You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Martin Kuba <ma...@ics.muni.cz> on 2004/01/08 15:23:34 UTC
ServletRequest.setCharacterEncoding() and GET parameters
Hi,
I have found recently that current TomCat 5 uses different
encoding for POST and GET parameters. I was quite surprised,
because all bugs opened for this issue are just closed as invalid
without an explanation.
But after a long searching I found the discussion about bug 23929 at
http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg50866.html
and I understand now that in the next realease, there will be
a configuration option useBodyEncodingForURI="true" of a connector.
I just want to say that I think that it should be the default
setting, not something that must be found after searching web and mail
archives for several hours and manually injected into server.xml
I agree with Jess Hole that it is a de facto standard and
the SUN servlet specification seems to indicate that
setCharacterEncoding() should affect all parameters.
Remember that GET and POST parameters are merged together.
Using different encoding for GET and POST parameters by default
is counter-intuitive and breaks the Principle of least astonishment.
If it is kept that way, the same bug will be reported again and again.
Martin
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Supercomputing Center Brno Martin Kuba
Institute of Computer Science email: makub@ics.muni.cz
Masaryk University http://www.ics.muni.cz/~makub/
Botanicka 68a, 60200 Brno, CZ mobil: +420-603-533775
--------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: ServletRequest.setCharacterEncoding() and GET parameters
Posted by Martin Kuba <ma...@ics.muni.cz>.
Remy Maucherat wrote:
>> Using different encoding for GET and POST parameters by default
>> is counter-intuitive and breaks the Principle of least astonishment.
>> If it is kept that way, the same bug will be reported again and again.
>
>
> -1.
>
> The attribute, now that it actually exists, is well documented.
>
> Rémy
It is not included in the default server.xml available in CVS.
It would help if it is included so that its existence
and placement will be obvious.
Also it is not displayed in the Administration Tool.
The default setting breaks compatibility with older
versions of TomCat and with all other web containers.
So what is the reason for having that default value
and not the other ?
Martin
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Supercomputing Center Brno Martin Kuba
Institute of Computer Science email: makub@ics.muni.cz
Masaryk University http://www.ics.muni.cz/~makub/
Botanicka 68a, 60200 Brno, CZ mobil: +420-603-533775
--------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: ServletRequest.setCharacterEncoding() and GET parameters
Posted by Remy Maucherat <re...@apache.org>.
Martin Kuba wrote:
> Stefanos Karasavvidis wrote:
>
>> This is getting ridiculous.
>> Both sides have strong arguments.
>> I hadn't thought about this issue until tomcat changed it's behaviour,
>> and maybe the Sun folks didn't do it as well.
>>
>> This should really be clarified within the specification (and I hope
>> they come up with a solution that allows us to continue using GET
>> parameters as we were used to as this is an absolute necessity...
>> maybe by introducing a new method or a second parameter).
>>
>> Although I do not expect too much, I 've just sent a comment to JSR53
>> and JSR154
>
> Sorry, nobody answered my previous question. What is the strong
> argument for breaking backward compatibility ?
>
> The RFC 2396 (URI syntax) in part "2.1 URI and non-ASCII characters"
> states that:
>
> However, there is currently
> no provision within the generic URI syntax to accomplish this
> identification. An individual URI scheme may require a single
> charset, define a default charset, or provide a way to indicate the
> charset used.
>
> It is expected that a systematic treatment of character encoding
> within URI will be developed as a future modification of this
> specification.
>
> It means that URL character encoding is not defined by standards.
> So the only problem which I see is that Tomcat suddenly breaks
> the de facto standard used for last ten years and tries to
> stop application to use GET parameters.
The decision has been made and was argumented. Please look into the
archives of the mailing list. Please stop whining, this will not be
changed. Since I wasted too much time already on this, I will ignore all
subsequent threads/reply/etc on this particular subject, and will vote
-1 to any proposal to change this.
If you cannot be bothered into adding a parameter in the configuration
file to enable the behavior you want, I suggest you try to look for
another server.
The change to the 4.1.x branch was not intended, and is a bug.
The change to the 5.0.x branch was on purpose (and is a new branch, so
expect at least *some* changes in behavior).
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: ServletRequest.setCharacterEncoding() and GET parameters
Posted by Martin Kuba <ma...@ics.muni.cz>.
Stefanos Karasavvidis wrote:
> This is getting ridiculous.
> Both sides have strong arguments.
> I hadn't thought about this issue until tomcat changed it's behaviour,
> and maybe the Sun folks didn't do it as well.
>
> This should really be clarified within the specification (and I hope
> they come up with a solution that allows us to continue using GET
> parameters as we were used to as this is an absolute necessity... maybe
> by introducing a new method or a second parameter).
>
> Although I do not expect too much, I 've just sent a comment to JSR53
> and JSR154
Sorry, nobody answered my previous question. What is the strong
argument for breaking backward compatibility ?
The RFC 2396 (URI syntax) in part "2.1 URI and non-ASCII characters"
states that:
However, there is currently
no provision within the generic URI syntax to accomplish this
identification. An individual URI scheme may require a single
charset, define a default charset, or provide a way to indicate the
charset used.
It is expected that a systematic treatment of character encoding
within URI will be developed as a future modification of this
specification.
It means that URL character encoding is not defined by standards.
So the only problem which I see is that Tomcat suddenly breaks
the de facto standard used for last ten years and tries to
stop application to use GET parameters.
Martin
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Supercomputing Center Brno Martin Kuba
Institute of Computer Science email: makub@ics.muni.cz
Masaryk University http://www.ics.muni.cz/~makub/
Botanicka 68a, 60200 Brno, CZ mobil: +420-603-533775
--------------------------------------------------------------
Re: ServletRequest.setCharacterEncoding() and GET parameters
Posted by Stefanos Karasavvidis <st...@msc.gr>.
Jess Holle wrote:
> Remy Maucherat wrote:
>
>> -1.
>>
>> The attribute, now that it actually exists, is well documented.
>
>
> Yes, but the default behavior should be for setCharacterEncoding() to
> work according to general JSP/servlet usage recommendation e.g.:
> http://java.sun.com/developer/technicalArticles/Intl/MultilingualJSP/.
>
> If there are reasons this is unworkable, then these should be worked out
> with Sun so they stop telling everyone that this approach works. Until
> then obnoxious ignoramouses like me will try to do what Sun says, fail
> with Tomcat, and blame Tomcat.
>
> --
> Jess Holle
This is getting ridiculous.
Both sides have strong arguments.
I hadn't thought about this issue until tomcat changed it's behaviour,
and maybe the Sun folks didn't do it as well.
This should really be clarified within the specification (and I hope
they come up with a solution that allows us to continue using GET
parameters as we were used to as this is an absolute necessity... maybe
by introducing a new method or a second parameter).
Although I do not expect too much, I 've just sent a comment to JSR53
and JSR154
I just hope that the new tomcat versions will be released soon
Stefanos
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: ServletRequest.setCharacterEncoding() and GET parameters
Posted by Jess Holle <je...@ptc.com>.
Remy Maucherat wrote:
> -1.
>
> The attribute, now that it actually exists, is well documented.
Yes, but the default behavior should be for setCharacterEncoding() to
work according to general JSP/servlet usage recommendation e.g.:
http://java.sun.com/developer/technicalArticles/Intl/MultilingualJSP/.
If there are reasons this is unworkable, then these should be worked out
with Sun so they stop telling everyone that this approach works. Until
then obnoxious ignoramouses like me will try to do what Sun says, fail
with Tomcat, and blame Tomcat.
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: ServletRequest.setCharacterEncoding() and GET parameters
Posted by Remy Maucherat <re...@apache.org>.
Martin Kuba wrote:
> Hi,
>
> I have found recently that current TomCat 5 uses different
> encoding for POST and GET parameters. I was quite surprised,
> because all bugs opened for this issue are just closed as invalid
> without an explanation.
> But after a long searching I found the discussion about bug 23929 at
> http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg50866.html
> and I understand now that in the next realease, there will be
> a configuration option useBodyEncodingForURI="true" of a connector.
>
> I just want to say that I think that it should be the default
> setting, not something that must be found after searching web and mail
> archives for several hours and manually injected into server.xml
>
> I agree with Jess Hole that it is a de facto standard and
> the SUN servlet specification seems to indicate that
> setCharacterEncoding() should affect all parameters.
> Remember that GET and POST parameters are merged together.
>
> Using different encoding for GET and POST parameters by default
> is counter-intuitive and breaks the Principle of least astonishment.
> If it is kept that way, the same bug will be reported again and again.
-1.
The attribute, now that it actually exists, is well documented.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org