draft-ietf-httpbis-http2-08.txt   draft-ietf-httpbis-http2-09.txt 
HTTPbis Working Group M. Belshe HTTPbis Working Group M. Belshe
Internet-Draft Twist Internet-Draft Twist
Intended status: Standards Track R. Peon Intended status: Standards Track R. Peon
Expires: May 15, 2014 Google, Inc Expires: June 7, 2014 Google, Inc
M. Thomson, Ed. M. Thomson, Ed.
Microsoft Microsoft
A. Melnikov, Ed. A. Melnikov, Ed.
Isode Ltd Isode Ltd
November 11, 2013 December 4, 2013
Hypertext Transfer Protocol version 2.0 Hypertext Transfer Protocol version 2.0
draft-ietf-httpbis-http2-08 draft-ietf-httpbis-http2-09
Abstract Abstract
This specification describes an optimized expression of the syntax of This specification describes an optimized expression of the syntax of
the Hypertext Transfer Protocol (HTTP). HTTP/2.0 enables a more the Hypertext Transfer Protocol (HTTP). HTTP/2.0 enables a more
efficient use of network resources and a reduced perception of efficient use of network resources and a reduced perception of
latency by introducing header field compression and allowing multiple latency by introducing header field compression and allowing multiple
concurrent messages on the same connection. It also introduces concurrent messages on the same connection. It also introduces
unsolicited push of representations from servers to clients. unsolicited push of representations from servers to clients.
This document is an alternative to, but does not obsolete, the This document is an alternative to, but does not obsolete, the
HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged. HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged.
This version of the draft has been marked for implementation. This version of the draft has been marked for implementation.
Interoperability testing will occur in the HTTP/2.0 interim in Interoperability testing will occur in the HTTP/2.0 interim in
Zurich, CH, starting 2014-01-22. Zurich, CH, starting 2014-01-22. This replaces -08, which was
originally identified as an implementation draft.
Editorial Note (To be removed by RFC Editor) Editorial Note (To be removed by RFC Editor)
Discussion of this draft takes place on the HTTPBIS working group Discussion of this draft takes place on the HTTPBIS working group
mailing list (ietf-http-wg@w3.org), which is archived at mailing list (ietf-http-wg@w3.org), which is archived at
<http://lists.w3.org/Archives/Public/ietf-http-wg/>. <http://lists.w3.org/Archives/Public/ietf-http-wg/>.
Working Group information and related documents can be found at Working Group information and related documents can be found at
<http://tools.ietf.org/wg/httpbis/> (Wiki) and <http://tools.ietf.org/wg/httpbis/> (Wiki) and
<https://github.com/http2/http2-spec> (source code and issues <https://github.com/http2/http2-spec> (source code and issues
skipping to change at page 2, line 15 skipping to change at page 2, line 15
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 15, 2014. This Internet-Draft will expire on June 7, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 12 skipping to change at page 3, line 12
4.3. Header Compression and Decompression . . . . . . . . . . . 13 4.3. Header Compression and Decompression . . . . . . . . . . . 13
5. Streams and Multiplexing . . . . . . . . . . . . . . . . . . . 14 5. Streams and Multiplexing . . . . . . . . . . . . . . . . . . . 14
5.1. Stream States . . . . . . . . . . . . . . . . . . . . . . 15 5.1. Stream States . . . . . . . . . . . . . . . . . . . . . . 15
5.1.1. Stream Identifiers . . . . . . . . . . . . . . . . . . 19 5.1.1. Stream Identifiers . . . . . . . . . . . . . . . . . . 19
5.1.2. Stream Concurrency . . . . . . . . . . . . . . . . . . 19 5.1.2. Stream Concurrency . . . . . . . . . . . . . . . . . . 19
5.2. Flow Control . . . . . . . . . . . . . . . . . . . . . . . 20 5.2. Flow Control . . . . . . . . . . . . . . . . . . . . . . . 20
5.2.1. Flow Control Principles . . . . . . . . . . . . . . . 20 5.2.1. Flow Control Principles . . . . . . . . . . . . . . . 20
5.2.2. Appropriate Use of Flow Control . . . . . . . . . . . 21 5.2.2. Appropriate Use of Flow Control . . . . . . . . . . . 21
5.3. Stream priority . . . . . . . . . . . . . . . . . . . . . 22 5.3. Stream priority . . . . . . . . . . . . . . . . . . . . . 22
5.4. Error Handling . . . . . . . . . . . . . . . . . . . . . . 22 5.4. Error Handling . . . . . . . . . . . . . . . . . . . . . . 22
5.4.1. Connection Error Handling . . . . . . . . . . . . . . 22 5.4.1. Connection Error Handling . . . . . . . . . . . . . . 23
5.4.2. Stream Error Handling . . . . . . . . . . . . . . . . 23 5.4.2. Stream Error Handling . . . . . . . . . . . . . . . . 23
5.4.3. Connection Termination . . . . . . . . . . . . . . . . 23 5.4.3. Connection Termination . . . . . . . . . . . . . . . . 24
6. Frame Definitions . . . . . . . . . . . . . . . . . . . . . . 24 6. Frame Definitions . . . . . . . . . . . . . . . . . . . . . . 24
6.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 6.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . . . 24 6.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.3. PRIORITY . . . . . . . . . . . . . . . . . . . . . . . . . 26 6.3. PRIORITY . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.4. RST_STREAM . . . . . . . . . . . . . . . . . . . . . . . . 26 6.4. RST_STREAM . . . . . . . . . . . . . . . . . . . . . . . . 26
6.5. SETTINGS . . . . . . . . . . . . . . . . . . . . . . . . . 27 6.5. SETTINGS . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.5.1. Setting Format . . . . . . . . . . . . . . . . . . . . 28 6.5.1. Setting Format . . . . . . . . . . . . . . . . . . . . 28
6.5.2. Defined Settings . . . . . . . . . . . . . . . . . . . 29 6.5.2. Defined Settings . . . . . . . . . . . . . . . . . . . 29
6.5.3. Settings Synchronization . . . . . . . . . . . . . . . 29 6.5.3. Settings Synchronization . . . . . . . . . . . . . . . 30
6.6. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . . . . 30 6.6. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . . . . 30
6.7. PING . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 6.7. PING . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.8. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . . . . 32 6.8. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.9. WINDOW_UPDATE . . . . . . . . . . . . . . . . . . . . . . 34 6.9. WINDOW_UPDATE . . . . . . . . . . . . . . . . . . . . . . 34
6.9.1. The Flow Control Window . . . . . . . . . . . . . . . 35 6.9.1. The Flow Control Window . . . . . . . . . . . . . . . 36
6.9.2. Initial Flow Control Window Size . . . . . . . . . . . 36 6.9.2. Initial Flow Control Window Size . . . . . . . . . . . 36
6.9.3. Reducing the Stream Window Size . . . . . . . . . . . 37 6.9.3. Reducing the Stream Window Size . . . . . . . . . . . 37
6.9.4. Ending Flow Control . . . . . . . . . . . . . . . . . 37 6.9.4. Ending Flow Control . . . . . . . . . . . . . . . . . 38
6.10. CONTINUATION . . . . . . . . . . . . . . . . . . . . . . . 38 6.10. CONTINUATION . . . . . . . . . . . . . . . . . . . . . . . 38
7. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 39 7. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 39
8. HTTP Message Exchanges . . . . . . . . . . . . . . . . . . . . 40 8. HTTP Message Exchanges . . . . . . . . . . . . . . . . . . . . 40
8.1. HTTP Request/Response Exchange . . . . . . . . . . . . . . 40 8.1. HTTP Request/Response Exchange . . . . . . . . . . . . . . 40
8.1.1. Informational Responses . . . . . . . . . . . . . . . 41 8.1.1. Informational Responses . . . . . . . . . . . . . . . 41
8.1.2. Examples . . . . . . . . . . . . . . . . . . . . . . . 41 8.1.2. Examples . . . . . . . . . . . . . . . . . . . . . . . 42
8.1.3. HTTP Header Fields . . . . . . . . . . . . . . . . . . 43 8.1.3. HTTP Header Fields . . . . . . . . . . . . . . . . . . 44
8.1.4. Request Reliability Mechanisms in HTTP/2.0 . . . . . . 45 8.1.4. Request Reliability Mechanisms in HTTP/2.0 . . . . . . 47
8.2. Server Push . . . . . . . . . . . . . . . . . . . . . . . 46 8.2. Server Push . . . . . . . . . . . . . . . . . . . . . . . 48
8.2.1. Push Requests . . . . . . . . . . . . . . . . . . . . 47 8.2.1. Push Requests . . . . . . . . . . . . . . . . . . . . 48
8.2.2. Push Responses . . . . . . . . . . . . . . . . . . . . 48 8.2.2. Push Responses . . . . . . . . . . . . . . . . . . . . 49
8.3. The CONNECT Method . . . . . . . . . . . . . . . . . . . . 48 8.3. The CONNECT Method . . . . . . . . . . . . . . . . . . . . 50
9. Additional HTTP Requirements/Considerations . . . . . . . . . 49 9. Additional HTTP Requirements/Considerations . . . . . . . . . 51
9.1. Connection Management . . . . . . . . . . . . . . . . . . 50 9.1. Connection Management . . . . . . . . . . . . . . . . . . 51
9.2. Use of TLS Features . . . . . . . . . . . . . . . . . . . 50 9.2. Use of TLS Features . . . . . . . . . . . . . . . . . . . 52
9.3. GZip Content-Encoding . . . . . . . . . . . . . . . . . . 51 9.3. GZip Content-Encoding . . . . . . . . . . . . . . . . . . 52
10. Security Considerations . . . . . . . . . . . . . . . . . . . 51 10. Security Considerations . . . . . . . . . . . . . . . . . . . 52
10.1. Server Authority and Same-Origin . . . . . . . . . . . . . 51 10.1. Server Authority and Same-Origin . . . . . . . . . . . . . 53
10.2. Cross-Protocol Attacks . . . . . . . . . . . . . . . . . . 51 10.2. Cross-Protocol Attacks . . . . . . . . . . . . . . . . . . 53
10.3. Intermediary Encapsulation Attacks . . . . . . . . . . . . 51 10.3. Intermediary Encapsulation Attacks . . . . . . . . . . . . 53
10.4. Cacheability of Pushed Resources . . . . . . . . . . . . . 52 10.4. Cacheability of Pushed Resources . . . . . . . . . . . . . 54
10.5. Denial of Service Considerations . . . . . . . . . . . . . 52 10.5. Denial of Service Considerations . . . . . . . . . . . . . 54
11. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 53 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 55
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55
12.1. Registration of HTTP/2.0 Identification String . . . . . . 54 12.1. Registration of HTTP/2.0 Identification String . . . . . . 55
12.2. Frame Type Registry . . . . . . . . . . . . . . . . . . . 54 12.2. Frame Type Registry . . . . . . . . . . . . . . . . . . . 56
12.3. Error Code Registry . . . . . . . . . . . . . . . . . . . 55 12.3. Error Code Registry . . . . . . . . . . . . . . . . . . . 56
12.4. Settings Registry . . . . . . . . . . . . . . . . . . . . 55 12.4. Settings Registry . . . . . . . . . . . . . . . . . . . . 57
12.5. HTTP2-Settings Header Field Registration . . . . . . . . . 56 12.5. HTTP2-Settings Header Field Registration . . . . . . . . . 58
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 56 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 58
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 57 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58
14.1. Normative References . . . . . . . . . . . . . . . . . . . 57 14.1. Normative References . . . . . . . . . . . . . . . . . . . 58
14.2. Informative References . . . . . . . . . . . . . . . . . . 58 14.2. Informative References . . . . . . . . . . . . . . . . . . 60
Appendix A. Change Log (to be removed by RFC Editor before Appendix A. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 59 publication) . . . . . . . . . . . . . . . . . . . . 61
A.1. Since draft-ietf-httpbis-http2-07 . . . . . . . . . . . . 59 A.1. Since draft-ietf-httpbis-http2-08 . . . . . . . . . . . . 61
A.2. Since draft-ietf-httpbis-http2-06 . . . . . . . . . . . . 59 A.2. Since draft-ietf-httpbis-http2-07 . . . . . . . . . . . . 61
A.3. Since draft-ietf-httpbis-http2-05 . . . . . . . . . . . . 59 A.3. Since draft-ietf-httpbis-http2-06 . . . . . . . . . . . . 61
A.4. Since draft-ietf-httpbis-http2-04 . . . . . . . . . . . . 59 A.4. Since draft-ietf-httpbis-http2-05 . . . . . . . . . . . . 61
A.5. Since draft-ietf-httpbis-http2-03 . . . . . . . . . . . . 60 A.5. Since draft-ietf-httpbis-http2-04 . . . . . . . . . . . . 61
A.6. Since draft-ietf-httpbis-http2-02 . . . . . . . . . . . . 60 A.6. Since draft-ietf-httpbis-http2-03 . . . . . . . . . . . . 62
A.7. Since draft-ietf-httpbis-http2-01 . . . . . . . . . . . . 60 A.7. Since draft-ietf-httpbis-http2-02 . . . . . . . . . . . . 62
A.8. Since draft-ietf-httpbis-http2-00 . . . . . . . . . . . . 61 A.8. Since draft-ietf-httpbis-http2-01 . . . . . . . . . . . . 62
A.9. Since draft-mbelshe-httpbis-spdy-00 . . . . . . . . . . . 61 A.9. Since draft-ietf-httpbis-http2-00 . . . . . . . . . . . . 63
A.10. Since draft-mbelshe-httpbis-spdy-00 . . . . . . . . . . . 63
1. Introduction 1. Introduction
The Hypertext Transfer Protocol (HTTP) is a wildly successful The Hypertext Transfer Protocol (HTTP) is a wildly successful
protocol. However, the HTTP/1.1 message format ([HTTP-p1], Section protocol. However, the HTTP/1.1 message format ([HTTP-p1], Section
3) is optimized for implementation simplicity and accessibility, not 3) is optimized for implementation simplicity and accessibility, not
application performance. As such it has several characteristics that application performance. As such it has several characteristics that
have a negative overall effect on application performance. have a negative overall effect on application performance.
In particular, HTTP/1.0 only allows one request to be outstanding at In particular, HTTP/1.0 only allows one request to be outstanding at
skipping to change at page 13, line 39 skipping to change at page 13, line 39
mandatory frame data, the endpoint MUST send a FRAME_SIZE_ERROR mandatory frame data, the endpoint MUST send a FRAME_SIZE_ERROR
error. Frame size errors in frames that affect connection-level error. Frame size errors in frames that affect connection-level
state MUST be treated as a connection error (Section 5.4.1). state MUST be treated as a connection error (Section 5.4.1).
4.3. Header Compression and Decompression 4.3. Header Compression and Decompression
A header field in HTTP/2.0 is a name-value pair with one or more A header field in HTTP/2.0 is a name-value pair with one or more
associated values. They are used within HTTP request and response associated values. They are used within HTTP request and response
messages as well as server push operations (see Section 8.2). messages as well as server push operations (see Section 8.2).
Header sets are logical collections of zero or more header fields Header sets are collections of zero or more header fields arranged at
arranged at the application layer. When transmitted over a the application layer. When transmitted over a connection, a header
connection, the header set is serialized into a header block using set is serialized into a header block using HTTP Header Compression
HTTP Header Compression [COMPRESSION]. The serialized header block [COMPRESSION]. The serialized header block is then divided into one
is then divided into one or more octet sequences, called header block or more octet sequences, called header block fragments, and
fragments, and transmitted within the payload of HEADERS transmitted within the payload of HEADERS (Section 6.2), PUSH_PROMISE
(Section 6.2), PUSH_PROMISE (Section 6.6) or CONTINUATION (Section 6.6) or CONTINUATION (Section 6.10) frames.
(Section 6.10) frames.
HTTP Header Compression does not preserve the relative ordering of
header fields. Header fields with multiple values are encoded into a
single header field using a special delimiter, see Section 8.1.3.3.
The Cookie header field [COOKIE] is treated specially by the HTTP
mapping, see Section 8.1.3.4.
A receiving endpoint reassembles the header block by concatenating A receiving endpoint reassembles the header block by concatenating
the individual fragments, then decompresses the block to reconstruct the individual fragments, then decompresses the block to reconstruct
the header set. the header set.
A complete header block consists of either: A complete header block consists of either:
o a single HEADERS or PUSH_PROMISE frame each respectively with the o a single HEADERS or PUSH_PROMISE frame each respectively with the
END_HEADERS or END_PUSH_PROMISE flag set, or END_HEADERS or END_PUSH_PROMISE flag set, or
o a HEADERS or PUSH_PROMISE frame with the END_HEADERS or o a HEADERS or PUSH_PROMISE frame with the END_HEADERS or
END_PUSH_PROMISE flag cleared and one or more CONTINUATION frames, END_PUSH_PROMISE flag cleared and one or more CONTINUATION frames,
where the last CONTINUATION frame has the END_HEADER flag set. where the last CONTINUATION frame has the END_HEADER flag set.
Header blocks MUST be transmitted as a contiguous sequence of frames, Header blocks MUST be transmitted as a contiguous sequence of frames,
with no interleaved frames of any other type, or from any other with no interleaved frames of any other type, or from any other
stream. The last frame in a sequence of HEADERS or CONTINUATION stream. The last frame in a sequence of HEADERS or CONTINUATION
frames MUST have the END_HEADERS flag set. The last frame in a frames MUST have the END_HEADERS flag set. The last frame in a
sequence of PUSH_PROMISEor CONTINUATION frames MUST have the sequence of PUSH_PROMISE or CONTINUATION frames MUST have the
END_PUSH_PROMISE or END_HEADERS flag set (respectively). END_PUSH_PROMISE or END_HEADERS flag set (respectively).
Header block fragments can only be sent as the payload of HEADERS, Header block fragments can only be sent as the payload of HEADERS,
PUSH_PROMISE or CONTINUATION frames. HEADERS, PUSH_PROMISE and PUSH_PROMISE or CONTINUATION frames. HEADERS, PUSH_PROMISE and
CONTINUATION frames carry data that can modify the compression CONTINUATION frames carry data that can modify the compression
context maintained by a receiver. An endpoint receiving HEADERS, context maintained by a receiver. An endpoint receiving HEADERS,
PUSH_PROMISE or CONTINUATION frames MUST reassemble header blocks and PUSH_PROMISE or CONTINUATION frames MUST reassemble header blocks and
perform decompression even if the frames are to be discarded. A perform decompression even if the frames are to be discarded. A
receiver MUST terminate the connection with a connection error receiver MUST terminate the connection with a connection error
(Section 5.4.1) of type COMPRESSION_ERROR, if it does not decompress (Section 5.4.1) of type COMPRESSION_ERROR, if it does not decompress
skipping to change at page 16, line 36 skipping to change at page 16, line 42
* The endpoint can send a HEADERS frame. This causes the stream * The endpoint can send a HEADERS frame. This causes the stream
to open in a "half closed (remote)" state. to open in a "half closed (remote)" state.
* Either endpoint can send a RST_STREAM frame to cause the stream * Either endpoint can send a RST_STREAM frame to cause the stream
to become "closed". This releases the stream reservation. to become "closed". This releases the stream reservation.
An endpoint MUST NOT send frames other than than HEADERS or An endpoint MUST NOT send frames other than than HEADERS or
RST_STREAM in this state. RST_STREAM in this state.
A PRIORITY frame MAY be received in this state. Receiving any A PRIORITY frame MAY be received in this state. Receiving any
frame other than HEADERS, RST_STREAM, or PRIORITY MUST be treated frame other than RST_STREAM, or PRIORITY MUST be treated as a
as a connection error (Section 5.4.1) of type PROTOCOL_ERROR. connection error (Section 5.4.1) of type PROTOCOL_ERROR.
reserved (remote): reserved (remote):
A stream in the "reserved (remote)" state has been reserved by a A stream in the "reserved (remote)" state has been reserved by a
remote peer. remote peer.
In this state, only the following transitions are possible: In this state, only the following transitions are possible:
* Receiving a HEADERS frame causes the stream to transition to * Receiving a HEADERS frame causes the stream to transition to
"half closed (local)". "half closed (local)".
skipping to change at page 24, line 44 skipping to change at page 24, line 50
RESERVED (0x2): Bit 2 is reserved for future use. RESERVED (0x2): Bit 2 is reserved for future use.
DATA frames MUST be associated with a stream. If a DATA frame is DATA frames MUST be associated with a stream. If a DATA frame is
received whose stream identifier field is 0x0, the recipient MUST received whose stream identifier field is 0x0, the recipient MUST
respond with a connection error (Section 5.4.1) of type respond with a connection error (Section 5.4.1) of type
PROTOCOL_ERROR. PROTOCOL_ERROR.
DATA frames are subject to flow control and can only be sent when a DATA frames are subject to flow control and can only be sent when a
stream is in the "open" or "half closed (remote)" states. If a DATA stream is in the "open" or "half closed (remote)" states. If a DATA
frame is received whose stream is not in "open" or "half closed frame is received whose stream is not in "open" or "half closed
(local)" state, the recipient MUST respond with a connection error (local)" state, the recipient MUST respond with a stream error
(Section 5.4.1) of type PROTOCOL_ERROR. (Section 5.4.2) of type STREAM_CLOSED.
6.2. HEADERS 6.2. HEADERS
The HEADERS frame (type=0x1) carries name-value pairs. It is used to The HEADERS frame (type=0x1) carries name-value pairs. It is used to
open a stream (Section 5.1). HEADERS frames can be sent on a stream open a stream (Section 5.1). HEADERS frames can be sent on a stream
in the "open" or "half closed (remote)" states. in the "open" or "half closed (remote)" states.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 29, line 13 skipping to change at page 29, line 23
Setting Format Setting Format
6.5.2. Defined Settings 6.5.2. Defined Settings
The following settings are defined: The following settings are defined:
SETTINGS_HEADER_TABLE_SIZE (1): Allows the sender to inform the SETTINGS_HEADER_TABLE_SIZE (1): Allows the sender to inform the
remote endpoint of the size of the header compression table used remote endpoint of the size of the header compression table used
to decode header blocks. The space available for encoding cannot to decode header blocks. The space available for encoding cannot
be changed; it is determined by the setting sent by the peer that be changed; it is determined by the setting sent by the peer that
receives the header blocks. The initial value is 4096 bytes. receives the header blocks. The initial value is 4,096 bytes.
SETTINGS_ENABLE_PUSH (2): This setting can be use to disable server SETTINGS_ENABLE_PUSH (2): This setting can be use to disable server
push (Section 8.2). An endpoint MUST NOT send a PUSH_PROMISE push (Section 8.2). An endpoint MUST NOT send a PUSH_PROMISE
frame if it receives this setting set to a value of 0. The frame if it receives this setting set to a value of 0. The
initial value is 1, which indicates that push is permitted. initial value is 1, which indicates that push is permitted.
SETTINGS_MAX_CONCURRENT_STREAMS (4): Indicates the maximum number of SETTINGS_MAX_CONCURRENT_STREAMS (4): Indicates the maximum number of
concurrent streams that the sender will allow. This limit is concurrent streams that the sender will allow. This limit is
directional: it applies to the number of streams that the sender directional: it applies to the number of streams that the sender
permits the receiver to create. Initially there is no limit to permits the receiver to create. Initially there is no limit to
skipping to change at page 41, line 21 skipping to change at page 41, line 31
An HTTP request/response exchange fully consumes a single stream. A An HTTP request/response exchange fully consumes a single stream. A
request starts with the HEADERS frame that puts the stream into an request starts with the HEADERS frame that puts the stream into an
"open" state and ends with a frame bearing END_STREAM, which causes "open" state and ends with a frame bearing END_STREAM, which causes
the stream to become "half closed" for the client. A response starts the stream to become "half closed" for the client. A response starts
with a HEADERS frame and ends with a frame bearing END_STREAM, which with a HEADERS frame and ends with a frame bearing END_STREAM, which
places the stream in the "closed" state. places the stream in the "closed" state.
8.1.1. Informational Responses 8.1.1. Informational Responses
[[anchor12: This section is likely to change significantly. This The 1xx series of HTTP response status codes ([HTTP-p2], Section 6.2)
only captures the high points.]] are not supported in HTTP/2.0.
The 1xx series of HTTP response codes ([HTTP-p2], Section 6.2) are The most common use case for 1xx is using a Expect header field with
not supported by HTTP/2.0. a "100-continue" token (colloquially, "Expect/continue") to indicate
that the client expects a 100 (Continue) non-final response status
code, receipt of which indicates that the client should continue
sending the request body if it has not already done so.
An intermediary that translates HTTP/1.1 requests to HTTP/2.0 MUST Typically, Expect/continue is used by clients wishing to avoid
generate any mandatory informational responses. For instance, a sending a large amount of data in a request body, only to have the
translating intermediary generates a 100 (Continue) response if a request rejected by the origin server.
request includes an Expect header field with a "100-continue" token
([HTTP-p2], Section 5.1.1).
An intermediary that translates HTTP/1.1 responses to HTTP/2.0 MUST HTTP/2.0 does not enable the Expect/continue mechanism; if the server
ignore informational responses. sends a final status code to reject the request, it can do so without
making the underlying connection unusable.
Note that this means HTTP/2.0 clients sending requests with bodies
may waste at least one round trip of sent data when the request is
rejected. This can be mitigated by restricting the amount of data
sent for the first round trip by bandwidth-constrained clients, in
anticipation of a final status code.
Other defined 1xx status codes are not applicable to HTTP/2.0; the
semantics of 101 (Switching Protocols) is better expressed using a
distinct frame type, since they apply to the entire connection, not
just one stream. Likewise, 102 (Processing) is no longer necessary,
because HTTP/2.0 has a separate means of keeping the connection
alive.
This difference between protocol versions necessitates special
handling by intermediaries that translate between them:
o An intermediary that gateways HTTP/1.1 to HTTP/2.0 MUST generate a
100 (Continue) response if a received request includes and Expect
header field with a "100-continue" token ([HTTP-p2], Section
5.1.1), unless it can immediately generate a final status code.
It MUST NOT forward the "100-continue" expectation in the request
header fields.
o An intermediary that gateways HTTP/2.0 to HTTP/1.1 MAY add an
Expect header field with a "100-continue" expectation when
forwarding a request that has a body; see [HTTP-p2], Section 5.1.1
for specific requirements.
o An intermediary that gateways HTTP/2.0 to HTTP/1.1 MUST discard
all other 1xx informational responses.
8.1.2. Examples 8.1.2. Examples
This section shows HTTP/1.1 requests and responses, with This section shows HTTP/1.1 requests and responses, with
illustrations of equivalent HTTP/2.0 requests and responses. illustrations of equivalent HTTP/2.0 requests and responses.
An HTTP GET request includes request header fields and no body and is An HTTP GET request includes request header fields and no body and is
therefore transmitted as a single contiguous sequence of HEADERS therefore transmitted as a single contiguous sequence of HEADERS
frames containing the serialized block of request header fields. The frames containing the serialized block of request header fields. The
last HEADERS frame in the sequence has both the END_HEADERS and last HEADERS frame in the sequence has both the END_HEADERS and
skipping to change at page 43, line 49 skipping to change at page 44, line 34
HTTP/2.0 request and response header fields carry information as a HTTP/2.0 request and response header fields carry information as a
series of key-value pairs. This includes the target URI for the series of key-value pairs. This includes the target URI for the
request, the status code for the response, as well as HTTP header request, the status code for the response, as well as HTTP header
fields. fields.
HTTP header field names are strings of ASCII characters that are HTTP header field names are strings of ASCII characters that are
compared in a case-insensitive fashion. Header field names MUST be compared in a case-insensitive fashion. Header field names MUST be
converted to lowercase prior to their encoding in HTTP/2.0. A converted to lowercase prior to their encoding in HTTP/2.0. A
request or response containing uppercase header field names MUST be request or response containing uppercase header field names MUST be
treated as malformed (Section 8.1.3.3). treated as malformed (Section 8.1.3.5).
The semantics of HTTP header fields are not altered by this The semantics of HTTP header fields are not altered by this
specification, though header fields relating to connection management specification, though header fields relating to connection management
or request framing are no longer necessary. An HTTP/2.0 request or or request framing are no longer necessary. An HTTP/2.0 request or
response MUST NOT include any of the following header fields: response MUST NOT include any of the following header fields:
Connection, Keep-Alive, Proxy-Connection, TE, Transfer-Encoding, and Connection, Keep-Alive, Proxy-Connection, TE, Transfer-Encoding, and
Upgrade. A request or response containing these header fields MUST Upgrade. A request or response containing these header fields MUST
be treated as malformed (Section 8.1.3.3). be treated as malformed (Section 8.1.3.5).
Note: HTTP/2.0 purposefully does not support upgrade from HTTP/2.0 Note: HTTP/2.0 purposefully does not support upgrade from HTTP/2.0
to another protocol. The handshake methods described in Section 3 to another protocol. The handshake methods described in Section 3
are sufficient to negotiate the use of alternative protocols. are sufficient to negotiate the use of alternative protocols.
8.1.3.1. Request Header Fields 8.1.3.1. Request Header Fields
HTTP/2.0 defines a number of header fields starting with a colon ':' HTTP/2.0 defines a number of header fields starting with a colon ':'
character that carry information about the request target: character that carry information about the request target:
skipping to change at page 44, line 49 skipping to change at page 45, line 40
optionally a '?' character followed by the "query" production, see optionally a '?' character followed by the "query" production, see
[RFC3986], Section 3.3 and [RFC3986], Section 3.4). This field [RFC3986], Section 3.3 and [RFC3986], Section 3.4). This field
MUST NOT be empty; URIs that do not contain a path component MUST MUST NOT be empty; URIs that do not contain a path component MUST
include a value of '/', unless the request is an OPTIONS in include a value of '/', unless the request is an OPTIONS in
asterisk form, in which case the ":path" header field MUST include asterisk form, in which case the ":path" header field MUST include
'*'. '*'.
All HTTP/2.0 requests MUST include exactly one valid value for all of All HTTP/2.0 requests MUST include exactly one valid value for all of
these header fields, unless this is a CONNECT request (Section 8.3). these header fields, unless this is a CONNECT request (Section 8.3).
An HTTP request that omits mandatory header fields is malformed An HTTP request that omits mandatory header fields is malformed
(Section 8.1.3.3). (Section 8.1.3.5).
Header field names that contain a colon are only valid in the Header field names that contain a colon are only valid in the
HTTP/2.0 context. These are not HTTP header fields. Implementations HTTP/2.0 context. These are not HTTP header fields. Implementations
MUST NOT generate header fields that start with a colon, but they MUST NOT generate header fields that start with a colon, but they
MUST ignore any header field that starts with a colon. In MUST ignore any header field that starts with a colon. In
particular, header fields with names starting with a colon MUST NOT particular, header fields with names starting with a colon MUST NOT
be exposed as HTTP header fields. be exposed as HTTP header fields.
HTTP/2.0 does not define a way to carry the version identifier that HTTP/2.0 does not define a way to carry the version identifier that
is included in the HTTP/1.1 request line. is included in the HTTP/1.1 request line.
8.1.3.2. Response Header Fields 8.1.3.2. Response Header Fields
A single ":status" header field is defined that carries the HTTP A single ":status" header field is defined that carries the HTTP
status code field (see [HTTP-p2], Section 6). This header field MUST status code field (see [HTTP-p2], Section 6). This header field MUST
be included in all responses, otherwise the response is malformed be included in all responses, otherwise the response is malformed
(Section 8.1.3.3). (Section 8.1.3.5).
HTTP/2.0 does not define a way to carry the version or reason phrase HTTP/2.0 does not define a way to carry the version or reason phrase
that is included in an HTTP/1.1 status line. that is included in an HTTP/1.1 status line.
8.1.3.3. Malformed Requests and Responses 8.1.3.3. Header Field Ordering
HTTP Header Compression [COMPRESSION] does not preserve the order of
header fields. The relative order of header fields with different
names is not important. However, the same header field can be
repeated to form a comma-separated list (see [HTTP-p1], Section
3.2.2), where the relative order of header field values is
significant. This repetition can occur either as a single header
field with a comma-separated list of values, or as several header
fields with a single value, or any combination thereof.
To preserve the order of a comma-separated list, the ordered values
for a single header field name appearing in different header fields
are concatenated into a single value. A zero-valued octet (0x0) is
used to delimit multiple values.
After decompression, header fields that have values containing zero
octets (0x0) MUST be split into multiple header fields before being
processed.
Header fields containing multiple values MUST be concatenated into a
single value unless the ordering of that header field is known to be
not significant.
The special case of "set-cookie" - which does not form a comma-
separated list, but can have multiple values - does not depend on
ordering. The "set-cookie" header field MAY be encoded as multiple
header field values, or as a single concatenated value.
8.1.3.4. Compressing the Cookie Header Field
The Cookie header field [COOKIE] can carry a significant amount of
redundant data.
The Cookie header field uses a semi-colon (";") to delimit cookie-
pairs (or "crumbs"). This header field doesn't follow the list
construction rules in HTTP (see [HTTP-p1], Section 3.2.2), which
prevents cookie-pairs from being separated into different name-value
pairs. This can significantly reduce compression efficiency as
individual cookie-pairs are updated.
To allow for better compression efficiency, the Cookie header field
MAY be split into separate header fields, each with one or more
cookie-pairs. If there are multiple Cookie header fields after
decompression, these MUST be concatenated into a single octet string
using the two octet delimiter of 0x3B, 0x20 (the ASCII string "; ").
8.1.3.5. Malformed Requests and Responses
A malformed request or response is one that uses a valid sequence of A malformed request or response is one that uses a valid sequence of
HTTP/2.0 frames, but is otherwise invalid due to the presence of HTTP/2.0 frames, but is otherwise invalid due to the presence of
prohibited header fields, the absence of mandatory header fields, or prohibited header fields, the absence of mandatory header fields, or
the inclusion of uppercase header field names. the inclusion of uppercase header field names.
A request or response that includes an entity body can include a A request or response that includes an entity body can include a
"content-length" header field. A request or response is also "content-length" header field. A request or response is also
malformed if the value of a "content-length" header field does not malformed if the value of a "content-length" header field does not
equal the sum of the DATA frame payload lengths that form the body. equal the sum of the DATA frame payload lengths that form the body.
skipping to change at page 48, line 37 skipping to change at page 50, line 27
the number of resources that can be concurrently pushed by a server. the number of resources that can be concurrently pushed by a server.
Advertising a SETTINGS_MAX_CONCURRENT_STREAMS value of zero disables Advertising a SETTINGS_MAX_CONCURRENT_STREAMS value of zero disables
server push by preventing the server from creating the necessary server push by preventing the server from creating the necessary
streams. This does not prohibit a server from sending PUSH_PROMISE streams. This does not prohibit a server from sending PUSH_PROMISE
frames; clients need to reset any promised streams that are not frames; clients need to reset any promised streams that are not
wanted. wanted.
Clients receiving a pushed response MUST validate that the server is Clients receiving a pushed response MUST validate that the server is
authorized to push the resource using the same-origin policy authorized to push the resource using the same-origin policy
([RFC6454], Section 3). For example, a HTTP/2.0 connection to ([RFC6454], Section 3). For example, a HTTP/2.0 connection to
"example.com" is generally [[anchor16: Ed: weaselly use of "example.com" is generally [[anchor15: Ed: weaselly use of
"generally", needs better definition]] not permitted to push a "generally", needs better definition]] not permitted to push a
response for "www.example.org". response for "www.example.org".
8.3. The CONNECT Method 8.3. The CONNECT Method
The HTTP pseudo-method CONNECT ([HTTP-p2], Section 4.3.6) is used to The HTTP pseudo-method CONNECT ([HTTP-p2], Section 4.3.6) is used to
convert an HTTP/1.1 connection into a tunnel to a remote host. convert an HTTP/1.1 connection into a tunnel to a remote host.
CONNECT is primarily used with HTTP proxies to established a TLS CONNECT is primarily used with HTTP proxies to established a TLS
session with a server for the purposes of interacting with "https" session with a server for the purposes of interacting with "https"
resources. resources.
skipping to change at page 49, line 15 skipping to change at page 51, line 6
o The ":method" header field is set to "CONNECT". o The ":method" header field is set to "CONNECT".
o The ":scheme" and ":path" header fields MUST be omitted. o The ":scheme" and ":path" header fields MUST be omitted.
o The ":authority" header field contains the host and port to o The ":authority" header field contains the host and port to
connect to (equivalent to the authority-form of the request-target connect to (equivalent to the authority-form of the request-target
of CONNECT requests, see [HTTP-p1], Section 5.3). of CONNECT requests, see [HTTP-p1], Section 5.3).
A proxy that supports CONNECT, establishes a TCP connection [TCP] to A proxy that supports CONNECT, establishes a TCP connection [TCP] to
the server identified in the ":path" header field. Once this the server identified in the ":authority" header field. Once this
connection is successfully established, the proxy sends a HEADERS connection is successfully established, the proxy sends a HEADERS
frame containing a 2xx series status code, as defined in [HTTP-p2], frame containing a 2xx series status code, as defined in [HTTP-p2],
Section 4.3.6. Section 4.3.6.
After the initial HEADERS frame sent by each peer, all subsequent After the initial HEADERS frame sent by each peer, all subsequent
DATA frames correspond to data sent on the TCP connection. The DATA frames correspond to data sent on the TCP connection. The
payload of any DATA frames sent by the client are transmitted by the payload of any DATA frames sent by the client are transmitted by the
proxy to the TCP server; data received from the TCP server is proxy to the TCP server; data received from the TCP server is
assembled into DATA frames by the proxy. Frame types other than DATA assembled into DATA frames by the proxy. Frame types other than DATA
or stream management frames (RST_STREAM, WINDOW_UPDATE, and PRIORITY) or stream management frames (RST_STREAM, WINDOW_UPDATE, and PRIORITY)
skipping to change at page 50, line 30 skipping to change at page 52, line 19
Servers are encouraged to maintain open connections for as long as Servers are encouraged to maintain open connections for as long as
possible, but are permitted to terminate idle connections if possible, but are permitted to terminate idle connections if
necessary. When either endpoint chooses to close the transport-level necessary. When either endpoint chooses to close the transport-level
TCP connection, the terminating endpoint SHOULD first send a GOAWAY TCP connection, the terminating endpoint SHOULD first send a GOAWAY
(Section 6.8) frame so that both endpoints can reliably determine (Section 6.8) frame so that both endpoints can reliably determine
whether previously sent frames have been processed and gracefully whether previously sent frames have been processed and gracefully
complete or terminate any necessary remaining tasks. complete or terminate any necessary remaining tasks.
9.2. Use of TLS Features 9.2. Use of TLS Features
Implementations of HTTP/2.0 MUST support TLS 1.1 [TLS11]. [[anchor19: Implementations of HTTP/2.0 MUST support TLS 1.1 [TLS11]. [[anchor18:
The working group intends to require at least the use of TLS 1.2 The working group intends to require at least the use of TLS 1.2
[TLS12] prior to publication of this document; negotiating TLS 1.1 is [TLS12] prior to publication of this document; negotiating TLS 1.1 is
permitted to enable the creation of interoperable implementations of permitted to enable the creation of interoperable implementations of
early drafts.]] early drafts.]]
The TLS implementation MUST support the Server Name Indication (SNI) The TLS implementation MUST support the Server Name Indication (SNI)
[TLS-EXT] extension to TLS. HTTP/2.0 clients MUST indicate the [TLS-EXT] extension to TLS. HTTP/2.0 clients MUST indicate the
target domain name when negotiating TLS. target domain name when negotiating TLS.
A server that receives a TLS handshake that does not include either A server that receives a TLS handshake that does not include either
skipping to change at page 51, line 40 skipping to change at page 53, line 29
A client MUST NOT use, in any way, resources provided by a server A client MUST NOT use, in any way, resources provided by a server
that is not authoritative for those resources. that is not authoritative for those resources.
10.2. Cross-Protocol Attacks 10.2. Cross-Protocol Attacks
When using TLS, we believe that HTTP/2.0 introduces no new cross- When using TLS, we believe that HTTP/2.0 introduces no new cross-
protocol attacks. TLS encrypts the contents of all transmission protocol attacks. TLS encrypts the contents of all transmission
(except the handshake itself), making it difficult for attackers to (except the handshake itself), making it difficult for attackers to
control the data which could be used in a cross-protocol attack. control the data which could be used in a cross-protocol attack.
[[anchor22: Issue: This is no longer true]] [[anchor21: Issue: This is no longer true]]
10.3. Intermediary Encapsulation Attacks 10.3. Intermediary Encapsulation Attacks
HTTP/2.0 header field names and values are encoded as sequences of HTTP/2.0 header field names and values are encoded as sequences of
octets with a length prefix. This enables HTTP/2.0 to carry any octets with a length prefix. This enables HTTP/2.0 to carry any
string of octets as the name or value of a header field. An string of octets as the name or value of a header field. An
intermediary that translates HTTP/2.0 requests or responses into intermediary that translates HTTP/2.0 requests or responses into
HTTP/1.1 directly could permit the creation of corrupted HTTP/1.1 HTTP/1.1 directly could permit the creation of corrupted HTTP/1.1
messages. An attacker might exploit this behavior to cause the messages. An attacker might exploit this behavior to cause the
intermediary to create HTTP/1.1 messages with illegal header fields, intermediary to create HTTP/1.1 messages with illegal header fields,
skipping to change at page 56, line 52 skipping to change at page 58, line 45
Wilk, Costin Manolache, William Chan, Vitaliy Lvin, Joe Chan, Adam Wilk, Costin Manolache, William Chan, Vitaliy Lvin, Joe Chan, Adam
Barth, Ryan Hamilton, Gavin Peters, Kent Alstad, Kevin Lindsay, Barth, Ryan Hamilton, Gavin Peters, Kent Alstad, Kevin Lindsay,
Paul Amer, Fan Yang, Jonathan Leighton (SPDY contributors). Paul Amer, Fan Yang, Jonathan Leighton (SPDY contributors).
o Gabriel Montenegro and Willy Tarreau (Upgrade mechanism) o Gabriel Montenegro and Willy Tarreau (Upgrade mechanism)
o William Chan, Salvatore Loreto, Osama Mazahir, Gabriel Montenegro, o William Chan, Salvatore Loreto, Osama Mazahir, Gabriel Montenegro,
Jitu Padhye, Roberto Peon, Rob Trace (Flow control) Jitu Padhye, Roberto Peon, Rob Trace (Flow control)
o Mark Nottingham, Julian Reschke, James Snell, Jeff Pinner, Mike o Mark Nottingham, Julian Reschke, James Snell, Jeff Pinner, Mike
Bishop (Substantial editorial contributions) Bishop, Herve Ruellan (Substantial editorial contributions)
14. References 14. References
14.1. Normative References 14.1. Normative References
[COMPRESSION] Ruellan, H. and R. Peon, "HPACK - Header Compression [COMPRESSION] Ruellan, H. and R. Peon, "HPACK - Header Compression
for HTTP/2.0", for HTTP/2.0",
draft-ietf-httpbis-header-compression-04 (work in draft-ietf-httpbis-header-compression-05 (work in
progress), October 2013. progress), December 2013.
[COOKIE] Barth, A., "HTTP State Management Mechanism",
RFC 6265, April 2011.
[HTTP-p1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext [HTTP-p1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Message Syntax and Transfer Protocol (HTTP/1.1): Message Syntax and
Routing", draft-ietf-httpbis-p1-messaging-24 (work in Routing", draft-ietf-httpbis-p1-messaging-25 (work in
progress), September 2013. progress), November 2013.
[HTTP-p2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext [HTTP-p2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Semantics and Content", Transfer Protocol (HTTP/1.1): Semantics and Content",
draft-ietf-httpbis-p2-semantics-24 (work in progress), draft-ietf-httpbis-p2-semantics-25 (work in progress),
September 2013. November 2013.
[HTTP-p4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext [HTTP-p4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Conditional Requests", Transfer Protocol (HTTP/1.1): Conditional Requests",
draft-ietf-httpbis-p4-conditional-24 (work in draft-ietf-httpbis-p4-conditional-25 (work in
progress), September 2013. progress), November 2013.
[HTTP-p5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, [HTTP-p5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP/1.1): Range Ed., "Hypertext Transfer Protocol (HTTP/1.1): Range
Requests", draft-ietf-httpbis-p5-range-24 (work in Requests", draft-ietf-httpbis-p5-range-25 (work in
progress), September 2013. progress), November 2013.
[HTTP-p6] Fielding, R., Ed., Nottingham, M., Ed., and J. [HTTP-p6] Fielding, R., Ed., Nottingham, M., Ed., and J.
Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1):
Caching", draft-ietf-httpbis-p6-cache-24 (work in Caching", draft-ietf-httpbis-p6-cache-25 (work in
progress), September 2013. progress), November 2013.
[HTTP-p7] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext [HTTP-p7] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Authentication", Transfer Protocol (HTTP/1.1): Authentication",
draft-ietf-httpbis-p7-auth-24 (work in progress), draft-ietf-httpbis-p7-auth-25 (work in progress),
September 2013. November 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
"Uniform Resource Identifier (URI): Generic Syntax", "Uniform Resource Identifier (URI): Generic Syntax",
STD 66, RFC 3986, January 2005. STD 66, RFC 3986, January 2005.
skipping to change at page 59, line 8 skipping to change at page 61, line 7
[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP
Extensions for High Performance", RFC 1323, May 1992. Extensions for High Performance", RFC 1323, May 1992.
[TALKING] Huang, L-S., Chen, E., Barth, A., Rescorla, E., and C. [TALKING] Huang, L-S., Chen, E., Barth, A., Rescorla, E., and C.
Jackson, "Talking to Yourself for Fun and Profit", Jackson, "Talking to Yourself for Fun and Profit",
2011, <http://w2spconf.com/2011/papers/websocket.pdf>. 2011, <http://w2spconf.com/2011/papers/websocket.pdf>.
Appendix A. Change Log (to be removed by RFC Editor before publication) Appendix A. Change Log (to be removed by RFC Editor before publication)
A.1. Since draft-ietf-httpbis-http2-07 A.1. Since draft-ietf-httpbis-http2-08
Added cookie crumbling for more efficient header compression.
Added header field ordering with the value-concatenation mechanism.
A.2. Since draft-ietf-httpbis-http2-07
Marked draft for implementation. Marked draft for implementation.
A.2. Since draft-ietf-httpbis-http2-06 A.3. Since draft-ietf-httpbis-http2-06
Adding definition for CONNECT method. Adding definition for CONNECT method.
Constraining the use of push to safe, cacheable methods with no Constraining the use of push to safe, cacheable methods with no
request body. request body.
Changing from :host to :authority to remove any potential confusion. Changing from :host to :authority to remove any potential confusion.
Adding setting for header compression table size. Adding setting for header compression table size.
Adding settings acknowledgement. Adding settings acknowledgement.
Removing unnecessary and potentially problematic flags from Removing unnecessary and potentially problematic flags from
CONTINUATION. CONTINUATION.
Added denial of service considerations. Added denial of service considerations.
A.3. Since draft-ietf-httpbis-http2-05 A.4. Since draft-ietf-httpbis-http2-05
Marking the draft ready for implementation. Marking the draft ready for implementation.
Renumbering END_PUSH_PROMISE flag. Renumbering END_PUSH_PROMISE flag.
Editorial clarifications and changes. Editorial clarifications and changes.
A.4. Since draft-ietf-httpbis-http2-04 A.5. Since draft-ietf-httpbis-http2-04
Added CONTINUATION frame for HEADERS and PUSH_PROMISE. Added CONTINUATION frame for HEADERS and PUSH_PROMISE.
PUSH_PROMISE is no longer implicitly prohibited if PUSH_PROMISE is no longer implicitly prohibited if
SETTINGS_MAX_CONCURRENT_STREAMS is zero. SETTINGS_MAX_CONCURRENT_STREAMS is zero.
Push expanded to allow all safe methods without a request body. Push expanded to allow all safe methods without a request body.
Clarified the use of HTTP header fields in requests and responses. Clarified the use of HTTP header fields in requests and responses.
Prohibited HTTP/1.1 hop-by-hop header fields. Prohibited HTTP/1.1 hop-by-hop header fields.
Requiring that intermediaries not forward requests with missing or Requiring that intermediaries not forward requests with missing or
illegal routing :-headers. illegal routing :-headers.
Clarified requirements around handling different frames after stream Clarified requirements around handling different frames after stream
close, stream reset and GOAWAY. close, stream reset and GOAWAY.
Added more specific prohibitions for sending of different frame types Added more specific prohibitions for sending of different frame types
in various stream states. in various stream states.
skipping to change at page 60, line 15 skipping to change at page 62, line 20
Clarified requirements around handling different frames after stream Clarified requirements around handling different frames after stream
close, stream reset and GOAWAY. close, stream reset and GOAWAY.
Added more specific prohibitions for sending of different frame types Added more specific prohibitions for sending of different frame types
in various stream states. in various stream states.
Making the last received setting value the effective value. Making the last received setting value the effective value.
Clarified requirements on TLS version, extension and ciphers. Clarified requirements on TLS version, extension and ciphers.
A.5. Since draft-ietf-httpbis-http2-03 A.6. Since draft-ietf-httpbis-http2-03
Committed major restructuring atrocities. Committed major restructuring atrocities.
Added reference to first header compression draft. Added reference to first header compression draft.
Added more formal description of frame lifecycle. Added more formal description of frame lifecycle.
Moved END_STREAM (renamed from FINAL) back to HEADERS/DATA. Moved END_STREAM (renamed from FINAL) back to HEADERS/DATA.
Removed HEADERS+PRIORITY, added optional priority to HEADERS frame. Removed HEADERS+PRIORITY, added optional priority to HEADERS frame.
Added PRIORITY frame. Added PRIORITY frame.
A.6. Since draft-ietf-httpbis-http2-02 A.7. Since draft-ietf-httpbis-http2-02
Added continuations to frames carrying header blocks. Added continuations to frames carrying header blocks.
Replaced use of "session" with "connection" to avoid confusion with Replaced use of "session" with "connection" to avoid confusion with
other HTTP stateful concepts, like cookies. other HTTP stateful concepts, like cookies.
Removed "message". Removed "message".
Switched to TLS ALPN from NPN. Switched to TLS ALPN from NPN.
Editorial changes. Editorial changes.
A.7. Since draft-ietf-httpbis-http2-01 A.8. Since draft-ietf-httpbis-http2-01
Added IANA considerations section for frame types, error codes and Added IANA considerations section for frame types, error codes and
settings. settings.
Removed data frame compression. Removed data frame compression.
Added PUSH_PROMISE. Added PUSH_PROMISE.
Added globally applicable flags to framing. Added globally applicable flags to framing.
skipping to change at page 61, line 27 skipping to change at page 63, line 31
Restructured frame header. Removed distinction between data and Restructured frame header. Removed distinction between data and
control frames. control frames.
Altered flow control properties to include session-level limits. Altered flow control properties to include session-level limits.
Added note on cacheability of pushed resources and multiple tenant Added note on cacheability of pushed resources and multiple tenant
servers. servers.
Changed protocol label form based on discussions. Changed protocol label form based on discussions.
A.8. Since draft-ietf-httpbis-http2-00 A.9. Since draft-ietf-httpbis-http2-00
Changed title throughout. Changed title throughout.
Removed section on Incompatibilities with SPDY draft#2. Removed section on Incompatibilities with SPDY draft#2.
Changed INTERNAL_ERROR on GOAWAY to have a value of 2 <https:// Changed INTERNAL_ERROR on GOAWAY to have a value of 2 <https://
groups.google.com/forum/?fromgroups#!topic/spdy-dev/cfUef2gL3iU>. groups.google.com/forum/?fromgroups#!topic/spdy-dev/cfUef2gL3iU>.
Replaced abstract and introduction. Replaced abstract and introduction.
Added section on starting HTTP/2.0, including upgrade mechanism. Added section on starting HTTP/2.0, including upgrade mechanism.
Removed unused references. Removed unused references.
Added flow control principles (Section 5.2.1) based on <http:// Added flow control principles (Section 5.2.1) based on <http://
tools.ietf.org/html/draft-montenegro-httpbis-http2-fc-principles-01>. tools.ietf.org/html/draft-montenegro-httpbis-http2-fc-principles-01>.
A.9. Since draft-mbelshe-httpbis-spdy-00 A.10. Since draft-mbelshe-httpbis-spdy-00
Adopted as base for draft-ietf-httpbis-http2. Adopted as base for draft-ietf-httpbis-http2.
Updated authors/editors list. Updated authors/editors list.
Added status note. Added status note.
Authors' Addresses Authors' Addresses
Mike Belshe Mike Belshe
 End of changes. 50 change blocks. 
108 lines changed or deleted 206 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/