draft-ietf-httpbis-p1-messaging-06.txt		draft-ietf-httpbis-p1-messaging-07.txt
	HTTPbis Working Group R. Fielding, Ed.		HTTPbis 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: September 10, 2009 J. Mogul		Expires: January 14, 2010 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
	March 9, 2009		July 13, 2009
	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-06		draft-ietf-httpbis-p1-messaging-07
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79. This document may contain material		provisions of BCP 78 and BCP 79. This document may contain material
	from IETF Documents or IETF Contributions published or made publicly		from IETF Documents or IETF Contributions published or made publicly
	available before November 10, 2008. The person(s) controlling the		available before November 10, 2008. The person(s) controlling the
	copyright in some of this material may not have granted the IETF		copyright in some of this material may not have granted the IETF
	Trust the right to allow modifications of such material outside the		Trust the right to allow modifications of such material outside the
	IETF Standards Process. Without obtaining an adequate license from		IETF Standards Process. Without obtaining an adequate license from
	skipping to change at page 2, line 10		skipping to change at page 2, line 10
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	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 September 10, 2009.		This Internet-Draft will expire on January 14, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2009 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents in effect on the date of		Provisions Relating to IETF Documents in effect on the date of
	publication of this document (http://trustee.ietf.org/license-info).		publication of this document (http://trustee.ietf.org/license-info).
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 44		skipping to change at page 2, line 44
	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://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://tools.ietf.org/wg/httpbis/>.		<http://tools.ietf.org/wg/httpbis/>.
	The changes in this draft are summarized in Appendix E.7.		The changes in this draft are summarized in Appendix E.8.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
	1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7		1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7
	1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7		1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7
	1.2.1. ABNF Extension: #rule . . . . . . . . . . . . . . . . 7		1.2.1. ABNF Extension: #rule . . . . . . . . . . . . . . . . 7
	1.2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . 8		1.2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . 8
	1.2.3. ABNF Rules defined in other Parts of the		1.2.3. ABNF Rules defined in other Parts of the
	Specification . . . . . . . . . . . . . . . . . . . . 9		Specification . . . . . . . . . . . . . . . . . . . . 9
	skipping to change at page 3, line 27		skipping to change at page 3, line 27
	2.1.2. https URI scheme . . . . . . . . . . . . . . . . . . . 11		2.1.2. https URI scheme . . . . . . . . . . . . . . . . . . . 11
	2.1.3. URI Comparison . . . . . . . . . . . . . . . . . . . . 11		2.1.3. URI Comparison . . . . . . . . . . . . . . . . . . . . 11
	2.1.4. Scheme aliases considered harmful . . . . . . . . . . 12		2.1.4. Scheme aliases considered harmful . . . . . . . . . . 12
	2.2. Overall Operation . . . . . . . . . . . . . . . . . . . . 12		2.2. Overall Operation . . . . . . . . . . . . . . . . . . . . 12
	2.3. Use of HTTP for proxy communication . . . . . . . . . . . 14		2.3. Use of HTTP for proxy communication . . . . . . . . . . . 14
	2.4. Interception of HTTP for access control . . . . . . . . . 14		2.4. Interception of HTTP for access control . . . . . . . . . 14
	2.5. Use of HTTP by other protocols . . . . . . . . . . . . . . 14		2.5. Use of HTTP by other protocols . . . . . . . . . . . . . . 14
	2.6. Use of HTTP by media type specification . . . . . . . . . 14		2.6. Use of HTTP by media type specification . . . . . . . . . 14
	3. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 14		3. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 14
	3.1. HTTP Version . . . . . . . . . . . . . . . . . . . . . . . 14		3.1. HTTP Version . . . . . . . . . . . . . . . . . . . . . . . 14
	3.2. Date/Time Formats . . . . . . . . . . . . . . . . . . . . 15		3.2. Date/Time Formats: Full Date . . . . . . . . . . . . . . . 15
	3.2.1. Full Date . . . . . . . . . . . . . . . . . . . . . . 15		3.3. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 18
	3.3. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 17		3.3.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 19
	3.3.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 18		3.4. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 21
	3.4. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 20		3.5. Quality Values . . . . . . . . . . . . . . . . . . . . . . 22
	3.5. Quality Values . . . . . . . . . . . . . . . . . . . . . . 21		4. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . . 22
	4. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . . 21		4.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 22
	4.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 21		4.2. Message Headers . . . . . . . . . . . . . . . . . . . . . 23
	4.2. Message Headers . . . . . . . . . . . . . . . . . . . . . 22		4.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 24
	4.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 23		4.4. Message Length . . . . . . . . . . . . . . . . . . . . . . 25
	4.4. Message Length . . . . . . . . . . . . . . . . . . . . . . 24		4.5. General Header Fields . . . . . . . . . . . . . . . . . . 27
	4.5. General Header Fields . . . . . . . . . . . . . . . . . . 26		5. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
	5. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
	5.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 27		5.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 27
	5.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 27		5.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 28
	5.1.2. request-target . . . . . . . . . . . . . . . . . . . . 27		5.1.2. request-target . . . . . . . . . . . . . . . . . . . . 28
	5.2. The Resource Identified by a Request . . . . . . . . . . . 29		5.2. The Resource Identified by a Request . . . . . . . . . . . 30
	6. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 30		6. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
	6.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 30		6.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 31
	6.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 30		6.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 31
	7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 31		7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 32
	7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 31		7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 32
	7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 31		7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 32
	7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 32		7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 32
	7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 33		7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 34
	7.1.4. Practical Considerations . . . . . . . . . . . . . . . 33		7.1.4. Practical Considerations . . . . . . . . . . . . . . . 34
	7.2. Message Transmission Requirements . . . . . . . . . . . . 34		7.2. Message Transmission Requirements . . . . . . . . . . . . 35
	7.2.1. Persistent Connections and Flow Control . . . . . . . 34		7.2.1. Persistent Connections and Flow Control . . . . . . . 35
	7.2.2. Monitoring Connections for Error Status Messages . . . 35		7.2.2. Monitoring Connections for Error Status Messages . . . 35
	7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 35		7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 36
	7.2.4. Client Behavior if Server Prematurely Closes		7.2.4. Client Behavior if Server Prematurely Closes
	Connection . . . . . . . . . . . . . . . . . . . . . . 37		Connection . . . . . . . . . . . . . . . . . . . . . . 38
	8. Header Field Definitions . . . . . . . . . . . . . . . . . . . 38		8. Header Field Definitions . . . . . . . . . . . . . . . . . . . 38
	8.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 38		8.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 39
	8.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 39		8.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 40
	8.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 39		8.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
	8.3.1. Clockless Origin Server Operation . . . . . . . . . . 41		8.3.1. Clockless Origin Server Operation . . . . . . . . . . 41
	8.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 41		8.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
	8.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42		8.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
	8.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 43		8.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 44
	8.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 43		8.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 44
	8.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 44		8.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 45
	8.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 45		8.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
	9.1. Message Header Registration . . . . . . . . . . . . . . . 47		9.1. Message Header Registration . . . . . . . . . . . . . . . 47
	9.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 47		9.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 48
	9.3. Internet Media Type Registrations . . . . . . . . . . . . 47		9.3. Internet Media Type Registrations . . . . . . . . . . . . 48
	9.3.1. Internet Media Type message/http . . . . . . . . . . . 47		9.3.1. Internet Media Type message/http . . . . . . . . . . . 48
	9.3.2. Internet Media Type application/http . . . . . . . . . 48		9.3.2. Internet Media Type application/http . . . . . . . . . 49
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 50		10. Security Considerations . . . . . . . . . . . . . . . . . . . 50
	10.1. Personal Information . . . . . . . . . . . . . . . . . . . 50		10.1. Personal Information . . . . . . . . . . . . . . . . . . . 51
	10.2. Abuse of Server Log Information . . . . . . . . . . . . . 50		10.2. Abuse of Server Log Information . . . . . . . . . . . . . 51
	10.3. Attacks Based On File and Path Names . . . . . . . . . . . 50		10.3. Attacks Based On File and Path Names . . . . . . . . . . . 51
	10.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 51		10.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 51
	10.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 51		10.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 52
	10.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 52		10.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 53
	11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52		11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53		12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54
	12.1. Normative References . . . . . . . . . . . . . . . . . . . 53		12.1. Normative References . . . . . . . . . . . . . . . . . . . 54
	12.2. Informative References . . . . . . . . . . . . . . . . . . 54		12.2. Informative References . . . . . . . . . . . . . . . . . . 55
	Appendix A. Tolerant Applications . . . . . . . . . . . . . . . . 56		Appendix A. Tolerant Applications . . . . . . . . . . . . . . . . 57
	Appendix B. Compatibility with Previous Versions . . . . . . . . 57		Appendix B. Compatibility with Previous Versions . . . . . . . . 58
	B.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 58		B.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 59
	B.1.1. Changes to Simplify Multi-homed Web Servers and		B.1.1. Changes to Simplify Multi-homed Web Servers and
	Conserve IP Addresses . . . . . . . . . . . . . . . . 58		Conserve IP Addresses . . . . . . . . . . . . . . . . 59
	B.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 59		B.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 59
	B.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 59		B.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 60
	B.4. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 60		B.4. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 61
	Appendix C. Terminology . . . . . . . . . . . . . . . . . . . . . 60		Appendix C. Terminology . . . . . . . . . . . . . . . . . . . . . 61
	Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 64		Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 64
	Appendix E. Change Log (to be removed by RFC Editor before		Appendix E. Change Log (to be removed by RFC Editor before
	publication) . . . . . . . . . . . . . . . . . . . . 68		publication) . . . . . . . . . . . . . . . . . . . . 69
	E.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 68		E.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 69
	E.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 68		E.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 69
	E.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 70		E.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 70
	E.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 71		E.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 71
	E.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 71		E.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 72
	E.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 72		E.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 72
	E.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 72		E.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 73
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73		E.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 74
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 77		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 78
	1. Introduction		1. Introduction
	The Hypertext Transfer Protocol (HTTP) is an application-level		The Hypertext Transfer Protocol (HTTP) is an application-level
	request/response protocol that uses extensible semantics and MIME-		request/response protocol that uses extensible semantics and MIME-
	like message payloads for flexible interaction with network-based		like message payloads for flexible interaction with network-based
	hypertext information systems. HTTP relies upon the Uniform Resource		hypertext information systems. HTTP relies upon the Uniform Resource
	Identifier (URI) standard [RFC3986] to indicate request targets and		Identifier (URI) standard [RFC3986] to indicate request targets and
	relationships between resources. Messages are passed in a format		relationships between resources. Messages are passed in a format
	similar to that used by Internet mail [RFC5322] and the Multipurpose		similar to that used by Internet mail [RFC5322] and the Multipurpose
	skipping to change at page 9, line 29		skipping to change at page 9, line 29
	tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*"		tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*"
	/ "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"		/ "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
	/ DIGIT / ALPHA		/ DIGIT / ALPHA
	token = 1*tchar		token = 1*tchar
	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 = *( OWS / %x21 / %x23-5B / %x5D-7E / obs-text )		qdtext = OWS / %x21 / %x23-5B / %x5D-7E / obs-text
			; OWS / <VCHAR except DQUOTE and "\"> / obs-text
	obs-text = %x80-FF		obs-text = %x80-FF
	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
	skipping to change at page 15, line 41		skipping to change at page 15, line 41
	Due to interoperability problems with HTTP/1.0 proxies discovered		Due to interoperability problems with HTTP/1.0 proxies discovered
	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. Date/Time Formats		3.2. Date/Time Formats: Full Date
	3.2.1. Full Date
	HTTP applications have historically allowed three different formats		HTTP applications have historically allowed three different formats
	for the representation of date/time stamps:		for the representation of date/time stamps:
	Sun, 06 Nov 1994 08:49:37 GMT ; RFC 1123		Sun, 06 Nov 1994 08:49:37 GMT ; RFC 1123
	Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format		Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format
	Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format		Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format
	The first format is preferred as an Internet standard and represents		The first format is preferred as an Internet standard and represents
	a fixed-length subset of that defined by [RFC1123]. The other		a fixed-length subset of that defined by [RFC1123]. The other
	formats are described here only for compatibility with obsolete		formats are described here only for compatibility with obsolete
	implementations. HTTP/1.1 clients and servers that parse the date		implementations. HTTP/1.1 clients and servers that parse the date
	value MUST accept all three formats (for compatibility with		value MUST accept all three formats (for compatibility with
	HTTP/1.0), though they MUST only generate the RFC 1123 format for		HTTP/1.0), though they MUST only generate the RFC 1123 format for
	representing HTTP-date values in header fields. See Appendix A for		representing HTTP-date values in header fields. See Appendix A for
	further information.		further information.
	Note: Recipients of date values are encouraged to be robust in
	accepting date values that may have been sent by non-HTTP
	applications, as is sometimes the case when retrieving or posting
	messages via proxies/gateways to SMTP or NNTP.
	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 whitespace beyond that specifically included as SP in the		additional whitespace beyond that specifically included as SP in the
	grammar.		grammar.
	HTTP-date = rfc1123-date / obsolete-date		HTTP-date = rfc1123-date / obs-date
	obsolete-date = rfc850-date / asctime-date
	rfc1123-date = wkday "," SP date1 SP time SP GMT		Preferred format:
	rfc850-date = weekday "," SP date2 SP time SP GMT
	asctime-date = wkday SP date3 SP time SP 4DIGIT		rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT
	date1 = 2DIGIT SP month SP 4DIGIT
	; day month year (e.g., 02 Jun 1982)		day-name = %x4D.6F.6E ; "Mon", case-sensitive
	date2 = 2DIGIT "-" month "-" 2DIGIT		/ %x54.75.65 ; "Tue", case-sensitive
	; day-month-year (e.g., 02-Jun-82)		/ %x57.65.64 ; "Wed", case-sensitive
	date3 = month SP ( 2DIGIT / ( SP 1DIGIT ))		/ %x54.68.75 ; "Thu", case-sensitive
	; month day (e.g., Jun 2)		/ %x46.72.69 ; "Fri", case-sensitive
	time = 2DIGIT ":" 2DIGIT ":" 2DIGIT		/ %x53.61.74 ; "Sat", case-sensitive
	; 00:00:00 - 23:59:59		/ %x53.75.6E ; "Sun", case-sensitive
	wkday = s-Mon / s-Tue / s-Wed
	/ s-Thu / s-Fri / s-Sat / s-Sun		date1 = day SP month SP year
	weekday = l-Mon / l-Tue / l-Wed		day = 2DIGIT
	/ l-Thu / l-Fri / l-Sat / l-Sun		month = %x4A.61.6E ; "Jan", case-sensitive
	month = s-Jan / s-Feb / s-Mar / s-Apr		/ %x46.65.62 ; "Feb", case-sensitive
	/ s-May / s-Jun / s-Jul / s-Aug		/ %x4D.61.72 ; "Mar", case-sensitive
	/ s-Sep / s-Oct / s-Nov / s-Dec		/ %x41.70.72 ; "Apr", case-sensitive
			/ %x4D.61.79 ; "May", case-sensitive
			/ %x4A.75.6E ; "Jun", case-sensitive
			/ %x4A.75.6C ; "Jul", case-sensitive
			/ %x41.75.67 ; "Aug", case-sensitive
			/ %x53.65.70 ; "Sep", case-sensitive
			/ %x4F.63.74 ; "Oct", case-sensitive
			/ %x4E.6F.76 ; "Nov", case-sensitive
			/ %x44.65.63 ; "Dec", case-sensitive
			year = 4DIGIT
	GMT = %x47.4D.54 ; "GMT", case-sensitive		GMT = %x47.4D.54 ; "GMT", case-sensitive
	s-Mon = %x4D.6F.6E ; "Mon", case-sensitive		time-of-day = hour ":" minute ":" second
	s-Tue = %x54.75.65 ; "Tue", case-sensitive		; 00:00:00 - 23:59:59
	s-Wed = %x57.65.64 ; "Wed", case-sensitive
	s-Thu = %x54.68.75 ; "Thu", case-sensitive
	s-Fri = %x46.72.69 ; "Fri", case-sensitive
	s-Sat = %x53.61.74 ; "Sat", case-sensitive
	s-Sun = %x53.75.6E ; "Sun", case-sensitive
	l-Mon = %x4D.6F.6E.64.61.79 ; "Monday", case-sensitive		hour = 2DIGIT
	l-Tue = %x54.75.65.73.64.61.79 ; "Tuesday", case-sensitive		minute = 2DIGIT
	l-Wed = %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive		second = 2DIGIT
	l-Thu = %x54.68.75.72.73.64.61.79 ; "Thursday", case-sensitive
	l-Fri = %x46.72.69.64.61.79 ; "Friday", case-sensitive
	l-Sat = %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive
	l-Sun = %x53.75.6E.64.61.79 ; "Sunday", case-sensitive
	s-Jan = %x4A.61.6E ; "Jan", case-sensitive		The semantics of day-name, day, month, year, and time-of-day are the
	s-Feb = %x46.65.62 ; "Feb", case-sensitive		same as those defined for the RFC 5322 constructs with the
	s-Mar = %x4D.61.72 ; "Mar", case-sensitive		corresponding name ([RFC5322], Section 3.3).
	s-Apr = %x41.70.72 ; "Apr", case-sensitive
	s-May = %x4D.61.79 ; "May", case-sensitive
	s-Jun = %x4A.75.6E ; "Jun", case-sensitive
	s-Jul = %x4A.75.6C ; "Jul", case-sensitive
	s-Aug = %x41.75.67 ; "Aug", case-sensitive
	s-Sep = %x53.65.70 ; "Sep", case-sensitive
	s-Oct = %x4F.63.74 ; "Oct", case-sensitive
	s-Nov = %x4E.6F.76 ; "Nov", case-sensitive
	s-Dec = %x44.65.63 ; "Dec", case-sensitive
	Note: HTTP requirements for the date/time stamp format apply only to		Obsolete formats:
	their usage within the protocol stream. Clients and servers are not
	required to use these formats for user presentation, request logging,		obs-date = rfc850-date / asctime-date
	etc.		rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT
			date2 = day "-" month "-" 2DIGIT
			; day-month-year (e.g., 02-Jun-82)
			day-name-l = %x4D.6F.6E.64.61.79 ; "Monday", case-sensitive
			/ %x54.75.65.73.64.61.79 ; "Tuesday", case-sensitive
			/ %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive
			/ %x54.68.75.72.73.64.61.79 ; "Thursday", case-sensitive
			/ %x46.72.69.64.61.79 ; "Friday", case-sensitive
			/ %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive
			/ %x53.75.6E.64.61.79 ; "Sunday", case-sensitive
			asctime-date = day-name SP date3 SP time-of-day SP year
			date3 = month SP ( 2DIGIT / ( SP 1DIGIT ))
			; month day (e.g., Jun 2)
			Note: Recipients of date values are encouraged to be robust in
			accepting date values that may have been sent by non-HTTP
			applications, as is sometimes the case when retrieving or posting
			messages via proxies/gateways to SMTP or NNTP.
			Note: HTTP requirements for the date/time stamp format apply only
			to their usage within the protocol stream. Clients and servers
			are not required to use these formats for user presentation,
			request logging, etc.
	3.3. Transfer Codings		3.3. 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 *( OWS ";" OWS parameter )		transfer-extension = token *( OWS ";" OWS transfer-parameter )
	Parameters are in the form of attribute/value pairs.		Parameters are in the form of attribute/value pairs.
	parameter = attribute BWS "=" BWS value		transfer-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
	applied more than once to a message-body. These rules allow the		applied more than once to a message-body. These rules allow the
	skipping to change at page 23, line 18		skipping to change at page 24, line 18
	whitespace with a single SP prior to interpreting the field value or		whitespace with a single SP prior to interpreting the field value or
	forwarding the message downstream.		forwarding the message downstream.
	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 = *( OWS / %x21-27 / %x2A-7E / obs-text )		ctext = OWS / %x21-27 / %x2A-5B / %x5D-7E / obs-text
			; OWS / <VCHAR except "(", ")", and "\"> / obs-text
	The order in which header fields with differing field names are		The order in which header fields with differing field names are
	received is not significant. However, it is "good practice" to send		received is not significant. However, it is "good practice" to send
	general-header fields first, followed by request-header or response-		general-header fields first, followed by request-header or response-
	header fields, and ending with the entity-header fields.		header fields, and ending with the entity-header fields.
	Multiple message-header fields with the same field-name MAY be		Multiple message-header fields with the same field-name MAY be
	present in a message if and only if the entire field-value for that		present in a message if and only if the entire field-value for that
	header field is defined as a comma-separated list [i.e., #(values)].		header field is defined as a comma-separated list [i.e., #(values)].
	It MUST be possible to combine the multiple header fields into one		It MUST be possible to combine the multiple header fields into one
	skipping to change at page 24, line 18		skipping to change at page 25, line 20
	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.3 places restrictions on		request/response chain. (However, Section 3.3 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.
	The presence of a message-body in a request is signaled by the		The presence of a message-body in a request is signaled by the
	inclusion of a Content-Length or Transfer-Encoding header field in		inclusion of a Content-Length or Transfer-Encoding header field in
	the request's message-headers. A message-body MUST NOT be included		the request's message-headers. When a request message contains both
	in a request if the specification of the request method (Section 2 of		a message-body of non-zero length and a method that does not define
	[Part2]) explicitly disallows an entity-body in requests. When a		any semantics for that request message-body, then an origin server
	request message contains both a message-body of non-zero length and a		SHOULD either ignore the message-body or respond with an appropriate
	method that does not define any semantics for that request message-		error message (e.g., 413). A proxy or gateway, when presented the
	body, then an origin server SHOULD either ignore the message-body or		same request, SHOULD either forward the request inbound with the
	respond with an appropriate error message (e.g., 413). A proxy or		message-body or ignore the message-body when determining a response.
	gateway, when presented the same request, SHOULD either forward the
	request inbound with the message-body or ignore the message-body when
	determining a response.
	For response messages, whether or not a message-body is included with		For response messages, whether or not a message-body is included with
	a message is dependent on both the request method and the response		a message is dependent on both the request method and the response
	status code (Section 6.1.1). All responses to the HEAD request		status code (Section 6.1.1). All responses to the HEAD request
	method MUST NOT include a message-body, even though the presence of		method MUST NOT include a message-body, even though the presence of
	entity-header fields might lead one to believe they do. All 1xx		entity-header fields might lead one to believe they do. All 1xx
	(informational), 204 (No Content), and 304 (Not Modified) responses		(informational), 204 (No Content), and 304 (Not Modified) responses
	MUST NOT include a message-body. All other responses do include a		MUST NOT include a message-body. All other responses do include a
	message-body, although it MAY be of zero length.		message-body, although it MAY be of zero length.
	skipping to change at page 25, line 13		skipping to change at page 26, line 10
	in the message.		in the message.
	2. If a Transfer-Encoding header field (Section 8.7) is present and		2. If a Transfer-Encoding header field (Section 8.7) is present and
	the "chunked" transfer-coding (Section 3.3) is used, the		the "chunked" transfer-coding (Section 3.3) is used, the
	transfer-length is defined by the use of this transfer-coding.		transfer-length is defined by the use of this transfer-coding.
	If a Transfer-Encoding header field is present and the "chunked"		If a Transfer-Encoding header field is present and the "chunked"
	transfer-coding is not present, the transfer-length is defined by		transfer-coding is not present, the transfer-length is defined by
	the sender closing the connection.		the sender closing the connection.
	3. If a Content-Length header field (Section 8.2) is present, its		3. If a Content-Length header field (Section 8.2) is present, its
	decimal value in OCTETs represents both the entity-length and the		value in OCTETs represents both the entity-length and the
	transfer-length. The Content-Length header field MUST NOT be		transfer-length. The Content-Length header field MUST NOT be
	sent if these two lengths are different (i.e., if a Transfer-		sent if these two lengths are different (i.e., if a Transfer-
	Encoding header field is present). If a message is received with		Encoding header field is present). If a message is received with
	both a Transfer-Encoding header field and a Content-Length header		both a Transfer-Encoding header field and a Content-Length header
	field, the latter MUST be ignored.		field, the latter MUST be ignored.
	4. If the message uses the media type "multipart/byteranges", and		4. If the message uses the media type "multipart/byteranges", and
	the transfer-length is not otherwise specified, then this self-		the transfer-length is not otherwise specified, then this self-
	delimiting media type defines the transfer-length. This media		delimiting media type defines the transfer-length. This media
	type MUST NOT be used unless the sender knows that the recipient		type MUST NOT be used unless the sender knows that the recipient
	skipping to change at page 31, line 23		skipping to change at page 32, line 18
	7.1.1. Purpose		7.1.1. Purpose
	Prior to persistent connections, a separate TCP connection was		Prior to persistent connections, a separate TCP connection was
	established to fetch each URL, increasing the load on HTTP servers		established to fetch each URL, increasing the load on HTTP servers
	and causing congestion on the Internet. The use of inline images and		and causing congestion on the Internet. The use of inline images and
	other associated data often require a client to make multiple		other associated data often require a client to make multiple
	requests of the same server in a short amount of time. Analysis of		requests of the same server in a short amount of time. Analysis of
	these performance problems and results from a prototype		these performance problems and results from a prototype
	implementation are available [Pad1995] [Spe]. Implementation		implementation are available [Pad1995] [Spe]. Implementation
	experience and measurements of actual HTTP/1.1 (RFC 2068)		experience and measurements of actual HTTP/1.1 implementations show
	implementations show good results [Nie1997]. Alternatives have also		good results [Nie1997]. Alternatives have also been explored, for
	been explored, for example, T/TCP [Tou1998].		example, T/TCP [Tou1998].
	Persistent HTTP connections have a number of advantages:		Persistent HTTP connections have a number of advantages:
	o By opening and closing fewer TCP connections, CPU time is saved in		o By opening and closing fewer TCP connections, CPU time is saved in
	routers and hosts (clients, servers, proxies, gateways, tunnels,		routers and hosts (clients, servers, proxies, gateways, tunnels,
	or caches), and memory used for TCP protocol control blocks can be		or caches), and memory used for TCP protocol control blocks can be
	saved in hosts.		saved in hosts.
	o HTTP requests and responses can be pipelined on a connection.		o HTTP requests and responses can be pipelined on a connection.
	Pipelining allows a client to make multiple requests without		Pipelining allows a client to make multiple requests without
	skipping to change at page 33, line 39		skipping to change at page 34, line 29
	It is especially important that proxies correctly implement the		It is especially important that proxies correctly implement the
	properties of the Connection header field as specified in		properties of the Connection header field as specified in
	Section 8.1.		Section 8.1.
	The proxy server MUST signal persistent connections separately with		The proxy server MUST signal persistent connections separately with
	its clients and the origin servers (or other proxy servers) that it		its clients and the origin servers (or other proxy servers) that it
	connects to. Each persistent connection applies to only one		connects to. Each persistent connection applies to only one
	transport link.		transport link.
	A proxy server MUST NOT establish a HTTP/1.1 persistent connection		A proxy server MUST NOT establish a HTTP/1.1 persistent connection
	with an HTTP/1.0 client (but see [RFC2068] for information and		with an HTTP/1.0 client (but see Section 19.7.1 of [RFC2068] for
	discussion of the problems with the Keep-Alive header implemented by		information and discussion of the problems with the Keep-Alive header
	many HTTP/1.0 clients).		implemented by many HTTP/1.0 clients).
	7.1.4. Practical Considerations		7.1.4. Practical Considerations
	Servers will usually have some time-out value beyond which they will		Servers will usually have some time-out value beyond which they will
	no longer maintain an inactive connection. Proxy servers might make		no longer maintain an inactive connection. Proxy servers might make
	this a higher value since it is likely that the client will be making		this a higher value since it is likely that the client will be making
	more connections through the same server. The use of persistent		more connections through the same server. The use of persistent
	connections places no requirements on the length (or existence) of		connections places no requirements on the length (or existence) of
	this time-out for either the client or the server.		this time-out for either the client or the server.
	skipping to change at page 39, line 20		skipping to change at page 40, line 10
	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 B.2.		See Appendix B.2.
	8.2. Content-Length		8.2. Content-Length
	The entity-header field "Content-Length" 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 number of OCTETs, sent to the recipient or, in the
	in the case of the HEAD method, the size of the entity-body that		case of the HEAD method, the size of the entity-body that would have
	would have been sent had the request been a GET.		been sent had the request been a GET.
	Content-Length = "Content-Length" ":" OWS 1*Content-Length-v		Content-Length = "Content-Length" ":" OWS 1*Content-Length-v
	Content-Length-v = 1*DIGIT		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
	skipping to change at page 39, line 51		skipping to change at page 40, line 41
	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 general-header field "Date" 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 [RFC5322]. 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.2.1; it MUST be sent in rfc1123-date format.		described in Section 3.2; it MUST be sent in rfc1123-date format.
	Date = "Date" ":" OWS Date-v		Date = "Date" ":" OWS Date-v
	Date-v = HTTP-date		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:
	skipping to change at page 53, line 45		skipping to change at page 54, line 37
	[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-06 (work in		Semantics", draft-ietf-httpbis-p2-semantics-07 (work in
	progress), March 2009.		progress), July 2009.
	[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-06		and Content Negotiation", draft-ietf-httpbis-p3-payload-07
	(work in progress), March 2009.		(work in progress), July 2009.
	[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-06 (work		Partial Responses", draft-ietf-httpbis-p5-range-07 (work
	in progress), March 2009.		in progress), July 2009.
	[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",		Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part
	draft-ietf-httpbis-p6-cache-06 (work in progress),		6: Caching", draft-ietf-httpbis-p6-cache-07 (work in
	March 2009.		progress), July 2009.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform		[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
	Resource Identifier (URI): Generic Syntax", RFC 3986,		Resource Identifier (URI): Generic Syntax", RFC 3986,
	STD 66, January 2005.		STD 66, January 2005.
	[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax		[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", STD 68, RFC 5234, January 2008.		Specifications: ABNF", STD 68, RFC 5234, January 2008.
	skipping to change at page 59, line 35		skipping to change at page 60, line 23
	However, talking to proxies is the most important use of persistent		However, talking to proxies is the most important use of persistent
	connections, so that prohibition is clearly unacceptable. Therefore,		connections, so that prohibition is clearly unacceptable. Therefore,
	we need some other mechanism for indicating a persistent connection		we need some other mechanism for indicating a persistent connection
	is desired, which is safe to use even when talking to an old proxy		is desired, which is safe to use even when talking to an old proxy
	that ignores Connection. Persistent connections are the default for		that ignores Connection. Persistent connections are the default for
	HTTP/1.1 messages; we introduce a new keyword (Connection: close) for		HTTP/1.1 messages; we introduce a new keyword (Connection: close) for
	declaring non-persistence. See Section 8.1.		declaring non-persistence. See Section 8.1.
	The original HTTP/1.0 form of persistent connections (the Connection:		The original HTTP/1.0 form of persistent connections (the Connection:
	Keep-Alive and Keep-Alive header) is documented in [RFC2068].		Keep-Alive and Keep-Alive header) is documented in Section 19.7.1 of
			[RFC2068].
	B.3. Changes from RFC 2068		B.3. Changes from RFC 2068
	This specification has been carefully audited to correct and		This specification has been carefully audited to correct and
	disambiguate key word usage; RFC 2068 had many problems in respect to		disambiguate key word usage; RFC 2068 had many problems in respect to
	the conventions laid out in [RFC2119].		the conventions laid out in [RFC2119].
	Transfer-coding and message lengths all interact in ways that		Transfer-coding and message lengths all interact in ways that
	required fixing exactly when chunked encoding is used (to allow for		required fixing exactly when chunked encoding is used (to allow for
	transfer encoding that may not be self delimiting); it was important		transfer encoding that may not be self delimiting); it was important
	skipping to change at page 64, line 20		skipping to change at page 65, line 9
	Chunked-Body = *chunk last-chunk trailer-part CRLF		Chunked-Body = *chunk last-chunk trailer-part CRLF
	Connection = "Connection:" OWS Connection-v		Connection = "Connection:" OWS Connection-v
	Connection-v = *( "," OWS ) connection-token *( OWS "," [ OWS		Connection-v = *( "," OWS ) connection-token *( OWS "," [ OWS
	connection-token ] )		connection-token ] )
	Content-Length = "Content-Length:" OWS 1*Content-Length-v		Content-Length = "Content-Length:" OWS 1*Content-Length-v
	Content-Length-v = 1*DIGIT		Content-Length-v = 1*DIGIT
	Date = "Date:" OWS Date-v		Date = "Date:" OWS Date-v
	Date-v = HTTP-date		Date-v = HTTP-date
	GMT = %x47.4D.54		GMT = %x47.4D.54 ; GMT
	HTTP-Prot-Name = %x48.54.54.50		HTTP-Prot-Name = %x48.54.54.50 ; HTTP
	HTTP-Version = HTTP-Prot-Name "/" 1*DIGIT "." 1*DIGIT		HTTP-Version = HTTP-Prot-Name "/" 1*DIGIT "." 1*DIGIT
	HTTP-date = rfc1123-date / obsolete-date		HTTP-date = rfc1123-date / obs-date
	HTTP-message = Request / Response		HTTP-message = Request / Response
	Host = "Host:" OWS Host-v		Host = "Host:" OWS Host-v
	Host-v = uri-host [ ":" port ]		Host-v = uri-host [ ":" port ]
	Method = token		Method = token
	OWS = *( [ obs-fold ] WSP )		OWS = *( [ obs-fold ] WSP )
	Pragma = <Pragma, defined in [Part6], Section 3.4>		Pragma = <Pragma, defined in [Part6], Section 3.4>
	skipping to change at page 65, line 4		skipping to change at page 65, line 42
	Status-Code = 3DIGIT		Status-Code = 3DIGIT
	Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF		Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
	TE = "TE:" OWS TE-v		TE = "TE:" OWS TE-v
	TE-v = [ ( "," / t-codings ) *( OWS "," [ OWS t-codings ] ) ]		TE-v = [ ( "," / t-codings ) *( OWS "," [ OWS t-codings ] ) ]
	Trailer = "Trailer:" OWS Trailer-v		Trailer = "Trailer:" OWS Trailer-v
	Trailer-v = *( "," OWS ) field-name *( OWS "," [ OWS field-name ] )		Trailer-v = *( "," OWS ) field-name *( OWS "," [ OWS field-name ] )
	Transfer-Encoding = "Transfer-Encoding:" OWS Transfer-Encoding-v		Transfer-Encoding = "Transfer-Encoding:" OWS Transfer-Encoding-v
	Transfer-Encoding-v = *( "," OWS ) transfer-coding *( OWS "," [ OWS		Transfer-Encoding-v = *( "," OWS ) transfer-coding *( OWS "," [ OWS
	transfer-coding ] )		transfer-coding ] )
	URI = <URI, defined in [RFC3986], Section 3>		URI = <URI, defined in [RFC3986], Section 3>
	URI-reference = <URI-reference, defined in [RFC3986], Section 4.1>		URI-reference = <URI-reference, defined in [RFC3986], Section 4.1>
	Upgrade = "Upgrade:" OWS Upgrade-v		Upgrade = "Upgrade:" OWS Upgrade-v
	Upgrade-v = *( "," OWS ) product *( OWS "," [ OWS product ] )		Upgrade-v = *( "," OWS ) product *( OWS "," [ OWS product ] )
	Via = "Via:" OWS Via-v		Via = "Via:" OWS Via-v
	Via-v = *( "," OWS ) received-protocol RWS received-by [ RWS comment		Via-v = *( "," OWS ) received-protocol RWS received-by [ RWS comment
	] *( OWS "," [ OWS received-protocol RWS received-by [ RWS comment ]		] *( OWS "," [ OWS received-protocol RWS received-by [ RWS comment ]
	] )		] )
	Warning = <Warning, defined in [Part6], Section 3.6>		Warning = <Warning, defined in [Part6], Section 3.6>
	absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3>		absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3>
	asctime-date = wkday SP date3 SP time SP 4DIGIT		asctime-date = day-name SP date3 SP time-of-day SP year
	attribute = token		attribute = token
	authority = <authority, defined in [RFC3986], Section 3.2>		authority = <authority, defined in [RFC3986], Section 3.2>
	chunk = chunk-size *WSP [ chunk-ext ] CRLF chunk-data CRLF		chunk = chunk-size *WSP [ chunk-ext ] CRLF chunk-data CRLF
	chunk-data = 1*OCTET		chunk-data = 1*OCTET
	chunk-ext = *( ";" *WSP chunk-ext-name [ "=" chunk-ext-val ] *WSP )		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-size = 1*HEXDIG		chunk-size = 1*HEXDIG
	comment = "(" *( ctext / quoted-pair / comment ) ")"		comment = "(" *( ctext / quoted-pair / comment ) ")"
	connection-token = token		connection-token = token
	ctext = *( OWS / %x21-27 / %x2A-7E / obs-text )		ctext = OWS / %x21-27 ; '!'-'''
			/ %x2A-5B ; '*'-'['
			/ %x5D-7E ; ']'-'~'
			/ obs-text
	date1 = 2DIGIT SP month SP 4DIGIT		date1 = day SP month SP year
	date2 = 2DIGIT "-" month "-" 2DIGIT		date2 = day "-" month "-" 2DIGIT
	date3 = month SP ( 2DIGIT / ( SP DIGIT ) )		date3 = month SP ( 2DIGIT / ( SP DIGIT ) )
			day = 2DIGIT
			day-name = %x4D.6F.6E ; Mon
			/ %x54.75.65 ; Tue
			/ %x57.65.64 ; Wed
			/ %x54.68.75 ; Thu
			/ %x46.72.69 ; Fri
			/ %x53.61.74 ; Sat
			/ %x53.75.6E ; Sun
			day-name-l = %x4D.6F.6E.64.61.79 ; Monday
			/ %x54.75.65.73.64.61.79 ; Tuesday
			/ %x57.65.64.6E.65.73.64.61.79 ; Wednesday
			/ %x54.68.75.72.73.64.61.79 ; Thursday
			/ %x46.72.69.64.61.79 ; Friday
			/ %x53.61.74.75.72.64.61.79 ; Saturday
			/ %x53.75.6E.64.61.79 ; Sunday
	entity-body = <entity-body, defined in [Part3], Section 3.2>		entity-body = <entity-body, defined in [Part3], Section 3.2>
	entity-header = <entity-header, defined in [Part3], Section 3.1>		entity-header = <entity-header, defined in [Part3], Section 3.1>
	field-content = *( WSP / VCHAR / obs-text )		field-content = *( WSP / VCHAR / obs-text )
	field-name = token		field-name = token
	field-value = *( field-content / OWS )		field-value = *( field-content / OWS )
	fragment = <fragment, defined in [RFC3986], Section 3.5>		fragment = <fragment, defined in [RFC3986], Section 3.5>
	general-header = Cache-Control / Connection / Date / Pragma / Trailer		general-header = Cache-Control / Connection / Date / Pragma / Trailer
	/ Transfer-Encoding / Upgrade / Via / Warning		/ Transfer-Encoding / Upgrade / Via / Warning
	generic-message = start-line *( message-header CRLF ) CRLF [		generic-message = start-line *( message-header CRLF ) CRLF [
	message-body ]		message-body ]
			hour = 2DIGIT
	http-URI = "http://" authority path-abempty [ "?" query ]		http-URI = "http://" authority path-abempty [ "?" query ]
	l-Fri = %x46.72.69.64.61.79
	l-Mon = %x4D.6F.6E.64.61.79
	l-Sat = %x53.61.74.75.72.64.61.79
	l-Sun = %x53.75.6E.64.61.79
	l-Thu = %x54.68.75.72.73.64.61.79
	l-Tue = %x54.75.65.73.64.61.79
	l-Wed = %x57.65.64.6E.65.73.64.61.79
	last-chunk = 1*"0" *WSP [ chunk-ext ] CRLF		last-chunk = 1*"0" *WSP [ chunk-ext ] CRLF
	message-body = entity-body /		message-body = entity-body /
	<entity-body encoded as per Transfer-Encoding>		<entity-body encoded as per Transfer-Encoding>
	message-header = field-name ":" OWS [ field-value ] OWS		message-header = field-name ":" OWS [ field-value ] OWS
	month = s-Jan / s-Feb / s-Mar / s-Apr / s-May / s-Jun / s-Jul / s-Aug		minute = 2DIGIT
	/ s-Sep / s-Oct / s-Nov / s-Dec		month = %x4A.61.6E ; Jan
			/ %x46.65.62 ; Feb
			/ %x4D.61.72 ; Mar
			/ %x41.70.72 ; Apr
			/ %x4D.61.79 ; May
			/ %x4A.75.6E ; Jun
			/ %x4A.75.6C ; Jul
			/ %x41.75.67 ; Aug
			/ %x53.65.70 ; Sep
			/ %x4F.63.74 ; Oct
			/ %x4E.6F.76 ; Nov
			/ %x44.65.63 ; Dec
			obs-date = rfc850-date / asctime-date
	obs-fold = CRLF		obs-fold = CRLF
	obs-text = %x80-FF		obs-text = %x80-FF
	obsolete-date = rfc850-date / asctime-date
	parameter = attribute BWS "=" BWS value
	partial-URI = relative-part [ "?" query ]		partial-URI = relative-part [ "?" query ]
	path-abempty = <path-abempty, defined in [RFC3986], Section 3.3>		path-abempty = <path-abempty, defined in [RFC3986], Section 3.3>
	path-absolute = <path-absolute, defined in [RFC3986], Section 3.3>		path-absolute = <path-absolute, defined in [RFC3986], Section 3.3>
	port = <port, defined in [RFC3986], Section 3.2.3>		port = <port, defined in [RFC3986], Section 3.2.3>
	product = token [ "/" product-version ]		product = token [ "/" product-version ]
	product-version = token		product-version = token
	protocol-name = token		protocol-name = token
	protocol-version = token		protocol-version = token
	pseudonym = token		pseudonym = token
	qdtext = *( OWS / "!" / %x23-5B / %x5D-7E / obs-text )		qdtext = OWS / "!" / %x23-5B ; '#'-'['
			/ %x5D-7E ; ']'-'~'
			/ obs-text
	query = <query, defined in [RFC3986], Section 3.4>		query = <query, defined in [RFC3986], Section 3.4>
	quoted-pair = "\" quoted-text		quoted-pair = "\" quoted-text
	quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE		quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
	quoted-text = %x01-09 / %x0B-0C / %x0E-FF		quoted-text = %x01-09 / %x0B-0C / %x0E-FF
	qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )		qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
	received-by = ( uri-host [ ":" port ] ) / pseudonym		received-by = ( uri-host [ ":" port ] ) / pseudonym
	received-protocol = [ protocol-name "/" ] protocol-version		received-protocol = [ protocol-name "/" ] protocol-version
	relative-part = <relative-part, defined in [RFC3986], Section 4.2>		relative-part = <relative-part, defined in [RFC3986], Section 4.2>
	request-header = <request-header, defined in [Part2], Section 3>		request-header = <request-header, defined in [Part2], Section 3>
	request-target = "*" / absolute-URI / ( path-absolute [ "?" query ] )		request-target = "*" / absolute-URI / ( path-absolute [ "?" query ] )
	/ authority		/ authority
	response-header = <response-header, defined in [Part2], Section 5>		response-header = <response-header, defined in [Part2], Section 5>
	rfc1123-date = wkday "," SP date1 SP time SP GMT		rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT
	rfc850-date = weekday "," SP date2 SP time SP GMT		rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT
	s-Apr = %x41.70.72		second = 2DIGIT
	s-Aug = %x41.75.67
	s-Dec = %x44.65.63
	s-Feb = %x46.65.62
	s-Fri = %x46.72.69
	s-Jan = %x4A.61.6E
	s-Jul = %x4A.75.6C
	s-Jun = %x4A.75.6E
	s-Mar = %x4D.61.72
	s-May = %x4D.61.79
	s-Mon = %x4D.6F.6E
	s-Nov = %x4E.6F.76
	s-Oct = %x4F.63.74
	s-Sat = %x53.61.74
	s-Sep = %x53.65.70
	s-Sun = %x53.75.6E
	s-Thu = %x54.68.75
	s-Tue = %x54.75.65
	s-Wed = %x57.65.64
	start-line = Request-Line / Status-Line		start-line = Request-Line / Status-Line
	t-codings = "trailers" / ( transfer-extension [ te-params ] )		t-codings = "trailers" / ( transfer-extension [ te-params ] )
	tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." /		tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." /
	"^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA		"^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA
	te-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ]		te-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ]
	te-params = OWS ";" OWS "q=" qvalue *te-ext		te-params = OWS ";" OWS "q=" qvalue *te-ext
	time = 2DIGIT ":" 2DIGIT ":" 2DIGIT		time-of-day = hour ":" minute ":" second
	token = 1*tchar		token = 1*tchar
	trailer-part = *( entity-header CRLF )		trailer-part = *( entity-header CRLF )
	transfer-coding = "chunked" / transfer-extension		transfer-coding = "chunked" / transfer-extension
	transfer-extension = token *( OWS ";" OWS parameter )		transfer-extension = token *( OWS ";" OWS transfer-parameter )
			transfer-parameter = attribute BWS "=" BWS value
	uri-host = <host, defined in [RFC3986], Section 3.2.2>		uri-host = <host, defined in [RFC3986], Section 3.2.2>
	value = token / quoted-string		value = token / quoted-string
	weekday = l-Mon / l-Tue / l-Wed / l-Thu / l-Fri / l-Sat / l-Sun		year = 4DIGIT
	wkday = s-Mon / s-Tue / s-Wed / s-Thu / s-Fri / s-Sat / s-Sun
	ABNF diagnostics:		ABNF diagnostics:
	; Chunked-Body defined but not used		; Chunked-Body defined but not used
	; Content-Length defined but not used		; Content-Length defined but not used
	; HTTP-message defined but not used		; HTTP-message defined but not used
	; Host defined but not used		; Host defined but not used
	; TE defined but not used		; TE defined but not used
	; URI defined but not used		; URI defined but not used
	; URI-reference defined but not used		; URI-reference defined but not used
	; fragment defined but not used		; fragment defined but not used
	skipping to change at page 73, line 33		skipping to change at page 74, line 11
	o Add appendix containing collected and expanded ABNF.		o Add appendix containing collected and expanded ABNF.
	Other changes:		Other changes:
	o Rewrite introduction; add mostly new Architecture Section.		o Rewrite introduction; add mostly new Architecture Section.
	o Move definition of quality values from Part 3 into Part 1; make TE		o Move definition of quality values from Part 3 into Part 1; make TE
	request header grammar independent of accept-params (defined in		request header grammar independent of accept-params (defined in
	Part 3).		Part 3).
			E.8. Since draft-ietf-httpbis-p1-messaging-06
			Closed issues:
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/161>: "base for
			numeric protocol elements"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/162>: "comment ABNF"
			Partly resolved issues:
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/88>: "205 Bodies"
			(took out language that implied that there may be methods for
			which a request body MUST NOT be included)
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/163>: "editorial
			improvements around HTTP-date"
	Index		Index
	A		A
	application/http Media Type 48		application/http Media Type 49
	C		C
	cache 61		cache 61
	cacheable 61		cacheable 62
	client 61		client 62
	connection 61		connection 62
	Connection header 38		Connection header 39
	content negotiation 61		content negotiation 62
	Content-Length header 39		Content-Length header 40
	D		D
	Date header 39		Date header 40
	downstream 63		downstream 64
	E		E
	entity 61		entity 62
	G		G
	gateway 61		gateway 62
	Grammar		Grammar
	absolute-URI 10		absolute-URI 10
	ALPHA 7		ALPHA 7
	asctime-date 16		asctime-date 18
	attribute 17		attribute 18
	authority 10		authority 10
	BWS 9		BWS 9
	chunk 19		chunk 20
	chunk-data 19		chunk-data 20
	chunk-ext 19		chunk-ext 20
	chunk-ext-name 19		chunk-ext-name 20
	chunk-ext-val 19		chunk-ext-val 20
	chunk-size 19		chunk-size 20
	Chunked-Body 19		Chunked-Body 20
	comment 23		comment 24
	Connection 38		Connection 39
	connection-token 38		connection-token 39
	Connection-v 38		Connection-v 39
	Content-Length 39		Content-Length 40
	Content-Length-v 39		Content-Length-v 40
	CR 7		CR 7
	CRLF 7		CRLF 7
	ctext 23		ctext 24
	CTL 7		CTL 7
	Date 40		Date 40
	Date-v 40		Date-v 40
	date1 16		date1 17
	date2 16		date2 18
	date3 16		date3 18
			day 17
			day-name 17
			day-name-l 17
	DIGIT 7		DIGIT 7
	DQUOTE 7		DQUOTE 7
	extension-code 31		extension-code 31
	extension-method 27		extension-method 28
	field-content 22		field-content 23
	field-name 22		field-name 23
	field-value 22		field-value 23
	general-header 26		general-header 27
	generic-message 21		generic-message 22
			GMT 17
	HEXDIG 7		HEXDIG 7
	Host 41		Host 42
	Host-v 41		Host-v 42
			hour 17
	HTTP-date 16		HTTP-date 16
	HTTP-message 21		HTTP-message 22
	HTTP-Prot-Name 14		HTTP-Prot-Name 14
	http-URI 11		http-URI 11
	HTTP-Version 14		HTTP-Version 14
	last-chunk 19		last-chunk 20
	LF 7		LF 7
	message-body 23		message-body 25
	message-header 22		message-header 23
	Method 27		Method 28
	month 16		minute 17
			month 17
			obs-date 17
	obs-text 9		obs-text 9
	obsolete-date 16
	OCTET 7		OCTET 7
	OWS 9		OWS 9
	parameter 17
	path-absolute 10		path-absolute 10
	port 10		port 10
	product 20		product 21
	product-version 20		product-version 21
	protocol-name 45		protocol-name 46
	protocol-version 45		protocol-version 46
	pseudonym 45		pseudonym 46
	qdtext 9		qdtext 9
	query 10		query 10
	quoted-pair 9		quoted-pair 9
	quoted-string 9		quoted-string 9
	quoted-text 9		quoted-text 9
	qvalue 21		qvalue 22
	Reason-Phrase 31		Reason-Phrase 31
	received-by 45		received-by 46
	received-protocol 45		received-protocol 46
	Request 26		Request 27
	Request-Line 27		Request-Line 28
	request-target 27		request-target 28
	Response 30		Response 31
	rfc850-date 16		rfc850-date 18
	rfc1123-date 16		rfc1123-date 17
	RWS 9		RWS 9
			second 17
	SP 7		SP 7
	start-line 21		start-line 22
	Status-Code 31		Status-Code 31
	Status-Line 30		Status-Line 31
	t-codings 42		t-codings 42
	tchar 9		tchar 9
	TE 42		TE 42
	te-ext 42		te-ext 42
	te-params 42		te-params 42
	TE-v 42		TE-v 42
	time 16		time-of-day 17
	token 9		token 9
	Trailer 43		Trailer 44
	trailer-part 19		trailer-part 20
	Trailer-v 43		Trailer-v 44
	transfer-coding 17		transfer-coding 18
	Transfer-Encoding 44		Transfer-Encoding 44
	Transfer-Encoding-v 44		Transfer-Encoding-v 44
	transfer-extension 17		transfer-extension 18
	Upgrade 44		transfer-parameter 18
	Upgrade-v 44		Upgrade 45
			Upgrade-v 45
	uri-host 10		uri-host 10
	URI-reference 10		URI-reference 10
	value 17		value 18
	VCHAR 7		VCHAR 7
	Via 45		Via 46
	Via-v 45		Via-v 46
	weekday 16
	wkday 16
	WSP 7		WSP 7
			year 17
	H		H
	Headers		Headers
	Connection 38		Connection 39
	Content-Length 39		Content-Length 40
	Date 39		Date 40
	Host 41		Host 42
	TE 42		TE 42
	Trailer 43		Trailer 44
	Transfer-Encoding 43		Transfer-Encoding 44
	Upgrade 44		Upgrade 45
	Via 45		Via 46
	Host header 41		Host header 42
	http URI scheme 11		http URI scheme 11
	https URI scheme 11		https URI scheme 11
	I		I
	inbound 62		inbound 62
	M		M
	Media Type		Media Type
	application/http 48		application/http 49
	message/http 47		message/http 48
	message 62		message 63
	message/http Media Type 47		message/http Media Type 48
	O		O
	origin server 62		origin server 63
	outbound 62		outbound 62
	P		P
	proxy 62		proxy 63
	R		R
	representation 63		representation 63
	request 62		request 63
	resource 62		resource 63
	response 62		response 63
	S		S
	server 63		server 64
	T		T
	TE header 42		TE header 42
	Trailer header 43		Trailer header 44
	Transfer-Encoding header 43		Transfer-Encoding header 44
	tunnel 63		tunnel 64
	U		U
	Upgrade header 44		Upgrade header 45
	upstream 63		upstream 64
	URI scheme		URI scheme
	http 11		http 11
	https 11		https 11
	user agent 63		user agent 64
	V		V
	variant 63		variant 64
	Via header 45		Via header 46
	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. 109 change blocks.
	308 lines changed or deleted		350 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/