Bumping this one, what do you think about: a) drop "Allowing encoded slashes does not imply decoding. Occurrences of %2F or %5C (only on according systems) will be left as such in the otherwise decoded URL string." since it has been decoding them for many years b) add a new option to AllowEncodedSlashes to get the "original" behavior of not decoding or further escaping the % c) put a smartly worded security stmt about why letting these float around escaped, or unescaped, is a bad idea.
For example, if the path segments won't be used to map to a file (PATH_INFO or interpreted otherwise by a script or backend) are you off the hook? d) See what exactly happens when you use this stuff with plugins like proxy, rewrite, etc. On Tue, Nov 2, 2010 at 2:03 PM, Eric Covener <[email protected]> wrote: > On Tue, Nov 2, 2010 at 12:55 PM, Dan Poirier <[email protected]> wrote: >> Actually, from https://issues.apache.org/bugzilla/show_bug.cgi?id=35256, >> it appears AllowEncodedSlashes hasn't worked right for some time, so >> there doesn't seem much point in fixing its config merging. >> >> Given the discussion in that bug, I'm wondering if AllowEncodedSlashes >> should just be deprecated or removed entirely. Thoughts? > > I think it sees a lot of use, so it would be nice to see how the > current behavior affects several modules (e.g. default/proxy/cgi (if > some use unparsed_uri maybe they could be misleading)) and fix the > doc then offer a "preserve" or "decode" option -- whichever isn't > happening now. Might even be useful to have an additional escape of > %2f as mentioned by wrowe in the PR. > > > -- > Eric Covener > [email protected] > -- Eric Covener [email protected]
