Summary: | HttpServletResponse.setContentType() parses the content type incorrectly | ||
---|---|---|---|
Product: | Tomcat 6 | Reporter: | Martin Havel <Martin.Havel> |
Component: | Servlet & JSP API | Assignee: | Tomcat Developers Mailing List <dev> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | P2 | ||
Version: | 6.0.29 | ||
Target Milestone: | default | ||
Hardware: | PC | ||
OS: | Windows XP |
Description
Martin Havel
2012-03-02 12:56:46 UTC
That was fun. Lots of sneaky edge cases parsing that little lot. Ended up implementing a new HTTP header parser. Fixed in trunk and 7.0.x and will be included in 7.0.27 onwards. I have proposed the fix for 6.0.x. (In reply to comment #1) > That was fun. Lots of sneaky edge cases parsing that little lot. Ended up > implementing a new HTTP header parser. > > Fixed in trunk and 7.0.x and will be included in 7.0.27 onwards. > > I have proposed the fix for 6.0.x. I do have similar issue and tested with latest Tomcat 7 code. What I observed is: 1. When the content type is ending with 'start-info="text/xml;charset=UTF-8"', at the browser I am getting: 'start-info="text/xml;charset=UTF-8";charset=ISO-8859-1'. charset=ISO-8859-1 is appended to content type. 2. When the content type is ending with 'start-info="text/xml"; charset=UTF-8', at the browser I am getting the same thing. There is not problem with this case. My question is: In case 1: even though charset exist (which is mentioned as UTF-8) in content type string, I am getting another extra charset (which is ISO-8859-1). Is it the expected behavior? Does the given content type is considered to as invalid/unknown content type? (In reply to comment #2) > My question is: Those are all questions for the users list. There is no Tomcat bug in the behavior you describe. The back-port proposal has been withdrawn due to a lack of support. A simpler solution is required. The original proposal used a pasrer generated by javacc. That has since been replaced in trunk and 7.0.x with a simpler implemenation. I have proposed a back-port of that simpler implementation. The backport of the simpler implementation has been committed and will be included in 6.0.38 onwards. |