Jess Holle wrote:my 2 cents on this issue,
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
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]
