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

Reply via email to