| draft-ietf-httpbis-p3-payload-12.txt |  | draft-ietf-httpbis-p3-payload-13.txt |
--- | --- | --- | --- | ---
| HTTPbis Working Group R. Fielding, Ed. |  | HTTPbis Working Group R. Fielding, Ed. |
| Internet-Draft Day Software |  | 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: April 28, 2011 J. Mogul |  | Expires: September 15, 2011 J. Mogul |
| HP |  | HP |
| H. Frystyk |  | H. Frystyk |
| Microsoft |  | Microsoft |
| L. Masinter |  | L. Masinter |
| Adobe Systems |  | 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 |
| October 25, 2010 |  | March 14, 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-12 |  | draft-ietf-httpbis-p3-payload-13 |
| Abstract |  | Abstract |
| The Hypertext Transfer Protocol (HTTP) is an application-level |  | The Hypertext Transfer Protocol (HTTP) is an application-level |
| protocol for distributed, collaborative, hypermedia information |  | protocol for distributed, collaborative, hypermedia information |
| systems. HTTP has been in use by the World Wide Web global |  | systems. HTTP has been in use by the World Wide Web global |
| information initiative since 1990. This document is Part 3 of the |  | information initiative since 1990. This document is Part 3 of the |
| seven-part specification that defines the protocol referred to as |  | seven-part specification that defines the protocol referred to as |
| "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 3 defines |  | "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 3 defines |
| HTTP message content, metadata, and content negotiation. |  | HTTP message content, metadata, and content negotiation. |
| Editorial Note (To be removed by RFC Editor) |  | Editorial Note (To be removed by RFC Editor) |
| Discussion of this draft should take place on the HTTPBIS working |  | Discussion of this draft should take place on the HTTPBIS working |
| group mailing list (ietf-http-wg@w3.org). The current issues list is |  | group mailing list (ietf-http-wg@w3.org). The current issues list is |
| at <http://tools.ietf.org/wg/httpbis/trac/report/3> and related |  | at <http://tools.ietf.org/wg/httpbis/trac/report/3> and related |
| documents (including fancy diffs) can be found at |  | documents (including fancy diffs) can be found at |
| <http://tools.ietf.org/wg/httpbis/>. |  | <http://tools.ietf.org/wg/httpbis/>. |
| The changes in this draft are summarized in Appendix E.13. |  | The changes in this draft are summarized in Appendix E.14. |
| Status of This Memo |  | Status of This Memo |
| This Internet-Draft is submitted in full conformance with the |  | This Internet-Draft is submitted in full conformance with the |
| provisions of BCP 78 and BCP 79. |  | provisions of BCP 78 and BCP 79. |
| Internet-Drafts are working documents of the Internet Engineering |  | Internet-Drafts are working documents of the Internet Engineering |
| Task Force (IETF). Note that other groups may also distribute |  | Task Force (IETF). Note that other groups may also distribute |
| working documents as Internet-Drafts. The list of current Internet- |  | working documents as Internet-Drafts. The list of current Internet- |
| Drafts is at http://datatracker.ietf.org/drafts/current/. |  | Drafts is at http://datatracker.ietf.org/drafts/current/. |
| Internet-Drafts are draft documents valid for a maximum of six months |  | Internet-Drafts are draft documents valid for a maximum of six months |
| and may be updated, replaced, or obsoleted by other documents at any |  | and may be updated, replaced, or obsoleted by other documents at any |
| time. It is inappropriate to use Internet-Drafts as reference |  | time. It is inappropriate to use Internet-Drafts as reference |
| material or to cite them other than as "work in progress." |  | material or to cite them other than as "work in progress." |
| This Internet-Draft will expire on April 28, 2011. |  | This Internet-Draft will expire on September 15, 2011. |
| Copyright Notice |  | Copyright Notice |
| Copyright (c) 2010 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 |
| carefully, as they describe your rights and restrictions with respect |  | carefully, as they describe your rights and restrictions with respect |
| to this document. Code Components extracted from this document must |  | to this document. Code Components extracted from this document must |
| include Simplified BSD License text as described in Section 4.e of |  | include Simplified BSD License text as described in Section 4.e of |
| the Trust Legal Provisions and are provided without warranty as |  | the Trust Legal Provisions and are provided without warranty as |
| skipping to change at page 3, line 6 |  | skipping to change at page 3, line 6 |
| 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 Sets . . . . . . . . . . . . . . . . . . . . . . 6 |  | 2.1. Character Encodings (charset) . . . . . . . . . . . . . . 6 |
| 2.1.1. Missing Charset . . . . . . . . . . . . . . . . . . . 7 |  | 2.1.1. Missing Charset . . . . . . . . . . . . . . . . . . . 7 |
| 2.2. Content Codings . . . . . . . . . . . . . . . . . . . . . 8 |  | 2.2. Content Codings . . . . . . . . . . . . . . . . . . . . . 7 |
| 2.2.1. Content Coding Registry . . . . . . . . . . . . . . . 9 |  | 2.2.1. Content Coding Registry . . . . . . . . . . . . . . . 8 |
| 2.3. Media Types . . . . . . . . . . . . . . . . . . . . . . . 9 |  | 2.3. Media Types . . . . . . . . . . . . . . . . . . . . . . . 8 |
| 2.3.1. Canonicalization and Text Defaults . . . . . . . . . . 10 |  | 2.3.1. Canonicalization and Text Defaults . . . . . . . . . . 9 |
| 2.3.2. Multipart Types . . . . . . . . . . . . . . . . . . . 11 |  | 2.3.2. Multipart Types . . . . . . . . . . . . . . . . . . . 10 |
| 2.4. Language Tags . . . . . . . . . . . . . . . . . . . . . . 11 |  | 2.4. Language Tags . . . . . . . . . . . . . . . . . . . . . . 10 |
| 3. Payload . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 |  | 3. Payload . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 |
| 3.1. Payload Header Fields . . . . . . . . . . . . . . . . . . 12 |  | 3.1. Payload Header Fields . . . . . . . . . . . . . . . . . . 11 |
| 3.2. Payload Body . . . . . . . . . . . . . . . . . . . . . . . 12 |  | 3.2. Payload Body . . . . . . . . . . . . . . . . . . . . . . . 12 |
| 4. Representation . . . . . . . . . . . . . . . . . . . . . . . . 12 |  | 4. Representation . . . . . . . . . . . . . . . . . . . . . . . . 12 |
| 4.1. Representation Header Fields . . . . . . . . . . . . . . . 13 |  | 4.1. Representation Header Fields . . . . . . . . . . . . . . . 12 |
| 4.2. Representation Data . . . . . . . . . . . . . . . . . . . 13 |  | 4.2. Representation Data . . . . . . . . . . . . . . . . . . . 13 |
| 5. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 14 |  | 5. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 14 |
| 5.1. Server-driven Negotiation . . . . . . . . . . . . . . . . 15 |  | 5.1. Server-driven Negotiation . . . . . . . . . . . . . . . . 15 |
| 5.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . . 16 |  | 5.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . . 16 |
| 6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 17 |  | 6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 16 |
| 6.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . . 17 |  | 6.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . . 16 |
| 6.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . . 19 |  | 6.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . . 19 |
| 6.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 20 |  | 6.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 19 |
| 6.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 21 |  | 6.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 21 |
| 6.5. Content-Encoding . . . . . . . . . . . . . . . . . . . . . 22 |  | 6.5. Content-Encoding . . . . . . . . . . . . . . . . . . . . . 22 |
| 6.6. Content-Language . . . . . . . . . . . . . . . . . . . . . 23 |  | 6.6. Content-Language . . . . . . . . . . . . . . . . . . . . . 23 |
| 6.7. Content-Location . . . . . . . . . . . . . . . . . . . . . 24 |  | 6.7. Content-Location . . . . . . . . . . . . . . . . . . . . . 24 |
| 6.8. Content-MD5 . . . . . . . . . . . . . . . . . . . . . . . 25 |  | 6.8. Content-MD5 . . . . . . . . . . . . . . . . . . . . . . . 25 |
| 6.9. Content-Type . . . . . . . . . . . . . . . . . . . . . . . 27 |  | 6.9. Content-Type . . . . . . . . . . . . . . . . . . . . . . . 26 |
| 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 |  | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 |
| 7.1. Header Field Registration . . . . . . . . . . . . . . . . 27 |  | 7.1. Header Field Registration . . . . . . . . . . . . . . . . 27 |
| 7.2. Content Coding Registry . . . . . . . . . . . . . . . . . 27 |  | 7.2. Content Coding Registry . . . . . . . . . . . . . . . . . 27 |
| 8. Security Considerations . . . . . . . . . . . . . . . . . . . 28 |  | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 28 |
| 8.1. Privacy Issues Connected to Accept Header Fields . . . . . 28 |  | 8.1. Privacy Issues Connected to Accept Header Fields . . . . . 28 |
| 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 |  | 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 |
| 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 |  | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 |
| 10.1. Normative References . . . . . . . . . . . . . . . . . . . 29 |  | 10.1. Normative References . . . . . . . . . . . . . . . . . . . 29 |
| 10.2. Informative References . . . . . . . . . . . . . . . . . . 31 |  | 10.2. Informative References . . . . . . . . . . . . . . . . . . 31 |
| Appendix A. Differences between HTTP and MIME . . . . . . . . . . 32 |  | Appendix A. Differences between HTTP and MIME . . . . . . . . . . 32 |
| A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 33 |  | A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 32 |
| A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 33 |  | A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 33 |
| A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 33 |  | A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 33 |
| A.4. Introduction of Content-Encoding . . . . . . . . . . . . . 34 |  | A.4. Introduction of Content-Encoding . . . . . . . . . . . . . 34 |
| A.5. No Content-Transfer-Encoding . . . . . . . . . . . . . . . 34 |  | A.5. No Content-Transfer-Encoding . . . . . . . . . . . . . . . 34 |
| A.6. Introduction of Transfer-Encoding . . . . . . . . . . . . 34 |  | A.6. Introduction of Transfer-Encoding . . . . . . . . . . . . 34 |
| A.7. MHTML and Line Length Limitations . . . . . . . . . . . . 34 |  | A.7. MHTML and Line Length Limitations . . . . . . . . . . . . 34 |
| Appendix B. Additional Features . . . . . . . . . . . . . . . . . 35 |  | Appendix B. Additional Features . . . . . . . . . . . . . . . . . 34 |
| Appendix C. Changes from RFC 2616 . . . . . . . . . . . . . . . . 35 |  | Appendix C. Changes from RFC 2616 . . . . . . . . . . . . . . . . 35 |
| Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 35 |  | 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) . . . . . . . . . . . . . . . . . . . . 37 |
| E.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 37 |  | E.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 37 |
| E.2. Since draft-ietf-httpbis-p3-payload-00 . . . . . . . . . . 37 |  | E.2. Since draft-ietf-httpbis-p3-payload-00 . . . . . . . . . . 37 |
| E.3. Since draft-ietf-httpbis-p3-payload-01 . . . . . . . . . . 38 |  | E.3. Since draft-ietf-httpbis-p3-payload-01 . . . . . . . . . . 38 |
| E.4. Since draft-ietf-httpbis-p3-payload-02 . . . . . . . . . . 38 |  | E.4. Since draft-ietf-httpbis-p3-payload-02 . . . . . . . . . . 38 |
| E.5. Since draft-ietf-httpbis-p3-payload-03 . . . . . . . . . . 38 |  | E.5. Since draft-ietf-httpbis-p3-payload-03 . . . . . . . . . . 38 |
| E.6. Since draft-ietf-httpbis-p3-payload-04 . . . . . . . . . . 39 |  | E.6. Since draft-ietf-httpbis-p3-payload-04 . . . . . . . . . . 39 |
| E.7. Since draft-ietf-httpbis-p3-payload-05 . . . . . . . . . . 39 |  | E.7. Since draft-ietf-httpbis-p3-payload-05 . . . . . . . . . . 39 |
| E.8. Since draft-ietf-httpbis-p3-payload-06 . . . . . . . . . . 40 |  | E.8. Since draft-ietf-httpbis-p3-payload-06 . . . . . . . . . . 39 |
| E.9. Since draft-ietf-httpbis-p3-payload-07 . . . . . . . . . . 40 |  | E.9. Since draft-ietf-httpbis-p3-payload-07 . . . . . . . . . . 40 |
| E.10. Since draft-ietf-httpbis-p3-payload-08 . . . . . . . . . . 40 |  | E.10. Since draft-ietf-httpbis-p3-payload-08 . . . . . . . . . . 40 |
| E.11. Since draft-ietf-httpbis-p3-payload-09 . . . . . . . . . . 41 |  | E.11. Since draft-ietf-httpbis-p3-payload-09 . . . . . . . . . . 41 |
| E.12. Since draft-ietf-httpbis-p3-payload-10 . . . . . . . . . . 41 |  | E.12. Since draft-ietf-httpbis-p3-payload-10 . . . . . . . . . . 41 |
| E.13. Since draft-ietf-httpbis-p3-payload-11 . . . . . . . . . . 42 |  | E.13. Since draft-ietf-httpbis-p3-payload-11 . . . . . . . . . . 42 |
|  |  | E.14. Since draft-ietf-httpbis-p3-payload-12 . . . . . . . . . . 42 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 |
| 1. Introduction |  | 1. Introduction |
| This document defines HTTP/1.1 message payloads (a.k.a., content), |  | This document defines HTTP/1.1 message payloads (a.k.a., content), |
| the associated metadata header fields that define how the payload is |  | the associated metadata header fields that define how the payload is |
| intended to be interpreted by a recipient, the request header fields |  | intended to be interpreted by a recipient, the request header fields |
| that 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 6, line 32 |  | skipping to change at page 6, line 32 |
| token = <token, defined in [Part1], Section 1.2.2> |  | token = <token, defined in [Part1], Section 1.2.2> |
| word = <word, defined in [Part1], Section 1.2.2> |  | word = <word, defined in [Part1], Section 1.2.2> |
| OWS = <OWS, defined in [Part1], Section 1.2.2> |  | OWS = <OWS, defined in [Part1], Section 1.2.2> |
| 1.3.2. ABNF Rules defined in other Parts of the Specification |  | 1.3.2. ABNF Rules defined in other Parts of the Specification |
| The ABNF rules below are defined in other parts: |  | The ABNF rules below are defined in other parts: |
| absolute-URI = <absolute-URI, defined in [Part1], Section 2.6> |  | absolute-URI = <absolute-URI, defined in [Part1], Section 2.6> |
| Content-Length = <Content-Length, defined in [Part1], Section 9.2> |  |  |
| partial-URI = <partial-URI, defined in [Part1], Section 2.6> |  | partial-URI = <partial-URI, defined in [Part1], Section 2.6> |
| qvalue = <qvalue, defined in [Part1], Section 6.4> |  | qvalue = <qvalue, defined in [Part1], Section 6.4> |
| Last-Modified = <Last-Modified, defined in [Part4], Section 6.6> |  |  |
| Content-Range = <Content-Range, defined in [Part5], Section 5.2> |  |  |
| Expires = <Expires, defined in [Part6], Section 3.3> |  |  |
| 2. Protocol Parameters |  | 2. Protocol Parameters |
| 2.1. Character Sets |  | 2.1. Character Encodings (charset) |
| HTTP uses the same definition of the term "character set" as that |  |  |
| described for MIME: |  |  |
| The term "character set" is used in this document to refer to a |  |  |
| method used with one or more tables to convert a sequence of octets |  |  |
| into a sequence of characters. Note that unconditional conversion in |  |  |
| the other direction is not required, in that not all characters might |  |  |
| be available in a given character set and a character set might |  |  |
| provide more than one sequence of octets to represent a particular |  |  |
| character. This definition is intended to allow various kinds of |  |  |
| character encoding, from simple single-table mappings such as US- |  |  |
| ASCII to complex table switching methods such as those that use ISO- |  |  |
| 2022's techniques. However, the definition associated with a MIME |  |  |
| character set name MUST fully specify the mapping to be performed |  |  |
| from octets to characters. In particular, use of external profiling |  |  |
| information to determine the exact mapping is not permitted. |  |  |
| Note: This use of the term "character set" is more commonly |  | HTTP uses charset names to indicate the character encoding of a |
| referred to as a "character encoding". However, since HTTP and |  | textual representation. |
| MIME share the same registry, it is important that the terminology |  |  |
| also be shared. |  |  |
| HTTP character sets are identified by case-insensitive tokens. The |  | A character encoding is identified by a case-insensitive token. The |
| complete set of tokens is defined by the IANA Character Set registry |  | complete set of tokens is defined by the IANA Character Set registry |
| (<http://www.iana.org/assignments/character-sets>). |  | (<http://www.iana.org/assignments/character-sets>). |
| charset = token |  | charset = token |
| Although HTTP allows an arbitrary token to be used as a charset |  | Although HTTP allows an arbitrary token to be used as a charset |
| value, any token that has a predefined value within the IANA |  | value, any token that has a predefined value within the IANA |
| Character Set registry MUST represent the character set defined by |  | Character Set registry MUST represent the character encoding defined |
| that registry. Applications SHOULD limit their use of character sets |  | by that registry. Applications SHOULD limit their use of character |
| to those defined by the IANA registry. |  | encodings to those defined within the IANA registry. |
| HTTP uses charset in two contexts: within an Accept-Charset request |  | HTTP uses charset in two contexts: within an Accept-Charset request |
| header 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]. |
| skipping to change at page 9, line 40 |  | skipping to change at page 9, line 9 |
| 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.9) and Accept (Section 6.1) header fields in order to |
| provide open and extensible data typing and type negotiation. |  | provide open and extensible data typing and type negotiation. |
| media-type = type "/" subtype *( OWS ";" OWS parameter ) |  | media-type = type "/" subtype *( OWS ";" OWS parameter ) |
| type = token |  | type = token |
| subtype = token |  | subtype = token |
| Parameters MAY follow the type/subtype in the form of attribute/value |  | The type/subtype MAY be followed by parameters in the form of |
| pairs. |  | attribute/value pairs. |
| parameter = attribute "=" value |  | parameter = attribute "=" value |
| attribute = token |  | attribute = token |
| value = word |  | value = word |
| The type, subtype, and parameter attribute names are case- |  | The type, subtype, and parameter attribute names are case- |
| insensitive. Parameter values might or might not be case-sensitive, |  | insensitive. Parameter values might or might not be case-sensitive, |
| depending on the semantics of the parameter name. The presence or |  | depending on the semantics of the parameter name. The presence or |
| absence of a parameter might be significant to the processing of a |  | absence of a parameter might be significant to the processing of a |
| media-type, depending on its definition within the media type |  | media-type, depending on its definition within the media type |
| skipping to change at page 12, line 28 |  | skipping to change at page 11, line 44 |
| header fields (e.g., responses to HEAD) or only some part(s) of the |  | header fields (e.g., responses to HEAD) or only some part(s) of the |
| representation (e.g., the 206 status code). |  | representation (e.g., the 206 status code). |
| 3.1. Payload Header Fields |  | 3.1. Payload Header Fields |
| 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: |
| Content-Length ; [Part1], Section 9.2 |  | +-------------------+------------------------+ |
| Content-MD5 ; Section 6.8 |  | | Header Field Name | Defined in... | |
| Content-Range ; [Part5], Section 5.2 |  | +-------------------+------------------------+ |
|  |  | | Content-Length | Section 9.2 of [Part1] | |
|  |  | | Content-MD5 | Section 6.8 | |
|  |  | | 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. |
| 4. Representation |  | 4. Representation |
| skipping to change at page 13, line 24 |  | skipping to change at page 13, line 5 |
| 4.1. Representation Header Fields |  | 4.1. Representation Header Fields |
| Representation header fields define metadata about the representation |  | Representation header fields define metadata about the representation |
| data enclosed in the message-body or, if no message-body is present, |  | data enclosed in the message-body or, if no message-body is present, |
| about the representation that would have been transferred in a 200 |  | about the representation that would have been transferred in a 200 |
| response to a simultaneous GET request with the same effective |  | response to a simultaneous GET request with the same effective |
| request URI. |  | request URI. |
| The following header fields are defined as representation metadata: |  | The following header fields are defined as representation metadata: |
| Content-Encoding ; Section 6.5 |  | +-------------------+------------------------+ |
| Content-Language ; Section 6.6 |  | | Header Field Name | Defined in... | |
| Content-Location ; Section 6.7 |  | +-------------------+------------------------+ |
| Content-Type ; Section 6.9 |  | | Content-Encoding | Section 6.5 | |
| Expires ; [Part6], Section 3.3 |  | | Content-Language | Section 6.6 | |
| Last-Modified ; [Part4], Section 6.6 |  | | Content-Location | Section 6.7 | |
|  |  | | Content-Type | Section 6.9 | |
|  |  | | Expires | Section 3.3 of [Part6] | |
|  |  | | Last-Modified | Section 6.6 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. |
| The data type of the representation data is determined via the header |  | The data type of the representation data is determined via the header |
| skipping to change at page 16, line 11 |  | skipping to change at page 15, line 44 |
| can be both very inefficient (given that only a small percentage |  | can be both very inefficient (given that only a small percentage |
| of responses have multiple representations) and a potential |  | of responses have multiple representations) and a potential |
| violation of the user's privacy. |  | violation of the user's privacy. |
| 3. It complicates the implementation of an origin server and the |  | 3. It complicates the implementation of an origin server and the |
| algorithms for generating responses to a request. |  | algorithms for generating responses to a request. |
| 4. It might limit a public cache's ability to use the same response |  | 4. It might limit a public cache's ability to use the same response |
| for multiple user's requests. |  | for multiple user's requests. |
| HTTP/1.1 includes the following request-header fields for enabling |  | HTTP/1.1 includes the following header fields for enabling server- |
| server-driven negotiation through description of user agent |  | driven negotiation through description of user agent capabilities and |
| capabilities and user preferences: Accept (Section 6.1), Accept- |  | user preferences: Accept (Section 6.1), Accept-Charset (Section 6.2), |
| Charset (Section 6.2), Accept-Encoding (Section 6.3), Accept-Language |  | Accept-Encoding (Section 6.3), Accept-Language (Section 6.4), and |
| (Section 6.4), and User-Agent (Section 9.9 of [Part2]). However, an |  | User-Agent (Section 9.9 of [Part2]). However, an origin server is |
| origin server is not limited to these dimensions and MAY vary the |  | not limited to these dimensions and MAY vary the response based on |
| response based on any aspect of the request, including information |  | any aspect of the request, including aspects of the connection (e.g., |
| outside the request-header fields or within extension header fields |  | IP address) or information within extension header fields not defined |
| not defined by this specification. |  | by this specification. |
| Note: In practice, User-Agent based negotiation is fragile, |  | Note: In practice, User-Agent based negotiation is fragile, |
| because new clients might not be recognized. |  | because new clients might not be recognized. |
| The Vary header field (Section 3.5 of [Part6]) can be used to express |  | The Vary header field (Section 3.5 of [Part6]) can be used to express |
| the parameters the server uses to select a representation that is |  | the parameters the server uses to select a representation that is |
| subject to server-driven negotiation. |  | subject to server-driven negotiation. |
| 5.2. Agent-driven Negotiation |  | 5.2. Agent-driven Negotiation |
| skipping to change at page 17, line 17 |  | skipping to change at page 16, line 50 |
| the server is unwilling or unable to provide a varying response using |  | the server is unwilling or unable to provide a varying response using |
| server-driven negotiation. |  | server-driven negotiation. |
| 6. Header Field Definitions |  | 6. Header Field Definitions |
| This section defines the syntax and semantics of HTTP/1.1 header |  | This section defines the syntax and semantics of HTTP/1.1 header |
| fields related to the payload of messages. |  | fields related to the payload of messages. |
| 6.1. Accept |  | 6.1. Accept |
| The "Accept" request-header field can be used by user agents to |  | The "Accept" header field can be used by user agents to specify |
| specify response media types that are acceptable. Accept header |  | response media types that are acceptable. Accept header fields can |
| fields can be used to indicate that the request is specifically |  | be used to indicate that the request is specifically limited to a |
| limited to a small set of desired types, as in the case of a request |  | small set of desired types, as in the case of a request for an in- |
| 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 ) |
| 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 ] |
| skipping to change at page 19, line 25 |  | skipping to change at page 19, line 9 |
| | 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. |
| 6.2. Accept-Charset |  | 6.2. Accept-Charset |
| The "Accept-Charset" request-header field can be used by user agents |  | The "Accept-Charset" header field can be used by user agents to |
| to indicate what response character sets are acceptable. This field |  | indicate what character encodings are acceptable in a response |
| allows clients capable of understanding more comprehensive or |  | payload. This field allows clients capable of understanding more |
| special-purpose character sets to signal that capability to a server |  | comprehensive or special-purpose character encodings to signal that |
| which is capable of representing documents in those character sets. |  | capability to a server which is capable of representing documents in |
|  |  | those character encodings. |
| 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 encoding values (a.k.a., charsets) are described in |
| be given an associated quality value which represents the user's |  | Section 2.1. Each charset MAY be given an associated quality value |
| preference for that charset. The default value is q=1. An example |  | which represents the user's preference for that charset. The default |
| 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 set (including ISO-8859-1) which is not |  | matches every character encoding (including ISO-8859-1) which is not |
| mentioned elsewhere in the Accept-Charset field. If no "*" is |  | mentioned elsewhere in the Accept-Charset field. If no "*" is |
| present in an Accept-Charset field, then all character sets not |  | present in an Accept-Charset field, then all character encodings not |
| explicitly mentioned get a quality value of 0, except for ISO-8859-1, |  | explicitly mentioned get a quality value of 0, except for ISO-8859-1, |
| which gets a quality value of 1 if not explicitly mentioned. |  | which gets a quality value of 1 if not explicitly mentioned. |
| If no Accept-Charset header field is present, the default is that any |  | If no Accept-Charset header field is present, the default is that any |
| character set is acceptable. If an Accept-Charset header field is |  | character encoding is acceptable. If an Accept-Charset header field |
| present, and if the server cannot send a response which is acceptable |  | is present, and if the server cannot send a response which is |
| according to the Accept-Charset header field, then the server SHOULD |  | acceptable according to the Accept-Charset header field, then the |
| send an error response with the 406 (Not Acceptable) status code, |  | server SHOULD send an error response with the 406 (Not Acceptable) |
| though the sending of an unacceptable response is also allowed. |  | status code, though the sending of an unacceptable response is also |
|  |  | allowed. |
| 6.3. Accept-Encoding |  | 6.3. Accept-Encoding |
| The "Accept-Encoding" request-header field can be used by user agents |  | The "Accept-Encoding" header field can be used by user agents to |
| to indicate what response content-codings (Section 2.2) are |  | indicate what response content-codings (Section 2.2) are acceptable |
| acceptable in the response. |  | 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 21, line 32 |  | skipping to change at page 21, line 22 |
| 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. |
| 6.4. Accept-Language |  | 6.4. Accept-Language |
| The "Accept-Language" request-header field can be used by user agents |  | The "Accept-Language" header field can be used by user agents to |
| 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" ":" 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 |
| skipping to change at page 22, line 50 |  | skipping to change at page 22, line 41 |
| Content-Encoding = "Content-Encoding" ":" OWS Content-Encoding-v |  | Content-Encoding = "Content-Encoding" ":" OWS Content-Encoding-v |
| Content-Encoding-v = 1#content-coding |  | Content-Encoding-v = 1#content-coding |
| Content codings are defined in Section 2.2. An example of its use is |  | Content codings are defined in Section 2.2. An example of its use is |
| Content-Encoding: gzip |  | Content-Encoding: gzip |
| The content-coding is a characteristic of the 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 non- |  | is only decoded before rendering or analogous usage. However, a |
| transparent 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" |
| cache-control directive is present in the message. |  | cache-control directive is present in the message. |
| If the content-coding of a representation is not "identity", then the |  | If the content-coding of a representation is not "identity", then the |
| representation metadata MUST include a Content-Encoding header field |  | representation metadata MUST include a Content-Encoding header field |
| (Section 6.5) that lists the non-identity content-coding(s) used. |  | (Section 6.5) that lists the non-identity content-coding(s) used. |
| If the content-coding of a representation in a request message is not |  | If the content-coding of a representation in a request message is not |
| acceptable to the origin server, the server SHOULD respond with a |  | acceptable to the origin server, the server SHOULD respond with a |
| status code of 415 (Unsupported Media Type). |  | status code of 415 (Unsupported Media Type). |
| skipping to change at page 24, line 37 |  | skipping to change at page 24, line 30 |
| 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 |
| SHOULD be considered the current representation of that resource. |  | SHOULD be considered the current representation of that resource. |
| For a GET or HEAD request, this is the same as the default semantics |  | For a GET or HEAD request, this is the same as the default semantics |
| when no Content-Location is provided by the server. For a state- |  | when no Content-Location is provided by the server. For a state- |
| changing method like PUT or POST, it implies that the server's |  | changing request like PUT or POST, it implies that the server's |
| response contains the new representation of that resource, thereby |  | response contains the new representation of that resource, thereby |
| distinguishing it from representations that might only report about |  | distinguishing it from representations that might only report about |
| the action (e.g., "It worked!"). This allows authoring applications |  | the action (e.g., "It worked!"). This allows authoring applications |
| to update their local copies without the need for a subsequent GET |  | to update their local copies without the need for a subsequent GET |
| request. |  | request. |
| If Content-Location is included in a response message and its value |  | If Content-Location is included in a response message and its value |
| differs from the effective request URI, then the origin server is |  | differs from the effective request URI, then the origin server is |
| informing recipients that this representation has its own, presumably |  | informing recipients that this representation has its own, presumably |
| more specific, identifier. For a GET or HEAD request, this is an |  | more specific, identifier. For a GET or HEAD request, this is an |
| indication that the effective request URI identifies a resource that |  | indication that the effective request URI identifies a resource that |
| is subject to content negotiation and the representation selected for |  | is subject to content negotiation and the representation selected for |
| this response can also be found at the identified URI. For other |  | this response can also be found at the identified URI. For other |
| methods, such a Content-Location indicates that this representation |  | methods, such a Content-Location indicates that this representation |
| contains a report on the action's status and the same report is |  | contains a report on the action's status and the same report is |
| available (for future access with GET) at the given URI. For |  | available (for future access with GET) at the given URI. For |
| example, a purchase transaction made via the POST method might |  | example, a purchase transaction made via a POST request might include |
| include a receipt document as the payload of the 200 response; the |  | a receipt document as the payload of the 200 response; the Content- |
| Content-Location value provides an identifier for retrieving a copy |  | Location value provides an identifier for retrieving a copy of that |
| of that same receipt in the future. |  | same receipt in the future. |
| If Content-Location is included in a request message, then it MAY be |  | If Content-Location is included in a request message, then it MAY be |
| interpreted by the origin server as an indication of where the user |  | interpreted by the origin server as an indication of where the user |
| agent originally obtained the content of the enclosed representation |  | agent originally obtained the content of the enclosed representation |
| (prior to any subsequent modification of the content by that user |  | (prior to any subsequent modification of the content by that user |
| agent). In other words, the user agent is providing the same |  | agent). In other words, the user agent is providing the same |
| representation metadata that it received with the original |  | representation metadata that it received with the original |
| representation. However, such interpretation MUST NOT be used to |  | representation. However, such interpretation MUST NOT be used to |
| alter the semantics of the method requested by the client. For |  | alter the semantics of the method requested by the client. For |
| example, if a client makes a PUT request on a negotiated resource and |  | example, if a client makes a PUT request on a negotiated resource and |
| skipping to change at page 26, line 8 |  | skipping to change at page 25, line 48 |
| transfer-coding is decoded). Note that a MIC is good for detecting |  | transfer-coding is decoded). Note that a MIC is good for detecting |
| accidental modification of the payload body in transit, but is not |  | accidental modification of the payload body in transit, but is not |
| proof against malicious attacks. |  | 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 payload body. Only |  | client to function as an integrity check of the payload body. Only |
| origin servers or user agents MAY generate the Content-MD5 header |  | origin servers or user agents MAY generate the Content-MD5 header |
| field; proxies and gateways MUST NOT generate it, as this would |  | field; proxies MUST NOT generate it, as this would defeat its value |
| defeat its value as an end-to-end integrity check. Any recipient MAY |  | as an end-to-end integrity check. Any recipient MAY check that the |
| check that the digest value in this header field matches a |  | digest value in this header field matches a corresponding digest |
| corresponding digest calculated on payload body as received. |  | calculated on payload body as received. |
| The MD5 digest is computed based on the content of the payload body, |  | The MD5 digest is computed based on the content of the payload body, |
| including any content-coding, but not including any transfer-coding |  | including any content-coding, but not including any transfer-coding |
| applied to the message-body because such transfer-codings might be |  | applied to the message-body because such transfer-codings might be |
| applied or removed anywhere along the request/response chain. If the |  | applied or removed anywhere along the request/response chain. If the |
| message is received with a transfer-coding, that encoding MUST be |  | message is received with a transfer-coding, that encoding MUST be |
| decoded prior to checking the Content-MD5 value against the received |  | decoded prior to checking the Content-MD5 value against the received |
| payload. |  | payload. |
| HTTP extends RFC 1864 to permit the digest to be computed for MIME |  | HTTP extends RFC 1864 to permit the digest to be computed for MIME |
| skipping to change at page 28, line 32 |  | skipping to change at page 28, line 30 |
| 8. Security Considerations |  | 8. Security Considerations |
| This section is meant to inform application developers, information |  | This section is meant to inform application developers, information |
| providers, and users of the security limitations in HTTP/1.1 as |  | providers, and users of the security limitations in HTTP/1.1 as |
| described by this document. The discussion does not include |  | described by this document. The discussion does not include |
| definitive solutions to the problems revealed, though it does make |  | definitive solutions to the problems revealed, though it does make |
| some suggestions for reducing security risks. |  | some suggestions for reducing security risks. |
| 8.1. Privacy Issues Connected to Accept Header Fields |  | 8.1. Privacy Issues Connected to Accept Header Fields |
| Accept request-headers fields can reveal information about the user |  | Accept headers fields can reveal information about the user to all |
| to all servers which are accessed. The Accept-Language header field |  | servers which are accessed. The Accept-Language header field in |
| in particular can reveal information the user would consider to be of |  | particular can reveal information the user would consider to be of a |
| a private nature, because the understanding of particular languages |  | private nature, because the understanding of particular languages is |
| is often strongly correlated to the membership of a particular ethnic |  | often strongly correlated to the membership of a particular ethnic |
| group. User agents which offer the option to configure the contents |  | group. User agents which offer the option to configure the contents |
| of an Accept-Language header field to be sent in every request are |  | of an Accept-Language header field to be sent in every request are |
| strongly encouraged to let the configuration process include a |  | strongly encouraged to let the configuration process include a |
| message which makes the user aware of the loss of privacy involved. |  | message which makes the user aware of the loss of privacy involved. |
| An approach that limits the loss of privacy would be for a user agent |  | An approach that limits the loss of privacy would be for a user agent |
| to omit the sending of Accept-Language header fields by default, and |  | to omit the sending of Accept-Language header fields by default, and |
| to ask the user whether or not to start sending Accept-Language |  | to ask the user whether or not to start sending Accept-Language |
| header fields to a server if it detects, by looking for any Vary |  | header fields to a server if it detects, by looking for any Vary |
| response-header fields generated by the server, that such sending |  | header fields generated by the server, that such sending could |
| could improve the quality of service. |  | improve the quality of service. |
| Elaborate user-customized accept header fields sent in every request, |  | Elaborate user-customized accept header fields sent in every request, |
| in particular if these include quality values, can be used by servers |  | in particular if these include quality values, can be used by servers |
| as relatively reliable and long-lived user identifiers. Such user |  | as relatively reliable and long-lived user identifiers. Such user |
| identifiers would allow content providers to do click-trail tracking, |  | identifiers would allow content providers to do click-trail tracking, |
| and would allow collaborating content providers to match cross-server |  | and would allow collaborating content providers to match cross-server |
| click-trails or form submissions of individual users. Note that for |  | click-trails or form submissions of individual users. Note that for |
| many users not behind a proxy, the network address of the host |  | many users not behind a proxy, the network address of the host |
| running the user agent will also serve as a long-lived user |  | running the user agent will also serve as a long-lived user |
| identifier. In environments where proxies are used to enhance |  | identifier. In environments where proxies are used to enhance |
| skipping to change at page 29, line 32 |  | skipping to change at page 29, line 29 |
| [ISO-8859-1] International Organization for Standardization, |  | [ISO-8859-1] International Organization for Standardization, |
| "Information technology -- 8-bit single-byte coded |  | "Information technology -- 8-bit single-byte coded |
| graphic character sets -- Part 1: Latin alphabet No. |  | graphic character sets -- Part 1: Latin alphabet No. |
| 1", ISO/IEC 8859-1:1998, 1998. |  | 1", ISO/IEC 8859-1:1998, 1998. |
| [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., |
| Ed., and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, |  | Ed., and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, |
| Connections, and Message Parsing", |  | Connections, and Message Parsing", |
| draft-ietf-httpbis-p1-messaging-12 (work in progress), |  | draft-ietf-httpbis-p1-messaging-13 (work in progress), |
| October 2010. |  | March 2011. |
| [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., |
| Ed., and J. Reschke, Ed., "HTTP/1.1, part 2: Message |  | Ed., and J. Reschke, Ed., "HTTP/1.1, part 2: Message |
| Semantics", draft-ietf-httpbis-p2-semantics-12 (work in |  | Semantics", draft-ietf-httpbis-p2-semantics-13 (work in |
| progress), October 2010. |  | progress), March 2011. |
| [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., |
| Ed., and J. Reschke, Ed., "HTTP/1.1, part 4: |  | Ed., and J. Reschke, Ed., "HTTP/1.1, part 4: |
| Conditional Requests", |  | Conditional Requests", |
| draft-ietf-httpbis-p4-conditional-12 (work in |  | draft-ietf-httpbis-p4-conditional-13 (work in |
| progress), October 2010. |  | progress), March 2011. |
| [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., |
| Ed., and J. Reschke, Ed., "HTTP/1.1, part 5: Range |  | Ed., and J. Reschke, Ed., "HTTP/1.1, part 5: Range |
| Requests and Partial Responses", |  | Requests and Partial Responses", |
| draft-ietf-httpbis-p5-range-12 (work in progress), |  | draft-ietf-httpbis-p5-range-13 (work in progress), |
| October 2010. |  | March 2011. |
| [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., |
| Ed., Nottingham, M., Ed., and J. Reschke, Ed., |  | Ed., Nottingham, M., Ed., and J. Reschke, Ed., |
| "HTTP/1.1, part 6: Caching", |  | "HTTP/1.1, part 6: Caching", |
| draft-ietf-httpbis-p6-cache-12 (work in progress), |  | draft-ietf-httpbis-p6-cache-13 (work in progress), |
| October 2010. |  | March 2011. |
| [RFC1864] Myers, J. and M. Rose, "The Content-MD5 Header Field", |  | [RFC1864] Myers, J. and M. Rose, "The Content-MD5 Header Field", |
| RFC 1864, October 1995. |  | RFC 1864, October 1995. |
| [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data |  | [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data |
| Format Specification version 3.3", RFC 1950, May 1996. |  | Format Specification version 3.3", RFC 1950, May 1996. |
| RFC 1950 is an Informational RFC, thus it might be less |  | RFC 1950 is an Informational RFC, thus it might be less |
| stable than this specification. On the other hand, |  | stable than this specification. On the other hand, |
| this downward reference was present since the |  | this downward reference was present since the |
| skipping to change at page 33, line 8 |  | skipping to change at page 32, line 50 |
| This appendix describes specific areas where HTTP differs from MIME. |  | This appendix describes specific areas where HTTP differs from MIME. |
| Proxies and gateways to strict MIME environments SHOULD be aware of |  | Proxies and gateways to strict MIME environments SHOULD be aware of |
| these differences and provide the appropriate conversions where |  | these differences and provide the appropriate conversions where |
| necessary. Proxies and gateways from MIME environments to HTTP also |  | necessary. Proxies and gateways from MIME environments to HTTP also |
| need to be aware of the differences because some conversions might be |  | need to be aware of the differences because some conversions might be |
| required. |  | required. |
| A.1. MIME-Version |  | A.1. MIME-Version |
| HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages |  | HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages |
| MAY include a single MIME-Version general-header field to indicate |  | MAY include a single MIME-Version header field to indicate what |
| what version of the MIME protocol was used to construct the message. |  | version of the MIME protocol was used to construct the message. Use |
| 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 = "MIME-Version" ":" OWS MIME-Version-v |
| MIME-Version-v = 1*DIGIT "." 1*DIGIT |  | MIME-Version-v = 1*DIGIT "." 1*DIGIT |
| MIME version "1.0" is the default for use in HTTP/1.1. However, |  | MIME version "1.0" is the default for use in HTTP/1.1. However, |
| HTTP/1.1 message parsing and semantics are defined by this document |  | HTTP/1.1 message parsing and semantics are defined by this document |
| and not the MIME specification. |  | and not the MIME specification. |
| skipping to change at page 33, line 39 |  | skipping to change at page 33, line 32 |
| represent line breaks as CRLF and forbids the use of CR or LF outside |  | represent line breaks as CRLF and forbids the use of CR or LF outside |
| of line break sequences. HTTP allows CRLF, bare CR, and bare LF to |  | of line break sequences. HTTP allows CRLF, bare CR, and bare LF to |
| indicate a line break within text content when a message is |  | indicate a line break within text content when a message is |
| transmitted over HTTP. |  | transmitted over HTTP. |
| Where it is possible, a proxy or gateway from HTTP to a strict MIME |  | Where it is possible, a proxy or gateway from HTTP to a strict MIME |
| environment SHOULD translate all line breaks within the text media |  | environment SHOULD translate all line breaks within the text media |
| types described in Section 2.3.1 of this document to the RFC 2049 |  | types described in Section 2.3.1 of this document to the RFC 2049 |
| canonical form of CRLF. Note, however, that this might be |  | canonical form of CRLF. Note, however, that this might be |
| complicated by the presence of a Content-Encoding and by the fact |  | complicated by the presence of a Content-Encoding and by the fact |
| that HTTP allows the use of some character sets which do not use |  | that HTTP allows the use of some character encodings which do not use |
| octets 13 and 10 to represent CR and LF, as is the case for some |  | octets 13 and 10 to represent CR and LF, respectively, as is the case |
| multi-byte character sets. |  | for some multi-byte character encodings. |
| Conversion will break any cryptographic checksums applied to the |  | Conversion will break any cryptographic checksums applied to the |
| original content unless the original content is already in canonical |  | original content unless the original content is already in canonical |
| form. Therefore, the canonical form is recommended for any content |  | form. Therefore, the canonical form is recommended for any content |
| that uses such checksums in HTTP. |  | that uses such checksums in HTTP. |
| A.3. Conversion of Date Formats |  | A.3. Conversion of Date Formats |
| HTTP/1.1 uses a restricted set of date formats (Section 6.1 of |  | HTTP/1.1 uses a restricted set of date formats (Section 6.1 of |
| [Part1]) to simplify the process of date comparison. Proxies and |  | [Part1]) to simplify the process of date comparison. Proxies and |
| skipping to change at page 36, line 6 |  | skipping to change at page 35, line 50 |
| ] ) |  | ] ) |
| 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 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-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> |  |  |
| Last-Modified = <Last-Modified, defined in [Part4], Section 6.6> |  |  |
| MIME-Version = "MIME-Version:" OWS MIME-Version-v |  | MIME-Version = "MIME-Version:" OWS MIME-Version-v |
| MIME-Version-v = 1*DIGIT "." 1*DIGIT |  | MIME-Version-v = 1*DIGIT "." 1*DIGIT |
| OWS = <OWS, defined in [Part1], Section 1.2.2> |  | OWS = <OWS, defined in [Part1], Section 1.2.2> |
| absolute-URI = <absolute-URI, defined in [Part1], Section 2.6> |  | absolute-URI = <absolute-URI, defined in [Part1], Section 2.6> |
| accept-ext = OWS ";" OWS token [ "=" 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 |
| skipping to change at page 37, line 4 |  | skipping to change at page 36, line 41 |
| partial-URI = <partial-URI, defined in [Part1], Section 2.6> |  | partial-URI = <partial-URI, defined in [Part1], Section 2.6> |
| 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-Length defined but not used |  |  |
| ; Content-Location defined but not used |  | ; Content-Location defined but not used |
| ; Content-MD5 defined but not used |  | ; Content-MD5 defined but not used |
| ; Content-Range defined but not used |  |  |
| ; Content-Type defined but not used |  | ; Content-Type defined but not used |
| ; Expires defined but not used |  |  |
| ; Last-Modified defined but not used |  |  |
| ; MIME-Version defined but not used |  | ; MIME-Version defined but not used |
| 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 20 |  | skipping to change at page 42, line 17 |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/178>: "Content-MD5 |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/178>: "Content-MD5 |
| and partial responses" |  | and partial responses" |
| E.13. Since draft-ietf-httpbis-p3-payload-11 |  | E.13. Since draft-ietf-httpbis-p3-payload-11 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/123>: "Factor out |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/123>: "Factor out |
| Content-Disposition" |  | Content-Disposition" |
|  |  | E.14. Since draft-ietf-httpbis-p3-payload-12 |
|  |  | Closed issues: |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/224>: "Header |
|  |  | Classification" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle |
|  |  | ABNFs for header fields" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/277>: "potentially |
|  |  | misleading MAY in media-type def" |
| Index |  | Index |
| A |  | A |
| Accept header 17 |  | Accept header field 16 |
| Accept-Charset header 19 |  | Accept-Charset header field 19 |
| Accept-Encoding header 20 |  | Accept-Encoding header field 19 |
| Accept-Language header 21 |  | Accept-Language header field 21 |
| C |  | C |
| Coding Format |  | Coding Format |
| compress 8 |  | compress 7 |
| deflate 8 |  | deflate 8 |
| gzip 8 |  | gzip 8 |
| identity 8 |  | identity 8 |
| compress (Coding Format) 8 |  | compress (Coding Format) 7 |
| content negotiation 5 |  | content negotiation 5 |
| Content-Encoding header 22 |  | Content-Encoding header field 22 |
| Content-Language header 23 |  | Content-Language header field 23 |
| Content-Location header 24 |  | Content-Location header field 24 |
| Content-MD5 header 25 |  | Content-MD5 header field 25 |
| Content-Type header 27 |  | Content-Type header field 26 |
| D |  | D |
| deflate (Coding Format) 8 |  | deflate (Coding Format) 8 |
| G |  | G |
| Grammar |  | Grammar |
| Accept 17 |  | Accept 17 |
| Accept-Charset 19 |  | Accept-Charset 19 |
| Accept-Charset-v 19 |  | Accept-Charset-v 19 |
| Accept-Encoding 20 |  | Accept-Encoding 20 |
| Accept-Encoding-v 20 |  | Accept-Encoding-v 20 |
| accept-ext 17 |  | accept-ext 17 |
| Accept-Language 21 |  | Accept-Language 21 |
| Accept-Language-v 21 |  | Accept-Language-v 21 |
| accept-params 17 |  | accept-params 17 |
| Accept-v 17 |  | Accept-v 17 |
| attribute 9 |  | attribute 9 |
| charset 7 |  | charset 6 |
| codings 20 |  | codings 20 |
| content-coding 8 |  | content-coding 7 |
| Content-Encoding 22 |  | Content-Encoding 22 |
| Content-Encoding-v 22 |  | Content-Encoding-v 22 |
| Content-Language 23 |  | Content-Language 23 |
| Content-Language-v 23 |  | Content-Language-v 23 |
| Content-Location 24 |  | Content-Location 24 |
| Content-Location-v 24 |  | Content-Location-v 24 |
| Content-MD5 25 |  | Content-MD5 25 |
| Content-MD5-v 25 |  | Content-MD5-v 25 |
| Content-Type 27 |  | Content-Type 26 |
| Content-Type-v 27 |  | Content-Type-v 26 |
| language-range 21 |  | language-range 21 |
| language-tag 11 |  | language-tag 11 |
| media-range 17 |  | media-range 17 |
| media-type 9 |  | media-type 9 |
| MIME-Version 33 |  | MIME-Version 33 |
| MIME-Version-v 33 |  | MIME-Version-v 33 |
| parameter 9 |  | parameter 9 |
| subtype 9 |  | subtype 9 |
| type 9 |  | type 9 |
| value 9 |  | value 9 |
| gzip (Coding Format) 8 |  | gzip (Coding Format) 8 |
| H |  | H |
| Headers |  | Header Fields |
| Accept 17 |  | Accept 16 |
| Accept-Charset 19 |  | Accept-Charset 19 |
| Accept-Encoding 20 |  | Accept-Encoding 19 |
| Accept-Language 21 |  | Accept-Language 21 |
| Content-Encoding 22 |  | Content-Encoding 22 |
| Content-Language 23 |  | Content-Language 23 |
| Content-Location 24 |  | Content-Location 24 |
| Content-MD5 25 |  | Content-MD5 25 |
| Content-Type 27 |  | Content-Type 26 |
| MIME-Version 33 |  | MIME-Version 32 |
| I |  | I |
| identity (Coding Format) 8 |  | identity (Coding Format) 8 |
| M |  | M |
| MIME-Version header 33 |  | MIME-Version header field 32 |
| P |  | P |
| payload 12 |  | payload 11 |
| R |  | R |
| representation 12 |  | representation 12 |
| Authors' Addresses |  | Authors' Addresses |
| Roy T. Fielding (editor) |  | Roy T. Fielding (editor) |
| Day Software |  | Adobe Systems Incorporated |
| 23 Corporate Plaza DR, Suite 280 |  | 345 Park Ave |
| Newport Beach, CA 92660 |  | San Jose, CA 95110 |
| USA |  | USA |
| Phone: +1-949-706-5300 |  |  |
| Fax: +1-949-706-5305 |  |  |
| EMail: fielding@gbiv.com |  | EMail: fielding@gbiv.com |
| URI: http://roy.gbiv.com/ |  | URI: http://roy.gbiv.com/ |
| Jim Gettys |  | Jim Gettys |
| Alcatel-Lucent Bell Labs |  | Alcatel-Lucent Bell Labs |
| 21 Oak Knoll Road |  | 21 Oak Knoll Road |
| Carlisle, MA 01741 |  | Carlisle, MA 01741 |
| USA |  | USA |
| EMail: jg@freedesktop.org |  | EMail: jg@freedesktop.org |
| skipping to change at page 44, line 41 |  | skipping to change at page 45, line 4 |
| URI: http://gettys.wordpress.com/ |  | URI: http://gettys.wordpress.com/ |
| Jeffrey C. Mogul |  | Jeffrey C. Mogul |
| Hewlett-Packard Company |  | Hewlett-Packard Company |
| HP Labs, Large Scale Systems Group |  | HP Labs, Large Scale Systems Group |
| 1501 Page Mill Road, MS 1177 |  | 1501 Page Mill Road, MS 1177 |
| Palo Alto, CA 94304 |  | Palo Alto, CA 94304 |
| USA |  | USA |
| EMail: JeffMogul@acm.org |  | EMail: JeffMogul@acm.org |
| Henrik Frystyk Nielsen |  | Henrik Frystyk Nielsen |
| Microsoft Corporation |  | Microsoft Corporation |
| 1 Microsoft Way |  | 1 Microsoft Way |
| Redmond, WA 98052 |  | Redmond, WA 98052 |
| USA |  | USA |
| EMail: henrikn@microsoft.com |  | EMail: henrikn@microsoft.com |
| Larry Masinter |  | Larry Masinter |
| Adobe Systems, Incorporated |  | Adobe Systems Incorporated |
| 345 Park Ave |  | 345 Park Ave |
| San Jose, CA 95110 |  | San Jose, CA 95110 |
| USA |  | USA |
| EMail: LMM@acm.org |  | EMail: LMM@acm.org |
| URI: http://larry.masinter.net/ |  | URI: http://larry.masinter.net/ |
| Paul J. Leach |  | Paul J. Leach |
| Microsoft Corporation |  | Microsoft Corporation |
| 1 Microsoft Way |  | 1 Microsoft Way |
End of changes. 75 change blocks.
| 178 lines changed or deleted |  | 164 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/