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/ |