-------- In message <[email protected]>, 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 [email protected] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. _______________________________________________ varnish-dev mailing list [email protected] https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
