[Catalyst] RFC for handling reverse proxies not deployed to
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.
Your guide to all that's veg. My book blog
More information about the Catalyst