When creating the HttpServletResponse the setContentType(type) is used for setting the content type and character encoding. If the type is for example: multipart/related;boundary=1_4F50BD36_CDF8C28;Start="<31671603.smil>";Type="application/smil;charset=UTF-8" it is parsed and the content type is set to: multipart/related;boundary=1_4F50BD36_CDF8C28;Start="<31671603.smil>";Type="application/smil and character encoding to: UTF-8 I believe it is incorrect, the content type should be: multipart/related;boundary=1_4F50BD36_CDF8C28;Start="<31671603.smil>";Type="application/smil;charset=UTF-8" and the character encoding should be set to default (ISO-8859-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.
(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.