[Catalyst] RFC for handling reverse proxies not deployed to standard ports.

Dave Rolsky autarch at urth.org
Fri Jun 15 17:55:12 GMT 2007

On Fri, 15 Jun 2007, Marlon Bailey wrote:

> Suggestion:  I'd like to submit a solution that extends the current
> proxy-backend practice of reading the proxy values out of the request
> header.  Currently the client's IP is taken from a "X-Forwarded-For"
> header value, and the host's(Reverse Proxy) hostname is taken from a
> "X-Forwarded-Host" header value. I suggest adding the ability for
> Catalyst to set the host's port from a "X-Forwarded-Host-Port" header
> value.  This way a simple config option such as this

This would be great. When I'm doing development I often run an Apache on a 
non-standard (high) port, and have solved this problem in various apps.

For Catalyst, so far I've mostly been using the standalone server, but 
eventually I'll want to be able to test locally with a "real" server to 
mimic the eventual production environment.

> Extras considerations:  After speaking with Matt(mst) about this, he
> also suggested allowing the "Path" value to be set from a header value
> as well.

And _another_ one to add ...

Often the frontend of an app is listening on both http & https ports. When 
I generate URIs in the backend, I often want to take this into account and 
generate the scheme based on what the user requested.

In previous mod_perl apps, what I've done is have the backend server 
_also_ listen on two ports. Then I have the frontend forward to one or the 
other. The code will usually look for some sort of hack like an env var 
(which I only set in one vhost) that says "use https".

Adding a header like X-Forwarded-Was-HTTPS would be a much better 
solution. Basically, the more info about the original frontend request 
that can be captured the better.


VegGuide.Org                        www.BookIRead.com
Your guide to all that's veg.       My book blog

More information about the Catalyst mailing list