yknoya opened a new pull request, #12936: URL: https://github.com/apache/trafficserver/pull/12936
# Issue When multiple POST requests are sent over a single HTTP/2 connection, 408/504 (timeout) responses may occur if the HTTP/2 stream error rate exceeds the configured threshold. When the stream error rate exceeds the threshold, ATS sends a GOAWAY frame in the following code path. However, a timeout occurs between sending the GOAWAY frame and closing the connection with the client. https://github.com/apache/trafficserver/blob/00604e128794099e3fbc85afcd8b94ba3f3dc502/src/proxy/http2/Http2CommonSession.cc#L371-L393 # Root Cause The issue is caused by ATS canceling HTTP/2 frame reception processing after sending the GOAWAY frame. https://github.com/apache/trafficserver/blob/00604e128794099e3fbc85afcd8b94ba3f3dc502/src/proxy/http2/Http2CommonSession.cc#L363-L369 Specifically, while handling multiple POST requests, the timeout occurs in the following sequence: 1. The client sends a HEADERS frame. 2. ATS receives the HEADERS frame. 3. ATS forwards the request headers to the origin. 4. The client sends a DATA frame. 5. The stream error rate exceeds the threshold, and ATS sends a GOAWAY frame to the client. 6. ATS receives the DATA frame, but cancels processing because the GOAWAY frame has already been sent. 7. ATS creates an HttpTunnel to forward the request body to the origin. 8. ATS waits indefinitely for the request body to be sent to the origin, resulting in a timeout. I reviewed RFC 9113 regarding the handling of frames received after sending a GOAWAY frame. The following description indicates that canceling the reception of all frames violates the RFC: > After sending a GOAWAY frame, the sender can discard frames for streams initiated by the receiver with identifiers higher than the identified last stream. However, any frames that alter connection state cannot be completely ignored. For instance, HEADERS, PUSH_PROMISE, and CONTINUATION frames MUST be minimally processed to ensure that the state maintained for field section compression is consistent (see Section 4.3); similarly, DATA frames MUST be counted toward the connection flow-control window. https://datatracker.ietf.org/doc/html/rfc9113#name-goaway # Fix ATS has been modified to continue receiving frames even after the HTTP/2 stream error rate exceeds the threshold and a GOAWAY frame is sent. However, if the stream ID of a received frame is greater than the Last-Stream-ID specified at the time the GOAWAY frame was sent, frame processing is limited to HEADERS, PUSH_PROMISE, CONTINUATION, and DATA frames. In such cases, ATS performs only the minimal processing required by RFC 9113 and sends an RST_STREAM frame. -- 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]
