On 01/21/2011 07:20 PM, Dan Poirier wrote:
> Can we take an informal vote on how best to handle AllowEncodedSlashes?
>
> At present, AllowEncodedSlashes Off (the default) results in any request
> containing an encoded slash, %2F, being rejected with a 404.
>
> In 2.0 and trunk, AllowEncodedSlashes On allows the encoded slash, but
> does not decode it. This keeps httpd from misinterpreting an encoded
> slash in a request as a path separator. I believe this was always
> the intended behavior.
>
> In 2.2, AllowEncodedSlashes On allows the encoded slash, and decodes it.
> This has caused problems for multiple people (see bugzilla, e.g. PR
> 35256), but has been the behavior since 2.2.0 (introduced in
> 2.1.something, I believe unintentionally).
>
> All the doc, even in 2.2, reflects the 2.0/trunk behavior.
>
> 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
Regards
Rüdiger
