<div dir="ltr">Hi,<br><br>I think it makes sense to make PROTO optional, falling back to current behavior if not present.<br><br>Since proxy also supports IPv6 we should consider using brackets around the address for IPv6, e.g. proxy@[2001:67c:2804:1001::c21f:279b]:8081<br><br>Regarding logging, your suggestion makes sense to me.<br><br>Salute.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 11, 2014 at 4:41 PM, Dag Haavi Finstad <span dir="ltr"><<a href="mailto:daghf@varnish-software.com" target="_blank">daghf@varnish-software.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi guys<br>
<br>
I've been looking into implementing the PROXY protocol[1] for Varnish<br>
4. This has been discussed several times before, in particular it<br>
seems some consensus was found at VDD13Q4 in Berlin last year [2].<br>
This was regarding the interface in terms of specifying the listening<br>
socket (-a) and the VCL *.ip bits. I was not present at this VDD<br>
myself, so I'd just like to discuss and perhaps get some verification<br>
as to what was agreed.<br>
<br>
As for the -a listening argument, this ties into how it should be<br>
handled for HTTP/2. From reading the notes, the agreed upon syntax was<br>
<br>
-a PROTO@IP:0<br>
<br>
Is the PROTO@ part mandatory, or is there a fallback when it's left<br>
out (e.g. plain old '-a :80')? I think it makes most sense to have the<br>
fallback value be HTTP/1.1 that also supports HTTP/2 via Upgrade [3].<br>
<br>
If we are also going to have a way of specifying the protocol to be<br>
exclusively HTTP/1 or HTTP/2 [4], we could use values 'http1' and<br>
'http2' to denote that.<br>
<br>
Further, a PROXY protocol listen socket is specified like this:<br>
-a <a href="http://proxy@192.168.1.10:8081" target="_blank">proxy@192.168.1.10:8081</a><br>
<br>
The PROXY implementation will hand over to the HTTP/1 FSM after<br>
processing the PROXY header. From my understanding the PROXY protocol<br>
is not specified for HTTP/2, so the connection here must stick with<br>
HTTP/1. Also, any incoming request on this interface not containing a<br>
valid PROXY header must be rejected.<br>
<br>
As for the VCL bits, I'm very happy with what was agreed upon at<br>
VDD13Q4 (local.ip, remote.ip, client.ip, server.ip).<br>
<br>
I don't see any mention of logging having been discussed, but I think<br>
it makes sense to have SessOpen use local.ip/remote.ip, while ReqStart<br>
should use server.ip/client.ip. varnishncsa will then use client.ip<br>
for logging the client host (%h).<br>
<br>
Opinions, input, comments?<br>
<br>
[1]: <a href="http://www.haproxy.org/download/1.5/doc/proxy-protocol.txt" target="_blank">http://www.haproxy.org/download/1.5/doc/proxy-protocol.txt</a><br>
[2]: <a href="https://www.varnish-cache.org/trac/wiki/VDD13Q4#PROXY" target="_blank">https://www.varnish-cache.org/trac/wiki/VDD13Q4#PROXY</a><br>
[3]: <a href="https://tools.ietf.org/html/draft-ietf-httpbis-http2-15#section-3.2" target="_blank">https://tools.ietf.org/html/draft-ietf-httpbis-http2-15#section-3.2</a><br>
[4]: <a href="https://tools.ietf.org/html/draft-ietf-httpbis-http2-15#section-3.4" target="_blank">https://tools.ietf.org/html/draft-ietf-httpbis-http2-15#section-3.4</a><br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Dag Haavi Finstad<br>
Software Developer | Varnish Software<br>
Mobile: <a href="tel:%2B47%20476%2064%20134" value="+4747664134">+47 476 64 134</a><br>
We Make Websites Fly!<br>
<br>
_______________________________________________<br>
varnish-dev mailing list<br>
<a href="mailto:varnish-dev@varnish-cache.org">varnish-dev@varnish-cache.org</a><br>
<a href="https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev" target="_blank">https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev</a><br>
</font></span></blockquote></div><br></div>