Handling x_forwarded_proto with Nginx as backend to HAproxy

Server NGINX
#1

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

#2

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]

#3

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

#4

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

#5

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]