On 22/06/2014 5:15 p.m., Amos Jeffries wrote: > Support receiving PROXY protocol version 1 and 2. > > PROXY protocol has been developed by Willy Tarreau of HAProxy for > communicating original src and dst IP:port details between proxies and > load balancers in a protocol-agnostic way. > > stunnel, HAProxy and some other HTTP proxying software are already > enabled and by adding support to Squid we can effectively chain these > proxies without having to rely on X-Forwarded-For headers. > > This patch adds http(s)_port mode flag (proxy-surrogate) to signal the > protocol is in use, parsing and processing logics for the PROXY protocol > headers on new connections, and extends the follow_x_forwarded_for > (renamed proxy_forwarded_access) access control to manage inbound > connections. > The indirect client security/trust model remains unchanged. As do all > HTTP related logics on the connection once PROXY protocol header has > been received. > > > Furture Work: > * support sending PROXY protocol to cache_peers > * rework the PROXY parse logics as a Parser-NG child parser. > > Amos >
So on the table the question of the http_port option name (and derived from that the *_access control name). The contenders so far: proxy surrogate [1] proxy-surrogate [1] require-PROXY expect-PROXY [2] require-PROXY-header expect-PROXY-header [2] forwarded [3] proxy-forwarded [3] haproxy-protocol[4] indirect-client [1] potential naming confusion with Surrogate protocol HTTP extension. And Alex objects that it means "nothing" in this squid context. [2] potential naming confusion with "explicit proxy" terminology [3] potential naming confusion with "forward proxy" terminology [4] free advertising for the competition At this stage it looks like Alexs' "require-proxy-header" is front runner for relevance. Probably with "indirect_client" for the access control. Does anyone else have optin names or even just words to throw into the mix? Amos
