Okay, I'm trying to writing an e-mail to those here at SAS Institute
to explain the behavioral change in Tomcat 5.0.14 and Tomcat 4.1.29 with respect to the URIEncoding issue, and how it impacts our webapps.
At the moment, I'm still struggling a bit on the justification for this
change.
True, the servlet spec only says that setCharacterEncoding() affects
the request body. However, it seems to me to leave the issue of character
encoding with respect to query parameters unaddressed. After my scan of
RFCs (primarily 2396, 1808, and 1738), what can and can't be used for
character encoding underneath URL encoding in the URI seems unaddressed
as well. If this is addressed somewhere, I would be interested in knowing
where.
I think the example provided in the 24557 bug, where an HREF is generated that includes a character encoded query, may not be that unusual. It is something that occurs in our webapps here at SAS. With the latest implementation, such a webapp that uses URLEncode(str) and another that uses URLEncode(str,"UTF-8") will need different values for URIEncoding. Thus, they can no longer be served under the same Host using the same connector/port. I think this represents a serious loss of functionality from prior versions, without strong justification, from what I can find. Not that I have lots of experience writing webapp, but I don't currently see a good use case for the current behavior. What am I missing?
I think it would be a benefit for the next releases of Tomcat 4.1.x and Tomcat 5.0.x to provide the ability to enable the old behavior, i.e. the query parameter character encoding is assumed to be the same as the request character encoding. Perhaps allowing URIEncoding="request" to enable this would be appropriate. I would also recommend the old behavior be the default as I think that would lead to fewer complaints on tomcat-user.
Sorry to raise this issue again so late. Thoughts?
Cheers, Larry
P.S. I haven't studied Bug 22666 yet. I'll take a look and see if there is something to learn there.
I don't agree.
Remy
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
