On Sun. 2011-01-23 at 12:25 PM EST, Stefan Fritsch <[email protected]> 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?)
Dan
