On Fri, Jun 15, 2007 at 11:09:23PM -0500, Dave Rolsky wrote:
On Sat, 16 Jun 2007, Matt S Trout wrote:
Does your interest in this extend to willingness to supply a patch?
If not, please allow Marlon to patch for the problem he sees and you can
solve your additional problem later ...
I
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
On Jun 15, 2007, at 12:24 PM, Marlon Bailey wrote:
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
Marlon Bailey wrote:
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
Marlon Bailey wrote on 6/15/07 11:24 AM:
I suggest adding the ability for
Catalyst to set the host's port from a X-Forwarded-Host-Port header
value.
What do you guys think?
I like. I have kludgy workarounds for this in my code that it be nice to see
part of the core app.
See also
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)
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
On Fri, 15 Jun 2007, Christopher H. Laco wrote:
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.
Ick.
X-Forwarded-Host-Secure
I don't really care about the name, I just
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
On Fri, Jun 15, 2007 at 12:43:09PM -0400, Andy Grundman wrote:
On Jun 15, 2007, at 12:24 PM, Marlon Bailey wrote:
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
On Fri, 15 Jun 2007, Marlon Bailey wrote:
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
On Fri, Jun 15, 2007 at 02:34:45PM -0500, Dave Rolsky wrote:
On Fri, 15 Jun 2007, Marlon Bailey wrote:
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
On Sat, 16 Jun 2007, Matt S Trout wrote:
Does your interest in this extend to willingness to supply a patch?
If not, please allow Marlon to patch for the problem he sees and you can
solve your additional problem later ...
I wasn't telling him not to do a patch for the port issue. Like I
13 matches
Mail list logo
