On Fri, Dec 29, 2017 at 04:10:12PM +0000, Lucas Rolff wrote: > > 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
OK, I didn't expect much of it to be honnest! > 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" This clearly shows that the request was aborted by the H2 gateway and after creating the stream. If you're willing to run another test, I can prepare a debugging patch which will try to report every single error path in the H2 and HPACK code so that we can try to understand where the code was upset. > 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. Don't spend too much time trying to figure the cause of side effects. Sometimes it's simply that the tool was not tested in such conditions and doesn't deal cleanly with such a bug. > 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) Given the small packet size here, I strongly suspect a GOAWAY followed by a shutdown : 16:03:31.690396 IP 178.63.183.xx.443 > 80.61.160.xxx.56078: Flags [P.], seq 250148:250194, ack 16947, win 622, options [nop,nop,TS val 1776018172 ecr 510066715], length 46 16:03:31.691182 IP 178.63.183.xx.443 > 80.61.160.xxx.56078: Flags [F.], seq 250194, ack 16947, win 622, options [nop,nop,TS val 1776018173 ecr 510066715], length 0 So there's definitely something that haproxy didn't accept. Here I'd more easily blame the H2 gateway than the H1 code though. I'll see if I can find anything related to this. Thanks, Willy
