draft-ietf-httpbis-p1-messaging-17.txt		draft-ietf-httpbis-p1-messaging-18.txt
	HTTPbis Working Group R. Fielding, Ed.		HTTPbis Working Group R. Fielding, Ed.
	Internet-Draft Adobe		Internet-Draft Adobe
	Obsoletes: 2145,2616 (if approved) J. Gettys		Obsoletes: 2145,2616 (if approved) J. Gettys
	Updates: 2817 (if approved) Alcatel-Lucent		Updates: 2817 (if approved) Alcatel-Lucent
	Intended status: Standards Track J. Mogul		Intended status: Standards Track J. Mogul
	Expires: May 3, 2012 HP		Expires: July 7, 2012 HP
	H. Frystyk		H. Frystyk
	Microsoft		Microsoft
	L. Masinter		L. Masinter
	Adobe		Adobe
	P. Leach		P. Leach
	Microsoft		Microsoft
	T. Berners-Lee		T. Berners-Lee
	W3C/MIT		W3C/MIT
	Y. Lafon, Ed.		Y. Lafon, Ed.
	W3C		W3C
	J. Reschke, Ed.		J. Reschke, Ed.
	greenbytes		greenbytes
	October 31, 2011		January 4, 2012
	HTTP/1.1, part 1: URIs, Connections, and Message Parsing		HTTP/1.1, part 1: URIs, Connections, and Message Parsing
	draft-ietf-httpbis-p1-messaging-17		draft-ietf-httpbis-p1-messaging-18
	Abstract		Abstract
	The Hypertext Transfer Protocol (HTTP) is an application-level		The Hypertext Transfer Protocol (HTTP) is an application-level
	protocol for distributed, collaborative, hypertext information		protocol for distributed, collaborative, hypertext information
	systems. HTTP has been in use by the World Wide Web global		systems. HTTP has been in use by the World Wide Web global
	information initiative since 1990. This document is Part 1 of the		information initiative since 1990. This document is Part 1 of the
	seven-part specification that defines the protocol referred to as		seven-part specification that defines the protocol referred to as
	"HTTP/1.1" and, taken together, obsoletes RFC 2616 and moves it to		"HTTP/1.1" and, taken together, obsoletes RFC 2616 and moves it to
	historic status, along with its predecessor RFC 2068.		historic status, along with its predecessor RFC 2068.
	skipping to change at page 2, line 11		skipping to change at page 2, line 11
	Discussion of this draft should take place on the HTTPBIS working		Discussion of this draft should take place on the HTTPBIS working
	group mailing list (ietf-http-wg@w3.org), which is archived at		group 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/>.
	The current issues list is at		The current issues list is at
	<http://tools.ietf.org/wg/httpbis/trac/report/3> and related		<http://tools.ietf.org/wg/httpbis/trac/report/3> and related
	documents (including fancy diffs) can be found at		documents (including fancy diffs) can be found at
	<http://tools.ietf.org/wg/httpbis/>.		<http://tools.ietf.org/wg/httpbis/>.
	The changes in this draft are summarized in Appendix C.18.		The changes in this draft are summarized in Appendix C.19.
	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 May 3, 2012.		This Internet-Draft will expire on July 7, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2012 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 3, line 27		skipping to change at page 3, line 27
	2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 10		2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 10
	2.2. Message Orientation and Buffering . . . . . . . . . . . . 11		2.2. Message Orientation and Buffering . . . . . . . . . . . . 11
	2.3. Connections and Transport Independence . . . . . . . . . . 12		2.3. Connections and Transport Independence . . . . . . . . . . 12
	2.4. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 12		2.4. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 12
	2.5. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 14		2.5. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	2.6. Protocol Versioning . . . . . . . . . . . . . . . . . . . 15		2.6. Protocol Versioning . . . . . . . . . . . . . . . . . . . 15
	2.7. Uniform Resource Identifiers . . . . . . . . . . . . . . . 17		2.7. Uniform Resource Identifiers . . . . . . . . . . . . . . . 17
	2.7.1. http URI scheme . . . . . . . . . . . . . . . . . . . 18		2.7.1. http URI scheme . . . . . . . . . . . . . . . . . . . 18
	2.7.2. https URI scheme . . . . . . . . . . . . . . . . . . . 19		2.7.2. https URI scheme . . . . . . . . . . . . . . . . . . . 19
	2.7.3. http and https URI Normalization and Comparison . . . 20		2.7.3. http and https URI Normalization and Comparison . . . 20
	3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 20		3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 21
	3.1. Start Line . . . . . . . . . . . . . . . . . . . . . . . . 21		3.1. Start Line . . . . . . . . . . . . . . . . . . . . . . . . 21
	3.1.1. Request-Line . . . . . . . . . . . . . . . . . . . . . 22		3.1.1. Request-Line . . . . . . . . . . . . . . . . . . . . . 22
	3.1.2. Response Status-Line . . . . . . . . . . . . . . . . . 23		3.1.2. Response Status-Line . . . . . . . . . . . . . . . . . 23
	3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 23		3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 23
	3.2.1. Field Parsing . . . . . . . . . . . . . . . . . . . . 24		3.2.1. Field Parsing . . . . . . . . . . . . . . . . . . . . 25
	3.2.2. Field Length . . . . . . . . . . . . . . . . . . . . . 25		3.2.2. Field Length . . . . . . . . . . . . . . . . . . . . . 25
	3.2.3. Common Field ABNF Rules . . . . . . . . . . . . . . . 25		3.2.3. Common Field ABNF Rules . . . . . . . . . . . . . . . 26
	3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 27		3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 27
	3.4. Handling Incomplete Messages . . . . . . . . . . . . . . . 30		3.4. Handling Incomplete Messages . . . . . . . . . . . . . . . 30
	3.5. Message Parsing Robustness . . . . . . . . . . . . . . . . 30		3.5. Message Parsing Robustness . . . . . . . . . . . . . . . . 31
	4. Message Routing . . . . . . . . . . . . . . . . . . . . . . . 31		4. Message Routing . . . . . . . . . . . . . . . . . . . . . . . 31
	4.1. Types of Request Target . . . . . . . . . . . . . . . . . 31		4.1. Types of Request Target . . . . . . . . . . . . . . . . . 31
	4.2. The Resource Identified by a Request . . . . . . . . . . . 33		4.2. The Resource Identified by a Request . . . . . . . . . . . 33
	4.3. Effective Request URI . . . . . . . . . . . . . . . . . . 34		4.3. Effective Request URI . . . . . . . . . . . . . . . . . . 34
	5. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 35		5. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 35
	5.1. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 35		5.1. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 35
	5.1.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 36		5.1.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 36
	5.1.2. Compression Codings . . . . . . . . . . . . . . . . . 38		5.1.2. Compression Codings . . . . . . . . . . . . . . . . . 38
	5.1.3. Transfer Coding Registry . . . . . . . . . . . . . . . 39		5.1.3. Transfer Coding Registry . . . . . . . . . . . . . . . 39
	5.2. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 39		5.2. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 39
	skipping to change at page 4, line 47		skipping to change at page 4, line 47
	10.1. Personal Information . . . . . . . . . . . . . . . . . . . 63		10.1. Personal Information . . . . . . . . . . . . . . . . . . . 63
	10.2. Abuse of Server Log Information . . . . . . . . . . . . . 63		10.2. Abuse of Server Log Information . . . . . . . . . . . . . 63
	10.3. Attacks Based On File and Path Names . . . . . . . . . . . 63		10.3. Attacks Based On File and Path Names . . . . . . . . . . . 63
	10.4. DNS-related Attacks . . . . . . . . . . . . . . . . . . . 63		10.4. DNS-related Attacks . . . . . . . . . . . . . . . . . . . 63
	10.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 64		10.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 64
	10.6. Protocol Element Size Overflows . . . . . . . . . . . . . 64		10.6. Protocol Element Size Overflows . . . . . . . . . . . . . 64
	10.7. Denial of Service Attacks on Proxies . . . . . . . . . . . 65		10.7. Denial of Service Attacks on Proxies . . . . . . . . . . . 65
	11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 65		11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 65
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 66		12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 66
	12.1. Normative References . . . . . . . . . . . . . . . . . . . 66		12.1. Normative References . . . . . . . . . . . . . . . . . . . 66
	12.2. Informative References . . . . . . . . . . . . . . . . . . 68		12.2. Informative References . . . . . . . . . . . . . . . . . . 67
	Appendix A. HTTP Version History . . . . . . . . . . . . . . . . 70		Appendix A. HTTP Version History . . . . . . . . . . . . . . . . 69
	A.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 71		A.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 70
	A.1.1. Multi-homed Web Servers . . . . . . . . . . . . . . . 71		A.1.1. Multi-homed Web Servers . . . . . . . . . . . . . . . 70
	A.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 71		A.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 71
	A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 72		A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 71
	Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 73		Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 72
	Appendix C. Change Log (to be removed by RFC Editor before		Appendix C. Change Log (to be removed by RFC Editor before
	publication) . . . . . . . . . . . . . . . . . . . . 76		publication) . . . . . . . . . . . . . . . . . . . . 75
	C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 76		C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 75
	C.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 76		C.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 75
	C.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 78		C.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 77
	C.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 79		C.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 78
	C.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 79		C.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 78
	C.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 80		C.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 79
	C.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 80		C.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 79
	C.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 81		C.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 80
	C.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 82		C.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 81
	C.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 82		C.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 82
	C.11. Since draft-ietf-httpbis-p1-messaging-09 . . . . . . . . . 83		C.11. Since draft-ietf-httpbis-p1-messaging-09 . . . . . . . . . 82
	C.12. Since draft-ietf-httpbis-p1-messaging-10 . . . . . . . . . 83		C.12. Since draft-ietf-httpbis-p1-messaging-10 . . . . . . . . . 82
	C.13. Since draft-ietf-httpbis-p1-messaging-11 . . . . . . . . . 84		C.13. Since draft-ietf-httpbis-p1-messaging-11 . . . . . . . . . 83
	C.14. Since draft-ietf-httpbis-p1-messaging-12 . . . . . . . . . 84		C.14. Since draft-ietf-httpbis-p1-messaging-12 . . . . . . . . . 83
	C.15. Since draft-ietf-httpbis-p1-messaging-13 . . . . . . . . . 85		C.15. Since draft-ietf-httpbis-p1-messaging-13 . . . . . . . . . 84
	C.16. Since draft-ietf-httpbis-p1-messaging-14 . . . . . . . . . 85		C.16. Since draft-ietf-httpbis-p1-messaging-14 . . . . . . . . . 84
	C.17. Since draft-ietf-httpbis-p1-messaging-15 . . . . . . . . . 85		C.17. Since draft-ietf-httpbis-p1-messaging-15 . . . . . . . . . 85
	C.18. Since draft-ietf-httpbis-p1-messaging-16 . . . . . . . . . 86		C.18. Since draft-ietf-httpbis-p1-messaging-16 . . . . . . . . . 85
			C.19. Since draft-ietf-httpbis-p1-messaging-17 . . . . . . . . . 85
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
	1. Introduction		1. Introduction
	The Hypertext Transfer Protocol (HTTP) is an application-level		The Hypertext Transfer Protocol (HTTP) is an application-level
	request/response protocol that uses extensible semantics and MIME-		request/response protocol that uses extensible semantics and MIME-
	like message payloads for flexible interaction with network-based		like message payloads for flexible interaction with network-based
	hypertext information systems. HTTP relies upon the Uniform Resource		hypertext information systems. HTTP relies upon the Uniform Resource
	Identifier (URI) standard [RFC3986] to indicate the target resource		Identifier (URI) standard [RFC3986] to indicate the target resource
	and relationships between resources. Messages are passed in a format		and relationships between resources. Messages are passed in a format
	skipping to change at page 10, line 27		skipping to change at page 10, line 27
	these programs perform for a particular connection. The same program		these programs perform for a particular connection. The same program
	might act as a client on some connections and a server on others. We		might act as a client on some connections and a server on others. We
	use the term "user agent" to refer to the program that initiates a		use the term "user agent" to refer to the program that initiates a
	request, such as a WWW browser, editor, or spider (web-traversing		request, such as a WWW browser, editor, or spider (web-traversing
	robot), and the term "origin server" to refer to the program that can		robot), and the term "origin server" to refer to the program that can
	originate authoritative responses to a request. For general		originate authoritative responses to a request. For general
	requirements, we use the term "sender" to refer to whichever		requirements, we use the term "sender" to refer to whichever
	component sent a given message and the term "recipient" to refer to		component sent a given message and the term "recipient" to refer to
	any component that receives the message.		any component that receives the message.
			Note: The term 'user agent' covers both those situations where
			there is a user (human) interacting with the software agent (and
			for which user interface or interactive suggestions might be made,
			e.g., warning the user or given the user an option in the case of
			security or privacy options) and also those where the software
			agent may act autonomously.
	Most HTTP communication consists of a retrieval request (GET) for a		Most HTTP communication consists of a retrieval request (GET) for a
	representation of some resource identified by a URI. In the simplest		representation of some resource identified by a URI. In the simplest
	case, this might be accomplished via a single bidirectional		case, this might be accomplished via a single bidirectional
	connection (===) between the user agent (UA) and the origin server		connection (===) between the user agent (UA) and the origin server
	(O).		(O).
	request >		request >
	UA ======================================= O		UA ======================================= O
	< response		< response
	skipping to change at page 11, line 6		skipping to change at page 11, line 14
	A server responds to the client's request by sending an HTTP response		A server responds to the client's request by sending an HTTP response
	message, beginning with a status line that includes the protocol		message, beginning with a status line that includes the protocol
	version, a success or error code, and textual reason phrase		version, a success or error code, and textual reason phrase
	(Section 3.1.2), followed by MIME-like header fields containing		(Section 3.1.2), followed by MIME-like header fields containing
	server information, resource metadata, and payload metadata		server information, resource metadata, and payload metadata
	(Section 3.2), an empty line to indicate the end of the header		(Section 3.2), an empty line to indicate the end of the header
	section, and finally a message body containing the payload body (if		section, and finally a message body containing the payload body (if
	any, Section 3.3).		any, Section 3.3).
			Note that 1xx responses (Section 7.1 of [Part2]) are not final;
			therefore, a server can send zero or more 1xx responses, followed by
			exactly one final response (with any other status code).
	The following example illustrates a typical message exchange for a		The following example illustrates a typical message exchange for a
	GET request on the URI "http://www.example.com/hello.txt":		GET request on the URI "http://www.example.com/hello.txt":
	client request:		client request:
	GET /hello.txt HTTP/1.1		GET /hello.txt HTTP/1.1
	User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3		User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
	Host: www.example.com		Host: www.example.com
	Accept: */*		Accept: */*
	skipping to change at page 33, line 18		skipping to change at page 33, line 22
	Host: www.example.org:8001		Host: www.example.org:8001
	after connecting to port 8001 of host "www.example.org".		after connecting to port 8001 of host "www.example.org".
	The request-target is transmitted in the format specified in		The request-target is transmitted in the format specified in
	Section 2.7.1. If the request-target is percent-encoded ([RFC3986],		Section 2.7.1. If the request-target is percent-encoded ([RFC3986],
	Section 2.1), the origin server MUST decode the request-target in		Section 2.1), the origin server MUST decode the request-target in
	order to properly interpret the request. Servers SHOULD respond to		order to properly interpret the request. Servers SHOULD respond to
	invalid request-targets with an appropriate status code.		invalid request-targets with an appropriate status code.
	A non-transforming proxy MUST NOT rewrite the "path-absolute" part of		A non-transforming proxy MUST NOT rewrite the "path-absolute" and
	the received request-target when forwarding it to the next inbound		"query" parts of the received request-target when forwarding it to
	server, except as noted above to replace a null path-absolute with		the next inbound server, except as noted above to replace a null
	"/" or "*".		path-absolute with "/" or "*".
	Note: The "no rewrite" rule prevents the proxy from changing the		Note: The "no rewrite" rule prevents the proxy from changing the
	meaning of the request when the origin server is improperly using		meaning of the request when the origin server is improperly using
	a non-reserved URI character for a reserved purpose. Implementors		a non-reserved URI character for a reserved purpose. Implementors
	need to be aware that some pre-HTTP/1.1 proxies have been known to		need to be aware that some pre-HTTP/1.1 proxies have been known to
	rewrite the request-target.		rewrite the request-target.
	4.2. The Resource Identified by a Request		4.2. The Resource Identified by a Request
	The exact resource identified by an Internet request is determined by		The exact resource identified by an Internet request is determined by
	skipping to change at page 34, line 26		skipping to change at page 34, line 30
	HTTP requests often do not carry the absolute URI ([RFC3986], Section		HTTP requests often do not carry the absolute URI ([RFC3986], Section
	4.3) for the target resource; instead, the URI needs to be inferred		4.3) for the target resource; instead, the URI needs to be inferred
	from the request-target, Host header field, and connection context.		from the request-target, Host header field, and connection context.
	The result of this process is called the "effective request URI".		The result of this process is called the "effective request URI".
	The "target resource" is the resource identified by the effective		The "target resource" is the resource identified by the effective
	request URI.		request URI.
	If the request-target is an absolute-URI, then the effective request		If the request-target is an absolute-URI, then the effective request
	URI is the request-target.		URI is the request-target.
	If the request-target uses the path-absolute form or the asterisk		If the request-target uses the origin form or the asterisk form, and
	form, and the Host header field is present, then the effective		the Host header field is present, then the effective request URI is
	request URI is constructed by concatenating		constructed by concatenating
	o the scheme name: "http" if the request was received over an		o the scheme name: "http" if the request was received over an
	insecure TCP connection, or "https" when received over a SSL/		insecure TCP connection, or "https" when received over a SSL/
	TLS-secured TCP connection,		TLS-secured TCP connection,
	o the octet sequence "://",		o the octet sequence "://",
	o the authority component, as specified in the Host header field		o the authority component, as specified in the Host header field
	(Section 8.3), and		(Section 8.3), and
	o the request-target obtained from the Request-Line, unless the		o the request-target obtained from the Request-Line, unless the
	request-target is just the asterisk "*".		request-target is just the asterisk "*".
	If the request-target uses the path-absolute form or the asterisk		If the request-target uses the origin form or the asterisk form, and
	form, and the Host header field is not present, then the effective		the Host header field is not present, then the effective request URI
	request URI is undefined.		is undefined.
	Otherwise, when request-target uses the authority form, the effective		Otherwise, when request-target uses the authority form, the effective
	request URI is undefined.		request URI is undefined.
	Example 1: the effective request URI for the message		Example 1: the effective request URI for the message
	GET /pub/WWW/TheProject.html HTTP/1.1		GET /pub/WWW/TheProject.html HTTP/1.1
	Host: www.example.org:8080		Host: www.example.org:8080
	(received over an insecure TCP connection) is "http", plus "://",		(received over an insecure TCP connection) is "http", plus "://",
	skipping to change at page 65, line 37		skipping to change at page 65, line 37
	smart questions, drafting and reviewing text, and discussing open		smart questions, drafting and reviewing text, and discussing open
	issues:		issues:
	Adam Barth, Adam Roach, Addison Phillips, Adrian Chadd, Adrien de		Adam Barth, Adam Roach, Addison Phillips, Adrian Chadd, Adrien de
	Croy, Alan Ford, Alan Ruttenberg, Albert Lunde, Alex Rousskov, Alexey		Croy, Alan Ford, Alan Ruttenberg, Albert Lunde, Alex Rousskov, Alexey
	Melnikov, Alisha Smith, Amichai Rothman, Amit Klein, Amos Jeffries,		Melnikov, Alisha Smith, Amichai Rothman, Amit Klein, Amos Jeffries,
	Andreas Maier, Andreas Petersson, Anne van Kesteren, Anthony Bryan,		Andreas Maier, Andreas Petersson, Anne van Kesteren, Anthony Bryan,
	Asbjorn Ulsberg, Balachander Krishnamurthy, Barry Leiba, Ben Laurie,		Asbjorn Ulsberg, Balachander Krishnamurthy, Barry Leiba, Ben Laurie,
	Benjamin Niven-Jenkins, Bil Corry, Bill Burke, Bjoern Hoehrmann, Bob		Benjamin Niven-Jenkins, Bil Corry, Bill Burke, Bjoern Hoehrmann, Bob
	Scheifler, Boris Zbarsky, Brett Slatkin, Brian Kell, Brian McBarron,		Scheifler, Boris Zbarsky, Brett Slatkin, Brian Kell, Brian McBarron,
	Brian Pane, Brian Smith, Bryce Nesbitt, Carl Kugler, Charles Fry,		Brian Pane, Brian Smith, Bryce Nesbitt, Cameron Heavon-Jones, Carl
	Chris Newman, Cyrus Daboo, Dale Robert Anderson, Dan Winship, Daniel		Kugler, Charles Fry, Chris Newman, Cyrus Daboo, Dale Robert Anderson,
	Stenberg, Dave Cridland, Dave Crocker, Dave Kristol, David Booth,		Dan Winship, Daniel Stenberg, Dave Cridland, Dave Crocker, Dave
	David Singer, David W. Morris, Diwakar Shetty, Drummond Reed, Duane		Kristol, David Booth, David Singer, David W. Morris, Diwakar Shetty,
	Wessels, Edward Lee, Eliot Lear, Eran Hammer-Lahav, Eric D. Williams,		Dmitry Kurochkin, Drummond Reed, Duane Wessels, Edward Lee, Eliot
	Eric J. Bowman, Eric Lawrence, Erik Aronesty, Florian Weimer, Frank		Lear, Eran Hammer-Lahav, Eric D. Williams, Eric J. Bowman, Eric
	Ellermann, Fred Bohle, Geoffrey Sneddon, Gervase Markham, Greg		Lawrence, Erik Aronesty, Florian Weimer, Frank Ellermann, Fred Bohle,
	Wilkins, Harald Tveit Alvestrand, Harry Halpin, Helge Hess, Henrik		Geoffrey Sneddon, Gervase Markham, Greg Wilkins, Harald Tveit
	Nordstrom, Henry S. Thompson, Henry Story, Howard Melman, Hugo Haas,		Alvestrand, Harry Halpin, Helge Hess, Henrik Nordstrom, Henry S.
	Ian Hickson, Ingo Struck, J. Ross Nicoll, James H. Manger, James		Thompson, Henry Story, Herbert van de Sompel, Howard Melman, Hugo
	Lacey, James M. Snell, Jamie Lokier, Jan Algermissen, Jeff Hodges		Haas, Ian Hickson, Ingo Struck, J. Ross Nicoll, James H. Manger,
	(for coming up with the term 'effective Request-URI'), Jeff Walden,		James Lacey, James M. Snell, Jamie Lokier, Jan Algermissen, Jeff
	Jim Luther, Joe D. Williams, Joe Gregorio, Joe Orton, John C.		Hodges (for coming up with the term 'effective Request-URI'), Jeff
			Walden, Jim Luther, Joe D. Williams, Joe Gregorio, Joe Orton, John C.
	Klensin, John C. Mallery, John Cowan, John Kemp, John Panzer, John		Klensin, John C. Mallery, John Cowan, John Kemp, John Panzer, John
	Schneider, John Stracke, Jonas Sicking, Jonathan Moore, Jonathan		Schneider, John Stracke, Jonas Sicking, Jonathan Moore, Jonathan
	Rees, Jordi Ros, Joris Dobbelsteen, Josh Cohen, Julien Pierre,		Rees, Jordi Ros, Joris Dobbelsteen, Josh Cohen, Julien Pierre,
	Jungshik Shin, Justin Chapweske, Justin Erenkrantz, Justin James,		Jungshik Shin, Justin Chapweske, Justin Erenkrantz, Justin James,
	Kalvinder Singh, Karl Dubost, Keith Hoffman, Keith Moore, Koen		Kalvinder Singh, Karl Dubost, Keith Hoffman, Keith Moore, Koen
	Holtman, Konstantin Voronkov, Kris Zyp, Lisa Dusseault, Maciej		Holtman, Konstantin Voronkov, Kris Zyp, Lisa Dusseault, Maciej
	Stachowiak, Marc Schneider, Marc Slemko, Mark Baker, Mark Nottingham		Stachowiak, Marc Schneider, Marc Slemko, Mark Baker, Mark Nottingham
	(Working Group chair), Mark Pauley, Martin J. Duerst, Martin Thomson,		(Working Group chair), Mark Pauley, Martin J. Duerst, Martin Thomson,
	Matt Lynch, Matthew Cox, Max Clark, Michael Burrows, Michael		Matt Lynch, Matthew Cox, Max Clark, Michael Burrows, Michael
	Hausenblas, Mike Amundsen, Mike Kelly, Mike Schinkel, Miles Sabin,		Hausenblas, Mike Amundsen, Mike Kelly, Mike Schinkel, Miles Sabin,
	skipping to change at page 66, line 41		skipping to change at page 66, line 42
	12.1. Normative References		12.1. Normative References
	[ISO-8859-1] International Organization for Standardization,		[ISO-8859-1] International Organization for Standardization,
	"Information technology -- 8-bit single-byte coded		"Information technology -- 8-bit single-byte coded
	graphic character sets -- Part 1: Latin alphabet No.		graphic character sets -- Part 1: Latin alphabet No.
	1", ISO/IEC 8859-1:1998, 1998.		1", ISO/IEC 8859-1:1998, 1998.
	[Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
	Ed., and J. Reschke, Ed., "HTTP/1.1, part 2: Message		Ed., and J. Reschke, Ed., "HTTP/1.1, part 2: Message
	Semantics", draft-ietf-httpbis-p2-semantics-17 (work in		Semantics", draft-ietf-httpbis-p2-semantics-18 (work in
	progress), October 2011.		progress), January 2012.
	[Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
	Ed., and J. Reschke, Ed., "HTTP/1.1, part 3: Message		Ed., and J. Reschke, Ed., "HTTP/1.1, part 3: Message
	Payload and Content Negotiation",		Payload and Content Negotiation",
	draft-ietf-httpbis-p3-payload-17 (work in progress),		draft-ietf-httpbis-p3-payload-18 (work in progress),
	October 2011.		January 2012.
	[Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
	Ed., Nottingham, M., Ed., and J. Reschke, Ed.,		Ed., Nottingham, M., Ed., and J. Reschke, Ed.,
	"HTTP/1.1, part 6: Caching",		"HTTP/1.1, part 6: Caching",
	draft-ietf-httpbis-p6-cache-17 (work in progress),		draft-ietf-httpbis-p6-cache-18 (work in progress),
	October 2011.		January 2012.
	[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data		[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data
	Format Specification version 3.3", RFC 1950, May 1996.		Format Specification version 3.3", RFC 1950, May 1996.
	RFC 1950 is an Informational RFC, thus it might be less
	stable than this specification. On the other hand,
	this downward reference was present since the
	publication of RFC 2068 in 1997, therefore it is
	unlikely to cause problems in practice. See also
	[BCP97].
	[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format		[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format
	Specification version 1.3", RFC 1951, May 1996.		Specification version 1.3", RFC 1951, May 1996.
	RFC 1951 is an Informational RFC, thus it might be less
	stable than this specification. On the other hand,
	this downward reference was present since the
	publication of RFC 2068 in 1997, therefore it is
	unlikely to cause problems in practice. See also
	[BCP97].
	[RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and		[RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and
	G. Randers-Pehrson, "GZIP file format specification		G. Randers-Pehrson, "GZIP file format specification
	version 4.3", RFC 1952, May 1996.		version 4.3", RFC 1952, May 1996.
	RFC 1952 is an Informational RFC, thus it might be less
	stable than this specification. On the other hand,
	this downward reference was present since the
	publication of RFC 2068 in 1997, therefore it is
	unlikely to cause problems in practice. See also
	[BCP97].
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,		[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
	"Uniform Resource Identifier (URI): Generic Syntax",		"Uniform Resource Identifier (URI): Generic Syntax",
	STD 66, RFC 3986, January 2005.		STD 66, RFC 3986, January 2005.
	[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for		[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for
	Syntax Specifications: ABNF", STD 68, RFC 5234,		Syntax Specifications: ABNF", STD 68, RFC 5234,
	January 2008.		January 2008.
	[USASCII] American National Standards Institute, "Coded Character		[USASCII] American National Standards Institute, "Coded Character
	Set -- 7-bit American Standard Code for Information		Set -- 7-bit American Standard Code for Information
	Interchange", ANSI X3.4, 1986.		Interchange", ANSI X3.4, 1986.
	12.2. Informative References		12.2. Informative References
	[BCP97] Klensin, J. and S. Hartman, "Handling Normative
	References to Standards-Track Documents", BCP 97,
	RFC 4897, June 2007.
	[Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and		[Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and
	Politics", ACM Transactions on Internet Technology Vol.		Politics", ACM Transactions on Internet Technology Vol.
	1, #2, November 2001,		1, #2, November 2001,
	<http://arxiv.org/abs/cs.SE/0105018>.		<http://arxiv.org/abs/cs.SE/0105018>.
	[Nie1997] Frystyk, H., Gettys, J., Prud'hommeaux, E., Lie, H.,		[Nie1997] Frystyk, H., Gettys, J., Prud'hommeaux, E., Lie, H.,
	and C. Lilley, "Network Performance Effects of		and C. Lilley, "Network Performance Effects of
	HTTP/1.1, CSS1, and PNG", ACM Proceedings of the ACM		HTTP/1.1, CSS1, and PNG", ACM Proceedings of the ACM
	SIGCOMM '97 conference on Applications, technologies,		SIGCOMM '97 conference on Applications, technologies,
	architectures, and protocols for computer communication		architectures, and protocols for computer communication
	skipping to change at page 71, line 31		skipping to change at page 71, line 8
	to which that request was directed. The Host header field was		to which that request was directed. The Host header field was
	introduced during the development of HTTP/1.1 and, though it was		introduced during the development of HTTP/1.1 and, though it was
	quickly implemented by most HTTP/1.0 browsers, additional		quickly implemented by most HTTP/1.0 browsers, additional
	requirements were placed on all HTTP/1.1 requests in order to ensure		requirements were placed on all HTTP/1.1 requests in order to ensure
	complete adoption. At the time of this writing, most HTTP-based		complete adoption. At the time of this writing, most HTTP-based
	services are dependent upon the Host header field for targeting		services are dependent upon the Host header field for targeting
	requests.		requests.
	A.1.2. Keep-Alive Connections		A.1.2. Keep-Alive Connections
	For most implementations of HTTP/1.0, each connection is established		In HTTP/1.0, each connection is established by the client prior to
	by the client prior to the request and closed by the server after		the request and closed by the server after sending the response.
	sending the response. However, some implementations implement the		However, some implementations implement the explicitly negotiated
	Keep-Alive version of persistent connections described in Section		("Keep-Alive") version of persistent connections described in Section
	19.7.1 of [RFC2068].		19.7.1 of [RFC2068].
	Some clients and servers might wish to be compatible with some		Some clients and servers might wish to be compatible with these
	previous implementations of persistent connections in HTTP/1.0		previous approaches to persistent connections, by explicitly
	clients and servers. Persistent connections in HTTP/1.0 are		negotiating for them with a "Connection: keep-alive" request header
	explicitly negotiated as they are not the default behavior. HTTP/1.0		field. However, some experimental implementations of HTTP/1.0
	experimental implementations of persistent connections are faulty,		persistent connections are faulty; for example, if a HTTP/1.0 proxy
	and the new facilities in HTTP/1.1 are designed to rectify these		server doesn't understand Connection, it will erroneously forward
	problems. The problem was that some existing HTTP/1.0 clients might		that header to the next inbound server, which would result in a hung
	send Keep-Alive to a proxy server that doesn't understand Connection,		connection.
	which would then erroneously forward it to the next inbound server,
	which would establish the Keep-Alive connection and result in a hung
	HTTP/1.0 proxy waiting for the close on the response. The result is
	that HTTP/1.0 clients must be prevented from using Keep-Alive when
	talking to proxies.
	However, talking to proxies is the most important use of persistent		One attempted solution was the introduction of a Proxy-Connection
	connections, so that prohibition is clearly unacceptable. Therefore,		header, targeted specifically at proxies. In practice, this was also
	we need some other mechanism for indicating a persistent connection		unworkable, because proxies are often deployed in multiple layers,
	is desired, which is safe to use even when talking to an old proxy		bringing about the same problem discussed above.
	that ignores Connection. Persistent connections are the default for
	HTTP/1.1 messages; we introduce a new keyword (Connection: close) for		As a result, clients are encouraged not to send the Proxy-Connection
	declaring non-persistence. See Section 8.1.		header in any requests.
			Clients are also encouraged to consider the use of Connection: keep-
			alive in requests carefully; while they can enable persistent
			connections with HTTP/1.0 servers, clients using them need will need
			to monitor the connection for "hung" requests (which indicate that
			the client ought stop sending the header), and this mechanism ought
			not be used by clients at all when a proxy is being used.
	A.2. Changes from RFC 2616		A.2. Changes from RFC 2616
	Empty list elements in list productions have been deprecated.		Empty list elements in list productions have been deprecated.
	(Section 1.2.1)		(Section 1.2.1)
	Rules about implicit linear whitespace between certain grammar		Rules about implicit linear whitespace between certain grammar
	productions have been removed; now it's only allowed when		productions have been removed; now it's only allowed when
	specifically pointed out in the ABNF. (Section 1.2.2)		specifically pointed out in the ABNF. (Section 1.2.2)
	skipping to change at page 86, line 30		skipping to change at page 85, line 43
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/219>: "Revise		o <http://tools.ietf.org/wg/httpbis/trac/ticket/219>: "Revise
	Acknowledgements Sections"		Acknowledgements Sections"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/297>: "Retrying		o <http://tools.ietf.org/wg/httpbis/trac/ticket/297>: "Retrying
	Requests"		Requests"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/318>: "Closing the		o <http://tools.ietf.org/wg/httpbis/trac/ticket/318>: "Closing the
	connection on server error"		connection on server error"
			C.19. Since draft-ietf-httpbis-p1-messaging-17
			Closed issues:
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/166>: "Clarify 'User
			Agent'"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/300>: "Define non-
			final responses"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/323>: "intended
			maturity level vs normative references"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/324>: "Intermediary
			rewriting of queries"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/158>: "Proxy-
			Connection and Keep-Alive"
	Index		Index
	A		A
	absolute-URI form (of request-target) 31		absolute-URI form (of request-target) 32
	accelerator 13		accelerator 13
	application/http Media Type 61		application/http Media Type 61
	asterisk form (of request-target) 31		asterisk form (of request-target) 31
	authority form (of request-target) 32		authority form (of request-target) 32
	B		B
	browser 10		browser 10
	C		C
	cache 14		cache 14
	skipping to change at page 87, line 20		skipping to change at page 86, line 52
	D		D
	deflate (Coding Format) 38		deflate (Coding Format) 38
	downstream 13		downstream 13
	E		E
	effective request URI 34		effective request URI 34
	G		G
	gateway 13		gateway 13
	Grammar		Grammar
	absolute-URI 17		absolute-URI 18
	ALPHA 7		ALPHA 7
	attribute 35		attribute 35
	authority 17		authority 18
	BWS 9		BWS 9
	chunk 36		chunk 36
	chunk-data 36		chunk-data 36
	chunk-ext 36		chunk-ext 36
	chunk-ext-name 36		chunk-ext-name 36
	chunk-ext-val 36		chunk-ext-val 36
	chunk-size 36		chunk-size 36
	Chunked-Body 36		Chunked-Body 36
	comment 26		comment 26
	Connection 50		Connection 50
	skipping to change at page 88, line 6		skipping to change at page 87, line 38
	field-name 23		field-name 23
	field-value 23		field-value 23
	header-field 23		header-field 23
	HEXDIG 7		HEXDIG 7
	Host 52		Host 52
	HTAB 7		HTAB 7
	HTTP-message 21		HTTP-message 21
	HTTP-Prot-Name 15		HTTP-Prot-Name 15
	http-URI 18		http-URI 18
	HTTP-Version 15		HTTP-Version 15
	https-URI 19		https-URI 20
	last-chunk 36		last-chunk 36
	LF 7		LF 7
	message-body 27		message-body 27
	Method 22		Method 22
	obs-text 26		obs-text 26
	OCTET 7		OCTET 7
	OWS 9		OWS 9
	path-absolute 17		path-absolute 18
	port 17		port 18
	product 39		product 39
	product-version 39		product-version 39
	protocol-name 57		protocol-name 57
	protocol-version 57		protocol-version 57
	pseudonym 57		pseudonym 57
	qdtext 26		qdtext 26
	qdtext-nf 36		qdtext-nf 36
	query 17		query 18
	quoted-cpair 26		quoted-cpair 27
	quoted-pair 26		quoted-pair 26
	quoted-str-nf 36		quoted-str-nf 36
	quoted-string 26		quoted-string 26
	qvalue 40		qvalue 40
	Reason-Phrase 23		Reason-Phrase 23
	received-by 57		received-by 57
	received-protocol 57		received-protocol 57
	Request-Line 22		Request-Line 22
	request-target 22		request-target 22
	RWS 9		RWS 9
	skipping to change at page 89, line 5		skipping to change at page 88, line 37
	te-ext 53		te-ext 53
	te-params 53		te-params 53
	token 26		token 26
	Trailer 54		Trailer 54
	trailer-part 36		trailer-part 36
	transfer-coding 35		transfer-coding 35
	Transfer-Encoding 54		Transfer-Encoding 54
	transfer-extension 35		transfer-extension 35
	transfer-parameter 35		transfer-parameter 35
	Upgrade 55		Upgrade 55
	uri-host 17		uri-host 18
	URI-reference 17		URI-reference 18
	value 35		value 35
	VCHAR 7		VCHAR 7
	Via 57		Via 57
	word 26		word 26
	gzip (Coding Format) 39		gzip (Coding Format) 39
	H		H
	header field 20		header field 21
	Header Fields		Header Fields
	Connection 49		Connection 49
	Content-Length 51		Content-Length 51
	Host 51		Host 51
	TE 53		TE 53
	Trailer 54		Trailer 54
	Transfer-Encoding 54		Transfer-Encoding 54
	Upgrade 55		Upgrade 55
	Via 57		Via 57
	header section 20		header section 21
	headers 20		headers 21
	Host header field 51		Host header field 51
	http URI scheme 18		http URI scheme 18
	https URI scheme 19		https URI scheme 19
	I		I
	inbound 13		inbound 13
	interception proxy 14		interception proxy 14
	intermediary 12		intermediary 12
	M		M
End of changes. 41 change blocks.
	124 lines changed or deleted		133 lines changed or added
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/