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