Hi Maxim,

Thank you for your reply.


> I don't see how this is explicitly allowed by RFC 7239.

In Section 4:

A proxy MAY remove all "Forwarded" header fields from a request.

And in Section 6.2:

The "unknown" identifier is used when the identity of the preceding
entity is not known, but the proxy server still wants to signal that
a forwarding of the request was made.


> And anyway this is an information loss, see above.

Isn't it acceptable to lose information from a badly malformed header?
An upstream probably wouldn't be able to extract that information
anyway, so this should only affect upstream debug/logging.


I understand your general misgivings, though.


> It should be more or less trivial to implement config-based
> emulation of $proxy_add_forwarded, using map{} and appropriate
> regular expression checks. The main problem here is ticket #1316,
> yet it probably should be addressed separately.

Until such a time as #1316 is dealt with, do you think it would be a
good idea to explicitly set Forwarded to
ngx_http_process_multi_header_lines, like X-Forwarded-For?


> On the other hand, such approach also faces the problem on
> what to do with syntactically invalid Forwarded headers, and I
> don't think I know a solution.

Any reasonable implementation of Forwarded on the upstream must be
prepared to deal with such malformed headers anyway. (For example,
aiohttp is.) So, in cases where the upstream is known to do this, the
config-based approach could be workable.


--
Vasiliy
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel