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/