Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
Message-ID: <3FBE5F71.3030603@gefionsoftware.com>
Date: Fri, 21 Nov 2003 10:54:41 -0800
From: Hans Bergsten <hans@gefionsoftware.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624
MIME-Version: 1.0
To: Tomcat Developers List <tomcat-dev@jakarta.apache.org>
Subject: Re: Justification for URIEncoding addition?
References: <8D966D6B75EB7F47AA300241BF2E1D0C01D11685@merc17.na.sas.com>
 <3FBE3CB4.40802@apache.org>
In-Reply-To: <3FBE3CB4.40802@apache.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Remy Maucherat wrote:
> Larry Isaacs wrote:
> 
>> Hi Remy,
>>
>> Okay, re-reviewed the original 22666 thread.  To complete this thread,
>> I'll assume the following from RFC2718 is our justification for the
>> new behavior:
>>
>>       Unless there is some compelling reason for a
>>       particular scheme to do otherwise, translating character
>>       sequences into UTF-8 (RFC 2279) [3] and then subsequently
>>       using the %HH encoding for unsafe octets is recommended.
>>
>> Tomcat will default to US-ASCII instead of UTF-8 so it won't break
>> too many existing webapps.  If there are other parts to this story,
>> I would be interested in learning of them.
>>
>> I'm still concerned that this makes Tomcat less useful by creating
>> deployment problems for webapps that aren't technically broken.
>> However, these issues were covered in the prior e-mail thread
>> (http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg46479.html), 
>>
>> so I'll drop the issue.  Thanks.
> 
> 
> The idea for the change is that there's no compelling reason (except 
> hacking) to have one part of the URI be in some encoding (US-ASCII or 
> UTF-8, if you want to have any chance of mapping it successfully), and 
> the rest encoded in something else.
> 
> There's indeed a bug thread on this issue, and I was on your side at first.

I've browsed through the thread referenced above as well as the comments
on bug 22666. Sorry if I'm missing something here, but to me it seems
like what Craig did for TC 4.x is the solution that's less harmful,
namely let Jasper get the "jsp_precompile" parameter by scanning the
getQueryString() result instead of using getParameter().

It's clear that enforcing the RFC2718 recommendation breaks a lot of
apps (based on all the bug reports and questions about this), and AFAIK,
most commonly used browsers (or all of them) use the encoding of the
page to encode parameters in both the body and the query string. It
therefore seems reasonable to use the setCharacterEncoding() value to
decode both types of parameters (at least as a default) and fix 22666
by avoiding the premature call to getParameter() that Jasper does in
the same way as it's done in TC 4.

My applogies if I missed a part of the thread that discussed this
solution and found it flawed.

Hans
-- 
Hans Bergsten                                <hans@gefionsoftware.com>
Gefion Software                       <http://www.gefionsoftware.com/>
Author of O'Reilly's "JavaServer Pages", covering JSP 2.0 and JSTL 1.1
Details at                                    <http://TheJSPBook.com/>


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org