Return-Path: 
 <users-return-239774-apmail-tomcat-users-archive=tomcat.apache.org@tomcat.apache.org>
X-Original-To: apmail-tomcat-users-archive@www.apache.org
Delivered-To: apmail-tomcat-users-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id E8430E72C
	for <apmail-tomcat-users-archive@www.apache.org>;
 Sun, 17 Feb 2013 22:57:59 +0000 (UTC)
Received: (qmail 61071 invoked by uid 500); 17 Feb 2013 22:57:56 -0000
Delivered-To: apmail-tomcat-users-archive@tomcat.apache.org
Received: (qmail 60995 invoked by uid 500); 17 Feb 2013 22:57:56 -0000
Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:users-help@tomcat.apache.org>
List-Unsubscribe: <mailto:users-unsubscribe@tomcat.apache.org>
List-Post: <mailto:users@tomcat.apache.org>
List-Id: <users.tomcat.apache.org>
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Delivered-To: mailing list users@tomcat.apache.org
Received: (qmail 60986 invoked by uid 99); 17 Feb 2013 22:57:56 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 17 Feb 2013 22:57:56 +0000
X-ASF-Spam-Status: No, hits=-0.0 required=5.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of aw@ice-sa.com designates
 212.85.38.228 as permitted sender)
Received: from [212.85.38.228] (HELO tor.combios.es) (212.85.38.228)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 17 Feb 2013 22:57:50 +0000
Received: from [192.168.245.129] (p549E1EBE.dip0.t-ipconnect.de
 [84.158.30.190])
	(Authenticated sender: andre.warnier@ice-sa.com)
	by tor.combios.es (Postfix) with ESMTPA id 3CC723C0792
	for <users@tomcat.apache.org>; Sun, 17 Feb 2013 23:57:54 +0100 (CET)
Message-ID: <51216057.9060004@ice-sa.com>
Date: Sun, 17 Feb 2013 23:57:27 +0100
From: =?ISO-8859-1?Q?Andr=E9_Warnier?= <aw@ice-sa.com>
Reply-To: Tomcat Users List <users@tomcat.apache.org>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: getRequestURI() in relation to Connector.URIEncoding
References: <SNT129-DS42C79290AB22F8C26B2C5A40F0@phx.gbl>
 <511D43A0.6040503@christopherschultz.net>
 <SNT129-DS105A07042643E2620AE048A40C0@phx.gbl> <51210B37.2000906@ice-sa.com>
 <51211635.5020208@apache.org> <SNT129-DS15902BC8E9BA7B7E7A2A59A40C0@phx.gbl>
In-Reply-To: <SNT129-DS15902BC8E9BA7B7E7A2A59A40C0@phx.gbl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Checked: Checked by ClamAV on apache.org

Mike Wilson wrote:
> Mark Thomas wrote:
>> On 17/02/2013 16:54, Andr� Warnier wrote:
>>> Mike Wilson wrote:
>> <snip/>
>>
>>>> Example 2: path /� in "binary" Unicode
>>>>   GET /.. [0xC3,0xA4]
>>>>   request.getRequestURI() -> "/.." [0xC3,0xA4]
>>>>   request.getPathInfo()   -> "/�"
>> <snip/>
>>
>>> I believe that your example #2 above is simply illegal.
>>> One is not supposed to send such bytes in a URL without 
>> URL-encoding them.
>>> That's per the HTTP RFC itself :
>>> RFC 2616 3.2.2 & 3.2.3
>>> (http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2.2)
>>> -> RFC 2396 part 2. URI Characters and Escape Sequences
>>> (http://www.ietf.org/rfc/rfc2396.txt)
>>>
>>> And I believe that the fact that Tomcat is returning the "correct"
>>> translation in the corresponding request.getPathInfo() is purely
>>> accidental, and it could be argued that this is a bug in 
>> Tomcat : the
>>> request should probably have been rejected, because the 
>> requested URL
>>> was invalid.
>> +1. It is on my list of things to do to check why this wasn't 
>> rejected 
>> with a 400 response.
>>
>> Mark
> 
> Explicitly making this invalid is probably fine, although it might
> be looked upon as "breaking" working systems. Note that we have
> apparently been running with a setup sending these binary URLs
> for years, where mod_jk is the source of the invalid URLs.
> Ie, the browser sends a nice URL-encoded URL which is decoded by 
> mod_jk before sending to Tomcat.
> 
> So might be appropriate to hold off this change to a release where
> back compat isn't crucial?
> 

Mmmm.
It stretches the imagination a bit to imagine that mod_jk by default takes a valid URL and 
makes it invalid before forwarding it to Tomcat.
As far as I recall, there are several options in mod_jk (ForwardURI* family) which allow 
to do things there, some of them unsafe.
So it raises the question : are you doing something until now which is considered as 
unsafe, and therefore are having that problem ?
(And a linked question is whether by changing this mod_jk option you could restore 
operability with a Tomcat rejecting the invalid URLs).

Otherwise, my feeling is that it will cost you quite a number of beers to stop Mark from 
fixing what could potentially be a security issue, now that he's sniffed it.


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