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/