> >
> > The problem is that browsers do not send the charset used to encode the
> > form's parameters; but they sent the request with the ContentType header
> > application/x-www-form-urlencoded. The charset should follow the encoding
> > type ex: "application/x-www-form-urlencoded; charset=UTF8" but in most of
> > cases does not.
>
> I know. But that's the standard, and we have to follow it first.
> If that fails ( and will - in most browsers that ignore the standards ) -
> then we can try workarounds.
>
>
> > >From my point of view instead of implementing a routine in charge of
> > analysing the request header to extract the data's encoding charset (few
> > chances for it to really work), It would be better to adopt the following
> > policy:
> There is no "instead" here - in addition of the ";charset=" we can do
> many things.
I 100% agree. Standard routines "must" be implemented and used and if they fail we can try workarounds.
In fact, I've already made and tested locally all modification that concern my suggestion for following versions:
* JServ 1.1.2 (It is not more supported but a lot of people still use it. A patch could be placed in JServ downloads)(Classes modified: org.apache.jserv.JServConnection, org.apache.jserv.JServServletManager and a new classes is added grouping limitating function for parameters parsing from javax.servlet.http.HttpUtils class)
* Tomcat 3.1.1 and Tomcat 3.2.1 (modified classes: org.apache.tomcat.util.RequestUtils, org.apache.tomcat.facade.RequestDispatcherImpl and a new class with parsing routines org.apache.tomcat.util.HttpUtils)
So if it can help.
Adalbert
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
