Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Message-ID: <004201c374f0$d8793120$d2b32b04@dslverizon.net>
From: "Bill Barker" <wbarker@wilshire.com>
To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>,
   <medthomas@ntlworld.com>
References: <01C374CB.9061AF90.medthomas@ntlworld.com>
Subject: Re: [PATCH] Bug 22666
Date: Sat, 6 Sep 2003 20:33:45 -0700
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----------=_1062905403-1347-543"

------------=_1062905403-1347-543
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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" <medthomas@ntlworld.com>
To: "'Tomcat Developers List'" <tomcat-dev@jakarta.apache.org>
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:remm@apache.org]
> 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: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>


------------=_1062905403-1347-543
Content-Type: text/plain; name="disclaimer.txt"
Content-Disposition: inline; filename="disclaimer.txt"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-Mailer: MIME-tools 5.411 (Entity 5.404)

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.

------------=_1062905403-1347-543--