maskit commented on issue #9179: URL: https://github.com/apache/trafficserver/issues/9179#issuecomment-1331097254
There are two issues. - ATS starts processing 6th HEADERS frame before it fully process the 1st RST_STREAM frame because actual stream deletion is done asynchronously and the stream count is not updated until the actual deletion. https://github.com/apache/trafficserver/blob/b9b6ee19e1b32ce12bfb5f2f9495e290e5bf9d41/proxy/http2/Http2Stream.cc#L519-L522 - Header blocks are not processed when the stream is refused. https://github.com/apache/trafficserver/blob/b9b6ee19e1b32ce12bfb5f2f9495e290e5bf9d41/proxy/http2/Http2ConnectionState.cc#L257-L260 https://github.com/apache/trafficserver/blob/b9b6ee19e1b32ce12bfb5f2f9495e290e5bf9d41/proxy/http2/Http2ConnectionState.cc#L1327-L1336 > An endpoint receiving [HEADERS](https://www.rfc-editor.org/rfc/rfc9113#HEADERS), [PUSH_PROMISE](https://www.rfc-editor.org/rfc/rfc9113#PUSH_PROMISE), or [CONTINUATION](https://www.rfc-editor.org/rfc/rfc9113#CONTINUATION) frames needs to reassemble field blocks and perform decompression even if the frames are to be discarded. https://www.rfc-editor.org/rfc/rfc9113#name-field-section-compression-a ---- For the first one, ATS just needs to complete stream deletion before it starts processing next frame. I don't think the stream count should be updated (decremented) until actual deletion completes because that can be used for a DoS attack and that would cause excessive memory utilization. For the second one, ATS needs to do whatever the spec says, but we also need to ensure that malicious activity doesn't cause excessive CPU utilization. Cancelling 100 streams on a session can be valid, but 100 of immediate cancellation is probably not. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
