Jan Luehe wrote:
Remy,

Remy Maucherat wrote:

Jan Luehe wrote:

Bill,

then I'd suggest simply
doing:
setCharacterEncoding(getCharacterEncoding());
in Response.getWriter (since the spec only requires that we identify the
charset when using a Writer, and we don't really know what it is when using
OutputStream).




The problem with this is that if you call getWriter() (with your proposed fix) followed by getContentType(), the returned content type
will include a charset, which is against the spec of getContentType():


  * If no character encoding has been specified, the
  * charset parameter is omitted.

This is why we need to append the default charset to the value of the
Content-Type header, if no char encoding has been specified.



This is not acceptable, and is not an option, so you shouldn't be using "we need", because we won't ;)


This is why I said "we need" instead of "we will". ;-)

I agreed with Bill's proposed solution in principle (include charset
only when using writer), but pointed out that his proposed patch
would break ServletResponse.getContentType(), which is why I said that
if we were to include the default charset (if no charset was specified
and if a writer was being used), we'd have to do it at the time of
generating the header.

I'll reply to your other mail shortly.

Actually, I just found that Bill's patch would fix the issue and be compliant with the spec:

ServletResponse.getWriter:

     * If the response's character encoding has not been
     * specified as described in <code>getCharacterEncoding</code>
     * (i.e., the method just returns the default value
     * <code>ISO-8859-1</code>), <code>getWriter</code>
     * updates it to <code>ISO-8859-1</code>.

So it *is* expected for getContentType() to include a
"charset=ISO-8859-1" if no char encoding had been specified
before getWriter() was called.

This way, the charset would automatically be included in the
Content-Type response header.

I'll revert my patch and apply Bill's solution.

Thanks, Bill!

Jan



Jan


The right solution is IMO to point out the issues to the specification people.

Rémy


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]




--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]





--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to