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