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

[Marlon Bailey]

I looked into how mod_proxy is handling this.  They pass a
X-Forwarded-Port header value with the port of the client.  So you can
rebuild the client information with

X-Forwarded-For
and X-Forwarded-Port

to tell whether the request was standard(port 80) or ssl(port 443) i
believe this would be a more general approach and seems to be working
for mod_proxy.  But it's beyond the scope of my RFC.


_Marlon_
On Fri, 2007-06-15 at 11:55 -0500, Dave Rolsky wrote:
> 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.
> 
> 
> -dave
> 
> /*===================================================
> VegGuide.Org                        www.BookIRead.com
> Your guide to all that's veg.       My book blog
> ===================================================*/
> 
> _______________________________________________
> List: Catalyst at lists.rawmode.org
> Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
> Dev site: http://dev.catalyst.perl.org/
> 


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.