diff --git a/draft-mbelshe-httpbis-spdy-00.txt b/draft-mbelshe-httpbis-spdy-00.txt index d8ee2ac..3b92caf 100644 --- a/draft-mbelshe-httpbis-spdy-00.txt +++ b/draft-mbelshe-httpbis-spdy-00.txt @@ -72,32 +72,32 @@ Table of Contents 2.1. Session (Connections) . . . . . . . . . . . . . . . . . . 6 2.2. Framing . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2.1. Notational Conventions for Framing . . . . . . . . . . 6 - 2.2.2. Control frames . . . . . . . . . . . . . . . . . . . . 8 - 2.2.3. Data frames . . . . . . . . . . . . . . . . . . . . . 9 - 2.3. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 2.3.1. Stream frames . . . . . . . . . . . . . . . . . . . . 10 - 2.3.2. Stream creation . . . . . . . . . . . . . . . . . . . 10 - 2.3.3. Stream priority . . . . . . . . . . . . . . . . . . . 11 - 2.3.4. Stream headers . . . . . . . . . . . . . . . . . . . . 11 - 2.3.5. Stream data exchange . . . . . . . . . . . . . . . . . 11 - 2.3.6. Stream half-close . . . . . . . . . . . . . . . . . . 11 - 2.3.7. Stream close . . . . . . . . . . . . . . . . . . . . . 12 - 2.4. Error Handling . . . . . . . . . . . . . . . . . . . . . . 12 - 2.4.1. Session Error Handling . . . . . . . . . . . . . . . . 12 - 2.4.2. Stream Error Handling . . . . . . . . . . . . . . . . 13 - 2.5. Data flow . . . . . . . . . . . . . . . . . . . . . . . . 13 - 2.6. Control frame types . . . . . . . . . . . . . . . . . . . 14 - 2.6.1. SYN_STREAM . . . . . . . . . . . . . . . . . . . . . . 14 - 2.6.2. SYN_REPLY . . . . . . . . . . . . . . . . . . . . . . 15 - 2.6.3. RST_STREAM . . . . . . . . . . . . . . . . . . . . . . 16 - 2.6.4. SETTINGS . . . . . . . . . . . . . . . . . . . . . . . 18 - 2.6.5. PING . . . . . . . . . . . . . . . . . . . . . . . . . 21 - 2.6.6. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . . 21 - 2.6.7. HEADERS . . . . . . . . . . . . . . . . . . . . . . . 23 - 2.6.8. WINDOW_UPDATE . . . . . . . . . . . . . . . . . . . . 23 - 2.6.9. CREDENTIAL . . . . . . . . . . . . . . . . . . . . . . 26 - 2.6.10. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . . 28 - 2.6.11. Name/Value Header Block . . . . . . . . . . . . . . . 29 + 2.2.2. Frame Format . . . . . . . . . . . . . . . . . . . . . 8 + 2.3. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 2.3.1. Stream frames . . . . . . . . . . . . . . . . . . . . 9 + 2.3.2. Stream creation . . . . . . . . . . . . . . . . . . . 9 + 2.3.3. Stream priority . . . . . . . . . . . . . . . . . . . 10 + 2.3.4. Stream headers . . . . . . . . . . . . . . . . . . . . 10 + 2.3.5. Stream data exchange . . . . . . . . . . . . . . . . . 10 + 2.3.6. Stream half-close . . . . . . . . . . . . . . . . . . 10 + 2.3.7. Stream close . . . . . . . . . . . . . . . . . . . . . 11 + 2.4. Error Handling . . . . . . . . . . . . . . . . . . . . . . 11 + 2.4.1. Session Error Handling . . . . . . . . . . . . . . . . 11 + 2.4.2. Stream Error Handling . . . . . . . . . . . . . . . . 12 + 2.5. Data flow . . . . . . . . . . . . . . . . . . . . . . . . 12 + 2.6. Frame Types . . . . . . . . . . . . . . . . . . . . . . . 13 + 2.6.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 2.6.2. SYN_STREAM . . . . . . . . . . . . . . . . . . . . . . 14 + 2.6.3. SYN_REPLY . . . . . . . . . . . . . . . . . . . . . . 15 + 2.6.4. RST_STREAM . . . . . . . . . . . . . . . . . . . . . . 16 + 2.6.5. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . . 17 + 2.6.6. SETTINGS . . . . . . . . . . . . . . . . . . . . . . . 18 + 2.6.7. PING . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 2.6.8. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . . 22 + 2.6.9. HEADERS . . . . . . . . . . . . . . . . . . . . . . . 23 + 2.6.10. WINDOW_UPDATE . . . . . . . . . . . . . . . . . . . . 24 + 2.6.11. CREDENTIAL . . . . . . . . . . . . . . . . . . . . . . 26 + 2.6.12. Name/Value Header Block . . . . . . . . . . . . . . . 28 3. HTTP Layering over SPDY . . . . . . . . . . . . . . . . . . . 36 3.1. Connection Management . . . . . . . . . . . . . . . . . . 36 3.1.1. Use of GOAWAY . . . . . . . . . . . . . . . . . . . . 36 @@ -295,7 +295,7 @@ Internet-Draft SPDY August 2012 closes the connection. Servers are encouraged to leave connections open for as long as possible, but can terminate idle connections if necessary. When either endpoint closes the transport-level - connection, it MUST first send a GOAWAY (Section 2.6.6) frame so that + connection, it MUST first send a GOAWAY (Section 2.6.8) frame so that the endpoints can reliably determine if requests finished before the close. It is expected that battery-operated clients may have more involved heuristics as to when a connection should be closed. @@ -303,13 +303,11 @@ Internet-Draft SPDY August 2012 2.2. Framing Once the connection is established, clients and servers exchange - framed messages. There are two types of frames: control frames - (Section 2.2.2) and data frames (Section 2.2.3). + framed messages. - Both types of frames carry a common set of headers: length, flags, - and frame type. Flag definitions vary between control and data - frames. The simple header is designed to make reading and writing of - frames easy. + All frames carry a common set of headers: length, type, and flags. + Flag definitions vary between frame types. The simple header format + is designed to make reading and writing of frames easy. All integer values, including length, and type, are in network byte order. SPDY does not enforce alignment of types in dynamically sized @@ -328,6 +326,8 @@ Internet-Draft SPDY August 2012 "=" denotes an unknown number of bits, typically bounded by one of the fields in the frame definition + "|" denotes field separation, which may or may not be on a byte + boundary. This does not count as a bit @@ -337,9 +337,6 @@ Belshe & Peon Expires February 2, 2013 [Page 6] Internet-Draft SPDY August 2012 - "|" denotes field separation, which may or may not be on a byte - boundary. This does not count as a bit - "->" at the end of a line indicates that the structure is not yet fully described @@ -378,21 +375,6 @@ Internet-Draft SPDY August 2012 continues, describing that an indeterminate (presumably defined elsewhere) amount of data follows and ends on a byte boundary. - - - - - - - - - - -Belshe & Peon Expires February 2, 2013 [Page 7] - -Internet-Draft SPDY August 2012 - - 0 +--|-|-|----+ |01|K|L|XXXX| -> @@ -403,115 +385,69 @@ Internet-Draft SPDY August 2012 | data | +========+ -2.2.2. Control frames - - 0 1 2 3 4 5 6 7 - +--------+--------+--------+-|-------+--------+--------+--------+--------+ - | Length(16) |Flags(8)|1| Num-of-Entries-or-Stream-ID-or-ID|Type(8) | -> - +--------+--------+--------+-|-------+--------+--------+--------+--------+ - 8..N - +========+ - | Data | - +========+ - Control bit: The 'C' bit is a single bit indicating if this is a - control message. For control frames this value is always 1. - Type: The type of control frame. See Control Frames (Section 2.6) - for the complete list of control frames. - - Flags: Flags related to this frame. Flags for control frames and - data frames are different. - - Length: An unsigned 16-bit value representing the number of bytes - after the length field. - Data: data associated with this control frame. The format and length - of this data is controlled by the control frame type. - - Control frame processing requirements: - - Note that full length control frames (16kb) can be large for - implementations running on resource-limited hardware. In such - cases, implementations MAY limit the maximum length frame - supported. However, all implementations MUST be able to receive - control frames of at least 8192 octets in length. - - - - - - - - -Belshe & Peon Expires February 2, 2013 [Page 8] +Belshe & Peon Expires February 2, 2013 [Page 7] Internet-Draft SPDY August 2012 -2.2.3. Data frames +2.2.2. Frame Format - 0 1 2 3 4 5 6 7..N - +--------+--------+--------+-|-------+--------+--------+--------+========+ - | Length(16) |Flags(8)|0| Stream ID (31) | Data | - +--------+--------+--------+-|-------+--------+--------+--------+========+ - - Control bit: For data frames this value is always 0. - - Stream-ID: A 31-bit value identifying the stream. - - Flags: Flags related to this frame. Valid flags are: - - 0x01 = FLAG_FIN - signifies that this frame represents the last - frame to be transmitted on this stream. See Stream Close - (Section 2.3.7) below. + 0 1 2 3 4 5 6 7 + +--------+--------+--------+--------+--------+--------+--------+--------+ + | Length(16) |Type(8) |Flags(8)| Num-of-Entries-or-Stream-ID-or-ID | -> + +--------+--------+--------+--------+--------+--------+--------+--------+ - 0x02 = MSG_DONE - signifies that this frame represents the last - frame of a message. This is relevant for layering of message- - based protocols on top of SPDY. + 8..N + +========+ + | Data | + +========+ - Length: An unsigned 16-bit value representing the number of bytes - after the length field. The total size of a data frame is 8 bytes + - length. It is valid to have a zero-length data frame. + Length: An unsigned 16-bit value representing the number of bytes of + the data field. - Data: The variable-length data payload; the length was defined in the - length field. + Type: The frame type. See Frame Types (Section 2.6) for the complete + list of frames. - Data frame processing requirements: + Flags: Flags related to this frame. Flag definitions are dependent + upon the frame type. - If an endpoint receives a data frame for a stream-id which is not - open and the endpoint has not sent a GOAWAY (Section 2.6.6) frame, - it MUST issue a stream error (Section 2.4.2) with the error code - INVALID_STREAM for the stream-id. + Data: data associated with this control frame. The format of this + data is controlled by the frame type. - If the endpoint which created the stream receives a data frame - before receiving a SYN_REPLY on that stream, it is a protocol - error, and the recipient MUST issue a stream error (Section 2.4.2) - with the status code PROTOCOL_ERROR for the stream-id. + Frame processing requirements: - Implementors note: If an endpoint receives multiple data frames - for invalid stream-ids, it MAY close the session. + Note that full length frames (64kb) can be large for + implementations running on resource-limited hardware. In such + cases, implementations MAY limit the maximum length frame + supported. However, all implementations MUST be able to receive + frames of at least 8192 octets in length. 2.3. Streams Streams are independent sequences of bi-directional data divided into frames with several properties: + Streams may be created by either the client or server. + Streams optionally carry a set of name/value header pairs. + Streams can concurrently send data interleaved with other streams. -Belshe & Peon Expires February 2, 2013 [Page 9] - -Internet-Draft SPDY August 2012 + Streams may be cancelled. - Streams may be created by either the client or server. - Streams optionally carry a set of name/value header pairs. - Streams can concurrently send data interleaved with other streams. - Streams may be cancelled. + + +Belshe & Peon Expires February 2, 2013 [Page 8] + +Internet-Draft SPDY August 2012 + 2.3.1. Stream frames @@ -526,7 +462,7 @@ Internet-Draft SPDY August 2012 2.3.2. Stream creation A stream is created by sending a control frame with the type set to - SYN_STREAM (Section 2.6.1). If the server is initiating the stream, + SYN_STREAM (Section 2.6.2). If the server is initiating the stream, the Stream-ID must be even. If the client is initiating the stream, the Stream-ID must be odd. 0 is not a valid Stream-ID. Stream-IDs from each side of the connection must increase monotonically as new @@ -553,14 +489,6 @@ Internet-Draft SPDY August 2012 Once the stream is created, the creator may immediately send HEADERS or DATA frames for that stream, without needing to wait for the - - - -Belshe & Peon Expires February 2, 2013 [Page 10] - -Internet-Draft SPDY August 2012 - - recipient to acknowledge. 2.3.2.1. Unidirectional streams @@ -569,6 +497,14 @@ Internet-Draft SPDY August 2012 Stream-ID, it creates a unidirectional stream which the creating endpoint can use to send frames, but the receiving endpoint cannot. The receiving endpoint is implicitly already in the half-closed + + + +Belshe & Peon Expires February 2, 2013 [Page 9] + +Internet-Draft SPDY August 2012 + + (Section 2.3.6) state. 2.3.2.2. Bidirectional streams @@ -600,8 +536,8 @@ Internet-Draft SPDY August 2012 Once a stream is created, it can be used to send arbitrary amounts of data. Generally this means that a series of data frames will be sent on the stream until a frame containing the FLAG_FIN flag is set. The - FLAG_FIN can be set on a SYN_STREAM (Section 2.6.1), SYN_REPLY - (Section 2.6.2), HEADERS (Section 2.6.7) or a DATA (Section 2.2.3) + FLAG_FIN can be set on a SYN_STREAM (Section 2.6.2), SYN_REPLY + (Section 2.6.3), HEADERS (Section 2.6.9) or a DATA (Section 2.6.1) frame. Once the FLAG_FIN has been sent, the stream is considered to be half-closed. @@ -609,14 +545,6 @@ Internet-Draft SPDY August 2012 When one side of the stream sends a frame with the FLAG_FIN flag set, the stream is half-closed from that endpoint. The sender of the - - - -Belshe & Peon Expires February 2, 2013 [Page 11] - -Internet-Draft SPDY August 2012 - - FLAG_FIN MUST NOT send further frames on that stream. When both sides have half-closed, the stream is closed. @@ -625,6 +553,14 @@ Internet-Draft SPDY August 2012 for the stream with the FIN flag set), it MUST send a RST_STREAM to the sender with the status STREAM_ALREADY_CLOSED. + + + +Belshe & Peon Expires February 2, 2013 [Page 10] + +Internet-Draft SPDY August 2012 + + 2.3.7. Stream close There are 3 ways that streams can be terminated: @@ -663,17 +599,9 @@ Internet-Draft SPDY August 2012 A session error is any error which prevents further processing of the framing layer or which corrupts the session compression state. When a session error occurs, the endpoint encountering the error MAY send - a SETTINGS (Section 2.6.4) frame. Whether or not a SETTINGS - (Section 2.6.4) frame is sent, the endpoint encountering the error - - - -Belshe & Peon Expires February 2, 2013 [Page 12] - -Internet-Draft SPDY August 2012 - - - MUST send a GOAWAY (Section 2.6.6) frame with the stream id of most + a SETTINGS (Section 2.6.6) frame. Whether or not a SETTINGS + (Section 2.6.6) frame is sent, the endpoint encountering the error + MUST send a GOAWAY (Section 2.6.8) frame with the stream id of most recently received stream from the remote endpoint, and the error code for why the session is terminating. After sending the GOAWAY frame, the endpoint MUST close the TCP connection. @@ -681,6 +609,14 @@ Internet-Draft SPDY August 2012 Note that the session compression state is dependent upon both endpoints always processing all compressed data. If an endpoint partially processes a frame containing compressed data without + + + +Belshe & Peon Expires February 2, 2013 [Page 11] + +Internet-Draft SPDY August 2012 + + updating compression state properly, future control frames which use compression will be always be errored. Implementations SHOULD always try to process compressed data so that errors which could be handled @@ -695,7 +631,7 @@ Internet-Draft SPDY August 2012 A stream error is an error related to a specific stream-id which does not affect processing of other streams at the framing layer. Upon a - stream error, the endpoint MUST send a RST_STREAM (Section 2.6.3) + stream error, the endpoint MUST send a RST_STREAM (Section 2.6.4) frame which contains the stream id of the stream where the error occurred and the error status which caused the error. After sending the RST_STREAM, the stream is closed to the sending endpoint. After @@ -724,58 +660,122 @@ Internet-Draft SPDY August 2012 -Belshe & Peon Expires February 2, 2013 [Page 13] + + + + + + + + +Belshe & Peon Expires February 2, 2013 [Page 12] Internet-Draft SPDY August 2012 -2.6. Control frame types - - +------------------+-------------------------------+ - | Type-field value | Control Frame-type | - +------------------+-------------------------------+ - | 0x1 | SYN_STREAM (Section 2.6.1) | - | | | - | 0x2 | SYN_REPLY (Section 2.6.2) | - | | | - | 0x3 | RST_STREAM (Section 2.6.3) | - | | | - | 0x4 | SETTINGS (Section 2.6.4) | - | | | - | 0x6 | PING (Section 2.6.5) | - | | | - | 0x7 | GOAWAY (Section 2.6.6) | - | | | - | 0x8 | HEADERS (Section 2.6.7) | - | | | - | 0x9 | WINDOW_UPDATE (Section 2.6.8) | - | | | - | 0xa | CREDENTIAL (Section 2.6.9) | - | | | - | 0xb | PUSH_PROMISE (Section 2.6.10) | - +------------------+-------------------------------+ +2.6. Frame Types + + +------------------+--------------------------------+ + | Type-field value | Frame type | + +------------------+--------------------------------+ + | 0x0 | DATA (Section 2.6.1) | + | | | + | 0x1 | SYN_STREAM (Section 2.6.2) | + | | | + | 0x2 | SYN_REPLY (Section 2.6.3) | + | | | + | 0x3 | RST_STREAM (Section 2.6.4) | + | | | + | 0x5 | PUSH_PROMISE (Section 2.6.5) | + | | | + | 0x4 | SETTINGS (Section 2.6.6) | + | | | + | 0x6 | PING (Section 2.6.7) | + | | | + | 0x7 | GOAWAY (Section 2.6.8) | + | | | + | 0x8 | HEADERS (Section 2.6.9) | + | | | + | 0x9 | WINDOW_UPDATE (Section 2.6.10) | + | | | + | 0xa | CREDENTIAL (Section 2.6.11) | + +------------------+--------------------------------+ Shared components of several control frames: Name/Value Header Block - (Section 2.6.11) + (Section 2.6.12) + +2.6.1. DATA + + 0 1 2 3 4 5 6 7 + +--------+--------+--------+--------+-|-------+--------+--------+--------+ + | Length(16) | 0x0 |Flags(8)|X| Stream-ID(31) | -> + +--------+--------+--------+--------+-|-------+--------+--------+--------+ + + 8..N + +========+ + | Data | + +========+ + + Length: An unsigned 16-bit value representing the number of bytes + which follow the frame header. The total size of a data frame is 8 + bytes + length. It is valid to have a zero-length data frame. + + Flags: Flags related to this frame. Valid flags are: + + + +Belshe & Peon Expires February 2, 2013 [Page 13] + +Internet-Draft SPDY August 2012 + + + 0x01 = FLAG_FIN - signifies that this frame represents the last + frame to be transmitted on this stream. See Stream Close + (Section 2.3.7) below. + + 0x02 = MSG_DONE - signifies that this frame represents the last + frame of a message. This is relevant for layering of message- + based protocols on top of SPDY. -2.6.1. SYN_STREAM + Stream-ID: A 31-bit value identifying the stream. + + Data: The variable-length data payload; the length was defined in the + length field. + + Data frame processing requirements: + + If an endpoint receives a data frame for a stream-id which is not + open and the endpoint has not sent a GOAWAY (Section 2.6.8) frame, + it MUST issue a stream error (Section 2.4.2) with the error code + INVALID_STREAM for the stream-id. + + If the endpoint which created the stream receives a data frame + before receiving a SYN_REPLY on that stream, it is a protocol + error, and the recipient MUST issue a stream error (Section 2.4.2) + with the status code PROTOCOL_ERROR for the stream-id. + + Implementors note: If an endpoint receives multiple data frames + for invalid stream-ids, it MAY close the session. + +2.6.2. SYN_STREAM The SYN_STREAM control frame allows the sender to asynchronously create a stream between the endpoints. See Stream Creation (Section 2.3.2) - 0 1 2 3 4 5 6 7 - +--------+--------+--------+-|-------+--------+--------+--------+--------+ - | Length(16) |Flags(8)|1| Stream Id(31) | 0x1 | -> - +--------+--------+--------+-|-------+--------+--------+--------+--------+ - - 8 9,10,11..N - +---|-----+=========================+ - |Pri|XXXXX| Name/Value Header Block | - +---|-----+=========================+ + 0 1 2 3 4 5 6 7 + +--------+--------+--------+--------+-|-------+--------+--------+--------+ + | Length(16) | 0x1 |Flags(8)|X| Stream-ID(31) | -> + +--------+--------+--------+--------+-|-------+--------+--------+--------+ - Flags: Flags related to this frame. Valid flags are: + 8 9 10 11 12,13,14..N + +-|-------+--------+--------+--------+=========================+ + |X|Priority(31) | Name/Value Header Block | + +-|-------+--------+--------+--------+=========================+ + Length: An unsigned 16-bit value representing the number of bytes + which follow the frame header. For SYN_STREAM frames, this is 4 + bytes plus the length of the Name/Value Header Block. @@ -785,47 +785,43 @@ Belshe & Peon Expires February 2, 2013 [Page 14] Internet-Draft SPDY August 2012 + Flags: Flags related to this frame. Valid flags are: + 0x01 = FLAG_FIN - marks this frame as the last frame to be transmitted on this stream and puts the sender in the half-closed (Section 2.3.6) state. - Length: The length is the number of bytes which follow the length - field in the frame. For SYN_STREAM frames, this is 6 bytes plus the - length of the Name/Value Header Block. - Stream-ID: The 31-bit identifier for this stream. This stream-id will be used in frames which are part of this stream. - Associated-To-Stream-ID: The 31-bit identifier for a stream which - this stream is associated to. If this stream is independent of all - other streams, it should be 0. - - Priority: A 3-bit priority (Section 2.3.3) field. - - Unused: 5 bits of unused space, reserved for future use. + Priority: A 31-bit priority (Section 2.3.3) field. Name/Value Header Block: A set of name/value pairs carried as part of - the SYN_STREAM. see Name/Value Header Block (Section 2.6.11). + the SYN_STREAM. see Name/Value Header Block (Section 2.6.12). If an endpoint receives a SYN_STREAM which is larger than the implementation supports, it MAY send a RST_STREAM with error code FRAME_TOO_LARGE. All implementations MUST support the minimum size - limits defined in the Control Frames section (Section 2.2.2). + limits defined in the Frame Format section (Section 2.2.2). -2.6.2. SYN_REPLY +2.6.3. SYN_REPLY SYN_REPLY indicates the acceptance of a stream creation by the recipient of a SYN_STREAM frame. - 0 1 2 3 4 5 6 7 - +--------+--------+--------+-|-------+--------+--------+--------+--------+ - | Length(16) |Flags(8)|1| Stream Id(31) | 0x2 | -> - +--------+--------+--------+-|-------+--------+--------+--------+--------+ + 0 1 2 3 4 5 6 7 + +--------+--------+--------+--------+-|-------+--------+--------+--------+ + | Length(16) | 0x2 |Flags(8)|X| Stream-ID(31) | -> + +--------+--------+--------+--------+-|-------+--------+--------+--------+ + + 8,9,10..N + +=========================+ + | Name/Value Header Block | + +=========================+ - 8,9,10..N - +=========================+ - | Name/Value Header Block | - +=========================+ + Length: An unsigned 16-bit value representing the number of bytes + which follow the frame header. For SYN_REPLY frames, this is the + length of the Name/Value Header Block. Flags: Flags related to this frame. Valid flags are: @@ -833,6 +829,10 @@ Internet-Draft SPDY August 2012 transmitted on this stream and puts the sender in the half-closed (Section 2.3.6) state. + Stream-ID: The 31-bit identifier for this stream. + + If an endpoint receives multiple SYN_REPLY frames for the same active + stream ID, it MUST issue a stream error (Section 2.4.2) with the @@ -841,25 +841,17 @@ Belshe & Peon Expires February 2, 2013 [Page 15] Internet-Draft SPDY August 2012 - Length: The length is the number of bytes which follow the length - field in the frame. For SYN_REPLY frames, this is 4 bytes plus the - length of the compressed Name/Value block. - - Stream-ID: The 31-bit identifier for this stream. - - If an endpoint receives multiple SYN_REPLY frames for the same active - stream ID, it MUST issue a stream error (Section 2.4.2) with the error code STREAM_IN_USE. Name/Value Header Block: A set of name/value pairs carried as part of - the SYN_STREAM. see Name/Value Header Block (Section 2.6.11). + the SYN_REPLY. see Name/Value Header Block (Section 2.6.12). If an endpoint receives a SYN_REPLY which is larger than the implementation supports, it MAY send a RST_STREAM with error code FRAME_TOO_LARGE. All implementations MUST support the minimum size - limits defined in the Control Frames section (Section 2.2.2). + limits defined in the Frame Format section (Section 2.2.2). -2.6.3. RST_STREAM +2.6.4. RST_STREAM The RST_STREAM frame allows for abnormal termination of a stream. When sent by the creator of a stream, it indicates the creator wishes @@ -867,36 +859,28 @@ Internet-Draft SPDY August 2012 indicates an error or that the recipient did not want to accept the stream, so the stream should be closed. - 0 1 2 3 4 5 6 7 - +--------+--------+--------+-|-------+--------+--------+--------+--------+ - | Length(16) |Flags(8)|1| Stream Id(31) | 0x3 | -> - +--------+--------+--------+-|-------+--------+--------+--------+--------+ + 0 1 2 3 4 5 6 7 + +--------+--------+--------+--------+-|-------+--------+--------+--------+ + | Length(16) | 0x3 |Flags(8)|X| Stream-ID(31) | -> + +--------+--------+--------+--------+-|-------+--------+--------+--------+ + + 8 9 10 11 + +--------+--------+--------+--------+ + | Status-Code(32) | + +--------+--------+--------+--------+ - 8 9 10 11 - +--------+--------+--------+--------+ - | Status-Code(32) | - +--------+--------+--------+--------+ + Length: An unsigned 16-bit value representing the number of bytes + which follow the frame header. For RST_STREAM frames, this value is + always 4. Flags: Flags related to this frame. RST_STREAM does not define any flags. This value must be 0. - Length: An unsigned 16-bit value representing the number of bytes - after the length field. For RST_STREAM control frames, this value is - always 8. - Stream-ID: The 31-bit identifier for this stream. Status code: (32 bits) An indicator for why the stream is being terminated.The following status codes are defined: - - - -Belshe & Peon Expires February 2, 2013 [Page 16] - -Internet-Draft SPDY August 2012 - - 1 - PROTOCOL_ERROR. This is a generic error, and should only be used if a more specific error is not available. @@ -906,6 +890,13 @@ Internet-Draft SPDY August 2012 3 - REFUSED_STREAM. Indicates that the stream was refused before any processing has been done on the stream. + + +Belshe & Peon Expires February 2, 2013 [Page 16] + +Internet-Draft SPDY August 2012 + + 4 - UNSUPPORTED_VERSION. Indicates that the recipient of a stream does not support the SPDY version requested. @@ -942,6 +933,15 @@ Internet-Draft SPDY August 2012 additional frames for that stream, and the stream moves into the closed state. +2.6.5. PUSH_PROMISE + + The PUSH_PROMISE control frame allows the sender to signal a promise + to create a stream and serve the referenced resource. Minimal data + allowing the receiver to understand which resource(s) are to be + pushed are to be included. + + + @@ -953,12 +953,62 @@ Belshe & Peon Expires February 2, 2013 [Page 17] Internet-Draft SPDY August 2012 -2.6.4. SETTINGS + 0 1 2 3 4 5 6 7 + +--------+--------+--------+--------+-|-------+--------+--------+--------+ + | Length(16) | 0x5 |Flags(8)|X| Associated-To-Stream-ID(31) | -> + +--------+--------+--------+--------+-|-------+--------+--------+--------+ + + 8 9 10 11 12,13,14..N + +-|-------+--------+--------+--------+=========================+ + |X| Promised-Stream-ID(31) | Name/Value Header Block | + +-|-------+--------+--------+--------+=========================+ + + Length: An unsigned 16-bit value representing the number of bytes + which follow the frame header. For PUSH_PROMISE frames, this is 4 + bytes plus the length of the Name/Value Header Block. + + Flags: Flags related to this frame. Valid flags are: + + 0x01 = FLAG_FIN - marks this frame as the last frame to be + transmitted on this stream and puts the sender in the half-closed + (Section 2.3.6) state. + + Associated-To-Stream-ID: The 31-bit identifier for a stream which + this stream is associated to. If this stream is independent of all + other streams, it should be 0. + + Promised-Stream-ID: The 31-bit identifier indicating the stream-id on + which the resource will be pushed. If multiple headers are indicated + within the Name/Value Header Block, each subsequent resource as + indicated in the Header Block will increment the Promised-Stream-Id + by two. The Promised-Stream-ID is subject to the same rules as any + other stream-id-- when defined and transmitted, the + Promised-Stream-ID MUST be part of a monotonically increasing + sequence of stream-ids. There is no requirement that the streams + referred to by the this frame are created in the order referenced. + + Name/Value Header Block: A set of name/value pairs carried as part of + the PUSH_PROMISE. see Name/Value Header Block (Section 2.6.12). + + If an endpoint receives a PUSH_PROMISE which is larger than the + implementation supports, it MAY send a RST_STREAM with error code + FRAME_TOO_LARGE. All implementations MUST support the minimum size + limits defined in the Frame Format section (Section 2.2.2). + +2.6.6. SETTINGS A SETTINGS frame contains a set of id/value pairs for communicating configuration data about how the two endpoints may communicate. SETTINGS frames can be sent at any time by either endpoint, are optionally sent, and are fully asynchronous. When the server is the + + + +Belshe & Peon Expires February 2, 2013 [Page 18] + +Internet-Draft SPDY August 2012 + + sender, the sender can request that configuration data be persisted by the client across SPDY sessions and returned to the server in future communications. @@ -972,17 +1022,19 @@ Internet-Draft SPDY August 2012 persistence features of the SETTINGS frames, and servers MUST ignore persistence related flags sent by a client. - 0 1 2 3 4 5 6 7 - +--------+--------+--------+-|-------+--------+--------+--------+--------+ - | Length(16) |Flags(8)|1| Number-of-Entries(31) | 0x4 | -> - +--------+--------+--------+-|-------+--------+--------+--------+--------+ + 0 1 2 3 4 5 6 7 + +--------+--------+--------+--------+-|-------+--------+--------+--------+ + | Length(16) | 0x4 |Flags(8)|X|Number-of-Entries(31) | -> + +--------+--------+--------+--------+-|-------+--------+--------+--------+ - 8..n - +================+ - | ID/Value-Pairs | - +================+ + 8..N + +================+ + | ID/Value-Pairs | + +================+ - Control bit: The control bit is always 1 for this message. + Length: An unsigned 16-bit value representing the number of bytes + which follow the frame header. For SETTINGS frames, this is the + length of the ID/Value-Pairs Block. Type: The message type for a SETTINGS message is 4. @@ -995,20 +1047,9 @@ Internet-Draft SPDY August 2012 is only implemented on the client, this flag can only be used when the sender is the server. - Length: An unsigned 16-bit value representing the number of bytes - after the length field. The total size of a SETTINGS frame is 8 - bytes + length. - Number of entries: A 32-bit value representing the number of ID/value pairs in this message. - - -Belshe & Peon Expires February 2, 2013 [Page 18] - -Internet-Draft SPDY August 2012 - - Each ID/value pair is as follows: 0 1 2 3 4 5 6 7 @@ -1016,6 +1057,14 @@ Internet-Draft SPDY August 2012 |Flags(8)| ID(24) | Value(32) | +--------+--------+--------+--------+--------+--------+--------+--------+ + + + +Belshe & Peon Expires February 2, 2013 [Page 19] + +Internet-Draft SPDY August 2012 + + Flags: An 8 bit value. Defined Flags: FLAG_SETTINGS_PERSIST_VALUE (0x1): When set, the sender of this @@ -1058,19 +1107,20 @@ Internet-Draft SPDY August 2012 5 - SETTINGS_CURRENT_CWND allows the sender to inform the remote endpoint of the current TCP CWND value. - - -Belshe & Peon Expires February 2, 2013 [Page 19] - -Internet-Draft SPDY August 2012 - - 6 - SETTINGS_DOWNLOAD_RETRANS_RATE allows the sender to inform the remote endpoint the retransmission rate (bytes retransmitted / total bytes transmitted). 7 - SETTINGS_INITIAL_WINDOW_SIZE allows the sender to inform the remote endpoint the initial window size (in bytes) for new + + + +Belshe & Peon Expires February 2, 2013 [Page 20] + +Internet-Draft SPDY August 2012 + + streams. 8 - SETTINGS_CLIENT_CERTIFICATE_VECTOR_SIZE allows the server to @@ -1110,18 +1160,7 @@ Internet-Draft SPDY August 2012 state on its next SETTINGS frame, it SHOULD send all 5 settings (1, 2, 3, 4, and 5 in this example) to the server. - - - - - - -Belshe & Peon Expires February 2, 2013 [Page 20] - -Internet-Draft SPDY August 2012 - - -2.6.5. PING +2.6.7. PING The PING control frame is a mechanism for measuring a minimal round- trip time from the sender. It can be sent from the client or the @@ -1130,17 +1169,22 @@ Internet-Draft SPDY August 2012 waiting to be sent, PING should take highest priority). Each ping sent by a sender should use a unique ID. - 0 1 2 3 4 5 6 7 - +--------+--------+--------+-|-------+--------+--------+--------+--------+ - | Length(16) |XXXXXXXX|1| ID(31) | 0x6 | -> - +--------+--------+--------+-|-------+--------+--------+--------+--------+ - Control bit: The control bit is always 1 for this message. - Type: The message type for a PING message is 6. +Belshe & Peon Expires February 2, 2013 [Page 21] + +Internet-Draft SPDY August 2012 - Length: This frame is always 4 bytes long. + + 0 1 2 3 4 5 6 7 + +--------+--------+--------+--------+-|-------+--------+--------+--------+ + | Length(16) | 0x6 |XXXXXXXX|X| ID(31) | + +--------+--------+--------+--------+-|-------+--------+--------+--------+ + + Length: An unsigned 16-bit value representing the number of bytes + which follow the frame header. For PING frames, this value is always + 0. ID: A unique ID for this ping, represented as an unsigned 32 bit value. When the client initiates a ping, it must use an odd numbered @@ -1156,7 +1200,7 @@ Internet-Draft SPDY August 2012 it must ignore the PING. If a client receives an odd numbered PING which it did not initiate, it must ignore the PING. -2.6.6. GOAWAY +2.6.8. GOAWAY The GOAWAY control frame is a mechanism to tell the remote side of the connection to stop creating streams on this session. It can be @@ -1169,14 +1213,6 @@ Internet-Draft SPDY August 2012 still finishing processing of previously established streams. There is an inherent race condition between an endpoint sending - - - -Belshe & Peon Expires February 2, 2013 [Page 21] - -Internet-Draft SPDY August 2012 - - SYN_STREAMs and the remote sending a GOAWAY message. To deal with this case, the GOAWAY contains a last-stream-id indicating the stream-id of the last stream which was created on the sending @@ -1189,6 +1225,14 @@ Internet-Draft SPDY August 2012 Endpoints should always send a GOAWAY message before closing a connection so that the remote can know whether a stream has been partially processed or not. (For example, if an HTTP client sends a + + + +Belshe & Peon Expires February 2, 2013 [Page 22] + +Internet-Draft SPDY August 2012 + + POST at the same time that a server closes a connection, the client cannot know if the server started to process that POST request if the server does not send a GOAWAY frame to indicate where it stopped @@ -1197,21 +1241,19 @@ Internet-Draft SPDY August 2012 After sending a GOAWAY message, the sender must ignore all SYN_STREAM frames for new streams. - 0 1 2 3 4 5 6 7 - +--------+--------+--------+-|-------+--------+--------+--------+--------+ - | Length(16) |Flags(8)|1| Last-Good-Stream-ID(31) | 0x7| -> - +--------+--------+--------+-|-------+--------+--------+--------+--------+ - - 8 9 10 11 - +--------+--------+--------+--------+ - | Status-Code(32) | - +--------+--------+--------+--------+ + 0 1 2 3 4 5 6 7 + +--------+--------+--------+--------+-|-------+--------+--------+--------+ + | Length(16) | 0x7 |Flags(8)|X| Last-Good-Stream-ID(31) | -> + +--------+--------+--------+--------+-|-------+--------+--------+--------+ - Control bit: The control bit is always 1 for this message. + 8 9 10 11 + +--------+--------+--------+--------+ + | Status-Code(32) | + +--------+--------+--------+--------+ - Type: The message type for a GOAWAY message is 7. - - Length: This frame is always 8 bytes long. + Length: An unsigned 16-bit value representing the number of bytes + which follow the frame header. For PING frames, this value is always + 4. Last-good-stream-Id: The last stream id which was replied to (with either a SYN_REPLY or RST_STREAM) by the sender of the GOAWAY @@ -1224,39 +1266,42 @@ Internet-Draft SPDY August 2012 1 - PROTOCOL_ERROR. This is a generic error, and should only be used if a more specific error is not available. - - - - -Belshe & Peon Expires February 2, 2013 [Page 22] - -Internet-Draft SPDY August 2012 - - - 11 - INTERNAL_ERROR. This is a generic error which can be used + 2 - INTERNAL_ERROR. This is a generic error which can be used when the implementation has internally failed, not due to anything in the protocol. -2.6.7. HEADERS +2.6.9. HEADERS The HEADERS frame augments a group of streams or an individual stream with additional metadata by providing an opportunity to send a new - Name/Value Header Block (Section 2.6.11) associated with the stream + Name/Value Header Block (Section 2.6.12) associated with the stream - Please see Name/Value Header Block (Section 2.6.11) for further + Please see Name/Value Header Block (Section 2.6.12) for further details about how it is to be interpreted. Here is the format of a headers frame and headers block: - 0 1 2 3 4 5 6 7 - +--------+--------+--------+-|-------+--------+--------+--------+--------+ - | Length(16) |Flags(8)|1| Stream-ID(31) | 0x8| -> - +--------+--------+--------+-|-------+--------+--------+--------+--------+ - 8,9,10..N - +=========================+ - | Name/Value Header Block | - +=========================+ + + +Belshe & Peon Expires February 2, 2013 [Page 23] + +Internet-Draft SPDY August 2012 + + + 0 1 2 3 4 5 6 7 + +--------+--------+--------+--------+-|-------+--------+--------+--------+ + | Length(16) | 0x8 |Flags(8)|X| Stream-ID(31) | -> + +--------+--------+--------+--------+-|-------+--------+--------+--------+ + + 8,9,10..N + +=========================+ + | Name/Value Header Block | + +=========================+ + + Length: An unsigned 16-bit value representing the number of bytes + which follow the frame header. For HEADERS frames, this is the + length of the Name/Value Header Block. Flags: Flags related to this frame. Valid flags are: @@ -1274,21 +1319,13 @@ Internet-Draft SPDY August 2012 Stream-ID: The stream this HEADERS block is associated with. - Name/Value Header Block: A set of name/value pairs carried as part of - the SYN_STREAM. see Name/Value Header Block (Section 2.6.11). - -2.6.8. WINDOW_UPDATE - - The WINDOW_UPDATE control frame is used to implement per stream flow - control in SPDY. Flow control in SPDY is per hop, that is, only - - - -Belshe & Peon Expires February 2, 2013 [Page 23] - -Internet-Draft SPDY August 2012 - + Name/Value Header Block: A set of name/value pairs carried as part of + the SYN_STREAM. see Name/Value Header Block (Section 2.6.12). + +2.6.10. WINDOW_UPDATE + The WINDOW_UPDATE control frame is used to implement per stream flow + control in SPDY. Flow control in SPDY is per hop, that is, only between the two endpoints of a SPDY connection. If there are one or more intermediaries between the client and the origin server, flow control signals are not explicitly forwarded by the intermediaries. @@ -1300,6 +1337,14 @@ Internet-Draft SPDY August 2012 a stream error (Section 2.4.2) with the status code FLOW_CONTROL_ERROR for the stream. + + + +Belshe & Peon Expires February 2, 2013 [Page 24] + +Internet-Draft SPDY August 2012 + + Flow control in SPDY is implemented by a data transfer window kept by the sender of each stream. The data transfer window is a simple uint32 that indicates how many bytes of data the sender can transmit. @@ -1315,36 +1360,23 @@ Internet-Draft SPDY August 2012 to notify the sender that it has consumed some data and freed up buffer space to receive more data. - 0 1 2 3 4 5 6 7 - +--------+--------+--------+-|-------+--------+--------+--------+--------+ - | Length(16) |Flags(8)|1| Stream-ID(31) | 0x9| -> - +--------+--------+--------+-|-------+--------+--------+--------+--------+ - - 8 9 10 11 - +--------+--------+--------+--------+ - |Delta-Window-Size | - +--------+--------+--------+--------+ - - - Control bit: The control bit is always 1 for this message. - - Version: The SPDY version number. + 0 1 2 3 4 5 6 7 + +--------+--------+--------+--------+-|-------+--------+--------+--------+ + | Length(16) | 0x9 |Flags(8)|X| Stream-ID(31) | -> + +--------+--------+--------+--------+-|-------+--------+--------+--------+ - Type: The message type for a WINDOW_UPDATE message is 9. + 8 9 10 11 + +--------+--------+--------+--------+ + |Delta-Window-Size | + +--------+--------+--------+--------+ - Length: The length field is always 8 for this frame (there are 8 - bytes after the length field). + Length: An unsigned 16-bit value representing the number of bytes + which follow the frame header. For WINDOW_UPDATE frames, this value + is always 4. Stream-ID: The stream ID that this WINDOW_UPDATE control frame is for. - - -Belshe & Peon Expires February 2, 2013 [Page 24] - -Internet-Draft SPDY August 2012 - - Delta-Window-Size: The additional number of bytes that the sender can transmit in addition to existing remaining window size. The legal range for this field is 1 to 2^31 - 1 (0x7fffffff) bytes. @@ -1361,6 +1393,14 @@ Internet-Draft SPDY August 2012 connection. That is, its peer can start out using the 64KB default initial window size when sending data frames before receiving the SETTINGS. Because SETTINGS is asynchronous, there may be a race + + + +Belshe & Peon Expires February 2, 2013 [Page 25] + +Internet-Draft SPDY August 2012 + + condition if the recipient wants to decrease the initial window size, but its peer immediately sends 64KB on the creation of a new connection, before waiting for the SETTINGS to arrive. This is one @@ -1393,19 +1433,11 @@ Internet-Draft SPDY August 2012 last frame for the stream. The data frames from the sender and the WINDOW_UPDATE frames from the - - - -Belshe & Peon Expires February 2, 2013 [Page 25] - -Internet-Draft SPDY August 2012 - - recipient are completely asynchronous with respect to each other. This property allows a recipient to aggressively update the window size kept by the sender to prevent the stream from stalling. -2.6.9. CREDENTIAL +2.6.11. CREDENTIAL The CREDENTIAL control frame is used by the client to send additional client certificates to the server. A SPDY client may decide to send @@ -1417,6 +1449,14 @@ Internet-Draft SPDY August 2012 contain at most one client certificate, the client needs a mechanism to send additional client certificates to the server. + + + +Belshe & Peon Expires February 2, 2013 [Page 26] + +Internet-Draft SPDY August 2012 + + The server is required to maintain a vector of client certificates associated with a SPDY session. When the client needs to send a client certificate to the server, it will send a CREDENTIAL frame @@ -1442,36 +1482,20 @@ Internet-Draft SPDY August 2012 which resource triggered the client certificate request, in order to prompt the user accordingly. + 0 1 2 3 4 5 6 7 + +--------+--------+--------+--------+-|-------+--------+--------+--------+ + | Length(16) | 0xa |Flags(8)|X| Num-of-Entires(31) | -> + +--------+--------+--------+--------+-|-------+--------+--------+--------+ + 8 9 10 11 12 + +--------+--------+--------+--------+========+ + | Slot(16) |Proof Length(16) | Proof | -> + +--------+--------+--------+--------+========+ - - - - - - - - -Belshe & Peon Expires February 2, 2013 [Page 26] - -Internet-Draft SPDY August 2012 - - - 0 1 2 3 4 5 6 7 - +--------+--------+--------+-|-------+--------+--------+--------+--------+ - | Length(16) |Flags(8)|1| Num-of-Entries-or-Stream-ID-or-ID| 0xa| -> - +--------+--------+--------+-|-------+--------+--------+--------+--------+ - - 8 9 10 11 12 - +--------+--------+--------+--------+========+ - | Slot(16) |Proof Length(16) | Proof | -> - +--------+--------+--------+--------+========+ - - /--Repeated to frame end--\ - +--------+--------+========+ - | Cert Length(16) | Cert | - +--------+--------+========+ - + /--Repeated to frame end--\ + +--------+--------+========+ + | Cert Length(16) | Cert | + +--------+--------+========+ Slot: The index in the server's client certificate vector where this certificate should be stored. If there is already a certificate @@ -1481,6 +1505,14 @@ Internet-Draft SPDY August 2012 Proof: Cryptographic proof that the client has possession of the private key associated with the certificate. The format is a TLS digitally-signed element + + + +Belshe & Peon Expires February 2, 2013 [Page 27] + +Internet-Draft SPDY August 2012 + + (http://tools.ietf.org/html/rfc5246#section-4.7). The signature algorithm must be the same as that used in the CertificateVerify message. However, since the MD5+SHA1 signature type used in TLS 1.0 @@ -1505,14 +1537,6 @@ Internet-Draft SPDY August 2012 RST_STREAM frame with the status code INVALID_CREDENTIALS. Upon receipt of a RST_STREAM frame with INVALID_CREDENTIALS, the client should initiate a new stream directly to the requested origin and - - - -Belshe & Peon Expires February 2, 2013 [Page 27] - -Internet-Draft SPDY August 2012 - - resend the request. Note, SPDY does not allow the server to request different client authentication for different resources in the same origin. @@ -1520,71 +1544,11 @@ Internet-Draft SPDY August 2012 If the server receives an invalid CREDENTIAL frame, it MUST respond with a GOAWAY frame and shutdown the session. -2.6.10. PUSH_PROMISE - - The PUSH_PROMISE control frame allows the sender to signal a promise - to create a stream and serve the referenced resource. Minimal data - allowing the receiver to understand which resource(s) are to be - pushed are to be included. - - 0 1 2 3 4 5 6 7 - +--------+--------+--------+-|-------+--------+--------+--------+--------+ - | Length(16) |Flags(8)|1| Associated-To-Stream-ID(31) | 0xb| -> - +--------+--------+--------+-|-------+--------+--------+--------+--------+ - - 8 9 10 11 12,13,14..N - +-|-------+--------+--------+--------+=========================+ - |X| Promised-Stream-Id(31) | Name/Value Header Block | - +-|-------+--------+--------+--------+=========================+ - - Flags: Flags related to this frame. Valid flags are: - - 0x01 = FLAG_FIN - marks this frame as the last frame to be - transmitted on this stream and puts the sender in the half-closed - (Section 2.3.6) state. - - Length: The length is the number of bytes which follow the length - field in the frame. For PUSH_PROMISE frames, this is 10 bytes plus - the length of the compressed Name/Value block. - - Stream-ID: The 31-bit identifier for this stream. This stream-id - will be used in frames which are part of this stream. - - Associated-To-Stream-ID: The 31-bit identifier for a stream which - this stream is associated to. If this stream is independent of all - other streams, it should be 0. - - Promised-Stream-ID: The 31-bit identifier indicating the stream-id on - which the resource will be pushed. If multiple headers are indicated - within the Name/Value Header Block, each subsequent resource as - indicated in the Header Block will increment the Promised-Stream-Id - by two. The Promised-Stream-ID is subject to the same rules as any - other stream-id-- when defined and transmitted, the - Promised-Stream-ID MUST be part of a monotonically increasing - - - -Belshe & Peon Expires February 2, 2013 [Page 28] - -Internet-Draft SPDY August 2012 - - - sequence of stream-ids. There is no requirement that the streams - referred to by the this frame are created in the order referenced. - - Name/Value Header Block: A set of name/value pairs carried as part of - the PUSH_PROMISE. see Name/Value Header Block (Section 2.6.11). - - If an endpoint receives a PUSH_PROMISE which is larger than the - implementation supports, it MAY send a RST_STREAM with error code - FRAME_TOO_LARGE. All implementations MUST support the minimum size - limits defined in the Control Frames section (Section 2.2.2). - -2.6.11. Name/Value Header Block +2.6.12. Name/Value Header Block A Name/Value Header Block augments the streams or group of streams - identified by the SYN_STREAM (Section 2.6.1), HEADERS - (Section 2.6.7), or SYN_REPLY (Section 2.6.2) frame stream with + identified by the SYN_STREAM (Section 2.6.2), HEADERS + (Section 2.6.9), or SYN_REPLY (Section 2.6.3) frame stream with additional metadata. At the group level, a map of token-index to key-pair is maintained @@ -1596,6 +1560,15 @@ Internet-Draft SPDY August 2012 The HeaderBlock compressor (described later) is subject to the following constraints: + + + + +Belshe & Peon Expires February 2, 2013 [Page 28] + +Internet-Draft SPDY August 2012 + + TotalHeaderStorageSize : default(16k) MaxHeaderGroups: default(1) @@ -1617,14 +1590,6 @@ Internet-Draft SPDY August 2012 headers[key] = value return headers - - - -Belshe & Peon Expires February 2, 2013 [Page 29] - -Internet-Draft SPDY August 2012 - - A smart implementation will be able to interpret a headers frame without reconstructing the headers, and thus be able to represent and interpret headers with less memory and CPU. @@ -1653,6 +1618,13 @@ Internet-Draft SPDY August 2012 0x0 (reserved) -- this is not used and is reserved in case a token-based delimiter is required in the future. + + +Belshe & Peon Expires February 2, 2013 [Page 29] + +Internet-Draft SPDY August 2012 + + 0x1 (Toggle) indicates that the data which follows will be an lru- index. That lru-index, if present in the current header-group will be removed from the header group. If it is not present in @@ -1674,13 +1646,6 @@ Internet-Draft SPDY August 2012 Clone, the key-value will be stored in the LRU with a new index, and that index will be added to the current header group. - - -Belshe & Peon Expires February 2, 2013 [Page 30] - -Internet-Draft SPDY August 2012 - - 0x2 (Eref) indicates that the data which follows will be two string literals. The first such string represents key, and the second string represents a value. Unlike KVSto, the Eref does not @@ -1709,6 +1674,13 @@ Internet-Draft SPDY August 2012 |0| 7 bit-ascii |00000000| +-|-------+========+--------+ + + +Belshe & Peon Expires February 2, 2013 [Page 30] + +Internet-Draft SPDY August 2012 + + The NumOps field encodes one minus the number of operations that follow. Since the field-width is 8 bits, a maximum of 256 ops can be represented. If more than 256 operations are required, simply repeat @@ -1729,14 +1701,6 @@ Internet-Draft SPDY August 2012 +--------+--------+ | LRU idx(16) | - - - -Belshe & Peon Expires February 2, 2013 [Page 31] - -Internet-Draft SPDY August 2012 - - +--------+--------+ Detail of an operation with an opcode of 0x2 (Clone): @@ -1757,6 +1721,22 @@ Internet-Draft SPDY August 2012 Detail of an operation with an opcode of 0x3 (KVSto): + + + + + + + + + + + +Belshe & Peon Expires February 2, 2013 [Page 31] + +Internet-Draft SPDY August 2012 + + 0 1 +--------+--------+ |00000011| NumOps | @@ -1785,14 +1765,6 @@ Internet-Draft SPDY August 2012 +========+========+ | String | String | - - - -Belshe & Peon Expires February 2, 2013 [Page 32] - -Internet-Draft SPDY August 2012 - - +========+========+ Each header name must have at least one value. Header names are @@ -1805,7 +1777,7 @@ Internet-Draft SPDY August 2012 Duplicate header names are allowed, but discouraged, except when encoding a cookie or set-cookie. -2.6.11.1. Compression +2.6.12.1. Compression The Name/Value Header Block is a section of the SYN_STREAM, SYN_REPLY, and HEADERS frames used to carry header meta-data. This @@ -1814,6 +1786,13 @@ Internet-Draft SPDY August 2012 Compressed Data Format Specification Version 3.3 as part of RFC1950. [RFC1950] + + +Belshe & Peon Expires February 2, 2013 [Page 32] + +Internet-Draft SPDY August 2012 + + For each HEADERS compression instance, the initial state is initialized using the following dictionary [UDELCOMPRESSION]: @@ -1841,14 +1820,6 @@ Internet-Draft SPDY August 2012 0: ":method", "GET" 1: ":version", "HTTP/1.1" 2: "user-agent", "blah blah browser version blah blah" - - - -Belshe & Peon Expires February 2, 2013 [Page 33] - -Internet-Draft SPDY August 2012 - - 3: "accept-encoding", "sdch, bzip, compress" The stream-group table for group zero looks like this: @@ -1870,6 +1841,14 @@ Internet-Draft SPDY August 2012 SYN_STREAM 3, stream-group (G)=0 Header-block: Store(0x1): level(G),index(2),v: "/index.js" + + + +Belshe & Peon Expires February 2, 2013 [Page 33] + +Internet-Draft SPDY August 2012 + + Store(0x1): level(G),index(3),v: "Wed Jul 18 11:50:44 2012" At this point the connection headers table is unchanged: @@ -1897,14 +1876,6 @@ Internet-Draft SPDY August 2012 Request 3 (for index.css): SYN_STREAM 5, stream-group (G)=0 Header-block: - - - -Belshe & Peon Expires February 2, 2013 [Page 34] - -Internet-Draft SPDY August 2012 - - Store(0x1): level(G),index(2),v: "/index.css" Store(0x1): level(G),index(3),v: "Wed Jul 18 11:50:44 PDT 2012" @@ -1926,6 +1897,14 @@ Internet-Draft SPDY August 2012 2: "user-agent", "blah blah browser version blah blah" 3: "accept-encoding", "sdch, bzip, compress" + + + +Belshe & Peon Expires February 2, 2013 [Page 34] + +Internet-Draft SPDY August 2012 + + The stream-group table for group zero looks like this: 0: ":host", "www.foo.com" 1: "cookie", "SOMELONGSTRINGHTATISMOSTLYOPAQUE;FOOBLA" @@ -1956,6 +1935,27 @@ Internet-Draft SPDY August 2012 + + + + + + + + + + + + + + + + + + + + + Belshe & Peon Expires February 2, 2013 [Page 35] Internet-Draft SPDY August 2012 diff --git a/draft-mbelshe-spdy-00.xml b/draft-mbelshe-spdy-00.xml index b10951d..8ca8b62 100644 --- a/draft-mbelshe-spdy-00.xml +++ b/draft-mbelshe-spdy-00.xml @@ -87,11 +87,12 @@
- Once the connection is established, clients and servers exchange framed messages. There are two types of frames: control frames and data frames. + Once the connection is established, clients and servers exchange framed messages. - Both types of frames carry a common set of headers: length, flags, and frame type. Flag definitions vary between control and data frames. The simple header is designed to make reading and writing of frames easy. + All frames carry a common set of headers: length, type, and flags. Flag definitions vary between frame types. The simple header format is designed to make reading and writing of frames easy. All integer values, including length, and type, are in network byte order. SPDY does not enforce alignment of types in dynamically sized frames. +
In SPDY, since everything is defined to be in network byte-order, the most significant bit of any field is the "leftmost" in any diagram. @@ -137,68 +138,33 @@ - - -
-
-
- - 0 1 2 3 4 5 6 7 - +--------+--------+--------+-|-------+--------+--------+--------+--------+ - | Length(16) |Flags(8)|1| Num-of-Entries-or-Stream-ID-or-ID|Type(8) | -> - +--------+--------+--------+-|-------+--------+--------+--------+--------+ - 8..N - +========+ - | Data | - +========+ - -
- Control bit: The 'C' bit is a single bit indicating if this is a control message. For control frames this value is always 1. - - Type: The type of control frame. See Control Frames for the complete list of control frames. - - Flags: Flags related to this frame. Flags for control frames and data frames are different. - - Length: An unsigned 16-bit value representing the number of bytes after the length field. - - Data: data associated with this control frame. The format and length of this data is controlled by the control frame type. - - Control frame processing requirements: - - Note that full length control frames (16kb) can be large for implementations running on resource-limited hardware. In such cases, implementations MAY limit the maximum length frame supported. However, all implementations MUST be able to receive control frames of at least 8192 octets in length. - -
-
+
- 0 1 2 3 4 5 6 7..N - +--------+--------+--------+-|-------+--------+--------+--------+========+ - | Length(16) |Flags(8)|0| Stream ID (31) | Data | - +--------+--------+--------+-|-------+--------+--------+--------+========+ + 0 1 2 3 4 5 6 7 + +--------+--------+--------+--------+--------+--------+--------+--------+ + | Length(16) |Type(8) |Flags(8)| Num-of-Entries-or-Stream-ID-or-ID | -> + +--------+--------+--------+--------+--------+--------+--------+--------+ + + 8..N + +========+ + | Data | + +========+
- Control bit: For data frames this value is always 0. + Length: An unsigned 16-bit value representing the number of bytes of the data field. - Stream-ID: A 31-bit value identifying the stream. - - Flags: Flags related to this frame. Valid flags are: - - 0x01 = FLAG_FIN - signifies that this frame represents the last frame to be transmitted on this stream. See Stream Close below. - 0x02 = MSG_DONE - signifies that this frame represents the last frame of a message. This is relevant for layering of message-based protocols on top of SPDY. - - + Type: The frame type. See Frame Types for the complete list of frames. - Length: An unsigned 16-bit value representing the number of bytes after the length field. The total size of a data frame is 8 bytes + length. It is valid to have a zero-length data frame. + Flags: Flags related to this frame. Flag definitions are dependent upon the frame type. - Data: The variable-length data payload; the length was defined in the length field. + Data: data associated with this control frame. The format of this data is controlled by the frame type. - Data frame processing requirements: + Frame processing requirements: - If an endpoint receives a data frame for a stream-id which is not open and the endpoint has not sent a GOAWAY frame, it MUST issue a stream error with the error code INVALID_STREAM for the stream-id. - If the endpoint which created the stream receives a data frame before receiving a SYN_REPLY on that stream, it is a protocol error, and the recipient MUST issue a stream error with the status code PROTOCOL_ERROR for the stream-id. - Implementors note: If an endpoint receives multiple data frames for invalid stream-ids, it MAY close the session. + Note that full length frames (64kb) can be large for implementations running on resource-limited hardware. In such cases, implementations MAY limit the maximum length frame supported. However, all implementations MUST be able to receive frames of at least 8192 octets in length.
@@ -255,7 +221,7 @@
- Once a stream is created, it can be used to send arbitrary amounts of data. Generally this means that a series of data frames will be sent on the stream until a frame containing the FLAG_FIN flag is set. The FLAG_FIN can be set on a SYN_STREAM, SYN_REPLY, HEADERS or a DATA frame. Once the FLAG_FIN has been sent, the stream is considered to be half-closed. + Once a stream is created, it can be used to send arbitrary amounts of data. Generally this means that a series of data frames will be sent on the stream until a frame containing the FLAG_FIN flag is set. The FLAG_FIN can be set on a SYN_STREAM, SYN_REPLY, HEADERS or a DATA frame. Once the FLAG_FIN has been sent, the stream is considered to be half-closed.
@@ -299,58 +265,92 @@ Because TCP provides a single stream of data on which SPDY multiplexes multiple logical streams, clients and servers must intelligently interleave data messages for concurrent sessions.
-
+
Type-field value - Control Frame-type + Frame type + 0x0 DATA 0x1 SYN_STREAM 0x2 SYN_REPLY 0x3 RST_STREAM + 0x5 PUSH_PROMISE 0x4 SETTINGS 0x6 PING 0x7 GOAWAY 0x8 HEADERS 0x9 WINDOW_UPDATE 0xa CREDENTIAL - 0xb PUSH_PROMISE Shared components of several control frames: Name/Value Header Block +
+
+ + 0 1 2 3 4 5 6 7 + +--------+--------+--------+--------+-|-------+--------+--------+--------+ + | Length(16) | 0x0 |Flags(8)|X| Stream-ID(31) | -> + +--------+--------+--------+--------+-|-------+--------+--------+--------+ + + 8..N + +========+ + | Data | + +========+ + +
+ + Length: An unsigned 16-bit value representing the number of bytes which follow the frame header. The total size of a data frame is 8 bytes + length. It is valid to have a zero-length data frame. + + Flags: Flags related to this frame. Valid flags are: + + 0x01 = FLAG_FIN - signifies that this frame represents the last frame to be transmitted on this stream. See Stream Close below. + 0x02 = MSG_DONE - signifies that this frame represents the last frame of a message. This is relevant for layering of message-based protocols on top of SPDY. + + + + Stream-ID: A 31-bit value identifying the stream. + + Data: The variable-length data payload; the length was defined in the length field. + + Data frame processing requirements: + + If an endpoint receives a data frame for a stream-id which is not open and the endpoint has not sent a GOAWAY frame, it MUST issue a stream error with the error code INVALID_STREAM for the stream-id. + If the endpoint which created the stream receives a data frame before receiving a SYN_REPLY on that stream, it is a protocol error, and the recipient MUST issue a stream error with the status code PROTOCOL_ERROR for the stream-id. + Implementors note: If an endpoint receives multiple data frames for invalid stream-ids, it MAY close the session. + + +
+
The SYN_STREAM control frame allows the sender to asynchronously create a stream between the endpoints. See Stream Creation
- 0 1 2 3 4 5 6 7 - +--------+--------+--------+-|-------+--------+--------+--------+--------+ - | Length(16) |Flags(8)|1| Stream Id(31) | 0x1 | -> - +--------+--------+--------+-|-------+--------+--------+--------+--------+ - - 8 9,10,11..N - +---|-----+=========================+ - |Pri|XXXXX| Name/Value Header Block | - +---|-----+=========================+ + 0 1 2 3 4 5 6 7 + +--------+--------+--------+--------+-|-------+--------+--------+--------+ + | Length(16) | 0x1 |Flags(8)|X| Stream-ID(31) | -> + +--------+--------+--------+--------+-|-------+--------+--------+--------+ + + 8 9 10 11 12,13,14..N + +-|-------+--------+--------+--------+=========================+ + |X|Priority(31) | Name/Value Header Block | + +-|-------+--------+--------+--------+=========================+
+ Length: An unsigned 16-bit value representing the number of bytes which follow the frame header. For SYN_STREAM frames, this is 4 bytes plus the length of the Name/Value Header Block. + Flags: Flags related to this frame. Valid flags are: 0x01 = FLAG_FIN - marks this frame as the last frame to be transmitted on this stream and puts the sender in the half-closed state. - Length: The length is the number of bytes which follow the length field in the frame. For SYN_STREAM frames, this is 6 bytes plus the length of the Name/Value Header Block. - Stream-ID: The 31-bit identifier for this stream. This stream-id will be used in frames which are part of this stream. - Associated-To-Stream-ID: The 31-bit identifier for a stream which this stream is associated to. If this stream is independent of all other streams, it should be 0. + Priority: A 31-bit priority field. - Priority: A 3-bit priority field. + Name/Value Header Block: A set of name/value pairs carried as part of the SYN_STREAM. see Name/Value Header Block. - Unused: 5 bits of unused space, reserved for future use. - - Name/Value Header Block: A set of name/value pairs carried as part of the SYN_STREAM. see Name/Value Header Block. - - If an endpoint receives a SYN_STREAM which is larger than the implementation supports, it MAY send a RST_STREAM with error code FRAME_TOO_LARGE. All implementations MUST support the minimum size limits defined in the Control Frames section. + If an endpoint receives a SYN_STREAM which is larger than the implementation supports, it MAY send a RST_STREAM with error code FRAME_TOO_LARGE. All implementations MUST support the minimum size limits defined in the Frame Format section.
@@ -358,53 +358,54 @@ SYN_REPLY indicates the acceptance of a stream creation by the recipient of a SYN_STREAM frame.
- 0 1 2 3 4 5 6 7 - +--------+--------+--------+-|-------+--------+--------+--------+--------+ - | Length(16) |Flags(8)|1| Stream Id(31) | 0x2 | -> - +--------+--------+--------+-|-------+--------+--------+--------+--------+ - - 8,9,10..N - +=========================+ - | Name/Value Header Block | - +=========================+ + 0 1 2 3 4 5 6 7 + +--------+--------+--------+--------+-|-------+--------+--------+--------+ + | Length(16) | 0x2 |Flags(8)|X| Stream-ID(31) | -> + +--------+--------+--------+--------+-|-------+--------+--------+--------+ + + 8,9,10..N + +=========================+ + | Name/Value Header Block | + +=========================+
+ Length: An unsigned 16-bit value representing the number of bytes which follow the frame header. For SYN_REPLY frames, this is the length of the Name/Value Header Block. + Flags: Flags related to this frame. Valid flags are: 0x01 = FLAG_FIN - marks this frame as the last frame to be transmitted on this stream and puts the sender in the half-closed state. - Length: The length is the number of bytes which follow the length field in the frame. For SYN_REPLY frames, this is 4 bytes plus the length of the compressed Name/Value block. - Stream-ID: The 31-bit identifier for this stream. If an endpoint receives multiple SYN_REPLY frames for the same active stream ID, it MUST issue a stream error with the error code STREAM_IN_USE. - Name/Value Header Block: A set of name/value pairs carried as part of the SYN_STREAM. see Name/Value Header Block. + Name/Value Header Block: A set of name/value pairs carried as part of the SYN_REPLY. see Name/Value Header Block. - If an endpoint receives a SYN_REPLY which is larger than the implementation supports, it MAY send a RST_STREAM with error code FRAME_TOO_LARGE. All implementations MUST support the minimum size limits defined in the Control Frames section. + If an endpoint receives a SYN_REPLY which is larger than the implementation supports, it MAY send a RST_STREAM with error code FRAME_TOO_LARGE. All implementations MUST support the minimum size limits defined in the Frame Format section.
The RST_STREAM frame allows for abnormal termination of a stream. When sent by the creator of a stream, it indicates the creator wishes to cancel the stream. When sent by the recipient of a stream, it indicates an error or that the recipient did not want to accept the stream, so the stream should be closed.
- 0 1 2 3 4 5 6 7 - +--------+--------+--------+-|-------+--------+--------+--------+--------+ - | Length(16) |Flags(8)|1| Stream Id(31) | 0x3 | -> - +--------+--------+--------+-|-------+--------+--------+--------+--------+ - - 8 9 10 11 - +--------+--------+--------+--------+ - | Status-Code(32) | - +--------+--------+--------+--------+ + 0 1 2 3 4 5 6 7 + +--------+--------+--------+--------+-|-------+--------+--------+--------+ + | Length(16) | 0x3 |Flags(8)|X| Stream-ID(31) | -> + +--------+--------+--------+--------+-|-------+--------+--------+--------+ + + 8 9 10 11 + +--------+--------+--------+--------+ + | Status-Code(32) | + +--------+--------+--------+--------+
- Flags: Flags related to this frame. RST_STREAM does not define any flags. This value must be 0. - Length: An unsigned 16-bit value representing the number of bytes after the length field. For RST_STREAM control frames, this value is always 8. + Length: An unsigned 16-bit value representing the number of bytes which follow the frame header. For RST_STREAM frames, this value is always 4. + + Flags: Flags related to this frame. RST_STREAM does not define any flags. This value must be 0. Stream-ID: The 31-bit identifier for this stream. @@ -428,31 +429,64 @@ After receiving a RST_STREAM on a stream, the recipient must not send additional frames for that stream, and the stream moves into the closed state.
+
+ The PUSH_PROMISE control frame allows the sender to signal a promise to create a stream and serve the referenced resource. Minimal data allowing the receiver to understand which resource(s) are to be pushed are to be included. +
+ + 0 1 2 3 4 5 6 7 + +--------+--------+--------+--------+-|-------+--------+--------+--------+ + | Length(16) | 0x5 |Flags(8)|X| Associated-To-Stream-ID(31) | -> + +--------+--------+--------+--------+-|-------+--------+--------+--------+ + + 8 9 10 11 12,13,14..N + +-|-------+--------+--------+--------+=========================+ + |X| Promised-Stream-ID(31) | Name/Value Header Block | + +-|-------+--------+--------+--------+=========================+ + +
+ + Length: An unsigned 16-bit value representing the number of bytes which follow the frame header. For PUSH_PROMISE frames, this is 4 bytes plus the length of the Name/Value Header Block. + + Flags: Flags related to this frame. Valid flags are: + + 0x01 = FLAG_FIN - marks this frame as the last frame to be transmitted on this stream and puts the sender in the half-closed state. + + + + Associated-To-Stream-ID: The 31-bit identifier for a stream which this stream is associated to. If this stream is independent of all other streams, it should be 0. + + Promised-Stream-ID: The 31-bit identifier indicating the stream-id on which the resource will be pushed. If multiple headers are indicated within the Name/Value Header Block, each subsequent resource as indicated in the Header Block will increment the Promised-Stream-Id by two. The Promised-Stream-ID is subject to the same rules as any other stream-id-- when defined and transmitted, the Promised-Stream-ID MUST be part of a monotonically increasing sequence of stream-ids. There is no requirement that the streams referred to by the this frame are created in the order referenced. + + Name/Value Header Block: A set of name/value pairs carried as part of the PUSH_PROMISE. see Name/Value Header Block. + + If an endpoint receives a PUSH_PROMISE which is larger than the implementation supports, it MAY send a RST_STREAM with error code FRAME_TOO_LARGE. All implementations MUST support the minimum size limits defined in the Frame Format section. + +
+
A SETTINGS frame contains a set of id/value pairs for communicating configuration data about how the two endpoints may communicate. SETTINGS frames can be sent at any time by either endpoint, are optionally sent, and are fully asynchronous. When the server is the sender, the sender can request that configuration data be persisted by the client across SPDY sessions and returned to the server in future communications. Persistence of SETTINGS ID/Value pairs is done on a per origin/IP pair (the "origin" is the set of scheme, host, and port from the URI. See ). That is, when a client connects to a server, and the server persists settings within the client, the client SHOULD return the persisted settings on future connections to the same origin AND IP address and TCP port. Clients MUST NOT request servers to use the persistence features of the SETTINGS frames, and servers MUST ignore persistence related flags sent by a client.
- 0 1 2 3 4 5 6 7 - +--------+--------+--------+-|-------+--------+--------+--------+--------+ - | Length(16) |Flags(8)|1| Number-of-Entries(31) | 0x4 | -> - +--------+--------+--------+-|-------+--------+--------+--------+--------+ - - 8..n - +================+ - | ID/Value-Pairs | - +================+ + 0 1 2 3 4 5 6 7 + +--------+--------+--------+--------+-|-------+--------+--------+--------+ + | Length(16) | 0x4 |Flags(8)|X|Number-of-Entries(31) | -> + +--------+--------+--------+--------+-|-------+--------+--------+--------+ + + 8..N + +================+ + | ID/Value-Pairs | + +================+
- Control bit: The control bit is always 1 for this message. + + Length: An unsigned 16-bit value representing the number of bytes which follow the frame header. For SETTINGS frames, this is the length of the ID/Value-Pairs Block. Type: The message type for a SETTINGS message is 4. Flags: FLAG_SETTINGS_CLEAR_SETTINGS (0x1): When set, the client should clear any previously persisted SETTINGS ID/Value pairs. If this frame contains ID/Value pairs with the FLAG_SETTINGS_PERSIST_VALUE set, then the client will first clear its existing, persisted settings, and then persist the values with the flag set which are contained within this frame. Because persistence is only implemented on the client, this flag can only be used when the sender is the server. - Length: An unsigned 16-bit value representing the number of bytes after the length field. The total size of a SETTINGS frame is 8 bytes + length. - Number of entries: A 32-bit value representing the number of ID/value pairs in this message. Each ID/value pair is as follows: @@ -504,18 +538,14 @@ The PING control frame is a mechanism for measuring a minimal round-trip time from the sender. It can be sent from the client or the server. Recipients of a PING frame should send an identical frame to the sender as soon as possible (if there is other pending data waiting to be sent, PING should take highest priority). Each ping sent by a sender should use a unique ID.
- 0 1 2 3 4 5 6 7 - +--------+--------+--------+-|-------+--------+--------+--------+--------+ - | Length(16) |XXXXXXXX|1| ID(31) | 0x6 | -> - +--------+--------+--------+-|-------+--------+--------+--------+--------+ - + 0 1 2 3 4 5 6 7 + +--------+--------+--------+--------+-|-------+--------+--------+--------+ + | Length(16) | 0x6 |XXXXXXXX|X| ID(31) | + +--------+--------+--------+--------+-|-------+--------+--------+--------+
- Control bit: The control bit is always 1 for this message. - - Type: The message type for a PING message is 6. - Length: This frame is always 4 bytes long. + Length: An unsigned 16-bit value representing the number of bytes which follow the frame header. For PING frames, this value is always 0. ID: A unique ID for this ping, represented as an unsigned 32 bit value. When the client initiates a ping, it must use an odd numbered ID. When the server initiates a ping, it must use an even numbered ping. Use of odd/even IDs is required in order to avoid accidental looping on PINGs (where each side initiates an identical PING at the same time). @@ -535,22 +565,19 @@ After sending a GOAWAY message, the sender must ignore all SYN_STREAM frames for new streams.
- 0 1 2 3 4 5 6 7 - +--------+--------+--------+-|-------+--------+--------+--------+--------+ - | Length(16) |Flags(8)|1| Last-Good-Stream-ID(31) | 0x7| -> - +--------+--------+--------+-|-------+--------+--------+--------+--------+ - - 8 9 10 11 - +--------+--------+--------+--------+ - | Status-Code(32) | - +--------+--------+--------+--------+ + 0 1 2 3 4 5 6 7 + +--------+--------+--------+--------+-|-------+--------+--------+--------+ + | Length(16) | 0x7 |Flags(8)|X| Last-Good-Stream-ID(31) | -> + +--------+--------+--------+--------+-|-------+--------+--------+--------+ + + 8 9 10 11 + +--------+--------+--------+--------+ + | Status-Code(32) | + +--------+--------+--------+--------+
- Control bit: The control bit is always 1 for this message. - Type: The message type for a GOAWAY message is 7. - - Length: This frame is always 8 bytes long. + Length: An unsigned 16-bit value representing the number of bytes which follow the frame header. For PING frames, this value is always 4. Last-good-stream-Id: The last stream id which was replied to (with either a SYN_REPLY or RST_STREAM) by the sender of the GOAWAY message. If no streams were replied to, this value MUST be 0. @@ -558,7 +585,7 @@ 0 - OK. This is a normal session teardown. 1 - PROTOCOL_ERROR. This is a generic error, and should only be used if a more specific error is not available. - 11 - INTERNAL_ERROR. This is a generic error which can be used when the implementation has internally failed, not due to anything in the protocol. + 2 - INTERNAL_ERROR. This is a generic error which can be used when the implementation has internally failed, not due to anything in the protocol.
@@ -569,17 +596,20 @@ Here is the format of a headers frame and headers block:
- 0 1 2 3 4 5 6 7 - +--------+--------+--------+-|-------+--------+--------+--------+--------+ - | Length(16) |Flags(8)|1| Stream-ID(31) | 0x8| -> - +--------+--------+--------+-|-------+--------+--------+--------+--------+ - - 8,9,10..N - +=========================+ - | Name/Value Header Block | - +=========================+ + 0 1 2 3 4 5 6 7 + +--------+--------+--------+--------+-|-------+--------+--------+--------+ + | Length(16) | 0x8 |Flags(8)|X| Stream-ID(31) | -> + +--------+--------+--------+--------+-|-------+--------+--------+--------+ + + 8,9,10..N + +=========================+ + | Name/Value Header Block | + +=========================+
+ + Length: An unsigned 16-bit value representing the number of bytes which follow the frame header. For HEADERS frames, this is the length of the Name/Value Header Block. + Flags: Flags related to this frame. Valid flags are: 0x01 = FLAG_FIN - marks this frame as the last frame to be transmitted on this stream and puts the sender in the half-closed state. @@ -601,25 +631,18 @@ Flow control in SPDY is implemented by a data transfer window kept by the sender of each stream. The data transfer window is a simple uint32 that indicates how many bytes of data the sender can transmit. After a stream is created, but before any data frames have been transmitted, the sender begins with the initial window size. This window size is a measure of the buffering capability of the recipient. The sender must not send a data frame with data length greater than the transfer window size. After sending each data frame, the sender decrements its transfer window size by the amount of data transmitted. When the window size becomes less than or equal to 0, the sender must pause transmitting data frames. At the other end of the stream, the recipient sends a WINDOW_UPDATE control back to notify the sender that it has consumed some data and freed up buffer space to receive more data.
- 0 1 2 3 4 5 6 7 - +--------+--------+--------+-|-------+--------+--------+--------+--------+ - | Length(16) |Flags(8)|1| Stream-ID(31) | 0x9| -> - +--------+--------+--------+-|-------+--------+--------+--------+--------+ - - 8 9 10 11 - +--------+--------+--------+--------+ - |Delta-Window-Size | - +--------+--------+--------+--------+ - + 0 1 2 3 4 5 6 7 + +--------+--------+--------+--------+-|-------+--------+--------+--------+ + | Length(16) | 0x9 |Flags(8)|X| Stream-ID(31) | -> + +--------+--------+--------+--------+-|-------+--------+--------+--------+ + + 8 9 10 11 + +--------+--------+--------+--------+ + |Delta-Window-Size | + +--------+--------+--------+--------+
- Control bit: The control bit is always 1 for this message. - - Version: The SPDY version number. - - Type: The message type for a WINDOW_UPDATE message is 9. - - Length: The length field is always 8 for this frame (there are 8 bytes after the length field). + Length: An unsigned 16-bit value representing the number of bytes which follow the frame header. For WINDOW_UPDATE frames, this value is always 4. Stream-ID: The stream ID that this WINDOW_UPDATE control frame is for. @@ -650,21 +673,20 @@
- 0 1 2 3 4 5 6 7 - +--------+--------+--------+-|-------+--------+--------+--------+--------+ - | Length(16) |Flags(8)|1| Num-of-Entries-or-Stream-ID-or-ID| 0xa| -> - +--------+--------+--------+-|-------+--------+--------+--------+--------+ - - 8 9 10 11 12 - +--------+--------+--------+--------+========+ - | Slot(16) |Proof Length(16) | Proof | -> - +--------+--------+--------+--------+========+ - - /--Repeated to frame end--\ - +--------+--------+========+ - | Cert Length(16) | Cert | - +--------+--------+========+ - + 0 1 2 3 4 5 6 7 + +--------+--------+--------+--------+-|-------+--------+--------+--------+ + | Length(16) | 0xa |Flags(8)|X| Num-of-Entires(31) | -> + +--------+--------+--------+--------+-|-------+--------+--------+--------+ + + 8 9 10 11 12 + +--------+--------+--------+--------+========+ + | Slot(16) |Proof Length(16) | Proof | -> + +--------+--------+--------+--------+========+ + + /--Repeated to frame end--\ + +--------+--------+========+ + | Cert Length(16) | Cert | + +--------+--------+========+
@@ -675,42 +697,6 @@ If the server receives an invalid CREDENTIAL frame, it MUST respond with a GOAWAY frame and shutdown the session.
-
- The PUSH_PROMISE control frame allows the sender to signal a promise to create a stream and serve the referenced resource. Minimal data allowing the receiver to understand which resource(s) are to be pushed are to be included. -
- - 0 1 2 3 4 5 6 7 - +--------+--------+--------+-|-------+--------+--------+--------+--------+ - | Length(16) |Flags(8)|1| Associated-To-Stream-ID(31) | 0xb| -> - +--------+--------+--------+-|-------+--------+--------+--------+--------+ - - 8 9 10 11 12,13,14..N - +-|-------+--------+--------+--------+=========================+ - |X| Promised-Stream-Id(31) | Name/Value Header Block | - +-|-------+--------+--------+--------+=========================+ - -
- - - Flags: Flags related to this frame. Valid flags are: - - 0x01 = FLAG_FIN - marks this frame as the last frame to be transmitted on this stream and puts the sender in the half-closed state. - - - - Length: The length is the number of bytes which follow the length field in the frame. For PUSH_PROMISE frames, this is 10 bytes plus the length of the compressed Name/Value block. - - Stream-ID: The 31-bit identifier for this stream. This stream-id will be used in frames which are part of this stream. - - Associated-To-Stream-ID: The 31-bit identifier for a stream which this stream is associated to. If this stream is independent of all other streams, it should be 0. - Promised-Stream-ID: The 31-bit identifier indicating the stream-id on which the resource will be pushed. If multiple headers are indicated within the Name/Value Header Block, each subsequent resource as indicated in the Header Block will increment the Promised-Stream-Id by two. The Promised-Stream-ID is subject to the same rules as any other stream-id-- when defined and transmitted, the Promised-Stream-ID MUST be part of a monotonically increasing sequence of stream-ids. There is no requirement that the streams referred to by the this frame are created in the order referenced. - - Name/Value Header Block: A set of name/value pairs carried as part of the PUSH_PROMISE. see Name/Value Header Block. - - If an endpoint receives a PUSH_PROMISE which is larger than the implementation supports, it MAY send a RST_STREAM with error code FRAME_TOO_LARGE. All implementations MUST support the minimum size limits defined in the Control Frames section. - -
-
A Name/Value Header Block augments the streams or group of streams identified by the SYN_STREAM, HEADERS, or SYN_REPLY frame stream with additional metadata.