httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Poirier <>
Subject Re: Please vote - how to handle AllowEncodedSlashes
Date Mon, 24 Jan 2011 13:00:56 GMT
On Sun. 2011-01-23 at 12:25 PM EST, Stefan Fritsch <> wrote:

> On Sat, 22 Jan 2011, Ruediger Pluem wrote:
>>> How to handle?
>>> [ ] 1. change the 2.2 doc to reflect the actual 2.2 behavior
>>> [ ] 2. backport the trunk behavior as-is, so 2.0/2.2/trunk behave the same
>>> [ ] 3. backport the trunk behavior, but using a new option to avoid
>>>     breaking existing configurations that might depend on the current
>>>     behavior
>> [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.
> AIUI, this is the same as on/off/decode in Bill's proposal.

Right, I think we have two new choices added to my original list:

[ ] 4. change "AllowEncodedSlashes On" in 2.2 to match the 2.0/trunk
       behavior, but add a new option ("Decode") that would behave
       like "AllowEncodedSlashes On" in 2.2 behaves now.

[ ] 5. Choice 4, and add another new option to specify what %2F should
       decode to.  (Maybe this would be an optional parameter to Decode
       rather than a separate option.)

To my mind, (4) has the drawback of possibly breaking people who do a
minor upgrade from 2.2.x to 2.2.x+1.  But it could only break people who
have the non-default "AllowEncodedSlashes On" configured - I wonder how
common that is?

Note that we could do (3) or (4) now, and add (5) later.

Bill would like (5) to provide a way to specify Unicode strings.  I'm
fine with that, but if we do, perhaps we should consider providing that
in a more general form than just for this directive?  (Maybe that's what
Bill is proposing?)


View raw message