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.
Thanks,
--
Christopher Faulet
