draft-ietf-httpbis-p3-payload-12.txt		draft-ietf-httpbis-p3-payload-13.txt
	HTTPbis Working Group R. Fielding, Ed.		HTTPbis Working Group R. Fielding, Ed.
	Internet-Draft Day Software		Internet-Draft Adobe
	Obsoletes: 2616 (if approved) J. Gettys		Obsoletes: 2616 (if approved) J. Gettys
	Intended status: Standards Track Alcatel-Lucent		Intended status: Standards Track Alcatel-Lucent
	Expires: April 28, 2011 J. Mogul		Expires: September 15, 2011 J. Mogul
	HP		HP
	H. Frystyk		H. Frystyk
	Microsoft		Microsoft
	L. Masinter		L. Masinter
	Adobe Systems		Adobe
	P. Leach		P. Leach
	Microsoft		Microsoft
	T. Berners-Lee		T. Berners-Lee
	W3C/MIT		W3C/MIT
	Y. Lafon, Ed.		Y. Lafon, Ed.
	W3C		W3C
	J. Reschke, Ed.		J. Reschke, Ed.
	greenbytes		greenbytes
	October 25, 2010		March 14, 2011
	HTTP/1.1, part 3: Message Payload and Content Negotiation		HTTP/1.1, part 3: Message Payload and Content Negotiation
	draft-ietf-httpbis-p3-payload-12		draft-ietf-httpbis-p3-payload-13
	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 3 of the		information initiative since 1990. This document is Part 3 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 3 defines		"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 3 defines
	HTTP message content, metadata, and content negotiation.		HTTP message content, metadata, and content negotiation.
	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/3> and related		at <http://tools.ietf.org/wg/httpbis/trac/report/3> and related
	documents (including fancy diffs) can be found at		documents (including fancy diffs) can be found at
	<http://tools.ietf.org/wg/httpbis/>.		<http://tools.ietf.org/wg/httpbis/>.
	The changes in this draft are summarized in Appendix E.13.		The changes in this draft are summarized in Appendix E.14.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on April 28, 2011.		This Internet-Draft will expire on September 15, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2011 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 3, line 6		skipping to change at page 3, line 6
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
	1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5		1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5
	1.3. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6		1.3. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6
	1.3.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 6		1.3.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 6
	1.3.2. ABNF Rules defined in other Parts of the		1.3.2. ABNF Rules defined in other Parts of the
	Specification . . . . . . . . . . . . . . . . . . . . 6		Specification . . . . . . . . . . . . . . . . . . . . 6
	2. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 6		2. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 6
	2.1. Character Sets . . . . . . . . . . . . . . . . . . . . . . 6		2.1. Character Encodings (charset) . . . . . . . . . . . . . . 6
	2.1.1. Missing Charset . . . . . . . . . . . . . . . . . . . 7		2.1.1. Missing Charset . . . . . . . . . . . . . . . . . . . 7
	2.2. Content Codings . . . . . . . . . . . . . . . . . . . . . 8		2.2. Content Codings . . . . . . . . . . . . . . . . . . . . . 7
	2.2.1. Content Coding Registry . . . . . . . . . . . . . . . 9		2.2.1. Content Coding Registry . . . . . . . . . . . . . . . 8
	2.3. Media Types . . . . . . . . . . . . . . . . . . . . . . . 9		2.3. Media Types . . . . . . . . . . . . . . . . . . . . . . . 8
	2.3.1. Canonicalization and Text Defaults . . . . . . . . . . 10		2.3.1. Canonicalization and Text Defaults . . . . . . . . . . 9
	2.3.2. Multipart Types . . . . . . . . . . . . . . . . . . . 11		2.3.2. Multipart Types . . . . . . . . . . . . . . . . . . . 10
	2.4. Language Tags . . . . . . . . . . . . . . . . . . . . . . 11		2.4. Language Tags . . . . . . . . . . . . . . . . . . . . . . 10
	3. Payload . . . . . . . . . . . . . . . . . . . . . . . . . . . 12		3. Payload . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	3.1. Payload Header Fields . . . . . . . . . . . . . . . . . . 12		3.1. Payload Header Fields . . . . . . . . . . . . . . . . . . 11
	3.2. Payload Body . . . . . . . . . . . . . . . . . . . . . . . 12		3.2. Payload Body . . . . . . . . . . . . . . . . . . . . . . . 12
	4. Representation . . . . . . . . . . . . . . . . . . . . . . . . 12		4. Representation . . . . . . . . . . . . . . . . . . . . . . . . 12
	4.1. Representation Header Fields . . . . . . . . . . . . . . . 13		4.1. Representation Header Fields . . . . . . . . . . . . . . . 12
	4.2. Representation Data . . . . . . . . . . . . . . . . . . . 13		4.2. Representation Data . . . . . . . . . . . . . . . . . . . 13
	5. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 14		5. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 14
	5.1. Server-driven Negotiation . . . . . . . . . . . . . . . . 15		5.1. Server-driven Negotiation . . . . . . . . . . . . . . . . 15
	5.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . . 16		5.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . . 16
	6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 17		6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 16
	6.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . . 17		6.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	6.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . . 19		6.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . . 19
	6.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 20		6.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 19
	6.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 21		6.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 21
	6.5. Content-Encoding . . . . . . . . . . . . . . . . . . . . . 22		6.5. Content-Encoding . . . . . . . . . . . . . . . . . . . . . 22
	6.6. Content-Language . . . . . . . . . . . . . . . . . . . . . 23		6.6. Content-Language . . . . . . . . . . . . . . . . . . . . . 23
	6.7. Content-Location . . . . . . . . . . . . . . . . . . . . . 24		6.7. Content-Location . . . . . . . . . . . . . . . . . . . . . 24
	6.8. Content-MD5 . . . . . . . . . . . . . . . . . . . . . . . 25		6.8. Content-MD5 . . . . . . . . . . . . . . . . . . . . . . . 25
	6.9. Content-Type . . . . . . . . . . . . . . . . . . . . . . . 27		6.9. Content-Type . . . . . . . . . . . . . . . . . . . . . . . 26
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
	7.1. Header Field Registration . . . . . . . . . . . . . . . . 27		7.1. Header Field Registration . . . . . . . . . . . . . . . . 27
	7.2. Content Coding Registry . . . . . . . . . . . . . . . . . 27		7.2. Content Coding Registry . . . . . . . . . . . . . . . . . 27
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 28		8. Security Considerations . . . . . . . . . . . . . . . . . . . 28
	8.1. Privacy Issues Connected to Accept Header Fields . . . . . 28		8.1. Privacy Issues Connected to Accept Header Fields . . . . . 28
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 29		10.1. Normative References . . . . . . . . . . . . . . . . . . . 29
	10.2. Informative References . . . . . . . . . . . . . . . . . . 31		10.2. Informative References . . . . . . . . . . . . . . . . . . 31
	Appendix A. Differences between HTTP and MIME . . . . . . . . . . 32		Appendix A. Differences between HTTP and MIME . . . . . . . . . . 32
	A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 33		A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 32
	A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 33		A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 33
	A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 33		A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 33
	A.4. Introduction of Content-Encoding . . . . . . . . . . . . . 34		A.4. Introduction of Content-Encoding . . . . . . . . . . . . . 34
	A.5. No Content-Transfer-Encoding . . . . . . . . . . . . . . . 34		A.5. No Content-Transfer-Encoding . . . . . . . . . . . . . . . 34
	A.6. Introduction of Transfer-Encoding . . . . . . . . . . . . 34		A.6. Introduction of Transfer-Encoding . . . . . . . . . . . . 34
	A.7. MHTML and Line Length Limitations . . . . . . . . . . . . 34		A.7. MHTML and Line Length Limitations . . . . . . . . . . . . 34
	Appendix B. Additional Features . . . . . . . . . . . . . . . . . 35		Appendix B. Additional Features . . . . . . . . . . . . . . . . . 34
	Appendix C. Changes from RFC 2616 . . . . . . . . . . . . . . . . 35		Appendix C. Changes from RFC 2616 . . . . . . . . . . . . . . . . 35
	Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 35		Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 35
	Appendix E. Change Log (to be removed by RFC Editor before		Appendix E. Change Log (to be removed by RFC Editor before
	publication) . . . . . . . . . . . . . . . . . . . . 37		publication) . . . . . . . . . . . . . . . . . . . . 37
	E.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 37		E.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 37
	E.2. Since draft-ietf-httpbis-p3-payload-00 . . . . . . . . . . 37		E.2. Since draft-ietf-httpbis-p3-payload-00 . . . . . . . . . . 37
	E.3. Since draft-ietf-httpbis-p3-payload-01 . . . . . . . . . . 38		E.3. Since draft-ietf-httpbis-p3-payload-01 . . . . . . . . . . 38
	E.4. Since draft-ietf-httpbis-p3-payload-02 . . . . . . . . . . 38		E.4. Since draft-ietf-httpbis-p3-payload-02 . . . . . . . . . . 38
	E.5. Since draft-ietf-httpbis-p3-payload-03 . . . . . . . . . . 38		E.5. Since draft-ietf-httpbis-p3-payload-03 . . . . . . . . . . 38
	E.6. Since draft-ietf-httpbis-p3-payload-04 . . . . . . . . . . 39		E.6. Since draft-ietf-httpbis-p3-payload-04 . . . . . . . . . . 39
	E.7. Since draft-ietf-httpbis-p3-payload-05 . . . . . . . . . . 39		E.7. Since draft-ietf-httpbis-p3-payload-05 . . . . . . . . . . 39
	E.8. Since draft-ietf-httpbis-p3-payload-06 . . . . . . . . . . 40		E.8. Since draft-ietf-httpbis-p3-payload-06 . . . . . . . . . . 39
	E.9. Since draft-ietf-httpbis-p3-payload-07 . . . . . . . . . . 40		E.9. Since draft-ietf-httpbis-p3-payload-07 . . . . . . . . . . 40
	E.10. Since draft-ietf-httpbis-p3-payload-08 . . . . . . . . . . 40		E.10. Since draft-ietf-httpbis-p3-payload-08 . . . . . . . . . . 40
	E.11. Since draft-ietf-httpbis-p3-payload-09 . . . . . . . . . . 41		E.11. Since draft-ietf-httpbis-p3-payload-09 . . . . . . . . . . 41
	E.12. Since draft-ietf-httpbis-p3-payload-10 . . . . . . . . . . 41		E.12. Since draft-ietf-httpbis-p3-payload-10 . . . . . . . . . . 41
	E.13. Since draft-ietf-httpbis-p3-payload-11 . . . . . . . . . . 42		E.13. Since draft-ietf-httpbis-p3-payload-11 . . . . . . . . . . 42
			E.14. Since draft-ietf-httpbis-p3-payload-12 . . . . . . . . . . 42
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
	1. Introduction		1. Introduction
	This document defines HTTP/1.1 message payloads (a.k.a., content),		This document defines HTTP/1.1 message payloads (a.k.a., content),
	the associated metadata header fields that define how the payload is		the associated metadata header fields that define how the payload is
	intended to be interpreted by a recipient, the request header fields		intended to be interpreted by a recipient, the request header fields
	that might influence content selection, and the various selection		that might influence content selection, and the various selection
	algorithms that are collectively referred to as HTTP content		algorithms that are collectively referred to as HTTP content
	negotiation.		negotiation.
	skipping to change at page 6, line 32		skipping to change at page 6, line 32
	token = <token, defined in [Part1], Section 1.2.2>		token = <token, defined in [Part1], Section 1.2.2>
	word = <word, defined in [Part1], Section 1.2.2>		word = <word, defined in [Part1], Section 1.2.2>
	OWS = <OWS, defined in [Part1], Section 1.2.2>		OWS = <OWS, defined in [Part1], Section 1.2.2>
	1.3.2. ABNF Rules defined in other Parts of the Specification		1.3.2. 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:
	absolute-URI = <absolute-URI, defined in [Part1], Section 2.6>		absolute-URI = <absolute-URI, defined in [Part1], Section 2.6>
	Content-Length = <Content-Length, defined in [Part1], Section 9.2>
	partial-URI = <partial-URI, defined in [Part1], Section 2.6>		partial-URI = <partial-URI, defined in [Part1], Section 2.6>
	qvalue = <qvalue, defined in [Part1], Section 6.4>		qvalue = <qvalue, defined in [Part1], Section 6.4>
	Last-Modified = <Last-Modified, defined in [Part4], Section 6.6>
	Content-Range = <Content-Range, defined in [Part5], Section 5.2>
	Expires = <Expires, defined in [Part6], Section 3.3>
	2. Protocol Parameters		2. Protocol Parameters
	2.1. Character Sets		2.1. Character Encodings (charset)
	HTTP uses the same definition of the term "character set" as that
	described for MIME:
	The term "character set" is used in this document to refer to a
	method used with one or more tables to convert a sequence of octets
	into a sequence of characters. Note that unconditional conversion in
	the other direction is not required, in that not all characters might
	be available in a given character set and a character set might
	provide more than one sequence of octets to represent a particular
	character. This definition is intended to allow various kinds of
	character encoding, from simple single-table mappings such as US-
	ASCII to complex table switching methods such as those that use ISO-
	2022's techniques. However, the definition associated with a MIME
	character set name MUST fully specify the mapping to be performed
	from octets to characters. In particular, use of external profiling
	information to determine the exact mapping is not permitted.
	Note: This use of the term "character set" is more commonly		HTTP uses charset names to indicate the character encoding of a
	referred to as a "character encoding". However, since HTTP and		textual representation.
	MIME share the same registry, it is important that the terminology
	also be shared.
	HTTP character sets are identified by case-insensitive tokens. The		A character encoding is identified by a case-insensitive token. The
	complete set of tokens is defined by the IANA Character Set registry		complete set of tokens is defined by the IANA Character Set registry
	(<http://www.iana.org/assignments/character-sets>).		(<http://www.iana.org/assignments/character-sets>).
	charset = token		charset = token
	Although HTTP allows an arbitrary token to be used as a charset		Although HTTP allows an arbitrary token to be used as a charset
	value, any token that has a predefined value within the IANA		value, any token that has a predefined value within the IANA
	Character Set registry MUST represent the character set defined by		Character Set registry MUST represent the character encoding defined
	that registry. Applications SHOULD limit their use of character sets		by that registry. Applications SHOULD limit their use of character
	to those defined by the IANA registry.		encodings to those defined within the IANA registry.
	HTTP uses charset in two contexts: within an Accept-Charset request		HTTP uses charset in two contexts: within an Accept-Charset request
	header field (in which the charset value is an unquoted token) and as		header field (in which the charset value is an unquoted token) and as
	the value of a parameter in a Content-Type header field (within a		the value of a parameter in a Content-Type header field (within a
	request or response), in which case the parameter value of the		request or response), in which case the parameter value of the
	charset parameter can be quoted.		charset parameter can be quoted.
	Implementors need to be aware of IETF character set requirements		Implementors need to be aware of IETF character set requirements
	[RFC3629] [RFC2277].		[RFC3629] [RFC2277].
	skipping to change at page 9, line 40		skipping to change at page 9, line 9
	2.3. Media Types		2.3. Media Types
	HTTP uses Internet Media Types [RFC2046] in the Content-Type		HTTP uses Internet Media Types [RFC2046] in the Content-Type
	(Section 6.9) and Accept (Section 6.1) header fields in order to		(Section 6.9) and Accept (Section 6.1) header fields in order to
	provide open and extensible data typing and type negotiation.		provide open and extensible data typing and type negotiation.
	media-type = type "/" subtype *( OWS ";" OWS parameter )		media-type = type "/" subtype *( OWS ";" OWS parameter )
	type = token		type = token
	subtype = token		subtype = token
	Parameters MAY follow the type/subtype in the form of attribute/value		The type/subtype MAY be followed by parameters in the form of
	pairs.		attribute/value pairs.
	parameter = attribute "=" value		parameter = attribute "=" value
	attribute = token		attribute = token
	value = word		value = word
	The type, subtype, and parameter attribute names are case-		The type, subtype, and parameter attribute names are case-
	insensitive. Parameter values might or might not be case-sensitive,		insensitive. Parameter values might or might not be case-sensitive,
	depending on the semantics of the parameter name. The presence or		depending on the semantics of the parameter name. The presence or
	absence of a parameter might be significant to the processing of a		absence of a parameter might be significant to the processing of a
	media-type, depending on its definition within the media type		media-type, depending on its definition within the media type
	skipping to change at page 12, line 28		skipping to change at page 11, line 44
	header fields (e.g., responses to HEAD) or only some part(s) of the		header fields (e.g., responses to HEAD) or only some part(s) of the
	representation (e.g., the 206 status code).		representation (e.g., the 206 status code).
	3.1. Payload Header Fields		3.1. Payload Header Fields
	HTTP header fields that specifically define the payload, rather than		HTTP header fields that specifically define the payload, rather than
	the associated representation, are referred to as "payload header		the associated representation, are referred to as "payload header
	fields". The following payload header fields are defined by		fields". The following payload header fields are defined by
	HTTP/1.1:		HTTP/1.1:
	Content-Length ; [Part1], Section 9.2		+-------------------+------------------------+
	Content-MD5 ; Section 6.8		| Header Field Name | Defined in... |
	Content-Range ; [Part5], Section 5.2		+-------------------+------------------------+
			| Content-Length | Section 9.2 of [Part1] |
			| Content-MD5 | Section 6.8 |
			| Content-Range | Section 5.2 of [Part5] |
			+-------------------+------------------------+
	3.2. Payload Body		3.2. Payload Body
	A payload body is only present in a message when a message-body is		A payload body is only present in a message when a message-body is
	present, as described in Section 3.3 of [Part1]. The payload body is		present, as described in Section 3.3 of [Part1]. The payload body is
	obtained from the message-body by decoding any Transfer-Encoding that		obtained from the message-body by decoding any Transfer-Encoding that
	might have been applied to ensure safe and proper transfer of the		might have been applied to ensure safe and proper transfer of the
	message.		message.
	4. Representation		4. Representation
	skipping to change at page 13, line 24		skipping to change at page 13, line 5
	4.1. Representation Header Fields		4.1. Representation Header Fields
	Representation header fields define metadata about the representation		Representation header fields define metadata about the representation
	data enclosed in the message-body or, if no message-body is present,		data enclosed in the message-body or, if no message-body is present,
	about the representation that would have been transferred in a 200		about the representation that would have been transferred in a 200
	response to a simultaneous GET request with the same effective		response to a simultaneous GET request with the same effective
	request URI.		request URI.
	The following header fields are defined as representation metadata:		The following header fields are defined as representation metadata:
	Content-Encoding ; Section 6.5		+-------------------+------------------------+
	Content-Language ; Section 6.6		| Header Field Name | Defined in... |
	Content-Location ; Section 6.7		+-------------------+------------------------+
	Content-Type ; Section 6.9		| Content-Encoding | Section 6.5 |
	Expires ; [Part6], Section 3.3		| Content-Language | Section 6.6 |
	Last-Modified ; [Part4], Section 6.6		| Content-Location | Section 6.7 |
			| Content-Type | Section 6.9 |
			| Expires | Section 3.3 of [Part6] |
			| Last-Modified | Section 6.6 of [Part4] |
			+-------------------+------------------------+
	4.2. Representation Data		4.2. Representation Data
	The representation body associated with an HTTP message is either		The representation body associated with an HTTP message is either
	provided as the payload body of the message or referred to by the		provided as the payload body of the message or referred to by the
	message semantics and the effective request URI. The representation		message semantics and the effective request URI. The representation
	data is in a format and encoding defined by the representation		data is in a format and encoding defined by the representation
	metadata header fields.		metadata header fields.
	The data type of the representation data is determined via the header		The data type of the representation data is determined via the header
	skipping to change at page 16, line 11		skipping to change at page 15, line 44
	can be both very inefficient (given that only a small percentage		can be both very inefficient (given that only a small percentage
	of responses have multiple representations) and a potential		of responses have multiple representations) and a potential
	violation of the user's privacy.		violation of the user's privacy.
	3. It complicates the implementation of an origin server and the		3. It complicates the implementation of an origin server and the
	algorithms for generating responses to a request.		algorithms for generating responses to a request.
	4. It might limit a public cache's ability to use the same response		4. It might limit a public cache's ability to use the same response
	for multiple user's requests.		for multiple user's requests.
	HTTP/1.1 includes the following request-header fields for enabling		HTTP/1.1 includes the following header fields for enabling server-
	server-driven negotiation through description of user agent		driven negotiation through description of user agent capabilities and
	capabilities and user preferences: Accept (Section 6.1), Accept-		user preferences: Accept (Section 6.1), Accept-Charset (Section 6.2),
	Charset (Section 6.2), Accept-Encoding (Section 6.3), Accept-Language		Accept-Encoding (Section 6.3), Accept-Language (Section 6.4), and
	(Section 6.4), and User-Agent (Section 9.9 of [Part2]). However, an		User-Agent (Section 9.9 of [Part2]). However, an origin server is
	origin server is not limited to these dimensions and MAY vary the		not limited to these dimensions and MAY vary the response based on
	response based on any aspect of the request, including information		any aspect of the request, including aspects of the connection (e.g.,
	outside the request-header fields or within extension header fields		IP address) or information within extension header fields not defined
	not defined by this specification.		by this specification.
	Note: In practice, User-Agent based negotiation is fragile,		Note: In practice, User-Agent based negotiation is fragile,
	because new clients might not be recognized.		because new clients might not be recognized.
	The Vary header field (Section 3.5 of [Part6]) can be used to express		The Vary header field (Section 3.5 of [Part6]) can be used to express
	the parameters the server uses to select a representation that is		the parameters the server uses to select a representation that is
	subject to server-driven negotiation.		subject to server-driven negotiation.
	5.2. Agent-driven Negotiation		5.2. Agent-driven Negotiation
	skipping to change at page 17, line 17		skipping to change at page 16, line 50
	the server is unwilling or unable to provide a varying response using		the server is unwilling or unable to provide a varying response using
	server-driven negotiation.		server-driven negotiation.
	6. Header Field Definitions		6. Header Field Definitions
	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 the payload of messages.		fields related to the payload of messages.
	6.1. Accept		6.1. Accept
	The "Accept" request-header field can be used by user agents to		The "Accept" header field can be used by user agents to specify
	specify response media types that are acceptable. Accept header		response media types that are acceptable. Accept header fields can
	fields can be used to indicate that the request is specifically		be used to indicate that the request is specifically limited to a
	limited to a small set of desired types, as in the case of a request		small set of desired types, as in the case of a request for an in-
	for an in-line image.		line image.
	Accept = "Accept" ":" OWS Accept-v		Accept = "Accept" ":" OWS Accept-v
	Accept-v = #( media-range [ accept-params ] )		Accept-v = #( media-range [ accept-params ] )
	media-range = ( "*/*"		media-range = ( "*/*"
	/ ( type "/" "*" )		/ ( type "/" "*" )
	/ ( type "/" subtype )		/ ( type "/" subtype )
	) *( OWS ";" OWS parameter )		) *( OWS ";" OWS parameter )
	accept-params = OWS ";" OWS "q=" qvalue *( accept-ext )		accept-params = OWS ";" OWS "q=" qvalue *( accept-ext )
	accept-ext = OWS ";" OWS token [ "=" word ]		accept-ext = OWS ";" OWS token [ "=" word ]
	skipping to change at page 19, line 25		skipping to change at page 19, line 9
	| text/html;level=3 | 0.7 |		| text/html;level=3 | 0.7 |
	+-------------------+---------------+		+-------------------+---------------+
	Note: A user agent might be provided with a default set of quality		Note: A user agent might be provided with a default set of quality
	values for certain media ranges. However, unless the user agent is a		values for certain media ranges. However, unless the user agent is a
	closed system which cannot interact with other rendering agents, this		closed system which cannot interact with other rendering agents, this
	default set ought to be configurable by the user.		default set ought to be configurable by the user.
	6.2. Accept-Charset		6.2. Accept-Charset
	The "Accept-Charset" request-header field can be used by user agents		The "Accept-Charset" header field can be used by user agents to
	to indicate what response character sets are acceptable. This field		indicate what character encodings are acceptable in a response
	allows clients capable of understanding more comprehensive or		payload. This field allows clients capable of understanding more
	special-purpose character sets to signal that capability to a server		comprehensive or special-purpose character encodings to signal that
	which is capable of representing documents in those character sets.		capability to a server which is capable of representing documents in
			those character encodings.
	Accept-Charset = "Accept-Charset" ":" OWS		Accept-Charset = "Accept-Charset" ":" OWS
	Accept-Charset-v		Accept-Charset-v
	Accept-Charset-v = 1#( ( charset / "*" )		Accept-Charset-v = 1#( ( charset / "*" )
	[ OWS ";" OWS "q=" qvalue ] )		[ OWS ";" OWS "q=" qvalue ] )
	Character set values are described in Section 2.1. Each charset MAY		Character encoding values (a.k.a., charsets) are described in
	be given an associated quality value which represents the user's		Section 2.1. Each charset MAY be given an associated quality value
	preference for that charset. The default value is q=1. An example		which represents the user's preference for that charset. The default
	is		value is q=1. An example is
	Accept-Charset: iso-8859-5, unicode-1-1;q=0.8		Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
	The special value "*", if present in the Accept-Charset field,		The special value "*", if present in the Accept-Charset field,
	matches every character set (including ISO-8859-1) which is not		matches every character encoding (including ISO-8859-1) which is not
	mentioned elsewhere in the Accept-Charset field. If no "*" is		mentioned elsewhere in the Accept-Charset field. If no "*" is
	present in an Accept-Charset field, then all character sets not		present in an Accept-Charset field, then all character encodings not
	explicitly mentioned get a quality value of 0, except for ISO-8859-1,		explicitly mentioned get a quality value of 0, except for ISO-8859-1,
	which gets a quality value of 1 if not explicitly mentioned.		which gets a quality value of 1 if not explicitly mentioned.
	If no Accept-Charset header field is present, the default is that any		If no Accept-Charset header field is present, the default is that any
	character set is acceptable. If an Accept-Charset header field is		character encoding is acceptable. If an Accept-Charset header field
	present, and if the server cannot send a response which is acceptable		is present, and if the server cannot send a response which is
	according to the Accept-Charset header field, then the server SHOULD		acceptable according to the Accept-Charset header field, then the
	send an error response with the 406 (Not Acceptable) status code,		server SHOULD send an error response with the 406 (Not Acceptable)
	though the sending of an unacceptable response is also allowed.		status code, though the sending of an unacceptable response is also
			allowed.
	6.3. Accept-Encoding		6.3. Accept-Encoding
	The "Accept-Encoding" request-header field can be used by user agents		The "Accept-Encoding" header field can be used by user agents to
	to indicate what response content-codings (Section 2.2) are		indicate what response content-codings (Section 2.2) are acceptable
	acceptable in the response.		in the response.
	Accept-Encoding = "Accept-Encoding" ":" OWS		Accept-Encoding = "Accept-Encoding" ":" OWS
	Accept-Encoding-v		Accept-Encoding-v
	Accept-Encoding-v =		Accept-Encoding-v =
	#( codings [ OWS ";" OWS "q=" qvalue ] )		#( codings [ OWS ";" OWS "q=" qvalue ] )
	codings = ( content-coding / "*" )		codings = ( content-coding / "*" )
	Each codings value MAY be given an associated quality value which		Each codings value MAY be given an associated quality value which
	represents the preference for that encoding. The default value is		represents the preference for that encoding. The default value is
	q=1.		q=1.
	skipping to change at page 21, line 32		skipping to change at page 21, line 22
	messages sent with other content-codings. The server might also		messages sent with other content-codings. The server might also
	make this decision based on information about the particular user-		make this decision based on information about the particular user-
	agent or client.		agent or client.
	Note: Most HTTP/1.0 applications do not recognize or obey qvalues		Note: Most HTTP/1.0 applications do not recognize or obey qvalues
	associated with content-codings. This means that qvalues will not		associated with content-codings. This means that qvalues will not
	work and are not permitted with x-gzip or x-compress.		work and are not permitted with x-gzip or x-compress.
	6.4. Accept-Language		6.4. Accept-Language
	The "Accept-Language" request-header field can be used by user agents		The "Accept-Language" header field can be used by user agents to
	to indicate the set of natural languages that are preferred in the		indicate the set of natural languages that are preferred in the
	response. Language tags are defined in Section 2.4.		response. Language tags are defined in Section 2.4.
	Accept-Language = "Accept-Language" ":" OWS		Accept-Language = "Accept-Language" ":" OWS
	Accept-Language-v		Accept-Language-v
	Accept-Language-v =		Accept-Language-v =
	1#( language-range [ OWS ";" OWS "q=" qvalue ] )		1#( language-range [ OWS ";" OWS "q=" qvalue ] )
	language-range =		language-range =
	<language-range, defined in [RFC4647], Section 2.1>		<language-range, defined in [RFC4647], Section 2.1>
	Each language-range can be given an associated quality value which		Each language-range can be given an associated quality value which
	skipping to change at page 22, line 50		skipping to change at page 22, line 41
	Content-Encoding = "Content-Encoding" ":" OWS Content-Encoding-v		Content-Encoding = "Content-Encoding" ":" OWS Content-Encoding-v
	Content-Encoding-v = 1#content-coding		Content-Encoding-v = 1#content-coding
	Content codings are defined in Section 2.2. An example of its use is		Content codings are defined in Section 2.2. An example of its use is
	Content-Encoding: gzip		Content-Encoding: gzip
	The content-coding is a characteristic of the representation.		The content-coding is a characteristic of the representation.
	Typically, the representation body is stored with this encoding and		Typically, the representation body is stored with this encoding and
	is only decoded before rendering or analogous usage. However, a non-		is only decoded before rendering or analogous usage. However, a
	transparent proxy MAY modify the content-coding if the new coding is		transforming proxy MAY modify the content-coding if the new coding is
	known to be acceptable to the recipient, unless the "no-transform"		known to be acceptable to the recipient, unless the "no-transform"
	cache-control directive is present in the message.		cache-control directive is present in the message.
	If the content-coding of a representation is not "identity", then the		If the content-coding of a representation is not "identity", then the
	representation metadata MUST include a Content-Encoding header field		representation metadata MUST include a Content-Encoding header field
	(Section 6.5) that lists the non-identity content-coding(s) used.		(Section 6.5) that lists the non-identity content-coding(s) used.
	If the content-coding of a representation in a request message is not		If the content-coding of a representation in a request message is not
	acceptable to the origin server, the server SHOULD respond with a		acceptable to the origin server, the server SHOULD respond with a
	status code of 415 (Unsupported Media Type).		status code of 415 (Unsupported Media Type).
	skipping to change at page 24, line 37		skipping to change at page 24, line 30
	It has the same syntax and semantics as the header field of the same		It has the same syntax and semantics as the header field of the same
	name defined for MIME body parts in Section 4 of [RFC2557]. However,		name defined for MIME body parts in Section 4 of [RFC2557]. However,
	its appearance in an HTTP message has some special implications for		its appearance in an HTTP message has some special implications for
	HTTP recipients.		HTTP recipients.
	If Content-Location is included in a response message and its value		If Content-Location is included in a response message and its value
	is the same as the effective request URI, then the response payload		is the same as the effective request URI, then the response payload
	SHOULD be considered the current representation of that resource.		SHOULD be considered the current representation of that resource.
	For a GET or HEAD request, this is the same as the default semantics		For a GET or HEAD request, this is the same as the default semantics
	when no Content-Location is provided by the server. For a state-		when no Content-Location is provided by the server. For a state-
	changing method like PUT or POST, it implies that the server's		changing request like PUT or POST, it implies that the server's
	response contains the new representation of that resource, thereby		response contains the new representation of that resource, thereby
	distinguishing it from representations that might only report about		distinguishing it from representations that might only report about
	the action (e.g., "It worked!"). This allows authoring applications		the action (e.g., "It worked!"). This allows authoring applications
	to update their local copies without the need for a subsequent GET		to update their local copies without the need for a subsequent GET
	request.		request.
	If Content-Location is included in a response message and its value		If Content-Location is included in a response message and its value
	differs from the effective request URI, then the origin server is		differs from the effective request URI, then the origin server is
	informing recipients that this representation has its own, presumably		informing recipients that this representation has its own, presumably
	more specific, identifier. For a GET or HEAD request, this is an		more specific, identifier. For a GET or HEAD request, this is an
	indication that the effective request URI identifies a resource that		indication that the effective request URI identifies a resource that
	is subject to content negotiation and the representation selected for		is subject to content negotiation and the representation selected for
	this response can also be found at the identified URI. For other		this response can also be found at the identified URI. For other
	methods, such a Content-Location indicates that this representation		methods, such a Content-Location indicates that this representation
	contains a report on the action's status and the same report is		contains a report on the action's status and the same report is
	available (for future access with GET) at the given URI. For		available (for future access with GET) at the given URI. For
	example, a purchase transaction made via the POST method might		example, a purchase transaction made via a POST request might include
	include a receipt document as the payload of the 200 response; the		a receipt document as the payload of the 200 response; the Content-
	Content-Location value provides an identifier for retrieving a copy		Location value provides an identifier for retrieving a copy of that
	of that same receipt in the future.		same receipt in the future.
	If Content-Location is included in a request message, then it MAY be		If Content-Location is included in a request message, then it MAY be
	interpreted by the origin server as an indication of where the user		interpreted by the origin server as an indication of where the user
	agent originally obtained the content of the enclosed representation		agent originally obtained the content of the enclosed representation
	(prior to any subsequent modification of the content by that user		(prior to any subsequent modification of the content by that user
	agent). In other words, the user agent is providing the same		agent). In other words, the user agent is providing the same
	representation metadata that it received with the original		representation metadata that it received with the original
	representation. However, such interpretation MUST NOT be used to		representation. However, such interpretation MUST NOT be used to
	alter the semantics of the method requested by the client. For		alter the semantics of the method requested by the client. For
	example, if a client makes a PUT request on a negotiated resource and		example, if a client makes a PUT request on a negotiated resource and
	skipping to change at page 26, line 8		skipping to change at page 25, line 48
	transfer-coding is decoded). Note that a MIC is good for detecting		transfer-coding is decoded). Note that a MIC is good for detecting
	accidental modification of the payload body in transit, but is not		accidental modification of the payload body in transit, but is not
	proof against malicious attacks.		proof against malicious attacks.
	Content-MD5 = "Content-MD5" ":" OWS Content-MD5-v		Content-MD5 = "Content-MD5" ":" OWS Content-MD5-v
	Content-MD5-v = <base64 of 128 bit MD5 digest as per [RFC1864]>		Content-MD5-v = <base64 of 128 bit MD5 digest as per [RFC1864]>
	The Content-MD5 header field MAY be generated by an origin server or		The Content-MD5 header field MAY be generated by an origin server or
	client to function as an integrity check of the payload body. Only		client to function as an integrity check of the payload body. Only
	origin servers or user agents MAY generate the Content-MD5 header		origin servers or user agents MAY generate the Content-MD5 header
	field; proxies and gateways MUST NOT generate it, as this would		field; proxies MUST NOT generate it, as this would defeat its value
	defeat its value as an end-to-end integrity check. Any recipient MAY		as an end-to-end integrity check. Any recipient MAY check that the
	check that the digest value in this header field matches a		digest value in this header field matches a corresponding digest
	corresponding digest calculated on payload body as received.		calculated on payload body as received.
	The MD5 digest is computed based on the content of the payload body,		The MD5 digest is computed based on the content of the payload body,
	including any content-coding, but not including any transfer-coding		including any content-coding, but not including any transfer-coding
	applied to the message-body because such transfer-codings might be		applied to the message-body because such transfer-codings might be
	applied or removed anywhere along the request/response chain. If the		applied or removed anywhere along the request/response chain. If the
	message is received with a transfer-coding, that encoding MUST be		message is received with a transfer-coding, that encoding MUST be
	decoded prior to checking the Content-MD5 value against the received		decoded prior to checking the Content-MD5 value against the received
	payload.		payload.
	HTTP extends RFC 1864 to permit the digest to be computed for MIME		HTTP extends RFC 1864 to permit the digest to be computed for MIME
	skipping to change at page 28, line 32		skipping to change at page 28, line 30
	8. Security Considerations		8. Security Considerations
	This section is meant to inform application developers, information		This section is meant to inform application developers, information
	providers, and users of the security limitations in HTTP/1.1 as		providers, and users of the security limitations in HTTP/1.1 as
	described by this document. The discussion does not include		described by this document. The discussion does not include
	definitive solutions to the problems revealed, though it does make		definitive solutions to the problems revealed, though it does make
	some suggestions for reducing security risks.		some suggestions for reducing security risks.
	8.1. Privacy Issues Connected to Accept Header Fields		8.1. Privacy Issues Connected to Accept Header Fields
	Accept request-headers fields can reveal information about the user		Accept headers fields can reveal information about the user to all
	to all servers which are accessed. The Accept-Language header field		servers which are accessed. The Accept-Language header field in
	in particular can reveal information the user would consider to be of		particular can reveal information the user would consider to be of a
	a private nature, because the understanding of particular languages		private nature, because the understanding of particular languages is
	is often strongly correlated to the membership of a particular ethnic		often strongly correlated to the membership of a particular ethnic
	group. User agents which offer the option to configure the contents		group. User agents which offer the option to configure the contents
	of an Accept-Language header field to be sent in every request are		of an Accept-Language header field to be sent in every request are
	strongly encouraged to let the configuration process include a		strongly encouraged to let the configuration process include a
	message which makes the user aware of the loss of privacy involved.		message which makes the user aware of the loss of privacy involved.
	An approach that limits the loss of privacy would be for a user agent		An approach that limits the loss of privacy would be for a user agent
	to omit the sending of Accept-Language header fields by default, and		to omit the sending of Accept-Language header fields by default, and
	to ask the user whether or not to start sending Accept-Language		to ask the user whether or not to start sending Accept-Language
	header fields to a server if it detects, by looking for any Vary		header fields to a server if it detects, by looking for any Vary
	response-header fields generated by the server, that such sending		header fields generated by the server, that such sending could
	could improve the quality of service.		improve the quality of service.
	Elaborate user-customized accept header fields sent in every request,		Elaborate user-customized accept header fields sent in every request,
	in particular if these include quality values, can be used by servers		in particular if these include quality values, can be used by servers
	as relatively reliable and long-lived user identifiers. Such user		as relatively reliable and long-lived user identifiers. Such user
	identifiers would allow content providers to do click-trail tracking,		identifiers would allow content providers to do click-trail tracking,
	and would allow collaborating content providers to match cross-server		and would allow collaborating content providers to match cross-server
	click-trails or form submissions of individual users. Note that for		click-trails or form submissions of individual users. Note that for
	many users not behind a proxy, the network address of the host		many users not behind a proxy, the network address of the host
	running the user agent will also serve as a long-lived user		running the user agent will also serve as a long-lived user
	identifier. In environments where proxies are used to enhance		identifier. In environments where proxies are used to enhance
	skipping to change at page 29, line 32		skipping to change at page 29, line 29
	[ISO-8859-1] International Organization for Standardization,		[ISO-8859-1] International Organization for Standardization,
	"Information technology -- 8-bit single-byte coded		"Information technology -- 8-bit single-byte coded
	graphic character sets -- Part 1: Latin alphabet No.		graphic character sets -- Part 1: Latin alphabet No.
	1", ISO/IEC 8859-1:1998, 1998.		1", ISO/IEC 8859-1:1998, 1998.
	[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
	Ed., and J. Reschke, Ed., "HTTP/1.1, part 1: URIs,		Ed., and J. Reschke, Ed., "HTTP/1.1, part 1: URIs,
	Connections, and Message Parsing",		Connections, and Message Parsing",
	draft-ietf-httpbis-p1-messaging-12 (work in progress),		draft-ietf-httpbis-p1-messaging-13 (work in progress),
	October 2010.		March 2011.
	[Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
	Ed., and J. Reschke, Ed., "HTTP/1.1, part 2: Message		Ed., and J. Reschke, Ed., "HTTP/1.1, part 2: Message
	Semantics", draft-ietf-httpbis-p2-semantics-12 (work in		Semantics", draft-ietf-httpbis-p2-semantics-13 (work in
	progress), October 2010.		progress), March 2011.
	[Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
	Ed., and J. Reschke, Ed., "HTTP/1.1, part 4:		Ed., and J. Reschke, Ed., "HTTP/1.1, part 4:
	Conditional Requests",		Conditional Requests",
	draft-ietf-httpbis-p4-conditional-12 (work in		draft-ietf-httpbis-p4-conditional-13 (work in
	progress), October 2010.		progress), March 2011.
	[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.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
	Ed., and J. Reschke, Ed., "HTTP/1.1, part 5: Range		Ed., and J. Reschke, Ed., "HTTP/1.1, part 5: Range
	Requests and Partial Responses",		Requests and Partial Responses",
	draft-ietf-httpbis-p5-range-12 (work in progress),		draft-ietf-httpbis-p5-range-13 (work in progress),
	October 2010.		March 2011.
	[Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
	Ed., Nottingham, M., Ed., and J. Reschke, Ed.,		Ed., Nottingham, M., Ed., and J. Reschke, Ed.,
	"HTTP/1.1, part 6: Caching",		"HTTP/1.1, part 6: Caching",
	draft-ietf-httpbis-p6-cache-12 (work in progress),		draft-ietf-httpbis-p6-cache-13 (work in progress),
	October 2010.		March 2011.
	[RFC1864] Myers, J. and M. Rose, "The Content-MD5 Header Field",		[RFC1864] Myers, J. and M. Rose, "The Content-MD5 Header Field",
	RFC 1864, October 1995.		RFC 1864, October 1995.
	[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data		[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data
	Format Specification version 3.3", RFC 1950, May 1996.		Format Specification version 3.3", RFC 1950, May 1996.
	RFC 1950 is an Informational RFC, thus it might be less		RFC 1950 is an Informational RFC, thus it might be less
	stable than this specification. On the other hand,		stable than this specification. On the other hand,
	this downward reference was present since the		this downward reference was present since the
	skipping to change at page 33, line 8		skipping to change at page 32, line 50
	This appendix describes specific areas where HTTP differs from MIME.		This appendix describes specific areas where HTTP differs from MIME.
	Proxies and gateways to strict MIME environments SHOULD be aware of		Proxies and gateways to strict MIME environments SHOULD be aware of
	these differences and provide the appropriate conversions where		these differences and provide the appropriate conversions where
	necessary. Proxies and gateways from MIME environments to HTTP also		necessary. Proxies and gateways from MIME environments to HTTP also
	need to be aware of the differences because some conversions might be		need to be aware of the differences because some conversions might be
	required.		required.
	A.1. MIME-Version		A.1. MIME-Version
	HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages		HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages
	MAY include a single MIME-Version general-header field to indicate		MAY include a single MIME-Version header field to indicate what
	what version of the MIME protocol was used to construct the message.		version of the MIME protocol was used to construct the message. Use
	Use of the MIME-Version header field indicates that the message is in		of the MIME-Version header field indicates that the message is in
	full compliance with the MIME protocol (as defined in [RFC2045]).		full compliance with the MIME protocol (as defined in [RFC2045]).
	Proxies/gateways are responsible for ensuring full compliance (where		Proxies/gateways are responsible for ensuring full compliance (where
	possible) when exporting HTTP messages to strict MIME environments.		possible) when exporting HTTP messages to strict MIME environments.
	MIME-Version = "MIME-Version" ":" OWS MIME-Version-v		MIME-Version = "MIME-Version" ":" OWS MIME-Version-v
	MIME-Version-v = 1*DIGIT "." 1*DIGIT		MIME-Version-v = 1*DIGIT "." 1*DIGIT
	MIME version "1.0" is the default for use in HTTP/1.1. However,		MIME version "1.0" is the default for use in HTTP/1.1. However,
	HTTP/1.1 message parsing and semantics are defined by this document		HTTP/1.1 message parsing and semantics are defined by this document
	and not the MIME specification.		and not the MIME specification.
	skipping to change at page 33, line 39		skipping to change at page 33, line 32
	represent line breaks as CRLF and forbids the use of CR or LF outside		represent line breaks as CRLF and forbids the use of CR or LF outside
	of line break sequences. HTTP allows CRLF, bare CR, and bare LF to		of line break sequences. HTTP allows CRLF, bare CR, and bare LF to
	indicate a line break within text content when a message is		indicate a line break within text content when a message is
	transmitted over HTTP.		transmitted over HTTP.
	Where it is possible, a proxy or gateway from HTTP to a strict MIME		Where it is possible, a proxy or gateway from HTTP to a strict MIME
	environment SHOULD translate all line breaks within the text media		environment SHOULD translate all line breaks within the text media
	types described in Section 2.3.1 of this document to the RFC 2049		types described in Section 2.3.1 of this document to the RFC 2049
	canonical form of CRLF. Note, however, that this might be		canonical form of CRLF. Note, however, that this might be
	complicated by the presence of a Content-Encoding and by the fact		complicated by the presence of a Content-Encoding and by the fact
	that HTTP allows the use of some character sets which do not use		that HTTP allows the use of some character encodings which do not use
	octets 13 and 10 to represent CR and LF, as is the case for some		octets 13 and 10 to represent CR and LF, respectively, as is the case
	multi-byte character sets.		for some multi-byte character encodings.
	Conversion will break any cryptographic checksums applied to the		Conversion will break any cryptographic checksums applied to the
	original content unless the original content is already in canonical		original content unless the original content is already in canonical
	form. Therefore, the canonical form is recommended for any content		form. Therefore, the canonical form is recommended for any content
	that uses such checksums in HTTP.		that uses such checksums in HTTP.
	A.3. Conversion of Date Formats		A.3. Conversion of Date Formats
	HTTP/1.1 uses a restricted set of date formats (Section 6.1 of		HTTP/1.1 uses a restricted set of date formats (Section 6.1 of
	[Part1]) to simplify the process of date comparison. Proxies and		[Part1]) to simplify the process of date comparison. Proxies and
	skipping to change at page 36, line 6		skipping to change at page 35, line 50
	] )		] )
	Accept-v = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [		Accept-v = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
	OWS media-range [ accept-params ] ] ) ]		OWS media-range [ accept-params ] ] ) ]
	Content-Encoding = "Content-Encoding:" OWS Content-Encoding-v		Content-Encoding = "Content-Encoding:" OWS Content-Encoding-v
	Content-Encoding-v = *( "," OWS ) content-coding *( OWS "," [ OWS		Content-Encoding-v = *( "," OWS ) content-coding *( OWS "," [ OWS
	content-coding ] )		content-coding ] )
	Content-Language = "Content-Language:" OWS Content-Language-v		Content-Language = "Content-Language:" OWS Content-Language-v
	Content-Language-v = *( "," OWS ) language-tag *( OWS "," [ OWS		Content-Language-v = *( "," OWS ) language-tag *( OWS "," [ OWS
	language-tag ] )		language-tag ] )
	Content-Length = <Content-Length, defined in [Part1], Section 9.2>
	Content-Location = "Content-Location:" OWS Content-Location-v		Content-Location = "Content-Location:" OWS Content-Location-v
	Content-Location-v = absolute-URI / partial-URI		Content-Location-v = absolute-URI / partial-URI
	Content-MD5 = "Content-MD5:" OWS Content-MD5-v		Content-MD5 = "Content-MD5:" OWS Content-MD5-v
	Content-MD5-v = <base64 of 128 bit MD5 digest as per [RFC1864]>		Content-MD5-v = <base64 of 128 bit MD5 digest as per [RFC1864]>
	Content-Range = <Content-Range, defined in [Part5], Section 5.2>
	Content-Type = "Content-Type:" OWS Content-Type-v		Content-Type = "Content-Type:" OWS Content-Type-v
	Content-Type-v = media-type		Content-Type-v = media-type
	Expires = <Expires, defined in [Part6], Section 3.3>
	Last-Modified = <Last-Modified, defined in [Part4], Section 6.6>
	MIME-Version = "MIME-Version:" OWS MIME-Version-v		MIME-Version = "MIME-Version:" OWS MIME-Version-v
	MIME-Version-v = 1*DIGIT "." 1*DIGIT		MIME-Version-v = 1*DIGIT "." 1*DIGIT
	OWS = <OWS, defined in [Part1], Section 1.2.2>		OWS = <OWS, defined in [Part1], Section 1.2.2>
	absolute-URI = <absolute-URI, defined in [Part1], Section 2.6>		absolute-URI = <absolute-URI, defined in [Part1], Section 2.6>
	accept-ext = OWS ";" OWS token [ "=" word ]		accept-ext = OWS ";" OWS token [ "=" word ]
	accept-params = OWS ";" OWS "q=" qvalue *accept-ext		accept-params = OWS ";" OWS "q=" qvalue *accept-ext
	attribute = token		attribute = token
	skipping to change at page 37, line 4		skipping to change at page 36, line 41
	partial-URI = <partial-URI, defined in [Part1], Section 2.6>		partial-URI = <partial-URI, defined in [Part1], Section 2.6>
	qvalue = <qvalue, defined in [Part1], Section 6.4>		qvalue = <qvalue, defined in [Part1], Section 6.4>
	subtype = token		subtype = token
	token = <token, defined in [Part1], Section 1.2.2>		token = <token, defined in [Part1], Section 1.2.2>
	type = token		type = token
	value = word		value = word
	word = <word, defined in [Part1], Section 1.2.2>
			word = <word, defined in [Part1], Section 1.2.2>
	ABNF diagnostics:		ABNF diagnostics:
	; Accept defined but not used		; Accept defined but not used
	; Accept-Charset defined but not used		; Accept-Charset defined but not used
	; Accept-Encoding defined but not used		; Accept-Encoding defined but not used
	; Accept-Language defined but not used		; Accept-Language defined but not used
	; Content-Encoding defined but not used		; Content-Encoding defined but not used
	; Content-Language defined but not used		; Content-Language defined but not used
	; Content-Length defined but not used
	; Content-Location defined but not used		; Content-Location defined but not used
	; Content-MD5 defined but not used		; Content-MD5 defined but not used
	; Content-Range defined but not used
	; Content-Type defined but not used		; Content-Type defined but not used
	; Expires defined but not used
	; Last-Modified defined but not used
	; MIME-Version defined but not used		; MIME-Version defined but not used
	Appendix E. Change Log (to be removed by RFC Editor before publication)		Appendix E. Change Log (to be removed by RFC Editor before publication)
	E.1. Since RFC 2616		E.1. Since RFC 2616
	Extracted relevant partitions from [RFC2616].		Extracted relevant partitions from [RFC2616].
	E.2. Since draft-ietf-httpbis-p3-payload-00		E.2. Since draft-ietf-httpbis-p3-payload-00
	skipping to change at page 42, line 20		skipping to change at page 42, line 17
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/178>: "Content-MD5		o <http://tools.ietf.org/wg/httpbis/trac/ticket/178>: "Content-MD5
	and partial responses"		and partial responses"
	E.13. Since draft-ietf-httpbis-p3-payload-11		E.13. Since draft-ietf-httpbis-p3-payload-11
	Closed issues:		Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/123>: "Factor out		o <http://tools.ietf.org/wg/httpbis/trac/ticket/123>: "Factor out
	Content-Disposition"		Content-Disposition"
			E.14. Since draft-ietf-httpbis-p3-payload-12
			Closed issues:
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/224>: "Header
			Classification"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle
			ABNFs for header fields"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/277>: "potentially
			misleading MAY in media-type def"
	Index		Index
	A		A
	Accept header 17		Accept header field 16
	Accept-Charset header 19		Accept-Charset header field 19
	Accept-Encoding header 20		Accept-Encoding header field 19
	Accept-Language header 21		Accept-Language header field 21
	C		C
	Coding Format		Coding Format
	compress 8		compress 7
	deflate 8		deflate 8
	gzip 8		gzip 8
	identity 8		identity 8
	compress (Coding Format) 8		compress (Coding Format) 7
	content negotiation 5		content negotiation 5
	Content-Encoding header 22		Content-Encoding header field 22
	Content-Language header 23		Content-Language header field 23
	Content-Location header 24		Content-Location header field 24
	Content-MD5 header 25		Content-MD5 header field 25
	Content-Type header 27		Content-Type header field 26
	D		D
	deflate (Coding Format) 8		deflate (Coding Format) 8
	G		G
	Grammar		Grammar
	Accept 17		Accept 17
	Accept-Charset 19		Accept-Charset 19
	Accept-Charset-v 19		Accept-Charset-v 19
	Accept-Encoding 20		Accept-Encoding 20
	Accept-Encoding-v 20		Accept-Encoding-v 20
	accept-ext 17		accept-ext 17
	Accept-Language 21		Accept-Language 21
	Accept-Language-v 21		Accept-Language-v 21
	accept-params 17		accept-params 17
	Accept-v 17		Accept-v 17
	attribute 9		attribute 9
	charset 7		charset 6
	codings 20		codings 20
	content-coding 8		content-coding 7
	Content-Encoding 22		Content-Encoding 22
	Content-Encoding-v 22		Content-Encoding-v 22
	Content-Language 23		Content-Language 23
	Content-Language-v 23		Content-Language-v 23
	Content-Location 24		Content-Location 24
	Content-Location-v 24		Content-Location-v 24
	Content-MD5 25		Content-MD5 25
	Content-MD5-v 25		Content-MD5-v 25
	Content-Type 27		Content-Type 26
	Content-Type-v 27		Content-Type-v 26
	language-range 21		language-range 21
	language-tag 11		language-tag 11
	media-range 17		media-range 17
	media-type 9		media-type 9
	MIME-Version 33		MIME-Version 33
	MIME-Version-v 33		MIME-Version-v 33
	parameter 9		parameter 9
	subtype 9		subtype 9
	type 9		type 9
	value 9		value 9
	gzip (Coding Format) 8		gzip (Coding Format) 8
	H		H
	Headers		Header Fields
	Accept 17		Accept 16
	Accept-Charset 19		Accept-Charset 19
	Accept-Encoding 20		Accept-Encoding 19
	Accept-Language 21		Accept-Language 21
	Content-Encoding 22		Content-Encoding 22
	Content-Language 23		Content-Language 23
	Content-Location 24		Content-Location 24
	Content-MD5 25		Content-MD5 25
	Content-Type 27		Content-Type 26
	MIME-Version 33		MIME-Version 32
	I		I
	identity (Coding Format) 8		identity (Coding Format) 8
	M		M
	MIME-Version header 33		MIME-Version header field 32
	P		P
	payload 12		payload 11
	R		R
	representation 12		representation 12
	Authors' Addresses		Authors' Addresses
	Roy T. Fielding (editor)		Roy T. Fielding (editor)
	Day Software		Adobe Systems Incorporated
	23 Corporate Plaza DR, Suite 280		345 Park Ave
	Newport Beach, CA 92660		San Jose, CA 95110
	USA		USA
	Phone: +1-949-706-5300
	Fax: +1-949-706-5305
	EMail: fielding@gbiv.com		EMail: fielding@gbiv.com
	URI: http://roy.gbiv.com/		URI: http://roy.gbiv.com/
	Jim Gettys		Jim Gettys
	Alcatel-Lucent Bell Labs		Alcatel-Lucent Bell Labs
	21 Oak Knoll Road		21 Oak Knoll Road
	Carlisle, MA 01741		Carlisle, MA 01741
	USA		USA
	EMail: jg@freedesktop.org		EMail: jg@freedesktop.org
	skipping to change at page 44, line 41		skipping to change at page 45, line 4
	URI: http://gettys.wordpress.com/		URI: http://gettys.wordpress.com/
	Jeffrey C. Mogul		Jeffrey C. Mogul
	Hewlett-Packard Company		Hewlett-Packard Company
	HP Labs, Large Scale Systems Group		HP Labs, Large Scale Systems Group
	1501 Page Mill Road, MS 1177		1501 Page Mill Road, MS 1177
	Palo Alto, CA 94304		Palo Alto, CA 94304
	USA		USA
	EMail: JeffMogul@acm.org		EMail: JeffMogul@acm.org
	Henrik Frystyk Nielsen		Henrik Frystyk Nielsen
	Microsoft Corporation		Microsoft Corporation
	1 Microsoft Way		1 Microsoft Way
	Redmond, WA 98052		Redmond, WA 98052
	USA		USA
	EMail: henrikn@microsoft.com		EMail: henrikn@microsoft.com
	Larry Masinter		Larry Masinter
	Adobe Systems, Incorporated		Adobe Systems Incorporated
	345 Park Ave		345 Park Ave
	San Jose, CA 95110		San Jose, CA 95110
	USA		USA
	EMail: LMM@acm.org		EMail: LMM@acm.org
	URI: http://larry.masinter.net/		URI: http://larry.masinter.net/
	Paul J. Leach		Paul J. Leach
	Microsoft Corporation		Microsoft Corporation
	1 Microsoft Way		1 Microsoft Way
End of changes. 75 change blocks.
	178 lines changed or deleted		164 lines changed or added
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/