Fwd: [users@httpd] encoded slashes in the url with AllowEncodedSlashes

[Eric Covener <co...@gmail.com>]

On Thu, Jul 3, 2008 at 4:23 AM, Zac Hansen <xa...@gmail.com> wrote:
> I have AllowEncodedSlashes in my conf.  I am calling
>
> https://myserver.com/foo.cgi/a/b%2fc/d
>
> In the docs for AllowEncodedSlashes, it says it doesn't mean they will be
> decoded.

I believe AllowEncodedSlashes' meaning has been changed since:
http://svn.apache.org/viewvc?view=rev&revision=104925

Paying special attention to the the commit message, the 404 behavior
should have been correct/expected (assuming literal '%2f' isn't what
the core handler should have found in the filesystem).

Bill: I saw your veto in the biug below, would that apply to restoring
the original behavior of AllowEncodedSlashes as well or just the
approach in one of the patches?

https://issues.apache.org/bugzilla/show_bug.cgi?id=35256

-- 
Eric Covener
covener@gmail.com

Re: Fwd: [users@httpd] encoded slashes in the url with AllowEncodedSlashes

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Eric Covener wrote:
> 
> Bill: I saw your veto in the biug below, would that apply to restoring
> the original behavior of AllowEncodedSlashes as well or just the
> approach in one of the patches?
> 
> https://issues.apache.org/bugzilla/show_bug.cgi?id=35256

I have an interesting idea...

combine the decode and the get_parents, such that only an encoded slash
would have the text value "//" and only an encoded backslash would have
the value "\\"  It would then be up to the proxy to forward the original
URI value or up to the file system to reject such constructs.

It needs fleshing out, but these are canonically unique values after the
string has had get_parents applied.  Thoughts?