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]
