DO NOT REPLY [Bug 24970] - charset appended to content-type even if not text/*

[bugzilla]

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]