DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25162>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25162 "charset" parameter in "contentType" header is always included Summary: "charset" parameter in "contentType" header is always included Product: Tomcat 5 Version: 5.0.14 Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Connector:Coyote AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] I think, that this is a wrong idea to explicitly define a parameter "charset" for any contentType of Response. For examples: 1. I render a PDF document as a response of my servlet with contentType="application/pdf". Then the "IE" receives a header "application/pdf;charset=ISO-8859-1" and it can't understand this content type. Even more, do you see, that this charset parameter is useless here? 2. I put into my JSP page a line like this: <%@ page contentType="text/html;CHARSET=windows-1251" %>. I use here an uppercase for CHARSET to avoid character encoding (transforming) of my JSP page by the engine, so it must use a system default encoding (I use this for multilanguage support in my application, that works with a database without unicode, and I didn't thinking about encoding, just gives this part for browser). The browser receives a header: "text/html;CHARSET=windows-1251;charset=ISO-8859-1"! Great! Conclusion: take back a control on the content type to the user, please! --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
