httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Gearls <nickgea...@gmail.com>
Subject Re: mod_proxy & &headers
Date Wed, 03 Oct 2007 10:44:28 GMT
Maybe I didn't describe the global picture, sorry.
There are obviously known headers that will never contain a URL, like 
the "Date" you mentioned, and several others.
However, you may have other headers containing the host URL, like 
"Destination" for the WebDAV protocol.
So, I was asking to check every header (we may potentially discard known 
ones, but that's an optimization) for the proxy/back-end URL, and fix it 
if needed.

Concretely, when using WebDAV, you can copy a file from one location to 
another; the client sends a "COPY" command on a URI "/dir/file", and 
sets a "Destination" header to - in my example - 
"https://proxy/newdir/newfile".
The WebDAV server refuses this because it receives a command to copy 
from "http://back-end/dir/file" to "https://proxy/newdir/newfile".

I personally have the problem with WebDAV, which is obviously a common 
one because of the standard, so we could fix only that header; but I 
imagine some other applications could use the same mechanism, so why not 
generalizing this to all headers ?
Excepting the little overhead, I find this a very robust solution. I 
don't think it breaks anything, so I would not see it as a behavior 
redesign.


Nick Kew wrote:
> On Wed, 03 Oct 2007 12:11:09 +0200
> Nick Gearls <nickgearls@gmail.com> wrote:
> 
>> Hi,
>>
>> I think mod_proxy should be enhanced/fixed in some way:
>> - If I use ProxyPass & ProxyPassReverse to forward connection from 
>> "proxy" to "back-end", ProxyPassReverse adapts the "Location" header 
>> from "back-end/..." to "proxy/...".
>>
>> 1. Why only the "Location header" ?
> 
> Because that's the only header you had that contained the string
> "back-end" with URL semantics.
> 
>> 2. In case you access your proxy in HTTPS, and your back-end in HTTP, 
>> ProxyPassReverse should also remove the protocol from all headers
>> 3. ProxyPass should do the same for all headers - fixing the
>> protocol, and possibly the host if "ProxyPreserveHost" was not used
> 
> How would you propose to rewrite, for example, the "Date" header?
> 
>> Does it sound sensible ?
> 
> I expect if you think through what you're asking, you'll eventually
> redesign the existing behaviour.  If not, tell us what's wrong.
> 

Mime
View raw message