> Lucas, Maximilian, can you check the situation with this patch? The POST > issue should definitely be gone, please also verify the GET issue with this > patch (as I was unable to reproduce it).
Sadly didn’t fix the GET request issue for me in Firefox: https://snaps.hcdn.dk/h1Oz3G950oepEb30AEoK.png the app.css?v=1 request still fails in this case (sometimes it’s also the HTML itself), log: Dec 29 15:42:25 localhost haproxy[7708]: 80.61.160.xxx:65155 [29/Dec/2017:15:42:13.362] https_frontend~ https_frontend/<NOSRV> -1/-1/-1/-1/12575 400 0 - - CR-- 1/1/0/0/0 0/0 "<BADREQ>" Dec 29 15:42:30 localhost haproxy[7708]: 80.61.160.xxx:65236 [29/Dec/2017:15:42:25.981] https_frontend~ cdn-backend/mycdn 0/0/0/1/5001 200 995 - - ---- 1/1/0/1/0 0/0 "GET /js/app.js?v=1 HTTP/1.1" First entry is app.css, 2nd is the javascript. As you can see in the screenshot the webdev tools line is kinda malformed, however, the actual file is served perfectly, with response headers and what not. The only thing that is missing in webdev tools for the app.js is the status code, remote address and “protocol” (Which is why you see +h2 and not HTTP/2.0+h2) – it manages to detect the actual protocol by an internal Firefox header (X-Firefox-Spdy), the HTTP/2.0 part is a “Version” attribute that Firefox manages as well, and this one never gets populated I’m still trying to figure out if I can find why that information is missing however. When I do a tcpdump from the haproxy server (a simple tcpdump host 80.61.160.xxx and port 443) where 80.61.160.xxx is my home connection: - When everything works, client port stays the same - When I visit a page where one GET request fails, I see the client port changing all of a sudden with a reset flag coming first from the server, and then the client: https://gist.github.com/lucasRolff/1b8f29ed61fd8ae443894d28c7efff95#file-tcpdump-pcap-L28-L32 178.63.183.xx == server (haproxy) 80.61.160.xxx == client (browser) Best Regards, Lucas Rolff On 29/12/2017, 16.47, "[email protected] on behalf of Lukas Tribus" <[email protected]> wrote: Hi Willy, On Fri, Dec 29, 2017 at 3:58 PM, Willy Tarreau <[email protected]> wrote: > On Fri, Dec 29, 2017 at 03:42:30PM +0100, Willy Tarreau wrote: >> OK I managed to reproduce it with nghttp using --expect-continue to >> force it to leave a pause before sending the data. And indeed there >> the data are immediately followed by a shutdown. Getting closer... > > So here's what I found : when dealing with request forwarding, we used > to let the close migrate from the client to the server with the last > block. And this happens only once we switch to fast forwarding, which > means that the last block from the request didn't fit in the buffer. > Thus it would randomly impact large uploads (though timing would often > protect them) and almost always impact small ones if sent in two parts > as we could produce. > > The attached patch fixes it for me. Could you please give it a try ? Confirmed, that patch fixes the issue for me. The client was just a windows build of curl (with openssl 1.1.0), and a tiny POST: curl -kv https://localhost/111 -d "bla=bla" --http2 Port 443 SSH tunneled to a remote dev box running haproxy (but that should not have affected the H2 stream). I'm confident this fixes the POST issue reported in this thread, as already confirmed by Lucas (by modifying nginx abort settings, permitting in-flight half-close). Not sure if the GET issue is just another vector of the same underlying issue, or if that is a completely different issue altogether. Lucas, Maximilian, can you check the situation with this patch? The POST issue should definitely be gone, please also verify the GET issue with this patch (as I was unable to reproduce it). Also I think we can update the bugs filed with Firefox and Safari, clearly they don't send the connection header (they just show it in the dev-tools and debug logs). > I'm currently thinking how to add more information to improve observability > inside the mux to match what can currently be done outside (ie: we don't > have the equivalent of the "show errors" nor error counters inside the mux). Indeed I think that is a good idea. This morning I plastered the mux code with printf's to figure out where exactly haproxy rejects the request. Only to then find out the problem was not in the request :) There are quite a few possible H2 failure code paths and the only debug possibility right now is to manually are printf's. Regards, Lukas
