I'd go for 2) personally. If you force the POST parameters to UTF-8 (which I understand is what '3' does), you break almost every web-app out there. Granted, the request line (including the query-string) should be UTF-8, but I haven't tested how many browsers actually enforce this. The POST parameters will generally be in the encoding of the referrer (which usually isn't UTF-8).
----- Original Message ----- From: "Mark Thomas" <[EMAIL PROTECTED]> To: "'Tomcat Developers List'" <[EMAIL PROTECTED]> Sent: Saturday, September 06, 2003 3:06 PM Subject: RE: [PATCH] Bug 22666 > This is obviously a bigger mess than I first thought. As I see it, the > following options exist for resolving bug 22666. > > 1. WONTFIX - On the basis that there is too much uncertainty to do anything > sensible and that any changes made might break interoperability as per Remy's > point 3 below. > > 2. FIX - Patch the parameter class (as per Remy's point 2 below) on the grounds > that the JSP spec states "The World Wide Web Consortium (http://www.w3.org/) is > a definitive source of HTTP related information affecting this specification > and its implementations." and the w3c view > (http://www.w3.org/International/O-URL-code.html) is that URI encoding should > always be based on UTF-8. However, this is still likely to break things (back > to Remy's point 3). > > 3. FIX - Add a configuration option that enables w3c compliant URI decoding and > patch the parameter and any other relevant classes to support this option. I am > not 100% sure where the best place to do this would be. I am leaning towards > adding it to the context as an optional parameter with a default state of > disabled. > > There are several bugs in bugzilla that look as if they are on similar lines > and on that basis my own view is that option 3 is way to go. Before I start > coding, I would be grateful for some feedback/guidance on my planned approach. > > Thanks in anticipation. > > Mark > > > On Friday, September 05, 2003 8:13 PM, Remy Maucherat [SMTP:[EMAIL PROTECTED] > wrote: > > Mark Thomas wrote: > > > I was working from > > > > > > http://www.w3.org/International/O-URL-code.html > > > > > > Applying the patch fixed the problem as reported in bug 22666. I am happy > to > > > > > > have another look at this. Can you point me in the direction of a better > > > reference? > > > > Well, -1 because: > > 1) Everyone ignores this standard > > 2) Your encoding will apply to *all* parameters, not just URL > > parameters; you have to patch the Parameters class for your patch to be > > correct (I would still vote -1, but at least it wouldn't break the > > specification) > > 3) It is extremely likely that people expect all parameters to have the > > same encoding, regardless of what that w3c spec says; if the servlet > > spec writes in big bold somewhere that the URL is always UTF8 (which > > would likely break interoperability with a lot of HTTP clients - > > possibly all), then it's different > > > > Remy > > > > > > > > --------------------------------------------------------------------- > > 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] >
This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
