#2517 closed defect (invalid)
QUIC：After sending a RESET_STREAM, nginx does not cease transmission of STREAM frames?
| Reported by: | Owned by: | ||
|---|---|---|---|
| Priority: | minor | Milestone: | nginx-1.26 |
| Component: | http/3 | Version: | 1.25.x |
| Keywords: | RESET_STREAM | Cc: | |
| uname -a: | Linux dev.na61 4.19.91-008.x86_64 #1 SMP Fri Sep 4 17:33:26 CST 2020 x86_64 x86_64 x86_64 GNU/Linux | ||
| nginx -V: |
nginx version: nginx/1.25.2
built by gcc 9.3.0 (GCC) built with OpenSSL 1.1.0 (compatible; BoringSSL) (running with BoringSSL) TLS SNI support enabled configure arguments: --with-debug --with-http_v3_module --prefix=/home/yefei.dyf/nginx --with-cc-opt=-I/home/yefei.dyf/boringssl/include --with-ld-opt='-L/home/yefei.dyf/boringssl/ssl -L/home/yefei.dyf/boringssl/crypto' |
||
Description
RFC 9000, 19.4 has a related statement about RESET_STREAM frame.
After sending a RESET_STREAM, an endpoint ceases transmission and retransmission of STREAM frames on the identified stream. A receiver of RESET_STREAM can discard any data that it already received on that stream.
I found the logic to cease the retransmission of STREAM frames in ngx_quic_resend_frames, when qs->send_state was NGX_QUIC_STREAM_SEND_RESET_SENT or NGX_QUIC_STREAM_SEND_RESET_RECVD.
When sending a stream frame, was also to cease transmission of STREAM frames in ctx->frames of ngx_quic_output_packet?
Change History (3)
comment:1 by , 17 months ago
comment:2 by , 17 months ago
| Resolution: | → invalid |
|---|---|
| Status: | new → closed |
Note:
See TracTickets
for help on using tickets.
Stream frames are queued by ngx_quic_stream_flush() called by ngx_quic_stream_send_chain(). After reset, no more stream frames are queued there. Queued frames are packaged in QUIC packets by ngx_quic_output_packet(). In the unlikely case that between those calls the stream was reset, there's nothing wrong with sending them since the receiver will discard them. This can also happen if the frames were in-flight. Adding more code to ngx_quic_output_packet() to check if stream is not reset seems unnecessary.