Sorry, but that is a seriously wrong conclusion of what you see. It has nothing to do with --next. It relates to the connection being re-used and curl wrongly thinking it is dead. But we don't know why the connection breaks, figuring that out could lead to us understanding what's going on.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Feel free to re-categorize or re-file if you are unhappy with the description. If you do decide to re-file lets just make sure the issue described here is also addressed.
Do you need additional information from me? The issue is reliably reproducable in the scenario I described on the mailing list.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I had posted this to the mailing list but it may be more appropraite to put it directly in the issue:
I found where the PROTOCOL_EXCEPTION exception is being generated in the curl code. The following if statement is evaluating to true and is resulting in a protocol error being sent https://github.com/bagder/curl/blob/7d9bef9286cd8efbed032d41a36e82d1c44058a7/lib/http2.c#L484? Each response has a ":status" header and also some other headers (content-type, custom "x-" extension headers, etc...) this check is evaluating to true because c->status_code == -1 is true.
Since this particular case was due to a server malfunction I'm closing this issue. There may still be other problems lurking but they're not easy to trigger or debug. Hopefully a future http2 test suite should help us with this.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry, but that is a seriously wrong conclusion of what you see. It has nothing to do with --next. It relates to the connection being re-used and curl wrongly thinking it is dead. But we don't know why the connection breaks, figuring that out could lead to us understanding what's going on.
Feel free to re-categorize or re-file if you are unhappy with the description. If you do decide to re-file lets just make sure the issue described here is also addressed.
Do you need additional information from me? The issue is reliably reproducable in the scenario I described on the mailing list.
I had posted this to the mailing list but it may be more appropraite to put it directly in the issue:
I found where the PROTOCOL_EXCEPTION exception is being generated in the curl code. The following if statement is evaluating to true and is resulting in a protocol error being sent
https://github.com/bagder/curl/blob/7d9bef9286cd8efbed032d41a36e82d1c44058a7/lib/http2.c#L484? Each response has a ":status" header and also some other headers (content-type, custom "x-" extension headers, etc...) this check is evaluating to true because
c->status_code == -1is true.status_codeis reset to -1 here https://github.com/bagder/curl/blob/7d9bef9286cd8efbed032d41a36e82d1c44058a7/lib/http2.c#L984 and here https://github.com/bagder/curl/blob/7d9bef9286cd8efbed032d41a36e82d1c44058a7/lib/http2.c#L251. The issue is both of these lines are hit in between receiving the ":status" header and the next headers for a given stream. I am not sure what the fix would be because I am a bit confused about the granularity of thehttp_connobject within the connectdata structure. It seems like there should be a collection of these (1 per stream) and not just one for the whole connection?Additional information
The
Curl_http2_setup(...)method is being called here https://github.com/bagder/curl/blob/7d9bef9286cd8efbed032d41a36e82d1c44058a7/lib/http.c#L1765 in between processing streams on a given connection.Since this particular case was due to a server malfunction I'm closing this issue. There may still be other problems lurking but they're not easy to trigger or debug. Hopefully a future http2 test suite should help us with this.