| draft-ietf-httpbis-p3-payload-13.txt |  | draft-ietf-httpbis-p3-payload-14.txt |
--- | --- | --- | --- | ---
| HTTPbis Working Group R. Fielding, Ed. |  | HTTPbis Working Group R. Fielding, Ed. |
| Internet-Draft Adobe |  | Internet-Draft Adobe |
| Obsoletes: 2616 (if approved) J. Gettys |  | Obsoletes: 2616 (if approved) J. Gettys |
| Intended status: Standards Track Alcatel-Lucent |  | Intended status: Standards Track Alcatel-Lucent |
| Expires: September 15, 2011 J. Mogul |  | Expires: October 20, 2011 J. Mogul |
| HP |  | HP |
| H. Frystyk |  | H. Frystyk |
| Microsoft |  | Microsoft |
| L. Masinter |  | L. Masinter |
| Adobe |  | Adobe |
| P. Leach |  | P. Leach |
| Microsoft |  | Microsoft |
| T. Berners-Lee |  | T. Berners-Lee |
| W3C/MIT |  | W3C/MIT |
| Y. Lafon, Ed. |  | Y. Lafon, Ed. |
| W3C |  | W3C |
| J. Reschke, Ed. |  | J. Reschke, Ed. |
| greenbytes |  | greenbytes |
| March 14, 2011 |  | April 18, 2011 |
| 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-13 |  | draft-ietf-httpbis-p3-payload-14 |
| Abstract |  | Abstract |
| The Hypertext Transfer Protocol (HTTP) is an application-level |  | The Hypertext Transfer Protocol (HTTP) is an application-level |
| protocol for distributed, collaborative, hypermedia information |  | protocol for distributed, collaborative, hypermedia information |
| systems. HTTP has been in use by the World Wide Web global |  | systems. HTTP has been in use by the World Wide Web global |
| information initiative since 1990. This document is Part 3 of the |  | information initiative since 1990. This document is Part 3 of the |
| seven-part specification that defines the protocol referred to as |  | seven-part specification that defines the protocol referred to as |
| "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 3 defines |  | "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 3 defines |
| HTTP message content, metadata, and content negotiation. |  | HTTP message content, metadata, and content negotiation. |
| Editorial Note (To be removed by RFC Editor) |  | Editorial Note (To be removed by RFC Editor) |
| Discussion of this draft should take place on the HTTPBIS working |  | Discussion of this draft should take place on the HTTPBIS working |
| group mailing list (ietf-http-wg@w3.org). The current issues list is |  | group mailing list (ietf-http-wg@w3.org), which is archived at |
| at <http://tools.ietf.org/wg/httpbis/trac/report/3> and related |  | <http://lists.w3.org/Archives/Public/ietf-http-wg/>. |
|  |  | The current issues list is at |
|  |  | <http://tools.ietf.org/wg/httpbis/trac/report/3> and related |
| documents (including fancy diffs) can be found at |  | documents (including fancy diffs) can be found at |
| <http://tools.ietf.org/wg/httpbis/>. |  | <http://tools.ietf.org/wg/httpbis/>. |
| The changes in this draft are summarized in Appendix E.14. |  | The changes in this draft are summarized in Appendix E.15. |
| Status of This Memo |  | Status of This Memo |
| This Internet-Draft is submitted in full conformance with the |  | This Internet-Draft is submitted in full conformance with the |
| provisions of BCP 78 and BCP 79. |  | provisions of BCP 78 and BCP 79. |
| Internet-Drafts are working documents of the Internet Engineering |  | Internet-Drafts are working documents of the Internet Engineering |
| Task Force (IETF). Note that other groups may also distribute |  | Task Force (IETF). Note that other groups may also distribute |
| working documents as Internet-Drafts. The list of current Internet- |  | working documents as Internet-Drafts. The list of current Internet- |
| Drafts is at http://datatracker.ietf.org/drafts/current/. |  | Drafts is at http://datatracker.ietf.org/drafts/current/. |
| Internet-Drafts are draft documents valid for a maximum of six months |  | Internet-Drafts are draft documents valid for a maximum of six months |
| and may be updated, replaced, or obsoleted by other documents at any |  | and may be updated, replaced, or obsoleted by other documents at any |
| skipping to change at page 2, line 15 |  | skipping to change at page 2, line 17 |
| Internet-Drafts are working documents of the Internet Engineering |  | Internet-Drafts are working documents of the Internet Engineering |
| Task Force (IETF). Note that other groups may also distribute |  | Task Force (IETF). Note that other groups may also distribute |
| working documents as Internet-Drafts. The list of current Internet- |  | working documents as Internet-Drafts. The list of current Internet- |
| Drafts is at http://datatracker.ietf.org/drafts/current/. |  | Drafts is at http://datatracker.ietf.org/drafts/current/. |
| Internet-Drafts are draft documents valid for a maximum of six months |  | Internet-Drafts are draft documents valid for a maximum of six months |
| and may be updated, replaced, or obsoleted by other documents at any |  | and may be updated, replaced, or obsoleted by other documents at any |
| time. It is inappropriate to use Internet-Drafts as reference |  | time. It is inappropriate to use Internet-Drafts as reference |
| material or to cite them other than as "work in progress." |  | material or to cite them other than as "work in progress." |
| This Internet-Draft will expire on September 15, 2011. |  | This Internet-Draft will expire on October 20, 2011. |
| Copyright Notice |  | Copyright Notice |
| Copyright (c) 2011 IETF Trust and the persons identified as the |  | Copyright (c) 2011 IETF Trust and the persons identified as the |
| document authors. All rights reserved. |  | document authors. All rights reserved. |
| This document is subject to BCP 78 and the IETF Trust's Legal |  | This document is subject to BCP 78 and the IETF Trust's Legal |
| Provisions Relating to IETF Documents |  | Provisions Relating to IETF Documents |
| (http://trustee.ietf.org/license-info) in effect on the date of |  | (http://trustee.ietf.org/license-info) in effect on the date of |
| publication of this document. Please review these documents |  | publication of this document. Please review these documents |
| skipping to change at page 3, line 4 |  | skipping to change at page 3, line 7 |
| Table of Contents |  | Table of Contents |
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 |  | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 |
| 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 |  | 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 |
| 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 |  | 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 |
| 1.3. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 |  | 1.3. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 |
| 1.3.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 6 |  | 1.3.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 6 |
| 1.3.2. ABNF Rules defined in other Parts of the |  | 1.3.2. ABNF Rules defined in other Parts of the |
| Specification . . . . . . . . . . . . . . . . . . . . 6 |  | Specification . . . . . . . . . . . . . . . . . . . . 6 |
| 2. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 6 |  | 2. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 6 |
| 2.1. Character Encodings (charset) . . . . . . . . . . . . . . 6 |  | 2.1. Character Encodings (charset) . . . . . . . . . . . . . . 6 |
| 2.1.1. Missing Charset . . . . . . . . . . . . . . . . . . . 7 |  |  |
| 2.2. Content Codings . . . . . . . . . . . . . . . . . . . . . 7 |  | 2.2. Content Codings . . . . . . . . . . . . . . . . . . . . . 7 |
| 2.2.1. Content Coding Registry . . . . . . . . . . . . . . . 8 |  | 2.2.1. Content Coding Registry . . . . . . . . . . . . . . . 8 |
| 2.3. Media Types . . . . . . . . . . . . . . . . . . . . . . . 8 |  | 2.3. Media Types . . . . . . . . . . . . . . . . . . . . . . . 8 |
| 2.3.1. Canonicalization and Text Defaults . . . . . . . . . . 9 |  | 2.3.1. Canonicalization and Text Defaults . . . . . . . . . . 9 |
| 2.3.2. Multipart Types . . . . . . . . . . . . . . . . . . . 10 |  | 2.3.2. Multipart Types . . . . . . . . . . . . . . . . . . . 9 |
| 2.4. Language Tags . . . . . . . . . . . . . . . . . . . . . . 10 |  | 2.4. Language Tags . . . . . . . . . . . . . . . . . . . . . . 10 |
| 3. Payload . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 |  | 3. Payload . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 |
| 3.1. Payload Header Fields . . . . . . . . . . . . . . . . . . 11 |  | 3.1. Payload Header Fields . . . . . . . . . . . . . . . . . . 11 |
| 3.2. Payload Body . . . . . . . . . . . . . . . . . . . . . . . 12 |  | 3.2. Payload Body . . . . . . . . . . . . . . . . . . . . . . . 11 |
| 4. Representation . . . . . . . . . . . . . . . . . . . . . . . . 12 |  | 4. Representation . . . . . . . . . . . . . . . . . . . . . . . . 11 |
| 4.1. Representation Header Fields . . . . . . . . . . . . . . . 12 |  | 4.1. Representation Header Fields . . . . . . . . . . . . . . . 12 |
| 4.2. Representation Data . . . . . . . . . . . . . . . . . . . 13 |  | 4.2. Representation Data . . . . . . . . . . . . . . . . . . . 12 |
| 5. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 14 |  | 5. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 13 |
| 5.1. Server-driven Negotiation . . . . . . . . . . . . . . . . 15 |  | 5.1. Server-driven Negotiation . . . . . . . . . . . . . . . . 14 |
| 5.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . . 16 |  | 5.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . . 15 |
| 6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 16 |  | 6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 16 |
| 6.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . . 16 |  | 6.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . . 16 |
| 6.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . . 19 |  | 6.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . . 18 |
| 6.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 19 |  | 6.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 19 |
| 6.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 21 |  | 6.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 20 |
| 6.5. Content-Encoding . . . . . . . . . . . . . . . . . . . . . 22 |  | 6.5. Content-Encoding . . . . . . . . . . . . . . . . . . . . . 21 |
| 6.6. Content-Language . . . . . . . . . . . . . . . . . . . . . 23 |  | 6.6. Content-Language . . . . . . . . . . . . . . . . . . . . . 22 |
| 6.7. Content-Location . . . . . . . . . . . . . . . . . . . . . 24 |  | 6.7. Content-Location . . . . . . . . . . . . . . . . . . . . . 23 |
| 6.8. Content-MD5 . . . . . . . . . . . . . . . . . . . . . . . 25 |  | 6.8. Content-Type . . . . . . . . . . . . . . . . . . . . . . . 24 |
| 6.9. Content-Type . . . . . . . . . . . . . . . . . . . . . . . 26 |  | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 |
| 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 |  | 7.1. Header Field Registration . . . . . . . . . . . . . . . . 24 |
| 7.1. Header Field Registration . . . . . . . . . . . . . . . . 27 |  | 7.2. Content Coding Registry . . . . . . . . . . . . . . . . . 25 |
| 7.2. Content Coding Registry . . . . . . . . . . . . . . . . . 27 |  | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 |
| 8. Security Considerations . . . . . . . . . . . . . . . . . . . 28 |  | 8.1. Privacy Issues Connected to Accept Header Fields . . . . . 26 |
| 8.1. Privacy Issues Connected to Accept Header Fields . . . . . 28 |  | 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 |
| 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 |  | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 |
| 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 |  | 10.1. Normative References . . . . . . . . . . . . . . . . . . . 26 |
| 10.1. Normative References . . . . . . . . . . . . . . . . . . . 29 |  | 10.2. Informative References . . . . . . . . . . . . . . . . . . 29 |
| 10.2. Informative References . . . . . . . . . . . . . . . . . . 31 |  | Appendix A. Differences between HTTP and MIME . . . . . . . . . . 31 |
| Appendix A. Differences between HTTP and MIME . . . . . . . . . . 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 . . . . . . . . . . . . . 34 |  | 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 |  | Appendix C. Changes from RFC 2616 . . . . . . . . . . . . . . . . 34 |
| Appendix C. Changes from RFC 2616 . . . . . . . . . . . . . . . . 35 |  | Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 34 |
| Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 35 |  |  |
| Appendix E. Change Log (to be removed by RFC Editor before |  | Appendix E. Change Log (to be removed by RFC Editor before |
| publication) . . . . . . . . . . . . . . . . . . . . 37 |  | publication) . . . . . . . . . . . . . . . . . . . . 36 |
| E.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 37 |  | E.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 36 |
| E.2. Since draft-ietf-httpbis-p3-payload-00 . . . . . . . . . . 37 |  | E.2. Since draft-ietf-httpbis-p3-payload-00 . . . . . . . . . . 36 |
| E.3. Since draft-ietf-httpbis-p3-payload-01 . . . . . . . . . . 38 |  | E.3. Since draft-ietf-httpbis-p3-payload-01 . . . . . . . . . . 37 |
| E.4. Since draft-ietf-httpbis-p3-payload-02 . . . . . . . . . . 38 |  | E.4. Since draft-ietf-httpbis-p3-payload-02 . . . . . . . . . . 37 |
| E.5. Since draft-ietf-httpbis-p3-payload-03 . . . . . . . . . . 38 |  | E.5. Since draft-ietf-httpbis-p3-payload-03 . . . . . . . . . . 37 |
| E.6. Since draft-ietf-httpbis-p3-payload-04 . . . . . . . . . . 39 |  | E.6. Since draft-ietf-httpbis-p3-payload-04 . . . . . . . . . . 38 |
| E.7. Since draft-ietf-httpbis-p3-payload-05 . . . . . . . . . . 39 |  | E.7. Since draft-ietf-httpbis-p3-payload-05 . . . . . . . . . . 38 |
| E.8. Since draft-ietf-httpbis-p3-payload-06 . . . . . . . . . . 39 |  | E.8. Since draft-ietf-httpbis-p3-payload-06 . . . . . . . . . . 38 |
| E.9. Since draft-ietf-httpbis-p3-payload-07 . . . . . . . . . . 40 |  | E.9. Since draft-ietf-httpbis-p3-payload-07 . . . . . . . . . . 39 |
| E.10. Since draft-ietf-httpbis-p3-payload-08 . . . . . . . . . . 40 |  | E.10. Since draft-ietf-httpbis-p3-payload-08 . . . . . . . . . . 39 |
| E.11. Since draft-ietf-httpbis-p3-payload-09 . . . . . . . . . . 41 |  | E.11. Since draft-ietf-httpbis-p3-payload-09 . . . . . . . . . . 39 |
| E.12. Since draft-ietf-httpbis-p3-payload-10 . . . . . . . . . . 41 |  | E.12. Since draft-ietf-httpbis-p3-payload-10 . . . . . . . . . . 40 |
| E.13. Since draft-ietf-httpbis-p3-payload-11 . . . . . . . . . . 42 |  | E.13. Since draft-ietf-httpbis-p3-payload-11 . . . . . . . . . . 41 |
| E.14. Since draft-ietf-httpbis-p3-payload-12 . . . . . . . . . . 42 |  | E.14. Since draft-ietf-httpbis-p3-payload-12 . . . . . . . . . . 41 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 |  | E.15. Since draft-ietf-httpbis-p3-payload-13 . . . . . . . . . . 41 |
|  |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 |
| 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 might influence content selection, and the various selection |  | that might influence content selection, and the various selection |
| algorithms that are collectively referred to as HTTP content |  | algorithms that are collectively referred to as HTTP content |
| negotiation. |  | negotiation. |
| skipping to change at page 7, line 14 |  | skipping to change at page 7, line 14 |
| HTTP uses charset in two contexts: within an Accept-Charset request |  | HTTP uses charset in two contexts: within an Accept-Charset request |
| header field (in which the charset value is an unquoted token) and as |  | header field (in which the charset value is an unquoted token) and as |
| the value of a parameter in a Content-Type header field (within a |  | the value of a parameter in a Content-Type header field (within a |
| request or response), in which case the parameter value of the |  | request or response), in which case the parameter value of the |
| charset parameter can be quoted. |  | charset parameter can be quoted. |
| Implementors need to be aware of IETF character set requirements |  | Implementors need to be aware of IETF character set requirements |
| [RFC3629] [RFC2277]. |  | [RFC3629] [RFC2277]. |
| 2.1.1. Missing Charset |  |  |
| Some HTTP/1.0 software has interpreted a Content-Type header field |  |  |
| without charset parameter incorrectly to mean "recipient should |  |  |
| guess". Senders wishing to defeat this behavior MAY include a |  |  |
| charset parameter even when the charset is ISO-8859-1 ([ISO-8859-1]) |  |  |
| and SHOULD do so when it is known that it will not confuse the |  |  |
| recipient. |  |  |
| Unfortunately, some older HTTP/1.0 clients did not deal properly with |  |  |
| an explicit charset parameter. HTTP/1.1 recipients MUST respect the |  |  |
| charset label provided by the sender; and those user agents that have |  |  |
| a provision to "guess" a charset MUST use the charset from the |  |  |
| content-type field if they support that charset, rather than the |  |  |
| recipient's preference, when initially displaying a document. See |  |  |
| Section 2.3.1. |  |  |
| 2.2. Content Codings |  | 2.2. Content Codings |
| Content coding values indicate an encoding transformation that has |  | Content coding values indicate an encoding transformation that has |
| been or can be applied to a representation. Content codings are |  | been or can be applied to a representation. Content codings are |
| primarily used to allow a representation to be compressed or |  | primarily used to allow a representation to be compressed or |
| otherwise usefully transformed without losing the identity of its |  | otherwise usefully transformed without losing the identity of its |
| underlying media type and without loss of information. Frequently, |  | underlying media type and without loss of information. Frequently, |
| the representation is stored in coded form, transmitted directly, and |  | the representation is stored in coded form, transmitted directly, and |
| only decoded by the recipient. |  | only decoded by the recipient. |
| skipping to change at page 8, line 49 |  | skipping to change at page 8, line 33 |
| Values to be added to this name space require a specification (see |  | Values to be added to this name space require a specification (see |
| "Specification Required" in Section 4.1 of [RFC5226]), and MUST |  | "Specification Required" in Section 4.1 of [RFC5226]), and MUST |
| conform to the purpose of content coding defined in this section. |  | conform to the purpose of content coding defined in this section. |
| The registry itself is maintained at |  | The registry itself is maintained at |
| <http://www.iana.org/assignments/http-parameters>. |  | <http://www.iana.org/assignments/http-parameters>. |
| 2.3. Media Types |  | 2.3. Media Types |
| HTTP uses Internet Media Types [RFC2046] in the Content-Type |  | HTTP uses Internet Media Types [RFC2046] in the Content-Type |
| (Section 6.9) and Accept (Section 6.1) header fields in order to |  | (Section 6.8) and Accept (Section 6.1) header fields in order to |
| provide open and extensible data typing and type negotiation. |  | provide open and extensible data typing and type negotiation. |
| media-type = type "/" subtype *( OWS ";" OWS parameter ) |  | media-type = type "/" subtype *( OWS ";" OWS parameter ) |
| type = token |  | type = token |
| subtype = token |  | subtype = token |
| The type/subtype MAY be followed by parameters in the form of |  | The type/subtype MAY be followed by parameters in the form of |
| attribute/value pairs. |  | attribute/value pairs. |
| parameter = attribute "=" value |  | parameter = attribute "=" value |
| skipping to change at page 10, line 12 |  | skipping to change at page 9, line 43 |
| multi-byte character encodings, HTTP allows the use of whatever octet |  | multi-byte character encodings, HTTP allows the use of whatever octet |
| sequences are defined by that character encoding to represent the |  | sequences are defined by that character encoding to represent the |
| equivalent of CR and LF for line breaks. This flexibility regarding |  | equivalent of CR and LF for line breaks. This flexibility regarding |
| line breaks applies only to text media in the payload body; a bare CR |  | line breaks applies only to text media in the payload body; a bare CR |
| or LF MUST NOT be substituted for CRLF within any of the HTTP control |  | or LF MUST NOT be substituted for CRLF within any of the HTTP control |
| structures (such as header fields and multipart boundaries). |  | structures (such as header fields and multipart boundaries). |
| If a representation is encoded with a content-coding, the underlying |  | If a representation is encoded with a content-coding, the underlying |
| data MUST be in a form defined above prior to being encoded. |  | data MUST be in a form defined above prior to being encoded. |
| The "charset" parameter is used with some media types to define the |  |  |
| character encoding (Section 2.1) of the data. When no explicit |  |  |
| charset parameter is provided by the sender, media subtypes of the |  |  |
| "text" type are defined to have a default charset value of |  |  |
| "ISO-8859-1" when received via HTTP. Data in character encodings |  |  |
| other than "ISO-8859-1" or its subsets MUST be labeled with an |  |  |
| appropriate charset value. See Section 2.1.1 for compatibility |  |  |
| problems. |  |  |
| 2.3.2. Multipart Types |  | 2.3.2. Multipart Types |
| MIME provides for a number of "multipart" types -- encapsulations of |  | MIME provides for a number of "multipart" types -- encapsulations of |
| one or more representations within a single message-body. All |  | one or more representations within a single message-body. All |
| multipart types share a common syntax, as defined in Section 5.1.1 of |  | multipart types share a common syntax, as defined in Section 5.1.1 of |
| [RFC2046], and MUST include a boundary parameter as part of the media |  | [RFC2046], and MUST include a boundary parameter as part of the media |
| type value. The message body is itself a protocol element and MUST |  | type value. The message body is itself a protocol element and MUST |
| therefore use only CRLF to represent line breaks between body-parts. |  | therefore use only CRLF to represent line breaks between body-parts. |
| In general, HTTP treats a multipart message-body no differently than |  | In general, HTTP treats a multipart message-body no differently than |
| skipping to change at page 11, line 48 |  | skipping to change at page 11, line 22 |
| HTTP header fields that specifically define the payload, rather than |  | HTTP header fields that specifically define the payload, rather than |
| the associated representation, are referred to as "payload header |  | the associated representation, are referred to as "payload header |
| fields". The following payload header fields are defined by |  | fields". The following payload header fields are defined by |
| HTTP/1.1: |  | HTTP/1.1: |
| +-------------------+------------------------+ |  | +-------------------+------------------------+ |
| | Header Field Name | Defined in... | |  | | Header Field Name | Defined in... | |
| +-------------------+------------------------+ |  | +-------------------+------------------------+ |
| | Content-Length | Section 9.2 of [Part1] | |  | | Content-Length | Section 9.2 of [Part1] | |
| | Content-MD5 | Section 6.8 | |  |  |
| | Content-Range | Section 5.2 of [Part5] | |  | | Content-Range | Section 5.2 of [Part5] | |
| +-------------------+------------------------+ |  | +-------------------+------------------------+ |
| 3.2. Payload Body |  | 3.2. Payload Body |
| A payload body is only present in a message when a message-body is |  | A payload body is only present in a message when a message-body is |
| present, as described in Section 3.3 of [Part1]. The payload body is |  | present, as described in Section 3.3 of [Part1]. The payload 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. |
| skipping to change at page 13, line 11 |  | skipping to change at page 12, line 23 |
| request URI. |  | request URI. |
| The following header fields are defined as representation metadata: |  | The following header fields are defined as representation metadata: |
| +-------------------+------------------------+ |  | +-------------------+------------------------+ |
| | Header Field Name | Defined in... | |  | | Header Field Name | Defined in... | |
| +-------------------+------------------------+ |  | +-------------------+------------------------+ |
| | Content-Encoding | Section 6.5 | |  | | Content-Encoding | Section 6.5 | |
| | Content-Language | Section 6.6 | |  | | Content-Language | Section 6.6 | |
| | Content-Location | Section 6.7 | |  | | Content-Location | Section 6.7 | |
| | Content-Type | Section 6.9 | |  | | Content-Type | Section 6.8 | |
| | Expires | Section 3.3 of [Part6] | |  | | Expires | Section 3.3 of [Part6] | |
| | Last-Modified | Section 6.6 of [Part4] | |  | | Last-Modified | Section 2.1 of [Part4] | |
| +-------------------+------------------------+ |  | +-------------------+------------------------+ |
| 4.2. Representation Data |  | 4.2. Representation Data |
| The representation body associated with an HTTP message is either |  | The representation body associated with an HTTP message is either |
| provided as the payload body of the message or referred to by the |  | provided as the payload body of the message or referred to by the |
| message semantics and the effective request URI. The representation |  | message semantics and the effective request URI. The representation |
| data is in a format and encoding defined by the representation |  | data is in a format and encoding defined by the representation |
| metadata header fields. |  | metadata header fields. |
| skipping to change at page 17, line 7 |  | skipping to change at page 16, line 20 |
| fields related to the payload of messages. |  | fields related to the payload of messages. |
| 6.1. Accept |  | 6.1. Accept |
| The "Accept" header field can be used by user agents to specify |  | The "Accept" header field can be used by user agents to specify |
| response media types that are acceptable. Accept header fields can |  | response media types that are acceptable. Accept header fields 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 = #( media-range [ accept-params ] ) |
| Accept-v = #( media-range [ accept-params ] ) |  |  |
| media-range = ( "*/*" |  | media-range = ( "*/*" |
| / ( type "/" "*" ) |  | / ( type "/" "*" ) |
| / ( type "/" subtype ) |  | / ( type "/" subtype ) |
| ) *( OWS ";" OWS parameter ) |  | ) *( OWS ";" OWS parameter ) |
| accept-params = OWS ";" OWS "q=" qvalue *( accept-ext ) |  | accept-params = OWS ";" OWS "q=" qvalue *( accept-ext ) |
| accept-ext = OWS ";" OWS token [ "=" word ] |  | accept-ext = OWS ";" OWS token [ "=" word ] |
| The asterisk "*" character is used to group media types into ranges, |  | The asterisk "*" character is used to group media types into ranges, |
| with "*/*" indicating all media types and "type/*" indicating all |  | with "*/*" indicating all media types and "type/*" indicating all |
| skipping to change at page 18, line 19 |  | skipping to change at page 17, line 29 |
| Verbally, this would be interpreted as "text/html and text/x-c are |  | Verbally, this would be interpreted as "text/html and text/x-c are |
| the preferred media types, but if they do not exist, then send the |  | the preferred media types, but if they do not exist, then send the |
| text/x-dvi representation, and if that does not exist, send the text/ |  | text/x-dvi representation, and if that does not exist, send the text/ |
| plain representation". |  | plain representation". |
| Media ranges can be overridden by more specific media ranges or |  | Media ranges can be overridden by more specific media ranges or |
| specific media types. If more than one media range applies to a |  | specific media types. If more than one media range applies to a |
| given type, the most specific reference has precedence. For example, |  | given type, the most specific reference has precedence. For example, |
| Accept: text/*, text/html, text/html;level=1, */* |  | Accept: text/*, text/plain, text/plain;format=flowed, */* |
| have the following precedence: |  | have the following precedence: |
| 1. text/html;level=1 |  | 1. text/plain;format=flowed |
| 2. text/html |  | 2. text/plain |
| 3. text/* |  | 3. text/* |
| 4. */* |  | 4. */* |
| The media type quality factor associated with a given type is |  | The media type quality factor associated with a given type is |
| determined by finding the media range with the highest precedence |  | determined by finding the media range with the highest precedence |
| which matches that type. For example, |  | which matches that type. For example, |
| Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, |  | Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, |
| skipping to change at page 19, line 16 |  | skipping to change at page 18, line 30 |
| 6.2. Accept-Charset |  | 6.2. Accept-Charset |
| The "Accept-Charset" header field can be used by user agents to |  | The "Accept-Charset" header field can be used by user agents to |
| indicate what character encodings are acceptable in a response |  | indicate what character encodings are acceptable in a response |
| payload. This field allows clients capable of understanding more |  | payload. This field allows clients capable of understanding more |
| comprehensive or special-purpose character encodings to signal that |  | comprehensive or special-purpose character encodings to signal that |
| capability to a server which is capable of representing documents in |  | capability to a server which is capable of representing documents in |
| those character encodings. |  | those character encodings. |
| Accept-Charset = "Accept-Charset" ":" OWS |  | Accept-Charset = 1#( ( charset / "*" ) |
| Accept-Charset-v |  |  |
| Accept-Charset-v = 1#( ( charset / "*" ) |  |  |
| [ OWS ";" OWS "q=" qvalue ] ) |  | [ OWS ";" OWS "q=" qvalue ] ) |
| Character encoding values (a.k.a., charsets) are described in |  | Character encoding values (a.k.a., charsets) are described in |
| Section 2.1. Each charset MAY be given an associated quality value |  | Section 2.1. Each charset MAY be given an associated quality value |
| which represents the user's preference for that charset. The default |  | which represents the user's preference for that charset. The default |
| value is q=1. An example is |  | value is q=1. An example is |
| Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 |  | Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 |
| The special value "*", if present in the Accept-Charset field, |  | The special value "*", if present in the Accept-Charset field, |
| matches every character encoding (including ISO-8859-1) which is not |  | matches every character encoding which is not mentioned elsewhere in |
| mentioned elsewhere in the Accept-Charset field. If no "*" is |  | the Accept-Charset field. If no "*" is present in an Accept-Charset |
| present in an Accept-Charset field, then all character encodings not |  | field, then all character encodings not explicitly mentioned get a |
| explicitly mentioned get a quality value of 0, except for ISO-8859-1, |  | quality value of 0. |
| which gets a quality value of 1 if not explicitly mentioned. |  |  |
| If no Accept-Charset header field is present, the default is that any |  | If no Accept-Charset header field is present, the default is that any |
| character encoding is acceptable. If an Accept-Charset header field |  | character encoding is acceptable. If an Accept-Charset header field |
| is present, and if the server cannot send a response which is |  | is present, and if the server cannot send a response which is |
| acceptable according to the Accept-Charset header field, then the |  | acceptable according to the Accept-Charset header field, then the |
| server SHOULD send an error response with the 406 (Not Acceptable) |  | server SHOULD send an error response with the 406 (Not Acceptable) |
| status code, though the sending of an unacceptable response is also |  | status code, though the sending of an unacceptable response is also |
| allowed. |  | allowed. |
| 6.3. Accept-Encoding |  | 6.3. Accept-Encoding |
| The "Accept-Encoding" header field can be used by user agents to |  | The "Accept-Encoding" header field can be used by user agents to |
| indicate what response content-codings (Section 2.2) are acceptable |  | indicate what response content-codings (Section 2.2) are acceptable |
| in the response. |  | in the response. |
| Accept-Encoding = "Accept-Encoding" ":" OWS |  | Accept-Encoding = #( codings [ OWS ";" OWS "q=" qvalue ] ) |
| Accept-Encoding-v |  | codings = ( content-coding / "*" ) |
| Accept-Encoding-v = |  |  |
| #( codings [ OWS ";" OWS "q=" qvalue ] ) |  |  |
| 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. |
| Examples of its use are: |  | Examples of its use are: |
| Accept-Encoding: compress, gzip |  | Accept-Encoding: compress, gzip |
| Accept-Encoding: |  | Accept-Encoding: |
| Accept-Encoding: * |  | Accept-Encoding: * |
| skipping to change at page 21, line 26 |  | skipping to change at page 20, line 30 |
| 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. |
| 6.4. Accept-Language |  | 6.4. Accept-Language |
| The "Accept-Language" header field can be used by user agents to |  | The "Accept-Language" header field can be used by user agents to |
| indicate the set of natural languages that are preferred in the |  | indicate the set of natural languages that are preferred in the |
| response. Language tags are defined in Section 2.4. |  | response. Language tags are defined in Section 2.4. |
| Accept-Language = "Accept-Language" ":" OWS |  | Accept-Language = |
| Accept-Language-v |  |  |
| Accept-Language-v = |  |  |
| 1#( language-range [ OWS ";" OWS "q=" qvalue ] ) |  | 1#( language-range [ OWS ";" OWS "q=" qvalue ] ) |
| language-range = |  | language-range = |
| <language-range, defined in [RFC4647], Section 2.1> |  | <language-range, defined in [RFC4647], Section 2.1> |
| Each language-range can be given an associated quality value which |  | Each language-range can be given an associated quality value which |
| represents an estimate of the user's preference for the languages |  | represents an estimate of the user's preference for the languages |
| specified by that range. The quality value defaults to "q=1". For |  | specified by that range. The quality value defaults to "q=1". For |
| example, |  | example, |
| Accept-Language: da, en-gb;q=0.8, en;q=0.7 |  | Accept-Language: da, en-gb;q=0.8, en;q=0.7 |
| would mean: "I prefer Danish, but will accept British English and |  | would mean: "I prefer Danish, but will accept British English and |
| skipping to change at page 22, line 32 |  | skipping to change at page 21, line 34 |
| 6.5. Content-Encoding |  | 6.5. Content-Encoding |
| The "Content-Encoding" header field indicates what content-codings |  | The "Content-Encoding" header field indicates what content-codings |
| have been applied to the representation, and thus what decoding |  | have been applied to the representation, and thus what decoding |
| mechanisms must be applied in order to obtain the media-type |  | mechanisms must be applied in order to obtain the media-type |
| referenced by the Content-Type header field. Content-Encoding is |  | referenced by the Content-Type header field. Content-Encoding is |
| primarily used to allow a representation to be compressed without |  | primarily used to allow a representation to be compressed without |
| losing the identity of its underlying media type. |  | losing the identity of its underlying media type. |
| Content-Encoding = "Content-Encoding" ":" OWS Content-Encoding-v |  | Content-Encoding = 1#content-coding |
| Content-Encoding-v = 1#content-coding |  |  |
| Content codings are defined in Section 2.2. An example of its use is |  | Content codings are defined in Section 2.2. An example of its use is |
| Content-Encoding: gzip |  | Content-Encoding: gzip |
| The content-coding is a characteristic of the representation. |  | The content-coding is a characteristic of the representation. |
| Typically, the representation body is stored with this encoding and |  | Typically, the representation body is stored with this encoding and |
| is only decoded before rendering or analogous usage. However, a |  | is only decoded before rendering or analogous usage. However, a |
| transforming proxy MAY modify the content-coding if the new coding is |  | transforming proxy MAY modify the content-coding if the new coding is |
| known to be acceptable to the recipient, unless the "no-transform" |  | known to be acceptable to the recipient, unless the "no-transform" |
| skipping to change at page 23, line 18 |  | skipping to change at page 22, line 18 |
| applied. Additional information about the encoding parameters MAY be |  | applied. Additional information about the encoding parameters MAY be |
| provided by other header fields not defined by this specification. |  | provided by other header fields not defined by this specification. |
| 6.6. Content-Language |  | 6.6. Content-Language |
| The "Content-Language" header field describes the natural language(s) |  | The "Content-Language" header field describes the natural language(s) |
| of the intended audience for the representation. Note that this |  | of the intended audience for the representation. Note that this |
| might not be equivalent to all the languages used within the |  | might not be equivalent to all the languages used within the |
| representation. |  | representation. |
| Content-Language = "Content-Language" ":" OWS Content-Language-v |  | Content-Language = 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 |
| representations according to the user's own preferred language. |  | representations according to the user's own preferred language. |
| Thus, if the body content is intended only for a Danish-literate |  | Thus, if the body content is intended only for a Danish-literate |
| audience, the appropriate field is |  | audience, the appropriate field is |
| Content-Language: da |  | Content-Language: da |
| If no Content-Language is specified, the default is that the content |  | If no Content-Language is specified, the default is that the content |
| skipping to change at page 24, line 13 |  | skipping to change at page 23, line 13 |
| limited to textual documents. |  | limited to textual documents. |
| 6.7. Content-Location |  | 6.7. Content-Location |
| The "Content-Location" header field supplies a URI that can be used |  | The "Content-Location" header field supplies a URI that can be used |
| as a specific identifier for the representation in this message. In |  | as a specific identifier for the representation in this message. In |
| other words, if one were to perform a GET on this URI at the time of |  | other words, if one were to perform a GET on this URI at the time of |
| this message's generation, then a 200 response would contain the same |  | this message's generation, then a 200 response would contain the same |
| representation that is enclosed as payload in this message. |  | representation that is enclosed as payload in this message. |
| Content-Location = "Content-Location" ":" OWS |  | Content-Location = absolute-URI / partial-URI |
| Content-Location-v |  |  |
| Content-Location-v = |  |  |
| absolute-URI / partial-URI |  |  |
| The Content-Location value is not a replacement for the effective |  | The Content-Location value is not a replacement for the effective |
| Request URI (Section 4.3 of [Part1]). It is representation metadata. |  | Request URI (Section 4.3 of [Part1]). It is representation metadata. |
| It has the same syntax and semantics as the header field of the same |  | It has the same syntax and semantics as the header field of the same |
| name defined for MIME body parts in Section 4 of [RFC2557]. However, |  | name defined for MIME body parts in Section 4 of [RFC2557]. However, |
| its appearance in an HTTP message has some special implications for |  | its appearance in an HTTP message has some special implications for |
| HTTP recipients. |  | HTTP recipients. |
| If Content-Location is included in a response message and its value |  | If Content-Location is included in a response message and its value |
| is the same as the effective request URI, then the response payload |  | is the same as the effective request URI, then the response payload |
| skipping to change at page 25, line 33 |  | skipping to change at page 24, line 30 |
| might be saved for use in other contexts, such as within source links |  | might be saved for use in other contexts, such as within source links |
| or other metadata. |  | or other metadata. |
| A cache cannot assume that a representation with a Content-Location |  | A cache cannot assume that a representation with a Content-Location |
| different from the URI used to retrieve it can be used to respond to |  | different from the URI used to retrieve it can be used to respond to |
| later requests on that Content-Location URI. |  | later requests on that Content-Location URI. |
| If the Content-Location value is a partial URI, the partial URI is |  | If the Content-Location value is a partial URI, the partial URI is |
| interpreted relative to the effective request URI. |  | interpreted relative to the effective request URI. |
| 6.8. Content-MD5 |  | 6.8. Content-Type |
| The "Content-MD5" header field, as defined in [RFC1864], is an MD5 |  |  |
| digest of the payload body that provides an end-to-end message |  |  |
| integrity check (MIC) of the payload body (the message-body after any |  |  |
| transfer-coding is decoded). Note that a MIC is good for detecting |  |  |
| accidental modification of the payload body in transit, but is not |  |  |
| proof against malicious attacks. |  |  |
| Content-MD5 = "Content-MD5" ":" OWS Content-MD5-v |  |  |
| Content-MD5-v = <base64 of 128 bit MD5 digest as per [RFC1864]> |  |  |
| The Content-MD5 header field MAY be generated by an origin server or |  |  |
| client to function as an integrity check of the payload body. Only |  |  |
| origin servers or user agents MAY generate the Content-MD5 header |  |  |
| field; proxies MUST NOT generate it, as this would defeat its value |  |  |
| as an end-to-end integrity check. Any recipient MAY check that the |  |  |
| digest value in this header field matches a corresponding digest |  |  |
| calculated on payload body as received. |  |  |
| The MD5 digest is computed based on the content of the payload body, |  |  |
| including any content-coding, but not including any transfer-coding |  |  |
| applied to the message-body because such transfer-codings might be |  |  |
| applied or removed anywhere along the request/response chain. If the |  |  |
| message is received with a transfer-coding, that encoding MUST be |  |  |
| decoded prior to checking the Content-MD5 value against the received |  |  |
| payload. |  |  |
| HTTP extends RFC 1864 to permit the digest to be computed for MIME |  |  |
| composite media-types (e.g., multipart/* and message/rfc822), but |  |  |
| this does not change how the digest is computed as defined in the |  |  |
| preceding paragraph. |  |  |
| There are several consequences of this. The payload for composite |  |  |
| types MAY contain many body-parts, each with its own MIME and HTTP |  |  |
| header fields (including Content-MD5, Content-Transfer-Encoding, and |  |  |
| Content-Encoding header fields). If a body-part has a Content- |  |  |
| Transfer-Encoding or Content-Encoding header field, it is assumed |  |  |
| that the content of the body-part has had the encoding applied, and |  |  |
| the body-part is included in the Content-MD5 digest as is -- i.e., |  |  |
| after the application. The Transfer-Encoding header field is not |  |  |
| allowed within body-parts. |  |  |
| Conversion of all line breaks to CRLF MUST NOT be done before |  |  |
| computing or checking the digest: the line break convention used in |  |  |
| the text actually transmitted MUST be left unaltered when computing |  |  |
| the digest. |  |  |
| Note: While the definition of Content-MD5 is exactly the same for |  |  |
| HTTP as in RFC 1864 for MIME entity-bodies, there are several ways |  |  |
| in which the application of Content-MD5 to HTTP entity-bodies |  |  |
| differs from its application to MIME entity-bodies. One is that |  |  |
| HTTP, unlike MIME, does not use Content-Transfer-Encoding, and |  |  |
| does use Transfer-Encoding and Content-Encoding. Another is that |  |  |
| HTTP more frequently uses binary content types than MIME, so it is |  |  |
| worth noting that, in such cases, the byte order used to compute |  |  |
| the digest is the transmission byte order defined for the type. |  |  |
| Lastly, HTTP allows transmission of text types with any of several |  |  |
| line break conventions and not just the canonical form using CRLF. |  |  |
| 6.9. Content-Type |  |  |
| The "Content-Type" header field indicates the media type of the |  | The "Content-Type" header field indicates the media type of the |
| representation. In the case of responses to the HEAD method, the |  | representation. In the case of responses to the HEAD method, the |
| media type is that which would have been sent had the request been a |  | media type is that which would have been sent had the request been a |
| GET. |  | GET. |
| Content-Type = "Content-Type" ":" OWS Content-Type-v |  | Content-Type = 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 Content-Type is provided in Section 4.2. |  | Further discussion of Content-Type is provided in Section 4.2. |
| 7. IANA Considerations |  | 7. IANA Considerations |
| 7.1. Header Field Registration |  | 7.1. Header Field Registration |
| skipping to change at page 27, line 30 |  | skipping to change at page 25, line 15 |
| +-------------------+----------+----------+--------------+ |  | +-------------------+----------+----------+--------------+ |
| | Header Field Name | Protocol | Status | Reference | |  | | Header Field Name | Protocol | Status | Reference | |
| +-------------------+----------+----------+--------------+ |  | +-------------------+----------+----------+--------------+ |
| | Accept | http | standard | Section 6.1 | |  | | Accept | http | standard | Section 6.1 | |
| | Accept-Charset | http | standard | Section 6.2 | |  | | Accept-Charset | http | standard | Section 6.2 | |
| | Accept-Encoding | http | standard | Section 6.3 | |  | | Accept-Encoding | http | standard | Section 6.3 | |
| | Accept-Language | http | standard | Section 6.4 | |  | | Accept-Language | http | standard | Section 6.4 | |
| | Content-Encoding | http | standard | Section 6.5 | |  | | Content-Encoding | http | standard | Section 6.5 | |
| | Content-Language | http | standard | Section 6.6 | |  | | Content-Language | http | standard | Section 6.6 | |
| | Content-Location | http | standard | Section 6.7 | |  | | Content-Location | http | standard | Section 6.7 | |
| | Content-MD5 | http | standard | Section 6.8 | |  | | Content-Type | http | standard | Section 6.8 | |
| | Content-Type | http | standard | Section 6.9 | |  |  |
| | MIME-Version | http | standard | Appendix A.1 | |  | | MIME-Version | http | standard | Appendix A.1 | |
| +-------------------+----------+----------+--------------+ |  | +-------------------+----------+----------+--------------+ |
| The change controller is: "IETF (iesg@ietf.org) - Internet |  | The change controller is: "IETF (iesg@ietf.org) - Internet |
| Engineering Task Force". |  | Engineering Task Force". |
| 7.2. Content Coding Registry |  | 7.2. Content Coding Registry |
| The registration procedure for HTTP Content Codings is now defined by |  | The registration procedure for HTTP Content Codings is now defined by |
| Section 2.2.1 of this document. |  | Section 2.2.1 of this document. |
| skipping to change at page 29, line 20 |  | skipping to change at page 26, line 46 |
| requests. General purpose user agents which provide a high degree of |  | requests. General purpose user agents which provide a high degree of |
| header configurability SHOULD warn users about the loss of privacy |  | header configurability SHOULD warn users about the loss of privacy |
| which can be involved. |  | which can be involved. |
| 9. Acknowledgments |  | 9. Acknowledgments |
| 10. References |  | 10. References |
| 10.1. Normative References |  | 10.1. Normative References |
| [ISO-8859-1] International Organization for Standardization, |  | [Part1] Fielding, R., Ed., Gettys, J., |
| "Information technology -- 8-bit single-byte coded |  | Mogul, J., Frystyk, H., Masinter, |
| graphic character sets -- Part 1: Latin alphabet No. |  | L., Leach, P., Berners-Lee, T., |
| 1", ISO/IEC 8859-1:1998, 1998. |  | Lafon, Y., Ed., and J. Reschke, |
|  |  | Ed., "HTTP/1.1, part 1: URIs, |
|  |  | Connections, and Message Parsing", |
|  |  | draft-ietf-httpbis-p1-messaging-14 |
|  |  | (work in progress), April 2011. |
| [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part2] Fielding, R., Ed., Gettys, J., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., |  | Mogul, J., Frystyk, H., Masinter, |
| Ed., and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, |  | L., Leach, P., Berners-Lee, T., |
| Connections, and Message Parsing", |  | Lafon, Y., Ed., and J. Reschke, |
| draft-ietf-httpbis-p1-messaging-13 (work in progress), |  | Ed., "HTTP/1.1, part 2: Message |
| March 2011. |  | Semantics", |
|  |  | draft-ietf-httpbis-p2-semantics-14 |
|  |  | (work in progress), April 2011. |
| [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part4] Fielding, R., Ed., Gettys, J., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., |  | Mogul, J., Frystyk, H., Masinter, |
| Ed., and J. Reschke, Ed., "HTTP/1.1, part 2: Message |  | L., Leach, P., Berners-Lee, T., |
| Semantics", draft-ietf-httpbis-p2-semantics-13 (work in |  | Lafon, Y., Ed., and J. Reschke, |
| progress), March 2011. |  | Ed., "HTTP/1.1, part 4: |
|  |  | Conditional Requests", draft-ietf- |
|  |  | httpbis-p4-conditional-14 (work in |
|  |  | progress), April 2011. |
| [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part5] Fielding, R., Ed., Gettys, J., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., |  | Mogul, J., Frystyk, H., Masinter, |
| Ed., and J. Reschke, Ed., "HTTP/1.1, part 4: |  | L., Leach, P., Berners-Lee, T., |
| Conditional Requests", |  | Lafon, Y., Ed., and J. Reschke, |
| draft-ietf-httpbis-p4-conditional-13 (work in |  | Ed., "HTTP/1.1, part 5: Range |
| progress), March 2011. |  | Requests and Partial Responses", |
|  |  | draft-ietf-httpbis-p5-range-14 |
|  |  | (work in progress), April 2011. |
| [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part6] Fielding, R., Ed., Gettys, J., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., |  | Mogul, J., Frystyk, H., Masinter, |
| Ed., and J. Reschke, Ed., "HTTP/1.1, part 5: Range |  | L., Leach, P., Berners-Lee, T., |
| Requests and Partial Responses", |  | Lafon, Y., Ed., Nottingham, M., |
| draft-ietf-httpbis-p5-range-13 (work in progress), |  | Ed., and J. Reschke, Ed., |
| March 2011. |  | "HTTP/1.1, part 6: Caching", |
|  |  | draft-ietf-httpbis-p6-cache-14 |
|  |  | (work in progress), April 2011. |
| [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., |  | Compressed Data Format |
| Ed., Nottingham, M., Ed., and J. Reschke, Ed., |  | Specification version 3.3", |
| "HTTP/1.1, part 6: Caching", |  | RFC 1950, May 1996. |
| draft-ietf-httpbis-p6-cache-13 (work in progress), |  |  |
| March 2011. |  |  |
| [RFC1864] Myers, J. and M. Rose, "The Content-MD5 Header Field", |  | RFC 1950 is an Informational RFC, |
| RFC 1864, October 1995. |  | thus it might 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]. |
| [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data |  | [RFC1951] Deutsch, P., "DEFLATE Compressed |
| Format Specification version 3.3", RFC 1950, May 1996. |  | Data Format Specification version |
|  |  | 1.3", RFC 1951, May 1996. |
| RFC 1950 is an Informational RFC, thus it might be less |  | RFC 1951 is an Informational RFC, |
| stable than this specification. On the other hand, |  | thus it might be less stable than |
| this downward reference was present since the |  | this specification. On the other |
| publication of RFC 2068 in 1997 ([RFC2068]), therefore |  | hand, this downward reference was |
| it is unlikely to cause problems in practice. See also |  | present since the publication of |
| [BCP97]. |  | RFC 2068 in 1997 ([RFC2068]), |
|  |  | therefore it is unlikely to cause |
|  |  | problems in practice. See also |
|  |  | [BCP97]. |
| [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format |  | [RFC1952] Deutsch, P., Gailly, J-L., Adler, |
| Specification version 1.3", RFC 1951, May 1996. |  | M., Deutsch, L., and G. Randers- |
|  |  | Pehrson, "GZIP file format |
|  |  | specification version 4.3", |
|  |  | RFC 1952, May 1996. |
| RFC 1951 is an Informational RFC, thus it might be less |  | RFC 1952 is an Informational RFC, |
| stable than this specification. On the other hand, |  | thus it might be less stable than |
| this downward reference was present since the |  | this specification. On the other |
| publication of RFC 2068 in 1997 ([RFC2068]), therefore |  | hand, this downward reference was |
| it is unlikely to cause problems in practice. See also |  | present since the publication of |
| [BCP97]. |  | 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 |  | [RFC2045] Freed, N. and N. Borenstein, |
| G. Randers-Pehrson, "GZIP file format specification |  | "Multipurpose Internet Mail |
| version 4.3", RFC 1952, May 1996. |  | Extensions (MIME) Part One: Format |
|  |  | of Internet Message Bodies", |
|  |  | RFC 2045, November 1996. |
| RFC 1952 is an Informational RFC, thus it might be less |  | [RFC2046] Freed, N. and N. Borenstein, |
| stable than this specification. On the other hand, |  | "Multipurpose Internet Mail |
| this downward reference was present since the |  | Extensions (MIME) Part Two: Media |
| publication of RFC 2068 in 1997 ([RFC2068]), therefore |  | Types", RFC 2046, November 1996. |
| it is unlikely to cause problems in practice. See also |  |  |
| [BCP97]. |  |  |
| [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet |  | [RFC2119] Bradner, S., "Key words for use in |
| Mail Extensions (MIME) Part One: Format of Internet |  | RFCs to Indicate Requirement |
| Message Bodies", RFC 2045, November 1996. |  | Levels", BCP 14, RFC 2119, |
|  |  | March 1997. |
| [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet |  | [RFC4647] Phillips, A., Ed. and M. Davis, |
| Mail Extensions (MIME) Part Two: Media Types", |  | Ed., "Matching of Language Tags", |
| RFC 2046, November 1996. |  | BCP 47, RFC 4647, September 2006. |
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |  | [RFC5234] Crocker, D., Ed. and P. Overell, |
| Requirement Levels", BCP 14, RFC 2119, March 1997. |  | "Augmented BNF for Syntax |
|  |  | Specifications: ABNF", STD 68, |
|  |  | RFC 5234, January 2008. |
| [RFC4647] Phillips, A., Ed. and M. Davis, Ed., "Matching of |  | [RFC5646] Phillips, A., Ed. and M. Davis, |
| Language Tags", BCP 47, RFC 4647, September 2006. |  | Ed., "Tags for Identifying |
|  |  | Languages", BCP 47, RFC 5646, |
|  |  | September 2009. |
| [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for |  | 10.2. Informative References |
| Syntax Specifications: ABNF", STD 68, RFC 5234, |  |  |
| January 2008. |  |  |
| [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for |  | [BCP97] Klensin, J. and S. Hartman, |
| Identifying Languages", BCP 47, RFC 5646, |  | "Handling Normative References to |
| September 2009. |  | Standards-Track Documents", |
|  |  | BCP 97, RFC 4897, June 2007. |
| 10.2. Informative References |  | [RFC1945] Berners-Lee, T., Fielding, R., and |
|  |  | H. Nielsen, "Hypertext Transfer |
|  |  | Protocol -- HTTP/1.0", RFC 1945, |
|  |  | May 1996. |
| [BCP97] Klensin, J. and S. Hartman, "Handling Normative |  | [RFC2049] Freed, N. and N. Borenstein, |
| References to Standards-Track Documents", BCP 97, |  | "Multipurpose Internet Mail |
| RFC 4897, June 2007. |  | Extensions (MIME) Part Five: |
|  |  | Conformance Criteria and |
|  |  | Examples", RFC 2049, |
|  |  | November 1996. |
| [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, |  | [RFC2068] Fielding, R., Gettys, J., Mogul, |
| "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, |  | J., Nielsen, H., and T. Berners- |
| May 1996. |  | Lee, "Hypertext Transfer Protocol |
|  |  | -- HTTP/1.1", RFC 2068, |
|  |  | January 1997. |
| [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet |  | [RFC2076] Palme, J., "Common Internet |
| Mail Extensions (MIME) Part Five: Conformance Criteria |  | Message Headers", RFC 2076, |
| and Examples", RFC 2049, November 1996. |  | February 1997. |
| [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and |  | [RFC2277] Alvestrand, H., "IETF Policy on |
| T. Berners-Lee, "Hypertext Transfer Protocol -- |  | Character Sets and Languages", |
| HTTP/1.1", RFC 2068, January 1997. |  | BCP 18, RFC 2277, January 1998. |
| [RFC2076] Palme, J., "Common Internet Message Headers", RFC 2076, |  | [RFC2295] Holtman, K. and A. Mutz, |
| February 1997. |  | "Transparent Content Negotiation |
|  |  | in HTTP", RFC 2295, March 1998. |
| [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and |  | [RFC2388] Masinter, L., "Returning Values |
| Languages", BCP 18, RFC 2277, January 1998. |  | from Forms: multipart/form-data", |
|  |  | RFC 2388, August 1998. |
| [RFC2295] Holtman, K. and A. Mutz, "Transparent Content |  | [RFC2557] Palme, F., Hopmann, A., Shelness, |
| Negotiation in HTTP", RFC 2295, March 1998. |  | N., and E. Stefferud, "MIME |
|  |  | Encapsulation of Aggregate |
|  |  | Documents, such as HTML (MHTML)", |
|  |  | RFC 2557, March 1999. |
| [RFC2388] Masinter, L., "Returning Values from Forms: multipart/ |  | [RFC2616] Fielding, R., Gettys, J., Mogul, |
| form-data", RFC 2388, August 1998. |  | J., Frystyk, H., Masinter, L., |
|  |  | Leach, P., and T. Berners-Lee, |
|  |  | "Hypertext Transfer Protocol -- |
|  |  | HTTP/1.1", RFC 2616, June 1999. |
| [RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud, |  | [RFC3629] Yergeau, F., "UTF-8, a |
| "MIME Encapsulation of Aggregate Documents, such as |  | transformation format of ISO |
| HTML (MHTML)", RFC 2557, March 1999. |  | 10646", STD 63, RFC 3629, |
|  |  | November 2003. |
| [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., |  | [RFC3864] Klyne, G., Nottingham, M., and J. |
| Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext |  | Mogul, "Registration Procedures |
| Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. |  | for Message Header Fields", |
|  |  | BCP 90, RFC 3864, September 2004. |
| [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO |  | [RFC4288] Freed, N. and J. Klensin, "Media |
| 10646", STD 63, RFC 3629, November 2003. |  | Type Specifications and |
|  |  | Registration Procedures", BCP 13, |
|  |  | RFC 4288, December 2005. |
| [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration |  | [RFC5226] Narten, T. and H. Alvestrand, |
| Procedures for Message Header Fields", BCP 90, |  | "Guidelines for Writing an IANA |
| RFC 3864, September 2004. |  | Considerations Section in RFCs", |
|  |  | BCP 26, RFC 5226, May 2008. |
| [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications |  | [RFC5322] Resnick, P., "Internet Message |
| and Registration Procedures", BCP 13, RFC 4288, |  | Format", RFC 5322, October 2008. |
| December 2005. |  |  |
| [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing |  | [RFC6151] Turner, S. and L. Chen, "Updated |
| an IANA Considerations Section in RFCs", BCP 26, |  | Security Considerations for the |
| RFC 5226, May 2008. |  | MD5 Message-Digest and the HMAC- |
|  |  | MD5 Algorithms", RFC 6151, |
|  |  | March 2011. |
| [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, |  | [draft-ietf-httpbis-content-disp] Reschke, J., "Use of the Content- |
| October 2008. |  | Disposition Header Field in the |
|  |  | Hypertext Transfer Protocol |
|  |  | (HTTP)", |
|  |  | draft-ietf-httpbis-content-disp-09 |
|  |  | (work in progress), March 2011. |
| Appendix A. Differences between HTTP and MIME |  | Appendix A. Differences between HTTP and MIME |
| HTTP/1.1 uses many of the constructs defined for Internet Mail |  | HTTP/1.1 uses many of the constructs defined for Internet Mail |
| ([RFC5322]) and the Multipurpose Internet Mail Extensions (MIME |  | ([RFC5322]) and the Multipurpose Internet Mail Extensions (MIME |
| [RFC2045]) to allow a message-body to be transmitted in an open |  | [RFC2045]) to allow a message-body to be transmitted in an open |
| variety of representations and with extensible mechanisms. However, |  | variety of representations and with extensible mechanisms. However, |
| RFC 2045 discusses mail, and HTTP has a few features that are |  | RFC 2045 discusses mail, and HTTP has a few features that are |
| different from those described in MIME. These differences were |  | different from those described in MIME. These differences were |
| carefully chosen to optimize performance over binary connections, to |  | carefully chosen to optimize performance over binary connections, to |
| skipping to change at page 33, line 8 |  | skipping to change at page 31, line 44 |
| A.1. MIME-Version |  | A.1. MIME-Version |
| HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages |  | HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages |
| MAY include a single MIME-Version header field to indicate what |  | MAY include a single MIME-Version header field to indicate what |
| version of the MIME protocol was used to construct the message. Use |  | version of the MIME protocol was used to construct the message. Use |
| of the MIME-Version header field indicates that the message is in |  | of the MIME-Version header field indicates that the message is in |
| full compliance with the MIME protocol (as defined in [RFC2045]). |  | full compliance with the MIME protocol (as defined in [RFC2045]). |
| Proxies/gateways are responsible for ensuring full compliance (where |  | Proxies/gateways are responsible for ensuring full compliance (where |
| possible) when exporting HTTP messages to strict MIME environments. |  | possible) when exporting HTTP messages to strict MIME environments. |
| MIME-Version = "MIME-Version" ":" OWS MIME-Version-v |  | MIME-Version = 1*DIGIT "." 1*DIGIT |
| MIME-Version-v = 1*DIGIT "." 1*DIGIT |  |  |
| MIME version "1.0" is the default for use in HTTP/1.1. However, |  | MIME version "1.0" is the default for use in HTTP/1.1. However, |
| HTTP/1.1 message parsing and semantics are defined by this document |  | HTTP/1.1 message parsing and semantics are defined by this document |
| and not the MIME specification. |  | and not the MIME specification. |
| A.2. Conversion to Canonical Form |  | A.2. Conversion to Canonical Form |
| MIME requires that an Internet mail body-part be converted to |  | MIME requires that an Internet mail body-part be converted to |
| canonical form prior to being transferred, as described in Section 4 |  | canonical form prior to being transferred, as described in Section 4 |
| of [RFC2049]. Section 2.3.1 of this document describes the forms |  | of [RFC2049]. Section 2.3.1 of this document describes the forms |
| skipping to change at page 35, line 12 |  | skipping to change at page 33, line 49 |
| [RFC1945] and [RFC2068] document protocol elements used by some |  | [RFC1945] and [RFC2068] document protocol elements used by some |
| existing HTTP implementations, but not consistently and correctly |  | existing HTTP implementations, but not consistently and correctly |
| across most HTTP/1.1 applications. Implementors are advised to be |  | across most HTTP/1.1 applications. Implementors are advised to be |
| aware of these features, but cannot rely upon their presence in, or |  | aware of these features, but cannot rely upon their presence in, or |
| 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 header fields, such as Content-Disposition and |  | A number of other header fields, such as Content-Disposition and |
| Title, from SMTP and MIME are also often implemented (see [RFC2076]). |  | Title, from SMTP and MIME are also often implemented (see |
|  |  | [draft-ietf-httpbis-content-disp] and [RFC2076]). |
| Appendix C. Changes from RFC 2616 |  | Appendix C. Changes from RFC 2616 |
| Clarify contexts that charset is used in. (Section 2.1) |  | Clarify contexts that charset is used in. (Section 2.1) |
|  |  | Remove the default character encoding for text media types; the |
|  |  | default now is whatever the media type definition says. |
|  |  | (Section 2.3.1) |
|  |  | Change ABNF productions for header fields to only define the field |
|  |  | value. (Section 6) |
|  |  | Remove definition of Content-MD5 header field because it was |
|  |  | inconsistently implemented with respect to partial responses, and |
|  |  | also because of known deficiencies in the hash algorithm itself (see |
|  |  | [RFC6151] for details). (Section 6) |
|  |  | Remove ISO-8859-1 special-casing in Accept-Charset. (Section 6.2) |
| Remove base URI setting semantics for Content-Location due to poor |  | Remove base URI setting semantics for Content-Location due to poor |
| implementation support, which was caused by too many broken servers |  | implementation support, which was caused by too many broken servers |
| emitting bogus Content-Location header fields, and also the |  | emitting bogus Content-Location header fields, and also the |
| potentially undesirable effect of potentially breaking relative links |  | potentially undesirable effect of potentially breaking relative links |
| in content-negotiated resources. (Section 6.7) |  | in content-negotiated resources. (Section 6.7) |
|  |  | Remove discussion of Content-Disposition header field, it is now |
|  |  | defined by [draft-ietf-httpbis-content-disp]. (Appendix B) |
| 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 = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [ |
| Accept-Charset = "Accept-Charset:" OWS Accept-Charset-v |  | OWS media-range [ accept-params ] ] ) ] |
| Accept-Charset-v = *( "," OWS ) ( charset / "*" ) [ OWS ";" OWS "q=" |  | Accept-Charset = *( "," OWS ) ( charset / "*" ) [ OWS ";" OWS "q=" |
| qvalue ] *( OWS "," [ OWS ( charset / "*" ) [ OWS ";" OWS "q=" |  | qvalue ] *( OWS "," [ OWS ( charset / "*" ) [ OWS ";" OWS "q=" |
| qvalue ] ] ) |  | qvalue ] ] ) |
| Accept-Encoding = "Accept-Encoding:" OWS Accept-Encoding-v |  | Accept-Encoding = [ ( "," / ( codings [ OWS ";" OWS "q=" qvalue ] ) ) |
| Accept-Encoding-v = [ ( "," / ( codings [ OWS ";" OWS "q=" qvalue ] ) |  | *( OWS "," [ OWS codings [ OWS ";" OWS "q=" qvalue ] ] ) ] |
| ) *( OWS "," [ OWS codings [ OWS ";" OWS "q=" qvalue ] ] ) ] |  | Accept-Language = *( "," OWS ) language-range [ OWS ";" OWS "q=" |
| Accept-Language = "Accept-Language:" OWS Accept-Language-v |  |  |
| Accept-Language-v = *( "," OWS ) language-range [ OWS ";" OWS "q=" |  |  |
| qvalue ] *( OWS "," [ OWS language-range [ OWS ";" OWS "q=" qvalue ] |  | qvalue ] *( OWS "," [ OWS language-range [ OWS ";" OWS "q=" qvalue ] |
| ] ) |  | ] ) |
| Accept-v = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [ |  |  |
| OWS media-range [ accept-params ] ] ) ] |  |  |
| Content-Encoding = "Content-Encoding:" OWS Content-Encoding-v |  | Content-Encoding = *( "," 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 = *( "," OWS ) language-tag *( OWS "," [ OWS |
| Content-Language-v = *( "," OWS ) language-tag *( OWS "," [ OWS |  |  |
| language-tag ] ) |  | language-tag ] ) |
| Content-Location = "Content-Location:" OWS Content-Location-v |  | Content-Location = absolute-URI / partial-URI |
| Content-Location-v = absolute-URI / partial-URI |  | Content-Type = media-type |
| Content-MD5 = "Content-MD5:" OWS Content-MD5-v |  |  |
| Content-MD5-v = <base64 of 128 bit MD5 digest as per [RFC1864]> |  |  |
| Content-Type = "Content-Type:" OWS Content-Type-v |  |  |
| Content-Type-v = media-type |  |  |
| MIME-Version = "MIME-Version:" OWS MIME-Version-v |  | MIME-Version = 1*DIGIT "." 1*DIGIT |
| MIME-Version-v = 1*DIGIT "." 1*DIGIT |  |  |
| OWS = <OWS, defined in [Part1], Section 1.2.2> |  | OWS = <OWS, defined in [Part1], Section 1.2.2> |
| absolute-URI = <absolute-URI, defined in [Part1], Section 2.6> |  | absolute-URI = <absolute-URI, defined in [Part1], Section 2.6> |
| accept-ext = OWS ";" OWS token [ "=" word ] |  | accept-ext = OWS ";" OWS token [ "=" word ] |
| accept-params = OWS ";" OWS "q=" qvalue *accept-ext |  | accept-params = OWS ";" OWS "q=" qvalue *accept-ext |
| attribute = token |  | attribute = token |
| charset = token |  | charset = token |
| codings = ( content-coding / "*" ) |  | codings = ( content-coding / "*" ) |
| skipping to change at page 37, line 4 |  | skipping to change at page 35, line 39 |
| qvalue = <qvalue, defined in [Part1], Section 6.4> |  | qvalue = <qvalue, defined in [Part1], Section 6.4> |
| subtype = token |  | subtype = token |
| token = <token, defined in [Part1], Section 1.2.2> |  | token = <token, defined in [Part1], Section 1.2.2> |
| type = token |  | type = token |
| value = word |  | value = word |
| word = <word, defined in [Part1], Section 1.2.2> |  | word = <word, defined in [Part1], Section 1.2.2> |
| ABNF diagnostics: |  | ABNF diagnostics: |
| ; Accept defined but not used |  | ; Accept defined but not used |
| ; Accept-Charset defined but not used |  | ; Accept-Charset defined but not used |
| ; Accept-Encoding defined but not used |  | ; Accept-Encoding defined but not used |
| ; Accept-Language defined but not used |  | ; Accept-Language defined but not used |
| ; Content-Encoding defined but not used |  | ; Content-Encoding defined but not used |
| ; Content-Language defined but not used |  | ; Content-Language defined but not used |
| ; Content-Location defined but not used |  | ; Content-Location defined but not used |
| ; Content-MD5 defined but not used |  |  |
| ; Content-Type defined but not used |  | ; Content-Type defined but not used |
| ; MIME-Version defined but not used |  | ; MIME-Version defined but not used |
| Appendix E. Change Log (to be removed by RFC Editor before publication) |  | Appendix E. Change Log (to be removed by RFC Editor before publication) |
| E.1. Since RFC 2616 |  | E.1. Since RFC 2616 |
| Extracted relevant partitions from [RFC2616]. |  | Extracted relevant partitions from [RFC2616]. |
| E.2. Since draft-ietf-httpbis-p3-payload-00 |  | E.2. Since draft-ietf-httpbis-p3-payload-00 |
| skipping to change at page 42, line 30 |  | skipping to change at page 41, line 25 |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/224>: "Header |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/224>: "Header |
| Classification" |  | Classification" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle |
| ABNFs for header fields" |  | ABNFs for header fields" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/277>: "potentially |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/277>: "potentially |
| misleading MAY in media-type def" |  | misleading MAY in media-type def" |
|  |  | E.15. Since draft-ietf-httpbis-p3-payload-13 |
|  |  | Closed issues: |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/20>: "Default |
|  |  | charsets for text media types" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/178>: "Content-MD5 |
|  |  | and partial responses" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle |
|  |  | ABNFs for header fields" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/281>: "confusing |
|  |  | undefined parameter in media range example" |
| Index |  | Index |
| A |  | A |
| Accept header field 16 |  | Accept header field 16 |
| Accept-Charset header field 19 |  | Accept-Charset header field 18 |
| Accept-Encoding header field 19 |  | Accept-Encoding header field 19 |
| Accept-Language header field 21 |  | Accept-Language header field 20 |
| C |  | C |
| Coding Format |  | Coding Format |
| compress 7 |  | compress 7 |
| deflate 8 |  | deflate 7 |
| gzip 8 |  | gzip 7 |
| identity 8 |  | identity 7 |
| compress (Coding Format) 7 |  | compress (Coding Format) 7 |
| content negotiation 5 |  | content negotiation 5 |
| Content-Encoding header field 22 |  | Content-Encoding header field 21 |
| Content-Language header field 23 |  | Content-Language header field 22 |
| Content-Location header field 24 |  | Content-Location header field 23 |
| Content-MD5 header field 25 |  | Content-Type header field 24 |
| Content-Type header field 26 |  |  |
| D |  | D |
| deflate (Coding Format) 8 |  | deflate (Coding Format) 7 |
| G |  | G |
| Grammar |  | Grammar |
| Accept 17 |  | Accept 16 |
| Accept-Charset 19 |  | Accept-Charset 18 |
| Accept-Charset-v 19 |  | Accept-Encoding 19 |
| Accept-Encoding 20 |  | accept-ext 16 |
| Accept-Encoding-v 20 |  | Accept-Language 20 |
| accept-ext 17 |  | accept-params 16 |
| Accept-Language 21 |  | attribute 8 |
| Accept-Language-v 21 |  |  |
| accept-params 17 |  |  |
| Accept-v 17 |  |  |
| attribute 9 |  |  |
| charset 6 |  | charset 6 |
| codings 20 |  | codings 19 |
| content-coding 7 |  | content-coding 7 |
| Content-Encoding 22 |  | Content-Encoding 21 |
| Content-Encoding-v 22 |  | Content-Language 22 |
| Content-Language 23 |  | Content-Location 23 |
| Content-Language-v 23 |  | Content-Type 24 |
| Content-Location 24 |  | language-range 20 |
| Content-Location-v 24 |  | language-tag 10 |
| Content-MD5 25 |  | media-range 16 |
| Content-MD5-v 25 |  | media-type 8 |
| Content-Type 26 |  | MIME-Version 31 |
| Content-Type-v 26 |  | parameter 8 |
| language-range 21 |  | subtype 8 |
| language-tag 11 |  | type 8 |
| media-range 17 |  | value 8 |
| media-type 9 |  | gzip (Coding Format) 7 |
| MIME-Version 33 |  |  |
| MIME-Version-v 33 |  |  |
| parameter 9 |  |  |
| subtype 9 |  |  |
| type 9 |  |  |
| value 9 |  |  |
| gzip (Coding Format) 8 |  |  |
| H |  | H |
| Header Fields |  | Header Fields |
| Accept 16 |  | Accept 16 |
| Accept-Charset 19 |  | Accept-Charset 18 |
| Accept-Encoding 19 |  | Accept-Encoding 19 |
| Accept-Language 21 |  | Accept-Language 20 |
| Content-Encoding 22 |  | Content-Encoding 21 |
| Content-Language 23 |  | Content-Language 22 |
| Content-Location 24 |  | Content-Location 23 |
| Content-MD5 25 |  | Content-Type 24 |
| Content-Type 26 |  | MIME-Version 31 |
| MIME-Version 32 |  |  |
| I |  | I |
| identity (Coding Format) 8 |  | identity (Coding Format) 7 |
| M |  | M |
| MIME-Version header field 32 |  | MIME-Version header field 31 |
| P |  | P |
| payload 11 |  | payload 10 |
| R |  | R |
| representation 12 |  | representation 11 |
| Authors' Addresses |  | Authors' Addresses |
| Roy T. Fielding (editor) |  | Roy T. Fielding (editor) |
| Adobe Systems Incorporated |  | Adobe Systems Incorporated |
| 345 Park Ave |  | 345 Park Ave |
| San Jose, CA 95110 |  | San Jose, CA 95110 |
| USA |  | USA |
| EMail: fielding@gbiv.com |  | EMail: fielding@gbiv.com |
End of changes. 100 change blocks.
| 384 lines changed or deleted |  | 348 lines changed or added |
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/