backend PROXY support - thought dump

[Nils Goroll]

Hi,

yesterday I have written backend PROXY2 support for an ancient varnish2 fork
which we still maintain - and doing so is part of the plan to get rid of it.

What I have now is simply support for

	sub vcl_pipe {
		return (proxy);
	}

which does what I need.

Varnish mainline currently does have PROXY support for frontend connections, but
not for backend connections.

After a brief irc discussion with phk on irc, I understand that Dag is already
working on changing this, so I'd like to dump some thoughts which accumulated in
this context:

It became apparent to me that having this feature available would facilitate
clustered and layered varnish setups and remove quite a bit of additional logic
regarding client IP handling:

- pipe mode with PROXY would offer a particularly efficient way to load-balance
  from a (possibly dumb) varnish node terminating client connections to worker
  nodes for actual request processing.

  This could eliminate additional L4 loadbalancers in many scenarios.

- generic backend PROXY mode would simplify code requiring client.ip in
  clustered and layered varnish setups.

  Non-pipe PROXY mode with the protocol as-it would require single-request
  connections and as such would be highly inefficient. Adding a per-request
  PROXY header would appear to be a simple solution, but in his spec
  http://www.haproxy.org/download/1.5/doc/proxy-protocol.txt Willy
  explicitly forbids such use:

	(http proxies) MUST use the facilities provided by this protocol to
	present the client's address.

  The reason appears simple to me: With a connection-origiented PROXY speaker
  in front of a request-oriented PROXY backend, a client could insert
  addtional PROXY headers and thus spoof client socket information.

  On the other hand, I do not see any reason why we shouldn't use the protocol
  with per-request semantics for our own HTTP purposes:

  A new accept socket protocol type (eg named CLUSTER) could require a PROXY2
  header with every request.

On irc, phk suggested that one way of getting backend PROXY support was though a
vmod inserting the header on the backend connection, but with these usage
scenarios in mind, I now think that we should really support configuration for
PROXY mode by means of a backend protocol property: Whether a socket we connect
to supports PROXY (or even CLUSTER as suggested above) is purely a property of
that socket and we should avoid the need to duplicate this information in VCL.

To summarize, I think we could have:

- an additional accept socket protocol type to support and _require_ per-request
  PROXY2 headers (which could be called CLUSTER type)
- support for backend protocol types PROXY and CLUSTER where
  - PROXY would always fail unless in pipe mode
  - CLUSTER would fail if in pipe mode

Nils