draft-ietf-httpbis-p1-messaging-04.txt		draft-ietf-httpbis-p1-messaging-05.txt
	Network Working Group R. Fielding, Ed.		Network Working Group R. Fielding, Ed.
	Internet-Draft Day Software		Internet-Draft Day Software
	Obsoletes: 2616 (if approved) J. Gettys		Obsoletes: 2616 (if approved) J. Gettys
	Intended status: Standards Track One Laptop per Child		Intended status: Standards Track One Laptop per Child
	Expires: March 2, 2009 J. Mogul		Expires: May 20, 2009 J. Mogul
	HP		HP
	H. Frystyk		H. Frystyk
	Microsoft		Microsoft
	L. Masinter		L. Masinter
	Adobe Systems		Adobe Systems
	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
	August 29, 2008		November 16, 2008
	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-04		draft-ietf-httpbis-p1-messaging-05
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 49		skipping to change at page 1, line 49
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on March 2, 2009.		This Internet-Draft will expire on May 20, 2009.
	Abstract		Abstract
	The Hypertext Transfer Protocol (HTTP) is an application-level		The Hypertext Transfer Protocol (HTTP) is an application-level
	protocol for distributed, collaborative, hypermedia information		protocol for distributed, collaborative, hypermedia 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. Part 1 provides		"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides
	an overview of HTTP and its associated terminology, defines the		an overview of HTTP and its associated terminology, defines the
	"http" and "https" Uniform Resource Identifier (URI) schemes, defines		"http" and "https" Uniform Resource Identifier (URI) schemes, defines
	the generic message syntax and parsing requirements for HTTP message		the generic message syntax and parsing requirements for HTTP message
	frames, and describes general security concerns for implementations.		frames, and describes general security concerns for implementations.
	Editorial Note (To be removed by RFC Editor)		Editorial Note (To be removed by RFC Editor)
	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). The current issues list is		group mailing list (ietf-http-wg@w3.org). The current issues list is
	at <http://www.tools.ietf.org/wg/httpbis/trac/report/11> and related		at <http://tools.ietf.org/wg/httpbis/trac/report/11> and related
	documents (including fancy diffs) can be found at		documents (including fancy diffs) can be found at
	<http://www.tools.ietf.org/wg/httpbis/>.		<http://tools.ietf.org/wg/httpbis/>.
	The changes in this draft are summarized in Appendix D.4.		The changes in this draft are summarized in Appendix E.6.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
	1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 5		1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5
	1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6		1.2. Overall Operation . . . . . . . . . . . . . . . . . . . . 6
	1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6		2. Notational Conventions and Generic Grammar . . . . . . . . . . 8
	1.4. Overall Operation . . . . . . . . . . . . . . . . . . . . 9		2.1. ABNF Extension: #rule . . . . . . . . . . . . . . . . . . 8
	2. Notational Conventions and Generic Grammar . . . . . . . . . . 11		2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . . . 8
	2.1. Augmented BNF . . . . . . . . . . . . . . . . . . . . . . 11		2.3. ABNF Rules defined in other Parts of the Specification . . 10
	2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . . . 13		3. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 11
	2.3. ABNF Rules defined in other Parts of the Specification . . 16		3.1. HTTP Version . . . . . . . . . . . . . . . . . . . . . . . 11
	3. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 16		3.2. Uniform Resource Identifiers . . . . . . . . . . . . . . . 12
	3.1. HTTP Version . . . . . . . . . . . . . . . . . . . . . . . 16		3.2.1. http URI scheme . . . . . . . . . . . . . . . . . . . 13
	3.2. Uniform Resource Identifiers . . . . . . . . . . . . . . . 17		3.2.2. URI Comparison . . . . . . . . . . . . . . . . . . . . 13
	3.2.1. General Syntax . . . . . . . . . . . . . . . . . . . . 17		3.3. Date/Time Formats . . . . . . . . . . . . . . . . . . . . 14
	3.2.2. http URL . . . . . . . . . . . . . . . . . . . . . . . 18		3.3.1. Full Date . . . . . . . . . . . . . . . . . . . . . . 14
	3.2.3. URI Comparison . . . . . . . . . . . . . . . . . . . . 19		3.4. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 16
	3.3. Date/Time Formats . . . . . . . . . . . . . . . . . . . . 19		3.4.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 17
	3.3.1. Full Date . . . . . . . . . . . . . . . . . . . . . . 19		3.5. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 18
	3.4. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 21		4. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . . 19
	3.4.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 22		4.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 19
	3.5. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 24		4.2. Message Headers . . . . . . . . . . . . . . . . . . . . . 20
	4. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . . 24		4.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 21
	4.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 24		4.4. Message Length . . . . . . . . . . . . . . . . . . . . . . 22
	4.2. Message Headers . . . . . . . . . . . . . . . . . . . . . 25		4.5. General Header Fields . . . . . . . . . . . . . . . . . . 23
	4.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 26		5. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
	4.4. Message Length . . . . . . . . . . . . . . . . . . . . . . 27		5.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 24
	4.5. General Header Fields . . . . . . . . . . . . . . . . . . 28		5.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 24
	5. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 29		5.1.2. Request-URI . . . . . . . . . . . . . . . . . . . . . 24
	5.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 29		5.2. The Resource Identified by a Request . . . . . . . . . . . 26
	5.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 29		6. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
	5.1.2. Request-URI . . . . . . . . . . . . . . . . . . . . . 30		6.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 27
	5.2. The Resource Identified by a Request . . . . . . . . . . . 31		6.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 27
	6. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 32		7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 27
	6.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 32		7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 28
	6.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 32		7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 28
	7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 33		7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 28
	7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 33		7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 30
	7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 33		7.1.4. Practical Considerations . . . . . . . . . . . . . . . 30
	7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 34		7.2. Message Transmission Requirements . . . . . . . . . . . . 31
	7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 35		7.2.1. Persistent Connections and Flow Control . . . . . . . 31
	7.1.4. Practical Considerations . . . . . . . . . . . . . . . 35		7.2.2. Monitoring Connections for Error Status Messages . . . 31
	7.2. Message Transmission Requirements . . . . . . . . . . . . 36		7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 32
	7.2.1. Persistent Connections and Flow Control . . . . . . . 37
	7.2.2. Monitoring Connections for Error Status Messages . . . 37
	7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 37
	7.2.4. Client Behavior if Server Prematurely Closes		7.2.4. Client Behavior if Server Prematurely Closes
	Connection . . . . . . . . . . . . . . . . . . . . . . 39		Connection . . . . . . . . . . . . . . . . . . . . . . 34
	8. Header Field Definitions . . . . . . . . . . . . . . . . . . . 40		8. Header Field Definitions . . . . . . . . . . . . . . . . . . . 34
	8.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 40		8.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 35
	8.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 41		8.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 36
	8.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 42		8.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
	8.3.1. Clockless Origin Server Operation . . . . . . . . . . 43		8.3.1. Clockless Origin Server Operation . . . . . . . . . . 37
	8.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 43		8.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
	8.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44		8.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
	8.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 45		8.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 39
	8.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 45		8.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 40
	8.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 46		8.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 41
	8.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 47		8.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
	9.1. Message Header Registration . . . . . . . . . . . . . . . 48		9.1. Message Header Registration . . . . . . . . . . . . . . . 43
	9.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 49		9.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 44
	9.3. Internet Media Type Registrations . . . . . . . . . . . . 49		9.3. Internet Media Type Registrations . . . . . . . . . . . . 44
	9.3.1. Internet Media Type message/http . . . . . . . . . . . 49		9.3.1. Internet Media Type message/http . . . . . . . . . . . 44
	9.3.2. Internet Media Type application/http . . . . . . . . . 50		9.3.2. Internet Media Type application/http . . . . . . . . . 45
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 51		10. Security Considerations . . . . . . . . . . . . . . . . . . . 46
	10.1. Personal Information . . . . . . . . . . . . . . . . . . . 52		10.1. Personal Information . . . . . . . . . . . . . . . . . . . 47
	10.2. Abuse of Server Log Information . . . . . . . . . . . . . 52		10.2. Abuse of Server Log Information . . . . . . . . . . . . . 47
	10.3. Attacks Based On File and Path Names . . . . . . . . . . . 52		10.3. Attacks Based On File and Path Names . . . . . . . . . . . 47
	10.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 52		10.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 47
	10.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 53		10.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 48
	10.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 54		10.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 49
	11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 54		11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 49
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55		12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50
	12.1. Normative References . . . . . . . . . . . . . . . . . . . 55		12.1. Normative References . . . . . . . . . . . . . . . . . . . 50
	12.2. Informative References . . . . . . . . . . . . . . . . . . 56		12.2. Informative References . . . . . . . . . . . . . . . . . . 51
	Appendix A. Tolerant Applications . . . . . . . . . . . . . . . . 59		Appendix A. Tolerant Applications . . . . . . . . . . . . . . . . 53
	Appendix B. Conversion of Date Formats . . . . . . . . . . . . . 59		Appendix B. Conversion of Date Formats . . . . . . . . . . . . . 54
	Appendix C. Compatibility with Previous Versions . . . . . . . . 60		Appendix C. Compatibility with Previous Versions . . . . . . . . 54
	C.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 60		C.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 55
	C.1.1. Changes to Simplify Multi-homed Web Servers and		C.1.1. Changes to Simplify Multi-homed Web Servers and
	Conserve IP Addresses . . . . . . . . . . . . . . . . 60		Conserve IP Addresses . . . . . . . . . . . . . . . . 55
	C.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 61		C.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 56
	C.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 62		C.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 57
	C.4. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 62		C.4. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 57
	Appendix D. Change Log (to be removed by RFC Editor before		Appendix D. Terminology . . . . . . . . . . . . . . . . . . . . . 58
	publication) . . . . . . . . . . . . . . . . . . . . 63		Appendix E. Change Log (to be removed by RFC Editor before
	D.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 63		publication) . . . . . . . . . . . . . . . . . . . . 61
	D.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 63		E.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 61
	D.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 64		E.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 61
	D.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 65		E.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 62
	D.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 66		E.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 63
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66		E.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 64
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 70		E.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 64
	Intellectual Property and Copyright Statements . . . . . . . . . . 73		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 69
			Intellectual Property and Copyright Statements . . . . . . . . . . 72
	1. Introduction		1. Introduction
	The Hypertext Transfer Protocol (HTTP) is an application-level		The Hypertext Transfer Protocol (HTTP) is an application-level
	protocol for distributed, collaborative, hypermedia information		request/response protocol that uses extensible semantics and MIME-
	systems. HTTP has been in use by the World-Wide Web global		like message payloads for flexible interaction with network-based
	information initiative since 1990. The first version of HTTP,		hypermedia information systems. HTTP relies upon the Uniform
	commonly referred to as HTTP/0.9, was a simple protocol for raw data		Resource Identifier (URI) standard [RFC3986] to indicate resource
	transfer across the Internet with only a single method and no		targets for interaction and to identify other resources. Messages
	metadata. HTTP/1.0, as defined by [RFC1945], improved the protocol
	by allowing messages to be in the format of MIME-like messages,
	containing metadata about the data transferred and modifiers on the
	request/response semantics. However, HTTP/1.0 did not sufficiently
	take into consideration the effects of hierarchical proxies, caching,
	the need for persistent connections, or name-based virtual hosts. In
	addition, the proliferation of incompletely-implemented applications
	calling themselves "HTTP/1.0" necessitated a protocol version change
	in order for two communicating applications to determine each other's
	true capabilities.
	This document is Part 1 of the seven-part specification that defines
	the protocol referred to as "HTTP/1.1", obsoleting [RFC2616].
	HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent
	requirements that enable reliable implementations and adding only
	those new features that will either be safely ignored by an HTTP/1.0
	recipient or only sent when communicating with a party advertising
	compliance with HTTP/1.1. Part 1 defines those aspects of HTTP/1.1
	related to overall network operation, message framing, interaction
	with transport protocols, and URI schemes.
	This document is currently disorganized in order to minimize the
	changes between drafts and enable reviewers to see the smaller errata
	changes. The next draft will reorganize the sections to better
	reflect the content. In particular, the sections will be organized
	according to the typical process of deciding when to use HTTP (URI
	schemes), overall network operation, connection management, message
	framing, and generic message parsing. The current mess reflects how
	widely dispersed these topics and associated requirements had become
	in [RFC2616].
	1.1. Purpose
	Practical information systems require more functionality than simple
	retrieval, including search, front-end update, and annotation. HTTP
	allows an open-ended set of methods and headers that indicate the
	purpose of a request [RFC2324]. It builds on the discipline of
	reference provided by the Uniform Resource Identifier (URI)
	[RFC1630], as a location (URL) [RFC1738] or name (URN) [RFC1737], for
	indicating the resource to which a method is to be applied. Messages
	are passed in a format similar to that used by Internet mail		are passed in a format similar to that used by Internet mail
	[RFC2822] as defined by the Multipurpose Internet Mail Extensions		[RFC5322] and the Multipurpose Internet Mail Extensions (MIME)
	(MIME) [RFC2045].		[RFC2045] (see Appendix A of [Part3] for the differences between HTTP
			and MIME messages).
	HTTP is also used as a generic protocol for communication between		HTTP is also designed for use as a generic protocol for translating
	user agents and proxies/gateways to other Internet systems, including		communication to and from other Internet information systems, such as
	those supported by the SMTP [RFC2821], NNTP [RFC3977], FTP [RFC959],		USENET news services via NNTP [RFC3977], file services via FTP
	Gopher [RFC1436], and WAIS [WAIS] protocols. In this way, HTTP		[RFC959], Gopher [RFC1436], and WAIS [WAIS]. HTTP proxies and
	allows basic hypermedia access to resources available from diverse		gateways provide access to alternative information services by
	applications.		translating their diverse protocols into a hypermedia format that can
			be viewed and manipulated by clients in the same way as HTTP
			services.
	1.2. Requirements		This document is Part 1 of the seven-part specification of HTTP,
			defining the protocol referred to as "HTTP/1.1" and obsoleting
			[RFC2616]. Part 1 defines how clients determine when to use HTTP,
			the URI schemes specific to HTTP-based resources, overall network
			operation with transport protocol connection management, and HTTP
			message framing. Our goal is to define all of the mechanisms
			necessary for HTTP message handling that are independent of message
			semantics, thereby defining the complete set of requirements for an
			HTTP message relay or generic message parser.
			1.1. Requirements
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	An implementation is not compliant if it fails to satisfy one or more		An implementation is not compliant if it fails to satisfy one or more
	of the MUST or REQUIRED level requirements for the protocols it		of the MUST or REQUIRED level requirements for the protocols it
	implements. An implementation that satisfies all the MUST or		implements. An implementation that satisfies all the MUST or
	REQUIRED level and all the SHOULD level requirements for its		REQUIRED level and all the SHOULD level requirements for its
	protocols is said to be "unconditionally compliant"; one that		protocols is said to be "unconditionally compliant"; one that
	satisfies all the MUST level requirements but not all the SHOULD		satisfies all the MUST level requirements but not all the SHOULD
	level requirements for its protocols is said to be "conditionally		level requirements for its protocols is said to be "conditionally
	compliant."		compliant."
	1.3. Terminology		1.2. Overall Operation
	This specification uses a number of terms to refer to the roles
	played by participants in, and objects of, the HTTP communication.
	connection
	A transport layer virtual circuit established between two programs
	for the purpose of communication.
	message
	The basic unit of HTTP communication, consisting of a structured
	sequence of octets matching the syntax defined in Section 4 and
	transmitted via the connection.
	request
	An HTTP request message, as defined in Section 5.
	response
	An HTTP response message, as defined in Section 6.
	resource
	A network data object or service that can be identified by a URI,
	as defined in Section 3.2. Resources may be available in multiple
	representations (e.g. multiple languages, data formats, size, and
	resolutions) or vary in other ways.
	entity
	The information transferred as the payload of a request or
	response. An entity consists of metainformation in the form of
	entity-header fields and content in the form of an entity-body, as
	described in Section 4 of [Part3].
	representation
	An entity included with a response that is subject to content
	negotiation, as described in Section 5 of [Part3]. There may
	exist multiple representations associated with a particular
	response status.
	content negotiation
	The mechanism for selecting the appropriate representation when
	servicing a request, as described in Section 5 of [Part3]. The
	representation of entities in any response can be negotiated
	(including error responses).
	variant
	A resource may have one, or more than one, representation(s)
	associated with it at any given instant. Each of these
	representations is termed a `variant'. Use of the term `variant'
	does not necessarily imply that the resource is subject to content
	negotiation.
	client
	A program that establishes connections for the purpose of sending
	requests.
	user agent
	The client which initiates a request. These are often browsers,
	editors, spiders (web-traversing robots), or other end user tools.
	server
	An application program that accepts connections in order to
	service requests by sending back responses. Any given program may
	be capable of being both a client and a server; our use of these
	terms refers only to the role being performed by the program for a
	particular connection, rather than to the program's capabilities
	in general. Likewise, any server may act as an origin server,
	proxy, gateway, or tunnel, switching behavior based on the nature
	of each request.
	origin server
	The server on which a given resource resides or is to be created.
	proxy
	An intermediary program which acts as both a server and a client
	for the purpose of making requests on behalf of other clients.
	Requests are serviced internally or by passing them on, with
	possible translation, to other servers. A proxy MUST implement
	both the client and server requirements of this specification. A
	"transparent proxy" is a proxy that does not modify the request or
	response beyond what is required for proxy authentication and
	identification. A "non-transparent proxy" is a proxy that
	modifies the request or response in order to provide some added
	service to the user agent, such as group annotation services,
	media type transformation, protocol reduction, or anonymity
	filtering. Except where either transparent or non-transparent
	behavior is explicitly stated, the HTTP proxy requirements apply
	to both types of proxies.
	gateway
	A server which acts as an intermediary for some other server.
	Unlike a proxy, a gateway receives requests as if it were the
	origin server for the requested resource; the requesting client
	may not be aware that it is communicating with a gateway.
	tunnel
	An intermediary program which is acting as a blind relay between
	two connections. Once active, a tunnel is not considered a party
	to the HTTP communication, though the tunnel may have been
	initiated by an HTTP request. The tunnel ceases to exist when
	both ends of the relayed connections are closed.
	cache
	A program's local store of response messages and the subsystem
	that controls its message storage, retrieval, and deletion. A
	cache stores cacheable responses in order to reduce the response
	time and network bandwidth consumption on future, equivalent
	requests. Any client or server may include a cache, though a
	cache cannot be used by a server that is acting as a tunnel.
	cacheable
	A response is cacheable if a cache is allowed to store a copy of
	the response message for use in answering subsequent requests.
	The rules for determining the cacheability of HTTP responses are
	defined in Section 1 of [Part6]. Even if a resource is cacheable,
	there may be additional constraints on whether a cache can use the
	cached copy for a particular request.
	upstream/downstream
	Upstream and downstream describe the flow of a message: all
	messages flow from upstream to downstream.
	inbound/outbound
	Inbound and outbound refer to the request and response paths for
	messages: "inbound" means "traveling toward the origin server",
	and "outbound" means "traveling toward the user agent"
	1.4. Overall Operation
	HTTP is a request/response protocol. A client sends a request to the		HTTP is a request/response protocol. A client sends a request to the
	server in the form of a request method, URI, and protocol version,		server in the form of a request method, URI, and protocol version,
	followed by a MIME-like message containing request modifiers, client		followed by a MIME-like message containing request modifiers, client
	information, and possible body content over a connection with a		information, and possible body content over a connection with a
	server. The server responds with a status line, including the		server. The server responds with a status line, including the
	message's protocol version and a success or error code, followed by a		message's protocol version and a success or error code, followed by a
	MIME-like message containing server information, entity		MIME-like message containing server information, entity
	metainformation, and possible entity-body content. The relationship		metainformation, and possible entity-body content. The relationship
	between HTTP and MIME is described in Appendix A of [Part3].		between HTTP and MIME is described in Appendix A of [Part3].
	skipping to change at page 11, line 34		skipping to change at page 8, line 7
	response structures onto the transport data units of the protocol in		response structures onto the transport data units of the protocol in
	question is outside the scope of this specification.		question is outside the scope of this specification.
	In HTTP/1.0, most implementations used a new connection for each		In HTTP/1.0, most implementations used a new connection for each
	request/response exchange. In HTTP/1.1, a connection may be used for		request/response exchange. In HTTP/1.1, a connection may be used for
	one or more request/response exchanges, although connections may be		one or more request/response exchanges, although connections may be
	closed for a variety of reasons (see Section 7.1).		closed for a variety of reasons (see Section 7.1).
	2. Notational Conventions and Generic Grammar		2. Notational Conventions and Generic Grammar
	2.1. Augmented BNF		2.1. ABNF Extension: #rule
	All of the mechanisms specified in this document are described in
	both prose and an augmented Backus-Naur Form (BNF) similar to that
	used by [RFC822ABNF]. Implementors will need to be familiar with the
	notation in order to understand this specification. The augmented
	BNF includes the following constructs:
	name = definition
	The name of a rule is simply the name itself (without any
	enclosing "<" and ">") and is separated from its definition by the
	equal "=" character. White space is only significant in that
	indentation of continuation lines is used to indicate a rule
	definition that spans more than one line. Certain basic rules are
	in uppercase, such as SP, LWS, HTAB, CRLF, DIGIT, ALPHA, etc.
	Angle brackets are used within definitions whenever their presence
	will facilitate discerning the use of rule names.
	"literal"
	Quotation marks surround literal text. Unless stated otherwise,
	the text is case-insensitive.
	rule1 | rule2
	Elements separated by a bar ("|") are alternatives, e.g., "yes |
	no" will accept yes or no.
	(rule1 rule2)
	Elements enclosed in parentheses are treated as a single element.
	Thus, "(elem (foo | bar) elem)" allows the token sequences "elem
	foo elem" and "elem bar elem".
	*rule
	The character "*" preceding an element indicates repetition. The
	full form is "<n>*<m>element" indicating at least <n> and at most
	<m> occurrences of element. Default values are 0 and infinity so
	that "*(element)" allows any number, including zero; "1*element"
	requires at least one; and "1*2element" allows one or two.
	[rule]
	Square brackets enclose optional elements; "[foo bar]" is
	equivalent to "*1(foo bar)".
	N rule
	Specific repetition: "<n>(element)" is equivalent to
	"<n>*<n>(element)"; that is, exactly <n> occurrences of (element).
	Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three
	alphabetic characters.
	#rule		One extension to the ABNF rules of [RFC5234] is used to improve
			readability.
	A construct "#" is defined, similar to "*", for defining lists of		A construct "#" is defined, similar to "*", for defining lists of
	elements. The full form is "<n>#<m>element" indicating at least		elements. The full form is "<n>#<m>element" indicating at least <n>
	<n> and at most <m> elements, each separated by one or more commas		and at most <m> elements, each separated by one or more commas (",")
	(",") and OPTIONAL linear white space (LWS). This makes the usual		and OPTIONAL linear white space (OWS). This makes the usual form of
	form of lists very easy; a rule such as		lists very easy; a rule such as
			( *OWS element *( *OWS "," *OWS element ))
	( *LWS element *( *LWS "," *LWS element ))
	can be shown as		can be shown as
	1#element		1#element
	Wherever this construct is used, null elements are allowed, but do		Wherever this construct is used, null elements are allowed, but do
	not contribute to the count of elements present. That is,		not contribute to the count of elements present. That is,
	"(element), , (element) " is permitted, but counts as only two		"(element), , (element) " is permitted, but counts as only two
	elements. Therefore, where at least one element is required, at		elements. Therefore, where at least one element is required, at
	least one non-null element MUST be present. Default values are 0		least one non-null element MUST be present. Default values are 0 and
	and infinity so that "#element" allows any number, including zero;		infinity so that "#element" allows any number, including zero;
	"1#element" requires at least one; and "1#2element" allows one or		"1#element" requires at least one; and "1#2element" allows one or
	two.		two.
	; comment		[[abnf.list: At a later point of time, we may want to add an appendix
			containing the whole ABNF, with the list rules expanded to strict RFC
	A semi-colon, set off some distance to the right of rule text,		5234 notation.]]
	starts a comment that continues to the end of line. This is a
	simple way of including useful notes in parallel with the
	specifications.
	implied *LWS
	The grammar described by this specification is word-based. Except
	where noted otherwise, linear white space (LWS) can be included
	between any two adjacent words (token or quoted-string), and
	between adjacent words and separators, without changing the
	interpretation of a field. At least one delimiter (LWS and/or
	separators) MUST exist between any two tokens (for the definition
	of "token" below), since they would otherwise be interpreted as a
	single token.
	2.2. Basic Rules		2.2. Basic Rules
	The following rules are used throughout this specification to		This specification uses the Augmented Backus-Naur Form (ABNF)
	describe basic parsing constructs. The US-ASCII coded character set		notation of [RFC5234]. The following core rules are included by
	is defined by ANSI X3.4-1986 [USASCII].		reference, as defined in [RFC5234], Appendix B.1: ALPHA (letters),
			CHAR (any [USASCII] character, excluding NUL), CR (carriage return),
	OCTET = %x00-FF		CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double
	; any 8-bit sequence of data		quote), HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF
	CHAR = %x01-7F		(line feed), OCTET (any 8-bit sequence of data), SP (space) and WSP
	; any US-ASCII character, excluding NUL		(white space).
	ALPHA = %x41-5A | %x61-7A
	; A-Z | a-z
	DIGIT = %x30-39
	; any US-ASCII digit "0".."9"
	CTL = %x00-1F | %x7F
	; (octets 0 - 31) and DEL (127)
	CR = %x0D
	; US-ASCII CR, carriage return (13)
	LF = %x0A
	; US-ASCII LF, linefeed (10)
	SP = %x20
	; US-ASCII SP, space (32)
	HTAB = %x09
	; US-ASCII HT, horizontal-tab (9)
	DQUOTE = %x22
	; US-ASCII double-quote mark (34)
	HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all		HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all
	protocol elements except the entity-body (see Appendix A for tolerant		protocol elements except the entity-body (see Appendix A for tolerant
	applications). The end-of-line marker within an entity-body is		applications). The end-of-line marker within an entity-body is
	defined by its associated media type, as described in Section 3.3 of		defined by its associated media type, as described in Section 3.3 of
	[Part3].		[Part3].
	CRLF = CR LF		All linear white space (LWS) in header field-values has the same
			semantics as SP. A recipient MAY replace any such linear white space
			with a single SP before interpreting the field value or forwarding
			the message downstream.
	HTTP/1.1 header field values can be folded onto multiple lines if the		Historically, HTTP/1.1 header field values allow linear white space
	continuation line begins with a space or horizontal tab. All linear		folding across multiple lines. However, this specification
	white space, including folding, has the same semantics as SP. A		deprecates its use; senders MUST NOT produce messages that include
	recipient MAY replace any linear white space with a single SP before		LWS folding (i.e., use the obs-fold rule), except within the message/
	interpreting the field value or forwarding the message downstream.		http media type (Section 9.3.1). Receivers SHOULD still parse folded
			linear white space.
	LWS = [CRLF] 1*( SP | HTAB )		This specification uses three rules to denote the use of linear white
			space; BWS ("Bad" White Space), OWS (Optional White Space), and RWS
			(Required White Space).
			"Bad" white space is allowed by the BNF, but senders SHOULD NOT
			produce it in messages. Receivers MUST accept it in incoming
			messages.
			Required white space is used when at least one linear white space
			character is required to separate field tokens. In all such cases, a
			single SP character SHOULD be used.
			OWS = *( [ obs-fold ] WSP )
			; "optional" white space
			RWS = 1*( [ obs-fold ] WSP )
			; "required" white space
			BWS = OWS
			; "bad" white space
			obs-fold = CRLF
	The TEXT rule is only used for descriptive field contents and values		The TEXT rule is only used for descriptive field contents and values
	that are not intended to be interpreted by the message parser. Words		that are not intended to be interpreted by the message parser. Words
	of *TEXT MAY contain characters from character sets other than ISO-		of *TEXT MAY contain characters from character sets other than ISO-
	8859-1 [ISO-8859-1] only when encoded according to the rules of		8859-1 [ISO-8859-1] only when encoded according to the rules of
	[RFC2047].		[RFC2047].
	TEXT = %x20-7E | %x80-FF | LWS		TEXT = %x20-7E / %x80-FF / OWS
	; any OCTET except CTLs, but including LWS		; any OCTET except CTLs, but including OWS
	A CRLF is allowed in the definition of TEXT only as part of a header		A CRLF is allowed in the definition of TEXT only as part of a header
	field continuation. It is expected that the folding LWS will be		field continuation. It is expected that the folding LWS will be
	replaced with a single SP before interpretation of the TEXT value.		replaced with a single SP before interpretation of the TEXT value.
	Hexadecimal numeric characters are used in several protocol elements.
	HEXDIG = "A" | "B" | "C" | "D" | "E" | "F"
	| "a" | "b" | "c" | "d" | "e" | "f" | DIGIT
	Many HTTP/1.1 header field values consist of words separated by LWS		Many HTTP/1.1 header field values consist of words separated by LWS
	or special characters. These special characters MUST be in a quoted		or special characters. These special characters MUST be in a quoted
	string to be used within a parameter value (as defined in		string to be used within a parameter value (as defined in
	Section 3.4).		Section 3.4).
	separators = "(" | ")" | "<" | ">" | "@"		tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*"
	| "," | ";" | ":" | "\" | DQUOTE		/ "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
	| "/" | "[" | "]" | "?" | "="		/ DIGIT / ALPHA
	| "{" | "}" | SP | HTAB
	tchar = "!" | "#" | "$" | "%" | "&" | "'" | "*"
	| "+" | "-" | "." | "^" | "_" | "`" | "|" | "~"
	| DIGIT | ALPHA
	; any CHAR except CTLs or separators
	token = 1*tchar		token = 1*tchar
	Comments can be included in some HTTP header fields by surrounding		Comments can be included in some HTTP header fields by surrounding
	the comment text with parentheses. Comments are only allowed in		the comment text with parentheses. Comments are only allowed in
	fields containing "comment" as part of their field value definition.		fields containing "comment" as part of their field value definition.
	In all other fields, parentheses are considered part of the field		In all other fields, parentheses are considered part of the field
	value.		value.
	comment = "(" *( ctext | quoted-pair | comment ) ")"		comment = "(" *( ctext / quoted-pair / comment ) ")"
	ctext = <any TEXT excluding "(" and ")">		ctext = <any TEXT excluding "(" and ")">
	A string of text is parsed as a single word if it is quoted using		A string of text is parsed as a single word if it is quoted using
	double-quote marks.		double-quote marks.
	quoted-string = ( DQUOTE *(qdtext | quoted-pair ) DQUOTE )		quoted-string = DQUOTE *(qdtext / quoted-pair ) DQUOTE
	qdtext = <any TEXT excluding DQUOTE and "\">		qdtext = <any TEXT excluding DQUOTE and "\">
	The backslash character ("\") MAY be used as a single-character		The backslash character ("\") MAY be used as a single-character
	quoting mechanism only within quoted-string and comment constructs.		quoting mechanism only within quoted-string and comment constructs.
	quoted-text = %x01-09 |		quoted-text = %x01-09 /
	%x0B-0C |		%x0B-0C /
	%x0E-FF ; Characters excluding NUL, CR and LF		%x0E-FF ; Characters excluding NUL, CR and LF
	quoted-pair = "\" quoted-text		quoted-pair = "\" quoted-text
	2.3. ABNF Rules defined in other Parts of the Specification		2.3. ABNF Rules defined in other Parts of the Specification
	The ABNF rules below are defined in other parts:		The ABNF rules below are defined in other parts:
	request-header = <request-header, defined in [Part2], Section 4>		request-header = <request-header, defined in [Part2], Section 4>
	response-header = <response-header, defined in [Part2], Section 6>		response-header = <response-header, defined in [Part2], Section 6>
	skipping to change at page 17, line 36		skipping to change at page 12, line 17
	since the publication of [RFC2068], caching proxies MUST, gateways		since the publication of [RFC2068], caching proxies MUST, gateways
	MAY, and tunnels MUST NOT upgrade the request to the highest version		MAY, and tunnels MUST NOT upgrade the request to the highest version
	they support. The proxy/gateway's response to that request MUST be		they support. The proxy/gateway's response to that request MUST be
	in the same major version as the request.		in the same major version as the request.
	Note: Converting between versions of HTTP may involve modification		Note: Converting between versions of HTTP may involve modification
	of header fields required or forbidden by the versions involved.		of header fields required or forbidden by the versions involved.
	3.2. Uniform Resource Identifiers		3.2. Uniform Resource Identifiers
	URIs have been known by many names: WWW addresses, Universal Document		Uniform Resource Identifiers (URIs) [RFC3986] are used in HTTP to
	Identifiers, Universal Resource Identifiers [RFC1630], and finally		indicate the target of a request and to identify additional resources
	the combination of Uniform Resource Locators (URL) [RFC1738] and		related to that resource, the request, or the response. Each
	Names (URN) [RFC1737]. As far as HTTP is concerned, Uniform Resource		protocol element in HTTP that allows a URI reference will indicate in
	Identifiers are simply formatted strings which identify--via name,		its ABNF whether the element allows only a URI in absolute form, any
	location, or any other characteristic--a resource.		relative reference, or some limited subset of the URI-reference
			grammar. Unless otherwise indicated, relative URI references are to
			be parsed relative to the URI corresponding to the request target
			(the base URI).
	3.2.1. General Syntax		This specification adopts the definitions of "URI-reference",
			"absolute-URI", "fragment", "port", "host", "path-abempty", "path-
			absolute", "query", and "authority" from [RFC3986]:
	URIs in HTTP can be represented in absolute form or relative to some		absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3>
	known base URI [RFC1808], depending upon the context of their use.		authority = <authority, defined in [RFC3986], Section 3.2>
	The two forms are differentiated by the fact that absolute URIs		fragment = <fragment, defined in [RFC3986], Section 3.5>
	always begin with a scheme name followed by a colon. For definitive		path-abempty = <path-abempty, defined in [RFC3986], Section 3.3>
	information on URL syntax and semantics, see "Uniform Resource		path-absolute = <path-absolute, defined in [RFC3986], Section 3.3>
	Identifiers (URI): Generic Syntax and Semantics," [RFC2396] (which		port = <port, defined in [RFC3986], Section 3.2.3>
	replaces [RFC1738] and [RFC1808]). This specification adopts the		query = <query, defined in [RFC3986], Section 3.4>
	definitions of "URI-reference", "absoluteURI", "fragment",		uri-host = <host, defined in [RFC3986], Section 3.2.2>
	"relativeURI", "port", "host", "abs_path", "query", and "authority"
	from that specification:
	absoluteURI = <absoluteURI, defined in [RFC2396], Section 3>		relative-part = <relative-part, defined in [RFC3986], Section 4.2>
	authority = <authority, defined in [RFC2396], Section 3.2>		relativeURI = relative-part [ "?" query ]
	fragment = <fragment, defined in [RFC2396], Section 4.1>
	path-absolute = <abs_path, defined in [RFC2396], Section 3>
	port = <port, defined in [RFC2396], Section 3.2.2>
	query = <query, defined in [RFC2396], Section 3.4>
	relativeURI = <relativeURI, defined in [RFC2396], Section 5>
	uri-host = <host, defined in [RFC2396], Section 3.2.2>
	HTTP does not place any a priori limit on the length of a URI.		HTTP does not place an a priori limit on the length of a URI.
	Servers MUST be able to handle the URI of any resource they serve,		Servers MUST be able to handle the URI of any resource they serve,
	and SHOULD be able to handle URIs of unbounded length if they provide		and SHOULD be able to handle URIs of unbounded length if they provide
	GET-based forms that could generate such URIs. A server SHOULD		GET-based forms that could generate such URIs. A server SHOULD
	return 414 (Request-URI Too Long) status if a URI is longer than the		return 414 (Request-URI Too Long) status if a URI is longer than the
	server can handle (see Section 9.4.15 of [Part2]).		server can handle (see Section 9.4.15 of [Part2]).
	Note: Servers ought to be cautious about depending on URI lengths		Note: Servers ought to be cautious about depending on URI lengths
	above 255 bytes, because some older client or proxy		above 255 bytes, because some older client or proxy
	implementations might not properly support these lengths.		implementations might not properly support these lengths.
	3.2.2. http URL		3.2.1. http URI scheme
	The "http" scheme is used to locate network resources via the HTTP		The "http" scheme is used to locate network resources via the HTTP
	protocol. This section defines the scheme-specific syntax and		protocol. This section defines the syntax and semantics for
	semantics for http URLs.		identifiers using the http or https URI schemes.
	http-URL = "http:" "//" uri-host [ ":" port ]		http-URI = "http:" "//" authority path-abempty [ "?" query ]
	[ path-absolute [ "?" query ]]
	If the port is empty or not given, port 80 is assumed. The semantics		If the port is empty or not given, port 80 is assumed. The semantics
	are that the identified resource is located at the server listening		are that the identified resource is located at the server listening
	for TCP connections on that port of that host, and the Request-URI		for TCP connections on that port of that host, and the Request-URI
	for the resource is path-absolute (Section 5.1.2). The use of IP		for the resource is path-absolute (Section 5.1.2). The use of IP
	addresses in URLs SHOULD be avoided whenever possible (see		addresses in URLs SHOULD be avoided whenever possible (see
	[RFC1900]). If the path-absolute is not present in the URL, it MUST		[RFC1900]). If the path-absolute is not present in the URL, it MUST
	be given as "/" when used as a Request-URI for a resource		be given as "/" when used as a Request-URI for a resource
	(Section 5.1.2). If a proxy receives a host name which is not a		(Section 5.1.2). If a proxy receives a host name which is not a
	fully qualified domain name, it MAY add its domain to the host name		fully qualified domain name, it MAY add its domain to the host name
	it received. If a proxy receives a fully qualified domain name, the		it received. If a proxy receives a fully qualified domain name, the
	proxy MUST NOT change the host name.		proxy MUST NOT change the host name.
	Note: the "https" scheme is defined in [RFC2818].		Note: the "https" scheme is defined in [RFC2818].
	3.2.3. URI Comparison		3.2.2. URI Comparison
	When comparing two URIs to decide if they match or not, a client		When comparing two URIs to decide if they match or not, a client
	SHOULD use a case-sensitive octet-by-octet comparison of the entire		SHOULD use a case-sensitive octet-by-octet comparison of the entire
	URIs, with these exceptions:		URIs, with these exceptions:
	o A port that is empty or not given is equivalent to the default		o A port that is empty or not given is equivalent to the default
	port for that URI-reference;		port for that URI-reference;
	o Comparisons of host names MUST be case-insensitive;		o Comparisons of host names MUST be case-insensitive;
	o Comparisons of scheme names MUST be case-insensitive;		o Comparisons of scheme names MUST be case-insensitive;
	o An empty path-absolute is equivalent to an path-absolute of "/".		o An empty path-absolute is equivalent to an path-absolute of "/".
	Characters other than those in the "reserved" set (see [RFC2396],		Characters other than those in the "reserved" set (see [RFC3986],
	Section 2.2) are equivalent to their ""%" HEXDIG HEXDIG" encoding.		Section 2.2) are equivalent to their ""%" HEXDIG HEXDIG" encoding.
	For example, the following three URIs are equivalent:		For example, the following three URIs are equivalent:
	http://example.com:80/~smith/home.html		http://example.com:80/~smith/home.html
	http://EXAMPLE.com/%7Esmith/home.html		http://EXAMPLE.com/%7Esmith/home.html
	http://EXAMPLE.com:/%7esmith/home.html		http://EXAMPLE.com:/%7esmith/home.html
	3.3. Date/Time Formats		3.3. Date/Time Formats
	skipping to change at page 20, line 14		skipping to change at page 14, line 40
	All HTTP date/time stamps MUST be represented in Greenwich Mean Time		All HTTP date/time stamps MUST be represented in Greenwich Mean Time
	(GMT), without exception. For the purposes of HTTP, GMT is exactly		(GMT), without exception. For the purposes of HTTP, GMT is exactly
	equal to UTC (Coordinated Universal Time). This is indicated in the		equal to UTC (Coordinated Universal Time). This is indicated in the
	first two formats by the inclusion of "GMT" as the three-letter		first two formats by the inclusion of "GMT" as the three-letter
	abbreviation for time zone, and MUST be assumed when reading the		abbreviation for time zone, and MUST be assumed when reading the
	asctime format. HTTP-date is case sensitive and MUST NOT include		asctime format. HTTP-date is case sensitive and MUST NOT include
	additional LWS beyond that specifically included as SP in the		additional LWS beyond that specifically included as SP in the
	grammar.		grammar.
	HTTP-date = rfc1123-date | obsolete-date		HTTP-date = rfc1123-date / obsolete-date
	obsolete-date = rfc850-date | asctime-date		obsolete-date = rfc850-date / asctime-date
	rfc1123-date = wkday "," SP date1 SP time SP GMT		rfc1123-date = wkday "," SP date1 SP time SP GMT
	rfc850-date = weekday "," SP date2 SP time SP GMT		rfc850-date = weekday "," SP date2 SP time SP GMT
	asctime-date = wkday SP date3 SP time SP 4DIGIT		asctime-date = wkday SP date3 SP time SP 4DIGIT
	date1 = 2DIGIT SP month SP 4DIGIT		date1 = 2DIGIT SP month SP 4DIGIT
	; day month year (e.g., 02 Jun 1982)		; day month year (e.g., 02 Jun 1982)
	date2 = 2DIGIT "-" month "-" 2DIGIT		date2 = 2DIGIT "-" month "-" 2DIGIT
	; day-month-year (e.g., 02-Jun-82)		; day-month-year (e.g., 02-Jun-82)
	date3 = month SP ( 2DIGIT | ( SP 1DIGIT ))		date3 = month SP ( 2DIGIT / ( SP 1DIGIT ))
	; month day (e.g., Jun 2)		; month day (e.g., Jun 2)
	time = 2DIGIT ":" 2DIGIT ":" 2DIGIT		time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
	; 00:00:00 - 23:59:59		; 00:00:00 - 23:59:59
	wkday = s-Mon | s-Tue | s-Wed		wkday = s-Mon / s-Tue / s-Wed
	| s-Thu | s-Fri | s-Sat | s-Sun		/ s-Thu / s-Fri / s-Sat / s-Sun
	weekday = l-Mon | l-Tue | l-Wed		weekday = l-Mon / l-Tue / l-Wed
	| l-Thu | l-Fri | l-Sat | l-Sun		/ l-Thu / l-Fri / l-Sat / l-Sun
	month = s-Jan | s-Feb | s-Mar | s-Apr		month = s-Jan / s-Feb / s-Mar / s-Apr
	| s-May | s-Jun | s-Jul | s-Aug		/ s-May / s-Jun / s-Jul / s-Aug
	| s-Sep | s-Oct | s-Nov | s-Dec		/ s-Sep / s-Oct / s-Nov / s-Dec
	GMT = %x47.4D.54 ; "GMT", case-sensitive		GMT = %x47.4D.54 ; "GMT", case-sensitive
	s-Mon = %x4D.6F.6E ; "Mon", case-sensitive		s-Mon = %x4D.6F.6E ; "Mon", case-sensitive
	s-Tue = %x54.75.65 ; "Tue", case-sensitive		s-Tue = %x54.75.65 ; "Tue", case-sensitive
	s-Wed = %x57.65.64 ; "Wed", case-sensitive		s-Wed = %x57.65.64 ; "Wed", case-sensitive
	s-Thu = %x54.68.75 ; "Thu", case-sensitive		s-Thu = %x54.68.75 ; "Thu", case-sensitive
	s-Fri = %x46.72.69 ; "Fri", case-sensitive		s-Fri = %x46.72.69 ; "Fri", case-sensitive
	s-Sat = %x53.61.74 ; "Sat", case-sensitive		s-Sat = %x53.61.74 ; "Sat", case-sensitive
	s-Sun = %x53.75.6E ; "Sun", case-sensitive		s-Sun = %x53.75.6E ; "Sun", case-sensitive
	skipping to change at page 21, line 30		skipping to change at page 16, line 13
	etc.		etc.
	3.4. Transfer Codings		3.4. Transfer Codings
	Transfer-coding values are used to indicate an encoding		Transfer-coding values are used to indicate an encoding
	transformation that has been, can be, or may need to be applied to an		transformation that has been, can be, or may need to be applied to an
	entity-body in order to ensure "safe transport" through the network.		entity-body in order to ensure "safe transport" through the network.
	This differs from a content coding in that the transfer-coding is a		This differs from a content coding in that the transfer-coding is a
	property of the message, not of the original entity.		property of the message, not of the original entity.
	transfer-coding = "chunked" | transfer-extension		transfer-coding = "chunked" / transfer-extension
	transfer-extension = token *( ";" parameter )		transfer-extension = token *( OWS ";" OWS parameter )
	Parameters are in the form of attribute/value pairs.		Parameters are in the form of attribute/value pairs.
	parameter = attribute "=" value		parameter = attribute BWS "=" BWS value
	attribute = token		attribute = token
	value = token | quoted-string		value = token / quoted-string
	All transfer-coding values are case-insensitive. HTTP/1.1 uses		All transfer-coding values are case-insensitive. HTTP/1.1 uses
	transfer-coding values in the TE header field (Section 8.5) and in		transfer-coding values in the TE header field (Section 8.5) and in
	the Transfer-Encoding header field (Section 8.7).		the Transfer-Encoding header field (Section 8.7).
	Whenever a transfer-coding is applied to a message-body, the set of		Whenever a transfer-coding is applied to a message-body, the set of
	transfer-codings MUST include "chunked", unless the message indicates		transfer-codings MUST include "chunked", unless the message indicates
	it is terminated by closing the connection. When the "chunked"		it is terminated by closing the connection. When the "chunked"
	transfer-coding is used, it MUST be the last transfer-coding applied		transfer-coding is used, it MUST be the last transfer-coding applied
	to the message-body. The "chunked" transfer-coding MUST NOT be		to the message-body. The "chunked" transfer-coding MUST NOT be
	skipping to change at page 22, line 40		skipping to change at page 17, line 21
	followed by an OPTIONAL trailer containing entity-header fields.		followed by an OPTIONAL trailer containing entity-header fields.
	This allows dynamically produced content to be transferred along with		This allows dynamically produced content to be transferred along with
	the information necessary for the recipient to verify that it has		the information necessary for the recipient to verify that it has
	received the full message.		received the full message.
	Chunked-Body = *chunk		Chunked-Body = *chunk
	last-chunk		last-chunk
	trailer-part		trailer-part
	CRLF		CRLF
	chunk = chunk-size [ chunk-extension ] CRLF		chunk = chunk-size *WSP [ chunk-ext ] CRLF
	chunk-data CRLF		chunk-data CRLF
	chunk-size = 1*HEXDIG		chunk-size = 1*HEXDIG
	last-chunk = 1*("0") [ chunk-extension ] CRLF		last-chunk = 1*("0") *WSP [ chunk-ext ] CRLF
	chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] )		chunk-ext = *( ";" *WSP chunk-ext-name
			[ "=" chunk-ext-val ] *WSP )
	chunk-ext-name = token		chunk-ext-name = token
	chunk-ext-val = token | quoted-string		chunk-ext-val = token / quoted-string
	chunk-data = 1*OCTET ; a sequence of chunk-size octets		chunk-data = 1*OCTET ; a sequence of chunk-size octets
	trailer-part = *(entity-header CRLF)		trailer-part = *(entity-header CRLF)
	The chunk-size field is a string of hex digits indicating the size of		The chunk-size field is a string of hex digits indicating the size of
	the chunk-data in octets. The chunked encoding is ended by any chunk		the chunk-data in octets. The chunked encoding is ended by any chunk
	whose size is zero, followed by the trailer, which is terminated by		whose size is zero, followed by the trailer, which is terminated by
	an empty line.		an empty line.
	The trailer allows the sender to include additional HTTP header		The trailer allows the sender to include additional HTTP header
	fields at the end of the message. The Trailer header field can be		fields at the end of the message. The Trailer header field can be
	skipping to change at page 23, line 38		skipping to change at page 18, line 22
	This requirement prevents an interoperability failure when the		This requirement prevents an interoperability failure when the
	message is being received by an HTTP/1.1 (or later) proxy and		message is being received by an HTTP/1.1 (or later) proxy and
	forwarded to an HTTP/1.0 recipient. It avoids a situation where		forwarded to an HTTP/1.0 recipient. It avoids a situation where
	compliance with the protocol would have necessitated a possibly		compliance with the protocol would have necessitated a possibly
	infinite buffer on the proxy.		infinite buffer on the proxy.
	A process for decoding the "chunked" transfer-coding can be		A process for decoding the "chunked" transfer-coding can be
	represented in pseudo-code as:		represented in pseudo-code as:
	length := 0		length := 0
	read chunk-size, chunk-extension (if any) and CRLF		read chunk-size, chunk-ext (if any) and CRLF
	while (chunk-size > 0) {		while (chunk-size > 0) {
	read chunk-data and CRLF		read chunk-data and CRLF
	append chunk-data to entity-body		append chunk-data to entity-body
	length := length + chunk-size		length := length + chunk-size
	read chunk-size and CRLF		read chunk-size and CRLF
	}		}
	read entity-header		read entity-header
	while (entity-header not empty) {		while (entity-header not empty) {
	append entity-header to existing header fields		append entity-header to existing header fields
	read entity-header		read entity-header
	skipping to change at page 24, line 4		skipping to change at page 18, line 36
	length := length + chunk-size		length := length + chunk-size
	read chunk-size and CRLF		read chunk-size and CRLF
	}		}
	read entity-header		read entity-header
	while (entity-header not empty) {		while (entity-header not empty) {
	append entity-header to existing header fields		append entity-header to existing header fields
	read entity-header		read entity-header
	}		}
	Content-Length := length		Content-Length := length
	Remove "chunked" from Transfer-Encoding		Remove "chunked" from Transfer-Encoding
	All HTTP/1.1 applications MUST be able to receive and decode the		All HTTP/1.1 applications MUST be able to receive and decode the
	"chunked" transfer-coding, and MUST ignore chunk-extension extensions		"chunked" transfer-coding, and MUST ignore chunk-ext extensions they
	they do not understand.		do not understand.
	3.5. Product Tokens		3.5. Product Tokens
	Product tokens are used to allow communicating applications to		Product tokens are used to allow communicating applications to
	identify themselves by software name and version. Most fields using		identify themselves by software name and version. Most fields using
	product tokens also allow sub-products which form a significant part		product tokens also allow sub-products which form a significant part
	of the application to be listed, separated by white space. By		of the application to be listed, separated by white space. By
	convention, the products are listed in order of their significance		convention, the products are listed in order of their significance
	for identifying the application.		for identifying the application.
	skipping to change at page 24, line 39		skipping to change at page 19, line 23
	versions of the same product SHOULD only differ in the product-		versions of the same product SHOULD only differ in the product-
	version portion of the product value).		version portion of the product value).
	4. HTTP Message		4. HTTP Message
	4.1. Message Types		4.1. Message Types
	HTTP messages consist of requests from client to server and responses		HTTP messages consist of requests from client to server and responses
	from server to client.		from server to client.
	HTTP-message = Request | Response ; HTTP/1.1 messages		HTTP-message = Request / Response ; HTTP/1.1 messages
	Request (Section 5) and Response (Section 6) messages use the generic		Request (Section 5) and Response (Section 6) messages use the generic
	message format of [RFC2822] for transferring entities (the payload of		message format of [RFC5322] for transferring entities (the payload of
	the message). Both types of message consist of a start-line, zero or		the message). Both types of message consist of a start-line, zero or
	more header fields (also known as "headers"), an empty line (i.e., a		more header fields (also known as "headers"), an empty line (i.e., a
	line with nothing preceding the CRLF) indicating the end of the		line with nothing preceding the CRLF) indicating the end of the
	header fields, and possibly a message-body.		header fields, and possibly a message-body.
	generic-message = start-line		generic-message = start-line
	*(message-header CRLF)		*(message-header CRLF)
	CRLF		CRLF
	[ message-body ]		[ message-body ]
	start-line = Request-Line | Status-Line		start-line = Request-Line / Status-Line
	In the interest of robustness, servers SHOULD ignore any empty		In the interest of robustness, servers SHOULD ignore any empty
	line(s) received where a Request-Line is expected. In other words,		line(s) received where a Request-Line is expected. In other words,
	if the server is reading the protocol stream at the beginning of a		if the server is reading the protocol stream at the beginning of a
	message and receives a CRLF first, it should ignore the CRLF.		message and receives a CRLF first, it should ignore the CRLF.
	Certain buggy HTTP/1.0 client implementations generate extra CRLF's		Certain buggy HTTP/1.0 client implementations generate extra CRLF's
	after a POST request. To restate what is explicitly forbidden by the		after a POST request. To restate what is explicitly forbidden by the
	BNF, an HTTP/1.1 client MUST NOT preface or follow a request with an		BNF, an HTTP/1.1 client MUST NOT preface or follow a request with an
	extra CRLF.		extra CRLF.
	4.2. Message Headers		4.2. Message Headers
	HTTP header fields, which include general-header (Section 4.5),		HTTP header fields, which include general-header (Section 4.5),
	request-header (Section 4 of [Part2]), response-header (Section 6 of		request-header (Section 4 of [Part2]), response-header (Section 6 of
	[Part2]), and entity-header (Section 4.1 of [Part3]) fields, follow		[Part2]), and entity-header (Section 4.1 of [Part3]) fields, follow
	the same generic format as that given in Section 2.1 of [RFC2822].		the same generic format as that given in Section 2.1 of [RFC5322].
	Each header field consists of a name followed by a colon (":") and		Each header field consists of a name followed by a colon (":") and
	the field value. Field names are case-insensitive. The field value		the field value. Field names are case-insensitive. The field value
	MAY be preceded by any amount of LWS, though a single SP is		MAY be preceded by any amount of LWS, though a single SP is
	preferred. Header fields can be extended over multiple lines by		preferred. Header fields can be extended over multiple lines by
	preceding each extra line with at least one SP or HTAB. Applications		preceding each extra line with at least one SP or HTAB. Applications
	ought to follow "common form", where one is known or indicated, when		ought to follow "common form", where one is known or indicated, when
	generating HTTP constructs, since there might exist some		generating HTTP constructs, since there might exist some
	implementations that fail to accept anything beyond the common forms.		implementations that fail to accept anything beyond the common forms.
	message-header = field-name ":" [ field-value ]		message-header = field-name ":" [ field-value ]
	field-name = token		field-name = token
	field-value = *( field-content | LWS )		field-value = *( field-content / OWS )
	field-content = <field content>		field-content = <field content>
	; the OCTETs making up the field-value
	; and consisting of either *TEXT or combinations		[[anchor1: whitespace between field-name and colon is an error and
	; of token, separators, and quoted-string		MUST NOT be accepted]]
	The field-content does not include any leading or trailing LWS:		The field-content does not include any leading or trailing LWS:
	linear white space occurring before the first non-whitespace		linear white space occurring before the first non-whitespace
	character of the field-value or after the last non-whitespace		character of the field-value or after the last non-whitespace
	character of the field-value. Such leading or trailing LWS MAY be		character of the field-value. Such leading or trailing LWS MAY be
	removed without changing the semantics of the field value. Any LWS		removed without changing the semantics of the field value. Any LWS
	that occurs between field-content MAY be replaced with a single SP		that occurs between field-content MAY be replaced with a single SP
	before interpreting the field value or forwarding the message		before interpreting the field value or forwarding the message
	downstream.		downstream.
	skipping to change at page 26, line 37		skipping to change at page 21, line 21
	4.3. Message Body		4.3. Message Body
	The message-body (if any) of an HTTP message is used to carry the		The message-body (if any) of an HTTP message is used to carry the
	entity-body associated with the request or response. The message-		entity-body associated with the request or response. The message-
	body differs from the entity-body only when a transfer-coding has		body differs from the entity-body only when a transfer-coding has
	been applied, as indicated by the Transfer-Encoding header field		been applied, as indicated by the Transfer-Encoding header field
	(Section 8.7).		(Section 8.7).
	message-body = entity-body		message-body = entity-body
	| <entity-body encoded as per Transfer-Encoding>		/ <entity-body encoded as per Transfer-Encoding>
	Transfer-Encoding MUST be used to indicate any transfer-codings		Transfer-Encoding MUST be used to indicate any transfer-codings
	applied by an application to ensure safe and proper transfer of the		applied by an application to ensure safe and proper transfer of the
	message. Transfer-Encoding is a property of the message, not of the		message. Transfer-Encoding is a property of the message, not of the
	entity, and thus MAY be added or removed by any application along the		entity, and thus MAY be added or removed by any application along the
	request/response chain. (However, Section 3.4 places restrictions on		request/response chain. (However, Section 3.4 places restrictions on
	when certain transfer-codings may be used.)		when certain transfer-codings may be used.)
	The rules for when a message-body is allowed in a message differ for		The rules for when a message-body is allowed in a message differ for
	requests and responses.		requests and responses.
	skipping to change at page 29, line 6		skipping to change at page 23, line 34
	invalid length is received and detected.		invalid length is received and detected.
	4.5. General Header Fields		4.5. General Header Fields
	There are a few header fields which have general applicability for		There are a few header fields which have general applicability for
	both request and response messages, but which do not apply to the		both request and response messages, but which do not apply to the
	entity being transferred. These header fields apply only to the		entity being transferred. These header fields apply only to the
	message being transmitted.		message being transmitted.
	general-header = Cache-Control ; [Part6], Section 16.2		general-header = Cache-Control ; [Part6], Section 16.2
	| Connection ; Section 8.1		/ Connection ; Section 8.1
	| Date ; Section 8.3		/ Date ; Section 8.3
	| Pragma ; [Part6], Section 16.4		/ Pragma ; [Part6], Section 16.4
	| Trailer ; Section 8.6		/ Trailer ; Section 8.6
	| Transfer-Encoding ; Section 8.7		/ Transfer-Encoding ; Section 8.7
	| Upgrade ; Section 8.8		/ Upgrade ; Section 8.8
	| Via ; Section 8.9		/ Via ; Section 8.9
	| Warning ; [Part6], Section 16.6		/ Warning ; [Part6], Section 16.6
	General-header field names can be extended reliably only in		General-header field names can be extended reliably only in
	combination with a change in the protocol version. However, new or		combination with a change in the protocol version. However, new or
	experimental header fields may be given the semantics of general		experimental header fields may be given the semantics of general
	header fields if all parties in the communication recognize them to		header fields if all parties in the communication recognize them to
	be general-header fields. Unrecognized header fields are treated as		be general-header fields. Unrecognized header fields are treated as
	entity-header fields.		entity-header fields.
	5. Request		5. Request
	A request message from a client to a server includes, within the		A request message from a client to a server includes, within the
	first line of that message, the method to be applied to the resource,		first line of that message, the method to be applied to the resource,
	the identifier of the resource, and the protocol version in use.		the identifier of the resource, and the protocol version in use.
	Request = Request-Line ; Section 5.1		Request = Request-Line ; Section 5.1
	*(( general-header ; Section 4.5		*(( general-header ; Section 4.5
	| request-header ; [Part2], Section 4		/ request-header ; [Part2], Section 4
	| entity-header ) CRLF) ; [Part3], Section 4.1		/ entity-header ) CRLF) ; [Part3], Section 4.1
	CRLF		CRLF
	[ message-body ] ; Section 4.3		[ message-body ] ; Section 4.3
	5.1. Request-Line		5.1. Request-Line
	The Request-Line begins with a method token, followed by the Request-		The Request-Line begins with a method token, followed by the Request-
	URI and the protocol version, and ending with CRLF. The elements are		URI and the protocol version, and ending with CRLF. The elements are
	separated by SP characters. No CR or LF is allowed except in the		separated by SP characters. No CR or LF is allowed except in the
	final CRLF sequence.		final CRLF sequence.
	skipping to change at page 30, line 11		skipping to change at page 24, line 40
	identified by the Request-URI. The method is case-sensitive.		identified by the Request-URI. The method is case-sensitive.
	Method = token		Method = token
	5.1.2. Request-URI		5.1.2. Request-URI
	The Request-URI is a Uniform Resource Identifier (Section 3.2) and		The Request-URI is a Uniform Resource Identifier (Section 3.2) and
	identifies the resource upon which to apply the request.		identifies the resource upon which to apply the request.
	Request-URI = "*"		Request-URI = "*"
	| absoluteURI		/ absolute-URI
	| ( path-absolute [ "?" query ] )		/ ( path-absolute [ "?" query ] )
	| authority		/ authority
	The four options for Request-URI are dependent on the nature of the		The four options for Request-URI are dependent on the nature of the
	request. The asterisk "*" means that the request does not apply to a		request. The asterisk "*" means that the request does not apply to a
	particular resource, but to the server itself, and is only allowed		particular resource, but to the server itself, and is only allowed
	when the method used does not necessarily apply to a resource. One		when the method used does not necessarily apply to a resource. One
	example would be		example would be
	OPTIONS * HTTP/1.1		OPTIONS * HTTP/1.1
	The absoluteURI form is REQUIRED when the request is being made to a		The absolute-URI form is REQUIRED when the request is being made to a
	proxy. The proxy is requested to forward the request or service it		proxy. The proxy is requested to forward the request or service it
	from a valid cache, and return the response. Note that the proxy MAY		from a valid cache, and return the response. Note that the proxy MAY
	forward the request on to another proxy or directly to the server		forward the request on to another proxy or directly to the server
	specified by the absoluteURI. In order to avoid request loops, a		specified by the absolute-URI. In order to avoid request loops, a
	proxy MUST be able to recognize all of its server names, including		proxy MUST be able to recognize all of its server names, including
	any aliases, local variations, and the numeric IP address. An		any aliases, local variations, and the numeric IP address. An
	example Request-Line would be:		example Request-Line would be:
	GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1		GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
	To allow for transition to absoluteURIs in all requests in future		To allow for transition to absolute-URIs in all requests in future
	versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI		versions of HTTP, all HTTP/1.1 servers MUST accept the absolute-URI
	form in requests, even though HTTP/1.1 clients will only generate		form in requests, even though HTTP/1.1 clients will only generate
	them in requests to proxies.		them in requests to proxies.
	The authority form is only used by the CONNECT method (Section 8.9 of		The authority form is only used by the CONNECT method (Section 8.9 of
	[Part2]).		[Part2]).
	The most common form of Request-URI is that used to identify a		The most common form of Request-URI is that used to identify a
	resource on an origin server or gateway. In this case the absolute		resource on an origin server or gateway. In this case the absolute
	path of the URI MUST be transmitted (see Section 3.2.1, path-		path of the URI MUST be transmitted (see Section 3.2.1, path-
	absolute) as the Request-URI, and the network location of the URI		absolute) as the Request-URI, and the network location of the URI
	skipping to change at page 31, line 4		skipping to change at page 25, line 33
	resource on an origin server or gateway. In this case the absolute		resource on an origin server or gateway. In this case the absolute
	path of the URI MUST be transmitted (see Section 3.2.1, path-		path of the URI MUST be transmitted (see Section 3.2.1, path-
	absolute) as the Request-URI, and the network location of the URI		absolute) as the Request-URI, and the network location of the URI
	(authority) MUST be transmitted in a Host header field. For example,		(authority) MUST be transmitted in a Host header field. For example,
	a client wishing to retrieve the resource above directly from the		a client wishing to retrieve the resource above directly from the
	origin server would create a TCP connection to port 80 of the host		origin server would create a TCP connection to port 80 of the host
	"www.example.org" and send the lines:		"www.example.org" and send the lines:
	GET /pub/WWW/TheProject.html HTTP/1.1		GET /pub/WWW/TheProject.html HTTP/1.1
	Host: www.example.org		Host: www.example.org
	followed by the remainder of the Request. Note that the absolute		followed by the remainder of the Request. Note that the absolute
	path cannot be empty; if none is present in the original URI, it MUST		path cannot be empty; if none is present in the original URI, it MUST
	be given as "/" (the server root).		be given as "/" (the server root).
	The Request-URI is transmitted in the format specified in		The Request-URI is transmitted in the format specified in
	Section 3.2.1. If the Request-URI is encoded using the "% HEXDIG		Section 3.2.1. If the Request-URI is encoded using the "% HEXDIG
	HEXDIG" encoding ([RFC2396], Section 2.4.1), the origin server MUST		HEXDIG" encoding ([RFC3986], Section 2.4), the origin server MUST
	decode the Request-URI in order to properly interpret the request.		decode the Request-URI in order to properly interpret the request.
	Servers SHOULD respond to invalid Request-URIs with an appropriate		Servers SHOULD respond to invalid Request-URIs with an appropriate
	status code.		status code.
	A transparent proxy MUST NOT rewrite the "path-absolute" part of the		A transparent proxy MUST NOT rewrite the "path-absolute" part of the
	received Request-URI when forwarding it to the next inbound server,		received Request-URI when forwarding it to the next inbound server,
	except as noted above to replace a null path-absolute with "/".		except as noted above to replace a null path-absolute with "/".
	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
	skipping to change at page 31, line 40		skipping to change at page 26, line 22
	An origin server that does not allow resources to differ by the		An origin server that does not allow resources to differ by the
	requested host MAY ignore the Host header field value when		requested host MAY ignore the Host header field value when
	determining the resource identified by an HTTP/1.1 request. (But see		determining the resource identified by an HTTP/1.1 request. (But see
	Appendix C.1.1 for other requirements on Host support in HTTP/1.1.)		Appendix C.1.1 for other requirements on Host support in HTTP/1.1.)
	An origin server that does differentiate resources based on the host		An origin server that does differentiate resources based on the host
	requested (sometimes referred to as virtual hosts or vanity host		requested (sometimes referred to as virtual hosts or vanity host
	names) MUST use the following rules for determining the requested		names) MUST use the following rules for determining the requested
	resource on an HTTP/1.1 request:		resource on an HTTP/1.1 request:
	1. If Request-URI is an absoluteURI, the host is part of the		1. If Request-URI is an absolute-URI, the host is part of the
	Request-URI. Any Host header field value in the request MUST be		Request-URI. Any Host header field value in the request MUST be
	ignored.		ignored.
	2. If the Request-URI is not an absoluteURI, and the request		2. If the Request-URI is not an absolute-URI, and the request
	includes a Host header field, the host is determined by the Host		includes a Host header field, the host is determined by the Host
	header field value.		header field value.
	3. If the host as determined by rule 1 or 2 is not a valid host on		3. If the host as determined by rule 1 or 2 is not a valid host on
	the server, the response MUST be a 400 (Bad Request) error		the server, the response MUST be a 400 (Bad Request) error
	message.		message.
	Recipients of an HTTP/1.0 request that lacks a Host header field MAY		Recipients of an HTTP/1.0 request that lacks a Host header field MAY
	attempt to use heuristics (e.g., examination of the URI path for		attempt to use heuristics (e.g., examination of the URI path for
	something unique to a particular host) in order to determine what		something unique to a particular host) in order to determine what
	exact resource is being requested.		exact resource is being requested.
	6. Response		6. Response
	After receiving and interpreting a request message, a server responds		After receiving and interpreting a request message, a server responds
	with an HTTP response message.		with an HTTP response message.
	Response = Status-Line ; Section 6.1		Response = Status-Line ; Section 6.1
	*(( general-header ; Section 4.5		*(( general-header ; Section 4.5
	| response-header ; [Part2], Section 6		/ response-header ; [Part2], Section 6
	| entity-header ) CRLF) ; [Part3], Section 4.1		/ entity-header ) CRLF) ; [Part3], Section 4.1
	CRLF		CRLF
	[ message-body ] ; Section 4.3		[ message-body ] ; Section 4.3
	6.1. Status-Line		6.1. Status-Line
	The first line of a Response message is the Status-Line, consisting		The first line of a Response message is the Status-Line, consisting
	of the protocol version followed by a numeric status code and its		of the protocol version followed by a numeric status code and its
	associated textual phrase, with each element separated by SP		associated textual phrase, with each element separated by SP
	characters. No CR or LF is allowed except in the final CRLF		characters. No CR or LF is allowed except in the final CRLF
	sequence.		sequence.
	skipping to change at page 40, line 25		skipping to change at page 35, line 9
	This section defines the syntax and semantics of HTTP/1.1 header		This section defines the syntax and semantics of HTTP/1.1 header
	fields related to message framing and transport protocols.		fields related to message framing and transport protocols.
	For entity-header fields, both sender and recipient refer to either		For entity-header fields, both sender and recipient refer to either
	the client or the server, depending on who sends and who receives the		the client or the server, depending on who sends and who receives the
	entity.		entity.
	8.1. Connection		8.1. Connection
	The Connection general-header field allows the sender to specify		The general-header field "Connection" allows the sender to specify
	options that are desired for that particular connection and MUST NOT		options that are desired for that particular connection and MUST NOT
	be communicated by proxies over further connections.		be communicated by proxies over further connections.
	The Connection header has the following grammar:		The Connection header's value has the following grammar:
	Connection = "Connection" ":" 1#(connection-token)		Connection = "Connection" ":" OWS Connection-v
			Connection-v = 1#connection-token
	connection-token = token		connection-token = token
	HTTP/1.1 proxies MUST parse the Connection header field before a		HTTP/1.1 proxies MUST parse the Connection header field before a
	message is forwarded and, for each connection-token in this field,		message is forwarded and, for each connection-token in this field,
	remove any header field(s) from the message with the same name as the		remove any header field(s) from the message with the same name as the
	connection-token. Connection options are signaled by the presence of		connection-token. Connection options are signaled by the presence of
	a connection-token in the Connection header field, not by any		a connection-token in the Connection header field, not by any
	corresponding additional header field(s), since the additional header		corresponding additional header field(s), since the additional header
	field may not be sent if there are no parameters associated with that		field may not be sent if there are no parameters associated with that
	connection option.		connection option.
	skipping to change at page 41, line 24		skipping to change at page 36, line 9
	A system receiving an HTTP/1.0 (or lower-version) message that		A system receiving an HTTP/1.0 (or lower-version) message that
	includes a Connection header MUST, for each connection-token in this		includes a Connection header MUST, for each connection-token in this
	field, remove and ignore any header field(s) from the message with		field, remove and ignore any header field(s) from the message with
	the same name as the connection-token. This protects against		the same name as the connection-token. This protects against
	mistaken forwarding of such header fields by pre-HTTP/1.1 proxies.		mistaken forwarding of such header fields by pre-HTTP/1.1 proxies.
	See Appendix C.2.		See Appendix C.2.
	8.2. Content-Length		8.2. Content-Length
	The Content-Length entity-header field indicates the size of the		The entity-header field "Content-Length" indicates the size of the
	entity-body, in decimal number of OCTETs, sent to the recipient or,		entity-body, in decimal number of OCTETs, sent to the recipient or,
	in the case of the HEAD method, the size of the entity-body that		in the case of the HEAD method, the size of the entity-body that
	would have been sent had the request been a GET.		would have been sent had the request been a GET.
	Content-Length = "Content-Length" ":" 1*DIGIT		Content-Length = "Content-Length" ":" OWS 1*Content-Length-v
			Content-Length-v = 1*DIGIT
	An example is		An example is
	Content-Length: 3495		Content-Length: 3495
	Applications SHOULD use this field to indicate the transfer-length of		Applications SHOULD use this field to indicate the transfer-length of
	the message-body, unless this is prohibited by the rules in		the message-body, unless this is prohibited by the rules in
	Section 4.4.		Section 4.4.
	Any Content-Length greater than or equal to zero is a valid value.		Any Content-Length greater than or equal to zero is a valid value.
	skipping to change at page 42, line 7		skipping to change at page 36, line 38
	Note that the meaning of this field is significantly different from		Note that the meaning of this field is significantly different from
	the corresponding definition in MIME, where it is an optional field		the corresponding definition in MIME, where it is an optional field
	used within the "message/external-body" content-type. In HTTP, it		used within the "message/external-body" content-type. In HTTP, it
	SHOULD be sent whenever the message's length can be determined prior		SHOULD be sent whenever the message's length can be determined prior
	to being transferred, unless this is prohibited by the rules in		to being transferred, unless this is prohibited by the rules in
	Section 4.4.		Section 4.4.
	8.3. Date		8.3. Date
	The Date general-header field represents the date and time at which		The general-header field "Date" represents the date and time at which
	the message was originated, having the same semantics as orig-date in		the message was originated, having the same semantics as orig-date in
	Section 3.6.1 of [RFC2822]. The field value is an HTTP-date, as		Section 3.6.1 of [RFC5322]. The field value is an HTTP-date, as
	described in Section 3.3.1; it MUST be sent in rfc1123-date format.		described in Section 3.3.1; it MUST be sent in rfc1123-date format.
	Date = "Date" ":" HTTP-date		Date = "Date" ":" OWS Date-v
			Date-v = HTTP-date
	An example is		An example is
	Date: Tue, 15 Nov 1994 08:12:31 GMT		Date: Tue, 15 Nov 1994 08:12:31 GMT
	Origin servers MUST include a Date header field in all responses,		Origin servers MUST include a Date header field in all responses,
	except in these cases:		except in these cases:
	1. If the response status code is 100 (Continue) or 101 (Switching		1. If the response status code is 100 (Continue) or 101 (Switching
	Protocols), the response MAY include a Date header field, at the		Protocols), the response MAY include a Date header field, at the
	skipping to change at page 43, line 21		skipping to change at page 38, line 7
	An origin server without a clock MUST NOT assign Expires or Last-		An origin server without a clock MUST NOT assign Expires or Last-
	Modified values to a response, unless these values were associated		Modified values to a response, unless these values were associated
	with the resource by a system or user with a reliable clock. It MAY		with the resource by a system or user with a reliable clock. It MAY
	assign an Expires value that is known, at or before server		assign an Expires value that is known, at or before server
	configuration time, to be in the past (this allows "pre-expiration"		configuration time, to be in the past (this allows "pre-expiration"
	of responses without storing separate Expires values for each		of responses without storing separate Expires values for each
	resource).		resource).
	8.4. Host		8.4. Host
	The Host request-header field specifies the Internet host and port		The request-header field "Host" specifies the Internet host and port
	number of the resource being requested, as obtained from the original		number of the resource being requested, as obtained from the original
	URI given by the user or referring resource (generally an HTTP URL,		URI given by the user or referring resource (generally an HTTP URL,
	as described in Section 3.2.2). The Host field value MUST represent		as described in Section 3.2.1). The Host field value MUST represent
	the naming authority of the origin server or gateway given by the		the naming authority of the origin server or gateway given by the
	original URL. This allows the origin server or gateway to		original URL. This allows the origin server or gateway to
	differentiate between internally-ambiguous URLs, such as the root "/"		differentiate between internally-ambiguous URLs, such as the root "/"
	URL of a server for multiple host names on a single IP address.		URL of a server for multiple host names on a single IP address.
	Host = "Host" ":" uri-host [ ":" port ] ; Section 3.2.2		Host = "Host" ":" OWS Host-v
			Host-v = uri-host [ ":" port ] ; Section 3.2.1
	A "host" without any trailing port information implies the default		A "host" without any trailing port information implies the default
	port for the service requested (e.g., "80" for an HTTP URL). For		port for the service requested (e.g., "80" for an HTTP URL). For
	example, a request on the origin server for		example, a request on the origin server for
	<http://www.example.org/pub/WWW/> would properly include:		<http://www.example.org/pub/WWW/> would properly include:
	GET /pub/WWW/ HTTP/1.1		GET /pub/WWW/ HTTP/1.1
	Host: www.example.org		Host: www.example.org
	A client MUST include a Host header field in all HTTP/1.1 request		A client MUST include a Host header field in all HTTP/1.1 request
	skipping to change at page 44, line 7		skipping to change at page 38, line 41
	request message it forwards does contain an appropriate Host header		request message it forwards does contain an appropriate Host header
	field that identifies the service being requested by the proxy. All		field that identifies the service being requested by the proxy. All
	Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request)		Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request)
	status code to any HTTP/1.1 request message which lacks a Host header		status code to any HTTP/1.1 request message which lacks a Host header
	field.		field.
	See Sections 5.2 and C.1.1 for other requirements relating to Host.		See Sections 5.2 and C.1.1 for other requirements relating to Host.
	8.5. TE		8.5. TE
	The TE request-header field indicates what extension transfer-codings		The request-header field "TE" indicates what extension transfer-
	it is willing to accept in the response and whether or not it is		codings it is willing to accept in the response and whether or not it
	willing to accept trailer fields in a chunked transfer-coding. Its		is willing to accept trailer fields in a chunked transfer-coding.
	value may consist of the keyword "trailers" and/or a comma-separated		Its value may consist of the keyword "trailers" and/or a comma-
	list of extension transfer-coding names with optional accept		separated list of extension transfer-coding names with optional
	parameters (as described in Section 3.4).		accept parameters (as described in Section 3.4).
	TE = "TE" ":" #( t-codings )		TE = "TE" ":" OWS TE-v
	t-codings = "trailers" | ( transfer-extension [ accept-params ] )		TE-v = #t-codings
			t-codings = "trailers" / ( transfer-extension [ accept-params ] )
	The presence of the keyword "trailers" indicates that the client is		The presence of the keyword "trailers" indicates that the client is
	willing to accept trailer fields in a chunked transfer-coding, as		willing to accept trailer fields in a chunked transfer-coding, as
	defined in Section 3.4.1. This keyword is reserved for use with		defined in Section 3.4.1. This keyword is reserved for use with
	transfer-coding values even though it does not itself represent a		transfer-coding values even though it does not itself represent a
	transfer-coding.		transfer-coding.
	Examples of its use are:		Examples of its use are:
	TE: deflate		TE: deflate
	skipping to change at page 45, line 14		skipping to change at page 39, line 50
	3. If multiple transfer-codings are acceptable, then the acceptable		3. If multiple transfer-codings are acceptable, then the acceptable
	transfer-coding with the highest non-zero qvalue is preferred.		transfer-coding with the highest non-zero qvalue is preferred.
	The "chunked" transfer-coding always has a qvalue of 1.		The "chunked" transfer-coding always has a qvalue of 1.
	If the TE field-value is empty or if no TE field is present, the only		If the TE field-value is empty or if no TE field is present, the only
	transfer-coding is "chunked". A message with no transfer-coding is		transfer-coding is "chunked". A message with no transfer-coding is
	always acceptable.		always acceptable.
	8.6. Trailer		8.6. Trailer
	The Trailer general field value indicates that the given set of		The general field "Trailer" indicates that the given set of header
	header fields is present in the trailer of a message encoded with		fields is present in the trailer of a message encoded with chunked
	chunked transfer-coding.		transfer-coding.
	Trailer = "Trailer" ":" 1#field-name		Trailer = "Trailer" ":" OWS Trailer-v
			Trailer-v = 1#field-name
	An HTTP/1.1 message SHOULD include a Trailer header field in a		An HTTP/1.1 message SHOULD include a Trailer header field in a
	message using chunked transfer-coding with a non-empty trailer.		message using chunked transfer-coding with a non-empty trailer.
	Doing so allows the recipient to know which header fields to expect		Doing so allows the recipient to know which header fields to expect
	in the trailer.		in the trailer.
	If no Trailer header field is present, the trailer SHOULD NOT include		If no Trailer header field is present, the trailer SHOULD NOT include
	any header fields. See Section 3.4.1 for restrictions on the use of		any header fields. See Section 3.4.1 for restrictions on the use of
	trailer fields in a "chunked" transfer-coding.		trailer fields in a "chunked" transfer-coding.
	skipping to change at page 45, line 40		skipping to change at page 40, line 29
	include the following header fields:		include the following header fields:
	o Transfer-Encoding		o Transfer-Encoding
	o Content-Length		o Content-Length
	o Trailer		o Trailer
	8.7. Transfer-Encoding		8.7. Transfer-Encoding
	The Transfer-Encoding general-header field indicates what (if any)		The general-header "Transfer-Encoding" field indicates what (if any)
	type of transformation has been applied to the message body in order		type of transformation has been applied to the message body in order
	to safely transfer it between the sender and the recipient. This		to safely transfer it between the sender and the recipient. This
	differs from the content-coding in that the transfer-coding is a		differs from the content-coding in that the transfer-coding is a
	property of the message, not of the entity.		property of the message, not of the entity.
	Transfer-Encoding = "Transfer-Encoding" ":" 1#transfer-coding		Transfer-Encoding = "Transfer-Encoding" ":" OWS
			Transfer-Encoding-v
			Transfer-Encoding-v = 1#transfer-coding
	Transfer-codings are defined in Section 3.4. An example is:		Transfer-codings are defined in Section 3.4. An example is:
	Transfer-Encoding: chunked		Transfer-Encoding: chunked
	If multiple encodings have been applied to an entity, the transfer-		If multiple encodings have been applied to an entity, the transfer-
	codings MUST be listed in the order in which they were applied.		codings MUST be listed in the order in which they were applied.
	Additional information about the encoding parameters MAY be provided		Additional information about the encoding parameters MAY be provided
	by other entity-header fields not defined by this specification.		by other entity-header fields not defined by this specification.
	Many older HTTP/1.0 applications do not understand the Transfer-		Many older HTTP/1.0 applications do not understand the Transfer-
	Encoding header.		Encoding header.
	8.8. Upgrade		8.8. Upgrade
	skipping to change at page 46, line 14		skipping to change at page 41, line 7
	If multiple encodings have been applied to an entity, the transfer-		If multiple encodings have been applied to an entity, the transfer-
	codings MUST be listed in the order in which they were applied.		codings MUST be listed in the order in which they were applied.
	Additional information about the encoding parameters MAY be provided		Additional information about the encoding parameters MAY be provided
	by other entity-header fields not defined by this specification.		by other entity-header fields not defined by this specification.
	Many older HTTP/1.0 applications do not understand the Transfer-		Many older HTTP/1.0 applications do not understand the Transfer-
	Encoding header.		Encoding header.
	8.8. Upgrade		8.8. Upgrade
	The Upgrade general-header allows the client to specify what		The general-header "Upgrade" allows the client to specify what
	additional communication protocols it supports and would like to use		additional communication protocols it supports and would like to use
	if the server finds it appropriate to switch protocols. The server		if the server finds it appropriate to switch protocols. The server
	MUST use the Upgrade header field within a 101 (Switching Protocols)		MUST use the Upgrade header field within a 101 (Switching Protocols)
	response to indicate which protocol(s) are being switched.		response to indicate which protocol(s) are being switched.
	Upgrade = "Upgrade" ":" 1#product		Upgrade = "Upgrade" ":" OWS Upgrade-v
			Upgrade-v = 1#product
	For example,		For example,
	Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11		Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
	The Upgrade header field is intended to provide a simple mechanism		The Upgrade header field is intended to provide a simple mechanism
	for transition from HTTP/1.1 to some other, incompatible protocol.		for transition from HTTP/1.1 to some other, incompatible protocol.
	It does so by allowing the client to advertise its desire to use		It does so by allowing the client to advertise its desire to use
	another protocol, such as a later version of HTTP with a higher major		another protocol, such as a later version of HTTP with a higher major
	version number, even though the current request has been made using		version number, even though the current request has been made using
	skipping to change at page 47, line 18		skipping to change at page 42, line 10
	This specification only defines the protocol name "HTTP" for use by		This specification only defines the protocol name "HTTP" for use by
	the family of Hypertext Transfer Protocols, as defined by the HTTP		the family of Hypertext Transfer Protocols, as defined by the HTTP
	version rules of Section 3.1 and future updates to this		version rules of Section 3.1 and future updates to this
	specification. Any token can be used as a protocol name; however, it		specification. Any token can be used as a protocol name; however, it
	will only be useful if both the client and server associate the name		will only be useful if both the client and server associate the name
	with the same protocol.		with the same protocol.
	8.9. Via		8.9. Via
	The Via general-header field MUST be used by gateways and proxies to		The general-header field "Via" MUST be used by gateways and proxies
	indicate the intermediate protocols and recipients between the user		to indicate the intermediate protocols and recipients between the
	agent and the server on requests, and between the origin server and		user agent and the server on requests, and between the origin server
	the client on responses. It is analogous to the "Received" field		and the client on responses. It is analogous to the "Received" field
	defined in Section 3.6.7 of [RFC2822] and is intended to be used for		defined in Section 3.6.7 of [RFC5322] and is intended to be used for
	tracking message forwards, avoiding request loops, and identifying		tracking message forwards, avoiding request loops, and identifying
	the protocol capabilities of all senders along the request/response		the protocol capabilities of all senders along the request/response
	chain.		chain.
	Via = "Via" ":" 1#( received-protocol received-by [ comment ] )		Via = "Via" ":" OWS Via-v
			Via-v = 1#( received-protocol RWS received-by
			[ RWS comment ] )
	received-protocol = [ protocol-name "/" ] protocol-version		received-protocol = [ protocol-name "/" ] protocol-version
	protocol-name = token		protocol-name = token
	protocol-version = token		protocol-version = token
	received-by = ( uri-host [ ":" port ] ) | pseudonym		received-by = ( uri-host [ ":" port ] ) / pseudonym
	pseudonym = token		pseudonym = token
	The received-protocol indicates the protocol version of the message		The received-protocol indicates the protocol version of the message
	received by the server or client along each segment of the request/		received by the server or client along each segment of the request/
	response chain. The received-protocol version is appended to the Via		response chain. The received-protocol version is appended to the Via
	field value when the message is forwarded so that information about		field value when the message is forwarded so that information about
	the protocol capabilities of upstream applications remains visible to		the protocol capabilities of upstream applications remains visible to
	all recipients.		all recipients.
	The protocol-name is optional if and only if it would be "HTTP". The		The protocol-name is optional if and only if it would be "HTTP". The
	skipping to change at page 49, line 26		skipping to change at page 44, line 26
	| Via | http | standard | Section 8.9 |		| Via | http | standard | Section 8.9 |
	+-------------------+----------+----------+-------------+		+-------------------+----------+----------+-------------+
	The change controller is: "IETF (iesg@ietf.org) - Internet		The change controller is: "IETF (iesg@ietf.org) - Internet
	Engineering Task Force".		Engineering Task Force".
	9.2. URI Scheme Registration		9.2. URI Scheme Registration
	The entry for the "http" URI Scheme in the registry located at		The entry for the "http" URI Scheme in the registry located at
	<http://www.iana.org/assignments/uri-schemes.html> should be updated		<http://www.iana.org/assignments/uri-schemes.html> should be updated
	to point to Section 3.2.2 of this document (see [RFC4395]).		to point to Section 3.2.1 of this document (see [RFC4395]).
	9.3. Internet Media Type Registrations		9.3. Internet Media Type Registrations
	This document serves as the specification for the Internet media		This document serves as the specification for the Internet media
	types "message/http" and "application/http". The following is to be		types "message/http" and "application/http". The following is to be
	registered with IANA (see [RFC4288]).		registered with IANA (see [RFC4288]).
	9.3.1. Internet Media Type message/http		9.3.1. Internet Media Type message/http
	The message/http type can be used to enclose a single HTTP request or		The message/http type can be used to enclose a single HTTP request or
	skipping to change at page 54, line 21		skipping to change at page 49, line 21
	protect against a broad range of security and privacy attacks. Such		protect against a broad range of security and privacy attacks. Such
	cryptography is beyond the scope of the HTTP/1.1 specification.		cryptography is beyond the scope of the HTTP/1.1 specification.
	10.6. Denial of Service Attacks on Proxies		10.6. Denial of Service Attacks on Proxies
	They exist. They are hard to defend against. Research continues.		They exist. They are hard to defend against. Research continues.
	Beware.		Beware.
	11. Acknowledgments		11. Acknowledgments
	This specification makes heavy use of the augmented BNF and generic
	constructs defined by David H. Crocker for [RFC822ABNF]. Similarly,
	it reuses many of the definitions provided by Nathaniel Borenstein
	and Ned Freed for MIME [RFC2045]. We hope that their inclusion in
	this specification will help reduce past confusion over the
	relationship between HTTP and Internet mail message formats.
	HTTP has evolved considerably over the years. It has benefited from		HTTP has evolved considerably over the years. It has benefited from
	a large and active developer community--the many people who have		a large and active developer community--the many people who have
	participated on the www-talk mailing list--and it is that community		participated on the www-talk mailing list--and it is that community
	which has been most responsible for the success of HTTP and of the		which has been most responsible for the success of HTTP and of the
	World-Wide Web in general. Marc Andreessen, Robert Cailliau, Daniel		World-Wide Web in general. Marc Andreessen, Robert Cailliau, Daniel
	W. Connolly, Bob Denny, John Franks, Jean-Francois Groff, Phillip M.		W. Connolly, Bob Denny, John Franks, Jean-Francois Groff, Phillip M.
	Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob McCool, Lou Montulli,		Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob McCool, Lou Montulli,
	Dave Raggett, Tony Sanders, and Marc VanHeyningen deserve special		Dave Raggett, Tony Sanders, and Marc VanHeyningen deserve special
	recognition for their efforts in defining early aspects of the		recognition for their efforts in defining early aspects of the
	protocol.		protocol.
	skipping to change at page 55, line 24		skipping to change at page 50, line 17
	Mogul, Paul Leach, Dave Kristol, Koen Holtman, John Franks, Josh		Mogul, Paul Leach, Dave Kristol, Koen Holtman, John Franks, Josh
	Cohen, Alex Hopmann, Scott Lawrence, and Larry Masinter for their		Cohen, Alex Hopmann, Scott Lawrence, and Larry Masinter for their
	help. And thanks go particularly to Jeff Mogul and Scott Lawrence		help. And thanks go particularly to Jeff Mogul and Scott Lawrence
	for performing the "MUST/MAY/SHOULD" audit.		for performing the "MUST/MAY/SHOULD" audit.
	The Apache Group, Anselm Baird-Smith, author of Jigsaw, and Henrik		The Apache Group, Anselm Baird-Smith, author of Jigsaw, and Henrik
	Frystyk implemented RFC 2068 early, and we wish to thank them for the		Frystyk implemented RFC 2068 early, and we wish to thank them for the
	discovery of many of the problems that this document attempts to		discovery of many of the problems that this document attempts to
	rectify.		rectify.
			This specification makes heavy use of the augmented BNF and generic
			constructs defined by David H. Crocker for [RFC5234]. Similarly, it
			reuses many of the definitions provided by Nathaniel Borenstein and
			Ned Freed for MIME [RFC2045]. We hope that their inclusion in this
			specification will help reduce past confusion over the relationship
			between HTTP and Internet mail message formats.
	12. References		12. References
	12.1. Normative References		12.1. Normative References
	[ISO-8859-1]		[ISO-8859-1]
	International Organization for Standardization,		International Organization for Standardization,
	"Information technology -- 8-bit single-byte coded graphic		"Information technology -- 8-bit single-byte coded graphic
	character sets -- Part 1: Latin alphabet No. 1", ISO/		character sets -- Part 1: Latin alphabet No. 1", ISO/
	IEC 8859-1:1998, 1998.		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., Ed.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	and J. Reschke, Ed., "HTTP/1.1, part 2: Message		and J. Reschke, Ed., "HTTP/1.1, part 2: Message
	Semantics", draft-ietf-httpbis-p2-semantics-04 (work in		Semantics", draft-ietf-httpbis-p2-semantics-05 (work in
	progress), August 2008.		progress), November 2008.
	[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., Ed.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload		and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload
	and Content Negotiation", draft-ietf-httpbis-p3-payload-04		and Content Negotiation", draft-ietf-httpbis-p3-payload-05
	(work in progress), August 2008.		(work in progress), November 2008.
	[Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and		and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and
	Partial Responses", draft-ietf-httpbis-p5-range-04 (work		Partial Responses", draft-ietf-httpbis-p5-range-05 (work
	in progress), August 2008.		in progress), November 2008.
	[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., Ed.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	and J. Reschke, Ed., "HTTP/1.1, part 6: Caching",		and J. Reschke, Ed., "HTTP/1.1, part 6: Caching",
	draft-ietf-httpbis-p6-cache-04 (work in progress),		draft-ietf-httpbis-p6-cache-05 (work in progress),
	August 2008.		November 2008.
	[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail		[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
	Extensions (MIME) Part One: Format of Internet Message		Extensions (MIME) Part One: Format of Internet Message
	Bodies", RFC 2045, November 1996.		Bodies", RFC 2045, November 1996.
	[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)		[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
	Part Three: Message Header Extensions for Non-ASCII Text",		Part Three: Message Header Extensions for Non-ASCII Text",
	RFC 2047, November 1996.		RFC 2047, November 1996.
	[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.
	[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform		[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
	Resource Identifiers (URI): Generic Syntax", RFC 2396,		Resource Identifier (URI): Generic Syntax", RFC 3986,
	August 1998.		STD 66, January 2005.
	[RFC822ABNF]		[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
	Crocker, D., "Standard for the format of ARPA Internet		Specifications: ABNF", STD 68, RFC 5234, January 2008.
	text messages", STD 11, RFC 822, August 1982.
	[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
	[Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and		[Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and
	Politics", ACM Transactions on Internet Technology Vol. 1,		Politics", ACM Transactions on Internet Technology Vol. 1,
	#2, November 2001, <http://arxiv.org/abs/cs.SE/0105018>.		#2, November 2001, <http://arxiv.org/abs/cs.SE/0105018>.
	skipping to change at page 57, line 16		skipping to change at page 52, line 14
	and Support", STD 3, RFC 1123, October 1989.		and Support", STD 3, RFC 1123, October 1989.
	[RFC1305] Mills, D., "Network Time Protocol (Version 3)		[RFC1305] Mills, D., "Network Time Protocol (Version 3)
	Specification, Implementation", RFC 1305, March 1992.		Specification, Implementation", RFC 1305, March 1992.
	[RFC1436] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D.,		[RFC1436] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D.,
	Torrey, D., and B. Alberti, "The Internet Gopher Protocol		Torrey, D., and B. Alberti, "The Internet Gopher Protocol
	(a distributed document search and retrieval protocol)",		(a distributed document search and retrieval protocol)",
	RFC 1436, March 1993.		RFC 1436, March 1993.
	[RFC1630] Berners-Lee, T., "Universal Resource Identifiers in WWW: A
	Unifying Syntax for the Expression of Names and Addresses
	of Objects on the Network as used in the World-Wide Web",
	RFC 1630, June 1994.
	[RFC1737] Masinter, L. and K. Sollins, "Functional Requirements for
	Uniform Resource Names", RFC 1737, December 1994.
	[RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
	Resource Locators (URL)", RFC 1738, December 1994.
	[RFC1808] Fielding, R., "Relative Uniform Resource Locators",
	RFC 1808, June 1995.
	[RFC1900] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work",		[RFC1900] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work",
	RFC 1900, February 1996.		RFC 1900, February 1996.
	[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext		[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext
	Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.		Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
	[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.		[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
	Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",		Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
	RFC 2068, January 1997.		RFC 2068, January 1997.
	[RFC2109] Kristol, D. and L. Montulli, "HTTP State Management		[RFC2109] Kristol, D. and L. Montulli, "HTTP State Management
	Mechanism", RFC 2109, February 1997.		Mechanism", RFC 2109, February 1997.
	[RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use		[RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use
	and Interpretation of HTTP Version Numbers", RFC 2145,		and Interpretation of HTTP Version Numbers", RFC 2145,
	May 1997.		May 1997.
	[RFC2324] Masinter, L., "Hyper Text Coffee Pot Control Protocol
	(HTCPCP/1.0)", RFC 2324, April 1998.
	[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,		[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext		Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
	Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.		Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
	[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.		[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
	[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
	April 2001.
	[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
	April 2001.
	[RFC2965] Kristol, D. and L. Montulli, "HTTP State Management		[RFC2965] Kristol, D. and L. Montulli, "HTTP State Management
	Mechanism", RFC 2965, October 2000.		Mechanism", RFC 2965, October 2000.
	[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration		[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
	Procedures for Message Header Fields", BCP 90, RFC 3864,		Procedures for Message Header Fields", BCP 90, RFC 3864,
	September 2004.		September 2004.
	[RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)",		[RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)",
	RFC 3977, October 2006.		RFC 3977, October 2006.
	[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and		[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
	Registration Procedures", BCP 13, RFC 4288, December 2005.		Registration Procedures", BCP 13, RFC 4288, December 2005.
	[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and		[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
	Registration Procedures for New URI Schemes", BCP 115,		Registration Procedures for New URI Schemes", BCP 115,
	RFC 4395, February 2006.		RFC 4395, February 2006.
			[RFC5322] Resnick, P., "Internet Message Format", RFC 5322,
			October 2008.
	[RFC822] Crocker, D., "Standard for the format of ARPA Internet		[RFC822] Crocker, D., "Standard for the format of ARPA Internet
	text messages", STD 11, RFC 822, August 1982.		text messages", STD 11, RFC 822, August 1982.
	[RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol",		[RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol",
	STD 9, RFC 959, October 1985.		STD 9, RFC 959, October 1985.
	[Spe] Spero, S., "Analysis of HTTP Performance Problems",		[Spe] Spero, S., "Analysis of HTTP Performance Problems",
	<http://sunsite.unc.edu/mdma-release/http-prob.html>.		<http://sunsite.unc.edu/mdma-release/http-prob.html>.
	[Tou1998] Touch, J., Heidemann, J., and K. Obraczka, "Analysis of		[Tou1998] Touch, J., Heidemann, J., and K. Obraczka, "Analysis of
	skipping to change at page 60, line 9		skipping to change at page 54, line 35
	Appendix B. Conversion of Date Formats		Appendix B. Conversion of Date Formats
	HTTP/1.1 uses a restricted set of date formats (Section 3.3.1) to		HTTP/1.1 uses a restricted set of date formats (Section 3.3.1) to
	simplify the process of date comparison. Proxies and gateways from		simplify the process of date comparison. Proxies and gateways from
	other protocols SHOULD ensure that any Date header field present in a		other protocols SHOULD ensure that any Date header field present in a
	message conforms to one of the HTTP/1.1 formats and rewrite the date		message conforms to one of the HTTP/1.1 formats and rewrite the date
	if necessary.		if necessary.
	Appendix C. Compatibility with Previous Versions		Appendix C. Compatibility with Previous Versions
			HTTP has been in use by the World-Wide Web global information
			initiative since 1990. The first version of HTTP, later referred to
			as HTTP/0.9, was a simple protocol for hypertext data transfer across
			the Internet with only a single method and no metadata. HTTP/1.0, as
			defined by [RFC1945], added a range of request methods and MIME-like
			messaging that could include metadata about the data transferred and
			modifiers on the request/response semantics. However, HTTP/1.0 did
			not sufficiently take into consideration the effects of hierarchical
			proxies, caching, the need for persistent connections, or name-based
			virtual hosts. The proliferation of incompletely-implemented
			applications calling themselves "HTTP/1.0" further necessitated a
			protocol version change in order for two communicating applications
			to determine each other's true capabilities.
			HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent
			requirements that enable reliable implementations, adding only those
			new features that will either be safely ignored by an HTTP/1.0
			recipient or only sent when communicating with a party advertising
			compliance with HTTP/1.1.
	It is beyond the scope of a protocol specification to mandate		It is beyond the scope of a protocol specification to mandate
	compliance with previous versions. HTTP/1.1 was deliberately		compliance with previous versions. HTTP/1.1 was deliberately
	designed, however, to make supporting previous versions easy. It is		designed, however, to make supporting previous versions easy. It is
	worth noting that, at the time of composing this specification		worth noting that, at the time of composing this specification
	(1996), we would expect commercial HTTP/1.1 servers to:		(1996), we would expect commercial HTTP/1.1 servers to:
	o recognize the format of the Request-Line for HTTP/0.9, 1.0, and		o recognize the format of the Request-Line for HTTP/0.9, 1.0, and
	1.1 requests;		1.1 requests;
	o understand any valid request in the format of HTTP/0.9, 1.0, or		o understand any valid request in the format of HTTP/0.9, 1.0, or
	skipping to change at page 62, line 38		skipping to change at page 57, line 38
	adding an IANA registry for transfer-codings (separate from content		adding an IANA registry for transfer-codings (separate from content
	codings), a new header field (TE) and enabling trailer headers in the		codings), a new header field (TE) and enabling trailer headers in the
	future. Transfer encoding is a major performance benefit, so it was		future. Transfer encoding is a major performance benefit, so it was
	worth fixing [Nie1997]. TE also solves another, obscure, downward		worth fixing [Nie1997]. TE also solves another, obscure, downward
	interoperability problem that could have occurred due to interactions		interoperability problem that could have occurred due to interactions
	between authentication trailers, chunked encoding and HTTP/1.0		between authentication trailers, chunked encoding and HTTP/1.0
	clients.(Section 3.4, 3.4.1, and 8.5)		clients.(Section 3.4, 3.4.1, and 8.5)
	C.4. Changes from RFC 2616		C.4. Changes from RFC 2616
	The CHAR rule does not allow the NUL character anymore (this affects		Rules about implicit linear white space between certain grammar
	the comment and quoted-string rules). Furthermore, the quoted-pair		productions have been removed; now it's only allowed when
	rule does not allow escaping NUL, CR or LF anymore. (Section 2.2)		specifically pointed out in the ABNF. The CHAR rule does not allow
			the NUL character anymore (this affects the comment and quoted-string
			rules). Furthermore, the quoted-pair rule does not allow escaping
			NUL, CR or LF anymore. (Section 2.2)
	Clarify that HTTP-Version is case sensitive. (Section 3.1)		Clarify that HTTP-Version is case sensitive. (Section 3.1)
	Remove reference to non-existant identity transfer-coding value		Remove reference to non-existant identity transfer-coding value
	tokens. (Sections 3.4 and 4.4)		tokens. (Sections 3.4 and 4.4)
	Clarification that the chunk length does not include the count of the		Clarification that the chunk length does not include the count of the
	octets in the chunk header and trailer. (Section 3.4.1)		octets in the chunk header and trailer. (Section 3.4.1)
			Update use of abs_path production from RFC1808 to the path-absolute +
			query components of RFC3986. (Section 5.1.2)
	Fix BNF to add query, as the abs_path production in Section 3 of
	[RFC2396] doesn't define it. (Section 5.1.2)
	Clarify exactly when close connection options must be sent.		Clarify exactly when close connection options must be sent.
	(Section 8.1)		(Section 8.1)
	Appendix D. Change Log (to be removed by RFC Editor before publication)		Appendix D. Terminology
	D.1. Since RFC2616		This specification uses a number of terms to refer to the roles
			played by participants in, and objects of, the HTTP communication.
			connection
			A transport layer virtual circuit established between two programs
			for the purpose of communication.
			message
			The basic unit of HTTP communication, consisting of a structured
			sequence of octets matching the syntax defined in Section 4 and
			transmitted via the connection.
			request
			An HTTP request message, as defined in Section 5.
			response
			An HTTP response message, as defined in Section 6.
			resource
			A network data object or service that can be identified by a URI,
			as defined in Section 3.2. Resources may be available in multiple
			representations (e.g. multiple languages, data formats, size, and
			resolutions) or vary in other ways.
			entity
			The information transferred as the payload of a request or
			response. An entity consists of metainformation in the form of
			entity-header fields and content in the form of an entity-body, as
			described in Section 4 of [Part3].
			representation
			An entity included with a response that is subject to content
			negotiation, as described in Section 5 of [Part3]. There may
			exist multiple representations associated with a particular
			response status.
			content negotiation
			The mechanism for selecting the appropriate representation when
			servicing a request, as described in Section 5 of [Part3]. The
			representation of entities in any response can be negotiated
			(including error responses).
			variant
			A resource may have one, or more than one, representation(s)
			associated with it at any given instant. Each of these
			representations is termed a `variant'. Use of the term `variant'
			does not necessarily imply that the resource is subject to content
			negotiation.
			client
			A program that establishes connections for the purpose of sending
			requests.
			user agent
			The client which initiates a request. These are often browsers,
			editors, spiders (web-traversing robots), or other end user tools.
			server
			An application program that accepts connections in order to
			service requests by sending back responses. Any given program may
			be capable of being both a client and a server; our use of these
			terms refers only to the role being performed by the program for a
			particular connection, rather than to the program's capabilities
			in general. Likewise, any server may act as an origin server,
			proxy, gateway, or tunnel, switching behavior based on the nature
			of each request.
			origin server
			The server on which a given resource resides or is to be created.
			proxy
			An intermediary program which acts as both a server and a client
			for the purpose of making requests on behalf of other clients.
			Requests are serviced internally or by passing them on, with
			possible translation, to other servers. A proxy MUST implement
			both the client and server requirements of this specification. A
			"transparent proxy" is a proxy that does not modify the request or
			response beyond what is required for proxy authentication and
			identification. A "non-transparent proxy" is a proxy that
			modifies the request or response in order to provide some added
			service to the user agent, such as group annotation services,
			media type transformation, protocol reduction, or anonymity
			filtering. Except where either transparent or non-transparent
			behavior is explicitly stated, the HTTP proxy requirements apply
			to both types of proxies.
			gateway
			A server which acts as an intermediary for some other server.
			Unlike a proxy, a gateway receives requests as if it were the
			origin server for the requested resource; the requesting client
			may not be aware that it is communicating with a gateway.
			tunnel
			An intermediary program which is acting as a blind relay between
			two connections. Once active, a tunnel is not considered a party
			to the HTTP communication, though the tunnel may have been
			initiated by an HTTP request. The tunnel ceases to exist when
			both ends of the relayed connections are closed.
			cache
			A program's local store of response messages and the subsystem
			that controls its message storage, retrieval, and deletion. A
			cache stores cacheable responses in order to reduce the response
			time and network bandwidth consumption on future, equivalent
			requests. Any client or server may include a cache, though a
			cache cannot be used by a server that is acting as a tunnel.
			cacheable
			A response is cacheable if a cache is allowed to store a copy of
			the response message for use in answering subsequent requests.
			The rules for determining the cacheability of HTTP responses are
			defined in Section 1 of [Part6]. Even if a resource is cacheable,
			there may be additional constraints on whether a cache can use the
			cached copy for a particular request.
			upstream/downstream
			Upstream and downstream describe the flow of a message: all
			messages flow from upstream to downstream.
			inbound/outbound
			Inbound and outbound refer to the request and response paths for
			messages: "inbound" means "traveling toward the origin server",
			and "outbound" means "traveling toward the user agent"
			Appendix E. Change Log (to be removed by RFC Editor before publication)
			E.1. Since RFC2616
	Extracted relevant partitions from [RFC2616].		Extracted relevant partitions from [RFC2616].
	D.2. Since draft-ietf-httpbis-p1-messaging-00		E.2. Since draft-ietf-httpbis-p1-messaging-00
	Closed issues:		Closed issues:
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/1>: "HTTP		o <http://tools.ietf.org/wg/httpbis/trac/ticket/1>: "HTTP Version
	Version should be case sensitive"		should be case sensitive"
	(<http://purl.org/NET/http-errata#verscase>)		(<http://purl.org/NET/http-errata#verscase>)
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/2>: "'unsafe'		o <http://tools.ietf.org/wg/httpbis/trac/ticket/2>: "'unsafe'
	characters" (<http://purl.org/NET/http-errata#unsafe-uri>)		characters" (<http://purl.org/NET/http-errata#unsafe-uri>)
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/3>: "Chunk Size		o <http://tools.ietf.org/wg/httpbis/trac/ticket/3>: "Chunk Size
	Definition" (<http://purl.org/NET/http-errata#chunk-size>)		Definition" (<http://purl.org/NET/http-errata#chunk-size>)
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/4>: "Message		o <http://tools.ietf.org/wg/httpbis/trac/ticket/4>: "Message Length"
	Length" (<http://purl.org/NET/http-errata#msg-len-chars>)		(<http://purl.org/NET/http-errata#msg-len-chars>)
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/8>: "Media Type		o <http://tools.ietf.org/wg/httpbis/trac/ticket/8>: "Media Type
	Registrations" (<http://purl.org/NET/http-errata#media-reg>)		Registrations" (<http://purl.org/NET/http-errata#media-reg>)
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/11>: "URI		o <http://tools.ietf.org/wg/httpbis/trac/ticket/11>: "URI includes
	includes query" (<http://purl.org/NET/http-errata#uriquery>)		query" (<http://purl.org/NET/http-errata#uriquery>)
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/15>: "No close		o <http://tools.ietf.org/wg/httpbis/trac/ticket/15>: "No close on
	on 1xx responses" (<http://purl.org/NET/http-errata#noclose1xx>)		1xx responses" (<http://purl.org/NET/http-errata#noclose1xx>)
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/16>: "Remove		o <http://tools.ietf.org/wg/httpbis/trac/ticket/16>: "Remove
	'identity' token references"		'identity' token references"
	(<http://purl.org/NET/http-errata#identity>)		(<http://purl.org/NET/http-errata#identity>)
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/26>: "Import query
			BNF"
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/26>: "Import		o <http://tools.ietf.org/wg/httpbis/trac/ticket/31>: "qdtext BNF"
	query BNF"
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/31>: "qdtext		o <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and
	BNF"		Informative references"
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative		o <http://tools.ietf.org/wg/httpbis/trac/ticket/42>: "RFC2606
	and Informative references"
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/42>: "RFC2606
	Compliance"		Compliance"
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/45>: "RFC977		o <http://tools.ietf.org/wg/httpbis/trac/ticket/45>: "RFC977
	reference"		reference"
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/46>: "RFC1700		o <http://tools.ietf.org/wg/httpbis/trac/ticket/46>: "RFC1700
	references"		references"
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/47>:		o <http://tools.ietf.org/wg/httpbis/trac/ticket/47>: "inconsistency
	"inconsistency in date format explanation"		in date format explanation"
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/48>: "Date		o <http://tools.ietf.org/wg/httpbis/trac/ticket/48>: "Date reference
	reference typo"		typo"
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/65>:		o <http://tools.ietf.org/wg/httpbis/trac/ticket/65>: "Informative
	"Informative references"		references"
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/66>:		o <http://tools.ietf.org/wg/httpbis/trac/ticket/66>: "ISO-8859-1
	"ISO-8859-1 Reference"		Reference"
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/86>: "Normative		o <http://tools.ietf.org/wg/httpbis/trac/ticket/86>: "Normative up-
	up-to-date references"		to-date references"
	Other changes:		Other changes:
	o Update media type registrations to use RFC4288 template.		o Update media type registrations to use RFC4288 template.
	o Use names of RFC4234 core rules DQUOTE and HTAB, fix broken ABNF		o Use names of RFC4234 core rules DQUOTE and HTAB, fix broken ABNF
	for chunk-data (work in progress on		for chunk-data (work in progress on
	<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36>)		<http://tools.ietf.org/wg/httpbis/trac/ticket/36>)
	D.3. Since draft-ietf-httpbis-p1-messaging-01		E.3. Since draft-ietf-httpbis-p1-messaging-01
	Closed issues:		Closed issues:
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/19>: "Bodies on		o <http://tools.ietf.org/wg/httpbis/trac/ticket/19>: "Bodies on GET
	GET (and other) requests"		(and other) requests"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/55>: "Updating to
			RFC4288"
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/55>: "Updating		o <http://tools.ietf.org/wg/httpbis/trac/ticket/57>: "Status Code
	to RFC4288"		and Reason Phrase"
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/57>: "Status		o <http://tools.ietf.org/wg/httpbis/trac/ticket/82>: "rel_path not
	Code and Reason Phrase"		used"
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/82>: "rel_path
	not used"
	Ongoing work on ABNF conversion		Ongoing work on ABNF conversion
	(<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36>):		(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
	o Get rid of duplicate BNF rule names ("host" -> "uri-host",		o Get rid of duplicate BNF rule names ("host" -> "uri-host",
	"trailer" -> "trailer-part").		"trailer" -> "trailer-part").
	o Avoid underscore character in rule names ("http_URL" -> "http-		o Avoid underscore character in rule names ("http_URL" -> "http-
	URL", "abs_path" -> "path-absolute").		URL", "abs_path" -> "path-absolute").
	o Add rules for terms imported from URI spec ("absoluteURI",		o Add rules for terms imported from URI spec ("absoluteURI",
	"authority", "path-absolute", "port", "query", "relativeURI",		"authority", "path-absolute", "port", "query", "relativeURI",
	"host) -- these will have to be updated when switching over to		"host) -- these will have to be updated when switching over to
	skipping to change at page 65, line 34		skipping to change at page 63, line 43
	o Move "Product Tokens" section (back) into Part 1, as "token" is		o Move "Product Tokens" section (back) into Part 1, as "token" is
	used in the definition of the Upgrade header.		used in the definition of the Upgrade header.
	o Add explicit references to BNF syntax and rules imported from		o Add explicit references to BNF syntax and rules imported from
	other parts of the specification.		other parts of the specification.
	o Rewrite prose rule "token" in terms of "tchar", rewrite prose rule		o Rewrite prose rule "token" in terms of "tchar", rewrite prose rule
	"TEXT".		"TEXT".
	D.4. Since draft-ietf-httpbis-p1-messaging-02		E.4. Since draft-ietf-httpbis-p1-messaging-02
	Closed issues:		Closed issues:
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/51>: "HTTP-date		o <http://tools.ietf.org/wg/httpbis/trac/ticket/51>: "HTTP-date vs.
	vs. rfc1123-date"		rfc1123-date"
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/64>: "WS in
	quoted-pair"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/64>: "WS in quoted-
			pair"
	Ongoing work on IANA Message Header Registration		Ongoing work on IANA Message Header Registration
	(<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/40>):		(<http://tools.ietf.org/wg/httpbis/trac/ticket/40>):
	o Reference RFC 3984, and update header registrations for headers		o Reference RFC 3984, and update header registrations for headers
	defined in this document.		defined in this document.
	Ongoing work on ABNF conversion		Ongoing work on ABNF conversion
	(<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36>):		(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
	o Replace string literals when the string really is case-sensitive		o Replace string literals when the string really is case-sensitive
	(HTTP-Version).		(HTTP-Version).
	D.5. Since draft-ietf-httpbis-p1-messaging-03		E.5. Since draft-ietf-httpbis-p1-messaging-03
	Closed issues:		Closed issues:
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/28>:		o <http://tools.ietf.org/wg/httpbis/trac/ticket/28>: "Connection
	"Connection closing"		closing"
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/97>: "Move		o <http://tools.ietf.org/wg/httpbis/trac/ticket/97>: "Move
	registrations and registry information to IANA Considerations"		registrations and registry information to IANA Considerations"
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/120>: "need new		o <http://tools.ietf.org/wg/httpbis/trac/ticket/120>: "need new URL
	URL for PAD1995 reference"		for PAD1995 reference"
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/127>: "IANA		o <http://tools.ietf.org/wg/httpbis/trac/ticket/127>: "IANA
	Considerations: update HTTP URI scheme registration"		Considerations: update HTTP URI scheme registration"
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/128>: "Cite		o <http://tools.ietf.org/wg/httpbis/trac/ticket/128>: "Cite HTTPS
	HTTPS URI scheme definition"		URI scheme definition"
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/129>: "List-		o <http://tools.ietf.org/wg/httpbis/trac/ticket/129>: "List-type
	type headers vs Set-Cookie"		headers vs Set-Cookie"
	Ongoing work on ABNF conversion		Ongoing work on ABNF conversion
	(<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36>):		(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
	o Replace string literals when the string really is case-sensitive		o Replace string literals when the string really is case-sensitive
	(HTTP-Date).		(HTTP-Date).
	o Replace HEX by HEXDIG for future consistence with RFC 5234's core		o Replace HEX by HEXDIG for future consistence with RFC 5234's core
	rules.		rules.
			E.6. Since draft-ietf-httpbis-p1-messaging-04
			Closed issues:
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/34>: "Out-of-date
			reference for URIs"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/132>: "RFC 2822 is
			updated by RFC 5322"
			Ongoing work on ABNF conversion
			(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
			o Use "/" instead of "|" for alternatives.
			o Get rid of RFC822 dependency; use RFC5234 plus extensions instead.
			o Only reference RFC 5234's core rules.
			o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
			whitespace ("OWS") and required whitespace ("RWS").
			o Rewrite ABNFs to spell out whitespace rules, factor out header
			value format definitions.
	Index		Index
	A		A
	application/http Media Type 50		application/http Media Type 45
	C		C
	cache 8		cache 60
	cacheable 9		cacheable 60
	client 7		client 59
	connection 6		connection 58
	Connection header 40		Connection header 35
	content negotiation 7		content negotiation 59
	Content-Length header 41		Content-Length header 36
	D		D
	Date header 42		Date header 36
	downstream 9		downstream 61
	E		E
	entity 7		entity 58
	G		G
	gateway 8		gateway 60
	Grammar		Grammar
	absoluteURI 18		absolute-URI 12
	ALPHA 14		asctime-date 14
	asctime-date 20		attribute 16
	attribute 21		authority 12
	authority 18		BWS 9
	CHAR 14		chunk 17
	chunk 22		chunk-data 17
	chunk-data 22		chunk-ext 17
	chunk-ext-name 22		chunk-ext-name 17
	chunk-ext-val 22		chunk-ext-val 17
	chunk-extension 22		chunk-size 17
	chunk-size 22		Chunked-Body 17
	Chunked-Body 22		comment 10
	comment 15		Connection 35
	Connection 40		connection-token 35
	connection-token 40		Connection-v 35
	Content-Length 41		Content-Length 36
	CR 14		Content-Length-v 36
	CRLF 14		ctext 10
	ctext 15		Date 36
	CTL 14		Date-v 36
	Date 42		date1 14
	date1 20		date2 14
	date2 20		date3 14
	date3 20		extension-code 27
	DIGIT 14		extension-method 24
	DQUOTE 14		field-content 20
	extension-code 33		field-name 20
	extension-method 29		field-value 20
	field-content 25		general-header 23
	field-name 25		generic-message 19
	field-value 25		Host 38
	general-header 29		Host-v 38
	generic-message 25		HTTP-date 14
	HEXDIG 15		HTTP-message 19
	Host 43		HTTP-Prot-Name 11
	HTAB 14		http-URI 13
	HTTP-date 20		HTTP-Version 11
	HTTP-message 24		last-chunk 17
	HTTP-Prot-Name 16		message-body 21
	http-URL 18		message-header 20
	HTTP-Version 16		Method 24
	last-chunk 22		month 14
	LF 14		obsolete-date 14
	LWS 14		OWS 9
	message-body 26		parameter 16
	message-header 25		path-absolute 12
	Method 29		port 12
	month 20		product 18
	obsolete-date 20		product-version 18
	OCTET 14		protocol-name 42
	parameter 21		protocol-version 42
	path-absolute 18		pseudonym 42
	port 18		qdtext 10
	product 24		query 12
	product-version 24		quoted-pair 10
	protocol-name 47		quoted-string 10
	protocol-version 47		quoted-text 10
	pseudonym 47		Reason-Phrase 27
	qdtext 15		received-by 42
	query 18		received-protocol 42
	quoted-pair 15		relative-part 12
	quoted-string 15		relativeURI 12
	quoted-text 15		Request 24
	Reason-Phrase 33		Request-Line 24
	received-by 47		Request-URI 24
	received-protocol 47		Response 26
	relativeURI 18		rfc850-date 14
	Request 29		rfc1123-date 14
	Request-Line 29		RWS 9
	Request-URI 30		start-line 19
	Response 32		Status-Code 27
	rfc850-date 20		Status-Line 27
	rfc1123-date 20		t-codings 38
	separators 15		tchar 10
	SP 14		TE 38
	start-line 25		TE-v 38
	Status-Code 33		TEXT 9
	Status-Line 32		time 14
	t-codings 44		token 10
	tchar 15		Trailer 40
	TE 44		trailer-part 17
	TEXT 14		Trailer-v 40
	time 20		transfer-coding 16
	token 15		Transfer-Encoding 40
	Trailer 45		Transfer-Encoding-v 40
	trailer-part 22		transfer-extension 16
	transfer-coding 21		Upgrade 41
	Transfer-Encoding 45		Upgrade-v 41
	transfer-extension 21		uri-host 12
	Upgrade 46		URI-reference 12
	uri-host 18		value 16
	value 21		Via 42
	Via 47		Via-v 42
	weekday 20		weekday 14
	wkday 20		wkday 14
	H		H
	Headers		Headers
	Connection 40		Connection 35
	Content-Length 41		Content-Length 36
	Date 42		Date 36
	Host 43		Host 38
	TE 44		TE 38
	Trailer 45		Trailer 39
	Transfer-Encoding 45		Transfer-Encoding 40
	Upgrade 46		Upgrade 41
	Via 47		Via 42
	Host header 43		Host header 38
	http URI scheme 18		http URI scheme 13
	https URI scheme 18		https URI scheme 13
	I		I
	implied *LWS 13		inbound 61
	inbound 9
	M		M
	Media Type		Media Type
	application/http 50		application/http 45
	message/http 49		message/http 44
	message 6		message 58
	message/http Media Type 49		message/http Media Type 44
	O		O
	origin server 8		origin server 59
	outbound 9		outbound 61
	P		P
	proxy 8		proxy 59
	R		R
	representation 7		representation 58
	request 6		request 58
	resource 7		resource 58
	response 6		response 58
	S		S
	server 8		server 59
	T		T
	TE header 44		TE header 38
	Trailer header 45		Trailer header 39
	Transfer-Encoding header 45		Transfer-Encoding header 40
	tunnel 8		tunnel 60
	U		U
	Upgrade header 46		Upgrade header 41
	upstream 9		upstream 61
	URI scheme		URI scheme
	http 18		http 13
	https 18		https 13
	user agent 7		user agent 59
	V		V
	variant 7		variant 59
	Via header 47		Via header 42
	Authors' Addresses		Authors' Addresses
	Roy T. Fielding (editor)		Roy T. Fielding (editor)
	Day Software		Day Software
	23 Corporate Plaza DR, Suite 280		23 Corporate Plaza DR, Suite 280
	Newport Beach, CA 92660		Newport Beach, CA 92660
	USA		USA
	Phone: +1-949-706-5300		Phone: +1-949-706-5300
End of changes. 172 change blocks.
	805 lines changed or deleted		743 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/