curl_easy_perform returns CURLE_SEND_ERROR even if the http/2 request was successful.

[paolonevis]

I did this

start the server like that:

python3 h2-backend.py localhost 11074

and run then the compiled curltest_deterministic.c.

client: curltest_deterministic.c

server: h2-backend.py

I expected the following

I would have expected that this would work without problems, but I get this error:

curl: [HTTP/2] [1] cf_send(len=0) -> 55, 0, eos=1, h2 windows -1-65502 (stream-conn), buffers 0-0 (stream-conn)
curl: Connection #0 to host localhost:11074 left intact
ERROR: curl_easy_perform() failed: Failed sending data to the peer
paolo@localhost:~/tmp$

The problem seems to be that curl is finalizing the request body with len=0, eos=1 after receiving a complete early HTTP/2 response. The stream has already been marked closed internally, and cf_h2_send() incorrectly returns CURLE_SEND_ERROR instead of accepting the completed response.

Find here a possible fix.
libcurl-http2-early-response.patch

The proposed patch is also consistent with libcurl’s existing cf_h2_body_send() behavior, which already treats a closed stream with completed response headers as a valid early response

I'll open a PR with the proposed patch.

curl/libcurl version

curl 8.22.0

operating system

Linux localhost.localdomain 5.14.0-611.36.1.el9_7.x86_64 #1 SMP PREEMPT_DYNAMIC Tue Mar 3 17:30:12 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux

[icing]

I'd like to see a trace of how the server responds. Does it send the EOF bit for the stream?

Either a wireshark capture file or using libcurl's DEBUGFUNCTION and invoking curl_global_trace("all") at the start. Thanks!

[paolonevis]

Hi @icing ,

find here the file invoking curl_global_trace("all")

curltest.log

[icing]

Thanks. Your server sends a response and closes the stream before having read all input. The error happens when libcurl tries to send the last DATA FRAME, length=0, eof=1 to close its side.

Your server implementation of the HTTP/2 protocol is incomplete. See RFC 9113, 8.1.1. Malformed Messages. The server needs to read the input until the EOF indicator in order to verify that the announced content-length is correct. Answering just because enough bytes have already arrived is not conforming to the protocol.

[paolonevis]

Hi @icing ,

many thanks for your answer, but the server did not forcefully terminate the request stream early.

Based on the curltest.log sent before, the server successfully sent its complete response and closed its own transmitting side of the stream, but it never issued a RST_STREAM to abort the client's upload. The stream was only fully closed after the client sent its final EOF marker.

More details based on the log:

• The server sends its response early: The server sends its HTTP headers (<- FRAME[HEADERS, len=22, hend=1, eos=0] (line 321)) and immediately follows up with the response body (<- FRAME[DATA, len=37, eos=1, padlen=0] (line 345)). The eos=1 flag indicates the server has finished sending its response, placing the stream in a "half-closed (remote)" state, but allowing the client to continue transmitting.
• The client finishes reading its input: The client subsequently determines it has no more request data to send (client_read(len=65536) -> 0, nread=0, eos=1 (line 368)).
• The client cleanly terminates the upload: The client sends an empty data frame with the end-of-stream flag (-> FRAME[DATA, len=0, eos=1, padlen=0] (line 374)) to gracefully finish its upload.
• The stream legally closes: Because both the server and the client have now sent frames with the eos=1 flag, the HTTP/2 stream naturally and legally transitions to a fully closed state ([HTTP/2] [1] CLOSED (line 376).
• libcurl panics and throws an error: Immediately after the stream is marked closed, libcurl's internal send function evaluates the newly closed state and mistakenly treats it as a failure (cf_send(len=0) -> 55, 0, eos=1 (line 382)). The status 55 corresponds to CURLE_SEND_ERROR, which causes libcurl to abort and discard the successful response.

Based on https://www.rfc-editor.org/rfc/rfc9113.html, the server works correctly:

A server can send a complete response prior to the client sending an entire request if the response does not depend on any portion of the request that has not been sent and received.

[icing]

It is true that the server can send a response before all frames from the request have arrived. But it needs to read all request frames or send a RST. Your server simply closes the connection, curl fails to send the last request frame and reports an error.

[paolonevis]

Hi @icing ,

sorry to insist, but I still think that the bug is in curl. Here a more detailed analysis:

1. curl: [0-0] [HTTP/2] [1] -> FRAME[DATA, len=0, eos=1, padlen=0]: nghttp2 constructs the final DATA frame with the End-of-Stream (eos=1) flag.
2. curl: [0-0] [HTTP/2] [1] CLOSED: Because nghttp2 just constructed the final outgoing eos=1 frame, and it already received the server's eos=1 frame earlier, its internal state machine immediately transitions the stream to CLOSED. It does this before flushing the bytes to the network.
3. curl: [0-0] [TCP] send(len=9) -> 0, 9: This line proves the frame went out. An HTTP/2 frame header is exactly 9 bytes long (3 bytes length, 1 byte type, 1 byte flags, 4 bytes stream ID). Because this is a DATA frame with a payload length of 0, the entire frame is exactly 9 bytes. The -> 0, 9 indicates that libcurl successfully wrote all 9 bytes to the TCP socket. The frame reached the network.
4. curl: [0-0] stream 1 closed: libcurl acknowledges the stream is closed.
5. curl: [0-0] [HTTP/2] [1] cf_send(len=0) -> 55, 0, eos=1...: The bug in libcurl occurs here. The high-level send function (cf_h2_send) finishes calling the nghttp2 routines. It then evaluates the state of the stream. It sees that the stream is now marked closed. Instead of realizing, "The stream is closed because we just successfully finished sending the final frame," it assumes, "The stream is closed, so my send must have failed." It then erroneously returns 55 (CURLE_SEND_ERROR).

The stream naturally transitioned to CLOSED because both sides finished cleanly. The patch (if(stream && stream->closed && !stream->resp_hds_complete)) correctly instructs libcurl: "If the stream is closed, do not throw a send error as long as we already successfully received the complete response headers."

[icing]

Good that you insist! I reviewed the log again and your analysis is correct. The last frame was sent and the reaction to the stream being closed in http2.c:2252 needs an additional condition like your patch proposes. Sorry to not have seen that sooner (it's a busy time here right now).

Do you want to make a PR from this or shall I?

[paolonevis]

Hi @icing ,

thank you for your answer. I can open a PR, no worries.
--> #22987