httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Covener <cove...@gmail.com>
Subject Re: Why AllowEncodedSlashes config not merged?
Date Fri, 14 Jan 2011 17:18:45 GMT
Bumping this one, what do you think about:

a) drop "Allowing encoded slashes does not imply decoding. Occurrences
of %2F or %5C (only on according systems) will be left as such in the
otherwise decoded URL string." since it has been decoding them for
many years
b) add a new option to AllowEncodedSlashes to get the "original"
behavior of not decoding or further escaping the %
c) put a smartly worded security stmt about why letting these float
around escaped, or unescaped, is a bad idea.

  For example, if the path segments won't be used to map to a file
(PATH_INFO or interpreted otherwise by a script or backend) are you
off the hook?

d) See what exactly happens when you use this stuff with plugins like
proxy, rewrite, etc.



On Tue, Nov 2, 2010 at 2:03 PM, Eric Covener <covener@gmail.com> wrote:
> On Tue, Nov 2, 2010 at 12:55 PM, Dan Poirier <poirier@pobox.com> wrote:
>> Actually, from https://issues.apache.org/bugzilla/show_bug.cgi?id=35256,
>> it appears AllowEncodedSlashes hasn't worked right for some time, so
>> there doesn't seem much point in fixing its config merging.
>>
>> Given the discussion in that bug, I'm wondering if AllowEncodedSlashes
>> should just be deprecated or removed entirely.  Thoughts?
>
> I think it sees a lot of use, so it would be nice to see how the
> current behavior affects several modules (e.g. default/proxy/cgi (if
> some use  unparsed_uri maybe they could be misleading)) and fix the
> doc then offer a "preserve" or "decode" option -- whichever isn't
> happening now.  Might even be useful to have an additional escape of
> %2f as mentioned by wrowe in the PR.
>
>
> --
> Eric Covener
> covener@gmail.com
>



-- 
Eric Covener
covener@gmail.com

Mime
View raw message