Hello,
On Wed, Jan 3, 2018 at 5:56 PM, Willy Tarreau <w...@1wt.eu> wrote: >> When moving the affected HREM code above the "return 0" branch, Edge >> works fine again. >> >> The attached patch fixes the issue for me, please give it a try. > > The problem with doing this is that when we have to stop transferring > data because for example the target buffer is full, we'll still switch > to HREM anyway and randomly destroy the last data frame. It was one of > the reasons some uploads were randomly truncated. > > But if it fixes the issue for you, it may indicate we're not properly > woken up sometimes during the upload. If I understand well, it only > happens on redirects, so maybe one transition is causing trouble here, > typically we may have an HLOC state (half-close(local)) when the response > is sent by the server before the client finishes to upload, and it's > possible that we don't continue to drain pending data there. With > your change it likely causes the stream to be aborted on this last > frame, unblocking the situation. That's just a wild guess, as usual :-/ In fact, with my patch the situation is not desirable at all: 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. 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). 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? Regards, Lukas
