| draft-ietf-httpbis-p3-payload-07.txt |  | draft-ietf-httpbis-p3-payload-08.txt |
--- | --- | --- | --- | ---
| HTTPbis Working Group R. Fielding, Ed. |  | HTTPbis Working Group R. Fielding, Ed. |
| Internet-Draft Day Software |  | Internet-Draft Day Software |
| Obsoletes: 2616 (if approved) J. Gettys |  | Obsoletes: 2616 (if approved) J. Gettys |
| Intended status: Standards Track One Laptop per Child |  | Intended status: Standards Track One Laptop per Child |
| Expires: January 14, 2010 J. Mogul |  | Expires: April 29, 2010 J. Mogul |
| HP |  | HP |
| H. Frystyk |  | H. Frystyk |
| Microsoft |  | Microsoft |
| L. Masinter |  | L. Masinter |
| Adobe Systems |  | Adobe Systems |
| P. Leach |  | P. Leach |
| Microsoft |  | Microsoft |
| T. Berners-Lee |  | T. Berners-Lee |
| W3C/MIT |  | W3C/MIT |
| Y. Lafon, Ed. |  | Y. Lafon, Ed. |
| W3C |  | W3C |
| J. Reschke, Ed. |  | J. Reschke, Ed. |
| greenbytes |  | greenbytes |
| July 13, 2009 |  | October 26, 2009 |
| 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-07 |  | draft-ietf-httpbis-p3-payload-08 |
| Status of this Memo |  | Status of this Memo |
| This Internet-Draft is submitted to IETF in full conformance with the |  | This Internet-Draft is submitted to IETF in full conformance with the |
| provisions of BCP 78 and BCP 79. This document may contain material |  | provisions of BCP 78 and BCP 79. This document may contain material |
| from IETF Documents or IETF Contributions published or made publicly |  | from IETF Documents or IETF Contributions published or made publicly |
| available before November 10, 2008. The person(s) controlling the |  | available before November 10, 2008. The person(s) controlling the |
| copyright in some of this material may not have granted the IETF |  | copyright in some of this material may not have granted the IETF |
| Trust the right to allow modifications of such material outside the |  | Trust the right to allow modifications of such material outside the |
| IETF Standards Process. Without obtaining an adequate license from |  | IETF Standards Process. Without obtaining an adequate license from |
| skipping to change at page 2, line 10 |  | skipping to change at page 2, line 10 |
| Internet-Drafts are draft documents valid for a maximum of six months |  | Internet-Drafts are draft documents valid for a maximum of six months |
| and may be updated, replaced, or obsoleted by other documents at any |  | and may be updated, replaced, or obsoleted by other documents at any |
| time. It is inappropriate to use Internet-Drafts as reference |  | time. It is inappropriate to use Internet-Drafts as reference |
| material or to cite them other than as "work in progress." |  | material or to cite them other than as "work in progress." |
| The list of current Internet-Drafts can be accessed at |  | The list of current Internet-Drafts can be accessed at |
| http://www.ietf.org/ietf/1id-abstracts.txt. |  | http://www.ietf.org/ietf/1id-abstracts.txt. |
| The list of Internet-Draft Shadow Directories can be accessed at |  | The list of Internet-Draft Shadow Directories can be accessed at |
| http://www.ietf.org/shadow.html. |  | http://www.ietf.org/shadow.html. |
| This Internet-Draft will expire on January 14, 2010. |  | This Internet-Draft will expire on April 29, 2010. |
| Copyright Notice |  | Copyright Notice |
| Copyright (c) 2009 IETF Trust and the persons identified as the |  | Copyright (c) 2009 IETF Trust and the persons identified as the |
| document authors. All rights reserved. |  | document authors. All rights reserved. |
| This document is subject to BCP 78 and the IETF Trust's Legal |  | This document is subject to BCP 78 and the IETF Trust's Legal |
| Provisions Relating to IETF Documents in effect on the date of |  | Provisions Relating to IETF Documents in effect on the date of |
| publication of this document (http://trustee.ietf.org/license-info). |  | publication of this document (http://trustee.ietf.org/license-info). |
| Please review these documents carefully, as they describe your rights |  | Please review these documents carefully, as they describe your rights |
| skipping to change at page 2, line 41 |  | skipping to change at page 2, line 41 |
| 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/11> 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.8. |  | The changes in this draft are summarized in Appendix E.9. |
| Table of Contents |  | Table of Contents |
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 |  | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 |
| 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 |  | 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 |
| 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5 |  | 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 |
| 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 6 |  | 1.3. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 |
| 1.2.2. ABNF Rules defined in other Parts of the |  | 1.3.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 6 |
|  |  | 1.3.2. ABNF Rules defined in other Parts of the |
| Specification . . . . . . . . . . . . . . . . . . . . 6 |  | Specification . . . . . . . . . . . . . . . . . . . . 6 |
| 2. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 6 |  | 2. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 7 |
| 2.1. Character Sets . . . . . . . . . . . . . . . . . . . . . . 6 |  | 2.1. Character Sets . . . . . . . . . . . . . . . . . . . . . . 7 |
| 2.1.1. Missing Charset . . . . . . . . . . . . . . . . . . . 7 |  | 2.1.1. Missing Charset . . . . . . . . . . . . . . . . . . . 8 |
| 2.2. Content Codings . . . . . . . . . . . . . . . . . . . . . 7 |  | 2.2. Content Codings . . . . . . . . . . . . . . . . . . . . . 8 |
|  |  | 2.2.1. Content Coding Registry . . . . . . . . . . . . . . . 9 |
| 2.3. Media Types . . . . . . . . . . . . . . . . . . . . . . . 9 |  | 2.3. Media Types . . . . . . . . . . . . . . . . . . . . . . . 9 |
| 2.3.1. Canonicalization and Text Defaults . . . . . . . . . . 9 |  | 2.3.1. Canonicalization and Text Defaults . . . . . . . . . . 10 |
| 2.3.2. Multipart Types . . . . . . . . . . . . . . . . . . . 10 |  | 2.3.2. Multipart Types . . . . . . . . . . . . . . . . . . . 11 |
| 2.4. Language Tags . . . . . . . . . . . . . . . . . . . . . . 11 |  | 2.4. Language Tags . . . . . . . . . . . . . . . . . . . . . . 11 |
| 3. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 |  | 3. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 |
| 3.1. Entity Header Fields . . . . . . . . . . . . . . . . . . . 12 |  | 3.1. Entity Header Fields . . . . . . . . . . . . . . . . . . . 12 |
| 3.2. Entity Body . . . . . . . . . . . . . . . . . . . . . . . 12 |  | 3.2. Entity Body . . . . . . . . . . . . . . . . . . . . . . . 13 |
| 3.2.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 12 |  | 3.2.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 13 |
| 3.2.2. Entity Length . . . . . . . . . . . . . . . . . . . . 13 |  | 3.2.2. Entity Length . . . . . . . . . . . . . . . . . . . . 13 |
| 4. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 13 |  | 4. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 14 |
| 4.1. Server-driven Negotiation . . . . . . . . . . . . . . . . 14 |  | 4.1. Server-driven Negotiation . . . . . . . . . . . . . . . . 14 |
| 4.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . . 15 |  | 4.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . . 15 |
| 4.3. Transparent Negotiation . . . . . . . . . . . . . . . . . 15 |  | 4.3. Transparent Negotiation . . . . . . . . . . . . . . . . . 16 |
| 5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 16 |  | 5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 16 |
| 5.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . . 16 |  | 5.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . . 17 |
| 5.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . . 18 |  | 5.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . . 19 |
| 5.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 19 |  | 5.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 20 |
| 5.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 20 |  | 5.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 21 |
| 5.5. Content-Encoding . . . . . . . . . . . . . . . . . . . . . 22 |  | 5.5. Content-Encoding . . . . . . . . . . . . . . . . . . . . . 23 |
| 5.6. Content-Language . . . . . . . . . . . . . . . . . . . . . 23 |  | 5.6. Content-Language . . . . . . . . . . . . . . . . . . . . . 23 |
| 5.7. Content-Location . . . . . . . . . . . . . . . . . . . . . 24 |  | 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 . . . . . . . . . . . . . . . . . . . . . 27 |
| 6.1. Message Header Registration . . . . . . . . . . . . . . . 26 |  | 6.1. Message Header Registration . . . . . . . . . . . . . . . 27 |
| 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 |  | 6.2. Content Coding Registry . . . . . . . . . . . . . . . . . 27 |
| 7.1. Privacy Issues Connected to Accept Headers . . . . . . . . 27 |  | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 |
| 7.2. Content-Disposition Issues . . . . . . . . . . . . . . . . 28 |  | 7.1. Privacy Issues Connected to Accept Headers . . . . . . . . 28 |
| 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 |  | 7.2. Content-Disposition Issues . . . . . . . . . . . . . . . . 29 |
| 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 |  | 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 |
| 9.1. Normative References . . . . . . . . . . . . . . . . . . . 28 |  | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 |
| 9.2. Informative References . . . . . . . . . . . . . . . . . . 30 |  | 9.1. Normative References . . . . . . . . . . . . . . . . . . . 29 |
|  |  | 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 . . . . . . . . . . . . . . . . . . . . . . . 31 |  | 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 . . . . . . . . . . . . . 32 |  | 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 . . . . . . . . . . . . . . . . . 33 |  | Appendix B. Additional Features . . . . . . . . . . . . . . . . . 34 |
| B.1. Content-Disposition . . . . . . . . . . . . . . . . . . . 34 |  | B.1. Content-Disposition . . . . . . . . . . . . . . . . . . . 35 |
| Appendix C. Compatibility with Previous Versions . . . . . . . . 34 |  | Appendix C. Compatibility with Previous Versions . . . . . . . . 35 |
| C.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 34 |  | 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) . . . . . . . . . . . . . . . . . . . . 37 |  | publication) . . . . . . . . . . . . . . . . . . . . 38 |
| E.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 37 |  | E.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 38 |
| E.2. Since draft-ietf-httpbis-p3-payload-00 . . . . . . . . . . 37 |  | E.2. Since draft-ietf-httpbis-p3-payload-00 . . . . . . . . . . 38 |
| E.3. Since draft-ietf-httpbis-p3-payload-01 . . . . . . . . . . 38 |  | E.3. Since draft-ietf-httpbis-p3-payload-01 . . . . . . . . . . 39 |
| E.4. Since draft-ietf-httpbis-p3-payload-02 . . . . . . . . . . 38 |  | 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 . . . . . . . . . . 39 |  | E.6. Since draft-ietf-httpbis-p3-payload-04 . . . . . . . . . . 40 |
| E.7. Since draft-ietf-httpbis-p3-payload-05 . . . . . . . . . . 39 |  | E.7. Since draft-ietf-httpbis-p3-payload-05 . . . . . . . . . . 40 |
| E.8. Since draft-ietf-httpbis-p3-payload-06 . . . . . . . . . . 40 |  | E.8. Since draft-ietf-httpbis-p3-payload-06 . . . . . . . . . . 41 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 |  | E.9. Since draft-ietf-httpbis-p3-payload-07 . . . . . . . . . . 41 |
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 |
|  |  | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 |
| 1. Introduction |  | 1. Introduction |
| This document defines HTTP/1.1 message payloads (a.k.a., content), |  | This document defines HTTP/1.1 message payloads (a.k.a., content), |
| the associated metadata header fields that define how the payload is |  | the associated metadata header fields that define how the payload is |
| intended to be interpreted by a recipient, the request header fields |  | intended to be interpreted by a recipient, the request header fields |
| that may influence content selection, and the various selection |  | that may influence content selection, and the various selection |
| algorithms that are collectively referred to as HTTP content |  | algorithms that are collectively referred to as HTTP content |
| negotiation. |  | negotiation. |
| 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 |
| how widely dispersed these topics and associated requirements had |  | how widely dispersed these topics and associated requirements had |
| become in [RFC2616]. |  | become in [RFC2616]. |
| 1.1. Requirements |  | 1.1. Terminology |
|  |  | This specification uses a number of terms to refer to the roles |
|  |  | played by participants in, and objects of, the HTTP communication. |
|  |  | content negotiation |
|  |  | The mechanism for selecting the appropriate representation when |
|  |  | servicing a request. The representation of entities in any |
|  |  | response can be 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 |
| 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.2. 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 |
| (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), |  | (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), |
| 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.2.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> |
| OWS = <OWS, defined in [Part1], Section 1.2.2> |  | OWS = <OWS, defined in [Part1], Section 1.2.2> |
| 1.2.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.1> |  | absolute-URI = <absolute-URI, defined in [Part1], Section 2.6> |
| Content-Length = <Content-Length, defined in [Part1], Section 8.2> |  | Content-Length = <Content-Length, defined in [Part1], Section 9.2> |
| message-header = <message-header, defined in [Part1], Section 4.2> |  | header-field = <header-field, defined in [Part1], Section 3.2> |
| partial-URI = <partial-URI, defined in [Part1], Section 2.1> |  | partial-URI = <partial-URI, defined in [Part1], Section 2.6> |
| qvalue = <qvalue, defined in [Part1], Section 3.5> |  | qvalue = <qvalue, defined in [Part1], Section 6.4> |
| Last-Modified = <Last-Modified, defined in [Part4], Section 6.6> |  | Last-Modified = <Last-Modified, defined in [Part4], Section 6.6> |
| Content-Range = <Content-Range, defined in [Part5], Section 5.2> |  | Content-Range = <Content-Range, defined in [Part5], Section 5.2> |
| Expires = <Expires, defined in [Part6], Section 3.3> |  | Expires = <Expires, defined in [Part6], Section 3.3> |
| 2. Protocol Parameters |  | 2. Protocol Parameters |
| 2.1. Character Sets |  | 2.1. Character Sets |
| skipping to change at page 8, line 16 |  | skipping to change at page 8, line 46 |
| 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 5.3) and |
| Content-Encoding (Section 5.5) header fields. Although the value |  | Content-Encoding (Section 5.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. |
| The Internet Assigned Numbers Authority (IANA) acts as a registry for |  |  |
| content-coding value tokens. Initially, the registry contains the |  |  |
| following tokens: |  |  |
| gzip |  |  |
| An encoding format produced by the file compression program "gzip" |  |  |
| (GNU zip) as described in [RFC1952]. This format is a Lempel-Ziv |  |  |
| coding (LZ77) with a 32 bit CRC. |  |  |
| compress |  | compress |
| The encoding format produced by the common UNIX file compression |  | See Section 6.2.2.1 of [Part1]. |
| program "compress". This format is an adaptive Lempel-Ziv-Welch |  |  |
| coding (LZW). |  |  |
| Use of program names for the identification of encoding formats is |  |  |
| not desirable and is discouraged for future encodings. Their use |  |  |
| here is representative of historical practice, not good design. |  |  |
| For compatibility with previous implementations of HTTP, |  |  |
| applications SHOULD consider "x-gzip" and "x-compress" to be |  |  |
| equivalent to "gzip" and "compress" respectively. |  |  |
| deflate |  | deflate |
|  |  | See Section 6.2.2.2 of [Part1]. |
| The "zlib" format defined in [RFC1950] in combination with the |  | gzip |
| "deflate" compression mechanism described in [RFC1951]. |  |  |
|  |  | 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- |
| Encoding header, and SHOULD NOT be used in the Content-Encoding |  | Encoding header, and SHOULD NOT be used in the Content-Encoding |
| header. |  | header. |
| New content-coding value tokens SHOULD be registered; to allow |  | 2.2.1. Content Coding Registry |
| interoperability between clients and servers, specifications of the |  |  |
| content coding algorithms needed to implement a new value SHOULD be |  | The HTTP Content Coding Registry defines the name space for the |
| publicly available and adequate for independent implementation, and |  | content coding names. |
| conform to the purpose of content coding defined in this section. |  |  |
|  |  | Registrations MUST include the following fields: |
|  |  | o Name |
|  |  | o Description |
|  |  | o Pointer to specification text |
|  |  | Values to be added to this name space require expert review and a |
|  |  | specification (see "Expert Review" and "Specification Required" in |
|  |  | Section 4.1 of [RFC5226]), and MUST conform to the purpose of content |
|  |  | coding defined in this section. |
|  |  | The registry itself is maintained at |
|  |  | <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 5.9) and Accept (Section 5.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 |
| skipping to change at page 11, line 17 |  | skipping to change at page 11, line 48 |
| 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. |
| 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 identifies a natural language spoken, written, or |  | A language tag, as defined in [RFC5646], identifies a natural |
| otherwise conveyed by human beings for communication of information |  | language spoken, written, or otherwise conveyed by human beings for |
| to other human beings. Computer languages are explicitly excluded. |  | communication of information to other human beings. Computer |
| HTTP uses language tags within the Accept-Language and Content- |  | languages are explicitly excluded. HTTP uses language tags within |
| Language fields. |  | the Accept-Language and Content-Language fields. |
| The syntax and registry of HTTP language tags is the same as that |  | In summary, a language tag is composed of one or more parts: A |
| defined by [RFC1766]. In summary, a language tag is composed of 1 or |  | primary language subtag followed by a possibly empty series of |
| more parts: A primary language tag and a possibly empty series of |  |  |
| subtags: |  | subtags: |
| language-tag = primary-tag *( "-" subtag ) |  | language-tag = <Language-Tag, defined in [RFC5646], Section 2.1> |
| primary-tag = 1*8ALPHA |  |  |
| subtag = 1*8ALPHA |  |  |
| White space is not allowed within the tag and all tags are case- |  | White space is not allowed within the tag and all tags are case- |
| insensitive. The name space of language tags is administered by the |  | insensitive. The name space of language subtags is administered by |
| IANA. Example tags include: |  | the IANA (see |
|  |  | <http://www.iana.org/assignments/language-subtag-registry>). |
| en, en-US, en-cockney, i-cherokee, x-pig-latin |  | Example tags include: |
| where any two-letter primary-tag is an ISO-639 language abbreviation |  | en, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN |
| and any two-letter initial subtag is an ISO-3166 country code. (The |  |  |
| last three tags above are not registered tags; all but the last are |  | See [RFC5646] for further information. |
| examples of tags which could be registered in future.) |  |  |
| 3. Entity |  | 3. Entity |
| Request and Response messages MAY transfer an entity if not otherwise |  | Request and Response messages MAY transfer an entity if not otherwise |
| restricted by the request method or response status code. An entity |  | restricted by the request method or response status code. An entity |
| consists of entity-header fields and an entity-body, although some |  | consists of entity-header fields and an entity-body, although some |
| responses will only include the entity-headers. |  | responses will only include the entity-headers. |
| In this section, both sender and recipient refer to either the client |  | In this section, both sender and recipient refer to either the client |
| or the server, depending on who sends and who receives the entity. |  | or the server, depending on who sends and who receives the entity. |
| 3.1. Entity Header Fields |  | 3.1. Entity Header Fields |
| Entity-header fields define metainformation about the entity-body or, |  | Entity-header fields define metainformation about the entity-body or, |
| if no body is present, about the resource identified by the request. |  | if no body is present, about the resource identified by the request. |
| entity-header = Content-Encoding ; Section 5.5 |  | entity-header = Content-Encoding ; Section 5.5 |
| / Content-Language ; Section 5.6 |  | / Content-Language ; Section 5.6 |
| / Content-Length ; [Part1], Section 8.2 |  | / Content-Length ; [Part1], Section 9.2 |
| / Content-Location ; Section 5.7 |  | / Content-Location ; Section 5.7 |
| / Content-MD5 ; Section 5.8 |  | / Content-MD5 ; Section 5.8 |
| / Content-Range ; [Part5], Section 5.2 |  | / Content-Range ; [Part5], Section 5.2 |
| / Content-Type ; Section 5.9 |  | / Content-Type ; Section 5.9 |
| / Expires ; [Part6], Section 3.3 |  | / Expires ; [Part6], Section 3.3 |
| / Last-Modified ; [Part4], Section 6.6 |  | / Last-Modified ; [Part4], Section 6.6 |
| / extension-header |  | / extension-header |
| extension-header = message-header |  | extension-header = header-field |
| The extension-header mechanism allows additional entity-header fields |  | The extension-header mechanism allows additional entity-header fields |
| to be defined without changing the protocol, but these fields cannot |  | to be defined without changing the protocol, but these fields cannot |
| be assumed to be recognizable by the recipient. Unrecognized header |  | be assumed to be recognizable by the recipient. Unrecognized header |
| fields SHOULD be ignored by the recipient and MUST be forwarded by |  | fields SHOULD be ignored by the recipient and MUST be forwarded by |
| transparent proxies. |  | transparent proxies. |
| 3.2. Entity Body |  | 3.2. Entity Body |
| The entity-body (if any) sent with an HTTP request or response is in |  | The entity-body (if any) sent with an HTTP request or response is in |
| a format and encoding defined by the entity-header fields. |  | a format and encoding defined by the entity-header fields. |
| entity-body = *OCTET |  | entity-body = *OCTET |
| An entity-body is only present in a message when a message-body is |  | An entity-body is only present in a message when a message-body is |
| present, as described in Section 4.3 of [Part1]. The entity-body is |  | present, as described in Section 3.3 of [Part1]. The entity-body is |
| obtained from the message-body by decoding any Transfer-Encoding that |  | obtained from the message-body by decoding any Transfer-Encoding that |
| might have been applied to ensure safe and proper transfer of the |  | might have been applied to ensure safe and proper transfer of the |
| message. |  | message. |
| 3.2.1. Type |  | 3.2.1. Type |
| 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: |
| skipping to change at page 13, line 17 |  | skipping to change at page 13, line 43 |
| present, it indicates that the sender does not know the media type of |  | present, it indicates that the sender does not know the media type of |
| the data; recipients MAY either assume that it is "application/ |  | the data; recipients MAY either assume that it is "application/ |
| octet-stream" ([RFC2046], Section 4.5.1) or examine the content to |  | octet-stream" ([RFC2046], Section 4.5.1) or examine the content to |
| determine its type. |  | determine its type. |
| 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. |
| Note that neither the interpretation of the data type of a message |  |  |
| nor the behaviors caused by it are defined by HTTP; this potentially |  |  |
| includes examination of the content to override any indicated type |  |  |
| ("sniffing"). |  |  |
| 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 4.4 of |  | before any transfer-codings have been applied. Section 3.4 of |
| [Part1] defines how the transfer-length of a message-body is |  | [Part1] defines how the transfer-length of a message-body is |
| determined. |  | determined. |
| 4. Content Negotiation |  | 4. Content Negotiation |
| Most HTTP responses include an entity which contains information for |  | Most HTTP responses include an entity which contains information for |
| interpretation by a human user. Naturally, it is desirable to supply |  | interpretation by a human user. Naturally, it is desirable to supply |
| the user with the "best available" entity corresponding to the |  | the user with the "best available" entity corresponding to the |
| request. Unfortunately for servers and caches, not all users have |  | request. Unfortunately for servers and caches, not all users have |
| the same preferences for what is "best," and not all user agents are |  | the same preferences for what is "best," and not all user agents are |
| skipping to change at page 16, line 29 |  | skipping to change at page 17, line 7 |
| This section defines the syntax and semantics of HTTP/1.1 header |  | This section defines the syntax and semantics of HTTP/1.1 header |
| fields related to the payload of messages. |  | fields related to the payload of messages. |
| For entity-header fields, both sender and recipient refer to either |  | For entity-header fields, both sender and recipient refer to either |
| the client or the server, depending on who sends and who receives the |  | the client or the server, depending on who sends and who receives the |
| entity. |  | entity. |
| 5.1. Accept |  | 5.1. Accept |
| The request-header field "Accept" can be used to specify certain |  | The "Accept" request-header field can be used by user agents to |
| media types which are acceptable for the response. Accept headers |  | specify response media types that are acceptable. Accept headers can |
| 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 ] ) |
| media-range = ( "*/*" |  | media-range = ( "*/*" |
| / ( type "/" "*" ) |  | / ( type "/" "*" ) |
| / ( type "/" subtype ) |  | / ( type "/" subtype ) |
| ) *( OWS ";" OWS parameter ) |  | ) *( OWS ";" OWS parameter ) |
| skipping to change at page 17, line 10 |  | skipping to change at page 17, line 34 |
| 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 |
| or user agent to indicate the relative degree of preference for that |  | or user agent to indicate the relative degree of preference for that |
| media-range, using the qvalue scale from 0 to 1 (Section 3.5 of |  | media-range, using the qvalue scale from 0 to 1 (Section 6.4 of |
| [Part1]). The default value is q=1. |  | [Part1]). The default value is q=1. |
| Note: Use of the "q" parameter name to separate media type |  | Note: Use of the "q" parameter name to separate media type |
| parameters from Accept extension parameters is due to historical |  | parameters from Accept extension parameters is due to historical |
| practice. Although this prevents any media type parameter named |  | practice. Although this prevents any media type parameter named |
| "q" from being used with a media range, such an event is believed |  | "q" from being used with a media range, such an event is believed |
| 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". |
| skipping to change at page 18, line 40 |  | skipping to change at page 19, line 23 |
| | 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 |  | 5.2. Accept-Charset |
| The request-header field "Accept-Charset" can be used to indicate |  | The "Accept-Charset" request-header field can be used by user agents |
| what character sets are acceptable for the response. 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 / "*" ) |
| [ OWS ";" OWS "q=" qvalue ] ) |  | [ OWS ";" OWS "q=" qvalue ] ) |
| Character set values are described in Section 2.1. Each charset MAY |  | Character set values are described in Section 2.1. Each charset MAY |
| skipping to change at page 19, line 25 |  | skipping to change at page 20, line 8 |
| 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 |  | 5.3. Accept-Encoding |
| The request-header field "Accept-Encoding" is similar to Accept, but |  | The "Accept-Encoding" request-header field can be used by user agents |
| restricts the content-codings (Section 2.2) that are acceptable in |  | to indicate what response content-codings (Section 2.2) are |
| 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 / "*" ) |
| Each codings value MAY be given an associated quality value which |  | Each codings value MAY be given an associated quality value which |
| represents the preference for that encoding. The default value is |  | represents the preference for that encoding. The default value is |
| q=1. |  | q=1. |
| skipping to change at page 20, line 4 |  | skipping to change at page 20, line 35 |
| Accept-Encoding: |  | Accept-Encoding: |
| 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 3.5 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 |
| skipping to change at page 20, line 47 |  | skipping to change at page 21, line 31 |
| 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 |  | 5.4. Accept-Language |
| The request-header field "Accept-Language" is similar to Accept, but |  | The "Accept-Language" request-header field can be used by user agents |
| restricts the set of natural languages that are preferred as a |  | to indicate the set of natural languages that are preferred in the |
| response to the request. 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 |
| skipping to change at page 22, line 23 |  | skipping to change at page 23, line 7 |
| 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 should provide appropriate guidance. As an example, users |
| might assume that on selecting "en-gb", they will be served any |  | might assume that on selecting "en-gb", they will be served any |
| kind of English document if British English is not available. A |  | kind of English document if British English is not available. A |
| user agent might suggest in such a case to add "en" to get the |  | user agent might suggest in such a case to add "en" to get the |
| best matching behavior. |  | best matching behavior. |
| 5.5. Content-Encoding |  | 5.5. Content-Encoding |
| The entity-header field "Content-Encoding" is used as a modifier to |  | The "Content-Encoding" entity-header field indicates what content- |
| the media-type. When present, its value indicates what additional |  | codings have been applied to the entity-body, and thus what decoding |
| content codings have been applied to the entity-body, and thus what |  | mechanisms must be applied in order to obtain the media-type |
| decoding 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 document to be compressed without losing |
| 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 |
| skipping to change at page 23, line 12 |  | skipping to change at page 23, line 43 |
| 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 |
| codings MUST be listed in the order in which they were applied. |  | codings MUST be listed in the order in which they were applied. |
| Additional information about the encoding parameters MAY be provided |  | Additional information about the encoding parameters MAY be provided |
| by other entity-header fields not defined by this specification. |  | by other entity-header fields not defined by this specification. |
| 5.6. Content-Language |  | 5.6. Content-Language |
| The entity-header field "Content-Language" describes the natural |  | The "Content-Language" entity-header field describes the natural |
| language(s) of the intended audience for the enclosed entity. Note |  | language(s) of the intended audience for the entity. Note that this |
| that this might not be equivalent to all the languages used within |  | might not be equivalent to all the languages used within the entity- |
| the entity-body. |  | body. |
| 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 |  | entities according to the user's own preferred language. Thus, if |
| the body content is intended only for a Danish-literate audience, the |  | the body content is intended only for a Danish-literate audience, the |
| appropriate field is |  | appropriate field is |
| skipping to change at page 24, line 7 |  | skipping to change at page 24, line 34 |
| An example would be a beginner's language primer, such as "A First |  | An example would be a beginner's language primer, such as "A First |
| Lesson in Latin," which is clearly intended to be used by an English- |  | Lesson in Latin," which is clearly intended to be used by an English- |
| literate audience. In this case, the Content-Language would properly |  | literate audience. In this case, the Content-Language would properly |
| only include "en". |  | 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 |  | 5.7. Content-Location |
| The entity-header field "Content-Location" MAY be used to supply the |  | The "Content-Location" entity-header field is used to supply a URI |
| resource location for the entity enclosed in the message when that |  | for the entity in the message when it is accessible from a location |
| entity is accessible from a location separate from the requested |  | separate from the requested resource's URI. |
| resource's URI. A server SHOULD provide a Content-Location for the |  |  |
| variant corresponding to the response entity; especially in the case |  | A server SHOULD provide a Content-Location for the variant |
| where a resource has multiple entities associated with it, and those |  | corresponding to the response entity, especially in the case where a |
| entities actually have separate locations by which they might be |  | resource has multiple entities associated with it, and those entities |
| individually accessed, the server SHOULD provide a Content-Location |  | actually have separate locations by which they might be individually |
| for the particular variant which is returned. |  | accessed, the server SHOULD provide a Content-Location for the |
|  |  | 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 value of Content-Location also defines the base URI for the |  |  |
| entity. |  |  |
| The Content-Location value is not a replacement for the original |  | The Content-Location value is not a replacement for the original |
| requested URI; it is only a statement of the location of the resource |  | requested URI; it is only a statement of the location of the resource |
| corresponding to this particular entity at the time of the request. |  | corresponding to this particular entity at the time of the request. |
| Future requests MAY specify the Content-Location URI as the request- |  | Future requests MAY specify the Content-Location URI as the request- |
| target if the desire is to identify the source of that particular |  | target if the desire is to identify the source of that particular |
| entity. |  | entity. |
|  |  | Section 6.1 of [Part2] describes how clients may process the Content- |
|  |  | 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.6 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 request-target. |
| 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 entity-header field "Content-MD5", as defined in [RFC1864], is an |  | The "Content-MD5" entity-header field, as defined in [RFC1864], is an |
| MD5 digest of the entity-body for the purpose of providing an end-to- |  | MD5 digest of the entity-body that provides an end-to-end message |
| end message integrity check (MIC) of the entity-body. (Note: a MIC |  | integrity check (MIC) of the entity-body. Note that a MIC is good |
| is good for detecting accidental modification of the entity-body in |  | for detecting accidental modification of the entity-body in transit, |
| transit, but is not proof against malicious attacks.) |  | 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 entity-body. Only |
| origin servers or clients MAY generate the Content-MD5 header field; |  | origin servers or clients MAY generate the Content-MD5 header field; |
| proxies and gateways MUST NOT generate it, as this would defeat its |  | proxies and gateways MUST NOT generate it, as this would defeat its |
| value as an end-to-end integrity check. Any recipient of the entity- |  | value as an end-to-end integrity check. Any recipient of the entity- |
| body, including gateways and proxies, MAY check that the digest value |  | body, including gateways and proxies, MAY check that the digest value |
| in this header field matches that of the entity-body as received. |  | in this header field matches that of the entity-body as received. |
| skipping to change at page 26, line 11 |  | skipping to change at page 26, line 40 |
| 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 |  | 5.9. Content-Type |
| The entity-header field "Content-Type" indicates the media type of |  | The "Content-Type" entity-header field indicates the media type of |
| the entity-body sent to the recipient or, in the case of the HEAD |  | the entity-body. In the case of responses to the HEAD method, the |
| method, the media type that would have been sent had the request been |  | media type is that which would have been sent had the request been a |
| 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 methods for identifying the media type of an |
| entity is provided in Section 3.2.1. |  | entity is provided in Section 3.2.1. |
| 6. IANA Considerations |  | 6. IANA Considerations |
| 6.1. Message Header Registration |  | 6.1. Message Header Registration |
| The Message Header Registry located at <http://www.iana.org/ |  | The Message Header Registry located at <http://www.iana.org/ |
| assignments/message-headers/message-header-index.html> should be |  | assignments/message-headers/message-header-index.html> should be |
| updated with the permanent registrations below (see [RFC3864]): |  | updated with the permanent registrations below (see [RFC3864]): |
| skipping to change at page 27, line 6 |  | skipping to change at page 27, line 34 |
| | Content-Language | http | standard | Section 5.6 | |  | | Content-Language | http | standard | Section 5.6 | |
| | Content-Location | http | standard | Section 5.7 | |  | | Content-Location | http | standard | Section 5.7 | |
| | Content-MD5 | http | standard | Section 5.8 | |  | | Content-MD5 | http | standard | Section 5.8 | |
| | Content-Type | http | standard | Section 5.9 | |  | | Content-Type | http | standard | Section 5.9 | |
| | MIME-Version | http | | Appendix A.1 | |  | | MIME-Version | http | | 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 |
|  |  | The registration procedure for HTTP Content Codings is now defined by |
|  |  | Section 2.2.1 of this document. |
|  |  | The HTTP Content Codings Registry located at |
|  |  | <http://www.iana.org/assignments/http-parameters> should be updated |
|  |  | with the registration below: |
|  |  | +----------+-----------------------------------+--------------------+ |
|  |  | | Name | Description | Reference | |
|  |  | +----------+-----------------------------------+--------------------+ |
|  |  | | compress | UNIX "compress" program method | Section 6.2.2.1 of | |
|  |  | | | | [Part1] | |
|  |  | | deflate | "zlib" format [RFC1950] with | Section 6.2.2.2 of | |
|  |  | | | "deflate" compression | [Part1] | |
|  |  | | 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 29 |  | skipping to change at page 29, line 36 |
| [ISO-8859-1] |  | [ISO-8859-1] |
| International Organization for Standardization, |  | International Organization for Standardization, |
| "Information technology -- 8-bit single-byte coded graphic |  | "Information technology -- 8-bit single-byte coded graphic |
| character sets -- Part 1: Latin alphabet No. 1", ISO/ |  | character sets -- Part 1: Latin alphabet No. 1", ISO/ |
| IEC 8859-1:1998, 1998. |  | IEC 8859-1:1998, 1998. |
| [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, |  | and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, |
| and Message Parsing", draft-ietf-httpbis-p1-messaging-07 |  | and Message Parsing", draft-ietf-httpbis-p1-messaging-08 |
| (work in progress), July 2009. |  | (work in progress), October 2009. |
| [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| and J. Reschke, Ed., "HTTP/1.1, part 2: Message |  | and J. Reschke, Ed., "HTTP/1.1, part 2: Message |
| Semantics", draft-ietf-httpbis-p2-semantics-07 (work in |  | Semantics", draft-ietf-httpbis-p2-semantics-08 (work in |
| progress), July 2009. |  | progress), October 2009. |
| [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional |  | and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional |
| Requests", draft-ietf-httpbis-p4-conditional-07 (work in |  | Requests", draft-ietf-httpbis-p4-conditional-08 (work in |
| progress), July 2009. |  | progress), October 2009. |
| [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and |  | and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and |
| Partial Responses", draft-ietf-httpbis-p5-range-07 (work |  | Partial Responses", draft-ietf-httpbis-p5-range-08 (work |
| in progress), July 2009. |  | in progress), October 2009. |
| [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part |  | Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part |
| 6: Caching", draft-ietf-httpbis-p6-cache-07 (work in |  | 6: Caching", draft-ietf-httpbis-p6-cache-08 (work in |
| progress), July 2009. |  | progress), October 2009. |
| [RFC1766] Alvestrand, H., "Tags for the Identification of |  |  |
| Languages", RFC 1766, March 1995. |  |  |
| [RFC1864] Myers, J. and M. Rose, "The Content-MD5 Header Field", |  | [RFC1864] Myers, J. and M. Rose, "The Content-MD5 Header Field", |
| RFC 1864, October 1995. |  | RFC 1864, October 1995. |
| [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format |  | [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format |
| Specification version 3.3", RFC 1950, May 1996. |  | Specification version 3.3", RFC 1950, May 1996. |
| RFC 1950 is an Informational RFC, thus it may be less |  | RFC 1950 is an Informational RFC, thus it may be less |
| stable than this specification. On the other hand, this |  | stable than this specification. On the other hand, this |
| downward reference was present since the publication of |  | downward reference was present since the publication of |
| RFC 2068 in 1997 ([RFC2068]), therefore it is unlikely to |  | RFC 2068 in 1997 ([RFC2068]), therefore it is unlikely to |
| cause problems in practice. See also [BCP97]. |  | cause problems in practice. See also [BCP97]. |
| [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification |  |  |
| version 1.3", RFC 1951, May 1996. |  |  |
| RFC 1951 is an Informational RFC, thus it may be less |  |  |
| stable than this specification. On the other hand, 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]. |  |  |
| [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G. |  | [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G. |
| Randers-Pehrson, "GZIP file format specification version |  | Randers-Pehrson, "GZIP file format specification version |
| 4.3", RFC 1952, May 1996. |  | 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 may be less |
| stable than this specification. On the other hand, this |  | stable than this specification. On the other hand, this |
| downward reference was present since the publication of |  | downward reference was present since the publication of |
| RFC 2068 in 1997 ([RFC2068]), therefore it is unlikely to |  | RFC 2068 in 1997 ([RFC2068]), therefore it is unlikely to |
| cause problems in practice. See also [BCP97]. |  | cause problems in practice. See also [BCP97]. |
| skipping to change at page 30, line 12 |  | skipping to change at page 31, line 8 |
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |  | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |
| Requirement Levels", BCP 14, RFC 2119, March 1997. |  | Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC4647] Phillips, A., Ed. and M. Davis, Ed., "Matching of Language |  | [RFC4647] Phillips, A., Ed. and M. Davis, Ed., "Matching of Language |
| Tags", BCP 47, RFC 4647, September 2006. |  | Tags", BCP 47, RFC 4647, September 2006. |
| [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax |  | [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax |
| Specifications: ABNF", STD 68, RFC 5234, January 2008. |  | 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 References |
| to Standards-Track Documents", BCP 97, RFC 4897, |  | to Standards-Track Documents", BCP 97, RFC 4897, |
| June 2007. |  | June 2007. |
| [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext |  | [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext |
| Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. |  | 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 Mail |
| skipping to change at page 31, line 12 |  | skipping to change at page 32, line 10 |
| [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, RFC 3864, |
| September 2004. |  | September 2004. |
| [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and |  | [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and |
| Registration Procedures", BCP 13, RFC 4288, December 2005. |  | Registration Procedures", BCP 13, RFC 4288, December 2005. |
|  |  | [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an |
|  |  | IANA Considerations Section in RFCs", BCP 26, 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 |
| skipping to change at page 32, line 33 |  | skipping to change at page 33, line 35 |
| 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 |  | Implementors should note that conversion will break any cryptographic |
| checksums applied to the original content unless the original content |  | checksums applied to the original content unless the original content |
| is already in canonical form. Therefore, the canonical form is |  | is already in canonical form. Therefore, the canonical form is |
| recommended for any content that uses such checksums in HTTP. |  | recommended for any content 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 3.2 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 |  | RFC 2045 does not include any concept equivalent to HTTP/1.1's |
| Content-Encoding header field. Since this acts as a modifier on the |  | Content-Encoding header field. Since this acts as a modifier on the |
| media type, proxies and gateways from HTTP to MIME-compliant |  | media type, proxies and gateways from HTTP to MIME-compliant |
| skipping to change at page 33, line 22 |  | skipping to change at page 34, line 22 |
| 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 |
| safe transport over the destination protocol. |  | safe transport over the destination protocol. |
| A.6. Introduction of Transfer-Encoding |  | A.6. Introduction of Transfer-Encoding |
| HTTP/1.1 introduces the Transfer-Encoding header field (Section 8.7 |  | HTTP/1.1 introduces the Transfer-Encoding header field (Section 9.7 |
| of [Part1]). Proxies/gateways MUST remove any transfer-coding prior |  | of [Part1]). Proxies/gateways MUST remove any transfer-coding prior |
| to forwarding a message via a MIME-compliant protocol. |  | to forwarding a message via a MIME-compliant protocol. |
| A.7. MHTML and Line Length Limitations |  | A.7. MHTML and Line Length Limitations |
| HTTP implementations which share code with MHTML [RFC2557] |  | HTTP implementations which share code with MHTML [RFC2557] |
| implementations need to be aware of MIME line length limitations. |  | implementations need to be aware of MIME line length limitations. |
| Since HTTP does not have this limitation, HTTP does not fold long |  | Since HTTP does not have this limitation, HTTP does not fold long |
| lines. MHTML messages being transported by HTTP follow all |  | lines. MHTML messages being transported by HTTP follow all |
| conventions of MHTML, including line length limitations and folding, |  | conventions of MHTML, including line length limitations and folding, |
| skipping to change at page 34, line 7 |  | skipping to change at page 35, line 7 |
| interoperability with, other HTTP/1.1 applications. Some of these |  | interoperability with, other HTTP/1.1 applications. Some of these |
| describe proposed experimental features, and some describe features |  | describe proposed experimental features, and some describe features |
| that experimental deployment found lacking that are now addressed in |  | that experimental deployment found lacking that are now addressed in |
| the base HTTP/1.1 specification. |  | the base HTTP/1.1 specification. |
| A number of other headers, such as Content-Disposition and Title, |  | A number of other headers, such as Content-Disposition and Title, |
| from SMTP and MIME are also often implemented (see [RFC2076]). |  | from SMTP and MIME are also often implemented (see [RFC2076]). |
| B.1. Content-Disposition |  | B.1. Content-Disposition |
| The Content-Disposition response-header field has been proposed as a |  | The "Content-Disposition" response-header field has been proposed as |
| means for the origin server to suggest a default filename if the user |  | a means for the origin server to suggest a default filename if the |
| requests that the content is saved to a file. This usage is derived |  | user requests that the content is saved to a file. This usage is |
| 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 "=" ( token / quoted-string ) |
| skipping to change at page 35, line 20 |  | skipping to change at page 36, line 20 |
| The Alternates, Content-Version, Derived-From, Link, URI, Public and |  | The Alternates, Content-Version, Derived-From, Link, URI, Public and |
| Content-Base header fields were defined in previous versions of this |  | Content-Base header fields were defined in previous versions of this |
| specification, but not commonly implemented. See Section 19.6.2 of |  | specification, but not commonly implemented. See Section 19.6.2 of |
| [RFC2068]. |  | [RFC2068]. |
| C.2. Changes from RFC 2616 |  | C.2. 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 |
|  |  | implementation support, which was caused by too many broken servers |
|  |  | emitting bogus Content-Location headers, and also the potentially |
|  |  | undesirable effect of potentially breaking relative links in content- |
|  |  | negotiated resources. (Section 5.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=" |
| qvalue ] ] ) |  | qvalue ] ] ) |
| skipping to change at page 35, line 46 |  | skipping to change at page 37, line 6 |
| ] ) |  | ] ) |
| Accept-v = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [ |  | Accept-v = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [ |
| OWS media-range [ accept-params ] ] ) ] |  | OWS media-range [ accept-params ] ] ) ] |
| Content-Encoding = "Content-Encoding:" OWS Content-Encoding-v |  | Content-Encoding = "Content-Encoding:" OWS Content-Encoding-v |
| Content-Encoding-v = *( "," OWS ) content-coding *( OWS "," [ OWS |  | Content-Encoding-v = *( "," OWS ) content-coding *( OWS "," [ OWS |
| content-coding ] ) |  | content-coding ] ) |
| Content-Language = "Content-Language:" OWS Content-Language-v |  | Content-Language = "Content-Language:" OWS Content-Language-v |
| Content-Language-v = *( "," OWS ) language-tag *( OWS "," [ OWS |  | Content-Language-v = *( "," OWS ) language-tag *( OWS "," [ OWS |
| language-tag ] ) |  | language-tag ] ) |
| Content-Length = <Content-Length, defined in [Part1], Section 8.2> |  | Content-Length = <Content-Length, defined in [Part1], Section 9.2> |
| Content-Location = "Content-Location:" OWS Content-Location-v |  | Content-Location = "Content-Location:" OWS Content-Location-v |
| Content-Location-v = absolute-URI / partial-URI |  | Content-Location-v = absolute-URI / partial-URI |
| 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]> |
| Content-Range = <Content-Range, defined in [Part5], Section 5.2> |  | Content-Range = <Content-Range, defined in [Part5], Section 5.2> |
| 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 |
| 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.1> |  | absolute-URI = <absolute-URI, defined in [Part1], Section 2.6> |
| accept-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ] |  | accept-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ] |
| 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 |
| skipping to change at page 36, line 39 |  | skipping to change at page 37, line 46 |
| disp-extension-parm = token "=" ( token / quoted-string ) |  | disp-extension-parm = token "=" ( token / quoted-string ) |
| 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 = message-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> |
| language-range = <language-range, defined in [RFC4647], Section 2.1> |  | language-range = <language-range, defined in [RFC4647], Section 2.1> |
| language-tag = primary-tag *( "-" subtag ) |  | 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 ) |
| message-header = <message-header, defined in [Part1], Section 4.2> |  |  |
| parameter = attribute "=" value |  | parameter = attribute "=" value |
| partial-URI = <partial-URI, defined in [Part1], Section 2.1> |  | partial-URI = <partial-URI, defined in [Part1], Section 2.6> |
| primary-tag = 1*8ALPHA |  |  |
| 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 3.5> |  | qvalue = <qvalue, defined in [Part1], Section 6.4> |
| subtag = 1*8ALPHA |  |  |
| 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 = token / quoted-string |
| ABNF diagnostics: |  | ABNF diagnostics: |
| ; Accept defined but not used |  | ; Accept defined but not used |
| skipping to change at page 40, line 23 |  | skipping to change at page 41, line 28 |
| E.8. Since draft-ietf-httpbis-p3-payload-06 |  | E.8. Since draft-ietf-httpbis-p3-payload-06 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/80>: "Content- |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/80>: "Content- |
| Location isn't special" |  | Location isn't special" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/155>: "Content |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/155>: "Content |
| Sniffing" |  | Sniffing" |
|  |  | E.9. Since draft-ietf-httpbis-p3-payload-07 |
|  |  | Closed issues: |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/13>: "Updated |
|  |  | reference for language tags" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/110>: "Clarify rules |
|  |  | for determining what entities a response carries" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/154>: "Content- |
|  |  | Location base-setting problems" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/155>: "Content |
|  |  | Sniffing" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/188>: "pick IANA |
|  |  | policy (RFC5226) for Transfer Coding / Content Coding" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/189>: "move |
|  |  | definitions of gzip/deflate/compress to part 1" |
|  |  | Partly resolved issues: |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/148>: "update IANA |
|  |  | requirements wrt Transfer-Coding values" (add the IANA |
|  |  | Considerations subsection) |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/149>: "update IANA |
|  |  | requirements wrt Content-Coding values" (add the IANA |
|  |  | Considerations subsection) |
| Index |  | Index |
| A |  | A |
| Accept header 16 |  | Accept header 17 |
| Accept-Charset header 18 |  | Accept-Charset header 19 |
| Accept-Encoding header 19 |  | Accept-Encoding header 20 |
| Accept-Language header 20 |  | Accept-Language header 21 |
| Alternates header 35 |  | Alternates header 36 |
| C |  | C |
|  |  | Coding Format |
| compress 8 |  | compress 8 |
| Content Type Sniffing 13 |  | deflate 8 |
| Content-Base header 35 |  | gzip 9 |
| Content-Disposition header 34 |  | identity 9 |
| Content-Encoding header 22 |  | compress (Coding Format) 8 |
|  |  | content negotiation 5 |
|  |  | Content-Base header 36 |
|  |  | Content-Disposition header 35 |
|  |  | Content-Encoding header 23 |
| Content-Language header 23 |  | Content-Language header 23 |
| Content-Location header 24 |  | 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 8 |  | deflate (Coding Format) 8 |
| Derived-From header 35 |  | Derived-From header 36 |
|  |  | E |
|  |  | entity 5 |
| G |  | G |
| Grammar |  | Grammar |
| Accept 16 |  | Accept 17 |
| Accept-Charset 18 |  | Accept-Charset 19 |
| Accept-Charset-v 18 |  | Accept-Charset-v 19 |
| Accept-Encoding 19 |  | Accept-Encoding 20 |
| Accept-Encoding-v 19 |  | Accept-Encoding-v 20 |
| accept-ext 16 |  | accept-ext 17 |
| Accept-Language 21 |  | Accept-Language 21 |
| Accept-Language-v 21 |  | Accept-Language-v 21 |
| accept-params 16 |  | accept-params 17 |
| Accept-v 16 |  | Accept-v 17 |
| attribute 9 |  | 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 23 |
| Content-Encoding-v 22 |  | Content-Encoding-v 23 |
| 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 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 12 |  | entity-body 13 |
| entity-header 12 |  | entity-header 12 |
| extension-header 12 |  | extension-header 12 |
| filename-parm 34 |  | filename-parm 35 |
| language-range 21 |  | language-range 21 |
| language-tag 11 |  | language-tag 12 |
| media-range 16 |  | media-range 17 |
| media-type 9 |  | media-type 9 |
| MIME-Version 31 |  | MIME-Version 32 |
| MIME-Version-v 31 |  | MIME-Version-v 32 |
| parameter 9 |  | parameter 10 |
| primary-tag 11 |  |  |
| subtag 11 |  |  |
| subtype 9 |  | subtype 9 |
| type 9 |  | type 9 |
| value 9 |  | value 10 |
| gzip 8 |  | gzip (Coding Format) 9 |
| H |  | H |
| Headers |  | Headers |
| Accept 16 |  | Accept 17 |
| Accept-Charset 18 |  | Accept-Charset 19 |
| Accept-Encoding 19 |  | Accept-Encoding 20 |
| Accept-Language 20 |  | Accept-Language 21 |
| Alternate 35 |  | Alternate 36 |
| Content-Base 35 |  | Content-Base 36 |
| Content-Disposition 34 |  | Content-Disposition 35 |
| Content-Encoding 22 |  | Content-Encoding 23 |
| Content-Language 23 |  | Content-Language 23 |
| Content-Location 24 |  | 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 31 |  | MIME-Version 32 |
| Public 35 |  | Public 36 |
| URI 35 |  | URI 36 |
| I |  | I |
| identity 8 |  | identity (Coding Format) 9 |
| L |  | L |
| Link header 35 |  | Link header 36 |
| M |  | M |
| MIME-Version header 31 |  | MIME-Version header 32 |
| P |  | P |
| Public header 35 |  | Public header 36 |
|  |  | R |
|  |  | representation 5 |
| U |  | U |
| URI header 35 |  | 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. 98 change blocks.
| 266 lines changed or deleted |  | 354 lines changed or added |
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/