Running Nginx 1.2.7 behind HAproxy, with SSL being terminated on on
HAproxy.
I was using the X_FORWARDED_PROTO header to make some decisions on the
backend when I was using Apache, but it doesn’t look like Nginx is
handling
the header currently:
client sent invalid header line: “X_FORWARDED_PROTO: http” while reading
client request headers,
I found an old thread that seemed to address this, with Igor suggesting
to
use:
but this doesn’t seem to be carrying the header forward. Maybe it’s a
lack
of understanding on my part or maybe the way the issue is handled has
changed in the years since that post (HERE: OSDIR), but if anyone has a
suggestion I would appreciate it.
On Mon, Apr 15, 2013 at 05:35:27PM -0400, jaychris wrote:
Hi there,
I was using the X_FORWARDED_PROTO header to make some decisions on the
backend when I was using Apache, but it doesn’t look like Nginx is handling
the header currently:
client sent invalid header line: “X_FORWARDED_PROTO: http” while reading
client request headers,
Strictly speaking, “_” isn’t invalid, but it’s not something nginx
allows by default due to security problems it might create - as
it’s indistinguishable from “-” in CGI-like headers
representation.
It is possible to allow the header in question using directives
mentioned, but better solution would be to use X-Forwarded-Proto
rather than X_FORWARDED_PROTO.
On Tue, Apr 16, 2013 at 02:06:30AM +0400, Maxim D. wrote:
On Mon, Apr 15, 2013 at 10:42:30PM +0100, Francis D. wrote:
On Mon, Apr 15, 2013 at 05:35:27PM -0400, jaychris wrote:
Hi there,
client sent invalid header line: “X_FORWARDED_PROTO: http” while reading
client request headers,
“_” is not a valid character in a http header.
Strictly speaking, “_” isn’t invalid, but it’s not something nginx
allows by default due to security problems it might create - as
it’s indistinguishable from “-” in CGI-like headers
representation.
Oh, thanks for the correction. I learn something new every day.
(RFC 2616 and its definition of “token”, which allows 78 characters,
if I count right. I don’t know if there’s a beyond-ASCII update to
extend
that, but it shouldn’t restrict it further.)