Observed test case failures 1700 / 1701 / 1702 (h2c upgrade) #7036
These three cases are all for HTTP/2 on plaintext TCP with the
Environment and issue reproduction
The failures may be reproduced stably at 51c0ebc and other recent revisions on my local machine, and in a Docker environment constructed purposely for reproducing this issue. Details on the Docker environment would be given below.
Click here for content of the
The text was updated successfully, but these errors were encountered:
TD;DR: What's known so far
The observed issue is believed to have been caused by
Although curl is aware of such residual data and attempts to feed it to
The role of
Sharing some raw debugging data from my local runs
In the earlier mentioned temporary repository https://github.com/starrify/curl-test-failure-1700 I have added further raw data recorded during local investigations:
(the captured traffic and debugging output come from different runs)
Observation: captured traffic for the succeeded and failed tests
When running without
|memcpy(httpc->inbuf, mem, nread);|
|httpc->inbuflen = nread;|
|DEBUGASSERT(httpc->nread_inbuf == 0);|
|if(-1 == h2_process_pending_input(data, httpc, &result))|
By further debugging practices, I also observed that the corresponding callbacks (e.g.
on_header) were properly invoked when the residual payload was parsed by
By linking my local debugging build of
curl to a local debugging build of
nghttp2 I was able to further examine the
nghttp2 debugging output, which did not look weird to me.
Further inspections suggested that the parsed HTTP/2 response was dropped (or more like ignored) at the entrance of
http2_recv, as the HTTP stream is already deemed as closed when the below code is reached:
This may be deemed necessary since some servers (e.g. nghttp2's reverse proxy) may start sending the response payload immediately following the server-side connection preface, other than waiting for the client's connection preface and possible setting negotiations. Resolves curl#7036. Please refer to this issue for further details.
It is confirmed that 252790c is the revision in which this issue may be first triggered.
Click here for debugging output (passing
This is considered not harmful as a following http2_recv shall be called very soon. This is considered helpful in the specific situation where some servers (e.g. nghttpx v1.43.0) may fulfill stream 1 immediately following the return of HTTP status 101, other than waiting for the client-side connection preface to arrive. Resolves curl#7036.