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:
|
void OnStopSending(stream_id id, error_code app_error_code) { |
which send invokes:
|
// 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?)
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
which send invokes:
node/src/quic/streams.cc
Line 1796 in ed33235
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?)