| 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.36. The latest version is available from http://tools.ietf.org/tools/rfcdiff/