While this is being looked at, it would be nice to pass along whether
the initial connection was HTTP or HTTPS for uri_for to make use of. If
the frontend is HTTPS and the backend is HTTP, uri_for breaks unless you
set an env variable (https=on?)

-----Original Message-----
From: Marlon Bailey
Sent: Friday, June 15, 2007 9:25 AM
To: catalyst@lists.rawmode.org
Subject: [Catalyst] RFC for handling reverse proxies not
deployed tostandard ports.

Current situation: There is no clean solution for deploying a reverse
proxy to a nonstandard HTTP(80)/HTTPs(443) port, like port 8080.

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

HEADER balancer_for_dev2 insert X-Forwarded-Host-Port: 8080

in a Perlbal config will give a clean solution.

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.

What do you guys think?

_Marlon Bailey_

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:
Dev site: http://dev.catalyst.perl.org/

Search Discussions

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcatalyst @
categoriescatalyst, perl
postedJun 15, '07 at 7:06p
activeJun 15, '07 at 7:06p

1 user in discussion

Dylan Vanderhoof: 1 post



site design / logo © 2022 Grokbase