Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
Message-ID: <3FF98A72.2060703@apache.org>
Date: Mon, 05 Jan 2004 17:01:54 +0100
From: Remy Maucherat <remm@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.5) Gecko/20031007
MIME-Version: 1.0
To: Tomcat Developers List <tomcat-dev@jakarta.apache.org>
Subject: Re: Bug 23929: ServletRequest.setCharacterEncoding()
References: <20031231213837.10315.qmail@nagoya.betaversion.org>
 <3FF98495.1000108@ptc.com>
In-Reply-To: <3FF98495.1000108@ptc.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

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.

R�my

> 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