You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Nick Gearls <ni...@gmail.com> on 2007/10/03 12:11:09 UTC
mod_proxy & &headers
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" ?
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
To summarise, this should be done for _all_ headers:
- ProxyPass: change "https://proxy/..." to "http://back-end/..."
or "http://proxy/..." if "ProxyPreserveHost" was used
(replace "https" by "protocol1" and http by "protocol2" to be generic)
- ProxyPassReverse: change "http://back-end/..." to "https://proxy/..."
Does it sound sensible ?
Obviously, you could do it manually with "Header" & "RequestHeader"
(although I have problems to do it with 2.24 - is there a known issue
with mod_proxy), but you have to know every header by advance, and I do
not see any reason to not do it systematically.
Please correct or acknowledge my thought.
Nick
Re: mod_proxy & &headers
Posted by Ruediger Pluem <rp...@apache.org>.
On 10/03/2007 12:44 PM, Nick Gearls wrote:
> 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".
AFAIK this information is not only contained in the header but also in
the XML bodies WebDav uses during request and response.
There are cases where you need to ensure that reverse proxy and backend
have the same name and WebDav seams to be one of them.
There are different ways of getting this. e.g:
1. Using different DNS servers or via hosts files and using ProxyPass / http://proxy/
2. Using ProxyPreserveHost and using the same ServerName on the backend as on the frontend.
In order to create SSL URL's on the non SSL backend set ServerName to https://proxy.
Regards
Rüdiger
Re: mod_proxy & &headers
Posted by Nick Gearls <ni...@gmail.com>.
I agree, we have to check if it latches the back-end before changing it
to the front-end, and vice-versa.
This way, it sounds totally safe, no ?
Graham Leggett wrote:
> On Wed, October 3, 2007 1:03 pm, Nick Kew wrote:
>
>> It would break headers that contain a URL-like pattern that isn't
>> a URL. And if you think that's unlikely, just look at the number
>> of false positives in desktop software (e.g. mailers) that guesses
>> links and makes http://www.example.org or even just www.example.com
>> clickable.
>
> As I recall the ProxyPassReverse does an exact string prefix match on
> Location, and if there is a match, the header is changed, otherwise it
> leaves the header alone.
>
> By saying "ProxyPassReverse" it seems sane to be telling the proxy that it
> should hide every and all occurences of the backend url by replacing it
> with the frontend url, although from the perspective of changing existing
> behaviour in existing installations, a compromise would be to identify
> headers used by WebDAV, and alter those headers as well as Location.
>
> Regards,
> Graham
> --
>
>
>
Re: mod_proxy & &headers
Posted by Graham Leggett <mi...@sharp.fm>.
On Wed, October 3, 2007 1:03 pm, Nick Kew wrote:
> It would break headers that contain a URL-like pattern that isn't
> a URL. And if you think that's unlikely, just look at the number
> of false positives in desktop software (e.g. mailers) that guesses
> links and makes http://www.example.org or even just www.example.com
> clickable.
As I recall the ProxyPassReverse does an exact string prefix match on
Location, and if there is a match, the header is changed, otherwise it
leaves the header alone.
By saying "ProxyPassReverse" it seems sane to be telling the proxy that it
should hide every and all occurences of the backend url by replacing it
with the frontend url, although from the perspective of changing existing
behaviour in existing installations, a compromise would be to identify
headers used by WebDAV, and alter those headers as well as Location.
Regards,
Graham
--
Re: mod_proxy & &headers
Posted by Nick Kew <ni...@webthing.com>.
On Wed, 03 Oct 2007 12:44:28 +0200
Nick Gearls <ni...@gmail.com> wrote:
> 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 ?
Different headers have different patterns and different semantics.
There's no single rewrite that would work everywhere. See for
example the treatment of cookies.
What might be an idea is to make the list of headers to rewrite
a configuration option. I did a similar thing in mod_proxy_html 3
with ProxyHTMLLinks and ProxyHTMLEvents.
> 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.
It would break headers that contain a URL-like pattern that isn't
a URL. And if you think that's unlikely, just look at the number
of false positives in desktop software (e.g. mailers) that guesses
links and makes http://www.example.org or even just www.example.com
clickable.
--
Nick Kew
Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/
Re: mod_proxy & &headers
Posted by Nick Gearls <ni...@gmail.com>.
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 <ni...@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.
>
Re: mod_proxy & &headers
Posted by Nick Kew <ni...@webthing.com>.
On Wed, 03 Oct 2007 12:11:09 +0200
Nick Gearls <ni...@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.
--
Nick Kew
Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/