You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
quic: Should QuicStream be destroyed, if onstream is not set #64192
Currently, incoming streams are destroyed, if the onstream callback is not set.
This sounds at first sight logically, however one can also use for http/3 onHeaders callback, later with webtransport support, it would be also onsessionid which is called for a webtransport data stream.
Then for http/3 onstream is most times pretty useless, as the other callbacks, which are opposed to the current docu are called later than onstream for h3 are more useful. So I have actually only stubs in onstream.
This is related to @pimterry api redesign (@jasnell may be also interested).
Agreed - if we're exposing the stream via other APIs, it shouldn't mysteriously die if it's being used elsewhere. The invariant should be broader: if we get a stream, and it's not exposed at all (nothing listening to any relevant callback) then it should be cleaned up automatically so it's not left hanging. It's not really about the onstream callback specifically.
Opened #65335 implementing the invariant discussed here — an incoming stream is destroyed only when the session has no consumer at all for it: no onstream, and no session-level stream callbacks runnable on the negotiated application (checked via the existing headersSupported state). Stub onstream handlers are no longer needed to keep h3/WebTransport streams alive.
One related observation as a possible follow-up: per RFC 9114 §4.1.1, rejecting a request stream without processing it should signal H3_REQUEST_REJECTED so the client knows it is safe to retry. The destroy path currently sends the generic error code instead. If that sounds right, happy to pick it up as a small follow-up.
Activity
pimterry commentedon Jun 29, 2026
Agreed - if we're exposing the stream via other APIs, it shouldn't mysteriously die if it's being used elsewhere. The invariant should be broader: if we get a stream, and it's not exposed at all (nothing listening to any relevant callback) then it should be cleaned up automatically so it's not left hanging. It's not really about the
onstreamcallback specifically.trivenay commentedon Aug 16, 2026
Opened #65335 implementing the invariant discussed here — an incoming stream is destroyed only when the session has no consumer at all for it: no
onstream, and no session-level stream callbacks runnable on the negotiated application (checked via the existingheadersSupportedstate). Stubonstreamhandlers are no longer needed to keep h3/WebTransport streams alive.Please take a look when you get a chance.
trivenay commentedon Aug 16, 2026
One related observation as a possible follow-up: per RFC 9114 §4.1.1, rejecting a request stream without processing it should signal
H3_REQUEST_REJECTEDso the client knows it is safe to retry. The destroy path currently sends the generic error code instead. If that sounds right, happy to pick it up as a small follow-up.quic: do not destroy incoming streams that have a consumer
quic: do not destroy incoming streams that have a consumer
quic: do not destroy incoming streams that have a consumer
quic: do not destroy incoming streams that have a consumer
quic: do not destroy incoming streams that have a consumer
quic: do not destroy incoming streams that have a consumer
quic: do not destroy incoming streams that have a consumer
quic: do not destroy incoming streams that have a consumer
quic: do not destroy incoming streams that have a consumer
quic: do not destroy incoming streams that have a consumer