Hi all,
thank you very much for your helpful answers!
We could resolve the encoding problem by adding the attribute
enctype="multipart/form-data"
to the html form. All special chars are received correctly now. Additionally we
will add accept-charset="UTF-8" to avoid further problems.
Kind re
André Warnier wrote:
Mark Thomas wrote:
I tend to use the following as a starting point to check my config is
OK. It is also useful to compare headers etc for your application
against the headers from this simple test case.
http://wiki.apache.org/tomcat/FAQ/CharacterEncoding#Q4
This is a
Mark Thomas wrote:
I tend to use the following as a starting point to check my config is
OK. It is also useful to compare headers etc for your application
against the headers from this simple test case.
http://wiki.apache.org/tomcat/FAQ/CharacterEncoding#Q4
This is a bit outside the scope
André Warnier wrote:
If you agree, a question to start in that process :
In the login page, the element should have the following
attributes :
...>
Does it ?
Ref : http://www.w3.org/TR/html401/interact/forms.html#submit-format
and in particular : 17.13.4 Form content types
(among other things
Mark Thomas wrote:
André Warnier wrote:
It is quite possible that Tomcat's innards do not do things correctly
when they decode a POST, and just deliver the raw parameter value as
received. But that would surprise me, and I would submit that it
would then be a bug.
As far as I am aware, Tom
André Warnier wrote:
It is quite possible that Tomcat's innards do not do things correctly
when they decode a POST, and just deliver the raw parameter value as
received. But that would surprise me, and I would submit that it would
then be a bug.
As far as I am aware, Tomcat correctly decodes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
All,
Christopher Schultz wrote:
| The filter example on this page needs to be
| fixed so that the encoding is only set if one is not detected. This is a
| BIG BUG in the filter shown on that page, and someone should fix it
| (maybe I will... I just r
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
André,
André Warnier wrote:
| I am sorry to butt in again, but are you *really* sure that the problem
| is not earlier in the chain than what you think ?
| I have read the article at the link given earlier :
| http://wiki.apache.org/tomcat/Tomcat/UTF
Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Youssef,
Youssef Mohammed wrote:
Guys,
I am sorry to butt in again, but are you *really* sure that the problem
is not earlier in the chain than what you think ?
I have read the article at the link given earlier :
http
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Youssef,
Youssef Mohammed wrote:
| I don't think you need to encode again in the reset or validation. I
am not
| quite sure if calling setCharacterEncoding twice would be the problem
here.
| but just try to remove the redundant ones.
At best, callin
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
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;
>
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
Hi.
Christoph Pirkl wrote:
[...]
Not being a Tomcat/Websphere expert myself, but having had to track down
similar problems before, just a couple of notes :
If this is true :
Both forms use the "post"-method.
then the userid and password are sent in the body of the request, not in
the URI
14 matches
Mail list logo
