On Wed, Jan 03, 2018 at 09:07:35PM +0100, Lukas Tribus wrote: > When the client sends the POST, haproxy responds with the 302 from the > backend (stream 3), the client follows the redirect sending a the new > GET (stream 5) which haproxy never sees. However, with this patch, > haproxy also sends GOAWAY (Last-Stream-ID = 3) and the entire > connection is killed. Because the browser understands that stream 5 > was never considered, the browser recovers from this situation by > resending the GET request in a new connection immediately.
OK I understand, thus in fact it "hides" the problem. > Before my patch, after the the 302 redirect in stream 3, and the GET > request in stream 5, the connection basically hangs, and haproxy > doesn't 'see' stream 5 and the browser waits for a response, until > haproxy kills the connection (due to timeout). Interesting. It could indicate that haproxy is stuck in the FRAME_P state waiting for the data of the initial stream and for some reason never escapes. > I took a look of the behavior of Edge compared to other, unaffected > browsers and one thing caught my attention: > Edge sends 2 DATA frames, the first one with the actual POST data (no > ES bit set), the second DATA frame is empty (Length: 0) and has the ES > bit set. All other browsers just have one single DATA frame with both > the payload and the ES bit set. I assume the 0-length DATA frame may > be something haproxy is unable to handle and brings the entire > connection into a bogus state? Oh I think you've just put your finger on it. I remember taking care of handling 0-sized frames, and facing certain difficulties with them (eg: sometimes returning size 0 just means nothing was done). I sounds very likely that we can still have a bug around this. It would also explain why your patch could get rid of it. I'll have a look at the code in case I have an idea. Thanks! Willy
