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: http3 nghttp3 handlers confuse stopSending and ResetStream #64237
While testing webtransport close capsule.
I have seen using a quiche client receives a quic ResetStream capsule between the webtransport capsule.
I asked in the nghttp3 PR for webtransport, what it might be: ngtcp2/nghttp3#442 (comment)
and @tatsuhiro-t suggested that the callbacks from http3 might be implemented in node.js not as it is intended.
// STOP_SENDING from the peer asks us to stop sending. Per RFC 9000
The name of the function suggest that node.js interprets it as receiving a stopsending, though nghttp3 means to ask that ngtcp2 sends a StopSending.
Any, I am not 100% sure if my diagnosis is correct? @jasnell and @pimterry can you take a look?
(Also, since @pimterry restructuring PR is in-flight, it probably does not make sense to make a PR, and also it sounds to me as if this could be rectified with the restructuring?)
Yes, that sounds very plausible to me, and makes sense generally that nghttp3 wouldn't be where QUIC frames like that would surface in any case.
I ran into a related issue - the actual behaviour we want for ReceiveStopSending actually isn't even possible today because there was no explicit callback for STOP_SENDING (we just detect it on the next write). I added a callback for it in ngtcp2 here but we haven't updated ngtcp2 here yet.
For my cases I don't think this is enormously impactful yet relative to the other issues, but yes it definitely sounds wrong so fixes in general are very welcome (though waiting a little until we have the other callback available to fix this fully might make it easier).
Don't worry about the big PR, changes like this might conflict a bit but that PR should rebase easily enough once we know what we're doing there, don't let it block other changes in the meantime.
Ok, then I will try to start to make a fix, tomorrow, and I will also look if the other callbacks from nghttp3 work correctly. Actually, these signals are quite important, as these issues can easily lead to blocking behavior when shutting connections down. (I really had a lot of fun with it, when doing my node.js plugin, it had a lot of bugs, the browsers had....)
@martenrichter ngtcp2 has now been updated here, and I've just opened the PR to fix the core issue I'm aware: #64710. Looking at that, do you think that was what caused this issue for you? Or is there something else more left?
Activity
pimterry commentedon Jul 2, 2026
Yes, that sounds very plausible to me, and makes sense generally that nghttp3 wouldn't be where QUIC frames like that would surface in any case.
I ran into a related issue - the actual behaviour we want for ReceiveStopSending actually isn't even possible today because there was no explicit callback for STOP_SENDING (we just detect it on the next write). I added a callback for it in ngtcp2 here but we haven't updated ngtcp2 here yet.
For my cases I don't think this is enormously impactful yet relative to the other issues, but yes it definitely sounds wrong so fixes in general are very welcome (though waiting a little until we have the other callback available to fix this fully might make it easier).
Don't worry about the big PR, changes like this might conflict a bit but that PR should rebase easily enough once we know what we're doing there, don't let it block other changes in the meantime.
martenrichter commentedon Jul 3, 2026
Ok, then I will try to start to make a fix, tomorrow, and I will also look if the other callbacks from nghttp3 work correctly. Actually, these signals are quite important, as these issues can easily lead to blocking behavior when shutting connections down. (I really had a lot of fun with it, when doing my node.js plugin, it had a lot of bugs, the browsers had....)
pimterry commentedon Jul 24, 2026
@martenrichter ngtcp2 has now been updated here, and I've just opened the PR to fix the core issue I'm aware: #64710. Looking at that, do you think that was what caused this issue for you? Or is there something else more left?
martenrichter commentedon Jul 24, 2026
@pimterry My bad, I closed the wrong issue with #64289 it was supposed to close this one and not:
#63657
martenrichter commentedon Jul 24, 2026
Do you have permissions to open #63657 .
pimterry commentedon Jul 24, 2026
Fixed 👍