$http_ variables only contain the first field-value

[vfaronov@…]

The value of the $http_X variable is the field-value of the first request header field named X. Further field-values, if any, are not included in the variable.

For example, given a request like:

GET / HTTP/1.1
Host: example.com
Forwarded: for=123.45.67.89
Forwarded: for=234.56.78.90

the value of $http_forwarded is for=123.45.67.89.

A more useful value would be for=123.45.67.89,for=234.56.78.90 (per ​RFC 7230 § 3.2.2).

Failing that, at least the current behavior should be documented.

[Maxim Dounin]

See also #1762.

[Maxim Dounin <mdounin@…>]

In 8023:08b3ea81ff5f/nginx:

Combining unknown headers during variables lookup (ticket #1316).

Previously, $http_*, $sent_http_*, $sent_trailer_*, $upstream_http_*,
and $upstream_trailer_* variables returned only the first header (with
a few specially handled exceptions: $http_cookie, $http_x_forwarded_for,
$sent_http_cache_control, $sent_http_link).

With this change, all headers are returned, combined together. For
example, $http_foo variable will be "a, b" if there are "Foo: a" and
"Foo: b" headers in the request.

Note that $upstream_http_set_cookie will also return all "Set-Cookie"
headers (ticket #1843), though this might not be what one want, since
the "Set-Cookie" header does not follow the list syntax (see RFC 7230,
section 3.2.2).

[Maxim Dounin]

Fixed, thanks to all involved.

[thomas.d.spear@…]

Hi, I found this ticket linked from ​https://www.nginx.com/resources/wiki/start/topics/examples/forwarded/ and wanted to ask since it is fixed now if the warning could be taken down or at least amended so as to clarify that this has now been fixed as of version x.yy, which ever version is the earliest with this fix?

Warm regards,

Thomas Spear

[Maxim Dounin]

Wiki articles are not maintained by nginx developers, but rather by users, if at all. The warning you are referring to is certainly no longer relevant starting with nginx 1.23.0 and in newer versions. On the other hand, the whole article looks, at least, questionable. Either way, feel free to update it if you think it worth the effort.

[nyurik@…]

Replying to Maxim Dounin:

Wiki articles are not maintained by nginx developers, but rather by users, if at all. The warning you are referring to is certainly no longer relevant starting with nginx 1.23.0 and in newer versions. On the other hand, the whole article looks, at least, questionable. Either way, feel free to update it if you think it worth the effort.

Maxim, thanks for fixing this! Do you know if there are any plans to provider easier path to use the Forwarded header? That wiki page approach with an unreadable regex is, indeed, a horrid hack. In your opinion, should Nginx provide a standard way to handle that? Where would it be documented or requested? (Trac is a bit harder to use than github, but I couldn't find anything relevant)

[Maxim Dounin]

Maxim, thanks for fixing this! Do you know if there are any plans to provider easier path to use the Forwarded header? That wiki page approach with an unreadable regex is, indeed, a horrid hack. In your opinion, should Nginx provide a standard way to handle that? Where would it be documented or requested? (Trac is a bit harder to use than github, but I couldn't find anything relevant)

I don't think it needs any special support. Just adding a header with appropriate address is trivial, and can be easily done with existing mechanisms. But attempts to validate the existing header, as the wiki article tries to do, look incorrect and misleading. And these attempts reveal the issue with the Forwarded header as defined by RFC 7239: first elements of the header are not expected to be correct or trusted, yet complex syntax makes it trivial to parse the header incorrectly. In general, I would recommend to use the X-Forwarded-For header instead, or even simpler one, X-Real-IP.