[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[GNUnet-SVN] r27281 - in libmicrohttpd: doc src src/datadir
|
From: |
gnunet |
|
Subject: |
[GNUnet-SVN] r27281 - in libmicrohttpd: doc src src/datadir |
|
Date: |
Fri, 24 May 2013 10:50:24 +0200 |
Author: grothoff
Date: 2013-05-24 10:50:24 +0200 (Fri, 24 May 2013)
New Revision: 27281
Added:
libmicrohttpd/src/datadir/spdy-draft.txt
Removed:
libmicrohttpd/doc/spdy-draft.txt
Modified:
libmicrohttpd/doc/Makefile.am
libmicrohttpd/src/Makefile.am
Log:
-move spdy draft so that testcases can find it
Modified: libmicrohttpd/doc/Makefile.am
===================================================================
--- libmicrohttpd/doc/Makefile.am 2013-05-24 07:57:26 UTC (rev 27280)
+++ libmicrohttpd/doc/Makefile.am 2013-05-24 08:50:24 UTC (rev 27281)
@@ -25,5 +25,5 @@
lgpl.texi \
ecos.texi
-EXTRA_DIST = $(man_MANS) Doxyfile $(microhttpd_TEXINFOS) spdy-draft.txt
+EXTRA_DIST = $(man_MANS) Doxyfile $(microhttpd_TEXINFOS)
Deleted: libmicrohttpd/doc/spdy-draft.txt
===================================================================
--- libmicrohttpd/doc/spdy-draft.txt 2013-05-24 07:57:26 UTC (rev 27280)
+++ libmicrohttpd/doc/spdy-draft.txt 2013-05-24 08:50:24 UTC (rev 27281)
@@ -1,2856 +0,0 @@
-
-
-
-Network Working Group M. Belshe
-Internet-Draft Twist
-Expires: August 4, 2012 R. Peon
- Google, Inc
- Feb 2012
-
-
- SPDY Protocol
- draft-mbelshe-httpbis-spdy-00
-
-Abstract
-
- This document describes SPDY, a protocol designed for low-latency
- transport of content over the World Wide Web. SPDY introduces two
- layers of protocol. The lower layer is a general purpose framing
- layer which can be used atop a reliable transport (likely TCP) for
- multiplexed, prioritized, and compressed data communication of many
- concurrent streams. The upper layer of the protocol provides HTTP-
- like RFC2616 [RFC2616] semantics for compatibility with existing HTTP
- application servers.
-
-Status of this Memo
-
- This Internet-Draft is submitted in full conformance with the
- provisions of BCP 78 and BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF). Note that other groups may also distribute
- working documents as Internet-Drafts. The list of current Internet-
- Drafts is at http://datatracker.ietf.org/drafts/current/.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- This Internet-Draft will expire on August 4, 2012.
-
-Copyright Notice
-
- Copyright (c) 2012 IETF Trust and the persons identified as the
- document authors. All rights reserved.
-
- This document is subject to BCP 78 and the IETF Trust's Legal
- Provisions Relating to IETF Documents
- (http://trustee.ietf.org/license-info) in effect on the date of
- publication of this document. Please review these documents
- carefully, as they describe your rights and restrictions with respect
-
-
-
-Belshe & Peon Expires August 4, 2012 [Page 1]
-
-Internet-Draft SPDY Feb 2012
-
-
- to this document. Code Components extracted from this document must
- include Simplified BSD License text as described in Section 4.e of
- the Trust Legal Provisions and are provided without warranty as
- described in the Simplified BSD License.
-
-
-Table of Contents
-
- 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
- 1.1. Document Organization . . . . . . . . . . . . . . . . . . 4
- 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
- 2. SPDY Framing Layer . . . . . . . . . . . . . . . . . . . . . . 6
- 2.1. Session (Connections) . . . . . . . . . . . . . . . . . . 6
- 2.2. Framing . . . . . . . . . . . . . . . . . . . . . . . . . 6
- 2.2.1. Control frames . . . . . . . . . . . . . . . . . . . . 6
- 2.2.2. Data frames . . . . . . . . . . . . . . . . . . . . . 7
- 2.3. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 8
- 2.3.1. Stream frames . . . . . . . . . . . . . . . . . . . . 9
- 2.3.2. Stream creation . . . . . . . . . . . . . . . . . . . 9
- 2.3.3. Stream priority . . . . . . . . . . . . . . . . . . . 10
- 2.3.4. Stream headers . . . . . . . . . . . . . . . . . . . . 10
- 2.3.5. Stream data exchange . . . . . . . . . . . . . . . . . 10
- 2.3.6. Stream half-close . . . . . . . . . . . . . . . . . . 10
- 2.3.7. Stream close . . . . . . . . . . . . . . . . . . . . . 11
- 2.4. Error Handling . . . . . . . . . . . . . . . . . . . . . . 11
- 2.4.1. Session Error Handling . . . . . . . . . . . . . . . . 11
- 2.4.2. Stream Error Handling . . . . . . . . . . . . . . . . 12
- 2.5. Data flow . . . . . . . . . . . . . . . . . . . . . . . . 12
- 2.6. Control frame types . . . . . . . . . . . . . . . . . . . 12
- 2.6.1. SYN_STREAM . . . . . . . . . . . . . . . . . . . . . . 12
- 2.6.2. SYN_REPLY . . . . . . . . . . . . . . . . . . . . . . 14
- 2.6.3. RST_STREAM . . . . . . . . . . . . . . . . . . . . . . 15
- 2.6.4. SETTINGS . . . . . . . . . . . . . . . . . . . . . . . 16
- 2.6.5. PING . . . . . . . . . . . . . . . . . . . . . . . . . 19
- 2.6.6. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . . 20
- 2.6.7. HEADERS . . . . . . . . . . . . . . . . . . . . . . . 21
- 2.6.8. WINDOW_UPDATE . . . . . . . . . . . . . . . . . . . . 22
- 2.6.9. CREDENTIAL . . . . . . . . . . . . . . . . . . . . . . 24
- 2.6.10. Name/Value Header Block . . . . . . . . . . . . . . . 26
- 3. HTTP Layering over SPDY . . . . . . . . . . . . . . . . . . . 33
- 3.1. Connection Management . . . . . . . . . . . . . . . . . . 33
- 3.1.1. Use of GOAWAY . . . . . . . . . . . . . . . . . . . . 33
- 3.2. HTTP Request/Response . . . . . . . . . . . . . . . . . . 34
- 3.2.1. Request . . . . . . . . . . . . . . . . . . . . . . . 34
- 3.2.2. Response . . . . . . . . . . . . . . . . . . . . . . . 35
- 3.2.3. Authentication . . . . . . . . . . . . . . . . . . . . 36
- 3.3. Server Push Transactions . . . . . . . . . . . . . . . . . 37
- 3.3.1. Server implementation . . . . . . . . . . . . . . . . 38
-
-
-
-Belshe & Peon Expires August 4, 2012 [Page 2]
-
-Internet-Draft SPDY Feb 2012
-
-
- 3.3.2. Client implementation . . . . . . . . . . . . . . . . 39
- 4. Design Rationale and Notes . . . . . . . . . . . . . . . . . . 40
- 4.1. Separation of Framing Layer and Application Layer . . . . 40
- 4.2. Error handling - Framing Layer . . . . . . . . . . . . . . 40
- 4.3. One Connection Per Domain . . . . . . . . . . . . . . . . 40
- 4.4. Fixed vs Variable Length Fields . . . . . . . . . . . . . 41
- 4.5. Compression Context(s) . . . . . . . . . . . . . . . . . . 41
- 4.6. Unidirectional streams . . . . . . . . . . . . . . . . . . 42
- 4.7. Data Compression . . . . . . . . . . . . . . . . . . . . . 42
- 4.8. Server Push . . . . . . . . . . . . . . . . . . . . . . . 42
- 5. Security Considerations . . . . . . . . . . . . . . . . . . . 43
- 5.1. Use of Same-origin constraints . . . . . . . . . . . . . . 43
- 5.2. HTTP Headers and SPDY Headers . . . . . . . . . . . . . . 43
- 5.3. Cross-Protocol Attacks . . . . . . . . . . . . . . . . . . 43
- 5.4. Server Push Implicit Headers . . . . . . . . . . . . . . . 43
- 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 44
- 6.1. Long Lived Connections . . . . . . . . . . . . . . . . . . 44
- 6.2. SETTINGS frame . . . . . . . . . . . . . . . . . . . . . . 44
- 7. Incompatibilities with SPDY draft #2 . . . . . . . . . . . . . 45
- 8. Requirements Notation . . . . . . . . . . . . . . . . . . . . 46
- 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 47
- 10. Normative References . . . . . . . . . . . . . . . . . . . . . 48
- Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 50
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Belshe & Peon Expires August 4, 2012 [Page 3]
-
-Internet-Draft SPDY Feb 2012
-
-
-1. Overview
-
- One of the bottlenecks of HTTP implementations is that HTTP relies on
- multiple connections for concurrency. This causes several problems,
- including additional round trips for connection setup, slow-start
- delays, and connection rationing by the client, where it tries to
- avoid opening too many connections to any single server. HTTP
- pipelining helps some, but only achieves partial multiplexing. In
- addition, pipelining has proven non-deployable in existing browsers
- due to intermediary interference.
-
- SPDY adds a framing layer for multiplexing multiple, concurrent
- streams across a single TCP connection (or any reliable transport
- stream). The framing layer is optimized for HTTP-like request-
- response streams, such that applications which run over HTTP today
- can work over SPDY with little or no change on behalf of the web
- application writer.
-
- The SPDY session offers four improvements over HTTP:
-
- Multiplexed requests: There is no limit to the number of requests
- that can be issued concurrently over a single SPDY connection.
-
- Prioritized requests: Clients can request certain resources to be
- delivered first. This avoids the problem of congesting the
- network channel with non-critical resources when a high-priority
- request is pending.
-
- Compressed headers: Clients today send a significant amount of
- redundant data in the form of HTTP headers. Because a single web
- page may require 50 or 100 subrequests, this data is significant.
-
- Server pushed streams: Server Push enables content to be pushed
- from servers to clients without a request.
-
- SPDY attempts to preserve the existing semantics of HTTP. All
- features such as cookies, ETags, Vary headers, Content-Encoding
- negotiations, etc work as they do with HTTP; SPDY only replaces the
- way the data is written to the network.
-
-1.1. Document Organization
-
- The SPDY Specification is split into two parts: a framing layer
- (Section 2), which multiplexes a TCP connection into independent,
- length-prefixed frames, and an HTTP layer (Section 3), which
- specifies the mechanism for overlaying HTTP request/response pairs on
- top of the framing layer. While some of the framing layer concepts
- are isolated from the HTTP layer, building a generic framing layer
-
-
-
-Belshe & Peon Expires August 4, 2012 [Page 4]
-
-Internet-Draft SPDY Feb 2012
-
-
- has not been a goal. The framing layer is tailored to the needs of
- the HTTP protocol and server push.
-
-1.2. Definitions
-
- client: The endpoint initiating the SPDY session.
-
- connection: A transport-level connection between two endpoints.
-
- endpoint: Either the client or server of a connection.
-
- frame: A header-prefixed sequence of bytes sent over a SPDY
- session.
-
- server: The endpoint which did not initiate the SPDY session.
-
- session: A synonym for a connection.
-
- session error: An error on the SPDY session.
-
- stream: A bi-directional flow of bytes across a virtual channel
- within a SPDY session.
-
- stream error: An error on an individual SPDY stream.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Belshe & Peon Expires August 4, 2012 [Page 5]
-
-Internet-Draft SPDY Feb 2012
-
-
-2. SPDY Framing Layer
-
-2.1. Session (Connections)
-
- The SPDY framing layer (or "session") runs atop a reliable transport
- layer such as TCP [RFC0793]. The client is the TCP connection
- initiator. SPDY connections are persistent connections.
-
- For best performance, it is expected that clients will not close open
- connections until the user navigates away from all web pages
- referencing a connection, or until the server closes the connection.
- Servers are encouraged to leave connections open for as long as
- possible, but can terminate idle connections if necessary. When
- either endpoint closes the transport-level connection, it MUST first
- send a GOAWAY (Section 2.6.6) frame so that the endpoints can
- reliably determine if requests finished before the close.
-
-2.2. Framing
-
- Once the connection is established, clients and servers exchange
- framed messages. There are two types of frames: control frames
- (Section 2.2.1) and data frames (Section 2.2.2). Frames always have
- a common header which is 8 bytes in length.
-
- The first bit is a control bit indicating whether a frame is a
- control frame or data frame. Control frames carry a version number,
- a frame type, flags, and a length. Data frames contain the stream
- ID, flags, and the length for the payload carried after the common
- header. The simple header is designed to make reading and writing of
- frames easy.
-
- All integer values, including length, version, and type, are in
- network byte order. SPDY does not enforce alignment of types in
- dynamically sized frames.
-
-2.2.1. Control frames
-
- +----------------------------------+
- |C| Version(15bits) | Type(16bits) |
- +----------------------------------+
- | Flags (8) | Length (24 bits) |
- +----------------------------------+
- | Data |
- +----------------------------------+
-
- Control bit: The 'C' bit is a single bit indicating if this is a
- control message. For control frames this value is always 1.
-
-
-
-
-Belshe & Peon Expires August 4, 2012 [Page 6]
-
-Internet-Draft SPDY Feb 2012
-
-
- Version: The version number of the SPDY protocol. This document
- describes SPDY version 3.
-
- Type: The type of control frame. See Control Frames for the complete
- list of control frames.
-
- Flags: Flags related to this frame. Flags for control frames and
- data frames are different.
-
- Length: An unsigned 24-bit value representing the number of bytes
- after the length field.
-
- Data: data associated with this control frame. The format and length
- of this data is controlled by the control frame type.
-
- Control frame processing requirements:
-
- Note that full length control frames (16MB) can be large for
- implementations running on resource-limited hardware. In such
- cases, implementations MAY limit the maximum length frame
- supported. However, all implementations MUST be able to receive
- control frames of at least 8192 octets in length.
-
-2.2.2. Data frames
-
- +----------------------------------+
- |C| Stream-ID (31bits) |
- +----------------------------------+
- | Flags (8) | Length (24 bits) |
- +----------------------------------+
- | Data |
- +----------------------------------+
-
- Control bit: For data frames this value is always 0.
-
- Stream-ID: A 31-bit value identifying the stream.
-
- Flags: Flags related to this frame. Valid flags are:
-
- 0x01 = FLAG_FIN - signifies that this frame represents the last
- frame to be transmitted on this stream. See Stream Close
- (Section 2.3.7) below.
-
- 0x02 = FLAG_COMPRESS - indicates that the data in this frame has
- been compressed.
-
- Length: An unsigned 24-bit value representing the number of bytes
- after the length field. The total size of a data frame is 8 bytes +
-
-
-
-Belshe & Peon Expires August 4, 2012 [Page 7]
-
-Internet-Draft SPDY Feb 2012
-
-
- length. It is valid to have a zero-length data frame.
-
- Data: The variable-length data payload; the length was defined in the
- length field.
-
- Data frame processing requirements:
-
- If an endpoint receives a data frame for a stream-id which is not
- open and the endpoint has not sent a GOAWAY (Section 2.6.6) frame,
- it MUST send issue a stream error (Section 2.4.2) with the error
- code INVALID_STREAM for the stream-id.
-
- If the endpoint which created the stream receives a data frame
- before receiving a SYN_REPLY on that stream, it is a protocol
- error, and the recipient MUST issue a stream error (Section 2.4.2)
- with the status code PROTOCOL_ERROR for the stream-id.
-
- Implementors note: If an endpoint receives multiple data frames
- for invalid stream-ids, it MAY close the session.
-
- All SPDY endpoints MUST accept compressed data frames.
- Compression of data frames is always done using zlib compression.
- Each stream initializes and uses its own compression context
- dedicated to use within that stream. Endpoints are encouraged to
- use application level compression rather than SPDY stream level
- compression.
-
- Each SPDY stream sending compressed frames creates its own zlib
- context for that stream, and these compression contexts MUST be
- distinct from the compression contexts used with SYN_STREAM/
- SYN_REPLY/HEADER compression. (Thus, if both endpoints of a
- stream are compressing data on the stream, there will be two zlib
- contexts, one for sending and one for receiving).
-
-2.3. Streams
-
- Streams are independent sequences of bi-directional data divided into
- frames with several properties:
-
- Streams may be created by either the client or server.
-
- Streams optionally carry a set of name/value header pairs.
-
- Streams can concurrently send data interleaved with other streams.
-
- Streams may be cancelled.
-
-
-
-
-
-Belshe & Peon Expires August 4, 2012 [Page 8]
-
-Internet-Draft SPDY Feb 2012
-
-
-2.3.1. Stream frames
-
- SPDY defines 3 control frames to manage the lifecycle of a stream:
-
- SYN_STREAM - Open a new stream
-
- SYN_REPLY - Remote acknowledgement of a new, open stream
-
- RST_STREAM - Close a stream
-
-2.3.2. Stream creation
-
- A stream is created by sending a control frame with the type set to
- SYN_STREAM (Section 2.6.1). If the server is initiating the stream,
- the Stream-ID must be even. If the client is initiating the stream,
- the Stream-ID must be odd. 0 is not a valid Stream-ID. Stream-IDs
- from each side of the connection must increase monotonically as new
- streams are created. E.g. Stream 2 may be created after stream 3,
- but stream 7 must not be created after stream 9. Stream IDs do not
- wrap: when a client or server cannot create a new stream id without
- exceeding a 31 bit value, it MUST NOT create a new stream.
-
- The stream-id MUST increase with each new stream. If an endpoint
- receives a SYN_STREAM with a stream id which is less than any
- previously received SYN_STREAM, it MUST issue a session error
- (Section 2.4.1) with the status PROTOCOL_ERROR.
-
- It is a protocol error to send two SYN_STREAMs with the same
- stream-id. If a recipient receives a second SYN_STREAM for the same
- stream, it MUST issue a stream error (Section 2.4.2) with the status
- code PROTOCOL_ERROR.
-
- Upon receipt of a SYN_STREAM, the recipient can reject the stream by
- sending a stream error (Section 2.4.2) with the error code
- REFUSED_STREAM. Note, however, that the creating endpoint may have
- already sent additional frames for that stream which cannot be
- immediately stopped.
-
- Once the stream is created, the creator may immediately send HEADERS
- or DATA frames for that stream, without needing to wait for the
- recipient to acknowledge.
-
-2.3.2.1. Unidirectional streams
-
- When an endpoint creates a stream with the FLAG_UNIDIRECTIONAL flag
- set, it creates a unidirectional stream which the creating endpoint
- can use to send frames, but the receiving endpoint cannot. The
- receiving endpoint is implicitly already in the half-closed
-
-
-
-Belshe & Peon Expires August 4, 2012 [Page 9]
-
-Internet-Draft SPDY Feb 2012
-
-
- (Section 2.3.6) state.
-
-2.3.2.2. Bidirectional streams
-
- SYN_STREAM frames which do not use the FLAG_UNIDIRECTIONAL flag are
- bidirectional streams. Both endpoints can send data on a bi-
- directional stream.
-
-2.3.3. Stream priority
-
- The creator of a stream assigns a priority for that stream. Priority
- is represented as an integer from 0 to 7. 0 represents the highest
- priority and 7 represents the lowest priority.
-
- The sender and recipient SHOULD use best-effort to process streams in
- the order of highest priority to lowest priority.
-
-2.3.4. Stream headers
-
- Streams carry optional sets of name/value pair headers which carry
- metadata about the stream. After the stream has been created, and as
- long as the sender is not closed (Section 2.3.7) or half-closed
- (Section 2.3.6), each side may send HEADERS frame(s) containing the
- header data. Header data can be sent in multiple HEADERS frames, and
- HEADERS frames may be interleaved with data frames.
-
-2.3.5. Stream data exchange
-
- Once a stream is created, it can be used to send arbitrary amounts of
- data. Generally this means that a series of data frames will be sent
- on the stream until a frame containing the FLAG_FIN flag is set. The
- FLAG_FIN can be set on a SYN_STREAM (Section 2.6.1), SYN_REPLY
- (Section 2.6.2), HEADERS (Section 2.6.7) or a DATA (Section 2.2.2)
- frame. Once the FLAG_FIN has been sent, the stream is considered to
- be half-closed.
-
-2.3.6. Stream half-close
-
- When one side of the stream sends a frame with the FLAG_FIN flag set,
- the stream is half-closed from that endpoint. The sender of the
- FLAG_FIN MUST NOT send further frames on that stream. When both
- sides have half-closed, the stream is closed.
-
- If an endpoint receives a data frame after the stream is half-closed
- from the sender (e.g. the endpoint has already received a prior frame
- for the stream with the FIN flag set), it MUST send a RST_STREAM to
- the sender with the status STREAM_ALREADY_CLOSED.
-
-
-
-
-Belshe & Peon Expires August 4, 2012 [Page 10]
-
-Internet-Draft SPDY Feb 2012
-
-
-2.3.7. Stream close
-
- There are 3 ways that streams can be terminated:
-
- Normal termination: Normal stream termination occurs when both
- sender and recipient have half-closed the stream by sending a
- FLAG_FIN.
-
- Abrupt termination: Either the client or server can send a
- RST_STREAM control frame at any time. A RST_STREAM contains an
- error code to indicate the reason for failure. When a RST_STREAM
- is sent from the stream originator, it indicates a failure to
- complete the stream and that no further data will be sent on the
- stream. When a RST_STREAM is sent from the stream recipient, the
- sender, upon receipt, should stop sending any data on the stream.
- The stream recipient should be aware that there is a race between
- data already in transit from the sender and the time the
- RST_STREAM is received. See Stream Error Handling (Section 2.4.2)
-
- TCP connection teardown: If the TCP connection is torn down while
- un-closed streams exist, then the endpoint must assume that the
- stream was abnormally interrupted and may be incomplete.
-
- If an endpoint receives a data frame after the stream is closed, it
- must send a RST_STREAM to the sender with the status PROTOCOL_ERROR.
-
-2.4. Error Handling
-
- The SPDY framing layer has only two types of errors, and they are
- always handled consistently. Any reference in this specification to
- "issue a session error" refers to Section 2.4.1. Any reference to
- "issue a stream error" refers to Section 2.4.2.
-
-2.4.1. Session Error Handling
-
- A session error is any error which prevents further processing of the
- framing layer or which corrupts the session compression state. When
- a session error occurs, the endpoint encountering the error MUST
- first send a GOAWAY (Section 2.6.6) frame with the stream id of most
- recently received stream from the remote endpoint, and the error code
- for why the session is terminating. After sending the GOAWAY frame,
- the endpoint MUST close the TCP connection.
-
- Note that the session compression state is dependent upon both
- endpoints always processing all compressed data. If an endpoint
- partially processes a frame containing compressed data without
- updating compression state properly, future control frames which use
- compression will be always be errored. Implementations SHOULD always
-
-
-
-Belshe & Peon Expires August 4, 2012 [Page 11]
-
-Internet-Draft SPDY Feb 2012
-
-
- try to process compressed data so that errors which could be handled
- as stream errors do not become session errors.
-
- Note that because this GOAWAY is sent during a session error case, it
- is possible that the GOAWAY will not be reliably received by the
- receiving endpoint. It is a best-effort attempt to communicate with
- the remote about why the session is going down.
-
-2.4.2. Stream Error Handling
-
- A stream error is an error related to a specific stream-id which does
- not affect processing of other streams at the framing layer. Upon a
- stream error, the endpoint MUST send a RST_STREAM (Section 2.6.3)
- frame which contains the stream id of the stream where the error
- occurred and the error status which caused the error. After sending
- the RST_STREAM, the stream is closed to the sending endpoint. After
- sending the RST_STREAM, if the sender receives any frames other than
- a RST_STREAM for that stream id, it will result in sending additional
- RST_STREAM frames. An endpoint MUST NOT send a RST_STREAM in
- response to an RST_STREAM, as doing so would lead to RST_STREAM
- loops. Sending a RST_STREAM does not cause the SPDY session to be
- closed.
-
- If an endpoint has multiple RST_STREAM frames to send in succession
- for the same stream-id and the same error code, it MAY coalesce them
- into a single RST_STREAM frame. (This can happen if a stream is
- closed, but the remote sends multiple data frames. There is no
- reason to send a RST_STREAM for each frame in succession).
-
-2.5. Data flow
-
- Because TCP provides a single stream of data on which SPDY
- multiplexes multiple logical streams, clients and servers must
- intelligently interleave data messages for concurrent sessions.
-
-2.6. Control frame types
-
-2.6.1. SYN_STREAM
-
- The SYN_STREAM control frame allows the sender to asynchronously
- create a stream between the endpoints. See Stream Creation
- (Section 2.3.2)
-
-
-
-
-
-
-
-
-
-Belshe & Peon Expires August 4, 2012 [Page 12]
-
-Internet-Draft SPDY Feb 2012
-
-
-+------------------------------------+
-|1| version | 1 |
-+------------------------------------+
-| Flags (8) | Length (24 bits) |
-+------------------------------------+
-|X| Stream-ID (31bits) |
-+------------------------------------+
-|X| Associated-To-Stream-ID (31bits) |
-+------------------------------------+
-| Pri|Unused | Slot | |
-+-------------------+ |
-| Number of Name/Value pairs (int32) | <+
-+------------------------------------+ |
-| Length of name (int32) | | This section is the "Name/Value
-+------------------------------------+ | Header Block", and is compressed.
-| Name (string) | |
-+------------------------------------+ |
-| Length of value (int32) | |
-+------------------------------------+ |
-| Value (string) | |
-+------------------------------------+ |
-| (repeats) | <+
-
- Flags: Flags related to this frame. Valid flags are:
-
- 0x01 = FLAG_FIN - marks this frame as the last frame to be
- transmitted on this stream and puts the sender in the half-closed
- (Section 2.3.6) state.
-
- 0x02 = FLAG_UNIDIRECTIONAL - a stream created with this flag puts
- the recipient in the half-closed (Section 2.3.6) state.
-
- Length: The length is the number of bytes which follow the length
- field in the frame. For SYN_STREAM frames, this is 10 bytes plus the
- length of the compressed Name/Value block.
-
- Stream-ID: The 31-bit identifier for this stream. This stream-id
- will be used in frames which are part of this stream.
-
- Associated-To-Stream-ID: The 31-bit identifier for a stream which
- this stream is associated to. If this stream is independent of all
- other streams, it should be 0.
-
- Priority: A 3-bit priority (Section 2.3.3) field.
-
- Unused: 5 bits of unused space, reserved for future use.
-
- Slot: An 8 bit unsigned integer specifying the index in the server's
-
-
-
-Belshe & Peon Expires August 4, 2012 [Page 13]
-
-Internet-Draft SPDY Feb 2012
-
-
- CREDENTIAL vector of the client certificate to be used for this
- request. see CREDENTIAL frame (Section 2.6.9). The value 0 means no
- client certificate should be associated with this stream.
-
- Name/Value Header Block: A set of name/value pairs carried as part of
- the SYN_STREAM. see Name/Value Header Block (Section 2.6.10).
-
- If an endpoint receives a SYN_STREAM which is larger than the
- implementation supports, it MAY send a RST_STREAM with error code
- FRAME_TOO_LARGE. All implementations MUST support the minimum size
- limits defined in the Control Frames section (Section 2.2.1).
-
-2.6.2. SYN_REPLY
-
- SYN_REPLY indicates the acceptance of a stream creation by the
- recipient of a SYN_STREAM frame.
-
-+------------------------------------+
-|1| version | 2 |
-+------------------------------------+
-| Flags (8) | Length (24 bits) |
-+------------------------------------+
-|X| Stream-ID (31bits) |
-+------------------------------------+
-| Number of Name/Value pairs (int32) | <+
-+------------------------------------+ |
-| Length of name (int32) | | This section is the "Name/Value
-+------------------------------------+ | Header Block", and is compressed.
-| Name (string) | |
-+------------------------------------+ |
-| Length of value (int32) | |
-+------------------------------------+ |
-| Value (string) | |
-+------------------------------------+ |
-| (repeats) | <+
-
- Flags: Flags related to this frame. Valid flags are:
-
- 0x01 = FLAG_FIN - marks this frame as the last frame to be
- transmitted on this stream and puts the sender in the half-closed
- (Section 2.3.6) state.
-
- Length: The length is the number of bytes which follow the length
- field in the frame. For SYN_REPLY frames, this is 4 bytes plus the
- length of the compressed Name/Value block.
-
- Stream-ID: The 31-bit identifier for this stream.
-
-
-
-
-Belshe & Peon Expires August 4, 2012 [Page 14]
-
-Internet-Draft SPDY Feb 2012
-
-
- If an endpoint receives multiple SYN_REPLY frames for the same active
- stream ID, it MUST issue a stream error (Section 2.4.2) with the
- error code STREAM_IN_USE.
-
- Name/Value Header Block: A set of name/value pairs carried as part of
- the SYN_STREAM. see Name/Value Header Block (Section 2.6.10).
-
- If an endpoint receives a SYN_REPLY which is larger than the
- implementation supports, it MAY send a RST_STREAM with error code
- FRAME_TOO_LARGE. All implementations MUST support the minimum size
- limits defined in the Control Frames section (Section 2.2.1).
-
-2.6.3. RST_STREAM
-
- The RST_STREAM frame allows for abnormal termination of a stream.
- When sent by the creator of a stream, it indicates the creator wishes
- to cancel the stream. When sent by the recipient of a stream, it
- indicates an error or that the recipient did not want to accept the
- stream, so the stream should be closed.
-
- +----------------------------------+
- |1| version | 3 |
- +----------------------------------+
- | Flags (8) | 8 |
- +----------------------------------+
- |X| Stream-ID (31bits) |
- +----------------------------------+
- | Status code |
- +----------------------------------+
-
- Flags: Flags related to this frame. RST_STREAM does not define any
- flags. This value must be 0.
-
- Length: An unsigned 24-bit value representing the number of bytes
- after the length field. For RST_STREAM control frames, this value is
- always 8.
-
- Stream-ID: The 31-bit identifier for this stream.
-
- Status code: (32 bits) An indicator for why the stream is being
- terminated.The following status codes are defined:
-
- 1 - PROTOCOL_ERROR. This is a generic error, and should only be
- used if a more specific error is not available.
-
- 2 - INVALID_STREAM. This is returned when a frame is received for
- a stream which is not active.
-
-
-
-
-Belshe & Peon Expires August 4, 2012 [Page 15]
-
-Internet-Draft SPDY Feb 2012
-
-
- 3 - REFUSED_STREAM. Indicates that the stream was refused before
- any processing has been done on the stream.
-
- 4 - UNSUPPORTED_VERSION. Indicates that the recipient of a stream
- does not support the SPDY version requested.
-
- 5 - CANCEL. Used by the creator of a stream to indicate that the
- stream is no longer needed.
-
- 6 - INTERNAL_ERROR. This is a generic error which can be used
- when the implementation has internally failed, not due to anything
- in the protocol.
-
- 7 - FLOW_CONTROL_ERROR. The endpoint detected that its peer
- violated the flow control protocol.
-
- 8 - STREAM_IN_USE. The endpoint received a SYN_REPLY for a stream
- already open.
-
- 9 - STREAM_ALREADY_CLOSED. The endpoint received a data or
- SYN_REPLY frame for a stream which is half closed.
-
- 10 - INVALID_CREDENTIALS. The server received a request for a
- resource whose origin does not have valid credentials in the
- client certificate vector.
-
- 11 - FRAME_TOO_LARGE. The endpoint received a frame which this
- implementation could not support. If FRAME_TOO_LARGE is sent for
- a SYN_STREAM, HEADERS, or SYN_REPLY frame without fully processing
- the compressed portion of those frames, then the compression state
- will be out-of-sync with the other endpoint. In this case,
- senders of FRAME_TOO_LARGE MUST close the session.
-
- Note: 0 is not a valid status code for a RST_STREAM.
-
- After receiving a RST_STREAM on a stream, the recipient must not send
- additional frames for that stream, and the stream moves into the
- closed state.
-
-2.6.4. SETTINGS
-
- A SETTINGS frame contains a set of id/value pairs for communicating
- configuration data about how the two endpoints may communicate.
- SETTINGS frames can be sent at any time by either endpoint, are
- optionally sent, and are fully asynchronous. When the server is the
- sender, the sender can request that configuration data be persisted
- by the client across SPDY sessions and returned to the server in
- future communications.
-
-
-
-Belshe & Peon Expires August 4, 2012 [Page 16]
-
-Internet-Draft SPDY Feb 2012
-
-
- Persistence of SETTINGS ID/Value pairs is done on a per origin/IP
- pair (the "origin" is the set of scheme, host, and port from the URI.
- See [RFC6454]). That is, when a client connects to a server, and the
- server persists settings within the client, the client SHOULD return
- the persisted settings on future connections to the same origin AND
- IP address and TCP port. Clients MUST NOT request servers to use the
- persistence features of the SETTINGS frames, and servers MUST ignore
- persistence related flags sent by a client.
-
- +----------------------------------+
- |1| version | 4 |
- +----------------------------------+
- | Flags (8) | Length (24 bits) |
- +----------------------------------+
- | Number of entries |
- +----------------------------------+
- | ID/Value Pairs |
- | ... |
-
- Control bit: The control bit is always 1 for this message.
-
- Version: The SPDY version number.
-
- Type: The message type for a SETTINGS message is 4.
-
- Flags: FLAG_SETTINGS_CLEAR_SETTINGS (0x1): When set, the client
- should clear any previously persisted SETTINGS ID/Value pairs. If
- this frame contains ID/Value pairs with the
- FLAG_SETTINGS_PERSIST_VALUE set, then the client will first clear its
- existing, persisted settings, and then persist the values with the
- flag set which are contained within this frame. Because persistence
- is only implemented on the client, this flag can only be used when
- the sender is the server.
-
- Length: An unsigned 24-bit value representing the number of bytes
- after the length field. The total size of a SETTINGS frame is 8
- bytes + length.
-
- Number of entries: A 32-bit value representing the number of ID/value
- pairs in this message.
-
- ID: A 32-bit ID number, comprised of 8 bits of flags and 24 bits of
- unique ID.
-
- ID.flags:
-
- FLAG_SETTINGS_PERSIST_VALUE (0x1): When set, the sender of this
- SETTINGS frame is requesting that the recipient persist the ID/
-
-
-
-Belshe & Peon Expires August 4, 2012 [Page 17]
-
-Internet-Draft SPDY Feb 2012
-
-
- Value and return it in future SETTINGS frames sent from the
- sender to this recipient. Because persistence is only
- implemented on the client, this flag is only sent by the
- server.
-
- FLAG_SETTINGS_PERSISTED (0x2): When set, the sender is
- notifying the recipient that this ID/Value pair was previously
- sent to the sender by the recipient with the
- FLAG_SETTINGS_PERSIST_VALUE, and the sender is returning it.
- Because persistence is only implemented on the client, this
- flag is only sent by the client.
-
- Defined IDs:
-
- 1 - SETTINGS_UPLOAD_BANDWIDTH allows the sender to send its
- expected upload bandwidth on this channel. This number is an
- estimate. The value should be the integral number of kilobytes
- per second that the sender predicts as an expected maximum
- upload channel capacity.
-
- 2 - SETTINGS_DOWNLOAD_BANDWIDTH allows the sender to send its
- expected download bandwidth on this channel. This number is an
- estimate. The value should be the integral number of kilobytes
- per second that the sender predicts as an expected maximum
- download channel capacity.
-
- 3 - SETTINGS_ROUND_TRIP_TIME allows the sender to send its
- expected round-trip-time on this channel. The round trip time
- is defined as the minimum amount of time to send a control
- frame from this client to the remote and receive a response.
- The value is represented in milliseconds.
-
- 4 - SETTINGS_MAX_CONCURRENT_STREAMS allows the sender to inform
- the remote endpoint the maximum number of concurrent streams
- which it will allow. By default there is no limit. For
- implementors it is recommended that this value be no smaller
- than 100.
-
- 5 - SETTINGS_CURRENT_CWND allows the sender to inform the
- remote endpoint of the current TCP CWND value.
-
- 6 - SETTINGS_DOWNLOAD_RETRANS_RATE allows the sender to inform
- the remote endpoint the retransmission rate (bytes
- retransmitted / total bytes transmitted).
-
- 7 - SETTINGS_INITIAL_WINDOW_SIZE allows the sender to inform
- the remote endpoint the initial window size (in bytes) for new
- streams.
-
-
-
-Belshe & Peon Expires August 4, 2012 [Page 18]
-
-Internet-Draft SPDY Feb 2012
-
-
- 8 - SETTINGS_CLIENT_CERTIFICATE_VECTOR_SIZE allows the server
- to inform the client if the new size of the client certificate
- vector.
-
- Value: A 32-bit value.
-
- 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.
-
- A server may send multiple SETTINGS frames containing different ID/
- Value pairs. When the same ID/Value is sent twice, the most recent
- value overrides any previously sent values. If the server sends IDs
- 1, 2, and 3 with the FLAG_SETTINGS_PERSIST_VALUE in a first SETTINGS
- frame, and then sends IDs 4 and 5 with the
- FLAG_SETTINGS_PERSIST_VALUE, when the client returns the persisted
- state on its next SETTINGS frame, it SHOULD send all 5 settings (1,
- 2, 3, 4, and 5 in this example) to the server.
-
-2.6.5. PING
-
- The PING control frame is a mechanism for measuring a minimal round-
- trip time from the sender. It can be sent from the client or the
- server. Recipients of a PING frame should send an identical frame to
- the sender as soon as possible (if there is other pending data
- waiting to be sent, PING should take highest priority). Each ping
- sent by a sender should use a unique ID.
-
- +----------------------------------+
- |1| version | 6 |
- +----------------------------------+
- | 0 (flags) | 4 (length) |
- +----------------------------------|
- | 32-bit ID |
- +----------------------------------+
-
- Control bit: The control bit is always 1 for this message.
-
- Version: The SPDY version number.
-
- Type: The message type for a PING message is 6.
-
- Length: This frame is always 4 bytes long.
-
-
-
-Belshe & Peon Expires August 4, 2012 [Page 19]
-
-Internet-Draft SPDY Feb 2012
-
-
- ID: A unique ID for this ping, represented as an unsigned 32 bit
- value. When the client initiates a ping, it must use an odd numbered
- ID. When the server initiates a ping, it must use an even numbered
- ping. Use of odd/even IDs is required in order to avoid accidental
- looping on PINGs (where each side initiates an identical PING at the
- same time).
-
- Note: If a sender uses all possible PING ids (e.g. has sent all 2^31
- possible IDs), it can wrap and start re-using IDs.
-
- If a server receives an even numbered PING which it did not initiate,
- it must ignore the PING. If a client receives an odd numbered PING
- which it did not initiate, it must ignore the PING.
-
-2.6.6. GOAWAY
-
- The GOAWAY control frame is a mechanism to tell the remote side of
- the connection to stop creating streams on this session. It can be
- sent from the client or the server. Once sent, the sender will not
- respond to any new SYN_STREAMs on this session. Recipients of a
- GOAWAY frame must not send additional streams on this session,
- although a new session can be established for new streams. The
- purpose of this message is to allow an endpoint to gracefully stop
- accepting new streams (perhaps for a reboot or maintenance), while
- still finishing processing of previously established streams.
-
- There is an inherent race condition between an endpoint sending
- SYN_STREAMs and the remote sending a GOAWAY message. To deal with
- this case, the GOAWAY contains a last-stream-id indicating the
- stream-id of the last stream which was created on the sending
- endpoint in this session. If the receiver of the GOAWAY sent new
- SYN_STREAMs for sessions after this last-stream-id, they were not
- processed by the server and the receiver may treat the stream as
- though it had never been created at all (hence the receiver may want
- to re-create the stream later on a new session).
-
- Endpoints should always send a GOAWAY message before closing a
- connection so that the remote can know whether a stream has been
- partially processed or not. (For example, if an HTTP client sends a
- POST at the same time that a server closes a connection, the client
- cannot know if the server started to process that POST request if the
- server does not send a GOAWAY frame to indicate where it stopped
- working).
-
- After sending a GOAWAY message, the sender must ignore all SYN_STREAM
- frames for new streams.
-
-
-
-
-
-Belshe & Peon Expires August 4, 2012 [Page 20]
-
-Internet-Draft SPDY Feb 2012
-
-
- +----------------------------------+
- |1| version | 7 |
- +----------------------------------+
- | 0 (flags) | 8 (length) |
- +----------------------------------|
- |X| Last-good-stream-ID (31 bits) |
- +----------------------------------+
- | Status code |
- +----------------------------------+
-
- Control bit: The control bit is always 1 for this message.
-
- Version: The SPDY version number.
-
- Type: The message type for a GOAWAY message is 7.
-
- Length: This frame is always 8 bytes long.
-
- Last-good-stream-Id: The last stream id which was replied to (with
- either a SYN_REPLY or RST_STREAM) by the sender of the GOAWAY
- message. If no streams were replied to, this value MUST be 0.
-
- Status: The reason for closing the session.
-
- 0 - OK. This is a normal session teardown.
-
- 1 - PROTOCOL_ERROR. This is a generic error, and should only be
- used if a more specific error is not available.
-
- 11 - INTERNAL_ERROR. This is a generic error which can be used
- when the implementation has internally failed, not due to anything
- in the protocol.
-
-2.6.7. HEADERS
-
- The HEADERS frame augments a stream with additional headers. It may
- be optionally sent on an existing stream at any time. Specific
- application of the headers in this frame is application-dependent.
- The name/value header block within this frame is compressed.
-
-
-
-
-
-
-
-
-
-
-
-
-Belshe & Peon Expires August 4, 2012 [Page 21]
-
-Internet-Draft SPDY Feb 2012
-
-
-+------------------------------------+
-|1| version | 8 |
-+------------------------------------+
-| Flags (8) | Length (24 bits) |
-+------------------------------------+
-|X| Stream-ID (31bits) |
-+------------------------------------+
-| Number of Name/Value pairs (int32) | <+
-+------------------------------------+ |
-| Length of name (int32) | | This section is the "Name/Value
-+------------------------------------+ | Header Block", and is compressed.
-| Name (string) | |
-+------------------------------------+ |
-| Length of value (int32) | |
-+------------------------------------+ |
-| Value (string) | |
-+------------------------------------+ |
-| (repeats) | <+
-
- Flags: Flags related to this frame. Valid flags are:
-
- 0x01 = FLAG_FIN - marks this frame as the last frame to be
- transmitted on this stream and puts the sender in the half-closed
- (Section 2.3.6) state.
-
- Length: An unsigned 24 bit value representing the number of bytes
- after the length field. The minimum length of the length field is 4
- (when the number of name value pairs is 0).
-
- Stream-ID: The stream this HEADERS block is associated with.
-
- Name/Value Header Block: A set of name/value pairs carried as part of
- the SYN_STREAM. see Name/Value Header Block (Section 2.6.10).
-
-2.6.8. WINDOW_UPDATE
-
- The WINDOW_UPDATE control frame is used to implement per stream flow
- control in SPDY. Flow control in SPDY is per hop, that is, only
- between the two endpoints of a SPDY connection. If there are one or
- more intermediaries between the client and the origin server, flow
- control signals are not explicitly forwarded by the intermediaries.
- (However, throttling of data transfer by any recipient may have the
- effect of indirectly propagating flow control information upstream
- back to the original sender.) Flow control only applies to the data
- portion of data frames. Recipients must buffer all control frames.
- If a recipient fails to buffer an entire control frame, it MUST issue
- a stream error (Section 2.4.2) with the status code
- FLOW_CONTROL_ERROR for the stream.
-
-
-
-Belshe & Peon Expires August 4, 2012 [Page 22]
-
-Internet-Draft SPDY Feb 2012
-
-
- Flow control in SPDY is implemented by a data transfer window kept by
- the sender of each stream. The data transfer window is a simple
- uint32 that indicates how many bytes of data the sender can transmit.
- After a stream is created, but before any data frames have been
- transmitted, the sender begins with the initial window size. This
- window size is a measure of the buffering capability of the
- recipient. The sender must not send a data frame with data length
- greater than the transfer window size. After sending each data
- frame, the sender decrements its transfer window size by the amount
- of data transmitted. When the window size becomes less than or equal
- to 0, the sender must pause transmitting data frames. At the other
- end of the stream, the recipient sends a WINDOW_UPDATE control back
- to notify the sender that it has consumed some data and freed up
- buffer space to receive more data.
-
- +----------------------------------+
- |1| version | 9 |
- +----------------------------------+
- | 0 (flags) | 8 (length) |
- +----------------------------------+
- |X| Stream-ID (31-bits) |
- +----------------------------------+
- |X| Delta-Window-Size (31-bits) |
- +----------------------------------+
-
- Control bit: The control bit is always 1 for this message.
-
- Version: The SPDY version number.
-
- Type: The message type for a WINDOW_UPDATE message is 9.
-
- Length: The length field is always 8 for this frame (there are 8
- bytes after the length field).
-
- Stream-ID: The stream ID that this WINDOW_UPDATE control frame is
- for.
-
- Delta-Window-Size: The additional number of bytes that the sender can
- transmit in addition to existing remaining window size. The legal
- range for this field is 1 to 2^31 - 1 (0x7fffffff) bytes.
-
- The window size as kept by the sender must never exceed 2^31
- (although it can become negative in one special case). If a sender
- receives a WINDOW_UPDATE that causes the its window size to exceed
- this limit, it must send RST_STREAM with status code
- FLOW_CONTROL_ERROR to terminate the stream.
-
- When a SPDY connection is first established, the default initial
-
-
-
-Belshe & Peon Expires August 4, 2012 [Page 23]
-
-Internet-Draft SPDY Feb 2012
-
-
- window size for all streams is 64KB. An endpoint can use the
- SETTINGS control frame to adjust the initial window size for the
- connection. That is, its peer can start out using the 64KB default
- initial window size when sending data frames before receiving the
- SETTINGS. Because SETTINGS is asynchronous, there may be a race
- condition if the recipient wants to decrease the initial window size,
- but its peer immediately sends 64KB on the creation of a new
- connection, before waiting for the SETTINGS to arrive. This is one
- case where the window size kept by the sender will become negative.
- Once the sender detects this condition, it must stop sending data
- frames and wait for the recipient to catch up. The recipient has two
- choices:
-
- immediately send RST_STREAM with FLOW_CONTROL_ERROR status code.
-
- allow the head of line blocking (as there is only one stream for
- the session and the amount of data in flight is bounded by the
- default initial window size), and send WINDOW_UPDATE as it
- consumes data.
-
- In the case of option 2, both sides must compute the window size
- based on the initial window size in the SETTINGS. For example, if
- the recipient sets the initial window size to be 16KB, and the sender
- sends 64KB immediately on connection establishment, the sender will
- discover its window size is -48KB on receipt of the SETTINGS. As the
- recipient consumes the first 16KB, it must send a WINDOW_UPDATE of
- 16KB back to the sender. This interaction continues until the
- sender's window size becomes positive again, and it can resume
- transmitting data frames.
-
- After the recipient reads in a data frame with FLAG_FIN that marks
- the end of the data stream, it should not send WINDOW_UPDATE frames
- as it consumes the last data frame. A sender should ignore all the
- WINDOW_UPDATE frames associated with the stream after it send the
- last frame for the stream.
-
- The data frames from the sender and the WINDOW_UPDATE frames from the
- recipient are completely asynchronous with respect to each other.
- This property allows a recipient to aggressively update the window
- size kept by the sender to prevent the stream from stalling.
-
-2.6.9. CREDENTIAL
-
- The CREDENTIAL control frame is used by the client to send additional
- client certificates to the server. A SPDY client may decide to send
- requests for resources from different origins on the same SPDY
- session if it decides that that server handles both origins. For
- example if the IP address associated with both hostnames matches and
-
-
-
-Belshe & Peon Expires August 4, 2012 [Page 24]
-
-Internet-Draft SPDY Feb 2012
-
-
- the SSL server certificate presented in the initial handshake is
- valid for both hostnames. However, because the SSL connection can
- contain at most one client certificate, the client needs a mechanism
- to send additional client certificates to the server.
-
- The server is required to maintain a vector of client certificates
- associated with a SPDY session. When the client needs to send a
- client certificate to the server, it will send a CREDENTIAL frame
- that specifies the index of the slot in which to store the
- certificate as well as proof that the client posesses the
- corresponding private key. The initial size of this vector must be
- 8. If the client provides a client certificate during the first TLS
- handshake, the contents of this certificate must be copied into the
- first slot (index 1) in the CREDENTIAL vector, though it may be
- overwritten by subsequent CREDENTIAL frames. The server must
- exclusively use the CREDNETIAL vector when evaluating the client
- certificates associated with an origin. The server may change the
- size of this vector by sending a SETTINGS frame with the setting
- SETTINGS_CLIENT_CERTIFICATE_VECTOR_SIZE value specified. In the
- event that the new size is smaller than the current size, truncation
- occurs preserving lower-index slots as possible.
-
- TLS renegotiation with client authentication is incompatible with
- SPDY given the multiplexed nature of SPDY. Specifically, imagine
- that the client has 2 requests outstanding to the server for two
- different pages (in different tabs). When the renegotiation + client
- certificate request comes in, the browser is unable to determine
- which resource triggered the client certificate request, in order to
- prompt the user accordingly.
-
- +----------------------------------+
- |1|000000000000001|0000000000001011|
- +----------------------------------+
- | flags (8) | Length (24 bits) |
- +----------------------------------+
- | Slot (16 bits) | |
- +-----------------+ |
- | Proof Length (32 bits) |
- +----------------------------------+
- | Proof |
- +----------------------------------+ <+
- | Certificate Length (32 bits) | |
- +----------------------------------+ | Repeated until end of frame
- | Certificate | |
- +----------------------------------+ <+
-
- Slot: The index in the server's client certificate vector where this
- certificate should be stored. If there is already a certificate
-
-
-
-Belshe & Peon Expires August 4, 2012 [Page 25]
-
-Internet-Draft SPDY Feb 2012
-
-
- stored at this index, it will be overwritten. The index is one
- based, not zero based; zero is an invalid slot index.
-
- Proof: Cryptographic proof that the client has possession of the
- private key associated with the certificate. The format is a TLS
- digitally-signed element
- (http://tools.ietf.org/html/rfc5246#section-4.7). The signature
- algorithm must be the same as that used in the CertificateVerify
- message. However, since the MD5+SHA1 signature type used in TLS 1.0
- connections can not be correctly encoded in a digitally-signed
- element, SHA1 must be used when MD5+SHA1 was used in the SSL
- connection. The signature is calculated over a 32 byte TLS extractor
- value (http://tools.ietf.org/html/rfc5705) with a label of "EXPORTER
- SPDY certificate proof" using the empty string as context. ForRSA
- certificates the signature would be a PKCS#1 v1.5 signature. For
- ECDSA, it would be an ECDSA-Sig-Value
- (http://tools.ietf.org/html/rfc5480#appendix-A). For a 1024-bit RSA
- key, the CREDENTIAL message would be ~500 bytes.
-
- Certificate: The certificate chain, starting with the leaf
- certificate. Each certificate must be encoded as a 32 bit length,
- followed by a DER encoded certificate. The certificate must be of
- the same type (RSA, ECDSA, etc) as the client certificate associated
- with the SSL connection.
-
- If the server receives a request for a resource with unacceptable
- credential (either missing or invalid), it must reply with a
- RST_STREAM frame with the status code INVALID_CREDENTIALS. Upon
- receipt of a RST_STREAM frame with INVALID_CREDENTIALS, the client
- should initiate a new stream directly to the requested origin and
- resend the request. Note, SPDY does not allow the server to request
- different client authentication for different resources in the same
- origin.
-
- If the server receives an invalid CREDENTIAL frame, it MUST respond
- with a GOAWAY frame and shutdown the session.
-
-2.6.10. Name/Value Header Block
-
- The Name/Value Header Block is found in the SYN_STREAM, SYN_REPLY and
- HEADERS control frames, and shares a common format:
-
-
-
-
-
-
-
-
-
-
-Belshe & Peon Expires August 4, 2012 [Page 26]
-
-Internet-Draft SPDY Feb 2012
-
-
- +------------------------------------+
- | Number of Name/Value pairs (int32) |
- +------------------------------------+
- | Length of name (int32) |
- +------------------------------------+
- | Name (string) |
- +------------------------------------+
- | Length of value (int32) |
- +------------------------------------+
- | Value (string) |
- +------------------------------------+
- | (repeats) |
-
- Number of Name/Value pairs: The number of repeating name/value pairs
- following this field.
-
- List of Name/Value pairs:
-
- Length of Name: a 32-bit value containing the number of octets in
- the name field. Note that in practice, this length must not
- exceed 2^24, as that is the maximum size of a SPDY frame.
-
- Name: 0 or more octets, 8-bit sequences of data, excluding 0.
-
- Length of Value: a 32-bit value containing the number of octets in
- the value field. Note that in practice, this length must not
- exceed 2^24, as that is the maximum size of a SPDY frame.
-
- Value: 0 or more octets, 8-bit sequences of data, excluding 0.
-
- Each header name must have at least one value. Header names are
- encoded using the US-ASCII character set [ASCII] and must be all
- lower case. The length of each name must be greater than zero. A
- recipient of a zero-length name MUST issue a stream error
- (Section 2.4.2) with the status code PROTOCOL_ERROR for the
- stream-id.
-
- Duplicate header names are not allowed. To send two identically
- named headers, send a header with two values, where the values are
- separated by a single NUL (0) byte. A header value can either be
- empty (e.g. the length is zero) or it can contain multiple, NUL-
- separated values, each with length greater than zero. The value
- never starts nor ends with a NUL character. Recipients of illegal
- value fields MUST issue a stream error (Section 2.4.2) with the
- status code PROTOCOL_ERROR for the stream-id.
-
-
-
-
-
-
-Belshe & Peon Expires August 4, 2012 [Page 27]
-
-Internet-Draft SPDY Feb 2012
-
-
-2.6.10.1. Compression
-
- The Name/Value Header Block is a section of the SYN_STREAM,
- SYN_REPLY, and HEADERS frames used to carry header meta-data. This
- block is always compressed using zlib compression. Within this
- specification, any reference to 'zlib' is referring to the ZLIB
- Compressed Data Format Specification Version 3.3 as part of RFC1950.
- [RFC1950]
-
- For each HEADERS compression instance, the initial state is
- initialized using the following dictionary [UDELCOMPRESSION]:
-
- const unsigned char SPDY_dictionary_txt[] = {
- 0x00, 0x00, 0x00, 0x07, 0x6f, 0x70, 0x74, 0x69, \\ - - - - o p t i
- 0x6f, 0x6e, 0x73, 0x00, 0x00, 0x00, 0x04, 0x68, \\ o n s - - - - h
- 0x65, 0x61, 0x64, 0x00, 0x00, 0x00, 0x04, 0x70, \\ e a d - - - - p
- 0x6f, 0x73, 0x74, 0x00, 0x00, 0x00, 0x03, 0x70, \\ o s t - - - - p
- 0x75, 0x74, 0x00, 0x00, 0x00, 0x06, 0x64, 0x65, \\ u t - - - - d e
- 0x6c, 0x65, 0x74, 0x65, 0x00, 0x00, 0x00, 0x05, \\ l e t e - - - -
- 0x74, 0x72, 0x61, 0x63, 0x65, 0x00, 0x00, 0x00, \\ t r a c e - - -
- 0x06, 0x61, 0x63, 0x63, 0x65, 0x70, 0x74, 0x00, \\ - a c c e p t -
- 0x00, 0x00, 0x0e, 0x61, 0x63, 0x63, 0x65, 0x70, \\ - - - a c c e p
- 0x74, 0x2d, 0x63, 0x68, 0x61, 0x72, 0x73, 0x65, \\ t - c h a r s e
- 0x74, 0x00, 0x00, 0x00, 0x0f, 0x61, 0x63, 0x63, \\ t - - - - a c c
- 0x65, 0x70, 0x74, 0x2d, 0x65, 0x6e, 0x63, 0x6f, \\ e p t - e n c o
- 0x64, 0x69, 0x6e, 0x67, 0x00, 0x00, 0x00, 0x0f, \\ d i n g - - - -
- 0x61, 0x63, 0x63, 0x65, 0x70, 0x74, 0x2d, 0x6c, \\ a c c e p t - l
- 0x61, 0x6e, 0x67, 0x75, 0x61, 0x67, 0x65, 0x00, \\ a n g u a g e -
- 0x00, 0x00, 0x0d, 0x61, 0x63, 0x63, 0x65, 0x70, \\ - - - a c c e p
- 0x74, 0x2d, 0x72, 0x61, 0x6e, 0x67, 0x65, 0x73, \\ t - r a n g e s
- 0x00, 0x00, 0x00, 0x03, 0x61, 0x67, 0x65, 0x00, \\ - - - - a g e -
- 0x00, 0x00, 0x05, 0x61, 0x6c, 0x6c, 0x6f, 0x77, \\ - - - a l l o w
- 0x00, 0x00, 0x00, 0x0d, 0x61, 0x75, 0x74, 0x68, \\ - - - - a u t h
- 0x6f, 0x72, 0x69, 0x7a, 0x61, 0x74, 0x69, 0x6f, \\ o r i z a t i o
- 0x6e, 0x00, 0x00, 0x00, 0x0d, 0x63, 0x61, 0x63, \\ n - - - - c a c
- 0x68, 0x65, 0x2d, 0x63, 0x6f, 0x6e, 0x74, 0x72, \\ h e - c o n t r
- 0x6f, 0x6c, 0x00, 0x00, 0x00, 0x0a, 0x63, 0x6f, \\ o l - - - - c o
- 0x6e, 0x6e, 0x65, 0x63, 0x74, 0x69, 0x6f, 0x6e, \\ n n e c t i o n
- 0x00, 0x00, 0x00, 0x0c, 0x63, 0x6f, 0x6e, 0x74, \\ - - - - c o n t
- 0x65, 0x6e, 0x74, 0x2d, 0x62, 0x61, 0x73, 0x65, \\ e n t - b a s e
- 0x00, 0x00, 0x00, 0x10, 0x63, 0x6f, 0x6e, 0x74, \\ - - - - c o n t
- 0x65, 0x6e, 0x74, 0x2d, 0x65, 0x6e, 0x63, 0x6f, \\ e n t - e n c o
- 0x64, 0x69, 0x6e, 0x67, 0x00, 0x00, 0x00, 0x10, \\ d i n g - - - -
- 0x63, 0x6f, 0x6e, 0x74, 0x65, 0x6e, 0x74, 0x2d, \\ c o n t e n t -
- 0x6c, 0x61, 0x6e, 0x67, 0x75, 0x61, 0x67, 0x65, \\ l a n g u a g e
- 0x00, 0x00, 0x00, 0x0e, 0x63, 0x6f, 0x6e, 0x74, \\ - - - - c o n t
- 0x65, 0x6e, 0x74, 0x2d, 0x6c, 0x65, 0x6e, 0x67, \\ e n t - l e n g
- 0x74, 0x68, 0x00, 0x00, 0x00, 0x10, 0x63, 0x6f, \\ t h - - - - c o
-
-
-
-Belshe & Peon Expires August 4, 2012 [Page 28]
-
-Internet-Draft SPDY Feb 2012
-
-
- 0x6e, 0x74, 0x65, 0x6e, 0x74, 0x2d, 0x6c, 0x6f, \\ n t e n t - l o
- 0x63, 0x61, 0x74, 0x69, 0x6f, 0x6e, 0x00, 0x00, \\ c a t i o n - -
- 0x00, 0x0b, 0x63, 0x6f, 0x6e, 0x74, 0x65, 0x6e, \\ - - c o n t e n
- 0x74, 0x2d, 0x6d, 0x64, 0x35, 0x00, 0x00, 0x00, \\ t - m d 5 - - -
- 0x0d, 0x63, 0x6f, 0x6e, 0x74, 0x65, 0x6e, 0x74, \\ - c o n t e n t
- 0x2d, 0x72, 0x61, 0x6e, 0x67, 0x65, 0x00, 0x00, \\ - r a n g e - -
- 0x00, 0x0c, 0x63, 0x6f, 0x6e, 0x74, 0x65, 0x6e, \\ - - c o n t e n
- 0x74, 0x2d, 0x74, 0x79, 0x70, 0x65, 0x00, 0x00, \\ t - t y p e - -
- 0x00, 0x04, 0x64, 0x61, 0x74, 0x65, 0x00, 0x00, \\ - - d a t e - -
- 0x00, 0x04, 0x65, 0x74, 0x61, 0x67, 0x00, 0x00, \\ - - e t a g - -
- 0x00, 0x06, 0x65, 0x78, 0x70, 0x65, 0x63, 0x74, \\ - - e x p e c t
- 0x00, 0x00, 0x00, 0x07, 0x65, 0x78, 0x70, 0x69, \\ - - - - e x p i
- 0x72, 0x65, 0x73, 0x00, 0x00, 0x00, 0x04, 0x66, \\ r e s - - - - f
- 0x72, 0x6f, 0x6d, 0x00, 0x00, 0x00, 0x04, 0x68, \\ r o m - - - - h
- 0x6f, 0x73, 0x74, 0x00, 0x00, 0x00, 0x08, 0x69, \\ o s t - - - - i
- 0x66, 0x2d, 0x6d, 0x61, 0x74, 0x63, 0x68, 0x00, \\ f - m a t c h -
- 0x00, 0x00, 0x11, 0x69, 0x66, 0x2d, 0x6d, 0x6f, \\ - - - i f - m o
- 0x64, 0x69, 0x66, 0x69, 0x65, 0x64, 0x2d, 0x73, \\ d i f i e d - s
- 0x69, 0x6e, 0x63, 0x65, 0x00, 0x00, 0x00, 0x0d, \\ i n c e - - - -
- 0x69, 0x66, 0x2d, 0x6e, 0x6f, 0x6e, 0x65, 0x2d, \\ i f - n o n e -
- 0x6d, 0x61, 0x74, 0x63, 0x68, 0x00, 0x00, 0x00, \\ m a t c h - - -
- 0x08, 0x69, 0x66, 0x2d, 0x72, 0x61, 0x6e, 0x67, \\ - i f - r a n g
- 0x65, 0x00, 0x00, 0x00, 0x13, 0x69, 0x66, 0x2d, \\ e - - - - i f -
- 0x75, 0x6e, 0x6d, 0x6f, 0x64, 0x69, 0x66, 0x69, \\ u n m o d i f i
- 0x65, 0x64, 0x2d, 0x73, 0x69, 0x6e, 0x63, 0x65, \\ e d - s i n c e
- 0x00, 0x00, 0x00, 0x0d, 0x6c, 0x61, 0x73, 0x74, \\ - - - - l a s t
- 0x2d, 0x6d, 0x6f, 0x64, 0x69, 0x66, 0x69, 0x65, \\ - m o d i f i e
- 0x64, 0x00, 0x00, 0x00, 0x08, 0x6c, 0x6f, 0x63, \\ d - - - - l o c
- 0x61, 0x74, 0x69, 0x6f, 0x6e, 0x00, 0x00, 0x00, \\ a t i o n - - -
- 0x0c, 0x6d, 0x61, 0x78, 0x2d, 0x66, 0x6f, 0x72, \\ - m a x - f o r
- 0x77, 0x61, 0x72, 0x64, 0x73, 0x00, 0x00, 0x00, \\ w a r d s - - -
- 0x06, 0x70, 0x72, 0x61, 0x67, 0x6d, 0x61, 0x00, \\ - p r a g m a -
- 0x00, 0x00, 0x12, 0x70, 0x72, 0x6f, 0x78, 0x79, \\ - - - p r o x y
- 0x2d, 0x61, 0x75, 0x74, 0x68, 0x65, 0x6e, 0x74, \\ - a u t h e n t
- 0x69, 0x63, 0x61, 0x74, 0x65, 0x00, 0x00, 0x00, \\ i c a t e - - -
- 0x13, 0x70, 0x72, 0x6f, 0x78, 0x79, 0x2d, 0x61, \\ - p r o x y - a
- 0x75, 0x74, 0x68, 0x6f, 0x72, 0x69, 0x7a, 0x61, \\ u t h o r i z a
- 0x74, 0x69, 0x6f, 0x6e, 0x00, 0x00, 0x00, 0x05, \\ t i o n - - - -
- 0x72, 0x61, 0x6e, 0x67, 0x65, 0x00, 0x00, 0x00, \\ r a n g e - - -
- 0x07, 0x72, 0x65, 0x66, 0x65, 0x72, 0x65, 0x72, \\ - r e f e r e r
- 0x00, 0x00, 0x00, 0x0b, 0x72, 0x65, 0x74, 0x72, \\ - - - - r e t r
- 0x79, 0x2d, 0x61, 0x66, 0x74, 0x65, 0x72, 0x00, \\ y - a f t e r -
- 0x00, 0x00, 0x06, 0x73, 0x65, 0x72, 0x76, 0x65, \\ - - - s e r v e
- 0x72, 0x00, 0x00, 0x00, 0x02, 0x74, 0x65, 0x00, \\ r - - - - t e -
- 0x00, 0x00, 0x07, 0x74, 0x72, 0x61, 0x69, 0x6c, \\ - - - t r a i l
- 0x65, 0x72, 0x00, 0x00, 0x00, 0x11, 0x74, 0x72, \\ e r - - - - t r
- 0x61, 0x6e, 0x73, 0x66, 0x65, 0x72, 0x2d, 0x65, \\ a n s f e r - e
- 0x6e, 0x63, 0x6f, 0x64, 0x69, 0x6e, 0x67, 0x00, \\ n c o d i n g -
-
-
-
-Belshe & Peon Expires August 4, 2012 [Page 29]
-
-Internet-Draft SPDY Feb 2012
-
-
- 0x00, 0x00, 0x07, 0x75, 0x70, 0x67, 0x72, 0x61, \\ - - - u p g r a
- 0x64, 0x65, 0x00, 0x00, 0x00, 0x0a, 0x75, 0x73, \\ d e - - - - u s
- 0x65, 0x72, 0x2d, 0x61, 0x67, 0x65, 0x6e, 0x74, \\ e r - a g e n t
- 0x00, 0x00, 0x00, 0x04, 0x76, 0x61, 0x72, 0x79, \\ - - - - v a r y
- 0x00, 0x00, 0x00, 0x03, 0x76, 0x69, 0x61, 0x00, \\ - - - - v i a -
- 0x00, 0x00, 0x07, 0x77, 0x61, 0x72, 0x6e, 0x69, \\ - - - w a r n i
- 0x6e, 0x67, 0x00, 0x00, 0x00, 0x10, 0x77, 0x77, \\ n g - - - - w w
- 0x77, 0x2d, 0x61, 0x75, 0x74, 0x68, 0x65, 0x6e, \\ w - a u t h e n
- 0x74, 0x69, 0x63, 0x61, 0x74, 0x65, 0x00, 0x00, \\ t i c a t e - -
- 0x00, 0x06, 0x6d, 0x65, 0x74, 0x68, 0x6f, 0x64, \\ - - m e t h o d
- 0x00, 0x00, 0x00, 0x03, 0x67, 0x65, 0x74, 0x00, \\ - - - - g e t -
- 0x00, 0x00, 0x06, 0x73, 0x74, 0x61, 0x74, 0x75, \\ - - - s t a t u
- 0x73, 0x00, 0x00, 0x00, 0x06, 0x32, 0x30, 0x30, \\ s - - - - 2 0 0
- 0x20, 0x4f, 0x4b, 0x00, 0x00, 0x00, 0x07, 0x76, \\ - O K - - - - v
- 0x65, 0x72, 0x73, 0x69, 0x6f, 0x6e, 0x00, 0x00, \\ e r s i o n - -
- 0x00, 0x08, 0x48, 0x54, 0x54, 0x50, 0x2f, 0x31, \\ - - H T T P - 1
- 0x2e, 0x31, 0x00, 0x00, 0x00, 0x03, 0x75, 0x72, \\ - 1 - - - - u r
- 0x6c, 0x00, 0x00, 0x00, 0x06, 0x70, 0x75, 0x62, \\ l - - - - p u b
- 0x6c, 0x69, 0x63, 0x00, 0x00, 0x00, 0x0a, 0x73, \\ l i c - - - - s
- 0x65, 0x74, 0x2d, 0x63, 0x6f, 0x6f, 0x6b, 0x69, \\ e t - c o o k i
- 0x65, 0x00, 0x00, 0x00, 0x0a, 0x6b, 0x65, 0x65, \\ e - - - - k e e
- 0x70, 0x2d, 0x61, 0x6c, 0x69, 0x76, 0x65, 0x00, \\ p - a l i v e -
- 0x00, 0x00, 0x06, 0x6f, 0x72, 0x69, 0x67, 0x69, \\ - - - o r i g i
- 0x6e, 0x31, 0x30, 0x30, 0x31, 0x30, 0x31, 0x32, \\ n 1 0 0 1 0 1 2
- 0x30, 0x31, 0x32, 0x30, 0x32, 0x32, 0x30, 0x35, \\ 0 1 2 0 2 2 0 5
- 0x32, 0x30, 0x36, 0x33, 0x30, 0x30, 0x33, 0x30, \\ 2 0 6 3 0 0 3 0
- 0x32, 0x33, 0x30, 0x33, 0x33, 0x30, 0x34, 0x33, \\ 2 3 0 3 3 0 4 3
- 0x30, 0x35, 0x33, 0x30, 0x36, 0x33, 0x30, 0x37, \\ 0 5 3 0 6 3 0 7
- 0x34, 0x30, 0x32, 0x34, 0x30, 0x35, 0x34, 0x30, \\ 4 0 2 4 0 5 4 0
- 0x36, 0x34, 0x30, 0x37, 0x34, 0x30, 0x38, 0x34, \\ 6 4 0 7 4 0 8 4
- 0x30, 0x39, 0x34, 0x31, 0x30, 0x34, 0x31, 0x31, \\ 0 9 4 1 0 4 1 1
- 0x34, 0x31, 0x32, 0x34, 0x31, 0x33, 0x34, 0x31, \\ 4 1 2 4 1 3 4 1
- 0x34, 0x34, 0x31, 0x35, 0x34, 0x31, 0x36, 0x34, \\ 4 4 1 5 4 1 6 4
- 0x31, 0x37, 0x35, 0x30, 0x32, 0x35, 0x30, 0x34, \\ 1 7 5 0 2 5 0 4
- 0x35, 0x30, 0x35, 0x32, 0x30, 0x33, 0x20, 0x4e, \\ 5 0 5 2 0 3 - N
- 0x6f, 0x6e, 0x2d, 0x41, 0x75, 0x74, 0x68, 0x6f, \\ o n - A u t h o
- 0x72, 0x69, 0x74, 0x61, 0x74, 0x69, 0x76, 0x65, \\ r i t a t i v e
- 0x20, 0x49, 0x6e, 0x66, 0x6f, 0x72, 0x6d, 0x61, \\ - I n f o r m a
- 0x74, 0x69, 0x6f, 0x6e, 0x32, 0x30, 0x34, 0x20, \\ t i o n 2 0 4 -
- 0x4e, 0x6f, 0x20, 0x43, 0x6f, 0x6e, 0x74, 0x65, \\ N o - C o n t e
- 0x6e, 0x74, 0x33, 0x30, 0x31, 0x20, 0x4d, 0x6f, \\ n t 3 0 1 - M o
- 0x76, 0x65, 0x64, 0x20, 0x50, 0x65, 0x72, 0x6d, \\ v e d - P e r m
- 0x61, 0x6e, 0x65, 0x6e, 0x74, 0x6c, 0x79, 0x34, \\ a n e n t l y 4
- 0x30, 0x30, 0x20, 0x42, 0x61, 0x64, 0x20, 0x52, \\ 0 0 - B a d - R
- 0x65, 0x71, 0x75, 0x65, 0x73, 0x74, 0x34, 0x30, \\ e q u e s t 4 0
- 0x31, 0x20, 0x55, 0x6e, 0x61, 0x75, 0x74, 0x68, \\ 1 - U n a u t h
- 0x6f, 0x72, 0x69, 0x7a, 0x65, 0x64, 0x34, 0x30, \\ o r i z e d 4 0
- 0x33, 0x20, 0x46, 0x6f, 0x72, 0x62, 0x69, 0x64, \\ 3 - F o r b i d
-
-
-
-Belshe & Peon Expires August 4, 2012 [Page 30]
-
-Internet-Draft SPDY Feb 2012
-
-
- 0x64, 0x65, 0x6e, 0x34, 0x30, 0x34, 0x20, 0x4e, \\ d e n 4 0 4 - N
- 0x6f, 0x74, 0x20, 0x46, 0x6f, 0x75, 0x6e, 0x64, \\ o t - F o u n d
- 0x35, 0x30, 0x30, 0x20, 0x49, 0x6e, 0x74, 0x65, \\ 5 0 0 - I n t e
- 0x72, 0x6e, 0x61, 0x6c, 0x20, 0x53, 0x65, 0x72, \\ r n a l - S e r
- 0x76, 0x65, 0x72, 0x20, 0x45, 0x72, 0x72, 0x6f, \\ v e r - E r r o
- 0x72, 0x35, 0x30, 0x31, 0x20, 0x4e, 0x6f, 0x74, \\ r 5 0 1 - N o t
- 0x20, 0x49, 0x6d, 0x70, 0x6c, 0x65, 0x6d, 0x65, \\ - I m p l e m e
- 0x6e, 0x74, 0x65, 0x64, 0x35, 0x30, 0x33, 0x20, \\ n t e d 5 0 3 -
- 0x53, 0x65, 0x72, 0x76, 0x69, 0x63, 0x65, 0x20, \\ S e r v i c e -
- 0x55, 0x6e, 0x61, 0x76, 0x61, 0x69, 0x6c, 0x61, \\ U n a v a i l a
- 0x62, 0x6c, 0x65, 0x4a, 0x61, 0x6e, 0x20, 0x46, \\ b l e J a n - F
- 0x65, 0x62, 0x20, 0x4d, 0x61, 0x72, 0x20, 0x41, \\ e b - M a r - A
- 0x70, 0x72, 0x20, 0x4d, 0x61, 0x79, 0x20, 0x4a, \\ p r - M a y - J
- 0x75, 0x6e, 0x20, 0x4a, 0x75, 0x6c, 0x20, 0x41, \\ u n - J u l - A
- 0x75, 0x67, 0x20, 0x53, 0x65, 0x70, 0x74, 0x20, \\ u g - S e p t -
- 0x4f, 0x63, 0x74, 0x20, 0x4e, 0x6f, 0x76, 0x20, \\ O c t - N o v -
- 0x44, 0x65, 0x63, 0x20, 0x30, 0x30, 0x3a, 0x30, \\ D e c - 0 0 - 0
- 0x30, 0x3a, 0x30, 0x30, 0x20, 0x4d, 0x6f, 0x6e, \\ 0 - 0 0 - M o n
- 0x2c, 0x20, 0x54, 0x75, 0x65, 0x2c, 0x20, 0x57, \\ - - T u e - - W
- 0x65, 0x64, 0x2c, 0x20, 0x54, 0x68, 0x75, 0x2c, \\ e d - - T h u -
- 0x20, 0x46, 0x72, 0x69, 0x2c, 0x20, 0x53, 0x61, \\ - F r i - - S a
- 0x74, 0x2c, 0x20, 0x53, 0x75, 0x6e, 0x2c, 0x20, \\ t - - S u n - -
- 0x47, 0x4d, 0x54, 0x63, 0x68, 0x75, 0x6e, 0x6b, \\ G M T c h u n k
- 0x65, 0x64, 0x2c, 0x74, 0x65, 0x78, 0x74, 0x2f, \\ e d - t e x t -
- 0x68, 0x74, 0x6d, 0x6c, 0x2c, 0x69, 0x6d, 0x61, \\ h t m l - i m a
- 0x67, 0x65, 0x2f, 0x70, 0x6e, 0x67, 0x2c, 0x69, \\ g e - p n g - i
- 0x6d, 0x61, 0x67, 0x65, 0x2f, 0x6a, 0x70, 0x67, \\ m a g e - j p g
- 0x2c, 0x69, 0x6d, 0x61, 0x67, 0x65, 0x2f, 0x67, \\ - i m a g e - g
- 0x69, 0x66, 0x2c, 0x61, 0x70, 0x70, 0x6c, 0x69, \\ i f - a p p l i
- 0x63, 0x61, 0x74, 0x69, 0x6f, 0x6e, 0x2f, 0x78, \\ c a t i o n - x
- 0x6d, 0x6c, 0x2c, 0x61, 0x70, 0x70, 0x6c, 0x69, \\ m l - a p p l i
- 0x63, 0x61, 0x74, 0x69, 0x6f, 0x6e, 0x2f, 0x78, \\ c a t i o n - x
- 0x68, 0x74, 0x6d, 0x6c, 0x2b, 0x78, 0x6d, 0x6c, \\ h t m l - x m l
- 0x2c, 0x74, 0x65, 0x78, 0x74, 0x2f, 0x70, 0x6c, \\ - t e x t - p l
- 0x61, 0x69, 0x6e, 0x2c, 0x74, 0x65, 0x78, 0x74, \\ a i n - t e x t
- 0x2f, 0x6a, 0x61, 0x76, 0x61, 0x73, 0x63, 0x72, \\ - j a v a s c r
- 0x69, 0x70, 0x74, 0x2c, 0x70, 0x75, 0x62, 0x6c, \\ i p t - p u b l
- 0x69, 0x63, 0x70, 0x72, 0x69, 0x76, 0x61, 0x74, \\ i c p r i v a t
- 0x65, 0x6d, 0x61, 0x78, 0x2d, 0x61, 0x67, 0x65, \\ e m a x - a g e
- 0x3d, 0x67, 0x7a, 0x69, 0x70, 0x2c, 0x64, 0x65, \\ - g z i p - d e
- 0x66, 0x6c, 0x61, 0x74, 0x65, 0x2c, 0x73, 0x64, \\ f l a t e - s d
- 0x63, 0x68, 0x63, 0x68, 0x61, 0x72, 0x73, 0x65, \\ c h c h a r s e
- 0x74, 0x3d, 0x75, 0x74, 0x66, 0x2d, 0x38, 0x63, \\ t - u t f - 8 c
- 0x68, 0x61, 0x72, 0x73, 0x65, 0x74, 0x3d, 0x69, \\ h a r s e t - i
- 0x73, 0x6f, 0x2d, 0x38, 0x38, 0x35, 0x39, 0x2d, \\ s o - 8 8 5 9 -
- 0x31, 0x2c, 0x75, 0x74, 0x66, 0x2d, 0x2c, 0x2a, \\ 1 - u t f - - -
- 0x2c, 0x65, 0x6e, 0x71, 0x3d, 0x30, 0x2e \\ - e n q - 0 -
- };
-
-
-
-Belshe & Peon Expires August 4, 2012 [Page 31]
-
-Internet-Draft SPDY Feb 2012
-
-
- The entire contents of the name/value header block is compressed
- using zlib. There is a single zlib stream for all name value pairs
- in one direction on a connection. SPDY uses a SYNC_FLUSH between
- each compressed frame.
-
- Implementation notes: the compression engine can be tuned to favor
- speed or size. Optimizing for size increases memory use and CPU
- consumption. Because header blocks are generally small, implementors
- may want to reduce the window-size of the compression engine from the
- default 15bits (a 32KB window) to more like 11bits (a 2KB window).
- The exact setting is chosen by the compressor, the decompressor will
- work with any setting.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Belshe & Peon Expires August 4, 2012 [Page 32]
-
-Internet-Draft SPDY Feb 2012
-
-
-3. HTTP Layering over SPDY
-
- SPDY is intended to be as compatible as possible with current web-
- based applications. This means that, from the perspective of the
- server business logic or application API, the features of HTTP are
- unchanged. To achieve this, all of the application request and
- response header semantics are preserved, although the syntax of
- conveying those semantics has changed. Thus, the rules from the
- HTTP/1.1 specification in RFC2616 [RFC2616] apply with the changes in
- the sections below.
-
-3.1. Connection Management
-
- Clients SHOULD NOT open more than one SPDY session to a given origin
- [RFC6454] concurrently.
-
- Note that it is possible for one SPDY session to be finishing (e.g. a
- GOAWAY message has been sent, but not all streams have finished),
- while another SPDY session is starting.
-
-3.1.1. Use of GOAWAY
-
- SPDY provides a GOAWAY message which can be used when closing a
- connection from either the client or server. Without a server GOAWAY
- message, HTTP has a race condition where the client sends a request
- (a new SYN_STREAM) just as the server is closing the connection, and
- the client cannot know if the server received the stream or not. By
- using the last-stream-id in the GOAWAY, servers can indicate to the
- client if a request was processed or not.
-
- Note that some servers will choose to send the GOAWAY and immediately
- terminate the connection without waiting for active streams to
- finish. The client will be able to determine this because SPDY
- streams are determinstically closed. This abrupt termination will
- force the client to heuristically decide whether to retry the pending
- requests. Clients always need to be capable of dealing with this
- case because they must deal with accidental connection termination
- cases, which are the same as the server never having sent a GOAWAY.
-
- More sophisticated servers will use GOAWAY to implement a graceful
- teardown. They will send the GOAWAY and provide some time for the
- active streams to finish before terminating the connection.
-
- If a SPDY client closes the connection, it should also send a GOAWAY
- message. This allows the server to know if any server-push streams
- were received by the client.
-
- If the endpoint closing the connection has not received any
-
-
-
-Belshe & Peon Expires August 4, 2012 [Page 33]
-
-Internet-Draft SPDY Feb 2012
-
-
- SYN_STREAMs from the remote, the GOAWAY will contain a last-stream-id
- of 0.
-
-3.2. HTTP Request/Response
-
-3.2.1. Request
-
- The client initiates a request by sending a SYN_STREAM frame. For
- requests which do not contain a body, the SYN_STREAM frame MUST set
- the FLAG_FIN, indicating that the client intends to send no further
- data on this stream. For requests which do contain a body, the
- SYN_STREAM will not contain the FLAG_FIN, and the body will follow
- the SYN_STREAM in a series of DATA frames. The last DATA frame will
- set the FLAG_FIN to indicate the end of the body.
-
- The SYN_STREAM Name/Value section will contain all of the HTTP
- headers which are associated with an HTTP request. The header block
- in SPDY is mostly unchanged from today's HTTP header block, with the
- following differences:
-
- The first line of the request is unfolded into name/value pairs
- like other HTTP headers and MUST be present:
-
- ":method" - the HTTP method for this request (e.g. "GET",
- "POST", "HEAD", etc)
-
- ":path" - the url-path for this url with "/" prefixed. (See
- RFC1738 [RFC1738]). For example, for
- "http://www.google.com/search?q=dogs"; the path would be
- "/search?q=dogs".
-
- ":version" - the HTTP version of this request (e.g.
- "HTTP/1.1")
-
- In addition, the following two name/value pairs must also be
- present in every request:
-
- ":host" - the hostport (See RFC1738 [RFC1738]) portion of the
- URL for this request (e.g. "www.google.com:1234"). This header
- is the same as the HTTP 'Host' header.
-
- ":scheme" - the scheme portion of the URL for this request
- (e.g. "https"))
-
- Header names are all lowercase.
-
- The Connection, Host, Keep-Alive, Proxy-Connection, and Transfer-
- Encoding headers are not valid and MUST not be sent.
-
-
-
-Belshe & Peon Expires August 4, 2012 [Page 34]
-
-Internet-Draft SPDY Feb 2012
-
-
- User-agents MUST support gzip compression. Regardless of the
- Accept-Encoding sent by the user-agent, the server may always send
- content encoded with gzip or deflate encoding.
-
- If a server receives a request where the sum of the data frame
- payload lengths does not equal the size of the Content-Length
- header, the server MUST return a 400 (Bad Request) error.
-
- POST-specific changes:
-
- Although POSTs are inherently chunked, POST requests SHOULD
- also be accompanied by a Content-Length header. There are two
- reasons for this: First, it assists with upload progress meters
- for an improved user experience. But second, we know from
- early versions of SPDY that failure to send a content length
- header is incompatible with many existing HTTP server
- implementations. Existing user-agents do not omit the Content-
- Length header, and server implementations have come to depend
- upon this.
-
- The user-agent is free to prioritize requests as it sees fit. If the
- user-agent cannot make progress without receiving a resource, it
- should attempt to raise the priority of that resource. Resources
- such as images, SHOULD generally use the lowest priority.
-
- If a client sends a SYN_STREAM without all of the method, host, path,
- scheme, and version headers, the server MUST reply with a HTTP 400
- Bad Request reply.
-
-3.2.2. Response
-
- The server responds to a client request with a SYN_REPLY frame.
- Symmetric to the client's upload stream, server will send data after
- the SYN_REPLY frame via a series of DATA frames, and the last data
- frame will contain the FLAG_FIN to indicate successful end-of-stream.
- If a response (like a 202 or 204 response) contains no body, the
- SYN_REPLY frame may contain the FLAG_FIN flag to indicate no further
- data will be sent on the stream.
-
- The response status line is unfolded into name/value pairs like
- other HTTP headers and must be present:
-
- ":status" - The HTTP response status code (e.g. "200" or "200
- OK")
-
- ":version" - The HTTP response version (e.g. "HTTP/1.1")
-
-
-
-
-
-Belshe & Peon Expires August 4, 2012 [Page 35]
-
-Internet-Draft SPDY Feb 2012
-
-
- All header names must be lowercase.
-
- The Connection, Keep-Alive, Proxy-Connection, and Transfer-
- Encoding headers are not valid and MUST not be sent.
-
- Responses MAY be accompanied by a Content-Length header for
- advisory purposes. (e.g. for UI progress meters)
-
- If a client receives a response where the sum of the data frame
- payload lengths does not equal the size of the Content-Length
- header, the client MUST ignore the content length header.
-
- If a client receives a SYN_REPLY without a status or without a
- version header, the client must reply with a RST_STREAM frame
- indicating a PROTOCOL ERROR.
-
-3.2.3. Authentication
-
- When a client sends a request to an origin server that requires
- authentication, the server can reply with a "401 Unauthorized"
- response, and include a WWW-Authenticate challenge header that
- defines the authentication scheme to be used. The client then
- retries the request with an Authorization header appropriate to the
- specified authentication scheme.
-
- There are four options for proxy authentication, Basic, Digest, NTLM
- and Negotiate (SPNEGO). The first two options were defined in
- RFC2617 [RFC2617], and are stateless. The second two options were
- developed by Microsoft and specified in RFC4559 [RFC4559], and are
- stateful; otherwise known as multi-round authentication, or
- connection authentication.
-
-3.2.3.1. Stateless Authentication
-
- Stateless Authentication over SPDY is identical to how it is
- performed over HTTP. If multiple SPDY streams are concurrently sent
- to a single server, each will authenticate independently, similar to
- how two HTTP connections would independently authenticate to a proxy
- server.
-
-3.2.3.2. Stateful Authentication
-
- Unfortunately, the stateful authentication mechanisms were
- implemented and defined in a such a way that directly violates
- RFC2617 - they do not include a "realm" as part of the request. This
- is problematic in SPDY because it makes it impossible for a client to
- disambiguate two concurrent server authentication challenges.
-
-
-
-
-Belshe & Peon Expires August 4, 2012 [Page 36]
-
-Internet-Draft SPDY Feb 2012
-
-
- To deal with this case, SPDY servers using Stateful Authentication
- MUST implement one of two changes:
-
- Servers can add a "realm=<desired realm>" header so that the two
- authentication requests can be disambiguated and run concurrently.
- Unfortunately, given how these mechanisms work, this is probably
- not practical.
-
- Upon sending the first stateful challenge response, the server
- MUST buffer and defer all further frames which are not part of
- completing the challenge until the challenge has completed.
- Completing the authentication challenge may take multiple round
- trips. Once the client receives a "401 Authenticate" response for
- a stateful authentication type, it MUST stop sending new requests
- to the server until the authentication has completed by receiving
- a non-401 response on at least one stream.
-
-3.3. Server Push Transactions
-
- SPDY enables a server to send multiple replies to a client for a
- single request. The rationale for this feature is that sometimes a
- server knows that it will need to send multiple resources in response
- to a single request. Without server push features, the client must
- first download the primary resource, then discover the secondary
- resource(s), and request them. Pushing of resources avoids the
- round-trip delay, but also creates a potential race where a server
- can be pushing content which a user-agent is in the process of
- requesting. The following mechanics attempt to prevent the race
- condition while enabling the performance benefit.
-
- Browsers receiving a pushed response MUST validate that the server is
- authorized to push the URL using the browser same-origin [RFC6454]
- policy. For example, a SPDY connection to www.foo.com is generally
- not permitted to push a response for www.evil.com.
-
- If the browser accepts a pushed response (e.g. it does not send a
- RST_STREAM), the browser MUST attempt to cache the pushed response in
- same way that it would cache any other response. This means
- validating the response headers and inserting into the disk cache.
-
- Because pushed responses have no request, they have no request
- headers associated with them. At the framing layer, SPDY pushed
- streams contain an "associated-stream-id" which indicates the
- requested stream for which the pushed stream is related. The pushed
- stream inherits all of the headers from the associated-stream-id with
- the exception of ":host", ":scheme", and ":path", which are provided
- as part of the pushed response stream headers. The browser MUST
- store these inherited and implied request headers with the cached
-
-
-
-Belshe & Peon Expires August 4, 2012 [Page 37]
-
-Internet-Draft SPDY Feb 2012
-
-
- resource.
-
- Implementation note: With server push, it is theoretically possible
- for servers to push unreasonable amounts of content or resources to
- the user-agent. Browsers MUST implement throttles to protect against
- unreasonable push attacks.
-
-3.3.1. Server implementation
-
- When the server intends to push a resource to the user-agent, it
- opens a new stream by sending a unidirectional SYN_STREAM. The
- SYN_STREAM MUST include an Associated-To-Stream-ID, and MUST set the
- FLAG_UNIDIRECTIONAL flag. The SYN_STREAM MUST include headers for
- ":scheme", ":host", ":path", which represent the URL for the resource
- being pushed. Subsequent headers may follow in HEADERS frames. The
- purpose of the association is so that the user-agent can
- differentiate which request induced the pushed stream; without it, if
- the user-agent had two tabs open to the same page, each pushing
- unique content under a fixed URL, the user-agent would not be able to
- differentiate the requests.
-
- The Associated-To-Stream-ID must be the ID of an existing, open
- stream. The reason for this restriction is to have a clear endpoint
- for pushed content. If the user-agent requested a resource on stream
- 11, the server replies on stream 11. It can push any number of
- additional streams to the client before sending a FLAG_FIN on stream
- 11. However, once the originating stream is closed no further push
- streams may be associated with it. The pushed streams do not need to
- be closed (FIN set) before the originating stream is closed, they
- only need to be created before the originating stream closes.
-
- It is illegal for a server to push a resource with the Associated-To-
- Stream-ID of 0.
-
- To minimize race conditions with the client, the SYN_STREAM for the
- pushed resources MUST be sent prior to sending any content which
- could allow the client to discover the pushed resource and request
- it.
-
- The server MUST only push resources which would have been returned
- from a GET request.
-
- Note: If the server does not have all of the Name/Value Response
- headers available at the time it issues the HEADERS frame for the
- pushed resource, it may later use an additional HEADERS frame to
- augment the name/value pairs to be associated with the pushed stream.
- The subsequent HEADERS frame(s) must not contain a header for
- ':host', ':scheme', or ':path' (e.g. the server can't change the
-
-
-
-Belshe & Peon Expires August 4, 2012 [Page 38]
-
-Internet-Draft SPDY Feb 2012
-
-
- identity of the resource to be pushed). The HEADERS frame must not
- contain duplicate headers with a previously sent HEADERS frame. The
- server must send a HEADERS frame including the scheme/host/port
- headers before sending any data frames on the stream.
-
-3.3.2. Client implementation
-
- When fetching a resource the client has 3 possibilities:
-
- the resource is not being pushed
-
- the resource is being pushed, but the data has not yet arrived
-
- the resource is being pushed, and the data has started to arrive
-
- When a SYN_STREAM and HEADERS frame which contains an Associated-To-
- Stream-ID is received, the client must not issue GET requests for the
- resource in the pushed stream, and instead wait for the pushed stream
- to arrive.
-
- If a client receives a server push stream with stream-id 0, it MUST
- issue a session error (Section 2.4.1) with the status code
- PROTOCOL_ERROR.
-
- When a client receives a SYN_STREAM from the server without a the
- ':host', ':scheme', and ':path' headers in the Name/Value section, it
- MUST reply with a RST_STREAM with error code HTTP_PROTOCOL_ERROR.
-
- To cancel individual server push streams, the client can issue a
- stream error (Section 2.4.2) with error code CANCEL. Upon receipt,
- the server MUST stop sending on this stream immediately (this is an
- Abrupt termination).
-
- To cancel all server push streams related to a request, the client
- may issue a stream error (Section 2.4.2) with error code CANCEL on
- the associated-stream-id. By cancelling that stream, the server MUST
- immediately stop sending frames for any streams with
- in-association-to for the original stream.
-
- If the server sends a HEADER frame containing duplicate headers with
- a previous HEADERS frame for the same stream, the client must issue a
- stream error (Section 2.4.2) with error code PROTOCOL ERROR.
-
- If the server sends a HEADERS frame after sending a data frame for
- the same stream, the client MAY ignore the HEADERS frame. Ignoring
- the HEADERS frame after a data frame prevents handling of HTTP's
- trailing headers
- (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.40).
-
-
-
-Belshe & Peon Expires August 4, 2012 [Page 39]
-
-Internet-Draft SPDY Feb 2012
-
-
-4. Design Rationale and Notes
-
- Authors' notes: The notes in this section have no bearing on the SPDY
- protocol as specified within this document, and none of these notes
- should be considered authoritative about how the protocol works.
- However, these notes may prove useful in future debates about how to
- resolve protocol ambiguities or how to evolve the protocol going
- forward. They may be removed before the final draft.
-
-4.1. Separation of Framing Layer and Application Layer
-
- Readers may note that this specification sometimes blends the framing
- layer (Section 2) with requirements of a specific application - HTTP
- (Section 3). This is reflected in the request/response nature of the
- streams, the definition of the HEADERS and compression contexts which
- are very similar to HTTP, and other areas as well.
-
- This blending is intentional - the primary goal of this protocol is
- to create a low-latency protocol for use with HTTP. Isolating the
- two layers is convenient for description of the protocol and how it
- relates to existing HTTP implementations. However, the ability to
- reuse the SPDY framing layer is a non goal.
-
-4.2. Error handling - Framing Layer
-
- Error handling at the SPDY layer splits errors into two groups: Those
- that affect an individual SPDY stream, and those that do not.
-
- When an error is confined to a single stream, but general framing is
- in tact, SPDY attempts to use the RST_STREAM as a mechanism to
- invalidate the stream but move forward without aborting the
- connection altogether.
-
- For errors occuring outside of a single stream context, SPDY assumes
- the entire session is hosed. In this case, the endpoint detecting
- the error should initiate a connection close.
-
-4.3. One Connection Per Domain
-
- SPDY attempts to use fewer connections than other protocols have
- traditionally used. The rationale for this behavior is because it is
- very difficult to provide a consistent level of service (e.g. TCP
- slow-start), prioritization, or optimal compression when the client
- is connecting to the server through multiple channels.
-
- Through lab measurements, we have seen consistent latency benefits by
- using fewer connections from the client. The overall number of
- packets sent by SPDY can be as much as 40% less than HTTP. Handling
-
-
-
-Belshe & Peon Expires August 4, 2012 [Page 40]
-
-Internet-Draft SPDY Feb 2012
-
-
- large numbers of concurrent connections on the server also does
- become a scalability problem, and SPDY reduces this load.
-
- The use of multiple connections is not without benefit, however.
- Because SPDY multiplexes multiple, independent streams onto a single
- stream, it creates a potential for head-of-line blocking problems at
- the transport level. In tests so far, the negative effects of head-
- of-line blocking (especially in the presence of packet loss) is
- outweighed by the benefits of compression and prioritization.
-
-4.4. Fixed vs Variable Length Fields
-
- SPDY favors use of fixed length 32bit fields in cases where smaller,
- variable length encodings could have been used. To some, this seems
- like a tragic waste of bandwidth. SPDY choses the simple encoding
- for speed and simplicity.
-
- The goal of SPDY is to reduce latency on the network. The overhead
- of SPDY frames is generally quite low. Each data frame is only an 8
- byte overhead for a 1452 byte payload (~0.6%). At the time of this
- writing, bandwidth is already plentiful, and there is a strong trend
- indicating that bandwidth will continue to increase. With an average
- worldwide bandwidth of 1Mbps, and assuming that a variable length
- encoding could reduce the overhead by 50%, the latency saved by using
- a variable length encoding would be less than 100 nanoseconds. More
- interesting are the effects when the larger encodings force a packet
- boundary, in which case a round-trip could be induced. However, by
- addressing other aspects of SPDY and TCP interactions, we believe
- this is completely mitigated.
-
-4.5. Compression Context(s)
-
- When isolating the compression contexts used for communicating with
- multiple origins, we had a few choices to make. We could have
- maintained a map (or list) of compression contexts usable for each
- origin. The basic case is easy - each HEADERS frame would need to
- identify the context to use for that frame. However, compression
- contexts are not cheap, so the lifecycle of each context would need
- to be bounded. For proxy servers, where we could churn through many
- contexts, this would be a concern. We considered using a static set
- of contexts, say 16 of them, which would bound the memory use. We
- also considered dynamic contexts, which could be created on the fly,
- and would need to be subsequently destroyed. All of these are
- complicated, and ultimately we decided that such a mechanism creates
- too many problems to solve.
-
- Alternatively, we've chosen the simple approach, which is to simply
- provide a flag for resetting the compression context. For the common
-
-
-
-Belshe & Peon Expires August 4, 2012 [Page 41]
-
-Internet-Draft SPDY Feb 2012
-
-
- case (no proxy), this fine because most requests are to the same
- origin and we never need to reset the context. For cases where we
- are using two different origins over a single SPDY session, we simply
- reset the compression state between each transition.
-
-4.6. Unidirectional streams
-
- Many readers notice that unidirectional streams are both a bit
- confusing in concept and also somewhat redundant. If the recipient
- of a stream doesn't wish to send data on a stream, it could simply
- send a SYN_REPLY with the FLAG_FIN bit set. The FLAG_UNIDIRECTIONAL
- is, therefore, not necessary.
-
- It is true that we don't need the UNIDIRECTIONAL markings. It is
- added because it avoids the recipient of pushed streams from needing
- to send a set of empty frames (e.g. the SYN_STREAM w/ FLAG_FIN) which
- otherwise serve no purpose.
-
-4.7. Data Compression
-
- Generic compression of data portion of the streams (as opposed to
- compression of the headers) without knowing the content of the stream
- is redundant. There is no value in compressing a stream which is
- already compressed. Because of this, SPDY does allow data
- compression to be optional. We included it because study of existing
- websites shows that many sites are not using compression as they
- should, and users suffer because of it. We wanted a mechanism where,
- at the SPDY layer, site administrators could simply force compression
- - it is better to compress twice than to not compress.
-
- Overall, however, with this feature being optional and sometimes
- redundant, it is unclear if it is useful at all. We will likely
- remove it from the specification.
-
-4.8. Server Push
-
- A subtle but important point is that server push streams must be
- declared before the associated stream is closed. The reason for this
- is so that proxies have a lifetime for which they can discard
- information about previous streams. If a pushed stream could
- associate itself with an already-closed stream, then endpoints would
- not have a specific lifecycle for when they could disavow knowledge
- of the streams which went before.
-
-
-
-
-
-
-
-
-Belshe & Peon Expires August 4, 2012 [Page 42]
-
-Internet-Draft SPDY Feb 2012
-
-
-5. Security Considerations
-
-5.1. Use of Same-origin constraints
-
- This specification uses the same-origin policy [RFC6454] in all cases
- where verification of content is required.
-
-5.2. HTTP Headers and SPDY Headers
-
- At the application level, HTTP uses name/value pairs in its headers.
- Because SPDY merges the existing HTTP headers with SPDY headers,
- there is a possibility that some HTTP applications already use a
- particular header name. To avoid any conflicts, all headers
- introduced for layering HTTP over SPDY are prefixed with ":". ":" is
- not a valid sequence in HTTP header naming, preventing any possible
- conflict.
-
-5.3. Cross-Protocol Attacks
-
- By utilizing TLS, we believe that SPDY introduces no new cross-
- protocol attacks. TLS encrypts the contents of all transmission
- (except the handshake itself), making it difficult for attackers to
- control the data which could be used in a cross-protocol attack.
-
-5.4. Server Push Implicit Headers
-
- Pushed resources do not have an associated request. In order for
- existing HTTP cache control validations (such as the Vary header) to
- work, however, all cached resources must have a set of request
- headers. For this reason, browsers MUST be careful to inherit
- request headers from the associated stream for the push. This
- includes the 'Cookie' header.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Belshe & Peon Expires August 4, 2012 [Page 43]
-
-Internet-Draft SPDY Feb 2012
-
-
-6. Privacy Considerations
-
-6.1. Long Lived Connections
-
- SPDY aims to keep connections open longer between clients and servers
- in order to reduce the latency when a user makes a request. The
- maintenance of these connections over time could be used to expose
- private information. For example, a user using a browser hours after
- the previous user stopped using that browser may be able to learn
- about what the previous user was doing. This is a problem with HTTP
- in its current form as well, however the short lived connections make
- it less of a risk.
-
-6.2. SETTINGS frame
-
- The SPDY SETTINGS frame allows servers to store out-of-band
- transmitted information about the communication between client and
- server on the client. Although this is intended only to be used to
- reduce latency, renegade servers could use it as a mechanism to store
- identifying information about the client in future requests.
-
- Clients implementing privacy modes, such as Google Chrome's
- "incognito mode", may wish to disable client-persisted SETTINGS
- storage.
-
- Clients MUST clear persisted SETTINGS information when clearing the
- cookies.
-
- TODO: Put range maximums on each type of setting to limit
- inappropriate uses.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Belshe & Peon Expires August 4, 2012 [Page 44]
-
-Internet-Draft SPDY Feb 2012
-
-
-7. Incompatibilities with SPDY draft #2
-
- Here is a list of the major changes between this draft and draft #2.
-
- Addition of flow control
-
- Increased 16 bit length fields in SYN_STREAM and SYN_REPLY to 32
- bits.
-
- Changed definition of compression for DATA frames
-
- Updated compression dictionary
-
- Fixed off-by-one on the compression dictionary for headers
-
- Increased priority field from 2bits to 3bits.
-
- Removed NOOP frame
-
- Split the request "url" into "scheme", "host", and "path"
-
- Added the requirement that POSTs contain content-length.
-
- Removed wasted 16bits of unused space from the end of the
- SYN_REPLY and HEADERS frames.
-
- Fixed bug: Priorities were described backward (0 was lowest
- instead of highest).
-
- Fixed bug: Name/Value header counts were duplicated in both the
- Name Value header block and also the containing frame.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Belshe & Peon Expires August 4, 2012 [Page 45]
-
-Internet-Draft SPDY Feb 2012
-
-
-8. Requirements Notation
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119 [RFC2119].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Belshe & Peon Expires August 4, 2012 [Page 46]
-
-Internet-Draft SPDY Feb 2012
-
-
-9. Acknowledgements
-
- Many individuals have contributed to the design and evolution of
- SPDY: Adam Langley, Wan-Teh Chang, Jim Morrison, Mark Nottingham,
- Alyssa Wilk, Costin Manolache, William Chan, Vitaliy Lvin, Joe Chan,
- Adam Barth, Ryan Hamilton, Gavin Peters, Kent Alstad, Kevin Lindsay,
- Paul Amer, Fan Yang, Jonathan Leighton
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Belshe & Peon Expires August 4, 2012 [Page 47]
-
-Internet-Draft SPDY Feb 2012
-
-
-10. Normative References
-
- [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
- RFC 793, September 1981.
-
- [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
- Resource Locators (URL)", RFC 1738, December 1994.
-
- [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format
- Specification version 3.3", RFC 1950, May 1996.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC2285] Mandeville, R., "Benchmarking Terminology for LAN
- Switching Devices", RFC 2285, February 1998.
-
- [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
- Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
- Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
-
- [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
- Leach, P., Luotonen, A., and L. Stewart, "HTTP
- Authentication: Basic and Digest Access Authentication",
- RFC 2617, June 1999.
-
- [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based
- Kerberos and NTLM HTTP Authentication in Microsoft
- Windows", RFC 4559, June 2006.
-
- [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
- and T. Wright, "Transport Layer Security (TLS)
- Extensions", RFC 4366, April 2006.
-
- [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
- (TLS) Protocol Version 1.2", RFC 5246, August 2008.
-
- [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
- December 2011.
-
- [TLSNPN] Langley, A., "TLS Next Protocol Negotiation",
- <http://tools.ietf.org/html/
- draft-agl-tls-nextprotoneg-01>.
-
- [ASCII] "US-ASCII. Coded Character Set - 7-Bit American Standard
- Code for Information Interchange. Standard ANSI X3.4-1986,
- ANSI, 1986.".
-
-
-
-
-Belshe & Peon Expires August 4, 2012 [Page 48]
-
-Internet-Draft SPDY Feb 2012
-
-
- [UDELCOMPRESSION]
- Yang, F., Amer, P., and J. Leighton, "A Methodology to
- Derive SPDY's Initial Dictionary for Zlib Compression",
- <http://www.eecis.udel.edu/~amer/PEL/poc/pdf/
- SPDY-Fan.pdf>.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Belshe & Peon Expires August 4, 2012 [Page 49]
-
-Internet-Draft SPDY Feb 2012
-
-
-Appendix A. Changes
-
- To be removed by RFC Editor before publication
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Belshe & Peon Expires August 4, 2012 [Page 50]
-
-Internet-Draft SPDY Feb 2012
-
-
-Authors' Addresses
-
- Mike Belshe
- Twist
-
- Email: address@hidden
-
-
- Roberto Peon
- Google, Inc
-
- Email: address@hidden
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Belshe & Peon Expires August 4, 2012 [Page 51]
-
Modified: libmicrohttpd/src/Makefile.am
===================================================================
--- libmicrohttpd/src/Makefile.am 2013-05-24 07:57:26 UTC (rev 27280)
+++ libmicrohttpd/src/Makefile.am 2013-05-24 08:50:24 UTC (rev 27281)
@@ -19,4 +19,5 @@
EXTRA_DIST = \
datadir/cert-and-key.pem \
- datadir/cert-and-key-for-wireshark.pem
+ datadir/cert-and-key-for-wireshark.pem \
+ datadir/spdy-draft.txt
Copied: libmicrohttpd/src/datadir/spdy-draft.txt (from rev 27278,
libmicrohttpd/doc/spdy-draft.txt)
===================================================================
--- libmicrohttpd/src/datadir/spdy-draft.txt (rev 0)
+++ libmicrohttpd/src/datadir/spdy-draft.txt 2013-05-24 08:50:24 UTC (rev
27281)
@@ -0,0 +1,2856 @@
+
+
+
+Network Working Group M. Belshe
+Internet-Draft Twist
+Expires: August 4, 2012 R. Peon
+ Google, Inc
+ Feb 2012
+
+
+ SPDY Protocol
+ draft-mbelshe-httpbis-spdy-00
+
+Abstract
+
+ This document describes SPDY, a protocol designed for low-latency
+ transport of content over the World Wide Web. SPDY introduces two
+ layers of protocol. The lower layer is a general purpose framing
+ layer which can be used atop a reliable transport (likely TCP) for
+ multiplexed, prioritized, and compressed data communication of many
+ concurrent streams. The upper layer of the protocol provides HTTP-
+ like RFC2616 [RFC2616] semantics for compatibility with existing HTTP
+ application servers.
+
+Status of this Memo
+
+ This Internet-Draft is submitted in full conformance with the
+ provisions of BCP 78 and BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF). Note that other groups may also distribute
+ working documents as Internet-Drafts. The list of current Internet-
+ Drafts is at http://datatracker.ietf.org/drafts/current/.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ This Internet-Draft will expire on August 4, 2012.
+
+Copyright Notice
+
+ Copyright (c) 2012 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+
+
+
+Belshe & Peon Expires August 4, 2012 [Page 1]
+
+Internet-Draft SPDY Feb 2012
+
+
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+Table of Contents
+
+ 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 1.1. Document Organization . . . . . . . . . . . . . . . . . . 4
+ 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
+ 2. SPDY Framing Layer . . . . . . . . . . . . . . . . . . . . . . 6
+ 2.1. Session (Connections) . . . . . . . . . . . . . . . . . . 6
+ 2.2. Framing . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 2.2.1. Control frames . . . . . . . . . . . . . . . . . . . . 6
+ 2.2.2. Data frames . . . . . . . . . . . . . . . . . . . . . 7
+ 2.3. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 2.3.1. Stream frames . . . . . . . . . . . . . . . . . . . . 9
+ 2.3.2. Stream creation . . . . . . . . . . . . . . . . . . . 9
+ 2.3.3. Stream priority . . . . . . . . . . . . . . . . . . . 10
+ 2.3.4. Stream headers . . . . . . . . . . . . . . . . . . . . 10
+ 2.3.5. Stream data exchange . . . . . . . . . . . . . . . . . 10
+ 2.3.6. Stream half-close . . . . . . . . . . . . . . . . . . 10
+ 2.3.7. Stream close . . . . . . . . . . . . . . . . . . . . . 11
+ 2.4. Error Handling . . . . . . . . . . . . . . . . . . . . . . 11
+ 2.4.1. Session Error Handling . . . . . . . . . . . . . . . . 11
+ 2.4.2. Stream Error Handling . . . . . . . . . . . . . . . . 12
+ 2.5. Data flow . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 2.6. Control frame types . . . . . . . . . . . . . . . . . . . 12
+ 2.6.1. SYN_STREAM . . . . . . . . . . . . . . . . . . . . . . 12
+ 2.6.2. SYN_REPLY . . . . . . . . . . . . . . . . . . . . . . 14
+ 2.6.3. RST_STREAM . . . . . . . . . . . . . . . . . . . . . . 15
+ 2.6.4. SETTINGS . . . . . . . . . . . . . . . . . . . . . . . 16
+ 2.6.5. PING . . . . . . . . . . . . . . . . . . . . . . . . . 19
+ 2.6.6. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . . 20
+ 2.6.7. HEADERS . . . . . . . . . . . . . . . . . . . . . . . 21
+ 2.6.8. WINDOW_UPDATE . . . . . . . . . . . . . . . . . . . . 22
+ 2.6.9. CREDENTIAL . . . . . . . . . . . . . . . . . . . . . . 24
+ 2.6.10. Name/Value Header Block . . . . . . . . . . . . . . . 26
+ 3. HTTP Layering over SPDY . . . . . . . . . . . . . . . . . . . 33
+ 3.1. Connection Management . . . . . . . . . . . . . . . . . . 33
+ 3.1.1. Use of GOAWAY . . . . . . . . . . . . . . . . . . . . 33
+ 3.2. HTTP Request/Response . . . . . . . . . . . . . . . . . . 34
+ 3.2.1. Request . . . . . . . . . . . . . . . . . . . . . . . 34
+ 3.2.2. Response . . . . . . . . . . . . . . . . . . . . . . . 35
+ 3.2.3. Authentication . . . . . . . . . . . . . . . . . . . . 36
+ 3.3. Server Push Transactions . . . . . . . . . . . . . . . . . 37
+ 3.3.1. Server implementation . . . . . . . . . . . . . . . . 38
+
+
+
+Belshe & Peon Expires August 4, 2012 [Page 2]
+
+Internet-Draft SPDY Feb 2012
+
+
+ 3.3.2. Client implementation . . . . . . . . . . . . . . . . 39
+ 4. Design Rationale and Notes . . . . . . . . . . . . . . . . . . 40
+ 4.1. Separation of Framing Layer and Application Layer . . . . 40
+ 4.2. Error handling - Framing Layer . . . . . . . . . . . . . . 40
+ 4.3. One Connection Per Domain . . . . . . . . . . . . . . . . 40
+ 4.4. Fixed vs Variable Length Fields . . . . . . . . . . . . . 41
+ 4.5. Compression Context(s) . . . . . . . . . . . . . . . . . . 41
+ 4.6. Unidirectional streams . . . . . . . . . . . . . . . . . . 42
+ 4.7. Data Compression . . . . . . . . . . . . . . . . . . . . . 42
+ 4.8. Server Push . . . . . . . . . . . . . . . . . . . . . . . 42
+ 5. Security Considerations . . . . . . . . . . . . . . . . . . . 43
+ 5.1. Use of Same-origin constraints . . . . . . . . . . . . . . 43
+ 5.2. HTTP Headers and SPDY Headers . . . . . . . . . . . . . . 43
+ 5.3. Cross-Protocol Attacks . . . . . . . . . . . . . . . . . . 43
+ 5.4. Server Push Implicit Headers . . . . . . . . . . . . . . . 43
+ 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 44
+ 6.1. Long Lived Connections . . . . . . . . . . . . . . . . . . 44
+ 6.2. SETTINGS frame . . . . . . . . . . . . . . . . . . . . . . 44
+ 7. Incompatibilities with SPDY draft #2 . . . . . . . . . . . . . 45
+ 8. Requirements Notation . . . . . . . . . . . . . . . . . . . . 46
+ 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 47
+ 10. Normative References . . . . . . . . . . . . . . . . . . . . . 48
+ Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 50
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Belshe & Peon Expires August 4, 2012 [Page 3]
+
+Internet-Draft SPDY Feb 2012
+
+
+1. Overview
+
+ One of the bottlenecks of HTTP implementations is that HTTP relies on
+ multiple connections for concurrency. This causes several problems,
+ including additional round trips for connection setup, slow-start
+ delays, and connection rationing by the client, where it tries to
+ avoid opening too many connections to any single server. HTTP
+ pipelining helps some, but only achieves partial multiplexing. In
+ addition, pipelining has proven non-deployable in existing browsers
+ due to intermediary interference.
+
+ SPDY adds a framing layer for multiplexing multiple, concurrent
+ streams across a single TCP connection (or any reliable transport
+ stream). The framing layer is optimized for HTTP-like request-
+ response streams, such that applications which run over HTTP today
+ can work over SPDY with little or no change on behalf of the web
+ application writer.
+
+ The SPDY session offers four improvements over HTTP:
+
+ Multiplexed requests: There is no limit to the number of requests
+ that can be issued concurrently over a single SPDY connection.
+
+ Prioritized requests: Clients can request certain resources to be
+ delivered first. This avoids the problem of congesting the
+ network channel with non-critical resources when a high-priority
+ request is pending.
+
+ Compressed headers: Clients today send a significant amount of
+ redundant data in the form of HTTP headers. Because a single web
+ page may require 50 or 100 subrequests, this data is significant.
+
+ Server pushed streams: Server Push enables content to be pushed
+ from servers to clients without a request.
+
+ SPDY attempts to preserve the existing semantics of HTTP. All
+ features such as cookies, ETags, Vary headers, Content-Encoding
+ negotiations, etc work as they do with HTTP; SPDY only replaces the
+ way the data is written to the network.
+
+1.1. Document Organization
+
+ The SPDY Specification is split into two parts: a framing layer
+ (Section 2), which multiplexes a TCP connection into independent,
+ length-prefixed frames, and an HTTP layer (Section 3), which
+ specifies the mechanism for overlaying HTTP request/response pairs on
+ top of the framing layer. While some of the framing layer concepts
+ are isolated from the HTTP layer, building a generic framing layer
+
+
+
+Belshe & Peon Expires August 4, 2012 [Page 4]
+
+Internet-Draft SPDY Feb 2012
+
+
+ has not been a goal. The framing layer is tailored to the needs of
+ the HTTP protocol and server push.
+
+1.2. Definitions
+
+ client: The endpoint initiating the SPDY session.
+
+ connection: A transport-level connection between two endpoints.
+
+ endpoint: Either the client or server of a connection.
+
+ frame: A header-prefixed sequence of bytes sent over a SPDY
+ session.
+
+ server: The endpoint which did not initiate the SPDY session.
+
+ session: A synonym for a connection.
+
+ session error: An error on the SPDY session.
+
+ stream: A bi-directional flow of bytes across a virtual channel
+ within a SPDY session.
+
+ stream error: An error on an individual SPDY stream.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Belshe & Peon Expires August 4, 2012 [Page 5]
+
+Internet-Draft SPDY Feb 2012
+
+
+2. SPDY Framing Layer
+
+2.1. Session (Connections)
+
+ The SPDY framing layer (or "session") runs atop a reliable transport
+ layer such as TCP [RFC0793]. The client is the TCP connection
+ initiator. SPDY connections are persistent connections.
+
+ For best performance, it is expected that clients will not close open
+ connections until the user navigates away from all web pages
+ referencing a connection, or until the server closes the connection.
+ Servers are encouraged to leave connections open for as long as
+ possible, but can terminate idle connections if necessary. When
+ either endpoint closes the transport-level connection, it MUST first
+ send a GOAWAY (Section 2.6.6) frame so that the endpoints can
+ reliably determine if requests finished before the close.
+
+2.2. Framing
+
+ Once the connection is established, clients and servers exchange
+ framed messages. There are two types of frames: control frames
+ (Section 2.2.1) and data frames (Section 2.2.2). Frames always have
+ a common header which is 8 bytes in length.
+
+ The first bit is a control bit indicating whether a frame is a
+ control frame or data frame. Control frames carry a version number,
+ a frame type, flags, and a length. Data frames contain the stream
+ ID, flags, and the length for the payload carried after the common
+ header. The simple header is designed to make reading and writing of
+ frames easy.
+
+ All integer values, including length, version, and type, are in
+ network byte order. SPDY does not enforce alignment of types in
+ dynamically sized frames.
+
+2.2.1. Control frames
+
+ +----------------------------------+
+ |C| Version(15bits) | Type(16bits) |
+ +----------------------------------+
+ | Flags (8) | Length (24 bits) |
+ +----------------------------------+
+ | Data |
+ +----------------------------------+
+
+ Control bit: The 'C' bit is a single bit indicating if this is a
+ control message. For control frames this value is always 1.
+
+
+
+
+Belshe & Peon Expires August 4, 2012 [Page 6]
+
+Internet-Draft SPDY Feb 2012
+
+
+ Version: The version number of the SPDY protocol. This document
+ describes SPDY version 3.
+
+ Type: The type of control frame. See Control Frames for the complete
+ list of control frames.
+
+ Flags: Flags related to this frame. Flags for control frames and
+ data frames are different.
+
+ Length: An unsigned 24-bit value representing the number of bytes
+ after the length field.
+
+ Data: data associated with this control frame. The format and length
+ of this data is controlled by the control frame type.
+
+ Control frame processing requirements:
+
+ Note that full length control frames (16MB) can be large for
+ implementations running on resource-limited hardware. In such
+ cases, implementations MAY limit the maximum length frame
+ supported. However, all implementations MUST be able to receive
+ control frames of at least 8192 octets in length.
+
+2.2.2. Data frames
+
+ +----------------------------------+
+ |C| Stream-ID (31bits) |
+ +----------------------------------+
+ | Flags (8) | Length (24 bits) |
+ +----------------------------------+
+ | Data |
+ +----------------------------------+
+
+ Control bit: For data frames this value is always 0.
+
+ Stream-ID: A 31-bit value identifying the stream.
+
+ Flags: Flags related to this frame. Valid flags are:
+
+ 0x01 = FLAG_FIN - signifies that this frame represents the last
+ frame to be transmitted on this stream. See Stream Close
+ (Section 2.3.7) below.
+
+ 0x02 = FLAG_COMPRESS - indicates that the data in this frame has
+ been compressed.
+
+ Length: An unsigned 24-bit value representing the number of bytes
+ after the length field. The total size of a data frame is 8 bytes +
+
+
+
+Belshe & Peon Expires August 4, 2012 [Page 7]
+
+Internet-Draft SPDY Feb 2012
+
+
+ length. It is valid to have a zero-length data frame.
+
+ Data: The variable-length data payload; the length was defined in the
+ length field.
+
+ Data frame processing requirements:
+
+ If an endpoint receives a data frame for a stream-id which is not
+ open and the endpoint has not sent a GOAWAY (Section 2.6.6) frame,
+ it MUST send issue a stream error (Section 2.4.2) with the error
+ code INVALID_STREAM for the stream-id.
+
+ If the endpoint which created the stream receives a data frame
+ before receiving a SYN_REPLY on that stream, it is a protocol
+ error, and the recipient MUST issue a stream error (Section 2.4.2)
+ with the status code PROTOCOL_ERROR for the stream-id.
+
+ Implementors note: If an endpoint receives multiple data frames
+ for invalid stream-ids, it MAY close the session.
+
+ All SPDY endpoints MUST accept compressed data frames.
+ Compression of data frames is always done using zlib compression.
+ Each stream initializes and uses its own compression context
+ dedicated to use within that stream. Endpoints are encouraged to
+ use application level compression rather than SPDY stream level
+ compression.
+
+ Each SPDY stream sending compressed frames creates its own zlib
+ context for that stream, and these compression contexts MUST be
+ distinct from the compression contexts used with SYN_STREAM/
+ SYN_REPLY/HEADER compression. (Thus, if both endpoints of a
+ stream are compressing data on the stream, there will be two zlib
+ contexts, one for sending and one for receiving).
+
+2.3. Streams
+
+ Streams are independent sequences of bi-directional data divided into
+ frames with several properties:
+
+ Streams may be created by either the client or server.
+
+ Streams optionally carry a set of name/value header pairs.
+
+ Streams can concurrently send data interleaved with other streams.
+
+ Streams may be cancelled.
+
+
+
+
+
+Belshe & Peon Expires August 4, 2012 [Page 8]
+
+Internet-Draft SPDY Feb 2012
+
+
+2.3.1. Stream frames
+
+ SPDY defines 3 control frames to manage the lifecycle of a stream:
+
+ SYN_STREAM - Open a new stream
+
+ SYN_REPLY - Remote acknowledgement of a new, open stream
+
+ RST_STREAM - Close a stream
+
+2.3.2. Stream creation
+
+ A stream is created by sending a control frame with the type set to
+ SYN_STREAM (Section 2.6.1). If the server is initiating the stream,
+ the Stream-ID must be even. If the client is initiating the stream,
+ the Stream-ID must be odd. 0 is not a valid Stream-ID. Stream-IDs
+ from each side of the connection must increase monotonically as new
+ streams are created. E.g. Stream 2 may be created after stream 3,
+ but stream 7 must not be created after stream 9. Stream IDs do not
+ wrap: when a client or server cannot create a new stream id without
+ exceeding a 31 bit value, it MUST NOT create a new stream.
+
+ The stream-id MUST increase with each new stream. If an endpoint
+ receives a SYN_STREAM with a stream id which is less than any
+ previously received SYN_STREAM, it MUST issue a session error
+ (Section 2.4.1) with the status PROTOCOL_ERROR.
+
+ It is a protocol error to send two SYN_STREAMs with the same
+ stream-id. If a recipient receives a second SYN_STREAM for the same
+ stream, it MUST issue a stream error (Section 2.4.2) with the status
+ code PROTOCOL_ERROR.
+
+ Upon receipt of a SYN_STREAM, the recipient can reject the stream by
+ sending a stream error (Section 2.4.2) with the error code
+ REFUSED_STREAM. Note, however, that the creating endpoint may have
+ already sent additional frames for that stream which cannot be
+ immediately stopped.
+
+ Once the stream is created, the creator may immediately send HEADERS
+ or DATA frames for that stream, without needing to wait for the
+ recipient to acknowledge.
+
+2.3.2.1. Unidirectional streams
+
+ When an endpoint creates a stream with the FLAG_UNIDIRECTIONAL flag
+ set, it creates a unidirectional stream which the creating endpoint
+ can use to send frames, but the receiving endpoint cannot. The
+ receiving endpoint is implicitly already in the half-closed
+
+
+
+Belshe & Peon Expires August 4, 2012 [Page 9]
+
+Internet-Draft SPDY Feb 2012
+
+
+ (Section 2.3.6) state.
+
+2.3.2.2. Bidirectional streams
+
+ SYN_STREAM frames which do not use the FLAG_UNIDIRECTIONAL flag are
+ bidirectional streams. Both endpoints can send data on a bi-
+ directional stream.
+
+2.3.3. Stream priority
+
+ The creator of a stream assigns a priority for that stream. Priority
+ is represented as an integer from 0 to 7. 0 represents the highest
+ priority and 7 represents the lowest priority.
+
+ The sender and recipient SHOULD use best-effort to process streams in
+ the order of highest priority to lowest priority.
+
+2.3.4. Stream headers
+
+ Streams carry optional sets of name/value pair headers which carry
+ metadata about the stream. After the stream has been created, and as
+ long as the sender is not closed (Section 2.3.7) or half-closed
+ (Section 2.3.6), each side may send HEADERS frame(s) containing the
+ header data. Header data can be sent in multiple HEADERS frames, and
+ HEADERS frames may be interleaved with data frames.
+
+2.3.5. Stream data exchange
+
+ Once a stream is created, it can be used to send arbitrary amounts of
+ data. Generally this means that a series of data frames will be sent
+ on the stream until a frame containing the FLAG_FIN flag is set. The
+ FLAG_FIN can be set on a SYN_STREAM (Section 2.6.1), SYN_REPLY
+ (Section 2.6.2), HEADERS (Section 2.6.7) or a DATA (Section 2.2.2)
+ frame. Once the FLAG_FIN has been sent, the stream is considered to
+ be half-closed.
+
+2.3.6. Stream half-close
+
+ When one side of the stream sends a frame with the FLAG_FIN flag set,
+ the stream is half-closed from that endpoint. The sender of the
+ FLAG_FIN MUST NOT send further frames on that stream. When both
+ sides have half-closed, the stream is closed.
+
+ If an endpoint receives a data frame after the stream is half-closed
+ from the sender (e.g. the endpoint has already received a prior frame
+ for the stream with the FIN flag set), it MUST send a RST_STREAM to
+ the sender with the status STREAM_ALREADY_CLOSED.
+
+
+
+
+Belshe & Peon Expires August 4, 2012 [Page 10]
+
+Internet-Draft SPDY Feb 2012
+
+
+2.3.7. Stream close
+
+ There are 3 ways that streams can be terminated:
+
+ Normal termination: Normal stream termination occurs when both
+ sender and recipient have half-closed the stream by sending a
+ FLAG_FIN.
+
+ Abrupt termination: Either the client or server can send a
+ RST_STREAM control frame at any time. A RST_STREAM contains an
+ error code to indicate the reason for failure. When a RST_STREAM
+ is sent from the stream originator, it indicates a failure to
+ complete the stream and that no further data will be sent on the
+ stream. When a RST_STREAM is sent from the stream recipient, the
+ sender, upon receipt, should stop sending any data on the stream.
+ The stream recipient should be aware that there is a race between
+ data already in transit from the sender and the time the
+ RST_STREAM is received. See Stream Error Handling (Section 2.4.2)
+
+ TCP connection teardown: If the TCP connection is torn down while
+ un-closed streams exist, then the endpoint must assume that the
+ stream was abnormally interrupted and may be incomplete.
+
+ If an endpoint receives a data frame after the stream is closed, it
+ must send a RST_STREAM to the sender with the status PROTOCOL_ERROR.
+
+2.4. Error Handling
+
+ The SPDY framing layer has only two types of errors, and they are
+ always handled consistently. Any reference in this specification to
+ "issue a session error" refers to Section 2.4.1. Any reference to
+ "issue a stream error" refers to Section 2.4.2.
+
+2.4.1. Session Error Handling
+
+ A session error is any error which prevents further processing of the
+ framing layer or which corrupts the session compression state. When
+ a session error occurs, the endpoint encountering the error MUST
+ first send a GOAWAY (Section 2.6.6) frame with the stream id of most
+ recently received stream from the remote endpoint, and the error code
+ for why the session is terminating. After sending the GOAWAY frame,
+ the endpoint MUST close the TCP connection.
+
+ Note that the session compression state is dependent upon both
+ endpoints always processing all compressed data. If an endpoint
+ partially processes a frame containing compressed data without
+ updating compression state properly, future control frames which use
+ compression will be always be errored. Implementations SHOULD always
+
+
+
+Belshe & Peon Expires August 4, 2012 [Page 11]
+
+Internet-Draft SPDY Feb 2012
+
+
+ try to process compressed data so that errors which could be handled
+ as stream errors do not become session errors.
+
+ Note that because this GOAWAY is sent during a session error case, it
+ is possible that the GOAWAY will not be reliably received by the
+ receiving endpoint. It is a best-effort attempt to communicate with
+ the remote about why the session is going down.
+
+2.4.2. Stream Error Handling
+
+ A stream error is an error related to a specific stream-id which does
+ not affect processing of other streams at the framing layer. Upon a
+ stream error, the endpoint MUST send a RST_STREAM (Section 2.6.3)
+ frame which contains the stream id of the stream where the error
+ occurred and the error status which caused the error. After sending
+ the RST_STREAM, the stream is closed to the sending endpoint. After
+ sending the RST_STREAM, if the sender receives any frames other than
+ a RST_STREAM for that stream id, it will result in sending additional
+ RST_STREAM frames. An endpoint MUST NOT send a RST_STREAM in
+ response to an RST_STREAM, as doing so would lead to RST_STREAM
+ loops. Sending a RST_STREAM does not cause the SPDY session to be
+ closed.
+
+ If an endpoint has multiple RST_STREAM frames to send in succession
+ for the same stream-id and the same error code, it MAY coalesce them
+ into a single RST_STREAM frame. (This can happen if a stream is
+ closed, but the remote sends multiple data frames. There is no
+ reason to send a RST_STREAM for each frame in succession).
+
+2.5. Data flow
+
+ Because TCP provides a single stream of data on which SPDY
+ multiplexes multiple logical streams, clients and servers must
+ intelligently interleave data messages for concurrent sessions.
+
+2.6. Control frame types
+
+2.6.1. SYN_STREAM
+
+ The SYN_STREAM control frame allows the sender to asynchronously
+ create a stream between the endpoints. See Stream Creation
+ (Section 2.3.2)
+
+
+
+
+
+
+
+
+
+Belshe & Peon Expires August 4, 2012 [Page 12]
+
+Internet-Draft SPDY Feb 2012
+
+
++------------------------------------+
+|1| version | 1 |
++------------------------------------+
+| Flags (8) | Length (24 bits) |
++------------------------------------+
+|X| Stream-ID (31bits) |
++------------------------------------+
+|X| Associated-To-Stream-ID (31bits) |
++------------------------------------+
+| Pri|Unused | Slot | |
++-------------------+ |
+| Number of Name/Value pairs (int32) | <+
++------------------------------------+ |
+| Length of name (int32) | | This section is the "Name/Value
++------------------------------------+ | Header Block", and is compressed.
+| Name (string) | |
++------------------------------------+ |
+| Length of value (int32) | |
++------------------------------------+ |
+| Value (string) | |
++------------------------------------+ |
+| (repeats) | <+
+
+ Flags: Flags related to this frame. Valid flags are:
+
+ 0x01 = FLAG_FIN - marks this frame as the last frame to be
+ transmitted on this stream and puts the sender in the half-closed
+ (Section 2.3.6) state.
+
+ 0x02 = FLAG_UNIDIRECTIONAL - a stream created with this flag puts
+ the recipient in the half-closed (Section 2.3.6) state.
+
+ Length: The length is the number of bytes which follow the length
+ field in the frame. For SYN_STREAM frames, this is 10 bytes plus the
+ length of the compressed Name/Value block.
+
+ Stream-ID: The 31-bit identifier for this stream. This stream-id
+ will be used in frames which are part of this stream.
+
+ Associated-To-Stream-ID: The 31-bit identifier for a stream which
+ this stream is associated to. If this stream is independent of all
+ other streams, it should be 0.
+
+ Priority: A 3-bit priority (Section 2.3.3) field.
+
+ Unused: 5 bits of unused space, reserved for future use.
+
+ Slot: An 8 bit unsigned integer specifying the index in the server's
+
+
+
+Belshe & Peon Expires August 4, 2012 [Page 13]
+
+Internet-Draft SPDY Feb 2012
+
+
+ CREDENTIAL vector of the client certificate to be used for this
+ request. see CREDENTIAL frame (Section 2.6.9). The value 0 means no
+ client certificate should be associated with this stream.
+
+ Name/Value Header Block: A set of name/value pairs carried as part of
+ the SYN_STREAM. see Name/Value Header Block (Section 2.6.10).
+
+ If an endpoint receives a SYN_STREAM which is larger than the
+ implementation supports, it MAY send a RST_STREAM with error code
+ FRAME_TOO_LARGE. All implementations MUST support the minimum size
+ limits defined in the Control Frames section (Section 2.2.1).
+
+2.6.2. SYN_REPLY
+
+ SYN_REPLY indicates the acceptance of a stream creation by the
+ recipient of a SYN_STREAM frame.
+
++------------------------------------+
+|1| version | 2 |
++------------------------------------+
+| Flags (8) | Length (24 bits) |
++------------------------------------+
+|X| Stream-ID (31bits) |
++------------------------------------+
+| Number of Name/Value pairs (int32) | <+
++------------------------------------+ |
+| Length of name (int32) | | This section is the "Name/Value
++------------------------------------+ | Header Block", and is compressed.
+| Name (string) | |
++------------------------------------+ |
+| Length of value (int32) | |
++------------------------------------+ |
+| Value (string) | |
++------------------------------------+ |
+| (repeats) | <+
+
+ Flags: Flags related to this frame. Valid flags are:
+
+ 0x01 = FLAG_FIN - marks this frame as the last frame to be
+ transmitted on this stream and puts the sender in the half-closed
+ (Section 2.3.6) state.
+
+ Length: The length is the number of bytes which follow the length
+ field in the frame. For SYN_REPLY frames, this is 4 bytes plus the
+ length of the compressed Name/Value block.
+
+ Stream-ID: The 31-bit identifier for this stream.
+
+
+
+
+Belshe & Peon Expires August 4, 2012 [Page 14]
+
+Internet-Draft SPDY Feb 2012
+
+
+ If an endpoint receives multiple SYN_REPLY frames for the same active
+ stream ID, it MUST issue a stream error (Section 2.4.2) with the
+ error code STREAM_IN_USE.
+
+ Name/Value Header Block: A set of name/value pairs carried as part of
+ the SYN_STREAM. see Name/Value Header Block (Section 2.6.10).
+
+ If an endpoint receives a SYN_REPLY which is larger than the
+ implementation supports, it MAY send a RST_STREAM with error code
+ FRAME_TOO_LARGE. All implementations MUST support the minimum size
+ limits defined in the Control Frames section (Section 2.2.1).
+
+2.6.3. RST_STREAM
+
+ The RST_STREAM frame allows for abnormal termination of a stream.
+ When sent by the creator of a stream, it indicates the creator wishes
+ to cancel the stream. When sent by the recipient of a stream, it
+ indicates an error or that the recipient did not want to accept the
+ stream, so the stream should be closed.
+
+ +----------------------------------+
+ |1| version | 3 |
+ +----------------------------------+
+ | Flags (8) | 8 |
+ +----------------------------------+
+ |X| Stream-ID (31bits) |
+ +----------------------------------+
+ | Status code |
+ +----------------------------------+
+
+ Flags: Flags related to this frame. RST_STREAM does not define any
+ flags. This value must be 0.
+
+ Length: An unsigned 24-bit value representing the number of bytes
+ after the length field. For RST_STREAM control frames, this value is
+ always 8.
+
+ Stream-ID: The 31-bit identifier for this stream.
+
+ Status code: (32 bits) An indicator for why the stream is being
+ terminated.The following status codes are defined:
+
+ 1 - PROTOCOL_ERROR. This is a generic error, and should only be
+ used if a more specific error is not available.
+
+ 2 - INVALID_STREAM. This is returned when a frame is received for
+ a stream which is not active.
+
+
+
+
+Belshe & Peon Expires August 4, 2012 [Page 15]
+
+Internet-Draft SPDY Feb 2012
+
+
+ 3 - REFUSED_STREAM. Indicates that the stream was refused before
+ any processing has been done on the stream.
+
+ 4 - UNSUPPORTED_VERSION. Indicates that the recipient of a stream
+ does not support the SPDY version requested.
+
+ 5 - CANCEL. Used by the creator of a stream to indicate that the
+ stream is no longer needed.
+
+ 6 - INTERNAL_ERROR. This is a generic error which can be used
+ when the implementation has internally failed, not due to anything
+ in the protocol.
+
+ 7 - FLOW_CONTROL_ERROR. The endpoint detected that its peer
+ violated the flow control protocol.
+
+ 8 - STREAM_IN_USE. The endpoint received a SYN_REPLY for a stream
+ already open.
+
+ 9 - STREAM_ALREADY_CLOSED. The endpoint received a data or
+ SYN_REPLY frame for a stream which is half closed.
+
+ 10 - INVALID_CREDENTIALS. The server received a request for a
+ resource whose origin does not have valid credentials in the
+ client certificate vector.
+
+ 11 - FRAME_TOO_LARGE. The endpoint received a frame which this
+ implementation could not support. If FRAME_TOO_LARGE is sent for
+ a SYN_STREAM, HEADERS, or SYN_REPLY frame without fully processing
+ the compressed portion of those frames, then the compression state
+ will be out-of-sync with the other endpoint. In this case,
+ senders of FRAME_TOO_LARGE MUST close the session.
+
+ Note: 0 is not a valid status code for a RST_STREAM.
+
+ After receiving a RST_STREAM on a stream, the recipient must not send
+ additional frames for that stream, and the stream moves into the
+ closed state.
+
+2.6.4. SETTINGS
+
+ A SETTINGS frame contains a set of id/value pairs for communicating
+ configuration data about how the two endpoints may communicate.
+ SETTINGS frames can be sent at any time by either endpoint, are
+ optionally sent, and are fully asynchronous. When the server is the
+ sender, the sender can request that configuration data be persisted
+ by the client across SPDY sessions and returned to the server in
+ future communications.
+
+
+
+Belshe & Peon Expires August 4, 2012 [Page 16]
+
+Internet-Draft SPDY Feb 2012
+
+
+ Persistence of SETTINGS ID/Value pairs is done on a per origin/IP
+ pair (the "origin" is the set of scheme, host, and port from the URI.
+ See [RFC6454]). That is, when a client connects to a server, and the
+ server persists settings within the client, the client SHOULD return
+ the persisted settings on future connections to the same origin AND
+ IP address and TCP port. Clients MUST NOT request servers to use the
+ persistence features of the SETTINGS frames, and servers MUST ignore
+ persistence related flags sent by a client.
+
+ +----------------------------------+
+ |1| version | 4 |
+ +----------------------------------+
+ | Flags (8) | Length (24 bits) |
+ +----------------------------------+
+ | Number of entries |
+ +----------------------------------+
+ | ID/Value Pairs |
+ | ... |
+
+ Control bit: The control bit is always 1 for this message.
+
+ Version: The SPDY version number.
+
+ Type: The message type for a SETTINGS message is 4.
+
+ Flags: FLAG_SETTINGS_CLEAR_SETTINGS (0x1): When set, the client
+ should clear any previously persisted SETTINGS ID/Value pairs. If
+ this frame contains ID/Value pairs with the
+ FLAG_SETTINGS_PERSIST_VALUE set, then the client will first clear its
+ existing, persisted settings, and then persist the values with the
+ flag set which are contained within this frame. Because persistence
+ is only implemented on the client, this flag can only be used when
+ the sender is the server.
+
+ Length: An unsigned 24-bit value representing the number of bytes
+ after the length field. The total size of a SETTINGS frame is 8
+ bytes + length.
+
+ Number of entries: A 32-bit value representing the number of ID/value
+ pairs in this message.
+
+ ID: A 32-bit ID number, comprised of 8 bits of flags and 24 bits of
+ unique ID.
+
+ ID.flags:
+
+ FLAG_SETTINGS_PERSIST_VALUE (0x1): When set, the sender of this
+ SETTINGS frame is requesting that the recipient persist the ID/
+
+
+
+Belshe & Peon Expires August 4, 2012 [Page 17]
+
+Internet-Draft SPDY Feb 2012
+
+
+ Value and return it in future SETTINGS frames sent from the
+ sender to this recipient. Because persistence is only
+ implemented on the client, this flag is only sent by the
+ server.
+
+ FLAG_SETTINGS_PERSISTED (0x2): When set, the sender is
+ notifying the recipient that this ID/Value pair was previously
+ sent to the sender by the recipient with the
+ FLAG_SETTINGS_PERSIST_VALUE, and the sender is returning it.
+ Because persistence is only implemented on the client, this
+ flag is only sent by the client.
+
+ Defined IDs:
+
+ 1 - SETTINGS_UPLOAD_BANDWIDTH allows the sender to send its
+ expected upload bandwidth on this channel. This number is an
+ estimate. The value should be the integral number of kilobytes
+ per second that the sender predicts as an expected maximum
+ upload channel capacity.
+
+ 2 - SETTINGS_DOWNLOAD_BANDWIDTH allows the sender to send its
+ expected download bandwidth on this channel. This number is an
+ estimate. The value should be the integral number of kilobytes
+ per second that the sender predicts as an expected maximum
+ download channel capacity.
+
+ 3 - SETTINGS_ROUND_TRIP_TIME allows the sender to send its
+ expected round-trip-time on this channel. The round trip time
+ is defined as the minimum amount of time to send a control
+ frame from this client to the remote and receive a response.
+ The value is represented in milliseconds.
+
+ 4 - SETTINGS_MAX_CONCURRENT_STREAMS allows the sender to inform
+ the remote endpoint the maximum number of concurrent streams
+ which it will allow. By default there is no limit. For
+ implementors it is recommended that this value be no smaller
+ than 100.
+
+ 5 - SETTINGS_CURRENT_CWND allows the sender to inform the
+ remote endpoint of the current TCP CWND value.
+
+ 6 - SETTINGS_DOWNLOAD_RETRANS_RATE allows the sender to inform
+ the remote endpoint the retransmission rate (bytes
+ retransmitted / total bytes transmitted).
+
+ 7 - SETTINGS_INITIAL_WINDOW_SIZE allows the sender to inform
+ the remote endpoint the initial window size (in bytes) for new
+ streams.
+
+
+
+Belshe & Peon Expires August 4, 2012 [Page 18]
+
+Internet-Draft SPDY Feb 2012
+
+
+ 8 - SETTINGS_CLIENT_CERTIFICATE_VECTOR_SIZE allows the server
+ to inform the client if the new size of the client certificate
+ vector.
+
+ Value: A 32-bit value.
+
+ 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.
+
+ A server may send multiple SETTINGS frames containing different ID/
+ Value pairs. When the same ID/Value is sent twice, the most recent
+ value overrides any previously sent values. If the server sends IDs
+ 1, 2, and 3 with the FLAG_SETTINGS_PERSIST_VALUE in a first SETTINGS
+ frame, and then sends IDs 4 and 5 with the
+ FLAG_SETTINGS_PERSIST_VALUE, when the client returns the persisted
+ state on its next SETTINGS frame, it SHOULD send all 5 settings (1,
+ 2, 3, 4, and 5 in this example) to the server.
+
+2.6.5. PING
+
+ The PING control frame is a mechanism for measuring a minimal round-
+ trip time from the sender. It can be sent from the client or the
+ server. Recipients of a PING frame should send an identical frame to
+ the sender as soon as possible (if there is other pending data
+ waiting to be sent, PING should take highest priority). Each ping
+ sent by a sender should use a unique ID.
+
+ +----------------------------------+
+ |1| version | 6 |
+ +----------------------------------+
+ | 0 (flags) | 4 (length) |
+ +----------------------------------|
+ | 32-bit ID |
+ +----------------------------------+
+
+ Control bit: The control bit is always 1 for this message.
+
+ Version: The SPDY version number.
+
+ Type: The message type for a PING message is 6.
+
+ Length: This frame is always 4 bytes long.
+
+
+
+Belshe & Peon Expires August 4, 2012 [Page 19]
+
+Internet-Draft SPDY Feb 2012
+
+
+ ID: A unique ID for this ping, represented as an unsigned 32 bit
+ value. When the client initiates a ping, it must use an odd numbered
+ ID. When the server initiates a ping, it must use an even numbered
+ ping. Use of odd/even IDs is required in order to avoid accidental
+ looping on PINGs (where each side initiates an identical PING at the
+ same time).
+
+ Note: If a sender uses all possible PING ids (e.g. has sent all 2^31
+ possible IDs), it can wrap and start re-using IDs.
+
+ If a server receives an even numbered PING which it did not initiate,
+ it must ignore the PING. If a client receives an odd numbered PING
+ which it did not initiate, it must ignore the PING.
+
+2.6.6. GOAWAY
+
+ The GOAWAY control frame is a mechanism to tell the remote side of
+ the connection to stop creating streams on this session. It can be
+ sent from the client or the server. Once sent, the sender will not
+ respond to any new SYN_STREAMs on this session. Recipients of a
+ GOAWAY frame must not send additional streams on this session,
+ although a new session can be established for new streams. The
+ purpose of this message is to allow an endpoint to gracefully stop
+ accepting new streams (perhaps for a reboot or maintenance), while
+ still finishing processing of previously established streams.
+
+ There is an inherent race condition between an endpoint sending
+ SYN_STREAMs and the remote sending a GOAWAY message. To deal with
+ this case, the GOAWAY contains a last-stream-id indicating the
+ stream-id of the last stream which was created on the sending
+ endpoint in this session. If the receiver of the GOAWAY sent new
+ SYN_STREAMs for sessions after this last-stream-id, they were not
+ processed by the server and the receiver may treat the stream as
+ though it had never been created at all (hence the receiver may want
+ to re-create the stream later on a new session).
+
+ Endpoints should always send a GOAWAY message before closing a
+ connection so that the remote can know whether a stream has been
+ partially processed or not. (For example, if an HTTP client sends a
+ POST at the same time that a server closes a connection, the client
+ cannot know if the server started to process that POST request if the
+ server does not send a GOAWAY frame to indicate where it stopped
+ working).
+
+ After sending a GOAWAY message, the sender must ignore all SYN_STREAM
+ frames for new streams.
+
+
+
+
+
+Belshe & Peon Expires August 4, 2012 [Page 20]
+
+Internet-Draft SPDY Feb 2012
+
+
+ +----------------------------------+
+ |1| version | 7 |
+ +----------------------------------+
+ | 0 (flags) | 8 (length) |
+ +----------------------------------|
+ |X| Last-good-stream-ID (31 bits) |
+ +----------------------------------+
+ | Status code |
+ +----------------------------------+
+
+ Control bit: The control bit is always 1 for this message.
+
+ Version: The SPDY version number.
+
+ Type: The message type for a GOAWAY message is 7.
+
+ Length: This frame is always 8 bytes long.
+
+ Last-good-stream-Id: The last stream id which was replied to (with
+ either a SYN_REPLY or RST_STREAM) by the sender of the GOAWAY
+ message. If no streams were replied to, this value MUST be 0.
+
+ Status: The reason for closing the session.
+
+ 0 - OK. This is a normal session teardown.
+
+ 1 - PROTOCOL_ERROR. This is a generic error, and should only be
+ used if a more specific error is not available.
+
+ 11 - INTERNAL_ERROR. This is a generic error which can be used
+ when the implementation has internally failed, not due to anything
+ in the protocol.
+
+2.6.7. HEADERS
+
+ The HEADERS frame augments a stream with additional headers. It may
+ be optionally sent on an existing stream at any time. Specific
+ application of the headers in this frame is application-dependent.
+ The name/value header block within this frame is compressed.
+
+
+
+
+
+
+
+
+
+
+
+
+Belshe & Peon Expires August 4, 2012 [Page 21]
+
+Internet-Draft SPDY Feb 2012
+
+
++------------------------------------+
+|1| version | 8 |
++------------------------------------+
+| Flags (8) | Length (24 bits) |
++------------------------------------+
+|X| Stream-ID (31bits) |
++------------------------------------+
+| Number of Name/Value pairs (int32) | <+
++------------------------------------+ |
+| Length of name (int32) | | This section is the "Name/Value
++------------------------------------+ | Header Block", and is compressed.
+| Name (string) | |
++------------------------------------+ |
+| Length of value (int32) | |
++------------------------------------+ |
+| Value (string) | |
++------------------------------------+ |
+| (repeats) | <+
+
+ Flags: Flags related to this frame. Valid flags are:
+
+ 0x01 = FLAG_FIN - marks this frame as the last frame to be
+ transmitted on this stream and puts the sender in the half-closed
+ (Section 2.3.6) state.
+
+ Length: An unsigned 24 bit value representing the number of bytes
+ after the length field. The minimum length of the length field is 4
+ (when the number of name value pairs is 0).
+
+ Stream-ID: The stream this HEADERS block is associated with.
+
+ Name/Value Header Block: A set of name/value pairs carried as part of
+ the SYN_STREAM. see Name/Value Header Block (Section 2.6.10).
+
+2.6.8. WINDOW_UPDATE
+
+ The WINDOW_UPDATE control frame is used to implement per stream flow
+ control in SPDY. Flow control in SPDY is per hop, that is, only
+ between the two endpoints of a SPDY connection. If there are one or
+ more intermediaries between the client and the origin server, flow
+ control signals are not explicitly forwarded by the intermediaries.
+ (However, throttling of data transfer by any recipient may have the
+ effect of indirectly propagating flow control information upstream
+ back to the original sender.) Flow control only applies to the data
+ portion of data frames. Recipients must buffer all control frames.
+ If a recipient fails to buffer an entire control frame, it MUST issue
+ a stream error (Section 2.4.2) with the status code
+ FLOW_CONTROL_ERROR for the stream.
+
+
+
+Belshe & Peon Expires August 4, 2012 [Page 22]
+
+Internet-Draft SPDY Feb 2012
+
+
+ Flow control in SPDY is implemented by a data transfer window kept by
+ the sender of each stream. The data transfer window is a simple
+ uint32 that indicates how many bytes of data the sender can transmit.
+ After a stream is created, but before any data frames have been
+ transmitted, the sender begins with the initial window size. This
+ window size is a measure of the buffering capability of the
+ recipient. The sender must not send a data frame with data length
+ greater than the transfer window size. After sending each data
+ frame, the sender decrements its transfer window size by the amount
+ of data transmitted. When the window size becomes less than or equal
+ to 0, the sender must pause transmitting data frames. At the other
+ end of the stream, the recipient sends a WINDOW_UPDATE control back
+ to notify the sender that it has consumed some data and freed up
+ buffer space to receive more data.
+
+ +----------------------------------+
+ |1| version | 9 |
+ +----------------------------------+
+ | 0 (flags) | 8 (length) |
+ +----------------------------------+
+ |X| Stream-ID (31-bits) |
+ +----------------------------------+
+ |X| Delta-Window-Size (31-bits) |
+ +----------------------------------+
+
+ Control bit: The control bit is always 1 for this message.
+
+ Version: The SPDY version number.
+
+ Type: The message type for a WINDOW_UPDATE message is 9.
+
+ Length: The length field is always 8 for this frame (there are 8
+ bytes after the length field).
+
+ Stream-ID: The stream ID that this WINDOW_UPDATE control frame is
+ for.
+
+ Delta-Window-Size: The additional number of bytes that the sender can
+ transmit in addition to existing remaining window size. The legal
+ range for this field is 1 to 2^31 - 1 (0x7fffffff) bytes.
+
+ The window size as kept by the sender must never exceed 2^31
+ (although it can become negative in one special case). If a sender
+ receives a WINDOW_UPDATE that causes the its window size to exceed
+ this limit, it must send RST_STREAM with status code
+ FLOW_CONTROL_ERROR to terminate the stream.
+
+ When a SPDY connection is first established, the default initial
+
+
+
+Belshe & Peon Expires August 4, 2012 [Page 23]
+
+Internet-Draft SPDY Feb 2012
+
+
+ window size for all streams is 64KB. An endpoint can use the
+ SETTINGS control frame to adjust the initial window size for the
+ connection. That is, its peer can start out using the 64KB default
+ initial window size when sending data frames before receiving the
+ SETTINGS. Because SETTINGS is asynchronous, there may be a race
+ condition if the recipient wants to decrease the initial window size,
+ but its peer immediately sends 64KB on the creation of a new
+ connection, before waiting for the SETTINGS to arrive. This is one
+ case where the window size kept by the sender will become negative.
+ Once the sender detects this condition, it must stop sending data
+ frames and wait for the recipient to catch up. The recipient has two
+ choices:
+
+ immediately send RST_STREAM with FLOW_CONTROL_ERROR status code.
+
+ allow the head of line blocking (as there is only one stream for
+ the session and the amount of data in flight is bounded by the
+ default initial window size), and send WINDOW_UPDATE as it
+ consumes data.
+
+ In the case of option 2, both sides must compute the window size
+ based on the initial window size in the SETTINGS. For example, if
+ the recipient sets the initial window size to be 16KB, and the sender
+ sends 64KB immediately on connection establishment, the sender will
+ discover its window size is -48KB on receipt of the SETTINGS. As the
+ recipient consumes the first 16KB, it must send a WINDOW_UPDATE of
+ 16KB back to the sender. This interaction continues until the
+ sender's window size becomes positive again, and it can resume
+ transmitting data frames.
+
+ After the recipient reads in a data frame with FLAG_FIN that marks
+ the end of the data stream, it should not send WINDOW_UPDATE frames
+ as it consumes the last data frame. A sender should ignore all the
+ WINDOW_UPDATE frames associated with the stream after it send the
+ last frame for the stream.
+
+ The data frames from the sender and the WINDOW_UPDATE frames from the
+ recipient are completely asynchronous with respect to each other.
+ This property allows a recipient to aggressively update the window
+ size kept by the sender to prevent the stream from stalling.
+
+2.6.9. CREDENTIAL
+
+ The CREDENTIAL control frame is used by the client to send additional
+ client certificates to the server. A SPDY client may decide to send
+ requests for resources from different origins on the same SPDY
+ session if it decides that that server handles both origins. For
+ example if the IP address associated with both hostnames matches and
+
+
+
+Belshe & Peon Expires August 4, 2012 [Page 24]
+
+Internet-Draft SPDY Feb 2012
+
+
+ the SSL server certificate presented in the initial handshake is
+ valid for both hostnames. However, because the SSL connection can
+ contain at most one client certificate, the client needs a mechanism
+ to send additional client certificates to the server.
+
+ The server is required to maintain a vector of client certificates
+ associated with a SPDY session. When the client needs to send a
+ client certificate to the server, it will send a CREDENTIAL frame
+ that specifies the index of the slot in which to store the
+ certificate as well as proof that the client posesses the
+ corresponding private key. The initial size of this vector must be
+ 8. If the client provides a client certificate during the first TLS
+ handshake, the contents of this certificate must be copied into the
+ first slot (index 1) in the CREDENTIAL vector, though it may be
+ overwritten by subsequent CREDENTIAL frames. The server must
+ exclusively use the CREDNETIAL vector when evaluating the client
+ certificates associated with an origin. The server may change the
+ size of this vector by sending a SETTINGS frame with the setting
+ SETTINGS_CLIENT_CERTIFICATE_VECTOR_SIZE value specified. In the
+ event that the new size is smaller than the current size, truncation
+ occurs preserving lower-index slots as possible.
+
+ TLS renegotiation with client authentication is incompatible with
+ SPDY given the multiplexed nature of SPDY. Specifically, imagine
+ that the client has 2 requests outstanding to the server for two
+ different pages (in different tabs). When the renegotiation + client
+ certificate request comes in, the browser is unable to determine
+ which resource triggered the client certificate request, in order to
+ prompt the user accordingly.
+
+ +----------------------------------+
+ |1|000000000000001|0000000000001011|
+ +----------------------------------+
+ | flags (8) | Length (24 bits) |
+ +----------------------------------+
+ | Slot (16 bits) | |
+ +-----------------+ |
+ | Proof Length (32 bits) |
+ +----------------------------------+
+ | Proof |
+ +----------------------------------+ <+
+ | Certificate Length (32 bits) | |
+ +----------------------------------+ | Repeated until end of frame
+ | Certificate | |
+ +----------------------------------+ <+
+
+ Slot: The index in the server's client certificate vector where this
+ certificate should be stored. If there is already a certificate
+
+
+
+Belshe & Peon Expires August 4, 2012 [Page 25]
+
+Internet-Draft SPDY Feb 2012
+
+
+ stored at this index, it will be overwritten. The index is one
+ based, not zero based; zero is an invalid slot index.
+
+ Proof: Cryptographic proof that the client has possession of the
+ private key associated with the certificate. The format is a TLS
+ digitally-signed element
+ (http://tools.ietf.org/html/rfc5246#section-4.7). The signature
+ algorithm must be the same as that used in the CertificateVerify
+ message. However, since the MD5+SHA1 signature type used in TLS 1.0
+ connections can not be correctly encoded in a digitally-signed
+ element, SHA1 must be used when MD5+SHA1 was used in the SSL
+ connection. The signature is calculated over a 32 byte TLS extractor
+ value (http://tools.ietf.org/html/rfc5705) with a label of "EXPORTER
+ SPDY certificate proof" using the empty string as context. ForRSA
+ certificates the signature would be a PKCS#1 v1.5 signature. For
+ ECDSA, it would be an ECDSA-Sig-Value
+ (http://tools.ietf.org/html/rfc5480#appendix-A). For a 1024-bit RSA
+ key, the CREDENTIAL message would be ~500 bytes.
+
+ Certificate: The certificate chain, starting with the leaf
+ certificate. Each certificate must be encoded as a 32 bit length,
+ followed by a DER encoded certificate. The certificate must be of
+ the same type (RSA, ECDSA, etc) as the client certificate associated
+ with the SSL connection.
+
+ If the server receives a request for a resource with unacceptable
+ credential (either missing or invalid), it must reply with a
+ RST_STREAM frame with the status code INVALID_CREDENTIALS. Upon
+ receipt of a RST_STREAM frame with INVALID_CREDENTIALS, the client
+ should initiate a new stream directly to the requested origin and
+ resend the request. Note, SPDY does not allow the server to request
+ different client authentication for different resources in the same
+ origin.
+
+ If the server receives an invalid CREDENTIAL frame, it MUST respond
+ with a GOAWAY frame and shutdown the session.
+
+2.6.10. Name/Value Header Block
+
+ The Name/Value Header Block is found in the SYN_STREAM, SYN_REPLY and
+ HEADERS control frames, and shares a common format:
+
+
+
+
+
+
+
+
+
+
+Belshe & Peon Expires August 4, 2012 [Page 26]
+
+Internet-Draft SPDY Feb 2012
+
+
+ +------------------------------------+
+ | Number of Name/Value pairs (int32) |
+ +------------------------------------+
+ | Length of name (int32) |
+ +------------------------------------+
+ | Name (string) |
+ +------------------------------------+
+ | Length of value (int32) |
+ +------------------------------------+
+ | Value (string) |
+ +------------------------------------+
+ | (repeats) |
+
+ Number of Name/Value pairs: The number of repeating name/value pairs
+ following this field.
+
+ List of Name/Value pairs:
+
+ Length of Name: a 32-bit value containing the number of octets in
+ the name field. Note that in practice, this length must not
+ exceed 2^24, as that is the maximum size of a SPDY frame.
+
+ Name: 0 or more octets, 8-bit sequences of data, excluding 0.
+
+ Length of Value: a 32-bit value containing the number of octets in
+ the value field. Note that in practice, this length must not
+ exceed 2^24, as that is the maximum size of a SPDY frame.
+
+ Value: 0 or more octets, 8-bit sequences of data, excluding 0.
+
+ Each header name must have at least one value. Header names are
+ encoded using the US-ASCII character set [ASCII] and must be all
+ lower case. The length of each name must be greater than zero. A
+ recipient of a zero-length name MUST issue a stream error
+ (Section 2.4.2) with the status code PROTOCOL_ERROR for the
+ stream-id.
+
+ Duplicate header names are not allowed. To send two identically
+ named headers, send a header with two values, where the values are
+ separated by a single NUL (0) byte. A header value can either be
+ empty (e.g. the length is zero) or it can contain multiple, NUL-
+ separated values, each with length greater than zero. The value
+ never starts nor ends with a NUL character. Recipients of illegal
+ value fields MUST issue a stream error (Section 2.4.2) with the
+ status code PROTOCOL_ERROR for the stream-id.
+
+
+
+
+
+
+Belshe & Peon Expires August 4, 2012 [Page 27]
+
+Internet-Draft SPDY Feb 2012
+
+
+2.6.10.1. Compression
+
+ The Name/Value Header Block is a section of the SYN_STREAM,
+ SYN_REPLY, and HEADERS frames used to carry header meta-data. This
+ block is always compressed using zlib compression. Within this
+ specification, any reference to 'zlib' is referring to the ZLIB
+ Compressed Data Format Specification Version 3.3 as part of RFC1950.
+ [RFC1950]
+
+ For each HEADERS compression instance, the initial state is
+ initialized using the following dictionary [UDELCOMPRESSION]:
+
+ const unsigned char SPDY_dictionary_txt[] = {
+ 0x00, 0x00, 0x00, 0x07, 0x6f, 0x70, 0x74, 0x69, \\ - - - - o p t i
+ 0x6f, 0x6e, 0x73, 0x00, 0x00, 0x00, 0x04, 0x68, \\ o n s - - - - h
+ 0x65, 0x61, 0x64, 0x00, 0x00, 0x00, 0x04, 0x70, \\ e a d - - - - p
+ 0x6f, 0x73, 0x74, 0x00, 0x00, 0x00, 0x03, 0x70, \\ o s t - - - - p
+ 0x75, 0x74, 0x00, 0x00, 0x00, 0x06, 0x64, 0x65, \\ u t - - - - d e
+ 0x6c, 0x65, 0x74, 0x65, 0x00, 0x00, 0x00, 0x05, \\ l e t e - - - -
+ 0x74, 0x72, 0x61, 0x63, 0x65, 0x00, 0x00, 0x00, \\ t r a c e - - -
+ 0x06, 0x61, 0x63, 0x63, 0x65, 0x70, 0x74, 0x00, \\ - a c c e p t -
+ 0x00, 0x00, 0x0e, 0x61, 0x63, 0x63, 0x65, 0x70, \\ - - - a c c e p
+ 0x74, 0x2d, 0x63, 0x68, 0x61, 0x72, 0x73, 0x65, \\ t - c h a r s e
+ 0x74, 0x00, 0x00, 0x00, 0x0f, 0x61, 0x63, 0x63, \\ t - - - - a c c
+ 0x65, 0x70, 0x74, 0x2d, 0x65, 0x6e, 0x63, 0x6f, \\ e p t - e n c o
+ 0x64, 0x69, 0x6e, 0x67, 0x00, 0x00, 0x00, 0x0f, \\ d i n g - - - -
+ 0x61, 0x63, 0x63, 0x65, 0x70, 0x74, 0x2d, 0x6c, \\ a c c e p t - l
+ 0x61, 0x6e, 0x67, 0x75, 0x61, 0x67, 0x65, 0x00, \\ a n g u a g e -
+ 0x00, 0x00, 0x0d, 0x61, 0x63, 0x63, 0x65, 0x70, \\ - - - a c c e p
+ 0x74, 0x2d, 0x72, 0x61, 0x6e, 0x67, 0x65, 0x73, \\ t - r a n g e s
+ 0x00, 0x00, 0x00, 0x03, 0x61, 0x67, 0x65, 0x00, \\ - - - - a g e -
+ 0x00, 0x00, 0x05, 0x61, 0x6c, 0x6c, 0x6f, 0x77, \\ - - - a l l o w
+ 0x00, 0x00, 0x00, 0x0d, 0x61, 0x75, 0x74, 0x68, \\ - - - - a u t h
+ 0x6f, 0x72, 0x69, 0x7a, 0x61, 0x74, 0x69, 0x6f, \\ o r i z a t i o
+ 0x6e, 0x00, 0x00, 0x00, 0x0d, 0x63, 0x61, 0x63, \\ n - - - - c a c
+ 0x68, 0x65, 0x2d, 0x63, 0x6f, 0x6e, 0x74, 0x72, \\ h e - c o n t r
+ 0x6f, 0x6c, 0x00, 0x00, 0x00, 0x0a, 0x63, 0x6f, \\ o l - - - - c o
+ 0x6e, 0x6e, 0x65, 0x63, 0x74, 0x69, 0x6f, 0x6e, \\ n n e c t i o n
+ 0x00, 0x00, 0x00, 0x0c, 0x63, 0x6f, 0x6e, 0x74, \\ - - - - c o n t
+ 0x65, 0x6e, 0x74, 0x2d, 0x62, 0x61, 0x73, 0x65, \\ e n t - b a s e
+ 0x00, 0x00, 0x00, 0x10, 0x63, 0x6f, 0x6e, 0x74, \\ - - - - c o n t
+ 0x65, 0x6e, 0x74, 0x2d, 0x65, 0x6e, 0x63, 0x6f, \\ e n t - e n c o
+ 0x64, 0x69, 0x6e, 0x67, 0x00, 0x00, 0x00, 0x10, \\ d i n g - - - -
+ 0x63, 0x6f, 0x6e, 0x74, 0x65, 0x6e, 0x74, 0x2d, \\ c o n t e n t -
+ 0x6c, 0x61, 0x6e, 0x67, 0x75, 0x61, 0x67, 0x65, \\ l a n g u a g e
+ 0x00, 0x00, 0x00, 0x0e, 0x63, 0x6f, 0x6e, 0x74, \\ - - - - c o n t
+ 0x65, 0x6e, 0x74, 0x2d, 0x6c, 0x65, 0x6e, 0x67, \\ e n t - l e n g
+ 0x74, 0x68, 0x00, 0x00, 0x00, 0x10, 0x63, 0x6f, \\ t h - - - - c o
+
+
+
+Belshe & Peon Expires August 4, 2012 [Page 28]
+
+Internet-Draft SPDY Feb 2012
+
+
+ 0x6e, 0x74, 0x65, 0x6e, 0x74, 0x2d, 0x6c, 0x6f, \\ n t e n t - l o
+ 0x63, 0x61, 0x74, 0x69, 0x6f, 0x6e, 0x00, 0x00, \\ c a t i o n - -
+ 0x00, 0x0b, 0x63, 0x6f, 0x6e, 0x74, 0x65, 0x6e, \\ - - c o n t e n
+ 0x74, 0x2d, 0x6d, 0x64, 0x35, 0x00, 0x00, 0x00, \\ t - m d 5 - - -
+ 0x0d, 0x63, 0x6f, 0x6e, 0x74, 0x65, 0x6e, 0x74, \\ - c o n t e n t
+ 0x2d, 0x72, 0x61, 0x6e, 0x67, 0x65, 0x00, 0x00, \\ - r a n g e - -
+ 0x00, 0x0c, 0x63, 0x6f, 0x6e, 0x74, 0x65, 0x6e, \\ - - c o n t e n
+ 0x74, 0x2d, 0x74, 0x79, 0x70, 0x65, 0x00, 0x00, \\ t - t y p e - -
+ 0x00, 0x04, 0x64, 0x61, 0x74, 0x65, 0x00, 0x00, \\ - - d a t e - -
+ 0x00, 0x04, 0x65, 0x74, 0x61, 0x67, 0x00, 0x00, \\ - - e t a g - -
+ 0x00, 0x06, 0x65, 0x78, 0x70, 0x65, 0x63, 0x74, \\ - - e x p e c t
+ 0x00, 0x00, 0x00, 0x07, 0x65, 0x78, 0x70, 0x69, \\ - - - - e x p i
+ 0x72, 0x65, 0x73, 0x00, 0x00, 0x00, 0x04, 0x66, \\ r e s - - - - f
+ 0x72, 0x6f, 0x6d, 0x00, 0x00, 0x00, 0x04, 0x68, \\ r o m - - - - h
+ 0x6f, 0x73, 0x74, 0x00, 0x00, 0x00, 0x08, 0x69, \\ o s t - - - - i
+ 0x66, 0x2d, 0x6d, 0x61, 0x74, 0x63, 0x68, 0x00, \\ f - m a t c h -
+ 0x00, 0x00, 0x11, 0x69, 0x66, 0x2d, 0x6d, 0x6f, \\ - - - i f - m o
+ 0x64, 0x69, 0x66, 0x69, 0x65, 0x64, 0x2d, 0x73, \\ d i f i e d - s
+ 0x69, 0x6e, 0x63, 0x65, 0x00, 0x00, 0x00, 0x0d, \\ i n c e - - - -
+ 0x69, 0x66, 0x2d, 0x6e, 0x6f, 0x6e, 0x65, 0x2d, \\ i f - n o n e -
+ 0x6d, 0x61, 0x74, 0x63, 0x68, 0x00, 0x00, 0x00, \\ m a t c h - - -
+ 0x08, 0x69, 0x66, 0x2d, 0x72, 0x61, 0x6e, 0x67, \\ - i f - r a n g
+ 0x65, 0x00, 0x00, 0x00, 0x13, 0x69, 0x66, 0x2d, \\ e - - - - i f -
+ 0x75, 0x6e, 0x6d, 0x6f, 0x64, 0x69, 0x66, 0x69, \\ u n m o d i f i
+ 0x65, 0x64, 0x2d, 0x73, 0x69, 0x6e, 0x63, 0x65, \\ e d - s i n c e
+ 0x00, 0x00, 0x00, 0x0d, 0x6c, 0x61, 0x73, 0x74, \\ - - - - l a s t
+ 0x2d, 0x6d, 0x6f, 0x64, 0x69, 0x66, 0x69, 0x65, \\ - m o d i f i e
+ 0x64, 0x00, 0x00, 0x00, 0x08, 0x6c, 0x6f, 0x63, \\ d - - - - l o c
+ 0x61, 0x74, 0x69, 0x6f, 0x6e, 0x00, 0x00, 0x00, \\ a t i o n - - -
+ 0x0c, 0x6d, 0x61, 0x78, 0x2d, 0x66, 0x6f, 0x72, \\ - m a x - f o r
+ 0x77, 0x61, 0x72, 0x64, 0x73, 0x00, 0x00, 0x00, \\ w a r d s - - -
+ 0x06, 0x70, 0x72, 0x61, 0x67, 0x6d, 0x61, 0x00, \\ - p r a g m a -
+ 0x00, 0x00, 0x12, 0x70, 0x72, 0x6f, 0x78, 0x79, \\ - - - p r o x y
+ 0x2d, 0x61, 0x75, 0x74, 0x68, 0x65, 0x6e, 0x74, \\ - a u t h e n t
+ 0x69, 0x63, 0x61, 0x74, 0x65, 0x00, 0x00, 0x00, \\ i c a t e - - -
+ 0x13, 0x70, 0x72, 0x6f, 0x78, 0x79, 0x2d, 0x61, \\ - p r o x y - a
+ 0x75, 0x74, 0x68, 0x6f, 0x72, 0x69, 0x7a, 0x61, \\ u t h o r i z a
+ 0x74, 0x69, 0x6f, 0x6e, 0x00, 0x00, 0x00, 0x05, \\ t i o n - - - -
+ 0x72, 0x61, 0x6e, 0x67, 0x65, 0x00, 0x00, 0x00, \\ r a n g e - - -
+ 0x07, 0x72, 0x65, 0x66, 0x65, 0x72, 0x65, 0x72, \\ - r e f e r e r
+ 0x00, 0x00, 0x00, 0x0b, 0x72, 0x65, 0x74, 0x72, \\ - - - - r e t r
+ 0x79, 0x2d, 0x61, 0x66, 0x74, 0x65, 0x72, 0x00, \\ y - a f t e r -
+ 0x00, 0x00, 0x06, 0x73, 0x65, 0x72, 0x76, 0x65, \\ - - - s e r v e
+ 0x72, 0x00, 0x00, 0x00, 0x02, 0x74, 0x65, 0x00, \\ r - - - - t e -
+ 0x00, 0x00, 0x07, 0x74, 0x72, 0x61, 0x69, 0x6c, \\ - - - t r a i l
+ 0x65, 0x72, 0x00, 0x00, 0x00, 0x11, 0x74, 0x72, \\ e r - - - - t r
+ 0x61, 0x6e, 0x73, 0x66, 0x65, 0x72, 0x2d, 0x65, \\ a n s f e r - e
+ 0x6e, 0x63, 0x6f, 0x64, 0x69, 0x6e, 0x67, 0x00, \\ n c o d i n g -
+
+
+
+Belshe & Peon Expires August 4, 2012 [Page 29]
+
+Internet-Draft SPDY Feb 2012
+
+
+ 0x00, 0x00, 0x07, 0x75, 0x70, 0x67, 0x72, 0x61, \\ - - - u p g r a
+ 0x64, 0x65, 0x00, 0x00, 0x00, 0x0a, 0x75, 0x73, \\ d e - - - - u s
+ 0x65, 0x72, 0x2d, 0x61, 0x67, 0x65, 0x6e, 0x74, \\ e r - a g e n t
+ 0x00, 0x00, 0x00, 0x04, 0x76, 0x61, 0x72, 0x79, \\ - - - - v a r y
+ 0x00, 0x00, 0x00, 0x03, 0x76, 0x69, 0x61, 0x00, \\ - - - - v i a -
+ 0x00, 0x00, 0x07, 0x77, 0x61, 0x72, 0x6e, 0x69, \\ - - - w a r n i
+ 0x6e, 0x67, 0x00, 0x00, 0x00, 0x10, 0x77, 0x77, \\ n g - - - - w w
+ 0x77, 0x2d, 0x61, 0x75, 0x74, 0x68, 0x65, 0x6e, \\ w - a u t h e n
+ 0x74, 0x69, 0x63, 0x61, 0x74, 0x65, 0x00, 0x00, \\ t i c a t e - -
+ 0x00, 0x06, 0x6d, 0x65, 0x74, 0x68, 0x6f, 0x64, \\ - - m e t h o d
+ 0x00, 0x00, 0x00, 0x03, 0x67, 0x65, 0x74, 0x00, \\ - - - - g e t -
+ 0x00, 0x00, 0x06, 0x73, 0x74, 0x61, 0x74, 0x75, \\ - - - s t a t u
+ 0x73, 0x00, 0x00, 0x00, 0x06, 0x32, 0x30, 0x30, \\ s - - - - 2 0 0
+ 0x20, 0x4f, 0x4b, 0x00, 0x00, 0x00, 0x07, 0x76, \\ - O K - - - - v
+ 0x65, 0x72, 0x73, 0x69, 0x6f, 0x6e, 0x00, 0x00, \\ e r s i o n - -
+ 0x00, 0x08, 0x48, 0x54, 0x54, 0x50, 0x2f, 0x31, \\ - - H T T P - 1
+ 0x2e, 0x31, 0x00, 0x00, 0x00, 0x03, 0x75, 0x72, \\ - 1 - - - - u r
+ 0x6c, 0x00, 0x00, 0x00, 0x06, 0x70, 0x75, 0x62, \\ l - - - - p u b
+ 0x6c, 0x69, 0x63, 0x00, 0x00, 0x00, 0x0a, 0x73, \\ l i c - - - - s
+ 0x65, 0x74, 0x2d, 0x63, 0x6f, 0x6f, 0x6b, 0x69, \\ e t - c o o k i
+ 0x65, 0x00, 0x00, 0x00, 0x0a, 0x6b, 0x65, 0x65, \\ e - - - - k e e
+ 0x70, 0x2d, 0x61, 0x6c, 0x69, 0x76, 0x65, 0x00, \\ p - a l i v e -
+ 0x00, 0x00, 0x06, 0x6f, 0x72, 0x69, 0x67, 0x69, \\ - - - o r i g i
+ 0x6e, 0x31, 0x30, 0x30, 0x31, 0x30, 0x31, 0x32, \\ n 1 0 0 1 0 1 2
+ 0x30, 0x31, 0x32, 0x30, 0x32, 0x32, 0x30, 0x35, \\ 0 1 2 0 2 2 0 5
+ 0x32, 0x30, 0x36, 0x33, 0x30, 0x30, 0x33, 0x30, \\ 2 0 6 3 0 0 3 0
+ 0x32, 0x33, 0x30, 0x33, 0x33, 0x30, 0x34, 0x33, \\ 2 3 0 3 3 0 4 3
+ 0x30, 0x35, 0x33, 0x30, 0x36, 0x33, 0x30, 0x37, \\ 0 5 3 0 6 3 0 7
+ 0x34, 0x30, 0x32, 0x34, 0x30, 0x35, 0x34, 0x30, \\ 4 0 2 4 0 5 4 0
+ 0x36, 0x34, 0x30, 0x37, 0x34, 0x30, 0x38, 0x34, \\ 6 4 0 7 4 0 8 4
+ 0x30, 0x39, 0x34, 0x31, 0x30, 0x34, 0x31, 0x31, \\ 0 9 4 1 0 4 1 1
+ 0x34, 0x31, 0x32, 0x34, 0x31, 0x33, 0x34, 0x31, \\ 4 1 2 4 1 3 4 1
+ 0x34, 0x34, 0x31, 0x35, 0x34, 0x31, 0x36, 0x34, \\ 4 4 1 5 4 1 6 4
+ 0x31, 0x37, 0x35, 0x30, 0x32, 0x35, 0x30, 0x34, \\ 1 7 5 0 2 5 0 4
+ 0x35, 0x30, 0x35, 0x32, 0x30, 0x33, 0x20, 0x4e, \\ 5 0 5 2 0 3 - N
+ 0x6f, 0x6e, 0x2d, 0x41, 0x75, 0x74, 0x68, 0x6f, \\ o n - A u t h o
+ 0x72, 0x69, 0x74, 0x61, 0x74, 0x69, 0x76, 0x65, \\ r i t a t i v e
+ 0x20, 0x49, 0x6e, 0x66, 0x6f, 0x72, 0x6d, 0x61, \\ - I n f o r m a
+ 0x74, 0x69, 0x6f, 0x6e, 0x32, 0x30, 0x34, 0x20, \\ t i o n 2 0 4 -
+ 0x4e, 0x6f, 0x20, 0x43, 0x6f, 0x6e, 0x74, 0x65, \\ N o - C o n t e
+ 0x6e, 0x74, 0x33, 0x30, 0x31, 0x20, 0x4d, 0x6f, \\ n t 3 0 1 - M o
+ 0x76, 0x65, 0x64, 0x20, 0x50, 0x65, 0x72, 0x6d, \\ v e d - P e r m
+ 0x61, 0x6e, 0x65, 0x6e, 0x74, 0x6c, 0x79, 0x34, \\ a n e n t l y 4
+ 0x30, 0x30, 0x20, 0x42, 0x61, 0x64, 0x20, 0x52, \\ 0 0 - B a d - R
+ 0x65, 0x71, 0x75, 0x65, 0x73, 0x74, 0x34, 0x30, \\ e q u e s t 4 0
+ 0x31, 0x20, 0x55, 0x6e, 0x61, 0x75, 0x74, 0x68, \\ 1 - U n a u t h
+ 0x6f, 0x72, 0x69, 0x7a, 0x65, 0x64, 0x34, 0x30, \\ o r i z e d 4 0
+ 0x33, 0x20, 0x46, 0x6f, 0x72, 0x62, 0x69, 0x64, \\ 3 - F o r b i d
+
+
+
+Belshe & Peon Expires August 4, 2012 [Page 30]
+
+Internet-Draft SPDY Feb 2012
+
+
+ 0x64, 0x65, 0x6e, 0x34, 0x30, 0x34, 0x20, 0x4e, \\ d e n 4 0 4 - N
+ 0x6f, 0x74, 0x20, 0x46, 0x6f, 0x75, 0x6e, 0x64, \\ o t - F o u n d
+ 0x35, 0x30, 0x30, 0x20, 0x49, 0x6e, 0x74, 0x65, \\ 5 0 0 - I n t e
+ 0x72, 0x6e, 0x61, 0x6c, 0x20, 0x53, 0x65, 0x72, \\ r n a l - S e r
+ 0x76, 0x65, 0x72, 0x20, 0x45, 0x72, 0x72, 0x6f, \\ v e r - E r r o
+ 0x72, 0x35, 0x30, 0x31, 0x20, 0x4e, 0x6f, 0x74, \\ r 5 0 1 - N o t
+ 0x20, 0x49, 0x6d, 0x70, 0x6c, 0x65, 0x6d, 0x65, \\ - I m p l e m e
+ 0x6e, 0x74, 0x65, 0x64, 0x35, 0x30, 0x33, 0x20, \\ n t e d 5 0 3 -
+ 0x53, 0x65, 0x72, 0x76, 0x69, 0x63, 0x65, 0x20, \\ S e r v i c e -
+ 0x55, 0x6e, 0x61, 0x76, 0x61, 0x69, 0x6c, 0x61, \\ U n a v a i l a
+ 0x62, 0x6c, 0x65, 0x4a, 0x61, 0x6e, 0x20, 0x46, \\ b l e J a n - F
+ 0x65, 0x62, 0x20, 0x4d, 0x61, 0x72, 0x20, 0x41, \\ e b - M a r - A
+ 0x70, 0x72, 0x20, 0x4d, 0x61, 0x79, 0x20, 0x4a, \\ p r - M a y - J
+ 0x75, 0x6e, 0x20, 0x4a, 0x75, 0x6c, 0x20, 0x41, \\ u n - J u l - A
+ 0x75, 0x67, 0x20, 0x53, 0x65, 0x70, 0x74, 0x20, \\ u g - S e p t -
+ 0x4f, 0x63, 0x74, 0x20, 0x4e, 0x6f, 0x76, 0x20, \\ O c t - N o v -
+ 0x44, 0x65, 0x63, 0x20, 0x30, 0x30, 0x3a, 0x30, \\ D e c - 0 0 - 0
+ 0x30, 0x3a, 0x30, 0x30, 0x20, 0x4d, 0x6f, 0x6e, \\ 0 - 0 0 - M o n
+ 0x2c, 0x20, 0x54, 0x75, 0x65, 0x2c, 0x20, 0x57, \\ - - T u e - - W
+ 0x65, 0x64, 0x2c, 0x20, 0x54, 0x68, 0x75, 0x2c, \\ e d - - T h u -
+ 0x20, 0x46, 0x72, 0x69, 0x2c, 0x20, 0x53, 0x61, \\ - F r i - - S a
+ 0x74, 0x2c, 0x20, 0x53, 0x75, 0x6e, 0x2c, 0x20, \\ t - - S u n - -
+ 0x47, 0x4d, 0x54, 0x63, 0x68, 0x75, 0x6e, 0x6b, \\ G M T c h u n k
+ 0x65, 0x64, 0x2c, 0x74, 0x65, 0x78, 0x74, 0x2f, \\ e d - t e x t -
+ 0x68, 0x74, 0x6d, 0x6c, 0x2c, 0x69, 0x6d, 0x61, \\ h t m l - i m a
+ 0x67, 0x65, 0x2f, 0x70, 0x6e, 0x67, 0x2c, 0x69, \\ g e - p n g - i
+ 0x6d, 0x61, 0x67, 0x65, 0x2f, 0x6a, 0x70, 0x67, \\ m a g e - j p g
+ 0x2c, 0x69, 0x6d, 0x61, 0x67, 0x65, 0x2f, 0x67, \\ - i m a g e - g
+ 0x69, 0x66, 0x2c, 0x61, 0x70, 0x70, 0x6c, 0x69, \\ i f - a p p l i
+ 0x63, 0x61, 0x74, 0x69, 0x6f, 0x6e, 0x2f, 0x78, \\ c a t i o n - x
+ 0x6d, 0x6c, 0x2c, 0x61, 0x70, 0x70, 0x6c, 0x69, \\ m l - a p p l i
+ 0x63, 0x61, 0x74, 0x69, 0x6f, 0x6e, 0x2f, 0x78, \\ c a t i o n - x
+ 0x68, 0x74, 0x6d, 0x6c, 0x2b, 0x78, 0x6d, 0x6c, \\ h t m l - x m l
+ 0x2c, 0x74, 0x65, 0x78, 0x74, 0x2f, 0x70, 0x6c, \\ - t e x t - p l
+ 0x61, 0x69, 0x6e, 0x2c, 0x74, 0x65, 0x78, 0x74, \\ a i n - t e x t
+ 0x2f, 0x6a, 0x61, 0x76, 0x61, 0x73, 0x63, 0x72, \\ - j a v a s c r
+ 0x69, 0x70, 0x74, 0x2c, 0x70, 0x75, 0x62, 0x6c, \\ i p t - p u b l
+ 0x69, 0x63, 0x70, 0x72, 0x69, 0x76, 0x61, 0x74, \\ i c p r i v a t
+ 0x65, 0x6d, 0x61, 0x78, 0x2d, 0x61, 0x67, 0x65, \\ e m a x - a g e
+ 0x3d, 0x67, 0x7a, 0x69, 0x70, 0x2c, 0x64, 0x65, \\ - g z i p - d e
+ 0x66, 0x6c, 0x61, 0x74, 0x65, 0x2c, 0x73, 0x64, \\ f l a t e - s d
+ 0x63, 0x68, 0x63, 0x68, 0x61, 0x72, 0x73, 0x65, \\ c h c h a r s e
+ 0x74, 0x3d, 0x75, 0x74, 0x66, 0x2d, 0x38, 0x63, \\ t - u t f - 8 c
+ 0x68, 0x61, 0x72, 0x73, 0x65, 0x74, 0x3d, 0x69, \\ h a r s e t - i
+ 0x73, 0x6f, 0x2d, 0x38, 0x38, 0x35, 0x39, 0x2d, \\ s o - 8 8 5 9 -
+ 0x31, 0x2c, 0x75, 0x74, 0x66, 0x2d, 0x2c, 0x2a, \\ 1 - u t f - - -
+ 0x2c, 0x65, 0x6e, 0x71, 0x3d, 0x30, 0x2e \\ - e n q - 0 -
+ };
+
+
+
+Belshe & Peon Expires August 4, 2012 [Page 31]
+
+Internet-Draft SPDY Feb 2012
+
+
+ The entire contents of the name/value header block is compressed
+ using zlib. There is a single zlib stream for all name value pairs
+ in one direction on a connection. SPDY uses a SYNC_FLUSH between
+ each compressed frame.
+
+ Implementation notes: the compression engine can be tuned to favor
+ speed or size. Optimizing for size increases memory use and CPU
+ consumption. Because header blocks are generally small, implementors
+ may want to reduce the window-size of the compression engine from the
+ default 15bits (a 32KB window) to more like 11bits (a 2KB window).
+ The exact setting is chosen by the compressor, the decompressor will
+ work with any setting.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Belshe & Peon Expires August 4, 2012 [Page 32]
+
+Internet-Draft SPDY Feb 2012
+
+
+3. HTTP Layering over SPDY
+
+ SPDY is intended to be as compatible as possible with current web-
+ based applications. This means that, from the perspective of the
+ server business logic or application API, the features of HTTP are
+ unchanged. To achieve this, all of the application request and
+ response header semantics are preserved, although the syntax of
+ conveying those semantics has changed. Thus, the rules from the
+ HTTP/1.1 specification in RFC2616 [RFC2616] apply with the changes in
+ the sections below.
+
+3.1. Connection Management
+
+ Clients SHOULD NOT open more than one SPDY session to a given origin
+ [RFC6454] concurrently.
+
+ Note that it is possible for one SPDY session to be finishing (e.g. a
+ GOAWAY message has been sent, but not all streams have finished),
+ while another SPDY session is starting.
+
+3.1.1. Use of GOAWAY
+
+ SPDY provides a GOAWAY message which can be used when closing a
+ connection from either the client or server. Without a server GOAWAY
+ message, HTTP has a race condition where the client sends a request
+ (a new SYN_STREAM) just as the server is closing the connection, and
+ the client cannot know if the server received the stream or not. By
+ using the last-stream-id in the GOAWAY, servers can indicate to the
+ client if a request was processed or not.
+
+ Note that some servers will choose to send the GOAWAY and immediately
+ terminate the connection without waiting for active streams to
+ finish. The client will be able to determine this because SPDY
+ streams are determinstically closed. This abrupt termination will
+ force the client to heuristically decide whether to retry the pending
+ requests. Clients always need to be capable of dealing with this
+ case because they must deal with accidental connection termination
+ cases, which are the same as the server never having sent a GOAWAY.
+
+ More sophisticated servers will use GOAWAY to implement a graceful
+ teardown. They will send the GOAWAY and provide some time for the
+ active streams to finish before terminating the connection.
+
+ If a SPDY client closes the connection, it should also send a GOAWAY
+ message. This allows the server to know if any server-push streams
+ were received by the client.
+
+ If the endpoint closing the connection has not received any
+
+
+
+Belshe & Peon Expires August 4, 2012 [Page 33]
+
+Internet-Draft SPDY Feb 2012
+
+
+ SYN_STREAMs from the remote, the GOAWAY will contain a last-stream-id
+ of 0.
+
+3.2. HTTP Request/Response
+
+3.2.1. Request
+
+ The client initiates a request by sending a SYN_STREAM frame. For
+ requests which do not contain a body, the SYN_STREAM frame MUST set
+ the FLAG_FIN, indicating that the client intends to send no further
+ data on this stream. For requests which do contain a body, the
+ SYN_STREAM will not contain the FLAG_FIN, and the body will follow
+ the SYN_STREAM in a series of DATA frames. The last DATA frame will
+ set the FLAG_FIN to indicate the end of the body.
+
+ The SYN_STREAM Name/Value section will contain all of the HTTP
+ headers which are associated with an HTTP request. The header block
+ in SPDY is mostly unchanged from today's HTTP header block, with the
+ following differences:
+
+ The first line of the request is unfolded into name/value pairs
+ like other HTTP headers and MUST be present:
+
+ ":method" - the HTTP method for this request (e.g. "GET",
+ "POST", "HEAD", etc)
+
+ ":path" - the url-path for this url with "/" prefixed. (See
+ RFC1738 [RFC1738]). For example, for
+ "http://www.google.com/search?q=dogs"; the path would be
+ "/search?q=dogs".
+
+ ":version" - the HTTP version of this request (e.g.
+ "HTTP/1.1")
+
+ In addition, the following two name/value pairs must also be
+ present in every request:
+
+ ":host" - the hostport (See RFC1738 [RFC1738]) portion of the
+ URL for this request (e.g. "www.google.com:1234"). This header
+ is the same as the HTTP 'Host' header.
+
+ ":scheme" - the scheme portion of the URL for this request
+ (e.g. "https"))
+
+ Header names are all lowercase.
+
+ The Connection, Host, Keep-Alive, Proxy-Connection, and Transfer-
+ Encoding headers are not valid and MUST not be sent.
+
+
+
+Belshe & Peon Expires August 4, 2012 [Page 34]
+
+Internet-Draft SPDY Feb 2012
+
+
+ User-agents MUST support gzip compression. Regardless of the
+ Accept-Encoding sent by the user-agent, the server may always send
+ content encoded with gzip or deflate encoding.
+
+ If a server receives a request where the sum of the data frame
+ payload lengths does not equal the size of the Content-Length
+ header, the server MUST return a 400 (Bad Request) error.
+
+ POST-specific changes:
+
+ Although POSTs are inherently chunked, POST requests SHOULD
+ also be accompanied by a Content-Length header. There are two
+ reasons for this: First, it assists with upload progress meters
+ for an improved user experience. But second, we know from
+ early versions of SPDY that failure to send a content length
+ header is incompatible with many existing HTTP server
+ implementations. Existing user-agents do not omit the Content-
+ Length header, and server implementations have come to depend
+ upon this.
+
+ The user-agent is free to prioritize requests as it sees fit. If the
+ user-agent cannot make progress without receiving a resource, it
+ should attempt to raise the priority of that resource. Resources
+ such as images, SHOULD generally use the lowest priority.
+
+ If a client sends a SYN_STREAM without all of the method, host, path,
+ scheme, and version headers, the server MUST reply with a HTTP 400
+ Bad Request reply.
+
+3.2.2. Response
+
+ The server responds to a client request with a SYN_REPLY frame.
+ Symmetric to the client's upload stream, server will send data after
+ the SYN_REPLY frame via a series of DATA frames, and the last data
+ frame will contain the FLAG_FIN to indicate successful end-of-stream.
+ If a response (like a 202 or 204 response) contains no body, the
+ SYN_REPLY frame may contain the FLAG_FIN flag to indicate no further
+ data will be sent on the stream.
+
+ The response status line is unfolded into name/value pairs like
+ other HTTP headers and must be present:
+
+ ":status" - The HTTP response status code (e.g. "200" or "200
+ OK")
+
+ ":version" - The HTTP response version (e.g. "HTTP/1.1")
+
+
+
+
+
+Belshe & Peon Expires August 4, 2012 [Page 35]
+
+Internet-Draft SPDY Feb 2012
+
+
+ All header names must be lowercase.
+
+ The Connection, Keep-Alive, Proxy-Connection, and Transfer-
+ Encoding headers are not valid and MUST not be sent.
+
+ Responses MAY be accompanied by a Content-Length header for
+ advisory purposes. (e.g. for UI progress meters)
+
+ If a client receives a response where the sum of the data frame
+ payload lengths does not equal the size of the Content-Length
+ header, the client MUST ignore the content length header.
+
+ If a client receives a SYN_REPLY without a status or without a
+ version header, the client must reply with a RST_STREAM frame
+ indicating a PROTOCOL ERROR.
+
+3.2.3. Authentication
+
+ When a client sends a request to an origin server that requires
+ authentication, the server can reply with a "401 Unauthorized"
+ response, and include a WWW-Authenticate challenge header that
+ defines the authentication scheme to be used. The client then
+ retries the request with an Authorization header appropriate to the
+ specified authentication scheme.
+
+ There are four options for proxy authentication, Basic, Digest, NTLM
+ and Negotiate (SPNEGO). The first two options were defined in
+ RFC2617 [RFC2617], and are stateless. The second two options were
+ developed by Microsoft and specified in RFC4559 [RFC4559], and are
+ stateful; otherwise known as multi-round authentication, or
+ connection authentication.
+
+3.2.3.1. Stateless Authentication
+
+ Stateless Authentication over SPDY is identical to how it is
+ performed over HTTP. If multiple SPDY streams are concurrently sent
+ to a single server, each will authenticate independently, similar to
+ how two HTTP connections would independently authenticate to a proxy
+ server.
+
+3.2.3.2. Stateful Authentication
+
+ Unfortunately, the stateful authentication mechanisms were
+ implemented and defined in a such a way that directly violates
+ RFC2617 - they do not include a "realm" as part of the request. This
+ is problematic in SPDY because it makes it impossible for a client to
+ disambiguate two concurrent server authentication challenges.
+
+
+
+
+Belshe & Peon Expires August 4, 2012 [Page 36]
+
+Internet-Draft SPDY Feb 2012
+
+
+ To deal with this case, SPDY servers using Stateful Authentication
+ MUST implement one of two changes:
+
+ Servers can add a "realm=<desired realm>" header so that the two
+ authentication requests can be disambiguated and run concurrently.
+ Unfortunately, given how these mechanisms work, this is probably
+ not practical.
+
+ Upon sending the first stateful challenge response, the server
+ MUST buffer and defer all further frames which are not part of
+ completing the challenge until the challenge has completed.
+ Completing the authentication challenge may take multiple round
+ trips. Once the client receives a "401 Authenticate" response for
+ a stateful authentication type, it MUST stop sending new requests
+ to the server until the authentication has completed by receiving
+ a non-401 response on at least one stream.
+
+3.3. Server Push Transactions
+
+ SPDY enables a server to send multiple replies to a client for a
+ single request. The rationale for this feature is that sometimes a
+ server knows that it will need to send multiple resources in response
+ to a single request. Without server push features, the client must
+ first download the primary resource, then discover the secondary
+ resource(s), and request them. Pushing of resources avoids the
+ round-trip delay, but also creates a potential race where a server
+ can be pushing content which a user-agent is in the process of
+ requesting. The following mechanics attempt to prevent the race
+ condition while enabling the performance benefit.
+
+ Browsers receiving a pushed response MUST validate that the server is
+ authorized to push the URL using the browser same-origin [RFC6454]
+ policy. For example, a SPDY connection to www.foo.com is generally
+ not permitted to push a response for www.evil.com.
+
+ If the browser accepts a pushed response (e.g. it does not send a
+ RST_STREAM), the browser MUST attempt to cache the pushed response in
+ same way that it would cache any other response. This means
+ validating the response headers and inserting into the disk cache.
+
+ Because pushed responses have no request, they have no request
+ headers associated with them. At the framing layer, SPDY pushed
+ streams contain an "associated-stream-id" which indicates the
+ requested stream for which the pushed stream is related. The pushed
+ stream inherits all of the headers from the associated-stream-id with
+ the exception of ":host", ":scheme", and ":path", which are provided
+ as part of the pushed response stream headers. The browser MUST
+ store these inherited and implied request headers with the cached
+
+
+
+Belshe & Peon Expires August 4, 2012 [Page 37]
+
+Internet-Draft SPDY Feb 2012
+
+
+ resource.
+
+ Implementation note: With server push, it is theoretically possible
+ for servers to push unreasonable amounts of content or resources to
+ the user-agent. Browsers MUST implement throttles to protect against
+ unreasonable push attacks.
+
+3.3.1. Server implementation
+
+ When the server intends to push a resource to the user-agent, it
+ opens a new stream by sending a unidirectional SYN_STREAM. The
+ SYN_STREAM MUST include an Associated-To-Stream-ID, and MUST set the
+ FLAG_UNIDIRECTIONAL flag. The SYN_STREAM MUST include headers for
+ ":scheme", ":host", ":path", which represent the URL for the resource
+ being pushed. Subsequent headers may follow in HEADERS frames. The
+ purpose of the association is so that the user-agent can
+ differentiate which request induced the pushed stream; without it, if
+ the user-agent had two tabs open to the same page, each pushing
+ unique content under a fixed URL, the user-agent would not be able to
+ differentiate the requests.
+
+ The Associated-To-Stream-ID must be the ID of an existing, open
+ stream. The reason for this restriction is to have a clear endpoint
+ for pushed content. If the user-agent requested a resource on stream
+ 11, the server replies on stream 11. It can push any number of
+ additional streams to the client before sending a FLAG_FIN on stream
+ 11. However, once the originating stream is closed no further push
+ streams may be associated with it. The pushed streams do not need to
+ be closed (FIN set) before the originating stream is closed, they
+ only need to be created before the originating stream closes.
+
+ It is illegal for a server to push a resource with the Associated-To-
+ Stream-ID of 0.
+
+ To minimize race conditions with the client, the SYN_STREAM for the
+ pushed resources MUST be sent prior to sending any content which
+ could allow the client to discover the pushed resource and request
+ it.
+
+ The server MUST only push resources which would have been returned
+ from a GET request.
+
+ Note: If the server does not have all of the Name/Value Response
+ headers available at the time it issues the HEADERS frame for the
+ pushed resource, it may later use an additional HEADERS frame to
+ augment the name/value pairs to be associated with the pushed stream.
+ The subsequent HEADERS frame(s) must not contain a header for
+ ':host', ':scheme', or ':path' (e.g. the server can't change the
+
+
+
+Belshe & Peon Expires August 4, 2012 [Page 38]
+
+Internet-Draft SPDY Feb 2012
+
+
+ identity of the resource to be pushed). The HEADERS frame must not
+ contain duplicate headers with a previously sent HEADERS frame. The
+ server must send a HEADERS frame including the scheme/host/port
+ headers before sending any data frames on the stream.
+
+3.3.2. Client implementation
+
+ When fetching a resource the client has 3 possibilities:
+
+ the resource is not being pushed
+
+ the resource is being pushed, but the data has not yet arrived
+
+ the resource is being pushed, and the data has started to arrive
+
+ When a SYN_STREAM and HEADERS frame which contains an Associated-To-
+ Stream-ID is received, the client must not issue GET requests for the
+ resource in the pushed stream, and instead wait for the pushed stream
+ to arrive.
+
+ If a client receives a server push stream with stream-id 0, it MUST
+ issue a session error (Section 2.4.1) with the status code
+ PROTOCOL_ERROR.
+
+ When a client receives a SYN_STREAM from the server without a the
+ ':host', ':scheme', and ':path' headers in the Name/Value section, it
+ MUST reply with a RST_STREAM with error code HTTP_PROTOCOL_ERROR.
+
+ To cancel individual server push streams, the client can issue a
+ stream error (Section 2.4.2) with error code CANCEL. Upon receipt,
+ the server MUST stop sending on this stream immediately (this is an
+ Abrupt termination).
+
+ To cancel all server push streams related to a request, the client
+ may issue a stream error (Section 2.4.2) with error code CANCEL on
+ the associated-stream-id. By cancelling that stream, the server MUST
+ immediately stop sending frames for any streams with
+ in-association-to for the original stream.
+
+ If the server sends a HEADER frame containing duplicate headers with
+ a previous HEADERS frame for the same stream, the client must issue a
+ stream error (Section 2.4.2) with error code PROTOCOL ERROR.
+
+ If the server sends a HEADERS frame after sending a data frame for
+ the same stream, the client MAY ignore the HEADERS frame. Ignoring
+ the HEADERS frame after a data frame prevents handling of HTTP's
+ trailing headers
+ (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.40).
+
+
+
+Belshe & Peon Expires August 4, 2012 [Page 39]
+
+Internet-Draft SPDY Feb 2012
+
+
+4. Design Rationale and Notes
+
+ Authors' notes: The notes in this section have no bearing on the SPDY
+ protocol as specified within this document, and none of these notes
+ should be considered authoritative about how the protocol works.
+ However, these notes may prove useful in future debates about how to
+ resolve protocol ambiguities or how to evolve the protocol going
+ forward. They may be removed before the final draft.
+
+4.1. Separation of Framing Layer and Application Layer
+
+ Readers may note that this specification sometimes blends the framing
+ layer (Section 2) with requirements of a specific application - HTTP
+ (Section 3). This is reflected in the request/response nature of the
+ streams, the definition of the HEADERS and compression contexts which
+ are very similar to HTTP, and other areas as well.
+
+ This blending is intentional - the primary goal of this protocol is
+ to create a low-latency protocol for use with HTTP. Isolating the
+ two layers is convenient for description of the protocol and how it
+ relates to existing HTTP implementations. However, the ability to
+ reuse the SPDY framing layer is a non goal.
+
+4.2. Error handling - Framing Layer
+
+ Error handling at the SPDY layer splits errors into two groups: Those
+ that affect an individual SPDY stream, and those that do not.
+
+ When an error is confined to a single stream, but general framing is
+ in tact, SPDY attempts to use the RST_STREAM as a mechanism to
+ invalidate the stream but move forward without aborting the
+ connection altogether.
+
+ For errors occuring outside of a single stream context, SPDY assumes
+ the entire session is hosed. In this case, the endpoint detecting
+ the error should initiate a connection close.
+
+4.3. One Connection Per Domain
+
+ SPDY attempts to use fewer connections than other protocols have
+ traditionally used. The rationale for this behavior is because it is
+ very difficult to provide a consistent level of service (e.g. TCP
+ slow-start), prioritization, or optimal compression when the client
+ is connecting to the server through multiple channels.
+
+ Through lab measurements, we have seen consistent latency benefits by
+ using fewer connections from the client. The overall number of
+ packets sent by SPDY can be as much as 40% less than HTTP. Handling
+
+
+
+Belshe & Peon Expires August 4, 2012 [Page 40]
+
+Internet-Draft SPDY Feb 2012
+
+
+ large numbers of concurrent connections on the server also does
+ become a scalability problem, and SPDY reduces this load.
+
+ The use of multiple connections is not without benefit, however.
+ Because SPDY multiplexes multiple, independent streams onto a single
+ stream, it creates a potential for head-of-line blocking problems at
+ the transport level. In tests so far, the negative effects of head-
+ of-line blocking (especially in the presence of packet loss) is
+ outweighed by the benefits of compression and prioritization.
+
+4.4. Fixed vs Variable Length Fields
+
+ SPDY favors use of fixed length 32bit fields in cases where smaller,
+ variable length encodings could have been used. To some, this seems
+ like a tragic waste of bandwidth. SPDY choses the simple encoding
+ for speed and simplicity.
+
+ The goal of SPDY is to reduce latency on the network. The overhead
+ of SPDY frames is generally quite low. Each data frame is only an 8
+ byte overhead for a 1452 byte payload (~0.6%). At the time of this
+ writing, bandwidth is already plentiful, and there is a strong trend
+ indicating that bandwidth will continue to increase. With an average
+ worldwide bandwidth of 1Mbps, and assuming that a variable length
+ encoding could reduce the overhead by 50%, the latency saved by using
+ a variable length encoding would be less than 100 nanoseconds. More
+ interesting are the effects when the larger encodings force a packet
+ boundary, in which case a round-trip could be induced. However, by
+ addressing other aspects of SPDY and TCP interactions, we believe
+ this is completely mitigated.
+
+4.5. Compression Context(s)
+
+ When isolating the compression contexts used for communicating with
+ multiple origins, we had a few choices to make. We could have
+ maintained a map (or list) of compression contexts usable for each
+ origin. The basic case is easy - each HEADERS frame would need to
+ identify the context to use for that frame. However, compression
+ contexts are not cheap, so the lifecycle of each context would need
+ to be bounded. For proxy servers, where we could churn through many
+ contexts, this would be a concern. We considered using a static set
+ of contexts, say 16 of them, which would bound the memory use. We
+ also considered dynamic contexts, which could be created on the fly,
+ and would need to be subsequently destroyed. All of these are
+ complicated, and ultimately we decided that such a mechanism creates
+ too many problems to solve.
+
+ Alternatively, we've chosen the simple approach, which is to simply
+ provide a flag for resetting the compression context. For the common
+
+
+
+Belshe & Peon Expires August 4, 2012 [Page 41]
+
+Internet-Draft SPDY Feb 2012
+
+
+ case (no proxy), this fine because most requests are to the same
+ origin and we never need to reset the context. For cases where we
+ are using two different origins over a single SPDY session, we simply
+ reset the compression state between each transition.
+
+4.6. Unidirectional streams
+
+ Many readers notice that unidirectional streams are both a bit
+ confusing in concept and also somewhat redundant. If the recipient
+ of a stream doesn't wish to send data on a stream, it could simply
+ send a SYN_REPLY with the FLAG_FIN bit set. The FLAG_UNIDIRECTIONAL
+ is, therefore, not necessary.
+
+ It is true that we don't need the UNIDIRECTIONAL markings. It is
+ added because it avoids the recipient of pushed streams from needing
+ to send a set of empty frames (e.g. the SYN_STREAM w/ FLAG_FIN) which
+ otherwise serve no purpose.
+
+4.7. Data Compression
+
+ Generic compression of data portion of the streams (as opposed to
+ compression of the headers) without knowing the content of the stream
+ is redundant. There is no value in compressing a stream which is
+ already compressed. Because of this, SPDY does allow data
+ compression to be optional. We included it because study of existing
+ websites shows that many sites are not using compression as they
+ should, and users suffer because of it. We wanted a mechanism where,
+ at the SPDY layer, site administrators could simply force compression
+ - it is better to compress twice than to not compress.
+
+ Overall, however, with this feature being optional and sometimes
+ redundant, it is unclear if it is useful at all. We will likely
+ remove it from the specification.
+
+4.8. Server Push
+
+ A subtle but important point is that server push streams must be
+ declared before the associated stream is closed. The reason for this
+ is so that proxies have a lifetime for which they can discard
+ information about previous streams. If a pushed stream could
+ associate itself with an already-closed stream, then endpoints would
+ not have a specific lifecycle for when they could disavow knowledge
+ of the streams which went before.
+
+
+
+
+
+
+
+
+Belshe & Peon Expires August 4, 2012 [Page 42]
+
+Internet-Draft SPDY Feb 2012
+
+
+5. Security Considerations
+
+5.1. Use of Same-origin constraints
+
+ This specification uses the same-origin policy [RFC6454] in all cases
+ where verification of content is required.
+
+5.2. HTTP Headers and SPDY Headers
+
+ At the application level, HTTP uses name/value pairs in its headers.
+ Because SPDY merges the existing HTTP headers with SPDY headers,
+ there is a possibility that some HTTP applications already use a
+ particular header name. To avoid any conflicts, all headers
+ introduced for layering HTTP over SPDY are prefixed with ":". ":" is
+ not a valid sequence in HTTP header naming, preventing any possible
+ conflict.
+
+5.3. Cross-Protocol Attacks
+
+ By utilizing TLS, we believe that SPDY introduces no new cross-
+ protocol attacks. TLS encrypts the contents of all transmission
+ (except the handshake itself), making it difficult for attackers to
+ control the data which could be used in a cross-protocol attack.
+
+5.4. Server Push Implicit Headers
+
+ Pushed resources do not have an associated request. In order for
+ existing HTTP cache control validations (such as the Vary header) to
+ work, however, all cached resources must have a set of request
+ headers. For this reason, browsers MUST be careful to inherit
+ request headers from the associated stream for the push. This
+ includes the 'Cookie' header.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Belshe & Peon Expires August 4, 2012 [Page 43]
+
+Internet-Draft SPDY Feb 2012
+
+
+6. Privacy Considerations
+
+6.1. Long Lived Connections
+
+ SPDY aims to keep connections open longer between clients and servers
+ in order to reduce the latency when a user makes a request. The
+ maintenance of these connections over time could be used to expose
+ private information. For example, a user using a browser hours after
+ the previous user stopped using that browser may be able to learn
+ about what the previous user was doing. This is a problem with HTTP
+ in its current form as well, however the short lived connections make
+ it less of a risk.
+
+6.2. SETTINGS frame
+
+ The SPDY SETTINGS frame allows servers to store out-of-band
+ transmitted information about the communication between client and
+ server on the client. Although this is intended only to be used to
+ reduce latency, renegade servers could use it as a mechanism to store
+ identifying information about the client in future requests.
+
+ Clients implementing privacy modes, such as Google Chrome's
+ "incognito mode", may wish to disable client-persisted SETTINGS
+ storage.
+
+ Clients MUST clear persisted SETTINGS information when clearing the
+ cookies.
+
+ TODO: Put range maximums on each type of setting to limit
+ inappropriate uses.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Belshe & Peon Expires August 4, 2012 [Page 44]
+
+Internet-Draft SPDY Feb 2012
+
+
+7. Incompatibilities with SPDY draft #2
+
+ Here is a list of the major changes between this draft and draft #2.
+
+ Addition of flow control
+
+ Increased 16 bit length fields in SYN_STREAM and SYN_REPLY to 32
+ bits.
+
+ Changed definition of compression for DATA frames
+
+ Updated compression dictionary
+
+ Fixed off-by-one on the compression dictionary for headers
+
+ Increased priority field from 2bits to 3bits.
+
+ Removed NOOP frame
+
+ Split the request "url" into "scheme", "host", and "path"
+
+ Added the requirement that POSTs contain content-length.
+
+ Removed wasted 16bits of unused space from the end of the
+ SYN_REPLY and HEADERS frames.
+
+ Fixed bug: Priorities were described backward (0 was lowest
+ instead of highest).
+
+ Fixed bug: Name/Value header counts were duplicated in both the
+ Name Value header block and also the containing frame.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Belshe & Peon Expires August 4, 2012 [Page 45]
+
+Internet-Draft SPDY Feb 2012
+
+
+8. Requirements Notation
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Belshe & Peon Expires August 4, 2012 [Page 46]
+
+Internet-Draft SPDY Feb 2012
+
+
+9. Acknowledgements
+
+ Many individuals have contributed to the design and evolution of
+ SPDY: Adam Langley, Wan-Teh Chang, Jim Morrison, Mark Nottingham,
+ Alyssa Wilk, Costin Manolache, William Chan, Vitaliy Lvin, Joe Chan,
+ Adam Barth, Ryan Hamilton, Gavin Peters, Kent Alstad, Kevin Lindsay,
+ Paul Amer, Fan Yang, Jonathan Leighton
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Belshe & Peon Expires August 4, 2012 [Page 47]
+
+Internet-Draft SPDY Feb 2012
+
+
+10. Normative References
+
+ [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
+ RFC 793, September 1981.
+
+ [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
+ Resource Locators (URL)", RFC 1738, December 1994.
+
+ [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format
+ Specification version 3.3", RFC 1950, May 1996.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2285] Mandeville, R., "Benchmarking Terminology for LAN
+ Switching Devices", RFC 2285, February 1998.
+
+ [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
+ Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
+ Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
+
+ [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
+ Leach, P., Luotonen, A., and L. Stewart, "HTTP
+ Authentication: Basic and Digest Access Authentication",
+ RFC 2617, June 1999.
+
+ [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based
+ Kerberos and NTLM HTTP Authentication in Microsoft
+ Windows", RFC 4559, June 2006.
+
+ [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
+ and T. Wright, "Transport Layer Security (TLS)
+ Extensions", RFC 4366, April 2006.
+
+ [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
+ (TLS) Protocol Version 1.2", RFC 5246, August 2008.
+
+ [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
+ December 2011.
+
+ [TLSNPN] Langley, A., "TLS Next Protocol Negotiation",
+ <http://tools.ietf.org/html/
+ draft-agl-tls-nextprotoneg-01>.
+
+ [ASCII] "US-ASCII. Coded Character Set - 7-Bit American Standard
+ Code for Information Interchange. Standard ANSI X3.4-1986,
+ ANSI, 1986.".
+
+
+
+
+Belshe & Peon Expires August 4, 2012 [Page 48]
+
+Internet-Draft SPDY Feb 2012
+
+
+ [UDELCOMPRESSION]
+ Yang, F., Amer, P., and J. Leighton, "A Methodology to
+ Derive SPDY's Initial Dictionary for Zlib Compression",
+ <http://www.eecis.udel.edu/~amer/PEL/poc/pdf/
+ SPDY-Fan.pdf>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Belshe & Peon Expires August 4, 2012 [Page 49]
+
+Internet-Draft SPDY Feb 2012
+
+
+Appendix A. Changes
+
+ To be removed by RFC Editor before publication
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Belshe & Peon Expires August 4, 2012 [Page 50]
+
+Internet-Draft SPDY Feb 2012
+
+
+Authors' Addresses
+
+ Mike Belshe
+ Twist
+
+ Email: address@hidden
+
+
+ Roberto Peon
+ Google, Inc
+
+ Email: address@hidden
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Belshe & Peon Expires August 4, 2012 [Page 51]
+
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [GNUnet-SVN] r27281 - in libmicrohttpd: doc src src/datadir,
gnunet <=