René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"quic: emit RFC 9114 stream-closure error codes (H3_REQUEST_CANCELLED, H3_REQUEST_INCOMPLETE)","articleBody":"Following #65442, which made rejected request streams reset with `H3_REQUEST_REJECTED`, two more RFC 9114 stream-closure codes are still not emitted. Filing to agree on direction before implementing — one needs a small API decision.\n\n### 1. Cancellation — `H3_REQUEST_CANCELLED` (0x10c)\n\nWhen an endpoint gives up on a request it no longer wants (client aborting a request, or a server abandoning a response after starting it), the stream should be reset as *cancelled*. There are two gaps today:\n\n- **A cancel is two operations, with no single one.** Fully cancelling a bidirectional stream means aborting both halves — `RESET_STREAM` (\"I will not send more\") and `STOP_SENDING` (\"do not send me more\").\n- **The code is wrong.** Both default to `0n` (`H3_NO_ERROR`), so a cancel currently signals *\"no error\"* to the peer.\n\n```js\n// Today: two calls, and both default to H3_NO_ERROR (0) — the peer is told \"no error\"\nstream.resetStream();\nstream.stopSending();\n```\n\n[RFC 9114 §4.1.1](https://www.rfc-editor.org/rfc/rfc9114.html#section-4.1.1): *\"Client SHOULD use the error code H3_REQUEST_CANCELLED to cancel requests\"*, and a server abandoning a response after partial processing *\"SHOULD abort its response stream with the error code H3_REQUEST_CANCELLED.\"* node neither defaults to `0x10c` nor exposes it.\n\n**Proposal:** a `stream.cancel([reason])` method that resets both halves with `H3_REQUEST_CANCELLED`. Role-agnostic (client-cancel and server-abandon use the same code); the existing `resetStream()`/`stopSending()` stay as low-level primitives.\n\n```js\n// Proposed: one call, resets both halves with H3_REQUEST_CANCELLED (0x10c)\nstream.cancel();\n```\n\nThis keeps the numeric code out of consumer code (e.g. a future h3 client in undici, #5471), matching how `node:http2` offers `stream.close(code)` and how `fetch`/`AbortController` sits a layer above.\n\n*Alternative considered:* expose a named `H3_REQUEST_CANCELLED` constant for the existing resets. Still two calls, and it pushes the code choice onto every caller:\n\n```js\n// Alternative: still two calls, caller supplies the code via an exposed constant\nstream.resetStream(\u003cQUIC_CONSTANTS>.H3_REQUEST_CANCELLED);\nstream.stopSending(\u003cQUIC_CONSTANTS>.H3_REQUEST_CANCELLED);\n```\n\n### 2. Incomplete request — `H3_REQUEST_INCOMPLETE` (0x10d)\n\n[RFC 9114 §4.1](https://www.rfc-editor.org/rfc/rfc9114.html#section-4.1): *\"If a client-initiated stream terminates without enough of the HTTP message to provide a complete response, the server SHOULD abort its response stream with the error code H3_REQUEST_INCOMPLETE.\"*\n\nThis needs no API — the HTTP/3 layer can emit it when a request stream closes before a complete message. Today the teardown uses a generic code (`H3_NO_ERROR` or `H3_INTERNAL_ERROR`), so the client can't distinguish \"the server errored\" from \"my request was incomplete.\" Emitting `0x10d` puts the signal where it belongs.","author":{"url":"https://github.com/trivenay","@type":"Person","name":"trivenay"},"datePublished":"2026-08-23T19:49:30Z","url":"https://github.com/nodejs/node/issues/65509"}