You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2003/09/12 11:22:30 UTC
DO NOT REPLY [Bug 23128] New: -
ServletRequest.setLocale() sets encoding even when already set
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23128>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23128
ServletRequest.setLocale() sets encoding even when already set
Summary: ServletRequest.setLocale() sets encoding even when
already set
Product: Tomcat 4
Version: 4.1.27
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: makub@ics.muni.cz
Calling ServletRequest.setLocale(locale) sets "charset" attribute
even if it was already specified. Following code shows it:
public void doGet (...) {
PrintWriter out;
response.setContentType("text/plain; charset=utf-8");
out = response.getWriter();
out.println( "getCharacterEncoding() = " + response.getCharacterEncoding() );
response.setLocale(request.getLocale());
out.println( "getCharacterEncoding() = " + response.getCharacterEncoding() );
}
It will produce output
getCharacterEncoding() = utf-8
getCharacterEncoding() = ISO-8859-2
for my browser with "cs" locale. This bug was probably introduced
by patch mentioned in bug 6569. To be precise, the Servlet 2.3 javadoc says
for ServletResponse.setLocale():
http://java.sun.com/webservices/docs/1.0/api/javax/servlet/ServletResponse.html#setLocale(java.util.Locale)
Sets the locale of the response, setting the headers (including the
Content-Type's charset) as appropriate.
but the javadoc for Servlet 2.4 is more precise:
http://java.sun.com/webservices/docs/1.2/api/javax/servlet/ServletResponse.html#setLocale(java.util.Locale)
Sets the locale of the response, setting the Content-Language header,
if the response has not been committed yet. It also sets the response's
character encoding appropriately for the locale, if the character
encoding has not been explicitly set using
setContentType(java.lang.String) or
setCharacterEncoding(java.lang.String), getWriter hasn't been called
yet, and the response hasn't been committed yet.
So Servlet 2.3 was vague in this, but Servlet 2.4 says it clearly, that
setLocale() should not change charset, if it is already set.
The last draft of Servlet 2.4 specification say in part 5.4 on page 52,
that "explicit specifications take precedence over implicit specifications".
This is a major problem when using JSTL fmt: tags for displaying internationalized
messages, because each fmt: tag calls the setLocale() to set Content-Language
header, and accidentaly changes also the charset. This makes impossible
to display internationalized pages with multilingual content using utf-8,
as the utf-8 charset is always replaced by setLocale() call of the last fmt:
tag.