| draft-ietf-httpbis-p3-payload-10.txt |  | draft-ietf-httpbis-p3-payload-11.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 Alcatel-Lucent |  | Intended status: Standards Track Alcatel-Lucent |
| Expires: January 13, 2011 J. Mogul |  | Expires: February 5, 2011 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 |
| July 12, 2010 |  | August 4, 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-10 |  | draft-ietf-httpbis-p3-payload-11 |
| Abstract |  | Abstract |
| The Hypertext Transfer Protocol (HTTP) is an application-level |  | The Hypertext Transfer Protocol (HTTP) is an application-level |
| protocol for distributed, collaborative, hypermedia information |  | protocol for distributed, collaborative, hypermedia information |
| systems. HTTP has been in use by the World Wide Web global |  | systems. HTTP has been in use by the World Wide Web global |
| information initiative since 1990. This document is Part 3 of the |  | information initiative since 1990. This document is Part 3 of the |
| seven-part specification that defines the protocol referred to as |  | seven-part specification that defines the protocol referred to as |
| "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 3 defines |  | "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 3 defines |
| HTTP message content, metadata, and content negotiation. |  | HTTP message content, metadata, and content negotiation. |
| Editorial Note (To be removed by RFC Editor) |  | Editorial Note (To be removed by RFC Editor) |
| Discussion of this draft should take place on the HTTPBIS working |  | Discussion of this draft should take place on the HTTPBIS working |
| group mailing list (ietf-http-wg@w3.org). The current issues list is |  | group mailing list (ietf-http-wg@w3.org). The current issues list is |
| at <http://tools.ietf.org/wg/httpbis/trac/report/3> and related |  | at <http://tools.ietf.org/wg/httpbis/trac/report/3> and related |
| documents (including fancy diffs) can be found at |  | documents (including fancy diffs) can be found at |
| <http://tools.ietf.org/wg/httpbis/>. |  | <http://tools.ietf.org/wg/httpbis/>. |
| The changes in this draft are summarized in Appendix E.11. |  | The changes in this draft are summarized in Appendix E.12. |
| Status of This Memo |  | Status of This Memo |
| This Internet-Draft is submitted in full conformance with the |  | This Internet-Draft is submitted in full conformance with the |
| provisions of BCP 78 and BCP 79. |  | provisions of BCP 78 and BCP 79. |
| Internet-Drafts are working documents of the Internet Engineering |  | Internet-Drafts are working documents of the Internet Engineering |
| Task Force (IETF). Note that other groups may also distribute |  | Task Force (IETF). Note that other groups may also distribute |
| working documents as Internet-Drafts. The list of current Internet- |  | working documents as Internet-Drafts. The list of current Internet- |
| Drafts is at http://datatracker.ietf.org/drafts/current/. |  | Drafts is at http://datatracker.ietf.org/drafts/current/. |
| Internet-Drafts are draft documents valid for a maximum of six months |  | Internet-Drafts are draft documents valid for a maximum of six months |
| and may be updated, replaced, or obsoleted by other documents at any |  | and may be updated, replaced, or obsoleted by other documents at any |
| time. It is inappropriate to use Internet-Drafts as reference |  | time. It is inappropriate to use Internet-Drafts as reference |
| material or to cite them other than as "work in progress." |  | material or to cite them other than as "work in progress." |
| This Internet-Draft will expire on January 13, 2011. |  | This Internet-Draft will expire on February 5, 2011. |
| Copyright Notice |  | Copyright Notice |
| Copyright (c) 2010 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 |  | Provisions Relating to IETF Documents |
| (http://trustee.ietf.org/license-info) in effect on the date of |  | (http://trustee.ietf.org/license-info) in effect on the date of |
| publication of this document. Please review these documents |  | publication of this document. Please review these documents |
| skipping to change at page 2, line 48 |  | skipping to change at page 2, line 48 |
| the copyright in such materials, this document may not be modified |  | the copyright in such materials, this document may not be modified |
| outside the IETF Standards Process, and derivative works of it may |  | outside the IETF Standards Process, and derivative works of it may |
| not be created outside the IETF Standards Process, except to format |  | not be created outside the IETF Standards Process, except to format |
| it for publication as an RFC or to translate it into languages other |  | it for publication as an RFC or to translate it into languages other |
| than English. |  | 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 . . . . . . . . . . . . . . . . . . . . . . . 5 |
| 1.3. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 |  | 1.3. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 |
| 1.3.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 6 |  | 1.3.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 6 |
| 1.3.2. ABNF Rules defined in other Parts of the |  | 1.3.2. ABNF Rules defined in other Parts of the |
| Specification . . . . . . . . . . . . . . . . . . . . 6 |  | Specification . . . . . . . . . . . . . . . . . . . . 6 |
| 2. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 7 |  | 2. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 6 |
| 2.1. Character Sets . . . . . . . . . . . . . . . . . . . . . . 7 |  | 2.1. Character Sets . . . . . . . . . . . . . . . . . . . . . . 6 |
| 2.1.1. Missing Charset . . . . . . . . . . . . . . . . . . . 8 |  | 2.1.1. Missing Charset . . . . . . . . . . . . . . . . . . . 7 |
| 2.2. Content Codings . . . . . . . . . . . . . . . . . . . . . 8 |  | 2.2. Content Codings . . . . . . . . . . . . . . . . . . . . . 8 |
| 2.2.1. Content Coding Registry . . . . . . . . . . . . . . . 9 |  | 2.2.1. Content Coding Registry . . . . . . . . . . . . . . . 9 |
| 2.3. Media Types . . . . . . . . . . . . . . . . . . . . . . . 9 |  | 2.3. Media Types . . . . . . . . . . . . . . . . . . . . . . . 9 |
| 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 . . . . . . . . . . . . . . . . . . . . . . 12 |  | 2.4. Language Tags . . . . . . . . . . . . . . . . . . . . . . 11 |
| 3. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 |  | 3. Payload . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 |
| 3.1. Entity Header Fields . . . . . . . . . . . . . . . . . . . 12 |  | 3.1. Payload Header Fields . . . . . . . . . . . . . . . . . . 12 |
| 3.2. Entity Body . . . . . . . . . . . . . . . . . . . . . . . 13 |  | 3.2. Payload Body . . . . . . . . . . . . . . . . . . . . . . . 12 |
| 3.2.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 13 |  | 4. Representation . . . . . . . . . . . . . . . . . . . . . . . . 12 |
| 3.2.2. Entity Length . . . . . . . . . . . . . . . . . . . . 14 |  | 4.1. Representation Header Fields . . . . . . . . . . . . . . . 13 |
| 4. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 14 |  | 4.2. Representation Data . . . . . . . . . . . . . . . . . . . 13 |
| 4.1. Server-driven Negotiation . . . . . . . . . . . . . . . . 15 |  | 5. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 14 |
| 4.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . . 16 |  | 5.1. Server-driven Negotiation . . . . . . . . . . . . . . . . 15 |
| 5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 17 |  | 5.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . . 16 |
| 5.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . . 17 |  | 6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 17 |
| 5.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . . 19 |  | 6.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . . 17 |
| 5.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 20 |  | 6.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . . 19 |
| 5.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 21 |  | 6.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 20 |
| 5.5. Content-Encoding . . . . . . . . . . . . . . . . . . . . . 22 |  | 6.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 21 |
| 5.6. Content-Language . . . . . . . . . . . . . . . . . . . . . 23 |  | 6.5. Content-Encoding . . . . . . . . . . . . . . . . . . . . . 22 |
| 5.7. Content-Location . . . . . . . . . . . . . . . . . . . . . 24 |  | 6.6. Content-Language . . . . . . . . . . . . . . . . . . . . . 23 |
| 5.8. Content-MD5 . . . . . . . . . . . . . . . . . . . . . . . 25 |  | 6.7. Content-Location . . . . . . . . . . . . . . . . . . . . . 24 |
| 5.9. Content-Type . . . . . . . . . . . . . . . . . . . . . . . 26 |  | 6.8. Content-MD5 . . . . . . . . . . . . . . . . . . . . . . . 25 |
| 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 |  | 6.9. Content-Type . . . . . . . . . . . . . . . . . . . . . . . 27 |
| 6.1. Message Header Registration . . . . . . . . . . . . . . . 26 |  | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 |
| 6.2. Content Coding Registry . . . . . . . . . . . . . . . . . 27 |  | 7.1. Header Field Registration . . . . . . . . . . . . . . . . 27 |
| 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 |  | 7.2. Content Coding Registry . . . . . . . . . . . . . . . . . 27 |
| 7.1. Privacy Issues Connected to Accept Headers . . . . . . . . 28 |  | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 28 |
| 7.2. Content-Disposition Issues . . . . . . . . . . . . . . . . 28 |  | 8.1. Privacy Issues Connected to Accept Headers . . . . . . . . 28 |
| 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 |  | 8.2. Content-Disposition Issues . . . . . . . . . . . . . . . . 29 |
| 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 |  | 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 |
| 9.1. Normative References . . . . . . . . . . . . . . . . . . . 29 |  | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 |
| 9.2. Informative References . . . . . . . . . . . . . . . . . . 31 |  | 10.1. Normative References . . . . . . . . . . . . . . . . . . . 29 |
| Appendix A. Differences Between HTTP Entities and RFC 2045 |  | 10.2. Informative References . . . . . . . . . . . . . . . . . . 31 |
| Entities . . . . . . . . . . . . . . . . . . . . . . 32 |  | Appendix A. Differences between HTTP and MIME . . . . . . . . . . 32 |
| A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 32 |  | A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 33 |
| A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 33 |  | A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 33 |
| A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 33 |  | A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 34 |
| A.4. Introduction of Content-Encoding . . . . . . . . . . . . . 33 |  | A.4. Introduction of Content-Encoding . . . . . . . . . . . . . 34 |
| A.5. No Content-Transfer-Encoding . . . . . . . . . . . . . . . 34 |  | A.5. No Content-Transfer-Encoding . . . . . . . . . . . . . . . 34 |
| A.6. Introduction of Transfer-Encoding . . . . . . . . . . . . 34 |  | A.6. Introduction of Transfer-Encoding . . . . . . . . . . . . 34 |
| A.7. MHTML and Line Length Limitations . . . . . . . . . . . . 34 |  | A.7. MHTML and Line Length Limitations . . . . . . . . . . . . 35 |
| Appendix B. Additional Features . . . . . . . . . . . . . . . . . 34 |  | Appendix B. Additional Features . . . . . . . . . . . . . . . . . 35 |
| B.1. Content-Disposition . . . . . . . . . . . . . . . . . . . 35 |  | B.1. Content-Disposition . . . . . . . . . . . . . . . . . . . 35 |
| Appendix C. Compatibility with Previous Versions . . . . . . . . 35 |  | Appendix C. Changes from RFC 2616 . . . . . . . . . . . . . . . . 36 |
| C.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 35 |  |  |
| C.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 36 |  |  |
| Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 36 |  | Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 36 |
| 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 . . . . . . . . . . 40 |
| 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 . . . . . . . . . . 41 |  | 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 . . . . . . . . . . 41 |
| E.9. Since draft-ietf-httpbis-p3-payload-07 . . . . . . . . . . 41 |  | E.9. Since draft-ietf-httpbis-p3-payload-07 . . . . . . . . . . 41 |
| E.10. Since draft-ietf-httpbis-p3-payload-08 . . . . . . . . . . 42 |  | E.10. Since draft-ietf-httpbis-p3-payload-08 . . . . . . . . . . 42 |
| E.11. Since draft-ietf-httpbis-p3-payload-09 . . . . . . . . . . 42 |  | E.11. Since draft-ietf-httpbis-p3-payload-09 . . . . . . . . . . 42 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 |  | E.12. Since draft-ietf-httpbis-p3-payload-10 . . . . . . . . . . 42 |
|  |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 |
| 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 might influence content selection, and the various selection |
| algorithms that are collectively referred to as HTTP content |  | algorithms that are collectively referred to as HTTP content |
| negotiation. |  | negotiation. |
| This document is currently disorganized in order to minimize the |  | This document is currently disorganized in order to minimize the |
| changes between drafts and enable reviewers to see the smaller errata |  | changes between drafts and enable reviewers to see the smaller errata |
| changes. The next draft will reorganize the sections to better |  | changes. The next draft will reorganize the sections to better |
| reflect the content. In particular, the sections on entities will be |  | reflect the content. In particular, the sections on entities will be |
| renamed payload and moved to the first half of the document, while |  | renamed payload and moved to the first half of the document, while |
| the sections on content negotiation and associated request header |  | the sections on content negotiation and associated request header |
| fields will be moved to the second half. The current mess reflects |  | fields will be moved to the second half. The current mess reflects |
| skipping to change at page 5, line 32 |  | skipping to change at page 5, line 32 |
| become in [RFC2616]. |  | become in [RFC2616]. |
| 1.1. Terminology |  | 1.1. Terminology |
| This specification uses a number of terms to refer to the roles |  | This specification uses a number of terms to refer to the roles |
| played by participants in, and objects of, the HTTP communication. |  | played by participants in, and objects of, the HTTP communication. |
| content negotiation |  | content negotiation |
| The mechanism for selecting the appropriate representation when |  | The mechanism for selecting the appropriate representation when |
| servicing a request. The representation of entities in any |  | servicing a request. The representation in any response can be |
| response can be negotiated (including error responses). |  | negotiated (including error responses). |
| entity |  |  |
| The information transferred as the payload of a request or |  |  |
| response. An entity consists of metadata in the form of entity- |  |  |
| header fields and content in the form of an entity-body. |  |  |
| representation |  |  |
| An entity included with a response that is subject to content |  |  |
| negotiation. There may exist multiple representations associated |  |  |
| with a particular response status. |  |  |
| variant |  |  |
| A resource may have one, or more than one, representation(s) |  |  |
| associated with it at any given instant. Each of these |  |  |
| representations is termed a "variant". Use of the term "variant" |  |  |
| does not necessarily imply that the resource is subject to content |  |  |
| 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 |
| of the "MUST" or "REQUIRED" level requirements for the protocols it |  | of the "MUST" or "REQUIRED" level requirements for the protocols it |
| implements. An implementation that satisfies all the "MUST" or |  | implements. An implementation that satisfies all the "MUST" or |
| skipping to change at page 7, line 22 |  | skipping to change at page 7, line 8 |
| 2. Protocol Parameters |  | 2. Protocol Parameters |
| 2.1. Character Sets |  | 2.1. Character Sets |
| HTTP uses the same definition of the term "character set" as that |  | HTTP uses the same definition of the term "character set" as that |
| described for MIME: |  | described for MIME: |
| The term "character set" is used in this document to refer to a |  | The term "character set" is used in this document to refer to a |
| method used with one or more tables to convert a sequence of octets |  | method used with one or more tables to convert a sequence of octets |
| into a sequence of characters. Note that unconditional conversion in |  | into a sequence of characters. Note that unconditional conversion in |
| the other direction is not required, in that not all characters may |  | the other direction is not required, in that not all characters might |
| be available in a given character set and a character set may provide |  | be available in a given character set and a character set might |
| more than one sequence of octets to represent a particular character. |  | provide more than one sequence of octets to represent a particular |
| This definition is intended to allow various kinds of character |  | character. This definition is intended to allow various kinds of |
| encoding, from simple single-table mappings such as US-ASCII to |  | character encoding, from simple single-table mappings such as US- |
| complex table switching methods such as those that use ISO-2022's |  | ASCII to complex table switching methods such as those that use ISO- |
| techniques. However, the definition associated with a MIME character |  | 2022's techniques. However, the definition associated with a MIME |
| set name MUST fully specify the mapping to be performed from octets |  | character set name MUST fully specify the mapping to be performed |
| to characters. In particular, use of external profiling information |  | from octets to characters. In particular, use of external profiling |
| to determine the exact mapping is not permitted. |  | information to determine the exact mapping is not permitted. |
| Note: This use of the term "character set" is more commonly |  | Note: This use of the term "character set" is more commonly |
| referred to as a "character encoding." However, since HTTP and |  | referred to as a "character encoding". However, since HTTP and |
| MIME share the same registry, it is important that the terminology |  | MIME share the same registry, it is important that the terminology |
| also be shared. |  | also be shared. |
| HTTP character sets are identified by case-insensitive tokens. The |  | HTTP character sets are identified by case-insensitive tokens. The |
| complete set of tokens is defined by the IANA Character Set registry |  | complete set of tokens is defined by the IANA Character Set registry |
| (<http://www.iana.org/assignments/character-sets>). |  | (<http://www.iana.org/assignments/character-sets>). |
| charset = token |  | charset = token |
| Although HTTP allows an arbitrary token to be used as a charset |  | Although HTTP allows an arbitrary token to be used as a charset |
| value, any token that has a predefined value within the IANA |  | value, any token that has a predefined value within the IANA |
| Character Set registry MUST represent the character set defined by |  | Character Set registry MUST represent the character set defined by |
| that registry. Applications SHOULD limit their use of character sets |  | that registry. Applications SHOULD limit their use of character sets |
| to those defined by the IANA registry. |  | to those defined by the IANA registry. |
| HTTP uses charset in two contexts: within an Accept-Charset request |  | HTTP uses charset in two contexts: within an Accept-Charset request |
| header (in which the charset value is an unquoted token) and as the |  | header (in which the charset value is an unquoted token) and as the |
| value of a parameter in a Content-Type header (within a request or |  | value of a parameter in a Content-Type header (within a request or |
| response), in which case the parameter value of the charset parameter |  | response), in which case the parameter value of the charset parameter |
| may be quoted. |  | can be quoted. |
| Implementors should be aware of IETF character set requirements |  | Implementors need to be aware of IETF character set requirements |
| [RFC3629] [RFC2277]. |  | [RFC3629] [RFC2277]. |
| 2.1.1. Missing Charset |  | 2.1.1. Missing Charset |
| Some HTTP/1.0 software has interpreted a Content-Type header without |  | Some HTTP/1.0 software has interpreted a Content-Type header without |
| charset parameter incorrectly to mean "recipient should guess." |  | charset parameter incorrectly to mean "recipient should guess". |
| Senders wishing to defeat this behavior MAY include a charset |  | Senders wishing to defeat this behavior MAY include a charset |
| parameter even when the charset is ISO-8859-1 ([ISO-8859-1]) and |  | parameter even when the charset is ISO-8859-1 ([ISO-8859-1]) and |
| SHOULD do so when it is known that it will not confuse the recipient. |  | SHOULD do so when it is known that it will not confuse the recipient. |
| Unfortunately, some older HTTP/1.0 clients did not deal properly with |  | Unfortunately, some older HTTP/1.0 clients did not deal properly with |
| an explicit charset parameter. HTTP/1.1 recipients MUST respect the |  | an explicit charset parameter. HTTP/1.1 recipients MUST respect the |
| charset label provided by the sender; and those user agents that have |  | charset label provided by the sender; and those user agents that have |
| a provision to "guess" a charset MUST use the charset from the |  | a provision to "guess" a charset MUST use the charset from the |
| content-type field if they support that charset, rather than the |  | content-type field if they support that charset, rather than the |
| recipient's preference, when initially displaying a document. See |  | recipient's preference, when initially displaying a document. See |
| Section 2.3.1. |  | Section 2.3.1. |
| 2.2. Content Codings |  | 2.2. Content Codings |
| Content coding values indicate an encoding transformation that has |  | Content coding values indicate an encoding transformation that has |
| been or can be applied to an entity. Content codings are primarily |  | been or can be applied to a representation. Content codings are |
| used to allow a document to be compressed or otherwise usefully |  | primarily used to allow a representation to be compressed or |
| transformed without losing the identity of its underlying media type |  | otherwise usefully transformed without losing the identity of its |
| and without loss of information. Frequently, the entity is stored in |  | underlying media type and without loss of information. Frequently, |
| coded form, transmitted directly, and only decoded by the recipient. |  | the representation is stored in coded form, transmitted directly, and |
|  |  | only decoded by the recipient. |
| content-coding = token |  | content-coding = token |
| All content-coding values are case-insensitive. HTTP/1.1 uses |  | All content-coding values are case-insensitive. HTTP/1.1 uses |
| content-coding values in the Accept-Encoding (Section 5.3) and |  | content-coding values in the Accept-Encoding (Section 6.3) and |
| Content-Encoding (Section 5.5) header fields. Although the value |  | Content-Encoding (Section 6.5) header fields. Although the value |
| describes the content-coding, what is more important is that it |  | describes the content-coding, what is more important is that it |
| indicates what decoding mechanism will be required to remove the |  | indicates what decoding mechanism will be required to remove the |
| encoding. |  | encoding. |
| compress |  | compress |
| See Section 6.2.2.1 of [Part1]. |  | See Section 6.2.2.1 of [Part1]. |
| deflate |  | deflate |
| See Section 6.2.2.2 of [Part1]. |  | See Section 6.2.2.2 of [Part1]. |
| gzip |  | gzip |
| See Section 6.2.2.3 of [Part1]. |  | See Section 6.2.2.3 of [Part1]. |
| identity |  | identity |
| The default (identity) encoding; the use of no transformation |  | The default (identity) encoding; the use of no transformation |
| whatsoever. This content-coding is used only in the Accept- |  | whatsoever. This content-coding is used only in the Accept- |
| skipping to change at page 9, line 35 |  | skipping to change at page 9, line 23 |
| o Description |  | o Description |
| o Pointer to specification text |  | o Pointer to specification text |
| Names of content codings MUST NOT overlap with names of transfer |  | Names of content codings MUST NOT overlap with names of transfer |
| codings (Section 6.2 of [Part1]), unless the encoding transformation |  | codings (Section 6.2 of [Part1]), unless the encoding transformation |
| is identical (as it is the case for the compression codings defined |  | is identical (as it is the case for the compression codings defined |
| in Section 6.2.2 of [Part1]). |  | in Section 6.2.2 of [Part1]). |
| Values to be added to this name space require expert review and a |  | Values to be added to this name space require a specification (see |
| specification (see "Expert Review" and "Specification Required" in |  | "Specification Required" in Section 4.1 of [RFC5226]), and MUST |
| Section 4.1 of [RFC5226]), and MUST conform to the purpose of content |  | conform to the purpose of content coding defined in this section. |
| coding defined in this section. |  |  |
| The registry itself is maintained at |  | The registry itself is maintained at |
| <http://www.iana.org/assignments/http-parameters>. |  | <http://www.iana.org/assignments/http-parameters>. |
| 2.3. Media Types |  | 2.3. Media Types |
| HTTP uses Internet Media Types [RFC2046] in the Content-Type |  | HTTP uses Internet Media Types [RFC2046] in the Content-Type |
| (Section 5.9) and Accept (Section 5.1) header fields in order to |  | (Section 6.9) and Accept (Section 6.1) header fields in order to |
| provide open and extensible data typing and type negotiation. |  | provide open and extensible data typing and type negotiation. |
| media-type = type "/" subtype *( OWS ";" OWS parameter ) |  | media-type = type "/" subtype *( OWS ";" OWS parameter ) |
| type = token |  | type = token |
| subtype = token |  | subtype = token |
| Parameters MAY follow the type/subtype in the form of attribute/value |  | Parameters MAY follow the type/subtype in the form of attribute/value |
| pairs. |  | pairs. |
| parameter = attribute "=" value |  | parameter = attribute "=" value |
| attribute = token |  | attribute = token |
| value = word |  | value = word |
| The type, subtype, and parameter attribute names are case- |  | The type, subtype, and parameter attribute names are case- |
| insensitive. Parameter values might or might not be case-sensitive, |  | insensitive. Parameter values might or might not be case-sensitive, |
| depending on the semantics of the parameter name. The presence or |  | depending on the semantics of the parameter name. The presence or |
| absence of a parameter might be significant to the processing of a |  | absence of a parameter might be significant to the processing of a |
| media-type, depending on its definition within the media type |  | media-type, depending on its definition within the media type |
| registry. |  | registry. |
| A parameter value that matches the token production may be |  | A parameter value that matches the token production can be |
| transmitted as either a token or within a quoted-string. The quoted |  | transmitted as either a token or within a quoted-string. The quoted |
| and unquoted values are equivalent. |  | and unquoted values are equivalent. |
| Note that some older HTTP applications do not recognize media type |  | Note that some older HTTP applications do not recognize media type |
| parameters. When sending data to older HTTP applications, |  | parameters. When sending data to older HTTP applications, |
| implementations SHOULD only use media type parameters when they are |  | implementations SHOULD only use media type parameters when they are |
| required by that type/subtype definition. |  | required by that type/subtype definition. |
| Media-type values are registered with the Internet Assigned Number |  | Media-type values are registered with the Internet Assigned Number |
| Authority (IANA). The media type registration process is outlined in |  | Authority (IANA). The media type registration process is outlined in |
| [RFC4288]. Use of non-registered media types is discouraged. |  | [RFC4288]. Use of non-registered media types is discouraged. |
| 2.3.1. Canonicalization and Text Defaults |  | 2.3.1. Canonicalization and Text Defaults |
| Internet media types are registered with a canonical form. An |  | Internet media types are registered with a canonical form. A |
| entity-body transferred via HTTP messages MUST be represented in the |  | representation transferred via HTTP messages MUST be in the |
| appropriate canonical form prior to its transmission except for |  | appropriate canonical form prior to its transmission except for |
| "text" types, as defined in the next paragraph. |  | "text" types, as defined in the next paragraph. |
| When in canonical form, media subtypes of the "text" type use CRLF as |  | When in canonical form, media subtypes of the "text" type use CRLF as |
| the text line break. HTTP relaxes this requirement and allows the |  | the text line break. HTTP relaxes this requirement and allows the |
| transport of text media with plain CR or LF alone representing a line |  | transport of text media with plain CR or LF alone representing a line |
| break when it is done consistently for an entire entity-body. HTTP |  | break when it is done consistently for an entire representation. |
| applications MUST accept CRLF, bare CR, and bare LF as being |  | HTTP applications MUST accept CRLF, bare CR, and bare LF as |
| representative of a line break in text media received via HTTP. In |  | indicating a line break in text media received via HTTP. In |
| addition, if the text is represented in a character set that does not |  | addition, if the text is in a character encoding that does not use |
| use octets 13 and 10 for CR and LF respectively, as is the case for |  | octets 13 and 10 for CR and LF respectively, as is the case for some |
| some multi-byte character sets, HTTP allows the use of whatever octet |  | multi-byte character encodings, HTTP allows the use of whatever octet |
| sequences are defined by that character set to represent the |  | sequences are defined by that character encoding to represent the |
| equivalent of CR and LF for line breaks. This flexibility regarding |  | equivalent of CR and LF for line breaks. This flexibility regarding |
| line breaks applies only to text media in the entity-body; a bare CR |  | line breaks applies only to text media in the payload body; a bare CR |
| or LF MUST NOT be substituted for CRLF within any of the HTTP control |  | or LF MUST NOT be substituted for CRLF within any of the HTTP control |
| structures (such as header fields and multipart boundaries). |  | structures (such as header fields and multipart boundaries). |
| If an entity-body is encoded with a content-coding, the underlying |  | If a representation is encoded with a content-coding, the underlying |
| data MUST be in a form defined above prior to being encoded. |  | data MUST be in a form defined above prior to being encoded. |
| The "charset" parameter is used with some media types to define the |  | The "charset" parameter is used with some media types to define the |
| character set (Section 2.1) of the data. When no explicit charset |  | character encoding (Section 2.1) of the data. When no explicit |
| parameter is provided by the sender, media subtypes of the "text" |  | charset parameter is provided by the sender, media subtypes of the |
| type are defined to have a default charset value of "ISO-8859-1" when |  | "text" type are defined to have a default charset value of |
| received via HTTP. Data in character sets other than "ISO-8859-1" or |  | "ISO-8859-1" when received via HTTP. Data in character encodings |
| its subsets MUST be labeled with an appropriate charset value. See |  | other than "ISO-8859-1" or its subsets MUST be labeled with an |
| Section 2.1.1 for compatibility problems. |  | appropriate charset value. See Section 2.1.1 for compatibility |
|  |  | problems. |
| 2.3.2. Multipart Types |  | 2.3.2. Multipart Types |
| MIME provides for a number of "multipart" types -- encapsulations of |  | MIME provides for a number of "multipart" types -- encapsulations of |
| one or more entities within a single message-body. All multipart |  | one or more representations within a single message-body. All |
| types share a common syntax, as defined in Section 5.1.1 of |  | multipart types share a common syntax, as defined in Section 5.1.1 of |
| [RFC2046], and MUST include a boundary parameter as part of the media |  | [RFC2046], and MUST include a boundary parameter as part of the media |
| type value. The message body is itself a protocol element and MUST |  | type value. The message body is itself a protocol element and MUST |
| therefore use only CRLF to represent line breaks between body-parts. |  | therefore use only CRLF to represent line breaks between body-parts. |
| Unlike in RFC 2046, the epilogue of any multipart message MUST be |  |  |
| empty; HTTP applications MUST NOT transmit the epilogue (even if the |  |  |
| original multipart contains an epilogue). These restrictions exist |  |  |
| in order to preserve the self-delimiting nature of a multipart |  |  |
| message-body, wherein the "end" of the message-body is indicated by |  |  |
| the ending multipart boundary. |  |  |
| In general, HTTP treats a multipart message-body no differently than |  | In general, HTTP treats a multipart message-body no differently than |
| any other media type: strictly as payload. The one exception is the |  | any other media type: strictly as payload. HTTP does not use the |
| "multipart/byteranges" type (Appendix A of [Part5]) when it appears |  | multipart boundary as an indicator of message-body length. In all |
| in a 206 (Partial Content) response. In all other cases, an HTTP |  | other respects, an HTTP user agent SHOULD follow the same or similar |
| user agent SHOULD follow the same or similar behavior as a MIME user |  |  |
| agent would upon receipt of a multipart type. The MIME header fields |  |  |
| within each body-part of a multipart message-body do not have any |  |  |
| significance to HTTP beyond that defined by their MIME semantics. |  |  |
| In general, an HTTP user agent SHOULD follow the same or similar |  |  |
| behavior as a MIME user agent would upon receipt of a multipart type. |  | behavior as a MIME user agent would upon receipt of a multipart type. |
|  |  | The MIME header fields within each body-part of a multipart message- |
|  |  | body do not have any significance to HTTP beyond that defined by |
|  |  | their MIME semantics. |
| If an application receives an unrecognized multipart subtype, the |  | If an application receives an unrecognized multipart subtype, the |
| application MUST treat it as being equivalent to "multipart/mixed". |  | application MUST treat it as being equivalent to "multipart/mixed". |
| Note: The "multipart/form-data" type has been specifically defined |  | Note: The "multipart/form-data" type has been specifically defined |
| for carrying form data suitable for processing via the POST |  | for carrying form data suitable for processing via the POST |
| request method, as described in [RFC2388]. |  | request method, as described in [RFC2388]. |
| 2.4. Language Tags |  | 2.4. Language Tags |
| A language tag, as defined in [RFC5646], identifies a natural |  | A language tag, as defined in [RFC5646], identifies a natural |
| skipping to change at page 12, line 30 |  | skipping to change at page 12, line 7 |
| insensitive. The name space of language subtags is administered by |  | insensitive. The name space of language subtags is administered by |
| the IANA (see |  | the IANA (see |
| <http://www.iana.org/assignments/language-subtag-registry>). |  | <http://www.iana.org/assignments/language-subtag-registry>). |
| Example tags include: |  | Example tags include: |
| en, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN |  | en, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN |
| See [RFC5646] for further information. |  | See [RFC5646] for further information. |
| 3. Entity |  | 3. Payload |
| Request and Response messages MAY transfer an entity if not otherwise |  | HTTP messages MAY transfer a payload if not otherwise restricted by |
| restricted by the request method or response status code. An entity |  | the request method or response status code. The payload consists of |
| consists of entity-header fields and an entity-body, although some |  | metadata, in the form of header fields, and data, in the form of the |
| responses will only include the entity-headers. |  | sequence of octets in the message-body after any transfer-coding has |
|  |  | been decoded. |
| In this section, both sender and recipient refer to either the client |  | A "payload" in HTTP is always a partial or complete representation of |
| or the server, depending on who sends and who receives the entity. |  | some resource. We use separate terms for payload and representation |
|  |  | because some messages contain only the associated representation's |
|  |  | header fields (e.g., responses to HEAD) or only some part(s) of the |
|  |  | representation (e.g., the 206 status code). |
| 3.1. Entity Header Fields |  | 3.1. Payload Header Fields |
| Entity-header fields define metainformation about the entity-body or, |  | HTTP header fields that specifically define the payload, rather than |
| if no body is present, about the resource identified by the request. |  | the associated representation, are referred to as "payload header |
|  |  | fields". The following payload header fields are defined by |
|  |  | HTTP/1.1: |
| entity-header = Content-Encoding ; Section 5.5 |  | Content-Length ; [Part1], Section 9.2 |
| / Content-Language ; Section 5.6 |  | Content-MD5 ; Section 6.8 |
| / Content-Length ; [Part1], Section 9.2 |  | Content-Range ; [Part5], Section 5.2 |
| / Content-Location ; Section 5.7 |  |  |
| / Content-MD5 ; Section 5.8 |  |  |
| / Content-Range ; [Part5], Section 5.2 |  |  |
| / Content-Type ; Section 5.9 |  |  |
| / Expires ; [Part6], Section 3.3 |  |  |
| / Last-Modified ; [Part4], Section 6.6 |  |  |
| / extension-header |  |  |
| extension-header = header-field |  | 3.2. Payload Body |
| The extension-header mechanism allows additional entity-header fields |  | A payload body is only present in a message when a message-body is |
| to be defined without changing the protocol, but these fields cannot |  | present, as described in Section 3.3 of [Part1]. The payload body is |
| be assumed to be recognizable by the recipient. Unrecognized header |  | obtained from the message-body by decoding any Transfer-Encoding that |
| fields SHOULD be ignored by the recipient and MUST be forwarded by |  | might have been applied to ensure safe and proper transfer of the |
| transparent proxies. |  | message. |
| 3.2. Entity Body |  | 4. Representation |
| The entity-body (if any) sent with an HTTP request or response is in |  | A "representation" is information in a format that can be readily |
| a format and encoding defined by the entity-header fields. |  | communicated from one party to another. A resource representation is |
|  |  | information that reflects the state of that resource, as observed at |
|  |  | some point in the past (e.g., in a response to GET) or to be desired |
|  |  | at some point in the future (e.g., in a PUT request). |
| entity-body = *OCTET |  | Most, but not all, representations transferred via HTTP are intended |
|  |  | to be a representation of the target resource (the resource |
|  |  | identified by the effective request URI). The precise semantics of a |
|  |  | representation are determined by the type of message (request or |
|  |  | response), the request method, the response status code, and the |
|  |  | representation metadata. For example, the above semantic is true for |
|  |  | the representation in any 200 (OK) response to GET and for the |
|  |  | representation in any PUT request. A 200 response to PUT, in |
|  |  | contrast, contains either a representation that describes the |
|  |  | successful action or a representation of the target resource, with |
|  |  | the latter indicated by a Content-Location header field with the same |
|  |  | value as the effective request URI. Likewise, response messages with |
|  |  | an error status code usually contain a representation that describes |
|  |  | the error and what next steps are suggested for resolving it. |
| An entity-body is only present in a message when a message-body is |  | 4.1. Representation Header Fields |
| present, as described in Section 3.3 of [Part1]. The entity-body is |  |  |
| obtained from the message-body by decoding any Transfer-Encoding that |  |  |
| might have been applied to ensure safe and proper transfer of the |  |  |
| message. |  |  |
| 3.2.1. Type |  | Representation header fields define metadata about the representation |
|  |  | data enclosed in the message-body or, if no message-body is present, |
|  |  | about the representation that would have been transferred in a 200 |
|  |  | response to a simultaneous GET request with the same effective |
|  |  | request URI. |
| When an entity-body is included with a message, the data type of that |  | The following header fields are defined as representation metadata: |
| body is determined via the header fields Content-Type and Content- |  |  |
| Encoding. These define a two-layer, ordered encoding model: |  |  |
| entity-body := Content-Encoding( Content-Type( data ) ) |  | Content-Encoding ; Section 6.5 |
|  |  | Content-Language ; Section 6.6 |
|  |  | Content-Location ; Section 6.7 |
|  |  | Content-Type ; Section 6.9 |
|  |  | Expires ; [Part6], Section 3.3 |
|  |  | Last-Modified ; [Part4], Section 6.6 |
| Content-Type specifies the media type of the underlying data. Any |  | 4.2. Representation Data |
| HTTP/1.1 message containing an entity-body SHOULD include a Content- |  |  |
| Type header field defining the media type of that body, unless that |  |  |
| information is unknown. |  |  |
| If the Content-Type header field is not present, it indicates that |  | The representation body associated with an HTTP message is either |
| the sender does not know the media type of the data; recipients MAY |  | provided as the payload body of the message or referred to by the |
| either assume that it is "application/octet-stream" ([RFC2046], |  | message semantics and the effective request URI. The representation |
| Section 4.5.1) or examine the content to determine its type. |  | data is in a format and encoding defined by the representation |
|  |  | metadata header fields. |
| In practice, currently-deployed servers sometimes provide a Content- |  | The data type of the representation data is determined via the header |
| Type header which does not correctly convey the intended |  | fields Content-Type and Content-Encoding. These define a two-layer, |
| interpretation of the content sent, with the result that some clients |  | ordered encoding model: |
| will examine the response body's content and override the specified |  |  |
| type. |  |  |
| Client that do so risk drawing incorrect conclusions, which may |  | representation-data := Content-Encoding( Content-Type( bits ) ) |
| expose additional security risks (e.g., "privilege escalation"). |  |  |
| Implementers are encouraged to provide a means of disabling such |  |  |
| "content sniffing" when it is used. |  |  |
| Content-Encoding may be used to indicate any additional content |  | Content-Type specifies the media type of the underlying data, which |
| codings applied to the data, usually for the purpose of data |  | defines both the data format and how that data SHOULD be processed by |
| compression, that are a property of the requested resource. There is |  | the recipient (within the scope of the request method semantics). |
| no default encoding. |  | Any HTTP/1.1 message containing a payload body SHOULD include a |
|  |  | Content-Type header field defining the media type of the associated |
|  |  | representation unless that metadata is unknown to the sender. If the |
|  |  | Content-Type header field is not present, it indicates that the |
|  |  | sender does not know the media type of the representation; recipients |
|  |  | MAY either assume that the media type is "application/octet-stream" |
|  |  | ([RFC2046], Section 4.5.1) or examine the content to determine its |
|  |  | type. |
| 3.2.2. Entity Length |  | In practice, resource owners do not always properly configure their |
|  |  | origin server to provide the correct Content-Type for a given |
|  |  | representation, with the result that some clients will examine a |
|  |  | response body's content and override the specified type. Clients |
|  |  | that do so risk drawing incorrect conclusions, which might expose |
|  |  | additional security risks (e.g., "privilege escalation"). |
|  |  | Furthermore, it is impossible to determine the sender's intent by |
|  |  | examining the data format: many data formats match multiple media |
|  |  | types that differ only in processing semantics. Implementers are |
|  |  | encouraged to provide a means of disabling such "content sniffing" |
|  |  | when it is used. |
| The entity-length of a message is the length of the message-body |  | Content-Encoding is used to indicate any additional content codings |
| before any transfer-codings have been applied. Section 3.4 of |  | applied to the data, usually for the purpose of data compression, |
| [Part1] defines how the transfer-length of a message-body is |  | that are a property of the representation. If Content-Encoding is |
| determined. |  | not present, then there is no additional encoding beyond that defined |
|  |  | by the Content-Type. |
| 4. Content Negotiation |  | 5. Content Negotiation |
| HTTP responses include a representation which contains information |  | HTTP responses include a representation which contains information |
| for interpretation, whether by a human user or for further |  | for interpretation, whether by a human user or for further |
| processing. Often, the server has different ways of representing the |  | processing. Often, the server has different ways of representing the |
| same information; for example, in different formats, languages, or |  | same information; for example, in different formats, languages, or |
| using different character encodings. |  | using different character encodings. |
| HTTP clients and their users might have different or variable |  | HTTP clients and their users might have different or variable |
| capabilities, characteristics or preferences which would influence |  | capabilities, characteristics or preferences which would influence |
| which representation, among those available from the server, would be |  | which representation, among those available from the server, would be |
| skipping to change at page 15, line 12 |  | skipping to change at page 15, line 10 |
| patterns: some applications use an "active content" pattern, where |  | patterns: some applications use an "active content" pattern, where |
| the server returns active content which runs on the client and, based |  | the server returns active content which runs on the client and, based |
| on client available parameters, selects additional resources to |  | on client available parameters, selects additional resources to |
| invoke. "Transparent Content Negotiation" ([RFC2295]) has also been |  | invoke. "Transparent Content Negotiation" ([RFC2295]) has also been |
| proposed. |  | proposed. |
| These patterns are all widely used, and have trade-offs in |  | These patterns are all widely used, and have trade-offs in |
| applicability and practicality. In particular, when the number of |  | applicability and practicality. In particular, when the number of |
| preferences or capabilities to be expressed by a client are large |  | preferences or capabilities to be expressed by a client are large |
| (such as when many different formats are supported by a user-agent), |  | (such as when many different formats are supported by a user-agent), |
| server-driven negotiation becomes unwieldy, and may not be |  | server-driven negotiation becomes unwieldy, and might not be |
| appropriate. Conversely, when the number of representations to |  | appropriate. Conversely, when the number of representations to |
| choose from is very large, agent-driven negotiation may not be |  | choose from is very large, agent-driven negotiation might not be |
| appropriate. |  | appropriate. |
| Note that in all cases, the supplier of representations has the |  | Note that in all cases, the supplier of representations has the |
| responsibility for determining which representations might be |  | responsibility for determining which representations might be |
| considered to be the "same information". |  | considered to be the "same information". |
| 4.1. Server-driven Negotiation |  | 5.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 |
| skipping to change at page 16, line 9 |  | skipping to change at page 16, line 8 |
| view it on screen or print it on paper?). |  | view it on screen or print it on paper?). |
| 2. Having the user agent describe its capabilities in every request |  | 2. Having the user agent describe its capabilities in every request |
| can be both very inefficient (given that only a small percentage |  | can be both very inefficient (given that only a small percentage |
| of responses have multiple representations) and a potential |  | of responses have multiple representations) and a potential |
| violation of the user's privacy. |  | violation of the user's privacy. |
| 3. It complicates the implementation of an origin server and the |  | 3. It complicates the implementation of an origin server and the |
| algorithms for generating responses to a request. |  | algorithms for generating responses to a request. |
| 4. It may limit a public cache's ability to use the same response |  | 4. It might limit a public cache's ability to use the same response |
| for multiple user's requests. |  | for multiple user's requests. |
| HTTP/1.1 includes the following request-header fields for enabling |  | HTTP/1.1 includes the following 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 6.1), Accept- |
| Charset (Section 5.2), Accept-Encoding (Section 5.3), Accept-Language |  | Charset (Section 6.2), Accept-Encoding (Section 6.3), Accept-Language |
| (Section 5.4), and User-Agent (Section 9.9 of [Part2]). However, an |  | (Section 6.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, |  | Note: In practice, User-Agent based negotiation is fragile, |
| because new clients might not be recognized. |  | because new clients might not be recognized. |
| The Vary header field (Section 3.5 of [Part6]) can be used to express |  | The Vary header field (Section 3.5 of [Part6]) can be used to express |
| the parameters the server uses to select a representation that is |  | the parameters the server uses to select a representation that is |
| subject to server-driven negotiation. |  | subject to server-driven negotiation. |
| 4.2. Agent-driven Negotiation |  | 5.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 |
| the header fields or entity-body of the initial response, with each |  | the header fields or body of the initial response, with each |
| representation identified by its own URI. Selection from among the |  | representation identified by its own URI. Selection from among the |
| representations may be performed automatically (if the user agent is |  | representations can be performed automatically (if the user agent is |
| capable of doing so) or manually by the user selecting from a |  | capable of doing so) or manually by the user selecting from a |
| generated (possibly hypertext) menu. |  | generated (possibly hypertext) menu. |
| Agent-driven negotiation is advantageous when the response would vary |  | Agent-driven negotiation is advantageous when the response would vary |
| over commonly-used dimensions (such as type, language, or encoding), |  | over commonly-used dimensions (such as type, language, or encoding), |
| when the origin server is unable to determine a user agent's |  | when the origin server is unable to determine a user agent's |
| capabilities from examining the request, and generally when public |  | capabilities from examining the request, and generally when public |
| 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 |
| skipping to change at page 17, line 12 |  | skipping to change at page 17, line 10 |
| 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. |
| This specification defines the 300 (Multiple Choices) and 406 (Not |  | This specification defines the 300 (Multiple Choices) and 406 (Not |
| Acceptable) status codes for enabling agent-driven negotiation when |  | Acceptable) status codes for enabling agent-driven negotiation when |
| the server is unwilling or unable to provide a varying response using |  | the server is unwilling or unable to provide a varying response using |
| server-driven negotiation. |  | server-driven negotiation. |
| 5. Header Field Definitions |  | 6. Header Field Definitions |
| This section defines the syntax and semantics of HTTP/1.1 header |  | This section defines the syntax and semantics of HTTP/1.1 header |
| fields related to the payload of messages. |  | fields related to the payload of messages. |
| For entity-header fields, both sender and recipient refer to either |  | 6.1. Accept |
| the client or the server, depending on who sends and who receives the |  |  |
| entity. |  |  |
| 5.1. Accept |  |  |
| The "Accept" request-header field can be used by user agents to |  | The "Accept" request-header field can be used by user agents to |
| specify response media types that are acceptable. Accept headers can |  | specify response media types that are acceptable. Accept headers can |
| be used to indicate that the request is specifically limited to a |  | be used to indicate that the request is specifically limited to a |
| small set of desired types, as in the case of a request for an in- |  | small set of desired types, as in the case of a request for an in- |
| line image. |  | line image. |
| Accept = "Accept" ":" OWS Accept-v |  | Accept = "Accept" ":" OWS Accept-v |
| Accept-v = #( media-range [ accept-params ] ) |  | Accept-v = #( media-range [ accept-params ] ) |
| skipping to change at page 18, line 19 |  | skipping to change at page 18, line 12 |
| to be unlikely given the lack of any "q" parameters in the IANA |  | to be unlikely given the lack of any "q" parameters in the IANA |
| media type registry and the rare usage of any media type |  | media type registry and the rare usage of any media type |
| parameters in Accept. Future media types are discouraged from |  | parameters in Accept. Future media types are discouraged from |
| registering any parameter named "q". |  | registering any parameter named "q". |
| The example |  | The example |
| Accept: audio/*; q=0.2, audio/basic |  | Accept: audio/*; q=0.2, audio/basic |
| SHOULD be interpreted as "I prefer audio/basic, but send me any audio |  | SHOULD be interpreted as "I prefer audio/basic, but send me any audio |
| type if it is the best available after an 80% mark-down in quality." |  | type if it is the best available after an 80% mark-down in quality". |
| If no Accept header field is present, then it is assumed that the |  | If no Accept header field is present, then it is assumed that the |
| client accepts all media types. If an Accept header field is |  | client accepts all media types. If an Accept header field is |
| present, and if the server cannot send a response which is acceptable |  | present, and if the server cannot send a response which is acceptable |
| according to the combined Accept field value, then the server SHOULD |  | according to the combined Accept field value, then the server SHOULD |
| send a 406 (Not Acceptable) response. |  | send a 406 (Not Acceptable) response. |
| A more elaborate example is |  | A more elaborate example is |
| Accept: text/plain; q=0.5, text/html, |  | Accept: text/plain; q=0.5, text/html, |
| text/x-dvi; q=0.8, text/x-c |  | text/x-dvi; q=0.8, text/x-c |
| Verbally, this would be interpreted as "text/html and text/x-c are |  | Verbally, this would be interpreted as "text/html and text/x-c are |
| the preferred media types, but if they do not exist, then send the |  | the preferred media types, but if they do not exist, then send the |
| text/x-dvi entity, and if that does not exist, send the text/plain |  | text/x-dvi representation, and if that does not exist, send the text/ |
| entity." |  | plain representation". |
| Media ranges can be overridden by more specific media ranges or |  | Media ranges can be overridden by more specific media ranges or |
| specific media types. If more than one media range applies to a |  | specific media types. If more than one media range applies to a |
| given type, the most specific reference has precedence. For example, |  | given type, the most specific reference has precedence. For example, |
| Accept: text/*, text/html, text/html;level=1, */* |  | Accept: text/*, text/html, text/html;level=1, */* |
| have the following precedence: |  | have the following precedence: |
| 1. text/html;level=1 |  | 1. text/html;level=1 |
| skipping to change at page 19, line 29 |  | skipping to change at page 19, line 23 |
| | image/jpeg | 0.5 | |  | | image/jpeg | 0.5 | |
| | text/html;level=2 | 0.4 | |  | | text/html;level=2 | 0.4 | |
| | text/html;level=3 | 0.7 | |  | | text/html;level=3 | 0.7 | |
| +-------------------+---------------+ |  | +-------------------+---------------+ |
| Note: A user agent might be provided with a default set of quality |  | Note: A user agent might be provided with a default set of quality |
| values for certain media ranges. However, unless the user agent is a |  | values for certain media ranges. However, unless the user agent is a |
| closed system which cannot interact with other rendering agents, this |  | closed system which cannot interact with other rendering agents, this |
| default set ought to be configurable by the user. |  | default set ought to be configurable by the user. |
| 5.2. Accept-Charset |  | 6.2. Accept-Charset |
| The "Accept-Charset" request-header field can be used by user agents |  | The "Accept-Charset" request-header field can be used by user agents |
| to indicate what response character sets are acceptable. This field |  | to indicate what response character sets are acceptable. This field |
| allows clients capable of understanding more comprehensive or |  | allows clients capable of understanding more comprehensive or |
| special-purpose character sets to signal that capability to a server |  | special-purpose character sets to signal that capability to a server |
| which is capable of representing documents in those character sets. |  | which is capable of representing documents in those character sets. |
| Accept-Charset = "Accept-Charset" ":" OWS |  | Accept-Charset = "Accept-Charset" ":" OWS |
| Accept-Charset-v |  | Accept-Charset-v |
| Accept-Charset-v = 1#( ( charset / "*" ) |  | Accept-Charset-v = 1#( ( charset / "*" ) |
| skipping to change at page 20, line 15 |  | skipping to change at page 20, line 8 |
| explicitly mentioned get a quality value of 0, except for ISO-8859-1, |  | explicitly mentioned get a quality value of 0, except for ISO-8859-1, |
| which gets a quality value of 1 if not explicitly mentioned. |  | which gets a quality value of 1 if not explicitly mentioned. |
| If no Accept-Charset header is present, the default is that any |  | If no Accept-Charset header is present, the default is that any |
| character set is acceptable. If an Accept-Charset header is present, |  | character set is acceptable. If an Accept-Charset header is present, |
| and if the server cannot send a response which is acceptable |  | and if the server cannot send a response which is acceptable |
| according to the Accept-Charset header, then the server SHOULD send |  | according to the Accept-Charset header, then the server SHOULD send |
| an error response with the 406 (Not Acceptable) status code, though |  | an error response with the 406 (Not Acceptable) status code, though |
| the sending of an unacceptable response is also allowed. |  | the sending of an unacceptable response is also allowed. |
| 5.3. Accept-Encoding |  | 6.3. Accept-Encoding |
| The "Accept-Encoding" request-header field can be used by user agents |  | The "Accept-Encoding" request-header field can be used by user agents |
| to indicate what response content-codings (Section 2.2) are |  | to indicate what response content-codings (Section 2.2) are |
| acceptable in the response. |  | acceptable in the response. |
| Accept-Encoding = "Accept-Encoding" ":" OWS |  | Accept-Encoding = "Accept-Encoding" ":" OWS |
| Accept-Encoding-v |  | Accept-Encoding-v |
| Accept-Encoding-v = |  | Accept-Encoding-v = |
| #( codings [ OWS ";" OWS "q=" qvalue ] ) |  | #( codings [ OWS ";" OWS "q=" qvalue ] ) |
| codings = ( content-coding / "*" ) |  | codings = ( content-coding / "*" ) |
| skipping to change at page 20, line 45 |  | skipping to change at page 20, line 38 |
| Accept-Encoding: * |  | Accept-Encoding: * |
| Accept-Encoding: compress;q=0.5, gzip;q=1.0 |  | Accept-Encoding: compress;q=0.5, gzip;q=1.0 |
| Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0 |  | Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0 |
| A server tests whether a content-coding is acceptable, according to |  | A server tests whether a content-coding is acceptable, according to |
| an Accept-Encoding field, using these rules: |  | an Accept-Encoding field, using these rules: |
| 1. If the content-coding is one of the content-codings listed in the |  | 1. If the content-coding is one of the content-codings listed in the |
| Accept-Encoding field, then it is acceptable, unless it is |  | Accept-Encoding field, then it is acceptable, unless it is |
| accompanied by a qvalue of 0. (As defined in Section 6.4 of |  | accompanied by a qvalue of 0. (As defined in Section 6.4 of |
| [Part1], a qvalue of 0 means "not acceptable.") |  | [Part1], a qvalue of 0 means "not acceptable".) |
| 2. The special "*" symbol in an Accept-Encoding field matches any |  | 2. The special "*" symbol in an Accept-Encoding field matches any |
| available content-coding not explicitly listed in the header |  | available content-coding not explicitly listed in the header |
| field. |  | field. |
| 3. If multiple content-codings are acceptable, then the acceptable |  | 3. If multiple content-codings are acceptable, then the acceptable |
| content-coding with the highest non-zero qvalue is preferred. |  | content-coding with the highest non-zero qvalue is preferred. |
| 4. The "identity" content-coding is always acceptable, unless |  | 4. The "identity" content-coding is always acceptable, unless |
| specifically refused because the Accept-Encoding field includes |  | specifically refused because the Accept-Encoding field includes |
| skipping to change at page 21, line 39 |  | skipping to change at page 21, line 30 |
| codings commonly understood by HTTP/1.0 clients (i.e., "gzip" and |  | codings commonly understood by HTTP/1.0 clients (i.e., "gzip" and |
| "compress") are preferred; some older clients improperly display |  | "compress") are preferred; some older clients improperly display |
| messages sent with other content-codings. The server might also |  | messages sent with other content-codings. The server might also |
| make this decision based on information about the particular user- |  | make this decision based on information about the particular user- |
| agent or client. |  | agent or client. |
| Note: Most HTTP/1.0 applications do not recognize or obey qvalues |  | Note: Most HTTP/1.0 applications do not recognize or obey qvalues |
| associated with content-codings. This means that qvalues will not |  | associated with content-codings. This means that qvalues will not |
| work and are not permitted with x-gzip or x-compress. |  | work and are not permitted with x-gzip or x-compress. |
| 5.4. Accept-Language |  | 6.4. Accept-Language |
| The "Accept-Language" request-header field can be used by user agents |  | The "Accept-Language" request-header field can be used by user agents |
| to indicate the set of natural languages that are preferred in the |  | to indicate the set of natural languages that are preferred in the |
| response. Language tags are defined in Section 2.4. |  | response. Language tags are defined in Section 2.4. |
| Accept-Language = "Accept-Language" ":" OWS |  | Accept-Language = "Accept-Language" ":" OWS |
| Accept-Language-v |  | Accept-Language-v |
| Accept-Language-v = |  | Accept-Language-v = |
| 1#( language-range [ OWS ";" OWS "q=" qvalue ] ) |  | 1#( language-range [ OWS ";" OWS "q=" qvalue ] ) |
| language-range = |  | language-range = |
| <language-range, defined in [RFC4647], Section 2.1> |  | <language-range, defined in [RFC4647], Section 2.1> |
| Each language-range can be given an associated quality value which |  | Each language-range can be given an associated quality value which |
| 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." (see also Section 2.3 of [RFC4647]) |  | other types of English". (see also Section 2.3 of [RFC4647]) |
| For matching, Section 3 of [RFC4647] defines several matching |  | For matching, Section 3 of [RFC4647] defines several matching |
| schemes. Implementations can offer the most appropriate matching |  | schemes. Implementations can offer the most appropriate matching |
| scheme for their requirements. |  | scheme for their requirements. |
| Note: The "Basic Filtering" scheme ([RFC4647], Section 3.3.1) is |  | Note: The "Basic Filtering" scheme ([RFC4647], Section 3.3.1) is |
| identical to the matching scheme that was previously defined in |  | identical to the matching scheme that was previously defined in |
| Section 14.4 of [RFC2616]. |  | Section 14.4 of [RFC2616]. |
| 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 8.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 |
| the request. |  | the request. |
| Note: When making the choice of linguistic preference available to |  | Note: When making the choice of linguistic preference available to |
| the user, we remind implementors of the fact that users are not |  | the user, we remind implementors of the fact that users are not |
| familiar with the details of language matching as described above, |  | familiar with the details of language matching as described above, |
| and should provide appropriate guidance. As an example, users |  | and ought to be provided appropriate guidance. As an example, |
| might assume that on selecting "en-gb", they will be served any |  | users might assume that on selecting "en-gb", they will be served |
| kind of English document if British English is not available. A |  | any kind of English document if British English is not available. |
| user agent might suggest in such a case to add "en" to get the |  | A user agent might suggest in such a case to add "en" to get the |
| best matching behavior. |  | best matching behavior. |
| 5.5. Content-Encoding |  | 6.5. Content-Encoding |
| The "Content-Encoding" entity-header field indicates what content- |  | The "Content-Encoding" header field indicates what content-codings |
| codings have been applied to the entity-body, and thus what decoding |  | have been applied to the representation, and thus what decoding |
| mechanisms must be applied in order to obtain the media-type |  | mechanisms must be applied in order to obtain the media-type |
| referenced by the Content-Type header field. Content-Encoding is |  | referenced by the Content-Type header field. Content-Encoding is |
| primarily used to allow a document to be compressed without losing |  | primarily used to allow a representation to be compressed without |
| the identity of its underlying media type. |  | losing the identity of its underlying media type. |
| Content-Encoding = "Content-Encoding" ":" OWS Content-Encoding-v |  | Content-Encoding = "Content-Encoding" ":" OWS Content-Encoding-v |
| Content-Encoding-v = 1#content-coding |  | Content-Encoding-v = 1#content-coding |
| Content codings are defined in Section 2.2. An example of its use is |  | Content codings are defined in Section 2.2. An example of its use is |
| Content-Encoding: gzip |  | Content-Encoding: gzip |
| The content-coding is a characteristic of the entity identified by |  | The content-coding is a characteristic of the representation. |
| the Effective Request URI (Section 4.3 of [Part1]). Typically, the |  | Typically, the representation body is stored with this encoding and |
| entity-body is stored with this encoding and is only decoded before |  | is only decoded before rendering or analogous usage. However, a non- |
| rendering or analogous usage. However, a non-transparent proxy MAY |  | transparent proxy MAY modify the content-coding if the new coding is |
| modify the content-coding if the new coding is known to be acceptable |  | known to be acceptable to the recipient, unless the "no-transform" |
| to the recipient, unless the "no-transform" cache-control directive |  | cache-control directive is present in the message. |
| is present in the message. |  |  |
| If the content-coding of an entity is not "identity", then the |  | If the content-coding of a representation is not "identity", then the |
| response MUST include a Content-Encoding entity-header (Section 5.5) |  | representation metadata MUST include a Content-Encoding header field |
| that lists the non-identity content-coding(s) used. |  | (Section 6.5) that lists the non-identity content-coding(s) used. |
| If the content-coding of an entity in a request message is not |  | If the content-coding of a representation in a request message is not |
| acceptable to the origin server, the server SHOULD respond with a |  | acceptable to the origin server, the server SHOULD respond with a |
| status code of 415 (Unsupported Media Type). |  | status code of 415 (Unsupported Media Type). |
| If multiple encodings have been applied to an entity, the content |  | If multiple encodings have been applied to a representation, the |
| codings MUST be listed in the order in which they were applied. |  | content codings MUST be listed in the order in which they were |
| Additional information about the encoding parameters MAY be provided |  | applied. Additional information about the encoding parameters MAY be |
| by other entity-header fields not defined by this specification. |  | provided by other header fields not defined by this specification. |
| 5.6. Content-Language |  | 6.6. Content-Language |
| The "Content-Language" entity-header field describes the natural |  | The "Content-Language" header field describes the natural language(s) |
| language(s) of the intended audience for the entity. Note that this |  | of the intended audience for the representation. Note that this |
| might not be equivalent to all the languages used within the entity- |  | might not be equivalent to all the languages used within the |
| body. |  | representation. |
| Content-Language = "Content-Language" ":" OWS Content-Language-v |  | Content-Language = "Content-Language" ":" OWS Content-Language-v |
| Content-Language-v = 1#language-tag |  | Content-Language-v = 1#language-tag |
| Language tags are defined in Section 2.4. The primary purpose of |  | Language tags are defined in Section 2.4. The primary purpose of |
| Content-Language is to allow a user to identify and differentiate |  | Content-Language is to allow a user to identify and differentiate |
| entities according to the user's own preferred language. Thus, if |  | representations according to the user's own preferred language. |
| the body content is intended only for a Danish-literate audience, the |  | Thus, if the body content is intended only for a Danish-literate |
| appropriate field is |  | audience, the appropriate field is |
| Content-Language: da |  | Content-Language: da |
| If no Content-Language is specified, the default is that the content |  | If no Content-Language is specified, the default is that the content |
| is intended for all language audiences. This might mean that the |  | is intended for all language audiences. This might mean that the |
| sender does not consider it to be specific to any natural language, |  | sender does not consider it to be specific to any natural language, |
| or that the sender does not know for which language it is intended. |  | or that the sender does not know for which language it is intended. |
| Multiple languages MAY be listed for content that is intended for |  | Multiple languages MAY be listed for content that is intended for |
| multiple audiences. For example, a rendition of the "Treaty of |  | multiple audiences. For example, a rendition of the "Treaty of |
| Waitangi," presented simultaneously in the original Maori and English |  | Waitangi", presented simultaneously in the original Maori and English |
| versions, would call for |  | versions, would call for |
| Content-Language: mi, en |  | Content-Language: mi, en |
| However, just because multiple languages are present within an entity |  | However, just because multiple languages are present within a |
| does not mean that it is intended for multiple linguistic audiences. |  | representation does not mean that it is intended for multiple |
| An example would be a beginner's language primer, such as "A First |  | linguistic audiences. An example would be a beginner's language |
| Lesson in Latin," which is clearly intended to be used by an English- |  | primer, such as "A First Lesson in Latin", which is clearly intended |
| literate audience. In this case, the Content-Language would properly |  | to be used by an English-literate audience. In this case, the |
| only include "en". |  | Content-Language would properly only include "en". |
| Content-Language MAY be applied to any media type -- it is not |  | Content-Language MAY be applied to any media type -- it is not |
| limited to textual documents. |  | limited to textual documents. |
| 5.7. Content-Location |  | 6.7. Content-Location |
| The "Content-Location" entity-header field is used to supply a URI |  |  |
| for the entity in the message when it is accessible from a location |  |  |
| separate from the requested resource's URI. |  |  |
| A server SHOULD provide a Content-Location for the variant |  | The "Content-Location" header field supplies a URI that can be used |
| corresponding to the response entity, especially in the case where a |  | as a specific identifier for the representation in this message. In |
| resource has multiple entities associated with it, and those entities |  | other words, if one were to perform a GET on this URI at the time of |
| actually have separate locations by which they might be individually |  | this message's generation, then a 200 response would contain the same |
| accessed, the server SHOULD provide a Content-Location for the |  | representation that is enclosed as payload in this message. |
| particular variant which is returned. |  |  |
| Content-Location = "Content-Location" ":" OWS |  | Content-Location = "Content-Location" ":" OWS |
| Content-Location-v |  | Content-Location-v |
| Content-Location-v = |  | Content-Location-v = |
| absolute-URI / partial-URI |  | absolute-URI / partial-URI |
| The Content-Location value is not a replacement for the Effective |  | The Content-Location value is not a replacement for the effective |
| Request URI (Section 4.3 of [Part1]); it is only a statement of the |  | Request URI (Section 4.3 of [Part1]). It is representation metadata. |
| location of the resource corresponding to this particular entity at |  | It has the same syntax and semantics as the header field of the same |
| the time of the request. Future requests MAY may be addressed to the |  | name defined for MIME body parts in Section 4 of [RFC2557]. However, |
| Content-Location URI if the desire is to identify the source of that |  | its appearance in an HTTP message has some special implications for |
| particular entity. |  | HTTP recipients. |
| Section 6.1 of [Part2] describes how clients may process the Content- |  | If Content-Location is included in a response message and its value |
| Location header field. |  | is the same as the effective request URI, then the response payload |
|  |  | SHOULD be considered the current representation of that resource. |
|  |  | For a GET or HEAD request, this is the same as the default semantics |
|  |  | when no Content-Location is provided by the server. For a state- |
|  |  | changing method like PUT or POST, it implies that the server's |
|  |  | response contains the new representation of that resource, thereby |
|  |  | distinguishing it from representations that might only report about |
|  |  | the action (e.g., "It worked!"). This allows authoring applications |
|  |  | to update their local copies without the need for a subsequent GET |
|  |  | request. |
| A cache cannot assume that an entity with a Content-Location |  | If Content-Location is included in a response message and its value |
| different from the URI used to retrieve it can be used to respond to |  | differs from the effective request URI, then the origin server is |
| later requests on that Content-Location URI. However, the Content- |  | informing recipients that this representation has its own, presumably |
| Location can be used to differentiate between multiple entities |  | more specific, identifier. For a GET or HEAD request, this is an |
| retrieved from a single requested resource, as described in Section |  | indication that the effective request URI identifies a resource that |
| 2.7 of [Part6]. |  | is subject to content negotiation and the representation selected for |
|  |  | this response can also be found at the identified URI. For other |
|  |  | methods, such a Content-Location indicates that this representation |
|  |  | contains a report on the action's status and the same report is |
|  |  | available (for future access with GET) at the given URI. For |
|  |  | example, a purchase transaction made via the POST method might |
|  |  | include a receipt document as the payload of the 200 response; the |
|  |  | Content-Location value provides an identifier for retrieving a copy |
|  |  | of that same receipt in the future. |
| If the Content-Location is a relative URI, the relative URI is |  | If Content-Location is included in a request message, then it MAY be |
| interpreted relative to the Effective Request URI. |  | interpreted by the origin server as an indication of where the user |
|  |  | agent originally obtained the content of the enclosed representation |
|  |  | (prior to any subsequent modification of the content by that user |
|  |  | agent). In other words, the user agent is providing the same |
|  |  | representation metadata that it received with the original |
|  |  | representation. However, such interpretation MUST NOT be used to |
|  |  | alter the semantics of the method requested by the client. For |
|  |  | example, if a client makes a PUT request on a negotiated resource and |
|  |  | the origin server accepts that PUT (without redirection), then the |
|  |  | new set of values for that resource is expected to be consistent with |
|  |  | the one representation supplied in that PUT; the Content-Location |
|  |  | cannot be used as a form of reverse content selection that identifies |
|  |  | only one of the negotiated representations to be updated. If the |
|  |  | user agent had wanted the latter semantics, it would have applied the |
|  |  | PUT directly to the Content-Location URI. |
| The meaning of the Content-Location header in requests is undefined; |  | A Content-Location field received in a request message is transitory |
| servers are free to ignore it in those cases. |  | information that SHOULD NOT be saved with other representation |
|  |  | metadata for use in later responses. The Content-Location's value |
|  |  | might be saved for use in other contexts, such as within source links |
|  |  | or other metadata. |
| 5.8. Content-MD5 |  | A cache cannot assume that a representation with a Content-Location |
|  |  | different from the URI used to retrieve it can be used to respond to |
|  |  | later requests on that Content-Location URI. |
| The "Content-MD5" entity-header field, as defined in [RFC1864], is an |  | If the Content-Location value is a partial URI, the partial URI is |
| MD5 digest of the entity-body that provides an end-to-end message |  | interpreted relative to the effective request URI. |
| integrity check (MIC) of the entity-body. Note that a MIC is good |  |  |
| for detecting accidental modification of the entity-body in transit, |  | 6.8. Content-MD5 |
| but is not proof against malicious attacks. |  |  |
|  |  | The "Content-MD5" header field, as defined in [RFC1864], is an MD5 |
|  |  | digest of the payload body that provides an end-to-end message |
|  |  | integrity check (MIC) of the payload body (the message-body after any |
|  |  | transfer-coding is decoded). Note that a MIC is good for detecting |
|  |  | accidental modification of the payload body in transit, but is not |
|  |  | proof against malicious attacks. |
| Content-MD5 = "Content-MD5" ":" OWS Content-MD5-v |  | Content-MD5 = "Content-MD5" ":" OWS Content-MD5-v |
| Content-MD5-v = <base64 of 128 bit MD5 digest as per [RFC1864]> |  | Content-MD5-v = <base64 of 128 bit MD5 digest as per [RFC1864]> |
| The Content-MD5 header field MAY be generated by an origin server or |  | The Content-MD5 header field MAY be generated by an origin server or |
| client to function as an integrity check of the entity-body. Only |  | client to function as an integrity check of the payload body. Only |
| origin servers or clients MAY generate the Content-MD5 header field; |  | origin servers or user agents MAY generate the Content-MD5 header |
| proxies and gateways MUST NOT generate it, as this would defeat its |  | field; proxies and gateways MUST NOT generate it, as this would |
| value as an end-to-end integrity check. Any recipient of the entity- |  | defeat its value as an end-to-end integrity check. Any recipient MAY |
| body, including gateways and proxies, MAY check that the digest value |  | check that the digest value in this header field matches a |
| in this header field matches that of the entity-body as received. |  | corresponding digest calculated on payload body as received. |
| The MD5 digest is computed based on the content of the entity-body, |  |  |
| including any content-coding that has been applied, but not including |  |  |
| any transfer-encoding applied to the message-body. If the message is |  |  |
| received with a transfer-encoding, that encoding MUST be removed |  |  |
| prior to checking the Content-MD5 value against the received entity. |  |  |
| This has the result that the digest is computed on the octets of the |  | The MD5 digest is computed based on the content of the payload body, |
| entity-body exactly as, and in the order that, they would be sent if |  | including any content-coding, but not including any transfer-coding |
| no transfer-encoding were being applied. |  | applied to the message-body because such transfer-codings might be |
|  |  | applied or removed anywhere along the request/response chain. If the |
|  |  | message is received with a transfer-coding, that encoding MUST be |
|  |  | decoded prior to checking the Content-MD5 value against the received |
|  |  | payload. |
| HTTP extends RFC 1864 to permit the digest to be computed for MIME |  | HTTP extends RFC 1864 to permit the digest to be computed for MIME |
| composite media-types (e.g., multipart/* and message/rfc822), but |  | composite media-types (e.g., multipart/* and message/rfc822), but |
| this does not change how the digest is computed as defined in the |  | this does not change how the digest is computed as defined in the |
| preceding paragraph. |  | preceding paragraph. |
| There are several consequences of this. The entity-body for |  | There are several consequences of this. The payload for composite |
| composite types MAY contain many body-parts, each with its own MIME |  | types MAY contain many body-parts, each with its own MIME and HTTP |
| and HTTP headers (including Content-MD5, Content-Transfer-Encoding, |  | headers (including Content-MD5, Content-Transfer-Encoding, and |
| and Content-Encoding headers). If a body-part has a Content- |  | Content-Encoding headers). If a body-part has a Content-Transfer- |
| Transfer-Encoding or Content-Encoding header, it is assumed that the |  | Encoding or Content-Encoding header, it is assumed that the content |
| content of the body-part has had the encoding applied, and the body- |  | of the body-part has had the encoding applied, and the body-part is |
| part is included in the Content-MD5 digest as is -- i.e., after the |  | 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. |
| 5.9. Content-Type |  | 6.9. Content-Type |
| The "Content-Type" entity-header field indicates the media type of |  | The "Content-Type" header field indicates the media type of the |
| the entity-body. In the case of responses to the HEAD method, the |  | representation. In the case of responses to the HEAD method, the |
| media type is that which would have been sent had the request been a |  | media type is that which would have been sent had the request been a |
| GET. |  | GET. |
| Content-Type = "Content-Type" ":" OWS Content-Type-v |  | Content-Type = "Content-Type" ":" OWS Content-Type-v |
| Content-Type-v = media-type |  | Content-Type-v = media-type |
| Media types are defined in Section 2.3. An example of the field is |  | Media types are defined in Section 2.3. An example of the field is |
| Content-Type: text/html; charset=ISO-8859-4 |  | Content-Type: text/html; charset=ISO-8859-4 |
| Further discussion of methods for identifying the media type of an |  | Further discussion of Content-Type is provided in Section 4.2. |
| entity is provided in Section 3.2.1. |  |  |
| 6. IANA Considerations |  | 7. IANA Considerations |
| 6.1. Message Header Registration |  | 7.1. Header Field Registration |
| The Message Header Registry located at <http://www.iana.org/ |  | The Message Header Field Registry located at <http://www.iana.org/ |
| assignments/message-headers/message-header-index.html> should be |  | assignments/message-headers/message-header-index.html> shall be |
| updated with the permanent registrations below (see [RFC3864]): |  | updated with the permanent registrations below (see [RFC3864]): |
| +---------------------+----------+----------+--------------+ |  | +---------------------+----------+----------+--------------+ |
| | Header Field Name | Protocol | Status | Reference | |  | | Header Field Name | Protocol | Status | Reference | |
| +---------------------+----------+----------+--------------+ |  | +---------------------+----------+----------+--------------+ |
| | Accept | http | standard | Section 5.1 | |  | | Accept | http | standard | Section 6.1 | |
| | Accept-Charset | http | standard | Section 5.2 | |  | | Accept-Charset | http | standard | Section 6.2 | |
| | Accept-Encoding | http | standard | Section 5.3 | |  | | Accept-Encoding | http | standard | Section 6.3 | |
| | Accept-Language | http | standard | Section 5.4 | |  | | Accept-Language | http | standard | Section 6.4 | |
| | Content-Disposition | http | | Appendix B.1 | |  | | Content-Disposition | http | standard | Appendix B.1 | |
| | Content-Encoding | http | standard | Section 5.5 | |  | | Content-Encoding | http | standard | Section 6.5 | |
| | Content-Language | http | standard | Section 5.6 | |  | | Content-Language | http | standard | Section 6.6 | |
| | Content-Location | http | standard | Section 5.7 | |  | | Content-Location | http | standard | Section 6.7 | |
| | Content-MD5 | http | standard | Section 5.8 | |  | | Content-MD5 | http | standard | Section 6.8 | |
| | Content-Type | http | standard | Section 5.9 | |  | | Content-Type | http | standard | Section 6.9 | |
| | MIME-Version | http | | Appendix A.1 | |  | | MIME-Version | http | standard | Appendix A.1 | |
| +---------------------+----------+----------+--------------+ |  | +---------------------+----------+----------+--------------+ |
| The change controller is: "IETF (iesg@ietf.org) - Internet |  | The change controller is: "IETF (iesg@ietf.org) - Internet |
| Engineering Task Force". |  | Engineering Task Force". |
| 6.2. Content Coding Registry |  | 7.2. Content Coding Registry |
| The registration procedure for HTTP Content Codings is now defined by |  | The registration procedure for HTTP Content Codings is now defined by |
| Section 2.2.1 of this document. |  | Section 2.2.1 of this document. |
| The HTTP Content Codings Registry located at |  | The HTTP Content Codings Registry located at |
| <http://www.iana.org/assignments/http-parameters> should be updated |  | <http://www.iana.org/assignments/http-parameters> shall be updated |
| with the registration below: |  | with the registration below: |
| +----------+-----------------------------------------+--------------+ |  | +----------+-----------------------------------------+--------------+ |
| | Name | Description | Reference | |  | | Name | Description | Reference | |
| +----------+-----------------------------------------+--------------+ |  | +----------+-----------------------------------------+--------------+ |
| | compress | UNIX "compress" program method | Section | |  | | compress | UNIX "compress" program method | Section | |
| | | | 6.2.2.1 of | |  | | | | 6.2.2.1 of | |
| | | | [Part1] | |  | | | | [Part1] | |
| | deflate | "deflate" compression mechanism | Section | |  | | deflate | "deflate" compression mechanism | Section | |
| | | ([RFC1951]) used inside the "zlib" data | 6.2.2.2 of | |  | | | ([RFC1951]) used inside the "zlib" data | 6.2.2.2 of | |
| | | format ([RFC1950]) | [Part1] | |  | | | format ([RFC1950]) | [Part1] | |
| | gzip | Same as GNU zip [RFC1952] | Section | |  | | gzip | Same as GNU zip [RFC1952] | Section | |
| | | | 6.2.2.3 of | |  | | | | 6.2.2.3 of | |
| | | | [Part1] | |  | | | | [Part1] | |
| | identity | No transformation | Section 2.2 | |  | | identity | No transformation | Section 2.2 | |
| +----------+-----------------------------------------+--------------+ |  | +----------+-----------------------------------------+--------------+ |
| 7. Security Considerations |  | 8. Security Considerations |
| This section is meant to inform application developers, information |  | This section is meant to inform application developers, information |
| providers, and users of the security limitations in HTTP/1.1 as |  | providers, and users of the security limitations in HTTP/1.1 as |
| described by this document. The discussion does not include |  | described by this document. The discussion does not include |
| definitive solutions to the problems revealed, though it does make |  | definitive solutions to the problems revealed, though it does make |
| some suggestions for reducing security risks. |  | some suggestions for reducing security risks. |
| 7.1. Privacy Issues Connected to Accept Headers |  | 8.1. Privacy Issues Connected to Accept Headers |
| Accept request-headers can reveal information about the user to all |  | Accept request-headers can reveal information about the user to all |
| servers which are accessed. The Accept-Language header in particular |  | servers which are accessed. The Accept-Language header in particular |
| can reveal information the user would consider to be of a private |  | can reveal information the user would consider to be of a private |
| nature, because the understanding of particular languages is often |  | nature, because the understanding of particular languages is often |
| strongly correlated to the membership of a particular ethnic group. |  | strongly correlated to the membership of a particular ethnic group. |
| User agents which offer the option to configure the contents of an |  | User agents which offer the option to configure the contents of an |
| Accept-Language header to be sent in every request are strongly |  | Accept-Language header to be sent in every request are strongly |
| encouraged to let the configuration process include a message which |  | encouraged to let the configuration process include a message which |
| makes the user aware of the loss of privacy involved. |  | makes the user aware of the loss of privacy involved. |
| skipping to change at page 28, line 42 |  | skipping to change at page 29, line 18 |
| many users not behind a proxy, the network address of the host |  | many users not behind a proxy, the network address of the host |
| running the user agent will also serve as a long-lived user |  | running the user agent will also serve as a long-lived user |
| identifier. In environments where proxies are used to enhance |  | identifier. In environments where proxies are used to enhance |
| privacy, user agents ought to be conservative in offering accept |  | privacy, user agents ought to be conservative in offering accept |
| header configuration options to end users. As an extreme privacy |  | header configuration options to end users. As an extreme privacy |
| measure, proxies could filter the accept headers in relayed requests. |  | measure, proxies could filter the accept headers in relayed requests. |
| General purpose user agents which provide a high degree of header |  | General purpose user agents which provide a high degree of header |
| configurability SHOULD warn users about the loss of privacy which can |  | configurability SHOULD warn users about the loss of privacy which can |
| be involved. |  | be involved. |
| 7.2. Content-Disposition Issues |  | 8.2. Content-Disposition Issues |
| [RFC2183], from which the often implemented Content-Disposition (see |  | [RFC2183], from which the often implemented Content-Disposition (see |
| Appendix B.1) header in HTTP is derived, has a number of very serious |  | Appendix B.1) header in HTTP is derived, has a number of very serious |
| security considerations. Content-Disposition is not part of the HTTP |  | security considerations. Content-Disposition is not part of the HTTP |
| standard, but since it is widely implemented, we are documenting its |  | standard, but since it is widely implemented, we are documenting its |
| use and risks for implementors. See Section 5 of [RFC2183] for |  | use and risks for implementors. See Section 5 of [RFC2183] for |
| details. |  | details. |
| 8. Acknowledgments |  | 9. Acknowledgments |
| 9. References |  | 10. References |
| 9.1. Normative References |  | 10.1. Normative References |
| [ISO-8859-1] International Organization for Standardization, |  | [ISO-8859-1] International Organization for Standardization, |
| "Information technology -- 8-bit single-byte coded |  | "Information technology -- 8-bit single-byte coded |
| graphic character sets -- Part 1: Latin alphabet No. |  | graphic character sets -- Part 1: Latin alphabet No. |
| 1", ISO/IEC 8859-1:1998, 1998. |  | 1", ISO/IEC 8859-1:1998, 1998. |
| [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., |
| Ed., and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, |  | Ed., and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, |
| Connections, and Message Parsing", |  | Connections, and Message Parsing", |
| draft-ietf-httpbis-p1-messaging-10 (work in progress), |  | draft-ietf-httpbis-p1-messaging-11 (work in progress), |
| July 2010. |  | August 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., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., |
| Ed., and J. Reschke, Ed., "HTTP/1.1, part 2: Message |  | Ed., and J. Reschke, Ed., "HTTP/1.1, part 2: Message |
| Semantics", draft-ietf-httpbis-p2-semantics-10 (work in |  | Semantics", draft-ietf-httpbis-p2-semantics-11 (work in |
| progress), July 2010. |  | progress), August 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., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., |
| Ed., and J. Reschke, Ed., "HTTP/1.1, part 4: |  | Ed., and J. Reschke, Ed., "HTTP/1.1, part 4: |
| Conditional Requests", |  | Conditional Requests", |
| draft-ietf-httpbis-p4-conditional-10 (work in |  | draft-ietf-httpbis-p4-conditional-11 (work in |
| progress), July 2010. |  | progress), August 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., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., |
| Ed., and J. Reschke, Ed., "HTTP/1.1, part 5: Range |  | Ed., and J. Reschke, Ed., "HTTP/1.1, part 5: Range |
| Requests and Partial Responses", |  | Requests and Partial Responses", |
| draft-ietf-httpbis-p5-range-10 (work in progress), |  | draft-ietf-httpbis-p5-range-11 (work in progress), |
| July 2010. |  | August 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., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., |
| Ed., Nottingham, M., Ed., and J. Reschke, Ed., |  | Ed., Nottingham, M., Ed., and J. Reschke, Ed., |
| "HTTP/1.1, part 6: Caching", |  | "HTTP/1.1, part 6: Caching", |
| draft-ietf-httpbis-p6-cache-10 (work in progress), |  | draft-ietf-httpbis-p6-cache-11 (work in progress), |
| July 2010. |  | August 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 |  | [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data |
| Format Specification version 3.3", RFC 1950, May 1996. |  | Format Specification version 3.3", RFC 1950, May 1996. |
| RFC 1950 is an Informational RFC, thus it may be less |  | RFC 1950 is an Informational RFC, thus it might be less |
| stable than this specification. On the other hand, |  | stable than this specification. On the other hand, |
| this downward reference was present since the |  | this downward reference was present since the |
| publication of RFC 2068 in 1997 ([RFC2068]), therefore |  | publication of RFC 2068 in 1997 ([RFC2068]), therefore |
| it is unlikely to cause problems in practice. See also |  | it is unlikely to cause problems in practice. See also |
| [BCP97]. |  | [BCP97]. |
| [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format |  | [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format |
| Specification version 1.3", RFC 1951, May 1996. |  | Specification version 1.3", RFC 1951, May 1996. |
| RFC 1951 is an Informational RFC, thus it may be less |  | RFC 1951 is an Informational RFC, thus it might be less |
| stable than this specification. On the other hand, |  | stable than this specification. On the other hand, |
| this downward reference was present since the |  | this downward reference was present since the |
| publication of RFC 2068 in 1997 ([RFC2068]), therefore |  | publication of RFC 2068 in 1997 ([RFC2068]), therefore |
| it is unlikely to cause problems in practice. See also |  | it is unlikely to cause problems in practice. See also |
| [BCP97]. |  | [BCP97]. |
| [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and |  | [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and |
| G. Randers-Pehrson, "GZIP file format specification |  | G. Randers-Pehrson, "GZIP file format specification |
| version 4.3", RFC 1952, May 1996. |  | version 4.3", RFC 1952, May 1996. |
| RFC 1952 is an Informational RFC, thus it may be less |  | RFC 1952 is an Informational RFC, thus it might be less |
| stable than this specification. On the other hand, |  | stable than this specification. On the other hand, |
| this downward reference was present since the |  | this downward reference was present since the |
| publication of RFC 2068 in 1997 ([RFC2068]), therefore |  | publication of RFC 2068 in 1997 ([RFC2068]), therefore |
| it is unlikely to cause problems in practice. See also |  | it is unlikely to cause problems in practice. See also |
| [BCP97]. |  | [BCP97]. |
| [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet |  | [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet |
| Mail Extensions (MIME) Part One: Format of Internet |  | Mail Extensions (MIME) Part One: Format of Internet |
| Message Bodies", RFC 2045, November 1996. |  | Message Bodies", RFC 2045, November 1996. |
| skipping to change at page 31, line 9 |  | skipping to change at page 31, line 32 |
| Language Tags", BCP 47, RFC 4647, September 2006. |  | Language Tags", BCP 47, RFC 4647, September 2006. |
| [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for |  | [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for |
| Syntax Specifications: ABNF", STD 68, RFC 5234, |  | Syntax Specifications: ABNF", STD 68, RFC 5234, |
| January 2008. |  | January 2008. |
| [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for |  | [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for |
| Identifying Languages", BCP 47, RFC 5646, |  | Identifying Languages", BCP 47, RFC 5646, |
| September 2009. |  | September 2009. |
| 9.2. Informative References |  | 10.2. Informative References |
| [BCP97] Klensin, J. and S. Hartman, "Handling Normative |  | [BCP97] Klensin, J. and S. Hartman, "Handling Normative |
| References to Standards-Track Documents", BCP 97, |  | References to Standards-Track Documents", BCP 97, |
| RFC 4897, June 2007. |  | RFC 4897, June 2007. |
| [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, |  | [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, |
| "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, |  | "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, |
| May 1996. |  | May 1996. |
| [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet |  | [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet |
| skipping to change at page 32, line 21 |  | skipping to change at page 32, line 45 |
| and Registration Procedures", BCP 13, RFC 4288, |  | and Registration Procedures", BCP 13, RFC 4288, |
| December 2005. |  | December 2005. |
| [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing |  | [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing |
| an IANA Considerations Section in RFCs", BCP 26, |  | an IANA Considerations Section in RFCs", BCP 26, |
| RFC 5226, May 2008. |  | RFC 5226, May 2008. |
| [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, |  | [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, |
| October 2008. |  | October 2008. |
| Appendix A. Differences Between HTTP Entities and RFC 2045 Entities |  | Appendix A. Differences between HTTP and MIME |
| HTTP/1.1 uses many of the constructs defined for Internet Mail |  | HTTP/1.1 uses many of the constructs defined for Internet Mail |
| ([RFC5322]) and the Multipurpose Internet Mail Extensions (MIME |  | ([RFC5322]) and the Multipurpose Internet Mail Extensions (MIME |
| [RFC2045]) to allow entities to be transmitted in an open variety of |  | [RFC2045]) to allow a message-body to be transmitted in an open |
| representations and with extensible mechanisms. However, RFC 2045 |  | variety of representations and with extensible mechanisms. However, |
| discusses mail, and HTTP has a few features that are different from |  | RFC 2045 discusses mail, and HTTP has a few features that are |
| those described in RFC 2045. These differences were carefully chosen |  | different from those described in MIME. These differences were |
| to optimize performance over binary connections, to allow greater |  | carefully chosen to optimize performance over binary connections, to |
| freedom in the use of new media types, to make date comparisons |  | allow greater freedom in the use of new media types, to make date |
| easier, and to acknowledge the practice of some early HTTP servers |  | comparisons easier, and to acknowledge the practice of some early |
| and clients. |  | HTTP servers and clients. |
| This appendix describes specific areas where HTTP differs from RFC |  | This appendix describes specific areas where HTTP differs from MIME. |
| 2045. Proxies and gateways to strict MIME environments SHOULD be |  | Proxies and gateways to strict MIME environments SHOULD be aware of |
| aware of these differences and provide the appropriate conversions |  | these differences and provide the appropriate conversions where |
| where necessary. Proxies and gateways from MIME environments to HTTP |  | necessary. Proxies and gateways from MIME environments to HTTP also |
| also need to be aware of the differences because some conversions |  | need to be aware of the differences because some conversions might be |
| might be required. |  | required. |
| A.1. MIME-Version |  | A.1. MIME-Version |
| HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages |  | HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages |
| MAY include a single MIME-Version general-header field to indicate |  | MAY include a single MIME-Version general-header field to indicate |
| what version of the MIME protocol was used to construct the message. |  | what version of the MIME protocol was used to construct the message. |
| Use of the MIME-Version header field indicates that the message is in |  | Use of the MIME-Version header field indicates that the message is in |
| full compliance with the MIME protocol (as defined in [RFC2045]). |  | full compliance with the MIME protocol (as defined in [RFC2045]). |
| Proxies/gateways are responsible for ensuring full compliance (where |  | Proxies/gateways are responsible for ensuring full compliance (where |
| possible) when exporting HTTP messages to strict MIME environments. |  | possible) when exporting HTTP messages to strict MIME environments. |
| MIME-Version = "MIME-Version" ":" OWS MIME-Version-v |  | MIME-Version = "MIME-Version" ":" OWS MIME-Version-v |
| MIME-Version-v = 1*DIGIT "." 1*DIGIT |  | MIME-Version-v = 1*DIGIT "." 1*DIGIT |
| MIME version "1.0" is the default for use in HTTP/1.1. However, |  | MIME version "1.0" is the default for use in HTTP/1.1. However, |
| HTTP/1.1 message parsing and semantics are defined by this document |  | HTTP/1.1 message parsing and semantics are defined by this document |
| and not the MIME specification. |  | and not the MIME specification. |
| A.2. Conversion to Canonical Form |  | A.2. Conversion to Canonical Form |
| [RFC2045] requires that an Internet mail entity be converted to |  | MIME requires that an Internet mail body-part be converted to |
| canonical form prior to being transferred, as described in Section 4 |  | canonical form prior to being transferred, as described in Section 4 |
| of [RFC2049]. Section 2.3.1 of this document describes the forms |  | of [RFC2049]. Section 2.3.1 of this document describes the forms |
| allowed for subtypes of the "text" media type when transmitted over |  | allowed for subtypes of the "text" media type when transmitted over |
| HTTP. [RFC2046] requires that content with a type of "text" |  | HTTP. [RFC2046] requires that content with a type of "text" |
| represent line breaks as CRLF and forbids the use of CR or LF outside |  | represent line breaks as CRLF and forbids the use of CR or LF outside |
| of line break sequences. HTTP allows CRLF, bare CR, and bare LF to |  | of line break sequences. HTTP allows CRLF, bare CR, and bare LF to |
| indicate a line break within text content when a message is |  | indicate a line break within text content when a message is |
| transmitted over HTTP. |  | transmitted over HTTP. |
| Where it is possible, a proxy or gateway from HTTP to a strict MIME |  | Where it is possible, a proxy or gateway from HTTP to a strict MIME |
| environment SHOULD translate all line breaks within the text media |  | environment SHOULD translate all line breaks within the text media |
| types described in Section 2.3.1 of this document to the RFC 2049 |  | types described in Section 2.3.1 of this document to the RFC 2049 |
| canonical form of CRLF. Note, however, that this might be |  | canonical form of CRLF. Note, however, that this might be |
| complicated by the presence of a Content-Encoding and by the fact |  | complicated by the presence of a Content-Encoding and by the fact |
| that HTTP allows the use of some character sets which do not use |  | that HTTP allows the use of some character sets which do not use |
| octets 13 and 10 to represent CR and LF, as is the case for some |  | octets 13 and 10 to represent CR and LF, as is the case for some |
| multi-byte character sets. |  | multi-byte character sets. |
| Implementors should note that conversion will break any cryptographic |  | Conversion will break any cryptographic checksums applied to the |
| checksums applied to the original content unless the original content |  | original content unless the original content is already in canonical |
| is already in canonical form. Therefore, the canonical form is |  | form. Therefore, the canonical form is recommended for any content |
| recommended for any content that uses such checksums in HTTP. |  | that uses such checksums in HTTP. |
| A.3. Conversion of Date Formats |  | A.3. Conversion of Date Formats |
| HTTP/1.1 uses a restricted set of date formats (Section 6.1 of |  | HTTP/1.1 uses a restricted set of date formats (Section 6.1 of |
| [Part1]) to simplify the process of date comparison. Proxies and |  | [Part1]) to simplify the process of date comparison. Proxies and |
| gateways from other protocols SHOULD ensure that any Date header |  | gateways from other protocols SHOULD ensure that any Date header |
| field present in a message conforms to one of the HTTP/1.1 formats |  | field present in a message conforms to one of the HTTP/1.1 formats |
| and rewrite the date if necessary. |  | and rewrite the date if necessary. |
| A.4. Introduction of Content-Encoding |  | A.4. Introduction of Content-Encoding |
| RFC 2045 does not include any concept equivalent to HTTP/1.1's |  | MIME does not include any concept equivalent to HTTP/1.1's Content- |
| Content-Encoding header field. Since this acts as a modifier on the |  | Encoding header field. Since this acts as a modifier on the media |
| media type, proxies and gateways from HTTP to MIME-compliant |  | type, proxies and gateways from HTTP to MIME-compliant protocols MUST |
| protocols MUST either change the value of the Content-Type header |  | either change the value of the Content-Type header field or decode |
| field or decode the entity-body before forwarding the message. (Some |  | the representation before forwarding the message. (Some experimental |
| experimental applications of Content-Type for Internet mail have used |  | applications of Content-Type for Internet mail have used a media-type |
| a media-type parameter of ";conversions=<content-coding>" to perform |  | parameter of ";conversions=<content-coding>" to perform a function |
| a function equivalent to Content-Encoding. However, this parameter |  | equivalent to Content-Encoding. However, this parameter is not part |
| is not part of RFC 2045). |  | of the MIME standards). |
| A.5. No Content-Transfer-Encoding |  | A.5. No Content-Transfer-Encoding |
| HTTP does not use the Content-Transfer-Encoding field of RFC 2045. |  | HTTP does not use the Content-Transfer-Encoding field of MIME. |
| Proxies and gateways from MIME-compliant protocols to HTTP MUST |  | Proxies and gateways from MIME-compliant protocols to HTTP MUST |
| remove any Content-Transfer-Encoding prior to delivering the response |  | remove any Content-Transfer-Encoding prior to delivering the response |
| message to an HTTP client. |  | message to an HTTP client. |
| Proxies and gateways from HTTP to MIME-compliant protocols are |  | Proxies and gateways from HTTP to MIME-compliant protocols are |
| responsible for ensuring that the message is in the correct format |  | responsible for ensuring that the message is in the correct format |
| and encoding for safe transport on that protocol, where "safe |  | and encoding for safe transport on that protocol, where "safe |
| transport" is defined by the limitations of the protocol being used. |  | transport" is defined by the limitations of the protocol being used. |
| Such a proxy or gateway SHOULD label the data with an appropriate |  | Such a proxy or gateway SHOULD label the data with an appropriate |
| Content-Transfer-Encoding if doing so will improve the likelihood of |  | Content-Transfer-Encoding if doing so will improve the likelihood of |
| skipping to change at page 35, line 37 |  | skipping to change at page 36, line 12 |
| 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 8.2 for Content-Disposition security issues. |
| Appendix C. Compatibility with Previous Versions |  |  |
| C.1. Changes from RFC 2068 |  |  |
| Transfer-coding and message lengths all interact in ways that |  |  |
| required fixing exactly when chunked encoding is used (to allow for |  |  |
| transfer encoding that may not be self delimiting); it was important |  |  |
| to straighten out exactly how message lengths are computed. |  |  |
| (Section 3.2.2, see also [Part1], [Part5] and [Part6]). |  |  |
| Charset wildcarding is introduced to avoid explosion of character set |  |  |
| names in accept headers. (Section 5.2) |  |  |
| Content-Base was deleted from the specification: it was not |  |  |
| implemented widely, and there is no simple, safe way to introduce it |  |  |
| without a robust extension mechanism. In addition, it is used in a |  |  |
| similar, but not identical fashion in MHTML [RFC2557]. |  |  |
| A content-coding of "identity" was introduced, to solve problems |  |  |
| discovered in caching. (Section 2.2) |  |  |
| The Alternates, Content-Version, Derived-From, Link, URI, Public and |  |  |
| Content-Base header fields were defined in previous versions of this |  |  |
| specification, but not commonly implemented. See Section 19.6.2 of |  |  |
| [RFC2068]. |  |  |
| C.2. Changes from RFC 2616 |  | Appendix C. Changes from RFC 2616 |
| Clarify contexts that charset is used in. (Section 2.1) |  | Clarify contexts that charset is used in. (Section 2.1) |
| Remove base URI setting semantics for Content-Location due to poor |  | Remove base URI setting semantics for Content-Location due to poor |
| implementation support, which was caused by too many broken servers |  | implementation support, which was caused by too many broken servers |
| emitting bogus Content-Location headers, and also the potentially |  | emitting bogus Content-Location headers, and also the potentially |
| undesirable effect of potentially breaking relative links in content- |  | undesirable effect of potentially breaking relative links in content- |
| negotiated resources. (Section 5.7) |  | negotiated resources. (Section 6.7) |
| Remove reference to non-existant identity transfer-coding value |  | Remove reference to non-existant identity transfer-coding value |
| tokens. (Appendix A.5) |  | tokens. (Appendix A.5) |
| Appendix D. Collected ABNF |  | Appendix D. Collected ABNF |
| Accept = "Accept:" OWS Accept-v |  | Accept = "Accept:" OWS Accept-v |
| Accept-Charset = "Accept-Charset:" OWS Accept-Charset-v |  | Accept-Charset = "Accept-Charset:" OWS Accept-Charset-v |
| Accept-Charset-v = *( "," OWS ) ( charset / "*" ) [ OWS ";" OWS "q=" |  | Accept-Charset-v = *( "," OWS ) ( charset / "*" ) [ OWS ";" OWS "q=" |
| qvalue ] *( OWS "," [ OWS ( charset / "*" ) [ OWS ";" OWS "q=" |  | qvalue ] *( OWS "," [ OWS ( charset / "*" ) [ OWS ";" OWS "q=" |
| skipping to change at page 37, line 42 |  | skipping to change at page 37, line 38 |
| content-disposition = "Content-Disposition:" OWS |  | content-disposition = "Content-Disposition:" OWS |
| content-disposition-v |  | content-disposition-v |
| content-disposition-v = disposition-type *( OWS ";" OWS |  | content-disposition-v = disposition-type *( OWS ";" OWS |
| disposition-parm ) |  | disposition-parm ) |
| disp-extension-parm = token "=" word |  | disp-extension-parm = token "=" word |
| disp-extension-token = token |  | disp-extension-token = token |
| disposition-parm = filename-parm / disp-extension-parm |  | disposition-parm = filename-parm / disp-extension-parm |
| disposition-type = "attachment" / disp-extension-token |  | disposition-type = "attachment" / disp-extension-token |
| entity-body = *OCTET |  |  |
| entity-header = Content-Encoding / Content-Language / Content-Length |  |  |
| / Content-Location / Content-MD5 / Content-Range / Content-Type / |  |  |
| Expires / Last-Modified / extension-header |  |  |
| extension-header = header-field |  |  |
| filename-parm = "filename=" quoted-string |  | filename-parm = "filename=" quoted-string |
| header-field = <header-field, defined in [Part1], Section 3.2> |  | header-field = <header-field, defined in [Part1], Section 3.2> |
| language-range = <language-range, defined in [RFC4647], Section 2.1> |  | language-range = <language-range, defined in [RFC4647], Section 2.1> |
| language-tag = <Language-Tag, defined in [RFC5646], Section 2.1> |  | language-tag = <Language-Tag, defined in [RFC5646], Section 2.1> |
| media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS |  | media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS |
| ";" OWS parameter ) |  | ";" OWS parameter ) |
| media-type = type "/" subtype *( OWS ";" OWS parameter ) |  | media-type = type "/" subtype *( OWS ";" OWS parameter ) |
| parameter = attribute "=" value |  | parameter = attribute "=" value |
| partial-URI = <partial-URI, defined in [Part1], Section 2.6> |  | partial-URI = <partial-URI, defined in [Part1], Section 2.6> |
| quoted-string = <quoted-string, defined in [Part1], Section 1.2.2> |  | quoted-string = <quoted-string, defined in [Part1], Section 1.2.2> |
| qvalue = <qvalue, defined in [Part1], Section 6.4> |  | qvalue = <qvalue, defined in [Part1], Section 6.4> |
| subtype = token |  | subtype = token |
| token = <token, defined in [Part1], Section 1.2.2> |  | token = <token, defined in [Part1], Section 1.2.2> |
| type = token |  | type = token |
| value = word |  | value = word |
| skipping to change at page 38, line 32 |  | skipping to change at page 38, line 22 |
| value = word |  | value = word |
| word = <word, defined in [Part1], Section 1.2.2> |  | word = <word, defined in [Part1], Section 1.2.2> |
| ABNF diagnostics: |  | ABNF diagnostics: |
| ; Accept defined but not used |  | ; Accept defined but not used |
| ; Accept-Charset defined but not used |  | ; Accept-Charset defined but not used |
| ; Accept-Encoding defined but not used |  | ; Accept-Encoding defined but not used |
| ; Accept-Language defined but not used |  | ; Accept-Language defined but not used |
|  |  | ; Content-Encoding defined but not used |
|  |  | ; Content-Language defined but not used |
|  |  | ; Content-Length defined but not used |
|  |  | ; Content-Location defined but not used |
|  |  | ; Content-MD5 defined but not used |
|  |  | ; Content-Range defined but not used |
|  |  | ; Content-Type defined but not used |
|  |  | ; Expires defined but not used |
|  |  | ; Last-Modified defined but not used |
| ; MIME-Version defined but not used |  | ; MIME-Version defined but not used |
| ; content-disposition defined but not used |  | ; content-disposition defined but not used |
| ; entity-body defined but not used |  | ; header-field defined but not used |
| ; entity-header defined but not used |  |  |
| Appendix E. Change Log (to be removed by RFC Editor before publication) |  | Appendix E. Change Log (to be removed by RFC Editor before publication) |
| E.1. Since RFC2616 |  | E.1. Since RFC2616 |
| Extracted relevant partitions from [RFC2616]. |  | Extracted relevant partitions from [RFC2616]. |
| E.2. Since draft-ietf-httpbis-p3-payload-00 |  | E.2. Since draft-ietf-httpbis-p3-payload-00 |
| Closed issues: |  | Closed issues: |
| skipping to change at page 42, line 29 |  | skipping to change at page 42, line 27 |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/81>: "Content |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/81>: "Content |
| Negotiation for media types" |  | Negotiation for media types" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/181>: "Accept- |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/181>: "Accept- |
| Language: which RFC4647 filtering?" |  | Language: which RFC4647 filtering?" |
| E.11. Since draft-ietf-httpbis-p3-payload-09 |  | E.11. Since draft-ietf-httpbis-p3-payload-09 |
| Closed issues: |  | Closed issues: |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/122>: "MIME-Version |
|  |  | not listed in P1, general header fields" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/143>: "IANA registry |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/143>: "IANA registry |
| for content/transfer encodings" |  | for content/transfer encodings" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/155>: "Content |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/155>: "Content |
| Sniffing" |  | Sniffing" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/200>: "use of term |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/200>: "use of term |
| "word" when talking about header structure" |  | "word" when talking about header structure" |
| Partly resolved issues: |  | Partly resolved issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/196>: "Term for the |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/196>: "Term for the |
| requested resource's URI" |  | requested resource's URI" |
|  |  | E.12. Since draft-ietf-httpbis-p3-payload-10 |
|  |  | Closed issues: |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/69>: "Clarify |
|  |  | 'Requested Variant'" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/80>: "Content- |
|  |  | Location isn't special" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/90>: "Delimiting |
|  |  | messages with multipart/byteranges" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/109>: "Clarify |
|  |  | entity / representation / variant terminology" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/136>: "confusing |
|  |  | req. language for Content-Location" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/167>: "Content- |
|  |  | Location on 304 responses" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/183>: "'requested |
|  |  | resource' in content-encoding definition" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider |
|  |  | removing the 'changes from 2068' sections" |
|  |  | Partly resolved issues: |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/178>: "Content-MD5 |
|  |  | and partial responses" |
| Index |  | Index |
| A |  | A |
| Accept header 17 |  | Accept header 17 |
| Accept-Charset header 19 |  | Accept-Charset header 19 |
| Accept-Encoding header 20 |  | Accept-Encoding header 20 |
| Accept-Language header 21 |  | Accept-Language header 21 |
| Alternates header 36 |  |  |
| C |  | C |
| Coding Format |  | Coding Format |
| compress 8 |  | compress 8 |
| deflate 8 |  | deflate 8 |
| gzip 9 |  | gzip 8 |
| identity 9 |  | identity 8 |
| compress (Coding Format) 8 |  | compress (Coding Format) 8 |
| content negotiation 5 |  | content negotiation 5 |
| Content-Base header 36 |  |  |
| Content-Disposition header 35 |  | Content-Disposition header 35 |
| Content-Encoding header 22 |  | Content-Encoding header 22 |
| Content-Language header 23 |  | Content-Language header 23 |
| Content-Location header 24 |  | Content-Location header 24 |
| Content-MD5 header 25 |  | Content-MD5 header 25 |
| Content-Type header 26 |  | Content-Type header 27 |
| Content-Version header 36 |  |  |
| D |  | D |
| deflate (Coding Format) 8 |  | deflate (Coding Format) 8 |
| Derived-From header 36 |  |  |
| E |  |  |
| 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 20 |
| Accept-Encoding-v 20 |  | Accept-Encoding-v 20 |
| accept-ext 17 |  | accept-ext 17 |
| Accept-Language 21 |  | Accept-Language 21 |
| Accept-Language-v 21 |  | Accept-Language-v 21 |
| accept-params 17 |  | accept-params 17 |
| Accept-v 17 |  | Accept-v 17 |
| attribute 10 |  | attribute 9 |
| charset 7 |  | charset 7 |
| codings 20 |  | codings 20 |
| content-coding 8 |  | content-coding 8 |
| content-disposition 35 |  | content-disposition 35 |
| content-disposition-v 35 |  | content-disposition-v 35 |
| Content-Encoding 22 |  | Content-Encoding 22 |
| Content-Encoding-v 22 |  | Content-Encoding-v 22 |
| Content-Language 23 |  | Content-Language 23 |
| Content-Language-v 23 |  | Content-Language-v 23 |
| Content-Location 24 |  | Content-Location 24 |
| Content-Location-v 24 |  | Content-Location-v 24 |
| Content-MD5 25 |  | Content-MD5 25 |
| Content-MD5-v 25 |  | Content-MD5-v 25 |
| Content-Type 26 |  | Content-Type 27 |
| Content-Type-v 26 |  | Content-Type-v 27 |
| disp-extension-parm 35 |  | disp-extension-parm 35 |
| disp-extension-token 35 |  | disp-extension-token 35 |
| disposition-parm 35 |  | disposition-parm 35 |
| disposition-type 35 |  | disposition-type 35 |
| entity-body 13 |  |  |
| entity-header 13 |  |  |
| extension-header 13 |  |  |
| filename-parm 35 |  | filename-parm 35 |
| language-range 21 |  | language-range 21 |
| language-tag 12 |  | language-tag 11 |
| media-range 17 |  | media-range 17 |
| media-type 9 |  | media-type 9 |
| MIME-Version 32 |  | MIME-Version 33 |
| MIME-Version-v 32 |  | MIME-Version-v 33 |
| parameter 10 |  | parameter 9 |
| subtype 9 |  | subtype 9 |
| type 9 |  | type 9 |
| value 10 |  | value 9 |
| gzip (Coding Format) 9 |  | gzip (Coding Format) 8 |
| H |  | H |
| Headers |  | Headers |
| Accept 17 |  | Accept 17 |
| Accept-Charset 19 |  | Accept-Charset 19 |
| Accept-Encoding 20 |  | Accept-Encoding 20 |
| Accept-Language 21 |  | Accept-Language 21 |
| Alternate 36 |  |  |
| Content-Base 36 |  |  |
| Content-Disposition 35 |  | Content-Disposition 35 |
| Content-Encoding 22 |  | Content-Encoding 22 |
| Content-Language 23 |  | Content-Language 23 |
| Content-Location 24 |  | Content-Location 24 |
| Content-MD5 25 |  | Content-MD5 25 |
| Content-Type 26 |  | Content-Type 27 |
| Content-Version 36 |  | MIME-Version 33 |
| Derived-From 36 |  |  |
| Link 36 |  |  |
| MIME-Version 32 |  |  |
| Public 36 |  |  |
| URI 36 |  |  |
| I |  | I |
| identity (Coding Format) 9 |  | identity (Coding Format) 8 |
| L |  |  |
| Link header 36 |  |  |
| M |  | M |
| MIME-Version header 32 |  | MIME-Version header 33 |
| P |  | P |
| Public header 36 |  | payload 12 |
| R |  | R |
| representation 5 |  | representation 12 |
| U |  |  |
| URI header 36 |  |  |
| V |  |  |
| 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 |
| USA |  | USA |
| Phone: +1-949-706-5300 |  | Phone: +1-949-706-5300 |
End of changes. 159 change blocks.
| 476 lines changed or deleted |  | 493 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/