Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Message-ID: <3F738048.6050001@wstoddard.com>
Date: Thu, 25 Sep 2003 19:54:48 -0400
From: Bill Stoddard <bill@wstoddard.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.4) Gecko/20030624
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: URLs containing colon: Win32 vs. Linux
References: <3F73380A.30604@modperlcookbook.org>
 <3F72CA65.4080700@attglobal.net> <3F730EB3.9010401@wstoddard.com>
 <3F73380A.30604@modperlcookbook.org>
 <5.2.0.9.2.20030925162553.0d484950@pop3.rowe-clan.net>
In-Reply-To: <5.2.0.9.2.20030925162553.0d484950@pop3.rowe-clan.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

William A. Rowe, Jr. wrote:
> At 02:00 PM 9/25/2003, Jeff Trawick wrote:
> 
>>Geoffrey Young wrote:
>>
>>
>>>while I'm still new exactly how APR fits in the whole picture, maybe some of ap_core_translate belongs there, since what seems to be happening is that some OSs get tripped up on valid URIs (and 3.3 of RFC 2396 does seem to indicate that the URI presented is indeed valid).
>>
>>yes, the URI is indeed valid...  however, core's translate name hook has to assume the URI maps directly to a file on disk via DocumentRoot, and APR is able to tell us (on Win32, Netware, etc.) that the resulting filename isn't valid...
> 
> 
> The handler is going to have to run defense around one of the hooks, either
> translate_name, or map_to_storage, to prevent us from attempting to serve
> the file from the file system.  r->proxyreq is also fatal, but mod_proxy does
> just that to prevent the file from being translated.
> 
> But I suspect our real problem is that translate name shouldn't try to handle
> the file name... that the map_to_storage hook should.  

 From http_request.h...
/**
  * This hook allow modules an opportunity to translate the URI into an
  * actual filename.
  ...
  */

> If we merge those
> two core handlers into the map_to_storage phase, do we sufficiently
> resolve the problem?
> 
> As far as embedded colons, less than or greater than signs in the filename
> path, we need to come up with much more clever code to accept those.
> 
> Perhaps we can cooerce the filepath functions to 'ignore' invalid filename
> parts in these merge operations with an APR_FILEPATH_ALLOW_INVALID
> argument.  Then it's up to the dir_walk'er to merge in components, and
> allow such cruft once it is past the 'filename' part, into the PATH_INFO part.
> 
> Bill 
>