Hello Willy,
> - client-facing HTTP/2 : that's HTTP/2 support on the frontend. It's > much better after the completely new rewrite than the first attempt a > few months ago, and in the end I'm really happy with the outcome > despite the pain it was. It's now almost complete, it supports POST, > 1xx responses, chunked responses. In fact it's easier to enumerate > what it does not support : CONTINUATION frames are not yet implemented > (I may have found how to do it), PRIORITY frames are ignored (that's > allowed by the spec), there's no equivalent of chunked encoding in > requests, and trailers from the response are discarded. What it needs > most is real world exposure now to spot corner cases. I wanted to > place it on haproxy.org until I failed on the thread problem described > above and had to revert. In order to enable it, simply add > "alpn http/1.1,h2" on a "bind" line present in an HTTP mode frontend, > and if the client advertises ALPN "h2" it will be used, otherwise it > will fall back to HTTP/1.1. Actually that is not what I'm seeing. In ALPN, the client announces the supported protocols, currently for example http1/1 and h2, and then the server picks a protocol out of that selection, based on its own preference. However, with clients supporting both http/1.1 and h2 the configuration: alpn http/1.1,h2 always leads to HTTP/1.1 (on both curl and Chrome) here. I had to turn it around, for HTTP/2 to be actually negotiated: alpn h2,http/1.1 With the latter configuration, HTTP/2 is actually used. > "alpn http/1.1,h2" on a "bind" line present in an HTTP mode frontend, And "alpn h2,http/1.1" does work via HTTP2 in a HTTP mode frontend. But when the frontend is in TCP mode, and the backend is in HTTP mode, its looks like the H2 parser is not started even when ALPN negotiates h2, and the HTTP/1.1 only backend server receives the "PRI" connection request verbatim: 0000000a:https_in.accept(0005)=0008 from [10.0.0.4:54737] ALPN=h2 0000000a:bk_testbk.clireq[0008:ffffffff]: PRI * HTTP/2.0 0000000a:bk_testbk.srvrep[0008:adfd]: HTTP/1.1 400 Bad Request 0000000a:bk_testbk.srvhdr[0008:adfd]: Server: nginx/1.10.3 (Ubuntu) 0000000a:bk_testbk.srvhdr[0008:adfd]: Date: Wed, 01 Nov 2017 21:15:41 GMT 0000000a:bk_testbk.srvhdr[0008:adfd]: Content-Type: text/html 0000000a:bk_testbk.srvhdr[0008:adfd]: Content-Length: 182 0000000a:bk_testbk.srvhdr[0008:adfd]: Connection: close 0000000a:bk_testbk.srvcls[0008:adfd] 0000000b:bk_testbk.clireq[0008:ffffffff]: SM 0000000b:bk_testbk.clicls[adfd:ffffffff] 0000000b:bk_testbk.closed[adfd:ffffffff] In the HTTP/1.1 world I used to think that even if the frontend is in TCP mode, when haproxy selects a backend in HTTP mode, it understands that this is gonna be a HTTP session and it turned on the HTTP hut for all intends and purposes. Of course, when both front and backend are in TCP mode and we negotiate h2 via NPN or ALPN, we have to leave it alone (just terminate TLS). But in the "frontend->tcp mode; backend->http mode" case, should we be able to start the H2 parsing and actually handle this case? Or is this something we are unable to cover? I'm certainly able to fix this issue here via configuration, I'm just not sure if that is the case for all the use-cases out there? Now, comment number 3, pretty sure this is actually a bug :) In my configuration, files transferred via HTTP2 are corrupted with random content from memory. I could spot my certificate, some HTTP headers and the content of /etc/resolv.conf in the HTTP payload. Using HTTP/1.1 (even by a client side change) fixes this. Just H2 is affected. How to reproduce? In my case I'm transferring a 150KB .svg file through haproxy and it gets corrupted every time. The configuration is *VERY* basic (also, no filters are enabled :) ): lukas@dev:~/haproxy$ cat ../haproxy.cfg defaults timeout connect 5000 timeout client 50000 timeout server 50000 #compression algo gzip frontend http_in bind :80 default_backend bk_testbk frontend https_in mode http bind :443 ssl crt /home/lukas/cert/certdir/cert.pem alpn h2,http/1.1 default_backend bk_testbk backend bk_testbk mode http server www www.lan.ltri.eu:80 lukas@dev:~/haproxy$ Not sure what I can do to pinpoint this issue? BTW: tomorrow is OpenSSL release day, they will publish new releases fixing a already disclosed low severity and a undisclosed moderate level security issue: https://mta.openssl.org/pipermail/openssl-announce/2017-October/000104.html cheers, lukas
