draft-ietf-httpbis-http2-11.txt		draft-ietf-httpbis-http2-12.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: October 5, 2014 Google, Inc		Expires: October 25, 2014 Google, Inc
	M. Thomson, Ed.		M. Thomson, Ed.
	Mozilla		Mozilla
	April 3, 2014		April 23, 2014
	Hypertext Transfer Protocol version 2		Hypertext Transfer Protocol version 2
	draft-ietf-httpbis-http2-11		draft-ietf-httpbis-http2-12
	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 enables a more		the Hypertext Transfer Protocol (HTTP). HTTP/2 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.
	skipping to change at page 1, line 38		skipping to change at page 1, line 38
	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 can be found at		Working Group information can be found at
	<http://tools.ietf.org/wg/httpbis/>; that specific to HTTP/2 are at		<http://tools.ietf.org/wg/httpbis/>; that specific to HTTP/2 are at
	<http://http2.github.io/>.		<http://http2.github.io/>.
	The changes in this draft are summarized in Appendix A.		The changes in this draft are summarized in Appendix A.
			This version of HTTP/2, identified as "h2-12" or "h2c-12", is
			intended for implementation. An interoperability event will be
			conducted 2014-06-05, see <https://github.com/http2/wg_materials/
			blob/master/interim-14-06/agenda.md>.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 October 5, 2014.		This Internet-Draft will expire on October 25, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 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 2, line 49		skipping to change at page 3, line 6
	4.2. Frame Size . . . . . . . . . . . . . . . . . . . . . . . . 14		4.2. Frame Size . . . . . . . . . . . . . . . . . . . . . . . . 14
	4.3. Header Compression and Decompression . . . . . . . . . . . 14		4.3. Header Compression and Decompression . . . . . . . . . . . 14
	5. Streams and Multiplexing . . . . . . . . . . . . . . . . . . . 15		5. Streams and Multiplexing . . . . . . . . . . . . . . . . . . . 15
	5.1. Stream States . . . . . . . . . . . . . . . . . . . . . . 16		5.1. Stream States . . . . . . . . . . . . . . . . . . . . . . 16
	5.1.1. Stream Identifiers . . . . . . . . . . . . . . . . . . 20		5.1.1. Stream Identifiers . . . . . . . . . . . . . . . . . . 20
	5.1.2. Stream Concurrency . . . . . . . . . . . . . . . . . . 20		5.1.2. Stream Concurrency . . . . . . . . . . . . . . . . . . 20
	5.2. Flow Control . . . . . . . . . . . . . . . . . . . . . . . 21		5.2. Flow Control . . . . . . . . . . . . . . . . . . . . . . . 21
	5.2.1. Flow Control Principles . . . . . . . . . . . . . . . 21		5.2.1. Flow Control Principles . . . . . . . . . . . . . . . 21
	5.2.2. Appropriate Use of Flow Control . . . . . . . . . . . 22		5.2.2. Appropriate Use of Flow Control . . . . . . . . . . . 22
	5.3. Stream priority . . . . . . . . . . . . . . . . . . . . . 23		5.3. Stream priority . . . . . . . . . . . . . . . . . . . . . 23
	5.3.1. Priority Groups and Weighting . . . . . . . . . . . . 23		5.3.1. Stream Dependencies . . . . . . . . . . . . . . . . . 23
	5.3.2. Stream Dependencies . . . . . . . . . . . . . . . . . 24		5.3.2. Dependency Weighting . . . . . . . . . . . . . . . . . 24
	5.3.3. Reprioritization . . . . . . . . . . . . . . . . . . . 25		5.3.3. Reprioritization . . . . . . . . . . . . . . . . . . . 24
	5.3.4. Prioritization State Management . . . . . . . . . . . 25		5.3.4. Prioritization State Management . . . . . . . . . . . 25
	5.3.5. Default Priorities . . . . . . . . . . . . . . . . . . 26		5.3.5. Default Priorities . . . . . . . . . . . . . . . . . . 26
	5.4. Error Handling . . . . . . . . . . . . . . . . . . . . . . 26		5.4. Error Handling . . . . . . . . . . . . . . . . . . . . . . 26
	5.4.1. Connection Error Handling . . . . . . . . . . . . . . 27		5.4.1. Connection Error Handling . . . . . . . . . . . . . . 27
	5.4.2. Stream Error Handling . . . . . . . . . . . . . . . . 27		5.4.2. Stream Error Handling . . . . . . . . . . . . . . . . 27
	5.4.3. Connection Termination . . . . . . . . . . . . . . . . 28		5.4.3. Connection Termination . . . . . . . . . . . . . . . . 28
	6. Frame Definitions . . . . . . . . . . . . . . . . . . . . . . 28		6. Frame Definitions . . . . . . . . . . . . . . . . . . . . . . 28
	6.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . . 28		6.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
	6.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . . . 30		6.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . . . 30
	6.3. PRIORITY . . . . . . . . . . . . . . . . . . . . . . . . . 32		6.3. PRIORITY . . . . . . . . . . . . . . . . . . . . . . . . . 32
	6.4. RST_STREAM . . . . . . . . . . . . . . . . . . . . . . . . 34		6.4. RST_STREAM . . . . . . . . . . . . . . . . . . . . . . . . 33
	6.5. SETTINGS . . . . . . . . . . . . . . . . . . . . . . . . . 35		6.5. SETTINGS . . . . . . . . . . . . . . . . . . . . . . . . . 34
	6.5.1. SETTINGS Format . . . . . . . . . . . . . . . . . . . 36		6.5.1. SETTINGS Format . . . . . . . . . . . . . . . . . . . 35
	6.5.2. Defined SETTINGS Parameters . . . . . . . . . . . . . 36		6.5.2. Defined SETTINGS Parameters . . . . . . . . . . . . . 35
	6.5.3. Settings Synchronization . . . . . . . . . . . . . . . 37		6.5.3. Settings Synchronization . . . . . . . . . . . . . . . 37
	6.6. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . . . . 37		6.6. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . . . . 37
	6.7. PING . . . . . . . . . . . . . . . . . . . . . . . . . . . 40		6.7. PING . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
	6.8. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . . . . 41		6.8. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . . . . 40
	6.9. WINDOW_UPDATE . . . . . . . . . . . . . . . . . . . . . . 43		6.9. WINDOW_UPDATE . . . . . . . . . . . . . . . . . . . . . . 42
	6.9.1. The Flow Control Window . . . . . . . . . . . . . . . 44		6.9.1. The Flow Control Window . . . . . . . . . . . . . . . 43
	6.9.2. Initial Flow Control Window Size . . . . . . . . . . . 45		6.9.2. Initial Flow Control Window Size . . . . . . . . . . . 44
	6.9.3. Reducing the Stream Window Size . . . . . . . . . . . 46		6.9.3. Reducing the Stream Window Size . . . . . . . . . . . 45
	6.10. CONTINUATION . . . . . . . . . . . . . . . . . . . . . . . 46		6.10. CONTINUATION . . . . . . . . . . . . . . . . . . . . . . . 46
	6.11. ALTSVC . . . . . . . . . . . . . . . . . . . . . . . . . . 47		6.11. ALTSVC . . . . . . . . . . . . . . . . . . . . . . . . . . 47
			6.12. BLOCKED . . . . . . . . . . . . . . . . . . . . . . . . . 49
	7. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 49		7. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 49
	8. HTTP Message Exchanges . . . . . . . . . . . . . . . . . . . . 50		8. HTTP Message Exchanges . . . . . . . . . . . . . . . . . . . . 51
	8.1. HTTP Request/Response Exchange . . . . . . . . . . . . . . 51		8.1. HTTP Request/Response Exchange . . . . . . . . . . . . . . 51
	8.1.1. Informational Responses . . . . . . . . . . . . . . . 52		8.1.1. Informational Responses . . . . . . . . . . . . . . . 52
	8.1.2. Examples . . . . . . . . . . . . . . . . . . . . . . . 53		8.1.2. Examples . . . . . . . . . . . . . . . . . . . . . . . 53
	8.1.3. HTTP Header Fields . . . . . . . . . . . . . . . . . . 55		8.1.3. HTTP Header Fields . . . . . . . . . . . . . . . . . . 55
	8.1.4. Request Reliability Mechanisms in HTTP/2 . . . . . . . 59		8.1.4. Request Reliability Mechanisms in HTTP/2 . . . . . . . 59
	8.2. Server Push . . . . . . . . . . . . . . . . . . . . . . . 60		8.2. Server Push . . . . . . . . . . . . . . . . . . . . . . . 60
	8.2.1. Push Requests . . . . . . . . . . . . . . . . . . . . 60		8.2.1. Push Requests . . . . . . . . . . . . . . . . . . . . 61
	8.2.2. Push Responses . . . . . . . . . . . . . . . . . . . . 61		8.2.2. Push Responses . . . . . . . . . . . . . . . . . . . . 62
	8.3. The CONNECT Method . . . . . . . . . . . . . . . . . . . . 62		8.3. The CONNECT Method . . . . . . . . . . . . . . . . . . . . 63
	9. Additional HTTP Requirements/Considerations . . . . . . . . . 63		9. Additional HTTP Requirements/Considerations . . . . . . . . . 64
	9.1. Connection Management . . . . . . . . . . . . . . . . . . 63		9.1. Connection Management . . . . . . . . . . . . . . . . . . 64
	9.2. Use of TLS Features . . . . . . . . . . . . . . . . . . . 64		9.2. Use of TLS Features . . . . . . . . . . . . . . . . . . . 65
	9.3. GZip Content-Encoding . . . . . . . . . . . . . . . . . . 65		9.3. GZip Content-Encoding . . . . . . . . . . . . . . . . . . 65
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 65		10. Security Considerations . . . . . . . . . . . . . . . . . . . 66
	10.1. Server Authority . . . . . . . . . . . . . . . . . . . . . 65		10.1. Server Authority . . . . . . . . . . . . . . . . . . . . . 66
	10.2. Cross-Protocol Attacks . . . . . . . . . . . . . . . . . . 66		10.2. Cross-Protocol Attacks . . . . . . . . . . . . . . . . . . 66
	10.3. Intermediary Encapsulation Attacks . . . . . . . . . . . . 66		10.3. Intermediary Encapsulation Attacks . . . . . . . . . . . . 67
	10.4. Cacheability of Pushed Responses . . . . . . . . . . . . . 67		10.4. Cacheability of Pushed Responses . . . . . . . . . . . . . 67
	10.5. Denial of Service Considerations . . . . . . . . . . . . . 67		10.5. Denial of Service Considerations . . . . . . . . . . . . . 67
	10.6. Use of Compression . . . . . . . . . . . . . . . . . . . . 68		10.6. Use of Compression . . . . . . . . . . . . . . . . . . . . 68
	10.7. Use of Padding . . . . . . . . . . . . . . . . . . . . . . 68		10.7. Use of Padding . . . . . . . . . . . . . . . . . . . . . . 69
	10.8. Privacy Considerations . . . . . . . . . . . . . . . . . . 69		10.8. Privacy Considerations . . . . . . . . . . . . . . . . . . 70
			11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 70
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 69		11.1. Registration of HTTP/2 Identification Strings . . . . . . 70
	11.1. Registration of HTTP/2 Identification String . . . . . . . 70		11.2. Error Code Registry . . . . . . . . . . . . . . . . . . . 71
	11.2. Error Code Registry . . . . . . . . . . . . . . . . . . . 70
	11.3. HTTP2-Settings Header Field Registration . . . . . . . . . 71		11.3. HTTP2-Settings Header Field Registration . . . . . . . . . 71
	11.4. PRI Method Registration . . . . . . . . . . . . . . . . . 71		11.4. PRI Method Registration . . . . . . . . . . . . . . . . . 72
	12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 71		12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 72
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 72		13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 73
	13.1. Normative References . . . . . . . . . . . . . . . . . . . 72		13.1. Normative References . . . . . . . . . . . . . . . . . . . 73
	13.2. Informative References . . . . . . . . . . . . . . . . . . 74		13.2. Informative References . . . . . . . . . . . . . . . . . . 74
	Appendix A. Change Log (to be removed by RFC Editor before		Appendix A. Change Log (to be removed by RFC Editor before
	publication) . . . . . . . . . . . . . . . . . . . . 74		publication) . . . . . . . . . . . . . . . . . . . . 75
	A.1. Since draft-ietf-httpbis-http2-10 . . . . . . . . . . . . 74		A.1. Since draft-ietf-httpbis-http2-11 . . . . . . . . . . . . 75
	A.2. Since draft-ietf-httpbis-http2-09 . . . . . . . . . . . . 75		A.2. Since draft-ietf-httpbis-http2-10 . . . . . . . . . . . . 75
	A.3. Since draft-ietf-httpbis-http2-08 . . . . . . . . . . . . 75		A.3. Since draft-ietf-httpbis-http2-09 . . . . . . . . . . . . 76
	A.4. Since draft-ietf-httpbis-http2-07 . . . . . . . . . . . . 75		A.4. Since draft-ietf-httpbis-http2-08 . . . . . . . . . . . . 76
	A.5. Since draft-ietf-httpbis-http2-06 . . . . . . . . . . . . 75		A.5. Since draft-ietf-httpbis-http2-07 . . . . . . . . . . . . 76
	A.6. Since draft-ietf-httpbis-http2-05 . . . . . . . . . . . . 76		A.6. Since draft-ietf-httpbis-http2-06 . . . . . . . . . . . . 76
	A.7. Since draft-ietf-httpbis-http2-04 . . . . . . . . . . . . 76		A.7. Since draft-ietf-httpbis-http2-05 . . . . . . . . . . . . 77
	A.8. Since draft-ietf-httpbis-http2-03 . . . . . . . . . . . . 76		A.8. Since draft-ietf-httpbis-http2-04 . . . . . . . . . . . . 77
	A.9. Since draft-ietf-httpbis-http2-02 . . . . . . . . . . . . 77		A.9. Since draft-ietf-httpbis-http2-03 . . . . . . . . . . . . 77
	A.10. Since draft-ietf-httpbis-http2-01 . . . . . . . . . . . . 77		A.10. Since draft-ietf-httpbis-http2-02 . . . . . . . . . . . . 78
	A.11. Since draft-ietf-httpbis-http2-00 . . . . . . . . . . . . 78		A.11. Since draft-ietf-httpbis-http2-01 . . . . . . . . . . . . 78
	A.12. Since draft-mbelshe-httpbis-spdy-00 . . . . . . . . . . . 78		A.12. Since draft-ietf-httpbis-http2-00 . . . . . . . . . . . . 79
			A.13. Since draft-mbelshe-httpbis-spdy-00 . . . . . . . . . . . 79
	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) was designed to be implemented with the tools at hand in the		3) was designed to be implemented with the tools at hand in the
	1990s, not modern Web application performance. As such it has		1990s, not modern Web application performance. As such it has
	several characteristics that have a negative overall effect on		several characteristics that have a negative overall effect on
	application performance today.		application performance today.
	skipping to change at page 6, line 22		skipping to change at page 6, line 22
	to ensure that only data that can be used by a receiver is		to ensure that only data that can be used by a receiver is
	transmitted. Prioritization (Section 5.3) ensures that limited		transmitted. Prioritization (Section 5.3) ensures that limited
	resources can be directed to the most important requests first.		resources can be directed to the most important requests first.
	HTTP/2 adds a new interaction mode, whereby a server can push		HTTP/2 adds a new interaction mode, whereby a server can push
	responses to a client (Section 8.2). Server push allows a server to		responses to a client (Section 8.2). Server push allows a server to
	speculatively send a client data that the server anticipates the		speculatively send a client data that the server anticipates the
	client will need, trading off some network usage against a potential		client will need, trading off some network usage against a potential
	latency gain. The server does this by synthesizing a request, which		latency gain. The server does this by synthesizing a request, which
	it sends as a PUSH_PROMISE frame. The server is then able to send a		it sends as a PUSH_PROMISE frame. The server is then able to send a
	response to the synthetic request on an separate stream.		response to the synthetic request on a separate stream.
	Frames that contain HTTP header fields are compressed (Section 4.3).		Frames that contain HTTP header fields are compressed (Section 4.3).
	HTTP requests can be highly redundant, so compression can reduce the		HTTP requests can be highly redundant, so compression can reduce the
	size of requests and responses significantly.		size of requests and responses significantly.
	HTTP/2 also supports HTTP Alternative Services (see [ALT-SVC]) using		HTTP/2 also supports HTTP Alternative Services (see [ALT-SVC]) using
	the ALTSVC frame type (Section 6.11), to allow servers more control		the ALTSVC frame type (Section 6.11), to allow servers more control
	over traffic to them.		over traffic to them.
	2.1. Document Organization		2.1. Document Organization
	skipping to change at page 10, line 19		skipping to change at page 10, line 19
	...		...
	A server that supports HTTP/2 can accept the upgrade with a 101		A server that supports HTTP/2 can accept the upgrade with a 101
	(Switching Protocols) response. After the empty line that terminates		(Switching Protocols) response. After the empty line that terminates
	the 101 response, the server can begin sending HTTP/2 frames. These		the 101 response, the server can begin sending HTTP/2 frames. These
	frames MUST include a response to the request that initiated the		frames MUST include a response to the request that initiated the
	Upgrade.		Upgrade.
	HTTP/1.1 101 Switching Protocols		HTTP/1.1 101 Switching Protocols
	Connection: Upgrade		Connection: Upgrade
	Upgrade: h2		Upgrade: h2c
	[ HTTP/2 connection ...		[ HTTP/2 connection ...
	The first HTTP/2 frame sent by the server is a SETTINGS frame		The first HTTP/2 frame sent by the server is a SETTINGS frame
	(Section 6.5). Upon receiving the 101 response, the client sends a		(Section 6.5). Upon receiving the 101 response, the client sends a
	connection preface (Section 3.5), which includes a SETTINGS frame.		connection preface (Section 3.5), which includes a SETTINGS frame.
	The HTTP/1.1 request that is sent prior to upgrade is assigned stream		The HTTP/1.1 request that is sent prior to upgrade is assigned stream
	identifier 1 and is assigned default priority values (Section 5.3.5).		identifier 1 and is assigned default priority values (Section 5.3.5).
	Stream 1 is implicitly half closed from the client toward the server,		Stream 1 is implicitly half closed from the client toward the server,
	skipping to change at page 23, line 20		skipping to change at page 23, line 20
	A client can assign a priority for a new stream by including		A client can assign a priority for a new stream by including
	prioritization information in the HEADERS frame (Section 6.2) that		prioritization information in the HEADERS frame (Section 6.2) that
	opens the stream. For an existing stream, the PRIORITY frame		opens the stream. For an existing stream, the PRIORITY frame
	(Section 6.3) can be used to change the priority.		(Section 6.3) can be used to change the priority.
	The purpose of prioritization is to allow an endpoint to express how		The purpose of prioritization is to allow an endpoint to express how
	it would prefer its peer allocate resources when managing concurrent		it would prefer its peer allocate resources when managing concurrent
	streams. Most importantly, priority can be used to select streams		streams. Most importantly, priority can be used to select streams
	for transmitting frames when there is limited capacity for sending.		for transmitting frames when there is limited capacity for sending.
	Each stream is prioritized into a group. Each group is identified		Streams can be prioritized by marking them as dependent on the
	using an identifier that is selected by the client. Each group is		completion of other streams (Section 5.3.1). Each dependency is
	assigned a relative weight, a number that is used to determine the		assigned a relative weight, a number that is used to determine the
	relative proportion of available resources that are assigned to that		relative proportion of available resources that are assigned to
	group.		streams dependent on the same stream.
	Within a priority group, streams can also be marked as being
	dependent on the completion of other streams.
	Explicitly setting the priority for a stream is input to a		Explicitly setting the priority for a stream is input to a
	prioritization process. It does not guarantee any particular		prioritization process. It does not guarantee any particular
	processing or transmission order for the stream relative to any other		processing or transmission order for the stream relative to any other
	stream. An endpoint cannot force a peer to process concurrent		stream. An endpoint cannot force a peer to process concurrent
	streams in a particular order using priority. Expressing priority is		streams in a particular order using priority. Expressing priority is
	therefore only ever a suggestion.		therefore only ever a suggestion.
	Prioritization information can be specified explicitly for streams as		Prioritization information can be specified explicitly for streams as
	they are created using the HEADERS frame, or changed using the		they are created using the HEADERS frame, or changed using the
	PRIORITY frame. Providing prioritization information is optional, so		PRIORITY frame. Providing prioritization information is optional, so
	default values are used if no explicit indicator is provided		default values are used if no explicit indicator is provided
	(Section 5.3.5).		(Section 5.3.5).
	Explicit prioritization information can be provided for a stream to		5.3.1. Stream Dependencies
	either allocate the stream to a priority group (Section 5.3.1), or to
	create a dependency on another stream (Section 5.3.2).
	5.3.1. Priority Groups and Weighting
	All streams are assigned a priority group. Each priority group is
	allocated a 31-bit identifier and an integer weight between 1 to 256
	(inclusive).
	Specifying a priority group and weight for a stream causes the stream
	to be assigned to the identified priority group and for the weight
	for the group to be changed to the new value.
	Resources are divided proportionally between priority groups based on
	their weight. For example, a priority group with weight 4 ideally
	receives one third of the resources allocated to a stream with weight
	12.
	5.3.2. Stream Dependencies
	Each stream can be given an explicit dependency on another stream.		Each stream can be given an explicit dependency on another stream.
	Including a dependency expresses a preference to allocate resources		Including a dependency expresses a preference to allocate resources
	to the identified stream rather than to the dependent stream.		to the identified stream rather than to the dependent stream.
	A stream that is dependent on another stream becomes part of the		A stream that is not dependent on any other stream can given a stream
	priority group of the stream it depends on. It belongs to the same		dependency of 0x0.
	dependency tree as the stream it depends on.
	A stream that is assigned directly to a priority group is not
	dependent on any other stream. It is the root of a dependency tree
	inside its priority group.
	When assigning a dependency on another stream, by default, the stream		When assigning a dependency on another stream, by default, the stream
	is added as a new dependency of the stream it depends on. For		is added as a new dependency of the stream it depends on. For
	example, if streams B and C are dependent on stream A, and if stream		example, if streams B and C are dependent on stream A, and if stream
	D is created with a dependency on stream A, this results in a		D is created with a dependency on stream A, this results in a
	dependency order of A followed by B, C, and D.		dependency order of A followed by B, C, and D.
	A A		A A
	/ \ ==> /|\		/ \ ==> /|\
	B C B D C		B C B D C
	Example of Default Dependency Creation		Example of Default Dependency Creation
	An exclusive flag allows for the insertion of a new level of		An exclusive flag allows for the insertion of a new level of
	dependencies. The exclusive flag causes the stream to become the		dependencies. The exclusive flag causes the stream to become the
	sole dependency of the stream it depends on, causing other		sole dependency of the stream it depends on, causing other
	dependencies to become dependencies of the stream. In the previous		dependencies to become dependencies of the stream. In the previous
	example, if stream D is created with an exclusive dependency on		example, if stream D is created with an exclusive dependency on
	stream A, this results in a dependency order of A followed by D		stream A, this results in a dependency order of A followed by D
	followed by B and C.		followed by B and C.
	A		A
	A |		A |
	/ \ ==> D		/ \ ==> D
	B C / \		B C / \
	B C		B C
	Example of Exclusive Dependency Creation		Example of Exclusive Dependency Creation
	Streams are ordered into several dependency trees within their		Inside the dependency tree, a dependent stream SHOULD only be
	priority group. Each dependency tree within a priority group SHOULD		allocated resources if the streams that it depends on are either
	be allocated the same amount of resources.		closed, or it is not possible to make progress on them.
	Inside a dependency tree, a dependent stream SHOULD only be allocated		5.3.2. Dependency Weighting
	resources if the streams that it depends on are either closed, or it
	is not possible to make progress on them.
	Streams with the same dependencies SHOULD be allocated the same		Each dependency is allocated an integer weight between 1 to 256
	amount of resources. Thus, if streams B and C depend on stream A,		(inclusive).
	and if no progress can be made on A, streams B and C are given an
	equal share of resources.		Streams with the same dependencies SHOULD be allocated resources
			proportionally based on their weight. Thus, if stream B depends on
			stream A with weight 4, and C depends on stream A with weight 12, and
			if no progress can be made on A, stream B ideally receives one third
			of the resources allocated to stream C.
	A stream MUST NOT depend on itself. An endpoint MAY either treat		A stream MUST NOT depend on itself. An endpoint MAY either treat
	this as a stream error (Section 5.4.2) of type PROTOCOL_ERROR, or		this as a stream error (Section 5.4.2) of type PROTOCOL_ERROR, or
	assign default priority values (Section 5.3.5) to the stream.		assign default priority values (Section 5.3.5) to the stream.
	5.3.3. Reprioritization		5.3.3. Reprioritization
	Stream priorities are changed using the PRIORITY frame. Setting a		Stream priorities are changed using the PRIORITY frame. Setting a
	priority group and weight causes a stream to become part of the
	identified group, and not dependent on any other stream. Setting a
	dependency causes a stream to become dependent on the identified		dependency causes a stream to become dependent on the identified
	stream, which can cause the reprioritized stream to move to a new		stream.
	priority group.
	All streams that are dependent on a reprioritized stream move with		All streams that are dependent on a reprioritized stream move with
	it. Setting a dependency with the exclusive flag for a reprioritized		it. Setting a dependency with the exclusive flag for a reprioritized
	stream moves all the dependencies of the stream it depends on to		stream moves all the dependencies of the stream it depends on to
	become dependencies of the reprioritized stream.		become dependencies of the reprioritized stream.
			If a stream is made dependent on one of its own dependencies, the
			formerly dependent stream is first moved to be depedent on the
			reprioritized streams previous dependency, retaining its weight.
			For example, for an original dependency tree where B and C depend on
			A, D and E depend on C, and F depends on D; if A is made dependent on
			D, then D takes the place of A with A dependent on D and all other
			dependency relationships staying the same.
			0
			A / \ D D
			/ \ D A / \ OR |
			B C ==> / / \ ==> F A ==> A
			/ \ F B C / \ /|\
			D E | B C B C F
			| E | |
			F E F
			(intermediate) (non-exclusive) (exclusive)
			Example of Dependency Reordering
	5.3.4. Prioritization State Management		5.3.4. Prioritization State Management
	When a stream is closed, its dependencies can be moved to become		When a stream is removed from the dependency tree, its dependencies
	dependent on the stream the closed stream depends on, if any, or to		can be moved to become dependent on the stream the closed stream
	become new dependency tree roots otherwise.		depends on. The weights of new dependencies SHOULD be assigned by
			distributing the weight of the dependency of the closed stream
			proportionally based on the weights of its dependencies.
			Streams that are removed from the dependency tree cause some
			prioritization information to be lost. Resources are shared between
			streams that depend on the same stream, which means that if a stream
			in that set closes or becomes blocked, any spare capacity allocated
			to a stream is distributed to the immediate neighbors of the stream.
			However, if the common dependency is removed from the tree, those
			streams share resources with streams at the next highest level. For
			example, assume streams A and B share a dependency, and C and D both
			depend on A. Prior to the removal of A, if stream A and D are unable
			to proceed, then C receives all the resources dedicated to A. If A is
			removed from the tree, the weight of A is divided equally between D
			and E, which results in stream C receiving a reduced proportion of
			resources (one third, rather than one half).
	It is possible for a stream to become closed while prioritization		It is possible for a stream to become closed while prioritization
	information that creates a dependency on that stream is in transit.		information that creates a dependency on that stream is in transit.
	If a stream identified in a dependency has been closed and any		If a stream identified in a dependency has been closed and any
	associated priority information destroyed then the dependent stream		associated priority information destroyed then the dependent stream
	is instead assigned a default priority. This potentially creates		is instead assigned a default priority. This potentially creates
	suboptimal prioritization, since the stream can be given an effective		suboptimal prioritization, since the stream can be given an effective
	priority that is higher than expressed by a peer.		priority that is higher than expressed by a peer.
	To avoid this problem, endpoints SHOULD maintain prioritization state		To avoid these problems, endpoints SHOULD maintain prioritization
	for closed streams for a period after streams close. This could		state for closed streams for a period after streams close.
	create an large state burden for an endpoint, so this state MAY be
	limited. The amount of additional state an endpoint maintains could
	be dependent on load; under high load, prioritization state can be
	discarded to limit resource commitments. In extreme cases, an
	endpoint could even discard prioritization state for active or
	reserved streams.
	An endpoint SHOULD retain stream prioritization state for at least
	one round trip, though maintaining state over longer periods reduces
	the chance that default values have to be assigned to streams. An
	endpoint MAY apply a fixed upper limit on the number of closed
	streams for which prioritization state is tracked to limit state
	exposure. If a fixed limit is applied, endpoints SHOULD maintain
	state for at least as many streams as allowed by their setting for
	SETTINGS_MAX_CONCURRENT_STREAMS.
	An endpoint receiving a PRIORITY frame that changes the priority of a		An endpoint SHOULD retain stream prioritization state for a period
	closed stream SHOULD alter the weight of the priority group, or the		after streams become closed. The longer state is retained, the lower
	dependencies of the streams that depend on it, if it has retained		the chance that streams are assigned incorrect or default priority
	enough state to do so.		values.
	Priority group information is part of the priority state of a stream.		This could create a large state burden for an endpoint, so this state
	Priority groups that contain only closed streams can be assigned a		MAY be limited. An endpoint MAY apply a fixed upper limit on the
	weight of zero.		number of closed streams for which prioritization state is tracked to
			limit state exposure. The amount of additional state an endpoint
			maintains could be dependent on load; under high load, prioritization
			state can be discarded to limit resource commitments. In extreme
			cases, an endpoint could even discard prioritization state for active
			or reserved streams. If a fixed limit is applied, endpoints SHOULD
			maintain state for at least as many streams as allowed by their
			setting for SETTINGS_MAX_CONCURRENT_STREAMS.
	The number of priority groups cannot exceed the number of non-closed		An endpoint receiving a PRIORITY frame that changes the priority of a
	streams. This includes streams in the "reserved" state. Priority		closed stream SHOULD alter the dependencies of the streams that
	state size for peer-initiated streams is limited by the value of		depend on it, if it has retained enough state to do so.
	SETTINGS_MAX_CONCURRENT_STREAMS. Reserved streams do not count
	toward the concurrent stream limit of either peer, but only the
	endpoint that creates the reservation needs to maintain priority
	information. Thus, the total amount of priority state for non-closed
	streams can be limited by an endpoint.
	5.3.5. Default Priorities		5.3.5. Default Priorities
	Providing priority information is optional. Streams are assigned to		Providing priority information is optional. Streams are assigned a
	a priority group with an identifier equal to the stream identifier		dependency on stream 0x0. Pushed streams (Section 8.2) initially
	and a weight of 16.		depend on their associated stream. In both cases, streams are
			assigned a default weight of 16.
	Pushed streams (Section 8.2) initially depend on their associated
	stream.
	5.4. Error Handling		5.4. Error Handling
	HTTP/2 framing permits two classes of error:		HTTP/2 framing permits two classes of error:
	o An error condition that renders the entire connection unusable is		o An error condition that renders the entire connection unusable is
	a connection error.		a connection error.
	o An error in an individual stream is a stream error.		o An error in an individual stream is a stream error.
	skipping to change at page 29, line 37		skipping to change at page 29, line 30
	END_STREAM (0x1): Bit 1 being set indicates that this frame is the		END_STREAM (0x1): Bit 1 being set indicates that this frame is the
	last that the endpoint will send for the identified stream.		last that the endpoint will send for the identified stream.
	Setting this flag causes the stream to enter one of the "half		Setting this flag causes the stream to enter one of the "half
	closed" states or the "closed" state (Section 5.1).		closed" states or the "closed" state (Section 5.1).
	END_SEGMENT (0x2): Bit 2 being set indicates that this frame is the		END_SEGMENT (0x2): Bit 2 being set indicates that this frame is the
	last for the current segment. Intermediaries MUST NOT coalesce		last for the current segment. Intermediaries MUST NOT coalesce
	frames across a segment boundary and MUST preserve segment		frames across a segment boundary and MUST preserve segment
	boundaries when forwarding frames.		boundaries when forwarding frames.
	PAD_LOW (0x08): Bit 4 being set indicates that the Pad Low field is		PAD_LOW (0x8): Bit 4 being set indicates that the Pad Low field is
	present.		present.
	PAD_HIGH (0x10): Bit 5 being set indicates that the Pad High field		PAD_HIGH (0x10): Bit 5 being set indicates that the Pad High field
	is present. This bit MUST NOT be set unless the PAD_LOW flag is		is present. This bit MUST NOT be set unless the PAD_LOW flag is
	also set. Endpoints that receive a frame with PAD_HIGH set and		also set. Endpoints that receive a frame with PAD_HIGH set and
	PAD_LOW cleared MUST treat this as a connection error		PAD_LOW cleared MUST treat this as a connection error
	(Section 5.4.1) of type PROTOCOL_ERROR.		(Section 5.4.1) of type PROTOCOL_ERROR.
			COMPRESSED (0x20): Bit 6 being set indicates that the data in the
			frame has been compressed with GZIP compression ([GZIP]).
	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 optionally compressed using GZip compression [GZIP].
			Each frame is individually compressed; the state of the compressor is
			reset for each frame.
			An endpoint MUST NOT send a DATA frame with the COMPRESSED flag set
			unless the SETTINGS_COMPRESS_DATA setting is enabled, that is, set to
			1. An endpoint that has not enabled DATA frame compression MUST
			treat the receipt of a DATA frame with the COMPRESSED flag set as a
			connection error (Section 5.4.1) of type 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. Padding is		stream is in the "open" or "half closed (remote)" states. Padding is
	included in flow control. If a DATA frame is received whose stream		included in flow control. If a DATA frame is received whose stream
	is not in "open" or "half closed (local)" state, the recipient MUST		is not in "open" or "half closed (local)" state, the recipient MUST
	respond with a stream error (Section 5.4.2) of type STREAM_CLOSED.		respond with a stream error (Section 5.4.2) of type STREAM_CLOSED.
	The total number of padding octets is determined by multiplying the		The total number of padding octets is determined by multiplying the
	value of the Pad High field by 256 and adding the value of the Pad		value of the Pad High field by 256 and adding the value of the Pad
	Low field. Both Pad High and Pad Low fields assume a value of zero		Low field. Both Pad High and Pad Low fields assume a value of zero
	if absent. If the length of the padding is greater than the length		if absent. If the length of the padding is greater than the length
	skipping to change at page 30, line 32		skipping to change at page 30, line 38
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Pad High? (8) | Pad Low? (8) |		| Pad High? (8) | Pad Low? (8) |
	+-+-------------+---------------+-------------------------------+		+-+-------------+---------------+-------------------------------+
	|R| Priority Group Identifier? (31) |		|E| Stream Dependency? (31) |
	+-+-------------+-----------------------------------------------+		+-+-------------+-----------------------------------------------+
	| Weight? (8) |		| Weight? (8) |
	+-+-------------+-----------------------------------------------+		+-+-------------+-----------------------------------------------+
	|E| Stream Dependency? (31) |
	+-+-------------------------------------------------------------+
	| Header Block Fragment (*) ...		| Header Block Fragment (*) ...
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
	| Padding (*) ...		| Padding (*) ...
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
	HEADERS Frame Payload		HEADERS Frame Payload
	The HEADERS frame payload has the following fields:		The HEADERS frame payload has the following fields:
	Pad High: Padding size high bits. This field is only present if the		Pad High: Padding size high bits. This field is only present if the
	PAD_HIGH flag is set.		PAD_HIGH flag is set.
	Pad Low: Padding size low bits. This field is only present if the		Pad Low: Padding size low bits. This field is only present if the
	PAD_LOW flag is set.		PAD_LOW flag is set.
	R: A single reserved bit. This field is optional and is only present
	if the PRIORITY_GROUP flag is set.
	Priority Group Identifier: A 31-bit identifier for a priority group,
	see Section 5.3. This field is optional and is only present if
	the PRIORITY_GROUP flag is set.
	Weight: An 8-bit weight for the identified priority group, see
	Section 5.3. This field is optional and is only present if the
	PRIORITY_GROUP flag is set.
	E: A single bit flag indicates that the stream dependency is		E: A single bit flag indicates that the stream dependency is
	exclusive, see Section 5.3. This field is optional and is only		exclusive, see Section 5.3. This field is optional and is only
	present if the PRIORITY_DEPENDENCY flag is set.		present if the PRIORITY flag is set.
	Stream Dependency: A 31-bit stream identifier for the stream that		Stream Dependency: A 31-bit stream identifier for the stream that
	this stream depends on, see Section 5.3. This field is optional		this stream depends on, see Section 5.3. This field is optional
	and is only present if the PRIORITY_DEPENDENCY flag is set.		and is only present if the PRIORITY flag is set.
			Weight: An 8-bit weight for the stream, see Section 5.3. Add one to
			the value to obtain a weight between 1 and 256. This field is
			optional and is only present if the PRIORITY flag is set.
	Header Block Fragment: A header block fragment (Section 4.3).		Header Block Fragment: A header block fragment (Section 4.3).
	Padding: Padding octets.		Padding: Padding octets.
	The HEADERS frame defines the following flags:		The HEADERS frame defines the following flags:
	END_STREAM (0x1): Bit 1 being set indicates that the header block		END_STREAM (0x1): Bit 1 being set indicates that the header block
	(Section 4.3) is the last that the endpoint will send for the		(Section 4.3) is the last that the endpoint will send for the
	identified stream. Setting this flag causes the stream to enter		identified stream. Setting this flag causes the stream to enter
	skipping to change at page 32, line 17		skipping to change at page 32, line 14
	PAD_LOW (0x8): Bit 4 being set indicates that the Pad Low field is		PAD_LOW (0x8): Bit 4 being set indicates that the Pad Low field is
	present.		present.
	PAD_HIGH (0x10): Bit 5 being set indicates that the Pad High field		PAD_HIGH (0x10): Bit 5 being set indicates that the Pad High field
	is present. This bit MUST NOT be set unless the PAD_LOW flag is		is present. This bit MUST NOT be set unless the PAD_LOW flag is
	also set. Endpoints that receive a frame with PAD_HIGH set and		also set. Endpoints that receive a frame with PAD_HIGH set and
	PAD_LOW cleared MUST treat this as a connection error		PAD_LOW cleared MUST treat this as a connection error
	(Section 5.4.1) of type PROTOCOL_ERROR.		(Section 5.4.1) of type PROTOCOL_ERROR.
	PRIORITY_GROUP (0x20): Bit 6 being set indicates that the Priority		PRIORITY (0x20): Bit 6 being set indicates that the Exclusive Flag
	Group Identifier and Weight fields are present; see Section 5.3.		(E), Stream Dependency, and Weight fields are present; see
	PRIORITY_DEPENDENCY (0x40): Bit 7 being set indicates that the
	Exclusive Flag (E) and Stream Dependency fields are present; see
	Section 5.3.		Section 5.3.
	The payload of a HEADERS frame contains a header block fragment		The payload of a HEADERS frame contains a header block fragment
	(Section 4.3). A header block that does not fit within a HEADERS		(Section 4.3). A header block that does not fit within a HEADERS
	frame is continued in a CONTINUATION frame (Section 6.10).		frame is continued in a CONTINUATION frame (Section 6.10).
	HEADERS frames MUST be associated with a stream. If a HEADERS frame		HEADERS frames MUST be associated with a stream. If a HEADERS frame
	is received whose stream identifier field is 0x0, the recipient MUST		is 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.
	A HEADERS frame MUST NOT have both the PRIORITY_GROUP and
	PRIORITY_DEPENDENCY flags set. Receipt of a HEADERS frame with both
	these flags set MUST be treated as a stream error (Section 5.4.2) of
	type PROTOCOL_ERROR.
	The HEADERS frame changes the connection state as described in		The HEADERS frame changes the connection state as described in
	Section 4.3.		Section 4.3.
	The HEADERS frame includes optional padding. Padding fields and		The HEADERS frame includes optional padding. Padding fields and
	flags are identical to those defined for DATA frames (Section 6.1).		flags are identical to those defined for DATA frames (Section 6.1).
	6.3. PRIORITY		6.3. PRIORITY
	The PRIORITY frame (type=0x2) specifies the sender-advised priority		The PRIORITY frame (type=0x2) specifies the sender-advised priority
	of a stream (Section 5.3). It can be sent at any time for an		of a stream (Section 5.3). It can be sent at any time for an
	existing stream. This enables reprioritisation of existing streams.		existing stream. This enables reprioritization of existing streams.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|R| Priority Group Identifier? (31) |		|E| Stream Dependency (31) |
	+-+-------------+-----------------------------------------------+
	| Weight? (8) |
	+-+-------------+-----------------------------------------------+		+-+-------------+-----------------------------------------------+
	|E| Stream Dependency? (31) |		| Weight (8) |
	+-+-------------------------------------------------------------+		+-+-------------+
	PRIORITY Frame Payload		PRIORITY Frame Payload
	The payload of a PRIORITY frame contains the following fields:		The payload of a PRIORITY frame contains the following fields:
	R: A single reserved bit. This field is optional and is only present
	if the PRIORITY_GROUP flag is set.
	Priority Group Identifier: A 31-bit identifier for a priority group,
	see Section 5.3. This field is optional and is only present if
	the PRIORITY_GROUP flag is set.
	Weight: An 8-bit weight for the identified priority group, see
	Section 5.3. This field is optional and is only present if the
	PRIORITY_GROUP flag is set.
	E: A single bit flag indicates that the stream dependency is		E: A single bit flag indicates that the stream dependency is
	exclusive, see Section 5.3. This field is optional and is only		exclusive, see Section 5.3.
	present if the PRIORITY_DEPENDENCY flag is set.
	Stream Dependency: A 31-bit stream identifier for the stream that		Stream Dependency: A 31-bit stream identifier for the stream that
	this stream depends on, see Section 5.3. This field is optional		this stream depends on, see Section 5.3.
	and is only present if the PRIORITY_DEPENDENCY flag is set.
	The PRIORITY frame defines the following flags:
	PRIORITY_GROUP (0x20): Bit 6 being set indicates that the Priority
	Group Identifier and Weight fields are present; see Section 5.3.
	PRIORITY_DEPENDENCY (0x40): Bit 7 being set indicates that the		Weight: An 8-bit weight for the identified stream dependency, see
	Exclusive Flag (E) and Stream Dependency fields are present; see		Section 5.3. Add one to the value to obtain a weight between 1
	Section 5.3.		and 256.
	A PRIORITY frame MUST have exactly one of the PRIORITY_GROUP and		The PRIORITY frame does not define any flags.
	PRIORITY_DEPENDENCY flags set. Receipt of a PRIORITY frame with
	either none or both these flags set MUST be treated as a stream error
	(Section 5.4.2) of type PROTOCOL_ERROR.
	The PRIORITY frame is associated with an existing stream. If a		The PRIORITY frame is associated with an existing stream. If a
	PRIORITY frame is received with a stream identifier of 0x0, the		PRIORITY frame is received with a stream identifier of 0x0, the
	recipient MUST respond with a connection error (Section 5.4.1) of		recipient MUST respond with a connection error (Section 5.4.1) of
	type PROTOCOL_ERROR.		type PROTOCOL_ERROR.
	The PRIORITY frame can be sent on a stream in any of the "reserved		The PRIORITY frame can be sent on a stream in any of the "reserved
	(remote)", "open", "half-closed (local)", or "half closed (remote)"		(remote)", "open", "half-closed (local)", or "half closed (remote)"
	states, though it cannot be sent between consecutive frames that		states, though it cannot be sent between consecutive frames that
	comprise a single header block (Section 4.3). Note that this frame		comprise a single header block (Section 4.3). Note that this frame
	skipping to change at page 37, line 23		skipping to change at page 36, line 36
	window size (in bytes) for stream level flow control. The initial		window size (in bytes) for stream level flow control. The initial
	value is 65,535.		value is 65,535.
	This setting affects the window size of all streams, including		This setting affects the window size of all streams, including
	existing streams, see Section 6.9.2.		existing streams, see Section 6.9.2.
	Values above the maximum flow control window size of 2^31 - 1 MUST		Values above the maximum flow control window size of 2^31 - 1 MUST
	be treated as a connection error (Section 5.4.1) of type		be treated as a connection error (Section 5.4.1) of type
	FLOW_CONTROL_ERROR.		FLOW_CONTROL_ERROR.
			SETTINGS_COMPRESS_DATA (5): This setting is used to enable GZip
			compression of DATA frames.
			A value of 1 indicates that DATA frames MAY be compressed. A
			value of 0 indicates that compression is not permitted. The
			initial value is 0.
			Values other than 0 or 1 are invalid. An endpoint MUST treat the
			receipt of any other value as a connection error (Section 5.4.1)
			of type PROTOCOL_ERROR.
	An endpoint that receives a SETTINGS frame with any other identifier		An endpoint that receives a SETTINGS frame with any other identifier
	MUST treat this as a connection error (Section 5.4.1) of type		MUST treat this as a connection error (Section 5.4.1) of type
	PROTOCOL_ERROR.		PROTOCOL_ERROR.
	6.5.3. Settings Synchronization		6.5.3. Settings Synchronization
	Most values in SETTINGS benefit from or require an understanding of		Most values in SETTINGS benefit from or require an understanding of
	when the peer has received and applied the changed the communicated		when the peer has received and applied the changed the communicated
	parameter values. In order to provide such synchronization		parameter values. In order to provide such synchronization
	timepoints, the recipient of a SETTINGS frame in which the ACK flag		timepoints, the recipient of a SETTINGS frame in which the ACK flag
	skipping to change at page 40, line 30		skipping to change at page 40, line 7
	| Opaque Data (64) |		| Opaque Data (64) |
	| |		| |
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
	PING Payload Format		PING Payload Format
	In addition to the frame header, PING frames MUST contain 8 octets of		In addition to the frame header, PING frames MUST contain 8 octets of
	data in the payload. A sender can include any value it chooses and		data in the payload. A sender can include any value it chooses and
	use those bytes in any fashion.		use those bytes in any fashion.
	Receivers of a PING frame that does not include a ACK flag MUST send		Receivers of a PING frame that does not include an ACK flag MUST send
	a PING frame with the ACK flag set in response, with an identical		a PING frame with the ACK flag set in response, with an identical
	payload. PING responses SHOULD be given higher priority than any		payload. PING responses SHOULD be given higher priority than any
	other frame.		other frame.
	The PING frame defines the following flags:		The PING frame defines the following flags:
	ACK (0x1): Bit 1 being set indicates that this PING frame is a PING		ACK (0x1): Bit 1 being set indicates that this PING frame is a PING
	response. An endpoint MUST set this flag in PING responses. An		response. An endpoint MUST set this flag in PING responses. An
	endpoint MUST NOT respond to PING frames containing this flag.		endpoint MUST NOT respond to PING frames containing this flag.
	skipping to change at page 41, line 36		skipping to change at page 41, line 10
	Endpoints SHOULD always send a GOAWAY frame before closing a		Endpoints SHOULD always send a GOAWAY frame before closing a
	connection so that the remote can know whether a stream has been		connection so that the remote can know whether a stream has been
	partially processed or not. For example, if an HTTP client sends a		partially processed or not. For example, if an HTTP client sends a
	POST at the same time that a server closes a connection, the client		POST at the same time that a server closes a connection, the client
	cannot know if the server started to process that POST request if the		cannot know if the server started to process that POST request if the
	server does not send a GOAWAY frame to indicate where it stopped		server does not send a GOAWAY frame to indicate where it stopped
	working. An endpoint might choose to close a connection without		working. An endpoint might choose to close a connection without
	sending GOAWAY for misbehaving peers.		sending GOAWAY for misbehaving peers.
	After sending a GOAWAY frame, the sender can discard frames for new
	streams. However, any frames that alter connection state cannot be
	completely ignored. For instance, HEADERS, PUSH_PROMISE and
	CONTINUATION frames MUST be minimally processed to ensure the state
	maintained for header compression is consistent (see Section 4.3);
	similarly DATA frames MUST be counted toward the connection flow
	control window.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|R| Last-Stream-ID (31) |		|R| Last-Stream-ID (31) |
	+-+-------------------------------------------------------------+		+-+-------------------------------------------------------------+
	| Error Code (32) |		| Error Code (32) |
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
	| Additional Debug Data (*) |		| Additional Debug Data (*) |
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
	GOAWAY Payload Format		GOAWAY Payload Format
	The GOAWAY frame does not define any flags.		The GOAWAY frame does not define any flags.
	The GOAWAY frame applies to the connection, not a specific stream.		The GOAWAY frame applies to the connection, not a specific stream.
	An endpoint MUST treat a GOAWAY frame with a stream identifier other		An endpoint MUST treat a GOAWAY frame with a stream identifier other
	than 0x0 as a connection error (Section 5.4.1) of type		than 0x0 as a connection error (Section 5.4.1) of type
	PROTOCOL_ERROR.		PROTOCOL_ERROR.
	The last stream identifier in the GOAWAY frame contains the highest		The last stream identifier in the GOAWAY frame contains the highest
	skipping to change at page 42, line 17		skipping to change at page 41, line 33
	The GOAWAY frame applies to the connection, not a specific stream.		The GOAWAY frame applies to the connection, not a specific stream.
	An endpoint MUST treat a GOAWAY frame with a stream identifier other		An endpoint MUST treat a GOAWAY frame with a stream identifier other
	than 0x0 as a connection error (Section 5.4.1) of type		than 0x0 as a connection error (Section 5.4.1) of type
	PROTOCOL_ERROR.		PROTOCOL_ERROR.
	The last stream identifier in the GOAWAY frame contains the highest		The last stream identifier in the GOAWAY frame contains the highest
	numbered stream identifier for which the sender of the GOAWAY frame		numbered stream identifier for which the sender of the GOAWAY frame
	has received frames and might have taken some action on. All streams		has received frames and might have taken some action on. All streams
	up to and including the identified stream might have been processed		up to and including the identified stream might have been processed
	in some way. The last stream identifier is set to 0 if no streams		in some way. The last stream identifier can be set to 0 if no
	were processed.		streams were processed.
	Note: In this case, "processed" means that some data from the		Note: In this context, "processed" means that some data from the
	stream was passed to some higher layer of software that might have		stream was passed to some higher layer of software that might have
	taken some action as a result.		taken some action as a result.
	If a connection terminates without a GOAWAY frame, this value is		If a connection terminates without a GOAWAY frame, this value is
	effectively the highest stream identifier.		effectively the highest possible stream identifier.
	On streams with lower or equal numbered identifiers that were not		On streams with lower or equal numbered identifiers that were not
	closed completely prior to the connection being closed, re-attempting		closed completely prior to the connection being closed, re-attempting
	requests, transactions, or any protocol activity is not possible		requests, transactions, or any protocol activity is not possible
	(with the exception of idempotent actions like HTTP GET, PUT, or		(with the exception of idempotent actions like HTTP GET, PUT, or
	DELETE). Any protocol activity that uses higher numbered streams can		DELETE). Any protocol activity that uses higher numbered streams can
	be safely retried using a new connection.		be safely retried using a new connection.
	Activity on streams numbered lower or equal to the last stream		Activity on streams numbered lower or equal to the last stream
	identifier might still complete successfully. The sender of a GOAWAY		identifier might still complete successfully. The sender of a GOAWAY
	frame might gracefully shut down a connection by sending a GOAWAY		frame might gracefully shut down a connection by sending a GOAWAY
	frame, maintaining the connection in an open state until all in-		frame, maintaining the connection in an open state until all in-
	progress streams complete.		progress streams complete.
	The last stream ID MUST be 0 if no streams were acted upon.		An endpoint MAY send multiple GOAWAY frames if circumstances change.
			For instance, an endpoint that sends GOAWAY with NO_ERROR during
			graceful shutdown could subsequently encounter an condition that
			requires immediate termination of the connection. The last stream
			identifier from the last GOAWAY frame received applies.
	If an endpoint maintains the connection and continues to exchange		After sending a GOAWAY frame, the sender can discard frames for
	frames, ignored frames MUST be counted toward flow control limits		streams with identifiers higher than the identified last stream.
	(Section 5.2) or update header compression state (Section 4.3).		However, any frames that alter connection state cannot be completely
	Otherwise, flow control or header compression state can become		ignored. For instance, HEADERS, PUSH_PROMISE and CONTINUATION frames
	unsynchronized.		MUST be minimally processed to ensure the state maintained for header
			compression is consistent (see Section 4.3); similarly DATA frames
			MUST be counted toward the connection flow control window. Failure
			to process these frames can cause flow control or header compression
			state to become unsynchronized.
	The GOAWAY frame also contains a 32-bit error code (Section 7) that		The GOAWAY frame also contains a 32-bit error code (Section 7) that
	contains the reason for closing the connection.		contains the reason for closing the connection.
	Endpoints MAY append opaque data to the payload of any GOAWAY frame.		Endpoints MAY append opaque data to the payload of any GOAWAY frame.
	Additional debug data is intended for diagnostic purposes only and		Additional debug data is intended for diagnostic purposes only and
	carries no semantic value. Debug information could contain security-		carries no semantic value. Debug information could contain security-
	or privacy-sensitive data. Logged or otherwise persistently stored		or privacy-sensitive data. Logged or otherwise persistently stored
	debug data MUST have adequate safeguards to prevent unauthorized		debug data MUST have adequate safeguards to prevent unauthorized
	access.		access.
	6.9. WINDOW_UPDATE		6.9. WINDOW_UPDATE
	The WINDOW_UPDATE frame (type=0x8) is used to implement flow control;		The WINDOW_UPDATE frame (type=0x8) is used to implement flow control;
	see Section 5.2 for an overview.		see Section 5.2 for an overview.
	skipping to change at page 43, line 31		skipping to change at page 43, line 6
	between dependent connections. However, throttling of data transfer		between dependent connections. However, throttling of data transfer
	by any receiver can indirectly cause the propagation of flow control		by any receiver can indirectly cause the propagation of flow control
	information toward the original sender.		information toward the original sender.
	Flow control only applies to frames that are identified as being		Flow control only applies to frames that are identified as being
	subject to flow control. Of the frame types defined in this		subject to flow control. Of the frame types defined in this
	document, this includes only DATA frame. Frames that are exempt from		document, this includes only DATA frame. Frames that are exempt from
	flow control MUST be accepted and processed, unless the receiver is		flow control MUST be accepted and processed, unless the receiver is
	unable to assign resources to handling the frame. A receiver MAY		unable to assign resources to handling the frame. A receiver MAY
	respond with a stream error (Section 5.4.2) or connection error		respond with a stream error (Section 5.4.2) or connection error
	(Section 5.4.1) of type FLOW_CONTROL_ERROR if it is unable accept a		(Section 5.4.1) of type FLOW_CONTROL_ERROR if it is unable to accept
	frame.		a frame.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|R| Window Size Increment (31) |		|R| Window Size Increment (31) |
	+-+-------------------------------------------------------------+		+-+-------------------------------------------------------------+
	WINDOW_UPDATE Payload Format		WINDOW_UPDATE Payload Format
	The payload of a WINDOW_UPDATE frame is one reserved bit, plus an		The payload of a WINDOW_UPDATE frame is one reserved bit, plus an
	skipping to change at page 45, line 13		skipping to change at page 44, line 37
	control window to exceed this maximum it MUST terminate either the		control window to exceed this maximum it MUST terminate either the
	stream or the connection, as appropriate. For streams, the sender		stream or the connection, as appropriate. For streams, the sender
	sends a RST_STREAM with the error code of FLOW_CONTROL_ERROR code;		sends a RST_STREAM with the error code of FLOW_CONTROL_ERROR code;
	for the connection, a GOAWAY frame with a FLOW_CONTROL_ERROR code.		for the connection, a GOAWAY frame with a FLOW_CONTROL_ERROR code.
	Flow controlled frames from the sender and WINDOW_UPDATE frames from		Flow controlled frames from the sender and WINDOW_UPDATE frames from
	the receiver are completely asynchronous with respect to each other.		the receiver are completely asynchronous with respect to each other.
	This property allows a receiver to aggressively update the window		This property allows a receiver to aggressively update the window
	size kept by the sender to prevent streams from stalling.		size kept by the sender to prevent streams from stalling.
			A sender that is unable to send data on a stream due to either flow
			control window being zero or lower MAY send a BLOCKED frame
			(Section 6.12) in order to inform the receiver of a potential flow
			control problem.
	6.9.2. Initial Flow Control Window Size		6.9.2. Initial Flow Control Window Size
	When an HTTP/2 connection is first established, new streams are		When an HTTP/2 connection is first established, new streams are
	created with an initial flow control window size of 65,535 bytes.		created with an initial flow control window size of 65,535 bytes.
	The connection flow control window is 65,535 bytes. Both endpoints		The connection flow control window is 65,535 bytes. Both endpoints
	can adjust the initial window size for new streams by including a		can adjust the initial window size for new streams by including a
	value for SETTINGS_INITIAL_WINDOW_SIZE in the SETTINGS frame that		value for SETTINGS_INITIAL_WINDOW_SIZE in the SETTINGS frame that
	forms part of the connection preface. The connection flow control		forms part of the connection preface. The connection flow control
	window initial size cannot be changed.		window initial size cannot be changed.
	skipping to change at page 48, line 21		skipping to change at page 48, line 9
	An ALTSVC frame on stream 0 indicates that the conveyed alternative		An ALTSVC frame on stream 0 indicates that the conveyed alternative
	service is associated with the origin contained in the Origin field		service is associated with the origin contained in the Origin field
	of the frame. An association with an origin that the client does not		of the frame. An association with an origin that the client does not
	consider authoritative for the current connection MUST be ignored.		consider authoritative for the current connection MUST be ignored.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Max-Age (32) |		| Max-Age (32) |
	+-------------------------------+----------------+--------------+		+-------------------------------+---------------+---------------+
	| Port (16) | Reserved (8) | PID_LEN (8) |		| Port (16) | Reserved (8) | Proto-Len (8) |
	+-------------------------------+----------------+--------------+		+-------------------------------+---------------+---------------+
	| Protocol-ID (*) |		| Protocol-ID (*) |
	+---------------+-----------------------------------------------+		+---------------+-----------------------------------------------+
	| HOST_LEN (8) | Host (*) ...		| Host-Len (8) | Host (*) ...
	+---------------+-----------------------------------------------+		+---------------+-----------------------------------------------+
	| Origin? (*) ...		| Origin? (*) ...
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
			ALTSVC Frame Payload
	The ALTSVC frame contains the following fields:		The ALTSVC frame contains the following fields:
	Max-Age: An unsigned, 32-bit integer indicating the freshness		Max-Age: An unsigned, 32-bit integer indicating the freshness
	lifetime of the alternative service association, as per [ALT-SVC],		lifetime of the alternative service association, as per [ALT-SVC],
	Section 2.2.		Section 2.2.
	Port: An unsigned, 16-bit integer indicating the port that the		Port: An unsigned, 16-bit integer indicating the port that the
	alternative service is available upon.		alternative service is available upon.
	Reserved: For future use. Senders MUST set these bits to '0', and		Reserved: For future use. Senders MUST set these bits to '0', and
	recipients MUST ignore them.		recipients MUST ignore them.
	PID_LEN: An unsigned, 8-bit integer indicating the length, in		Proto-Len: An unsigned, 8-bit integer indicating the length, in
	octets, of the PROTOCOL-ID field.		octets, of the Protocol-ID field.
	Protocol-ID: A sequence of bytes (length determined by PID_LEN)		Protocol-ID: A sequence of bytes (length determined by "Proto-Len")
	containing the ALPN protocol identifier of the alternative		containing the ALPN protocol identifier of the alternative
	service.		service.
	HOST_LEN: An unsigned, 8-bit integer indicating the length, in		Host-Len: An unsigned, 8-bit integer indicating the length, in
	octets, of the Host field.		octets, of the Host field.
	Host: A sequence of characters (length determined by HOST_LEN)		Host: A sequence of characters (length determined by "Host-Len")
	containing an ASCII string indicating the host that the		containing an ASCII string indicating the host that the
	alternative service is available upon. An internationalized		alternative service is available upon. An internationalized
	domain name [IDNA] MUST be expressed using A-labels.		domain name [IDNA] MUST be expressed using A-labels.
	Origin: An optional sequence of characters (length determined by		Origin: An optional sequence of characters (length determined by
	subtracting the length of all preceding fields from the frame		subtracting the length of all preceding fields from the frame
	length) containing ASCII serialisation of an origin ([RFC6454],		length) containing the ASCII serialisation of an origin
	Section 6.2) that the alternate service is applicable to.		([RFC6454], Section 6.2) that the alternate service is applicable
			to.
	The ALTSVC frame does not define any flags.		The ALTSVC frame does not define any flags.
	The ALTSVC frame is intended for receipt by clients; a server that		The ALTSVC frame is intended for receipt by clients; a server that
	receives an ALTSVC frame MUST treat it as a connection error of type		receives an ALTSVC frame MUST treat it as a connection error
	PROTOCOL_ERROR.		(Section 5.4.1) of type PROTOCOL_ERROR.
	The ALTSVC frame is processed hop-by-hop. An intermediary MUST NOT		The ALTSVC frame is processed hop-by-hop. An intermediary MUST NOT
	forward ALTSVC frames, though it can use the information contained in		forward ALTSVC frames, though it can use the information contained in
	ALTSVC frames in forming new ALTSVC frames to send to its own		ALTSVC frames in forming new ALTSVC frames to send to its own
	clients.		clients.
			6.12. BLOCKED
			The BLOCKED frame (type=0xB) indicates that the sender is unable to
			send data due to a closed flow control window.
			[[anchor12: The BLOCKED frame is included in this draft version to
			facilitate experimentation. If the results of the experiment do not
			provide positive feedback, it could be removed.]]
			The BLOCKED frame is used to provide feedback about the performance
			of flow control for the purposes of performance tuning and debugging.
			The BLOCKED frame can be sent by a peer when flow controlled data
			cannot be sent due to the connection- or stream-level flow control.
			This frame MUST NOT be sent if there are other reasons preventing
			data from being sent, either a lack of available data, or the
			underlying transport being blocked.
			The BLOCKED frame is sent on the stream that is blocked, that is, the
			stream with a non-positive number of bytes available in the flow
			control window. A BLOCKED frame can be sent on stream 0x0 to
			indicate that connection-level flow control is blocked.
			An endpoint MUST NOT send any subsequent BLOCKED frames until the
			affected flow control window becomes positive. This means that
			WINDOW_UPDATE frames are received or SETTINGS_INITIAL_WINDOW_SIZE is
			increased before more BLOCKED frames can be sent.
			The BLOCKED frame defines no flags and contains no payload. A
			receiver MUST treat the receipt of a BLOCKED frame with a payload as
			a connection error (Section 5.4.1) of type FRAME_SIZE_ERROR.
	7. Error Codes		7. Error Codes
	Error codes are 32-bit fields that are used in RST_STREAM and GOAWAY		Error codes are 32-bit fields that are used in RST_STREAM and GOAWAY
	frames to convey the reasons for the stream or connection error.		frames to convey the reasons for the stream or connection error.
	Error codes share a common code space. Some error codes only apply		Error codes share a common code space. Some error codes only apply
	to specific conditions and have no defined semantics in certain frame		to specific conditions and have no defined semantics in certain frame
	types.		types.
	The following error codes are defined:		The following error codes are defined:
	skipping to change at page 53, line 16		skipping to change at page 53, line 34
	other 1xx informational responses.		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 requests and responses.		illustrations of equivalent HTTP/2 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 HEADERS frame, followed by zero or		therefore transmitted as a single HEADERS frame, followed by zero or
	more CONTINUATION frames containing the serialized block of request		more CONTINUATION frames containing the serialized block of request
	header fields. The last HEADERS frame in the sequence has both the		header fields. The HEADERS frame in the following has both the
	END_HEADERS and END_STREAM flags set:		END_HEADERS and END_STREAM flags set; no CONTINUATION frames are
			sent:
	GET /resource HTTP/1.1 HEADERS		GET /resource HTTP/1.1 HEADERS
	Host: example.org ==> + END_STREAM		Host: example.org ==> + END_STREAM
	Accept: image/jpeg + END_HEADERS		Accept: image/jpeg + END_HEADERS
	:method = GET		:method = GET
	:scheme = https		:scheme = https
	:path = /resource		:path = /resource
	host = example.org		host = example.org
	accept = image/jpeg		accept = image/jpeg
	Similarly, a response that includes only response header fields is		Similarly, a response that includes only response header fields is
	transmitted as a HEADERS frame (again, followed by zero or more		transmitted as a HEADERS frame (again, followed by zero or more
	CONTINUATION frames) containing the serialized block of response		CONTINUATION frames) containing the serialized block of response
	header fields. The last HEADERS frame in the sequence has both the		header fields.
	END_HEADERS and END_STREAM flag set:
	HTTP/1.1 304 Not Modified HEADERS		HTTP/1.1 304 Not Modified HEADERS
	ETag: "xyzzy" ==> + END_STREAM		ETag: "xyzzy" ==> + END_STREAM
	Expires: Thu, 23 Jan ... + END_HEADERS		Expires: Thu, 23 Jan ... + END_HEADERS
	:status = 304		:status = 304
	etag: "xyzzy"		etag: "xyzzy"
	expires: Thu, 23 Jan ...		expires: Thu, 23 Jan ...
	An HTTP POST request that includes request header fields and payload		An HTTP POST request that includes request header fields and payload
	data is transmitted as one HEADERS frame, followed by zero or more		data is transmitted as one HEADERS frame, followed by zero or more
	CONTINUATION frames containing the request header fields, followed by		CONTINUATION frames containing the request header fields, followed by
	one or more DATA frames, with the last CONTINUATION (or HEADERS)		one or more DATA frames, with the last CONTINUATION (or HEADERS)
	frame having the END_HEADERS flag set and the final DATA frame having		frame having the END_HEADERS flag set and the final DATA frame having
	the END_STREAM flag set:		the END_STREAM flag set:
	POST /resource HTTP/1.1 HEADERS		POST /resource HTTP/1.1 HEADERS
	Host: example.org ==> - END_STREAM		Host: example.org ==> - END_STREAM
	Content-Type: image/jpeg + END_HEADERS		Content-Type: image/jpeg - END_HEADERS
	Content-Length: 123 :method = POST		Content-Length: 123 :method = POST
	:scheme = https		:path = /resource
	{binary data} :path = /resource		{binary data} content-type = image/jpeg
			CONTINUATION
			+ END_HEADERS
	:authority = example.org		:authority = example.org
	content-type = image/jpeg		:scheme = https
	content-length = 123		content-length = 123
	DATA		DATA
	+ END_STREAM		+ END_STREAM
	{binary data}		{binary data}
			Note that data contributing to any given header field could be spread
			between header block fragments. The allocation of header fields to
			frames in this example is illustrative only.
	A response that includes header fields and payload data is		A response that includes header fields and payload data is
	transmitted as a HEADERS frame, followed by zero or more CONTINUATION		transmitted as a HEADERS frame, followed by zero or more CONTINUATION
	frames, followed by one or more DATA frames, with the last DATA frame		frames, followed by one or more DATA frames, with the last DATA frame
	in the sequence having the END_STREAM flag set:		in the sequence having the END_STREAM flag set:
	HTTP/1.1 200 OK HEADERS		HTTP/1.1 200 OK HEADERS
	Content-Type: image/jpeg ==> - END_STREAM		Content-Type: image/jpeg ==> - END_STREAM
	Content-Length: 123 + END_HEADERS		Content-Length: 123 + END_HEADERS
	:status = 200		:status = 200
	{binary data} content-type = image/jpeg		{binary data} content-type = image/jpeg
	content-length = 123		content-length = 123
	DATA		DATA
	+ END_STREAM		+ END_STREAM
	{binary data}		{binary data}
	Trailing header fields are sent as a header block after both the		Trailing header fields are sent as a header block after both the
	request or response header block and all the DATA frames have been		request or response header block and all the DATA frames have been
	sent. The sequence of HEADERS/CONTINUATION frames that bears the		sent. The HEADERS frame starting the trailers header block has the
	trailers includes a terminal frame that has both END_HEADERS and		END_STREAM flag set.
	END_STREAM flags set.
	HTTP/1.1 200 OK HEADERS		HTTP/1.1 200 OK HEADERS
	Content-Type: image/jpeg ==> - END_STREAM		Content-Type: image/jpeg ==> - END_STREAM
	Transfer-Encoding: chunked + END_HEADERS		Transfer-Encoding: chunked + END_HEADERS
	Trailer: Foo :status = 200		Trailer: Foo :status = 200
	content-length = 123		content-length = 123
	123 content-type = image/jpeg		123 content-type = image/jpeg
	{binary data} trailer = Foo		{binary data} trailer = Foo
	0		0
	Foo: bar DATA		Foo: bar DATA
	skipping to change at page 59, line 15		skipping to change at page 59, line 28
	8.1.3.5. Malformed Messages		8.1.3.5. Malformed Messages
	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 frames, but is otherwise invalid due to the presence of		HTTP/2 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 uncompressed DATA frame payload lengths that
			form the body.
			Note: The "Content-Length" header field is set to the length of an
			entity body. Compression of DATA frames is a function of HTTP/2
			that does not alter entities.
	Intermediaries that process HTTP requests or responses (i.e., all		Intermediaries that process HTTP requests or responses (i.e., all
	intermediaries other than those acting as tunnels) MUST NOT forward a		intermediaries other than those acting as tunnels) MUST NOT forward a
	malformed request or response.		malformed request or response.
	Implementations that detect malformed requests or responses need to		Implementations that detect malformed requests or responses need to
	ensure that the stream ends. For malformed requests, a server MAY		ensure that the stream ends. For malformed requests, a server MAY
	send an HTTP response prior to closing or resetting the stream.		send an HTTP response prior to closing or resetting the stream.
	Clients MUST NOT accept a malformed response. Note that these		Clients MUST NOT accept a malformed response. Note that these
	requirements are intended to protect against several types of common		requirements are intended to protect against several types of common
	skipping to change at page 60, line 37		skipping to change at page 61, line 8
	0 to indicate that server push is disabled.		0 to indicate that server push is disabled.
	Because pushing responses is effectively hop-by-hop, an intermediary		Because pushing responses is effectively hop-by-hop, an intermediary
	could receive pushed responses from the server and choose not to		could receive pushed responses from the server and choose not to
	forward those on to the client. In other words, how to make use of		forward those on to the client. In other words, how to make use of
	the pushed responses is up to that intermediary. Equally, the		the pushed responses is up to that intermediary. Equally, the
	intermediary might choose to push additional responses to the client,		intermediary might choose to push additional responses to the client,
	without any action taken by the server.		without any action taken by the server.
	A client cannot push. Thus, servers MUST treat the receipt of a		A client cannot push. Thus, servers MUST treat the receipt of a
	PUSH_PROMISE frame as a connection error (Section 5.4.1). Clients		PUSH_PROMISE frame as a connection error (Section 5.4.1) of type
	MUST reject any attempt to change the SETTINGS_ENABLE_PUSH setting to		PROTOCOL_ERROR. Clients MUST reject any attempt to change the
	a value other than "0" by treating the message as a connection error		SETTINGS_ENABLE_PUSH setting to a value other than "0" by treating
	(Section 5.4.1) of type PROTOCOL_ERROR.		the message as a connection error (Section 5.4.1) of type
			PROTOCOL_ERROR.
	A server can only push responses that are cacheable (see [HTTP-p6],		A server can only push responses that are cacheable (see [HTTP-p6],
	Section 3); promised requests MUST be safe (see [HTTP-p2], Section		Section 3); promised requests MUST be safe (see [HTTP-p2], Section
	4.2.1) and MUST NOT include a request body.		4.2.1) and MUST NOT include a request body.
	8.2.1. Push Requests		8.2.1. Push Requests
	Server push is semantically equivalent to a server responding to a		Server push is semantically equivalent to a server responding to a
	request; however, in this case that request is also sent by the		request; however, in this case that request is also sent by the
	server, as a PUSH_PROMISE frame.		server, as a PUSH_PROMISE frame.
	skipping to change at page 62, line 28		skipping to change at page 62, line 48
	A client can use the SETTINGS_MAX_CONCURRENT_STREAMS setting to limit		A client can use the SETTINGS_MAX_CONCURRENT_STREAMS setting to limit
	the number of responses that can be concurrently pushed by a server.		the number of responses 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 provide the response, see Section 10.1. For example,		authorized to provide the response, see Section 10.1. For example, a
	an server that offers a certificate for only the "example.com" DNS-ID		server that offers a certificate for only the "example.com" DNS-ID or
	or Common Name is not permitted to push a response for		Common Name is not permitted to push a response for
	"https://www.example.org/doc".		"https://www.example.org/doc".
	8.3. The CONNECT Method		8.3. The CONNECT Method
	In HTTP/1.x, the pseudo-method CONNECT ([HTTP-p2], Section 4.3.6) is		In HTTP/1.x, the pseudo-method CONNECT ([HTTP-p2], Section 4.3.6) is
	used to convert an HTTP connection into a tunnel to a remote host.		used to convert an HTTP connection into a tunnel to a remote host.
	CONNECT is primarily used with HTTP proxies to establish a TLS		CONNECT is primarily used with HTTP proxies to establish a TLS
	session with an origin server for the purposes of interacting with		session with an origin server for the purposes of interacting with
	"https" resources.		"https" resources.
	skipping to change at page 64, line 17		skipping to change at page 64, line 35
	destination, where a destination is the IP address and port that is		destination, where a destination is the IP address and port that is
	derived from a URI, a selected alternative service [ALT-SVC], or a		derived from a URI, a selected alternative service [ALT-SVC], or a
	configured proxy. A client can create additional connections as		configured proxy. A client can create additional connections as
	replacements, either to replace connections that are near to		replacements, either to replace connections that are near to
	exhausting the available stream identifier space (Section 5.1.1), or		exhausting the available stream identifier space (Section 5.1.1), or
	to replace connections that have encountered errors (Section 5.4.1).		to replace connections that have encountered errors (Section 5.4.1).
	A client MAY open multiple connections to the same IP address and TCP		A client MAY open multiple connections to the same IP address and TCP
	port using different Server Name Indication [TLS-EXT] values or to		port using different Server Name Indication [TLS-EXT] values or to
	provide different TLS client certificates, but SHOULD avoid creating		provide different TLS client certificates, but SHOULD avoid creating
	multiple connections with the same configuration. [[anchor15: Need		multiple connections with the same configuration. [[anchor17: Need
	more text on how client certificates relate here, see issue #363.]]		more text on how client certificates relate here, see issue #363.]]
	Clients MAY use a single server connection to send requests for URIs		Clients MAY use a single server connection to send requests for URIs
	with multiple different authority components as long as the server is		with multiple different authority components as long as the server is
	authoritative (Section 10.1).		authoritative (Section 10.1).
	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
	skipping to change at page 65, line 48		skipping to change at page 66, line 20
	10.1. Server Authority		10.1. Server Authority
	A client is only able to accept HTTP/2 responses from servers that		A client is only able to accept HTTP/2 responses from servers that
	are authoritative for those resources. This is particularly		are authoritative for those resources. This is particularly
	important for server push (Section 8.2), where the client validates		important for server push (Section 8.2), where the client validates
	the PUSH_PROMISE before accepting the response.		the PUSH_PROMISE before accepting the response.
	HTTP/2 relies on the HTTP/1.1 definition of authority for determining		HTTP/2 relies on the HTTP/1.1 definition of authority for determining
	whether a server is authoritative in providing a given response, see		whether a server is authoritative in providing a given response, see
	[HTTP-p1], Section 9.1). This relies on local name resolution for		[HTTP-p1], Section 9.1. This relies on local name resolution for the
	the "http" URI scheme, and the offered server identity for the		"http" URI scheme, and the offered server identity for the "https"
	"https" scheme (see [RFC2818], Section 3).		scheme (see [RFC2818], Section 3).
	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
	In a cross-protocol attack, an attacker causes a client to initiate a		In a cross-protocol attack, an attacker causes a client to initiate a
	transaction in one protocol toward a server that understands a		transaction in one protocol toward a server that understands a
	different protocol. An attacker might be able to cause the		different protocol. An attacker might be able to cause the
	transaction to appear as valid transaction in the second protocol.		transaction to appear as valid transaction in the second protocol.
	skipping to change at page 67, line 38		skipping to change at page 68, line 10
	An HTTP/2 connection can demand a greater commitment of resources to		An HTTP/2 connection can demand a greater commitment of resources to
	operate than a HTTP/1.1 connection. The use of header compression		operate than a HTTP/1.1 connection. The use of header compression
	and flow control depend on a commitment of resources for storing a		and flow control depend on a commitment of resources for storing a
	greater amount of state. Settings for these features ensure that		greater amount of state. Settings for these features ensure that
	memory commitments for these features are strictly bounded.		memory commitments for these features are strictly bounded.
	Processing capacity cannot be guarded in the same fashion.		Processing capacity cannot be guarded in the same fashion.
	The SETTINGS frame can be abused to cause a peer to expend additional		The SETTINGS frame can be abused to cause a peer to expend additional
	processing time. This might be done by pointlessly changing SETTINGS		processing time. This might be done by pointlessly changing SETTINGS
	parameters, setting multiple undefined parameters, or changing the		parameters, setting multiple undefined parameters, or changing the
	same setting multiple times in the same frame. WINDOW_UPDATE or		same setting multiple times in the same frame. WINDOW_UPDATE,
	PRIORITY frames can be abused to cause an unnecessary waste of		PRIORITY, or BLOCKED frames can be abused to cause an unnecessary
	resources. A server might erroneously issue ALTSVC frames for		waste of resources. A server might erroneously issue ALTSVC frames
	origins on which it cannot be authoritative to generate excess work		for origins on which it cannot be authoritative to generate excess
	for clients.		work for clients.
	Large numbers of small or empty frames can be abused to cause a peer		Large numbers of small or empty frames can be abused to cause a peer
	to expend time processing frame headers. Note however that some uses		to expend time processing frame headers. Note however that some uses
	are entirely legitimate, such as the sending of an empty DATA frame		are entirely legitimate, such as the sending of an empty DATA frame
	to end a stream.		to end a stream.
	Header compression also offers some opportunities to waste processing		Header compression also offers some opportunities to waste processing
	resources; see [COMPRESSION] for more details on potential abuses.		resources; see [COMPRESSION] for more details on potential abuses.
	Limits in SETTINGS parameters cannot be reduced instantaneously,		Limits in SETTINGS parameters cannot be reduced instantaneously,
	skipping to change at page 68, line 38		skipping to change at page 69, line 11
	multiple requests containing varying plaintext, observing the length		multiple requests containing varying plaintext, observing the length
	of the resulting ciphertext in each, which reveals a shorter length		of the resulting ciphertext in each, which reveals a shorter length
	when a guess about the secret is correct.		when a guess about the secret is correct.
	Implementations communicating on a secure channel MUST NOT compress		Implementations communicating on a secure channel MUST NOT compress
	content that includes both confidential and attacker-controlled data		content that includes both confidential and attacker-controlled data
	unless separate compression dictionaries are used for each source of		unless separate compression dictionaries are used for each source of
	data. Compression MUST NOT be used if the source of data cannot be		data. Compression MUST NOT be used if the source of data cannot be
	reliably determined.		reliably determined.
			Intermediaries MUST NOT alter the compression of DATA frames unless
			additional information is available that allows the intermediary to
			identify the source of data. In particular, frames that are not
			compressed cannot be compressed, and frames that are separately
			compressed cannot be merged into a single frame. Compressed frames
			MAY be decompressed or split into multiple frames.
	Further considerations regarding the compression of header fields are		Further considerations regarding the compression of header fields are
	described in [COMPRESSION].		described in [COMPRESSION].
	10.7. Use of Padding		10.7. Use of Padding
	Padding within HTTP/2 is not intended as a replacement for general		Padding within HTTP/2 is not intended as a replacement for general
	purpose padding, such as might be provided by TLS [TLS12]. Redundant		purpose padding, such as might be provided by TLS [TLS12]. Redundant
	padding could even be counterproductive. Correct application can		padding could even be counterproductive. Correct application can
	depend on having specific knowledge of the data that is being padded.		depend on having specific knowledge of the data that is being padded.
	skipping to change at page 70, line 5		skipping to change at page 70, line 34
	This document establishes a registry for error codes. This new		This document establishes a registry for error codes. This new
	registry is entered into a new "Hypertext Transfer Protocol (HTTP) 2		registry is entered into a new "Hypertext Transfer Protocol (HTTP) 2
	Parameters" section.		Parameters" section.
	This document registers the "HTTP2-Settings" header field for use in		This document registers the "HTTP2-Settings" header field for use in
	HTTP.		HTTP.
	This document registers the "PRI" method for use in HTTP, to avoid		This document registers the "PRI" method for use in HTTP, to avoid
	collisions with the connection preface (Section 3.5).		collisions with the connection preface (Section 3.5).
	11.1. Registration of HTTP/2 Identification String		11.1. Registration of HTTP/2 Identification Strings
	This document creates two registrations for the identification of		This document creates two registrations for the identification of
	HTTP/2 in the "Application Layer Protocol Negotiation (ALPN) Protocol		HTTP/2 in the "Application Layer Protocol Negotiation (ALPN) Protocol
	IDs" registry established in [TLSALPN].		IDs" registry established in [TLSALPN].
	The "h2" string identifies HTTP/2 when used over TLS:		The "h2" string identifies HTTP/2 when used over TLS:
	Protocol: HTTP/2 over TLS		Protocol: HTTP/2 over TLS
	Identification Sequence: 0x68 0x32 ("h2")		Identification Sequence: 0x68 0x32 ("h2")
	skipping to change at page 72, line 31		skipping to change at page 73, line 17
	Alternative Services", draft-ietf-httpbis-alt-svc-01		Alternative Services", draft-ietf-httpbis-alt-svc-01
	(work in progress), April 2014.		(work in progress), April 2014.
	[COMPRESSION] Ruellan, H. and R. Peon, "HPACK - Header Compression		[COMPRESSION] Ruellan, H. and R. Peon, "HPACK - Header Compression
	for HTTP/2", draft-ietf-httpbis-header-compression-07		for HTTP/2", draft-ietf-httpbis-header-compression-07
	(work in progress), April 2014.		(work in progress), April 2014.
	[COOKIE] Barth, A., "HTTP State Management Mechanism",		[COOKIE] Barth, A., "HTTP State Management Mechanism",
	RFC 6265, April 2011.		RFC 6265, April 2011.
			[GZIP] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and
			G. Randers-Pehrson, "GZIP file format specification
			version 4.3", RFC 1952, May 1996.
	[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-26 (work in		Routing", draft-ietf-httpbis-p1-messaging-26 (work in
	progress), February 2014.		progress), February 2014.
	[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-26 (work in progress),		draft-ietf-httpbis-p2-semantics-26 (work in progress),
	February 2014.		February 2014.
	skipping to change at page 74, line 41		skipping to change at page 75, line 32
	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>.
	[TLSBCP] Sheffer, Y., Holz, R., and P. Saint-Andre,		[TLSBCP] Sheffer, Y., Holz, R., and P. Saint-Andre,
	"Recommendations for Secure Use of TLS and DTLS",		"Recommendations for Secure Use of TLS and DTLS",
	draft-sheffer-tls-bcp-02 (work in progress),		draft-sheffer-tls-bcp-02 (work in progress),
	February 2014.		February 2014.
	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-10		A.1. Since draft-ietf-httpbis-http2-11
			Added BLOCKED frame (at risk).
			Simplified priority scheme.
			Added DATA per-frame GZip compression.
			A.2. Since draft-ietf-httpbis-http2-10
	Changed "connection header" to "connection preface" to avoid		Changed "connection header" to "connection preface" to avoid
	confusion.		confusion.
	Added dependency-based stream prioritization.		Added dependency-based stream prioritization.
	Added "h2c" identifier to distinguish between cleartext and secured		Added "h2c" identifier to distinguish between cleartext and secured
	HTTP/2.		HTTP/2.
	Adding missing padding to PUSH_PROMISE.		Adding missing padding to PUSH_PROMISE.
	Integrate ALTSVC frame and supporting text.		Integrate ALTSVC frame and supporting text.
	Dropping requirement on "deflate" Content-Encoding.		Dropping requirement on "deflate" Content-Encoding.
	Improving security considerations around use of compression.		Improving security considerations around use of compression.
	A.2. Since draft-ietf-httpbis-http2-09		A.3. Since draft-ietf-httpbis-http2-09
	Adding padding for data frames.		Adding padding for data frames.
	Renumbering frame types, error codes, and settings.		Renumbering frame types, error codes, and settings.
	Adding INADEQUATE_SECURITY error code.		Adding INADEQUATE_SECURITY error code.
	Updating TLS usage requirements to 1.2; forbidding TLS compression.		Updating TLS usage requirements to 1.2; forbidding TLS compression.
	Removing extensibility for frames and settings.		Removing extensibility for frames and settings.
	skipping to change at page 75, line 36		skipping to change at page 76, line 36
	Changing the protocol identification token to "h2".		Changing the protocol identification token to "h2".
	Changing the use of :authority to make it optional and to allow		Changing the use of :authority to make it optional and to allow
	userinfo in non-HTTP cases.		userinfo in non-HTTP cases.
	Allowing split on 0x0 for Cookie.		Allowing split on 0x0 for Cookie.
	Reserved PRI method in HTTP/1.1 to avoid possible future collisions.		Reserved PRI method in HTTP/1.1 to avoid possible future collisions.
	A.3. Since draft-ietf-httpbis-http2-08		A.4. Since draft-ietf-httpbis-http2-08
	Added cookie crumbling for more efficient header compression.		Added cookie crumbling for more efficient header compression.
	Added header field ordering with the value-concatenation mechanism.		Added header field ordering with the value-concatenation mechanism.
	A.4. Since draft-ietf-httpbis-http2-07		A.5. Since draft-ietf-httpbis-http2-07
	Marked draft for implementation.		Marked draft for implementation.
	A.5. Since draft-ietf-httpbis-http2-06		A.6. 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.6. Since draft-ietf-httpbis-http2-05		A.7. 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.7. Since draft-ietf-httpbis-http2-04		A.8. 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.
	skipping to change at page 76, line 49		skipping to change at page 77, line 49
	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.8. Since draft-ietf-httpbis-http2-03		A.9. 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.9. Since draft-ietf-httpbis-http2-02		A.10. 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.10. Since draft-ietf-httpbis-http2-01		A.11. 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 78, line 12		skipping to change at page 79, line 12
	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.11. Since draft-ietf-httpbis-http2-00		A.12. 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.12. Since draft-mbelshe-httpbis-spdy-00		A.13. 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. 104 change blocks.
	285 lines changed or deleted		339 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/