ProxyPassReverse - dropping the port value in location?

ProxyPassReverse - dropping the port value in location?

am 24.10.2003 02:00:55 von Phillip Rhodes

Thanks for the great product! However, I am totally stressed out because I
pushed a new version of a proxied application into production because some
customers had problems with high ports and their firewalls. Now the
application is broken for everyone!

I am using Apache 2.0.4.3 with mod_proxy.
When there is a redirect with a Location header, mod_proxy is rewriting it
to use the port from whence it came. Normally, this would be okay. The
problem is that the mod_proxy instance is not running on the same port as
the "public" site. I am using a pics firewall to forward the requests
to the mod_proxy.

Is there a way to control the values that mod_proxy will use in a
ProxyPassReverse?


My problem is that I need to change the location header that is being sent
back to the client from mod_proxy to be the "public address"


Browser (https://www.x.com)
---->>>>

Pics Firewall forwards request to internal web server running on HIGH
PORT (https://www.x.com:8943)
--->>>>

Web server for www.x.com on port 8943 receives request. Forwards request
to internal application server.

ProxyPass / http://internal.x.com/
ProxyPassReverse / http://internal.x.com/


The client browser is receiving a location header of https://www.x.com:8943
I need it to be https://www.x.com
Just drop the port.

I understand that the simpliest solution would be to run on 80/443 and the
problem would go away. But there are limited ip addresses in our dmz,
networking requests... etc...

Any other ideas?

Re: ProxyPassReverse - dropping the port value in location?

am 24.10.2003 17:31:08 von Daniel Lopez

Phillip,

Take a look at the ServerName directive and
http://httpd.apache.org/docs-2.0/mod/core.html#usecanonicaln ame

If I understand correctly your setup, the redirect is being sent by
www.x.com, independently of whether mod_proxy is installed or not.

With the above directives you can tell www.x.com to always construct self
referential URLs (such as those used with redirects, reverse proxies,
mod_rewrite etc.) as www.x.com and not www.x.com:8943

Cheers

Daniel

On Thu, Oct 23, 2003 at 08:00:55PM -0400, Phillip Rhodes wrote:
> Thanks for the great product! However, I am totally stressed out because I
> pushed a new version of a proxied application into production because some
> customers had problems with high ports and their firewalls. Now the
> application is broken for everyone!
>
> I am using Apache 2.0.4.3 with mod_proxy.
> When there is a redirect with a Location header, mod_proxy is rewriting it
> to use the port from whence it came. Normally, this would be okay. The
> problem is that the mod_proxy instance is not running on the same port as
> the "public" site. I am using a pics firewall to forward the requests
> to the mod_proxy.
>
> Is there a way to control the values that mod_proxy will use in a
> ProxyPassReverse?
>
>
> My problem is that I need to change the location header that is being sent
> back to the client from mod_proxy to be the "public address"
>
>
> Browser (https://www.x.com)
> ---->>>>
>
> Pics Firewall forwards request to internal web server running on HIGH
> PORT (https://www.x.com:8943)
> --->>>>
>
> Web server for www.x.com on port 8943 receives request. Forwards request
> to internal application server.
>
> ProxyPass / http://internal.x.com/
> ProxyPassReverse / http://internal.x.com/
>
>
> The client browser is receiving a location header of https://www.x.com:8943
> I need it to be https://www.x.com
> Just drop the port.
>
> I understand that the simpliest solution would be to run on 80/443 and the
> problem would go away. But there are limited ip addresses in our dmz,
> networking requests... etc...
>
> Any other ideas?
>
>
>
>

--
Teach Yourself Apache 2 -- http://apacheworld.org/ty24/