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:
http {
map $http_x_forwarded_proto $my_https {
default off;
https on;
}
server {
…
location {
…;
fastcgi_param HTTPS $my_https;
}
}
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:
http://osdir.com/ml/nginx/2010-05/msg00101.html), but if anyone has a
suggestion I would appreciate it.
Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,238384,238384#msg-238384
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,
“_” is not a valid character in a http header.
http://nginx.org/r/ignore_invalid_headers or maybe
http://nginx.org/r/underscores_in_headers
f
Francis D. [email protected]
Thanks! Setting “underscores_in_headers on;” fixed the issue and
X_FORWARDED_PROTO is being carried forward now.
Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,238384,238387#msg-238387
Hello!
On Mon, Apr 15, 2013 at 10:42:30PM +0100, Francis D. wrote:
“_” is not a valid character in a http header.
http://nginx.org/r/ignore_invalid_headers or maybe
http://nginx.org/r/underscores_in_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.
–
Maxim D.
http://nginx.org/en/donation.html
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.)
Cheers,
f
Francis D. [email protected]