HTTP - Hypertext Transfer Protocol
[Search] [txt]] | html | xml | pdf | Contains the path and query parts of the target URI (the "path-absolute" production and optionally a | Frame | Control Stream | Request | Push | Section | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | Stream | Stream | rfc_9114_http_3 | +==============+================+================+========+=========+ | DATA | No | Yes | Yes | Section | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | 7.2.1 | +--------------+----------------+----------------+--------+---------+ | HEADERS | No | Yes | Yes | Section | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | 7.2.2 | +--------------+----------------+----------------+--------+---------+ | CANCEL_PUSH | Yes | No | No | Section | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | 7.2.3 | +--------------+----------------+----------------+--------+---------+ | SETTINGS | Yes (1) | No | No | Section | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | 7.2.4 | +--------------+----------------+----------------+--------+---------+ | PUSH_PROMISE | No | Yes | No | Section | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | 7.2.5 | +--------------+----------------+----------------+--------+---------+ | GOAWAY | Yes | No | No | Section | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | 7.2.6 | +--------------+----------------+----------------+--------+---------+ | MAX_PUSH_ID | Yes | No | No | Section | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | 7.2.7 | +--------------+----------------+----------------+--------+---------+ | Reserved | Yes | Yes | Yes | Section | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | 7.2.8 | +--------------+----------------+----------------+--------+---------+ Table 1: HTTP/3 Frames and Stream Type Overview The SETTINGS frame can only occur as the first frame of a Control stream; this is indicated in Table 1 with a (1). Specific guidance is provided in the relevant section. Note that, unlike QUIC frames, HTTP/3 frames can span multiple packets. 7.1. Frame Layout All frames have the following format: HTTP/3 Frame Format { Type (i), Length (i), Frame Payload (..), } Figure 3: HTTP/3 Frame Format A frame includes the following fields: Type: A variable-length integer that identifies the frame type. Length: A variable-length integer that describes the length in bytes of the Frame Payload. Frame Payload: A payload, the semantics of which are determined by the Type field. Each frame's payload MUST contain exactly the fields identified in its description. A frame payload that contains additional bytes after the identified fields or a frame payload that terminates before the end of the identified fields MUST be treated as a connection error of type H3_FRAME_ERROR. In particular, redundant length encodings MUST be verified to be self-consistent; see Section 10.8. When a stream terminates cleanly, if the last frame on the stream was truncated, this MUST be treated as a connection error of type H3_FRAME_ERROR. Streams that terminate abruptly may be reset at any point in a frame. 7.2. Frame Definitions 7.2.1. DATA DATA frames (type=0x00) convey arbitrary, variable-length sequences of bytes associated with HTTP request or response content. DATA frames MUST be associated with an HTTP request or response. If a DATA frame is received on a control stream, the recipient MUST respond with a connection error of type H3_FRAME_UNEXPECTED. DATA Frame { Type (i) = 0x00, Length (i), Data (..), } Figure 4: DATA Frame 7.2.2. HEADERS The HEADERS frame (type=0x01) is used to carry an HTTP field section that is encoded using QPACK. See [QPACK] for more details. HEADERS Frame { Type (i) = 0x01, Length (i), Encoded Field Section (..), } Figure 5: HEADERS Frame HEADERS frames can only be sent on request streams or push streams. If a HEADERS frame is received on a control stream, the recipient MUST respond with a connection error of type H3_FRAME_UNEXPECTED. 7.2.3. CANCEL_PUSH The CANCEL_PUSH frame (type=0x03) is used to request cancellation of a server push prior to the push stream being received. The CANCEL_PUSH frame identifies a server push by push ID (see Section 4.6), encoded as a variable-length integer. When a client sends a CANCEL_PUSH frame, it is indicating that it does not wish to receive the promised resource. The server SHOULD abort sending the resource, but the mechanism to do so depends on the state of the corresponding push stream. If the server has not yet created a push stream, it does not create one. If the push stream is open, the server SHOULD abruptly terminate that stream. If the push stream has already ended, the server MAY still abruptly terminate the stream or MAY take no action. A server sends a CANCEL_PUSH frame to indicate that it will not be fulfilling a promise that was previously sent. The client cannot expect the corresponding promise to be fulfilled, unless it has already received and processed the promised response. Regardless of whether a push stream has been opened, a server SHOULD send a CANCEL_PUSH frame when it determines that promise will not be fulfilled. If a stream has already been opened, the server can abort sending on the stream with an error code of H3_REQUEST_CANCELLED. Sending a CANCEL_PUSH frame has no direct effect on the state of existing push streams. A client SHOULD NOT send a CANCEL_PUSH frame when it has already received a corresponding push stream. A push stream could arrive after a client has sent a CANCEL_PUSH frame, because a server might not have processed the CANCEL_PUSH. The client SHOULD abort reading the stream with an error code of H3_REQUEST_CANCELLED. A CANCEL_PUSH frame is sent on the control stream. Receiving a CANCEL_PUSH frame on a stream other than the control stream MUST be treated as a connection error of type H3_FRAME_UNEXPECTED. CANCEL_PUSH Frame { Type (i) = 0x03, Length (i), Push ID (i), } Figure 6: CANCEL_PUSH Frame The CANCEL_PUSH frame carries a push ID encoded as a variable-length integer. The Push ID field identifies the server push that is being cancelled; see Section 4.6. If a CANCEL_PUSH frame is received that references a push ID greater than currently allowed on the connection, this MUST be treated as a connection error of type H3_ID_ERROR. If the client receives a CANCEL_PUSH frame, that frame might identify a push ID that has not yet been mentioned by a PUSH_PROMISE frame due to reordering. If a server receives a CANCEL_PUSH frame for a push ID that has not yet been mentioned by a PUSH_PROMISE frame, this MUST be treated as a connection error of type H3_ID_ERROR. 7.2.4. SETTINGS The SETTINGS frame (type=0x04) conveys configuration parameters that affect how endpoints communicate, such as preferences and constraints on peer behavior. Individually, a SETTINGS parameter can also be referred to as a "setting"; the identifier and value of each setting parameter can be referred to as a "setting identifier" and a "setting value". SETTINGS frames always apply to an entire HTTP/3 connection, never a single stream. A SETTINGS frame MUST be sent as the first frame of each control stream (see Section 6.2.1) by each peer, and it MUST NOT be sent subsequently. If an endpoint receives a second SETTINGS frame on the control stream, the endpoint MUST respond with a connection error of type H3_FRAME_UNEXPECTED. SETTINGS frames MUST NOT be sent on any stream other than the control stream. If an endpoint receives a SETTINGS frame on a different stream, the endpoint MUST respond with a connection error of type H3_FRAME_UNEXPECTED. SETTINGS parameters are not negotiated; they describe characteristics of the sending peer that can be used by the receiving peer. However, a negotiation can be implied by the use of SETTINGS: each peer uses SETTINGS to advertise a set of supported values. The definition of the setting would describe how each peer combines the two sets to conclude which choice will be used. SETTINGS does not provide a mechanism to identify when the choice takes effect. Different values for the same parameter can be advertised by each peer. For example, a client might be willing to consume a very large response field section, while servers are more cautious about request size. The same setting identifier MUST NOT occur more than once in the SETTINGS frame. A receiver MAY treat the presence of duplicate setting identifiers as a connection error of type H3_SETTINGS_ERROR. The payload of a SETTINGS frame consists of zero or more parameters. Each parameter consists of a setting identifier and a value, both encoded as QUIC variable-length integers. Setting { Identifier (i), Value (i), } SETTINGS Frame { Type (i) = 0x04, Length (i), Setting (..) ..., } Figure 7: SETTINGS Frame An implementation MUST ignore any parameter with an identifier it does not understand. 7.2.4.1. Defined SETTINGS Parameters The following settings are defined in HTTP/3: SETTINGS_MAX_FIELD_SECTION_SIZE (0x06): The default value is unlimited. See Section 4.2.2 for usage. Setting identifiers of the format 0x1f * N + 0x21 for non-negative integer values of N are reserved to exercise the requirement that unknown identifiers be ignored. Such settings have no defined meaning. Endpoints SHOULD include at least one such setting in their SETTINGS frame. Endpoints MUST NOT consider such settings to have any meaning upon receipt. Because the setting has no defined meaning, the value of the setting can be any value the implementation selects. Setting identifiers that were defined in [HTTP/2] where there is no corresponding HTTP/3 setting have also been reserved (Section 11.2.2). These reserved settings MUST NOT be sent, and their receipt MUST be treated as a connection error of type H3_SETTINGS_ERROR. Additional settings can be defined by extensions to HTTP/3; see Section 9 for more details. 7.2.4.2. Initialization An HTTP implementation MUST NOT send frames or requests that would be invalid based on its current understanding of the peer's settings. All settings begin at an initial value. Each endpoint SHOULD use these initial values to send messages before the peer's SETTINGS frame has arrived, as packets carrying the settings can be lost or delayed. When the SETTINGS frame arrives, any settings are changed to their new values. This removes the need to wait for the SETTINGS frame before sending messages. Endpoints MUST NOT require any data to be received from the peer prior to sending the SETTINGS frame; settings MUST be sent as soon as the transport is ready to send data. For servers, the initial value of each client setting is the default value. For clients using a 1-RTT QUIC connection, the initial value of each server setting is the default value. 1-RTT keys will always become available prior to the packet containing SETTINGS being processed by QUIC, even if the server sends SETTINGS immediately. Clients SHOULD NOT wait indefinitely for SETTINGS to arrive before sending requests, but they SHOULD process received datagrams in order to increase the likelihood of processing SETTINGS before sending the first request. When a 0-RTT QUIC connection is being used, the initial value of each server setting is the value used in the previous session. Clients SHOULD store the settings the server provided in the HTTP/3 connection where resumption information was provided, but they MAY opt not to store settings in certain cases (e.g., if the session ticket is received before the SETTINGS frame). A client MUST comply with stored settings -- or default values if no values are stored -- when attempting 0-RTT. Once a server has provided new settings, clients MUST comply with those values. A server can remember the settings that it advertised or store an integrity-protected copy of the values in the ticket and recover the information when accepting 0-RTT data. A server uses the HTTP/3 settings values in determining whether to accept 0-RTT data. If the server cannot determine that the settings remembered by a client are compatible with its current settings, it MUST NOT accept 0-RTT data. Remembered settings are compatible if a client complying with those settings would not violate the server's current settings. A server MAY accept 0-RTT and subsequently provide different settings in its SETTINGS frame. If 0-RTT data is accepted by the server, its SETTINGS frame MUST NOT reduce any limits or alter any values that might be violated by the client with its 0-RTT data. The server MUST include all settings that differ from their default values. If a server accepts 0-RTT but then sends settings that are not compatible with the previously specified settings, this MUST be treated as a connection error of type H3_SETTINGS_ERROR. If a server accepts 0-RTT but then sends a SETTINGS frame that omits a setting value that the client understands (apart from reserved setting identifiers) that was previously specified to have a non-default value, this MUST be treated as a connection error of type H3_SETTINGS_ERROR. 7.2.5. PUSH_PROMISE The PUSH_PROMISE frame (type=0x05) is used to carry a promised request header section from server to client on a request stream. PUSH_PROMISE Frame { Type (i) = 0x05, Length (i), Push ID (i), Encoded Field Section (..), } Figure 8: PUSH_PROMISE Frame The payload consists of: Push ID: A variable-length integer that identifies the server push operation. A push ID is used in push stream headers (Section 4.6) and CANCEL_PUSH frames. Encoded Field Section: QPACK-encoded request header fields for the promised response. See [QPACK] for more details. A server MUST NOT use a push ID that is larger than the client has provided in a MAX_PUSH_ID frame (Section 7.2.7). A client MUST treat receipt of a PUSH_PROMISE frame that contains a larger push ID than the client has advertised as a connection error of H3_ID_ERROR. A server MAY use the same push ID in multiple PUSH_PROMISE frames. If so, the decompressed request header sets MUST contain the same fields in the same order, and both the name and the value in each field MUST be exact matches. Clients SHOULD compare the request header sections for resources promised multiple times. If a client receives a push ID that has already been promised and detects a mismatch, it MUST respond with a connection error of type H3_GENERAL_PROTOCOL_ERROR. If the decompressed field sections match exactly, the client SHOULD associate the pushed content with each stream on which a PUSH_PROMISE frame was received. Allowing duplicate references to the same push ID is primarily to reduce duplication caused by concurrent requests. A server SHOULD avoid reusing a push ID over a long period. Clients are likely to consume server push responses and not retain them for reuse over time. Clients that see a PUSH_PROMISE frame that uses a push ID that they have already consumed and discarded are forced to ignore the promise. If a PUSH_PROMISE frame is received on the control stream, the client MUST respond with a connection error of type H3_FRAME_UNEXPECTED. A client MUST NOT send a PUSH_PROMISE frame. A server MUST treat the receipt of a PUSH_PROMISE frame as a connection error of type H3_FRAME_UNEXPECTED. See Section 4.6 for a description of the overall server push mechanism. 7.2.6. GOAWAY The GOAWAY frame (type=0x07) is used to initiate graceful shutdown of an HTTP/3 connection by either endpoint. GOAWAY allows an endpoint to stop accepting new requests or pushes while still finishing processing of previously received requests and pushes. This enables administrative actions, like server maintenance. GOAWAY by itself does not close a connection. GOAWAY Frame { Type (i) = 0x07, Length (i), Stream ID/Push ID (i), } Figure 9: GOAWAY Frame The GOAWAY frame is always sent on the control stream. In the server-to-client direction, it carries a QUIC stream ID for a client- initiated bidirectional stream encoded as a variable-length integer. A client MUST treat receipt of a GOAWAY frame containing a stream ID of any other type as a connection error of type H3_ID_ERROR. In the client-to-server direction, the GOAWAY frame carries a push ID encoded as a variable-length integer. The GOAWAY frame applies to the entire connection, not a specific stream. A client MUST treat a GOAWAY frame on a stream other than the control stream as a connection error of type H3_FRAME_UNEXPECTED. See Section 5.2 for more information on the use of the GOAWAY frame. 7.2.7. MAX_PUSH_ID The MAX_PUSH_ID frame (type=0x0d) is used by clients to control the number of server pushes that the server can initiate. This sets the maximum value for a push ID that the server can use in PUSH_PROMISE and CANCEL_PUSH frames. Consequently, this also limits the number of push streams that the server can initiate in addition to the limit maintained by the QUIC transport. The MAX_PUSH_ID frame is always sent on the control stream. Receipt of a MAX_PUSH_ID frame on any other stream MUST be treated as a connection error of type H3_FRAME_UNEXPECTED. A server MUST NOT send a MAX_PUSH_ID frame. A client MUST treat the receipt of a MAX_PUSH_ID frame as a connection error of type H3_FRAME_UNEXPECTED. The maximum push ID is unset when an HTTP/3 connection is created, meaning that a server 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 MAX_PUSH_ID frames as the server fulfills or cancels server pushes. MAX_PUSH_ID Frame { Type (i) = 0x0d, Length (i), Push ID (i), } Figure 10: MAX_PUSH_ID Frame The MAX_PUSH_ID frame carries a single variable-length integer that identifies the maximum value for a push ID that the server can use; see Section 4.6. A MAX_PUSH_ID frame cannot reduce the maximum push ID; receipt of a MAX_PUSH_ID frame that contains a smaller value than previously received MUST be treated as a connection error of type H3_ID_ERROR. 7.2.8. Reserved Frame Types Frame types of the format 0x1f * N + 0x21 for non-negative integer values of N are reserved to exercise the requirement that unknown types be ignored (Section 9). These frames have no semantics, and they MAY be sent on any stream where frames are allowed to be sent. This enables their use for application-layer padding. Endpoints MUST NOT consider these frames to have any meaning upon receipt. The payload and length of the frames are selected in any manner the implementation chooses. Frame types that were used in HTTP/2 where there is no corresponding HTTP/3 frame have also been reserved (Section 11.2.1). These frame types MUST NOT be sent, and their receipt MUST be treated as a connection error of type H3_FRAME_UNEXPECTED. 8. Error Handling When a stream cannot be completed successfully, QUIC allows the application to abruptly terminate (reset) that stream and communicate a reason; see Section 2.4 of [QUIC-TRANSPORT]. This is referred to as a "stream error". An HTTP/3 implementation can decide to close a QUIC stream and communicate the type of error. Wire encodings of error codes are defined in Section 8.1. Stream errors are distinct from HTTP status codes that indicate error conditions. Stream errors indicate that the sender did not transfer or consume the full request or response, while HTTP status codes indicate the result of a request that was successfully received. If an entire connection needs to be terminated, QUIC similarly provides mechanisms to communicate a reason; see Section 5.3 of [QUIC-TRANSPORT]. This is referred to as a "connection error". Similar to stream errors, an HTTP/3 implementation can terminate a QUIC connection and communicate the reason using an error code from Section 8.1. Although the reasons for closing streams and connections are called "errors", these actions do not necessarily indicate a problem with the connection or either implementation. For example, a stream can be reset if the requested resource is no longer needed. An endpoint MAY choose to treat a stream error as a connection error under certain circumstances, closing the entire connection in response to a condition on a single stream. Implementations need to consider the impact on outstanding requests before making this choice. Because new error codes can be defined without negotiation (see Section 9), use of an error code in an unexpected context or receipt of an unknown error code MUST be treated as equivalent to H3_NO_ERROR. However, closing a stream can have other effects regardless of the error code; for example, see Section 4.1. 8.1. HTTP/3 Error Codes The following error codes are defined for use when abruptly terminating streams, aborting reading of streams, or immediately closing HTTP/3 connections. H3_NO_ERROR (0x0100): No error. This is used when the connection or stream needs to be closed, but there is no error to signal. H3_GENERAL_PROTOCOL_ERROR (0x0101): Peer violated protocol requirements in a way that does not match a more specific error code or endpoint declines to use the more specific error code. H3_INTERNAL_ERROR (0x0102): An internal error has occurred in the HTTP stack. H3_STREAM_CREATION_ERROR (0x0103): The endpoint detected that its peer created a stream that it will not accept. H3_CLOSED_CRITICAL_STREAM (0x0104): A stream required by the HTTP/3 connection was closed or reset. H3_FRAME_UNEXPECTED (0x0105): A frame was received that was not permitted in the current state or on the current stream. H3_FRAME_ERROR (0x0106): A frame that fails to satisfy layout requirements or with an invalid size was received. H3_EXCESSIVE_LOAD (0x0107): The endpoint detected that its peer is exhibiting a behavior that might be generating excessive load. H3_ID_ERROR (0x0108): A stream ID or push ID was used incorrectly, such as exceeding a limit, reducing a limit, or being reused. H3_SETTINGS_ERROR (0x0109): An endpoint detected an error in the payload of a SETTINGS frame. H3_MISSING_SETTINGS (0x010a): No SETTINGS frame was received at the beginning of the control stream. H3_REQUEST_REJECTED (0x010b): A server rejected a request without performing any application processing. H3_REQUEST_CANCELLED (0x010c): The request or its response (including pushed response) is cancelled. H3_REQUEST_INCOMPLETE (0x010d): The client's stream terminated without containing a fully formed request. H3_MESSAGE_ERROR (0x010e): An HTTP message was malformed and cannot be processed. H3_CONNECT_ERROR (0x010f): The TCP connection established in response to a CONNECT request was reset or abnormally closed. H3_VERSION_FALLBACK (0x0110): The requested operation cannot be served over HTTP/3. The peer should retry over HTTP/1.1. Error codes of the format 0x1f * N + 0x21 for non-negative integer values of N are reserved to exercise the requirement that unknown error codes be treated as equivalent to H3_NO_ERROR (Section 9). Implementations SHOULD select an error code from this space with some probability when they would have sent H3_NO_ERROR. 9. Extensions to HTTP/3 HTTP/3 permits extension of the protocol. Within the limitations described in this section, protocol extensions can be used to provide additional services or alter any aspect of the protocol. Extensions are effective only within the scope of a single HTTP/3 connection. This applies to the protocol elements defined in this document. This does not affect the existing options for extending HTTP, such as defining new methods, status codes, or fields. Extensions are permitted to use new frame types (Section 7.2), new settings (Section 7.2.4.1), new error codes (Section 8), or new unidirectional stream types (Section 6.2). Registries are established for managing these extension points: frame types (Section 11.2.1), settings (Section 11.2.2), error codes (Section 11.2.3), and stream types (Section 11.2.4). Implementations MUST ignore unknown or unsupported values in all extensible protocol elements. Implementations MUST discard data or abort reading on unidirectional streams that have unknown or unsupported types. This means that any of these extension points can be safely used by extensions without prior arrangement or negotiation. However, where a known frame type is required to be in a specific location, such as the SETTINGS frame as the first frame of the control stream (see Section 6.2.1), an unknown frame type does not satisfy that requirement and SHOULD be treated as an error. Extensions that could change the semantics of existing protocol components MUST be negotiated before being used. For example, an extension that changes the layout of the HEADERS frame cannot be used until the peer has given a positive signal that this is acceptable. Coordinating when such a revised layout comes into effect could prove complex. As such, allocating new identifiers for new definitions of existing protocol elements is likely to be more effective. This document does not mandate a specific method for negotiating the use of an extension, but it notes that a setting (Section 7.2.4.1) could be used for that purpose. If both peers set a value that indicates willingness to use the extension, then the extension can be used. If a setting is used for extension negotiation, the default value MUST be defined in such a fashion that the extension is disabled if the setting is omitted. 10. Security Considerations The security considerations of HTTP/3 should be comparable to those of HTTP/2 with TLS. However, many of the considerations from Section 10 of [HTTP/2] apply to [QUIC-TRANSPORT] and are discussed in that document. 10.1. Server Authority HTTP/3 relies on the HTTP definition of authority. The security considerations of establishing authority are discussed in Section 17.1 of [HTTP]. 10.2. Cross-Protocol Attacks The use of ALPN in the TLS and QUIC handshakes establishes the target application protocol before application-layer bytes are processed. This ensures that endpoints have strong assurances that peers are using the same protocol. This does not guarantee protection from all cross-protocol attacks. Section 21.5 of [QUIC-TRANSPORT] describes some ways in which the plaintext of QUIC packets can be used to perform request forgery against endpoints that don't use authenticated transports. 10.3. Intermediary-Encapsulation Attacks The HTTP/3 field encoding allows the expression of names that are not valid field names in the syntax used by HTTP (Section 5.1 of [HTTP]). Requests or responses containing invalid field names MUST be treated as malformed. Therefore, an intermediary cannot translate an HTTP/3 request or response containing an invalid field name into an HTTP/1.1 message. Similarly, HTTP/3 can transport field values that are not valid. While most values that can be encoded will not alter field parsing, carriage return (ASCII 0x0d), line feed (ASCII 0x0a), and the null character (ASCII 0x00) might be exploited by an attacker if they are translated verbatim. Any request or response that contains a character not permitted in a field value MUST be treated as malformed. Valid characters are defined by the "field-content" ABNF rule in Section 5.5 of [HTTP]. 10.4. Cacheability of Pushed Responses Pushed responses do not have an explicit request from the client; the request is provided by the server in the PUSH_PROMISE frame. Caching responses that are pushed is possible based on the guidance provided by the origin server in the Cache-Control header field. However, this can cause issues if a single server hosts more than one tenant. For example, a server might offer multiple users each a small portion of its URI space. Where multiple tenants share space on the same server, that server MUST ensure that tenants are not able to push representations of resources that they do not have authority over. Failure to enforce this would allow a tenant to provide a representation that would be served out of cache, overriding the actual representation that the authoritative tenant provides. Clients are required to reject pushed responses for which an origin server is not authoritative; see Section 4.6. 10.5. Denial-of-Service Considerations An HTTP/3 connection can demand a greater commitment of resources to operate than an HTTP/1.1 or HTTP/2 connection. The use of field compression and flow control depend on a commitment of resources for storing a greater amount of state. Settings for these features ensure that memory commitments for these features are strictly bounded. The number of PUSH_PROMISE frames is constrained in a similar fashion. A client that accepts server push SHOULD limit the number of push IDs it issues at a time. Processing capacity cannot be guarded as effectively as state capacity. The ability to send undefined protocol elements that the peer is required to ignore can be abused to cause a peer to expend additional processing time. This might be done by setting multiple undefined SETTINGS parameters, unknown frame types, or unknown stream types. Note, however, that some uses are entirely legitimate, such as optional-to-understand extensions and padding to increase resistance to traffic analysis. Compression of field sections also offers some opportunities to waste processing resources; see Section 7 of [QPACK] for more details on potential abuses. All these features -- i.e., server push, unknown protocol elements, field compression -- have legitimate uses. These features become a burden only when they are used unnecessarily or to excess. An endpoint that does not monitor such behavior exposes itself to a risk of denial-of-service attack. Implementations SHOULD track the use of these features and set limits on their use. An endpoint MAY treat activity that is suspicious as a connection error of type H3_EXCESSIVE_LOAD, but false positives will result in disrupting valid connections and requests. 10.5.1. Limits on Field Section Size A large field section (Section 4.1) can cause an implementation to commit a large amount of state. Header fields that are critical for routing can appear toward the end of a header section, which prevents streaming of the header section to its ultimate destination. This ordering and other reasons, such as ensuring cache correctness, mean that an endpoint likely needs to buffer the entire header section. Since there is no hard limit to the size of a field section, some endpoints could be forced to commit a large amount of available memory for header fields. An endpoint can use the SETTINGS_MAX_FIELD_SECTION_SIZE (Section 4.2.2) setting to advise peers of limits that might apply on the size of field sections. This setting is only advisory, so endpoints MAY choose to send field sections that exceed this limit and risk having the request or response being treated as malformed. This setting is specific to an HTTP/3 connection, so any request or response could encounter a hop with a lower, unknown limit. An intermediary can attempt to avoid this problem by passing on values presented by different peers, but they are not obligated to do so. A server that receives a larger field section than it is willing to handle can send an HTTP 431 (Request Header Fields Too Large) status code ([RFC6585]). A client can discard responses that it cannot process. 10.5.2. CONNECT Issues The CONNECT method can be used to create disproportionate load on a proxy, since stream creation is relatively inexpensive when compared to the creation and maintenance of a TCP connection. Therefore, a proxy that supports CONNECT might be more conservative in the number of simultaneous requests it accepts. A proxy might also maintain some resources for a TCP connection beyond the closing of the stream that carries the CONNECT request, since the outgoing TCP connection remains in the TIME_WAIT state. To account for this, a proxy might delay increasing the QUIC stream limits for some time after a TCP connection terminates. 10.6. Use of Compression Compression can allow an attacker to recover secret data when it is compressed in the same context as data under attacker control. HTTP/3 enables compression of fields (Section 4.2); the following concerns also apply to the use of HTTP compressed content-codings; see Section 8.4.1 of [HTTP]. There are demonstrable attacks on compression that exploit the characteristics of the web (e.g., [BREACH]). The attacker induces multiple requests containing varying plaintext, observing the length of the resulting ciphertext in each, which reveals a shorter length when a guess about the secret is correct. Implementations communicating on a secure channel MUST NOT compress content that includes both confidential and attacker-controlled data unless separate compression contexts are used for each source of data. Compression MUST NOT be used if the source of data cannot be reliably determined. Further considerations regarding the compression of field sections are described in [QPACK]. 10.7. Padding and Traffic Analysis Padding can be used to obscure the exact size of frame content and is provided to mitigate specific attacks within HTTP, for example, attacks where compressed content includes both attacker-controlled plaintext and secret data (e.g., [BREACH]). Where HTTP/2 employs PADDING frames and Padding fields in other frames to make a connection more resistant to traffic analysis, HTTP/3 can either rely on transport-layer padding or employ the reserved frame and stream types discussed in Sections 7.2.8 and 6.2.3. These methods of padding produce different results in terms of the granularity of padding, how padding is arranged in relation to the information that is being protected, whether padding is applied in the case of packet loss, and how an implementation might control padding. Reserved stream types can be used to give the appearance of sending traffic even when the connection is idle. Because HTTP traffic often occurs in bursts, apparent traffic can be used to obscure the timing or duration of such bursts, even to the point of appearing to send a constant stream of data. However, as such traffic is still flow controlled by the receiver, a failure to promptly drain such streams and provide additional flow-control credit can limit the sender's ability to send real traffic. To mitigate attacks that rely on compression, disabling or limiting compression might be preferable to padding as a countermeasure. Use of padding can result in less protection than might seem immediately obvious. Redundant padding could even be counterproductive. At best, padding only makes it more difficult for an attacker to infer length information by increasing the number of frames an attacker has to observe. Incorrectly implemented padding schemes can be easily defeated. In particular, randomized padding with a predictable distribution provides very little protection; similarly, padding payloads to a fixed size exposes information as payload sizes cross the fixed-sized boundary, which could be possible if an attacker can control plaintext. 10.8. Frame Parsing Several protocol elements contain nested length elements, typically in the form of frames with an explicit length containing variable- length integers. This could pose a security risk to an incautious implementer. An implementation MUST ensure that the length of a frame exactly matches the length of the fields it contains. 10.9. Early Data The use of 0-RTT with HTTP/3 creates an exposure to replay attack. The anti-replay mitigations in [HTTP-REPLAY] MUST be applied when using HTTP/3 with 0-RTT. When applying [HTTP-REPLAY] to HTTP/3, references to the TLS layer refer to the handshake performed within QUIC, while all references to application data refer to the contents of streams. 10.10. Migration Certain HTTP implementations use the client address for logging or access-control purposes. Since a QUIC client's address might change during a connection (and future versions might support simultaneous use of multiple addresses), such implementations will need to either actively retrieve the client's current address or addresses when they are relevant or explicitly accept that the original address might change. 10.11. Privacy Considerations Several characteristics of HTTP/3 provide an observer an opportunity to correlate actions of a single client or server over time. These include the value of settings, the timing of reactions to stimulus, and the handling of any features that are controlled by settings. As far as these create observable differences in behavior, they could be used as a basis for fingerprinting a specific client. HTTP/3's preference for using a single QUIC connection allows correlation of a user's activity on a site. Reusing connections for different origins allows for correlation of activity across those origins. Several features of QUIC solicit immediate responses and can be used by an endpoint to measure latency to their peer; this might have privacy implications in certain scenarios. 11. IANA Considerations This document registers a new ALPN protocol ID (Section 11.1) and creates new registries that manage the assignment of code points in HTTP/3. 11.1. Registration of HTTP/3 Identification String This document creates a new registration for the identification of HTTP/3 in the "TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs" registry established in [RFC7301]. The "h3" string identifies HTTP/3: Protocol: HTTP/3 Identification Sequence: 0x68 0x33 ("h3") Specification: This document 11.2. New Registries New registries created in this document operate under the QUIC registration policy documented in Section 22.1 of [QUIC-TRANSPORT]. These registries all include the common set of fields listed in Section 22.1.1 of [QUIC-TRANSPORT]. These registries are collected under the "Hypertext Transfer Protocol version 3 (HTTP/3)" heading. The initial allocations in these registries are all assigned permanent status and list a change controller of the IETF and a contact of the HTTP working group (ietf-http-wg@w3.org). 11.2.1. Frame Types This document establishes a registry for HTTP/3 frame type codes. The "HTTP/3 Frame Types" registry governs a 62-bit space. This registry follows the QUIC registry policy; see Section 11.2. Permanent registrations in this registry are assigned using the Specification Required policy ([RFC8126]), except for values between 0x00 and 0x3f (in hexadecimal; inclusive), which are assigned using Standards Action or IESG Approval as defined in Sections 4.9 and 4.10 of [RFC8126]. While this registry is separate from the "HTTP/2 Frame Type" registry defined in [HTTP/2], it is preferable that the assignments parallel each other where the code spaces overlap. If an entry is present in only one registry, every effort SHOULD be made to avoid assigning the corresponding value to an unrelated operation. Expert reviewers MAY reject unrelated registrations that would conflict with the same value in the corresponding registry. In addition to common fields as described in Section 11.2, permanent registrations in this registry MUST include the following field: Frame Type: A name or label for the frame type. Specifications of frame types MUST include a description of the frame layout and its semantics, including any parts of the frame that are conditionally present. The entries in Table 2 are registered by this document. +==============+=======+===============+ | Frame Type | Value | Specification | +==============+=======+===============+ | DATA | 0x00 | Section 7.2.1 | +--------------+-------+---------------+ | HEADERS | 0x01 | Section 7.2.2 | +--------------+-------+---------------+ | Reserved | 0x02 | This document | +--------------+-------+---------------+ | CANCEL_PUSH | 0x03 | Section 7.2.3 | +--------------+-------+---------------+ | SETTINGS | 0x04 | Section 7.2.4 | +--------------+-------+---------------+ | PUSH_PROMISE | 0x05 | Section 7.2.5 | +--------------+-------+---------------+ | Reserved | 0x06 | This document | +--------------+-------+---------------+ | GOAWAY | 0x07 | Section 7.2.6 | +--------------+-------+---------------+ | Reserved | 0x08 | This document | +--------------+-------+---------------+ | Reserved | 0x09 | This document | +--------------+-------+---------------+ | MAX_PUSH_ID | 0x0d | Section 7.2.7 | The value of the setting unless otherwise indicated. A default SHOULD be the most restrictive possible value. The entries in Table 3 are registered by this document. +========================+=======+=================+===========+ | Setting Name | Value | Specification | Default | +========================+=======+=================+===========+ | Reserved | 0x00 | This document | N/A | +------------------------+-------+-----------------+-----------+ | Reserved | 0x02 | This document | N/A | +------------------------+-------+-----------------+-----------+ | Reserved | 0x03 | This document | N/A | +------------------------+-------+-----------------+-----------+ | Reserved | 0x04 | This document | N/A | +------------------------+-------+-----------------+-----------+ | Reserved | 0x05 | This document | N/A | +------------------------+-------+-----------------+-----------+ | MAX_FIELD_SECTION_SIZE | 0x06 | Section 7.2.4.1 | Unlimited | A brief description of the error code semantics. The entries in Table 4 are registered by this document. These error codes were selected from the range that operates on a Specification Required policy to avoid collisions with HTTP/2 error codes. +===========================+========+==============+===============+ | Name | Value | Description | Specification | +===========================+========+==============+===============+ | H3_NO_ERROR | 0x0100 | No error | Section 8.1 | +---------------------------+--------+--------------+---------------+ | H3_GENERAL_PROTOCOL_ERROR | 0x0101 | General | Section 8.1 | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | protocol | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | error | rfc_9114_http_3 | +---------------------------+--------+--------------+---------------+ | H3_INTERNAL_ERROR | 0x0102 | Internal | Section 8.1 | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | error | rfc_9114_http_3 | +---------------------------+--------+--------------+---------------+ | H3_STREAM_CREATION_ERROR | 0x0103 | Stream | Section 8.1 | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | creation | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | error | rfc_9114_http_3 | +---------------------------+--------+--------------+---------------+ | H3_CLOSED_CRITICAL_STREAM | 0x0104 | Critical | Section 8.1 | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | stream was | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | closed | rfc_9114_http_3 | +---------------------------+--------+--------------+---------------+ | H3_FRAME_UNEXPECTED | 0x0105 | Frame not | Section 8.1 | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | permitted | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | in the | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | current | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | state | rfc_9114_http_3 | +---------------------------+--------+--------------+---------------+ | H3_FRAME_ERROR | 0x0106 | Frame | Section 8.1 | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | violated | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | layout or | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | size rules | rfc_9114_http_3 | +---------------------------+--------+--------------+---------------+ | H3_EXCESSIVE_LOAD | 0x0107 | Peer | Section 8.1 | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | generating | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | excessive | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | load | rfc_9114_http_3 | +---------------------------+--------+--------------+---------------+ | H3_ID_ERROR | 0x0108 | An | Section 8.1 | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | identifier | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | was used | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | incorrectly | rfc_9114_http_3 | +---------------------------+--------+--------------+---------------+ | H3_SETTINGS_ERROR | 0x0109 | SETTINGS | Section 8.1 | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | frame | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | contained | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | invalid | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | values | rfc_9114_http_3 | +---------------------------+--------+--------------+---------------+ | H3_MISSING_SETTINGS | 0x010a | No SETTINGS | Section 8.1 | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | frame | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | received | rfc_9114_http_3 | +---------------------------+--------+--------------+---------------+ | H3_REQUEST_REJECTED | 0x010b | Request not | Section 8.1 | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | processed | rfc_9114_http_3 | +---------------------------+--------+--------------+---------------+ | H3_REQUEST_CANCELLED | 0x010c | Data no | Section 8.1 | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | longer | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | needed | rfc_9114_http_3 | +---------------------------+--------+--------------+---------------+ | H3_REQUEST_INCOMPLETE | 0x010d | Stream | Section 8.1 | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | terminated | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | early | rfc_9114_http_3 | +---------------------------+--------+--------------+---------------+ | H3_MESSAGE_ERROR | 0x010e | Malformed | Section 8.1 | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | message | rfc_9114_http_3 | +---------------------------+--------+--------------+---------------+ | H3_CONNECT_ERROR | 0x010f | TCP reset | Section 8.1 | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | or error on | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | CONNECT | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | request | rfc_9114_http_3 | +---------------------------+--------+--------------+---------------+ | H3_VERSION_FALLBACK | 0x0110 | Retry over | Section 8.1 | rfc_9114_http_3 | rfc_9114_http_3 | rfc_9114_http_3 | HTTP/1.1 | rfc_9114_http_3 | Which endpoint on an HTTP/3 connection may initiate a stream of this type. Values are "Client", "Server", or "Both". Specifications for permanent registrations MUST include a description of the stream type, including the layout and semantics of the stream contents. The entries in Table 5 are registered by this document. +================+=======+===============+========+ | Stream Type | Value | Specification | Sender | +================+=======+===============+========+ | Control Stream | 0x00 | Section 6.2.1 | Both | +----------------+-------+---------------+--------+ | Push Stream | 0x01 | Section 4.6 | Server | [[
+----------------+-------+---------------+--------+
Table 5: Initial Stream Types
Each code of the format 0x1f * N + 0x21 for non-negative integer values of N (that is, 0x21, 0x40, ..., through 0x3ffffffffffffffe) MUST NOT be assigned by IANA and MUST NOT appear in the listing of assigned values.
12. References
12.1. Normative References
[ALTSVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP
Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
April 2016, .
[COOKIES] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011,
.
[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
.
[HTTP-CACHING]
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Caching", STD 98, RFC 9111,
DOI 10.17487/RFC9111, June 2022,
.
[HTTP-REPLAY]
Thomson, M., Nottingham, M., and W. Tarreau, "Using Early
Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September
2018, .
[QPACK] Krasic, C., Bishop, M., and A. Frindell, Ed., "QPACK:
Field Compression for HTTP/3", RFC 9204,
DOI 10.17487/RFC9204, June 2022,
.
[QUIC-TRANSPORT]
Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981,
.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011,
.
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, .
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, .
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
.
12.2. Informative References
[BREACH] Gluck, Y., Harris, N., and A. Prado, "BREACH: Reviving the
CRIME Attack", July 2013,
.
[DNS-TERMS]
Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
January 2019, .
[HPACK] Peon, R. and H. Ruellan, "HPACK: Header Compression for
HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015,
.
[HTTP/1.1] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112,
June 2022, .
[HTTP/2] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,
DOI 10.17487/RFC9113, June 2022,
.
[RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status
Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012,
.
[RFC8164] Nottingham, M. and M. Thomson, "Opportunistic Security for
HTTP/2", RFC 8164, DOI 10.17487/RFC8164, May 2017,
.
[TFO] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
.
[TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
.
Appendix A. Considerations for Transitioning from HTTP/2
HTTP/3 is strongly informed by HTTP/2, and it bears many similarities. This section describes the approach taken to design HTTP/3, points out important differences from HTTP/2, and describes how to map HTTP/2 extensions into HTTP/3.
HTTP/3 begins from the premise that similarity to HTTP/2 is preferable, but not a hard requirement. HTTP/3 departs from HTTP/2 where QUIC differs from TCP, either to take advantage of QUIC features (like streams) or to accommodate important shortcomings (such as a lack of total ordering). While HTTP/3 is similar to HTTP/2 in key aspects, such as the relationship of requests and responses to streams, the details of the HTTP/3 design are substantially different from HTTP/2.
Some important departures are noted in this section.
A.1. Streams
HTTP/3 permits use of a larger number of streams (2^62-1) than HTTP/2. The same considerations about exhaustion of stream identifier space apply, though the space is significantly larger such that it is likely that other limits in QUIC are reached first, such as the limit on the connection flow-control window.
In contrast to HTTP/2, stream concurrency in HTTP/3 is managed by QUIC. QUIC considers a stream closed when all data has been received and sent data has been acknowledged by the peer. HTTP/2 considers a stream closed when the frame containing the END_STREAM bit has been committed to the transport. As a result, the stream for an equivalent exchange could remain "active" for a longer period of time. HTTP/3 servers might choose to permit a larger number of concurrent client-initiated bidirectional streams to achieve equivalent concurrency to HTTP/2, depending on the expected usage patterns.
In HTTP/2, only request and response bodies (the frame payload of DATA frames) are subject to flow control. All HTTP/3 frames are sent on QUIC streams, so all frames on all streams are flow controlled in HTTP/3.
Due to the presence of other unidirectional stream types, HTTP/3 does not rely exclusively on the number of concurrent unidirectional streams to control the number of concurrent in-flight pushes. Instead, HTTP/3 clients use the MAX_PUSH_ID frame to control the number of pushes received from an HTTP/3 server.
A.2. HTTP Frame Types
Many framing concepts from HTTP/2 can be elided on QUIC, because the 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. This permits the removal of the Flags field from the generic frame layout.
Frame payloads are largely drawn from [HTTP/2]. However, QUIC includes many features (e.g., flow control) that are also present in HTTP/2. In these cases, the HTTP mapping does not re-implement them. As a result, several HTTP/2 frame types are not required in HTTP/3. Where an HTTP/2-defined frame is no longer used, the frame ID has been reserved in order to maximize portability between HTTP/2 and HTTP/3 implementations. However, even frame types that appear in both mappings do not have identical semantics.
Many of the differences arise from the fact that HTTP/2 provides an absolute ordering between frames across all streams, while QUIC provides this guarantee on each stream only. As a result, if a frame type makes assumptions that frames from different streams will still be received in the order sent, HTTP/3 will break them.
Some examples of feature adaptations are described below, as well as general guidance to extension frame implementors converting an HTTP/2 extension to HTTP/3.
A.2.1. Prioritization Differences
HTTP/2 specifies priority assignments in PRIORITY frames and (optionally) in HEADERS frames. HTTP/3 does not provide a means of signaling priority.
Note that, while there is no explicit signaling for priority, this does not mean that prioritization is not important for achieving good performance.
A.2.2. Field Compression Differences
HPACK was designed with the assumption of in-order delivery. A sequence of encoded field sections must arrive (and be decoded) at an endpoint in the same order in which they were encoded. This ensures that the dynamic state at the two endpoints remains in sync.
Because this total ordering is not provided by QUIC, HTTP/3 uses a modified version of HPACK, called QPACK. QPACK uses a single unidirectional stream to make all modifications to the dynamic table, ensuring a total order of updates. All frames that contain encoded fields merely reference the table state at a given time without modifying it.
[QPACK] provides additional details.
A.2.3. Flow-Control Differences
HTTP/2 specifies a stream flow-control mechanism. Although all HTTP/2 frames are delivered on streams, only the DATA frame payload is subject to flow control. QUIC provides flow control for stream data and all HTTP/3 frame types defined in this document are sent on streams. Therefore, all frame headers and payload are subject to flow control.
A.2.4. Guidance for New Frame Type Definitions
Frame type definitions in HTTP/3 often use the QUIC variable-length integer encoding. In particular, stream IDs use this encoding, which allows for a larger range of possible values than the encoding used in HTTP/2. Some frames in HTTP/3 use an identifier other than a stream ID (e.g., push IDs). Redefinition of the encoding of extension frame types might be necessary if the encoding includes a stream ID.
Because the Flags field is not present in generic HTTP/3 frames, those frames that 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 a control stream in HTTP/3. HTTP/3 extensions will not assume ordering, but would not be harmed by ordering, and are expected to be portable to HTTP/2.
A.2.5. Comparison of HTTP/2 and HTTP/3 Frame Types
DATA (0x00): Padding is not defined in HTTP/3 frames. See
Section 7.2.1.
HEADERS (0x01): The PRIORITY region of HEADERS is not defined in
HTTP/3 frames. Padding is not defined in HTTP/3 frames. See
Section 7.2.2.
PRIORITY (0x02): As described in Appendix A.2.1, HTTP/3 does not
provide a means of signaling priority.
RST_STREAM (0x03): RST_STREAM frames do not exist in HTTP/3, since
QUIC provides stream lifecycle management. The same code point is
used for the CANCEL_PUSH frame (Section 7.2.3).
SETTINGS (0x04): SETTINGS frames are sent only at the beginning of
the connection. See Section 7.2.4 and Appendix A.3.
PUSH_PROMISE (0x05): The PUSH_PROMISE frame does not reference a
stream; instead, the push stream references the PUSH_PROMISE frame
using a push ID. See Section 7.2.5.
PING (0x06): PING frames do not exist in HTTP/3, as QUIC provides
equivalent functionality.
GOAWAY (0x07): GOAWAY does not contain an error code. In the
client-to-server direction, it carries a push ID instead of a
server-initiated stream ID. See Section 7.2.6.
WINDOW_UPDATE (0x08): WINDOW_UPDATE frames do not exist in HTTP/3,
since QUIC provides flow control.
CONTINUATION (0x09): CONTINUATION frames do not exist in HTTP/3;
instead, larger HEADERS/PUSH_PROMISE frames than HTTP/2 are
permitted.
Frame types defined by extensions to HTTP/2 need to be separately registered for HTTP/3 if still applicable. The IDs of frames defined in [HTTP/2] have been reserved for simplicity. Note that the frame type space in HTTP/3 is substantially larger (62 bits versus 8 bits), so many HTTP/3 frame types have no equivalent HTTP/2 code points. See Section 11.2.1.
A.3. HTTP/2 SETTINGS Parameters
An important difference from HTTP/2 is that settings are sent once, as the first frame of the control stream, and thereafter cannot change. This eliminates many corner cases around synchronization of changes.
Some transport-level options that HTTP/2 specifies via the SETTINGS frame are superseded by QUIC transport parameters in HTTP/3. The HTTP-level setting that is retained in HTTP/3 has the same value as in HTTP/2. The superseded settings are reserved, and their receipt is an error. See Section 7.2.4.1 for discussion of both the retained and reserved values.
Below is a listing of how each HTTP/2 SETTINGS parameter is mapped:
SETTINGS_HEADER_TABLE_SIZE (0x01): See [QPACK].
SETTINGS_ENABLE_PUSH (0x02): This is removed in favor of the
MAX_PUSH_ID frame, which provides a more granular control over
server push. Specifying a setting with the identifier 0x02
(corresponding to the SETTINGS_ENABLE_PUSH parameter) in the
HTTP/3 SETTINGS frame is an error.
SETTINGS_MAX_CONCURRENT_STREAMS (0x03): QUIC controls the largest
open stream ID as part of its flow-control logic. Specifying a
setting with the identifier 0x03 (corresponding to the
SETTINGS_MAX_CONCURRENT_STREAMS parameter) in the HTTP/3 SETTINGS
frame is an error.
SETTINGS_INITIAL_WINDOW_SIZE (0x04): QUIC requires both stream and
connection flow-control window sizes to be specified in the
initial transport handshake. Specifying a setting with the
identifier 0x04 (corresponding to the SETTINGS_INITIAL_WINDOW_SIZE
parameter) in the HTTP/3 SETTINGS frame is an error.
SETTINGS_MAX_FRAME_SIZE (0x05): This setting has no equivalent in
HTTP/3. Specifying a setting with the identifier 0x05
(corresponding to the SETTINGS_MAX_FRAME_SIZE parameter) in the
HTTP/3 SETTINGS frame is an error.
SETTINGS_MAX_HEADER_LIST_SIZE (0x06): This setting identifier has
been renamed SETTINGS_MAX_FIELD_SECTION_SIZE.
In HTTP/3, setting values are variable-length integers (6, 14, 30, or 62 bits long) rather than fixed-length 32-bit fields as in HTTP/2. This will often produce a shorter encoding, but can produce a longer encoding for settings that use the full 32-bit space. Settings ported from HTTP/2 might choose to redefine their value to limit it to 30 bits for more efficient encoding or to make use of the 62-bit space if more than 30 bits are required.
Settings need to be defined separately for HTTP/2 and HTTP/3. The IDs of settings defined in [HTTP/2] have been reserved for simplicity. Note that the settings identifier space in HTTP/3 is substantially larger (62 bits versus 16 bits), so many HTTP/3 settings have no equivalent HTTP/2 code point. See Section 11.2.2.
As QUIC streams might arrive out of order, endpoints are advised not to wait for the peers' settings to arrive before responding to other streams. See Section 7.2.4.2.
A.4. HTTP/2 Error Codes
QUIC has the same concepts of "stream" and "connection" errors that HTTP/2 provides. However, the differences between HTTP/2 and HTTP/3 mean that error codes are not directly portable between versions.
The HTTP/2 error codes defined in Section 7 of [HTTP/2] logically map to the HTTP/3 error codes as follows:
NO_ERROR (0x00): H3_NO_ERROR in Section 8.1.
PROTOCOL_ERROR (0x01): This is mapped to H3_GENERAL_PROTOCOL_ERROR
except in cases where more specific error codes have been defined.
Such cases include H3_FRAME_UNEXPECTED, H3_MESSAGE_ERROR, and
H3_CLOSED_CRITICAL_STREAM defined in Section 8.1.
INTERNAL_ERROR (0x02): H3_INTERNAL_ERROR in Section 8.1.
FLOW_CONTROL_ERROR (0x03): Not applicable, since QUIC handles flow
control.
SETTINGS_TIMEOUT (0x04): Not applicable, since no acknowledgment of
SETTINGS is defined.
STREAM_CLOSED (0x05): Not applicable, since QUIC handles stream
management.
FRAME_SIZE_ERROR (0x06): H3_FRAME_ERROR error code defined in
Section 8.1.
REFUSED_STREAM (0x07): H3_REQUEST_REJECTED (in Section 8.1) is used
to indicate that a request was not processed. Otherwise, not
applicable because QUIC handles stream management.
CANCEL (0x08): H3_REQUEST_CANCELLED in Section 8.1.
COMPRESSION_ERROR (0x09): Multiple error codes are defined in
[QPACK].
CONNECT_ERROR (0x0a): H3_CONNECT_ERROR in Section 8.1.
ENHANCE_YOUR_CALM (0x0b): H3_EXCESSIVE_LOAD in Section 8.1.
INADEQUATE_SECURITY (0x0c): Not applicable, since QUIC is assumed to
provide sufficient security on all connections.
HTTP_1_1_REQUIRED (0x0d): H3_VERSION_FALLBACK in Section 8.1.
Error codes need to be defined for HTTP/2 and HTTP/3 separately. See Section 11.2.3.
A.4.1. Mapping between HTTP/2 and HTTP/3 Errors
An intermediary that converts between HTTP/2 and HTTP/3 may encounter error conditions from either upstream. It is useful to communicate the occurrence of errors to the downstream, but error codes largely reflect connection-local problems that generally do not make sense to propagate.
An intermediary that encounters an error from an upstream origin can indicate this by sending an HTTP status code such as 502 (Bad Gateway), which is suitable for a broad class of errors.
There are some rare cases where it is beneficial to propagate the error by mapping it to the closest matching error type to the receiver. For example, an intermediary that receives an HTTP/2 stream error of type REFUSED_STREAM from the origin has a clear signal that the request was not processed and that the request is safe to retry. Propagating this error condition to the client as an HTTP/3 stream error of type H3_REQUEST_REJECTED allows the client to take the action it deems most appropriate. In the reverse direction, the intermediary might deem it beneficial to pass on client request cancellations that are indicated by terminating a stream with H3_REQUEST_CANCELLED; see Section 4.1.1.
Conversion between errors is described in the logical mapping. The error codes are defined in non-overlapping spaces in order to protect against accidental conversion that could result in the use of inappropriate or unknown error codes for the target version. An intermediary is permitted to promote stream errors to connection errors but they should be aware of the cost to the HTTP/3 connection for what might be a temporary or intermittent error.
Acknowledgments
Robbie Shade and Mike Warres were the authors of draft-shade-quic- http2-mapping, a precursor of this document.
The IETF QUIC Working Group received an enormous amount of support from many people. Among others, the following people provided substantial contributions to this document:
* Bence Beky * Daan De Meyer * Martin Duke * Roy Fielding * Alan Frindell * Alessandro Ghedini * Nick Harper * Ryan Hamilton * Christian Huitema * Subodh Iyengar * Robin Marx * Patrick McManus * Luca Niccolini * 奥 一穂 (Kazuho Oku) * Lucas Pardue * Roberto Peon * Julian Reschke * Eric Rescorla * Martin Seemann * Ben Schwartz * Ian Swett * Willy Taureau * Martin Thomson * Dmitri Tikhonov * Tatsuhiro Tsujikawa
A portion of Mike Bishop's contribution was supported by Microsoft during his employment there.
Index
C D G H M P R S
C
CANCEL_PUSH Section 2, Paragraph 5; Section 4.6, Paragraph 6;
Section 4.6, Paragraph 10; Table 1; *_Section 7.2.3_*;
Section 7.2.5, Paragraph 4.2.1; Section 7.2.7, Paragraph 1;
Table 2; Appendix A.2.5, Paragraph 1.8.1
connection error Section 2.2; Section 4.1, Paragraph 7;
Section 4.1, Paragraph 8; Section 4.4, Paragraph 8;
Section 4.4, Paragraph 10; Section 4.6, Paragraph 3;
Section 5.2, Paragraph 7; Section 6.1, Paragraph 3;
Section 6.2, Paragraph 7; Section 6.2.1, Paragraph 2;
Section 6.2.1, Paragraph 2; Section 6.2.1, Paragraph 2;
Section 6.2.2, Paragraph 3; Section 6.2.2, Paragraph 6;
Section 7.1, Paragraph 5; Section 7.1, Paragraph 6;
Section 7.2.1, Paragraph 2; Section 7.2.2, Paragraph 3;
Section 7.2.3, Paragraph 5; Section 7.2.3, Paragraph 7;
Section 7.2.3, Paragraph 8; Section 7.2.4, Paragraph 2;
Section 7.2.4, Paragraph 3; Section 7.2.4, Paragraph 6;
Section 7.2.4.1, Paragraph 5; Section 7.2.4.2, Paragraph 8;
Section 7.2.4.2, Paragraph 8; Section 7.2.5, Paragraph 5;
Section 7.2.5, Paragraph 6; Section 7.2.5, Paragraph 8;
Section 7.2.5, Paragraph 9; Section 7.2.6, Paragraph 3;
Section 7.2.6, Paragraph 5; Section 7.2.7, Paragraph 2;
Section 7.2.7, Paragraph 3; Section 7.2.7, Paragraph 6;
Section 7.2.8, Paragraph 3; *_Section 8_*; Section 10.5,
Paragraph 7; Appendix A.4.1, Paragraph 4
control stream Section 2, Paragraph 3; Section 3.2, Paragraph
4; Section 6.2, Paragraph 3; Section 6.2, Paragraph 5;
Section 6.2, Paragraph 6; *_Section 6.2.1_*; Section 7,
Paragraph 1; Section 7.2.1, Paragraph 2; Section 7.2.2,
Paragraph 3; Section 7.2.3, Paragraph 5; Section 7.2.3,
Paragraph 5; Section 7.2.4, Paragraph 2; Section 7.2.4,
Paragraph 2; Section 7.2.4, Paragraph 3; Section 7.2.5,
Paragraph 8; Section 7.2.6, Paragraph 3; Section 7.2.6,
Paragraph 5; Section 7.2.7, Paragraph 2; Section 8.1,
Paragraph 2.22.1; Section 9, Paragraph 4; Appendix A.2.4,
Paragraph 3; Appendix A.3, Paragraph 1
D
DATA Section 2, Paragraph 3; Section 4.1, Paragraph 5, Item 2;
Section 4.1, Paragraph 7; Section 4.1, Paragraph 7;
Section 4.1.2, Paragraph 3; Section 4.1.2, Paragraph 3;
Section 4.4, Paragraph 7; Section 4.4, Paragraph 7;
Section 4.4, Paragraph 7; Section 4.4, Paragraph 7;
Section 4.4, Paragraph 8; Section 4.6, Paragraph 12;
Table 1; *_Section 7.2.1_*; Table 2; Appendix A.1, Paragraph
3; Appendix A.2.3, Paragraph 1; Appendix A.2.5
G
GOAWAY Section 3.3, Paragraph 5; Section 5.2, Paragraph 1;
Section 5.2, Paragraph 1; Section 5.2, Paragraph 1;
Section 5.2, Paragraph 2; Section 5.2, Paragraph 2;
Section 5.2, Paragraph 3; Section 5.2, Paragraph 5.1.1;
Section 5.2, Paragraph 5.1.1; Section 5.2, Paragraph 5.1.2;
Section 5.2, Paragraph 5.1.2; Section 5.2, Paragraph 5, Item
2; Section 5.2, Paragraph 5, Item 2; Section 5.2, Paragraph
6; Section 5.2, Paragraph 6; Section 5.2, Paragraph 7;
Section 5.2, Paragraph 7; Section 5.2, Paragraph 8;
Section 5.2, Paragraph 8; Section 5.2, Paragraph 9;
Section 5.2, Paragraph 9; Section 5.2, Paragraph 10;
Section 5.2, Paragraph 12; Section 5.3, Paragraph 2;
Section 5.3, Paragraph 2; Section 5.4, Paragraph 2; Table 1;
*_Section 7.2.6_*; Table 2; Appendix A.2.5; Appendix A.2.5,
Paragraph 1.16.1
H
H3_CLOSED_CRITICAL_STREAM Section 6.2.1, Paragraph 2;
Section 8.1; Table 4; Appendix A.4, Paragraph 3.4.1
H3_CONNECT_ERROR Section 4.4, Paragraph 10; Section 8.1;
Table 4; Appendix A.4, Paragraph 3.22.1
H3_EXCESSIVE_LOAD Section 8.1; Section 10.5, Paragraph 7;
Table 4; Appendix A.4, Paragraph 3.24.1
H3_FRAME_ERROR Section 7.1, Paragraph 5; Section 7.1,
Paragraph 6; Section 8.1; Table 4; Appendix A.4, Paragraph
3.14.1
H3_FRAME_UNEXPECTED Section 4.1, Paragraph 7; Section 4.1,
Paragraph 8; Section 4.4, Paragraph 8; Section 7.2.1,
Paragraph 2; Section 7.2.2, Paragraph 3; Section 7.2.3,
Paragraph 5; Section 7.2.4, Paragraph 2; Section 7.2.4,
Paragraph 3; Section 7.2.5, Paragraph 8; Section 7.2.5,
Paragraph 9; Section 7.2.6, Paragraph 5; Section 7.2.7,
Paragraph 2; Section 7.2.7, Paragraph 3; Section 7.2.8,
Paragraph 3; Section 8.1; Table 4; Appendix A.4, Paragraph
3.4.1
H3_GENERAL_PROTOCOL_ERROR Section 7.2.5, Paragraph 6;
Section 8.1; Table 4; Appendix A.4, Paragraph 3.4.1
H3_ID_ERROR Section 4.6, Paragraph 3; Section 5.2, Paragraph
7; Section 6.2.2, Paragraph 6; Section 7.2.3, Paragraph 7;
Section 7.2.3, Paragraph 8; Section 7.2.5, Paragraph 5;
Section 7.2.6, Paragraph 3; Section 7.2.7, Paragraph 6;
Section 8.1; Table 4
H3_INTERNAL_ERROR Section 8.1; Table 4; Appendix A.4,
Paragraph 3.6.1
H3_MESSAGE_ERROR Section 4.1.2, Paragraph 4; Section 8.1;
Table 4; Appendix A.4, Paragraph 3.4.1
H3_MISSING_SETTINGS Section 6.2.1, Paragraph 2; Section 8.1;
Table 4
H3_NO_ERROR Section 4.1, Paragraph 15; Section 5.2, Paragraph
11; Section 6.2.3, Paragraph 2; Section 8, Paragraph 5;
Section 8.1; Section 8.1, Paragraph 3; Section 8.1,
Paragraph 3; Table 4; Appendix A.4, Paragraph 3.2.1
H3_REQUEST_CANCELLED Section 4.1.1, Paragraph 4;
Section 4.1.1, Paragraph 5; Section 4.6, Paragraph 14;
Section 7.2.3, Paragraph 3; Section 7.2.3, Paragraph 4;
Section 8.1; Table 4; Appendix A.4, Paragraph 3.18.1;
Appendix A.4.1, Paragraph 3
H3_REQUEST_INCOMPLETE Section 4.1, Paragraph 14; Section 8.1;
Table 4
H3_REQUEST_REJECTED Section 4.1.1, Paragraph 3; Section 4.1.1,
Paragraph 4; Section 4.1.1, Paragraph 5; Section 4.1.1,
Paragraph 5; Section 8.1; Table 4; Appendix A.4, Paragraph
3.16.1; Appendix A.4.1, Paragraph 3
H3_SETTINGS_ERROR Section 7.2.4, Paragraph 6; Section 7.2.4.1,
Paragraph 5; Section 7.2.4.2, Paragraph 8; Section 7.2.4.2,
Paragraph 8; Section 8.1; Table 4
H3_STREAM_CREATION_ERROR Section 6.1, Paragraph 3;
Section 6.2, Paragraph 7; Section 6.2.1, Paragraph 2;
Section 6.2.2, Paragraph 3; Section 8.1; Table 4
H3_VERSION_FALLBACK Section 8.1; Table 4; Appendix A.4,
Paragraph 3.28.1
HEADERS Section 2, Paragraph 3; Section 4.1, Paragraph 5, Item
1; Section 4.1, Paragraph 5, Item 3; Section 4.1, Paragraph
7; Section 4.1, Paragraph 7; Section 4.1, Paragraph 7;
Section 4.1, Paragraph 10; Section 4.4, Paragraph 6;
Section 4.6, Paragraph 12; Table 1; *_Section 7.2.2_*;
Section 9, Paragraph 5; Table 2; Appendix A.2.1, Paragraph
1; Appendix A.2.5; Appendix A.2.5, Paragraph 1.4.1;
Appendix A.2.5, Paragraph 1.20.1
M
malformed Section 4.1, Paragraph 3; *_Section 4.1.2_*;
Section 4.2, Paragraph 2; Section 4.2, Paragraph 3;
Section 4.2, Paragraph 5; Section 4.3, Paragraph 3;
Section 4.3, Paragraph 4; Section 4.3.1, Paragraph 5;
Section 4.3.2, Paragraph 1; Section 4.4, Paragraph 5;
Section 8.1, Paragraph 2.30.1; Section 10.3, Paragraph 1;
Section 10.3, Paragraph 2; Section 10.5.1, Paragraph 2
MAX_PUSH_ID Section 2, Paragraph 5; Section 4.6, Paragraph 3;
Section 4.6, Paragraph 3; Section 4.6, Paragraph 3;
Section 4.6, Paragraph 3; Table 1; Section 7.2.5, Paragraph
5; *_Section 7.2.7_*; Table 2; Appendix A.1, Paragraph 4;
Appendix A.3, Paragraph 4.4.1
P
push ID *_Section 4.6_*; Section 5.2, Paragraph 1;
Section 5.2, Paragraph 5, Item 2; Section 5.2, Paragraph 9;
Section 6.2.2, Paragraph 2; Section 6.2.2, Paragraph 6;
Section 6.2.2, Paragraph 6; Section 7.2.3, Paragraph 1;
Section 7.2.3, Paragraph 7; Section 7.2.3, Paragraph 7;
Section 7.2.3, Paragraph 8; Section 7.2.3, Paragraph 8;
Section 7.2.5, Paragraph 4.2.1; Section 7.2.5, Paragraph 5;
Section 7.2.5, Paragraph 5; Section 7.2.5, Paragraph 6;
Section 7.2.5, Paragraph 6; Section 7.2.5, Paragraph 7;
Section 7.2.5, Paragraph 7; Section 7.2.5, Paragraph 7;
Section 7.2.6, Paragraph 4; Section 7.2.7, Paragraph 1;
Section 7.2.7, Paragraph 4; Section 7.2.7, Paragraph 4;
Section 7.2.7, Paragraph 6; Section 7.2.7, Paragraph 6;
Section 8.1, Paragraph 2.18.1; Appendix A.2.5, Paragraph
1.12.1; Appendix A.2.5, Paragraph 1.16.1
push stream Section 4.1, Paragraph 8; Section 4.1, Paragraph
9; Section 4.6, Paragraph 3; Section 4.6, Paragraph 5;
Section 4.6, Paragraph 5; Section 4.6, Paragraph 13;
Section 4.6, Paragraph 13; Section 4.6, Paragraph 13;
Section 6.2, Paragraph 3; *_Section 6.2.2_*; Section 7,
Paragraph 1; Section 7.2.2, Paragraph 3; Section 7.2.3,
Paragraph 1; Section 7.2.3, Paragraph 2; Section 7.2.3,
Paragraph 2; Section 7.2.3, Paragraph 2; Section 7.2.3,
Paragraph 2; Section 7.2.3, Paragraph 3; Section 7.2.3,
Paragraph 4; Section 7.2.3, Paragraph 4; Section 7.2.3,
Paragraph 4; Section 7.2.5, Paragraph 4.2.1; Section 7.2.7,
Paragraph 1; Appendix A.2.5, Paragraph 1.12.1
PUSH_PROMISE Section 2, Paragraph 5; Section 4.1, Paragraph 8;
Section 4.1, Paragraph 8; Section 4.1, Paragraph 8;
Section 4.1, Paragraph 8; Section 4.1, Paragraph 10;
Section 4.6, Paragraph 4; Section 4.6, Paragraph 10;
Section 4.6, Paragraph 11; Section 4.6, Paragraph 11;
Section 4.6, Paragraph 12; Section 4.6, Paragraph 12;
Section 4.6, Paragraph 13; Section 4.6, Paragraph 13;
Section 4.6, Paragraph 13; Table 1; Section 7.2.3, Paragraph
8; Section 7.2.3, Paragraph 8; *_Section 7.2.5_*;
Section 7.2.7, Paragraph 1; Section 10.4, Paragraph 1;
Section 10.5, Paragraph 2; Table 2; Appendix A.2.5;
Appendix A.2.5, Paragraph 1.12.1; Appendix A.2.5, Paragraph
1.12.1; Appendix A.2.5, Paragraph 1.20.1
R
request stream Section 4.1, Paragraph 1; Section 4.1,
Paragraph 15; Section 4.1, Paragraph 15; Section 4.1.1,
Paragraph 1; Section 4.1.1, Paragraph 5; Section 4.4,
Paragraph 5; Section 4.4, Paragraph 9; Section 4.6,
Paragraph 4; Section 4.6, Paragraph 4; Section 4.6,
Paragraph 11; Section 4.6, Paragraph 11; *_Section 6.1_*;
Section 7, Paragraph 1; Section 7.2.2, Paragraph 3;
Section 7.2.5, Paragraph 1
S
SETTINGS Section 3.2, Paragraph 4; Section 3.2, Paragraph 4;
Section 6.2.1, Paragraph 2; Table 1; Section 7, Paragraph 3;
*_Section 7.2.4_*; Section 8.1, Paragraph 2.20.1;
Section 8.1, Paragraph 2.22.1; Section 9, Paragraph 4;
Section 10.5, Paragraph 4; Table 2; Table 4; Table 4;
Appendix A.2.5; Appendix A.2.5, Paragraph 1.10.1;
Appendix A.3, Paragraph 2; Appendix A.3, Paragraph 3;
Appendix A.3, Paragraph 4.4.1; Appendix A.3, Paragraph
4.6.1; Appendix A.3, Paragraph 4.8.1; Appendix A.3,
Paragraph 4.10.1; Appendix A.4, Paragraph 3.10.1
SETTINGS_MAX_FIELD_SECTION_SIZE Section 4.2.2, Paragraph 2;
Section 7.2.4.1; Section 10.5.1, Paragraph 2; Appendix A.3,
Paragraph 4.12.1
stream error Section 2.2; Section 4.1.2, Paragraph 4;
Section 4.4, Paragraph 10; *_Section 8_*; Appendix A.4.1,
Paragraph 3; Appendix A.4.1, Paragraph 3; Appendix A.4.1,
Paragraph 4
Author's Address
Mike Bishop (editor) Akamai Email: mbishop@evequefou.be
HTTP Protocol, HTTP Request, HTTP Response, HTTP Client, HTTP Server, HTTP Message, HTTP Header, HTTP Body, HTTP Method, HTTP Status Code, HTTP Version, HTTP URL, HTTP Uniform Resource Identifier (URI), HTTP Hypertext Transfer Protocol, HTTP Secure (HTTPS), HTTP TLS (Transport Layer Security), HTTP SSL (Secure Sockets Layer), HTTP Session, HTTP Persistent Connection, HTTP Keep-Alive, HTTP Pipeline, HTTP Chunked Transfer Encoding, HTTP Caching, HTTP Cache-Control Header, HTTP ETag Header, HTTP If-None-Match Header, HTTP If-Modified-Since Header, HTTP Last-Modified Header, HTTP Expires Header, HTTP Conditional Requests, HTTP Range Request, HTTP Content Negotiation, HTTP Accept Header, HTTP Accept-Language Header, HTTP Accept-Encoding Header, HTTP Content-Type Header, HTTP Content-Length Header, HTTP Content-Encoding Header, HTTP Content-Language Header, HTTP Content-Range Header, HTTP Transfer-Encoding Header, HTTP Chunked Encoding, HTTP Gzip Encoding, HTTP Deflate Encoding, HTTP Brotli Encoding, HTTP TE Header, HTTP Connection Header, HTTP Host Header, HTTP User-Agent Header, HTTP Referer Header, HTTP Origin Header, HTTP Authorization Header, HTTP WWW-Authenticate Header, HTTP Proxy-Authenticate Header, HTTP Proxy-Authorization Header, HTTP Cookie Header, HTTP Set-Cookie Header, HTTP Cookie-based Authentication, HTTP Basic Authentication, HTTP Digest Authentication, HTTP Bearer Token Authentication, HTTP SPNEGO Authentication, HTTP NTLM Authentication, HTTP Request Line, HTTP Status Line, HTTP Start Line, HTTP General Headers, HTTP Request Headers, HTTP Response Headers, HTTP Entity Headers, HTTP Hop-by-hop Headers, HTTP End-to-end Headers, HTTP Trailer Headers, HTTP Upgrade Header, HTTP ALPN (Application-Layer Protocol Negotiation), HTTP GET Method, HTTP POST Method, HTTP PUT Method, HTTP DELETE Method, HTTP HEAD Method, HTTP OPTIONS Method, HTTP TRACE Method, HTTP CONNECT Method, HTTP PATCH Method, HTTP Safe Methods, HTTP Idempotent Methods, HTTP Cacheable Methods, HTTP Status Code 200 OK, HTTP Status Code 201 Created, HTTP Status Code 202 Accepted, HTTP Status Code 204 No Content, HTTP Status Code 301 Moved Permanently, HTTP Status Code 302 Found, HTTP Status Code 303 See Other, HTTP Status Code 304 Not Modified, HTTP Status Code 307 Temporary Redirect, HTTP Status Code 308 Permanent Redirect, HTTP Status Code 400 Bad Request, HTTP Status Code 401 Unauthorized, HTTP Status Code 403 Forbidden, HTTP Status Code 404 Not Found, HTTP Status Code 405 Method Not Allowed, HTTP Status Code 406 Not Acceptable, HTTP Status Code 409 Conflict, HTTP Status Code 410 Gone, HTTP Status Code 415 Unsupported Media Type, HTTP Status Code 429 Too Many Requests, HTTP Status Code 500 Internal Server Error, HTTP Status Code 501 Not Implemented, HTTP Status Code 502 Bad Gateway, HTTP Status Code 503 Service Unavailable, HTTP Status Code 504 Gateway Timeout, HTTP Status Code 505 HTTP Version Not Supported, HTTP Informational Responses (1xx), HTTP Successful Responses (2xx), HTTP Redirection Messages (3xx), HTTP Client Error Responses (4xx), HTTP Server Error Responses (5xx), HTTP RFC 7230 (Message Syntax and Routing), HTTP RFC 7231 (Semantics and Content), HTTP RFC 7232 (Conditional Requests), HTTP RFC 7233 (Range Requests), HTTP RFC 7234 (Caching), HTTP RFC 7235 (Authentication), HTTP RFC 9110 (HTTP Semantics), HTTP RFC 9111 (Caching), HTTP RFC 9112 (HTTP/1.1), HTTP RFC 9113 (HTTP/2), HTTP RFC 9114 (HTTP/3), HTTP/0.9 Version, HTTP/1.0 Version, HTTP/1.1 Version, HTTP/2 Protocol, HTTP/3 Protocol, HTTP QUIC Transport, HTTP HEADERS Frame (HTTP/2), HTTP SETTINGS Frame (HTTP/2), HTTP GOAWAY Frame (HTTP/2), HTTP RST_STREAM Frame (HTTP/2), HTTP WINDOW_UPDATE Frame (HTTP/2), HTTP DATA Frame (HTTP/2), HTTP PRIORITY Frame (HTTP/2), HTTP PUSH_PROMISE Frame (HTTP/2), HTTP HPACK (Header Compression for HTTP/2), HTTP Huffman Encoding (HPACK), HTTP Indexing Tables (HPACK), HTTP Dynamic Table (HPACK), HTTP QPACK (HTTP/3 Header Compression), HTTP Multiplexing (HTTP/2), HTTP Stream Identifiers (HTTP/2), HTTP Connection Preface (HTTP/2), HTTP ALPN Extension, HTTP Upgrade Mechanism, HTTP OPTIONS * Request, HTTP no-store Directive, HTTP no-cache Directive, HTTP must-revalidate Directive, HTTP proxy-revalidate Directive, HTTP private Directive, HTTP public Directive, HTTP s-maxage Directive, HTTP stale-while-revalidate Directive, HTTP stale-if-error Directive, HTTP Expect Header, HTTP Content-Disposition Header, HTTP Content-Location Header, HTTP Content-MD5 Header, HTTP Content-Security-Policy Header, HTTP Strict-Transport-Security Header, HTTP X-Frame-Options Header, HTTP X-XSS-Protection Header, HTTP Referrer-Policy Header, HTTP Feature-Policy Header, HTTP Permissions-Policy Header, HTTP X-Content-Type-Options Header, HTTP Accept-Patch Header, HTTP Accept-Post Header, HTTP Retry-After Header, HTTP Warning Header, HTTP Date Header, HTTP Server Header, HTTP Allow Header, HTTP Vary Header, HTTP Accept-Ranges Header, HTTP Forwarded Header, HTTP Max-Forwards Header, HTTP Upgrade-Insecure-Requests Header, HTTP Server-Timing Header, HTTP Large-Allocation Header, HTTP Expect-CT Header, HTTP Public-Key-Pins Header, HTTP Public-Key-Pins-Report-Only Header, HTTP Alt-Svc Header, HTTP Early-Data Header, HTTP Service-Worker-Allowed Header, HTTP Clear-Site-Data Header, HTTP Pragma Header, HTTP Proxy-Connection Header, HTTP X-Content-Duration Header, HTTP X-Forwarded-For Header, HTTP X-Forwarded-Host Header, HTTP X-Forwarded-Proto Header, HTTP Front-End-Https Header, HTTP Save-Data Header, HTTP Link Header, HTTP Access-Control-Allow-Origin Header, HTTP Access-Control-Allow-Methods Header, HTTP Access-Control-Allow-Headers Header, HTTP Access-Control-Max-Age Header, HTTP Access-Control-Allow-Credentials Header, HTTP Access-Control-Expose-Headers Header, HTTP Access-Control-Request-Method Header, HTTP Access-Control-Request-Headers Header, HTTP DNT (Do Not Track) Header, HTTP Tk Header (Tracking Status), HTTP Accept-CH Header (Client Hints), HTTP Device-Memory Header (Client Hint), HTTP Viewport-Width Header (Client Hint), HTTP Width Header (Client Hint), HTTP Downlink Header (Client Hint), HTTP Status Code 408 Request Timeout, HTTP Status Code 411 Length Required, HTTP Status Code 412 Precondition Failed, HTTP Status Code 413 Payload Too Large, HTTP Status Code 414 URI Too Long, HTTP Status Code 417 Expectation Failed, HTTP Status Code 426 Upgrade Required, HTTP Status Code 451 Unavailable For Legal Reasons, HTTP Status Code 506 Variant Also Negotiates, HTTP Status Code 507 Insufficient Storage, HTTP Status Code 508 Loop Detected, HTTP Status Code 510 Not Extended, HTTP Status Code 511 Network Authentication Required, HTTP Status Code 103 Early Hints, HTTP Status Code 418 I'm a Teapot, HTTP Status Code 422 Unprocessable Entity, HTTP Status Code 423 Locked, HTTP Status Code 424 Failed Dependency, HTTP Status Code 431 Request Header Fields Too Large, HTTP Status Code 444 No Response (Nginx), HTTP Status Code 495 SSL Certificate Error (Nginx), HTTP Status Code 496 SSL Certificate Required (Nginx), HTTP Status Code 497 HTTP to HTTPS (Nginx), HTTP Status Code 499 Client Closed Request (Nginx), HTTP Status Code 520 Web Server Returned An Unknown Error (Cloudflare), HTTP Status Code 521 Web Server Is Down (Cloudflare), HTTP Status Code 522 Connection Timed Out (Cloudflare), HTTP Status Code 523 Origin Is Unreachable (Cloudflare), HTTP Status Code 524 A Timeout Occurred (Cloudflare), HTTP Status Code 525 SSL Handshake Failed (Cloudflare), HTTP Status Code 526 Invalid SSL Certificate (Cloudflare), HTTP Status Code 527 Railgun Error (Cloudflare), HTTP 'nosniff' directive, HTTP HSTS max-age Directive, HTTP HSTS includeSubDomains Directive, HTTP HSTS preload Directive, HTTP h2c Upgrade Token, HTTP ALPN protocol IDs, HTTP 'trailers' directive in TE, HTTP MIME Type Negotiation, HTTP SPDY (Predecessor to HTTP/2), HTTP Client Hints, HTTP MIME-Version Header, HTTP Character Encoding, HTTP Charset Parameter, HTTP Language Tags, HTTP Quality Values (q=values), HTTP Content Negotiation Mechanisms, HTTP Reason Phrase (obsolete in HTTP/2), HTTP ABNF (Augmented Backus–Naur Form), HTTP BNF Notation used in specs, HTTP Pseudo-headers (HTTP/2), method Pseudo-Header, scheme Pseudo-Header, authority Pseudo-Header, path Pseudo-Header, status Pseudo-Header, HTTP frame fragmentation (HTTP/2), HTTP Flow Control (HTTP/2), HTTP Priority (HTTP/2), HTTP Server Push (HTTP/2) (Deprecated), HTTP OPTIONS * Request (Asterisk Form), HTTP Origin Form, HTTP Authority Form, HTTP Asterisk Form, HTTP Absolute Path, HTTP Request URI, HTTP Request Target, HTTP CRLF (Carriage Return Line Feed), HTTP Whitespace Handling, HTTP Folding (Obsolete in HTTP/1.1) HTTP - Hypertext Transfer Protocol: RFC 9114 HTTP/3,
HTTP/2 in Action by Barry Pollard - https://manning.com/books/http2-in-action - https://learning.oreilly.com/library/view/http-2-in-action/9781617295164
Hypertext Transfer Protocol | HTTP:
Request methods | Request methods
List of HTTP header fields | Header fields:
List of HTTP status codes | Status codes:
Security access control methods:
HTTP/1.0 <small>(1996)</small>
HTTP/1.1 <small>(1997)</small>
HTTP/1.1 <small>(1999)</small>
HTTP/1.1: Message Syntax and Routing <small>(2014)</small>
HTTP/1.1: Semantics and Content <small>(2014)</small>
HTTP/1.1: Conditional Requests <small>(2014)</small>
HTTP/1.1: Range Requests <small>(2014)</small>
HTTP/1.1: Caching <small>(2014)</small>
HTTP/1.1: Authentication <small>(2014)</small>
HTTP/2 <small>(2015)</small>
HTTP/2: HPACK Header Compression <small>(2015)</small>
HTTP/2: Opportunistic Security for HTTP/2 <small>(2017)</small>
HTTP/2: The ORIGIN HTTP/2 Frame <small>(2018)</small>
HTTP/2: Bootstrapping WebSockets with HTTP/2 <small>(2018)</small>
HTTP/2: Using TLS 1.3 with HTTP/2 <small>(2020)</small>
HTTP/3
}} ]] | developer = initially [[CERN; IETF, W3C ]] | introdate = {{Start date and age | 1991 | df=yes}} | newer = }} {{IPstack}} ([[navbar_http - see also navbar_html)
Cloud Monk is Retired ( for now). Buddha with you. © 2025 and Beginningless Time - Present Moment - Three Times: The Buddhas or Fair Use. Disclaimers
SYI LU SENG E MU CHYWE YE. NAN. WEI LA YE. WEI LA YE. SA WA HE.