Hi Youssef,
thank you for your tip, but we are already using a filter that does exactly the
same thing. We also set the character encoding in the reset and validation
methods of all action forms.
Is it possible, that this character encoding filter is called too late, i.e.
when the submitted request parameters are already processed?
Kind regards,
Christoph.
> Date: Mon, 23 Jun 2008 15:54:36 +0300
> From: [EMAIL PROTECTED]
> To: users@tomcat.apache.org
> Subject: Re: UTF-8 handling differs between two servlets within the same
> application
>
> Christoph;
> We used to have the same issue two years ago with older version of
> tomcat 4.x . And yes it was working just nice with Websphere.
> We resolved that but just adding a filter that would always set the encoding
> to utf8.
>
> namely ...
> in web.xml
>
>
> CharEncoding
> com.company.ipo.utils.CharSetFilter
>
>
>
> CharEncoding
> action
>
>
>
> and the class is ...
>
> public class CharSetFilter implements Filter {
>
> public void destroy() {
> }
>
> public void doFilter(ServletRequest request , ServletResponse response,
> FilterChain chain) throws IOException, ServletException {
>
> request.setCharacterEncoding("UTF-8");
> chain.doFilter(request,response);
> }
>
> public void init(FilterConfig arg0) throws ServletException {
>
> }
>
> }
>
>
> On Mon, Jun 23, 2008 at 1:38 PM, Christoph Pirkl wrote:
>
>>
>> Hi,
>>
>> we are developing an application, where we experience an interesting UTF-8
>> related behaviour.
>>
>> For the development the team mostly uses Tomcat, since the deployment is
>> much faster and nicer. All tests are repeated on WebSphere, because that is
>> what our customer runs.
>>
>> We are running a Tomcat environment
>>
>> Tomcat 6.0.16
>> Java 1.6 - 6
>> Struts 1.2.9
>> RHEL 4 and Windows XP / SP2
>>
>> and a WebSphere environment
>>
>> WebSphere 6.0.2.17
>> Java 1.4 (shipped with WS)
>> Struts 1.2.9
>> RHEL 4
>>
>> There is a login action and an action where the user can change his
>> password.
>>
>> Both forms use the "post"-method. Content of both HTML-pages is declared as
>> UTF-8. We use an encoding filter (Tomcat only) as described in:
>>
>> http://wiki.apache.org/tomcat/Tomcat/UTF-8
>>
>> Funny thing is:
>>
>> One of the servlets (login) works as expected.
>> Username and password are in proper UTF-8 encoding.
>>
>> The other servlet does not receive proper UTF-8.
>>
>> This way the password-hashes are corrupted if the user types in non-ANSI
>> chars (i.e. every char that needs multibyte encoding in UTF-8). The user
>> then cannot log into the application.
>>
>> In both cases the filter code is executed, we verified that with a
>> debugger.
>>
>> Tracing the client-server communication with WireShark shows that the
>> Web-Browser sends identical password data as a result of both forms.
>>
>> In the request object on the other hand the strings differ if a special
>> character was entered. We checked that with a debugger by setting a
>> breakpoint in the encoding filter.
>>
>> We added URIEncoding="UTF-8" in the connector, as suggested in various
>> posts we found googling the problem... unfortunately to no avail.
>>
>> If I'm not totally mistaken there is no application code run before the
>> filter, so either we are making a mistake that has slipped us (quite
>> possible) or we might have found a rare bug in Tomcat.
>>
>> On WebSphere the same code works without a problem.
>>
>> I would appreciate any kind of hint, since developing on Tomcat is much
>> more fun than on WebSphere.
>>
>> Thanks for your help in advance and with kind regards,
>>
>> Christoph.
>> ---------------------------------------------------------------------
>> To start a new topic, e-mail: users@tomcat.apache.org
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
> --
> Regards, Youssef
_________________________________________________________________
Die aktuelle Frühjahrsmode - Preise vergleichen bei MSN Shopping
http://shopping.msn.de/category/damenbekleidung/bcatid66/forsale?text=category:damenbekleidung&edt=1&ptnrid=230
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
