Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
CURLE_HTTP2 with libcurl multi interface #1967
I did this
I'm developing an application that uses libcurl's multi interface (source code here) and am experiencing outbound PUT messages reproducibly failing with the error CURLE_HTTP2, and the data not being sent. The error buffer for the sending easy handle is empty.
I expected the following
The PUT should complete normally as it does with HTTP/1.1.
To give some context, my application translates the IRC protocol to another http based one (matrix); IRC PRIVMSGs to my application become http PUTs to a server. The problem is reproducable by waiting around ~3 minutes before PRIVMSGing my application. The corresponding PUT to the server will fail with CURLE_HTTP2, but following ones will work fine as long as they are sent without another waiting period.
I did some cursory debugging, and it seems that libcurl's
I have also recorded a log of libcurl's verbose output (with DEBUGBUILD set) from the start of my application to when the problem occurs here.
libcurl version, operating system, etc
OS: Linux 4.4.0 x86_64
curl -V output
I just built curl against nghttp2 1.26.0 and get the same behaviour: Start my program, send a message immediately, wait 3-4 mins, send another and it will seemingly always fail with CURLE_HTTP2.
This did fill in the ??s in the stack trace though:
we encounter something:
by setting "http2_max_requests 1;" in nginx and using libcurl (multi handle + libuv) and it gives the error Failure when receiving data from the peer (almost) every time (every 10 ~ 15 request there will be a success).
(nginx 1.12.2 curl 7.58.0/7.59.0 nghttp2 1.29).
with the same version, using curl cmd, everyting is fine.
By capture tcp packet we see that the data has finished transfering and follow by "Encrypted Alert" and FIN from server.
so i guess that it has something to do with connection reusing inside multi handle. hopes this help.
In the "smaller test case", the server sends a
The message doesn't seem to be handled by curl correctly (which should find the goaway, close the existing connection and create a new one for the next transfer) but instead it appears as if it still reuses the original connection and sends a
@baines: I'm sorry its taken me ages to get around to work on this, but at least I now have a first take on a fix (in #2402). It does fix the "simplified" test case you made. It would be lovely if you could perhaps take it for a spin in your original use case you had to make sure it actually is the same issue/fix.
@terrywh: that sounds like a different error than this. Please file a new issue and please provide source code for us to reproduce this, or give us every imaginable detail you can think of.