draft-ietf-httpbis-p3-payload-08.txt		draft-ietf-httpbis-p3-payload-09.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: April 29, 2010 J. Mogul		Expires: September 9, 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
	October 26, 2009		March 8, 2010
	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-08		draft-ietf-httpbis-p3-payload-09
			Abstract
			The Hypertext Transfer Protocol (HTTP) is an application-level
			protocol for distributed, collaborative, hypermedia information
			systems. HTTP has been in use by the World Wide Web global
			information initiative since 1990. This document is Part 3 of the
			seven-part specification that defines the protocol referred to as
			"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 3 defines
			HTTP message content, metadata, and content negotiation.
			Editorial Note (To be removed by RFC Editor)
			Discussion of this draft should take place on the HTTPBIS working
			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
			documents (including fancy diffs) can be found at
			<http://tools.ietf.org/wg/httpbis/>.
			The changes in this draft are summarized in Appendix E.10.
	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.
	from IETF Documents or IETF Contributions published or made publicly
	available before November 10, 2008. The person(s) controlling the
	copyright in some of this material may not have granted the IETF
	Trust the right to allow modifications of such material outside the
	IETF Standards Process. Without obtaining an adequate license from
	the person(s) controlling the copyright in such materials, this
	document may not be modified outside the IETF Standards Process, and
	derivative works of it may not be created outside the IETF Standards
	Process, except to format it for publication as an RFC or to
	translate it into languages other than English.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	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."
	skipping to change at page 2, line 4		skipping to change at page 2, line 14
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	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 April 29, 2010.		This Internet-Draft will expire on September 9, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2010 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
	publication of this document (http://trustee.ietf.org/license-info).		(http://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights		publication of this document. Please review these documents
	and restrictions with respect to this document.		carefully, as they describe your rights and restrictions with respect
			to this document. Code Components extracted from this document must
	Abstract		include Simplified BSD License text as described in Section 4.e of
			the Trust Legal Provisions and are provided without warranty as
	The Hypertext Transfer Protocol (HTTP) is an application-level		described in the BSD License.
	protocol for distributed, collaborative, hypermedia information
	systems. HTTP has been in use by the World Wide Web global
	information initiative since 1990. This document is Part 3 of the
	seven-part specification that defines the protocol referred to as
	"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 3 defines
	HTTP message content, metadata, and content negotiation.
	Editorial Note (To be removed by RFC Editor)
	Discussion of this draft should take place on the HTTPBIS working
	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
	documents (including fancy diffs) can be found at
	<http://tools.ietf.org/wg/httpbis/>.
	The changes in this draft are summarized in Appendix E.9.		This document may contain material from IETF Documents or IETF
			Contributions published or made publicly available before November
			10, 2008. The person(s) controlling the copyright in some of this
			material may not have granted the IETF Trust the right to allow
			modifications of such material outside the IETF Standards Process.
			Without obtaining an adequate license from the person(s) controlling
			the copyright in such materials, this document may not be modified
			outside the IETF Standards Process, and derivative works of it may
			not be created outside the IETF Standards Process, except to format
			it for publication as an RFC or to translate it into languages other
			than English.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
	1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6		1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6
	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
	skipping to change at page 3, line 30		skipping to change at page 3, line 30
	2.3.1. Canonicalization and Text Defaults . . . . . . . . . . 10		2.3.1. Canonicalization and Text Defaults . . . . . . . . . . 10
	2.3.2. Multipart Types . . . . . . . . . . . . . . . . . . . 11		2.3.2. Multipart Types . . . . . . . . . . . . . . . . . . . 11
	2.4. Language Tags . . . . . . . . . . . . . . . . . . . . . . 11		2.4. Language Tags . . . . . . . . . . . . . . . . . . . . . . 11
	3. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12		3. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	3.1. Entity Header Fields . . . . . . . . . . . . . . . . . . . 12		3.1. Entity Header Fields . . . . . . . . . . . . . . . . . . . 12
	3.2. Entity Body . . . . . . . . . . . . . . . . . . . . . . . 13		3.2. Entity Body . . . . . . . . . . . . . . . . . . . . . . . 13
	3.2.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 13		3.2.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 13
	3.2.2. Entity Length . . . . . . . . . . . . . . . . . . . . 13		3.2.2. Entity Length . . . . . . . . . . . . . . . . . . . . 13
	4. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 14		4. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 14
	4.1. Server-driven Negotiation . . . . . . . . . . . . . . . . 14		4.1. Server-driven Negotiation . . . . . . . . . . . . . . . . 14
	4.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . . 15		4.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . . 16
	4.3. Transparent Negotiation . . . . . . . . . . . . . . . . . 16
	5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 16		5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 16
	5.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . . 17		5.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	5.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . . 19		5.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . . 19
	5.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 20		5.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 19
	5.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 21		5.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 21
	5.5. Content-Encoding . . . . . . . . . . . . . . . . . . . . . 23		5.5. Content-Encoding . . . . . . . . . . . . . . . . . . . . . 22
	5.6. Content-Language . . . . . . . . . . . . . . . . . . . . . 23		5.6. Content-Language . . . . . . . . . . . . . . . . . . . . . 23
	5.7. Content-Location . . . . . . . . . . . . . . . . . . . . . 24		5.7. Content-Location . . . . . . . . . . . . . . . . . . . . . 23
	5.8. Content-MD5 . . . . . . . . . . . . . . . . . . . . . . . 25		5.8. Content-MD5 . . . . . . . . . . . . . . . . . . . . . . . 24
	5.9. Content-Type . . . . . . . . . . . . . . . . . . . . . . . 26		5.9. Content-Type . . . . . . . . . . . . . . . . . . . . . . . 26
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
	6.1. Message Header Registration . . . . . . . . . . . . . . . 27		6.1. Message Header Registration . . . . . . . . . . . . . . . 26
	6.2. Content Coding Registry . . . . . . . . . . . . . . . . . 27		6.2. Content Coding Registry . . . . . . . . . . . . . . . . . 27
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 28		7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
	7.1. Privacy Issues Connected to Accept Headers . . . . . . . . 28		7.1. Privacy Issues Connected to Accept Headers . . . . . . . . 27
	7.2. Content-Disposition Issues . . . . . . . . . . . . . . . . 29		7.2. Content-Disposition Issues . . . . . . . . . . . . . . . . 28
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 29		9.1. Normative References . . . . . . . . . . . . . . . . . . . 28
	9.2. Informative References . . . . . . . . . . . . . . . . . . 31		9.2. Informative References . . . . . . . . . . . . . . . . . . 30
	Appendix A. Differences Between HTTP Entities and RFC 2045		Appendix A. Differences Between HTTP Entities and RFC 2045
	Entities . . . . . . . . . . . . . . . . . . . . . . 32		Entities . . . . . . . . . . . . . . . . . . . . . . 31
	A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 32		A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 32
	A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 33		A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 32
	A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 33		A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 32
	A.4. Introduction of Content-Encoding . . . . . . . . . . . . . 33		A.4. Introduction of Content-Encoding . . . . . . . . . . . . . 33
	A.5. No Content-Transfer-Encoding . . . . . . . . . . . . . . . 34		A.5. No Content-Transfer-Encoding . . . . . . . . . . . . . . . 33
	A.6. Introduction of Transfer-Encoding . . . . . . . . . . . . 34		A.6. Introduction of Transfer-Encoding . . . . . . . . . . . . 33
	A.7. MHTML and Line Length Limitations . . . . . . . . . . . . 34		A.7. MHTML and Line Length Limitations . . . . . . . . . . . . 33
	Appendix B. Additional Features . . . . . . . . . . . . . . . . . 34		Appendix B. Additional Features . . . . . . . . . . . . . . . . . 34
	B.1. Content-Disposition . . . . . . . . . . . . . . . . . . . 35		B.1. Content-Disposition . . . . . . . . . . . . . . . . . . . 34
	Appendix C. Compatibility with Previous Versions . . . . . . . . 35		Appendix C. Compatibility with Previous Versions . . . . . . . . 35
	C.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 35		C.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 35
	C.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 36		C.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 35
	Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 36		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) . . . . . . . . . . . . . . . . . . . . 38		publication) . . . . . . . . . . . . . . . . . . . . 38
	E.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 38		E.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 38
	E.2. Since draft-ietf-httpbis-p3-payload-00 . . . . . . . . . . 38		E.2. Since draft-ietf-httpbis-p3-payload-00 . . . . . . . . . . 38
	E.3. Since draft-ietf-httpbis-p3-payload-01 . . . . . . . . . . 39		E.3. Since draft-ietf-httpbis-p3-payload-01 . . . . . . . . . . 39
	E.4. Since draft-ietf-httpbis-p3-payload-02 . . . . . . . . . . 39		E.4. Since draft-ietf-httpbis-p3-payload-02 . . . . . . . . . . 39
	E.5. Since draft-ietf-httpbis-p3-payload-03 . . . . . . . . . . 40		E.5. Since draft-ietf-httpbis-p3-payload-03 . . . . . . . . . . 39
	E.6. Since draft-ietf-httpbis-p3-payload-04 . . . . . . . . . . 40		E.6. Since draft-ietf-httpbis-p3-payload-04 . . . . . . . . . . 40
	E.7. Since draft-ietf-httpbis-p3-payload-05 . . . . . . . . . . 40		E.7. Since draft-ietf-httpbis-p3-payload-05 . . . . . . . . . . 40
	E.8. Since draft-ietf-httpbis-p3-payload-06 . . . . . . . . . . 41		E.8. Since draft-ietf-httpbis-p3-payload-06 . . . . . . . . . . 40
	E.9. Since draft-ietf-httpbis-p3-payload-07 . . . . . . . . . . 41		E.9. Since draft-ietf-httpbis-p3-payload-07 . . . . . . . . . . 41
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42		E.10. Since draft-ietf-httpbis-p3-payload-08 . . . . . . . . . . 41
			Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44
	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 may influence content selection, and the various selection		that may 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 5, line 51		skipping to change at page 5, line 51
	representation		representation
	An entity included with a response that is subject to content		An entity included with a response that is subject to content
	negotiation. There may exist multiple representations associated		negotiation. There may exist multiple representations associated
	with a particular response status.		with a particular response status.
	variant		variant
	A resource may have one, or more than one, representation(s)		A resource may have one, or more than one, representation(s)
	associated with it at any given instant. Each of these		associated with it at any given instant. Each of these
	representations is termed a `variant'. Use of the term `variant'		representations is termed a "variant". Use of the term "variant"
	does not necessarily imply that the resource is subject to content		does not necessarily imply that the resource is subject to content
	negotiation.		negotiation.
	1.2. Requirements		1.2. Requirements
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	An implementation is not compliant if it fails to satisfy one or more		An implementation is not compliant if it fails to satisfy one or more
	skipping to change at page 14, line 7		skipping to change at page 14, line 7
	3.2.2. Entity Length		3.2.2. Entity Length
	The entity-length of a message is the length of the message-body		The entity-length of a message is the length of the message-body
	before any transfer-codings have been applied. Section 3.4 of		before any transfer-codings have been applied. Section 3.4 of
	[Part1] defines how the transfer-length of a message-body is		[Part1] defines how the transfer-length of a message-body is
	determined.		determined.
	4. Content Negotiation		4. Content Negotiation
	Most HTTP responses include an entity which contains information for		HTTP responses include a representation which contains information
	interpretation by a human user. Naturally, it is desirable to supply		for interpretation, whether by a human user or for further
	the user with the "best available" entity corresponding to the		processing. Often, the server has different ways of representing the
	request. Unfortunately for servers and caches, not all users have		same information; for example, in different formats, languages, or
	the same preferences for what is "best," and not all user agents are		using different character encodings.
	equally capable of rendering all entity types. For that reason, HTTP
	has provisions for several mechanisms for "content negotiation" --
	the process of selecting the best representation for a given response
	when there are multiple representations available.
	Note: This is not called "format negotiation" because the		HTTP clients and their users might have different or variable
	alternate representations may be of the same media type, but use		capabilities, characteristics or preferences which would influence
	different capabilities of that type, be in different languages,		which representation, among those available from the server, would be
	etc.		best for the server to deliver. For this reason, HTTP provides
			mechanisms for "content negotiation" -- a process of allowing
			selection of a representation of a given resource, when more than one
			is available.
	Any response containing an entity-body MAY be subject to negotiation,		This specification defines two patterns of content negotiation;
	including error responses.		"server-driven", where the server selects the representation based
			upon the client's stated preferences, and "agent-driven" negotiation,
			where the server provides a list of representations for the client to
			choose from, based upon their metadata. In addition, there are other
			patterns: some applications use an "active content" pattern, where
			the server returns active content which runs on the client and, based
			on client available parameters, selects additional resources to
			invoke. "Transparent Content Negotiation" ([RFC2295]) has also been
			proposed.
	There are two kinds of content negotiation which are possible in		These patterns are all widely used, and have trade-offs in
	HTTP: server-driven and agent-driven negotiation. These two kinds of		applicability and practicality. In particular, when the number of
	negotiation are orthogonal and thus may be used separately or in		preferences or capabilities to be expressed by a client are large
	combination. One method of combination, referred to as transparent		(such as when many different formats are supported by a user-agent),
	negotiation, occurs when a cache uses the agent-driven negotiation		server-driven negotiation becomes unwieldy, and may not be
	information provided by the origin server in order to provide server-		appropriate. Conversely, when the number of representations to
	driven negotiation for subsequent requests.		choose from is very large, agent-driven negotiation may not be
			appropriate.
			Note that in all cases, the supplier of representations has the
			responsibility for determining which representations might be
			considered to be the "same information".
	4.1. Server-driven Negotiation		4.1. Server-driven Negotiation
	If the selection of the best representation for a response is made by		If the selection of the best representation for a response is made by
	an algorithm located at the server, it is called server-driven		an algorithm located at the server, it is called server-driven
	negotiation. Selection is based on the available representations of		negotiation. Selection is based on the available representations of
	the response (the dimensions over which it can vary; e.g. language,		the response (the dimensions over which it can vary; e.g., language,
	content-coding, etc.) and the contents of particular header fields in		content-coding, etc.) and the contents of particular header fields in
	the request message or on other information pertaining to the request		the request message or on other information pertaining to the request
	(such as the network address of the client).		(such as the network address of the client).
	Server-driven negotiation is advantageous when the algorithm for		Server-driven negotiation is advantageous when the algorithm for
	selecting from among the available representations is difficult to		selecting from among the available representations is difficult to
	describe to the user agent, or when the server desires to send its		describe to the user agent, or when the server desires to send its
	"best guess" to the client along with the first response (hoping to		"best guess" to the client along with the first response (hoping to
	avoid the round-trip delay of a subsequent request if the "best		avoid the round-trip delay of a subsequent request if the "best
	guess" is good enough for the user). In order to improve the		guess" is good enough for the user). In order to improve the
	skipping to change at page 15, line 34		skipping to change at page 15, line 45
	HTTP/1.1 includes the following request-header fields for enabling		HTTP/1.1 includes the following request-header fields for enabling
	server-driven negotiation through description of user agent		server-driven negotiation through description of user agent
	capabilities and user preferences: Accept (Section 5.1), Accept-		capabilities and user preferences: Accept (Section 5.1), Accept-
	Charset (Section 5.2), Accept-Encoding (Section 5.3), Accept-Language		Charset (Section 5.2), Accept-Encoding (Section 5.3), Accept-Language
	(Section 5.4), and User-Agent (Section 9.9 of [Part2]). However, an		(Section 5.4), and User-Agent (Section 9.9 of [Part2]). However, an
	origin server is not limited to these dimensions and MAY vary the		origin server is not limited to these dimensions and MAY vary the
	response based on any aspect of the request, including information		response based on any aspect of the request, including information
	outside the request-header fields or within extension header fields		outside the request-header fields or within extension header fields
	not defined by this specification.		not defined by this specification.
			Note: In practice, User-Agent based negotiation is fragile,
			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.
	4.2. Agent-driven Negotiation		4.2. Agent-driven Negotiation
	With agent-driven negotiation, selection of the best representation		With agent-driven negotiation, selection of the best representation
	for a response is performed by the user agent after receiving an		for a response is performed by the user agent after receiving an
	initial response from the origin server. Selection is based on a		initial response from the origin server. Selection is based on a
	list of the available representations of the response included within		list of the available representations of the response included within
	skipping to change at page 16, line 15		skipping to change at page 16, line 31
	caches are used to distribute server load and reduce network usage.		caches are used to distribute server load and reduce network usage.
	Agent-driven negotiation suffers from the disadvantage of needing a		Agent-driven negotiation suffers from the disadvantage of needing a
	second request to obtain the best alternate representation. This		second request to obtain the best alternate representation. This
	second request is only efficient when caching is used. In addition,		second request is only efficient when caching is used. In addition,
	this specification does not define any mechanism for supporting		this specification does not define any mechanism for supporting
	automatic selection, though it also does not prevent any such		automatic selection, though it also does not prevent any such
	mechanism from being developed as an extension and used within		mechanism from being developed as an extension and used within
	HTTP/1.1.		HTTP/1.1.
	HTTP/1.1 defines the 300 (Multiple Choices) and 406 (Not Acceptable)		This specification defines the 300 (Multiple Choices) and 406 (Not
	status codes for enabling agent-driven negotiation when the server is		Acceptable) status codes for enabling agent-driven negotiation when
	unwilling or unable to provide a varying response using server-driven		the server is unwilling or unable to provide a varying response using
	negotiation.		server-driven negotiation.
	4.3. Transparent Negotiation
	Transparent negotiation is a combination of both server-driven and
	agent-driven negotiation. When a cache is supplied with a form of
	the list of available representations of the response (as in agent-
	driven negotiation) and the dimensions of variance are completely
	understood by the cache, then the cache becomes capable of performing
	server-driven negotiation on behalf of the origin server for
	subsequent requests on that resource.
	Transparent negotiation has the advantage of distributing the
	negotiation work that would otherwise be required of the origin
	server and also removing the second request delay of agent-driven
	negotiation when the cache is able to correctly guess the right
	response.
	This specification does not define any mechanism for transparent
	negotiation, though it also does not prevent any such mechanism from
	being developed as an extension that could be used within HTTP/1.1.
	5. Header Field Definitions		5. 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.
	For entity-header fields, both sender and recipient refer to either		For entity-header fields, both sender and recipient refer to either
	the client or the server, depending on who sends and who receives the		the client or the server, depending on who sends and who receives the
	entity.		entity.
	skipping to change at page 21, line 50		skipping to change at page 21, line 33
	<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
	represents an estimate of the user's preference for the languages		represents an estimate of the user's preference for the languages
	specified by that range. The quality value defaults to "q=1". For		specified by that range. The quality value defaults to "q=1". For
	example,		example,
	Accept-Language: da, en-gb;q=0.8, en;q=0.7		Accept-Language: da, en-gb;q=0.8, en;q=0.7
	would mean: "I prefer Danish, but will accept British English and		would mean: "I prefer Danish, but will accept British English and
	other types of English."		other types of English." (see also Section 2.3 of [RFC4647])
	For matching, the "Basic Filtering" matching scheme, defined in
	Section 3.3.1 of [RFC4647], is used:
	A language range matches a particular language tag if, in a case-
	insensitive comparison, it exactly equals the tag, or if it
	exactly equals a prefix of the tag such that the first character
	following the prefix is "-".
	The special range "*", if present in the Accept-Language field,
	matches every tag not matched by any other range present in the
	Accept-Language field.
	Note: This use of a prefix matching rule does not imply that		For matching, Section 3 of [RFC4647] defines several matching
	language tags are assigned to languages in such a way that it is		schemes. Implementations can offer the most appropriate matching
	always true that if a user understands a language with a certain		scheme for their requirements.
	tag, then this user will also understand all languages with tags
	for which this tag is a prefix. The prefix rule simply allows the
	use of prefix tags if this is the case.
	The language quality factor assigned to a language-tag by the Accept-		Note: The "Basic Filtering" scheme ([RFC4647], Section 3.3.1) is
	Language field is the quality value of the longest language-range in		identical to the matching scheme that was previously defined in
	the field that matches the language-tag. If no language-range in the		Section 14.4 of [RFC2616].
	field matches the tag, the language quality factor assigned is 0. If
	no Accept-Language header is present in the request, the server
	SHOULD assume that all languages are equally acceptable. If an
	Accept-Language header is present, then all languages which are
	assigned a quality factor greater than 0 are acceptable.
	It might be contrary to the privacy expectations of the user to send		It might be contrary to the privacy expectations of the user to send
	an Accept-Language header with the complete linguistic preferences of		an Accept-Language header with the complete linguistic preferences of
	the user in every request. For a discussion of this issue, see		the user in every request. For a discussion of this issue, see
	Section 7.1.		Section 7.1.
	As intelligibility is highly dependent on the individual user, it is		As intelligibility is highly dependent on the individual user, it is
	recommended that client applications make the choice of linguistic		recommended that client applications make the choice of linguistic
	preference available to the user. If the choice is not made		preference available to the user. If the choice is not made
	available, then the Accept-Language header field MUST NOT be given in		available, then the Accept-Language header field MUST NOT be given in
	skipping to change at page 26, line 26		skipping to change at page 25, line 38
	content of the body-part has had the encoding applied, and the body-		content of the body-part has had the encoding applied, and the body-
	part is included in the Content-MD5 digest as is -- i.e., after the		part is included in the Content-MD5 digest as is -- i.e., after the
	application. The Transfer-Encoding header field is not allowed		application. The Transfer-Encoding header field is not allowed
	within body-parts.		within body-parts.
	Conversion of all line breaks to CRLF MUST NOT be done before		Conversion of all line breaks to CRLF MUST NOT be done before
	computing or checking the digest: the line break convention used in		computing or checking the digest: the line break convention used in
	the text actually transmitted MUST be left unaltered when computing		the text actually transmitted MUST be left unaltered when computing
	the digest.		the digest.
	Note: while the definition of Content-MD5 is exactly the same for		Note: While the definition of Content-MD5 is exactly the same for
	HTTP as in RFC 1864 for MIME entity-bodies, there are several ways		HTTP as in RFC 1864 for MIME entity-bodies, there are several ways
	in which the application of Content-MD5 to HTTP entity-bodies		in which the application of Content-MD5 to HTTP entity-bodies
	differs from its application to MIME entity-bodies. One is that		differs from its application to MIME entity-bodies. One is that
	HTTP, unlike MIME, does not use Content-Transfer-Encoding, and		HTTP, unlike MIME, does not use Content-Transfer-Encoding, and
	does use Transfer-Encoding and Content-Encoding. Another is that		does use Transfer-Encoding and Content-Encoding. Another is that
	HTTP more frequently uses binary content types than MIME, so it is		HTTP more frequently uses binary content types than MIME, so it is
	worth noting that, in such cases, the byte order used to compute		worth noting that, in such cases, the byte order used to compute
	the digest is the transmission byte order defined for the type.		the digest is the transmission byte order defined for the type.
	Lastly, HTTP allows transmission of text types with any of several		Lastly, HTTP allows transmission of text types with any of several
	line break conventions and not just the canonical form using CRLF.		line break conventions and not just the canonical form using CRLF.
	skipping to change at page 29, line 36		skipping to change at page 28, line 45
	[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.
	[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., Ed.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,		and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
	and Message Parsing", draft-ietf-httpbis-p1-messaging-08		and Message Parsing", draft-ietf-httpbis-p1-messaging-09
	(work in progress), October 2009.		(work in progress), March 2010.
	[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-08 (work in		Semantics", draft-ietf-httpbis-p2-semantics-09 (work in
	progress), October 2009.		progress), March 2010.
	[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., Ed.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional		and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional
	Requests", draft-ietf-httpbis-p4-conditional-08 (work in		Requests", draft-ietf-httpbis-p4-conditional-09 (work in
	progress), October 2009.		progress), March 2010.
	[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-08 (work		Partial Responses", draft-ietf-httpbis-p5-range-09 (work
	in progress), October 2009.		in progress), March 2010.
	[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.,
	Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part		Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part
	6: Caching", draft-ietf-httpbis-p6-cache-08 (work in		6: Caching", draft-ietf-httpbis-p6-cache-09 (work in
	progress), October 2009.		progress), March 2010.
	[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 Format		[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format
	Specification version 3.3", RFC 1950, May 1996.		Specification version 3.3", RFC 1950, May 1996.
	RFC 1950 is an Informational RFC, thus it may be less		RFC 1950 is an Informational RFC, thus it may be less
	stable than this specification. On the other hand, this		stable than this specification. On the other hand, this
	downward reference was present since the publication of		downward reference was present since the publication of
	skipping to change at page 31, line 38		skipping to change at page 30, line 46
	[RFC2076] Palme, J., "Common Internet Message Headers", RFC 2076,		[RFC2076] Palme, J., "Common Internet Message Headers", RFC 2076,
	February 1997.		February 1997.
	[RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating		[RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating
	Presentation Information in Internet Messages: The		Presentation Information in Internet Messages: The
	Content-Disposition Header Field", RFC 2183, August 1997.		Content-Disposition Header Field", RFC 2183, August 1997.
	[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and		[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
	Languages", BCP 18, RFC 2277, January 1998.		Languages", BCP 18, RFC 2277, January 1998.
			[RFC2295] Holtman, K. and A. Mutz, "Transparent Content Negotiation
			in HTTP", RFC 2295, March 1998.
	[RFC2388] Masinter, L., "Returning Values from Forms: multipart/		[RFC2388] Masinter, L., "Returning Values from Forms: multipart/
	form-data", RFC 2388, August 1998.		form-data", RFC 2388, August 1998.
	[RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud,		[RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud,
	"MIME Encapsulation of Aggregate Documents, such as HTML		"MIME Encapsulation of Aggregate Documents, such as HTML
	(MHTML)", RFC 2557, March 1999.		(MHTML)", RFC 2557, March 1999.
	[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,		[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext		Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
	Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.		Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
	skipping to change at page 35, line 33		skipping to change at page 34, line 47
	Content-Disposition: attachment; filename="fname.ext"		Content-Disposition: attachment; filename="fname.ext"
	The receiving user agent SHOULD NOT respect any directory path		The receiving user agent SHOULD NOT respect any directory path
	information present in the filename-parm parameter, which is the only		information present in the filename-parm parameter, which is the only
	parameter believed to apply to HTTP implementations at this time.		parameter believed to apply to HTTP implementations at this time.
	The filename SHOULD be treated as a terminal component only.		The filename SHOULD be treated as a terminal component only.
	If this header is used in a response with the application/		If this header is used in a response with the application/
	octet-stream content-type, the implied suggestion is that the user		octet-stream content-type, the implied suggestion is that the user
	agent should not display the response, but directly enter a `save		agent should not display the response, but directly enter a "save
	response as...' dialog.		response as..." dialog.
	See Section 7.2 for Content-Disposition security issues.		See Section 7.2 for Content-Disposition security issues.
	Appendix C. Compatibility with Previous Versions		Appendix C. Compatibility with Previous Versions
	C.1. Changes from RFC 2068		C.1. Changes from RFC 2068
	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 42, line 13		skipping to change at page 41, line 37
	Partly resolved issues:		Partly resolved issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/148>: "update IANA		o <http://tools.ietf.org/wg/httpbis/trac/ticket/148>: "update IANA
	requirements wrt Transfer-Coding values" (add the IANA		requirements wrt Transfer-Coding values" (add the IANA
	Considerations subsection)		Considerations subsection)
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/149>: "update IANA		o <http://tools.ietf.org/wg/httpbis/trac/ticket/149>: "update IANA
	requirements wrt Content-Coding values" (add the IANA		requirements wrt Content-Coding values" (add the IANA
	Considerations subsection)		Considerations subsection)
			E.10. Since draft-ietf-httpbis-p3-payload-08
			Closed issues:
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/81>: "Content
			Negotiation for media types"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/181>: "Accept-
			Language: which RFC4647 filtering?"
	Index		Index
	A		A
	Accept header 17		Accept header 16
	Accept-Charset header 19		Accept-Charset header 19
	Accept-Encoding header 20		Accept-Encoding header 19
	Accept-Language header 21		Accept-Language header 21
	Alternates header 36		Alternates header 35
	C		C
	Coding Format		Coding Format
	compress 8		compress 8
	deflate 8		deflate 8
	gzip 9		gzip 9
	identity 9		identity 9
	compress (Coding Format) 8		compress (Coding Format) 8
	content negotiation 5		content negotiation 5
	Content-Base header 36		Content-Base header 35
	Content-Disposition header 35		Content-Disposition header 34
	Content-Encoding header 23		Content-Encoding header 22
	Content-Language header 23		Content-Language header 23
	Content-Location header 24		Content-Location header 23
	Content-MD5 header 25		Content-MD5 header 24
	Content-Type header 26		Content-Type header 26
	Content-Version header 36		Content-Version header 35
	D		D
	deflate (Coding Format) 8		deflate (Coding Format) 8
	Derived-From header 36		Derived-From header 35
	E		E
	entity 5		entity 5
	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 19
	Accept-Encoding-v 20		Accept-Encoding-v 19
	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 10		attribute 10
	charset 7		charset 7
	codings 20		codings 19
	content-coding 8		content-coding 8
	content-disposition 35		content-disposition 34
	content-disposition-v 35		content-disposition-v 34
	Content-Encoding 23		Content-Encoding 22
	Content-Encoding-v 23		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 24
	Content-MD5-v 25		Content-MD5-v 24
	Content-Type 26		Content-Type 26
	Content-Type-v 26		Content-Type-v 26
	disp-extension-parm 35		disp-extension-parm 34
	disp-extension-token 35		disp-extension-token 34
	disposition-parm 35		disposition-parm 34
	disposition-type 35		disposition-type 34
	entity-body 13		entity-body 13
	entity-header 12		entity-header 12
	extension-header 12		extension-header 12
	filename-parm 35		filename-parm 34
	language-range 21		language-range 21
	language-tag 12		language-tag 12
	media-range 17		media-range 17
	media-type 9		media-type 9
	MIME-Version 32		MIME-Version 32
	MIME-Version-v 32		MIME-Version-v 32
	parameter 10		parameter 10
	subtype 9		subtype 9
	type 9		type 9
	value 10		value 10
	gzip (Coding Format) 9		gzip (Coding Format) 9
	H		H
	Headers		Headers
	Accept 17		Accept 16
	Accept-Charset 19		Accept-Charset 19
	Accept-Encoding 20		Accept-Encoding 19
	Accept-Language 21		Accept-Language 21
	Alternate 36		Alternate 35
	Content-Base 36		Content-Base 35
	Content-Disposition 35		Content-Disposition 34
	Content-Encoding 23		Content-Encoding 22
	Content-Language 23		Content-Language 23
	Content-Location 24		Content-Location 23
	Content-MD5 25		Content-MD5 24
	Content-Type 26		Content-Type 26
	Content-Version 36		Content-Version 35
	Derived-From 36		Derived-From 35
	Link 36		Link 35
	MIME-Version 32		MIME-Version 32
	Public 36		Public 35
	URI 36		URI 35
	I		I
	identity (Coding Format) 9		identity (Coding Format) 9
	L		L
	Link header 36		Link header 35
	M		M
	MIME-Version header 32		MIME-Version header 32
	P		P
	Public header 36		Public header 35
	R		R
	representation 5		representation 5
	U		U
	URI header 36		URI header 35
	V		V
	variant 5		variant 5
	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
End of changes. 66 change blocks.
	195 lines changed or deleted		191 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/