1 2 3 4 Network Working Group M. Belshe 5 Internet-Draft Twist 6 Expires: August 4, 2012 R. Peon 7 Google, Inc 8 Feb 2012 9 10 11 SPDY Protocol 12 draft-mbelshe-httpbis-spdy-00 13 14 Abstract 15 16 This document describes SPDY, a protocol designed for low-latency 17 transport of content over the World Wide Web. SPDY introduces two 18 layers of protocol. The lower layer is a general purpose framing 19 layer which can be used atop a reliable transport (likely TCP) for 20 multiplexed, prioritized, and compressed data communication of many 21 concurrent streams. The upper layer of the protocol provides HTTP- 22 like RFC2616 [RFC2616] semantics for compatibility with existing HTTP 23 application servers. 24 25 Status of this Memo 26 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 29 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 39 40 This Internet-Draft will expire on August 4, 2012. 41 42 Copyright Notice 43 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 46 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 53 54 55 Belshe & Peon Expires August 4, 2012 [Page 1] 56 58 Internet-Draft SPDY Feb 2012 59 60 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 65 66 67 Table of Contents 68 69 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 1.1. Document Organization . . . . . . . . . . . . . . . . . . 4 71 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 72 2. SPDY Framing Layer . . . . . . . . . . . . . . . . . . . . . . 6 73 2.1. Session (Connections) . . . . . . . . . . . . . . . . . . 6 74 2.2. Framing . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 2.2.1. Control frames . . . . . . . . . . . . . . . . . . . . 6 76 2.2.2. Data frames . . . . . . . . . . . . . . . . . . . . . 7 77 2.3. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 8 78 2.3.1. Stream frames . . . . . . . . . . . . . . . . . . . . 9 79 2.3.2. Stream creation . . . . . . . . . . . . . . . . . . . 9 80 2.3.3. Stream priority . . . . . . . . . . . . . . . . . . . 10 81 2.3.4. Stream headers . . . . . . . . . . . . . . . . . . . . 10 82 2.3.5. Stream data exchange . . . . . . . . . . . . . . . . . 10 83 2.3.6. Stream half-close . . . . . . . . . . . . . . . . . . 10 84 2.3.7. Stream close . . . . . . . . . . . . . . . . . . . . . 11 85 2.4. Error Handling . . . . . . . . . . . . . . . . . . . . . . 11 86 2.4.1. Session Error Handling . . . . . . . . . . . . . . . . 11 87 2.4.2. Stream Error Handling . . . . . . . . . . . . . . . . 12 88 2.5. Data flow . . . . . . . . . . . . . . . . . . . . . . . . 12 89 2.6. Control frame types . . . . . . . . . . . . . . . . . . . 12 90 2.6.1. SYN_STREAM . . . . . . . . . . . . . . . . . . . . . . 12 91 2.6.2. SYN_REPLY . . . . . . . . . . . . . . . . . . . . . . 14 92 2.6.3. RST_STREAM . . . . . . . . . . . . . . . . . . . . . . 15 93 2.6.4. SETTINGS . . . . . . . . . . . . . . . . . . . . . . . 16 94 2.6.5. PING . . . . . . . . . . . . . . . . . . . . . . . . . 19 95 2.6.6. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . . 20 96 2.6.7. HEADERS . . . . . . . . . . . . . . . . . . . . . . . 21 97 2.6.8. WINDOW_UPDATE . . . . . . . . . . . . . . . . . . . . 22 98 2.6.9. CREDENTIAL . . . . . . . . . . . . . . . . . . . . . . 24 99 2.6.10. Name/Value Header Block . . . . . . . . . . . . . . . 26 100 3. HTTP Layering over SPDY . . . . . . . . . . . . . . . . . . . 33 101 3.1. Connection Management . . . . . . . . . . . . . . . . . . 33 102 3.1.1. Use of GOAWAY . . . . . . . . . . . . . . . . . . . . 33 103 3.2. HTTP Request/Response . . . . . . . . . . . . . . . . . . 34 104 3.2.1. Request . . . . . . . . . . . . . . . . . . . . . . . 34 105 3.2.2. Response . . . . . . . . . . . . . . . . . . . . . . . 35 106 3.2.3. Authentication . . . . . . . . . . . . . . . . . . . . 36 107 3.3. Server Push Transactions . . . . . . . . . . . . . . . . . 37 108 3.3.1. Server implementation . . . . . . . . . . . . . . . . 38 109 110 111 112 Belshe & Peon Expires August 4, 2012 [Page 2] 113 115 Internet-Draft SPDY Feb 2012 116 117 118 3.3.2. Client implementation . . . . . . . . . . . . . . . . 39 119 4. Design Rationale and Notes . . . . . . . . . . . . . . . . . . 40 120 4.1. Separation of Framing Layer and Application Layer . . . . 40 121 4.2. Error handling - Framing Layer . . . . . . . . . . . . . . 40 122 4.3. One Connection Per Domain . . . . . . . . . . . . . . . . 40 123 4.4. Fixed vs Variable Length Fields . . . . . . . . . . . . . 41 124 4.5. Compression Context(s) . . . . . . . . . . . . . . . . . . 41 125 4.6. Unidirectional streams . . . . . . . . . . . . . . . . . . 42 126 4.7. Data Compression . . . . . . . . . . . . . . . . . . . . . 42 127 4.8. Server Push . . . . . . . . . . . . . . . . . . . . . . . 42 128 5. Security Considerations . . . . . . . . . . . . . . . . . . . 43 129 5.1. Use of Same-origin constraints . . . . . . . . . . . . . . 43 130 5.2. HTTP Headers and SPDY Headers . . . . . . . . . . . . . . 43 131 5.3. Cross-Protocol Attacks . . . . . . . . . . . . . . . . . . 43 132 5.4. Server Push Implicit Headers . . . . . . . . . . . . . . . 43 133 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 44 134 6.1. Long Lived Connections . . . . . . . . . . . . . . . . . . 44 135 6.2. SETTINGS frame . . . . . . . . . . . . . . . . . . . . . . 44 136 7. Incompatibilities with SPDY draft #2 . . . . . . . . . . . . . 45 137 8. Requirements Notation . . . . . . . . . . . . . . . . . . . . 46 138 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 47 139 10. Normative References . . . . . . . . . . . . . . . . . . . . . 48 140 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 50 141 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 Belshe & Peon Expires August 4, 2012 [Page 3] 170 172 Internet-Draft SPDY Feb 2012 173 174 175 1. Overview 176 177 One of the bottlenecks of HTTP implementations is that HTTP relies on 178 multiple connections for concurrency. This causes several problems, 179 including additional round trips for connection setup, slow-start 180 delays, and connection rationing by the client, where it tries to 181 avoid opening too many connections to any single server. HTTP 182 pipelining helps some, but only achieves partial multiplexing. In 183 addition, pipelining has proven non-deployable in existing browsers 184 due to intermediary interference. 185 186 SPDY adds a framing layer for multiplexing multiple, concurrent 187 streams across a single TCP connection (or any reliable transport 188 stream). The framing layer is optimized for HTTP-like request- 189 response streams, such that applications which run over HTTP today 190 can work over SPDY with little or no change on behalf of the web 191 application writer. 192 193 The SPDY session offers four improvements over HTTP: 194 195 Multiplexed requests: There is no limit to the number of requests 196 that can be issued concurrently over a single SPDY connection. 197 198 Prioritized requests: Clients can request certain resources to be 199 delivered first. This avoids the problem of congesting the 200 network channel with non-critical resources when a high-priority 201 request is pending. 202 203 Compressed headers: Clients today send a significant amount of 204 redundant data in the form of HTTP headers. Because a single web 205 page may require 50 or 100 subrequests, this data is significant. 206 207 Server pushed streams: Server Push enables content to be pushed 208 from servers to clients without a request. 209 210 SPDY attempts to preserve the existing semantics of HTTP. All 211 features such as cookies, ETags, Vary headers, Content-Encoding 212 negotiations, etc work as they do with HTTP; SPDY only replaces the 213 way the data is written to the network. 214 215 1.1. Document Organization 216 217 The SPDY Specification is split into two parts: a framing layer 218 (Section 2), which multiplexes a TCP connection into independent, 219 length-prefixed frames, and an HTTP layer (Section 3), which 220 specifies the mechanism for overlaying HTTP request/response pairs on 221 top of the framing layer. While some of the framing layer concepts 222 are isolated from the HTTP layer, building a generic framing layer 223 224 225 226 Belshe & Peon Expires August 4, 2012 [Page 4] 227 229 Internet-Draft SPDY Feb 2012 230 231 232 has not been a goal. The framing layer is tailored to the needs of 233 the HTTP protocol and server push. 234 235 1.2. Definitions 236 237 client: The endpoint initiating the SPDY session. 238 239 connection: A transport-level connection between two endpoints. 240 241 endpoint: Either the client or server of a connection. 242 243 frame: A header-prefixed sequence of bytes sent over a SPDY 244 session. 245 246 server: The endpoint which did not initiate the SPDY session. 247 248 session: A synonym for a connection. 249 250 session error: An error on the SPDY session. 251 252 stream: A bi-directional flow of bytes across a virtual channel 253 within a SPDY session. 254 255 stream error: An error on an individual SPDY stream. 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 Belshe & Peon Expires August 4, 2012 [Page 5] 284 286 Internet-Draft SPDY Feb 2012 287 288 289 2. SPDY Framing Layer 290 291 2.1. Session (Connections) 292 293 The SPDY framing layer (or "session") runs atop a reliable transport 294 layer such as TCP [RFC0793]. The client is the TCP connection 295 initiator. SPDY connections are persistent connections. 296 297 For best performance, it is expected that clients will not close open 298 connections until the user navigates away from all web pages 299 referencing a connection, or until the server closes the connection. 300 Servers are encouraged to leave connections open for as long as 301 possible, but can terminate idle connections if necessary. When 302 either endpoint closes the transport-level connection, it MUST first 303 send a GOAWAY (Section 2.6.6) frame so that the endpoints can 304 reliably determine if requests finished before the close. 305 306 2.2. Framing 307 308 Once the connection is established, clients and servers exchange 309 framed messages. There are two types of frames: control frames 310 (Section 2.2.1) and data frames (Section 2.2.2). Frames always have 311 a common header which is 8 bytes in length. 312 313 The first bit is a control bit indicating whether a frame is a 314 control frame or data frame. Control frames carry a version number, 315 a frame type, flags, and a length. Data frames contain the stream 316 ID, flags, and the length for the payload carried after the common 317 header. The simple header is designed to make reading and writing of 318 frames easy. 319 320 All integer values, including length, version, and type, are in 321 network byte order. SPDY does not enforce alignment of types in 322 dynamically sized frames. 323 324 2.2.1. Control frames 325 326 +----------------------------------+ 327 |C| Version(15bits) | Type(16bits) | 328 +----------------------------------+ 329 | Flags (8) | Length (24 bits) | 330 +----------------------------------+ 331 | Data | 332 +----------------------------------+ 333 334 Control bit: The 'C' bit is a single bit indicating if this is a 335 control message. For control frames this value is always 1. 336 337 338 339 340 Belshe & Peon Expires August 4, 2012 [Page 6] 341 343 Internet-Draft SPDY Feb 2012 344 345 346 Version: The version number of the SPDY protocol. This document 347 describes SPDY version 3. 348 349 Type: The type of control frame. See Control Frames for the complete 350 list of control frames. 351 352 Flags: Flags related to this frame. Flags for control frames and 353 data frames are different. 354 355 Length: An unsigned 24-bit value representing the number of bytes 356 after the length field. 357 358 Data: data associated with this control frame. The format and length 359 of this data is controlled by the control frame type. 360 361 Control frame processing requirements: 362 363 Note that full length control frames (16MB) can be large for 364 implementations running on resource-limited hardware. In such 365 cases, implementations MAY limit the maximum length frame 366 supported. However, all implementations MUST be able to receive 367 control frames of at least 8192 octets in length. 368 369 2.2.2. Data frames 370 371 +----------------------------------+ 372 |C| Stream-ID (31bits) | 373 +----------------------------------+ 374 | Flags (8) | Length (24 bits) | 375 +----------------------------------+ 376 | Data | 377 +----------------------------------+ 378 379 Control bit: For data frames this value is always 0. 380 381 Stream-ID: A 31-bit value identifying the stream. 382 383 Flags: Flags related to this frame. Valid flags are: 384 385 0x01 = FLAG_FIN - signifies that this frame represents the last 386 frame to be transmitted on this stream. See Stream Close 387 (Section 2.3.7) below. 388 389 0x02 = FLAG_COMPRESS - indicates that the data in this frame has 390 been compressed. 391 392 Length: An unsigned 24-bit value representing the number of bytes 393 after the length field. The total size of a data frame is 8 bytes + 394 395 396 397 Belshe & Peon Expires August 4, 2012 [Page 7] 398 400 Internet-Draft SPDY Feb 2012 401 402 403 length. It is valid to have a zero-length data frame. 404 405 Data: The variable-length data payload; the length was defined in the 406 length field. 407 408 Data frame processing requirements: 409 410 If an endpoint receives a data frame for a stream-id which is not 411 open and the endpoint has not sent a GOAWAY (Section 2.6.6) frame, 412 it MUST send issue a stream error (Section 2.4.2) with the error 413 code INVALID_STREAM for the stream-id. 414 415 If the endpoint which created the stream receives a data frame 416 before receiving a SYN_REPLY on that stream, it is a protocol 417 error, and the recipient MUST issue a stream error (Section 2.4.2) 418 with the status code PROTOCOL_ERROR for the stream-id. 419 420 Implementors note: If an endpoint receives multiple data frames 421 for invalid stream-ids, it MAY close the session. 422 423 All SPDY endpoints MUST accept compressed data frames. 424 Compression of data frames is always done using zlib compression. 425 Each stream initializes and uses its own compression context 426 dedicated to use within that stream. Endpoints are encouraged to 427 use application level compression rather than SPDY stream level 428 compression. 429 430 Each SPDY stream sending compressed frames creates its own zlib 431 context for that stream, and these compression contexts MUST be 432 distinct from the compression contexts used with SYN_STREAM/ 433 SYN_REPLY/HEADER compression. (Thus, if both endpoints of a 434 stream are compressing data on the stream, there will be two zlib 435 contexts, one for sending and one for receiving). 436 437 2.3. Streams 438 439 Streams are independent sequences of bi-directional data divided into 440 frames with several properties: 441 442 Streams may be created by either the client or server. 443 444 Streams optionally carry a set of name/value header pairs. 445 446 Streams can concurrently send data interleaved with other streams. 447 448 Streams may be cancelled. 449 450 451 452 453 454 Belshe & Peon Expires August 4, 2012 [Page 8] 455 457 Internet-Draft SPDY Feb 2012 458 459 460 2.3.1. Stream frames 461 462 SPDY defines 3 control frames to manage the lifecycle of a stream: 463 464 SYN_STREAM - Open a new stream 465 466 SYN_REPLY - Remote acknowledgement of a new, open stream 467 468 RST_STREAM - Close a stream 469 470 2.3.2. Stream creation 471 472 A stream is created by sending a control frame with the type set to 473 SYN_STREAM (Section 2.6.1). If the server is initiating the stream, 474 the Stream-ID must be even. If the client is initiating the stream, 475 the Stream-ID must be odd. 0 is not a valid Stream-ID. Stream-IDs 476 from each side of the connection must increase monotonically as new 477 streams are created. E.g. Stream 2 may be created after stream 3, 478 but stream 7 must not be created after stream 9. Stream IDs do not 479 wrap: when a client or server cannot create a new stream id without 480 exceeding a 31 bit value, it MUST NOT create a new stream. 481 482 The stream-id MUST increase with each new stream. If an endpoint 483 receives a SYN_STREAM with a stream id which is less than any 484 previously received SYN_STREAM, it MUST issue a session error 485 (Section 2.4.1) with the status PROTOCOL_ERROR. 486 487 It is a protocol error to send two SYN_STREAMs with the same 488 stream-id. If a recipient receives a second SYN_STREAM for the same 489 stream, it MUST issue a stream error (Section 2.4.2) with the status 490 code PROTOCOL_ERROR. 491 492 Upon receipt of a SYN_STREAM, the recipient can reject the stream by 493 sending a stream error (Section 2.4.2) with the error code 494 REFUSED_STREAM. Note, however, that the creating endpoint may have 495 already sent additional frames for that stream which cannot be 496 immediately stopped. 497 498 Once the stream is created, the creator may immediately send HEADERS 499 or DATA frames for that stream, without needing to wait for the 500 recipient to acknowledge. 501 502 2.3.2.1. Unidirectional streams 503 504 When an endpoint creates a stream with the FLAG_UNIDIRECTIONAL flag 505 set, it creates a unidirectional stream which the creating endpoint 506 can use to send frames, but the receiving endpoint cannot. The 507 receiving endpoint is implicitly already in the half-closed 508 509 510 511 Belshe & Peon Expires August 4, 2012 [Page 9] 512 514 Internet-Draft SPDY Feb 2012 515 516 517 (Section 2.3.6) state. 518 519 2.3.2.2. Bidirectional streams 520 521 SYN_STREAM frames which do not use the FLAG_UNIDIRECTIONAL flag are 522 bidirectional streams. Both endpoints can send data on a bi- 523 directional stream. 524 525 2.3.3. Stream priority 526 527 The creator of a stream assigns a priority for that stream. Priority 528 is represented as an integer from 0 to 7. 0 represents the highest 529 priority and 7 represents the lowest priority. 530 531 The sender and recipient SHOULD use best-effort to process streams in 532 the order of highest priority to lowest priority. 533 534 2.3.4. Stream headers 535 536 Streams carry optional sets of name/value pair headers which carry 537 metadata about the stream. After the stream has been created, and as 538 long as the sender is not closed (Section 2.3.7) or half-closed 539 (Section 2.3.6), each side may send HEADERS frame(s) containing the 540 header data. Header data can be sent in multiple HEADERS frames, and 541 HEADERS frames may be interleaved with data frames. 542 543 2.3.5. Stream data exchange 544 545 Once a stream is created, it can be used to send arbitrary amounts of 546 data. Generally this means that a series of data frames will be sent 547 on the stream until a frame containing the FLAG_FIN flag is set. The 548 FLAG_FIN can be set on a SYN_STREAM (Section 2.6.1), SYN_REPLY 549 (Section 2.6.2), HEADERS (Section 2.6.7) or a DATA (Section 2.2.2) 550 frame. Once the FLAG_FIN has been sent, the stream is considered to 551 be half-closed. 552 553 2.3.6. Stream half-close 554 555 When one side of the stream sends a frame with the FLAG_FIN flag set, 556 the stream is half-closed from that endpoint. The sender of the 557 FLAG_FIN MUST NOT send further frames on that stream. When both 558 sides have half-closed, the stream is closed. 559 560 If an endpoint receives a data frame after the stream is half-closed 561 from the sender (e.g. the endpoint has already received a prior frame 562 for the stream with the FIN flag set), it MUST send a RST_STREAM to 563 the sender with the status STREAM_ALREADY_CLOSED. 564 565 566 567 568 Belshe & Peon Expires August 4, 2012 [Page 10] 569 571 Internet-Draft SPDY Feb 2012 572 573 574 2.3.7. Stream close 575 576 There are 3 ways that streams can be terminated: 577 578 Normal termination: Normal stream termination occurs when both 579 sender and recipient have half-closed the stream by sending a 580 FLAG_FIN. 581 582 Abrupt termination: Either the client or server can send a 583 RST_STREAM control frame at any time. A RST_STREAM contains an 584 error code to indicate the reason for failure. When a RST_STREAM 585 is sent from the stream originator, it indicates a failure to 586 complete the stream and that no further data will be sent on the 587 stream. When a RST_STREAM is sent from the stream recipient, the 588 sender, upon receipt, should stop sending any data on the stream. 589 The stream recipient should be aware that there is a race between 590 data already in transit from the sender and the time the 591 RST_STREAM is received. See Stream Error Handling (Section 2.4.2) 592 593 TCP connection teardown: If the TCP connection is torn down while 594 un-closed streams exist, then the endpoint must assume that the 595 stream was abnormally interrupted and may be incomplete. 596 597 If an endpoint receives a data frame after the stream is closed, it 598 must send a RST_STREAM to the sender with the status PROTOCOL_ERROR. 599 600 2.4. Error Handling 601 602 The SPDY framing layer has only two types of errors, and they are 603 always handled consistently. Any reference in this specification to 604 "issue a session error" refers to Section 2.4.1. Any reference to 605 "issue a stream error" refers to Section 2.4.2. 606 607 2.4.1. Session Error Handling 608 609 A session error is any error which prevents further processing of the 610 framing layer or which corrupts the session compression state. When 611 a session error occurs, the endpoint encountering the error MUST 612 first send a GOAWAY (Section 2.6.6) frame with the stream id of most 613 recently received stream from the remote endpoint, and the error code 614 for why the session is terminating. After sending the GOAWAY frame, 615 the endpoint MUST close the TCP connection. 616 617 Note that the session compression state is dependent upon both 618 endpoints always processing all compressed data. If an endpoint 619 partially processes a frame containing compressed data without 620 updating compression state properly, future control frames which use 621 compression will be always be errored. Implementations SHOULD always 622 623 624 625 Belshe & Peon Expires August 4, 2012 [Page 11] 626 628 Internet-Draft SPDY Feb 2012 629 630 631 try to process compressed data so that errors which could be handled 632 as stream errors do not become session errors. 633 634 Note that because this GOAWAY is sent during a session error case, it 635 is possible that the GOAWAY will not be reliably received by the 636 receiving endpoint. It is a best-effort attempt to communicate with 637 the remote about why the session is going down. 638 639 2.4.2. Stream Error Handling 640 641 A stream error is an error related to a specific stream-id which does 642 not affect processing of other streams at the framing layer. Upon a 643 stream error, the endpoint MUST send a RST_STREAM (Section 2.6.3) 644 frame which contains the stream id of the stream where the error 645 occurred and the error status which caused the error. After sending 646 the RST_STREAM, the stream is closed to the sending endpoint. After 647 sending the RST_STREAM, if the sender receives any frames other than 648 a RST_STREAM for that stream id, it will result in sending additional 649 RST_STREAM frames. An endpoint MUST NOT send a RST_STREAM in 650 response to an RST_STREAM, as doing so would lead to RST_STREAM 651 loops. Sending a RST_STREAM does not cause the SPDY session to be 652 closed. 653 654 If an endpoint has multiple RST_STREAM frames to send in succession 655 for the same stream-id and the same error code, it MAY coalesce them 656 into a single RST_STREAM frame. (This can happen if a stream is 657 closed, but the remote sends multiple data frames. There is no 658 reason to send a RST_STREAM for each frame in succession). 659 660 2.5. Data flow 661 662 Because TCP provides a single stream of data on which SPDY 663 multiplexes multiple logical streams, clients and servers must 664 intelligently interleave data messages for concurrent sessions. 665 666 2.6. Control frame types 667 668 2.6.1. SYN_STREAM 669 670 The SYN_STREAM control frame allows the sender to asynchronously 671 create a stream between the endpoints. See Stream Creation 672 (Section 2.3.2) 673 674 675 676 677 678 679 680 681 682 Belshe & Peon Expires August 4, 2012 [Page 12] 683 685 Internet-Draft SPDY Feb 2012 686 687 688 +------------------------------------+ 689 |1| version | 1 | 690 +------------------------------------+ 691 | Flags (8) | Length (24 bits) | 692 +------------------------------------+ 693 |X| Stream-ID (31bits) | 694 +------------------------------------+ 695 |X| Associated-To-Stream-ID (31bits) | 696 +------------------------------------+ 697 | Pri|Unused | Slot | | 698 +-------------------+ | 699 | Number of Name/Value pairs (int32) | <+ 700 +------------------------------------+ | 701 | Length of name (int32) | | This section is the "Name/Value 702 +------------------------------------+ | Header Block", and is compressed. 703 | Name (string) | | 704 +------------------------------------+ | 705 | Length of value (int32) | | 706 +------------------------------------+ | 707 | Value (string) | | 708 +------------------------------------+ | 709 | (repeats) | <+ 710 711 Flags: Flags related to this frame. Valid flags are: 712 713 0x01 = FLAG_FIN - marks this frame as the last frame to be 714 transmitted on this stream and puts the sender in the half-closed 715 (Section 2.3.6) state. 716 717 0x02 = FLAG_UNIDIRECTIONAL - a stream created with this flag puts 718 the recipient in the half-closed (Section 2.3.6) state. 719 720 Length: The length is the number of bytes which follow the length 721 field in the frame. For SYN_STREAM frames, this is 10 bytes plus the 722 length of the compressed Name/Value block. 723 724 Stream-ID: The 31-bit identifier for this stream. This stream-id 725 will be used in frames which are part of this stream. 726 727 Associated-To-Stream-ID: The 31-bit identifier for a stream which 728 this stream is associated to. If this stream is independent of all 729 other streams, it should be 0. 730 731 Priority: A 3-bit priority (Section 2.3.3) field. 732 733 Unused: 5 bits of unused space, reserved for future use. 734 735 Slot: An 8 bit unsigned integer specifying the index in the server's 736 737 738 739 Belshe & Peon Expires August 4, 2012 [Page 13] 740 742 Internet-Draft SPDY Feb 2012 743 744 745 CREDENTIAL vector of the client certificate to be used for this 746 request. see CREDENTIAL frame (Section 2.6.9). The value 0 means no 747 client certificate should be associated with this stream. 748 749 Name/Value Header Block: A set of name/value pairs carried as part of 750 the SYN_STREAM. see Name/Value Header Block (Section 2.6.10). 751 752 If an endpoint receives a SYN_STREAM which is larger than the 753 implementation supports, it MAY send a RST_STREAM with error code 754 FRAME_TOO_LARGE. All implementations MUST support the minimum size 755 limits defined in the Control Frames section (Section 2.2.1). 756 757 2.6.2. SYN_REPLY 758 759 SYN_REPLY indicates the acceptance of a stream creation by the 760 recipient of a SYN_STREAM frame. 761 762 +------------------------------------+ 763 |1| version | 2 | 764 +------------------------------------+ 765 | Flags (8) | Length (24 bits) | 766 +------------------------------------+ 767 |X| Stream-ID (31bits) | 768 +------------------------------------+ 769 | Number of Name/Value pairs (int32) | <+ 770 +------------------------------------+ | 771 | Length of name (int32) | | This section is the "Name/Value 772 +------------------------------------+ | Header Block", and is compressed. 773 | Name (string) | | 774 +------------------------------------+ | 775 | Length of value (int32) | | 776 +------------------------------------+ | 777 | Value (string) | | 778 +------------------------------------+ | 779 | (repeats) | <+ 780 781 Flags: Flags related to this frame. Valid flags are: 782 783 0x01 = FLAG_FIN - marks this frame as the last frame to be 784 transmitted on this stream and puts the sender in the half-closed 785 (Section 2.3.6) state. 786 787 Length: The length is the number of bytes which follow the length 788 field in the frame. For SYN_REPLY frames, this is 4 bytes plus the 789 length of the compressed Name/Value block. 790 791 Stream-ID: The 31-bit identifier for this stream. 792 793 794 795 796 Belshe & Peon Expires August 4, 2012 [Page 14] 797 799 Internet-Draft SPDY Feb 2012 800 801 802 If an endpoint receives multiple SYN_REPLY frames for the same active 803 stream ID, it MUST issue a stream error (Section 2.4.2) with the 804 error code STREAM_IN_USE. 805 806 Name/Value Header Block: A set of name/value pairs carried as part of 807 the SYN_STREAM. see Name/Value Header Block (Section 2.6.10). 808 809 If an endpoint receives a SYN_REPLY which is larger than the 810 implementation supports, it MAY send a RST_STREAM with error code 811 FRAME_TOO_LARGE. All implementations MUST support the minimum size 812 limits defined in the Control Frames section (Section 2.2.1). 813 814 2.6.3. RST_STREAM 815 816 The RST_STREAM frame allows for abnormal termination of a stream. 817 When sent by the creator of a stream, it indicates the creator wishes 818 to cancel the stream. When sent by the recipient of a stream, it 819 indicates an error or that the recipient did not want to accept the 820 stream, so the stream should be closed. 821 822 +----------------------------------+ 823 |1| version | 3 | 824 +----------------------------------+ 825 | Flags (8) | 8 | 826 +----------------------------------+ 827 |X| Stream-ID (31bits) | 828 +----------------------------------+ 829 | Status code | 830 +----------------------------------+ 831 832 Flags: Flags related to this frame. RST_STREAM does not define any 833 flags. This value must be 0. 834 835 Length: An unsigned 24-bit value representing the number of bytes 836 after the length field. For RST_STREAM control frames, this value is 837 always 8. 838 839 Stream-ID: The 31-bit identifier for this stream. 840 841 Status code: (32 bits) An indicator for why the stream is being 842 terminated.The following status codes are defined: 843 844 1 - PROTOCOL_ERROR. This is a generic error, and should only be 845 used if a more specific error is not available. 846 847 2 - INVALID_STREAM. This is returned when a frame is received for 848 a stream which is not active. 849 850 851 852 853 Belshe & Peon Expires August 4, 2012 [Page 15] 854 856 Internet-Draft SPDY Feb 2012 857 858 859 3 - REFUSED_STREAM. Indicates that the stream was refused before 860 any processing has been done on the stream. 861 862 4 - UNSUPPORTED_VERSION. Indicates that the recipient of a stream 863 does not support the SPDY version requested. 864 865 5 - CANCEL. Used by the creator of a stream to indicate that the 866 stream is no longer needed. 867 868 6 - INTERNAL_ERROR. This is a generic error which can be used 869 when the implementation has internally failed, not due to anything 870 in the protocol. 871 872 7 - FLOW_CONTROL_ERROR. The endpoint detected that its peer 873 violated the flow control protocol. 874 875 8 - STREAM_IN_USE. The endpoint received a SYN_REPLY for a stream 876 already open. 877 878 9 - STREAM_ALREADY_CLOSED. The endpoint received a data or 879 SYN_REPLY frame for a stream which is half closed. 880 881 10 - INVALID_CREDENTIALS. The server received a request for a 882 resource whose origin does not have valid credentials in the 883 client certificate vector. 884 885 11 - FRAME_TOO_LARGE. The endpoint received a frame which this 886 implementation could not support. If FRAME_TOO_LARGE is sent for 887 a SYN_STREAM, HEADERS, or SYN_REPLY frame without fully processing 888 the compressed portion of those frames, then the compression state 889 will be out-of-sync with the other endpoint. In this case, 890 senders of FRAME_TOO_LARGE MUST close the session. 891 892 Note: 0 is not a valid status code for a RST_STREAM. 893 894 After receiving a RST_STREAM on a stream, the recipient must not send 895 additional frames for that stream, and the stream moves into the 896 closed state. 897 898 2.6.4. SETTINGS 899 900 A SETTINGS frame contains a set of id/value pairs for communicating 901 configuration data about how the two endpoints may communicate. 902 SETTINGS frames can be sent at any time by either endpoint, are 903 optionally sent, and are fully asynchronous. When the server is the 904 sender, the sender can request that configuration data be persisted 905 by the client across SPDY sessions and returned to the server in 906 future communications. 907 908 909 910 Belshe & Peon Expires August 4, 2012 [Page 16] 911 913 Internet-Draft SPDY Feb 2012 914 915 916 Persistence of SETTINGS ID/Value pairs is done on a per origin/IP 917 pair (the "origin" is the set of scheme, host, and port from the URI. 918 See [RFC6454]). That is, when a client connects to a server, and the 919 server persists settings within the client, the client SHOULD return 920 the persisted settings on future connections to the same origin AND 921 IP address and TCP port. Clients MUST NOT request servers to use the 922 persistence features of the SETTINGS frames, and servers MUST ignore 923 persistence related flags sent by a client. 924 925 +----------------------------------+ 926 |1| version | 4 | 927 +----------------------------------+ 928 | Flags (8) | Length (24 bits) | 929 +----------------------------------+ 930 | Number of entries | 931 +----------------------------------+ 932 | ID/Value Pairs | 933 | ... | 934 935 Control bit: The control bit is always 1 for this message. 936 937 Version: The SPDY version number. 938 939 Type: The message type for a SETTINGS message is 4. 940 941 Flags: FLAG_SETTINGS_CLEAR_SETTINGS (0x1): When set, the client 942 should clear any previously persisted SETTINGS ID/Value pairs. If 943 this frame contains ID/Value pairs with the 944 FLAG_SETTINGS_PERSIST_VALUE set, then the client will first clear its 945 existing, persisted settings, and then persist the values with the 946 flag set which are contained within this frame. Because persistence 947 is only implemented on the client, this flag can only be used when 948 the sender is the server. 949 950 Length: An unsigned 24-bit value representing the number of bytes 951 after the length field. The total size of a SETTINGS frame is 8 952 bytes + length. 953 954 Number of entries: A 32-bit value representing the number of ID/value 955 pairs in this message. 956 957 ID: A 32-bit ID number, comprised of 8 bits of flags and 24 bits of 958 unique ID. 959 960 ID.flags: 961 962 FLAG_SETTINGS_PERSIST_VALUE (0x1): When set, the sender of this 963 SETTINGS frame is requesting that the recipient persist the ID/ 964 965 966 967 Belshe & Peon Expires August 4, 2012 [Page 17] 968 970 Internet-Draft SPDY Feb 2012 971 972 973 Value and return it in future SETTINGS frames sent from the 974 sender to this recipient. Because persistence is only 975 implemented on the client, this flag is only sent by the 976 server. 977 978 FLAG_SETTINGS_PERSISTED (0x2): When set, the sender is 979 notifying the recipient that this ID/Value pair was previously 980 sent to the sender by the recipient with the 981 FLAG_SETTINGS_PERSIST_VALUE, and the sender is returning it. 982 Because persistence is only implemented on the client, this 983 flag is only sent by the client. 984 985 Defined IDs: 986 987 1 - SETTINGS_UPLOAD_BANDWIDTH allows the sender to send its 988 expected upload bandwidth on this channel. This number is an 989 estimate. The value should be the integral number of kilobytes 990 per second that the sender predicts as an expected maximum 991 upload channel capacity. 992 993 2 - SETTINGS_DOWNLOAD_BANDWIDTH allows the sender to send its 994 expected download bandwidth on this channel. This number is an 995 estimate. The value should be the integral number of kilobytes 996 per second that the sender predicts as an expected maximum 997 download channel capacity. 998 999 3 - SETTINGS_ROUND_TRIP_TIME allows the sender to send its 1000 expected round-trip-time on this channel. The round trip time 1001 is defined as the minimum amount of time to send a control 1002 frame from this client to the remote and receive a response. 1003 The value is represented in milliseconds. 1004 1005 4 - SETTINGS_MAX_CONCURRENT_STREAMS allows the sender to inform 1006 the remote endpoint the maximum number of concurrent streams 1007 which it will allow. By default there is no limit. For 1008 implementors it is recommended that this value be no smaller 1009 than 100. 1010 1011 5 - SETTINGS_CURRENT_CWND allows the sender to inform the 1012 remote endpoint of the current TCP CWND value. 1013 1014 6 - SETTINGS_DOWNLOAD_RETRANS_RATE allows the sender to inform 1015 the remote endpoint the retransmission rate (bytes 1016 retransmitted / total bytes transmitted). 1017 1018 7 - SETTINGS_INITIAL_WINDOW_SIZE allows the sender to inform 1019 the remote endpoint the initial window size (in bytes) for new 1020 streams. 1021 1022 1023 1024 Belshe & Peon Expires August 4, 2012 [Page 18] 1025 1027 Internet-Draft SPDY Feb 2012 1028 1029 1030 8 - SETTINGS_CLIENT_CERTIFICATE_VECTOR_SIZE allows the server 1031 to inform the client if the new size of the client certificate 1032 vector. 1033 1034 Value: A 32-bit value. 1035 1036 The message is intentionally extensible for future information which 1037 may improve client-server communications. The sender does not need 1038 to send every type of ID/value. It must only send those for which it 1039 has accurate values to convey. When multiple ID/value pairs are 1040 sent, they should be sent in order of lowest id to highest id. A 1041 single SETTINGS frame MUST not contain multiple values for the same 1042 ID. If the recipient of a SETTINGS frame discovers multiple values 1043 for the same ID, it MUST ignore all values except the first one. 1044 1045 A server may send multiple SETTINGS frames containing different ID/ 1046 Value pairs. When the same ID/Value is sent twice, the most recent 1047 value overrides any previously sent values. If the server sends IDs 1048 1, 2, and 3 with the FLAG_SETTINGS_PERSIST_VALUE in a first SETTINGS 1049 frame, and then sends IDs 4 and 5 with the 1050 FLAG_SETTINGS_PERSIST_VALUE, when the client returns the persisted 1051 state on its next SETTINGS frame, it SHOULD send all 5 settings (1, 1052 2, 3, 4, and 5 in this example) to the server. 1053 1054 2.6.5. PING 1055 1056 The PING control frame is a mechanism for measuring a minimal round- 1057 trip time from the sender. It can be sent from the client or the 1058 server. Recipients of a PING frame should send an identical frame to 1059 the sender as soon as possible (if there is other pending data 1060 waiting to be sent, PING should take highest priority). Each ping 1061 sent by a sender should use a unique ID. 1062 1063 +----------------------------------+ 1064 |1| version | 6 | 1065 +----------------------------------+ 1066 | 0 (flags) | 4 (length) | 1067 +----------------------------------| 1068 | 32-bit ID | 1069 +----------------------------------+ 1070 1071 Control bit: The control bit is always 1 for this message. 1072 1073 Version: The SPDY version number. 1074 1075 Type: The message type for a PING message is 6. 1076 1077 Length: This frame is always 4 bytes long. 1078 1079 1080 1081 Belshe & Peon Expires August 4, 2012 [Page 19] 1082 1084 Internet-Draft SPDY Feb 2012 1085 1086 1087 ID: A unique ID for this ping, represented as an unsigned 32 bit 1088 value. When the client initiates a ping, it must use an odd numbered 1089 ID. When the server initiates a ping, it must use an even numbered 1090 ping. Use of odd/even IDs is required in order to avoid accidental 1091 looping on PINGs (where each side initiates an identical PING at the 1092 same time). 1093 1094 Note: If a sender uses all possible PING ids (e.g. has sent all 2^31 1095 possible IDs), it can wrap and start re-using IDs. 1096 1097 If a server receives an even numbered PING which it did not initiate, 1098 it must ignore the PING. If a client receives an odd numbered PING 1099 which it did not initiate, it must ignore the PING. 1100 1101 2.6.6. GOAWAY 1102 1103 The GOAWAY control frame is a mechanism to tell the remote side of 1104 the connection to stop creating streams on this session. It can be 1105 sent from the client or the server. Once sent, the sender will not 1106 respond to any new SYN_STREAMs on this session. Recipients of a 1107 GOAWAY frame must not send additional streams on this session, 1108 although a new session can be established for new streams. The 1109 purpose of this message is to allow an endpoint to gracefully stop 1110 accepting new streams (perhaps for a reboot or maintenance), while 1111 still finishing processing of previously established streams. 1112 1113 There is an inherent race condition between an endpoint sending 1114 SYN_STREAMs and the remote sending a GOAWAY message. To deal with 1115 this case, the GOAWAY contains a last-stream-id indicating the 1116 stream-id of the last stream which was created on the sending 1117 endpoint in this session. If the receiver of the GOAWAY sent new 1118 SYN_STREAMs for sessions after this last-stream-id, they were not 1119 processed by the server and the receiver may treat the stream as 1120 though it had never been created at all (hence the receiver may want 1121 to re-create the stream later on a new session). 1122 1123 Endpoints should always send a GOAWAY message before closing a 1124 connection so that the remote can know whether a stream has been 1125 partially processed or not. (For example, if an HTTP client sends a 1126 POST at the same time that a server closes a connection, the client 1127 cannot know if the server started to process that POST request if the 1128 server does not send a GOAWAY frame to indicate where it stopped 1129 working). 1130 1131 After sending a GOAWAY message, the sender must ignore all SYN_STREAM 1132 frames for new streams. 1133 1134 1135 1136 1137 1138 Belshe & Peon Expires August 4, 2012 [Page 20] 1139 1141 Internet-Draft SPDY Feb 2012 1142 1143 1144 +----------------------------------+ 1145 |1| version | 7 | 1146 +----------------------------------+ 1147 | 0 (flags) | 8 (length) | 1148 +----------------------------------| 1149 |X| Last-good-stream-ID (31 bits) | 1150 +----------------------------------+ 1151 | Status code | 1152 +----------------------------------+ 1153 1154 Control bit: The control bit is always 1 for this message. 1155 1156 Version: The SPDY version number. 1157 1158 Type: The message type for a GOAWAY message is 7. 1159 1160 Length: This frame is always 8 bytes long. 1161 1162 Last-good-stream-Id: The last stream id which was replied to (with 1163 either a SYN_REPLY or RST_STREAM) by the sender of the GOAWAY 1164 message. If no streams were replied to, this value MUST be 0. 1165 1166 Status: The reason for closing the session. 1167 1168 0 - OK. This is a normal session teardown. 1169 1170 1 - PROTOCOL_ERROR. This is a generic error, and should only be 1171 used if a more specific error is not available. 1172 1173 11 - INTERNAL_ERROR. This is a generic error which can be used 1174 when the implementation has internally failed, not due to anything 1175 in the protocol. 1176 1177 2.6.7. HEADERS 1178 1179 The HEADERS frame augments a stream with additional headers. It may 1180 be optionally sent on an existing stream at any time. Specific 1181 application of the headers in this frame is application-dependent. 1182 The name/value header block within this frame is compressed. 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 Belshe & Peon Expires August 4, 2012 [Page 21] 1196 1198 Internet-Draft SPDY Feb 2012 1199 1200 1201 +------------------------------------+ 1202 |1| version | 8 | 1203 +------------------------------------+ 1204 | Flags (8) | Length (24 bits) | 1205 +------------------------------------+ 1206 |X| Stream-ID (31bits) | 1207 +------------------------------------+ 1208 | Number of Name/Value pairs (int32) | <+ 1209 +------------------------------------+ | 1210 | Length of name (int32) | | This section is the "Name/Value 1211 +------------------------------------+ | Header Block", and is compressed. 1212 | Name (string) | | 1213 +------------------------------------+ | 1214 | Length of value (int32) | | 1215 +------------------------------------+ | 1216 | Value (string) | | 1217 +------------------------------------+ | 1218 | (repeats) | <+ 1219 1220 Flags: Flags related to this frame. Valid flags are: 1221 1222 0x01 = FLAG_FIN - marks this frame as the last frame to be 1223 transmitted on this stream and puts the sender in the half-closed 1224 (Section 2.3.6) state. 1225 1226 Length: An unsigned 24 bit value representing the number of bytes 1227 after the length field. The minimum length of the length field is 4 1228 (when the number of name value pairs is 0). 1229 1230 Stream-ID: The stream this HEADERS block is associated with. 1231 1232 Name/Value Header Block: A set of name/value pairs carried as part of 1233 the SYN_STREAM. see Name/Value Header Block (Section 2.6.10). 1234 1235 2.6.8. WINDOW_UPDATE 1236 1237 The WINDOW_UPDATE control frame is used to implement per stream flow 1238 control in SPDY. Flow control in SPDY is per hop, that is, only 1239 between the two endpoints of a SPDY connection. If there are one or 1240 more intermediaries between the client and the origin server, flow 1241 control signals are not explicitly forwarded by the intermediaries. 1242 (However, throttling of data transfer by any recipient may have the 1243 effect of indirectly propagating flow control information upstream 1244 back to the original sender.) Flow control only applies to the data 1245 portion of data frames. Recipients must buffer all control frames. 1246 If a recipient fails to buffer an entire control frame, it MUST issue 1247 a stream error (Section 2.4.2) with the status code 1248 FLOW_CONTROL_ERROR for the stream. 1249 1250 1251 1252 Belshe & Peon Expires August 4, 2012 [Page 22] 1253 1255 Internet-Draft SPDY Feb 2012 1256 1257 1258 Flow control in SPDY is implemented by a data transfer window kept by 1259 the sender of each stream. The data transfer window is a simple 1260 uint32 that indicates how many bytes of data the sender can transmit. 1261 After a stream is created, but before any data frames have been 1262 transmitted, the sender begins with the initial window size. This 1263 window size is a measure of the buffering capability of the 1264 recipient. The sender must not send a data frame with data length 1265 greater than the transfer window size. After sending each data 1266 frame, the sender decrements its transfer window size by the amount 1267 of data transmitted. When the window size becomes less than or equal 1268 to 0, the sender must pause transmitting data frames. At the other 1269 end of the stream, the recipient sends a WINDOW_UPDATE control back 1270 to notify the sender that it has consumed some data and freed up 1271 buffer space to receive more data. 1272 1273 +----------------------------------+ 1274 |1| version | 9 | 1275 +----------------------------------+ 1276 | 0 (flags) | 8 (length) | 1277 +----------------------------------+ 1278 |X| Stream-ID (31-bits) | 1279 +----------------------------------+ 1280 |X| Delta-Window-Size (31-bits) | 1281 +----------------------------------+ 1282 1283 Control bit: The control bit is always 1 for this message. 1284 1285 Version: The SPDY version number. 1286 1287 Type: The message type for a WINDOW_UPDATE message is 9. 1288 1289 Length: The length field is always 8 for this frame (there are 8 1290 bytes after the length field). 1291 1292 Stream-ID: The stream ID that this WINDOW_UPDATE control frame is 1293 for. 1294 1295 Delta-Window-Size: The additional number of bytes that the sender can 1296 transmit in addition to existing remaining window size. The legal 1297 range for this field is 1 to 2^31 - 1 (0x7fffffff) bytes. 1298 1299 The window size as kept by the sender must never exceed 2^31 1300 (although it can become negative in one special case). If a sender 1301 receives a WINDOW_UPDATE that causes the its window size to exceed 1302 this limit, it must send RST_STREAM with status code 1303 FLOW_CONTROL_ERROR to terminate the stream. 1304 1305 When a SPDY connection is first established, the default initial 1306 1307 1308 1309 Belshe & Peon Expires August 4, 2012 [Page 23] 1310 1312 Internet-Draft SPDY Feb 2012 1313 1314 1315 window size for all streams is 64KB. An endpoint can use the 1316 SETTINGS control frame to adjust the initial window size for the 1317 connection. That is, its peer can start out using the 64KB default 1318 initial window size when sending data frames before receiving the 1319 SETTINGS. Because SETTINGS is asynchronous, there may be a race 1320 condition if the recipient wants to decrease the initial window size, 1321 but its peer immediately sends 64KB on the creation of a new 1322 connection, before waiting for the SETTINGS to arrive. This is one 1323 case where the window size kept by the sender will become negative. 1324 Once the sender detects this condition, it must stop sending data 1325 frames and wait for the recipient to catch up. The recipient has two 1326 choices: 1327 1328 immediately send RST_STREAM with FLOW_CONTROL_ERROR status code. 1329 1330 allow the head of line blocking (as there is only one stream for 1331 the session and the amount of data in flight is bounded by the 1332 default initial window size), and send WINDOW_UPDATE as it 1333 consumes data. 1334 1335 In the case of option 2, both sides must compute the window size 1336 based on the initial window size in the SETTINGS. For example, if 1337 the recipient sets the initial window size to be 16KB, and the sender 1338 sends 64KB immediately on connection establishment, the sender will 1339 discover its window size is -48KB on receipt of the SETTINGS. As the 1340 recipient consumes the first 16KB, it must send a WINDOW_UPDATE of 1341 16KB back to the sender. This interaction continues until the 1342 sender's window size becomes positive again, and it can resume 1343 transmitting data frames. 1344 1345 After the recipient reads in a data frame with FLAG_FIN that marks 1346 the end of the data stream, it should not send WINDOW_UPDATE frames 1347 as it consumes the last data frame. A sender should ignore all the 1348 WINDOW_UPDATE frames associated with the stream after it send the 1349 last frame for the stream. 1350 1351 The data frames from the sender and the WINDOW_UPDATE frames from the 1352 recipient are completely asynchronous with respect to each other. 1353 This property allows a recipient to aggressively update the window 1354 size kept by the sender to prevent the stream from stalling. 1355 1356 2.6.9. CREDENTIAL 1357 1358 The CREDENTIAL control frame is used by the client to send additional 1359 client certificates to the server. A SPDY client may decide to send 1360 requests for resources from different origins on the same SPDY 1361 session if it decides that that server handles both origins. For 1362 example if the IP address associated with both hostnames matches and 1363 1364 1365 1366 Belshe & Peon Expires August 4, 2012 [Page 24] 1367 1369 Internet-Draft SPDY Feb 2012 1370 1371 1372 the SSL server certificate presented in the initial handshake is 1373 valid for both hostnames. However, because the SSL connection can 1374 contain at most one client certificate, the client needs a mechanism 1375 to send additional client certificates to the server. 1376 1377 The server is required to maintain a vector of client certificates 1378 associated with a SPDY session. When the client needs to send a 1379 client certificate to the server, it will send a CREDENTIAL frame 1380 that specifies the index of the slot in which to store the 1381 certificate as well as proof that the client posesses the 1382 corresponding private key. The initial size of this vector must be 1383 8. If the client provides a client certificate during the first TLS 1384 handshake, the contents of this certificate must be copied into the 1385 first slot (index 1) in the CREDENTIAL vector, though it may be 1386 overwritten by subsequent CREDENTIAL frames. The server must 1387 exclusively use the CREDNETIAL vector when evaluating the client 1388 certificates associated with an origin. The server may change the 1389 size of this vector by sending a SETTINGS frame with the setting 1390 SETTINGS_CLIENT_CERTIFICATE_VECTOR_SIZE value specified. In the 1391 event that the new size is smaller than the current size, truncation 1392 occurs preserving lower-index slots as possible. 1393 1394 TLS renegotiation with client authentication is incompatible with 1395 SPDY given the multiplexed nature of SPDY. Specifically, imagine 1396 that the client has 2 requests outstanding to the server for two 1397 different pages (in different tabs). When the renegotiation + client 1398 certificate request comes in, the browser is unable to determine 1399 which resource triggered the client certificate request, in order to 1400 prompt the user accordingly. 1401 1402 +----------------------------------+ 1403 |1|000000000000001|0000000000001011| 1404 +----------------------------------+ 1405 | flags (8) | Length (24 bits) | 1406 +----------------------------------+ 1407 | Slot (16 bits) | | 1408 +-----------------+ | 1409 | Proof Length (32 bits) | 1410 +----------------------------------+ 1411 | Proof | 1412 +----------------------------------+ <+ 1413 | Certificate Length (32 bits) | | 1414 +----------------------------------+ | Repeated until end of frame 1415 | Certificate | | 1416 +----------------------------------+ <+ 1417 1418 Slot: The index in the server's client certificate vector where this 1419 certificate should be stored. If there is already a certificate 1420 1421 1422 1423 Belshe & Peon Expires August 4, 2012 [Page 25] 1424 1426 Internet-Draft SPDY Feb 2012 1427 1428 1429 stored at this index, it will be overwritten. The index is one 1430 based, not zero based; zero is an invalid slot index. 1431 1432 Proof: Cryptographic proof that the client has possession of the 1433 private key associated with the certificate. The format is a TLS 1434 digitally-signed element 1435 (http://tools.ietf.org/html/rfc5246#section-4.7). The signature 1436 algorithm must be the same as that used in the CertificateVerify 1437 message. However, since the MD5+SHA1 signature type used in TLS 1.0 1438 connections can not be correctly encoded in a digitally-signed 1439 element, SHA1 must be used when MD5+SHA1 was used in the SSL 1440 connection. The signature is calculated over a 32 byte TLS extractor 1441 value (http://tools.ietf.org/html/rfc5705) with a label of "EXPORTER 1442 SPDY certificate proof" using the empty string as context. ForRSA 1443 certificates the signature would be a PKCS#1 v1.5 signature. For 1444 ECDSA, it would be an ECDSA-Sig-Value 1445 (http://tools.ietf.org/html/rfc5480#appendix-A). For a 1024-bit RSA 1446 key, the CREDENTIAL message would be ~500 bytes. 1447 1448 Certificate: The certificate chain, starting with the leaf 1449 certificate. Each certificate must be encoded as a 32 bit length, 1450 followed by a DER encoded certificate. The certificate must be of 1451 the same type (RSA, ECDSA, etc) as the client certificate associated 1452 with the SSL connection. 1453 1454 If the server receives a request for a resource with unacceptable 1455 credential (either missing or invalid), it must reply with a 1456 RST_STREAM frame with the status code INVALID_CREDENTIALS. Upon 1457 receipt of a RST_STREAM frame with INVALID_CREDENTIALS, the client 1458 should initiate a new stream directly to the requested origin and 1459 resend the request. Note, SPDY does not allow the server to request 1460 different client authentication for different resources in the same 1461 origin. 1462 1463 If the server receives an invalid CREDENTIAL frame, it MUST respond 1464 with a GOAWAY frame and shutdown the session. 1465 1466 2.6.10. Name/Value Header Block 1467 1468 The Name/Value Header Block is found in the SYN_STREAM, SYN_REPLY and 1469 HEADERS control frames, and shares a common format: 1470 1471 1472 1473 1474 1475 1476 1477 1478 1479 1480 Belshe & Peon Expires August 4, 2012 [Page 26] 1481 1483 Internet-Draft SPDY Feb 2012 1484 1485 1486 +------------------------------------+ 1487 | Number of Name/Value pairs (int32) | 1488 +------------------------------------+ 1489 | Length of name (int32) | 1490 +------------------------------------+ 1491 | Name (string) | 1492 +------------------------------------+ 1493 | Length of value (int32) | 1494 +------------------------------------+ 1495 | Value (string) | 1496 +------------------------------------+ 1497 | (repeats) | 1498 1499 Number of Name/Value pairs: The number of repeating name/value pairs 1500 following this field. 1501 1502 List of Name/Value pairs: 1503 1504 Length of Name: a 32-bit value containing the number of octets in 1505 the name field. Note that in practice, this length must not 1506 exceed 2^24, as that is the maximum size of a SPDY frame. 1507 1508 Name: 0 or more octets, 8-bit sequences of data, excluding 0. 1509 1510 Length of Value: a 32-bit value containing the number of octets in 1511 the value field. Note that in practice, this length must not 1512 exceed 2^24, as that is the maximum size of a SPDY frame. 1513 1514 Value: 0 or more octets, 8-bit sequences of data, excluding 0. 1515 1516 Each header name must have at least one value. Header names are 1517 encoded using the US-ASCII character set [ASCII] and must be all 1518 lower case. The length of each name must be greater than zero. A 1519 recipient of a zero-length name MUST issue a stream error 1520 (Section 2.4.2) with the status code PROTOCOL_ERROR for the 1521 stream-id. 1522 1523 Duplicate header names are not allowed. To send two identically 1524 named headers, send a header with two values, where the values are 1525 separated by a single NUL (0) byte. A header value can either be 1526 empty (e.g. the length is zero) or it can contain multiple, NUL- 1527 separated values, each with length greater than zero. The value 1528 never starts nor ends with a NUL character. Recipients of illegal 1529 value fields MUST issue a stream error (Section 2.4.2) with the 1530 status code PROTOCOL_ERROR for the stream-id. 1531 1532 1533 1534 1535 1536 1537 Belshe & Peon Expires August 4, 2012 [Page 27] 1538 1540 Internet-Draft SPDY Feb 2012 1541 1542 1543 2.6.10.1. Compression 1544 1545 The Name/Value Header Block is a section of the SYN_STREAM, 1546 SYN_REPLY, and HEADERS frames used to carry header meta-data. This 1547 block is always compressed using zlib compression. Within this 1548 specification, any reference to 'zlib' is referring to the ZLIB 1549 Compressed Data Format Specification Version 3.3 as part of RFC1950. 1550 [RFC1950] 1551 1552 For each HEADERS compression instance, the initial state is 1553 initialized using the following dictionary [UDELCOMPRESSION]: 1554 1555 const unsigned char SPDY_dictionary_txt[] = { 1556 0x00, 0x00, 0x00, 0x07, 0x6f, 0x70, 0x74, 0x69, \\ - - - - o p t i 1557 0x6f, 0x6e, 0x73, 0x00, 0x00, 0x00, 0x04, 0x68, \\ o n s - - - - h 1558 0x65, 0x61, 0x64, 0x00, 0x00, 0x00, 0x04, 0x70, \\ e a d - - - - p 1559 0x6f, 0x73, 0x74, 0x00, 0x00, 0x00, 0x03, 0x70, \\ o s t - - - - p 1560 0x75, 0x74, 0x00, 0x00, 0x00, 0x06, 0x64, 0x65, \\ u t - - - - d e 1561 0x6c, 0x65, 0x74, 0x65, 0x00, 0x00, 0x00, 0x05, \\ l e t e - - - - 1562 0x74, 0x72, 0x61, 0x63, 0x65, 0x00, 0x00, 0x00, \\ t r a c e - - - 1563 0x06, 0x61, 0x63, 0x63, 0x65, 0x70, 0x74, 0x00, \\ - a c c e p t - 1564 0x00, 0x00, 0x0e, 0x61, 0x63, 0x63, 0x65, 0x70, \\ - - - a c c e p 1565 0x74, 0x2d, 0x63, 0x68, 0x61, 0x72, 0x73, 0x65, \\ t - c h a r s e 1566 0x74, 0x00, 0x00, 0x00, 0x0f, 0x61, 0x63, 0x63, \\ t - - - - a c c 1567 0x65, 0x70, 0x74, 0x2d, 0x65, 0x6e, 0x63, 0x6f, \\ e p t - e n c o 1568 0x64, 0x69, 0x6e, 0x67, 0x00, 0x00, 0x00, 0x0f, \\ d i n g - - - - 1569 0x61, 0x63, 0x63, 0x65, 0x70, 0x74, 0x2d, 0x6c, \\ a c c e p t - l 1570 0x61, 0x6e, 0x67, 0x75, 0x61, 0x67, 0x65, 0x00, \\ a n g u a g e - 1571 0x00, 0x00, 0x0d, 0x61, 0x63, 0x63, 0x65, 0x70, \\ - - - a c c e p 1572 0x74, 0x2d, 0x72, 0x61, 0x6e, 0x67, 0x65, 0x73, \\ t - r a n g e s 1573 0x00, 0x00, 0x00, 0x03, 0x61, 0x67, 0x65, 0x00, \\ - - - - a g e - 1574 0x00, 0x00, 0x05, 0x61, 0x6c, 0x6c, 0x6f, 0x77, \\ - - - a l l o w 1575 0x00, 0x00, 0x00, 0x0d, 0x61, 0x75, 0x74, 0x68, \\ - - - - a u t h 1576 0x6f, 0x72, 0x69, 0x7a, 0x61, 0x74, 0x69, 0x6f, \\ o r i z a t i o 1577 0x6e, 0x00, 0x00, 0x00, 0x0d, 0x63, 0x61, 0x63, \\ n - - - - c a c 1578 0x68, 0x65, 0x2d, 0x63, 0x6f, 0x6e, 0x74, 0x72, \\ h e - c o n t r 1579 0x6f, 0x6c, 0x00, 0x00, 0x00, 0x0a, 0x63, 0x6f, \\ o l - - - - c o 1580 0x6e, 0x6e, 0x65, 0x63, 0x74, 0x69, 0x6f, 0x6e, \\ n n e c t i o n 1581 0x00, 0x00, 0x00, 0x0c, 0x63, 0x6f, 0x6e, 0x74, \\ - - - - c o n t 1582 0x65, 0x6e, 0x74, 0x2d, 0x62, 0x61, 0x73, 0x65, \\ e n t - b a s e 1583 0x00, 0x00, 0x00, 0x10, 0x63, 0x6f, 0x6e, 0x74, \\ - - - - c o n t 1584 0x65, 0x6e, 0x74, 0x2d, 0x65, 0x6e, 0x63, 0x6f, \\ e n t - e n c o 1585 0x64, 0x69, 0x6e, 0x67, 0x00, 0x00, 0x00, 0x10, \\ d i n g - - - - 1586 0x63, 0x6f, 0x6e, 0x74, 0x65, 0x6e, 0x74, 0x2d, \\ c o n t e n t - 1587 0x6c, 0x61, 0x6e, 0x67, 0x75, 0x61, 0x67, 0x65, \\ l a n g u a g e 1588 0x00, 0x00, 0x00, 0x0e, 0x63, 0x6f, 0x6e, 0x74, \\ - - - - c o n t 1589 0x65, 0x6e, 0x74, 0x2d, 0x6c, 0x65, 0x6e, 0x67, \\ e n t - l e n g 1590 0x74, 0x68, 0x00, 0x00, 0x00, 0x10, 0x63, 0x6f, \\ t h - - - - c o 1591 1592 1593 1594 Belshe & Peon Expires August 4, 2012 [Page 28] 1595 1597 Internet-Draft SPDY Feb 2012 1598 1599 1600 0x6e, 0x74, 0x65, 0x6e, 0x74, 0x2d, 0x6c, 0x6f, \\ n t e n t - l o 1601 0x63, 0x61, 0x74, 0x69, 0x6f, 0x6e, 0x00, 0x00, \\ c a t i o n - - 1602 0x00, 0x0b, 0x63, 0x6f, 0x6e, 0x74, 0x65, 0x6e, \\ - - c o n t e n 1603 0x74, 0x2d, 0x6d, 0x64, 0x35, 0x00, 0x00, 0x00, \\ t - m d 5 - - - 1604 0x0d, 0x63, 0x6f, 0x6e, 0x74, 0x65, 0x6e, 0x74, \\ - c o n t e n t 1605 0x2d, 0x72, 0x61, 0x6e, 0x67, 0x65, 0x00, 0x00, \\ - r a n g e - - 1606 0x00, 0x0c, 0x63, 0x6f, 0x6e, 0x74, 0x65, 0x6e, \\ - - c o n t e n 1607 0x74, 0x2d, 0x74, 0x79, 0x70, 0x65, 0x00, 0x00, \\ t - t y p e - - 1608 0x00, 0x04, 0x64, 0x61, 0x74, 0x65, 0x00, 0x00, \\ - - d a t e - - 1609 0x00, 0x04, 0x65, 0x74, 0x61, 0x67, 0x00, 0x00, \\ - - e t a g - - 1610 0x00, 0x06, 0x65, 0x78, 0x70, 0x65, 0x63, 0x74, \\ - - e x p e c t 1611 0x00, 0x00, 0x00, 0x07, 0x65, 0x78, 0x70, 0x69, \\ - - - - e x p i 1612 0x72, 0x65, 0x73, 0x00, 0x00, 0x00, 0x04, 0x66, \\ r e s - - - - f 1613 0x72, 0x6f, 0x6d, 0x00, 0x00, 0x00, 0x04, 0x68, \\ r o m - - - - h 1614 0x6f, 0x73, 0x74, 0x00, 0x00, 0x00, 0x08, 0x69, \\ o s t - - - - i 1615 0x66, 0x2d, 0x6d, 0x61, 0x74, 0x63, 0x68, 0x00, \\ f - m a t c h - 1616 0x00, 0x00, 0x11, 0x69, 0x66, 0x2d, 0x6d, 0x6f, \\ - - - i f - m o 1617 0x64, 0x69, 0x66, 0x69, 0x65, 0x64, 0x2d, 0x73, \\ d i f i e d - s 1618 0x69, 0x6e, 0x63, 0x65, 0x00, 0x00, 0x00, 0x0d, \\ i n c e - - - - 1619 0x69, 0x66, 0x2d, 0x6e, 0x6f, 0x6e, 0x65, 0x2d, \\ i f - n o n e - 1620 0x6d, 0x61, 0x74, 0x63, 0x68, 0x00, 0x00, 0x00, \\ m a t c h - - - 1621 0x08, 0x69, 0x66, 0x2d, 0x72, 0x61, 0x6e, 0x67, \\ - i f - r a n g 1622 0x65, 0x00, 0x00, 0x00, 0x13, 0x69, 0x66, 0x2d, \\ e - - - - i f - 1623 0x75, 0x6e, 0x6d, 0x6f, 0x64, 0x69, 0x66, 0x69, \\ u n m o d i f i 1624 0x65, 0x64, 0x2d, 0x73, 0x69, 0x6e, 0x63, 0x65, \\ e d - s i n c e 1625 0x00, 0x00, 0x00, 0x0d, 0x6c, 0x61, 0x73, 0x74, \\ - - - - l a s t 1626 0x2d, 0x6d, 0x6f, 0x64, 0x69, 0x66, 0x69, 0x65, \\ - m o d i f i e 1627 0x64, 0x00, 0x00, 0x00, 0x08, 0x6c, 0x6f, 0x63, \\ d - - - - l o c 1628 0x61, 0x74, 0x69, 0x6f, 0x6e, 0x00, 0x00, 0x00, \\ a t i o n - - - 1629 0x0c, 0x6d, 0x61, 0x78, 0x2d, 0x66, 0x6f, 0x72, \\ - m a x - f o r 1630 0x77, 0x61, 0x72, 0x64, 0x73, 0x00, 0x00, 0x00, \\ w a r d s - - - 1631 0x06, 0x70, 0x72, 0x61, 0x67, 0x6d, 0x61, 0x00, \\ - p r a g m a - 1632 0x00, 0x00, 0x12, 0x70, 0x72, 0x6f, 0x78, 0x79, \\ - - - p r o x y 1633 0x2d, 0x61, 0x75, 0x74, 0x68, 0x65, 0x6e, 0x74, \\ - a u t h e n t 1634 0x69, 0x63, 0x61, 0x74, 0x65, 0x00, 0x00, 0x00, \\ i c a t e - - - 1635 0x13, 0x70, 0x72, 0x6f, 0x78, 0x79, 0x2d, 0x61, \\ - p r o x y - a 1636 0x75, 0x74, 0x68, 0x6f, 0x72, 0x69, 0x7a, 0x61, \\ u t h o r i z a 1637 0x74, 0x69, 0x6f, 0x6e, 0x00, 0x00, 0x00, 0x05, \\ t i o n - - - - 1638 0x72, 0x61, 0x6e, 0x67, 0x65, 0x00, 0x00, 0x00, \\ r a n g e - - - 1639 0x07, 0x72, 0x65, 0x66, 0x65, 0x72, 0x65, 0x72, \\ - r e f e r e r 1640 0x00, 0x00, 0x00, 0x0b, 0x72, 0x65, 0x74, 0x72, \\ - - - - r e t r 1641 0x79, 0x2d, 0x61, 0x66, 0x74, 0x65, 0x72, 0x00, \\ y - a f t e r - 1642 0x00, 0x00, 0x06, 0x73, 0x65, 0x72, 0x76, 0x65, \\ - - - s e r v e 1643 0x72, 0x00, 0x00, 0x00, 0x02, 0x74, 0x65, 0x00, \\ r - - - - t e - 1644 0x00, 0x00, 0x07, 0x74, 0x72, 0x61, 0x69, 0x6c, \\ - - - t r a i l 1645 0x65, 0x72, 0x00, 0x00, 0x00, 0x11, 0x74, 0x72, \\ e r - - - - t r 1646 0x61, 0x6e, 0x73, 0x66, 0x65, 0x72, 0x2d, 0x65, \\ a n s f e r - e 1647 0x6e, 0x63, 0x6f, 0x64, 0x69, 0x6e, 0x67, 0x00, \\ n c o d i n g - 1648 1649 1650 1651 Belshe & Peon Expires August 4, 2012 [Page 29] 1652 1654 Internet-Draft SPDY Feb 2012 1655 1656 1657 0x00, 0x00, 0x07, 0x75, 0x70, 0x67, 0x72, 0x61, \\ - - - u p g r a 1658 0x64, 0x65, 0x00, 0x00, 0x00, 0x0a, 0x75, 0x73, \\ d e - - - - u s 1659 0x65, 0x72, 0x2d, 0x61, 0x67, 0x65, 0x6e, 0x74, \\ e r - a g e n t 1660 0x00, 0x00, 0x00, 0x04, 0x76, 0x61, 0x72, 0x79, \\ - - - - v a r y 1661 0x00, 0x00, 0x00, 0x03, 0x76, 0x69, 0x61, 0x00, \\ - - - - v i a - 1662 0x00, 0x00, 0x07, 0x77, 0x61, 0x72, 0x6e, 0x69, \\ - - - w a r n i 1663 0x6e, 0x67, 0x00, 0x00, 0x00, 0x10, 0x77, 0x77, \\ n g - - - - w w 1664 0x77, 0x2d, 0x61, 0x75, 0x74, 0x68, 0x65, 0x6e, \\ w - a u t h e n 1665 0x74, 0x69, 0x63, 0x61, 0x74, 0x65, 0x00, 0x00, \\ t i c a t e - - 1666 0x00, 0x06, 0x6d, 0x65, 0x74, 0x68, 0x6f, 0x64, \\ - - m e t h o d 1667 0x00, 0x00, 0x00, 0x03, 0x67, 0x65, 0x74, 0x00, \\ - - - - g e t - 1668 0x00, 0x00, 0x06, 0x73, 0x74, 0x61, 0x74, 0x75, \\ - - - s t a t u 1669 0x73, 0x00, 0x00, 0x00, 0x06, 0x32, 0x30, 0x30, \\ s - - - - 2 0 0 1670 0x20, 0x4f, 0x4b, 0x00, 0x00, 0x00, 0x07, 0x76, \\ - O K - - - - v 1671 0x65, 0x72, 0x73, 0x69, 0x6f, 0x6e, 0x00, 0x00, \\ e r s i o n - - 1672 0x00, 0x08, 0x48, 0x54, 0x54, 0x50, 0x2f, 0x31, \\ - - H T T P - 1 1673 0x2e, 0x31, 0x00, 0x00, 0x00, 0x03, 0x75, 0x72, \\ - 1 - - - - u r 1674 0x6c, 0x00, 0x00, 0x00, 0x06, 0x70, 0x75, 0x62, \\ l - - - - p u b 1675 0x6c, 0x69, 0x63, 0x00, 0x00, 0x00, 0x0a, 0x73, \\ l i c - - - - s 1676 0x65, 0x74, 0x2d, 0x63, 0x6f, 0x6f, 0x6b, 0x69, \\ e t - c o o k i 1677 0x65, 0x00, 0x00, 0x00, 0x0a, 0x6b, 0x65, 0x65, \\ e - - - - k e e 1678 0x70, 0x2d, 0x61, 0x6c, 0x69, 0x76, 0x65, 0x00, \\ p - a l i v e - 1679 0x00, 0x00, 0x06, 0x6f, 0x72, 0x69, 0x67, 0x69, \\ - - - o r i g i 1680 0x6e, 0x31, 0x30, 0x30, 0x31, 0x30, 0x31, 0x32, \\ n 1 0 0 1 0 1 2 1681 0x30, 0x31, 0x32, 0x30, 0x32, 0x32, 0x30, 0x35, \\ 0 1 2 0 2 2 0 5 1682 0x32, 0x30, 0x36, 0x33, 0x30, 0x30, 0x33, 0x30, \\ 2 0 6 3 0 0 3 0 1683 0x32, 0x33, 0x30, 0x33, 0x33, 0x30, 0x34, 0x33, \\ 2 3 0 3 3 0 4 3 1684 0x30, 0x35, 0x33, 0x30, 0x36, 0x33, 0x30, 0x37, \\ 0 5 3 0 6 3 0 7 1685 0x34, 0x30, 0x32, 0x34, 0x30, 0x35, 0x34, 0x30, \\ 4 0 2 4 0 5 4 0 1686 0x36, 0x34, 0x30, 0x37, 0x34, 0x30, 0x38, 0x34, \\ 6 4 0 7 4 0 8 4 1687 0x30, 0x39, 0x34, 0x31, 0x30, 0x34, 0x31, 0x31, \\ 0 9 4 1 0 4 1 1 1688 0x34, 0x31, 0x32, 0x34, 0x31, 0x33, 0x34, 0x31, \\ 4 1 2 4 1 3 4 1 1689 0x34, 0x34, 0x31, 0x35, 0x34, 0x31, 0x36, 0x34, \\ 4 4 1 5 4 1 6 4 1690 0x31, 0x37, 0x35, 0x30, 0x32, 0x35, 0x30, 0x34, \\ 1 7 5 0 2 5 0 4 1691 0x35, 0x30, 0x35, 0x32, 0x30, 0x33, 0x20, 0x4e, \\ 5 0 5 2 0 3 - N 1692 0x6f, 0x6e, 0x2d, 0x41, 0x75, 0x74, 0x68, 0x6f, \\ o n - A u t h o 1693 0x72, 0x69, 0x74, 0x61, 0x74, 0x69, 0x76, 0x65, \\ r i t a t i v e 1694 0x20, 0x49, 0x6e, 0x66, 0x6f, 0x72, 0x6d, 0x61, \\ - I n f o r m a 1695 0x74, 0x69, 0x6f, 0x6e, 0x32, 0x30, 0x34, 0x20, \\ t i o n 2 0 4 - 1696 0x4e, 0x6f, 0x20, 0x43, 0x6f, 0x6e, 0x74, 0x65, \\ N o - C o n t e 1697 0x6e, 0x74, 0x33, 0x30, 0x31, 0x20, 0x4d, 0x6f, \\ n t 3 0 1 - M o 1698 0x76, 0x65, 0x64, 0x20, 0x50, 0x65, 0x72, 0x6d, \\ v e d - P e r m 1699 0x61, 0x6e, 0x65, 0x6e, 0x74, 0x6c, 0x79, 0x34, \\ a n e n t l y 4 1700 0x30, 0x30, 0x20, 0x42, 0x61, 0x64, 0x20, 0x52, \\ 0 0 - B a d - R 1701 0x65, 0x71, 0x75, 0x65, 0x73, 0x74, 0x34, 0x30, \\ e q u e s t 4 0 1702 0x31, 0x20, 0x55, 0x6e, 0x61, 0x75, 0x74, 0x68, \\ 1 - U n a u t h 1703 0x6f, 0x72, 0x69, 0x7a, 0x65, 0x64, 0x34, 0x30, \\ o r i z e d 4 0 1704 0x33, 0x20, 0x46, 0x6f, 0x72, 0x62, 0x69, 0x64, \\ 3 - F o r b i d 1705 1706 1707 1708 Belshe & Peon Expires August 4, 2012 [Page 30] 1709 1711 Internet-Draft SPDY Feb 2012 1712 1713 1714 0x64, 0x65, 0x6e, 0x34, 0x30, 0x34, 0x20, 0x4e, \\ d e n 4 0 4 - N 1715 0x6f, 0x74, 0x20, 0x46, 0x6f, 0x75, 0x6e, 0x64, \\ o t - F o u n d 1716 0x35, 0x30, 0x30, 0x20, 0x49, 0x6e, 0x74, 0x65, \\ 5 0 0 - I n t e 1717 0x72, 0x6e, 0x61, 0x6c, 0x20, 0x53, 0x65, 0x72, \\ r n a l - S e r 1718 0x76, 0x65, 0x72, 0x20, 0x45, 0x72, 0x72, 0x6f, \\ v e r - E r r o 1719 0x72, 0x35, 0x30, 0x31, 0x20, 0x4e, 0x6f, 0x74, \\ r 5 0 1 - N o t 1720 0x20, 0x49, 0x6d, 0x70, 0x6c, 0x65, 0x6d, 0x65, \\ - I m p l e m e 1721 0x6e, 0x74, 0x65, 0x64, 0x35, 0x30, 0x33, 0x20, \\ n t e d 5 0 3 - 1722 0x53, 0x65, 0x72, 0x76, 0x69, 0x63, 0x65, 0x20, \\ S e r v i c e - 1723 0x55, 0x6e, 0x61, 0x76, 0x61, 0x69, 0x6c, 0x61, \\ U n a v a i l a 1724 0x62, 0x6c, 0x65, 0x4a, 0x61, 0x6e, 0x20, 0x46, \\ b l e J a n - F 1725 0x65, 0x62, 0x20, 0x4d, 0x61, 0x72, 0x20, 0x41, \\ e b - M a r - A 1726 0x70, 0x72, 0x20, 0x4d, 0x61, 0x79, 0x20, 0x4a, \\ p r - M a y - J 1727 0x75, 0x6e, 0x20, 0x4a, 0x75, 0x6c, 0x20, 0x41, \\ u n - J u l - A 1728 0x75, 0x67, 0x20, 0x53, 0x65, 0x70, 0x74, 0x20, \\ u g - S e p t - 1729 0x4f, 0x63, 0x74, 0x20, 0x4e, 0x6f, 0x76, 0x20, \\ O c t - N o v - 1730 0x44, 0x65, 0x63, 0x20, 0x30, 0x30, 0x3a, 0x30, \\ D e c - 0 0 - 0 1731 0x30, 0x3a, 0x30, 0x30, 0x20, 0x4d, 0x6f, 0x6e, \\ 0 - 0 0 - M o n 1732 0x2c, 0x20, 0x54, 0x75, 0x65, 0x2c, 0x20, 0x57, \\ - - T u e - - W 1733 0x65, 0x64, 0x2c, 0x20, 0x54, 0x68, 0x75, 0x2c, \\ e d - - T h u - 1734 0x20, 0x46, 0x72, 0x69, 0x2c, 0x20, 0x53, 0x61, \\ - F r i - - S a 1735 0x74, 0x2c, 0x20, 0x53, 0x75, 0x6e, 0x2c, 0x20, \\ t - - S u n - - 1736 0x47, 0x4d, 0x54, 0x63, 0x68, 0x75, 0x6e, 0x6b, \\ G M T c h u n k 1737 0x65, 0x64, 0x2c, 0x74, 0x65, 0x78, 0x74, 0x2f, \\ e d - t e x t - 1738 0x68, 0x74, 0x6d, 0x6c, 0x2c, 0x69, 0x6d, 0x61, \\ h t m l - i m a 1739 0x67, 0x65, 0x2f, 0x70, 0x6e, 0x67, 0x2c, 0x69, \\ g e - p n g - i 1740 0x6d, 0x61, 0x67, 0x65, 0x2f, 0x6a, 0x70, 0x67, \\ m a g e - j p g 1741 0x2c, 0x69, 0x6d, 0x61, 0x67, 0x65, 0x2f, 0x67, \\ - i m a g e - g 1742 0x69, 0x66, 0x2c, 0x61, 0x70, 0x70, 0x6c, 0x69, \\ i f - a p p l i 1743 0x63, 0x61, 0x74, 0x69, 0x6f, 0x6e, 0x2f, 0x78, \\ c a t i o n - x 1744 0x6d, 0x6c, 0x2c, 0x61, 0x70, 0x70, 0x6c, 0x69, \\ m l - a p p l i 1745 0x63, 0x61, 0x74, 0x69, 0x6f, 0x6e, 0x2f, 0x78, \\ c a t i o n - x 1746 0x68, 0x74, 0x6d, 0x6c, 0x2b, 0x78, 0x6d, 0x6c, \\ h t m l - x m l 1747 0x2c, 0x74, 0x65, 0x78, 0x74, 0x2f, 0x70, 0x6c, \\ - t e x t - p l 1748 0x61, 0x69, 0x6e, 0x2c, 0x74, 0x65, 0x78, 0x74, \\ a i n - t e x t 1749 0x2f, 0x6a, 0x61, 0x76, 0x61, 0x73, 0x63, 0x72, \\ - j a v a s c r 1750 0x69, 0x70, 0x74, 0x2c, 0x70, 0x75, 0x62, 0x6c, \\ i p t - p u b l 1751 0x69, 0x63, 0x70, 0x72, 0x69, 0x76, 0x61, 0x74, \\ i c p r i v a t 1752 0x65, 0x6d, 0x61, 0x78, 0x2d, 0x61, 0x67, 0x65, \\ e m a x - a g e 1753 0x3d, 0x67, 0x7a, 0x69, 0x70, 0x2c, 0x64, 0x65, \\ - g z i p - d e 1754 0x66, 0x6c, 0x61, 0x74, 0x65, 0x2c, 0x73, 0x64, \\ f l a t e - s d 1755 0x63, 0x68, 0x63, 0x68, 0x61, 0x72, 0x73, 0x65, \\ c h c h a r s e 1756 0x74, 0x3d, 0x75, 0x74, 0x66, 0x2d, 0x38, 0x63, \\ t - u t f - 8 c 1757 0x68, 0x61, 0x72, 0x73, 0x65, 0x74, 0x3d, 0x69, \\ h a r s e t - i 1758 0x73, 0x6f, 0x2d, 0x38, 0x38, 0x35, 0x39, 0x2d, \\ s o - 8 8 5 9 - 1759 0x31, 0x2c, 0x75, 0x74, 0x66, 0x2d, 0x2c, 0x2a, \\ 1 - u t f - - - 1760 0x2c, 0x65, 0x6e, 0x71, 0x3d, 0x30, 0x2e \\ - e n q - 0 - 1761 }; 1762 1763 1764 1765 Belshe & Peon Expires August 4, 2012 [Page 31] 1766 1768 Internet-Draft SPDY Feb 2012 1769 1770 1771 The entire contents of the name/value header block is compressed 1772 using zlib. There is a single zlib stream for all name value pairs 1773 in one direction on a connection. SPDY uses a SYNC_FLUSH between 1774 each compressed frame. 1775 1776 Implementation notes: the compression engine can be tuned to favor 1777 speed or size. Optimizing for size increases memory use and CPU 1778 consumption. Because header blocks are generally small, implementors 1779 may want to reduce the window-size of the compression engine from the 1780 default 15bits (a 32KB window) to more like 11bits (a 2KB window). 1781 The exact setting is chosen by the compressor, the decompressor will 1782 work with any setting. 1783 1784 1785 1786 1787 1788 1789 1790 1791 1792 1793 1794 1795 1796 1797 1798 1799 1800 1801 1802 1803 1804 1805 1806 1807 1808 1809 1810 1811 1812 1813 1814 1815 1816 1817 1818 1819 1820 1821 1822 Belshe & Peon Expires August 4, 2012 [Page 32] 1823 1825 Internet-Draft SPDY Feb 2012 1826 1827 1828 3. HTTP Layering over SPDY 1829 1830 SPDY is intended to be as compatible as possible with current web- 1831 based applications. This means that, from the perspective of the 1832 server business logic or application API, the features of HTTP are 1833 unchanged. To achieve this, all of the application request and 1834 response header semantics are preserved, although the syntax of 1835 conveying those semantics has changed. Thus, the rules from the 1836 HTTP/1.1 specification in RFC2616 [RFC2616] apply with the changes in 1837 the sections below. 1838 1839 3.1. Connection Management 1840 1841 Clients SHOULD NOT open more than one SPDY session to a given origin 1842 [RFC6454] concurrently. 1843 1844 Note that it is possible for one SPDY session to be finishing (e.g. a 1845 GOAWAY message has been sent, but not all streams have finished), 1846 while another SPDY session is starting. 1847 1848 3.1.1. Use of GOAWAY 1849 1850 SPDY provides a GOAWAY message which can be used when closing a 1851 connection from either the client or server. Without a server GOAWAY 1852 message, HTTP has a race condition where the client sends a request 1853 (a new SYN_STREAM) just as the server is closing the connection, and 1854 the client cannot know if the server received the stream or not. By 1855 using the last-stream-id in the GOAWAY, servers can indicate to the 1856 client if a request was processed or not. 1857 1858 Note that some servers will choose to send the GOAWAY and immediately 1859 terminate the connection without waiting for active streams to 1860 finish. The client will be able to determine this because SPDY 1861 streams are determinstically closed. This abrupt termination will 1862 force the client to heuristically decide whether to retry the pending 1863 requests. Clients always need to be capable of dealing with this 1864 case because they must deal with accidental connection termination 1865 cases, which are the same as the server never having sent a GOAWAY. 1866 1867 More sophisticated servers will use GOAWAY to implement a graceful 1868 teardown. They will send the GOAWAY and provide some time for the 1869 active streams to finish before terminating the connection. 1870 1871 If a SPDY client closes the connection, it should also send a GOAWAY 1872 message. This allows the server to know if any server-push streams 1873 were received by the client. 1874 1875 If the endpoint closing the connection has not received any 1876 1877 1878 1879 Belshe & Peon Expires August 4, 2012 [Page 33] 1880 1882 Internet-Draft SPDY Feb 2012 1883 1884 1885 SYN_STREAMs from the remote, the GOAWAY will contain a last-stream-id 1886 of 0. 1887 1888 3.2. HTTP Request/Response 1889 1890 3.2.1. Request 1891 1892 The client initiates a request by sending a SYN_STREAM frame. For 1893 requests which do not contain a body, the SYN_STREAM frame MUST set 1894 the FLAG_FIN, indicating that the client intends to send no further 1895 data on this stream. For requests which do contain a body, the 1896 SYN_STREAM will not contain the FLAG_FIN, and the body will follow 1897 the SYN_STREAM in a series of DATA frames. The last DATA frame will 1898 set the FLAG_FIN to indicate the end of the body. 1899 1900 The SYN_STREAM Name/Value section will contain all of the HTTP 1901 headers which are associated with an HTTP request. The header block 1902 in SPDY is mostly unchanged from today's HTTP header block, with the 1903 following differences: 1904 1905 The first line of the request is unfolded into name/value pairs 1906 like other HTTP headers and MUST be present: 1907 1908 ":method" - the HTTP method for this request (e.g. "GET", 1909 "POST", "HEAD", etc) 1910 1911 ":path" - the url-path for this url with "/" prefixed. (See 1912 RFC1738 [RFC1738]). For example, for 1913 "http://www.google.com/search?q=dogs" the path would be 1914 "/search?q=dogs". 1915 1916 ":version" - the HTTP version of this request (e.g. 1917 "HTTP/1.1") 1918 1919 In addition, the following two name/value pairs must also be 1920 present in every request: 1921 1922 ":host" - the hostport (See RFC1738 [RFC1738]) portion of the 1923 URL for this request (e.g. "www.google.com:1234"). This header 1924 is the same as the HTTP 'Host' header. 1925 1926 ":scheme" - the scheme portion of the URL for this request 1927 (e.g. "https")) 1928 1929 Header names are all lowercase. 1930 1931 The Connection, Host, Keep-Alive, Proxy-Connection, and Transfer- 1932 Encoding headers are not valid and MUST not be sent. 1933 1934 1935 1936 Belshe & Peon Expires August 4, 2012 [Page 34] 1937 1939 Internet-Draft SPDY Feb 2012 1940 1941 1942 User-agents MUST support gzip compression. Regardless of the 1943 Accept-Encoding sent by the user-agent, the server may always send 1944 content encoded with gzip or deflate encoding. 1945 1946 If a server receives a request where the sum of the data frame 1947 payload lengths does not equal the size of the Content-Length 1948 header, the server MUST return a 400 (Bad Request) error. 1949 1950 POST-specific changes: 1951 1952 Although POSTs are inherently chunked, POST requests SHOULD 1953 also be accompanied by a Content-Length header. There are two 1954 reasons for this: First, it assists with upload progress meters 1955 for an improved user experience. But second, we know from 1956 early versions of SPDY that failure to send a content length 1957 header is incompatible with many existing HTTP server 1958 implementations. Existing user-agents do not omit the Content- 1959 Length header, and server implementations have come to depend 1960 upon this. 1961 1962 The user-agent is free to prioritize requests as it sees fit. If the 1963 user-agent cannot make progress without receiving a resource, it 1964 should attempt to raise the priority of that resource. Resources 1965 such as images, SHOULD generally use the lowest priority. 1966 1967 If a client sends a SYN_STREAM without all of the method, host, path, 1968 scheme, and version headers, the server MUST reply with a HTTP 400 1969 Bad Request reply. 1970 1971 3.2.2. Response 1972 1973 The server responds to a client request with a SYN_REPLY frame. 1974 Symmetric to the client's upload stream, server will send data after 1975 the SYN_REPLY frame via a series of DATA frames, and the last data 1976 frame will contain the FLAG_FIN to indicate successful end-of-stream. 1977 If a response (like a 202 or 204 response) contains no body, the 1978 SYN_REPLY frame may contain the FLAG_FIN flag to indicate no further 1979 data will be sent on the stream. 1980 1981 The response status line is unfolded into name/value pairs like 1982 other HTTP headers and must be present: 1983 1984 ":status" - The HTTP response status code (e.g. "200" or "200 1985 OK") 1986 1987 ":version" - The HTTP response version (e.g. "HTTP/1.1") 1988 1989 1990 1991 1992 1993 Belshe & Peon Expires August 4, 2012 [Page 35] 1994 1996 Internet-Draft SPDY Feb 2012 1997 1998 1999 All header names must be lowercase. 2000 2001 The Connection, Keep-Alive, Proxy-Connection, and Transfer- 2002 Encoding headers are not valid and MUST not be sent. 2003 2004 Responses MAY be accompanied by a Content-Length header for 2005 advisory purposes. (e.g. for UI progress meters) 2006 2007 If a client receives a response where the sum of the data frame 2008 payload lengths does not equal the size of the Content-Length 2009 header, the client MUST ignore the content length header. 2010 2011 If a client receives a SYN_REPLY without a status or without a 2012 version header, the client must reply with a RST_STREAM frame 2013 indicating a PROTOCOL ERROR. 2014 2015 3.2.3. Authentication 2016 2017 When a client sends a request to an origin server that requires 2018 authentication, the server can reply with a "401 Unauthorized" 2019 response, and include a WWW-Authenticate challenge header that 2020 defines the authentication scheme to be used. The client then 2021 retries the request with an Authorization header appropriate to the 2022 specified authentication scheme. 2023 2024 There are four options for proxy authentication, Basic, Digest, NTLM 2025 and Negotiate (SPNEGO). The first two options were defined in 2026 RFC2617 [RFC2617], and are stateless. The second two options were 2027 developed by Microsoft and specified in RFC4559 [RFC4559], and are 2028 stateful; otherwise known as multi-round authentication, or 2029 connection authentication. 2030 2031 3.2.3.1. Stateless Authentication 2032 2033 Stateless Authentication over SPDY is identical to how it is 2034 performed over HTTP. If multiple SPDY streams are concurrently sent 2035 to a single server, each will authenticate independently, similar to 2036 how two HTTP connections would independently authenticate to a proxy 2037 server. 2038 2039 3.2.3.2. Stateful Authentication 2040 2041 Unfortunately, the stateful authentication mechanisms were 2042 implemented and defined in a such a way that directly violates 2043 RFC2617 - they do not include a "realm" as part of the request. This 2044 is problematic in SPDY because it makes it impossible for a client to 2045 disambiguate two concurrent server authentication challenges. 2046 2047 2048 2049 2050 Belshe & Peon Expires August 4, 2012 [Page 36] 2051 2053 Internet-Draft SPDY Feb 2012 2054 2055 2056 To deal with this case, SPDY servers using Stateful Authentication 2057 MUST implement one of two changes: 2058 2059 Servers can add a "realm=<desired realm>" header so that the two 2060 authentication requests can be disambiguated and run concurrently. 2061 Unfortunately, given how these mechanisms work, this is probably 2062 not practical. 2063 2064 Upon sending the first stateful challenge response, the server 2065 MUST buffer and defer all further frames which are not part of 2066 completing the challenge until the challenge has completed. 2067 Completing the authentication challenge may take multiple round 2068 trips. Once the client receives a "401 Authenticate" response for 2069 a stateful authentication type, it MUST stop sending new requests 2070 to the server until the authentication has completed by receiving 2071 a non-401 response on at least one stream. 2072 2073 3.3. Server Push Transactions 2074 2075 SPDY enables a server to send multiple replies to a client for a 2076 single request. The rationale for this feature is that sometimes a 2077 server knows that it will need to send multiple resources in response 2078 to a single request. Without server push features, the client must 2079 first download the primary resource, then discover the secondary 2080 resource(s), and request them. Pushing of resources avoids the 2081 round-trip delay, but also creates a potential race where a server 2082 can be pushing content which a user-agent is in the process of 2083 requesting. The following mechanics attempt to prevent the race 2084 condition while enabling the performance benefit. 2085 2086 Browsers receiving a pushed response MUST validate that the server is 2087 authorized to push the URL using the browser same-origin [RFC6454] 2088 policy. For example, a SPDY connection to www.foo.com is generally 2089 not permitted to push a response for www.evil.com. 2090 2091 If the browser accepts a pushed response (e.g. it does not send a 2092 RST_STREAM), the browser MUST attempt to cache the pushed response in 2093 same way that it would cache any other response. This means 2094 validating the response headers and inserting into the disk cache. 2095 2096 Because pushed responses have no request, they have no request 2097 headers associated with them. At the framing layer, SPDY pushed 2098 streams contain an "associated-stream-id" which indicates the 2099 requested stream for which the pushed stream is related. The pushed 2100 stream inherits all of the headers from the associated-stream-id with 2101 the exception of ":host", ":scheme", and ":path", which are provided 2102 as part of the pushed response stream headers. The browser MUST 2103 store these inherited and implied request headers with the cached 2104 2105 2106 2107 Belshe & Peon Expires August 4, 2012 [Page 37] 2108 2110 Internet-Draft SPDY Feb 2012 2111 2112 2113 resource. 2114 2115 Implementation note: With server push, it is theoretically possible 2116 for servers to push unreasonable amounts of content or resources to 2117 the user-agent. Browsers MUST implement throttles to protect against 2118 unreasonable push attacks. 2119 2120 3.3.1. Server implementation 2121 2122 When the server intends to push a resource to the user-agent, it 2123 opens a new stream by sending a unidirectional SYN_STREAM. The 2124 SYN_STREAM MUST include an Associated-To-Stream-ID, and MUST set the 2125 FLAG_UNIDIRECTIONAL flag. The SYN_STREAM MUST include headers for 2126 ":scheme", ":host", ":path", which represent the URL for the resource 2127 being pushed. Subsequent headers may follow in HEADERS frames. The 2128 purpose of the association is so that the user-agent can 2129 differentiate which request induced the pushed stream; without it, if 2130 the user-agent had two tabs open to the same page, each pushing 2131 unique content under a fixed URL, the user-agent would not be able to 2132 differentiate the requests. 2133 2134 The Associated-To-Stream-ID must be the ID of an existing, open 2135 stream. The reason for this restriction is to have a clear endpoint 2136 for pushed content. If the user-agent requested a resource on stream 2137 11, the server replies on stream 11. It can push any number of 2138 additional streams to the client before sending a FLAG_FIN on stream 2139 11. However, once the originating stream is closed no further push 2140 streams may be associated with it. The pushed streams do not need to 2141 be closed (FIN set) before the originating stream is closed, they 2142 only need to be created before the originating stream closes. 2143 2144 It is illegal for a server to push a resource with the Associated-To- 2145 Stream-ID of 0. 2146 2147 To minimize race conditions with the client, the SYN_STREAM for the 2148 pushed resources MUST be sent prior to sending any content which 2149 could allow the client to discover the pushed resource and request 2150 it. 2151 2152 The server MUST only push resources which would have been returned 2153 from a GET request. 2154 2155 Note: If the server does not have all of the Name/Value Response 2156 headers available at the time it issues the HEADERS frame for the 2157 pushed resource, it may later use an additional HEADERS frame to 2158 augment the name/value pairs to be associated with the pushed stream. 2159 The subsequent HEADERS frame(s) must not contain a header for 2160 ':host', ':scheme', or ':path' (e.g. the server can't change the 2161 2162 2163 2164 Belshe & Peon Expires August 4, 2012 [Page 38] 2165 2167 Internet-Draft SPDY Feb 2012 2168 2169 2170 identity of the resource to be pushed). The HEADERS frame must not 2171 contain duplicate headers with a previously sent HEADERS frame. The 2172 server must send a HEADERS frame including the scheme/host/port 2173 headers before sending any data frames on the stream. 2174 2175 3.3.2. Client implementation 2176 2177 When fetching a resource the client has 3 possibilities: 2178 2179 the resource is not being pushed 2180 2181 the resource is being pushed, but the data has not yet arrived 2182 2183 the resource is being pushed, and the data has started to arrive 2184 2185 When a SYN_STREAM and HEADERS frame which contains an Associated-To- 2186 Stream-ID is received, the client must not issue GET requests for the 2187 resource in the pushed stream, and instead wait for the pushed stream 2188 to arrive. 2189 2190 If a client receives a server push stream with stream-id 0, it MUST 2191 issue a session error (Section 2.4.1) with the status code 2192 PROTOCOL_ERROR. 2193 2194 When a client receives a SYN_STREAM from the server without a the 2195 ':host', ':scheme', and ':path' headers in the Name/Value section, it 2196 MUST reply with a RST_STREAM with error code HTTP_PROTOCOL_ERROR. 2197 2198 To cancel individual server push streams, the client can issue a 2199 stream error (Section 2.4.2) with error code CANCEL. Upon receipt, 2200 the server MUST stop sending on this stream immediately (this is an 2201 Abrupt termination). 2202 2203 To cancel all server push streams related to a request, the client 2204 may issue a stream error (Section 2.4.2) with error code CANCEL on 2205 the associated-stream-id. By cancelling that stream, the server MUST 2206 immediately stop sending frames for any streams with 2207 in-association-to for the original stream. 2208 2209 If the server sends a HEADER frame containing duplicate headers with 2210 a previous HEADERS frame for the same stream, the client must issue a 2211 stream error (Section 2.4.2) with error code PROTOCOL ERROR. 2212 2213 If the server sends a HEADERS frame after sending a data frame for 2214 the same stream, the client MAY ignore the HEADERS frame. Ignoring 2215 the HEADERS frame after a data frame prevents handling of HTTP's 2216 trailing headers 2217 (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.40). 2218 2219 2220 2221 Belshe & Peon Expires August 4, 2012 [Page 39] 2222 2224 Internet-Draft SPDY Feb 2012 2225 2226 2227 4. Design Rationale and Notes 2228 2229 Authors' notes: The notes in this section have no bearing on the SPDY 2230 protocol as specified within this document, and none of these notes 2231 should be considered authoritative about how the protocol works. 2232 However, these notes may prove useful in future debates about how to 2233 resolve protocol ambiguities or how to evolve the protocol going 2234 forward. They may be removed before the final draft. 2235 2236 4.1. Separation of Framing Layer and Application Layer 2237 2238 Readers may note that this specification sometimes blends the framing 2239 layer (Section 2) with requirements of a specific application - HTTP 2240 (Section 3). This is reflected in the request/response nature of the 2241 streams, the definition of the HEADERS and compression contexts which 2242 are very similar to HTTP, and other areas as well. 2243 2244 This blending is intentional - the primary goal of this protocol is 2245 to create a low-latency protocol for use with HTTP. Isolating the 2246 two layers is convenient for description of the protocol and how it 2247 relates to existing HTTP implementations. However, the ability to 2248 reuse the SPDY framing layer is a non goal. 2249 2250 4.2. Error handling - Framing Layer 2251 2252 Error handling at the SPDY layer splits errors into two groups: Those 2253 that affect an individual SPDY stream, and those that do not. 2254 2255 When an error is confined to a single stream, but general framing is 2256 in tact, SPDY attempts to use the RST_STREAM as a mechanism to 2257 invalidate the stream but move forward without aborting the 2258 connection altogether. 2259 2260 For errors occuring outside of a single stream context, SPDY assumes 2261 the entire session is hosed. In this case, the endpoint detecting 2262 the error should initiate a connection close. 2263 2264 4.3. One Connection Per Domain 2265 2266 SPDY attempts to use fewer connections than other protocols have 2267 traditionally used. The rationale for this behavior is because it is 2268 very difficult to provide a consistent level of service (e.g. TCP 2269 slow-start), prioritization, or optimal compression when the client 2270 is connecting to the server through multiple channels. 2271 2272 Through lab measurements, we have seen consistent latency benefits by 2273 using fewer connections from the client. The overall number of 2274 packets sent by SPDY can be as much as 40% less than HTTP. Handling 2275 2276 2277 2278 Belshe & Peon Expires August 4, 2012 [Page 40] 2279 2281 Internet-Draft SPDY Feb 2012 2282 2283 2284 large numbers of concurrent connections on the server also does 2285 become a scalability problem, and SPDY reduces this load. 2286 2287 The use of multiple connections is not without benefit, however. 2288 Because SPDY multiplexes multiple, independent streams onto a single 2289 stream, it creates a potential for head-of-line blocking problems at 2290 the transport level. In tests so far, the negative effects of head- 2291 of-line blocking (especially in the presence of packet loss) is 2292 outweighed by the benefits of compression and prioritization. 2293 2294 4.4. Fixed vs Variable Length Fields 2295 2296 SPDY favors use of fixed length 32bit fields in cases where smaller, 2297 variable length encodings could have been used. To some, this seems 2298 like a tragic waste of bandwidth. SPDY choses the simple encoding 2299 for speed and simplicity. 2300 2301 The goal of SPDY is to reduce latency on the network. The overhead 2302 of SPDY frames is generally quite low. Each data frame is only an 8 2303 byte overhead for a 1452 byte payload (~0.6%). At the time of this 2304 writing, bandwidth is already plentiful, and there is a strong trend 2305 indicating that bandwidth will continue to increase. With an average 2306 worldwide bandwidth of 1Mbps, and assuming that a variable length 2307 encoding could reduce the overhead by 50%, the latency saved by using 2308 a variable length encoding would be less than 100 nanoseconds. More 2309 interesting are the effects when the larger encodings force a packet 2310 boundary, in which case a round-trip could be induced. However, by 2311 addressing other aspects of SPDY and TCP interactions, we believe 2312 this is completely mitigated. 2313 2314 4.5. Compression Context(s) 2315 2316 When isolating the compression contexts used for communicating with 2317 multiple origins, we had a few choices to make. We could have 2318 maintained a map (or list) of compression contexts usable for each 2319 origin. The basic case is easy - each HEADERS frame would need to 2320 identify the context to use for that frame. However, compression 2321 contexts are not cheap, so the lifecycle of each context would need 2322 to be bounded. For proxy servers, where we could churn through many 2323 contexts, this would be a concern. We considered using a static set 2324 of contexts, say 16 of them, which would bound the memory use. We 2325 also considered dynamic contexts, which could be created on the fly, 2326 and would need to be subsequently destroyed. All of these are 2327 complicated, and ultimately we decided that such a mechanism creates 2328 too many problems to solve. 2329 2330 Alternatively, we've chosen the simple approach, which is to simply 2331 provide a flag for resetting the compression context. For the common 2332 2333 2334 2335 Belshe & Peon Expires August 4, 2012 [Page 41] 2336 2338 Internet-Draft SPDY Feb 2012 2339 2340 2341 case (no proxy), this fine because most requests are to the same 2342 origin and we never need to reset the context. For cases where we 2343 are using two different origins over a single SPDY session, we simply 2344 reset the compression state between each transition. 2345 2346 4.6. Unidirectional streams 2347 2348 Many readers notice that unidirectional streams are both a bit 2349 confusing in concept and also somewhat redundant. If the recipient 2350 of a stream doesn't wish to send data on a stream, it could simply 2351 send a SYN_REPLY with the FLAG_FIN bit set. The FLAG_UNIDIRECTIONAL 2352 is, therefore, not necessary. 2353 2354 It is true that we don't need the UNIDIRECTIONAL markings. It is 2355 added because it avoids the recipient of pushed streams from needing 2356 to send a set of empty frames (e.g. the SYN_STREAM w/ FLAG_FIN) which 2357 otherwise serve no purpose. 2358 2359 4.7. Data Compression 2360 2361 Generic compression of data portion of the streams (as opposed to 2362 compression of the headers) without knowing the content of the stream 2363 is redundant. There is no value in compressing a stream which is 2364 already compressed. Because of this, SPDY does allow data 2365 compression to be optional. We included it because study of existing 2366 websites shows that many sites are not using compression as they 2367 should, and users suffer because of it. We wanted a mechanism where, 2368 at the SPDY layer, site administrators could simply force compression 2369 - it is better to compress twice than to not compress. 2370 2371 Overall, however, with this feature being optional and sometimes 2372 redundant, it is unclear if it is useful at all. We will likely 2373 remove it from the specification. 2374 2375 4.8. Server Push 2376 2377 A subtle but important point is that server push streams must be 2378 declared before the associated stream is closed. The reason for this 2379 is so that proxies have a lifetime for which they can discard 2380 information about previous streams. If a pushed stream could 2381 associate itself with an already-closed stream, then endpoints would 2382 not have a specific lifecycle for when they could disavow knowledge 2383 of the streams which went before. 2384 2385 2386 2387 2388 2389 2390 2391 2392 Belshe & Peon Expires August 4, 2012 [Page 42] 2393 2395 Internet-Draft SPDY Feb 2012 2396 2397 2398 5. Security Considerations 2399 2400 5.1. Use of Same-origin constraints 2401 2402 This specification uses the same-origin policy [RFC6454] in all cases 2403 where verification of content is required. 2404 2405 5.2. HTTP Headers and SPDY Headers 2406 2407 At the application level, HTTP uses name/value pairs in its headers. 2408 Because SPDY merges the existing HTTP headers with SPDY headers, 2409 there is a possibility that some HTTP applications already use a 2410 particular header name. To avoid any conflicts, all headers 2411 introduced for layering HTTP over SPDY are prefixed with ":". ":" is 2412 not a valid sequence in HTTP header naming, preventing any possible 2413 conflict. 2414 2415 5.3. Cross-Protocol Attacks 2416 2417 By utilizing TLS, we believe that SPDY introduces no new cross- 2418 protocol attacks. TLS encrypts the contents of all transmission 2419 (except the handshake itself), making it difficult for attackers to 2420 control the data which could be used in a cross-protocol attack. 2421 2422 5.4. Server Push Implicit Headers 2423 2424 Pushed resources do not have an associated request. In order for 2425 existing HTTP cache control validations (such as the Vary header) to 2426 work, however, all cached resources must have a set of request 2427 headers. For this reason, browsers MUST be careful to inherit 2428 request headers from the associated stream for the push. This 2429 includes the 'Cookie' header. 2430 2431 2432 2433 2434 2435 2436 2437 2438 2439 2440 2441 2442 2443 2444 2445 2446 2447 2448 2449 Belshe & Peon Expires August 4, 2012 [Page 43] 2450 2452 Internet-Draft SPDY Feb 2012 2453 2454 2455 6. Privacy Considerations 2456 2457 6.1. Long Lived Connections 2458 2459 SPDY aims to keep connections open longer between clients and servers 2460 in order to reduce the latency when a user makes a request. The 2461 maintenance of these connections over time could be used to expose 2462 private information. For example, a user using a browser hours after 2463 the previous user stopped using that browser may be able to learn 2464 about what the previous user was doing. This is a problem with HTTP 2465 in its current form as well, however the short lived connections make 2466 it less of a risk. 2467 2468 6.2. SETTINGS frame 2469 2470 The SPDY SETTINGS frame allows servers to store out-of-band 2471 transmitted information about the communication between client and 2472 server on the client. Although this is intended only to be used to 2473 reduce latency, renegade servers could use it as a mechanism to store 2474 identifying information about the client in future requests. 2475 2476 Clients implementing privacy modes, such as Google Chrome's 2477 "incognito mode", may wish to disable client-persisted SETTINGS 2478 storage. 2479 2480 Clients MUST clear persisted SETTINGS information when clearing the 2481 cookies. 2482 2483 TODO: Put range maximums on each type of setting to limit 2484 inappropriate uses. 2485 2486 2487 2488 2489 2490 2491 2492 2493 2494 2495 2496 2497 2498 2499 2500 2501 2502 2503 2504 2505 2506 Belshe & Peon Expires August 4, 2012 [Page 44] 2507 2509 Internet-Draft SPDY Feb 2012 2510 2511 2512 7. Incompatibilities with SPDY draft #2 2513 2514 Here is a list of the major changes between this draft and draft #2. 2515 2516 Addition of flow control 2517 2518 Increased 16 bit length fields in SYN_STREAM and SYN_REPLY to 32 2519 bits. 2520 2521 Changed definition of compression for DATA frames 2522 2523 Updated compression dictionary 2524 2525 Fixed off-by-one on the compression dictionary for headers 2526 2527 Increased priority field from 2bits to 3bits. 2528 2529 Removed NOOP frame 2530 2531 Split the request "url" into "scheme", "host", and "path" 2532 2533 Added the requirement that POSTs contain content-length. 2534 2535 Removed wasted 16bits of unused space from the end of the 2536 SYN_REPLY and HEADERS frames. 2537 2538 Fixed bug: Priorities were described backward (0 was lowest 2539 instead of highest). 2540 2541 Fixed bug: Name/Value header counts were duplicated in both the 2542 Name Value header block and also the containing frame. 2543 2544 2545 2546 2547 2548 2549 2550 2551 2552 2553 2554 2555 2556 2557 2558 2559 2560 2561 2562 2563 Belshe & Peon Expires August 4, 2012 [Page 45] 2564 2566 Internet-Draft SPDY Feb 2012 2567 2568 2569 8. Requirements Notation 2570 2571 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 2572 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 2573 document are to be interpreted as described in RFC 2119 [RFC2119]. 2574 2575 2576 2577 2578 2579 2580 2581 2582 2583 2584 2585 2586 2587 2588 2589 2590 2591 2592 2593 2594 2595 2596 2597 2598 2599 2600 2601 2602 2603 2604 2605 2606 2607 2608 2609 2610 2611 2612 2613 2614 2615 2616 2617 2618 2619 2620 Belshe & Peon Expires August 4, 2012 [Page 46] 2621 2623 Internet-Draft SPDY Feb 2012 2624 2625 2626 9. Acknowledgements 2627 2628 Many individuals have contributed to the design and evolution of 2629 SPDY: Adam Langley, Wan-Teh Chang, Jim Morrison, Mark Nottingham, 2630 Alyssa Wilk, Costin Manolache, William Chan, Vitaliy Lvin, Joe Chan, 2631 Adam Barth, Ryan Hamilton, Gavin Peters, Kent Alstad, Kevin Lindsay, 2632 Paul Amer, Fan Yang, Jonathan Leighton 2633 2634 2635 2636 2637 2638 2639 2640 2641 2642 2643 2644 2645 2646 2647 2648 2649 2650 2651 2652 2653 2654 2655 2656 2657 2658 2659 2660 2661 2662 2663 2664 2665 2666 2667 2668 2669 2670 2671 2672 2673 2674 2675 2676 2677 Belshe & Peon Expires August 4, 2012 [Page 47] 2678 2680 Internet-Draft SPDY Feb 2012 2681 2682 2683 10. Normative References 2684 2685 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 2686 RFC 793, September 1981. 2687 2688 [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform 2689 Resource Locators (URL)", RFC 1738, December 1994. 2690 2691 [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format 2692 Specification version 3.3", RFC 1950, May 1996. 2693 2694 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2695 Requirement Levels", BCP 14, RFC 2119, March 1997. 2696 2697 [RFC2285] Mandeville, R., "Benchmarking Terminology for LAN 2698 Switching Devices", RFC 2285, February 1998. 2699 2700 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 2701 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 2702 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 2703 2704 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 2705 Leach, P., Luotonen, A., and L. Stewart, "HTTP 2706 Authentication: Basic and Digest Access Authentication", 2707 RFC 2617, June 1999. 2708 2709 [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based 2710 Kerberos and NTLM HTTP Authentication in Microsoft 2711 Windows", RFC 4559, June 2006. 2712 2713 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 2714 and T. Wright, "Transport Layer Security (TLS) 2715 Extensions", RFC 4366, April 2006. 2716 2717 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2718 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 2719 2720 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 2721 December 2011. 2722 2723 [TLSNPN] Langley, A., "TLS Next Protocol Negotiation", 2724 <http://tools.ietf.org/html/ 2725 draft-agl-tls-nextprotoneg-01>. 2726 2727 [ASCII] "US-ASCII. Coded Character Set - 7-Bit American Standard 2728 Code for Information Interchange. Standard ANSI X3.4-1986, 2729 ANSI, 1986.". 2730 2731 2732 2733 2734 Belshe & Peon Expires August 4, 2012 [Page 48] 2735 2737 Internet-Draft SPDY Feb 2012 2738 2739 2740 [UDELCOMPRESSION] 2741 Yang, F., Amer, P., and J. Leighton, "A Methodology to 2742 Derive SPDY's Initial Dictionary for Zlib Compression", 2743 <http://www.eecis.udel.edu/~amer/PEL/poc/pdf/ 2744 SPDY-Fan.pdf>. 2745 2746 2747 2748 2749 2750 2751 2752 2753 2754 2755 2756 2757 2758 2759 2760 2761 2762 2763 2764 2765 2766 2767 2768 2769 2770 2771 2772 2773 2774 2775 2776 2777 2778 2779 2780 2781 2782 2783 2784 2785 2786 2787 2788 2789 2790 2791 Belshe & Peon Expires August 4, 2012 [Page 49] 2792 2794 Internet-Draft SPDY Feb 2012 2795 2796 2797 Appendix A. Changes 2798 2799 To be removed by RFC Editor before publication 2800 2801 2802 2803 2804 2805 2806 2807 2808 2809 2810 2811 2812 2813 2814 2815 2816 2817 2818 2819 2820 2821 2822 2823 2824 2825 2826 2827 2828 2829 2830 2831 2832 2833 2834 2835 2836 2837 2838 2839 2840 2841 2842 2843 2844 2845 2846 2847 2848 Belshe & Peon Expires August 4, 2012 [Page 50] 2849 2851 Internet-Draft SPDY Feb 2012 2852 2853 2854 Authors' Addresses 2855 2856 Mike Belshe 2857 Twist 2858 2859 Email: mbelshe (a] chromium.org 2860 2861 2862 Roberto Peon 2863 Google, Inc 2864 2865 Email: fenix (a] google.com 2866 2867 2868 2869 2870 2871 2872 2873 2874 2875 2876 2877 2878 2879 2880 2881 2882 2883 2884 2885 2886 2887 2888 2889 2890 2891 2892 2893 2894 2895 2896 2897 2898 2899 2900 2901 2902 2903 2904 2905 Belshe & Peon Expires August 4, 2012 [Page 51] 2906 2908
