This is related to bugs 39746 and 38448. After turning on AllowEncodedSlashes, Apache lets us use percent encoded forward slashes in the path. Eg: "http://foo/hello%2Fworld" When using "ProxyPass / http://bar/" mod_proxy makes a request for: "http://bar/hello/world" That is wrong as I understand it. The forward slash at the end should be encoded still. RFC-1738, section 3.3 regarding HTTP URLs: "Within the <path> and <searchpart> components, "/", ";", "?" are reserved. The "/" character may be used within HTTP to designate a hierarchical structure." So... The forward slash is a reserved character. Section 2.2 says the following about reserved characters: "If the character corresponding to an octet is reserved in a scheme, the octet must be encoded." So as far as I can see http://foo/hello%2Fworld and http://foo/hello/world are distinctly different HTTP URLs that should be allowed to behave differently. Just because Apache treats them the same when serving local content, doesn't mean that other servers do when you're proxying the request to them, so I don't think the path should be rewritten in the way mod_proxy is doing it... Perhaps there should be an option called something like "ProxyPreservePathEncoding" which when turned on, means that *no* encoding/decoding of the path in the url is performed before it is proxied... If my browser makes a request for "http://foo/hello%2Fworld" and I have "ProxyPass / http://bar/" I *expect* it to call "http://bar/hello%2Fworld" not "http://bar/hello/world" as it does currently. It *should* be the default behaviour, but that would probably not be backwards compatible. Mike
*** Bug 35100 has been marked as a duplicate of this bug. ***
*** Bug 42592 has been marked as a duplicate of this bug. ***
*** Bug 39455 has been marked as a duplicate of this bug. ***
Fixed in Trunk in r588791.
Fixed in r596712.
I have an instance of mod_proxy doing reverse proxying using the "nocanon" parameter in the ProxyPass directive. The reason I needed this was that I'm dealing with IRIs on the path, and mod_proxy was decoding the characters for me. In any case, I find that when "nocanon" is turned on, mod_proxy appends the query twice and sent it to the target host, e.g.: Original request: http://mod-proxy-host.com/path?query The target was sent: http://localhost:8003/target?query?query This seems to be due to r->unparsed_uri containing the original query, whereas r->uri doesn't (and other parts of the code appends it to the target.)
Created attachment 21743 [details] Proof-of-concept that fixes the issue This is meant to demonstrate that it fixes the issue. However, I have not checked for security issues or whether it breaks other configurations.
Comments 6 and 7 appear to be opening a new report. Please don't hijack an old report for that. And if we're to take your NEW report seriously, we'll need more information, such as a configuration and request that trigger the problem with 2.2.8.
Sorry for hijacking this report. I've created bug 44730 to track the issue.