Le 31/10/2019 à 11:01, Ing. Andrea Vettori a écrit :
Sorry to bother you with all these stuff. But for now, I don't know where to
start my investigation.
Sure I’ll do as soon as possibile and thank you very much for your continued
support.
Hi,
Sorry for the delay and thanks for the captures you sent me. In them, I noticed
2 things that explain the truncated responses :
* Firstly, when you send your request through HAProxy, your server send a frame
GOAWAY with the error code ERR_ENHANCE_YOUR_CALM(11) in the middle of the
response transfer. Because, once the request is sent, HAProxy only send frames
WINDOW_UPDATE, I guess your server has some "security" mechanism about those
frames. Or it is a bug. I don't know. The last stream ID indicated in the frame
GOAWAY is the one of your request. So, the response transfer should normally be
continued. In itself, it is not really a problem. And the transfer is
effectively still in progress because in the captures, we can see a frame DATA
following the GOAWAY. But after that, your server aborts the transfer by closing
the connection with a TCP reset, probably because it receives some other frames
WINDOW_UPDATE from HAProxy.
* Secondly, the server abort is not properly handled on the client side by the
mux h2. It is definitely a bug. We should normally send a RST_STREAM to abort
the request. Instead, we mark the end of the response with an empty frame DATA
with the flag END_STREAM set. Because there is no content-length specified on
the response, the client has no way to know that the response was truncated.
So, this bug must be addressed. We're still discussing with Willy to know how to
do it properly. But, in the end, it requires some fundamental changes on the way
aborts are handle in HAProxy. We are rather reluctant to do a quick patch.
Once said, the problem remains on your server side, because it aborts the
response transfer. I noticed the last WINDOW_UPDATE before the GOAWAY has a
length of 1. This may be related.
--
Christopher Faulet
