Remy Maucherat wrote:
Jess Holle wrote:
Remy Maucherat wrote:
This is a good question -- but one which only applies to POST. My bug
case was explictly with GET.
If there is an entity body encoding specified in the request, then I
am not sure which should override. If there is not, then I would
presume setCharacterEncoding() should win out. If the only issue is
when these differ, then I believe that site designers should simply
ensure they don't.
I think you should read the HTTP RFC. content-type does not apply to the
URI or the HTTP header. The fact that setCharacterEncoding would apply
to (part of) the URI and/or the header violates the RFC on URIs.
Anyway, to put it simply: in the next release, add
useBodyEncodingForURI="true" on the connector, and you're done.
Please don't complain that it won't do what you want before trying it.
You can also use the URIEncoding attribute to specify the path encoding.
Rémy
my 2 cents on this issue,
Remy is for sure right stating that
a) the HTTP RFC does not cover variable character encoding for query
parameters for different requests
b) it is (sounds ?) logical to assume that the whole URI (including
paths, query parameters etc.) should be considered as being encoded with
the same character encoding
From a developers point of view however, applying the above two points
a) brakes expected behaviour (setCharacterEncoding() method does not
work the same as before)
b) does not give an acceptable alternative (if all parameter passing
could be solved with POST method, then the GET method would not be
needed, would it?)
c) a lot of web apps stopped working when an upgrade of the tomcat
version was performed
So I think it is legitimate to be upset when first confronted with this
change of behaviour.
As for how easy it is to NOT file duplicate bugs on this issue, having
followed this debate, I have collected the following list of somehow
related bugs
bug 25360
bug 25231
bug 25235
bug 22666
bug 24557
bug 24345
bug 23929
bug 25848
and of course a bunch of messages in the developer list
Speaking for myself and having reread these messages:
Assuming I 've been working for some time with the old behaviour and
experienced the new one, I would not be able to understand why this
change was made, EVEN if someone gave me the above list of bugs.
I propose the following:
write a short summary of why this change was necessary and include the
above list of bugs, as well as links to the related developer list
threads. Then submit a link to this summary to all the above bugs.
If not already done, port the useBodyEncodingForURI parameter to the
next 4.1.x release.
I volunteer to write the summary if the list thinks that the proposal is
reasonable.
Regards
Stefanos
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]