Incorrect X-Forwarded-For header parsing

[amiart]

The X-Forwarded-For header is parsed incorectly in THttpRequest::originatingClientAddress() function:

1. There may be multiple X-Forwarded-For headers in request.
2. The originatingClientAddress() does not check whether clientAddress() is trusted proxy - the clientAddress() is not included in X-Forwarded-For.
3. When splitting X-Forwarded-For don't use Tf::SkipEmptyParts.

See article:

https://httptoolkit.com/blog/what-is-x-forwarded-for/

Also there is no possibility to define proxy IP ranges.
Such a feature would be useful for TreeFrog to be able to work with Claudflare proxy servers:

https://www.cloudflare.com/ips/

Some time ago I made a pull request #296 that helps solving these problems (except bug 1), but was not merged.

[treefrogframework]

Thanks.
The pull request #296 rejected because UNIX domain communications were given special treatment.

In modern proxy/cloud services, the behavior of “merging into a single header” is recognized as being relatively standardized.
Please tell me under what circumstances multiple X-Forwarded-For headers occur. HTTPS?

[amiart]

Thank you for reply.

When I wrote #296, I based it on the ngx_http_realip_module:

https://nginx.org/en/docs/http/ngx_http_realip_module.html

It has a set_real_ip_from parameter, which could be set to unix: to specify that the server should trust the proxy communicating via a Unix domain socket.

I realize that most proxy servers join X-Forwarder-For headers into one. However, for security reasons, it is recommended not to rely on this:

https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/X-Forwarded-For#parsing