| draft-ietf-httpbis-p3-payload-18.txt |  | draft-ietf-httpbis-p3-payload-19.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) Y. Lafon, Ed. |
| Intended status: Standards Track Alcatel-Lucent |  | Intended status: Standards Track W3C |
| Expires: July 7, 2012 J. Mogul |  | Expires: September 13, 2012 J. Reschke, Ed. |
| HP |  |  |
| H. Frystyk |  |  |
| Microsoft |  |  |
| L. Masinter |  |  |
| Adobe |  |  |
| P. Leach |  |  |
| Microsoft |  |  |
| T. Berners-Lee |  |  |
| W3C/MIT |  |  |
| Y. Lafon, Ed. |  |  |
| W3C |  |  |
| J. Reschke, Ed. |  |  |
| greenbytes |  | greenbytes |
| January 4, 2012 |  | March 12, 2012 |
| 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-18 |  | draft-ietf-httpbis-p3-payload-19 |
| Abstract |  | Abstract |
| The Hypertext Transfer Protocol (HTTP) is an application-level |  | The Hypertext Transfer Protocol (HTTP) is an application-level |
| protocol for distributed, collaborative, hypertext information |  | protocol for distributed, collaborative, hypertext 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. |  | "HTTP/1.1" and, taken together, obsoletes RFC 2616. |
| skipping to change at page 1, line 49 |  | skipping to change at page 1, line 37 |
| 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), which is archived at |  | group mailing list (ietf-http-wg@w3.org), which is archived at |
| <http://lists.w3.org/Archives/Public/ietf-http-wg/>. |  | <http://lists.w3.org/Archives/Public/ietf-http-wg/>. |
| The current issues list is at |  | The current issues list is at |
| <http://tools.ietf.org/wg/httpbis/trac/report/3> and related |  | <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.19. |  | The changes in this draft are summarized in Appendix E.20. |
| 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 July 7, 2012. |  | This Internet-Draft will expire on September 13, 2012. |
| Copyright Notice |  | Copyright Notice |
| Copyright (c) 2012 IETF Trust and the persons identified as the |  | Copyright (c) 2012 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 9 |  | skipping to change at page 2, line 46 |
| Table of Contents |  | Table of Contents |
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 |  | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 |
| 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 |  | 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 |
| 1.2. Conformance and Error Handling . . . . . . . . . . . . . . 5 |  | 1.2. Conformance and Error Handling . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 7 |
| 2.1. Character Encodings (charset) . . . . . . . . . . . . . . 6 |  | 2.1. Character Encodings (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 . . . . . . . . . . . . . . . . . . . 9 |  | 2.3.2. Multipart Types . . . . . . . . . . . . . . . . . . . 10 |
| 2.4. Language Tags . . . . . . . . . . . . . . . . . . . . . . 10 |  | 2.4. Language Tags . . . . . . . . . . . . . . . . . . . . . . 10 |
| 3. Payload . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 |  | 3. Payload . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 |
| 3.1. Payload Header Fields . . . . . . . . . . . . . . . . . . 11 |  | 3.1. Payload Header Fields . . . . . . . . . . . . . . . . . . 11 |
| 3.2. Payload Body . . . . . . . . . . . . . . . . . . . . . . . 11 |  | 3.2. Payload Body . . . . . . . . . . . . . . . . . . . . . . . 11 |
| 4. Representation . . . . . . . . . . . . . . . . . . . . . . . . 11 |  | 4. Representation . . . . . . . . . . . . . . . . . . . . . . . . 11 |
| 4.1. Representation Header Fields . . . . . . . . . . . . . . . 12 |  | 4.1. Representation Header Fields . . . . . . . . . . . . . . . 12 |
| 4.2. Representation Data . . . . . . . . . . . . . . . . . . . 12 |  | 4.2. Representation Data . . . . . . . . . . . . . . . . . . . 13 |
| 5. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 13 |  | 5. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 13 |
| 5.1. Server-driven Negotiation . . . . . . . . . . . . . . . . 14 |  | 5.1. Server-driven Negotiation . . . . . . . . . . . . . . . . 14 |
| 5.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . . 15 |  | 5.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . . 16 |
| 6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 16 |  | 6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 16 |
| 6.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . . 16 |  | 6.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . . 16 |
| 6.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . . 18 |  | 6.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . . 19 |
| 6.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 19 |  | 6.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 19 |
| 6.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 20 |  | 6.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 21 |
| 6.5. Content-Encoding . . . . . . . . . . . . . . . . . . . . . 21 |  | 6.5. Content-Encoding . . . . . . . . . . . . . . . . . . . . . 22 |
| 6.6. Content-Language . . . . . . . . . . . . . . . . . . . . . 22 |  | 6.6. Content-Language . . . . . . . . . . . . . . . . . . . . . 23 |
| 6.7. Content-Location . . . . . . . . . . . . . . . . . . . . . 23 |  | 6.7. Content-Location . . . . . . . . . . . . . . . . . . . . . 23 |
| 6.8. Content-Type . . . . . . . . . . . . . . . . . . . . . . . 25 |  | 6.8. Content-Type . . . . . . . . . . . . . . . . . . . . . . . 25 |
| 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 |  | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 |
| 7.1. Header Field Registration . . . . . . . . . . . . . . . . 25 |  | 7.1. Header Field Registration . . . . . . . . . . . . . . . . 25 |
| 7.2. Content Coding Registry . . . . . . . . . . . . . . . . . 25 |  | 7.2. Content Coding Registry . . . . . . . . . . . . . . . . . 26 |
| 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 |  | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 |
| 8.1. Privacy Issues Connected to Accept Header Fields . . . . . 26 |  | 8.1. Privacy Issues Connected to Accept Header Fields . . . . . 27 |
| 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 |  | 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 |
| 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 |  | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 |
| 10.1. Normative References . . . . . . . . . . . . . . . . . . . 27 |  | 10.1. Normative References . . . . . . . . . . . . . . . . . . . 27 |
| 10.2. Informative References . . . . . . . . . . . . . . . . . . 28 |  | 10.2. Informative References . . . . . . . . . . . . . . . . . . 29 |
| Appendix A. Differences between HTTP and MIME . . . . . . . . . . 29 |  | Appendix A. Differences between HTTP and MIME . . . . . . . . . . 30 |
| A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 30 |  | A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 30 |
| A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 30 |  | A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 31 |
| A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 31 |  | A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 31 |
| A.4. Introduction of Content-Encoding . . . . . . . . . . . . . 31 |  | A.4. Introduction of Content-Encoding . . . . . . . . . . . . . 31 |
| A.5. No Content-Transfer-Encoding . . . . . . . . . . . . . . . 31 |  | A.5. No Content-Transfer-Encoding . . . . . . . . . . . . . . . 32 |
| A.6. Introduction of Transfer-Encoding . . . . . . . . . . . . 32 |  | A.6. Introduction of Transfer-Encoding . . . . . . . . . . . . 32 |
| A.7. MHTML and Line Length Limitations . . . . . . . . . . . . 32 |  | A.7. MHTML and Line Length Limitations . . . . . . . . . . . . 32 |
| Appendix B. Additional Features . . . . . . . . . . . . . . . . . 32 |  | Appendix B. Additional Features . . . . . . . . . . . . . . . . . 32 |
| Appendix C. Changes from RFC 2616 . . . . . . . . . . . . . . . . 32 |  | Appendix C. Changes from RFC 2616 . . . . . . . . . . . . . . . . 33 |
| Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 33 |  | Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 33 |
| Appendix E. Change Log (to be removed by RFC Editor before |  | Appendix E. Change Log (to be removed by RFC Editor before |
| publication) . . . . . . . . . . . . . . . . . . . . 34 |  | publication) . . . . . . . . . . . . . . . . . . . . 35 |
| E.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 34 |  | E.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 35 |
| E.2. Since draft-ietf-httpbis-p3-payload-00 . . . . . . . . . . 34 |  | E.2. Since draft-ietf-httpbis-p3-payload-00 . . . . . . . . . . 35 |
| E.3. Since draft-ietf-httpbis-p3-payload-01 . . . . . . . . . . 35 |  | E.3. Since draft-ietf-httpbis-p3-payload-01 . . . . . . . . . . 36 |
| E.4. Since draft-ietf-httpbis-p3-payload-02 . . . . . . . . . . 35 |  | E.4. Since draft-ietf-httpbis-p3-payload-02 . . . . . . . . . . 36 |
| E.5. Since draft-ietf-httpbis-p3-payload-03 . . . . . . . . . . 36 |  | E.5. Since draft-ietf-httpbis-p3-payload-03 . . . . . . . . . . 36 |
| E.6. Since draft-ietf-httpbis-p3-payload-04 . . . . . . . . . . 36 |  | E.6. Since draft-ietf-httpbis-p3-payload-04 . . . . . . . . . . 37 |
| E.7. Since draft-ietf-httpbis-p3-payload-05 . . . . . . . . . . 36 |  | E.7. Since draft-ietf-httpbis-p3-payload-05 . . . . . . . . . . 37 |
| E.8. Since draft-ietf-httpbis-p3-payload-06 . . . . . . . . . . 37 |  | E.8. Since draft-ietf-httpbis-p3-payload-06 . . . . . . . . . . 37 |
| E.9. Since draft-ietf-httpbis-p3-payload-07 . . . . . . . . . . 37 |  | E.9. Since draft-ietf-httpbis-p3-payload-07 . . . . . . . . . . 38 |
| E.10. Since draft-ietf-httpbis-p3-payload-08 . . . . . . . . . . 38 |  | E.10. Since draft-ietf-httpbis-p3-payload-08 . . . . . . . . . . 38 |
| E.11. Since draft-ietf-httpbis-p3-payload-09 . . . . . . . . . . 38 |  | E.11. Since draft-ietf-httpbis-p3-payload-09 . . . . . . . . . . 39 |
| E.12. Since draft-ietf-httpbis-p3-payload-10 . . . . . . . . . . 38 |  | E.12. Since draft-ietf-httpbis-p3-payload-10 . . . . . . . . . . 39 |
| E.13. Since draft-ietf-httpbis-p3-payload-11 . . . . . . . . . . 39 |  | E.13. Since draft-ietf-httpbis-p3-payload-11 . . . . . . . . . . 40 |
| E.14. Since draft-ietf-httpbis-p3-payload-12 . . . . . . . . . . 39 |  | E.14. Since draft-ietf-httpbis-p3-payload-12 . . . . . . . . . . 40 |
| E.15. Since draft-ietf-httpbis-p3-payload-13 . . . . . . . . . . 39 |  | E.15. Since draft-ietf-httpbis-p3-payload-13 . . . . . . . . . . 40 |
| E.16. Since draft-ietf-httpbis-p3-payload-14 . . . . . . . . . . 40 |  | E.16. Since draft-ietf-httpbis-p3-payload-14 . . . . . . . . . . 40 |
| E.17. Since draft-ietf-httpbis-p3-payload-15 . . . . . . . . . . 40 |  | E.17. Since draft-ietf-httpbis-p3-payload-15 . . . . . . . . . . 41 |
| E.18. Since draft-ietf-httpbis-p3-payload-16 . . . . . . . . . . 40 |  | E.18. Since draft-ietf-httpbis-p3-payload-16 . . . . . . . . . . 41 |
| E.19. Since draft-ietf-httpbis-p3-payload-17 . . . . . . . . . . 40 |  | E.19. Since draft-ietf-httpbis-p3-payload-17 . . . . . . . . . . 41 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 |  | E.20. Since draft-ietf-httpbis-p3-payload-18 . . . . . . . . . . 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 5, line 35 |  | skipping to change at page 5, line 35 |
| This specification uses a number of terms to refer to the roles |  | This specification uses a number of terms to refer to the roles |
| played by participants in, and objects of, the HTTP communication. |  | played by participants in, and objects of, the HTTP communication. |
| content negotiation |  | content negotiation |
| The mechanism for selecting the appropriate representation when |  | The mechanism for selecting the appropriate representation when |
| servicing a request. The representation in any response can be |  | servicing a request. The representation in any response can be |
| negotiated (including error responses). |  | negotiated (including error responses). |
|  |  | selected representation |
|  |  | The current representation of the target resource that would have |
|  |  | been selected in a successful response if the same request had |
|  |  | used the method GET and excluded any conditional request header |
|  |  | fields. |
| 1.2. Conformance and Error Handling |  | 1.2. Conformance and Error Handling |
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |  | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |  | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |
| document are to be interpreted as described in [RFC2119]. |  | document are to be interpreted as described in [RFC2119]. |
| This document defines conformance criteria for several roles in HTTP |  | This document defines conformance criteria for several roles in HTTP |
| communication, including Senders, Recipients, Clients, Servers, User- |  | communication, including Senders, Recipients, Clients, Servers, User- |
| Agents, Origin Servers, Intermediaries, Proxies and Gateways. See |  | Agents, Origin Servers, Intermediaries, Proxies and Gateways. See |
| Section 2 of [Part1] for definitions of these terms. |  | Section 2 of [Part1] for definitions of these terms. |
| skipping to change at page 6, line 18 |  | skipping to change at page 6, line 26 |
| define specific error handling mechanisms, except in cases where it |  | define specific error handling mechanisms, except in cases where it |
| has direct impact on security. This is because different uses of the |  | has direct impact on security. This is because different uses of the |
| protocol require different error handling strategies; for example, a |  | protocol require different error handling strategies; for example, a |
| Web browser may wish to transparently recover from a response where |  | Web browser may wish to transparently recover from a response where |
| the Location header field doesn't parse according to the ABNF, |  | the Location header field doesn't parse according to the ABNF, |
| whereby in a systems control protocol using HTTP, this type of error |  | whereby in a systems control protocol using HTTP, this type of error |
| recovery could lead to dangerous consequences. |  | recovery could lead to dangerous consequences. |
| 1.3. Syntax Notation |  | 1.3. Syntax Notation |
| This specification uses the ABNF syntax defined in Section 1.2 of |  | This specification uses the Augmented Backus-Naur Form (ABNF) |
| [Part1] (which extends the syntax defined in [RFC5234] with a list |  | notation of [RFC5234] with the list rule extension defined in Section |
| rule). Appendix D shows the collected ABNF, with the list rule |  | 1.2 of [Part1]. Appendix D shows the collected ABNF with the list |
| expanded. |  | rule expanded. |
| The following core rules are included by reference, as defined in |  | The following core rules are included by reference, as defined in |
| [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF |  | [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF |
| (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), |  | (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), |
| HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit |  | HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit |
| sequence of data), SP (space), and VCHAR (any visible US-ASCII |  | sequence of data), SP (space), and VCHAR (any visible US-ASCII |
| character). |  | character). |
| 1.3.1. Core Rules |  | 1.3.1. Core Rules |
| The core rules below are defined in [Part1]: |  | The core rules below are defined in [Part1]: |
| OWS = <OWS, defined in [Part1], Section 1.2.2> |  | OWS = <OWS, defined in [Part1], Section 3.2.1> |
| token = <token, defined in [Part1], Section 3.2.3> |  | token = <token, defined in [Part1], Section 3.2.4> |
| word = <word, defined in [Part1], Section 3.2.3> |  | word = <word, defined in [Part1], Section 3.2.4> |
| 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.7> |  | absolute-URI = <absolute-URI, defined in [Part1], Section 2.7> |
| partial-URI = <partial-URI, defined in [Part1], Section 2.7> |  | partial-URI = <partial-URI, defined in [Part1], Section 2.7> |
| qvalue = <qvalue, defined in [Part1], Section 5.3> |  | qvalue = <qvalue, defined in [Part1], Section 4.3.1> |
| 2. Protocol Parameters |  | 2. Protocol Parameters |
| 2.1. Character Encodings (charset) |  | 2.1. Character Encodings (charset) |
| HTTP uses charset names to indicate the character encoding of a |  | HTTP uses charset names to indicate the character encoding of a |
| textual representation. |  | textual representation. |
| A character encoding is identified by a case-insensitive token. 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 |
| skipping to change at page 7, line 46 |  | skipping to change at page 8, line 4 |
| content-coding = token |  | content-coding = token |
| All content-coding values are case-insensitive. HTTP/1.1 uses |  | All content-coding values are case-insensitive. HTTP/1.1 uses |
| content-coding values in the Accept-Encoding (Section 6.3) and |  | content-coding values in the Accept-Encoding (Section 6.3) and |
| Content-Encoding (Section 6.5) header fields. Although the value |  | Content-Encoding (Section 6.5) header fields. Although the value |
| describes the content-coding, what is more important is that it |  | describes the content-coding, what is more important is that it |
| indicates what decoding mechanism will be required to remove the |  | indicates what decoding mechanism will be required to remove the |
| encoding. |  | encoding. |
| compress |  | compress |
|  |  | See Section 4.2.1 of [Part1]. |
| See Section 5.1.2.1 of [Part1]. |  |  |
| deflate |  | deflate |
| See Section 5.1.2.2 of [Part1]. |  | See Section 4.2.2 of [Part1]. |
| gzip |  | gzip |
| See Section 5.1.2.3 of [Part1]. |  | See Section 4.2.3 of [Part1]. |
| 2.2.1. Content Coding Registry |  | 2.2.1. Content Coding Registry |
| The HTTP Content Coding Registry defines the name space for the |  | The HTTP Content Coding Registry defines the name space for the |
| content coding names. |  | content coding names. |
| Registrations MUST include the following fields: |  | Registrations MUST include the following fields: |
| o Name |  | o Name |
| o Description |  | o Description |
| o Pointer to specification text |  | o Pointer to specification text |
| Names of content codings MUST NOT overlap with names of transfer |  | Names of content codings MUST NOT overlap with names of transfer |
| codings (Section 5.1 of [Part1]), unless the encoding transformation |  | codings (Section 4 of [Part1]), unless the encoding transformation is |
| is identical (as it is the case for the compression codings defined |  | identical (as is the case for the compression codings defined in |
| in Section 5.1.2 of [Part1]). |  | Section 4.2 of [Part1]). |
| Values to be added to this name space require a specification (see |  | Values to be added to this name space require IETF Review (see |
| "Specification Required" in Section 4.1 of [RFC5226]), and MUST |  | Section 4.1 of [RFC5226]), and MUST conform to the purpose of content |
| conform to the purpose of content coding defined in this section. |  | coding defined in this section. |
| The registry itself is maintained at |  | The registry itself is maintained at |
| <http://www.iana.org/assignments/http-parameters>. |  | <http://www.iana.org/assignments/http-parameters>. |
| 2.3. Media Types |  | 2.3. Media Types |
| HTTP uses Internet Media Types [RFC2046] in the Content-Type |  | HTTP uses Internet Media Types [RFC2046] in the Content-Type |
| (Section 6.8) 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. |
| skipping to change at page 9, line 50 |  | skipping to change at page 10, line 8 |
| 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. |
| 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 |
| any other media type: strictly as payload. HTTP does not use the |  | any other media type: strictly as payload. HTTP does not use the |
| multipart boundary as an indicator of message-body length. In all |  | multipart boundary as an indicator of message body length. In all |
| other respects, an HTTP user agent SHOULD follow the same or similar |  | other respects, an HTTP user agent SHOULD follow the same or similar |
| behavior as a MIME user agent would upon receipt of a multipart type. |  | behavior as a MIME user agent would upon receipt of a multipart type. |
| The MIME header fields within each body-part of a multipart message- |  | The MIME header fields within each body-part of a multipart message |
| body do not have any significance to HTTP beyond that defined by |  | body do not have any significance to HTTP beyond that defined by |
| their MIME semantics. |  | their MIME semantics. |
| If an application receives an unrecognized multipart subtype, the |  | If an application receives an unrecognized multipart subtype, the |
| application MUST treat it as being equivalent to "multipart/mixed". |  | application MUST treat it as being equivalent to "multipart/mixed". |
| Note: The "multipart/form-data" type has been specifically defined |  | Note: The "multipart/form-data" type has been specifically defined |
| for carrying form data suitable for processing via the POST |  | for carrying form data suitable for processing via the POST |
| request method, as described in [RFC2388]. |  | request method, as described in [RFC2388]. |
| skipping to change at page 11, line 10 |  | skipping to change at page 11, line 12 |
| en, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN |  | en, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN |
| See [RFC5646] for further information. |  | See [RFC5646] for further information. |
| 3. Payload |  | 3. Payload |
| HTTP messages MAY transfer a payload if not otherwise restricted by |  | HTTP messages MAY transfer a payload if not otherwise restricted by |
| the request method or response status code. The payload consists of |  | the request method or response status code. The payload consists of |
| metadata, in the form of header fields, and data, in the form of the |  | metadata, in the form of header fields, and data, in the form of the |
| sequence of octets in the message-body after any transfer-coding has |  | sequence of octets in the message body after any transfer-coding has |
| been decoded. |  | been decoded. |
| A "payload" in HTTP is always a partial or complete representation of |  | A "payload" in HTTP is always a partial or complete representation of |
| some resource. We use separate terms for payload and representation |  | some resource. We use separate terms for payload and representation |
| because some messages contain only the associated representation's |  | because some messages contain only the associated representation's |
| 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: |
| +-------------------+------------------------+ |  | +-------------------+--------------------------+ |
| | Header Field Name | Defined in... | |  | | Header Field Name | Defined in... | |
| +-------------------+------------------------+ |  | +-------------------+--------------------------+ |
| | Content-Length | Section 8.2 of [Part1] | |  | | Content-Length | Section 3.3.2 of [Part1] | |
| | 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. |
| 4. Representation |  | 4. Representation |
| A "representation" is information in a format that can be readily |  | A "representation" is information in a format that can be readily |
| communicated from one party to another. A resource representation is |  | communicated from one party to another. A resource representation is |
| information that reflects the state of that resource, as observed at |  | information that reflects the state of that resource, as observed at |
| some point in the past (e.g., in a response to GET) or to be desired |  | some point in the past (e.g., in a response to GET) or to be desired |
| at some point in the future (e.g., in a PUT request). |  | at some point in the future (e.g., in a PUT request). |
| skipping to change at page 12, line 18 |  | skipping to change at page 12, line 20 |
| contrast, contains either a representation that describes the |  | contrast, contains either a representation that describes the |
| successful action or a representation of the target resource, with |  | successful action or a representation of the target resource, with |
| the latter indicated by a Content-Location header field with the same |  | the latter indicated by a Content-Location header field with the same |
| value as the effective request URI. Likewise, response messages with |  | value as the effective request URI. Likewise, response messages with |
| an error status code usually contain a representation that describes |  | an error status code usually contain a representation that describes |
| the error and what next steps are suggested for resolving it. |  | the error and what next steps are suggested for resolving it. |
| 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: |
| +-------------------+------------------------+ |  | +-------------------+------------------------+ |
| | 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.8 | |  | | Content-Type | Section 6.8 | |
| | Expires | Section 3.3 of [Part6] | |  | | Expires | Section 3.3 of [Part6] | |
|  |  | +-------------------+------------------------+ |
|  |  | Additional header fields define metadata about the selected |
|  |  | representation, which might differ from the representation included |
|  |  | in the message for responses to some state-changing methods. The |
|  |  | following header fields are defined as selected representation |
|  |  | metadata: |
|  |  | +-------------------+------------------------+ |
|  |  | | Header Field Name | Defined in... | |
|  |  | +-------------------+------------------------+ |
|  |  | | ETag | Section 2.3 of [Part4] | |
| | Last-Modified | Section 2.2 of [Part4] | |  | | Last-Modified | Section 2.2 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 15, line 17 |  | skipping to change at page 15, line 32 |
| 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. |
| Server-driven negotiation allows the user agent to specify its |  | Server-driven negotiation allows the user agent to specify its |
| preferences, but it cannot expect responses to always honour them. |  | preferences, but it cannot expect responses to always honor them. |
| For example, the origin server might not implement server-driven |  | For example, the origin server might not implement server-driven |
| negotiation, or it might decide that sending a response that doesn't |  | negotiation, or it might decide that sending a response that doesn't |
| conform to them is better than sending a 406 (Not Acceptable) |  | conform to them is better than sending a 406 (Not Acceptable) |
| response. |  | response. |
| Many of the mechanisms for expressing preferences use quality values |  | Many of the mechanisms for expressing preferences use quality values |
| to declare relative preference. See Section 5.3 of [Part1] for more |  | to declare relative preference. See Section 4.3.1 of [Part1] for |
| information. |  | more information. |
| HTTP/1.1 includes the following header fields for enabling server- |  | HTTP/1.1 includes the following header fields for enabling server- |
| driven negotiation through description of user agent capabilities and |  | driven negotiation through description of user agent capabilities and |
| user preferences: Accept (Section 6.1), Accept-Charset (Section 6.2), |  | user preferences: Accept (Section 6.1), Accept-Charset (Section 6.2), |
| Accept-Encoding (Section 6.3), Accept-Language (Section 6.4), and |  | Accept-Encoding (Section 6.3), Accept-Language (Section 6.4), and |
| User-Agent (Section 9.10 of [Part2]). However, an origin server is |  | User-Agent (Section 10.10 of [Part2]). However, an origin server is |
| not limited to these dimensions and MAY vary the response based on |  | not limited to these dimensions and MAY vary the response based on |
| any aspect of the request, including aspects of the connection (e.g., |  | any aspect of the request, including aspects of the connection (e.g., |
| IP address) or information within extension header fields not defined |  | IP address) or information within extension header fields 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 |
| skipping to change at page 17, line 10 |  | skipping to change at page 17, line 26 |
| The asterisk "*" character is used to group media types into ranges, |  | The asterisk "*" character is used to group media types into ranges, |
| with "*/*" indicating all media types and "type/*" indicating all |  | with "*/*" indicating all media types and "type/*" indicating all |
| subtypes of that type. The media-range MAY include media type |  | subtypes of that type. The media-range MAY include media type |
| parameters that are applicable to that range. |  | parameters that are applicable to that range. |
| Each media-range MAY be followed by one or more accept-params, |  | Each media-range MAY be followed by one or more accept-params, |
| beginning with the "q" parameter for indicating a relative quality |  | beginning with the "q" parameter for indicating a relative quality |
| factor. The first "q" parameter (if any) separates the media-range |  | factor. The first "q" parameter (if any) separates the media-range |
| parameter(s) from the accept-params. Quality factors allow the user |  | parameter(s) from the accept-params. Quality factors allow the user |
| or user agent to indicate the relative degree of preference for that |  | or user agent to indicate the relative degree of preference for that |
| media-range, using the qvalue scale from 0 to 1 (Section 5.3 of |  | media-range, using the qvalue scale from 0 to 1 (Section 4.3.1 of |
| [Part1]). The default value is q=1. |  | [Part1]). The default value is q=1. |
| Note: Use of the "q" parameter name to separate media type |  | Note: Use of the "q" parameter name to separate media type |
| parameters from Accept extension parameters is due to historical |  | parameters from Accept extension parameters is due to historical |
| practice. Although this prevents any media type parameter named |  | practice. Although this prevents any media type parameter named |
| "q" from being used with a media range, such an event is believed |  | "q" from being used with a media range, such an event is believed |
| to be unlikely given the lack of any "q" parameters in the IANA |  | to be unlikely given the lack of any "q" parameters in the IANA |
| media type registry and the rare usage of any media type |  | media type registry and the rare usage of any media type |
| parameters in Accept. Future media types are discouraged from |  | parameters in Accept. Future media types are discouraged from |
| registering any parameter named "q". |  | registering any parameter named "q". |
| skipping to change at page 20, line 14 |  | skipping to change at page 20, line 30 |
| field. |  | field. |
| 2. If the representation has no content-coding, then it is |  | 2. If the representation has no content-coding, then it is |
| acceptable by default unless specifically excluded by the Accept- |  | acceptable by default unless specifically excluded by the Accept- |
| Encoding field stating either "identity;q=0" or "*;q=0" without a |  | Encoding field stating either "identity;q=0" or "*;q=0" without a |
| more specific entry for "identity". |  | more specific entry for "identity". |
| 3. If the representation's content-coding is one of the content- |  | 3. If the representation's content-coding is one of the content- |
| codings listed in the Accept-Encoding field, then it is |  | codings listed in the Accept-Encoding field, then it is |
| acceptable unless it is accompanied by a qvalue of 0. (As |  | acceptable unless it is accompanied by a qvalue of 0. (As |
| defined in Section 5.3 of [Part1], a qvalue of 0 means "not |  | defined in Section 4.3.1 of [Part1], a qvalue of 0 means "not |
| acceptable".) |  | acceptable".) |
| 4. If multiple content-codings are acceptable, then the acceptable |  | 4. If multiple content-codings are acceptable, then the acceptable |
| content-coding with the highest non-zero qvalue is preferred. |  | content-coding with the highest non-zero qvalue is preferred. |
| An Accept-Encoding header field with a combined field-value that is |  | An Accept-Encoding header field with a combined field-value that is |
| empty implies that the user agent does not want any content-coding in |  | empty implies that the user agent does not want any content-coding in |
| response. If an Accept-Encoding header field is present in a request |  | response. If an Accept-Encoding header field is present in a request |
| and none of the available representations for the response have a |  | and none of the available representations for the response have a |
| content-coding that is listed as acceptable, the origin server SHOULD |  | content-coding that is listed as acceptable, the origin server SHOULD |
| skipping to change at page 23, line 39 |  | skipping to change at page 24, line 6 |
| 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 = absolute-URI / partial-URI |  | Content-Location = 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 5.5 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 |
| SHOULD be considered the current representation of that resource. |  | SHOULD be considered a current representation of that resource. For |
| For a GET or HEAD request, this is the same as the default semantics |  | a GET or HEAD request, this is the same as the default semantics when |
| when no Content-Location is provided by the server. For a state- |  | no Content-Location is provided by the server. For a state-changing |
| changing request like PUT or POST, it implies that the server's |  | request like PUT or POST, it implies that the server's response |
| response contains the new representation of that resource, thereby |  | 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 selected representation 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 a POST request might include |  | example, a purchase transaction made via a POST request might include |
| a receipt document as the payload of the 200 response; the Content- |  | a receipt document as the payload of the 200 response; the Content- |
| Location value provides an identifier for retrieving a copy of that |  | Location value provides an identifier for retrieving a copy 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 |
| skipping to change at page 26, line 7 |  | skipping to change at page 26, line 31 |
| 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. |
| The HTTP Content Codings Registry located at |  | The HTTP Content Codings Registry located at |
| <http://www.iana.org/assignments/http-parameters> shall be updated |  | <http://www.iana.org/assignments/http-parameters> shall be updated |
| with the registration below: |  | with the registration below: |
| +----------+-----------------------------------------+--------------+ |  | +----------+------------------------------------------+-------------+ |
| | Name | Description | Reference | |  | | Name | Description | Reference | |
| +----------+-----------------------------------------+--------------+ |  | +----------+------------------------------------------+-------------+ |
| | compress | UNIX "compress" program method | Section | |  | | compress | UNIX "compress" program method | Section | |
| | | | 5.1.2.1 of | |  | | | | 4.2.1 of | |
| | | | [Part1] | |  | | | | [Part1] | |
| | deflate | "deflate" compression mechanism | Section | |  | | deflate | "deflate" compression mechanism | Section | |
| | | ([RFC1951]) used inside the "zlib" data | 5.1.2.2 of | |  | | | ([RFC1951]) used inside the "zlib" data | 4.2.2 of | |
| | | format ([RFC1950]) | [Part1] | |  | | | format ([RFC1950]) | [Part1] | |
| | gzip | Same as GNU zip [RFC1952] | Section | |  | | gzip | Same as GNU zip [RFC1952] | Section | |
| | | | 5.1.2.3 of | |  | | | | 4.2.3 of | |
| | | | [Part1] | |  | | | | [Part1] | |
| | identity | reserved (synonym for "no encoding" in | Section 6.3 | |  | | identity | reserved (synonym for "no encoding" in | Section 6.3 | |
| | | Accept-Encoding header field) | | |  | | | Accept-Encoding header field) | | |
| +----------+-----------------------------------------+--------------+ |  | +----------+------------------------------------------+-------------+ |
| 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 headers fields can reveal information about the user to all |  | Accept header fields can reveal information about the user to all |
| servers which are accessed. The Accept-Language header field in |  | servers which are accessed. The Accept-Language header field in |
| particular can reveal information the user would consider to be of a |  | particular can reveal information the user would consider to be of a |
| private nature, because the understanding of particular languages is |  | private nature, because the understanding of particular languages 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 |
| skipping to change at page 27, line 20 |  | skipping to change at page 27, line 43 |
| identifier. In environments where proxies are used to enhance |  | identifier. In environments where proxies are used to enhance |
| privacy, user agents ought to be conservative in offering accept |  | privacy, user agents ought to be conservative in offering accept |
| header configuration options to end users. As an extreme privacy |  | header configuration options to end users. As an extreme privacy |
| measure, proxies could filter the accept header fields in relayed |  | measure, proxies could filter the accept header fields in relayed |
| 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 |
| See Section 11 of [Part1]. |  | See Section 9 of [Part1]. |
| 10. References |  | 10. References |
| 10.1. Normative References |  | 10.1. Normative References |
| [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part1] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | "HTTP/1.1, part 1: URIs, Connections, and Message |
| and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, |  | Parsing", draft-ietf-httpbis-p1-messaging-19 (work in |
| and Message Parsing", draft-ietf-httpbis-p1-messaging-18 |  | progress), March 2012. |
| (work in progress), January 2012. |  |  |
| [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part2] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | "HTTP/1.1, part 2: Message Semantics", |
| and J. Reschke, Ed., "HTTP/1.1, part 2: Message |  | draft-ietf-httpbis-p2-semantics-19 (work in progress), |
| Semantics", draft-ietf-httpbis-p2-semantics-18 (work in |  | March 2012. |
| progress), January 2012. |  |  |
| [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part4] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | "HTTP/1.1, part 4: Conditional Requests", |
| and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional |  | draft-ietf-httpbis-p4-conditional-19 (work in progress), |
| Requests", draft-ietf-httpbis-p4-conditional-18 (work in |  | March 2012. |
| progress), January 2012. |  |  |
| [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | "HTTP/1.1, part 5: Range Requests and Partial Responses", |
| and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and |  | draft-ietf-httpbis-p5-range-19 (work in progress), |
| Partial Responses", draft-ietf-httpbis-p5-range-18 (work |  | March 2012. |
| in progress), January 2012. |  |  |
| [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part6] Fielding, R., Ed., Lafon, Y., Ed., Nottingham, M., Ed., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", |
| Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part |  | draft-ietf-httpbis-p6-cache-19 (work in progress), |
| 6: Caching", draft-ietf-httpbis-p6-cache-18 (work in |  | March 2012. |
| progress), January 2012. |  |  |
| [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format |  | [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format |
| Specification version 3.3", RFC 1950, May 1996. |  | Specification version 3.3", RFC 1950, May 1996. |
| [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification |  | [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification |
| version 1.3", RFC 1951, May 1996. |  | version 1.3", RFC 1951, May 1996. |
| [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G. |  | [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G. |
| Randers-Pehrson, "GZIP file format specification version |  | Randers-Pehrson, "GZIP file format specification version |
| 4.3", RFC 1952, May 1996. |  | 4.3", RFC 1952, May 1996. |
| skipping to change at page 30, line 4 |  | skipping to change at page 30, line 21 |
| RFC 6151, March 2011. |  | RFC 6151, March 2011. |
| [RFC6266] Reschke, J., "Use of the Content-Disposition Header Field |  | [RFC6266] Reschke, J., "Use of the Content-Disposition Header Field |
| in the Hypertext Transfer Protocol (HTTP)", RFC 6266, |  | in the Hypertext Transfer Protocol (HTTP)", RFC 6266, |
| June 2011. |  | June 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 |
| allow greater freedom in the use of new media types, to make date |  | allow greater freedom in the use of new media types, to make date |
| comparisons easier, and to acknowledge the practice of some early |  | comparisons easier, and to acknowledge the practice of some early |
| HTTP servers and clients. |  | HTTP servers and clients. |
| 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 |
| skipping to change at page 30, line 27 |  | skipping to change at page 30, line 43 |
| 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 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 conformance with the MIME protocol (as defined in [RFC2045]). |
| Proxies/gateways are responsible for ensuring full compliance (where |  | Proxies/gateways are responsible for ensuring full conformance (where |
| possible) when exporting HTTP messages to strict MIME environments. |  | possible) when exporting HTTP messages to strict MIME environments. |
| MIME-Version = 1*DIGIT "." 1*DIGIT |  | MIME-Version = 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 |
| skipping to change at page 32, line 7 |  | skipping to change at page 32, line 22 |
| Proxies and gateways from HTTP to MIME-compliant protocols are |  | Proxies and gateways from HTTP to MIME-compliant protocols are |
| responsible for ensuring that the message is in the correct format |  | responsible for ensuring that the message is in the correct format |
| and encoding for safe transport on that protocol, where "safe |  | and encoding for safe transport on that protocol, where "safe |
| transport" is defined by the limitations of the protocol being used. |  | transport" is defined by the limitations of the protocol being used. |
| Such a proxy or gateway SHOULD label the data with an appropriate |  | Such a proxy or gateway SHOULD label the data with an appropriate |
| Content-Transfer-Encoding if doing so will improve the likelihood of |  | Content-Transfer-Encoding if doing so will improve the likelihood of |
| safe transport over the destination protocol. |  | safe transport over the destination protocol. |
| A.6. Introduction of Transfer-Encoding |  | A.6. Introduction of Transfer-Encoding |
| HTTP/1.1 introduces the Transfer-Encoding header field (Section 8.6 |  | HTTP/1.1 introduces the Transfer-Encoding header field (Section 3.3.1 |
| of [Part1]). Proxies/gateways MUST remove any transfer-coding prior |  | of [Part1]). Proxies/gateways MUST remove any transfer-coding prior |
| to forwarding a message via a MIME-compliant protocol. |  | to forwarding a message via a MIME-compliant protocol. |
| A.7. MHTML and Line Length Limitations |  | A.7. MHTML and Line Length Limitations |
| HTTP implementations which share code with MHTML [RFC2557] |  | HTTP implementations which share code with MHTML [RFC2557] |
| implementations need to be aware of MIME line length limitations. |  | implementations need to be aware of MIME line length limitations. |
| Since HTTP does not have this limitation, HTTP does not fold long |  | Since HTTP does not have this limitation, HTTP does not fold long |
| lines. MHTML messages being transported by HTTP follow all |  | lines. MHTML messages being transported by HTTP follow all |
| conventions of MHTML, including line length limitations and folding, |  | conventions of MHTML, including line length limitations and folding, |
| skipping to change at page 32, line 41 |  | skipping to change at page 33, line 9 |
| 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 [RFC6266] |  | Title, from SMTP and MIME are also often implemented (see [RFC6266] |
| and [RFC2076]). |  | 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) |
|  |  | Registration of Content Codings now requires IETF Review |
|  |  | (Section 2.2.1) |
| Remove the default character encoding for text media types; the |  | Remove the default character encoding for text media types; the |
| default now is whatever the media type definition says. |  | default now is whatever the media type definition says. |
| (Section 2.3.1) |  | (Section 2.3.1) |
| Change ABNF productions for header fields to only define the field |  | Change ABNF productions for header fields to only define the field |
| value. (Section 6) |  | value. (Section 6) |
| Remove definition of Content-MD5 header field because it was |  | Remove definition of Content-MD5 header field because it was |
| inconsistently implemented with respect to partial responses, and |  | inconsistently implemented with respect to partial responses, and |
| also because of known deficiencies in the hash algorithm itself (see |  | also because of known deficiencies in the hash algorithm itself (see |
| skipping to change at page 33, line 4 |  | skipping to change at page 33, line 23 |
| default now is whatever the media type definition says. |  | default now is whatever the media type definition says. |
| (Section 2.3.1) |  | (Section 2.3.1) |
| Change ABNF productions for header fields to only define the field |  | Change ABNF productions for header fields to only define the field |
| value. (Section 6) |  | value. (Section 6) |
| Remove definition of Content-MD5 header field because it was |  | Remove definition of Content-MD5 header field because it was |
| inconsistently implemented with respect to partial responses, and |  | inconsistently implemented with respect to partial responses, and |
| also because of known deficiencies in the hash algorithm itself (see |  | also because of known deficiencies in the hash algorithm itself (see |
| [RFC6151] for details). (Section 6) |  | [RFC6151] for details). (Section 6) |
| Remove ISO-8859-1 special-casing in Accept-Charset. (Section 6.2) |  | 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 [RFC6266]. (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) |
|  |  | Remove discussion of Content-Disposition header field, it is now |
|  |  | defined by [RFC6266]. (Appendix B) |
| Appendix D. Collected ABNF |  | Appendix D. Collected ABNF |
| Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [ |  | Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [ |
| OWS media-range [ accept-params ] ] ) ] |  | OWS media-range [ accept-params ] ] ) ] |
| Accept-Charset = *( "," 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 = [ ( "," / ( codings [ OWS ";" OWS "q=" qvalue ] ) ) |  | Accept-Encoding = [ ( "," / ( 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 = *( "," OWS ) language-range [ OWS ";" OWS "q=" |
| skipping to change at page 33, line 33 |  | skipping to change at page 34, line 4 |
| qvalue ] *( OWS "," [ OWS ( charset / "*" ) [ OWS ";" OWS "q=" |  | qvalue ] *( OWS "," [ OWS ( charset / "*" ) [ OWS ";" OWS "q=" |
| qvalue ] ] ) |  | qvalue ] ] ) |
| Accept-Encoding = [ ( "," / ( codings [ OWS ";" OWS "q=" qvalue ] ) ) |  | Accept-Encoding = [ ( "," / ( 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 = *( "," OWS ) language-range [ OWS ";" OWS "q=" |
| qvalue ] *( OWS "," [ OWS language-range [ OWS ";" OWS "q=" qvalue ] |  | qvalue ] *( OWS "," [ OWS language-range [ OWS ";" OWS "q=" qvalue ] |
| ] ) |  | ] ) |
| Content-Encoding = *( "," OWS ) content-coding *( OWS "," [ OWS |  | Content-Encoding = *( "," OWS ) content-coding *( OWS "," [ OWS |
| content-coding ] ) |  | content-coding ] ) |
| Content-Language = *( "," OWS ) language-tag *( OWS "," [ OWS |  | Content-Language = *( "," OWS ) language-tag *( OWS "," [ OWS |
| language-tag ] ) |  | language-tag ] ) |
| Content-Location = absolute-URI / partial-URI |  | Content-Location = absolute-URI / partial-URI |
| Content-Type = media-type |  | Content-Type = media-type |
| MIME-Version = 1*DIGIT "." 1*DIGIT |  | MIME-Version = 1*DIGIT "." 1*DIGIT |
| OWS = <OWS, defined in [Part1], Section 1.2.2> |  | OWS = <OWS, defined in [Part1], Section 3.2.1> |
| absolute-URI = <absolute-URI, defined in [Part1], Section 2.7> |  | absolute-URI = <absolute-URI, defined in [Part1], Section 2.7> |
| 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 / "identity" / "*" |  | codings = content-coding / "identity" / "*" |
| content-coding = token |  | content-coding = token |
| language-range = <language-range, defined in [RFC4647], Section 2.1> |  | language-range = <language-range, defined in [RFC4647], Section 2.1> |
| language-tag = <Language-Tag, defined in [RFC5646], Section 2.1> |  | language-tag = <Language-Tag, defined in [RFC5646], Section 2.1> |
| media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS |  | media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS |
| ";" OWS parameter ) |  | ";" OWS parameter ) |
| media-type = type "/" subtype *( OWS ";" OWS parameter ) |  | media-type = type "/" subtype *( OWS ";" OWS parameter ) |
| parameter = attribute "=" value |  | parameter = attribute "=" value |
| partial-URI = <partial-URI, defined in [Part1], Section 2.7> |  | partial-URI = <partial-URI, defined in [Part1], Section 2.7> |
| qvalue = <qvalue, defined in [Part1], Section 5.3> |  | qvalue = <qvalue, defined in [Part1], Section 4.3.1> |
| subtype = token |  | subtype = token |
| token = <token, defined in [Part1], Section 3.2.3> |  | token = <token, defined in [Part1], Section 3.2.4> |
| type = token |  | type = token |
| value = word |  | value = word |
| word = <word, defined in [Part1], Section 3.2.3> |  | word = <word, defined in [Part1], Section 3.2.4> |
| 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-Type defined but not used |  | ; Content-Type defined but not used |
| skipping to change at page 40, line 42 |  | skipping to change at page 41, line 26 |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/186>: "Document |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/186>: "Document |
| HTTP's error-handling philosophy" |  | HTTP's error-handling philosophy" |
| E.19. Since draft-ietf-httpbis-p3-payload-17 |  | E.19. Since draft-ietf-httpbis-p3-payload-17 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/323>: "intended |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/323>: "intended |
| maturity level vs normative references" |  | maturity level vs normative references" |
|  |  | E.20. Since draft-ietf-httpbis-p3-payload-18 |
|  |  | Closed issues: |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/330>: "is ETag a |
|  |  | representation header field?" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/338>: "Content- |
|  |  | Location doesn't constrain the cardinality of representations" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/346>: "make IANA |
|  |  | policy definitions consistent" |
| Index |  | Index |
| A |  | A |
| Accept header field 16 |  | Accept header field 16 |
| Accept-Charset header field 18 |  | Accept-Charset header field 19 |
| Accept-Encoding header field 19 |  | Accept-Encoding header field 19 |
| Accept-Language header field 20 |  | Accept-Language header field 21 |
| C |  | C |
| Coding Format |  | Coding Format |
| compress 7 |  | compress 7 |
| deflate 7 |  | deflate 8 |
| gzip 8 |  | gzip 8 |
| compress (Coding Format) 7 |  | compress (Coding Format) 7 |
| content negotiation 5 |  | content negotiation 5 |
| Content-Encoding header field 21 |  | Content-Encoding header field 22 |
| Content-Language header field 22 |  | Content-Language header field 23 |
| Content-Location header field 23 |  | Content-Location header field 23 |
|  |  | Content-Transfer-Encoding header field 32 |
| Content-Type header field 25 |  | Content-Type header field 25 |
| D |  | D |
| deflate (Coding Format) 7 |  | deflate (Coding Format) 8 |
| G |  | G |
| Grammar |  | Grammar |
| Accept 16 |  | Accept 17 |
| Accept-Charset 18 |  | Accept-Charset 19 |
| Accept-Encoding 19 |  | Accept-Encoding 19 |
| accept-ext 16 |  | accept-ext 17 |
| Accept-Language 20 |  | Accept-Language 21 |
| accept-params 16 |  | accept-params 17 |
| attribute 8 |  | attribute 9 |
| charset 7 |  | charset 7 |
| codings 19 |  | codings 19 |
| content-coding 7 |  | content-coding 7 |
| Content-Encoding 21 |  | Content-Encoding 22 |
| Content-Language 22 |  | Content-Language 23 |
| Content-Location 23 |  | Content-Location 23 |
| Content-Type 25 |  | Content-Type 25 |
| language-range 20 |  | language-range 21 |
| language-tag 10 |  | language-tag 10 |
| media-range 16 |  | media-range 17 |
| media-type 8 |  | media-type 8 |
| MIME-Version 30 |  | MIME-Version 30 |
| parameter 8 |  | parameter 9 |
| subtype 8 |  | subtype 8 |
| type 8 |  | type 8 |
| value 8 |  | value 9 |
| gzip (Coding Format) 8 |  | gzip (Coding Format) 8 |
| H |  | H |
| Header Fields |  | Header Fields |
| Accept 16 |  | Accept 16 |
| Accept-Charset 18 |  | Accept-Charset 19 |
| Accept-Encoding 19 |  | Accept-Encoding 19 |
| Accept-Language 20 |  | Accept-Language 21 |
| Content-Encoding 21 |  | Content-Encoding 22 |
| Content-Language 22 |  | Content-Language 23 |
| Content-Location 23 |  | Content-Location 23 |
|  |  | Content-Transfer-Encoding 32 |
| Content-Type 25 |  | Content-Type 25 |
| MIME-Version 30 |  | MIME-Version 30 |
| M |  | M |
| MIME-Version header field 30 |  | MIME-Version header field 30 |
| P |  | P |
| payload 11 |  | payload 11 |
| R |  | R |
| representation 11 |  | representation 11 |
|  |  | S |
|  |  | selected representation 5 |
| 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 |
| URI: http://roy.gbiv.com/ |  | URI: http://roy.gbiv.com/ |
| Jim Gettys |  |  |
| Alcatel-Lucent Bell Labs |  |  |
| 21 Oak Knoll Road |  |  |
| Carlisle, MA 01741 |  |  |
| USA |  |  |
| EMail: jg@freedesktop.org |  |  |
| URI: http://gettys.wordpress.com/ |  |  |
| Jeffrey C. Mogul |  |  |
| Hewlett-Packard Company |  |  |
| HP Labs, Large Scale Systems Group |  |  |
| 1501 Page Mill Road, MS 1177 |  |  |
| Palo Alto, CA 94304 |  |  |
| USA |  |  |
| EMail: JeffMogul@acm.org |  |  |
| Henrik Frystyk Nielsen |  |  |
| Microsoft Corporation |  |  |
| 1 Microsoft Way |  |  |
| Redmond, WA 98052 |  |  |
| USA |  |  |
| EMail: henrikn@microsoft.com |  |  |
| Larry Masinter |  |  |
| Adobe Systems Incorporated |  |  |
| 345 Park Ave |  |  |
| San Jose, CA 95110 |  |  |
| USA |  |  |
| EMail: LMM@acm.org |  |  |
| URI: http://larry.masinter.net/ |  |  |
| Paul J. Leach |  |  |
| Microsoft Corporation |  |  |
| 1 Microsoft Way |  |  |
| Redmond, WA 98052 |  |  |
| EMail: paulle@microsoft.com |  |  |
| Tim Berners-Lee |  |  |
| World Wide Web Consortium |  |  |
| MIT Computer Science and Artificial Intelligence Laboratory |  |  |
| The Stata Center, Building 32 |  |  |
| 32 Vassar Street |  |  |
| Cambridge, MA 02139 |  |  |
| USA |  |  |
| EMail: timbl@w3.org |  |  |
| URI: http://www.w3.org/People/Berners-Lee/ |  |  |
| Yves Lafon (editor) |  | Yves Lafon (editor) |
| World Wide Web Consortium |  | World Wide Web Consortium |
| W3C / ERCIM |  | W3C / ERCIM |
| 2004, rte des Lucioles |  | 2004, rte des Lucioles |
| Sophia-Antipolis, AM 06902 |  | Sophia-Antipolis, AM 06902 |
| France |  | France |
| EMail: ylafon@w3.org |  | EMail: ylafon@w3.org |
| URI: http://www.raubacapeu.net/people/yves/ |  | URI: http://www.raubacapeu.net/people/yves/ |
End of changes. 90 change blocks.
| 227 lines changed or deleted |  | 197 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/