httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Poirier <>
Subject Please vote - how to handle AllowEncodedSlashes
Date Fri, 21 Jan 2011 18:20:18 GMT
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


View raw message