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@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. _______________________________________________ List: Catalyst@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/