tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <>
Subject Re: Bug 23929: ServletRequest.setCharacterEncoding()
Date Mon, 05 Jan 2004 16:01:54 GMT
Jess Holle wrote:

> Remmy, et al:
> The API is *not* optional.  It is a required part of the servlet spec.

Great. I didn't know that ;-)

How about:
- Not CCing me. I'm subscribed to tomcat-dev already. thanks.
- There's big threads, commit messages (incl recent ones), and bugs on 
this issue. How about reading that before writing an email about how bad 
things are.

BTW, there's no bug.


> 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 
> (
> 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:
For additional commands, e-mail:

View raw message