Hacktoberfest 2026：維護者為十月標記出來的 issue，仍然開放、適合新手。 瀏覽 Hacktoberfest issue

quic: emit RFC 9114 stream-closure error codes (H3_REQUEST_CANCELLED, H3_REQUEST_INCOMPLETE)

未關閉
  • 哪裡不對？
#65,509 2 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

維護者通常 1 天內回覆

還沒有人認領這個 Issue。

評估

難度
5/5
預估耗時
一週以上
新手友好度
38/100
Issue 類型
功能
描述清晰度
基本清楚
活躍度
活躍
技術堆疊
javascript, nodejs
領域
networking

研究方向

從 issue 中描述的 QUIC HTTP/3 串流 teardown 路徑開始，並檢視 RFC 9114 的第 4.1 和 4.1.1 節。首先確認是否需要整合的 stream.cancel([reason]) API，然後確保取消使用 H3_REQUEST_CANCELLED，且未完成的用戶端請求串流使用 H3_REQUEST_INCOMPLETE；為這兩種行為新增或更新 coverage。

由索引模型根據 Issue 內容生成。

描述

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.

1. Cancellation — H3_REQUEST_CANCELLED (0x10c)

When 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:

  • 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").
  • The code is wrong. Both default to 0n (H3_NO_ERROR), so a cancel currently signals "no error" to the peer.
// Today: two calls, and both default to H3_NO_ERROR (0) — the peer is told "no error"
stream.resetStream();
stream.stopSending();

RFC 9114 §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.

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.

// Proposed: one call, resets both halves with H3_REQUEST_CANCELLED (0x10c)
stream.cancel();

This 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.

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:

// Alternative: still two calls, caller supplies the code via an exposed constant
stream.resetStream(<QUIC_CONSTANTS>.H3_REQUEST_CANCELLED);
stream.stopSending(<QUIC_CONSTANTS>.H3_REQUEST_CANCELLED);
2. Incomplete request — H3_REQUEST_INCOMPLETE (0x10d)

RFC 9114 §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."

This 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.

主要語言
JavaScript
星號
122k
分支
38.4k
平均合併
3 天 23 小時
30 天內合併 PR
274

環境準備

從這裡開始

  1. 先讀完整個 Issue，再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫，在一個分支上完成修改。
  4. 送出 Pull Request，並在描述裡引用這個 Issue 編號。

nodejs/node 的其他 Issue

查看 nodejs/node 的全部 Issue

相似的 Issue

更多 JavaScript Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。