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
<filter>
<filter-name>CharEncoding</filter-name>
<filter-class>com.company.ipo.utils.CharSetFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>CharEncoding</filter-name>
<servlet-name>action</servlet-name>
</filter-mapping>
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 <[EMAIL PROTECTED]> 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.
> _________________________________________________________________
> 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]
>
>
--
Regards, Youssef
