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.
I will not claim that I was reasonable when originally confronted with the change.
I will say that:
1. Our existing (4.1.x) usage of setCharacterEncoding() works across
all recent servlet engines tested [including 2 commercial servlet
engines] -- and is thus some indication of a de facto standard.
2. It would seem from examples provided with setCharacterEncoding()
by Sun that the intent is to include request parameters and that
thus this should be the default operation of this API rather than
requiring additional configuration to obtain this behavior.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
I did searches again after being scolded by Remy. I must admit that I must have crossed wires when doing searches and filing bugs and somehow managed to miss this search (which it is my habit to do).
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.
Agreed. Without a short summary attached to the bugs I would still have filed a new bug and argued to high hell...
-- Jess Holle
