idnits 2.17.1 draft-ietf-httpbis-http2-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([RFC2616]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The message is intentionally extensible for future information which may improve client-server communications. The sender does not need to send every type of ID/value. It must only send those for which it has accurate values to convey. When multiple ID/value pairs are sent, they should be sent in order of lowest id to highest id. A single SETTINGS frame MUST not contain multiple values for the same ID. If the recipient of a SETTINGS frame discovers multiple values for the same ID, it MUST ignore all values except the first one. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The Connection, Host, Keep-Alive, Proxy-Connection, and Transfer-Encoding headers are not valid and MUST not be sent. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The Connection, Keep-Alive, Proxy-Connection, and Transfer-Encoding headers are not valid and MUST not be sent. -- The document date (November 28, 2012) is 4166 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2285' is defined on line 2074, but no explicit reference was found in the text == Unused Reference: 'RFC4366' is defined on line 2087, but no explicit reference was found in the text == Unused Reference: 'TLSNPN' is defined on line 2102, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ASCII' ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) ** Downref: Normative reference to an Informational RFC: RFC 1950 ** Downref: Normative reference to an Informational RFC: RFC 2285 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 4366 (Obsoleted by RFC 5246, RFC 6066) ** Downref: Normative reference to an Informational RFC: RFC 4559 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-04) exists of draft-agl-tls-nextprotoneg-01 -- Possible downref: Normative reference to a draft: ref. 'TLSNPN' -- Possible downref: Non-RFC (?) normative reference: ref. 'UDELCOMPRESSION' Summary: 11 errors (**), 0 flaws (~~), 10 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTPbis Working Group M. Belshe 3 Internet-Draft Twist 4 Expires: June 1, 2013 R. Peon 5 Google, Inc 6 M. Thomson, Ed. 7 Microsoft 8 A. Melnikov, Ed. 9 Isode Ltd 10 November 28, 2012 12 SPDY Protocol 13 draft-ietf-httpbis-http2-00 15 Abstract 17 This document describes SPDY, a protocol designed for low-latency 18 transport of content over the World Wide Web. SPDY introduces two 19 layers of protocol. The lower layer is a general purpose framing 20 layer which can be used atop a reliable transport (likely TCP) for 21 multiplexed, prioritized, and compressed data communication of many 22 concurrent streams. The upper layer of the protocol provides HTTP- 23 like RFC2616 [RFC2616] semantics for compatibility with existing HTTP 24 application servers. 26 Editorial Note (To be removed by RFC Editor) 28 This draft is a work-in-progress, and does not yet reflect Working 29 Group consensus. 31 This first draft uses the SPDY Protocol as a starting point, as per 32 the Working Group's charter. Future drafts will add, remove and 33 change text, based upon the Working Group's decisions. 35 Discussion of this draft takes place on the HTTPBIS working group 36 mailing list (ietf-http-wg@w3.org), which is archived at 37 . 39 The current issues list is at 40 and related 41 documents (including fancy diffs) can be found at 42 . 44 The changes in this draft are summarized in Appendix A.1. 46 Status of This Memo 48 This Internet-Draft is submitted in full conformance with the 49 provisions of BCP 78 and BCP 79. 51 Internet-Drafts are working documents of the Internet Engineering 52 Task Force (IETF). Note that other groups may also distribute 53 working documents as Internet-Drafts. The list of current Internet- 54 Drafts is at http://datatracker.ietf.org/drafts/current/. 56 Internet-Drafts are draft documents valid for a maximum of six months 57 and may be updated, replaced, or obsoleted by other documents at any 58 time. It is inappropriate to use Internet-Drafts as reference 59 material or to cite them other than as "work in progress." 61 This Internet-Draft will expire on June 1, 2013. 63 Copyright Notice 65 Copyright (c) 2012 IETF Trust and the persons identified as the 66 document authors. All rights reserved. 68 This document is subject to BCP 78 and the IETF Trust's Legal 69 Provisions Relating to IETF Documents 70 (http://trustee.ietf.org/license-info) in effect on the date of 71 publication of this document. Please review these documents 72 carefully, as they describe your rights and restrictions with respect 73 to this document. Code Components extracted from this document must 74 include Simplified BSD License text as described in Section 4.e of 75 the Trust Legal Provisions and are provided without warranty as 76 described in the Simplified BSD License. 78 Table of Contents 80 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 81 1.1. Document Organization . . . . . . . . . . . . . . . . . . 4 82 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 83 2. SPDY Framing Layer . . . . . . . . . . . . . . . . . . . . . . 5 84 2.1. Session (Connections) . . . . . . . . . . . . . . . . . . 5 85 2.2. Framing . . . . . . . . . . . . . . . . . . . . . . . . . 5 86 2.2.1. Control frames . . . . . . . . . . . . . . . . . . . . 6 87 2.2.2. Data frames . . . . . . . . . . . . . . . . . . . . . 7 88 2.3. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 8 89 2.3.1. Stream frames . . . . . . . . . . . . . . . . . . . . 8 90 2.3.2. Stream creation . . . . . . . . . . . . . . . . . . . 8 91 2.3.3. Stream priority . . . . . . . . . . . . . . . . . . . 9 92 2.3.4. Stream headers . . . . . . . . . . . . . . . . . . . . 9 93 2.3.5. Stream data exchange . . . . . . . . . . . . . . . . . 10 94 2.3.6. Stream half-close . . . . . . . . . . . . . . . . . . 10 95 2.3.7. Stream close . . . . . . . . . . . . . . . . . . . . . 10 96 2.4. Error Handling . . . . . . . . . . . . . . . . . . . . . . 11 97 2.4.1. Session Error Handling . . . . . . . . . . . . . . . . 11 98 2.4.2. Stream Error Handling . . . . . . . . . . . . . . . . 11 99 2.5. Data flow . . . . . . . . . . . . . . . . . . . . . . . . 12 100 2.6. Control frame types . . . . . . . . . . . . . . . . . . . 12 101 2.6.1. SYN_STREAM . . . . . . . . . . . . . . . . . . . . . . 12 102 2.6.2. SYN_REPLY . . . . . . . . . . . . . . . . . . . . . . 13 103 2.6.3. RST_STREAM . . . . . . . . . . . . . . . . . . . . . . 14 104 2.6.4. SETTINGS . . . . . . . . . . . . . . . . . . . . . . . 16 105 2.6.5. PING . . . . . . . . . . . . . . . . . . . . . . . . . 19 106 2.6.6. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . . 20 107 2.6.7. HEADERS . . . . . . . . . . . . . . . . . . . . . . . 21 108 2.6.8. WINDOW_UPDATE . . . . . . . . . . . . . . . . . . . . 22 109 2.6.9. CREDENTIAL . . . . . . . . . . . . . . . . . . . . . . 24 110 2.6.10. Name/Value Header Block . . . . . . . . . . . . . . . 26 111 3. HTTP Layering over SPDY . . . . . . . . . . . . . . . . . . . 32 112 3.1. Connection Management . . . . . . . . . . . . . . . . . . 32 113 3.1.1. Use of GOAWAY . . . . . . . . . . . . . . . . . . . . 32 114 3.2. HTTP Request/Response . . . . . . . . . . . . . . . . . . 33 115 3.2.1. Request . . . . . . . . . . . . . . . . . . . . . . . 33 116 3.2.2. Response . . . . . . . . . . . . . . . . . . . . . . . 35 117 3.2.3. Authentication . . . . . . . . . . . . . . . . . . . . 35 118 3.3. Server Push Transactions . . . . . . . . . . . . . . . . . 36 119 3.3.1. Server implementation . . . . . . . . . . . . . . . . 37 120 3.3.2. Client implementation . . . . . . . . . . . . . . . . 38 121 4. Design Rationale and Notes . . . . . . . . . . . . . . . . . . 39 122 4.1. Separation of Framing Layer and Application Layer . . . . 39 123 4.2. Error handling - Framing Layer . . . . . . . . . . . . . . 39 124 4.3. One Connection Per Domain . . . . . . . . . . . . . . . . 40 125 4.4. Fixed vs Variable Length Fields . . . . . . . . . . . . . 40 126 4.5. Compression Context(s) . . . . . . . . . . . . . . . . . . 41 127 4.6. Unidirectional streams . . . . . . . . . . . . . . . . . . 41 128 4.7. Data Compression . . . . . . . . . . . . . . . . . . . . . 41 129 4.8. Server Push . . . . . . . . . . . . . . . . . . . . . . . 42 130 5. Security Considerations . . . . . . . . . . . . . . . . . . . 42 131 5.1. Use of Same-origin constraints . . . . . . . . . . . . . . 42 132 5.2. HTTP Headers and SPDY Headers . . . . . . . . . . . . . . 42 133 5.3. Cross-Protocol Attacks . . . . . . . . . . . . . . . . . . 42 134 5.4. Server Push Implicit Headers . . . . . . . . . . . . . . . 42 135 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 43 136 6.1. Long Lived Connections . . . . . . . . . . . . . . . . . . 43 137 6.2. SETTINGS frame . . . . . . . . . . . . . . . . . . . . . . 43 138 7. Incompatibilities with SPDY draft #2 . . . . . . . . . . . . . 43 139 8. Requirements Notation . . . . . . . . . . . . . . . . . . . . 44 140 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44 141 10. Normative References . . . . . . . . . . . . . . . . . . . . . 44 142 Appendix A. Change Log (to be removed by RFC Editor before 143 publication) . . . . . . . . . . . . . . . . . . . . 45 144 A.1. Since draft-mbelshe-httpbis-spdy-00 . . . . . . . . . . . 45 146 1. Overview 148 One of the bottlenecks of HTTP implementations is that HTTP relies on 149 multiple connections for concurrency. This causes several problems, 150 including additional round trips for connection setup, slow-start 151 delays, and connection rationing by the client, where it tries to 152 avoid opening too many connections to any single server. HTTP 153 pipelining helps some, but only achieves partial multiplexing. In 154 addition, pipelining has proven non-deployable in existing browsers 155 due to intermediary interference. 157 SPDY adds a framing layer for multiplexing multiple, concurrent 158 streams across a single TCP connection (or any reliable transport 159 stream). The framing layer is optimized for HTTP-like request- 160 response streams, such that applications which run over HTTP today 161 can work over SPDY with little or no change on behalf of the web 162 application writer. 164 The SPDY session offers four improvements over HTTP: 166 Multiplexed requests: There is no limit to the number of requests 167 that can be issued concurrently over a single SPDY connection. 169 Prioritized requests: Clients can request certain resources to be 170 delivered first. This avoids the problem of congesting the 171 network channel with non-critical resources when a high-priority 172 request is pending. 174 Compressed headers: Clients today send a significant amount of 175 redundant data in the form of HTTP headers. Because a single web 176 page may require 50 or 100 subrequests, this data is significant. 178 Server pushed streams: Server Push enables content to be pushed 179 from servers to clients without a request. 181 SPDY attempts to preserve the existing semantics of HTTP. All 182 features such as cookies, ETags, Vary headers, Content-Encoding 183 negotiations, etc work as they do with HTTP; SPDY only replaces the 184 way the data is written to the network. 186 1.1. Document Organization 188 The SPDY Specification is split into two parts: a framing layer 189 (Section 2), which multiplexes a TCP connection into independent, 190 length-prefixed frames, and an HTTP layer (Section 3), which 191 specifies the mechanism for overlaying HTTP request/response pairs on 192 top of the framing layer. While some of the framing layer concepts 193 are isolated from the HTTP layer, building a generic framing layer 194 has not been a goal. The framing layer is tailored to the needs of 195 the HTTP protocol and server push. 197 1.2. Definitions 199 client: The endpoint initiating the SPDY session. 201 connection: A transport-level connection between two endpoints. 203 endpoint: Either the client or server of a connection. 205 frame: A header-prefixed sequence of bytes sent over a SPDY 206 session. 208 server: The endpoint which did not initiate the SPDY session. 210 session: A synonym for a connection. 212 session error: An error on the SPDY session. 214 stream: A bi-directional flow of bytes across a virtual channel 215 within a SPDY session. 217 stream error: An error on an individual SPDY stream. 219 2. SPDY Framing Layer 221 2.1. Session (Connections) 223 The SPDY framing layer (or "session") runs atop a reliable transport 224 layer such as TCP [RFC0793]. The client is the TCP connection 225 initiator. SPDY connections are persistent connections. 227 For best performance, it is expected that clients will not close open 228 connections until the user navigates away from all web pages 229 referencing a connection, or until the server closes the connection. 230 Servers are encouraged to leave connections open for as long as 231 possible, but can terminate idle connections if necessary. When 232 either endpoint closes the transport-level connection, it MUST first 233 send a GOAWAY (Section 2.6.6) frame so that the endpoints can 234 reliably determine if requests finished before the close. 236 2.2. Framing 238 Once the connection is established, clients and servers exchange 239 framed messages. There are two types of frames: control frames 240 (Section 2.2.1) and data frames (Section 2.2.2). Frames always have 241 a common header which is 8 bytes in length. 243 The first bit is a control bit indicating whether a frame is a 244 control frame or data frame. Control frames carry a version number, 245 a frame type, flags, and a length. Data frames contain the stream 246 ID, flags, and the length for the payload carried after the common 247 header. The simple header is designed to make reading and writing of 248 frames easy. 250 All integer values, including length, version, and type, are in 251 network byte order. SPDY does not enforce alignment of types in 252 dynamically sized frames. 254 2.2.1. Control frames 256 +----------------------------------+ 257 |C| Version(15bits) | Type(16bits) | 258 +----------------------------------+ 259 | Flags (8) | Length (24 bits) | 260 +----------------------------------+ 261 | Data | 262 +----------------------------------+ 264 Control bit: The 'C' bit is a single bit indicating if this is a 265 control message. For control frames this value is always 1. 267 Version: The version number of the SPDY protocol. This document 268 describes SPDY version 3. 270 Type: The type of control frame. See Control Frames for the complete 271 list of control frames. 273 Flags: Flags related to this frame. Flags for control frames and 274 data frames are different. 276 Length: An unsigned 24-bit value representing the number of bytes 277 after the length field. 279 Data: data associated with this control frame. The format and length 280 of this data is controlled by the control frame type. 282 Control frame processing requirements: 284 Note that full length control frames (16MB) can be large for 285 implementations running on resource-limited hardware. In such 286 cases, implementations MAY limit the maximum length frame 287 supported. However, all implementations MUST be able to receive 288 control frames of at least 8192 octets in length. 290 2.2.2. Data frames 292 +----------------------------------+ 293 |C| Stream-ID (31bits) | 294 +----------------------------------+ 295 | Flags (8) | Length (24 bits) | 296 +----------------------------------+ 297 | Data | 298 +----------------------------------+ 300 Control bit: For data frames this value is always 0. 302 Stream-ID: A 31-bit value identifying the stream. 304 Flags: Flags related to this frame. Valid flags are: 306 0x01 = FLAG_FIN - signifies that this frame represents the last 307 frame to be transmitted on this stream. See Stream Close 308 (Section 2.3.7) below. 310 0x02 = FLAG_COMPRESS - indicates that the data in this frame has 311 been compressed. 313 Length: An unsigned 24-bit value representing the number of bytes 314 after the length field. The total size of a data frame is 8 bytes + 315 length. It is valid to have a zero-length data frame. 317 Data: The variable-length data payload; the length was defined in the 318 length field. 320 Data frame processing requirements: 322 If an endpoint receives a data frame for a stream-id which is not 323 open and the endpoint has not sent a GOAWAY (Section 2.6.6) frame, 324 it MUST send issue a stream error (Section 2.4.2) with the error 325 code INVALID_STREAM for the stream-id. 327 If the endpoint which created the stream receives a data frame 328 before receiving a SYN_REPLY on that stream, it is a protocol 329 error, and the recipient MUST issue a stream error (Section 2.4.2) 330 with the status code PROTOCOL_ERROR for the stream-id. 332 Implementors note: If an endpoint receives multiple data frames 333 for invalid stream-ids, it MAY close the session. 335 All SPDY endpoints MUST accept compressed data frames. 336 Compression of data frames is always done using zlib compression. 337 Each stream initializes and uses its own compression context 338 dedicated to use within that stream. Endpoints are encouraged to 339 use application level compression rather than SPDY stream level 340 compression. 342 Each SPDY stream sending compressed frames creates its own zlib 343 context for that stream, and these compression contexts MUST be 344 distinct from the compression contexts used with SYN_STREAM/ 345 SYN_REPLY/HEADER compression. (Thus, if both endpoints of a 346 stream are compressing data on the stream, there will be two zlib 347 contexts, one for sending and one for receiving). 349 2.3. Streams 351 Streams are independent sequences of bi-directional data divided into 352 frames with several properties: 354 Streams may be created by either the client or server. 356 Streams optionally carry a set of name/value header pairs. 358 Streams can concurrently send data interleaved with other streams. 360 Streams may be cancelled. 362 2.3.1. Stream frames 364 SPDY defines 3 control frames to manage the lifecycle of a stream: 366 SYN_STREAM - Open a new stream 368 SYN_REPLY - Remote acknowledgement of a new, open stream 370 RST_STREAM - Close a stream 372 2.3.2. Stream creation 374 A stream is created by sending a control frame with the type set to 375 SYN_STREAM (Section 2.6.1). If the server is initiating the stream, 376 the Stream-ID must be even. If the client is initiating the stream, 377 the Stream-ID must be odd. 0 is not a valid Stream-ID. Stream-IDs 378 from each side of the connection must increase monotonically as new 379 streams are created. E.g. Stream 2 may be created after stream 3, 380 but stream 7 must not be created after stream 9. Stream IDs do not 381 wrap: when a client or server cannot create a new stream id without 382 exceeding a 31 bit value, it MUST NOT create a new stream. 384 The stream-id MUST increase with each new stream. If an endpoint 385 receives a SYN_STREAM with a stream id which is less than any 386 previously received SYN_STREAM, it MUST issue a session error 387 (Section 2.4.1) with the status PROTOCOL_ERROR. 389 It is a protocol error to send two SYN_STREAMs with the same 390 stream-id. If a recipient receives a second SYN_STREAM for the same 391 stream, it MUST issue a stream error (Section 2.4.2) with the status 392 code PROTOCOL_ERROR. 394 Upon receipt of a SYN_STREAM, the recipient can reject the stream by 395 sending a stream error (Section 2.4.2) with the error code 396 REFUSED_STREAM. Note, however, that the creating endpoint may have 397 already sent additional frames for that stream which cannot be 398 immediately stopped. 400 Once the stream is created, the creator may immediately send HEADERS 401 or DATA frames for that stream, without needing to wait for the 402 recipient to acknowledge. 404 2.3.2.1. Unidirectional streams 406 When an endpoint creates a stream with the FLAG_UNIDIRECTIONAL flag 407 set, it creates a unidirectional stream which the creating endpoint 408 can use to send frames, but the receiving endpoint cannot. The 409 receiving endpoint is implicitly already in the half-closed 410 (Section 2.3.6) state. 412 2.3.2.2. Bidirectional streams 414 SYN_STREAM frames which do not use the FLAG_UNIDIRECTIONAL flag are 415 bidirectional streams. Both endpoints can send data on a bi- 416 directional stream. 418 2.3.3. Stream priority 420 The creator of a stream assigns a priority for that stream. Priority 421 is represented as an integer from 0 to 7. 0 represents the highest 422 priority and 7 represents the lowest priority. 424 The sender and recipient SHOULD use best-effort to process streams in 425 the order of highest priority to lowest priority. 427 2.3.4. Stream headers 429 Streams carry optional sets of name/value pair headers which carry 430 metadata about the stream. After the stream has been created, and as 431 long as the sender is not closed (Section 2.3.7) or half-closed 432 (Section 2.3.6), each side may send HEADERS frame(s) containing the 433 header data. Header data can be sent in multiple HEADERS frames, and 434 HEADERS frames may be interleaved with data frames. 436 2.3.5. Stream data exchange 438 Once a stream is created, it can be used to send arbitrary amounts of 439 data. Generally this means that a series of data frames will be sent 440 on the stream until a frame containing the FLAG_FIN flag is set. The 441 FLAG_FIN can be set on a SYN_STREAM (Section 2.6.1), SYN_REPLY 442 (Section 2.6.2), HEADERS (Section 2.6.7) or a DATA (Section 2.2.2) 443 frame. Once the FLAG_FIN has been sent, the stream is considered to 444 be half-closed. 446 2.3.6. Stream half-close 448 When one side of the stream sends a frame with the FLAG_FIN flag set, 449 the stream is half-closed from that endpoint. The sender of the 450 FLAG_FIN MUST NOT send further frames on that stream. When both 451 sides have half-closed, the stream is closed. 453 If an endpoint receives a data frame after the stream is half-closed 454 from the sender (e.g. the endpoint has already received a prior frame 455 for the stream with the FIN flag set), it MUST send a RST_STREAM to 456 the sender with the status STREAM_ALREADY_CLOSED. 458 2.3.7. Stream close 460 There are 3 ways that streams can be terminated: 462 Normal termination: Normal stream termination occurs when both 463 sender and recipient have half-closed the stream by sending a 464 FLAG_FIN. 466 Abrupt termination: Either the client or server can send a 467 RST_STREAM control frame at any time. A RST_STREAM contains an 468 error code to indicate the reason for failure. When a RST_STREAM 469 is sent from the stream originator, it indicates a failure to 470 complete the stream and that no further data will be sent on the 471 stream. When a RST_STREAM is sent from the stream recipient, the 472 sender, upon receipt, should stop sending any data on the stream. 473 The stream recipient should be aware that there is a race between 474 data already in transit from the sender and the time the 475 RST_STREAM is received. See Stream Error Handling (Section 2.4.2) 477 TCP connection teardown: If the TCP connection is torn down while 478 un-closed streams exist, then the endpoint must assume that the 479 stream was abnormally interrupted and may be incomplete. 481 If an endpoint receives a data frame after the stream is closed, it 482 must send a RST_STREAM to the sender with the status PROTOCOL_ERROR. 484 2.4. Error Handling 486 The SPDY framing layer has only two types of errors, and they are 487 always handled consistently. Any reference in this specification to 488 "issue a session error" refers to Section 2.4.1. Any reference to 489 "issue a stream error" refers to Section 2.4.2. 491 2.4.1. Session Error Handling 493 A session error is any error which prevents further processing of the 494 framing layer or which corrupts the session compression state. When 495 a session error occurs, the endpoint encountering the error MUST 496 first send a GOAWAY (Section 2.6.6) frame with the stream id of most 497 recently received stream from the remote endpoint, and the error code 498 for why the session is terminating. After sending the GOAWAY frame, 499 the endpoint MUST close the TCP connection. 501 Note that the session compression state is dependent upon both 502 endpoints always processing all compressed data. If an endpoint 503 partially processes a frame containing compressed data without 504 updating compression state properly, future control frames which use 505 compression will be always be errored. Implementations SHOULD always 506 try to process compressed data so that errors which could be handled 507 as stream errors do not become session errors. 509 Note that because this GOAWAY is sent during a session error case, it 510 is possible that the GOAWAY will not be reliably received by the 511 receiving endpoint. It is a best-effort attempt to communicate with 512 the remote about why the session is going down. 514 2.4.2. Stream Error Handling 516 A stream error is an error related to a specific stream-id which does 517 not affect processing of other streams at the framing layer. Upon a 518 stream error, the endpoint MUST send a RST_STREAM (Section 2.6.3) 519 frame which contains the stream id of the stream where the error 520 occurred and the error status which caused the error. After sending 521 the RST_STREAM, the stream is closed to the sending endpoint. After 522 sending the RST_STREAM, if the sender receives any frames other than 523 a RST_STREAM for that stream id, it will result in sending additional 524 RST_STREAM frames. An endpoint MUST NOT send a RST_STREAM in 525 response to an RST_STREAM, as doing so would lead to RST_STREAM 526 loops. Sending a RST_STREAM does not cause the SPDY session to be 527 closed. 529 If an endpoint has multiple RST_STREAM frames to send in succession 530 for the same stream-id and the same error code, it MAY coalesce them 531 into a single RST_STREAM frame. (This can happen if a stream is 532 closed, but the remote sends multiple data frames. There is no 533 reason to send a RST_STREAM for each frame in succession). 535 2.5. Data flow 537 Because TCP provides a single stream of data on which SPDY 538 multiplexes multiple logical streams, clients and servers must 539 intelligently interleave data messages for concurrent sessions. 541 2.6. Control frame types 543 2.6.1. SYN_STREAM 545 The SYN_STREAM control frame allows the sender to asynchronously 546 create a stream between the endpoints. See Stream Creation 547 (Section 2.3.2) 549 +------------------------------------+ 550 |1| version | 1 | 551 +------------------------------------+ 552 | Flags (8) | Length (24 bits) | 553 +------------------------------------+ 554 |X| Stream-ID (31bits) | 555 +------------------------------------+ 556 |X| Associated-To-Stream-ID (31bits) | 557 +------------------------------------+ 558 | Pri|Unused | Slot | | 559 +-------------------+ | 560 | Number of Name/Value pairs (int32) | <+ 561 +------------------------------------+ | 562 | Length of name (int32) | | This section is the 563 +------------------------------------+ | "Name/Value Header 564 | Name (string) | | Block", and is 565 +------------------------------------+ | compressed. 566 | Length of value (int32) | | 567 +------------------------------------+ | 568 | Value (string) | | 569 +------------------------------------+ | 570 | (repeats) | <+ 572 Flags: Flags related to this frame. Valid flags are: 574 0x01 = FLAG_FIN - marks this frame as the last frame to be 575 transmitted on this stream and puts the sender in the half-closed 576 (Section 2.3.6) state. 578 0x02 = FLAG_UNIDIRECTIONAL - a stream created with this flag puts 579 the recipient in the half-closed (Section 2.3.6) state. 581 Length: The length is the number of bytes which follow the length 582 field in the frame. For SYN_STREAM frames, this is 10 bytes plus the 583 length of the compressed Name/Value block. 585 Stream-ID: The 31-bit identifier for this stream. This stream-id 586 will be used in frames which are part of this stream. 588 Associated-To-Stream-ID: The 31-bit identifier for a stream which 589 this stream is associated to. If this stream is independent of all 590 other streams, it should be 0. 592 Priority: A 3-bit priority (Section 2.3.3) field. 594 Unused: 5 bits of unused space, reserved for future use. 596 Slot: An 8 bit unsigned integer specifying the index in the server's 597 CREDENTIAL vector of the client certificate to be used for this 598 request. see CREDENTIAL frame (Section 2.6.9). The value 0 means no 599 client certificate should be associated with this stream. 601 Name/Value Header Block: A set of name/value pairs carried as part of 602 the SYN_STREAM. see Name/Value Header Block (Section 2.6.10). 604 If an endpoint receives a SYN_STREAM which is larger than the 605 implementation supports, it MAY send a RST_STREAM with error code 606 FRAME_TOO_LARGE. All implementations MUST support the minimum size 607 limits defined in the Control Frames section (Section 2.2.1). 609 2.6.2. SYN_REPLY 611 SYN_REPLY indicates the acceptance of a stream creation by the 612 recipient of a SYN_STREAM frame. 614 +------------------------------------+ 615 |1| version | 2 | 616 +------------------------------------+ 617 | Flags (8) | Length (24 bits) | 618 +------------------------------------+ 619 |X| Stream-ID (31bits) | 620 +------------------------------------+ 621 | Number of Name/Value pairs (int32) | <+ 622 +------------------------------------+ | 623 | Length of name (int32) | | This section is the 624 +------------------------------------+ | "Name/Value Header 625 | Name (string) | | Block", and is 626 +------------------------------------+ | compressed. 627 | Length of value (int32) | | 628 +------------------------------------+ | 629 | Value (string) | | 630 +------------------------------------+ | 631 | (repeats) | <+ 633 Flags: Flags related to this frame. Valid flags are: 635 0x01 = FLAG_FIN - marks this frame as the last frame to be 636 transmitted on this stream and puts the sender in the half-closed 637 (Section 2.3.6) state. 639 Length: The length is the number of bytes which follow the length 640 field in the frame. For SYN_REPLY frames, this is 4 bytes plus the 641 length of the compressed Name/Value block. 643 Stream-ID: The 31-bit identifier for this stream. 645 If an endpoint receives multiple SYN_REPLY frames for the same active 646 stream ID, it MUST issue a stream error (Section 2.4.2) with the 647 error code STREAM_IN_USE. 649 Name/Value Header Block: A set of name/value pairs carried as part of 650 the SYN_STREAM. see Name/Value Header Block (Section 2.6.10). 652 If an endpoint receives a SYN_REPLY which is larger than the 653 implementation supports, it MAY send a RST_STREAM with error code 654 FRAME_TOO_LARGE. All implementations MUST support the minimum size 655 limits defined in the Control Frames section (Section 2.2.1). 657 2.6.3. RST_STREAM 659 The RST_STREAM frame allows for abnormal termination of a stream. 660 When sent by the creator of a stream, it indicates the creator wishes 661 to cancel the stream. When sent by the recipient of a stream, it 662 indicates an error or that the recipient did not want to accept the 663 stream, so the stream should be closed. 665 +----------------------------------+ 666 |1| version | 3 | 667 +----------------------------------+ 668 | Flags (8) | 8 | 669 +----------------------------------+ 670 |X| Stream-ID (31bits) | 671 +----------------------------------+ 672 | Status code | 673 +----------------------------------+ 675 Flags: Flags related to this frame. RST_STREAM does not define any 676 flags. This value must be 0. 678 Length: An unsigned 24-bit value representing the number of bytes 679 after the length field. For RST_STREAM control frames, this value is 680 always 8. 682 Stream-ID: The 31-bit identifier for this stream. 684 Status code: (32 bits) An indicator for why the stream is being 685 terminated.The following status codes are defined: 687 1 - PROTOCOL_ERROR. This is a generic error, and should only be 688 used if a more specific error is not available. 690 2 - INVALID_STREAM. This is returned when a frame is received for 691 a stream which is not active. 693 3 - REFUSED_STREAM. Indicates that the stream was refused before 694 any processing has been done on the stream. 696 4 - UNSUPPORTED_VERSION. Indicates that the recipient of a stream 697 does not support the SPDY version requested. 699 5 - CANCEL. Used by the creator of a stream to indicate that the 700 stream is no longer needed. 702 6 - INTERNAL_ERROR. This is a generic error which can be used 703 when the implementation has internally failed, not due to anything 704 in the protocol. 706 7 - FLOW_CONTROL_ERROR. The endpoint detected that its peer 707 violated the flow control protocol. 709 8 - STREAM_IN_USE. The endpoint received a SYN_REPLY for a stream 710 already open. 712 9 - STREAM_ALREADY_CLOSED. The endpoint received a data or 713 SYN_REPLY frame for a stream which is half closed. 715 10 - INVALID_CREDENTIALS. The server received a request for a 716 resource whose origin does not have valid credentials in the 717 client certificate vector. 719 11 - FRAME_TOO_LARGE. The endpoint received a frame which this 720 implementation could not support. If FRAME_TOO_LARGE is sent for 721 a SYN_STREAM, HEADERS, or SYN_REPLY frame without fully processing 722 the compressed portion of those frames, then the compression state 723 will be out-of-sync with the other endpoint. In this case, 724 senders of FRAME_TOO_LARGE MUST close the session. 726 Note: 0 is not a valid status code for a RST_STREAM. 728 After receiving a RST_STREAM on a stream, the recipient must not send 729 additional frames for that stream, and the stream moves into the 730 closed state. 732 2.6.4. SETTINGS 734 A SETTINGS frame contains a set of id/value pairs for communicating 735 configuration data about how the two endpoints may communicate. 736 SETTINGS frames can be sent at any time by either endpoint, are 737 optionally sent, and are fully asynchronous. When the server is the 738 sender, the sender can request that configuration data be persisted 739 by the client across SPDY sessions and returned to the server in 740 future communications. 742 Persistence of SETTINGS ID/Value pairs is done on a per origin/IP 743 pair (the "origin" is the set of scheme, host, and port from the URI. 744 See [RFC6454]). That is, when a client connects to a server, and the 745 server persists settings within the client, the client SHOULD return 746 the persisted settings on future connections to the same origin AND 747 IP address and TCP port. Clients MUST NOT request servers to use the 748 persistence features of the SETTINGS frames, and servers MUST ignore 749 persistence related flags sent by a client. 751 +----------------------------------+ 752 |1| version | 4 | 753 +----------------------------------+ 754 | Flags (8) | Length (24 bits) | 755 +----------------------------------+ 756 | Number of entries | 757 +----------------------------------+ 758 | ID/Value Pairs | 759 | ... | 761 Control bit: The control bit is always 1 for this message. 763 Version: The SPDY version number. 765 Type: The message type for a SETTINGS message is 4. 767 Flags: FLAG_SETTINGS_CLEAR_SETTINGS (0x1): When set, the client 768 should clear any previously persisted SETTINGS ID/Value pairs. If 769 this frame contains ID/Value pairs with the 770 FLAG_SETTINGS_PERSIST_VALUE set, then the client will first clear its 771 existing, persisted settings, and then persist the values with the 772 flag set which are contained within this frame. Because persistence 773 is only implemented on the client, this flag can only be used when 774 the sender is the server. 776 Length: An unsigned 24-bit value representing the number of bytes 777 after the length field. The total size of a SETTINGS frame is 8 778 bytes + length. 780 Number of entries: A 32-bit value representing the number of ID/value 781 pairs in this message. 783 ID: A 32-bit ID number, comprised of 8 bits of flags and 24 bits of 784 unique ID. 786 ID.flags: 788 FLAG_SETTINGS_PERSIST_VALUE (0x1): When set, the sender of this 789 SETTINGS frame is requesting that the recipient persist the ID/ 790 Value and return it in future SETTINGS frames sent from the 791 sender to this recipient. Because persistence is only 792 implemented on the client, this flag is only sent by the 793 server. 795 FLAG_SETTINGS_PERSISTED (0x2): When set, the sender is 796 notifying the recipient that this ID/Value pair was previously 797 sent to the sender by the recipient with the 798 FLAG_SETTINGS_PERSIST_VALUE, and the sender is returning it. 800 Because persistence is only implemented on the client, this 801 flag is only sent by the client. 803 Defined IDs: 805 1 - SETTINGS_UPLOAD_BANDWIDTH allows the sender to send its 806 expected upload bandwidth on this channel. This number is an 807 estimate. The value should be the integral number of kilobytes 808 per second that the sender predicts as an expected maximum 809 upload channel capacity. 811 2 - SETTINGS_DOWNLOAD_BANDWIDTH allows the sender to send its 812 expected download bandwidth on this channel. This number is an 813 estimate. The value should be the integral number of kilobytes 814 per second that the sender predicts as an expected maximum 815 download channel capacity. 817 3 - SETTINGS_ROUND_TRIP_TIME allows the sender to send its 818 expected round-trip-time on this channel. The round trip time 819 is defined as the minimum amount of time to send a control 820 frame from this client to the remote and receive a response. 821 The value is represented in milliseconds. 823 4 - SETTINGS_MAX_CONCURRENT_STREAMS allows the sender to inform 824 the remote endpoint the maximum number of concurrent streams 825 which it will allow. By default there is no limit. For 826 implementors it is recommended that this value be no smaller 827 than 100. 829 5 - SETTINGS_CURRENT_CWND allows the sender to inform the 830 remote endpoint of the current TCP CWND value. 832 6 - SETTINGS_DOWNLOAD_RETRANS_RATE allows the sender to inform 833 the remote endpoint the retransmission rate (bytes 834 retransmitted / total bytes transmitted). 836 7 - SETTINGS_INITIAL_WINDOW_SIZE allows the sender to inform 837 the remote endpoint the initial window size (in bytes) for new 838 streams. 840 8 - SETTINGS_CLIENT_CERTIFICATE_VECTOR_SIZE allows the server 841 to inform the client if the new size of the client certificate 842 vector. 844 Value: A 32-bit value. 846 The message is intentionally extensible for future information which 847 may improve client-server communications. The sender does not need 848 to send every type of ID/value. It must only send those for which it 849 has accurate values to convey. When multiple ID/value pairs are 850 sent, they should be sent in order of lowest id to highest id. A 851 single SETTINGS frame MUST not contain multiple values for the same 852 ID. If the recipient of a SETTINGS frame discovers multiple values 853 for the same ID, it MUST ignore all values except the first one. 855 A server may send multiple SETTINGS frames containing different ID/ 856 Value pairs. When the same ID/Value is sent twice, the most recent 857 value overrides any previously sent values. If the server sends IDs 858 1, 2, and 3 with the FLAG_SETTINGS_PERSIST_VALUE in a first SETTINGS 859 frame, and then sends IDs 4 and 5 with the 860 FLAG_SETTINGS_PERSIST_VALUE, when the client returns the persisted 861 state on its next SETTINGS frame, it SHOULD send all 5 settings (1, 862 2, 3, 4, and 5 in this example) to the server. 864 2.6.5. PING 866 The PING control frame is a mechanism for measuring a minimal round- 867 trip time from the sender. It can be sent from the client or the 868 server. Recipients of a PING frame should send an identical frame to 869 the sender as soon as possible (if there is other pending data 870 waiting to be sent, PING should take highest priority). Each ping 871 sent by a sender should use a unique ID. 873 +----------------------------------+ 874 |1| version | 6 | 875 +----------------------------------+ 876 | 0 (flags) | 4 (length) | 877 +----------------------------------| 878 | 32-bit ID | 879 +----------------------------------+ 881 Control bit: The control bit is always 1 for this message. 883 Version: The SPDY version number. 885 Type: The message type for a PING message is 6. 887 Length: This frame is always 4 bytes long. 889 ID: A unique ID for this ping, represented as an unsigned 32 bit 890 value. When the client initiates a ping, it must use an odd numbered 891 ID. When the server initiates a ping, it must use an even numbered 892 ping. Use of odd/even IDs is required in order to avoid accidental 893 looping on PINGs (where each side initiates an identical PING at the 894 same time). 896 Note: If a sender uses all possible PING ids (e.g. has sent all 2^31 897 possible IDs), it can wrap and start re-using IDs. 899 If a server receives an even numbered PING which it did not initiate, 900 it must ignore the PING. If a client receives an odd numbered PING 901 which it did not initiate, it must ignore the PING. 903 2.6.6. GOAWAY 905 The GOAWAY control frame is a mechanism to tell the remote side of 906 the connection to stop creating streams on this session. It can be 907 sent from the client or the server. Once sent, the sender will not 908 respond to any new SYN_STREAMs on this session. Recipients of a 909 GOAWAY frame must not send additional streams on this session, 910 although a new session can be established for new streams. The 911 purpose of this message is to allow an endpoint to gracefully stop 912 accepting new streams (perhaps for a reboot or maintenance), while 913 still finishing processing of previously established streams. 915 There is an inherent race condition between an endpoint sending 916 SYN_STREAMs and the remote sending a GOAWAY message. To deal with 917 this case, the GOAWAY contains a last-stream-id indicating the 918 stream-id of the last stream which was created on the sending 919 endpoint in this session. If the receiver of the GOAWAY sent new 920 SYN_STREAMs for sessions after this last-stream-id, they were not 921 processed by the server and the receiver may treat the stream as 922 though it had never been created at all (hence the receiver may want 923 to re-create the stream later on a new session). 925 Endpoints should always send a GOAWAY message before closing a 926 connection so that the remote can know whether a stream has been 927 partially processed or not. (For example, if an HTTP client sends a 928 POST at the same time that a server closes a connection, the client 929 cannot know if the server started to process that POST request if the 930 server does not send a GOAWAY frame to indicate where it stopped 931 working). 933 After sending a GOAWAY message, the sender must ignore all SYN_STREAM 934 frames for new streams. 936 +----------------------------------+ 937 |1| version | 7 | 938 +----------------------------------+ 939 | 0 (flags) | 8 (length) | 940 +----------------------------------| 941 |X| Last-good-stream-ID (31 bits) | 942 +----------------------------------+ 943 | Status code | 944 +----------------------------------+ 946 Control bit: The control bit is always 1 for this message. 948 Version: The SPDY version number. 950 Type: The message type for a GOAWAY message is 7. 952 Length: This frame is always 8 bytes long. 954 Last-good-stream-Id: The last stream id which was replied to (with 955 either a SYN_REPLY or RST_STREAM) by the sender of the GOAWAY 956 message. If no streams were replied to, this value MUST be 0. 958 Status: The reason for closing the session. 960 0 - OK. This is a normal session teardown. 962 1 - PROTOCOL_ERROR. This is a generic error, and should only be 963 used if a more specific error is not available. 965 11 - INTERNAL_ERROR. This is a generic error which can be used 966 when the implementation has internally failed, not due to anything 967 in the protocol. 969 2.6.7. HEADERS 971 The HEADERS frame augments a stream with additional headers. It may 972 be optionally sent on an existing stream at any time. Specific 973 application of the headers in this frame is application-dependent. 974 The name/value header block within this frame is compressed. 976 +------------------------------------+ 977 |1| version | 8 | 978 +------------------------------------+ 979 | Flags (8) | Length (24 bits) | 980 +------------------------------------+ 981 |X| Stream-ID (31bits) | 982 +------------------------------------+ 983 | Number of Name/Value pairs (int32) | <+ 984 +------------------------------------+ | 985 | Length of name (int32) | | This section is the 986 +------------------------------------+ | "Name/Value Header 987 | Name (string) | | Block", and is 988 +------------------------------------+ | compressed. 989 | Length of value (int32) | | 990 +------------------------------------+ | 991 | Value (string) | | 992 +------------------------------------+ | 993 | (repeats) | <+ 995 Flags: Flags related to this frame. Valid flags are: 997 0x01 = FLAG_FIN - marks this frame as the last frame to be 998 transmitted on this stream and puts the sender in the half-closed 999 (Section 2.3.6) state. 1001 Length: An unsigned 24 bit value representing the number of bytes 1002 after the length field. The minimum length of the length field is 4 1003 (when the number of name value pairs is 0). 1005 Stream-ID: The stream this HEADERS block is associated with. 1007 Name/Value Header Block: A set of name/value pairs carried as part of 1008 the SYN_STREAM. see Name/Value Header Block (Section 2.6.10). 1010 2.6.8. WINDOW_UPDATE 1012 The WINDOW_UPDATE control frame is used to implement per stream flow 1013 control in SPDY. Flow control in SPDY is per hop, that is, only 1014 between the two endpoints of a SPDY connection. If there are one or 1015 more intermediaries between the client and the origin server, flow 1016 control signals are not explicitly forwarded by the intermediaries. 1017 (However, throttling of data transfer by any recipient may have the 1018 effect of indirectly propagating flow control information upstream 1019 back to the original sender.) Flow control only applies to the data 1020 portion of data frames. Recipients must buffer all control frames. 1021 If a recipient fails to buffer an entire control frame, it MUST issue 1022 a stream error (Section 2.4.2) with the status code 1023 FLOW_CONTROL_ERROR for the stream. 1025 Flow control in SPDY is implemented by a data transfer window kept by 1026 the sender of each stream. The data transfer window is a simple 1027 uint32 that indicates how many bytes of data the sender can transmit. 1028 After a stream is created, but before any data frames have been 1029 transmitted, the sender begins with the initial window size. This 1030 window size is a measure of the buffering capability of the 1031 recipient. The sender must not send a data frame with data length 1032 greater than the transfer window size. After sending each data 1033 frame, the sender decrements its transfer window size by the amount 1034 of data transmitted. When the window size becomes less than or equal 1035 to 0, the sender must pause transmitting data frames. At the other 1036 end of the stream, the recipient sends a WINDOW_UPDATE control back 1037 to notify the sender that it has consumed some data and freed up 1038 buffer space to receive more data. 1040 +----------------------------------+ 1041 |1| version | 9 | 1042 +----------------------------------+ 1043 | 0 (flags) | 8 (length) | 1044 +----------------------------------+ 1045 |X| Stream-ID (31-bits) | 1046 +----------------------------------+ 1047 |X| Delta-Window-Size (31-bits) | 1048 +----------------------------------+ 1050 Control bit: The control bit is always 1 for this message. 1052 Version: The SPDY version number. 1054 Type: The message type for a WINDOW_UPDATE message is 9. 1056 Length: The length field is always 8 for this frame (there are 8 1057 bytes after the length field). 1059 Stream-ID: The stream ID that this WINDOW_UPDATE control frame is 1060 for. 1062 Delta-Window-Size: The additional number of bytes that the sender can 1063 transmit in addition to existing remaining window size. The legal 1064 range for this field is 1 to 2^31 - 1 (0x7fffffff) bytes. 1066 The window size as kept by the sender must never exceed 2^31 1067 (although it can become negative in one special case). If a sender 1068 receives a WINDOW_UPDATE that causes the its window size to exceed 1069 this limit, it must send RST_STREAM with status code 1070 FLOW_CONTROL_ERROR to terminate the stream. 1072 When a SPDY connection is first established, the default initial 1073 window size for all streams is 64KB. An endpoint can use the 1074 SETTINGS control frame to adjust the initial window size for the 1075 connection. That is, its peer can start out using the 64KB default 1076 initial window size when sending data frames before receiving the 1077 SETTINGS. Because SETTINGS is asynchronous, there may be a race 1078 condition if the recipient wants to decrease the initial window size, 1079 but its peer immediately sends 64KB on the creation of a new 1080 connection, before waiting for the SETTINGS to arrive. This is one 1081 case where the window size kept by the sender will become negative. 1082 Once the sender detects this condition, it must stop sending data 1083 frames and wait for the recipient to catch up. The recipient has two 1084 choices: 1086 immediately send RST_STREAM with FLOW_CONTROL_ERROR status code. 1088 allow the head of line blocking (as there is only one stream for 1089 the session and the amount of data in flight is bounded by the 1090 default initial window size), and send WINDOW_UPDATE as it 1091 consumes data. 1093 In the case of option 2, both sides must compute the window size 1094 based on the initial window size in the SETTINGS. For example, if 1095 the recipient sets the initial window size to be 16KB, and the sender 1096 sends 64KB immediately on connection establishment, the sender will 1097 discover its window size is -48KB on receipt of the SETTINGS. As the 1098 recipient consumes the first 16KB, it must send a WINDOW_UPDATE of 1099 16KB back to the sender. This interaction continues until the 1100 sender's window size becomes positive again, and it can resume 1101 transmitting data frames. 1103 After the recipient reads in a data frame with FLAG_FIN that marks 1104 the end of the data stream, it should not send WINDOW_UPDATE frames 1105 as it consumes the last data frame. A sender should ignore all the 1106 WINDOW_UPDATE frames associated with the stream after it send the 1107 last frame for the stream. 1109 The data frames from the sender and the WINDOW_UPDATE frames from the 1110 recipient are completely asynchronous with respect to each other. 1111 This property allows a recipient to aggressively update the window 1112 size kept by the sender to prevent the stream from stalling. 1114 2.6.9. CREDENTIAL 1116 The CREDENTIAL control frame is used by the client to send additional 1117 client certificates to the server. A SPDY client may decide to send 1118 requests for resources from different origins on the same SPDY 1119 session if it decides that that server handles both origins. For 1120 example if the IP address associated with both hostnames matches and 1121 the SSL server certificate presented in the initial handshake is 1122 valid for both hostnames. However, because the SSL connection can 1123 contain at most one client certificate, the client needs a mechanism 1124 to send additional client certificates to the server. 1126 The server is required to maintain a vector of client certificates 1127 associated with a SPDY session. When the client needs to send a 1128 client certificate to the server, it will send a CREDENTIAL frame 1129 that specifies the index of the slot in which to store the 1130 certificate as well as proof that the client posesses the 1131 corresponding private key. The initial size of this vector must be 1132 8. If the client provides a client certificate during the first TLS 1133 handshake, the contents of this certificate must be copied into the 1134 first slot (index 1) in the CREDENTIAL vector, though it may be 1135 overwritten by subsequent CREDENTIAL frames. The server must 1136 exclusively use the CREDNETIAL vector when evaluating the client 1137 certificates associated with an origin. The server may change the 1138 size of this vector by sending a SETTINGS frame with the setting 1139 SETTINGS_CLIENT_CERTIFICATE_VECTOR_SIZE value specified. In the 1140 event that the new size is smaller than the current size, truncation 1141 occurs preserving lower-index slots as possible. 1143 TLS renegotiation with client authentication is incompatible with 1144 SPDY given the multiplexed nature of SPDY. Specifically, imagine 1145 that the client has 2 requests outstanding to the server for two 1146 different pages (in different tabs). When the renegotiation + client 1147 certificate request comes in, the browser is unable to determine 1148 which resource triggered the client certificate request, in order to 1149 prompt the user accordingly. 1151 +----------------------------------+ 1152 |1|000000000000001|0000000000001011| 1153 +----------------------------------+ 1154 | flags (8) | Length (24 bits) | 1155 +----------------------------------+ 1156 | Slot (16 bits) | | 1157 +-----------------+ | 1158 | Proof Length (32 bits) | 1159 +----------------------------------+ 1160 | Proof | 1161 +----------------------------------+ <+ 1162 | Certificate Length (32 bits) | | 1163 +----------------------------------+ | Repeated until end of frame 1164 | Certificate | | 1165 +----------------------------------+ <+ 1167 Slot: The index in the server's client certificate vector where this 1168 certificate should be stored. If there is already a certificate 1169 stored at this index, it will be overwritten. The index is one 1170 based, not zero based; zero is an invalid slot index. 1172 Proof: Cryptographic proof that the client has possession of the 1173 private key associated with the certificate. The format is a TLS 1174 digitally-signed element ([RFC5246], Section 4.7). The signature 1175 algorithm must be the same as that used in the CertificateVerify 1176 message. However, since the MD5+SHA1 signature type used in TLS 1.0 1177 connections can not be correctly encoded in a digitally-signed 1178 element, SHA1 must be used when MD5+SHA1 was used in the SSL 1179 connection. The signature is calculated over a 32 byte TLS extractor 1180 value (http://tools.ietf.org/html/rfc5705) with a label of "EXPORTER 1181 SPDY certificate proof" using the empty string as context. ForRSA 1182 certificates the signature would be a PKCS#1 v1.5 signature. For 1183 ECDSA, it would be an ECDSA-Sig-Value 1184 (http://tools.ietf.org/html/rfc5480#appendix-A). For a 1024-bit RSA 1185 key, the CREDENTIAL message would be ~500 bytes. 1187 Certificate: The certificate chain, starting with the leaf 1188 certificate. Each certificate must be encoded as a 32 bit length, 1189 followed by a DER encoded certificate. The certificate must be of 1190 the same type (RSA, ECDSA, etc) as the client certificate associated 1191 with the SSL connection. 1193 If the server receives a request for a resource with unacceptable 1194 credential (either missing or invalid), it must reply with a 1195 RST_STREAM frame with the status code INVALID_CREDENTIALS. Upon 1196 receipt of a RST_STREAM frame with INVALID_CREDENTIALS, the client 1197 should initiate a new stream directly to the requested origin and 1198 resend the request. Note, SPDY does not allow the server to request 1199 different client authentication for different resources in the same 1200 origin. 1202 If the server receives an invalid CREDENTIAL frame, it MUST respond 1203 with a GOAWAY frame and shutdown the session. 1205 2.6.10. Name/Value Header Block 1207 The Name/Value Header Block is found in the SYN_STREAM, SYN_REPLY and 1208 HEADERS control frames, and shares a common format: 1210 +------------------------------------+ 1211 | Number of Name/Value pairs (int32) | 1212 +------------------------------------+ 1213 | Length of name (int32) | 1214 +------------------------------------+ 1215 | Name (string) | 1216 +------------------------------------+ 1217 | Length of value (int32) | 1218 +------------------------------------+ 1219 | Value (string) | 1220 +------------------------------------+ 1221 | (repeats) | 1223 Number of Name/Value pairs: The number of repeating name/value pairs 1224 following this field. 1226 List of Name/Value pairs: 1228 Length of Name: a 32-bit value containing the number of octets in 1229 the name field. Note that in practice, this length must not 1230 exceed 2^24, as that is the maximum size of a SPDY frame. 1232 Name: 0 or more octets, 8-bit sequences of data, excluding 0. 1234 Length of Value: a 32-bit value containing the number of octets in 1235 the value field. Note that in practice, this length must not 1236 exceed 2^24, as that is the maximum size of a SPDY frame. 1238 Value: 0 or more octets, 8-bit sequences of data, excluding 0. 1240 Each header name must have at least one value. Header names are 1241 encoded using the US-ASCII character set [ASCII] and must be all 1242 lower case. The length of each name must be greater than zero. A 1243 recipient of a zero-length name MUST issue a stream error 1244 (Section 2.4.2) with the status code PROTOCOL_ERROR for the 1245 stream-id. 1247 Duplicate header names are not allowed. To send two identically 1248 named headers, send a header with two values, where the values are 1249 separated by a single NUL (0) byte. A header value can either be 1250 empty (e.g. the length is zero) or it can contain multiple, NUL- 1251 separated values, each with length greater than zero. The value 1252 never starts nor ends with a NUL character. Recipients of illegal 1253 value fields MUST issue a stream error (Section 2.4.2) with the 1254 status code PROTOCOL_ERROR for the stream-id. 1256 2.6.10.1. Compression 1258 The Name/Value Header Block is a section of the SYN_STREAM, 1259 SYN_REPLY, and HEADERS frames used to carry header meta-data. This 1260 block is always compressed using zlib compression. Within this 1261 specification, any reference to 'zlib' is referring to the ZLIB 1262 Compressed Data Format Specification Version 3.3 as part of RFC1950. 1263 [RFC1950] 1265 For each HEADERS compression instance, the initial state is 1266 initialized using the following dictionary [UDELCOMPRESSION]: 1268 1270 const unsigned char SPDY_dictionary_txt[] = { 1271 0x00, 0x00, 0x00, 0x07, 0x6f, 0x70, 0x74, 0x69, \\ - - - - o p t i 1272 0x6f, 0x6e, 0x73, 0x00, 0x00, 0x00, 0x04, 0x68, \\ o n s - - - - h 1273 0x65, 0x61, 0x64, 0x00, 0x00, 0x00, 0x04, 0x70, \\ e a d - - - - p 1274 0x6f, 0x73, 0x74, 0x00, 0x00, 0x00, 0x03, 0x70, \\ o s t - - - - p 1275 0x75, 0x74, 0x00, 0x00, 0x00, 0x06, 0x64, 0x65, \\ u t - - - - d e 1276 0x6c, 0x65, 0x74, 0x65, 0x00, 0x00, 0x00, 0x05, \\ l e t e - - - - 1277 0x74, 0x72, 0x61, 0x63, 0x65, 0x00, 0x00, 0x00, \\ t r a c e - - - 1278 0x06, 0x61, 0x63, 0x63, 0x65, 0x70, 0x74, 0x00, \\ - a c c e p t - 1279 0x00, 0x00, 0x0e, 0x61, 0x63, 0x63, 0x65, 0x70, \\ - - - a c c e p 1280 0x74, 0x2d, 0x63, 0x68, 0x61, 0x72, 0x73, 0x65, \\ t - c h a r s e 1281 0x74, 0x00, 0x00, 0x00, 0x0f, 0x61, 0x63, 0x63, \\ t - - - - a c c 1282 0x65, 0x70, 0x74, 0x2d, 0x65, 0x6e, 0x63, 0x6f, \\ e p t - e n c o 1283 0x64, 0x69, 0x6e, 0x67, 0x00, 0x00, 0x00, 0x0f, \\ d i n g - - - - 1284 0x61, 0x63, 0x63, 0x65, 0x70, 0x74, 0x2d, 0x6c, \\ a c c e p t - l 1285 0x61, 0x6e, 0x67, 0x75, 0x61, 0x67, 0x65, 0x00, \\ a n g u a g e - 1286 0x00, 0x00, 0x0d, 0x61, 0x63, 0x63, 0x65, 0x70, \\ - - - a c c e p 1287 0x74, 0x2d, 0x72, 0x61, 0x6e, 0x67, 0x65, 0x73, \\ t - r a n g e s 1288 0x00, 0x00, 0x00, 0x03, 0x61, 0x67, 0x65, 0x00, \\ - - - - a g e - 1289 0x00, 0x00, 0x05, 0x61, 0x6c, 0x6c, 0x6f, 0x77, \\ - - - a l l o w 1290 0x00, 0x00, 0x00, 0x0d, 0x61, 0x75, 0x74, 0x68, \\ - - - - a u t h 1291 0x6f, 0x72, 0x69, 0x7a, 0x61, 0x74, 0x69, 0x6f, \\ o r i z a t i o 1292 0x6e, 0x00, 0x00, 0x00, 0x0d, 0x63, 0x61, 0x63, \\ n - - - - c a c 1293 0x68, 0x65, 0x2d, 0x63, 0x6f, 0x6e, 0x74, 0x72, \\ h e - c o n t r 1294 0x6f, 0x6c, 0x00, 0x00, 0x00, 0x0a, 0x63, 0x6f, \\ o l - - - - c o 1295 0x6e, 0x6e, 0x65, 0x63, 0x74, 0x69, 0x6f, 0x6e, \\ n n e c t i o n 1296 0x00, 0x00, 0x00, 0x0c, 0x63, 0x6f, 0x6e, 0x74, \\ - - - - c o n t 1297 0x65, 0x6e, 0x74, 0x2d, 0x62, 0x61, 0x73, 0x65, \\ e n t - b a s e 1298 0x00, 0x00, 0x00, 0x10, 0x63, 0x6f, 0x6e, 0x74, \\ - - - - c o n t 1299 0x65, 0x6e, 0x74, 0x2d, 0x65, 0x6e, 0x63, 0x6f, \\ e n t - e n c o 1300 0x64, 0x69, 0x6e, 0x67, 0x00, 0x00, 0x00, 0x10, \\ d i n g - - - - 1301 0x63, 0x6f, 0x6e, 0x74, 0x65, 0x6e, 0x74, 0x2d, \\ c o n t e n t - 1302 0x6c, 0x61, 0x6e, 0x67, 0x75, 0x61, 0x67, 0x65, \\ l a n g u a g e 1303 0x00, 0x00, 0x00, 0x0e, 0x63, 0x6f, 0x6e, 0x74, \\ - - - - c o n t 1304 0x65, 0x6e, 0x74, 0x2d, 0x6c, 0x65, 0x6e, 0x67, \\ e n t - l e n g 1305 0x74, 0x68, 0x00, 0x00, 0x00, 0x10, 0x63, 0x6f, \\ t h - - - - c o 1306 0x6e, 0x74, 0x65, 0x6e, 0x74, 0x2d, 0x6c, 0x6f, \\ n t e n t - l o 1307 0x63, 0x61, 0x74, 0x69, 0x6f, 0x6e, 0x00, 0x00, \\ c a t i o n - - 1308 0x00, 0x0b, 0x63, 0x6f, 0x6e, 0x74, 0x65, 0x6e, \\ - - c o n t e n 1309 0x74, 0x2d, 0x6d, 0x64, 0x35, 0x00, 0x00, 0x00, \\ t - m d 5 - - - 1310 0x0d, 0x63, 0x6f, 0x6e, 0x74, 0x65, 0x6e, 0x74, \\ - c o n t e n t 1311 0x2d, 0x72, 0x61, 0x6e, 0x67, 0x65, 0x00, 0x00, \\ - r a n g e - - 1312 0x00, 0x0c, 0x63, 0x6f, 0x6e, 0x74, 0x65, 0x6e, \\ - - c o n t e n 1313 0x74, 0x2d, 0x74, 0x79, 0x70, 0x65, 0x00, 0x00, \\ t - t y p e - - 1314 0x00, 0x04, 0x64, 0x61, 0x74, 0x65, 0x00, 0x00, \\ - - d a t e - - 1315 0x00, 0x04, 0x65, 0x74, 0x61, 0x67, 0x00, 0x00, \\ - - e t a g - - 1316 0x00, 0x06, 0x65, 0x78, 0x70, 0x65, 0x63, 0x74, \\ - - e x p e c t 1317 0x00, 0x00, 0x00, 0x07, 0x65, 0x78, 0x70, 0x69, \\ - - - - e x p i 1318 0x72, 0x65, 0x73, 0x00, 0x00, 0x00, 0x04, 0x66, \\ r e s - - - - f 1319 0x72, 0x6f, 0x6d, 0x00, 0x00, 0x00, 0x04, 0x68, \\ r o m - - - - h 1320 0x6f, 0x73, 0x74, 0x00, 0x00, 0x00, 0x08, 0x69, \\ o s t - - - - i 1321 0x66, 0x2d, 0x6d, 0x61, 0x74, 0x63, 0x68, 0x00, \\ f - m a t c h - 1322 0x00, 0x00, 0x11, 0x69, 0x66, 0x2d, 0x6d, 0x6f, \\ - - - i f - m o 1323 0x64, 0x69, 0x66, 0x69, 0x65, 0x64, 0x2d, 0x73, \\ d i f i e d - s 1324 0x69, 0x6e, 0x63, 0x65, 0x00, 0x00, 0x00, 0x0d, \\ i n c e - - - - 1325 0x69, 0x66, 0x2d, 0x6e, 0x6f, 0x6e, 0x65, 0x2d, \\ i f - n o n e - 1326 0x6d, 0x61, 0x74, 0x63, 0x68, 0x00, 0x00, 0x00, \\ m a t c h - - - 1327 0x08, 0x69, 0x66, 0x2d, 0x72, 0x61, 0x6e, 0x67, \\ - i f - r a n g 1328 0x65, 0x00, 0x00, 0x00, 0x13, 0x69, 0x66, 0x2d, \\ e - - - - i f - 1329 0x75, 0x6e, 0x6d, 0x6f, 0x64, 0x69, 0x66, 0x69, \\ u n m o d i f i 1330 0x65, 0x64, 0x2d, 0x73, 0x69, 0x6e, 0x63, 0x65, \\ e d - s i n c e 1331 0x00, 0x00, 0x00, 0x0d, 0x6c, 0x61, 0x73, 0x74, \\ - - - - l a s t 1332 0x2d, 0x6d, 0x6f, 0x64, 0x69, 0x66, 0x69, 0x65, \\ - m o d i f i e 1333 0x64, 0x00, 0x00, 0x00, 0x08, 0x6c, 0x6f, 0x63, \\ d - - - - l o c 1334 0x61, 0x74, 0x69, 0x6f, 0x6e, 0x00, 0x00, 0x00, \\ a t i o n - - - 1335 0x0c, 0x6d, 0x61, 0x78, 0x2d, 0x66, 0x6f, 0x72, \\ - m a x - f o r 1336 0x77, 0x61, 0x72, 0x64, 0x73, 0x00, 0x00, 0x00, \\ w a r d s - - - 1337 0x06, 0x70, 0x72, 0x61, 0x67, 0x6d, 0x61, 0x00, \\ - p r a g m a - 1338 0x00, 0x00, 0x12, 0x70, 0x72, 0x6f, 0x78, 0x79, \\ - - - p r o x y 1339 0x2d, 0x61, 0x75, 0x74, 0x68, 0x65, 0x6e, 0x74, \\ - a u t h e n t 1340 0x69, 0x63, 0x61, 0x74, 0x65, 0x00, 0x00, 0x00, \\ i c a t e - - - 1341 0x13, 0x70, 0x72, 0x6f, 0x78, 0x79, 0x2d, 0x61, \\ - p r o x y - a 1342 0x75, 0x74, 0x68, 0x6f, 0x72, 0x69, 0x7a, 0x61, \\ u t h o r i z a 1343 0x74, 0x69, 0x6f, 0x6e, 0x00, 0x00, 0x00, 0x05, \\ t i o n - - - - 1344 0x72, 0x61, 0x6e, 0x67, 0x65, 0x00, 0x00, 0x00, \\ r a n g e - - - 1345 0x07, 0x72, 0x65, 0x66, 0x65, 0x72, 0x65, 0x72, \\ - r e f e r e r 1346 0x00, 0x00, 0x00, 0x0b, 0x72, 0x65, 0x74, 0x72, \\ - - - - r e t r 1347 0x79, 0x2d, 0x61, 0x66, 0x74, 0x65, 0x72, 0x00, \\ y - a f t e r - 1348 0x00, 0x00, 0x06, 0x73, 0x65, 0x72, 0x76, 0x65, \\ - - - s e r v e 1349 0x72, 0x00, 0x00, 0x00, 0x02, 0x74, 0x65, 0x00, \\ r - - - - t e - 1350 0x00, 0x00, 0x07, 0x74, 0x72, 0x61, 0x69, 0x6c, \\ - - - t r a i l 1351 0x65, 0x72, 0x00, 0x00, 0x00, 0x11, 0x74, 0x72, \\ e r - - - - t r 1352 0x61, 0x6e, 0x73, 0x66, 0x65, 0x72, 0x2d, 0x65, \\ a n s f e r - e 1353 0x6e, 0x63, 0x6f, 0x64, 0x69, 0x6e, 0x67, 0x00, \\ n c o d i n g - 1354 0x00, 0x00, 0x07, 0x75, 0x70, 0x67, 0x72, 0x61, \\ - - - u p g r a 1355 0x64, 0x65, 0x00, 0x00, 0x00, 0x0a, 0x75, 0x73, \\ d e - - - - u s 1356 0x65, 0x72, 0x2d, 0x61, 0x67, 0x65, 0x6e, 0x74, \\ e r - a g e n t 1357 0x00, 0x00, 0x00, 0x04, 0x76, 0x61, 0x72, 0x79, \\ - - - - v a r y 1358 0x00, 0x00, 0x00, 0x03, 0x76, 0x69, 0x61, 0x00, \\ - - - - v i a - 1359 0x00, 0x00, 0x07, 0x77, 0x61, 0x72, 0x6e, 0x69, \\ - - - w a r n i 1360 0x6e, 0x67, 0x00, 0x00, 0x00, 0x10, 0x77, 0x77, \\ n g - - - - w w 1361 0x77, 0x2d, 0x61, 0x75, 0x74, 0x68, 0x65, 0x6e, \\ w - a u t h e n 1362 0x74, 0x69, 0x63, 0x61, 0x74, 0x65, 0x00, 0x00, \\ t i c a t e - - 1363 0x00, 0x06, 0x6d, 0x65, 0x74, 0x68, 0x6f, 0x64, \\ - - m e t h o d 1364 0x00, 0x00, 0x00, 0x03, 0x67, 0x65, 0x74, 0x00, \\ - - - - g e t - 1365 0x00, 0x00, 0x06, 0x73, 0x74, 0x61, 0x74, 0x75, \\ - - - s t a t u 1366 0x73, 0x00, 0x00, 0x00, 0x06, 0x32, 0x30, 0x30, \\ s - - - - 2 0 0 1367 0x20, 0x4f, 0x4b, 0x00, 0x00, 0x00, 0x07, 0x76, \\ - O K - - - - v 1368 0x65, 0x72, 0x73, 0x69, 0x6f, 0x6e, 0x00, 0x00, \\ e r s i o n - - 1369 0x00, 0x08, 0x48, 0x54, 0x54, 0x50, 0x2f, 0x31, \\ - - H T T P - 1 1370 0x2e, 0x31, 0x00, 0x00, 0x00, 0x03, 0x75, 0x72, \\ - 1 - - - - u r 1371 0x6c, 0x00, 0x00, 0x00, 0x06, 0x70, 0x75, 0x62, \\ l - - - - p u b 1372 0x6c, 0x69, 0x63, 0x00, 0x00, 0x00, 0x0a, 0x73, \\ l i c - - - - s 1373 0x65, 0x74, 0x2d, 0x63, 0x6f, 0x6f, 0x6b, 0x69, \\ e t - c o o k i 1374 0x65, 0x00, 0x00, 0x00, 0x0a, 0x6b, 0x65, 0x65, \\ e - - - - k e e 1375 0x70, 0x2d, 0x61, 0x6c, 0x69, 0x76, 0x65, 0x00, \\ p - a l i v e - 1376 0x00, 0x00, 0x06, 0x6f, 0x72, 0x69, 0x67, 0x69, \\ - - - o r i g i 1377 0x6e, 0x31, 0x30, 0x30, 0x31, 0x30, 0x31, 0x32, \\ n 1 0 0 1 0 1 2 1378 0x30, 0x31, 0x32, 0x30, 0x32, 0x32, 0x30, 0x35, \\ 0 1 2 0 2 2 0 5 1379 0x32, 0x30, 0x36, 0x33, 0x30, 0x30, 0x33, 0x30, \\ 2 0 6 3 0 0 3 0 1380 0x32, 0x33, 0x30, 0x33, 0x33, 0x30, 0x34, 0x33, \\ 2 3 0 3 3 0 4 3 1381 0x30, 0x35, 0x33, 0x30, 0x36, 0x33, 0x30, 0x37, \\ 0 5 3 0 6 3 0 7 1382 0x34, 0x30, 0x32, 0x34, 0x30, 0x35, 0x34, 0x30, \\ 4 0 2 4 0 5 4 0 1383 0x36, 0x34, 0x30, 0x37, 0x34, 0x30, 0x38, 0x34, \\ 6 4 0 7 4 0 8 4 1384 0x30, 0x39, 0x34, 0x31, 0x30, 0x34, 0x31, 0x31, \\ 0 9 4 1 0 4 1 1 1385 0x34, 0x31, 0x32, 0x34, 0x31, 0x33, 0x34, 0x31, \\ 4 1 2 4 1 3 4 1 1386 0x34, 0x34, 0x31, 0x35, 0x34, 0x31, 0x36, 0x34, \\ 4 4 1 5 4 1 6 4 1387 0x31, 0x37, 0x35, 0x30, 0x32, 0x35, 0x30, 0x34, \\ 1 7 5 0 2 5 0 4 1388 0x35, 0x30, 0x35, 0x32, 0x30, 0x33, 0x20, 0x4e, \\ 5 0 5 2 0 3 - N 1389 0x6f, 0x6e, 0x2d, 0x41, 0x75, 0x74, 0x68, 0x6f, \\ o n - A u t h o 1390 0x72, 0x69, 0x74, 0x61, 0x74, 0x69, 0x76, 0x65, \\ r i t a t i v e 1391 0x20, 0x49, 0x6e, 0x66, 0x6f, 0x72, 0x6d, 0x61, \\ - I n f o r m a 1392 0x74, 0x69, 0x6f, 0x6e, 0x32, 0x30, 0x34, 0x20, \\ t i o n 2 0 4 - 1393 0x4e, 0x6f, 0x20, 0x43, 0x6f, 0x6e, 0x74, 0x65, \\ N o - C o n t e 1394 0x6e, 0x74, 0x33, 0x30, 0x31, 0x20, 0x4d, 0x6f, \\ n t 3 0 1 - M o 1395 0x76, 0x65, 0x64, 0x20, 0x50, 0x65, 0x72, 0x6d, \\ v e d - P e r m 1396 0x61, 0x6e, 0x65, 0x6e, 0x74, 0x6c, 0x79, 0x34, \\ a n e n t l y 4 1397 0x30, 0x30, 0x20, 0x42, 0x61, 0x64, 0x20, 0x52, \\ 0 0 - B a d - R 1398 0x65, 0x71, 0x75, 0x65, 0x73, 0x74, 0x34, 0x30, \\ e q u e s t 4 0 1399 0x31, 0x20, 0x55, 0x6e, 0x61, 0x75, 0x74, 0x68, \\ 1 - U n a u t h 1400 0x6f, 0x72, 0x69, 0x7a, 0x65, 0x64, 0x34, 0x30, \\ o r i z e d 4 0 1401 0x33, 0x20, 0x46, 0x6f, 0x72, 0x62, 0x69, 0x64, \\ 3 - F o r b i d 1402 0x64, 0x65, 0x6e, 0x34, 0x30, 0x34, 0x20, 0x4e, \\ d e n 4 0 4 - N 1403 0x6f, 0x74, 0x20, 0x46, 0x6f, 0x75, 0x6e, 0x64, \\ o t - F o u n d 1404 0x35, 0x30, 0x30, 0x20, 0x49, 0x6e, 0x74, 0x65, \\ 5 0 0 - I n t e 1405 0x72, 0x6e, 0x61, 0x6c, 0x20, 0x53, 0x65, 0x72, \\ r n a l - S e r 1406 0x76, 0x65, 0x72, 0x20, 0x45, 0x72, 0x72, 0x6f, \\ v e r - E r r o 1407 0x72, 0x35, 0x30, 0x31, 0x20, 0x4e, 0x6f, 0x74, \\ r 5 0 1 - N o t 1408 0x20, 0x49, 0x6d, 0x70, 0x6c, 0x65, 0x6d, 0x65, \\ - I m p l e m e 1409 0x6e, 0x74, 0x65, 0x64, 0x35, 0x30, 0x33, 0x20, \\ n t e d 5 0 3 - 1410 0x53, 0x65, 0x72, 0x76, 0x69, 0x63, 0x65, 0x20, \\ S e r v i c e - 1411 0x55, 0x6e, 0x61, 0x76, 0x61, 0x69, 0x6c, 0x61, \\ U n a v a i l a 1412 0x62, 0x6c, 0x65, 0x4a, 0x61, 0x6e, 0x20, 0x46, \\ b l e J a n - F 1413 0x65, 0x62, 0x20, 0x4d, 0x61, 0x72, 0x20, 0x41, \\ e b - M a r - A 1414 0x70, 0x72, 0x20, 0x4d, 0x61, 0x79, 0x20, 0x4a, \\ p r - M a y - J 1415 0x75, 0x6e, 0x20, 0x4a, 0x75, 0x6c, 0x20, 0x41, \\ u n - J u l - A 1416 0x75, 0x67, 0x20, 0x53, 0x65, 0x70, 0x74, 0x20, \\ u g - S e p t - 1417 0x4f, 0x63, 0x74, 0x20, 0x4e, 0x6f, 0x76, 0x20, \\ O c t - N o v - 1418 0x44, 0x65, 0x63, 0x20, 0x30, 0x30, 0x3a, 0x30, \\ D e c - 0 0 - 0 1419 0x30, 0x3a, 0x30, 0x30, 0x20, 0x4d, 0x6f, 0x6e, \\ 0 - 0 0 - M o n 1420 0x2c, 0x20, 0x54, 0x75, 0x65, 0x2c, 0x20, 0x57, \\ - - T u e - - W 1421 0x65, 0x64, 0x2c, 0x20, 0x54, 0x68, 0x75, 0x2c, \\ e d - - T h u - 1422 0x20, 0x46, 0x72, 0x69, 0x2c, 0x20, 0x53, 0x61, \\ - F r i - - S a 1423 0x74, 0x2c, 0x20, 0x53, 0x75, 0x6e, 0x2c, 0x20, \\ t - - S u n - - 1424 0x47, 0x4d, 0x54, 0x63, 0x68, 0x75, 0x6e, 0x6b, \\ G M T c h u n k 1425 0x65, 0x64, 0x2c, 0x74, 0x65, 0x78, 0x74, 0x2f, \\ e d - t e x t - 1426 0x68, 0x74, 0x6d, 0x6c, 0x2c, 0x69, 0x6d, 0x61, \\ h t m l - i m a 1427 0x67, 0x65, 0x2f, 0x70, 0x6e, 0x67, 0x2c, 0x69, \\ g e - p n g - i 1428 0x6d, 0x61, 0x67, 0x65, 0x2f, 0x6a, 0x70, 0x67, \\ m a g e - j p g 1429 0x2c, 0x69, 0x6d, 0x61, 0x67, 0x65, 0x2f, 0x67, \\ - i m a g e - g 1430 0x69, 0x66, 0x2c, 0x61, 0x70, 0x70, 0x6c, 0x69, \\ i f - a p p l i 1431 0x63, 0x61, 0x74, 0x69, 0x6f, 0x6e, 0x2f, 0x78, \\ c a t i o n - x 1432 0x6d, 0x6c, 0x2c, 0x61, 0x70, 0x70, 0x6c, 0x69, \\ m l - a p p l i 1433 0x63, 0x61, 0x74, 0x69, 0x6f, 0x6e, 0x2f, 0x78, \\ c a t i o n - x 1434 0x68, 0x74, 0x6d, 0x6c, 0x2b, 0x78, 0x6d, 0x6c, \\ h t m l - x m l 1435 0x2c, 0x74, 0x65, 0x78, 0x74, 0x2f, 0x70, 0x6c, \\ - t e x t - p l 1436 0x61, 0x69, 0x6e, 0x2c, 0x74, 0x65, 0x78, 0x74, \\ a i n - t e x t 1437 0x2f, 0x6a, 0x61, 0x76, 0x61, 0x73, 0x63, 0x72, \\ - j a v a s c r 1438 0x69, 0x70, 0x74, 0x2c, 0x70, 0x75, 0x62, 0x6c, \\ i p t - p u b l 1439 0x69, 0x63, 0x70, 0x72, 0x69, 0x76, 0x61, 0x74, \\ i c p r i v a t 1440 0x65, 0x6d, 0x61, 0x78, 0x2d, 0x61, 0x67, 0x65, \\ e m a x - a g e 1441 0x3d, 0x67, 0x7a, 0x69, 0x70, 0x2c, 0x64, 0x65, \\ - g z i p - d e 1442 0x66, 0x6c, 0x61, 0x74, 0x65, 0x2c, 0x73, 0x64, \\ f l a t e - s d 1443 0x63, 0x68, 0x63, 0x68, 0x61, 0x72, 0x73, 0x65, \\ c h c h a r s e 1444 0x74, 0x3d, 0x75, 0x74, 0x66, 0x2d, 0x38, 0x63, \\ t - u t f - 8 c 1445 0x68, 0x61, 0x72, 0x73, 0x65, 0x74, 0x3d, 0x69, \\ h a r s e t - i 1446 0x73, 0x6f, 0x2d, 0x38, 0x38, 0x35, 0x39, 0x2d, \\ s o - 8 8 5 9 - 1447 0x31, 0x2c, 0x75, 0x74, 0x66, 0x2d, 0x2c, 0x2a, \\ 1 - u t f - - - 1448 0x2c, 0x65, 0x6e, 0x71, 0x3d, 0x30, 0x2e \\ - e n q - 0 - 1449 }; 1451 1453 The entire contents of the name/value header block is compressed 1454 using zlib. There is a single zlib stream for all name value pairs 1455 in one direction on a connection. SPDY uses a SYNC_FLUSH between 1456 each compressed frame. 1458 Implementation notes: the compression engine can be tuned to favor 1459 speed or size. Optimizing for size increases memory use and CPU 1460 consumption. Because header blocks are generally small, implementors 1461 may want to reduce the window-size of the compression engine from the 1462 default 15bits (a 32KB window) to more like 11bits (a 2KB window). 1463 The exact setting is chosen by the compressor, the decompressor will 1464 work with any setting. 1466 3. HTTP Layering over SPDY 1468 SPDY is intended to be as compatible as possible with current web- 1469 based applications. This means that, from the perspective of the 1470 server business logic or application API, the features of HTTP are 1471 unchanged. To achieve this, all of the application request and 1472 response header semantics are preserved, although the syntax of 1473 conveying those semantics has changed. Thus, the rules from the 1474 HTTP/1.1 specification in RFC2616 [RFC2616] apply with the changes in 1475 the sections below. 1477 3.1. Connection Management 1479 Clients SHOULD NOT open more than one SPDY session to a given origin 1480 [RFC6454] concurrently. 1482 Note that it is possible for one SPDY session to be finishing (e.g. a 1483 GOAWAY message has been sent, but not all streams have finished), 1484 while another SPDY session is starting. 1486 3.1.1. Use of GOAWAY 1488 SPDY provides a GOAWAY message which can be used when closing a 1489 connection from either the client or server. Without a server GOAWAY 1490 message, HTTP has a race condition where the client sends a request 1491 (a new SYN_STREAM) just as the server is closing the connection, and 1492 the client cannot know if the server received the stream or not. By 1493 using the last-stream-id in the GOAWAY, servers can indicate to the 1494 client if a request was processed or not. 1496 Note that some servers will choose to send the GOAWAY and immediately 1497 terminate the connection without waiting for active streams to 1498 finish. The client will be able to determine this because SPDY 1499 streams are determinstically closed. This abrupt termination will 1500 force the client to heuristically decide whether to retry the pending 1501 requests. Clients always need to be capable of dealing with this 1502 case because they must deal with accidental connection termination 1503 cases, which are the same as the server never having sent a GOAWAY. 1505 More sophisticated servers will use GOAWAY to implement a graceful 1506 teardown. They will send the GOAWAY and provide some time for the 1507 active streams to finish before terminating the connection. 1509 If a SPDY client closes the connection, it should also send a GOAWAY 1510 message. This allows the server to know if any server-push streams 1511 were received by the client. 1513 If the endpoint closing the connection has not received any 1514 SYN_STREAMs from the remote, the GOAWAY will contain a last-stream-id 1515 of 0. 1517 3.2. HTTP Request/Response 1519 3.2.1. Request 1521 The client initiates a request by sending a SYN_STREAM frame. For 1522 requests which do not contain a body, the SYN_STREAM frame MUST set 1523 the FLAG_FIN, indicating that the client intends to send no further 1524 data on this stream. For requests which do contain a body, the 1525 SYN_STREAM will not contain the FLAG_FIN, and the body will follow 1526 the SYN_STREAM in a series of DATA frames. The last DATA frame will 1527 set the FLAG_FIN to indicate the end of the body. 1529 The SYN_STREAM Name/Value section will contain all of the HTTP 1530 headers which are associated with an HTTP request. The header block 1531 in SPDY is mostly unchanged from today's HTTP header block, with the 1532 following differences: 1534 The first line of the request is unfolded into name/value pairs 1535 like other HTTP headers and MUST be present: 1537 ":method" - the HTTP method for this request (e.g. "GET", 1538 "POST", "HEAD", etc) 1540 ":path" - the url-path for this url with "/" prefixed. (See 1541 RFC1738 [RFC1738]). For example, for 1542 "http://www.google.com/search?q=dogs" the path would be 1543 "/search?q=dogs". 1545 ":version" - the HTTP version of this request (e.g. 1546 "HTTP/1.1") 1548 In addition, the following two name/value pairs must also be 1549 present in every request: 1551 ":host" - the hostport (See RFC1738 [RFC1738]) portion of the 1552 URL for this request (e.g. "www.google.com:1234"). This header 1553 is the same as the HTTP 'Host' header. 1555 ":scheme" - the scheme portion of the URL for this request 1556 (e.g. "https")) 1558 Header names are all lowercase. 1560 The Connection, Host, Keep-Alive, Proxy-Connection, and Transfer- 1561 Encoding headers are not valid and MUST not be sent. 1563 User-agents MUST support gzip compression. Regardless of the 1564 Accept-Encoding sent by the user-agent, the server may always send 1565 content encoded with gzip or deflate encoding. 1567 If a server receives a request where the sum of the data frame 1568 payload lengths does not equal the size of the Content-Length 1569 header, the server MUST return a 400 (Bad Request) error. 1571 POST-specific changes: 1573 Although POSTs are inherently chunked, POST requests SHOULD 1574 also be accompanied by a Content-Length header. There are two 1575 reasons for this: First, it assists with upload progress meters 1576 for an improved user experience. But second, we know from 1577 early versions of SPDY that failure to send a content length 1578 header is incompatible with many existing HTTP server 1579 implementations. Existing user-agents do not omit the Content- 1580 Length header, and server implementations have come to depend 1581 upon this. 1583 The user-agent is free to prioritize requests as it sees fit. If the 1584 user-agent cannot make progress without receiving a resource, it 1585 should attempt to raise the priority of that resource. Resources 1586 such as images, SHOULD generally use the lowest priority. 1588 If a client sends a SYN_STREAM without all of the method, host, path, 1589 scheme, and version headers, the server MUST reply with a HTTP 400 1590 Bad Request reply. 1592 3.2.2. Response 1594 The server responds to a client request with a SYN_REPLY frame. 1595 Symmetric to the client's upload stream, server will send data after 1596 the SYN_REPLY frame via a series of DATA frames, and the last data 1597 frame will contain the FLAG_FIN to indicate successful end-of-stream. 1598 If a response (like a 202 or 204 response) contains no body, the 1599 SYN_REPLY frame may contain the FLAG_FIN flag to indicate no further 1600 data will be sent on the stream. 1602 The response status line is unfolded into name/value pairs like 1603 other HTTP headers and must be present: 1605 ":status" - The HTTP response status code (e.g. "200" or "200 1606 OK") 1608 ":version" - The HTTP response version (e.g. "HTTP/1.1") 1610 All header names must be lowercase. 1612 The Connection, Keep-Alive, Proxy-Connection, and Transfer- 1613 Encoding headers are not valid and MUST not be sent. 1615 Responses MAY be accompanied by a Content-Length header for 1616 advisory purposes. (e.g. for UI progress meters) 1618 If a client receives a response where the sum of the data frame 1619 payload lengths does not equal the size of the Content-Length 1620 header, the client MUST ignore the content length header. 1622 If a client receives a SYN_REPLY without a status or without a 1623 version header, the client must reply with a RST_STREAM frame 1624 indicating a PROTOCOL ERROR. 1626 3.2.3. Authentication 1628 When a client sends a request to an origin server that requires 1629 authentication, the server can reply with a "401 Unauthorized" 1630 response, and include a WWW-Authenticate challenge header that 1631 defines the authentication scheme to be used. The client then 1632 retries the request with an Authorization header appropriate to the 1633 specified authentication scheme. 1635 There are four options for proxy authentication, Basic, Digest, NTLM 1636 and Negotiate (SPNEGO). The first two options were defined in 1637 RFC2617 [RFC2617], and are stateless. The second two options were 1638 developed by Microsoft and specified in RFC4559 [RFC4559], and are 1639 stateful; otherwise known as multi-round authentication, or 1640 connection authentication. 1642 3.2.3.1. Stateless Authentication 1644 Stateless Authentication over SPDY is identical to how it is 1645 performed over HTTP. If multiple SPDY streams are concurrently sent 1646 to a single server, each will authenticate independently, similar to 1647 how two HTTP connections would independently authenticate to a proxy 1648 server. 1650 3.2.3.2. Stateful Authentication 1652 Unfortunately, the stateful authentication mechanisms were 1653 implemented and defined in a such a way that directly violates 1654 RFC2617 - they do not include a "realm" as part of the request. This 1655 is problematic in SPDY because it makes it impossible for a client to 1656 disambiguate two concurrent server authentication challenges. 1658 To deal with this case, SPDY servers using Stateful Authentication 1659 MUST implement one of two changes: 1661 Servers can add a "realm=" header so that the two 1662 authentication requests can be disambiguated and run concurrently. 1663 Unfortunately, given how these mechanisms work, this is probably 1664 not practical. 1666 Upon sending the first stateful challenge response, the server 1667 MUST buffer and defer all further frames which are not part of 1668 completing the challenge until the challenge has completed. 1669 Completing the authentication challenge may take multiple round 1670 trips. Once the client receives a "401 Authenticate" response for 1671 a stateful authentication type, it MUST stop sending new requests 1672 to the server until the authentication has completed by receiving 1673 a non-401 response on at least one stream. 1675 3.3. Server Push Transactions 1677 SPDY enables a server to send multiple replies to a client for a 1678 single request. The rationale for this feature is that sometimes a 1679 server knows that it will need to send multiple resources in response 1680 to a single request. Without server push features, the client must 1681 first download the primary resource, then discover the secondary 1682 resource(s), and request them. Pushing of resources avoids the 1683 round-trip delay, but also creates a potential race where a server 1684 can be pushing content which a user-agent is in the process of 1685 requesting. The following mechanics attempt to prevent the race 1686 condition while enabling the performance benefit. 1688 Browsers receiving a pushed response MUST validate that the server is 1689 authorized to push the URL using the browser same-origin [RFC6454] 1690 policy. For example, a SPDY connection to www.foo.com is generally 1691 not permitted to push a response for www.evil.com. 1693 If the browser accepts a pushed response (e.g. it does not send a 1694 RST_STREAM), the browser MUST attempt to cache the pushed response in 1695 same way that it would cache any other response. This means 1696 validating the response headers and inserting into the disk cache. 1698 Because pushed responses have no request, they have no request 1699 headers associated with them. At the framing layer, SPDY pushed 1700 streams contain an "associated-stream-id" which indicates the 1701 requested stream for which the pushed stream is related. The pushed 1702 stream inherits all of the headers from the associated-stream-id with 1703 the exception of ":host", ":scheme", and ":path", which are provided 1704 as part of the pushed response stream headers. The browser MUST 1705 store these inherited and implied request headers with the cached 1706 resource. 1708 Implementation note: With server push, it is theoretically possible 1709 for servers to push unreasonable amounts of content or resources to 1710 the user-agent. Browsers MUST implement throttles to protect against 1711 unreasonable push attacks. 1713 3.3.1. Server implementation 1715 When the server intends to push a resource to the user-agent, it 1716 opens a new stream by sending a unidirectional SYN_STREAM. The 1717 SYN_STREAM MUST include an Associated-To-Stream-ID, and MUST set the 1718 FLAG_UNIDIRECTIONAL flag. The SYN_STREAM MUST include headers for 1719 ":scheme", ":host", ":path", which represent the URL for the resource 1720 being pushed. Subsequent headers may follow in HEADERS frames. The 1721 purpose of the association is so that the user-agent can 1722 differentiate which request induced the pushed stream; without it, if 1723 the user-agent had two tabs open to the same page, each pushing 1724 unique content under a fixed URL, the user-agent would not be able to 1725 differentiate the requests. 1727 The Associated-To-Stream-ID must be the ID of an existing, open 1728 stream. The reason for this restriction is to have a clear endpoint 1729 for pushed content. If the user-agent requested a resource on stream 1730 11, the server replies on stream 11. It can push any number of 1731 additional streams to the client before sending a FLAG_FIN on stream 1732 11. However, once the originating stream is closed no further push 1733 streams may be associated with it. The pushed streams do not need to 1734 be closed (FIN set) before the originating stream is closed, they 1735 only need to be created before the originating stream closes. 1737 It is illegal for a server to push a resource with the Associated-To- 1738 Stream-ID of 0. 1740 To minimize race conditions with the client, the SYN_STREAM for the 1741 pushed resources MUST be sent prior to sending any content which 1742 could allow the client to discover the pushed resource and request 1743 it. 1745 The server MUST only push resources which would have been returned 1746 from a GET request. 1748 Note: If the server does not have all of the Name/Value Response 1749 headers available at the time it issues the HEADERS frame for the 1750 pushed resource, it may later use an additional HEADERS frame to 1751 augment the name/value pairs to be associated with the pushed stream. 1752 The subsequent HEADERS frame(s) must not contain a header for 1753 ':host', ':scheme', or ':path' (e.g. the server can't change the 1754 identity of the resource to be pushed). The HEADERS frame must not 1755 contain duplicate headers with a previously sent HEADERS frame. The 1756 server must send a HEADERS frame including the scheme/host/port 1757 headers before sending any data frames on the stream. 1759 3.3.2. Client implementation 1761 When fetching a resource the client has 3 possibilities: 1763 the resource is not being pushed 1765 the resource is being pushed, but the data has not yet arrived 1767 the resource is being pushed, and the data has started to arrive 1769 When a SYN_STREAM and HEADERS frame which contains an Associated-To- 1770 Stream-ID is received, the client must not issue GET requests for the 1771 resource in the pushed stream, and instead wait for the pushed stream 1772 to arrive. 1774 If a client receives a server push stream with stream-id 0, it MUST 1775 issue a session error (Section 2.4.1) with the status code 1776 PROTOCOL_ERROR. 1778 When a client receives a SYN_STREAM from the server without a the 1779 ':host', ':scheme', and ':path' headers in the Name/Value section, it 1780 MUST reply with a RST_STREAM with error code HTTP_PROTOCOL_ERROR. 1782 To cancel individual server push streams, the client can issue a 1783 stream error (Section 2.4.2) with error code CANCEL. Upon receipt, 1784 the server MUST stop sending on this stream immediately (this is an 1785 Abrupt termination). 1787 To cancel all server push streams related to a request, the client 1788 may issue a stream error (Section 2.4.2) with error code CANCEL on 1789 the associated-stream-id. By cancelling that stream, the server MUST 1790 immediately stop sending frames for any streams with 1791 in-association-to for the original stream. 1793 If the server sends a HEADER frame containing duplicate headers with 1794 a previous HEADERS frame for the same stream, the client must issue a 1795 stream error (Section 2.4.2) with error code PROTOCOL ERROR. 1797 If the server sends a HEADERS frame after sending a data frame for 1798 the same stream, the client MAY ignore the HEADERS frame. Ignoring 1799 the HEADERS frame after a data frame prevents handling of HTTP's 1800 trailing headers 1801 (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.40). 1803 4. Design Rationale and Notes 1805 Authors' notes: The notes in this section have no bearing on the SPDY 1806 protocol as specified within this document, and none of these notes 1807 should be considered authoritative about how the protocol works. 1808 However, these notes may prove useful in future debates about how to 1809 resolve protocol ambiguities or how to evolve the protocol going 1810 forward. They may be removed before the final draft. 1812 4.1. Separation of Framing Layer and Application Layer 1814 Readers may note that this specification sometimes blends the framing 1815 layer (Section 2) with requirements of a specific application - HTTP 1816 (Section 3). This is reflected in the request/response nature of the 1817 streams, the definition of the HEADERS and compression contexts which 1818 are very similar to HTTP, and other areas as well. 1820 This blending is intentional - the primary goal of this protocol is 1821 to create a low-latency protocol for use with HTTP. Isolating the 1822 two layers is convenient for description of the protocol and how it 1823 relates to existing HTTP implementations. However, the ability to 1824 reuse the SPDY framing layer is a non goal. 1826 4.2. Error handling - Framing Layer 1828 Error handling at the SPDY layer splits errors into two groups: Those 1829 that affect an individual SPDY stream, and those that do not. 1831 When an error is confined to a single stream, but general framing is 1832 in tact, SPDY attempts to use the RST_STREAM as a mechanism to 1833 invalidate the stream but move forward without aborting the 1834 connection altogether. 1836 For errors occuring outside of a single stream context, SPDY assumes 1837 the entire session is hosed. In this case, the endpoint detecting 1838 the error should initiate a connection close. 1840 4.3. One Connection Per Domain 1842 SPDY attempts to use fewer connections than other protocols have 1843 traditionally used. The rationale for this behavior is because it is 1844 very difficult to provide a consistent level of service (e.g. TCP 1845 slow-start), prioritization, or optimal compression when the client 1846 is connecting to the server through multiple channels. 1848 Through lab measurements, we have seen consistent latency benefits by 1849 using fewer connections from the client. The overall number of 1850 packets sent by SPDY can be as much as 40% less than HTTP. Handling 1851 large numbers of concurrent connections on the server also does 1852 become a scalability problem, and SPDY reduces this load. 1854 The use of multiple connections is not without benefit, however. 1855 Because SPDY multiplexes multiple, independent streams onto a single 1856 stream, it creates a potential for head-of-line blocking problems at 1857 the transport level. In tests so far, the negative effects of head- 1858 of-line blocking (especially in the presence of packet loss) is 1859 outweighed by the benefits of compression and prioritization. 1861 4.4. Fixed vs Variable Length Fields 1863 SPDY favors use of fixed length 32bit fields in cases where smaller, 1864 variable length encodings could have been used. To some, this seems 1865 like a tragic waste of bandwidth. SPDY choses the simple encoding 1866 for speed and simplicity. 1868 The goal of SPDY is to reduce latency on the network. The overhead 1869 of SPDY frames is generally quite low. Each data frame is only an 8 1870 byte overhead for a 1452 byte payload (~0.6%). At the time of this 1871 writing, bandwidth is already plentiful, and there is a strong trend 1872 indicating that bandwidth will continue to increase. With an average 1873 worldwide bandwidth of 1Mbps, and assuming that a variable length 1874 encoding could reduce the overhead by 50%, the latency saved by using 1875 a variable length encoding would be less than 100 nanoseconds. More 1876 interesting are the effects when the larger encodings force a packet 1877 boundary, in which case a round-trip could be induced. However, by 1878 addressing other aspects of SPDY and TCP interactions, we believe 1879 this is completely mitigated. 1881 4.5. Compression Context(s) 1883 When isolating the compression contexts used for communicating with 1884 multiple origins, we had a few choices to make. We could have 1885 maintained a map (or list) of compression contexts usable for each 1886 origin. The basic case is easy - each HEADERS frame would need to 1887 identify the context to use for that frame. However, compression 1888 contexts are not cheap, so the lifecycle of each context would need 1889 to be bounded. For proxy servers, where we could churn through many 1890 contexts, this would be a concern. We considered using a static set 1891 of contexts, say 16 of them, which would bound the memory use. We 1892 also considered dynamic contexts, which could be created on the fly, 1893 and would need to be subsequently destroyed. All of these are 1894 complicated, and ultimately we decided that such a mechanism creates 1895 too many problems to solve. 1897 Alternatively, we've chosen the simple approach, which is to simply 1898 provide a flag for resetting the compression context. For the common 1899 case (no proxy), this fine because most requests are to the same 1900 origin and we never need to reset the context. For cases where we 1901 are using two different origins over a single SPDY session, we simply 1902 reset the compression state between each transition. 1904 4.6. Unidirectional streams 1906 Many readers notice that unidirectional streams are both a bit 1907 confusing in concept and also somewhat redundant. If the recipient 1908 of a stream doesn't wish to send data on a stream, it could simply 1909 send a SYN_REPLY with the FLAG_FIN bit set. The FLAG_UNIDIRECTIONAL 1910 is, therefore, not necessary. 1912 It is true that we don't need the UNIDIRECTIONAL markings. It is 1913 added because it avoids the recipient of pushed streams from needing 1914 to send a set of empty frames (e.g. the SYN_STREAM w/ FLAG_FIN) which 1915 otherwise serve no purpose. 1917 4.7. Data Compression 1919 Generic compression of data portion of the streams (as opposed to 1920 compression of the headers) without knowing the content of the stream 1921 is redundant. There is no value in compressing a stream which is 1922 already compressed. Because of this, SPDY does allow data 1923 compression to be optional. We included it because study of existing 1924 websites shows that many sites are not using compression as they 1925 should, and users suffer because of it. We wanted a mechanism where, 1926 at the SPDY layer, site administrators could simply force compression 1927 - it is better to compress twice than to not compress. 1929 Overall, however, with this feature being optional and sometimes 1930 redundant, it is unclear if it is useful at all. We will likely 1931 remove it from the specification. 1933 4.8. Server Push 1935 A subtle but important point is that server push streams must be 1936 declared before the associated stream is closed. The reason for this 1937 is so that proxies have a lifetime for which they can discard 1938 information about previous streams. If a pushed stream could 1939 associate itself with an already-closed stream, then endpoints would 1940 not have a specific lifecycle for when they could disavow knowledge 1941 of the streams which went before. 1943 5. Security Considerations 1945 5.1. Use of Same-origin constraints 1947 This specification uses the same-origin policy [RFC6454] in all cases 1948 where verification of content is required. 1950 5.2. HTTP Headers and SPDY Headers 1952 At the application level, HTTP uses name/value pairs in its headers. 1953 Because SPDY merges the existing HTTP headers with SPDY headers, 1954 there is a possibility that some HTTP applications already use a 1955 particular header name. To avoid any conflicts, all headers 1956 introduced for layering HTTP over SPDY are prefixed with ":". ":" is 1957 not a valid sequence in HTTP header naming, preventing any possible 1958 conflict. 1960 5.3. Cross-Protocol Attacks 1962 By utilizing TLS, we believe that SPDY introduces no new cross- 1963 protocol attacks. TLS encrypts the contents of all transmission 1964 (except the handshake itself), making it difficult for attackers to 1965 control the data which could be used in a cross-protocol attack. 1967 5.4. Server Push Implicit Headers 1969 Pushed resources do not have an associated request. In order for 1970 existing HTTP cache control validations (such as the Vary header) to 1971 work, however, all cached resources must have a set of request 1972 headers. For this reason, browsers MUST be careful to inherit 1973 request headers from the associated stream for the push. This 1974 includes the 'Cookie' header. 1976 6. Privacy Considerations 1978 6.1. Long Lived Connections 1980 SPDY aims to keep connections open longer between clients and servers 1981 in order to reduce the latency when a user makes a request. The 1982 maintenance of these connections over time could be used to expose 1983 private information. For example, a user using a browser hours after 1984 the previous user stopped using that browser may be able to learn 1985 about what the previous user was doing. This is a problem with HTTP 1986 in its current form as well, however the short lived connections make 1987 it less of a risk. 1989 6.2. SETTINGS frame 1991 The SPDY SETTINGS frame allows servers to store out-of-band 1992 transmitted information about the communication between client and 1993 server on the client. Although this is intended only to be used to 1994 reduce latency, renegade servers could use it as a mechanism to store 1995 identifying information about the client in future requests. 1997 Clients implementing privacy modes, such as Google Chrome's 1998 "incognito mode", may wish to disable client-persisted SETTINGS 1999 storage. 2001 Clients MUST clear persisted SETTINGS information when clearing the 2002 cookies. 2004 TODO: Put range maximums on each type of setting to limit 2005 inappropriate uses. 2007 7. Incompatibilities with SPDY draft #2 2009 Here is a list of the major changes between this draft and draft #2. 2011 Addition of flow control 2013 Increased 16 bit length fields in SYN_STREAM and SYN_REPLY to 32 2014 bits. 2016 Changed definition of compression for DATA frames 2018 Updated compression dictionary 2020 Fixed off-by-one on the compression dictionary for headers 2022 Increased priority field from 2bits to 3bits. 2024 Removed NOOP frame 2026 Split the request "url" into "scheme", "host", and "path" 2028 Added the requirement that POSTs contain content-length. 2030 Removed wasted 16bits of unused space from the end of the 2031 SYN_REPLY and HEADERS frames. 2033 Fixed bug: Priorities were described backward (0 was lowest 2034 instead of highest). 2036 Fixed bug: Name/Value header counts were duplicated in both the 2037 Name Value header block and also the containing frame. 2039 8. Requirements Notation 2041 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 2042 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 2043 document are to be interpreted as described in RFC 2119 [RFC2119]. 2045 9. Acknowledgements 2047 Many individuals have contributed to the design and evolution of 2048 SPDY: Adam Langley, Wan-Teh Chang, Jim Morrison, Mark Nottingham, 2049 Alyssa Wilk, Costin Manolache, William Chan, Vitaliy Lvin, Joe Chan, 2050 Adam Barth, Ryan Hamilton, Gavin Peters, Kent Alstad, Kevin Lindsay, 2051 Paul Amer, Fan Yang, Jonathan Leighton. 2053 10. Normative References 2055 [ASCII] "US-ASCII. Coded Character Set - 7-Bit American 2056 Standard Code for Information Interchange. 2057 Standard ANSI X3.4-1986, ANSI, 1986.". 2059 [RFC0793] Postel, J., "Transmission Control Protocol", 2060 STD 7, RFC 793, September 1981. 2062 [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, 2063 "Uniform Resource Locators (URL)", RFC 1738, 2064 December 1994. 2066 [RFC1950] Deutsch, L. and J. Gailly, "ZLIB Compressed Data 2067 Format Specification version 3.3", RFC 1950, 2068 May 1996. 2070 [RFC2119] Bradner, S., "Key words for use in RFCs to 2071 Indicate Requirement Levels", BCP 14, RFC 2119, 2072 March 1997. 2074 [RFC2285] Mandeville, R., "Benchmarking Terminology for LAN 2075 Switching Devices", RFC 2285, February 1998. 2077 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 2078 Masinter, L., Leach, P., and T. Berners-Lee, 2079 "Hypertext Transfer Protocol -- HTTP/1.1", 2080 RFC 2616, June 1999. 2082 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., 2083 Lawrence, S., Leach, P., Luotonen, A., and L. 2084 Stewart, "HTTP Authentication: Basic and Digest 2085 Access Authentication", RFC 2617, June 1999. 2087 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., 2088 Mikkelsen, J., and T. Wright, "Transport Layer 2089 Security (TLS) Extensions", RFC 4366, April 2006. 2091 [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO- 2092 based Kerberos and NTLM HTTP Authentication in 2093 Microsoft Windows", RFC 4559, June 2006. 2095 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer 2096 Security (TLS) Protocol Version 1.2", RFC 5246, 2097 August 2008. 2099 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 2100 December 2011. 2102 [TLSNPN] Langley, A., "TLS Next Protocol Negotiation", 2103 draft-agl-tls-nextprotoneg-01 (work in progress), 2104 August 2010. 2106 [UDELCOMPRESSION] Yang, F., Amer, P., and J. Leighton, "A 2107 Methodology to Derive SPDY's Initial Dictionary 2108 for Zlib Compression", . 2111 Appendix A. Change Log (to be removed by RFC Editor before publication) 2113 A.1. Since draft-mbelshe-httpbis-spdy-00 2115 Adopted as base for draft-ietf-httpbis-http2. 2117 Updated authors/editors list. 2119 Added status note. 2121 Authors' Addresses 2123 Mike Belshe 2124 Twist 2126 EMail: mbelshe@chromium.org 2128 Roberto Peon 2129 Google, Inc 2131 EMail: fenix@google.com 2133 Martin Thomson (editor) 2134 Microsoft 2135 3210 Porter Drive 2136 Palo Alto 94043 2137 US 2139 EMail: martin.thomson@skype.net 2141 Alexey Melnikov (editor) 2142 Isode Ltd 2143 5 Castle Business Village 2144 36 Station Road 2145 Hampton, Middlesex TW12 2BX 2146 UK 2148 EMail: Alexey.Melnikov@isode.com