[GitHub] [trafficserver] maskit commented on issue #5675: ATS closes an H2 connection after refusing a new stream on the connection

[GitBox <gi...@apache.org>]

maskit commented on issue #5675:
URL: https://github.com/apache/trafficserver/issues/5675#issuecomment-908825717


   You're talking about below, right?
   
   > So the client could dutifully be decrementing the stream count on receiving the EOS frame, and then have a lower stream count than the peer and send too many HEADER frames. While this is only a STREAM error, it is likely that a DATA frame would be sent soon after resulting in a BAD stream ID error which is a connection error. This would take down the session and all active streams (which could be quite a few streams on a busy session).
   
   So a stream error happens on receiving HEADERS frame, and then a connection error on receiving following DATA frames.
   
   > But in the case where a HEADER frame was refused, the stream has never been opened.
   
   How is the HEADER frame "refused"? Isn't it by RST_STREAM? Once ATS received a HEADER frame, I think the stream is open regardless of whether it was accepted or not. Note that you cannot send RST_STREAM on an "idle" stream.
   
   > Possibly we could in the rejected HEADER case go ahead and bump the stream ID counters, so the resulting stream ID is valid but closed. Maybe that would pass the h2spec test.
   
   This sounds like an appropriate approach actually because the stream ID was used.


-- 
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: issues-unsubscribe@trafficserver.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org