tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jess Holle <je...@ptc.com>
Subject Bug 23929: ServletRequest.setCharacterEncoding()
Date Mon, 05 Jan 2004 15:36:53 GMT
Remmy, et al:

The API is *not* optional.  It is a required part of the servlet spec.

It works just great in Tomcat 4.1 and is not an acceptable regression in 
Tomcat 5.  I am thus one step away from re-opening this bug 
(http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23929)

I cannot use the encoding setting on the connector as the standard 
handling of servlet parameters is ISO-8859-1 decoding unless 
setCharacterEncoding() is used to specify something else.  All of our 
other code thus follows this standard carefully (and works across all 
servlet engines tested).  [This includes handling multi-byte data in 
servlet parameters.]  This does require some careful shuffling to 
workaround the fact that the wrong encoding was used by the servlet 
engine and to use the correct one (UTF-8 in most, but not all, cases).

We do, however, have some code which leverages this new API to 
setCharacterEncoding("UTF-8") -- which is, in fact, very nice to have.  
I can see that it can be obnoxious for implementation -- but users of 
the API do not and should not care.

Tomcat 5 has a lot of promising things over Tomcat 4.1 -- don't let spec 
non-compliance force those who are forced to care about rigorous i18n to 
tell our customers to use Tomcat 4.1 or pay for a commercial servlet 
engine if they want later spec compliance.

--
Jess Holle



---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Mime
View raw message