Bug 41798 - mod_proxy rewrites url paths badly
Summary: mod_proxy rewrites url paths badly
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_proxy (show other bugs)
Version: 2.0.52
Hardware: All Linux
: P2 normal with 11 votes (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
Depends on:
Blocks: 43454
  Show dependency tree
Reported: 2007-03-09 02:20 UTC by Mike Cardwell
Modified: 2008-04-01 11:03 UTC (History)
4 users (show)

Proof-of-concept that fixes the issue (1.15 KB, patch)
2008-03-31 15:26 UTC, Wil Tan
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Cardwell 2007-03-09 02:20:45 UTC
This is related to bugs 39746 and 38448.

After turning on AllowEncodedSlashes,
Apache lets us use percent encoded forward slashes in the path. Eg:


When using "ProxyPass / http://bar/"

mod_proxy makes a request for:


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.

Comment 1 Nick Kew 2007-09-09 15:38:08 UTC
*** Bug 35100 has been marked as a duplicate of this bug. ***
Comment 2 Nick Kew 2007-09-09 16:25:02 UTC
*** Bug 42592 has been marked as a duplicate of this bug. ***
Comment 3 Nick Kew 2007-09-10 03:10:46 UTC
*** Bug 39455 has been marked as a duplicate of this bug. ***
Comment 4 Nick Kew 2007-10-26 16:08:47 UTC
Fixed in Trunk in r588791.
Comment 5 Nick Kew 2007-11-20 07:29:51 UTC
Fixed in r596712.
Comment 6 Wil Tan 2008-03-31 15:24:47 UTC
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:


The target was sent:


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.)
Comment 7 Wil Tan 2008-03-31 15:26:23 UTC
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.
Comment 8 Nick Kew 2008-03-31 15:43:00 UTC
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.
Comment 9 Wil Tan 2008-04-01 11:03:34 UTC
Sorry for hijacking this report. I've created bug 44730 to track the issue.