Jan Luehe wrote:
yes, sorry, I had forgotten about that case.
Believe, I didn't commit yesterday's patch simply because I don't have anything better to do. It's come up as a compliance issue which had been masked by an unrelated problem that was fixed.
I thought the issue caused enough trouble last time ;) I remember we got a huge amount of bug reports on that.
So what I suggest is that you send that you send that as feedback to the servlet API, and that they put a small errata for the specification.
ServletResponse.setCharacterEncoding/setContentType/setLocale...
* <p>Containers must communicate the character encoding used for * the servlet response's writer to the client if the protocol * provides a way for doing so. In the case of HTTP, the character * encoding is communicated as part of the <code>Content-Type</code> * header for text media types. Note that the character encoding * cannot be communicated via HTTP headers if the servlet does not * specify a content type; however, it is still used to encode text * written via the servlet response's writer.
Reason: Many browsers let the user choose which encoding to apply to responses that don't declare their encoding, which will result in data corruption if the response was encoded in ISO-8859-1 and the user picks an incompatible encoding.
The user can still manually override the charset on its client if it wants to do so. I don't see how the specified behavior fixes anything.
ServletResponse.getContentType...:
* If no character encoding has been specified, the * charset parameter is omitted.
Reason: Allow setLocale() to set the response's char encoding (corresponding to the locale) if the char encoding has not already been set by setContentType() or setCharacterEncoding().
You can find corresponding wordings in the servlet spec.
Therefore, we need to add a charset to the Content-Type response header if:
- no response encoding has been specified (ie., the return value of ServletResponse.getContentType() has no charset), and - the response is using a writer
My patch did not check for the latter.
Well, this would be a big improvement already (the implementation is inefficient, also, but either Bill or me can rework it). People who wanted to generate PDFs from JSPs had trouble (but it made sense), now it'll be worse. This doesn't seem very useable overall.
Rémy
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
