I’m trying to understand the restrictions on the interleaving of frames in HTTP/2, specifically regarding HEADERS and CONTINUATION frames, as well as how the HPACK compression context is maintained. Here are my specific questions:
-
Interleaving HEADERS/CONTINUATION Frames with Other Frames:
I understand that the HEADERS/CONTINUATION frames cannot be interleaved with any other type of frame from the same stream or any other stream. This seems to be to maintain the correct compression context (HPACK dynamic table) on the sender’s and receiver’s end. However, why can’t a DATA frame from another stream be interleaved between the HEADERS/CONTINUATION frames of a stream, given that the DATA frame does not affect the compression context? -
Differentiating Between Sending and Receiving Frames:
When we say HEADERS/CONTINUATION frames should be sent as a contiguous unit and cannot be interleaved with any other frame on a stream from the client side, does it also mean that the client cannot receive any other type of frame from another stream at the same time as sending HEADERS/CONTINUATION frames on one stream? I want to clarify whether this restriction applies only to sending frames or if it also affects the client’s ability to receive frames from other streams concurrently. -
HPACK Compression Context Across Multiple Streams:
Since the HPACK compression context is maintained connection-wide, meaning all the streams of a connection use the same dynamic table and each stream will update the dynamic table accordingly, how is it possible for the client to send two requests in order on two different streams without first receiving the response from the first stream? When the first request is sent, HEADER frames are generated, compressed, and the dynamic table is updated. If, before receiving the response for request 1 on stream 1, the client opens another stream (stream 2) and sends request 2, which will again update the dynamic table (maybe adding some new entries), won’t it tamper with the compression context of the first request’s response?
According to Section 4.3 of RFC 7540 (HTTP/2), header compression is stateful, and each header block must be processed as a discrete unit. Header blocks must be transmitted as a contiguous sequence of frames, with no interleaved frames of any other type or from any other stream. This ensures the correct state of the HPACK dynamic table is maintained. However, I’m unclear on the specific rationale behind not allowing interleaving with DATA frames from other streams and whether receiving frames while sending HEADERS/CONTINUATION frames is restricted. Additionally, I am trying to understand how the HPACK compression context is correctly maintained across multiple streams when responses may not be received in order.