* on the Wed, Mar 07, 2007 at 04:41:08PM +0000, Mike Cardwell wrote: >> Using the standard Redhat Enterprise 4, Apache 2.0.52 RPMs here. I have >> a CommunigatePro server. It runs it's own http daemon for the >> administration interface, and webmail. We needed to extend it in several >> ways, so I stuck an Apache mod_proxy in front of it. Here's the config I >> used which works fine: >> >> ProxyPass / https://127.0.0.1:9100/ >> ProxyPassReverse / https://127.0.0.1:9100/ >> >> However. When using webmail, if you go to view an attachment like for >> example "filename.txt" from message "message_id" in folder "INBOX" the >> url would look like: >> >> https://the.domain/session/session_id/MessagePart/INBOX/message_id/filename.txt >> >> That works absolutely fine. The problem is when the file is in a >> subfolder, eg "INBOX/Archive". Then the url becomes: >> >> https://the.domain/session/session_id/MessagePart/INBOX%2FArchive/message_id/filename.txt >> >> With the url above, mod_proxy simply does *nothing*, I get an Apache 404 >> error message because the path doesn't exist locally because mod_proxy >> hasn't attempted to do the proxying. I've used tcpdump to verify that >> there is no connection to port 9100 when I make the request. >> >> Is this a bug, or am I doing something dumb? > I found a solution to this problem. It's not a bug, just unexpected > default behaviour I guess. I solved it over on the users list anyway. > > Sorry for wasting your time.
Ok. I'm back. I've come to the conclusion that mod_proxy is actually using incorrect behaviour. 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... Does anyone agree/disagree? Is this something that can/should be fixed, or are there backwards compatibility issues? If there are backwards compatability issues can/should an option be added to mod_proxy for preserving character encoding, eg: ProxyPreservePathEncoding ... ? Thanks, Mike
