You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Graham Leggett <mi...@sharp.fm> on 2000/02/18 11:13:02 UTC
[Patch] Content-Location headers stripped by reverse proxy
Hi all,
Microsoft IIS v4.0 wants to place Content-Location headers on responses
to requests. When such a server is reverse proxied, Apache allows this
header, containing private backend information, through to the browser.
Normal browsers seem to ignore the Content-Location header, however WAP
phones do not. This header causes the WAP browser to bypass the reverse
proxy and access the backend server directly.
Our first solution was to treat the Content-Location header the same way
Location headers were treated with ProxyPassReverse. But: Microsoft IIS
v4.0 contains a bug where an attempt to access the URL
http://somesite:8080/index.wml will return a Content-Location that says
http://somesite/index.wml. The missing port number caused the WAP phone
to go off to a different site completely. Oops.
Our second solution is simpler: If the request is a reverse proxy,
filter out the Content-Location header. After being reverse proxied the
info in the Content-Location header is incorrect and irrelevant anyway.
The patch is enclosed...
Regards,
Graham
--
-----------------------------------------
minfrin@sharp.fm "There's a moon
over Bourbon Street
tonight...
Re: [Patch] Content-Location headers stripped by reverse proxy
Posted by Ben Laurie <be...@algroup.co.uk>.
Graham Leggett wrote:
>
> Ben Laurie wrote:
>
> > I think if you want any chance of this kind of thing being accepted
> > you're going to have to make a general purpose "strip these headers when
> > proxying" thing. I certainly can't see us always stripping
> > Content-Location simply because some phone companies can't implement
> > their browsers correctly.
>
> During reverse proxy behaviour I believe the Content-Location header
> should be stripped anyway, because it contains incorrect information
> once it reaches the browser.
You have a good point there :-)
Correcting it may be better, though.
Cheers,
Ben.
--
SECURE HOSTING AT THE BUNKER! http://www.thebunker.net/hosting.htm
http://www.apache-ssl.org/ben.html
Y19100 no-prize winner!
http://www.ntk.net/index.cgi?back=2000/now0121.txt
Re: [Patch] Content-Location headers stripped by reverse proxy
Posted by Graham Leggett <mi...@sharp.fm>.
Ben Laurie wrote:
> I think if you want any chance of this kind of thing being accepted
> you're going to have to make a general purpose "strip these headers when
> proxying" thing. I certainly can't see us always stripping
> Content-Location simply because some phone companies can't implement
> their browsers correctly.
During reverse proxy behaviour I believe the Content-Location header
should be stripped anyway, because it contains incorrect information
once it reaches the browser.
> Have you submitted a patch for the WAP phones? Oh, no, silly me. No
> source. Shucks.
Hehehe.
Yes I have. I have spent a number of weeks trying to track down someone
in the development team responsible for the phone in question.
Unfortunately the only responses I have got back so far are mails with
me CC'ed on them saying "do you know who this should go to? Do you? Or
do you?".
Regards,
Graham
--
-----------------------------------------
minfrin@sharp.fm "There's a moon
over Bourbon Street
tonight...
Re: [Patch] Content-Location headers stripped by reverse proxy
Posted by Ben Laurie <be...@algroup.co.uk>.
Graham Leggett wrote:
>
> Hi all,
>
> Microsoft IIS v4.0 wants to place Content-Location headers on responses
> to requests. When such a server is reverse proxied, Apache allows this
> header, containing private backend information, through to the browser.
>
> Normal browsers seem to ignore the Content-Location header, however WAP
> phones do not. This header causes the WAP browser to bypass the reverse
> proxy and access the backend server directly.
>
> Our first solution was to treat the Content-Location header the same way
> Location headers were treated with ProxyPassReverse. But: Microsoft IIS
> v4.0 contains a bug where an attempt to access the URL
> http://somesite:8080/index.wml will return a Content-Location that says
> http://somesite/index.wml. The missing port number caused the WAP phone
> to go off to a different site completely. Oops.
>
> Our second solution is simpler: If the request is a reverse proxy,
> filter out the Content-Location header. After being reverse proxied the
> info in the Content-Location header is incorrect and irrelevant anyway.
>
> The patch is enclosed...
I think if you want any chance of this kind of thing being accepted
you're going to have to make a general purpose "strip these headers when
proxying" thing. I certainly can't see us always stripping
Content-Location simply because some phone companies can't implement
their browsers correctly.
Have you submitted a patch for the WAP phones? Oh, no, silly me. No
source. Shucks.
Cheers,
Ben.
--
SECURE HOSTING AT THE BUNKER! http://www.thebunker.net/hosting.htm
http://www.apache-ssl.org/ben.html
Y19100 no-prize winner!
http://www.ntk.net/index.cgi?back=2000/now0121.txt