httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan Ristic <>
Subject Re: Please vote - how to handle AllowEncodedSlashes
Date Mon, 24 Jan 2011 19:58:47 GMT
I've been following the discussion on this topic and, and I'd like to
share a thought with you.

>From the security perspective, allowing end users to control how %2f
is treated is problematic. Consider the situation in which you have
some sort of a HTTP monitoring device (either passive, or a reverse
proxy) in front of httpd. For this device to be effective, it must
interpret traffic in the way identical to the interpretation of the
web server. But if the %2f treatment is configurable, the device won't
know if /path%2fto is the same as /path/to. That creates a problem,
for example, when the device has to apply two different policies based
on the path (e.g., one policy for /path, another for /path/to).

A similar problem arises when httpd is used as a reverse proxy,
forwarding traffic to a backend server that handles %2f differently.
There are also other issues related to case sensitivity, the use of
other characters as path separators, and so on.

To sum it up, it would be best to choose one correct way to handle a
%2f and stick with it. That means getting rid of the
AllowEncodedSlashes directive, which was a bad idea to begin with. (On
the other hand, if you think that AllowEncodedSlashes should stay,
then Apache should add new directives to add all the other evasion
techniques that apply in reverse-proxy mode.)

On Mon, Jan 24, 2011 at 5:58 PM, Jim Jagielski <> wrote:
> On Jan 22, 2011, at 3:45 AM, Ruediger Pluem wrote:
>> [X] 4. backport the trunk behavior, but using a new option to set the current 2.2
>>       behavior to avoid breaking existing configurations from 2.0/trunk but enable
>>       2.2 users that rely on the new 2.2 behavior to get this back
> +1

Ivan Ristić

View raw message