http2
Header (HEADERS) and data (DATA) frames make up the basic HTTP request and response
Settings (SETTINGS), window updates (WINDOW_UPDATE), and push promises (PUSH_PROMISE) are used to implement other functions of HTTP/2
1. Initiating HTTP/2
2. Frames (section 4) and the stream layer
3. Frames (section 6) and error codes (section 7)
4. HTTP addressing (section 8) and extended requirements (section 9) describe HTTP semantics How is culture represented by frames and streams
3 Start HTTP/2
3.1 HTTP/2 version definition
The character "h2" indicates that the HTTP/2 protocol uses TLS [TLS]
The character "h2c" indicates that the HTTP/2 protocol runs on plaintext TCP
Use of "h2" or "h2c" indicates use of transport, security, framing and semantic messaging as defined in the document.
The client cannot predict whether the server supports http2
GET /default.htm HTTP/1.1
Host: server.example.com
Connection: Upgrade, HTTP2-Settings
Upgrade: h2c
HTTP2-Settings: <base64url encoding of HTTP/2 SETTINGS payload>
不支持
HTTP/1.1 200 OK
Content-Length: 243
Content-Type: text/html
…
支持
HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: h2c
[ HTTP/2 connection …
After support, the first HTTP/2 frame sent by the client is the connection preamble.
The first HTTP/2 frame sent by the server is a SETTINGS frame. After receiving a 101 response, the client sends a connection preamble containing a SETTINGS frame.
Connection Prologue: PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n
If either endpoint does not begin with a valid connection preamble, the client and server MUST terminate the TCP connection. The GOAWAY frame (section 6.8) MAY be omitted if the endpoint is not using HTTP/2.
4 HTTP Frames HTTP帧
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
±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+
| R | Length (14) | Type (8) | Flags (8) |
±±±----------±--------------±------------------------------+
|R| Stream Identifier (31) |
+=+=============================================================+
| Frame Payload (0…) …
±--------------------------------------------------------------+
R : Reserved 2-bit field. The semantics of these bytes are undefined, and MUST be left unset (0) when sent, and this field MUST be ignored when received.
Length : The length of the frame body in 14-bit unsigned integer. The 8-byte frame header information is not counted.
Type : The 8-bit type of the frame. The frame type defines how the rest of the frame header and frame body will be interpreted. Concrete implementations MUST handle receiving an unknown frame type (any frame not defined in the documentation) as a connection error of type PROTOCOL_ERROR .
Flags: The 8-byte field reserved for the frame type has a specific Boolean flag.
Identifiers assign specific semantics to certain frame types. Flags other than those defining the semantics of the frame type definition MUST be ignored and MUST be left unset (0) when sent.
R : Reserved field of 1 bit. The semantics of this field are unset and MUST remain unset (0) when sending, and MUST be ignored when receiving.
Stream Identifier: 31-byte stream identifier (see StreamIdentifiers). 0 is reserved and indicates that the frame is associated with the connection as a whole rather than a single stream.
4.2 Frame Size
The maximum length limit of the frame body is different for different frame types. The absolute length of the maximum frame body is (16,383) bytes, indicating that the maximum frame length is 16,391 bytes. All implementations MUST be capable of receiving and processing frames of this maximum length.
4.3 Header Compression and Decompression header compression and decompression
An HTTP/2 message header field contains one or more associated key-value pairs. They are used in HTTP request response messages and server push operations (see Section 8.2).
A header set is a collection of 0 or more header fields. When it is transmitted over the connection, the header set will be serialized into the message header block using HTTP header compression. Serialized header blocks are split into one or more sequences of bytes, called header partitions, and delivered in the carrier of header, push-promise, and continuation frames.
HTTP header compression does not preserve the relative order of header fields. Header fields with multiple values are encoded into a single header field using a specific splitter (see Section 8.1.2.3 HeaderOrdering), which preserves the corresponding order of the various values in that header field.
The header Cookie field is specially handled by the HTTP mapping; see Section 8.1.2.4.
The receiving endpoint connects header block reassembly, and reconstructs the header set after decompressing the block.
A complete header block contains:
A complete header block contains:
A single HEADERS or PUSH_PROMISE frame containing the set of header termination markers, or
a header HEADERS or push promise PUSH_PROMISE frame with header termination markers cleared and one or more continuation CONTINUATION frames, the last continuation CONTINUATION frame having the header termination marker set up.
Header compression is stateful and uses the same compression environment throughout the connection. Each header block is treated as a discrete unit. Header blocks MUST be transmitted as a continuous sequence of frames, without interleaved frames of any type or any other stream. The last frame of a sequence of HEADERS or continuation CONTINUATION frames MUST have the End of Headers flag set. A push promise PUSH_PROMISE or the last frame of a sequence of continuation CONTINUATION frames MUST have the header Terminate flag set.
The header block MUST be sent with headers HEADERS, PUSH_PROMISE or CONTINUATION payload, because these frames carry compression context data that can be modified by the receiver. An endpoint MUST reassemble header blocks and perform decompression when receiving HEADERS, PUSH_PROMISE, or continuation CONTINUATION frames, even if those frames would be discarded. If the header section cannot be reconstructed, the receiver MUST terminate the connection with a connection error of type Decompression Error (Section 5.4.1).
5 Streams and Multiplexing Streams and Multiplexing
A single HTTP/2 connection can hold multiple concurrently open streams, from which frames are exchanged between the various endpoints.
Streams can be created, used or shared unilaterally by clients or servers.
Streams can be closed by any connection endpoint.
The order in which frames are sent within a stream is important. They will be processed in the order they are received. In particular, the sequence of headers and data frames makes sense semantically.
Streams are identified by an integer. The identifier is assigned by the terminal that started the stream.
+--------+
PP | | PP
,--------| idle |--------.
/ | | \
v +--------+ v
+----------+ | +----------+
| | | H | |
,—| reserved | | | reserved |—.
| | (local) | v | (remote) | |
| ±---------+ ±-------+ ±---------+ |
| | ES | | ES | |
| | H ,-------| open |-------. | H |
| | / | | \ | |
| v v ±-------+ v v |
| ±---------+ | ±---------+ |
| | half | | | half | |
| | closed | | R | closed | |
| | (remote) | | | (local) | |
| ±---------+ | ±---------+ |
| | v | |
| | ES / R ±-------+ ES / R | |
| ----------->| |<-----------' | | R | closed | R | -------------------->| |<--------------------’
±-------+
H: HEADERS frame (with implied CONTINUATIONs)
PP: PUSH_PROMISE frame (with implied CONTINUATIONs)
ES: END_STREAM flag
R: RST_STREAM frame
Stream status:
All streams start in an "idle" state. In this state, there is no exchange of any frames.
The following transfers are valid in this state:
Sending or receiving a HEADERS frame causes the stream to become "open". Stream identifiers are described in StreamIdentifiers. This HEADERS frame may also cause the stream to immediately become "half-closed".
Send a PUSH_PROMISE frame to mark the related stream for later use. The reserved flow state will transition to "Reserved (local)".
Receiving a PUSH_PROMISE frame marks the associated stream as a reserved stream for the remote endpoint. The status of these streams becomes "Reserved (Remote)"
reserved (local) :
In the "reserved (local)" state are streams that have been committed to sending PUSH_PROMISE frames. A PUSH_PROMISE frame reserves an idle stream by associating a stream with an open stream initiated by the remote peer.
In this state, only the following transfers are possible:
An endpoint may send a HEADERS frame, causing the stream to be opened to a "half-closed (remote)" state.
Any endpoint can send a RST_STREAM frame to cause the stream to become "closed". This will release the stream's hold.
In this state a peer MUST NOT send frames other than HEADERS frames and RST_STREAM
A PRIORITY frame may be received in this state. Receipt of any frame other than a HEADERS frame, a RST_STREAM frame, or a priority PRIORITY frame shall be considered a connection error (Section 5.4.1) of type PROTOCOL_ERROR.
reserved (remote) :
Flow descriptions in the "reserved (remote)" state have been reserved by the remote peer.
In this state, only the following transfers are possible:
Receiving a HEADERS frame causes the stream to transition to the "semi-closed (local)" state.
Either endpoint can send a RST_STREAM frame to cause the stream to become "closed". This will release the stream's hold.
open :
A stream in the "open" state can be used by both peers to send frames of any type. In this state, peer inspection of sent data is limited by the broadcaster's FlowControl flow control (Section 5.2).
In this state each endpoint can send a frame with the END_STREAM end-stream marker to make the stream transition to one of the "half-closed" states: an endpoint sends an end-stream END_STREAM marker to make the stream into the "half-closed" state ;A terminal receives an end stream END_STREAM marker to make the stream into a "semi-closed (remote)" state. A HEADERS frame marked with an end stream END_STREAM may be followed by a CONTINUATION frame.
Each terminal in this state can send a RST_STREAM frame to make the stream transition to the "closed" state.
half closed (local) :
Streams in the "semi-closed (local)" state cannot send frames. Only window update (WINDOW_UPDATE), priority (PRIORITY) and terminate stream (RST_STREAM) frames can be sent in this state.
half closed (remote) :
A stream in the "half closed (remote)" state is no longer used by the peer to send frames. In this state, the terminal performing flow control no longer undertakes the work of receiving the blank control window.
If an endpoint receives additional frames from a stream in this state, unless it is a continuation CONTINUATION frame, it MUST return a stream error of type STREAM_CLOSED (Section 5.4.2).
In this state, when the stream sends a frame with the END_STREAM flag or an endpoint sends a RST_STREAM frame, the stream will transition to the "closed" state.
closed :
The "closed" state is a terminal state.
An endpoint MUST NOT send frames over a closed stream. Any frame received by an endpoint after receipt of a RST_STREAM MUST be handled as a StreamErrorHandler stream error (Section 5.4.2) of type STREAM_CLOSED. Similarly, any frame received by an endpoint after a DATA frame with the END_STREAM flag set, or after a HEADERS frame with the END_STREAM flag set and not followed by a continuation CONTINUATION frame MUST be closed as a stream. Connection error (Section 5.4.1) handling for STREAM_CLOSED.
5.1.1 Stream Identifiers stream identifier
Streams are identified by unsigned integers of 31-bit bytes. Streams initiated by the client must be marked with an odd number; streams initiated by the server must be marked with an even number.
A newly established stream identifier must be greater in value than any terminal has opened or reserved stream identifiers. The rules apply to streams opened with header frames and to streams reserved with push-promise frames. An endpoint receiving a non-canonical stream identifier MUST respond with a connection error of type PROTOCOL_ERROR.
Stream identifiers cannot be reused. Long-lived connections may cause the available range of stream identifiers to be exhausted. A client may establish a new connection for a new stream when it cannot create a new stream identifier. When the server cannot create a new stream identifier, it can send a timeout frame (GOAWAY) to force the client to use a new connection for the new stream.
5.1.2 Stream Concurrency
The peer can use the SETTINGS_MAX_CONCURRENT_STREAMS parameter in the settings frame to limit the concurrency of streams.
The client can specify the maximum concurrency of streams that the server can start, and the server can specify the maximum concurrency of streams that the client can start. Endpoints must never exceed the limit set by the peer.
Streams in "open" or any of the "semi-closed" states are counted in the number of streams that the terminal is allowed to start. Streams in any of these three states will count toward the SETTINGS_MAX_CONCURRENT_STREAMS setting. Streams in any of the "reserved" states do not count towards opens.
Endpoints must never exceed the settings set by peers. Endpoints that receive header frames that cause the concurrent streams they broadcast to exceed the limit MUST treat this as a Stream Error (Section 5.4.2). An endpoint that wishes to reduce the value of SETTINGS_MAX_CONCURRENT_STREAMS to a value smaller than the currently open streams can either close streams exceeding the new setting value or allow streams to end.
5.2 Flow Control Flow Control
Using Multiplexed Streams describes stream blocking caused by resource contention for TCP connections. Flow control schemes etc. ensure that streams on the same connection do not destructively interfere with each other. Flow control is used for individual streams as well as for the entire connection.
HTTP/2 provides flow control by using the WINDOW_UPDATE frame type (Section 6.9).
5.2.1 Flow Control Principles flow control rules
Flow control is defined to protect the operation of endpoints under resource constraints. For example, a proxy needs to share memory across many connections, possibly with slow upstream connections and fast downstream connections.
Flow control solves the situation where the receiving end is processing data on one stream while also wanting to continue processing other streams on the same connection.
5.4 Error Handling Error handling
The HTTP/2 framework allows two types of errors:
An error that makes the entire connection unusable.
Errors that occur within a single stream.
A list of error codes can be found at "ErrorCodes".
5.4.1 Connection Error Handling A
stream error is an error that prevents further processing by the frame layer or corrupts any stream state.
An endpoint sending a stream error SHOULD first send a GOAWAY frame (Section 6.8) with the identifier of the most recent stream that successfully received a frame from the peer. The GOAWAY timeout frame contains the error code of the link terminal. After sending GOAWAY, the endpoint MUST close the TCP connection.
The timeout (GOAWAY) frame may not be effectively received by the receiving end. In the event of a connection error, a GOAWAY frame is a best practice attempt to communicate to the peer why the connection was terminated.
5.4.2 Stream Error Handling Stream Error Handling
An endpoint that detects a stream error sends a RST_STREAM frame (RST_STREAM, Section 6.4) with the stream identifier at the time the error occurred. RST_STREAM frames carry an error code indicating the type of error.
RST_STREAM is the last frame that an endpoint can send a stream. A peer sending a RST_STREAM frame MUST be ready to receive any frame sent or prepared to be sent by a remote peer. These frames MAY be ignored unless the connection state is modified (such as in header compression (Section 4.3)).
5.4.3 Connection Termination
If a TCP connection is disconnected while streams are still open or half-closed, the endpoint MUST assume that these streams are abnormally terminated and incomplete.
6 Frame Definitions frame definition
6.1 DATA data frame
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
±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+
| [Pad High(8)] | [Pad Low (8)] | Data () .
±--------------±--------------±------------------------------+
. Data () …
±--------------------------------------------------------------+
| Padding (*) …
±--------------------------------------------------------------+
Pad Length: An 8-bit field containing the frame pad length in bytes. This field is optional and only present if the PADDED flag is set.
Padding: The padding bytes do not contain any application semantic value. Padding bytes must be set to 0 when sending and ignored when receiving.
Data : application data. The size of the data volume is the frame's payload minus the length of other presentation fields.
END_STREAM (0x1): Bit 1 is used to indicate that the current frame is the last frame sent by the determined stream. When this flag is set the stream enters a semi-closed or closed state (Section 5.1).
END_SEGMENT (0x2): Bit 2 indicates that it is the last frame of the current end. Proxy MUST NOT merge frames across multiple peer boundaries, and Proxy MUST maintain segment boundaries when forwarding frames.
PADDED (0x8): Bit 4 is used to indicate that the Pad Length field is visible.
A dataframe absolutely needs to be associated with a stream. If a data frame is received with a Flow Marker field of 0x0, a Connection Error of type Protocol Error (Section 5.4.1) MUST be responded.
Data frames are subject to flow control and can only be sent if the stream is open or half-closed (remote). Padding is also included in flow control.
If a data frame is received while the associated stream is not in the open and half-closed (native) state, the receiver MUST respond with a stream error (Section 5.4.2) of type stream closed.
The total number of padding bytes depends on the value of Pad Length. If the size of the padding is greater than the size of the frame payload, the receiver MUST treat it as a connection error (Section 5.4.1) of type Protocol Error.
6.2 HEADERS header
A header frame (type=0x1) consists of key-value pairs. It is used to open a stream (Section 5.1). Header frames can be sent with the stream open or half-closed (remote).
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
±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+
|Pad Length? (8)|
±±------------±----------------------------------------------+
|E| Stream Dependency? (31) |
±±------------±----------------------------------------------+
| Weight? (8) |
±±------------±----------------------------------------------+
| Header Block Fragment () …
±--------------------------------------------------------------+
| Padding () …
±--------------------------------------------------------------+
Pad Length: The 8-bit containing unit is the byte frame padding length field. This field is optional and present only if the PADDED flag is set.
E: A 1-bit flag used to identify whether a flow dependency is private, see Section 5.3. This field is optional and only present if the priority flag is set.
Stream Dependency: The field of the identifier of the stream on which the 31-bit stream depends, see Section 5.3. This field is optional and only present if the priority flag is set.
Weight : The 8-bit weight flag of the stream, see Section 5.3. Add a value from 1-256 to store the weight of the stream. This field is optional and only present if the priority flag is set.
Header Block Fragment: Header block fragment.
Padding: padding bytes
6.3 PRIORITY priority frame
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
±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+
|E| Stream Dependency (31) |
±±------------±----------------------------------------------+
| Weight (8) |
±±------------+
E: A one-bit flag indicating that the dependency of the stream is exclusive, see Section 5.3
Stream Dependency: A 31-bit stream identifier that identifies the stream on which the stream depends, see Section 5.3
Weight: The weight of the stream's dependency (8 bits) , see Section 5.3. Add a weight value of 1-256.
6.4 RST_STREAM RST_STREAM帧
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
±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+
| Error Code (32) |
±--------------------------------------------------------------+
RST_STREAM frames (type=0x3) allow abnormal termination of streams. When sent by a stream's pointer, it indicates that cancellation of the stream is expected or an error condition has occurred. When sent by a stream at the receiving end, it indicates that the receiver wishes to reject the stream, that the stream was canceled, or that an error occurred.
6.5 SETTINGS setting frame
The setting frame (type=0x4) contains setting parameters that affect how to communicate with the terminal (such as preferences and peer behavior constraints), and is used to confirm the receipt of these parameters. Individual setting parameters may also be considered "settings".
Setup frames always apply to connections, not to a single stream. The stream setup frame identifier MUST be 0. If an endpoint receives a setup frame with a stream setup frame identifier other than 0, it MUST respond with a connection error of type Protocol Error (Section 5.4.1).
6.5.1 SettingFormat Set frame format
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
±±±±±±± ±±±±±±±±±±±±±±±±±±±±±±±+
|Identifier (8) | Value (32) …
±------------ --±----------------------------------------------+
…Value |
±-------------+
The following parameters are defined:
SETTINGS_HEADER_TABLE_SIZE (1): Allows the sender to notify the remote terminal of the maximum capacity of the header compression table for decoding header blocks. This encoder can optionally use certain signals in the header block to reduce the size of the header compression (???). The initial value is 4,096 bytes.
SETTINGS_ENABLE_PUSH (2) : This parameter can be used to turn off server push. When the terminal receives this parameter as 0, it must not send the server push promise frame. When the terminal has set this parameter to 0 and acknowledges it, it must handle the received server push as a connection error of type Protocol Error.
The initial value is 1, which means push is permitted. Any value other than 0 or 1 MUST be handled as a connection error of type ProtocolError.
SETTINGS_MAX_CONCURRENT_STREAMS (3): Indicates the maximum concurrent streams allowed by the sender. This limit is directional: it applies to the maximum number of concurrent streams the sender allows the receiver to create. There is no limit to this value when initialized. It is recommended that the value not be greater than 100 to avoid unnecessary restrictions on parallelism.
A value of this set to 0 should not be considered special by the terminal. A value of 0 prevents the creation of new streams, otherwise it applies to any limit exhausted by activated streams. For short connections, this parameter should not be set to 0; if the server does not want to receive any requests, the best way is to close the connection.
SETTINGS_INITIAL_WINDOW_SIZE (4): Indicates the initial window size (in bytes) of the sender's troposphere flow control. The initial value is 65,535.
This parameter affects the window size for all streams, including existing streams. See Section 6.9.2.
Flow control window size values greater than 2 to the power of 31 -1 MUST be treated as connection errors for flow control errors.
6.6 PUSH_PROMISE push promise frame
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
±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+
| [Pad High(8)] | [Pad Low (8)] |X| Promised Stream ID (31) …
±--------------±--------------±±----------------------------+
… Promised Stream ID | Header Block Fragment () …
±------------------------------±------------------------------+
| Header Block Fragment () …
±--------------------------------------------------------------+
| Padding (*) …
±--------------------------------------------------------------+
The Header Frame Carrier contains the following fields:
Pad High : Pad size high. This field is only present if the PAD_HIGH flag is set.
Pad Low : Pad size low. This field is only present if the PAD_LOW flag is set.
X : Individual reserved bits.
Promised Stream ID : This unsigned 31-bit integer represents the stream identifier that the endpoint is ready to send. The promised stream token must be a valid choice for the next stream the sender intends to send.
Header Block Fragment : A header block fragment (Section 5.1.1) containing the request header fields.
Padding : padding bytes.
6.7 PING PING帧
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
±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+
| |
| Opaque Data (64) |
| |
±--------------------------------------------------------------+
6.8 GOAWAY timeout frame
The timeout frame (type=0x7) informs the remote peer not to establish new flows on this connection. Timeout frames can be sent by the client or the server. Once sent, the initiator shall ignore the sending of new frames with identifiers greater than those of the previous stream on the current connection. After receiving the timeout frame, the receiving end must not open a new stream on this connection, but can create a new connection for the new stream.
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
±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+
|X| Last-Stream-ID (31) |
±±------------------------------------------------------------+
| Error Code (32) |
±--------------------------------------------------------------+
| Additional Debug Data (*) |
±--------------------------------------------------------------+
6.9 WINDOW_UPDATE window update frame
WINDOW_UPDATE frame (type=0x8) is used to implement flow control; see Chapter 5.2 for an overview.
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
±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+
|X| Window Size Increment (31) |
±±------------------------------------------------------------+
7 Error Codes
NO_ERROR (0): The relevant condition is not the result of an error. For example, a timeout frame may carry this error code to indicate a graceful shutdown of the connection.
PROTOCOL_ERROR (1) : The endpoint detected an unspecified protocol error. This error is used when a more specific error code is not available.
INTERNAL_ERROR (2) : The terminal encountered an unexpected internal error.
FLOW_CONTROL_ERROR (3) : The endpoint detected a violation of the flow control protocol by the peer.
SETTINGS_TIMEOUT (4): The endpoint sent a SETTINGS frame, but did not receive a response in time. See Settings Synchronization.
STREAM_CLOSED (5) : The endpoint received the frame while the stream was half closed.
FRAME_SIZE_ERROR (6) : The endpoint received a frame whose size exceeds the maximum size.
REFUSED_STREAM (7): The endpoint rejects the stream before it performs any application processing, see Reliability (Section 8.1.4) for details.
CANCEL (8): The endpoint uses this to indicate that a stream is no longer needed.
COMPRESSION_ERROR (9): The terminal cannot maintain the connection of the header compression context
CONNECT_ERROR (10): The connection established in response to a connection request is regarded as abnormally closed.
ENHANCE_YOUR_CALM (11) : The endpoint detects that the peer is exhibiting behavior that may generate excessive load.
INADEQUATE_SECURITY (12): The underlying transport contains attributes that do not meet the minimum requirements declared by the document or terminal.
8.1 HTTP Request/Response Exchange HTTP Request/Response Exchange
The client initiates an HTTP request on a new stream, using a previously unused stream identifier. The server initiates an HTTP request on the same stream.
8.1.3 Examples
GET /resource HTTP/1.1 HEADERS
Host: example.org ==> + END_STREAM
Accept: image/jpeg + END_HEADERS
:method = GET
:scheme = https
:path = /resource
host = example.org
accept = image/jpeg
HTTP/1.1 304 Not Modified HEADERS
ETag: “xyzzy” ==> + END_STREAM
Expires: Thu, 23 Jan … + END_HEADERS
:status = 304
etag: “xyzzy”
expires: Thu, 23 Jan …
POST /resource HTTP/1.1 HEADERS
Host: example.org ==> - END_STREAM
Content-Type: image/jpeg + END_HEADERS
Content-Length: 123 :method = POST
:scheme = https
{binary data} :path = /resource
:authority = example.org
content-type = image/jpeg
content-length = 123
DATA
+ END_STREAM
{binary data}
A response with header fields and payload data will be converted into a header frame, followed by zero or more continuation frames, followed by one or more data frames, the last data frame in the sequence has the END_STREAM flag.
HTTP/1.1 200 OK HEADERS
Content-Type: image/jpeg ==> - END_STREAM
Content-Length: 123 + END_HEADERS
:status = 200
{binary data} content-type = image/jpeg
content-length = 123
DATA
+ END_STREAM
{binary data}
After all request or response header blocks and all data frames are sent, the trailer header fields are sent as one header block. A header/continuation frame sequence with a trailer contains a terminating frame marked with END_HEADERS and END_STREAM.
HTTP/1.1 200 OK HEADERS
Content-Type: image/jpeg ==> - END_STREAM
Transfer-Encoding: chunked + END_HEADERS
Trailer: Foo :status = 200
content-length = 123
123 content-type = image/jpeg
{binary data} trailer = Foo
0
Foo: bar DATA
-
END_STREAM
{binary data}HEADERS + END_STREAM + END_HEADERS foo: bar