You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jeff Trawick <tr...@attglobal.net> on 2003/09/25 12:58:45 UTC
URLs containing colon: Win32 vs. Linux
Does anybody have a quick answer, like "can't have colon anywhere in uri
path" or "we're busted" or something else?
URL is http://127.0.0.1:8080/dobedobedo;session=0:0
dobedobedo doesn't really exist
Apache 2.0.47 on Win32:
-> 403 (no reason logged)
Apache 2.0.47 on Linux:
-> 404
I'll try to figure out which filepath operation is blowing and make sure
we log something for such errors and see what we should be doing.
Re: URLs containing colon: Win32 vs. Linux
Posted by Günter Knauf <ef...@gmx.net>.
Hi Jeff,
> Does anybody have a quick answer, like "can't have colon anywhere in uri
> path" or "we're busted" or something else?
> URL is http://127.0.0.1:8080/dobedobedo;session=0:0
> dobedobedo doesn't really exist
> Apache 2.0.47 on Win32:
> -> 403 (no reason logged)
> Apache 2.0.47 on Linux:
> -> 404
Apache 2.0.47 on NetWare:
-> 403
nothing in error log; access log shows:
1.2.3.4 - - [25/Sep/2003:14:08:01 +0200] "GET /dobedobedo;session=0:0 HTTP/1.1" 403 393
Guenter.
Re: URLs containing colon: Win32 vs. Linux
Posted by Bill Stoddard <bi...@wstoddard.com>.
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
>
Re: URLs containing colon: Win32 vs. Linux
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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. 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
Re: URLs containing colon: Win32 vs. Linux
Posted by Jeff Trawick <tr...@attglobal.net>.
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...
Re: URLs containing colon: Win32 vs. Linux
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
hi :)
> A
> module like mod_php would have to determine -sometime in the
> translate_name phase- that it is serving the object requested and
> prevent ap_core_translate from running (returning OK on it's translate
> name hook?) the make darn sure it's handler did not decline the request.
how would you enforce the fact that there are several phases between
translation and content where modules can set r->handler? for instance,
it's common in mod_perl land to use fixups to set r->handler based on $foo.
a few core modules do this too (such as mod_include and mod_dav, I noticed).
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).
--Geoff
Re: URLs containing colon: Win32 vs. Linux
Posted by Bill Stoddard <bi...@wstoddard.com>.
Jeff Trawick wrote:
> Does anybody have a quick answer, like "can't have colon anywhere in uri
> path" or "we're busted" or something else?
>
> URL is http://127.0.0.1:8080/dobedobedo;session=0:0
>
> dobedobedo doesn't really exist
>
> Apache 2.0.47 on Win32:
> -> 403 (no reason logged)
>
> Apache 2.0.47 on Linux:
> -> 404
>
> I'll try to figure out which filepath operation is blowing and make sure
> we log something for such errors and see what we should be doing.
>
Jeff and I had a discussion and here is our conclusion...
The is a valid URL -if- the content is not being served out of the file
system. It should be possible for mod_php, for instance, to serve this
URL. The problem occurs when ap_core_translate, which is the last
translate_name hook to run, does the final mapping of a URI to a
filename because the URI above does not map to a valid filename. A
module like mod_php would have to determine -sometime in the
translate_name phase- that it is serving the object requested and
prevent ap_core_translate from running (returning OK on it's translate
name hook?) the make darn sure it's handler did not decline the request.
Does that analysis sound reasonable?
Bill
Re: URLs containing colon: Win32 vs. Linux
Posted by Jeff Trawick <tr...@attglobal.net>.
Jeff Trawick wrote:
>> It's probably apr_filepath_merge in server/core.c:ap_core_translate
>> (cannot verify from here).
>
>
> That was my top suspect. I'll see if I can build on Windows and fix the
> logging in this area.
yep, it was ap_translate_name()
This is a lot better than the previous silence:
[Thu Sep 25 08:50:52 2003] [error] [client 127.0.0.1] (20024)The
given path misformatted or contained invalid characters: Invalid URI
in request GET /dobedobedo;session=0:0 HTTP/1.1
though it is pretty wordy :)
> But, in the real world failure the module which is supposed to handle
> this has a translate hook (pretty darn sure) and would ordinarily handle
> that stage as long as it knows it is supposed to handle that request.
> And we don't seem to be getting that module's translate hook called. But
> I am pretty fuzzy in the operation of that module, so better tracing
> should probably be my first goal so there is no doubt where it is failing.
off to look at this
Re: URLs containing colon: Win32 vs. Linux
Posted by Jeff Trawick <tr...@attglobal.net>.
André Malo wrote:
> Jeff Trawick wrote:
>
>> Does anybody have a quick answer, like "can't have colon anywhere in
>> uri path" or "we're busted" or something else?
>>
>> URL is http://127.0.0.1:8080/dobedobedo;session=0:0
>>
>> dobedobedo doesn't really exist
>>
>> Apache 2.0.47 on Win32:
>> -> 403 (no reason logged)
>
>
> Can't have colon in filepath.
It isn't intended to be a filepath, but just maybe we assume it is
before we get far enough for a module that handles the object to tell
the core server that. Unclear.
>It's probably apr_filepath_merge in
> server/core.c:ap_core_translate (cannot verify from here).
That was my top suspect. I'll see if I can build on Windows and fix the
logging in this area.
But, in the real world failure the module which is supposed to handle
this has a translate hook (pretty darn sure) and would ordinarily handle
that stage as long as it knows it is supposed to handle that request.
And we don't seem to be getting that module's translate hook called.
But I am pretty fuzzy in the operation of that module, so better tracing
should probably be my first goal so there is no doubt where it is failing.
Re: URLs containing colon: Win32 vs. Linux
Posted by André Malo <nd...@perlig.de>.
Jeff Trawick wrote:
> Does anybody have a quick answer, like "can't have colon anywhere in
> uri path" or "we're busted" or something else?
>
> URL is http://127.0.0.1:8080/dobedobedo;session=0:0
>
> dobedobedo doesn't really exist
>
> Apache 2.0.47 on Win32:
> -> 403 (no reason logged)
Can't have colon in filepath. It's probably apr_filepath_merge in
server/core.c:ap_core_translate (cannot verify from here).
nd