httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Stoddard <>
Subject Re: URLs containing colon: Win32 vs. Linux
Date Thu, 25 Sep 2003 23:54:48 GMT
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 

View raw message