`CURLE_PARTIAL_FILE` is reported on HTTP/3 stream reset even if the entire body was received

[Lubrsi]

I did this

I loaded https://cdn.7tv.app/emote/01F6MQ33FG000FFJ97ZB8MWV52/1x.webp in Ladybird with a small patch:

diff --git a/Services/RequestServer/Request.cpp b/Services/RequestServer/Request.cpp
index 29d7ef9bb4e..5227f2ed2ac 100644
--- a/Services/RequestServer/Request.cpp
+++ b/Services/RequestServer/Request.cpp
@@ -940,7 +940,7 @@ void Request::handle_fetch_state()
 
     set_option(CURLOPT_CUSTOMREQUEST, m_method.characters());
     set_option(CURLOPT_FOLLOWLOCATION, 0);
-    if constexpr (CURL_DEBUG) {
+    if constexpr (1) {
         set_option(CURLOPT_VERBOSE, 1);
     }
 
@@ -1157,6 +1157,8 @@ size_t Request::on_data_received(void* buffer, size_t size, size_t nmemb, void*
     auto total_size = size * nmemb;
     ReadonlyBytes bytes { static_cast<u8 const*>(buffer), total_size };
 
+    dbgln("received {} bytes", total_size);
+
     auto result = [&] -> ErrorOr<void> {
         TRY(request.m_response_buffer.write_some(bytes));
         return request.write_queued_bytes_without_blocking();

Which resulted in:

* Added cdn.7tv.app:443:37.27.171.118,37.27.171.120,37.27.171.107,37.27.171.119,37.27.171.106,37.27.171.117,37.27.171.108,37.27.171.109,37.27.171.121,37.27.171.122,::ffff:37.27.171.118,::ffff:37.27.171.120,::ffff:37.27.171.107,::ffff:37.27.171.119,::ffff:37.27.171.106,::ffff:37.27.171.117,::ffff:37.27.171.108,::ffff:37.27.171.109,::ffff:37.27.171.121,::ffff:37.27.171.122 to DNS cache * Hostname cdn.7tv.app was found in DNS cache * Host cdn.7tv.app:443 was resolved. * IPv6: ::ffff:37.27.171.118, ::ffff:37.27.171.120, ::ffff:37.27.171.107, ::ffff:37.27.171.119, ::ffff:37.27.171.106, ::ffff:37.27.171.117, ::ffff:37.27.171.108, ::ffff:37.27.171.109, ::ffff:37.27.171.121, ::ffff:37.27.171.122 * IPv4: 37.27.171.118, 37.27.171.120, 37.27.171.107, 37.27.171.119, 37.27.171.106, 37.27.171.117, 37.27.171.108, 37.27.171.109, 37.27.171.121, 37.27.171.122 * Trying [::ffff:37.27.171.118]:443... * SSL Trust Anchors: * Native: Apple SecTrust * OpenSSL default paths (fallback) * Trying 37.27.171.118:443... * Trying [::ffff:37.27.171.118]:443... * SSL Trust Anchors: * Native: Apple SecTrust * OpenSSL default paths (fallback) * ALPN: curl offers h2,http/1.1 * SSL Trust Anchors: * Native: Apple SecTrust * OpenSSL default paths (fallback) * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / x25519 / id-ecPublicKey * Server certificate: * subject: CN=cdn.7tv.app * start date: May 14 08:00:33 2026 GMT * expire date: Aug 12 08:00:32 2026 GMT * issuer: C=US; O=Let's Encrypt; CN=E8 * Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using ecdsa-with-SHA384 * Certificate level 1: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using sha256WithRSAEncryption * Certificate level 2: Public key type RSA (4096/152 Bits/secBits), signed using sha256WithRSAEncryption * subjectAltName: "cdn.7tv.app" matches cert's "cdn.7tv.app" * OpenSSL verify result: 0 * SSL certificate verified via OpenSSL. * Established connection to cdn.7tv.app (37.27.171.118 port 443) from 192.168.1.105 port 65025 * using HTTP/3 * [HTTP/3] [0] OPENED stream for https://cdn.7tv.app/emote/01F6MQ33FG000FFJ97ZB8MWV52/1x.webp * [HTTP/3] [0] [:method: GET] * [HTTP/3] [0] [:scheme: https] * [HTTP/3] [0] [:authority: cdn.7tv.app] * [HTTP/3] [0] [:path: /emote/01F6MQ33FG000FFJ97ZB8MWV52/1x.webp] * [HTTP/3] [0] [accept-encoding: deflate, gzip, br, zstd] * [HTTP/3] [0] [accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8] * [HTTP/3] [0] [accept-language: en-GB,en-US,en] * [HTTP/3] [0] [sec-fetch-dest: document] * [HTTP/3] [0] [sec-fetch-mode: navigate] * [HTTP/3] [0] [sec-fetch-site: cross-site] * [HTTP/3] [0] [user-agent: Mozilla/5.0 (macOS; AArch64) Ladybird/1.0 Chrome/146.0.0.0 AppleWebKit/537.36 Safari/537.36] > GET /emote/01F6MQ33FG000FFJ97ZB8MWV52/1x.webp HTTP/3 Host: cdn.7tv.app Accept-Encoding: deflate, gzip, br, zstd Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-GB,en-US,en Sec-Fetch-Dest: document Sec-Fetch-Mode: navigate Sec-Fetch-Site: cross-site User-Agent: Mozilla/5.0 (macOS; AArch64) Ladybird/1.0 Chrome/146.0.0.0 AppleWebKit/537.36 Safari/537.36

• Request completely sent off
  < HTTP/3 200
  < content-type: image/webp
  < content-length: 94822
  < x-7tv-cache-hits: 458307
  < x-7tv-cache: hit
  < age: 1649394
  < cache-control: public, max-age=31536000, s-maxage=86400, immutable
• Added alt-svc: cdn.7tv.app:443 over h3
  < alt-svc: h3=":443"; ma=2592000
  < x-7tv-cdn-pod: cdn-klnfz
  < x-7tv-cdn-node: cdn-2
  < server: SevenTV
  < vary: origin, access-control-request-method, access-control-request-headers
  < access-control-allow-origin: *
  < access-control-expose-headers: *
  <
  275233.975 RequestServer(30387): received 1158 bytes
  275233.975 RequestServer(30387): received 1158 bytes
  275233.975 RequestServer(30387): received 1158 bytes
  275233.975 RequestServer(30387): received 2316 bytes
  275233.975 RequestServer(30387): received 1158 bytes
  275233.975 RequestServer(30387): received 1158 bytes
  275233.975 RequestServer(30387): received 1158 bytes
  275234.016 RequestServer(30387): received 1279 bytes
  275234.016 RequestServer(30387): received 1284 bytes
  275234.020 RequestServer(30387): received 1284 bytes
  275234.020 RequestServer(30387): received 1284 bytes
  275234.020 RequestServer(30387): received 1284 bytes
  275234.020 RequestServer(30387): received 1284 bytes
  275234.020 RequestServer(30387): received 1282 bytes
  275234.020 RequestServer(30387): received 1282 bytes
  275234.021 RequestServer(30387): received 1282 bytes
  275234.022 RequestServer(30387): received 1282 bytes
  275234.022 RequestServer(30387): received 1282 bytes
  275234.022 RequestServer(30387): received 971 bytes
  275234.022 RequestServer(30387): received 311 bytes
  275234.022 RequestServer(30387): received 1282 bytes
  275234.022 RequestServer(30387): received 1282 bytes
  275234.022 RequestServer(30387): received 1282 bytes
  275234.022 RequestServer(30387): received 1282 bytes
  275234.062 RequestServer(30387): received 1338 bytes
  275234.062 RequestServer(30387): received 1345 bytes
  275234.062 RequestServer(30387): received 1345 bytes
  275234.062 RequestServer(30387): received 4035 bytes
  275234.068 RequestServer(30387): received 1338 bytes
  275234.068 RequestServer(30387): received 1345 bytes
  275234.068 RequestServer(30387): received 199 bytes
  275234.068 RequestServer(30387): received 1146 bytes
  275234.068 RequestServer(30387): received 1345 bytes
  275234.068 RequestServer(30387): received 1345 bytes
  275234.068 RequestServer(30387): received 1345 bytes
  275234.068 RequestServer(30387): received 1345 bytes
  275234.081 RequestServer(30387): received 1345 bytes
  275234.081 RequestServer(30387): received 1345 bytes
  275234.081 RequestServer(30387): received 4035 bytes
  275234.081 RequestServer(30387): received 1345 bytes
  275234.081 RequestServer(30387): received 1788 bytes
  275234.081 RequestServer(30387): received 902 bytes
  275234.081 RequestServer(30387): received 1345 bytes
  275234.081 RequestServer(30387): received 1345 bytes
  275234.092 RequestServer(30387): received 1345 bytes
  275234.092 RequestServer(30387): received 1345 bytes
  275234.092 RequestServer(30387): received 1345 bytes
  275234.092 RequestServer(30387): received 1345 bytes
  275234.092 RequestServer(30387): received 2690 bytes
  275234.092 RequestServer(30387): received 1345 bytes
  275234.092 RequestServer(30387): received 1345 bytes
  275234.092 RequestServer(30387): received 1345 bytes
  275234.108 RequestServer(30387): received 1371 bytes
  275234.108 RequestServer(30387): received 1376 bytes
  275234.108 RequestServer(30387): received 1376 bytes
  275234.108 RequestServer(30387): received 1376 bytes
  275234.108 RequestServer(30387): received 1376 bytes
  275234.108 RequestServer(30387): received 2004 bytes
  275234.108 RequestServer(30387): received 748 bytes
  275234.108 RequestServer(30387): received 1376 bytes
  275234.108 RequestServer(30387): received 1376 bytes
  275234.108 RequestServer(30387): received 1376 bytes
  275234.114 RequestServer(30387): received 1376 bytes
  275234.114 RequestServer(30387): received 1940 bytes
  275234.114 RequestServer(30387): received 812 bytes
  275234.114 RequestServer(30387): received 1376 bytes
  275234.114 RequestServer(30387): received 1376 bytes
  275234.114 RequestServer(30387): received 1376 bytes
  275234.120 RequestServer(30387): received 2 bytes
• HTTP/3 stream 0 reset by server (error 0x0 unknown)
• Connection #0 to host cdn.7tv.app:443 left intact
  275234.120 WebContent(30392): ResourceLoader: Failed load of: "https://cdn.7tv.app/emote/01F6MQ33FG000FFJ97ZB8MWV52/1x.webp", Error: Request finished with error: Connection was closed before entire response was received, Duration: 525ms

Adding up the individual "received N bytes" lines, they total the reported Content-Length of 94822 and then the server is strange and resets the stream with an unknown error code. This check here turns any received body bytes into a CURLE_PARTIAL_FILE error:

curl/lib/vquic/cf-ngtcp2.c

Lines 463 to 466 in 6841d59

	failf(data, "HTTP/3 stream %" PRId64 " reset by server (error 0x%" PRIx64
	" %s)", stream->id, stream->error3,
	Curl_vquic_h3_err_str(stream->error3));
	return data->req.bytecount ? CURLE_PARTIAL_FILE : CURLE_HTTP3;

I expected the following

If the full body (as reported by Content-Length) has been received, the check above should return CURLE_OK, even though the server had acted strangely by resetting the stream.

curl/libcurl version

libcurl/8.21.0 OpenSSL/3.5.3 zlib/1.3.1 brotli/1.2.0 zstd/1.5.7 nghttp2/1.68.0 ngtcp2/1.24.0 nghttp3/1.17.0

operating system

Darwin Mac.lan 25.5.0 Darwin Kernel Version 25.5.0: Tue Jun 9 22:28:34 PDT 2026; root:xnu-12377.121.10~1/RELEASE_ARM64_T6041 arm64

[icing]

Thanks for the report. The question I have is: does the server send an EOF data frame before the RESET or not?

If it does, we should ignore RESET frames after the EOF. If not, we should error the stream.

[Lubrsi]

It seems the server doesn't actually send a RESET_STREAM at all.

What appears to be happening is that after the server receives the request and just before sending the response starting with the headers, it's sending a STOP_SENDING frame with error code 0:

This seems to eventually get passed into cb_stream_close's app_error_code with flag NGTCP2_STREAM_CLOSE_FLAG_APP_ERROR_CODE_SET set, when the final frame with FIN set is received:
https://github.com/ngtcp2/ngtcp2/blob/713151dcef2b48e3f2d7977d091d8c92c0e9171d/lib/ngtcp2_strm.h#L177-L182
https://github.com/ngtcp2/ngtcp2/blob/713151dcef2b48e3f2d7977d091d8c92c0e9171d/lib/ngtcp2_strm.c#L707
https://github.com/ngtcp2/ngtcp2/blob/main/lib/ngtcp2_conn.c#L7956
https://github.com/ngtcp2/ngtcp2/blob/713151dcef2b48e3f2d7977d091d8c92c0e9171d/lib/ngtcp2_conn.c#L205-L207

Since the flag is set, the app_error_code is passed through unchanged to nghttp3:

curl/lib/vquic/cf-ngtcp2-cmn.c

Lines 376 to 380 in 6841d59

	if(!(flags & NGTCP2_STREAM_CLOSE_FLAG_APP_ERROR_CODE_SET)) {
	app_error_code = NGHTTP3_H3_NO_ERROR;
	}
	rv = nghttp3_conn_close_stream(ctx->h3conn, stream_id, app_error_code);

Then, cb_h3_stream_close is called with stream->error3 set to the app_error_code (0) passed down from nghttp3_conn_close_stream, which is not equal to NGHTTP3_H3_NO_ERROR (0x0100), so it interprets the STOP_SENDING frame as a stream reset at the very end:
https://github.com/ngtcp2/nghttp3/blob/e6a713006391469fcfca540d9c9ce2c8cdadc820/lib/nghttp3_conn.c#L2739
https://github.com/ngtcp2/nghttp3/blob/e6a713006391469fcfca540d9c9ce2c8cdadc820/lib/nghttp3_conn.c#L1357

curl/lib/vquic/cf-ngtcp2.c

Lines 109 to 114 in 6841d59

	if(stream->error3 != NGHTTP3_H3_NO_ERROR) {
	stream->reset = TRUE;
	stream->send_closed = TRUE;
	CURL_TRC_CF(data, cf, "[%" PRId64 "] RESET: error %" PRIu64,
	stream->id, stream->error3);
	}

[icing]

Nice analysis. Sounds like a broken server or do you think ngtpc2/nghttp3 does something wrong here?

[Lubrsi]

I think ngtcp2/nghttp3 are doing the right thing on the wire. In comparison, it seems when Chrome receives the STOP_SENDING frame from the server asking the client to stop sending request bytes, Chrome responds with RESET_STREAM, and ngtcp2 does the same thing internally.
https://github.com/ngtcp2/ngtcp2/blob/713151dcef2b48e3f2d7977d091d8c92c0e9171d/lib/ngtcp2_conn.c#L7956-L7974

It seems this is the relevant part of the HTTP/3 RFC:

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. When the server does not need to receive the remainder of the request, it MAY abort reading the request stream, send a complete response, and cleanly close the sending part of the stream. The error code H3_NO_ERROR SHOULD be used when requesting that the client stop sending on the request stream.

Even though it's out of the ordinary, I interpret this as the server being allowed to send a STOP_SENDING frame when it no longer requires request bytes, even for the simple GET here. The 0 application error code is not equal to H3_NO_ERROR (0x0100), but in Error Handling, it states:

Because new error codes can be defined without negotiation (see Section 9), use of an error code in an unexpected context or receipt of an unknown error code MUST be treated as equivalent to H3_NO_ERROR. However, closing a stream can have other effects regardless of the error code; for example, see Section 4.1.

Section 4.1 then goes on to say:

Clients MUST NOT discard complete responses as a result of having their request terminated abruptly, though clients can always discard responses at their discretion for other reasons. If the server sends a partial or complete response but does not abort reading the request, clients SHOULD continue sending the content of the request and close the stream normally.

I think the issue is that when ngtcp2 reports the application error code in the stream closing callback, it does not distinguish where it came from. This puts the onus on the user of the library to distinguish that. There is a new callback in v1.24.0 for STOP_SENDING which seems like it would make it possible for curl to distinguish this case:
https://github.com/ngtcp2/ngtcp2/blob/main/lib/includes/ngtcp2/ngtcp2.h#L3986-L3995

It's also possible that another callback could be used, but I haven't looked deeply into the other callbacks.

[tatsuhiro-t]

Perhaps, just ignore the error code, and check whether the transfer is completed or not by validating that whole response body is received? ngtcp2 has no knowledge about h3 and cannot translate or manipulate the error code.

[tatsuhiro-t]

After thinking a little bit more, ngtcp2 could provide new type of stream close callback that provides 2 error codes: send side and receive side. Unlike http/2, where a stream is terminated in both sides with a single RST_STREAM from any side, QUIC stream bidirectional stream treats both sides separately. We might have 2 different error codes here. So in this case, we have 0 error code in send side stream, and no error code in the receiving side of the stream.

[icing]

Makes sense to distinguish those. I just would us like to error on an unclean close by the server. Even though the content length might match (if there is one), it seems icky to just rely on this.

[tatsuhiro-t]

Yeah, that is the uneasy part of HTTP/2 style protocol. I hope the new callback would improve this situation.

[icing]

Yeah, that is the uneasy part of HTTP/2 style protocol. I hope the new callback would improve this situation.

Looking at the new callback for ngtcp2 v1.25.0: will this callback be invoked twice, e.g. once for each direction or just once when the stream is closed on both ends?

I am wondering when to call nghttp3_conn_close_stream() on this. My current version in #22356

[tatsuhiro-t]

@icing

Looking at the new callback for ngtcp2 v1.25.0: will this callback be invoked twice, e.g. once for each direction or just once when the stream is closed on both ends?

It is called just once. It is a replacement of ngtcp2_stream_close callback. It is invoked when both sides of stream are closed.

I am wondering when to call nghttp3_conn_close_stream() on this. My current version in #22356

nghttp3_conn_close_stream (or nghttp3_conn_close_stream2) should be called when a stream is closed, so call it inside ngtcp2_stream_close or ngtcp2_stream_close2. You can defer the call but they are the best places.