| draft-ietf-httpbis-p3-payload-09.txt |  | draft-ietf-httpbis-p3-payload-10.txt |
--- | --- | --- | --- | ---
| HTTPbis Working Group R. Fielding, Ed. |  | HTTPbis Working Group R. Fielding, Ed. |
| Internet-Draft Day Software |  | Internet-Draft Day Software |
| Obsoletes: 2616 (if approved) J. Gettys |  | Obsoletes: 2616 (if approved) J. Gettys |
| Intended status: Standards Track One Laptop per Child |  | Intended status: Standards Track Alcatel-Lucent |
| Expires: September 9, 2010 J. Mogul |  | Expires: January 13, 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 |
| March 8, 2010 |  | July 12, 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-09 |  | draft-ietf-httpbis-p3-payload-10 |
| 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/11> 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.10. |  | The changes in this draft are summarized in Appendix E.11. |
| Status of this Memo |  | Status of This Memo |
| This Internet-Draft is submitted to IETF in full conformance with the |  | This Internet-Draft is submitted 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), its areas, and its working groups. Note that |  | Task Force (IETF). Note that other groups may also distribute |
| other groups may also distribute working documents as Internet- |  | working documents as Internet-Drafts. The list of current Internet- |
| Drafts. |  | 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." |
| The list of current Internet-Drafts can be accessed at |  | This Internet-Draft will expire on January 13, 2011. |
| http://www.ietf.org/ietf/1id-abstracts.txt. |  |  |
| The list of Internet-Draft Shadow Directories can be accessed at |  |  |
| http://www.ietf.org/shadow.html. |  |  |
| This Internet-Draft will expire on September 9, 2010. |  |  |
| 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 |
| carefully, as they describe your rights and restrictions with respect |  | carefully, as they describe your rights and restrictions with respect |
| to this document. Code Components extracted from this document must |  | to this document. Code Components extracted from this document must |
| include Simplified BSD License text as described in Section 4.e of |  | include Simplified BSD License text as described in Section 4.e of |
| the Trust Legal Provisions and are provided without warranty as |  | the Trust Legal Provisions and are provided without warranty as |
| described in the BSD License. |  | described in the Simplified BSD License. |
| This document may contain material from IETF Documents or IETF |  | This document may contain material from IETF Documents or IETF |
| Contributions published or made publicly available before November |  | Contributions published or made publicly available before November |
| 10, 2008. The person(s) controlling the copyright in some of this |  | 10, 2008. The person(s) controlling the copyright in some of this |
| material may not have granted the IETF Trust the right to allow |  | material may not have granted the IETF Trust the right to allow |
| modifications of such material outside the IETF Standards Process. |  | modifications of such material outside the IETF Standards Process. |
| Without obtaining an adequate license from the person(s) controlling |  | Without obtaining an adequate license from the person(s) controlling |
| 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 |
| skipping to change at page 3, line 14 |  | skipping to change at page 3, line 4 |
| Table of Contents |  | Table of Contents |
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 |  | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 |
| 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 |  | 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 |
| 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 |  | 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 |
| 1.3. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 |  | 1.3. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 |
| 1.3.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 6 |  | 1.3.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 6 |
| 1.3.2. ABNF Rules defined in other Parts of the |  | 1.3.2. ABNF Rules defined in other Parts of the |
| Specification . . . . . . . . . . . . . . . . . . . . 6 |  | Specification . . . . . . . . . . . . . . . . . . . . 6 |
| 2. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 7 |  | 2. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 7 |
| 2.1. Character Sets . . . . . . . . . . . . . . . . . . . . . . 7 |  | 2.1. Character Sets . . . . . . . . . . . . . . . . . . . . . . 7 |
| 2.1.1. Missing Charset . . . . . . . . . . . . . . . . . . . 8 |  | 2.1.1. Missing Charset . . . . . . . . . . . . . . . . . . . 8 |
| 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 . . . . . . . . . . . . . . . . . . . . . . 11 |  | 2.4. Language Tags . . . . . . . . . . . . . . . . . . . . . . 12 |
| 3. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 |  | 3. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 |
| 3.1. Entity Header Fields . . . . . . . . . . . . . . . . . . . 12 |  | 3.1. Entity Header Fields . . . . . . . . . . . . . . . . . . . 12 |
| 3.2. Entity Body . . . . . . . . . . . . . . . . . . . . . . . 13 |  | 3.2. Entity Body . . . . . . . . . . . . . . . . . . . . . . . 13 |
| 3.2.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 13 |  | 3.2.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 13 |
| 3.2.2. Entity Length . . . . . . . . . . . . . . . . . . . . 13 |  | 3.2.2. Entity Length . . . . . . . . . . . . . . . . . . . . 14 |
| 4. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 14 |  | 4. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 14 |
| 4.1. Server-driven Negotiation . . . . . . . . . . . . . . . . 14 |  | 4.1. Server-driven Negotiation . . . . . . . . . . . . . . . . 15 |
| 4.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . . 16 |  | 4.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . . 16 |
| 5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 16 |  | 5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 17 |
| 5.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . . 16 |  | 5.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . . 17 |
| 5.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . . 19 |  | 5.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . . 19 |
| 5.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 19 |  | 5.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 20 |
| 5.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 21 |  | 5.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 21 |
| 5.5. Content-Encoding . . . . . . . . . . . . . . . . . . . . . 22 |  | 5.5. Content-Encoding . . . . . . . . . . . . . . . . . . . . . 22 |
| 5.6. Content-Language . . . . . . . . . . . . . . . . . . . . . 23 |  | 5.6. Content-Language . . . . . . . . . . . . . . . . . . . . . 23 |
| 5.7. Content-Location . . . . . . . . . . . . . . . . . . . . . 23 |  | 5.7. Content-Location . . . . . . . . . . . . . . . . . . . . . 24 |
| 5.8. Content-MD5 . . . . . . . . . . . . . . . . . . . . . . . 24 |  | 5.8. Content-MD5 . . . . . . . . . . . . . . . . . . . . . . . 25 |
| 5.9. Content-Type . . . . . . . . . . . . . . . . . . . . . . . 26 |  | 5.9. Content-Type . . . . . . . . . . . . . . . . . . . . . . . 26 |
| 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 |  | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 |
| 6.1. Message Header Registration . . . . . . . . . . . . . . . 26 |  | 6.1. Message Header Registration . . . . . . . . . . . . . . . 26 |
| 6.2. Content Coding Registry . . . . . . . . . . . . . . . . . 27 |  | 6.2. Content Coding Registry . . . . . . . . . . . . . . . . . 27 |
| 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 |  | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 |
| 7.1. Privacy Issues Connected to Accept Headers . . . . . . . . 27 |  | 7.1. Privacy Issues Connected to Accept Headers . . . . . . . . 28 |
| 7.2. Content-Disposition Issues . . . . . . . . . . . . . . . . 28 |  | 7.2. Content-Disposition Issues . . . . . . . . . . . . . . . . 28 |
| 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 |  | 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 |
| 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 |  | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 |
| 9.1. Normative References . . . . . . . . . . . . . . . . . . . 28 |  | 9.1. Normative References . . . . . . . . . . . . . . . . . . . 29 |
| 9.2. Informative References . . . . . . . . . . . . . . . . . . 30 |  | 9.2. Informative References . . . . . . . . . . . . . . . . . . 31 |
| Appendix A. Differences Between HTTP Entities and RFC 2045 |  | Appendix A. Differences Between HTTP Entities and RFC 2045 |
| Entities . . . . . . . . . . . . . . . . . . . . . . 31 |  | Entities . . . . . . . . . . . . . . . . . . . . . . 32 |
| A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 32 |  | A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 32 |
| A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 32 |  | A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 33 |
| A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 32 |  | A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 33 |
| A.4. Introduction of Content-Encoding . . . . . . . . . . . . . 33 |  | A.4. Introduction of Content-Encoding . . . . . . . . . . . . . 33 |
| A.5. No Content-Transfer-Encoding . . . . . . . . . . . . . . . 33 |  | A.5. No Content-Transfer-Encoding . . . . . . . . . . . . . . . 34 |
| A.6. Introduction of Transfer-Encoding . . . . . . . . . . . . 33 |  | A.6. Introduction of Transfer-Encoding . . . . . . . . . . . . 34 |
| A.7. MHTML and Line Length Limitations . . . . . . . . . . . . 33 |  | A.7. MHTML and Line Length Limitations . . . . . . . . . . . . 34 |
| Appendix B. Additional Features . . . . . . . . . . . . . . . . . 34 |  | Appendix B. Additional Features . . . . . . . . . . . . . . . . . 34 |
| B.1. Content-Disposition . . . . . . . . . . . . . . . . . . . 34 |  | B.1. Content-Disposition . . . . . . . . . . . . . . . . . . . 35 |
| Appendix C. Compatibility with Previous Versions . . . . . . . . 35 |  | Appendix C. Compatibility with Previous Versions . . . . . . . . 35 |
| C.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 35 |  | C.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 35 |
| C.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 35 |  | C.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 36 |
| Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 35 |  | 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 . . . . . . . . . . 39 |  | 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 . . . . . . . . . . 40 |  | E.7. Since draft-ietf-httpbis-p3-payload-05 . . . . . . . . . . 41 |
| E.8. Since draft-ietf-httpbis-p3-payload-06 . . . . . . . . . . 40 |  | 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 . . . . . . . . . . 41 |  | E.10. Since draft-ietf-httpbis-p3-payload-08 . . . . . . . . . . 42 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 |  | E.11. Since draft-ietf-httpbis-p3-payload-09 . . . . . . . . . . 42 |
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 |
| 1. Introduction |  | 1. Introduction |
| This document defines HTTP/1.1 message payloads (a.k.a., content), |  | This document defines HTTP/1.1 message payloads (a.k.a., content), |
| the associated metadata header fields that define how the payload is |  | the associated metadata header fields that define how the payload is |
| intended to be interpreted by a recipient, the request header fields |  | intended to be interpreted by a recipient, the request header fields |
| that may influence content selection, and the various selection |  | that may influence content selection, and the various selection |
| algorithms that are collectively referred to as HTTP content |  | algorithms that are collectively referred to as HTTP content |
| negotiation. |  | negotiation. |
| skipping to change at page 6, line 13 |  | skipping to change at page 6, line 13 |
| does not necessarily imply that the resource is subject to content |  | does not necessarily imply that the resource is subject to content |
| negotiation. |  | negotiation. |
| 1.2. Requirements |  | 1.2. Requirements |
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |  | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |  | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |
| document are to be interpreted as described in [RFC2119]. |  | document are to be interpreted as described in [RFC2119]. |
| An implementation is not compliant if it fails to satisfy one or more |  | An implementation is not compliant if it fails to satisfy one or more |
| 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 |
| REQUIRED level and all the SHOULD level requirements for its |  | "REQUIRED" level and all the "SHOULD" level requirements for its |
| protocols is said to be "unconditionally compliant"; one that |  | protocols is said to be "unconditionally compliant"; one that |
| satisfies all the MUST level requirements but not all the SHOULD |  | satisfies all the "MUST" level requirements but not all the "SHOULD" |
| level requirements for its protocols is said to be "conditionally |  | level requirements for its protocols is said to be "conditionally |
| compliant." |  | compliant". |
| 1.3. Syntax Notation |  | 1.3. Syntax Notation |
| This specification uses the ABNF syntax defined in Section 1.2 of |  | This specification uses the ABNF syntax defined in Section 1.2 of |
| [Part1] (which extends the syntax defined in [RFC5234] with a list |  | [Part1] (which extends the syntax defined in [RFC5234] with a list |
| rule). Appendix D shows the collected ABNF, with the list rule |  | rule). Appendix D shows the collected ABNF, with the list rule |
| expanded. |  | expanded. |
| The following core rules are included by reference, as defined in |  | The following core rules are included by reference, as defined in |
| [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF |  | [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF |
| skipping to change at page 6, line 41 |  | skipping to change at page 6, line 41 |
| HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit |  | HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit |
| sequence of data), SP (space), VCHAR (any visible USASCII character), |  | sequence of data), SP (space), VCHAR (any visible USASCII character), |
| and WSP (whitespace). |  | and WSP (whitespace). |
| 1.3.1. Core Rules |  | 1.3.1. Core Rules |
| The core rules below are defined in Section 1.2.2 of [Part1]: |  | The core rules below are defined in Section 1.2.2 of [Part1]: |
| quoted-string = <quoted-string, defined in [Part1], Section 1.2.2> |  | quoted-string = <quoted-string, defined in [Part1], Section 1.2.2> |
| token = <token, defined in [Part1], Section 1.2.2> |  | token = <token, defined in [Part1], Section 1.2.2> |
|  |  | word = <word, defined in [Part1], Section 1.2.2> |
| OWS = <OWS, defined in [Part1], Section 1.2.2> |  | OWS = <OWS, defined in [Part1], Section 1.2.2> |
| 1.3.2. ABNF Rules defined in other Parts of the Specification |  | 1.3.2. ABNF Rules defined in other Parts of the Specification |
| The ABNF rules below are defined in other parts: |  | The ABNF rules below are defined in other parts: |
| absolute-URI = <absolute-URI, defined in [Part1], Section 2.6> |  | absolute-URI = <absolute-URI, defined in [Part1], Section 2.6> |
| Content-Length = <Content-Length, defined in [Part1], Section 9.2> |  | Content-Length = <Content-Length, defined in [Part1], Section 9.2> |
| header-field = <header-field, defined in [Part1], Section 3.2> |  | header-field = <header-field, defined in [Part1], Section 3.2> |
| partial-URI = <partial-URI, defined in [Part1], Section 2.6> |  | partial-URI = <partial-URI, defined in [Part1], Section 2.6> |
| skipping to change at page 9, line 30 |  | skipping to change at page 9, line 30 |
| content coding names. |  | content coding names. |
| Registrations MUST include the following fields: |  | Registrations MUST include the following fields: |
| o Name |  | o Name |
| 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 |
|  |  | codings (Section 6.2 of [Part1]), unless the encoding transformation |
|  |  | is identical (as it is the case for the compression codings defined |
|  |  | 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 expert review and a |
| specification (see "Expert Review" and "Specification Required" in |  | specification (see "Expert Review" and "Specification Required" in |
| Section 4.1 of [RFC5226]), and MUST conform to the purpose of content |  | Section 4.1 of [RFC5226]), and MUST 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 |
| skipping to change at page 10, line 7 |  | skipping to change at page 10, line 10 |
| 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 = token / quoted-string |  | 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 may 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 |
| skipping to change at page 13, line 32 |  | skipping to change at page 13, line 48 |
| When an entity-body is included with a message, the data type of that |  | When an entity-body is included with a message, the data type of that |
| body is determined via the header fields Content-Type and Content- |  | body is determined via the header fields Content-Type and Content- |
| Encoding. These define a two-layer, ordered encoding model: |  | Encoding. These define a two-layer, ordered encoding model: |
| entity-body := Content-Encoding( Content-Type( data ) ) |  | entity-body := Content-Encoding( Content-Type( data ) ) |
| Content-Type specifies the media type of the underlying data. Any |  | Content-Type specifies the media type of the underlying data. Any |
| HTTP/1.1 message containing an entity-body SHOULD include a Content- |  | HTTP/1.1 message containing an entity-body SHOULD include a Content- |
| Type header field defining the media type of that body, unless that |  | Type header field defining the media type of that body, unless that |
| information is unknown. If the Content-Type header field is not |  | information is unknown. |
| present, it indicates that the sender does not know the media type of |  |  |
| the data; recipients MAY either assume that it is "application/ |  | If the Content-Type header field is not present, it indicates that |
| octet-stream" ([RFC2046], Section 4.5.1) or examine the content to |  | the sender does not know the media type of the data; recipients MAY |
| determine its type. |  | either assume that it is "application/octet-stream" ([RFC2046], |
|  |  | Section 4.5.1) or examine the content to determine its type. |
|  |  | In practice, currently-deployed servers sometimes provide a Content- |
|  |  | Type header which does not correctly convey the intended |
|  |  | interpretation of the content sent, with the result that some clients |
|  |  | will examine the response body's content and override the specified |
|  |  | type. |
|  |  | Client that do so risk drawing incorrect conclusions, which may |
|  |  | 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-Encoding may be used to indicate any additional content |
| codings applied to the data, usually for the purpose of data |  | codings applied to the data, usually for the purpose of data |
| compression, that are a property of the requested resource. There is |  | compression, that are a property of the requested resource. There is |
| no default encoding. |  | no default encoding. |
| 3.2.2. Entity Length |  | 3.2.2. Entity Length |
| The entity-length of a message is the length of the message-body |  | The entity-length of a message is the length of the message-body |
| before any transfer-codings have been applied. Section 3.4 of |  | before any transfer-codings have been applied. Section 3.4 of |
| skipping to change at page 17, line 14 |  | skipping to change at page 17, line 38 |
| Accept = "Accept" ":" OWS Accept-v |  | Accept = "Accept" ":" OWS Accept-v |
| Accept-v = #( media-range [ accept-params ] ) |  | Accept-v = #( media-range [ accept-params ] ) |
| media-range = ( "*/*" |  | media-range = ( "*/*" |
| / ( type "/" "*" ) |  | / ( type "/" "*" ) |
| / ( type "/" subtype ) |  | / ( type "/" subtype ) |
| ) *( OWS ";" OWS parameter ) |  | ) *( OWS ";" OWS parameter ) |
| accept-params = OWS ";" OWS "q=" qvalue *( accept-ext ) |  | accept-params = OWS ";" OWS "q=" qvalue *( accept-ext ) |
| accept-ext = OWS ";" OWS token |  | accept-ext = OWS ";" OWS token |
| [ "=" ( token / quoted-string ) ] |  | [ "=" word ] |
| The asterisk "*" character is used to group media types into ranges, |  | The asterisk "*" character is used to group media types into ranges, |
| with "*/*" indicating all media types and "type/*" indicating all |  | with "*/*" indicating all media types and "type/*" indicating all |
| subtypes of that type. The media-range MAY include media type |  | subtypes of that type. The media-range MAY include media type |
| parameters that are applicable to that range. |  | parameters that are applicable to that range. |
| Each media-range MAY be followed by one or more accept-params, |  | Each media-range MAY be followed by one or more accept-params, |
| beginning with the "q" parameter for indicating a relative quality |  | beginning with the "q" parameter for indicating a relative quality |
| factor. The first "q" parameter (if any) separates the media-range |  | factor. The first "q" parameter (if any) separates the media-range |
| parameter(s) from the accept-params. Quality factors allow the user |  | parameter(s) from the accept-params. Quality factors allow the user |
| skipping to change at page 22, line 32 |  | skipping to change at page 23, line 10 |
| the identity of its underlying media type. |  | 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 entity identified by |
| the request-target. Typically, the entity-body is stored with this |  | the Effective Request URI (Section 4.3 of [Part1]). Typically, the |
| encoding and is only decoded before rendering or analogous usage. |  | entity-body is stored with this encoding and is only decoded before |
| However, a non-transparent proxy MAY modify the content-coding if the |  | rendering or analogous usage. However, a non-transparent proxy MAY |
| new coding is known to be acceptable to the recipient, unless the |  | modify the content-coding if the new coding is known to be acceptable |
| "no-transform" cache-control directive is present in the message. |  | to the recipient, unless the "no-transform" cache-control directive |
|  |  | is present in the message. |
| If the content-coding of an entity is not "identity", then the |  | If the content-coding of an entity is not "identity", then the |
| response MUST include a Content-Encoding entity-header (Section 5.5) |  | response MUST include a Content-Encoding entity-header (Section 5.5) |
| that lists the non-identity content-coding(s) used. |  | 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 an entity 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 an entity, the content |
| skipping to change at page 24, line 14 |  | skipping to change at page 24, line 40 |
| resource has multiple entities associated with it, and those entities |  | resource has multiple entities associated with it, and those entities |
| actually have separate locations by which they might be individually |  | actually have separate locations by which they might be individually |
| accessed, the server SHOULD provide a Content-Location for the |  | accessed, the server SHOULD provide a Content-Location for the |
| particular variant which is returned. |  | 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 original |  | The Content-Location value is not a replacement for the Effective |
| requested URI; it is only a statement of the location of the resource |  | Request URI (Section 4.3 of [Part1]); it is only a statement of the |
| corresponding to this particular entity at the time of the request. |  | location of the resource corresponding to this particular entity at |
| Future requests MAY specify the Content-Location URI as the request- |  | the time of the request. Future requests MAY may be addressed to the |
| target if the desire is to identify the source of that particular |  | Content-Location URI if the desire is to identify the source of that |
| entity. |  | particular entity. |
| Section 6.1 of [Part2] describes how clients may process the Content- |  | Section 6.1 of [Part2] describes how clients may process the Content- |
| Location header field. |  | Location header field. |
| A cache cannot assume that an entity with a Content-Location |  | A cache cannot assume that an entity with a Content-Location |
| different from the URI used to retrieve it can be used to respond to |  | different from the URI used to retrieve it can be used to respond to |
| later requests on that Content-Location URI. However, the Content- |  | later requests on that Content-Location URI. However, the Content- |
| Location can be used to differentiate between multiple entities |  | Location can be used to differentiate between multiple entities |
| retrieved from a single requested resource, as described in Section |  | retrieved from a single requested resource, as described in Section |
| 2.6 of [Part6]. |  | 2.7 of [Part6]. |
| If the Content-Location is a relative URI, the relative URI is |  | If the Content-Location is a relative URI, the relative URI is |
| interpreted relative to the request-target. |  | interpreted relative to the Effective Request URI. |
| The meaning of the Content-Location header in requests is undefined; |  | The meaning of the Content-Location header in requests is undefined; |
| servers are free to ignore it in those cases. |  | servers are free to ignore it in those cases. |
| 5.8. Content-MD5 |  | 5.8. Content-MD5 |
| The "Content-MD5" entity-header field, as defined in [RFC1864], is an |  | The "Content-MD5" entity-header field, as defined in [RFC1864], is an |
| MD5 digest of the entity-body that provides an end-to-end message |  | MD5 digest of the entity-body that provides an end-to-end message |
| integrity check (MIC) of the entity-body. Note that a MIC is good |  | integrity check (MIC) of the entity-body. Note that a MIC is good |
| for detecting accidental modification of the entity-body in transit, |  | for detecting accidental modification of the entity-body in transit, |
| skipping to change at page 27, line 14 |  | skipping to change at page 27, line 33 |
| 6.2. Content Coding Registry |  | 6.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> should be updated |
| with the registration below: |  | with the registration below: |
| +----------+-----------------------------------+--------------------+ |  | +----------+-----------------------------------------+--------------+ |
| | Name | Description | Reference | |  | | Name | Description | Reference | |
| +----------+-----------------------------------+--------------------+ |  | +----------+-----------------------------------------+--------------+ |
| | compress | UNIX "compress" program method | Section 6.2.2.1 of | |  | | compress | UNIX "compress" program method | Section | |
| | | | [Part1] | |  | | | | 6.2.2.1 of | |
| | deflate | "zlib" format [RFC1950] with | Section 6.2.2.2 of | |  | | | | [Part1] | |
| | | "deflate" compression | [Part1] | |  | | deflate | "deflate" compression mechanism | Section | |
| | gzip | Same as GNU zip [RFC1952] | Section 6.2.2.3 of | |  | | | ([RFC1951]) used inside the "zlib" data | 6.2.2.2 of | |
| | | | [Part1] | |  | | | format ([RFC1950]) | [Part1] | |
| | identity | No transformation | Section 2.2 | |  | | gzip | Same as GNU zip [RFC1952] | Section | |
| +----------+-----------------------------------+--------------------+ |  | | | | 6.2.2.3 of | |
|  |  | | | | [Part1] | |
|  |  | | identity | No transformation | Section 2.2 | |
|  |  | +----------+-----------------------------------------+--------------+ |
| 7. Security Considerations |  | 7. 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 |  | 7.1. Privacy Issues Connected to Accept Headers |
| skipping to change at page 28, line 36 |  | skipping to change at page 29, line 11 |
| 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 |  | 8. Acknowledgments |
| 9. References |  | 9. References |
| 9.1. Normative References |  | 9.1. Normative References |
| [ISO-8859-1] |  | [ISO-8859-1] International Organization for Standardization, |
| International Organization for Standardization, |  | "Information technology -- 8-bit single-byte coded |
| "Information technology -- 8-bit single-byte coded graphic |  | graphic character sets -- Part 1: Latin alphabet No. |
| character sets -- Part 1: Latin alphabet No. 1", ISO/ |  | 1", ISO/IEC 8859-1:1998, 1998. |
| IEC 8859-1:1998, 1998. |  |  |
| [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., |
| and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, |  | Ed., and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, |
| and Message Parsing", draft-ietf-httpbis-p1-messaging-09 |  | Connections, and Message Parsing", |
| (work in progress), March 2010. |  | draft-ietf-httpbis-p1-messaging-10 (work in progress), |
|  |  | July 2010. |
| [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., |
| 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-09 (work in |  | Semantics", draft-ietf-httpbis-p2-semantics-10 (work in |
| progress), March 2010. |  | progress), July 2010. |
| [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., |
| and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional |  | Ed., and J. Reschke, Ed., "HTTP/1.1, part 4: |
| Requests", draft-ietf-httpbis-p4-conditional-09 (work in |  | Conditional Requests", |
| progress), March 2010. |  | draft-ietf-httpbis-p4-conditional-10 (work in |
|  |  | progress), July 2010. |
| [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., |
| and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and |  | Ed., and J. Reschke, Ed., "HTTP/1.1, part 5: Range |
| Partial Responses", draft-ietf-httpbis-p5-range-09 (work |  | Requests and Partial Responses", |
| in progress), March 2010. |  | draft-ietf-httpbis-p5-range-10 (work in progress), |
|  |  | July 2010. |
| [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., |
| Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part |  | Ed., Nottingham, M., Ed., and J. Reschke, Ed., |
| 6: Caching", draft-ietf-httpbis-p6-cache-09 (work in |  | "HTTP/1.1, part 6: Caching", |
| progress), March 2010. |  | draft-ietf-httpbis-p6-cache-10 (work in progress), |
|  |  | July 2010. |
| [RFC1864] Myers, J. and M. Rose, "The Content-MD5 Header Field", |  | [RFC1864] Myers, J. and M. Rose, "The Content-MD5 Header Field", |
| RFC 1864, October 1995. |  | RFC 1864, October 1995. |
| [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format |  | [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data |
| 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 may be less |
| stable than this specification. On the other hand, this |  | stable than this specification. On the other hand, |
| downward reference was present since the publication of |  | this downward reference was present since the |
| RFC 2068 in 1997 ([RFC2068]), therefore it is unlikely to |  | publication of RFC 2068 in 1997 ([RFC2068]), therefore |
| cause problems in practice. See also [BCP97]. |  | it is unlikely to cause problems in practice. See also |
|  |  | [BCP97]. |
| [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G. |  | [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format |
| Randers-Pehrson, "GZIP file format specification version |  | Specification version 1.3", RFC 1951, May 1996. |
| 4.3", RFC 1952, May 1996. |  |  |
| RFC 1952 is an Informational RFC, thus it may be less |  | RFC 1951 is an Informational RFC, thus it may be less |
| stable than this specification. On the other hand, this |  | stable than this specification. On the other hand, |
| downward reference was present since the publication of |  | this downward reference was present since the |
| RFC 2068 in 1997 ([RFC2068]), therefore it is unlikely to |  | publication of RFC 2068 in 1997 ([RFC2068]), therefore |
| cause problems in practice. See also [BCP97]. |  | it is unlikely to cause problems in practice. See also |
|  |  | [BCP97]. |
| [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail |  | [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and |
| Extensions (MIME) Part One: Format of Internet Message |  | G. Randers-Pehrson, "GZIP file format specification |
| Bodies", RFC 2045, November 1996. |  | version 4.3", RFC 1952, May 1996. |
| [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail |  | RFC 1952 is an Informational RFC, thus it may be less |
| Extensions (MIME) Part Two: Media Types", RFC 2046, |  | stable than this specification. On the other hand, |
| November 1996. |  | this downward reference was present since the |
|  |  | publication of RFC 2068 in 1997 ([RFC2068]), therefore |
|  |  | it is unlikely to cause problems in practice. See also |
|  |  | [BCP97]. |
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |  | [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet |
| Requirement Levels", BCP 14, RFC 2119, March 1997. |  | Mail Extensions (MIME) Part One: Format of Internet |
|  |  | Message Bodies", RFC 2045, November 1996. |
| [RFC4647] Phillips, A., Ed. and M. Davis, Ed., "Matching of Language |  | [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet |
| Tags", BCP 47, RFC 4647, September 2006. |  | Mail Extensions (MIME) Part Two: Media Types", |
|  |  | RFC 2046, November 1996. |
| [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax |  | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |
| Specifications: ABNF", STD 68, RFC 5234, January 2008. |  | Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying |  | [RFC4647] Phillips, A., Ed. and M. Davis, Ed., "Matching of |
| Languages", BCP 47, RFC 5646, September 2009. |  | Language Tags", BCP 47, RFC 4647, September 2006. |
|  |  | [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for |
|  |  | Syntax Specifications: ABNF", STD 68, RFC 5234, |
|  |  | January 2008. |
|  |  | [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for |
|  |  | Identifying Languages", BCP 47, RFC 5646, |
|  |  | September 2009. |
| 9.2. Informative References |  | 9.2. Informative References |
| [BCP97] Klensin, J. and S. Hartman, "Handling Normative References |  | [BCP97] Klensin, J. and S. Hartman, "Handling Normative |
| to Standards-Track Documents", BCP 97, RFC 4897, |  | References to Standards-Track Documents", BCP 97, |
| June 2007. |  | RFC 4897, June 2007. |
| [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext |  | [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, |
| Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. |  | "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, |
|  |  | May 1996. |
| [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail |  | [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet |
| Extensions (MIME) Part Five: Conformance Criteria and |  | Mail Extensions (MIME) Part Five: Conformance Criteria |
| Examples", RFC 2049, November 1996. |  | and Examples", RFC 2049, November 1996. |
| [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. |  | [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and |
| Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", |  | T. Berners-Lee, "Hypertext Transfer Protocol -- |
| RFC 2068, January 1997. |  | HTTP/1.1", RFC 2068, January 1997. |
| [RFC2076] Palme, J., "Common Internet Message Headers", RFC 2076, |  | [RFC2076] Palme, J., "Common Internet Message Headers", RFC 2076, |
| February 1997. |  | February 1997. |
| [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating |  | [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating |
| Presentation Information in Internet Messages: The |  | Presentation Information in Internet Messages: The |
| Content-Disposition Header Field", RFC 2183, August 1997. |  | Content-Disposition Header Field", RFC 2183, |
|  |  | August 1997. |
| [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and |  | [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and |
| Languages", BCP 18, RFC 2277, January 1998. |  | Languages", BCP 18, RFC 2277, January 1998. |
| [RFC2295] Holtman, K. and A. Mutz, "Transparent Content Negotiation |  | [RFC2295] Holtman, K. and A. Mutz, "Transparent Content |
| in HTTP", RFC 2295, March 1998. |  | Negotiation in HTTP", RFC 2295, March 1998. |
| [RFC2388] Masinter, L., "Returning Values from Forms: multipart/ |  | [RFC2388] Masinter, L., "Returning Values from Forms: multipart/ |
| form-data", RFC 2388, August 1998. |  | form-data", RFC 2388, August 1998. |
| [RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud, |  | [RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud, |
| "MIME Encapsulation of Aggregate Documents, such as HTML |  | "MIME Encapsulation of Aggregate Documents, such as |
| (MHTML)", RFC 2557, March 1999. |  | HTML (MHTML)", RFC 2557, March 1999. |
| [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., |  | [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext |  | Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext |
| Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. |  | Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. |
| [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO |  | [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO |
| 10646", RFC 3629, STD 63, November 2003. |  | 10646", RFC 3629, STD 63, November 2003. |
| [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration |  | [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration |
| Procedures for Message Header Fields", BCP 90, RFC 3864, |  | Procedures for Message Header Fields", BCP 90, |
| September 2004. |  | RFC 3864, September 2004. |
| [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and |  | [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications |
| Registration Procedures", BCP 13, RFC 4288, December 2005. |  | and Registration Procedures", BCP 13, RFC 4288, |
|  |  | December 2005. |
| [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an |  | [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing |
| IANA Considerations Section in RFCs", BCP 26, RFC 5226, |  | an IANA Considerations Section in RFCs", BCP 26, |
| 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 Entities and RFC 2045 Entities |
| 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 entities to be transmitted in an open variety of |
| representations and with extensible mechanisms. However, RFC 2045 |  | representations and with extensible mechanisms. However, RFC 2045 |
| discusses mail, and HTTP has a few features that are different from |  | discusses mail, and HTTP has a few features that are different from |
| those described in RFC 2045. These differences were carefully chosen |  | those described in RFC 2045. These differences were carefully chosen |
| to optimize performance over binary connections, to allow greater |  | to optimize performance over binary connections, to allow greater |
| skipping to change at page 34, line 34 |  | skipping to change at page 35, line 21 |
| derived from the definition of Content-Disposition in [RFC2183]. |  | derived from the definition of Content-Disposition in [RFC2183]. |
| content-disposition = "Content-Disposition" ":" OWS |  | content-disposition = "Content-Disposition" ":" OWS |
| content-disposition-v |  | content-disposition-v |
| content-disposition-v = disposition-type |  | content-disposition-v = disposition-type |
| *( OWS ";" OWS disposition-parm ) |  | *( OWS ";" OWS disposition-parm ) |
| disposition-type = "attachment" / disp-extension-token |  | disposition-type = "attachment" / disp-extension-token |
| disposition-parm = filename-parm / disp-extension-parm |  | disposition-parm = filename-parm / disp-extension-parm |
| filename-parm = "filename" "=" quoted-string |  | filename-parm = "filename" "=" quoted-string |
| disp-extension-token = token |  | disp-extension-token = token |
| disp-extension-parm = token "=" ( token / quoted-string ) |  | disp-extension-parm = token "=" word |
| An example is |  | An example is |
| Content-Disposition: attachment; filename="fname.ext" |  | Content-Disposition: attachment; filename="fname.ext" |
| The receiving user agent SHOULD NOT respect any directory path |  | The receiving user agent SHOULD NOT respect any directory path |
| information present in the filename-parm parameter, which is the only |  | information present in the filename-parm parameter, which is the only |
| parameter believed to apply to HTTP implementations at this time. |  | parameter believed to apply to HTTP implementations at this time. |
| The filename SHOULD be treated as a terminal component only. |  | The filename SHOULD be treated as a terminal component only. |
| skipping to change at page 36, line 38 |  | skipping to change at page 37, line 25 |
| Expires = <Expires, defined in [Part6], Section 3.3> |  | Expires = <Expires, defined in [Part6], Section 3.3> |
| Last-Modified = <Last-Modified, defined in [Part4], Section 6.6> |  | Last-Modified = <Last-Modified, defined in [Part4], Section 6.6> |
| 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 |
| OWS = <OWS, defined in [Part1], Section 1.2.2> |  | OWS = <OWS, defined in [Part1], Section 1.2.2> |
| absolute-URI = <absolute-URI, defined in [Part1], Section 2.6> |  | absolute-URI = <absolute-URI, defined in [Part1], Section 2.6> |
| accept-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ] |  | accept-ext = OWS ";" OWS token [ "=" word ] |
| accept-params = OWS ";" OWS "q=" qvalue *accept-ext |  | accept-params = OWS ";" OWS "q=" qvalue *accept-ext |
| attribute = token |  | attribute = token |
| charset = token |  | charset = token |
| codings = ( content-coding / "*" ) |  | codings = ( content-coding / "*" ) |
| content-coding = token |  | content-coding = token |
| 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 "=" ( token / quoted-string ) |  | 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-body = *OCTET |
| entity-header = Content-Encoding / Content-Language / Content-Length |  | entity-header = Content-Encoding / Content-Language / Content-Length |
| / Content-Location / Content-MD5 / Content-Range / Content-Type / |  | / Content-Location / Content-MD5 / Content-Range / Content-Type / |
| Expires / Last-Modified / extension-header |  | Expires / Last-Modified / extension-header |
| extension-header = header-field |  | extension-header = header-field |
| skipping to change at page 37, line 35 |  | skipping to change at page 38, line 22 |
| 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 = token / quoted-string |  | value = word |
|  |  | 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 |
| ; 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 |  | ; entity-body defined but not used |
| skipping to change at page 41, line 47 |  | skipping to change at page 42, line 25 |
| E.10. Since draft-ietf-httpbis-p3-payload-08 |  | E.10. Since draft-ietf-httpbis-p3-payload-08 |
| Closed issues: |  | Closed issues: |
| 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 |
|  |  | Closed issues: |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/143>: "IANA registry |
|  |  | for content/transfer encodings" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/155>: "Content |
|  |  | Sniffing" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/200>: "use of term |
|  |  | "word" when talking about header structure" |
|  |  | Partly resolved issues: |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/196>: "Term for the |
|  |  | requested resource's URI" |
| Index |  | Index |
| A |  | A |
| Accept header 16 |  | Accept header 17 |
| Accept-Charset header 19 |  | Accept-Charset header 19 |
| Accept-Encoding header 19 |  | Accept-Encoding header 20 |
| Accept-Language header 21 |  | Accept-Language header 21 |
| Alternates header 35 |  | Alternates header 36 |
| C |  | C |
| Coding Format |  | Coding Format |
| compress 8 |  | compress 8 |
| deflate 8 |  | deflate 8 |
| gzip 9 |  | gzip 9 |
| identity 9 |  | identity 9 |
| compress (Coding Format) 8 |  | compress (Coding Format) 8 |
| content negotiation 5 |  | content negotiation 5 |
| Content-Base header 35 |  | Content-Base header 36 |
| Content-Disposition header 34 |  | Content-Disposition header 35 |
| Content-Encoding header 22 |  | Content-Encoding header 22 |
| Content-Language header 23 |  | Content-Language header 23 |
| Content-Location header 23 |  | Content-Location header 24 |
| Content-MD5 header 24 |  | Content-MD5 header 25 |
| Content-Type header 26 |  | Content-Type header 26 |
| Content-Version header 35 |  | Content-Version header 36 |
| D |  | D |
| deflate (Coding Format) 8 |  | deflate (Coding Format) 8 |
| Derived-From header 35 |  | Derived-From header 36 |
| E |  | E |
| entity 5 |  | entity 5 |
| G |  | G |
| Grammar |  | Grammar |
| Accept 17 |  | Accept 17 |
| Accept-Charset 19 |  | Accept-Charset 19 |
| Accept-Charset-v 19 |  | Accept-Charset-v 19 |
| Accept-Encoding 19 |  | Accept-Encoding 20 |
| Accept-Encoding-v 19 |  | 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 10 |
| charset 7 |  | charset 7 |
| codings 19 |  | codings 20 |
| content-coding 8 |  | content-coding 8 |
| content-disposition 34 |  | content-disposition 35 |
| content-disposition-v 34 |  | 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 24 |  | Content-MD5 25 |
| Content-MD5-v 24 |  | Content-MD5-v 25 |
| Content-Type 26 |  | Content-Type 26 |
| Content-Type-v 26 |  | Content-Type-v 26 |
| disp-extension-parm 34 |  | disp-extension-parm 35 |
| disp-extension-token 34 |  | disp-extension-token 35 |
| disposition-parm 34 |  | disposition-parm 35 |
| disposition-type 34 |  | disposition-type 35 |
| entity-body 13 |  | entity-body 13 |
| entity-header 12 |  | entity-header 13 |
| extension-header 12 |  | extension-header 13 |
| filename-parm 34 |  | filename-parm 35 |
| language-range 21 |  | language-range 21 |
| language-tag 12 |  | language-tag 12 |
| media-range 17 |  | media-range 17 |
| media-type 9 |  | media-type 9 |
| MIME-Version 32 |  | MIME-Version 32 |
| MIME-Version-v 32 |  | MIME-Version-v 32 |
| parameter 10 |  | parameter 10 |
| subtype 9 |  | subtype 9 |
| type 9 |  | type 9 |
| value 10 |  | value 10 |
| gzip (Coding Format) 9 |  | gzip (Coding Format) 9 |
| H |  | H |
| Headers |  | Headers |
| Accept 16 |  | Accept 17 |
| Accept-Charset 19 |  | Accept-Charset 19 |
| Accept-Encoding 19 |  | Accept-Encoding 20 |
| Accept-Language 21 |  | Accept-Language 21 |
| Alternate 35 |  | Alternate 36 |
| Content-Base 35 |  | Content-Base 36 |
| Content-Disposition 34 |  | Content-Disposition 35 |
| Content-Encoding 22 |  | Content-Encoding 22 |
| Content-Language 23 |  | Content-Language 23 |
| Content-Location 23 |  | Content-Location 24 |
| Content-MD5 24 |  | Content-MD5 25 |
| Content-Type 26 |  | Content-Type 26 |
| Content-Version 35 |  | Content-Version 36 |
| Derived-From 35 |  | Derived-From 36 |
| Link 35 |  | Link 36 |
| MIME-Version 32 |  | MIME-Version 32 |
| Public 35 |  | Public 36 |
| URI 35 |  | URI 36 |
| I |  | I |
| identity (Coding Format) 9 |  | identity (Coding Format) 9 |
| L |  | L |
| Link header 35 |  | Link header 36 |
| M |  | M |
| MIME-Version header 32 |  | MIME-Version header 32 |
| P |  | P |
| Public header 35 |  | Public header 36 |
| R |  | R |
| representation 5 |  | representation 5 |
| U |  | U |
| URI header 35 |  | URI header 36 |
| V |  | V |
| variant 5 |  | variant 5 |
| Authors' Addresses |  | Authors' Addresses |
| Roy T. Fielding (editor) |  | Roy T. Fielding (editor) |
| Day Software |  | Day Software |
| 23 Corporate Plaza DR, Suite 280 |  | 23 Corporate Plaza DR, Suite 280 |
| Newport Beach, CA 92660 |  | Newport Beach, CA 92660 |
| USA |  | USA |
| Phone: +1-949-706-5300 |  | Phone: +1-949-706-5300 |
| Fax: +1-949-706-5305 |  | Fax: +1-949-706-5305 |
| Email: fielding@gbiv.com |  | EMail: fielding@gbiv.com |
| URI: http://roy.gbiv.com/ |  | URI: http://roy.gbiv.com/ |
| Jim Gettys |  | Jim Gettys |
| One Laptop per Child |  | Alcatel-Lucent Bell Labs |
| 21 Oak Knoll Road |  | 21 Oak Knoll Road |
| Carlisle, MA 01741 |  | Carlisle, MA 01741 |
| USA |  | USA |
| Email: jg@laptop.org |  | EMail: jg@freedesktop.org |
| URI: http://www.laptop.org/ |  | URI: http://gettys.wordpress.com/ |
| Jeffrey C. Mogul |  | Jeffrey C. Mogul |
| Hewlett-Packard Company |  | Hewlett-Packard Company |
| HP Labs, Large Scale Systems Group |  | HP Labs, Large Scale Systems Group |
| 1501 Page Mill Road, MS 1177 |  | 1501 Page Mill Road, MS 1177 |
| Palo Alto, CA 94304 |  | Palo Alto, CA 94304 |
| USA |  | USA |
| Email: JeffMogul@acm.org |  | EMail: JeffMogul@acm.org |
| Henrik Frystyk Nielsen |  | Henrik Frystyk Nielsen |
| Microsoft Corporation |  | Microsoft Corporation |
| 1 Microsoft Way |  | 1 Microsoft Way |
| Redmond, WA 98052 |  | Redmond, WA 98052 |
| USA |  | USA |
| Email: henrikn@microsoft.com |  | EMail: henrikn@microsoft.com |
| Larry Masinter |  | Larry Masinter |
| Adobe Systems, Incorporated |  | Adobe Systems, Incorporated |
| 345 Park Ave |  | 345 Park Ave |
| San Jose, CA 95110 |  | San Jose, CA 95110 |
| USA |  | USA |
| Email: LMM@acm.org |  | EMail: LMM@acm.org |
| URI: http://larry.masinter.net/ |  | URI: http://larry.masinter.net/ |
| Paul J. Leach |  | Paul J. Leach |
| Microsoft Corporation |  | Microsoft Corporation |
| 1 Microsoft Way |  | 1 Microsoft Way |
| Redmond, WA 98052 |  | Redmond, WA 98052 |
| Email: paulle@microsoft.com |  | EMail: paulle@microsoft.com |
| Tim Berners-Lee |  | Tim Berners-Lee |
| World Wide Web Consortium |  | World Wide Web Consortium |
| MIT Computer Science and Artificial Intelligence Laboratory |  | MIT Computer Science and Artificial Intelligence Laboratory |
| The Stata Center, Building 32 |  | The Stata Center, Building 32 |
| 32 Vassar Street |  | 32 Vassar Street |
| Cambridge, MA 02139 |  | Cambridge, MA 02139 |
| USA |  | USA |
| Email: timbl@w3.org |  | EMail: timbl@w3.org |
| URI: http://www.w3.org/People/Berners-Lee/ |  | URI: http://www.w3.org/People/Berners-Lee/ |
| Yves Lafon (editor) |  | Yves Lafon (editor) |
| World Wide Web Consortium |  | World Wide Web Consortium |
| W3C / ERCIM |  | W3C / ERCIM |
| 2004, rte des Lucioles |  | 2004, rte des Lucioles |
| Sophia-Antipolis, AM 06902 |  | Sophia-Antipolis, AM 06902 |
| France |  | France |
| Email: ylafon@w3.org |  | EMail: ylafon@w3.org |
| URI: http://www.raubacapeu.net/people/yves/ |  | URI: http://www.raubacapeu.net/people/yves/ |
| Julian F. Reschke (editor) |  | Julian F. Reschke (editor) |
| greenbytes GmbH |  | greenbytes GmbH |
| Hafenweg 16 |  | Hafenweg 16 |
| Muenster, NW 48155 |  | Muenster, NW 48155 |
| Germany |  | Germany |
| Phone: +49 251 2807760 |  | Phone: +49 251 2807760 |
| Fax: +49 251 2807761 |  | Fax: +49 251 2807761 |
| Email: julian.reschke@greenbytes.de |  | EMail: julian.reschke@greenbytes.de |
| URI: http://greenbytes.de/tech/webdav/ |  | URI: http://greenbytes.de/tech/webdav/ |
End of changes. 110 change blocks.
| 238 lines changed or deleted |  | 295 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/