diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index 6adc6ec375..ba43ff3232 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -508,7 +508,7 @@ All frames have the following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length (i) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Type (8) | Flags (8) | Frame Payload (*) ... +| Type (8) | Frame Payload (*) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~~~~~~~~~~ {: #fig-frame title="HTTP/QUIC frame format"} @@ -522,10 +522,6 @@ A frame includes the following fields: Type: : An 8-bit type for the frame. - Flags: - : An 8-bit field containing flags. The Type field determines the semantics of - flags. - Frame Payload: : A payload, the semantics of which are determined by the Type field. @@ -537,8 +533,6 @@ A frame includes the following fields: DATA frames (type=0x0) convey arbitrary, variable-length sequences of octets associated with an HTTP request or response payload. -The DATA frame defines no flags. - DATA frames MUST be associated with an HTTP request or response. If a DATA frame is received on either control stream, the recipient MUST respond with a connection error ({{errors}}) of type HTTP_WRONG_STREAM. @@ -561,8 +555,6 @@ with a payload length of zero, the recipient MUST respond with a stream error The HEADERS frame (type=0x1) is used to carry a header block, compressed using QPACK. See [QPACK] for more details. -The HEADERS frame defines no flags. - ~~~~~~~~~~ drawing 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 @@ -587,23 +579,12 @@ to allow for identification of server pushes, and the larger stream ID space of QUIC. The semantics of the Stream Dependency, Weight, and E flag are otherwise the same as in HTTP/2. -The flags defined are: - - PUSH_PRIORITIZED (0x04): - : Indicates that the Prioritized Stream is a server push rather than a - request. - - PUSH_DEPENDENT (0x02): - : Indicates a dependency on a server push. - - E (0x01): - : Indicates that the stream dependency is exclusive (see {{!RFC7540}}, Section - 5.3). - ~~~~~~~~~~ drawing 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Flags (8) | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prioritized Request ID (i) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stream Dependency ID (i) ... @@ -615,6 +596,23 @@ The flags defined are: The PRIORITY frame payload has the following fields: + Flags: + : An eight-bit field containing flags. The flags defined are: + + PUSH_PRIORITIZED (0x04): + : Indicates that the Prioritized Stream is a server push rather than a + request. + + PUSH_DEPENDENT (0x02): + : Indicates a dependency on a server push. + + E (0x01): + : Indicates that the stream dependency is exclusive (see {{!RFC7540}}, + Section 5.3). + + Undefined bits in the Flags field MUST be zero when sent, and ignored upon + receipt. + Prioritized Request ID: : A variable-length integer that identifies a request. This contains the Stream ID of a request stream when the PUSH_PRIORITIZED flag is clear, @@ -686,8 +684,6 @@ A CANCEL_PUSH frame is sent on the control stream. Sending a CANCEL_PUSH frame on a stream other than the control stream MUST be treated as a stream error of type HTTP_WRONG_STREAM. -The CANCEL_PUSH frame has no defined flags. - ~~~~~~~~~~ drawing 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 @@ -731,8 +727,6 @@ Parameters MUST NOT occur more than once. A receiver MAY treat the presence of the same parameter more than once as a connection error of type HTTP_MALFORMED_FRAME. -The SETTINGS frame defines no flags. - The payload of a SETTINGS frame consists of zero or more parameters, each consisting of an unsigned 16-bit setting identifier and a length-prefixed binary value. @@ -803,7 +797,7 @@ prior to receiving and processing the server's SETTINGS frame. ### PUSH_PROMISE {#frame-push-promise} The PUSH_PROMISE frame (type=0x05) is used to carry a request header set from -server to client, as in HTTP/2. The PUSH_PROMISE frame defines no flags. +server to client, as in HTTP/2. ~~~~~~~~~~ drawing 0 1 2 3 @@ -861,8 +855,6 @@ while still finishing processing of previously received requests. This enables administrative actions, like server maintenance. GOAWAY by itself does not close a connection. -The GOAWAY frame does not define any flags. - ~~~~~~~~~~ drawing 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 @@ -974,8 +966,6 @@ cannot push until it receives a MAX_PUSH_ID frame. A client that wishes to manage the number of promised server pushes can increase the maximum Push ID by sending a MAX_PUSH_ID frame as the server fulfills or cancels server pushes. -The MAX_PUSH_ID frame has no defined flags. - ~~~~~~~~~~ drawing 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 @@ -1112,7 +1102,8 @@ transport deals with them. Because frames are already on a stream, they can omit the stream number. Because frames do not block multiplexing (QUIC's multiplexing occurs below this layer), the support for variable-maximum-length packets can be removed. Because stream termination is handled by QUIC, an END_STREAM flag is -not required. +not required. This permits the removal of the Flags field from the generic +frame layout. Frame payloads are largely drawn from {{!RFC7540}}. However, QUIC includes many features (e.g. flow control) which are also present in HTTP/2. In these cases, @@ -1151,7 +1142,11 @@ HTTP/QUIC use an identifier rather than a Stream ID (e.g. Push IDs in PRIORITY frames). Redefinition of the encoding of extension frame types might be necessary if the encoding includes a Stream ID. -Other than this issue, frame type HTTP/2 extensions are typically portable to +Because the Flags field is not present in generic HTTP/QUIC frames, those frames +which depend on the presence of flags need to allocate space for flags as part +of their frame payload. + +Other than these issues, frame type HTTP/2 extensions are typically portable to QUIC simply by replacing Stream 0 in HTTP/2 with Stream 2 or 3 in HTTP/QUIC. HTTP/QUIC extensions will not assume ordering, but would not be harmed by ordering, and would be portable to HTTP/2 in the same manner. @@ -1365,9 +1360,9 @@ Code: : The 8-bit code assigned to the frame type. Specification: -: A reference to a specification that includes a description of the frame - layout, its semantics, and flags that the frame type uses, including any parts - of the frame that are conditionally present based on the value of flags. +: A reference to a specification that includes a description of the frame layout + and its semantics, including any parts of the frame that are conditionally + present. The entries in the following table are registered by this document.