Skip to content

Conversation

@bneradt
Copy link
Contributor

@bneradt bneradt commented Nov 19, 2025

When streams are canceled via RST_STREAM, the stream deletion now happens immediately before the next frame is processed. This prevents the race condition where new HEADERS frames are incorrectly refused because the stream count hasn't been decremented yet. Additionally, when streams are refused due to exceeding max_concurrent_streams, the header blocks are now properly decoded to maintain HPACK dynamic table synchronization per RFC 9113, and RST_STREAM with REFUSED_STREAM is sent instead of terminating the connection with COMPRESSION_ERROR.

Fixes: #9179


I have run this on a machine taking production traffic and it ran fine.

When streams are canceled via RST_STREAM, the stream deletion now
happens immediately before the next frame is processed. This prevents
the race condition where new HEADERS frames are incorrectly refused
because the stream count hasn't been decremented yet. Additionally, when
streams are refused due to exceeding max_concurrent_streams, the header
blocks are now properly decoded to maintain HPACK dynamic table
synchronization per RFC 9113, and RST_STREAM with REFUSED_STREAM is sent
instead of terminating the connection with COMPRESSION_ERROR.

Fixes: apache#9179
@bneradt bneradt added this to the 10.2.0 milestone Nov 19, 2025
@bneradt bneradt requested a review from maskit November 19, 2025 02:25
@bneradt bneradt self-assigned this Nov 19, 2025
@bneradt bneradt marked this pull request as ready for review November 19, 2025 22:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Canceled streams are not cleaned up in time

1 participant