> -----Original Message----- > From: Remy Maucherat [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 19, 2003 5:43 PM > To: Tomcat Developers List > Subject: Re: cvs commit: > jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/htt > p Parameters.java > > > Larry Isaacs wrote: > > Hi All, > > > > Sorry to pipe up so late on this, but a recent re-org still has me > > still swamped at work. > > > > I'm not sure if the patch below is doing exactly what was > > intended. I am unable to get the servlet example provided by > > Mirek Hankus in: > > > > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24557 > > > > to work in Tomcat 5.0.14, even with URIEncoding="UTF-8" specified > > on the connector. It seems to me that it should work with a > > request which has a query parameter that is UTF-8 encoded > > and URL encoded, as this example implements. Note that the > > UTF-8 encoding is applied first, followed by the URL encoding, > > which makes sense. > > > > The reason it doesn't work in Tomcat 5 is that, in spite of > > URIEncoding="UTF-8", the added code: > > > > + decodedQuery.setEncoding(queryStringEncoding); > > + decodedQuery.toChars(); > > > > is applying the UTF-8 decoding prior to URL decoding, which I > > think is guaranteed to have no effect. Prior to this change, > > the URL decoding would occur first, followed the by UTF-8 > > decoding, which successfully unwinds the encoding of the query > > parameter. The current implementation doesn't seem right, or > > am I missing something? > > > > Note that this is separate from the "should setCharacterEncoding() > > apply to query parameters issue", which I think gave rise to this > > change. I don't have a disagreement with that decision. > > > > Assuming this is a bug, I think it would be good to address > this prior > > to declaring Tomcat 5.0.x as stable. Unfortunately, I haven't > > had time yet look for a good solution. I'll continue looking, but > > if somebody comes up with one before me, feel free to commit it. > > I'm still familiarizing my self with how things are plugged together > > in this case. > > > > I'm willing to back port any needed changes to Tomcat 4.1.x. SAS > > has a number internationalized webapps that rely on being able to > > UTF-8/URL encode parameters into HREFs. Currently they are all > > broken on Tomcat 4.1.29, and can't be made to work unless > > the URIEncoding property is added to the connector. I'm not > > sure how many others would be in the same boat. > > Now that's what I call perfect timing.
To tell the truth, I had glazed over writing documentation and decided I needed a diversion. The bug seemed like something I would benefit from understanding. > I'll try to fix it and > hopefully > not break anything too badly ... > > I hope you plan to test the fix within less than to months > (there could > be a ";-)", but I'm in stress mode right now ...) I'll work on getting my "gump" running again so I can test it quickly. > > BTW, there's nothing to backport to Tomcat 4.1.x. I couldn't find anything in Tomcat 4 that calls Parameters.setQueryStringEncoding(). I assume at least the URIEncoding support would need to be added to org.apache.coyote.tomcat4.CoyoteConnector as was done in Tomcat5's version of CoyoteConnector. Larry > > Rémy > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
