DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=24970>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=24970 charset appended to content-type even if not text/* [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Priority|Other |High Resolution|FIXED | ------- Additional Comments From [EMAIL PROTECTED] 2004-07-30 13:11 ------- I agree with Paul Brohman, the bug is still present in 4.1.30. response.setContentType( "application/pdf" ); gives Content-Type: application/pdf;charset=ISO-8859-1 I've tried with Response.class from attachment 9309 first in {TOMCAT INSTALL}/server/classes/org/apache/coyote/Response.class and then by replacing Response.class in tomcat-coyote.jar with the same result. So I looked the source of Response.java and found in setContentType : if (!hasCharset) { this.contentType = type; return; } In the other case (if hasCharset is true), and if charsetValue is valid, then charsetSet is set to true. The problem is the folowing : - I'm using J2EE 1.3 so the method setCharacterEncoding() can't be used. - When compiling a JSP, tomcat adds automaticaly response.setContentType("text/html;charset=ISO-8859-1"); in the _jsp.java file. Doing this, charsetSet is set to true in response and characterEncoding is set to ISO-8859-1. Then my own code says : response.setContentType( "application/pdf" ); But in this case, charsetSet is NOT reset to false, and characterEncoding keeps it's old value. I think the above code should almost be : if (!hasCharset) { this.contentType = type; charsetSet=false; return; } Or charsetSet should be set to false at the begining of setContentType; But this means for those who can use setCharacterEncoding(), to use it AFTER setContentType(); So to completely fix the problem, I think that setCharacterEncoding() should set a special boolean and setContentType() another one. Then getContentType() should append the charset expression to Content-Type if one the the two boolean is true. In this case we will have the folowing results : response.setCharacterEncoding( "ISO-8859-1" ); response.setContentType( "application/pdf" ); response.getContentType( ) -> Content-Type: application/pdf;charset=ISO-8859-1; response.setCharacterEncoding( "ISO-8859-1" ); response.setContentType( "plain/text;charset=UTF-8" ); response.getContentType( ) -> Content-Type: plain/text;charset=UTF-8; response.setContentType( "plain/text;charset=UTF-8" ); response.setCharacterEncoding( "ISO-8859-1" ); response.getContentType( ) -> Content-Type: plain/text;ISO-8859-1; response.setContentType("text/html;charset=ISO-8859-1"); response.setContentType( "application/pdf" ); response.getContentType( ) -> Content-Type: application/pdf Nevertheless waiting for the bug to be fixed, a workaround is to use the reset() method who sets charsetSet to false. response.reset(); response.addHeader( "Content-Disposition", "inline; filename=\"" + strFileName + "\"" ) ; response.setContentType( "application/pdf" ); response.setContentLength(data.length); response.getOutputStream().write( data ) ; response.getOutputStream().close() ; Regards --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]