httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: workaround for encoded slashes (%2f)
Date Mon, 13 Jan 2003 23:17:32 GMT
At 04:37 PM 1/13/2003, Greg Stein wrote:
>On Mon, Jan 13, 2003 at 06:46:19AM -0500, Rodent of Unusual Size wrote:
>> okey, here's anpther take on the %2f thing.  as a reminder, we
>> currently reject any reques that includes an encoded slash in the
>> pat with a 404.  this breaks environments which need to use %2f in
>> the path info.  the issue has to do, in part, with decoding the
>> %2fs into slashes, and possibly having to re-encode them again.
>> 
>> i've been fighting with saving %2f state and restoring it for a long
>> time, but to no definitely acceptable conclusion.  but last week a
>> possible alternative came to mind:  if the AllowEncodedSlashes directive
>> is set to 'on', unencode everything *except* %2f.  then let it go
>> through the normal processing.  if %2f is part of the path, the
>> request will fail with a 404 anyway when the document isn't found;
>> if the %2f is strictly in the path-info, it won't intefere with
>> document location and will be available to the resource as expected.
>> 
>> i have a patch for this against 2.1 that i'd like to send, but i
>> won't bother if people are going to veto all over it without even
>> looking at it.
>
>That sounds rather hacky. IMO, Apache should not do any URI decoding.
>Instead, Apache should figure out who is going to handle the request (i.e.
>map the identified resource to a handler), then let the handler do whatever
>processing is appropriate on the URI.

Agreed; %2F is not '/' and cannot be handled as '/'.

>Today, Apache unconditionally decodes the URI (see the problems that Mike
>Pilato just posted about today), which really horks systems that need to
>pass that URI further along (e.g. proxy-like code).

Well, there's nothing wrong with Apache today, we have two different
values, unparsed_uri and uri.

Granted, the model could be much cleaner ...

>If Apache is going to decode the URI, then it should first split the URI
>into path segments (an array) and then perform the decoding. Thus, you can
>make http://host/path/foo%2fbar/baz into ["path", "foo/bar", "baz"]. You can
>then encode each piece, and join them together with "/".

This is, in fact, the only way to handle this scenario.  The introduction of
%2F means that we have two URI entities (%2F and '/') each of which has
a distinct meaning.  And in general I like the proposal.

%2F as a segment separator cannot not be permitted.

The decoded %2f should then be treated as invalid within any apache file
resource (dir_walk/file_walk) but could then be permitted by some other
module.  The risk that those 'other modules' aren't prepared for it had better
be dealt with by introducing this into the 2.1-dev branch soon, allowing our
3rd party module authors time to prepare for the consequences before 2.2
is released to the world.

Since some folks are itching to cut apart the filesystem from the request_rec,
now seems like a golden opportunity to play out how this new logic would work.

Bill



Mime
View raw message