> Could you please just remove this option (or replace it with > http-server-close if you absolutely want to disable keepalive for any reason) > ?
I can’t remember why I disabled keep-alive, however – removing it completely did the trick. So basically “option httpclose” and h2 won’t work. Using “http-server-close” on the backend does work as well – so it seems like something between 1.8.1 and 1.8.2 caused “option httpclose” to stop working when also using http2. > Just to be sure, you mean the response to the request will be 55 kB, not the > request's payload ? I'm asking because I think I saw a GET in your trace. You’re correct, the response to the request will be 55 kB So it means I have a working haproxy 1.8.2 with http2 now! Thank you once again! I was hoping that version 1.8.2 would also have resolved https://www.mail-archive.com/haproxy@formilux.org/msg28333.html - however, doesn’t seem to be the case – I’ll see if I can find the cause for that one Best Regards, Lucas Rolff On 27/12/2017, 20.15, "Willy Tarreau" <w...@1wt.eu> wrote: On Wed, Dec 27, 2017 at 06:52:21PM +0000, Lucas Rolff wrote: > - you said that using multiple certs breaks, but did you get a working state in any way ? > > Actually regarding the multiple certs breaking - I was wrong. > > So, if I use release 1.8.1 (downloaded from haproxy.org and compiling from > source) then my bind works perfectly. OK so it's a regression from 1.8.1 to 1.8.2. > If I use release 1.8.2 with same compile options, and I use the same bind, or > a bind even with a single certificate ( bind *:443 ssl crt > /etc/haproxy/certs/wildcard_domain.com.pem alpn h2,http/1.1 ) I still end up > with the same error from curl: > > curl: (16) Error in the HTTP2 framing layer > > So it's as long as I pass alpn h2,http/1.1 in my bind "flag" that it breaks. I couldn't face this one yet, and I've used curl quite a lot during all my recent tests (in addition to nghttp, h2c and h2load). > > if you run haproxy with -d (debug mode), do you see something like this : > > Yes, I see the ALPN=h2: > > 00000000:https_frontend.accept(0006)=0010 from [80.61.160.xxx:52922] ALPN=h2 > 00000000:https_frontend.clireq[0010:ffffffff]: GET / HTTP/1.1 > 00000000:https_frontend.clihdr[0010:ffffffff]: user-agent: curl/7.54.1 > 00000000:https_frontend.clihdr[0010:ffffffff]: accept: */* > 00000000:https_frontend.clihdr[0010:ffffffff]: host: dashboard.domain.com > 00000000:cdn-backend.srvcls[0010:adfd] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ That's interesting : the connection to the server was closed. It was a nightmare to fix the abortonclose case, and I'm seeing you have option httpclose in your config, that (almost) nobody uses anymore since it was the "passive close" mode. I didn't test this one, I only tested "http-server-close", "http-keep-alive" and "forceclose". Maybe I broke it. Could you please just remove this option (or replace it with http-server-close if you absolutely want to disable keepalive for any reason) ? > > are you sure you didn't limit your buffer size to less than 16kB ? > > Config between my compiled 1.8.1 and 1.8.2 didn't change at all, and I'm also > not touching buffers within the haproxy config, the only defaults I really > set is connect, client and server timeouts - OK. Anyway whenever you want to check the default settings, you can find them in "haproxy -vv". Eg here with my "small memory" setup : Default settings : maxconn = 2000, bufsize = 8030, maxrewrite = 1030, maxpollevents = 200 This one definitely will not work with HTTP/2. > the rest pretty much stays the > same: > > https://gist.github.com/lucasRolff/12b2036baa47400d6c3437a67d9f5fd1 - > I try to avoid touching things the instance does next to no traffic so > defaults *should* be fine. So unless buffers change between 1.8.1 an 1.8.2 > then no changes has been done. That's also what makes me think about httpclose :-/ > The specific request will have a content-length of 55 kilobytes. Just to be sure, you mean the response to the request will be 55 kB, not the request's payload ? I'm asking because I think I saw a GET in your trace. > > how did you manage to get curl to emit this amount of useful debugging > > information ? I never got that even after reading all options, I'm jealous! > > Use -vvv option in curl I didn't know it had any effect to add more "-v" :-) > or even better, on http2 enabled sites, you can use > nghttp -v http://url/ it will give you extensive information regarding your > http2 traffic - since it will be aware of your streams, priorities etc etc. Yes, I use it a lot, it's very useful. For raw h2 frames, h2c in wiretap mode is convenient as well (and completes well with nghttp). Thanks! Willy
