Le 29/10/2019 à 18:48, Ing. Andrea Vettori a écrit :
Here is a direct session to backend server from the client machine in clear text http2 without upgrade. Note that in this case output is NOT truncated if I call the command without the ‘-n’ option. To do this test I temporary overriden the host’s name dns resolution on the client (curl has a handy option to do that but haven’t found it on nghttp).


The following is the same client to the haproxy server, to port 80 i.e. no “proto h2” on the front-end. Proto h2 on the backend. Note that in this case output is truncated if I call the command without the ‘-n’ option


Finally this is the output when port 82 is called on haproxy, i.e. the frontend with “proto h2” option. This also produces truncated output.


Ok, Thanks for these infos. So, from the H2 point of view, the responses are valid and well formatted. But the responses size are radically different. If the size should be the same for all the three responses, the bug is probably in the communication between HAProxy and the server. Because the 2nd response is ~144K lower than the 1st one. And the 3rd is ~232K lower. So, far from the internal buffer size.

To emit a flag END_STREAM on a DATA frame, internally, we need to reach the end of the HTTP message. It is marked by a dedicated block of data (HTX_BLK_EOM). This one is present if the flag END_STREAM was received on the other side.

So now, the next move is to provide a network capture. Sorry to ask it again :) Because you use dedicated ports for your tests, I guess it will be quite simple. Could you provide the result of the following command, executed on HAProxy server ?

  tcpdump -i any -w h2toh2.cap  port 82 or port 8080

You can fill the capture with some requests on http://g.testhost.com:82. It could be also usefull to have the capture of a successfull request.

Sorry to bother you with all these stuff. But for now, I don't know where to start my investigation.

Christopher Faulet

Reply via email to