I do not believe Mr. Lucifer's "patch" should be applied. As has been
pointed out a number of times Tomcat is the reference implementation for
the JSP and servlet JCRs.
In the Servlet 2.3 PFD2 specification you find the following in the
definition of parseQueryString():
"The query string should be in the form of a string packaged by the
GET or POST method, that is, it should have key-value pairs in the
form key=value, with each pair separated from the next by a &
character."
People regularly ask for "features" that run contrary to the
specification (e.g. a common request/confusion is that parsePostData()
should handle the "multipart/form-data" encoding) - these requests are
turned down. If you want to change/query the specification talk to the
JCR people not to the Tomcat implementers!
Even if the Tomcat implementers were prepared to entertain Mr. Lucifer,
I don't believe that his assertion that interpreting the b in
"a=1&b&c=2" as b="" [i.e. inserting a key value pair of (b, "") into the
hashtable that's returned by parseQueryString()] shouldn't break
anything. Under the current specification such a pair should be
impossible and people can safely code on the assumption that the
hashtable returned by parseQueryString() will never contain such a pair
- adding in Mr. Lucifer's patch renders this assumption false despite it
being valid according to the Servlet specification.
So IllegalArgumentException seems to be the correct response to the
query string presented by Mr. Lucifer as his query string is clearly
invalid according to the specification. While it maybe reasonable for
Tomcat to compensate for buggy clients where their popularity demands it
AND it DOES NOT clash with the specification it is not reasonable where
there is a clash. [Individual application developers can of course do
what they like, e.g. catch the exception and parse the query string
themselves.]
Neither Internet Explorer, Netscape or Opera would (I believe) generate
a query string from a standard form GET or POST like the one presented
by Mr. Lucifer, so my guess is that it is a Javascript or application
generated URL in which case - fix the Javascript or application, or if
you're not in a position to do so code your application to parse the
query string itself rather than requesting a change in Tomcat.
Yours,
George.
