--- 1/draft-ietf-httpbis-http2-07.txt 2013-11-11 16:14:29.392895390 -0800 +++ 2/draft-ietf-httpbis-http2-08.txt 2013-11-11 16:14:29.508898228 -0800 @@ -1,65 +1,69 @@ HTTPbis Working Group M. Belshe Internet-Draft Twist Intended status: Standards Track R. Peon -Expires: April 24, 2014 Google, Inc +Expires: May 15, 2014 Google, Inc M. Thomson, Ed. Microsoft A. Melnikov, Ed. Isode Ltd - October 21, 2013 + November 11, 2013 Hypertext Transfer Protocol version 2.0 - draft-ietf-httpbis-http2-07 + draft-ietf-httpbis-http2-08 Abstract This specification describes an optimized expression of the syntax of the Hypertext Transfer Protocol (HTTP). HTTP/2.0 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent messages on the same connection. It also introduces unsolicited push of representations from servers to clients. This document is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged. + This version of the draft has been marked for implementation. + Interoperability testing will occur in the HTTP/2.0 interim in + Zurich, CH, starting 2014-01-22. + Editorial Note (To be removed by RFC Editor) Discussion of this draft takes place on the HTTPBIS working group mailing list (ietf-http-wg@w3.org), which is archived at . Working Group information and related documents can be found at (Wiki) and (source code and issues tracker). - The changes in this draft are summarized in Appendix A.1. + The changes in this draft are summarized in Appendix A. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on April 24, 2014. + This Internet-Draft will expire on May 15, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -83,21 +87,21 @@ 3.2. Starting HTTP/2.0 for "http" URIs . . . . . . . . . . . . 8 3.2.1. HTTP2-Settings Header Field . . . . . . . . . . . . . 10 3.3. Starting HTTP/2.0 for "https" URIs . . . . . . . . . . . . 10 3.4. Starting HTTP/2.0 with Prior Knowledge . . . . . . . . . . 10 3.5. HTTP/2.0 Connection Header . . . . . . . . . . . . . . . . 11 4. HTTP Frames . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1. Frame Format . . . . . . . . . . . . . . . . . . . . . . . 12 4.2. Frame Size . . . . . . . . . . . . . . . . . . . . . . . . 13 4.3. Header Compression and Decompression . . . . . . . . . . . 13 5. Streams and Multiplexing . . . . . . . . . . . . . . . . . . . 14 - 5.1. Stream States . . . . . . . . . . . . . . . . . . . . . . 14 + 5.1. Stream States . . . . . . . . . . . . . . . . . . . . . . 15 5.1.1. Stream Identifiers . . . . . . . . . . . . . . . . . . 19 5.1.2. Stream Concurrency . . . . . . . . . . . . . . . . . . 19 5.2. Flow Control . . . . . . . . . . . . . . . . . . . . . . . 20 5.2.1. Flow Control Principles . . . . . . . . . . . . . . . 20 5.2.2. Appropriate Use of Flow Control . . . . . . . . . . . 21 5.3. Stream priority . . . . . . . . . . . . . . . . . . . . . 22 5.4. Error Handling . . . . . . . . . . . . . . . . . . . . . . 22 5.4.1. Connection Error Handling . . . . . . . . . . . . . . 22 5.4.2. Stream Error Handling . . . . . . . . . . . . . . . . 23 5.4.3. Connection Termination . . . . . . . . . . . . . . . . 23 @@ -146,28 +150,29 @@ 12.2. Frame Type Registry . . . . . . . . . . . . . . . . . . . 54 12.3. Error Code Registry . . . . . . . . . . . . . . . . . . . 55 12.4. Settings Registry . . . . . . . . . . . . . . . . . . . . 55 12.5. HTTP2-Settings Header Field Registration . . . . . . . . . 56 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 56 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 57 14.1. Normative References . . . . . . . . . . . . . . . . . . . 57 14.2. Informative References . . . . . . . . . . . . . . . . . . 58 Appendix A. Change Log (to be removed by RFC Editor before publication) . . . . . . . . . . . . . . . . . . . . 59 - A.1. Since draft-ietf-httpbis-http2-06 . . . . . . . . . . . . 59 - A.2. Since draft-ietf-httpbis-http2-05 . . . . . . . . . . . . 59 - A.3. Since draft-ietf-httpbis-http2-04 . . . . . . . . . . . . 59 - A.4. Since draft-ietf-httpbis-http2-03 . . . . . . . . . . . . 60 - A.5. Since draft-ietf-httpbis-http2-02 . . . . . . . . . . . . 60 - A.6. Since draft-ietf-httpbis-http2-01 . . . . . . . . . . . . 60 - A.7. Since draft-ietf-httpbis-http2-00 . . . . . . . . . . . . 61 - A.8. Since draft-mbelshe-httpbis-spdy-00 . . . . . . . . . . . 61 + A.1. Since draft-ietf-httpbis-http2-07 . . . . . . . . . . . . 59 + A.2. Since draft-ietf-httpbis-http2-06 . . . . . . . . . . . . 59 + A.3. Since draft-ietf-httpbis-http2-05 . . . . . . . . . . . . 59 + A.4. Since draft-ietf-httpbis-http2-04 . . . . . . . . . . . . 59 + A.5. Since draft-ietf-httpbis-http2-03 . . . . . . . . . . . . 60 + A.6. Since draft-ietf-httpbis-http2-02 . . . . . . . . . . . . 60 + A.7. Since draft-ietf-httpbis-http2-01 . . . . . . . . . . . . 60 + A.8. Since draft-ietf-httpbis-http2-00 . . . . . . . . . . . . 61 + A.9. Since draft-mbelshe-httpbis-spdy-00 . . . . . . . . . . . 61 1. Introduction The Hypertext Transfer Protocol (HTTP) is a wildly successful protocol. However, the HTTP/1.1 message format ([HTTP-p1], Section 3) is optimized for implementation simplicity and accessibility, not application performance. As such it has several characteristics that have a negative overall effect on application performance. In particular, HTTP/1.0 only allows one request to be outstanding at @@ -358,21 +363,21 @@ Upgrade: HTTP/2.0 HTTP2-Settings: Requests that contain an entity body MUST be sent in their entirety before the client can send HTTP/2.0 frames. This means that a large request entity can block the use of the connection until it is completely sent. If concurrency of an initial request with subsequent requests is important, a small request can be used to perform the upgrade to - HTTP/2.0, at the cost of an additional round trip. + HTTP/2.0, at the cost of an additional round-trip. A server that does not support HTTP/2.0 can respond to the request as though the Upgrade header field were absent: HTTP/1.1 200 OK Content-Length: 243 Content-Type: text/html ... @@ -501,21 +506,21 @@ using HTTP/2.0. 4. HTTP Frames Once the HTTP/2.0 connection is established, endpoints can begin exchanging frames. 4.1. Frame Format All frames begin with an 8-octet header followed by a payload of - between 0 and 16383 octets. + between 0 and 16,383 octets. 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...) ... +---------------------------------------------------------------+ @@ -578,47 +583,51 @@ associated values. They are used within HTTP request and response messages as well as server push operations (see Section 8.2). Header sets are logical collections of zero or more header fields arranged at the application layer. When transmitted over a connection, the header set is serialized into a header block using HTTP Header Compression [COMPRESSION]. The serialized header block is then divided into one or more octet sequences, called header block fragments, and transmitted within the payload of HEADERS (Section 6.2), PUSH_PROMISE (Section 6.6) or CONTINUATION - (Section 6.10) frames. The receiving endpoint reassembles the header - block by concatenating the individual fragments, then decompresses - the block to reconstruct the header set. + (Section 6.10) frames. - Header block fragments can only be sent as the payload of HEADERS, - PUSH_PROMISE or CONTINUATION frames. + A receiving endpoint reassembles the header block by concatenating + the individual fragments, then decompresses the block to reconstruct + the header set. - A compressed and encoded header block is transmitted in a HEADERS or - PUSH_PROMISE frame, followed by zero or more CONTINUATION frames. If - the number of octets in the block is greater than the space remaining - in the frame, the block is divided into multiple fragments, which are - then transmitted in multiple frames. + A complete header block consists of either: + + o a single HEADERS or PUSH_PROMISE frame each respectively with the + END_HEADERS or END_PUSH_PROMISE flag set, or + + o a HEADERS or PUSH_PROMISE frame with the END_HEADERS or + END_PUSH_PROMISE flag cleared and one or more CONTINUATION frames, + where the last CONTINUATION frame has the END_HEADER flag set. Header blocks MUST be transmitted as a contiguous sequence of frames, with no interleaved frames of any other type, or from any other - stream. The last frame in a sequence of HEADERS/CONTINUATION frames - MUST have the END_HEADERS flag set. The last frame in a sequence of - PUSH_PROMISE/CONTINUATION frames MUST have the END_PUSH_PROMISE/ - END_HEADERS flag set (respectively). + stream. The last frame in a sequence of HEADERS or CONTINUATION + frames MUST have the END_HEADERS flag set. The last frame in a + sequence of PUSH_PROMISEor CONTINUATION frames MUST have the + END_PUSH_PROMISE or END_HEADERS flag set (respectively). - HEADERS, PUSH_PROMISE and CONTINUATION frames carry data that can - modify the compression context maintained by a receiver. An endpoint - receiving HEADERS, PUSH_PROMISE or CONTINUATION frames MUST - reassemble header blocks and perform decompression even if the frames - are to be discarded. A receiver MUST terminate the connection with a - connection error (Section 5.4.1) of type COMPRESSION_ERROR, if it - does not decompress a header block. + Header block fragments can only be sent as the payload of HEADERS, + PUSH_PROMISE or CONTINUATION frames. HEADERS, PUSH_PROMISE and + CONTINUATION frames carry data that can modify the compression + context maintained by a receiver. An endpoint receiving HEADERS, + PUSH_PROMISE or CONTINUATION frames MUST reassemble header blocks and + perform decompression even if the frames are to be discarded. A + receiver MUST terminate the connection with a connection error + (Section 5.4.1) of type COMPRESSION_ERROR, if it does not decompress + a header block. 5. Streams and Multiplexing A "stream" is an independent, bi-directional sequence of HEADERS and DATA frames exchanged between the client and server within an HTTP/2.0 connection. Streams have several important characteristics: o A single HTTP/2.0 connection can contain multiple concurrently open streams, with either endpoint interleaving frames from multiple streams. @@ -1042,21 +1051,21 @@ A RST_STREAM is the last frame that an endpoint can send on a stream. The peer that sends the RST_STREAM frame MUST be prepared to receive any frames that were sent or enqueued for sending by the remote peer. These frames can be ignored, except where they modify connection state (such as the state maintained for header compression (Section 4.3)). Normally, an endpoint SHOULD NOT send more than one RST_STREAM frame for any stream. However, an endpoint MAY send additional RST_STREAM frames if it receives frames on a closed stream after more than a - round trip time. This behavior is permitted to deal with misbehaving + round-trip time. This behavior is permitted to deal with misbehaving implementations. An endpoint MUST NOT send a RST_STREAM in response to an RST_STREAM frame, to avoid looping. 5.4.3. Connection Termination If the TCP connection is torn down while streams remain in open or half closed states, then the endpoint MUST assume that the stream was abnormally interrupted and could be incomplete. @@ -1080,72 +1089,68 @@ 6.1. DATA DATA frames (type=0x0) convey arbitrary, variable-length sequences of octets associated with a stream. One or more DATA frames are used, for instance, to carry HTTP request or response payloads. The DATA frame defines the following flags: END_STREAM (0x1): Bit 1 being set indicates that this frame is the last that the endpoint will send for the identified stream. - Setting this flag causes the stream to enter a "half closed" or - "closed" state (Section 5.1). + Setting this flag causes the stream to enter one of "half closed" + states or "closed" state (Section 5.1). RESERVED (0x2): Bit 2 is reserved for future use. DATA frames MUST be associated with a stream. If a DATA frame is received whose stream identifier field is 0x0, the recipient MUST respond with a connection error (Section 5.4.1) of type PROTOCOL_ERROR. DATA frames are subject to flow control and can only be sent when a - stream is in the "open" or "half closed (remote)" states. + stream is in the "open" or "half closed (remote)" states. If a DATA + frame is received whose stream is not in "open" or "half closed + (local)" state, the recipient MUST respond with a connection error + (Section 5.4.1) of type PROTOCOL_ERROR. 6.2. HEADERS The HEADERS frame (type=0x1) carries name-value pairs. It is used to open a stream (Section 5.1). HEADERS frames can be sent on a stream in the "open" or "half closed (remote)" states. 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| Priority (31) | +-+-------------------------------------------------------------+ | Header Block Fragment (*) ... +---------------------------------------------------------------+ HEADERS Frame Payload The HEADERS frame defines the following flags: - END_STREAM (0x1): Bit 1 being set indicates that this frame is the - last that the endpoint will send for the identified stream. - Setting this flag causes the stream to enter a "half closed" state - (Section 5.1). + END_STREAM (0x1): Bit 1 being set indicates that the header block + (Section 4.3) is the last that the endpoint will send for the + identified stream. Setting this flag causes the stream to enter + one of "half closed" states (Section 5.1). A HEADERS frame that is followed by CONTINUATION frames carries - the flag that signals the end of a stream. A CONTINUATION frame - cannot be used to terminate a stream. + the END_STREAM flag that signals the end of a stream. A + CONTINUATION frame cannot be used to terminate a stream. RESERVED (0x2): Bit 2 is reserved for future use. - END_HEADERS (0x4): Bit 3 being set indicates that this frame ends - the sequence of header block fragments necessary to provide a - complete set of header fields. - - The payload for a complete header block is provided by a sequence - of that starts with a HEADERS frame, followed by zero or more - CONTINUATION frames. The sequence is terminated by a frame with - the END_HEADERS flag set. Once the sequence terminates, the - payload of all HEADERS and CONTINUATION frames are concatenated - and interpreted as a single block. + END_HEADERS (0x4): Bit 3 being set indicates that this frame + contains an entire header block (Section 4.3) and is not followed + by any CONTINUATION frames. A HEADERS frame without the END_HEADERS flag set MUST be followed by a CONTINUATION frame for the same stream. A receiver MUST treat the receipt of any other type of frame or a frame on a different stream as a connection error (Section 5.4.1) of type PROTOCOL_ERROR. PRIORITY (0x8): Bit 4 being set indicates that the first four octets of this frame contain a single reserved bit and a 31-bit priority; see Section 5.3. If this bit is not set, the four bytes do not @@ -1236,20 +1241,26 @@ If a RST_STREAM frame identifying an idle stream is received, the recipient MUST treat this as a connection error (Section 5.4.1) of type PROTOCOL_ERROR. 6.5. SETTINGS The SETTINGS frame (type=0x4) conveys configuration parameters that affect how endpoints communicate. The parameters are either constraints on peer behavior or preferences. + Settings are not negotiated. Settings describe characteristics of + the sending peer, which are used by the receiving peer. Different + values for the same setting can be advertised by each peer. For + example, a client might set a high initial flow control window, + whereas a server might set a lower value to conserve resources. + SETTINGS frames MUST be sent at the start of a connection, and MAY be sent at any other time by either endpoint over the lifetime of the connection. Implementations MUST support all of the settings defined by this specification and MAY support additional settings defined by extensions. Unsupported or unrecognized settings MUST be ignored. New settings MUST NOT be defined or implemented in a way that requires endpoints to understand them in order to communicate successfully. @@ -1298,33 +1309,35 @@ +---------------------------------------------------------------+ Setting Format 6.5.2. Defined Settings The following settings are defined: SETTINGS_HEADER_TABLE_SIZE (1): Allows the sender to inform the remote endpoint of the size of the header compression table used - to decode header blocks. The default value is 4096 bytes. + to decode header blocks. The space available for encoding cannot + be changed; it is determined by the setting sent by the peer that + receives the header blocks. The initial value is 4096 bytes. SETTINGS_ENABLE_PUSH (2): This setting can be use to disable server push (Section 8.2). An endpoint MUST NOT send a PUSH_PROMISE frame if it receives this setting set to a value of 0. The - default value is 1, which indicates that push is permitted. + initial value is 1, which indicates that push is permitted. SETTINGS_MAX_CONCURRENT_STREAMS (4): Indicates the maximum number of concurrent streams that the sender will allow. This limit is directional: it applies to the number of streams that the sender - permits the receiver to create. By default there is no limit. It - is recommended that this value be no smaller than 100, so as to - not unnecessarily limit parallelism. + permits the receiver to create. Initially there is no limit to + this value. It is recommended that this value be no smaller than + 100, so as to not unnecessarily limit parallelism. SETTINGS_INITIAL_WINDOW_SIZE (7): Indicates the sender's initial window size (in bytes) for stream level flow control. This settings affects the window size of all streams, including existing streams, see Section 6.9.2. SETTINGS_FLOW_CONTROL_OPTIONS (10): Indicates flow control options. The least significant bit (0x1) of the value is set to indicate that the sender has disabled all flow control. This bit cannot be @@ -1333,37 +1346,39 @@ All bits other than the least significant are reserved. 6.5.3. Settings Synchronization Most values in SETTINGS benefit from or require an understanding of when the peer has received and applied the changed setting values. In order to provide such synchronization timepoints, the recipient of a SETTINGS frame in which the ACK flag is not set MUST apply the updated settings as soon as possible upon receipt. - The values in the SETTINGS frame MUST be applied in sequence, with no - other frame processing between values. Once all values have been - applied, the recipient MUST immediately emit a SETTINGS frame with - the ACK flag set. + The values in the SETTINGS frame MUST be applied in the order they + appear, with no other frame processing between values. Once all + values have been applied, the recipient MUST immediately emit a + SETTINGS frame with the ACK flag set. The sender of altered settings + applies changes upon receiving a SETTINGS frame with the ACK flag + set. If the sender of a SETTINGS frame does not receive an acknowledgement within a reasonable amount of time, it MAY issue a connection error (Section 5.4.1) of type SETTINGS_TIMEOUT. 6.6. PUSH_PROMISE The PUSH_PROMISE frame (type=0x5) is used to notify the peer endpoint in advance of streams the sender intends to initiate. The PUSH_PROMISE frame includes the unsigned 31-bit identifier of the - stream the endpoint plans to create along with a minimal set of - headers that provide additional context for the stream. Section 8.2 - contains a thorough description of the use of PUSH_PROMISE frames. + stream the endpoint plans to create along with a set of headers that + provide additional context for the stream. Section 8.2 contains a + thorough description of the use of PUSH_PROMISE frames. PUSH_PROMISE MUST NOT be sent if the SETTINGS_ENABLE_PUSH setting of the peer endpoint is set to 0. 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| Promised-Stream-ID (31) | +-+-------------------------------------------------------------+ | Header Block Fragment (*) ... @@ -1380,31 +1395,23 @@ Following the "Promised-Stream-ID" is a header block fragment (Section 4.3). PUSH_PROMISE frames MUST be associated with an existing, peer- initiated stream. If the stream identifier field specifies the value 0x0, a recipient MUST respond with a connection error (Section 5.4.1) of type PROTOCOL_ERROR. The PUSH_PROMISE frame defines the following flags: - END_PUSH_PROMISE (0x4): The END_PUSH_PROMISE bit indicates that this - frame ends the sequence of header block fragments necessary to - provide a complete set of headers. - - The payload for a complete header block is provided by a sequence - of frames that starts with a PUSH_PROMISE frame, followed by zero - or more CONTINUATION frames. The sequence terminates by a - PUSH_PROMISE frame with the END_PUSH_PROMISE flag set or a - CONTINUATION frame with the END_HEADERS flag set. Once the - sequence terminates, the payload of all frames in the sequence are - concatenated and interpreted as a single block. + END_PUSH_PROMISE (0x4): Bit 3 being set indicates that this frame + contains an entire header block (Section 4.3) and is not followed + by any CONTINUATION frames. A PUSH_PROMISE frame without the END_PUSH_PROMISE flag set MUST be followed by a CONTINUATION frame for the same stream. A receiver MUST treat the receipt of any other type of frame or a frame on a different stream as a connection error (Section 5.4.1) of type PROTOCOL_ERROR. Promised streams are not required to be used in order promised. The PUSH_PROMISE only reserves stream identifiers for later use. @@ -1742,65 +1749,55 @@ re-enable flow control - by sending a WINDOW_UPDATE or by clearing the bits on the SETTINGS_FLOW_CONTROL_OPTIONS setting - MUST be rejected with a FLOW_CONTROL_ERROR error code. 6.10. CONTINUATION The CONTINUATION frame (type=0xA) is used to continue a sequence of header block fragments (Section 4.3). Any number of CONTINUATION frames can be sent on an existing stream, as long as the preceding frame on the same stream is one of HEADERS, PUSH_PROMISE or - CONTINUATION. + CONTINUATION without the END_HEADERS or END_PUSH_PROMISE flag set. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Header Block Fragment (*) ... +---------------------------------------------------------------+ CONTINUATION Frame Payload The CONTINUATION frame defines the following flags: - END_HEADERS (0x4): The END_HEADERS bit indicates that this frame - ends the sequence of header block fragments necessary to provide a - complete set of header fields. - - The payload for a complete header block is provided by a sequence - that starts with a HEADERS or PUSH_PROMISE frame and zero or more - CONTINUATION frames, terminated by a HEADERS or CONTINUATION frame - with the END_HEADERS flag set, or PUSH_PROMISE frame with the - END_PUSH_PROMISE flag set. Once the sequence terminates, the - payload of all frames in the sequence are concatenated and - interpreted as a single block. + END_HEADERS (0x4): Bit 3 being set indicates that this frame ends a + header block (Section 4.3). - A HEADERS, PUSH_PROMISE, or CONTINUATION frame without the - END_HEADERS flag set MUST be followed by a CONTINUATION frame for - the same stream. A receiver MUST treat the receipt of any other - type of frame or a frame on a different stream as a connection - error (Section 5.4.1) of type PROTOCOL_ERROR. + If the END_HEADERS bit is not set, this frame MUST be followed by + another CONTINUATION frame. A receiver MUST treat the receipt of + any other type of frame or a frame on a different stream as a + connection error (Section 5.4.1) of type PROTOCOL_ERROR. The payload of a CONTINUATION frame contains a header block fragment (Section 4.3). The CONTINUATION frame changes the connection state as defined in Section 4.3. CONTINUATION frames MUST be associated with a stream. If a CONTINUATION frame is received whose stream identifier field is 0x0, the recipient MUST respond with a connection error (Section 5.4.1) of type PROTOCOL_ERROR. A CONTINUATION frame MUST be preceded by a HEADERS, PUSH_PROMISE or - CONTINUATION frame. A recipient that observes violation of this rule - MUST respond with a connection error (Section 5.4.1) of type - PROTOCOL_ERROR. + CONTINUATION frame without the END_HEADERS flag set. A recipient + that observes violation of this rule MUST respond with a connection + error (Section 5.4.1) of type PROTOCOL_ERROR. 7. Error Codes Error codes are 32-bit fields that are used in RST_STREAM and GOAWAY frames to convey the reasons for the stream or connection error. Error codes share a common code space. Some error codes only apply to specific conditions and have no defined semantics in certain frame types. @@ -2093,22 +2090,23 @@ A malformed request or response is one that uses a valid sequence of HTTP/2.0 frames, but is otherwise invalid due to the presence of prohibited header fields, the absence of mandatory header fields, or the inclusion of uppercase header field names. A request or response that includes an entity body can include a "content-length" header field. A request or response is also malformed if the value of a "content-length" header field does not equal the sum of the DATA frame payload lengths that form the body. - Intermediaries MAY forward a malformed request or response, but only - if the frames are forwarded without inspection of header fields. + Intermediaries that process HTTP requests or responses (i.e., all + intermediaries other than those acting as tunnels) MUST NOT forward a + malformed request or response. Implementations that detect malformed requests or responses need to ensure that the stream ends. For malformed requests, a server MAY send an HTTP response to prior to closing or resetting the stream. Clients MUST NOT accept a malformed response. 8.1.4. Request Reliability Mechanisms in HTTP/2.0 In HTTP/1.1, an HTTP client is unable to retry a non-idempotent request when an error occurs, because there is no means to determine @@ -2413,23 +2411,23 @@ to HTTP/2.0 MUST remove any instances of the "obs-fold" production from header field values. 10.4. Cacheability of Pushed Resources Pushed resources are responses without an explicit request; the request for a pushed resource is synthesized from the request that triggered the push, plus resource identification information provided by the server. Request header fields are necessary for HTTP cache control validations (such as the Vary header field) to work. For - this reason, caches MUST inherit request header fields from the - associated stream for the push. This includes the Cookie header - field. + this reason, caches MUST associate the request header fields from the + PUSH_PROMISE frame with the response headers and content delivered on + the pushed stream. This includes the Cookie header field. Caching resources 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 @@ -2733,47 +2731,51 @@ [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992. [TALKING] Huang, L-S., Chen, E., Barth, A., Rescorla, E., and C. Jackson, "Talking to Yourself for Fun and Profit", 2011, . Appendix A. Change Log (to be removed by RFC Editor before publication) -A.1. Since draft-ietf-httpbis-http2-06 +A.1. Since draft-ietf-httpbis-http2-07 + + Marked draft for implementation. + +A.2. Since draft-ietf-httpbis-http2-06 Adding definition for CONNECT method. Constraining the use of push to safe, cacheable methods with no request body. Changing from :host to :authority to remove any potential confusion. Adding setting for header compression table size. Adding settings acknowledgement. Removing unnecessary and potentially problematic flags from CONTINUATION. Added denial of service considerations. -A.2. Since draft-ietf-httpbis-http2-05 +A.3. Since draft-ietf-httpbis-http2-05 Marking the draft ready for implementation. Renumbering END_PUSH_PROMISE flag. Editorial clarifications and changes. -A.3. Since draft-ietf-httpbis-http2-04 +A.4. Since draft-ietf-httpbis-http2-04 Added CONTINUATION frame for HEADERS and PUSH_PROMISE. PUSH_PROMISE is no longer implicitly prohibited if SETTINGS_MAX_CONCURRENT_STREAMS is zero. Push expanded to allow all safe methods without a request body. Clarified the use of HTTP header fields in requests and responses. Prohibited HTTP/1.1 hop-by-hop header fields. @@ -2784,48 +2786,48 @@ Clarified requirements around handling different frames after stream close, stream reset and GOAWAY. Added more specific prohibitions for sending of different frame types in various stream states. Making the last received setting value the effective value. Clarified requirements on TLS version, extension and ciphers. -A.4. Since draft-ietf-httpbis-http2-03 +A.5. Since draft-ietf-httpbis-http2-03 Committed major restructuring atrocities. Added reference to first header compression draft. Added more formal description of frame lifecycle. Moved END_STREAM (renamed from FINAL) back to HEADERS/DATA. Removed HEADERS+PRIORITY, added optional priority to HEADERS frame. Added PRIORITY frame. -A.5. Since draft-ietf-httpbis-http2-02 +A.6. Since draft-ietf-httpbis-http2-02 Added continuations to frames carrying header blocks. Replaced use of "session" with "connection" to avoid confusion with other HTTP stateful concepts, like cookies. Removed "message". Switched to TLS ALPN from NPN. Editorial changes. -A.6. Since draft-ietf-httpbis-http2-01 +A.7. Since draft-ietf-httpbis-http2-01 Added IANA considerations section for frame types, error codes and settings. Removed data frame compression. Added PUSH_PROMISE. Added globally applicable flags to framing. @@ -2844,39 +2846,39 @@ Restructured frame header. Removed distinction between data and control frames. Altered flow control properties to include session-level limits. Added note on cacheability of pushed resources and multiple tenant servers. Changed protocol label form based on discussions. -A.7. Since draft-ietf-httpbis-http2-00 +A.8. Since draft-ietf-httpbis-http2-00 Changed title throughout. Removed section on Incompatibilities with SPDY draft#2. Changed INTERNAL_ERROR on GOAWAY to have a value of 2 . Replaced abstract and introduction. Added section on starting HTTP/2.0, including upgrade mechanism. Removed unused references. Added flow control principles (Section 5.2.1) based on . -A.8. Since draft-mbelshe-httpbis-spdy-00 +A.9. Since draft-mbelshe-httpbis-spdy-00 Adopted as base for draft-ietf-httpbis-http2. Updated authors/editors list. Added status note. Authors' Addresses Mike Belshe @@ -2888,20 +2890,20 @@ Google, Inc EMail: fenix@google.com Martin Thomson (editor) Microsoft 3210 Porter Drive Palo Alto 94304 US - EMail: martin.thomson@skype.net + EMail: martin.thomson@gmail.com Alexey Melnikov (editor) Isode Ltd 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK EMail: Alexey.Melnikov@isode.com