quic: http3 nghttp3 handlers confuse stopSending and ResetStream

[martenrichter]

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.

I see that the nghttp3_stop_sending i
invokes:

node/src/quic/http3.cc

Line 924 in ed33235

void OnStopSending(stream_id id, error_code app_error_code) {

which send invokes:

node/src/quic/streams.cc

Line 1796 in ed33235

// 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?)

[pimterry]

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]

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