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
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 T
15 matches
Mail list logo
