tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <>
Subject Re: svn commit: r371765 - /tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/connector/
Date Fri, 03 Feb 2006 08:54:34 GMT
Jan Luehe wrote:
> I don't think you are misunderstanding the spec.
> See the following javadocs snippets from ServletResponse:
>     public String getCharacterEncoding():
>      * If no character encoding
>      * has been specified, <code>ISO-8859-1</code> is returned.
>     public PrintWriter getWriter() throws IOException:
>      * 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>.
>     public void setCharacterEncoding(String charset):
>      * <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.

Yes, but the strict dumb application of what ended up being written 
written is definitely not what they intended, because it brings no 
benefits. I think everyone agrees that if the application is very 
careful about not specifying a charset anywhere, it shouldn't be 
forcefully added to the content-type header.

- Did you read the "for text media types" portion ? I find it important.
- "communicated as part of the Content-Type header": ISO-8859-1 is the 
default for HTTP, so one could consider it is communicated even if it is 
not physically present in the Content-Type header.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message