VIP6 / Re: backend PROXY support - thought dump

[Poul-Henning Kamp]

--------
In message <5702E0A0.3060101 at schokola.de>, Nils Goroll writes:

>Quoting VIP6
>https://github.com/varnishcache/varnish-cache/wiki/VIP6:-What-does-pipe-mean-in-Varnish5%3F
>
>	We add a std.send_proxy_header() which can be called from vcl_pipe{}
>	only.
>
>I think whether or not a PROXY header gets added should be based on an attribute
>of the chosen backend, anything else results in a blowup of VCL code.

I came to the same conclusion.

Then I tried to make it a backend attribute, which was easy, but
then I realized that we do not have a hold of the clients struct
sess in the backend fetch code, so we have no way to get the addresses
we need to put into the PROXY header in the first place.

Since we'll need to refcount struct sess for H2 anyway, that's not
fatal, it's just not as trivial as I thought it would be.

There is another detail though.

If we've sent a PROXY header to the backend, that connection cannot
be reused by anybody but the very same struct sess.

Ideally we'd hang the connection on the struct sess, so we can reap
them when it goes away, but that is not at all trivial (What if the
VCL changed before the next req ?)

The alternative is to mark them 'magic' in the backend connection pool,
and only recycle them if its the same struct sess.  That leaves us with
a garbage collection issue.

Finally there is the really crude solution:  Just never recycle backend
connections on which we sent a PROXY header.

I'm leaning heavily on the last one, until somebody shows me something
that simply cannot be done with that restriction.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.