| draft-ietf-httpbis-p1-messaging-21.txt |  | draft-ietf-httpbis-p1-messaging-22.txt |
--- | --- | --- | --- | ---
| HTTPbis Working Group R. Fielding, Ed. |  | HTTPbis Working Group R. Fielding, Ed. |
| Internet-Draft Adobe |  | Internet-Draft Adobe |
| Obsoletes: 2145,2616 (if approved) J. Reschke, Ed. |  | Obsoletes: 2145,2616 (if approved) J. Reschke, Ed. |
| Updates: 2817 (if approved) greenbytes |  | Updates: 2817,2818 (if approved) greenbytes |
| Intended status: Standards Track October 4, 2012 |  | Intended status: Standards Track February 23, 2013 |
| Expires: April 7, 2013 |  | Expires: August 27, 2013 |
| Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing |  | Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing |
| draft-ietf-httpbis-p1-messaging-21 |  | draft-ietf-httpbis-p1-messaging-22 |
| 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 provides an |  | information initiative since 1990. This document provides an |
| overview of HTTP architecture and its associated terminology, defines |  | overview of HTTP architecture and its associated terminology, defines |
| the "http" and "https" Uniform Resource Identifier (URI) schemes, |  | the "http" and "https" Uniform Resource Identifier (URI) schemes, |
| defines the HTTP/1.1 message syntax and parsing requirements, and |  | defines the HTTP/1.1 message syntax and parsing requirements, and |
| skipping to change at page 1, line 35 |  | skipping to change at page 1, line 35 |
| Discussion of this draft takes place on the HTTPBIS working group |  | Discussion of this draft takes place on the HTTPBIS working group |
| mailing list (ietf-http-wg@w3.org), which is archived at |  | 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 D.22. |  | The changes in this draft are summarized in Appendix D.2. |
| 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 7, 2013. |  | This Internet-Draft will expire on August 27, 2013. |
| Copyright Notice |  | Copyright Notice |
| Copyright (c) 2012 IETF Trust and the persons identified as the |  | Copyright (c) 2013 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 2, line 51 |  | skipping to change at page 2, line 51 |
| 2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 7 |  | 2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 7 |
| 2.2. Implementation Diversity . . . . . . . . . . . . . . . . . 8 |  | 2.2. Implementation Diversity . . . . . . . . . . . . . . . . . 8 |
| 2.3. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 9 |  | 2.3. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 9 |
| 2.4. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 11 |  | 2.4. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 11 |
| 2.5. Conformance and Error Handling . . . . . . . . . . . . . . 12 |  | 2.5. Conformance and Error Handling . . . . . . . . . . . . . . 12 |
| 2.6. Protocol Versioning . . . . . . . . . . . . . . . . . . . 13 |  | 2.6. Protocol Versioning . . . . . . . . . . . . . . . . . . . 13 |
| 2.7. Uniform Resource Identifiers . . . . . . . . . . . . . . . 15 |  | 2.7. Uniform Resource Identifiers . . . . . . . . . . . . . . . 15 |
| 2.7.1. http URI scheme . . . . . . . . . . . . . . . . . . . 16 |  | 2.7.1. http URI scheme . . . . . . . . . . . . . . . . . . . 16 |
| 2.7.2. https URI scheme . . . . . . . . . . . . . . . . . . . 17 |  | 2.7.2. https URI scheme . . . . . . . . . . . . . . . . . . . 17 |
| 2.7.3. http and https URI Normalization and Comparison . . . 18 |  | 2.7.3. http and https URI Normalization and Comparison . . . 18 |
| 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 18 |  | 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 19 |
| 3.1. Start Line . . . . . . . . . . . . . . . . . . . . . . . . 19 |  | 3.1. Start Line . . . . . . . . . . . . . . . . . . . . . . . . 19 |
| 3.1.1. Request Line . . . . . . . . . . . . . . . . . . . . . 20 |  | 3.1.1. Request Line . . . . . . . . . . . . . . . . . . . . . 20 |
| 3.1.2. Status Line . . . . . . . . . . . . . . . . . . . . . 21 |  | 3.1.2. Status Line . . . . . . . . . . . . . . . . . . . . . 21 |
| 3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 21 |  | 3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 22 |
| 3.2.1. Whitespace . . . . . . . . . . . . . . . . . . . . . . 23 |  | 3.2.1. Field Extensibility . . . . . . . . . . . . . . . . . 22 |
| 3.2.2. Field Parsing . . . . . . . . . . . . . . . . . . . . 23 |  | 3.2.2. Field Order . . . . . . . . . . . . . . . . . . . . . 22 |
| 3.2.3. Field Length . . . . . . . . . . . . . . . . . . . . . 24 |  | 3.2.3. Whitespace . . . . . . . . . . . . . . . . . . . . . . 23 |
| 3.2.4. Field value components . . . . . . . . . . . . . . . . 24 |  | 3.2.4. Field Parsing . . . . . . . . . . . . . . . . . . . . 24 |
|  |  | 3.2.5. Field Limits . . . . . . . . . . . . . . . . . . . . . 25 |
|  |  | 3.2.6. Field value components . . . . . . . . . . . . . . . . 25 |
| 3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 26 |  | 3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 26 |
| 3.3.1. Transfer-Encoding . . . . . . . . . . . . . . . . . . 26 |  | 3.3.1. Transfer-Encoding . . . . . . . . . . . . . . . . . . 27 |
| 3.3.2. Content-Length . . . . . . . . . . . . . . . . . . . . 28 |  | 3.3.2. Content-Length . . . . . . . . . . . . . . . . . . . . 28 |
| 3.3.3. Message Body Length . . . . . . . . . . . . . . . . . 29 |  | 3.3.3. Message Body Length . . . . . . . . . . . . . . . . . 30 |
| 3.4. Handling Incomplete Messages . . . . . . . . . . . . . . . 31 |  | 3.4. Handling Incomplete Messages . . . . . . . . . . . . . . . 32 |
| 3.5. Message Parsing Robustness . . . . . . . . . . . . . . . . 32 |  | 3.5. Message Parsing Robustness . . . . . . . . . . . . . . . . 33 |
| 4. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . . 32 |  | 4. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . . 33 |
| 4.1. Chunked Transfer Coding . . . . . . . . . . . . . . . . . 33 |  | 4.1. Chunked Transfer Coding . . . . . . . . . . . . . . . . . 34 |
| 4.1.1. Trailer . . . . . . . . . . . . . . . . . . . . . . . 34 |  | 4.1.1. Trailer . . . . . . . . . . . . . . . . . . . . . . . 35 |
| 4.1.2. Decoding chunked . . . . . . . . . . . . . . . . . . . 35 |  | 4.1.2. Decoding chunked . . . . . . . . . . . . . . . . . . . 36 |
| 4.2. Compression Codings . . . . . . . . . . . . . . . . . . . 35 |  | 4.2. Compression Codings . . . . . . . . . . . . . . . . . . . 37 |
| 4.2.1. Compress Coding . . . . . . . . . . . . . . . . . . . 35 |  | 4.2.1. Compress Coding . . . . . . . . . . . . . . . . . . . 37 |
| 4.2.2. Deflate Coding . . . . . . . . . . . . . . . . . . . . 35 |  | 4.2.2. Deflate Coding . . . . . . . . . . . . . . . . . . . . 37 |
| 4.2.3. Gzip Coding . . . . . . . . . . . . . . . . . . . . . 36 |  | 4.2.3. Gzip Coding . . . . . . . . . . . . . . . . . . . . . 37 |
| 4.3. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 |  | 4.3. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 |
| 5. Message Routing . . . . . . . . . . . . . . . . . . . . . . . 37 |  | 5. Message Routing . . . . . . . . . . . . . . . . . . . . . . . 38 |
| 5.1. Identifying a Target Resource . . . . . . . . . . . . . . 37 |  | 5.1. Identifying a Target Resource . . . . . . . . . . . . . . 38 |
| 5.2. Connecting Inbound . . . . . . . . . . . . . . . . . . . . 37 |  | 5.2. Connecting Inbound . . . . . . . . . . . . . . . . . . . . 39 |
| 5.3. Request Target . . . . . . . . . . . . . . . . . . . . . . 38 |  | 5.3. Request Target . . . . . . . . . . . . . . . . . . . . . . 39 |
| 5.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 |  | 5.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 |
| 5.5. Effective Request URI . . . . . . . . . . . . . . . . . . 41 |  | 5.5. Effective Request URI . . . . . . . . . . . . . . . . . . 43 |
| 5.6. Message Forwarding . . . . . . . . . . . . . . . . . . . . 42 |  | 5.6. Associating a Response to a Request . . . . . . . . . . . 44 |
| 5.7. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 |  | 5.7. Message Forwarding . . . . . . . . . . . . . . . . . . . . 44 |
| 5.8. Message Transforming . . . . . . . . . . . . . . . . . . . 44 |  | 5.7.1. Via . . . . . . . . . . . . . . . . . . . . . . . . . 45 |
| 5.9. Associating a Response to a Request . . . . . . . . . . . 46 |  | 5.7.2. Transformations . . . . . . . . . . . . . . . . . . . 46 |
| 6. Connection Management . . . . . . . . . . . . . . . . . . . . 46 |  | 6. Connection Management . . . . . . . . . . . . . . . . . . . . 47 |
| 6.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 46 |  | 6.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 48 |
| 6.2. Persistent Connections . . . . . . . . . . . . . . . . . . 48 |  | 6.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 49 |
| 6.2.1. Establishment . . . . . . . . . . . . . . . . . . . . 49 |  | 6.3. Persistence . . . . . . . . . . . . . . . . . . . . . . . 49 |
| 6.2.2. Reuse . . . . . . . . . . . . . . . . . . . . . . . . 50 |  | 6.3.1. Retrying Requests . . . . . . . . . . . . . . . . . . 50 |
| 6.2.3. Concurrency . . . . . . . . . . . . . . . . . . . . . 51 |  | 6.3.2. Pipelining . . . . . . . . . . . . . . . . . . . . . . 51 |
| 6.2.4. Failures and Time-outs . . . . . . . . . . . . . . . . 51 |  | 6.4. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 52 |
| 6.2.5. Tear-down . . . . . . . . . . . . . . . . . . . . . . 52 |  | 6.5. Failures and Time-outs . . . . . . . . . . . . . . . . . . 52 |
| 6.3. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 53 |  | 6.6. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 53 |
| 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54 |  | 6.7. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 54 |
| 7.1. Header Field Registration . . . . . . . . . . . . . . . . 54 |  | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55 |
| 7.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 55 |  | 7.1. Header Field Registration . . . . . . . . . . . . . . . . 55 |
| 7.3. Internet Media Type Registrations . . . . . . . . . . . . 56 |  | 7.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 56 |
| 7.3.1. Internet Media Type message/http . . . . . . . . . . . 56 |  | 7.3. Internet Media Type Registration . . . . . . . . . . . . . 56 |
| 7.3.2. Internet Media Type application/http . . . . . . . . . 57 |  | 7.3.1. Internet Media Type message/http . . . . . . . . . . . 57 |
|  |  | 7.3.2. Internet Media Type application/http . . . . . . . . . 58 |
| 7.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 58 |  | 7.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 59 |
| 7.5. Transfer Coding Registrations . . . . . . . . . . . . . . 58 |  | 7.5. Transfer Coding Registration . . . . . . . . . . . . . . . 59 |
| 7.6. Upgrade Token Registry . . . . . . . . . . . . . . . . . . 59 |  | 7.6. Upgrade Token Registry . . . . . . . . . . . . . . . . . . 60 |
| 7.7. Upgrade Token Registration . . . . . . . . . . . . . . . . 60 |  | 7.7. Upgrade Token Registration . . . . . . . . . . . . . . . . 61 |
| 8. Security Considerations . . . . . . . . . . . . . . . . . . . 60 |  | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 61 |
| 8.1. Personal Information . . . . . . . . . . . . . . . . . . . 60 |  | 8.1. DNS-related Attacks . . . . . . . . . . . . . . . . . . . 61 |
| 8.2. Abuse of Server Log Information . . . . . . . . . . . . . 60 |  | 8.2. Intermediaries and Caching . . . . . . . . . . . . . . . . 61 |
| 8.3. Attacks Based On File and Path Names . . . . . . . . . . . 61 |  | 8.3. Buffer Overflows . . . . . . . . . . . . . . . . . . . . . 62 |
| 8.4. DNS-related Attacks . . . . . . . . . . . . . . . . . . . 61 |  | 8.4. Message Integrity . . . . . . . . . . . . . . . . . . . . 62 |
| 8.5. Intermediaries and Caching . . . . . . . . . . . . . . . . 61 |  | 8.5. Server Log Information . . . . . . . . . . . . . . . . . . 63 |
| 8.6. Protocol Element Size Overflows . . . . . . . . . . . . . 62 |  | 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 63 |
| 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 62 |  | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 65 |
| 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 64 |  | 10.1. Normative References . . . . . . . . . . . . . . . . . . . 65 |
| 10.1. Normative References . . . . . . . . . . . . . . . . . . . 64 |  | 10.2. Informative References . . . . . . . . . . . . . . . . . . 66 |
| 10.2. Informative References . . . . . . . . . . . . . . . . . . 65 |  | Appendix A. HTTP Version History . . . . . . . . . . . . . . . . 68 |
| Appendix A. HTTP Version History . . . . . . . . . . . . . . . . 67 |  | A.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 69 |
| A.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 67 |  | A.1.1. Multi-homed Web Servers . . . . . . . . . . . . . . . 69 |
| A.1.1. Multi-homed Web Servers . . . . . . . . . . . . . . . 68 |  | A.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 69 |
| A.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 68 |  | A.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 70 |
| A.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 69 |  | A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 70 |
| A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 69 |  | Appendix B. ABNF list extension: #rule . . . . . . . . . . . . . 72 |
| Appendix B. ABNF list extension: #rule . . . . . . . . . . . . . 70 |  | Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 73 |
| Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 71 |  |  |
| Appendix D. Change Log (to be removed by RFC Editor before |  | Appendix D. Change Log (to be removed by RFC Editor before |
| publication) . . . . . . . . . . . . . . . . . . . . 74 |  | publication) . . . . . . . . . . . . . . . . . . . . 76 |
| D.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 74 |  | D.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 76 |
| D.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 74 |  | D.2. Since draft-ietf-httpbis-p1-messaging-21 . . . . . . . . . 76 |
| D.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 75 |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 |
| D.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 76 |  |  |
| D.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 77 |  |  |
| D.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 77 |  |  |
| D.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 78 |  |  |
| D.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 79 |  |  |
| D.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 79 |  |  |
| D.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 80 |  |  |
| D.11. Since draft-ietf-httpbis-p1-messaging-09 . . . . . . . . . 80 |  |  |
| D.12. Since draft-ietf-httpbis-p1-messaging-10 . . . . . . . . . 81 |  |  |
| D.13. Since draft-ietf-httpbis-p1-messaging-11 . . . . . . . . . 81 |  |  |
| D.14. Since draft-ietf-httpbis-p1-messaging-12 . . . . . . . . . 82 |  |  |
| D.15. Since draft-ietf-httpbis-p1-messaging-13 . . . . . . . . . 82 |  |  |
| D.16. Since draft-ietf-httpbis-p1-messaging-14 . . . . . . . . . 83 |  |  |
| D.17. Since draft-ietf-httpbis-p1-messaging-15 . . . . . . . . . 83 |  |  |
| D.18. Since draft-ietf-httpbis-p1-messaging-16 . . . . . . . . . 83 |  |  |
| D.19. Since draft-ietf-httpbis-p1-messaging-17 . . . . . . . . . 84 |  |  |
| D.20. Since draft-ietf-httpbis-p1-messaging-18 . . . . . . . . . 84 |  |  |
| D.21. Since draft-ietf-httpbis-p1-messaging-19 . . . . . . . . . 84 |  |  |
| D.22. Since draft-ietf-httpbis-p1-messaging-20 . . . . . . . . . 85 |  |  |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 |  |  |
| 1. Introduction |  | 1. Introduction |
| The Hypertext Transfer Protocol (HTTP) is an application-level |  | The Hypertext Transfer Protocol (HTTP) is an application-level |
| request/response protocol that uses extensible semantics and MIME- |  | request/response protocol that uses extensible semantics and self- |
| like message payloads for flexible interaction with network-based |  | descriptive message payloads for flexible interaction with network- |
| hypertext information systems. This document is the first in a |  | based hypertext information systems. This document is the first in a |
| series of documents that collectively form the HTTP/1.1 |  | series of documents that collectively form the HTTP/1.1 |
| specification: |  | specification: |
| RFC xxx1: Message Syntax and Routing |  | RFC xxx1: Message Syntax and Routing |
| RFC xxx2: Semantics and Content |  | RFC xxx2: Semantics and Content |
| RFC xxx3: Conditional Requests |  | RFC xxx3: Conditional Requests |
| RFC xxx4: Range Requests |  | RFC xxx4: Range Requests |
| RFC xxx5: Caching |  | RFC xxx5: Caching |
| RFC xxx6: Authentication |  | RFC xxx6: Authentication |
| This HTTP/1.1 specification obsoletes and moves to historic status |  | This HTTP/1.1 specification obsoletes and moves to historic status |
| RFC 2616, its predecessor RFC 2068, RFC 2145 (on HTTP versioning), |  | RFC 2616, its predecessor RFC 2068, and RFC 2145 (on HTTP |
| and RFC 2817 (on using CONNECT for TLS upgrades). |  | versioning). This specification also updates the use of CONNECT to |
|  |  | establish a tunnel, previously defined in RFC 2817, and defines the |
|  |  | "https" URI scheme that was described informally in RFC 2818. |
| HTTP is a generic interface protocol for information systems. It is |  | HTTP is a generic interface protocol for information systems. It is |
| designed to hide the details of how a service is implemented by |  | designed to hide the details of how a service is implemented by |
| presenting a uniform interface to clients that is independent of the |  | presenting a uniform interface to clients that is independent of the |
| types of resources provided. Likewise, servers do not need to be |  | types of resources provided. Likewise, servers do not need to be |
| aware of each client's purpose: an HTTP request can be considered in |  | aware of each client's purpose: an HTTP request can be considered in |
| isolation rather than being associated with a specific type of client |  | isolation rather than being associated with a specific type of client |
| or a predetermined sequence of application steps. The result is a |  | or a predetermined sequence of application steps. The result is a |
| protocol that can be used effectively in many different contexts and |  | protocol that can be used effectively in many different contexts and |
| for which implementations can evolve independently over time. |  | for which implementations can evolve independently over time. |
| HTTP is also designed for use as an intermediation protocol for |  | HTTP is also designed for use as an intermediation protocol for |
| translating communication to and from non-HTTP information systems. |  | translating communication to and from non-HTTP information systems. |
| HTTP proxies and gateways can provide access to alternative |  | HTTP proxies and gateways can provide access to alternative |
| information services by translating their diverse protocols into a |  | information services by translating their diverse protocols into a |
| hypertext format that can be viewed and manipulated by clients in the |  | hypertext format that can be viewed and manipulated by clients in the |
| same way as HTTP services. |  | same way as HTTP services. |
| One consequence of HTTP flexibility is that the protocol cannot be |  | One consequence of this flexibility is that the protocol cannot be |
| defined in terms of what occurs behind the interface. Instead, we |  | defined in terms of what occurs behind the interface. Instead, we |
| are limited to defining the syntax of communication, the intent of |  | are limited to defining the syntax of communication, the intent of |
| received communication, and the expected behavior of recipients. If |  | received communication, and the expected behavior of recipients. If |
| the communication is considered in isolation, then successful actions |  | the communication is considered in isolation, then successful actions |
| ought to be reflected in corresponding changes to the observable |  | ought to be reflected in corresponding changes to the observable |
| interface provided by servers. However, since multiple clients might |  | interface provided by servers. However, since multiple clients might |
| act in parallel and perhaps at cross-purposes, we cannot require that |  | act in parallel and perhaps at cross-purposes, we cannot require that |
| such changes be observable beyond the scope of a single response. |  | such changes be observable beyond the scope of a single response. |
| This document describes the architectural elements that are used or |  | This document describes the architectural elements that are used or |
| skipping to change at page 7, line 18 |  | skipping to change at page 7, line 18 |
| exchanging messages (Section 3) across a reliable transport or |  | exchanging messages (Section 3) across a reliable transport or |
| session-layer "connection" (Section 6). An HTTP "client" is a |  | session-layer "connection" (Section 6). An HTTP "client" is a |
| program that establishes a connection to a server for the purpose of |  | program that establishes a connection to a server for the purpose of |
| sending one or more HTTP requests. An HTTP "server" is a program |  | sending one or more HTTP requests. An HTTP "server" is a program |
| that accepts connections in order to service HTTP requests by sending |  | that accepts connections in order to service HTTP requests by sending |
| HTTP responses. |  | HTTP responses. |
| The terms client and server refer only to the roles that these |  | The terms client and server refer only to the roles that these |
| programs perform for a particular connection. The same program might |  | programs perform for a particular connection. The same program might |
| act as a client on some connections and a server on others. We use |  | act as a client on some connections and a server on others. We use |
| the term "user agent" to refer to the program that initiates a |  | the term "user agent" to refer to any of the various client programs |
| request, such as a WWW browser, editor, or spider (web-traversing |  | that initiate a request, including (but not limited to) browsers, |
| robot), and the term "origin server" to refer to the program that can |  | spiders (web-based robots), command-line tools, native applications, |
| originate authoritative responses to a request. For general |  | and mobile apps. The term "origin server" is used to refer to the |
| requirements, we use the term "sender" to refer to whichever |  | program that can originate authoritative responses to a request. For |
| component sent a given message and the term "recipient" to refer to |  | general requirements, we use the terms "sender" and "recipient" to |
| any component that receives the message. |  | refer to any component that sends or receives, respectively, a given |
|  |  | message. |
| HTTP relies upon the Uniform Resource Identifier (URI) standard |  | HTTP relies upon the Uniform Resource Identifier (URI) standard |
| [RFC3986] to indicate the target resource (Section 5.1) and |  | [RFC3986] to indicate the target resource (Section 5.1) and |
| relationships between resources. Messages are passed in a format |  | relationships between resources. Messages are passed in a format |
| similar to that used by Internet mail [RFC5322] and the Multipurpose |  | similar to that used by Internet mail [RFC5322] and the Multipurpose |
| Internet Mail Extensions (MIME) [RFC2045] (see Appendix A of [Part2] |  | Internet Mail Extensions (MIME) [RFC2045] (see Appendix A of [Part2] |
| for the differences between HTTP and MIME messages). |  | for the differences between HTTP and MIME messages). |
| Most HTTP communication consists of a retrieval request (GET) for a |  | Most HTTP communication consists of a retrieval request (GET) for a |
| representation of some resource identified by a URI. In the simplest |  | representation of some resource identified by a URI. In the simplest |
| skipping to change at page 8, line 12 |  | skipping to change at page 8, line 13 |
| A server responds to a client's request by sending one or more HTTP |  | A server responds to a client's request by sending one or more HTTP |
| response messages, each beginning with a status line that includes |  | response messages, each beginning with a status line that includes |
| the protocol version, a success or error code, and textual reason |  | the protocol version, a success or error code, and textual reason |
| phrase (Section 3.1.2), possibly followed by header fields containing |  | phrase (Section 3.1.2), possibly followed by header fields containing |
| server information, resource metadata, and representation metadata |  | server information, resource metadata, and representation metadata |
| (Section 3.2), an empty line to indicate the end of the header |  | (Section 3.2), an empty line to indicate the end of the header |
| section, and finally a message body containing the payload body (if |  | section, and finally a message body containing the payload body (if |
| any, Section 3.3). |  | any, Section 3.3). |
| A connection might be used for multiple request/response exchanges, |  | A connection might be used for multiple request/response exchanges, |
| as defined in Section 6.2. |  | as defined in Section 6.3. |
| The following example illustrates a typical message exchange for a |  | The following example illustrates a typical message exchange for a |
| GET request on the URI "http://www.example.com/hello.txt": |  | GET request on the URI "http://www.example.com/hello.txt": |
| client request: |  | client request: |
| GET /hello.txt HTTP/1.1 |  | GET /hello.txt HTTP/1.1 |
| User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 |  | User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 |
| Host: www.example.com |  | Host: www.example.com |
| Accept-Language: en, mi |  | Accept-Language: en, mi |
| skipping to change at page 8, line 38 |  | skipping to change at page 8, line 39 |
| Server: Apache |  | Server: Apache |
| Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT |  | Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT |
| ETag: "34aa387-d-1568eb00" |  | ETag: "34aa387-d-1568eb00" |
| Accept-Ranges: bytes |  | Accept-Ranges: bytes |
| Content-Length: 14 |  | Content-Length: 14 |
| Vary: Accept-Encoding |  | Vary: Accept-Encoding |
| Content-Type: text/plain |  | Content-Type: text/plain |
| Hello World! |  | Hello World! |
|  |  | (Note that the content length includes the trailing CR/LF sequence of |
|  |  | the body text) |
| 2.2. Implementation Diversity |  | 2.2. Implementation Diversity |
| When considering the design of HTTP, it is easy to fall into a trap |  | When considering the design of HTTP, it is easy to fall into a trap |
| of thinking that all user agents are general-purpose browsers and all |  | of thinking that all user agents are general-purpose browsers and all |
| origin servers are large public websites. That is not the case in |  | origin servers are large public websites. That is not the case in |
| practice. Common HTTP user agents include household appliances, |  | practice. Common HTTP user agents include household appliances, |
| stereos, scales, firmware update scripts, command-line programs, |  | stereos, scales, firmware update scripts, command-line programs, |
| mobile apps, and communication devices in a multitude of shapes and |  | mobile apps, and communication devices in a multitude of shapes and |
| sizes. Likewise, common HTTP origin servers include home automation |  | sizes. Likewise, common HTTP origin servers include home automation |
| units, configurable networking components, office machines, |  | units, configurable networking components, office machines, |
| skipping to change at page 9, line 20 |  | skipping to change at page 9, line 23 |
| erroneous). Spiders, for example, are typically given a start URI |  | erroneous). Spiders, for example, are typically given a start URI |
| and configured to follow certain behavior while crawling the Web as a |  | and configured to follow certain behavior while crawling the Web as a |
| hypertext graph. |  | hypertext graph. |
| The implementation diversity of HTTP means that we cannot assume the |  | The implementation diversity of HTTP means that we cannot assume the |
| user agent can make interactive suggestions to a user or provide |  | user agent can make interactive suggestions to a user or provide |
| adequate warning for security or privacy options. In the few cases |  | adequate warning for security or privacy options. In the few cases |
| where this specification requires reporting of errors to the user, it |  | where this specification requires reporting of errors to the user, it |
| is acceptable for such reporting to only be observable in an error |  | is acceptable for such reporting to only be observable in an error |
| console or log file. Likewise, requirements that an automated action |  | console or log file. Likewise, requirements that an automated action |
| be confirmed by the user before proceeding can me met via advance |  | be confirmed by the user before proceeding can be met via advance |
| configuration choices, run-time options, or simply not proceeding |  | configuration choices, run-time options, or simply not proceeding |
| with the unsafe action. |  | with the unsafe action. |
| 2.3. Intermediaries |  | 2.3. Intermediaries |
| HTTP enables the use of intermediaries to satisfy requests through a |  | HTTP enables the use of intermediaries to satisfy requests through a |
| chain of connections. There are three common forms of HTTP |  | chain of connections. There are three common forms of HTTP |
| intermediary: proxy, gateway, and tunnel. In some cases, a single |  | intermediary: proxy, gateway, and tunnel. In some cases, a single |
| intermediary might act as an origin server, proxy, gateway, or |  | intermediary might act as an origin server, proxy, gateway, or |
| tunnel, switching behavior based on the nature of each request. |  | tunnel, switching behavior based on the nature of each request. |
| skipping to change at page 10, line 30 |  | skipping to change at page 10, line 34 |
| that would be significant to the original sender or potentially |  | that would be significant to the original sender or potentially |
| significant to downstream recipients). For example, a transforming |  | significant to downstream recipients). For example, a transforming |
| proxy might be acting as a shared annotation server (modifying |  | proxy might be acting as a shared annotation server (modifying |
| responses to include references to a local annotation database), a |  | responses to include references to a local annotation database), a |
| malware filter, a format transcoder, or an intranet-to-Internet |  | malware filter, a format transcoder, or an intranet-to-Internet |
| privacy filter. Such transformations are presumed to be desired by |  | privacy filter. Such transformations are presumed to be desired by |
| the client (or client organization) that selected the proxy and are |  | the client (or client organization) that selected the proxy and are |
| beyond the scope of this specification. However, when a proxy is not |  | beyond the scope of this specification. However, when a proxy is not |
| intended to transform a given message, we use the term "non- |  | intended to transform a given message, we use the term "non- |
| transforming proxy" to target requirements that preserve HTTP message |  | transforming proxy" to target requirements that preserve HTTP message |
| semantics. See Section 7.3.4 of [Part2] and Section 7.5 of [Part6] |  | semantics. See Section 6.3.4 of [Part2] and Section 7.5 of [Part6] |
| for status and warning codes related to transformations. |  | for status and warning codes related to transformations. |
| A "gateway" (a.k.a., "reverse proxy") is a receiving agent that acts |  | A "gateway" (a.k.a., "reverse proxy") is a receiving agent that acts |
| as a layer above some other server(s) and translates the received |  | as a layer above some other server(s) and translates the received |
| requests to the underlying server's protocol. Gateways are often |  | requests to the underlying server's protocol. Gateways are often |
| used to encapsulate legacy or untrusted information services, to |  | used to encapsulate legacy or untrusted information services, to |
| improve server performance through "accelerator" caching, and to |  | improve server performance through "accelerator" caching, and to |
| enable partitioning or load-balancing of HTTP services across |  | enable partitioning or load-balancing of HTTP services across |
| multiple machines. |  | multiple machines. |
| A gateway behaves as an origin server on its outbound connection and |  | A gateway behaves as an origin server on its outbound connection and |
| as a user agent on its inbound connection. All HTTP requirements |  | as a user agent on its inbound connection. All HTTP requirements |
| applicable to an origin server also apply to the outbound |  | applicable to an origin server also apply to the outbound |
| communication of a gateway. A gateway communicates with inbound |  | communication of a gateway. A gateway communicates with inbound |
| servers using any protocol that it desires, including private |  | servers using any protocol that it desires, including private |
| extensions to HTTP that are outside the scope of this specification. |  | extensions to HTTP that are outside the scope of this specification. |
| However, an HTTP-to-HTTP gateway that wishes to interoperate with |  | However, an HTTP-to-HTTP gateway that wishes to interoperate with |
| third-party HTTP servers MUST conform to HTTP user agent requirements |  | third-party HTTP servers MUST conform to HTTP user agent requirements |
| on the gateway's inbound connection and MUST implement the Connection |  | on the gateway's inbound connection and MUST implement the Connection |
| (Section 6.1) and Via (Section 5.7) header fields for both |  | (Section 6.1) and Via (Section 5.7.1) header fields for both |
| connections. |  | connections. |
| A "tunnel" acts as a blind relay between two connections without |  | A "tunnel" acts as a blind relay between two connections without |
| changing the messages. Once active, a tunnel is not considered a |  | changing the messages. Once active, a tunnel is not considered a |
| party to the HTTP communication, though the tunnel might have been |  | party to the HTTP communication, though the tunnel might have been |
| initiated by an HTTP request. A tunnel ceases to exist when both |  | initiated by an HTTP request. A tunnel ceases to exist when both |
| ends of the relayed connection are closed. Tunnels are used to |  | ends of the relayed connection are closed. Tunnels are used to |
| extend a virtual connection through an intermediary, such as when |  | extend a virtual connection through an intermediary, such as when |
| Transport Layer Security (TLS, [RFC5246]) is used to establish |  | Transport Layer Security (TLS, [RFC5246]) is used to establish |
| confidential communication through a shared firewall proxy. |  | confidential communication through a shared firewall proxy. |
| skipping to change at page 11, line 34 |  | skipping to change at page 11, line 38 |
| TCP port 80 packets (and occasionally other common port traffic). |  | TCP port 80 packets (and occasionally other common port traffic). |
| Interception proxies are commonly found on public network access |  | Interception proxies are commonly found on public network access |
| points, as a means of enforcing account subscription prior to |  | points, as a means of enforcing account subscription prior to |
| allowing use of non-local Internet services, and within corporate |  | allowing use of non-local Internet services, and within corporate |
| firewalls to enforce network usage policies. They are |  | firewalls to enforce network usage policies. They are |
| indistinguishable from a man-in-the-middle attack. |  | indistinguishable from a man-in-the-middle attack. |
| HTTP is defined as a stateless protocol, meaning that each request |  | HTTP is defined as a stateless protocol, meaning that each request |
| message can be understood in isolation. Many implementations depend |  | message can be understood in isolation. Many implementations depend |
| on HTTP's stateless design in order to reuse proxied connections or |  | on HTTP's stateless design in order to reuse proxied connections or |
| dynamically load balance requests across multiple servers. Hence, |  | dynamically load-balance requests across multiple servers. Hence, |
| servers MUST NOT assume that two requests on the same connection are |  | servers MUST NOT assume that two requests on the same connection are |
| from the same user agent unless the connection is secured and |  | from the same user agent unless the connection is secured and |
| specific to that agent. Some non-standard HTTP extensions (e.g., |  | specific to that agent. Some non-standard HTTP extensions (e.g., |
| [RFC4559]) have been known to violate this requirement, resulting in |  | [RFC4559]) have been known to violate this requirement, resulting in |
| security and interoperability problems. |  | security and interoperability problems. |
| 2.4. Caches |  | 2.4. Caches |
| A "cache" is a local store of previous response messages and the |  | A "cache" is a local store of previous response messages and the |
| subsystem that controls its message storage, retrieval, and deletion. |  | subsystem that controls its message storage, retrieval, and deletion. |
| A cache stores cacheable responses in order to reduce the response |  | A cache stores cacheable responses in order to reduce the response |
| time and network bandwidth consumption on future, equivalent |  | time and network bandwidth consumption on future, equivalent |
| requests. Any client or server MAY employ a cache, though a cache |  | requests. Any client or server MAY employ a cache, though a cache |
| cannot be used by a server while it is acting as a tunnel. |  | cannot be used by a server while it is acting as a tunnel. |
| The effect of a cache is that the request/response chain is shortened |  | The effect of a cache is that the request/response chain is shortened |
| if one of the participants along the chain has a cached response |  | if one of the participants along the chain has a cached response |
| applicable to that request. The following illustrates the resulting |  | applicable to that request. The following illustrates the resulting |
| chain if B has a cached copy of an earlier response from O (via C) |  | chain if B has a cached copy of an earlier response from O (via C) |
| for a request which has not been cached by UA or A. |  | for a request that has not been cached by UA or A. |
| > > |  | > > |
| UA =========== A =========== B - - - - - - C - - - - - - O |  | UA =========== A =========== B - - - - - - C - - - - - - O |
| < < |  | < < |
| A response is "cacheable" if a cache is allowed to store a copy of |  | A response is "cacheable" if a cache is allowed to store a copy of |
| the response message for use in answering subsequent requests. Even |  | the response message for use in answering subsequent requests. Even |
| when a response is cacheable, there might be additional constraints |  | when a response is cacheable, there might be additional constraints |
| placed by the client or by the origin server on when that cached |  | placed by the client or by the origin server on when that cached |
| response can be used for a particular request. HTTP requirements for |  | response can be used for a particular request. HTTP requirements for |
| cache behavior and cacheable responses are defined in Section 2 of |  | cache behavior and cacheable responses are defined in Section 2 of |
| [Part6]. |  | [Part6]. |
| There are a wide variety of architectures and configurations of |  | There are a wide variety of architectures and configurations of |
| caches and proxies deployed across the World Wide Web and inside |  | caches deployed across the World Wide Web and inside large |
| large organizations. These systems include national hierarchies of |  | organizations. These include national hierarchies of proxy caches to |
| proxy caches to save transoceanic bandwidth, systems that broadcast |  | save transoceanic bandwidth, collaborative systems that broadcast or |
| or multicast cache entries, organizations that distribute subsets of |  | multicast cache entries, archives of pre-fetched cache entries for |
| cached data via optical media, and so on. |  | use in off-line or high-latency environments, and so on. |
| 2.5. Conformance and Error Handling |  | 2.5. Conformance and Error Handling |
| This specification targets conformance criteria according to the role |  | This specification targets conformance criteria according to the role |
| of a participant in HTTP communication. Hence, HTTP requirements are |  | of a participant in HTTP communication. Hence, HTTP requirements are |
| placed on senders, recipients, clients, servers, user agents, |  | placed on senders, recipients, clients, servers, user agents, |
| intermediaries, origin servers, proxies, gateways, or caches, |  | intermediaries, origin servers, proxies, gateways, or caches, |
| depending on what behavior is being constrained by the requirement. |  | depending on what behavior is being constrained by the requirement. |
| Additional (social) requirements are placed on implementations, |  | Additional (social) requirements are placed on implementations, |
| resource owners, and protocol element registrations when they apply |  | resource owners, and protocol element registrations when they apply |
| skipping to change at page 15, line 23 |  | skipping to change at page 15, line 28 |
| performed unless triggered by specific client attributes, such as |  | performed unless triggered by specific client attributes, such as |
| when one or more of the request header fields (e.g., User-Agent) |  | when one or more of the request header fields (e.g., User-Agent) |
| uniquely match the values sent by a client known to be in error. |  | uniquely match the values sent by a client known to be in error. |
| The intention of HTTP's versioning design is that the major number |  | The intention of HTTP's versioning design is that the major number |
| will only be incremented if an incompatible message syntax is |  | will only be incremented if an incompatible message syntax is |
| introduced, and that the minor number will only be incremented when |  | introduced, and that the minor number will only be incremented when |
| changes made to the protocol have the effect of adding to the message |  | changes made to the protocol have the effect of adding to the message |
| semantics or implying additional capabilities of the sender. |  | semantics or implying additional capabilities of the sender. |
| However, the minor version was not incremented for the changes |  | However, the minor version was not incremented for the changes |
| introduced between [RFC2068] and [RFC2616], and this revision is |  | introduced between [RFC2068] and [RFC2616], and this revision has |
| specifically avoiding any such changes to the protocol. |  | specifically avoiding any such changes to the protocol. |
| 2.7. Uniform Resource Identifiers |  | 2.7. Uniform Resource Identifiers |
| Uniform Resource Identifiers (URIs) [RFC3986] are used throughout |  | Uniform Resource Identifiers (URIs) [RFC3986] are used throughout |
| HTTP as the means for identifying resources (Section 2 of [Part2]). |  | HTTP as the means for identifying resources (Section 2 of [Part2]). |
| URI references are used to target requests, indicate redirects, and |  | URI references are used to target requests, indicate redirects, and |
| define relationships. |  | define relationships. |
| This specification adopts the definitions of "URI-reference", |  | This specification adopts the definitions of "URI-reference", |
| "absolute-URI", "relative-part", "port", "host", "path-abempty", |  | "absolute-URI", "relative-part", "port", "host", "path-abempty", |
| "path-absolute", "query", and "authority" from the URI generic |  | "query", "segment", and "authority" from the URI generic syntax. In |
| syntax. In addition, we define a partial-URI rule for protocol |  | addition, we define an "absolute-path" rule (that differs from RFC |
| elements that allow a relative URI but not a fragment. |  | 3986's "path-absolute" in that it allows a leading "//") and a |
|  |  | "partial-URI" rule for protocol elements that allow a relative URI |
|  |  | but not a fragment. |
| URI-reference = <URI-reference, defined in [RFC3986], Section 4.1> |  | URI-reference = <URI-reference, defined in [RFC3986], Section 4.1> |
| absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3> |  | absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3> |
| relative-part = <relative-part, defined in [RFC3986], Section 4.2> |  | relative-part = <relative-part, defined in [RFC3986], Section 4.2> |
| authority = <authority, defined in [RFC3986], Section 3.2> |  | authority = <authority, defined in [RFC3986], Section 3.2> |
| path-abempty = <path-abempty, defined in [RFC3986], Section 3.3> |  | path-abempty = <path-abempty, defined in [RFC3986], Section 3.3> |
| path-absolute = <path-absolute, defined in [RFC3986], Section 3.3> |  |  |
| port = <port, defined in [RFC3986], Section 3.2.3> |  | port = <port, defined in [RFC3986], Section 3.2.3> |
| query = <query, defined in [RFC3986], Section 3.4> |  | query = <query, defined in [RFC3986], Section 3.4> |
|  |  | segment = <segment, defined in [RFC3986], Section 3.3> |
| uri-host = <host, defined in [RFC3986], Section 3.2.2> |  | uri-host = <host, defined in [RFC3986], Section 3.2.2> |
|  |  | absolute-path = 1*( "/" segment ) |
| partial-URI = relative-part [ "?" query ] |  | partial-URI = relative-part [ "?" query ] |
| Each protocol element in HTTP that allows a URI reference will |  | Each protocol element in HTTP that allows a URI reference will |
| indicate in its ABNF production whether the element allows any form |  | indicate in its ABNF production whether the element allows any form |
| of reference (URI-reference), only a URI in absolute form (absolute- |  | of reference (URI-reference), only a URI in absolute form (absolute- |
| URI), only the path and optional query components, or some |  | URI), only the path and optional query components, or some |
| combination of the above. Unless otherwise indicated, URI references |  | combination of the above. Unless otherwise indicated, URI references |
| are parsed relative to the effective request URI (Section 5.5). |  | are parsed relative to the effective request URI (Section 5.5). |
| 2.7.1. http URI scheme |  | 2.7.1. http URI scheme |
| skipping to change at page 16, line 26 |  | skipping to change at page 16, line 41 |
| http-URI = "http:" "//" authority path-abempty [ "?" query ] |  | http-URI = "http:" "//" authority path-abempty [ "?" query ] |
| The HTTP origin server is identified by the generic syntax's |  | The HTTP origin server is identified by the generic syntax's |
| authority component, which includes a host identifier and optional |  | authority component, which includes a host identifier and optional |
| TCP port ([RFC3986], Section 3.2.2). The remainder of the URI, |  | TCP port ([RFC3986], Section 3.2.2). The remainder of the URI, |
| consisting of both the hierarchical path component and optional query |  | consisting of both the hierarchical path component and optional query |
| component, serves as an identifier for a potential resource within |  | component, serves as an identifier for a potential resource within |
| that origin server's name space. |  | that origin server's name space. |
| If the host identifier is provided as an IP literal or IPv4 address, |  | If the host identifier is provided as an IP address, then the origin |
| then the origin server is any listener on the indicated TCP port at |  | server is any listener on the indicated TCP port at that IP address. |
| that IP address. If host is a registered name, then that name is |  | If host is a registered name, then that name is considered an |
| considered an indirect identifier and the recipient might use a name |  | indirect identifier and the recipient might use a name resolution |
| resolution service, such as DNS, to find the address of a listener |  | service, such as DNS, to find the address of a listener for that |
| for that host. The host MUST NOT be empty; if an "http" URI is |  | host. The host MUST NOT be empty; if an "http" URI is received with |
| received with an empty host, then it MUST be rejected as invalid. If |  | an empty host, then it MUST be rejected as invalid. If the port |
| the port subcomponent is empty or not given, then TCP port 80 is |  | subcomponent is empty or not given, then TCP port 80 is assumed (the |
| assumed (the default reserved port for WWW services). |  | default reserved port for WWW services). |
| Regardless of the form of host identifier, access to that host is not |  | Regardless of the form of host identifier, access to that host is not |
| implied by the mere presence of its name or address. The host might |  | implied by the mere presence of its name or address. The host might |
| or might not exist and, even when it does exist, might or might not |  | or might not exist and, even when it does exist, might or might not |
| be running an HTTP server or listening to the indicated port. The |  | be running an HTTP server or listening to the indicated port. The |
| "http" URI scheme makes use of the delegated nature of Internet names |  | "http" URI scheme makes use of the delegated nature of Internet names |
| and addresses to establish a naming authority (whatever entity has |  | and addresses to establish a naming authority (whatever entity has |
| the ability to place an HTTP server at that Internet name or address) |  | the ability to place an HTTP server at that Internet name or address) |
| and allows that authority to determine which names are valid and how |  | and allows that authority to determine which names are valid and how |
| they might be used. |  | they might be used. |
| When an "http" URI is used within a context that calls for access to |  | When an "http" URI is used within a context that calls for access to |
| the indicated resource, a client MAY attempt access by resolving the |  | the indicated resource, a client MAY attempt access by resolving the |
| host to an IP address, establishing a TCP connection to that address |  | host to an IP address, establishing a TCP connection to that address |
| on the indicated port, and sending an HTTP request message |  | on the indicated port, and sending an HTTP request message |
| (Section 3) containing the URI's identifying data (Section 5) to the |  | (Section 3) containing the URI's identifying data (Section 5) to the |
| server. If the server responds to that request with a non-interim |  | server. If the server responds to that request with a non-interim |
| HTTP response message, as described in Section 7 of [Part2], then |  | HTTP response message, as described in Section 6 of [Part2], then |
| that response is considered an authoritative answer to the client's |  | that response is considered an authoritative answer to the client's |
| request. |  | request. |
| Although HTTP is independent of the transport protocol, the "http" |  | Although HTTP is independent of the transport protocol, the "http" |
| scheme is specific to TCP-based services because the name delegation |  | scheme is specific to TCP-based services because the name delegation |
| process depends on TCP for establishing authority. An HTTP service |  | process depends on TCP for establishing authority. An HTTP service |
| based on some other underlying connection protocol would presumably |  | based on some other underlying connection protocol would presumably |
| be identified using a different URI scheme, just as the "https" |  | be identified using a different URI scheme, just as the "https" |
| scheme (below) is used for resources that require an end-to-end |  | scheme (below) is used for resources that require an end-to-end |
| secured connection. Other protocols might also be used to provide |  | secured connection. Other protocols might also be used to provide |
| access to "http" identified resources -- it is only the authoritative |  | access to "http" identified resources -- it is only the authoritative |
| interface used for mapping the namespace that is specific to TCP. |  | interface used for mapping the namespace that is specific to TCP. |
| The URI generic syntax for authority also includes a deprecated |  | The URI generic syntax for authority also includes a deprecated |
| userinfo subcomponent ([RFC3986], Section 3.2.1) for including user |  | userinfo subcomponent ([RFC3986], Section 3.2.1) for including user |
| authentication information in the URI. Some implementations make use |  | authentication information in the URI. Some implementations make use |
| of the userinfo component for internal configuration of |  | of the userinfo component for internal configuration of |
| authentication information, such as within command invocation |  | authentication information, such as within command invocation |
| options, configuration files, or bookmark lists, even though such |  | options, configuration files, or bookmark lists, even though such |
| usage might expose a user identifier or password. Senders MUST NOT |  | usage might expose a user identifier or password. Senders MUST |
| include a userinfo subcomponent (and its "@" delimiter) when |  | exclude the userinfo subcomponent (and its "@" delimiter) when an |
| transmitting an "http" URI in a message. Recipients of HTTP messages |  | "http" URI is transmitted within a message as a request target or |
| that contain a URI reference SHOULD parse for the existence of |  | header field value. Recipients of an "http" URI reference SHOULD |
| userinfo and treat its presence as an error, likely indicating that |  | parse for userinfo and treat its presence as an error, since it is |
| the deprecated subcomponent is being used to obscure the authority |  | likely being used to obscure the authority for the sake of phishing |
| for the sake of phishing attacks. |  | attacks. |
| 2.7.2. https URI scheme |  | 2.7.2. https URI scheme |
| The "https" URI scheme is hereby defined for the purpose of minting |  | The "https" URI scheme is hereby defined for the purpose of minting |
| identifiers according to their association with the hierarchical |  | identifiers according to their association with the hierarchical |
| namespace governed by a potential HTTP origin server listening to a |  | namespace governed by a potential HTTP origin server listening to a |
| given TCP port for TLS-secured connections [RFC5246]. |  | given TCP port for TLS-secured connections [RFC5246]. |
| All of the requirements listed above for the "http" scheme are also |  | All of the requirements listed above for the "http" scheme are also |
| requirements for the "https" scheme, except that a default TCP port |  | requirements for the "https" scheme, except that a default TCP port |
| of 443 is assumed if the port subcomponent is empty or not given, and |  | of 443 is assumed if the port subcomponent is empty or not given, and |
| the TCP connection MUST be secured, end-to-end, through the use of |  | the TCP connection MUST be secured, end-to-end, through the use of |
| strong encryption prior to sending the first HTTP request. |  | strong encryption prior to sending the first HTTP request. |
| https-URI = "https:" "//" authority path-abempty [ "?" query ] |  | https-URI = "https:" "//" authority path-abempty [ "?" query ] |
| Unlike the "http" scheme, responses to "https" identified requests |  |  |
| are never "public" and thus MUST NOT be reused for shared caching. |  |  |
| They can, however, be reused in a private cache if the message is |  |  |
| cacheable by default in HTTP or specifically indicated as such by the |  |  |
| Cache-Control header field (Section 7.2 of [Part6]). |  |  |
| Resources made available via the "https" scheme have no shared |  | Resources made available via the "https" scheme have no shared |
| identity with the "http" scheme even if their resource identifiers |  | identity with the "http" scheme even if their resource identifiers |
| indicate the same authority (the same host listening to the same TCP |  | indicate the same authority (the same host listening to the same TCP |
| port). They are distinct name spaces and are considered to be |  | port). They are distinct name spaces and are considered to be |
| distinct origin servers. However, an extension to HTTP that is |  | distinct origin servers. However, an extension to HTTP that is |
| defined to apply to entire host domains, such as the Cookie protocol |  | defined to apply to entire host domains, such as the Cookie protocol |
| [RFC6265], can allow information set by one service to impact |  | [RFC6265], can allow information set by one service to impact |
| communication with other services within a matching group of host |  | communication with other services within a matching group of host |
| domains. |  | domains. |
| skipping to change at page 18, line 26 |  | skipping to change at page 18, line 34 |
| resource is defined in [RFC2818]. |  | resource is defined in [RFC2818]. |
| 2.7.3. http and https URI Normalization and Comparison |  | 2.7.3. http and https URI Normalization and Comparison |
| Since the "http" and "https" schemes conform to the URI generic |  | Since the "http" and "https" schemes conform to the URI generic |
| syntax, such URIs are normalized and compared according to the |  | syntax, such URIs are normalized and compared according to the |
| algorithm defined in [RFC3986], Section 6, using the defaults |  | algorithm defined in [RFC3986], Section 6, using the defaults |
| described above for each scheme. |  | described above for each scheme. |
| If the port is equal to the default port for a scheme, the normal |  | If the port is equal to the default port for a scheme, the normal |
| form is to elide the port subcomponent. Likewise, an empty path |  | form is to elide the port subcomponent. When not being used in |
| component is equivalent to an absolute path of "/", so the normal |  | absolute form as the request target of an OPTIONS request, an empty |
| form is to provide a path of "/" instead. The scheme and host are |  | path component is equivalent to an absolute path of "/", so the |
| case-insensitive and normally provided in lowercase; all other |  | normal form is to provide a path of "/" instead. The scheme and host |
|  |  | are case-insensitive and normally provided in lowercase; all other |
| components are compared in a case-sensitive manner. Characters other |  | components are compared in a case-sensitive manner. Characters other |
| than those in the "reserved" set are equivalent to their percent- |  | than those in the "reserved" set are equivalent to their percent- |
| encoded octets (see [RFC3986], Section 2.1): the normal form is to |  | encoded octets (see [RFC3986], Section 2.1): the normal form is to |
| not encode them. |  | not encode them. |
| For example, the following three URIs are equivalent: |  | For example, the following three URIs are equivalent: |
| http://example.com:80/~smith/home.html |  | http://example.com:80/~smith/home.html |
| http://EXAMPLE.com/%7Esmith/home.html |  | http://EXAMPLE.com/%7Esmith/home.html |
| http://EXAMPLE.com:/%7esmith/home.html |  | http://EXAMPLE.com:/%7esmith/home.html |
| skipping to change at page 19, line 35 |  | skipping to change at page 19, line 48 |
| incremental delivery of partial messages, since some implementations |  | incremental delivery of partial messages, since some implementations |
| will buffer or delay message forwarding for the sake of network |  | will buffer or delay message forwarding for the sake of network |
| efficiency, security checks, or payload transformations. |  | efficiency, security checks, or payload transformations. |
| 3.1. Start Line |  | 3.1. Start Line |
| An HTTP message can either be a request from client to server or a |  | An HTTP message can either be a request from client to server or a |
| response from server to client. Syntactically, the two types of |  | response from server to client. Syntactically, the two types of |
| message differ only in the start-line, which is either a request-line |  | message differ only in the start-line, which is either a request-line |
| (for requests) or a status-line (for responses), and in the algorithm |  | (for requests) or a status-line (for responses), and in the algorithm |
| for determining the length of the message body (Section 3.3). In |  | for determining the length of the message body (Section 3.3). |
| theory, a client could receive requests and a server could receive |  |  |
|  |  | In theory, a client could receive requests and a server could receive |
| responses, distinguishing them by their different start-line formats, |  | responses, distinguishing them by their different start-line formats, |
| but in practice servers are implemented to only expect a request (a |  | but in practice servers are implemented to only expect a request (a |
| response is interpreted as an unknown or invalid request method) and |  | response is interpreted as an unknown or invalid request method) and |
| clients are implemented to only expect a response. |  | clients are implemented to only expect a response. |
| start-line = request-line / status-line |  | start-line = request-line / status-line |
| A sender MUST NOT send whitespace between the start-line and the |  | A sender MUST NOT send whitespace between the start-line and the |
| first header field. The presence of such whitespace in a request |  | first header field. The presence of such whitespace in a request |
| might be an attempt to trick a server into ignoring that field or |  | might be an attempt to trick a server into ignoring that field or |
| processing the line after it as a new request, either of which might |  | processing the line after it as a new request, either of which might |
| result in a security vulnerability if other implementations within |  | result in a security vulnerability if other implementations within |
| the request chain interpret the same message differently. Likewise, |  | the request chain interpret the same message differently. Likewise, |
| the presence of such whitespace in a response might be ignored by |  | the presence of such whitespace in a response might be ignored by |
| some clients or cause others to cease parsing. |  | some clients or cause others to cease parsing. |
|  |  | A recipient that receives whitespace between the start-line and the |
|  |  | first header field MUST either reject the message as invalid or |
|  |  | consume each whitespace-preceded line without further processing of |
|  |  | it (i.e., ignore the entire line, along with any subsequent lines |
|  |  | preceded by whitespace, until a properly formed header field is |
|  |  | received or the header block is terminated). |
| 3.1.1. Request Line |  | 3.1.1. Request Line |
| A request-line begins with a method token, followed by a single space |  | A request-line begins with a method token, followed by a single space |
| (SP), the request-target, another single space (SP), the protocol |  | (SP), the request-target, another single space (SP), the protocol |
| version, and ending with CRLF. |  | version, and ending with CRLF. |
| request-line = method SP request-target SP HTTP-version CRLF |  | request-line = method SP request-target SP HTTP-version CRLF |
| A server MUST be able to parse any received message that begins with |  |  |
| a request-line and matches the ABNF rule for HTTP-message. |  |  |
| The method token indicates the request method to be performed on the |  | The method token indicates the request method to be performed on the |
| target resource. The request method is case-sensitive. |  | target resource. The request method is case-sensitive. |
| method = token |  | method = token |
| The methods defined by this specification can be found in Section 5 |  | The methods defined by this specification can be found in Section 4 |
| of [Part2], along with information regarding the HTTP method registry |  | of [Part2], along with information regarding the HTTP method registry |
| and considerations for defining new methods. |  | and considerations for defining new methods. |
| The request-target identifies the target resource upon which to apply |  | The request-target identifies the target resource upon which to apply |
| the request, as defined in Section 5.3. |  | the request, as defined in Section 5.3. |
| No whitespace is allowed inside the method, request-target, and |  | No whitespace is allowed inside the method, request-target, and |
| protocol version. Hence, recipients typically parse the request-line |  | protocol version. Hence, recipients typically parse the request-line |
| into its component parts by splitting on the SP characters. |  | into its component parts by splitting on whitespace (see |
|  |  | Section 3.5). |
| Unfortunately, some user agents fail to properly encode hypertext |  | Unfortunately, some user agents fail to properly encode hypertext |
| references that have embedded whitespace, sending the characters |  | references that have embedded whitespace, sending the characters |
| directly instead of properly percent-encoding the disallowed |  | directly instead of properly encoding or excluding the disallowed |
| characters. Recipients of an invalid request-line SHOULD respond |  | characters. Recipients of an invalid request-line SHOULD respond |
| with either a 400 (Bad Request) error or a 301 (Moved Permanently) |  | with either a 400 (Bad Request) error or a 301 (Moved Permanently) |
| redirect with the request-target properly encoded. Recipients SHOULD |  | redirect with the request-target properly encoded. Recipients SHOULD |
| NOT attempt to autocorrect and then process the request without a |  | NOT attempt to autocorrect and then process the request without a |
| redirect, since the invalid request-line might be deliberately |  | redirect, since the invalid request-line might be deliberately |
| crafted to bypass security filters along the request chain. |  | crafted to bypass security filters along the request chain. |
| HTTP does not place a pre-defined limit on the length of a request- |  | HTTP does not place a pre-defined limit on the length of a request- |
| line. A server that receives a method longer than any that it |  | line. A server that receives a method longer than any that it |
| implements SHOULD respond with either a 405 (Method Not Allowed), if |  | implements SHOULD respond with a 501 (Not Implemented) status code. |
| it is an origin server, or a 501 (Not Implemented) status code. A |  | A server MUST be prepared to receive URIs of unbounded length and |
| server MUST be prepared to receive URIs of unbounded length and |  |  |
| respond with the 414 (URI Too Long) status code if the received |  | respond with the 414 (URI Too Long) status code if the received |
| request-target would be longer than the server wishes to handle (see |  | request-target would be longer than the server wishes to handle (see |
| Section 7.5.12 of [Part2]). |  | Section 6.5.12 of [Part2]). |
| Various ad-hoc limitations on request-line length are found in |  | Various ad-hoc limitations on request-line length are found in |
| practice. It is RECOMMENDED that all HTTP senders and recipients |  | practice. It is RECOMMENDED that all HTTP senders and recipients |
| support, at a minimum, request-line lengths of up to 8000 octets. |  | support, at a minimum, request-line lengths of 8000 octets. |
| 3.1.2. Status Line |  | 3.1.2. Status Line |
| The first line of a response message is the status-line, consisting |  | The first line of a response message is the status-line, consisting |
| of the protocol version, a space (SP), the status code, another |  | of the protocol version, a space (SP), the status code, another |
| space, a possibly-empty textual phrase describing the status code, |  | space, a possibly-empty textual phrase describing the status code, |
| and ending with CRLF. |  | and ending with CRLF. |
| status-line = HTTP-version SP status-code SP reason-phrase CRLF |  | status-line = HTTP-version SP status-code SP reason-phrase CRLF |
| A client MUST be able to parse any received message that begins with |  |  |
| a status-line and matches the ABNF rule for HTTP-message. |  |  |
| The status-code element is a 3-digit integer code describing the |  | The status-code element is a 3-digit integer code describing the |
| result of the server's attempt to understand and satisfy the client's |  | result of the server's attempt to understand and satisfy the client's |
| corresponding request. The rest of the response message is to be |  | corresponding request. The rest of the response message is to be |
| interpreted in light of the semantics defined for that status code. |  | interpreted in light of the semantics defined for that status code. |
| See Section 7 of [Part2] for information about the semantics of |  | See Section 6 of [Part2] for information about the semantics of |
| status codes, including the classes of status code (indicated by the |  | status codes, including the classes of status code (indicated by the |
| first digit), the status codes defined by this specification, |  | first digit), the status codes defined by this specification, |
| considerations for the definition of new status codes, and the IANA |  | considerations for the definition of new status codes, and the IANA |
| registry. |  | registry. |
| status-code = 3DIGIT |  | status-code = 3DIGIT |
| The reason-phrase element exists for the sole purpose of providing a |  | The reason-phrase element exists for the sole purpose of providing a |
| textual description associated with the numeric status code, mostly |  | textual description associated with the numeric status code, mostly |
| out of deference to earlier Internet application protocols that were |  | out of deference to earlier Internet application protocols that were |
| skipping to change at page 21, line 49 |  | skipping to change at page 22, line 16 |
| Each HTTP header field consists of a case-insensitive field name |  | Each HTTP header field consists of a case-insensitive field name |
| followed by a colon (":"), optional whitespace, and the field value. |  | followed by a colon (":"), optional whitespace, and the field value. |
| header-field = field-name ":" OWS field-value BWS |  | header-field = field-name ":" OWS field-value BWS |
| field-name = token |  | field-name = token |
| field-value = *( field-content / obs-fold ) |  | field-value = *( field-content / obs-fold ) |
| field-content = *( HTAB / SP / VCHAR / obs-text ) |  | field-content = *( HTAB / SP / VCHAR / obs-text ) |
| obs-fold = CRLF ( SP / HTAB ) |  | obs-fold = CRLF ( SP / HTAB ) |
| ; obsolete line folding |  | ; obsolete line folding |
| ; see Section 3.2.2 |  | ; see Section 3.2.4 |
| The field-name token labels the corresponding field-value as having |  | The field-name token labels the corresponding field-value as having |
| the semantics defined by that header field. For example, the Date |  | the semantics defined by that header field. For example, the Date |
| header field is defined in Section 8.1.1.2 of [Part2] as containing |  | header field is defined in Section 7.1.1.2 of [Part2] as containing |
| the origination timestamp for the message in which it appears. |  | the origination timestamp for the message in which it appears. |
|  |  | 3.2.1. Field Extensibility |
| HTTP header fields are fully extensible: there is no limit on the |  | HTTP header fields are fully extensible: there is no limit on the |
| introduction of new field names, each presumably defining new |  | introduction of new field names, each presumably defining new |
| semantics, or on the number of header fields used in a given message. |  | semantics, nor on the number of header fields used in a given |
| Existing fields are defined in each part of this specification and in |  | message. Existing fields are defined in each part of this |
| many other specifications outside the standards process. New header |  | specification and in many other specifications outside the core |
| fields can be introduced without changing the protocol version if |  | standard. New header fields can be introduced without changing the |
| their defined semantics allow them to be safely ignored by recipients |  | protocol version if their defined semantics allow them to be safely |
| that do not recognize them. |  | ignored by recipients that do not recognize them. |
| New HTTP header fields SHOULD be registered with IANA in the Message |  | New HTTP header fields ought to be be registered with IANA in the |
| Header Field Registry, as described in Section 9.3 of [Part2]. |  | Message Header Field Registry, as described in Section 8.3 of |
| Unrecognized header fields MUST be forwarded by a proxy unless the |  | [Part2]. A proxy MUST forward unrecognized header fields unless the |
| field-name is listed in the Connection header field (Section 6.1) or |  | field-name is listed in the Connection header field (Section 6.1) or |
| the proxy is specifically configured to block or otherwise transform |  | the proxy is specifically configured to block, or otherwise |
| such fields. Unrecognized header fields SHOULD be ignored by other |  | transform, such fields. Other recipients SHOULD ignore unrecognized |
| recipients. |  | header fields. |
|  |  | 3.2.2. Field Order |
| The order in which header fields with differing field names are |  | The order in which header fields with differing field names are |
| received is not significant. However, it is "good practice" to send |  | received is not significant. However, it is "good practice" to send |
| header fields that contain control data first, such as Host on |  | header fields that contain control data first, such as Host on |
| requests and Date on responses, so that implementations can decide |  | requests and Date on responses, so that implementations can decide |
| when not to handle a message as early as possible. A server MUST |  | when not to handle a message as early as possible. A server MUST |
| wait until the entire header section is received before interpreting |  | wait until the entire header section is received before interpreting |
| a request message, since later header fields might include |  | a request message, since later header fields might include |
| conditionals, authentication credentials, or deliberately misleading |  | conditionals, authentication credentials, or deliberately misleading |
| duplicate header fields that would impact request processing. |  | duplicate header fields that would impact request processing. |
| Multiple header fields with the same field name MUST NOT be sent in a |  | A sender MUST NOT generate multiple header fields with the same field |
| message unless the entire field value for that header field is |  | name in a message unless either the entire field value for that |
| defined as a comma-separated list [i.e., #(values)]. Multiple header |  | header field is defined as a comma-separated list [i.e., #(values)] |
| fields with the same field name can be combined into one "field-name: |  | or the header field is a well-known exception (as noted below). |
| field-value" pair, without changing the semantics of the message, by |  |  |
| appending each subsequent field value to the combined field value in |  |  |
| order, separated by a comma. The order in which header fields with |  |  |
| the same field name are received is therefore significant to the |  |  |
| interpretation of the combined field value; a proxy MUST NOT change |  |  |
| the order of these field values when forwarding a message. |  |  |
| Note: The "Set-Cookie" header field as implemented in practice can |  | Multiple header fields with the same field name can be combined into |
| occur multiple times, but does not use the list syntax, and thus |  | one "field-name: field-value" pair, without changing the semantics of |
| cannot be combined into a single line ([RFC6265]). (See Appendix |  | the message, by appending each subsequent field value to the combined |
| A.2.3 of [Kri2001] for details.) Also note that the Set-Cookie2 |  | field value in order, separated by a comma. The order in which |
| header field specified in [RFC2965] does not share this problem. |  | header fields with the same field name are received is therefore |
|  |  | significant to the interpretation of the combined field value; a |
|  |  | proxy MUST NOT change the order of these field values when forwarding |
|  |  | a message. |
| 3.2.1. Whitespace |  | Note: In practice, the "Set-Cookie" header field ([RFC6265]) often |
|  |  | appears multiple times in a response message and does not use the |
|  |  | list syntax, violating the above requirements on multiple header |
|  |  | fields with the same name. Since it cannot be combined into a |
|  |  | single field-value, recipients ought to handle "Set-Cookie" as a |
|  |  | special case while processing header fields. (See Appendix A.2.3 |
|  |  | of [Kri2001] for details.) |
|  |  | 3.2.3. Whitespace |
| This specification uses three rules to denote the use of linear |  | This specification uses three rules to denote the use of linear |
| whitespace: OWS (optional whitespace), RWS (required whitespace), and |  | whitespace: OWS (optional whitespace), RWS (required whitespace), and |
| BWS ("bad" whitespace). |  | BWS ("bad" whitespace). |
| The OWS rule is used where zero or more linear whitespace octets |  | The OWS rule is used where zero or more linear whitespace octets |
| might appear. OWS SHOULD either not be produced or be produced as a |  | might appear. OWS SHOULD either not be generated or be generated as |
| single SP. Multiple OWS octets that occur within field-content |  | a single SP. Multiple OWS octets that occur within field-content |
| SHOULD either be replaced with a single SP or transformed to all SP |  | SHOULD either be replaced with a single SP or transformed to all SP |
| octets (each octet other than SP replaced with SP) before |  | octets (each octet other than SP replaced with SP) before |
| interpreting the field value or forwarding the message downstream. |  | interpreting the field value or forwarding the message downstream. |
| RWS is used when at least one linear whitespace octet is required to |  | RWS is used when at least one linear whitespace octet is required to |
| separate field tokens. RWS SHOULD be produced as a single SP. |  | separate field tokens. RWS SHOULD be generated as a single SP. |
| Multiple RWS octets that occur within field-content SHOULD either be |  | Multiple RWS octets that occur within field-content SHOULD either be |
| replaced with a single SP or transformed to all SP octets before |  | replaced with a single SP or transformed to all SP octets before |
| interpreting the field value or forwarding the message downstream. |  | interpreting the field value or forwarding the message downstream. |
| BWS is used where the grammar allows optional whitespace, for |  | BWS is used where the grammar allows optional whitespace, for |
| historical reasons, but senders SHOULD NOT produce it in messages; |  | historical reasons, but senders SHOULD NOT generate it in messages; |
| recipients MUST accept such bad optional whitespace and remove it |  | recipients MUST accept such bad optional whitespace and remove it |
| before interpreting the field value or forwarding the message |  | before interpreting the field value or forwarding the message |
| downstream. |  | downstream. |
| OWS = *( SP / HTAB ) |  | OWS = *( SP / HTAB ) |
| ; "optional" whitespace |  | ; optional whitespace |
| RWS = 1*( SP / HTAB ) |  | RWS = 1*( SP / HTAB ) |
| ; "required" whitespace |  | ; required whitespace |
| BWS = OWS |  | BWS = OWS |
| ; "bad" whitespace |  | ; "bad" whitespace |
| 3.2.2. Field Parsing |  | 3.2.4. Field Parsing |
| No whitespace is allowed between the header field-name and colon. In |  | No whitespace is allowed between the header field-name and colon. In |
| the past, differences in the handling of such whitespace have led to |  | the past, differences in the handling of such whitespace have led to |
| security vulnerabilities in request routing and response handling. |  | security vulnerabilities in request routing and response handling. A |
| Any received request message that contains whitespace between a |  | server MUST reject any received request message that contains |
| header field-name and colon MUST be rejected with a response code of |  | whitespace between a header field-name and colon with a response code |
| 400 (Bad Request). A proxy MUST remove any such whitespace from a |  | of 400 (Bad Request). A proxy MUST remove any such whitespace from a |
| response message before forwarding the message downstream. |  | response message before forwarding the message downstream. |
| A field value MAY be preceded by optional whitespace (OWS); a single |  | A field value is preceded by optional whitespace (OWS); a single SP |
| SP is preferred. The field value does not include any leading or |  | is preferred. The field value does not include any leading or |
| trailing white space: OWS occurring before the first non-whitespace |  | trailing white space: OWS occurring before the first non-whitespace |
| octet of the field value or after the last non-whitespace octet of |  | octet of the field value or after the last non-whitespace octet of |
| the field value is ignored and SHOULD be removed before further |  | the field value is ignored and SHOULD be removed before further |
| processing (as this does not change the meaning of the header field). |  | processing (as this does not change the meaning of the header field). |
| Historically, HTTP header field values could be extended over |  | Historically, HTTP header field values could be extended over |
| multiple lines by preceding each extra line with at least one space |  | multiple lines by preceding each extra line with at least one space |
| or horizontal tab (obs-fold). This specification deprecates such |  | or horizontal tab (obs-fold). This specification deprecates such |
| line folding except within the message/http media type |  | line folding except within the message/http media type |
| (Section 7.3.1). HTTP senders MUST NOT produce messages that include |  | (Section 7.3.1). Senders MUST NOT generate messages that include |
| line folding (i.e., that contain any field-value that matches the |  | line folding (i.e., that contain any field-value that contains a |
| obs-fold rule) unless the message is intended for packaging within |  | match to the obs-fold rule) unless the message is intended for |
| the message/http media type. HTTP recipients SHOULD accept line |  | packaging within the message/http media type. When an obs-fold is |
| folding and replace any embedded obs-fold whitespace with either a |  | received in a message, recipients MUST do one of: |
| single SP or a matching number of SP octets (to avoid buffer copying) |  |  |
| prior to interpreting the field value or forwarding the message |  | o accept the message and replace any embedded obs-fold whitespace |
| downstream. |  | with either a single SP or a matching number of SP octets (to |
|  |  | avoid buffer copying) prior to interpreting the field value or |
|  |  | forwarding the message downstream; |
|  |  | o if it is a request, reject the message by sending a 400 (Bad |
|  |  | Request) response with a representation explaining that obsolete |
|  |  | line folding is unacceptable; or, |
|  |  | o if it is a response, discard the message and generate a 502 (Bad |
|  |  | Gateway) response with a representation explaining that |
|  |  | unacceptable line folding was received. |
|  |  | Recipients that choose not to implement obs-fold processing (as |
|  |  | described above) MUST NOT accept messages containing header fields |
|  |  | with leading whitespace, as this can expose them to attacks that |
|  |  | exploit this difference in processing. |
| Historically, HTTP has allowed field content with text in the ISO- |  | Historically, HTTP has allowed field content with text in the ISO- |
| 8859-1 [ISO-8859-1] character encoding and supported other character |  | 8859-1 [ISO-8859-1] charset, supporting other charsets only through |
| sets only through use of [RFC2047] encoding. In practice, most HTTP |  | use of [RFC2047] encoding. In practice, most HTTP header field |
| header field values use only a subset of the US-ASCII character |  | values use only a subset of the US-ASCII charset [USASCII]. Newly |
| encoding [USASCII]. Newly defined header fields SHOULD limit their |  | defined header fields SHOULD limit their field values to US-ASCII |
| field values to US-ASCII octets. Recipients SHOULD treat other (obs- |  | octets. Recipients SHOULD treat other octets in field content (obs- |
| text) octets in field content as opaque data. |  | text) as opaque data. |
| 3.2.3. Field Length |  | 3.2.5. Field Limits |
| HTTP does not place a pre-defined limit on the length of header |  | HTTP does not place a pre-defined limit on the length of each header |
| fields, either in isolation or as a set. A server MUST be prepared |  | field or on the length of the header block as a whole. Various ad- |
| to receive request header fields of unbounded length and respond with |  | hoc limitations on individual header field length are found in |
| a 4xx (Client Error) status code if the received header field(s) |  | practice, often depending on the specific field semantics. |
| would be longer than the server wishes to handle. |  |  |
| A client that receives response header fields that are longer than it |  | A server MUST be prepared to receive request header fields of |
| wishes to handle can only treat it as a server error. |  | unbounded length and respond with an appropriate 4xx (Client Error) |
|  |  | status code if the received header field(s) are larger than the |
|  |  | server wishes to process. |
| Various ad-hoc limitations on header field length are found in |  | A client MUST be prepared to receive response header fields of |
| practice. It is RECOMMENDED that all HTTP senders and recipients |  | unbounded length. A client MAY discard or truncate received header |
| support messages whose combined header fields have 4000 or more |  | fields that are larger than the client wishes to process if the field |
| octets. |  | semantics are such that the dropped value(s) can be safely ignored |
|  |  | without changing the response semantics. |
| 3.2.4. Field value components |  | 3.2.6. Field value components |
| Many HTTP header field values consist of words (token or quoted- |  | Many HTTP header field values consist of words (token or quoted- |
| string) separated by whitespace or special characters. These special |  | string) separated by whitespace or special characters. These special |
| characters MUST be in a quoted string to be used within a parameter |  | characters MUST be in a quoted string to be used within a parameter |
| value (as defined in Section 4). |  | value (as defined in Section 4). |
| word = token / quoted-string |  | word = token / quoted-string |
| token = 1*tchar |  | token = 1*tchar |
| skipping to change at page 25, line 22 |  | skipping to change at page 26, line 10 |
| ; any VCHAR, except special |  | ; any VCHAR, except special |
| special = "(" / ")" / "<" / ">" / "@" / "," |  | special = "(" / ")" / "<" / ">" / "@" / "," |
| / ";" / ":" / "\" / DQUOTE / "/" / "[" |  | / ";" / ":" / "\" / DQUOTE / "/" / "[" |
| / "]" / "?" / "=" / "{" / "}" |  | / "]" / "?" / "=" / "{" / "}" |
| A string of text is parsed as a single word if it is quoted using |  | A string of text is parsed as a single word if it is quoted using |
| double-quote marks. |  | double-quote marks. |
| quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE |  | quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE |
| qdtext = OWS / %x21 / %x23-5B / %x5D-7E / obs-text |  | qdtext = HTAB / SP /%x21 / %x23-5B / %x5D-7E / obs-text |
| obs-text = %x80-FF |  | obs-text = %x80-FF |
| The backslash octet ("\") can be used as a single-octet quoting |  | The backslash octet ("\") can be used as a single-octet quoting |
| mechanism within quoted-string constructs: |  | mechanism within quoted-string constructs: |
| quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text ) |  | quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text ) |
| Recipients that process the value of the quoted-string MUST handle a |  | Recipients that process the value of a quoted-string MUST handle a |
| quoted-pair as if it were replaced by the octet following the |  | quoted-pair as if it were replaced by the octet following the |
| backslash. |  | backslash. |
| Senders SHOULD NOT escape octets in quoted-strings that do not |  | Senders SHOULD NOT generate a quoted-pair in a quoted-string except |
| require escaping (i.e., other than DQUOTE and the backslash octet). |  | where necessary to quote DQUOTE and backslash octets occurring within |
|  |  | that string. |
| Comments can be included in some HTTP header fields by surrounding |  | Comments can be included in some HTTP header fields by surrounding |
| the comment text with parentheses. Comments are only allowed in |  | the comment text with parentheses. Comments are only allowed in |
| fields containing "comment" as part of their field value definition. |  | fields containing "comment" as part of their field value definition. |
| comment = "(" *( ctext / quoted-cpair / comment ) ")" |  | comment = "(" *( ctext / quoted-cpair / comment ) ")" |
| ctext = OWS / %x21-27 / %x2A-5B / %x5D-7E / obs-text |  | ctext = HTAB / SP / %x21-27 / %x2A-5B / %x5D-7E / obs-text |
| The backslash octet ("\") can be used as a single-octet quoting |  | The backslash octet ("\") can be used as a single-octet quoting |
| mechanism within comment constructs: |  | mechanism within comment constructs: |
| quoted-cpair = "\" ( HTAB / SP / VCHAR / obs-text ) |  | quoted-cpair = "\" ( HTAB / SP / VCHAR / obs-text ) |
| Senders SHOULD NOT escape octets in comments that do not require |  | Senders SHOULD NOT escape octets in comments that do not require |
| escaping (i.e., other than the backslash octet "\" and the |  | escaping (i.e., other than the backslash octet "\" and the |
| parentheses "(" and ")"). |  | parentheses "(" and ")"). |
| skipping to change at page 26, line 17 |  | skipping to change at page 27, line 6 |
| The message body (if any) of an HTTP message is used to carry the |  | The message body (if any) of an HTTP message is used to carry the |
| payload body of that request or response. The message body is |  | payload body of that request or response. The message body is |
| identical to the payload body unless a transfer coding has been |  | identical to the payload body unless a transfer coding has been |
| applied, as described in Section 3.3.1. |  | applied, as described in Section 3.3.1. |
| message-body = *OCTET |  | message-body = *OCTET |
| The rules for when a message body is allowed in a message differ for |  | The rules for when a message body is allowed in a message differ for |
| requests and responses. |  | requests and responses. |
| The presence of a message body in a request is signaled by a a |  | The presence of a message body in a request is signaled by a Content- |
| Content-Length or Transfer-Encoding header field. Request message |  | Length or Transfer-Encoding header field. Request message framing is |
| framing is independent of method semantics, even if the method does |  | independent of method semantics, even if the method does not define |
| not define any use for a message body. |  | any use for a message body. |
| The presence of a message body in a response depends on both the |  | The presence of a message body in a response depends on both the |
| request method to which it is responding and the response status code |  | request method to which it is responding and the response status code |
| (Section 3.1.2). Responses to the HEAD request method never include |  | (Section 3.1.2). Responses to the HEAD request method never include |
| a message body because the associated response header fields (e.g., |  | a message body because the associated response header fields (e.g., |
| Transfer-Encoding, Content-Length, etc.), if present, indicate only |  | Transfer-Encoding, Content-Length, etc.), if present, indicate only |
| what their values would have been if the request method had been GET |  | what their values would have been if the request method had been GET |
| (Section 5.3.2 of [Part2]). 2xx (Successful) responses to CONNECT |  | (Section 4.3.2 of [Part2]). 2xx (Successful) responses to CONNECT |
| switch to tunnel mode instead of having a message body (Section 5.3.6 |  | switch to tunnel mode instead of having a message body (Section 4.3.6 |
| of [Part2]). All 1xx (Informational), 204 (No Content), and 304 (Not |  | of [Part2]). All 1xx (Informational), 204 (No Content), and 304 (Not |
| Modified) responses MUST NOT include a message body. All other |  | Modified) responses do not include a message body. All other |
| responses do include a message body, although the body MAY be of zero |  | responses do include a message body, although the body might be of |
| length. |  | zero length. |
| 3.3.1. Transfer-Encoding |  | 3.3.1. Transfer-Encoding |
| When one or more transfer codings are applied to a payload body in |  | The Transfer-Encoding header field lists the transfer coding names |
| order to form the message body, a Transfer-Encoding header field MUST |  | corresponding to the sequence of transfer codings that have been (or |
| be sent in the message and MUST contain the list of corresponding |  | will be) applied to the payload body in order to form the message |
| transfer-coding names in the same order that they were applied. |  | body. Transfer codings are defined in Section 4. |
| Transfer codings are defined in Section 4. |  |  |
| Transfer-Encoding = 1#transfer-coding |  | Transfer-Encoding = 1#transfer-coding |
| Transfer-Encoding is analogous to the Content-Transfer-Encoding field |  | Transfer-Encoding is analogous to the Content-Transfer-Encoding field |
| of MIME, which was designed to enable safe transport of binary data |  | of MIME, which was designed to enable safe transport of binary data |
| over a 7-bit transport service ([RFC2045], Section 6). However, safe |  | over a 7-bit transport service ([RFC2045], Section 6). However, safe |
| transport has a different focus for an 8bit-clean transfer protocol. |  | transport has a different focus for an 8bit-clean transfer protocol. |
| In HTTP's case, Transfer-Encoding is primarily intended to accurately |  | In HTTP's case, Transfer-Encoding is primarily intended to accurately |
| delimit a dynamically generated payload and to distinguish payload |  | delimit a dynamically generated payload and to distinguish payload |
| encodings that are only applied for transport efficiency or security |  | encodings that are only applied for transport efficiency or security |
| from those that are characteristics of the target resource. |  | from those that are characteristics of the selected resource. |
| The "chunked" transfer-coding (Section 4.1) MUST be implemented by |  | All HTTP/1.1 recipients MUST implement the chunked transfer coding |
| all HTTP/1.1 recipients because it plays a crucial role in delimiting |  | (Section 4.1) because it plays a crucial role in framing messages |
| messages when the payload body size is not known in advance. When |  | when the payload body size is not known in advance. If chunked is |
| the "chunked" transfer-coding is used, it MUST be the last transfer- |  | applied to a payload body, the sender MUST NOT apply chunked more |
| coding applied to form the message body and MUST NOT be applied more |  | than once (i.e., chunking an already chunked message is not allowed). |
| than once in a message body. If any transfer-coding is applied to a |  | If any transfer coding is applied to a request payload body, the |
| request payload body, the final transfer-coding applied MUST be |  | sender MUST apply chunked as the final transfer coding to ensure that |
| "chunked". If any transfer-coding is applied to a response payload |  | the message is properly framed. If any transfer coding is applied to |
| body, then either the final transfer-coding applied MUST be "chunked" |  | a response payload body, the sender MUST either apply chunked as the |
| or the message MUST be terminated by closing the connection. |  | final transfer coding or terminate the message by closing the |
|  |  | connection. |
| For example, |  | For example, |
| Transfer-Encoding: gzip, chunked |  | Transfer-Encoding: gzip, chunked |
| indicates that the payload body has been compressed using the gzip |  | indicates that the payload body has been compressed using the gzip |
| coding and then chunked using the chunked coding while forming the |  | coding and then chunked using the chunked coding while forming the |
| message body. |  | message body. |
| If more than one Transfer-Encoding header field is present in a |  |  |
| message, the multiple field-values MUST be combined into one field- |  |  |
| value, according to the algorithm defined in Section 3.2, before |  |  |
| determining the message body length. |  |  |
| Unlike Content-Encoding (Section 3.1.2.1 of [Part2]), Transfer- |  | Unlike Content-Encoding (Section 3.1.2.1 of [Part2]), Transfer- |
| Encoding is a property of the message, not of the payload, and thus |  | Encoding is a property of the message, not of the representation, and |
| MAY be added or removed by any implementation along the request/ |  | any recipient along the request/response chain MAY decode the |
| response chain. Additional information about the encoding parameters |  | received transfer coding(s) or apply additional transfer coding(s) to |
| MAY be provided by other header fields not defined by this |  | the message body, assuming that corresponding changes are made to the |
| specification. |  | Transfer-Encoding field-value. Additional information about the |
|  |  | encoding parameters MAY be provided by other header fields not |
|  |  | defined by this specification. |
| Transfer-Encoding MAY be sent in a response to a HEAD request or in a |  | Transfer-Encoding MAY be sent in a response to a HEAD request or in a |
| 304 (Not Modified) response (Section 4.1 of [Part4]) to a GET |  | 304 (Not Modified) response (Section 4.1 of [Part4]) to a GET |
| request, neither of which includes a message body, to indicate that |  | request, neither of which includes a message body, to indicate that |
| the origin server would have applied a transfer coding to the message |  | the origin server would have applied a transfer coding to the message |
| body if the request had been an unconditional GET. This indication |  | body if the request had been an unconditional GET. This indication |
| is not required, however, because any recipient on the response chain |  | is not required, however, because any recipient on the response chain |
| (including the origin server) can remove transfer codings when they |  | (including the origin server) can remove transfer codings when they |
| are not needed. |  | are not needed. |
| Transfer-Encoding was added in HTTP/1.1. It is generally assumed |  | Transfer-Encoding was added in HTTP/1.1. It is generally assumed |
| that implementations advertising only HTTP/1.0 support will not |  | that implementations advertising only HTTP/1.0 support will not |
| understand how to process a transfer-encoded payload. A client MUST |  | understand how to process a transfer-encoded payload. A client MUST |
| NOT send a request containing Transfer-Encoding unless it knows the |  | NOT send a request containing Transfer-Encoding unless it knows the |
| server will handle HTTP/1.1 (or later) requests; such knowledge might |  | server will handle HTTP/1.1 (or later) requests; such knowledge might |
| be in the form of specific user configuration or by remembering the |  | be in the form of specific user configuration or by remembering the |
| version of a prior received response. A server MUST NOT send a |  | version of a prior received response. A server MUST NOT send a |
| response containing Transfer-Encoding unless the corresponding |  | response containing Transfer-Encoding unless the corresponding |
| request indicates HTTP/1.1 (or later). |  | request indicates HTTP/1.1 (or later). |
| A server that receives a request message with a transfer-coding it |  | A server that receives a request message with a transfer coding it |
| does not understand SHOULD respond with 501 (Not Implemented) and |  | does not understand SHOULD respond with 501 (Not Implemented). |
| then close the connection. |  |  |
| 3.3.2. Content-Length |  | 3.3.2. Content-Length |
| When a message is allowed to contain a message body, does not have a |  | When a message does not have a Transfer-Encoding header field, a |
| Transfer-Encoding header field, and has a payload body length that is |  | Content-Length header field can provide the anticipated size, as a |
| known to the sender before the message header section has been sent, |  | decimal number of octets, for a potential payload body. For messages |
| the sender SHOULD send a Content-Length header field to indicate the |  | that do include a payload body, the Content-Length field-value |
| length of the payload body as a decimal number of octets. |  | provides the framing information necessary for determining where the |
|  |  | body (and message) ends. For messages that do not include a payload |
|  |  | body, the Content-Length indicates the size of the selected |
|  |  | representation (Section 3 of [Part2]). |
| Content-Length = 1*DIGIT |  | Content-Length = 1*DIGIT |
| An example is |  | An example is |
| Content-Length: 3495 |  | Content-Length: 3495 |
| A sender MUST NOT send a Content-Length header field in any message |  | A sender MUST NOT send a Content-Length header field in any message |
| that contains a Transfer-Encoding header field. |  | that contains a Transfer-Encoding header field. |
|  |  | A user agent SHOULD send a Content-Length in a request message when |
|  |  | no Transfer-Encoding is sent and the request method defines a meaning |
|  |  | for an enclosed payload body. For example, a Content-Length header |
|  |  | field is normally sent in a POST request even when the value is 0 |
|  |  | (indicating an empty payload body). A user agent SHOULD NOT send a |
|  |  | Content-Length header field when the request message does not contain |
|  |  | a payload body and the method semantics do not anticipate such a |
|  |  | body. |
| A server MAY send a Content-Length header field in a response to a |  | A server MAY send a Content-Length header field in a response to a |
| HEAD request (Section 5.3.2 of [Part2]); a server MUST NOT send |  | HEAD request (Section 4.3.2 of [Part2]); a server MUST NOT send |
| Content-Length in such a response unless its field-value equals the |  | Content-Length in such a response unless its field-value equals the |
| decimal number of octets that would have been sent in the payload |  | decimal number of octets that would have been sent in the payload |
| body of a response if the same request had used the GET method. |  | body of a response if the same request had used the GET method. |
| A server MAY send a Content-Length header field in a 304 (Not |  | A server MAY send a Content-Length header field in a 304 (Not |
| Modified) response to a conditional GET request (Section 4.1 of |  | Modified) response to a conditional GET request (Section 4.1 of |
| [Part4]); a server MUST NOT send Content-Length in such a response |  | [Part4]); a server MUST NOT send Content-Length in such a response |
| unless its field-value equals the decimal number of octets that would |  | unless its field-value equals the decimal number of octets that would |
| have been sent in the payload body of a 200 (OK) response to the same |  | have been sent in the payload body of a 200 (OK) response to the same |
| request. |  | request. |
| A server MUST NOT send a Content-Length header field in any response |  | A server MUST NOT send a Content-Length header field in any response |
| with a status code of 1xx (Informational) or 204 (No Content). A |  | with a status code of 1xx (Informational) or 204 (No Content). A |
| server SHOULD NOT send a Content-Length header field in any 2xx |  | server SHOULD NOT send a Content-Length header field in any 2xx |
| (Successful) response to a CONNECT request (Section 5.3.6 of |  | (Successful) response to a CONNECT request (Section 4.3.6 of |
| [Part2]). |  | [Part2]). |
|  |  | Aside from the cases defined above, in the absence of Transfer- |
|  |  | Encoding, an origin server SHOULD send a Content-Length header field |
|  |  | when the payload body size is known prior to sending the complete |
|  |  | header block. This will allow downstream recipients to measure |
|  |  | transfer progress, know when a received message is complete, and |
|  |  | potentially reuse the connection for additional requests. |
| Any Content-Length field value greater than or equal to zero is |  | Any Content-Length field value greater than or equal to zero is |
| valid. Since there is no predefined limit to the length of an HTTP |  | valid. Since there is no predefined limit to the length of a |
| payload, recipients SHOULD anticipate potentially large decimal |  | payload, recipients SHOULD anticipate potentially large decimal |
| numerals and prevent parsing errors due to integer conversion |  | numerals and prevent parsing errors due to integer conversion |
| overflows (Section 8.6). |  | overflows (Section 8.3). |
| If a message is received that has multiple Content-Length header |  | If a message is received that has multiple Content-Length header |
| fields with field-values consisting of the same decimal value, or a |  | fields with field-values consisting of the same decimal value, or a |
| single Content-Length header field with a field value containing a |  | single Content-Length header field with a field value containing a |
| list of identical decimal values (e.g., "Content-Length: 42, 42"), |  | list of identical decimal values (e.g., "Content-Length: 42, 42"), |
| indicating that duplicate Content-Length header fields have been |  | indicating that duplicate Content-Length header fields have been |
| generated or combined by an upstream message processor, then the |  | generated or combined by an upstream message processor, then the |
| recipient MUST either reject the message as invalid or replace the |  | recipient MUST either reject the message as invalid or replace the |
| duplicated field-values with a single valid Content-Length field |  | duplicated field-values with a single valid Content-Length field |
| containing that decimal value prior to determining the message body |  | containing that decimal value prior to determining the message body |
| skipping to change at page 29, line 38 |  | skipping to change at page 30, line 44 |
| code is always terminated by the first empty line after the |  | code is always terminated by the first empty line after the |
| header fields, regardless of the header fields present in the |  | header fields, regardless of the header fields present in the |
| message, and thus cannot contain a message body. |  | message, and thus cannot contain a message body. |
| 2. Any 2xx (Successful) response to a CONNECT request implies that |  | 2. Any 2xx (Successful) response to a CONNECT request implies that |
| the connection will become a tunnel immediately after the empty |  | the connection will become a tunnel immediately after the empty |
| line that concludes the header fields. A client MUST ignore any |  | line that concludes the header fields. A client MUST ignore any |
| Content-Length or Transfer-Encoding header fields received in |  | Content-Length or Transfer-Encoding header fields received in |
| such a message. |  | such a message. |
| 3. If a Transfer-Encoding header field is present and the "chunked" |  | 3. If a Transfer-Encoding header field is present and the chunked |
| transfer-coding (Section 4.1) is the final encoding, the message |  | transfer coding (Section 4.1) is the final encoding, the message |
| body length is determined by reading and decoding the chunked |  | body length is determined by reading and decoding the chunked |
| data until the transfer-coding indicates the data is complete. |  | data until the transfer coding indicates the data is complete. |
| If a Transfer-Encoding header field is present in a response and |  | If a Transfer-Encoding header field is present in a response and |
| the "chunked" transfer-coding is not the final encoding, the |  | the chunked transfer coding is not the final encoding, the |
| message body length is determined by reading the connection until |  | message body length is determined by reading the connection until |
| it is closed by the server. If a Transfer-Encoding header field |  | it is closed by the server. If a Transfer-Encoding header field |
| is present in a request and the "chunked" transfer-coding is not |  | is present in a request and the chunked transfer coding is not |
| the final encoding, the message body length cannot be determined |  | the final encoding, the message body length cannot be determined |
| reliably; the server MUST respond with the 400 (Bad Request) |  | reliably; the server MUST respond with the 400 (Bad Request) |
| status code and then close the connection. |  | status code and then close the connection. |
| If a message is received with both a Transfer-Encoding and a |  | If a message is received with both a Transfer-Encoding and a |
| Content-Length header field, the Transfer-Encoding overrides the |  | Content-Length header field, the Transfer-Encoding overrides the |
| Content-Length. Such a message might indicate an attempt to |  | Content-Length. Such a message might indicate an attempt to |
| perform request or response smuggling (bypass of security-related |  | perform request or response smuggling (bypass of security-related |
| checks on message routing or content) and thus ought to be |  | checks on message routing or content) and thus ought to be |
| handled as an error. The provided Content-Length MUST be |  | handled as an error. A sender MUST remove the received Content- |
| removed, prior to forwarding the message downstream, or replaced |  | Length field prior to forwarding such a message downstream. |
| with the real message body length after the transfer-coding is |  |  |
| decoded. |  |  |
| 4. If a message is received without Transfer-Encoding and with |  | 4. If a message is received without Transfer-Encoding and with |
| either multiple Content-Length header fields having differing |  | either multiple Content-Length header fields having differing |
| field-values or a single Content-Length header field having an |  | field-values or a single Content-Length header field having an |
| invalid value, then the message framing is invalid and MUST be |  | invalid value, then the message framing is invalid and MUST be |
| treated as an error to prevent request or response smuggling. If |  | treated as an error to prevent request or response smuggling. If |
| this is a request message, the server MUST respond with a 400 |  | this is a request message, the server MUST respond with a 400 |
| (Bad Request) status code and then close the connection. If this |  | (Bad Request) status code and then close the connection. If this |
| is a response message received by a proxy, the proxy MUST discard |  | is a response message received by a proxy, the proxy MUST discard |
| the received response, send a 502 (Bad Gateway) status code as |  | the received response, send a 502 (Bad Gateway) status code as |
| its downstream response, and then close the connection. If this |  | its downstream response, and then close the connection. If this |
| is a response message received by a user-agent, it MUST be |  | is a response message received by a user agent, it MUST be |
| treated as an error by discarding the message and closing the |  | treated as an error by discarding the message and closing the |
| connection. |  | connection. |
| 5. If a valid Content-Length header field is present without |  | 5. If a valid Content-Length header field is present without |
| Transfer-Encoding, its decimal value defines the message body |  | Transfer-Encoding, its decimal value defines the expected message |
| length in octets. If the actual number of octets sent in the |  | body length in octets. If the sender closes the connection or |
| message is less than the indicated Content-Length, the recipient |  | the recipient times out before the indicated number of octets are |
| MUST consider the message to be incomplete and treat the |  | received, the recipient MUST consider the message to be |
| connection as no longer usable. If the actual number of octets |  | incomplete and close the connection. |
| sent in the message is more than the indicated Content-Length, |  |  |
| the recipient MUST only process the message body up to the field |  |  |
| value's number of octets; the remainder of the message MUST |  |  |
| either be discarded or treated as the next message in a pipeline. |  |  |
| For the sake of robustness, a user-agent MAY attempt to detect |  |  |
| and correct such an error in message framing if it is parsing the |  |  |
| response to the last request on a connection and the connection |  |  |
| has been closed by the server. |  |  |
| 6. If this is a request message and none of the above are true, then |  | 6. If this is a request message and none of the above are true, then |
| the message body length is zero (no message body is present). |  | the message body length is zero (no message body is present). |
| 7. Otherwise, this is a response message without a declared message |  | 7. Otherwise, this is a response message without a declared message |
| body length, so the message body length is determined by the |  | body length, so the message body length is determined by the |
| number of octets received prior to the server closing the |  | number of octets received prior to the server closing the |
| connection. |  | connection. |
| Since there is no way to distinguish a successfully completed, close- |  | Since there is no way to distinguish a successfully completed, close- |
| delimited message from a partially-received message interrupted by |  | delimited message from a partially-received message interrupted by |
| network failure, a server SHOULD use encoding or length-delimited |  | network failure, a server SHOULD use encoding or length-delimited |
| messages whenever possible. The close-delimiting feature exists |  | messages whenever possible. The close-delimiting feature exists |
| primarily for backwards compatibility with HTTP/1.0. |  | primarily for backwards compatibility with HTTP/1.0. |
| A server MAY reject a request that contains a message body but not a |  | A server MAY reject a request that contains a message body but not a |
| Content-Length by responding with 411 (Length Required). |  | Content-Length by responding with 411 (Length Required). |
| Unless a transfer-coding other than "chunked" has been applied, a |  | Unless a transfer coding other than chunked has been applied, a |
| client that sends a request containing a message body SHOULD use a |  | client that sends a request containing a message body SHOULD use a |
| valid Content-Length header field if the message body length is known |  | valid Content-Length header field if the message body length is known |
| in advance, rather than the "chunked" encoding, since some existing |  | in advance, rather than the chunked transfer coding, since some |
| services respond to "chunked" with a 411 (Length Required) status |  | existing services respond to chunked with a 411 (Length Required) |
| code even though they understand the chunked encoding. This is |  | status code even though they understand the chunked transfer coding. |
| typically because such services are implemented via a gateway that |  | This is typically because such services are implemented via a gateway |
| requires a content-length in advance of being called and the server |  | that requires a content-length in advance of being called and the |
| is unable or unwilling to buffer the entire request before |  | server is unable or unwilling to buffer the entire request before |
| processing. |  | processing. |
| A client that sends a request containing a message body MUST include |  | A user agent that sends a request containing a message body MUST send |
| a valid Content-Length header field if it does not know the server |  | a valid Content-Length header field if it does not know the server |
| will handle HTTP/1.1 (or later) requests; such knowledge can be in |  | will handle HTTP/1.1 (or later) requests; such knowledge can be in |
| the form of specific user configuration or by remembering the version |  | the form of specific user configuration or by remembering the version |
| of a prior received response. |  | of a prior received response. |
|  |  | If the final response to the last request on a connection has been |
|  |  | completely received and there remains additional data to read, a user |
|  |  | agent MAY discard the remaining data or attempt to determine if that |
|  |  | data belongs as part of the prior response body, which might be the |
|  |  | case if the prior message's Content-Length value is incorrect. A |
|  |  | client MUST NOT process, cache, or forward such extra data as a |
|  |  | separate response, since such behavior would be vulnerable to cache |
|  |  | poisoning. |
| 3.4. Handling Incomplete Messages |  | 3.4. Handling Incomplete Messages |
| Request messages that are prematurely terminated, possibly due to a |  | A server that receives an incomplete request message, usually due to |
| canceled connection or a server-imposed time-out exception, MUST |  | a canceled request or a triggered time-out exception, MAY send an |
| result in closure of the connection; sending an error response prior |  | error response prior to closing the connection. |
| to closing the connection is OPTIONAL. |  |  |
| Response messages that are prematurely terminated, usually by closure |  | A client that receives an incomplete response message, which can |
| of the connection prior to receiving the expected number of octets or |  | occur when a connection is closed prematurely or when decoding a |
| by failure to decode a transfer-encoded message body, MUST be |  | supposedly chunked transfer coding fails, MUST record the message as |
| recorded as incomplete. A response that terminates in the middle of |  | incomplete. Cache requirements for incomplete responses are defined |
| the header block (before the empty line is received) cannot be |  | in Section 3 of [Part6]. |
| assumed to convey the full semantics of the response and MUST be |  |  |
| treated as an error. |  |  |
| A message body that uses the chunked transfer encoding is incomplete |  | If a response terminates in the middle of the header block (before |
| if the zero-sized chunk that terminates the encoding has not been |  | the empty line is received) and the status code might rely on header |
|  |  | fields to convey the full meaning of the response, then the client |
|  |  | cannot assume that meaning has been conveyed; the client might need |
|  |  | to repeat the request in order to determine what action to take next. |
|  |  | A message body that uses the chunked transfer coding is incomplete if |
|  |  | the zero-sized chunk that terminates the encoding has not been |
| received. A message that uses a valid Content-Length is incomplete |  | received. A message that uses a valid Content-Length is incomplete |
| if the size of the message body received (in octets) is less than the |  | if the size of the message body received (in octets) is less than the |
| value given by Content-Length. A response that has neither chunked |  | value given by Content-Length. A response that has neither chunked |
| transfer encoding nor Content-Length is terminated by closure of the |  | transfer coding nor Content-Length is terminated by closure of the |
| connection, and thus is considered complete regardless of the number |  | connection, and thus is considered complete regardless of the number |
| of message body octets received, provided that the header block was |  | of message body octets received, provided that the header block was |
| received intact. |  | received intact. |
| A user agent MUST NOT render an incomplete response message body as |  |  |
| if it were complete (i.e., some indication needs to be given to the |  |  |
| user that an error occurred). Cache requirements for incomplete |  |  |
| responses are defined in Section 3 of [Part6]. |  |  |
| A server MUST read the entire request message body or close the |  |  |
| connection after sending its response, since otherwise the remaining |  |  |
| data on a persistent connection would be misinterpreted as the next |  |  |
| request. Likewise, a client MUST read the entire response message |  |  |
| body if it intends to reuse the same connection for a subsequent |  |  |
| request. Pipelining multiple requests on a connection is described |  |  |
| in Section 6.2.2.1. |  |  |
| 3.5. Message Parsing Robustness |  | 3.5. Message Parsing Robustness |
| Older HTTP/1.0 client implementations might send an extra CRLF after |  | Older HTTP/1.0 user agent implementations might send an extra CRLF |
| a POST request as a lame workaround for some early server |  | after a POST request as a lame workaround for some early server |
| applications that failed to read message body content that was not |  | applications that failed to read message body content that was not |
| terminated by a line-ending. An HTTP/1.1 client MUST NOT preface or |  | terminated by a line-ending. An HTTP/1.1 user agent MUST NOT preface |
| follow a request with an extra CRLF. If terminating the request |  | or follow a request with an extra CRLF. If terminating the request |
| message body with a line-ending is desired, then the client MUST |  | message body with a line-ending is desired, then the user agent MUST |
| include the terminating CRLF octets as part of the message body |  | count the terminating CRLF octets as part of the message body length. |
| length. |  |  |
| In the interest of robustness, servers SHOULD ignore at least one |  | In the interest of robustness, servers SHOULD ignore at least one |
| empty line received where a request-line is expected. In other |  | empty line received where a request-line is expected. In other |
| words, if the server is reading the protocol stream at the beginning |  | words, if a server is reading the protocol stream at the beginning of |
| of a message and receives a CRLF first, it SHOULD ignore the CRLF. |  | a message and receives a CRLF first, the server SHOULD ignore the |
| Likewise, although the line terminator for the start-line and header |  | CRLF. |
| fields is the sequence CRLF, we recommend that recipients recognize a |  |  |
| single LF as a line terminator and ignore any CR. |  | Although the line terminator for the start-line and header fields is |
|  |  | the sequence CRLF, recipients MAY recognize a single LF as a line |
|  |  | terminator and ignore any preceding CR. |
|  |  | Although the request-line and status-line grammar rules require that |
|  |  | each of the component elements be separated by a single SP octet, |
|  |  | recipients MAY instead parse on whitespace-delimited word boundaries |
|  |  | and, aside from the CRLF terminator, treat any form of whitespace as |
|  |  | the SP separator while ignoring preceding or trailing whitespace; |
|  |  | such whitespace includes one or more of the following octets: SP, |
|  |  | HTAB, VT (%x0B), FF (%x0C), or bare CR. |
| When a server listening only for HTTP request messages, or processing |  | When a server listening only for HTTP request messages, or processing |
| what appears from the start-line to be an HTTP request message, |  | what appears from the start-line to be an HTTP request message, |
| receives a sequence of octets that does not match the HTTP-message |  | receives a sequence of octets that does not match the HTTP-message |
| grammar aside from the robustness exceptions listed above, the server |  | grammar aside from the robustness exceptions listed above, the server |
| MUST respond with an HTTP/1.1 400 (Bad Request) response. |  | SHOULD respond with a 400 (Bad Request) response. |
| 4. Transfer Codings |  | 4. Transfer Codings |
| Transfer-coding values are used to indicate an encoding |  | Transfer coding names are used to indicate an encoding transformation |
| transformation that has been, can be, or might need to be applied to |  | that has been, can be, or might need to be applied to a payload body |
| a payload body in order to ensure "safe transport" through the |  | in order to ensure "safe transport" through the network. This |
| network. This differs from a content coding in that the transfer- |  | differs from a content coding in that the transfer coding is a |
| coding is a property of the message rather than a property of the |  | property of the message rather than a property of the representation |
| representation that is being transferred. |  | that is being transferred. |
| transfer-coding = "chunked" ; Section 4.1 |  | transfer-coding = "chunked" ; Section 4.1 |
| / "compress" ; Section 4.2.1 |  | / "compress" ; Section 4.2.1 |
| / "deflate" ; Section 4.2.2 |  | / "deflate" ; Section 4.2.2 |
| / "gzip" ; Section 4.2.3 |  | / "gzip" ; Section 4.2.3 |
| / transfer-extension |  | / transfer-extension |
| transfer-extension = token *( OWS ";" OWS transfer-parameter ) |  | transfer-extension = token *( OWS ";" OWS transfer-parameter ) |
| Parameters are in the form of attribute/value pairs. |  | Parameters are in the form of attribute/value pairs. |
| transfer-parameter = attribute BWS "=" BWS value |  | transfer-parameter = attribute BWS "=" BWS value |
| attribute = token |  | attribute = token |
| value = word |  | value = word |
| All transfer-coding values are case-insensitive and SHOULD be |  | All transfer-coding names are case-insensitive and ought to be |
| registered within the HTTP Transfer Coding registry, as defined in |  | registered within the HTTP Transfer Coding registry, as defined in |
| Section 7.4. They are used in the TE (Section 4.3) and Transfer- |  | Section 7.4. They are used in the TE (Section 4.3) and Transfer- |
| Encoding (Section 3.3.1) header fields. |  | Encoding (Section 3.3.1) header fields. |
| 4.1. Chunked Transfer Coding |  | 4.1. Chunked Transfer Coding |
| The chunked encoding modifies the body of a message in order to |  | The chunked transfer coding modifies the body of a message in order |
| transfer it as a series of chunks, each with its own size indicator, |  | to transfer it as a series of chunks, each with its own size |
| followed by an OPTIONAL trailer containing header fields. This |  | indicator, followed by an OPTIONAL trailer containing header fields. |
| allows dynamically produced content to be transferred along with the |  | This allows dynamically generated content to be transferred along |
| information necessary for the recipient to verify that it has |  | with the information necessary for the recipient to verify that it |
| received the full message. |  | has received the full message. |
| chunked-body = *chunk |  | chunked-body = *chunk |
| last-chunk |  | last-chunk |
| trailer-part |  | trailer-part |
| CRLF |  | CRLF |
| chunk = chunk-size [ chunk-ext ] CRLF |  | chunk = chunk-size [ chunk-ext ] CRLF |
| chunk-data CRLF |  | chunk-data CRLF |
| chunk-size = 1*HEXDIG |  | chunk-size = 1*HEXDIG |
| last-chunk = 1*("0") [ chunk-ext ] CRLF |  | last-chunk = 1*("0") [ chunk-ext ] CRLF |
| skipping to change at page 33, line 52 |  | skipping to change at page 35, line 25 |
| chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-val ] ) |  | chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-val ] ) |
| chunk-ext-name = token |  | chunk-ext-name = token |
| chunk-ext-val = token / quoted-str-nf |  | chunk-ext-val = token / quoted-str-nf |
| chunk-data = 1*OCTET ; a sequence of chunk-size octets |  | chunk-data = 1*OCTET ; a sequence of chunk-size octets |
| trailer-part = *( header-field CRLF ) |  | trailer-part = *( header-field CRLF ) |
| quoted-str-nf = DQUOTE *( qdtext-nf / quoted-pair ) DQUOTE |  | quoted-str-nf = DQUOTE *( qdtext-nf / quoted-pair ) DQUOTE |
| ; like quoted-string, but disallowing line folding |  | ; like quoted-string, but disallowing line folding |
| qdtext-nf = HTAB / SP / %x21 / %x23-5B / %x5D-7E / obs-text |  | qdtext-nf = HTAB / SP / %x21 / %x23-5B / %x5D-7E / obs-text |
| Chunk extensions within the chucked encoding are deprecated. Senders |  | Chunk extensions within the chunked transfer coding are deprecated. |
| SHOULD NOT send chunk-ext. Definition of new chunk extensions is |  | Senders SHOULD NOT send chunk-ext. Definition of new chunk |
| discouraged. |  | extensions is discouraged. |
| The chunk-size field is a string of hex digits indicating the size of |  | The chunk-size field is a string of hex digits indicating the size of |
| the chunk-data in octets. The chunked encoding is ended by any chunk |  | the chunk-data in octets. The chunked transfer coding is complete |
| whose size is zero, followed by the trailer, which is terminated by |  | when a chunk with a chunk-size of zero is received, possibly followed |
| an empty line. |  | by a trailer, and finally terminated by an empty line. |
| 4.1.1. Trailer |  | 4.1.1. Trailer |
| A trailer allows the sender to include additional fields at the end |  | A trailer allows the sender to include additional fields at the end |
| of a chunked message in order to supply metadata that might be |  | of a chunked message in order to supply metadata that might be |
| dynamically generated while the message body is sent, such as a |  | dynamically generated while the message body is sent, such as a |
| message integrity check, digital signature, or post-processing |  | message integrity check, digital signature, or post-processing |
| status. The trailer MUST NOT contain fields that need to be known |  | status. The trailer MUST NOT contain fields that need to be known |
| before a recipient processes the body, such as Transfer-Encoding, |  | before a recipient processes the body, such as Transfer-Encoding, |
| Content-Length, and Trailer. |  | Content-Length, and Trailer. |
| When a message includes a message body encoded with the chunked |  | When a message includes a message body encoded with the chunked |
| transfer-coding and the sender desires to send metadata in the form |  | transfer coding and the sender desires to send metadata in the form |
| of trailer fields at the end of the message, the sender SHOULD send a |  | of trailer fields at the end of the message, the sender SHOULD send a |
| Trailer header field before the message body to indicate which fields |  | Trailer header field before the message body to indicate which fields |
| will be present in the trailers. This allows the recipient to |  | will be present in the trailers. This allows the recipient to |
| prepare for receipt of that metadata before it starts processing the |  | prepare for receipt of that metadata before it starts processing the |
| body, which is useful if the message is being streamed and the |  | body, which is useful if the message is being streamed and the |
| recipient wishes to confirm an integrity check on the fly. |  | recipient wishes to confirm an integrity check on the fly. |
| Trailer = 1#field-name |  | Trailer = 1#field-name |
| If no Trailer header field is present, the sender of a chunked |  | If no Trailer header field is present, the sender of a chunked |
| message body SHOULD send an empty trailer. |  | message body SHOULD send an empty trailer. |
| A server MUST send an empty trailer with the chunked transfer-coding |  | A server MUST send an empty trailer with the chunked transfer coding |
| unless at least one of the following is true: |  | unless at least one of the following is true: |
| 1. the request included a TE header field that indicates "trailers" |  | 1. the request included a TE header field that indicates "trailers" |
| is acceptable in the transfer-coding of the response, as |  | is acceptable in the transfer coding of the response, as |
| described in Section 4.3; or, |  | described in Section 4.3; or, |
| 2. the trailer fields consist entirely of optional metadata and the |  | 2. the trailer fields consist entirely of optional metadata and the |
| recipient could use the message (in a manner acceptable to the |  | recipient could use the message (in a manner acceptable to the |
| server where the field originated) without receiving that |  | server where the field originated) without receiving that |
| metadata. In other words, the server that generated the header |  | metadata. In other words, the server that generated the header |
| field is willing to accept the possibility that the trailer |  | field is willing to accept the possibility that the trailer |
| fields might be silently discarded along the path to the client. |  | fields might be silently discarded along the path to the client. |
| The above requirement prevents the need for an infinite buffer when a |  | The above requirement prevents the need for an infinite buffer when a |
| message is being received by an HTTP/1.1 (or later) proxy and |  | message is being received by an HTTP/1.1 (or later) proxy and |
| forwarded to an HTTP/1.0 recipient. |  | forwarded to an HTTP/1.0 recipient. |
| 4.1.2. Decoding chunked |  | 4.1.2. Decoding chunked |
| A process for decoding the "chunked" transfer-coding can be |  | A process for decoding the chunked transfer coding can be represented |
| represented in pseudo-code as: |  | in pseudo-code as: |
| length := 0 |  | length := 0 |
| read chunk-size, chunk-ext (if any) and CRLF |  | read chunk-size, chunk-ext (if any) and CRLF |
| while (chunk-size > 0) { |  | while (chunk-size > 0) { |
| read chunk-data and CRLF |  | read chunk-data and CRLF |
| append chunk-data to decoded-body |  | append chunk-data to decoded-body |
| length := length + chunk-size |  | length := length + chunk-size |
| read chunk-size and CRLF |  | read chunk-size and CRLF |
| } |  | } |
| read header-field |  | read header-field |
| while (header-field not empty) { |  | while (header-field not empty) { |
| append header-field to existing header fields |  | append header-field to existing header fields |
| read header-field |  | read header-field |
| } |  | } |
| Content-Length := length |  | Content-Length := length |
| Remove "chunked" from Transfer-Encoding |  | Remove "chunked" from Transfer-Encoding |
| Remove Trailer from existing header fields |  | Remove Trailer from existing header fields |
| All recipients MUST be able to receive and decode the "chunked" |  | All recipients MUST be able to receive and decode the chunked |
| transfer-coding and MUST ignore chunk-ext extensions they do not |  | transfer coding and MUST ignore chunk-ext extensions they do not |
| understand. |  | understand. |
| 4.2. Compression Codings |  | 4.2. Compression Codings |
| The codings defined below can be used to compress the payload of a |  | The codings defined below can be used to compress the payload of a |
| message. |  | message. |
| 4.2.1. Compress Coding |  | 4.2.1. Compress Coding |
| The "compress" format is produced by the common UNIX file compression |  | The "compress" format is produced by the common UNIX file compression |
| skipping to change at page 36, line 17 |  | skipping to change at page 37, line 35 |
| 4.2.3. Gzip Coding |  | 4.2.3. Gzip Coding |
| The "gzip" format is produced by the file compression program "gzip" |  | The "gzip" format is produced by the file compression program "gzip" |
| (GNU zip), as described in [RFC1952]. This format is a Lempel-Ziv |  | (GNU zip), as described in [RFC1952]. This format is a Lempel-Ziv |
| coding (LZ77) with a 32 bit CRC. Recipients SHOULD consider "x-gzip" |  | coding (LZ77) with a 32 bit CRC. Recipients SHOULD consider "x-gzip" |
| to be equivalent to "gzip". |  | to be equivalent to "gzip". |
| 4.3. TE |  | 4.3. TE |
| The "TE" header field in a request indicates what transfer-codings, |  | The "TE" header field in a request indicates what transfer codings, |
| besides "chunked", the client is willing to accept in response, and |  | besides chunked, the client is willing to accept in response, and |
| whether or not the client is willing to accept trailer fields in a |  | whether or not the client is willing to accept trailer fields in a |
| chunked transfer-coding. |  | chunked transfer coding. |
| The TE field-value consists of a comma-separated list of transfer- |  | The TE field-value consists of a comma-separated list of transfer |
| coding names, each allowing for optional parameters (as described in |  | coding names, each allowing for optional parameters (as described in |
| Section 4), and/or the keyword "trailers". Clients MUST NOT send the |  | Section 4), and/or the keyword "trailers". Clients MUST NOT send the |
| chunked transfer-coding name in TE; chunked is always acceptable for |  | chunked transfer coding name in TE; chunked is always acceptable for |
| HTTP/1.1 recipients. |  | HTTP/1.1 recipients. |
| TE = #t-codings |  | TE = #t-codings |
| t-codings = "trailers" / ( transfer-coding [ t-ranking ] ) |  | t-codings = "trailers" / ( transfer-coding [ t-ranking ] ) |
| t-ranking = OWS ";" OWS "q=" rank |  | t-ranking = OWS ";" OWS "q=" rank |
| rank = ( "0" [ "." 0*3DIGIT ] ) |  | rank = ( "0" [ "." 0*3DIGIT ] ) |
| / ( "1" [ "." 0*3("0") ] ) |  | / ( "1" [ "." 0*3("0") ] ) |
| Three examples of TE use are below. |  | Three examples of TE use are below. |
| TE: deflate |  | TE: deflate |
| TE: |  | TE: |
| TE: trailers, deflate;q=0.5 |  | TE: trailers, deflate;q=0.5 |
| The presence of the keyword "trailers" indicates that the client is |  | The presence of the keyword "trailers" indicates that the client is |
| willing to accept trailer fields in a chunked transfer-coding, as |  | willing to accept trailer fields in a chunked transfer coding, as |
| defined in Section 4.1, on behalf of itself and any downstream |  | defined in Section 4.1, on behalf of itself and any downstream |
| clients. For chained requests, this implies that either: (a) all |  | clients. For chained requests, this implies that either: (a) all |
| downstream clients are willing to accept trailer fields in the |  | downstream clients are willing to accept trailer fields in the |
| forwarded response; or, (b) the client will attempt to buffer the |  | forwarded response; or, (b) the client will attempt to buffer the |
| response on behalf of downstream recipients. Note that HTTP/1.1 does |  | response on behalf of downstream recipients. Note that HTTP/1.1 does |
| not define any means to limit the size of a chunked response such |  | not define any means to limit the size of a chunked response such |
| that a client can be assured of buffering the entire response. |  | that a client can be assured of buffering the entire response. |
| When multiple transfer-codings are acceptable, the client MAY rank |  | When multiple transfer codings are acceptable, the client MAY rank |
| the codings by preference using a case-insensitive "q" parameter |  | the codings by preference using a case-insensitive "q" parameter |
| (similar to the qvalues used in content negotiation fields, Section |  | (similar to the qvalues used in content negotiation fields, Section |
| 6.3.1 of [Part2]). The rank value is a real number in the range 0 |  | 5.3.1 of [Part2]). The rank value is a real number in the range 0 |
| through 1, where 0.001 is the least preferred and 1 is the most |  | through 1, where 0.001 is the least preferred and 1 is the most |
| preferred; a value of 0 means "not acceptable". |  | preferred; a value of 0 means "not acceptable". |
| If the TE field-value is empty or if no TE field is present, the only |  | If the TE field-value is empty or if no TE field is present, the only |
| acceptable transfer-coding is "chunked". A message with no transfer- |  | acceptable transfer coding is chunked. A message with no transfer |
| coding is always acceptable. |  | coding is always acceptable. |
| Since the TE header field only applies to the immediate connection, a |  | Since the TE header field only applies to the immediate connection, a |
| sender of TE MUST also send a "TE" connection option within the |  | sender of TE MUST also send a "TE" connection option within the |
| Connection header field (Section 6.1) in order to prevent the TE |  | Connection header field (Section 6.1) in order to prevent the TE |
| field from being forwarded by intermediaries that do not support its |  | field from being forwarded by intermediaries that do not support its |
| semantics. |  | semantics. |
| 5. Message Routing |  | 5. Message Routing |
| skipping to change at page 38, line 39 |  | skipping to change at page 40, line 10 |
| request message (Section 3) with a request-target derived from the |  | request message (Section 3) with a request-target derived from the |
| target URI. There are four distinct formats for the request-target, |  | target URI. There are four distinct formats for the request-target, |
| depending on both the method being requested and whether the request |  | depending on both the method being requested and whether the request |
| is to a proxy. |  | is to a proxy. |
| request-target = origin-form |  | request-target = origin-form |
| / absolute-form |  | / absolute-form |
| / authority-form |  | / authority-form |
| / asterisk-form |  | / asterisk-form |
| origin-form = path-absolute [ "?" query ] |  | origin-form = absolute-path [ "?" query ] |
| absolute-form = absolute-URI |  | absolute-form = absolute-URI |
| authority-form = authority |  | authority-form = authority |
| asterisk-form = "*" |  | asterisk-form = "*" |
|  |  | origin-form |
| The most common form of request-target is the origin-form. When |  | The most common form of request-target is the origin-form. When |
| making a request directly to an origin server, other than a CONNECT |  | making a request directly to an origin server, other than a CONNECT |
| or server-wide OPTIONS request (as detailed below), a client MUST |  | or server-wide OPTIONS request (as detailed below), a client MUST |
| send only the absolute path and query components of the target URI as |  | send only the absolute path and query components of the target URI as |
| the request-target. If the target URI's path component is empty, |  | the request-target. If the target URI's path component is empty, |
| then the client MUST send "/" as the path within the origin-form of |  | then the client MUST send "/" as the path within the origin-form of |
| request-target. A Host header field is also sent, as defined in |  | request-target. A Host header field is also sent, as defined in |
| Section 5.4, containing the target URI's authority component |  | Section 5.4, containing the target URI's authority component |
| (excluding any userinfo). |  | (excluding any userinfo). |
| skipping to change at page 39, line 20 |  | skipping to change at page 40, line 41 |
| directly from the origin server would open (or reuse) a TCP |  | directly from the origin server would open (or reuse) a TCP |
| connection to port 80 of the host "www.example.org" and send the |  | connection to port 80 of the host "www.example.org" and send the |
| lines: |  | lines: |
| GET /where?q=now HTTP/1.1 |  | GET /where?q=now HTTP/1.1 |
| Host: www.example.org |  | Host: www.example.org |
| followed by the remainder of the request message. |  | followed by the remainder of the request message. |
|  |  | absolute-form |
| When making a request to a proxy, other than a CONNECT or server-wide |  | When making a request to a proxy, other than a CONNECT or server-wide |
| OPTIONS request (as detailed below), a client MUST send the target |  | OPTIONS request (as detailed below), a client MUST send the target |
| URI in absolute-form as the request-target. The proxy is requested |  | URI in absolute-form as the request-target. The proxy is requested |
| to either service that request from a valid cache, if possible, or |  | to either service that request from a valid cache, if possible, or |
| make the same request on the client's behalf to either the next |  | make the same request on the client's behalf to either the next |
| inbound proxy server or directly to the origin server indicated by |  | inbound proxy server or directly to the origin server indicated by |
| the request-target. Requirements on such "forwarding" of messages |  | the request-target. Requirements on such "forwarding" of messages |
| are defined in Section 5.6. |  | are defined in Section 5.7. |
| An example absolute-form of request-line would be: |  | An example absolute-form of request-line would be: |
| GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1 |  | GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1 |
| To allow for transition to the absolute-form for all requests in some |  | To allow for transition to the absolute-form for all requests in some |
| future version of HTTP, HTTP/1.1 servers MUST accept the absolute- |  | future version of HTTP, HTTP/1.1 servers MUST accept the absolute- |
| form in requests, even though HTTP/1.1 clients will only send them in |  | form in requests, even though HTTP/1.1 clients will only send them in |
| requests to proxies. |  | requests to proxies. |
|  |  | authority-form |
| The authority-form of request-target is only used for CONNECT |  | The authority-form of request-target is only used for CONNECT |
| requests (Section 5.3.6 of [Part2]). When making a CONNECT request |  | requests (Section 4.3.6 of [Part2]). When making a CONNECT request |
| to establish a tunnel through one or more proxies, a client MUST send |  | to establish a tunnel through one or more proxies, a client MUST send |
| only the target URI's authority component (excluding any userinfo) as |  | only the target URI's authority component (excluding any userinfo) as |
| the request-target. For example, |  | the request-target. For example, |
| CONNECT www.example.com:80 HTTP/1.1 |  | CONNECT www.example.com:80 HTTP/1.1 |
|  |  | asterisk-form |
| The asterisk-form of request-target is only used for a server-wide |  | The asterisk-form of request-target is only used for a server-wide |
| OPTIONS request (Section 5.3.7 of [Part2]). When a client wishes to |  | OPTIONS request (Section 4.3.7 of [Part2]). When a client wishes to |
| request OPTIONS for the server as a whole, as opposed to a specific |  | request OPTIONS for the server as a whole, as opposed to a specific |
| named resource of that server, the client MUST send only "*" (%x2A) |  | named resource of that server, the client MUST send only "*" (%x2A) |
| as the request-target. For example, |  | as the request-target. For example, |
| OPTIONS * HTTP/1.1 |  | OPTIONS * HTTP/1.1 |
| If a proxy receives an OPTIONS request with an absolute-form of |  | If a proxy receives an OPTIONS request with an absolute-form of |
| request-target in which the URI has an empty path and no query |  | request-target in which the URI has an empty path and no query |
| component, then the last proxy on the request chain MUST send a |  | component, then the last proxy on the request chain MUST send a |
| request-target of "*" when it forwards the request to the indicated |  | request-target of "*" when it forwards the request to the indicated |
| origin server. |  | origin server. |
| For example, the request |  | For example, the request |
| skipping to change at page 42, line 43 |  | skipping to change at page 44, line 24 |
| An origin server that does not allow resources to differ by requested |  | An origin server that does not allow resources to differ by requested |
| host MAY ignore the Host field-value and instead replace it with a |  | host MAY ignore the Host field-value and instead replace it with a |
| configured server name when constructing the effective request URI. |  | configured server name when constructing the effective request URI. |
| Recipients of an HTTP/1.0 request that lacks a Host header field MAY |  | Recipients of an HTTP/1.0 request that lacks a Host header field MAY |
| attempt to use heuristics (e.g., examination of the URI path for |  | attempt to use heuristics (e.g., examination of the URI path for |
| something unique to a particular host) in order to guess the |  | something unique to a particular host) in order to guess the |
| effective request URI's authority component. |  | effective request URI's authority component. |
| 5.6. Message Forwarding |  | 5.6. Associating a Response to a Request |
|  |  | HTTP does not include a request identifier for associating a given |
|  |  | request message with its corresponding one or more response messages. |
|  |  | Hence, it relies on the order of response arrival to correspond |
|  |  | exactly to the order in which requests are made on the same |
|  |  | connection. More than one response message per request only occurs |
|  |  | when one or more informational responses (1xx, see Section 6.2 of |
|  |  | [Part2]) precede a final response to the same request. |
|  |  | A client that has more than one outstanding request on a connection |
|  |  | MUST maintain a list of outstanding requests in the order sent and |
|  |  | MUST associate each received response message on that connection to |
|  |  | the highest ordered request that has not yet received a final (non- |
|  |  | 1xx) response. |
|  |  | 5.7. Message Forwarding |
| As described in Section 2.3, intermediaries can serve a variety of |  | As described in Section 2.3, intermediaries can serve a variety of |
| roles in the processing of HTTP requests and responses. Some |  | roles in the processing of HTTP requests and responses. Some |
| intermediaries are used to improve performance or availability. |  | intermediaries are used to improve performance or availability. |
| Others are used for access control or to filter content. Since an |  | Others are used for access control or to filter content. Since an |
| HTTP stream has characteristics similar to a pipe-and-filter |  | HTTP stream has characteristics similar to a pipe-and-filter |
| architecture, there are no inherent limits to the extent an |  | architecture, there are no inherent limits to the extent an |
| intermediary can enhance (or interfere) with either direction of the |  | intermediary can enhance (or interfere) with either direction of the |
| stream. |  | stream. |
| Intermediaries that forward a message MUST implement the Connection |  | Intermediaries that forward a message MUST implement the Connection |
| header field, as specified in Section 6.1, to exclude fields that are |  | header field, as specified in Section 6.1, to exclude fields that are |
| only intended for the incoming connection. |  | only intended for the incoming connection. |
| In order to avoid request loops, a proxy that forwards requests to |  | In order to avoid request loops, a proxy that forwards requests to |
| other proxies MUST be able to recognize and exclude all of its own |  | other proxies MUST be able to recognize and exclude all of its own |
| server names, including any aliases, local variations, or literal IP |  | server names, including any aliases, local variations, or literal IP |
| addresses. |  | addresses. |
| 5.7. Via |  | 5.7.1. Via |
| The "Via" header field MUST be sent by a proxy or gateway in |  | The "Via" header field MUST be sent by a proxy or gateway in |
| forwarded messages to indicate the intermediate protocols and |  | forwarded messages to indicate the intermediate protocols and |
| recipients between the user agent and the server on requests, and |  | recipients between the user agent and the server on requests, and |
| between the origin server and the client on responses. It is |  | between the origin server and the client on responses. It is |
| analogous to the "Received" field used by email systems (Section |  | analogous to the "Received" field used by email systems (Section |
| 3.6.7 of [RFC5322]). Via is used in HTTP for tracking message |  | 3.6.7 of [RFC5322]). Via is used in HTTP for tracking message |
| forwards, avoiding request loops, and identifying the protocol |  | forwards, avoiding request loops, and identifying the protocol |
| capabilities of all senders along the request/response chain. |  | capabilities of all senders along the request/response chain. |
| Via = 1#( received-protocol RWS received-by |  | Via = 1#( received-protocol RWS received-by |
| [ RWS comment ] ) |  | [ RWS comment ] ) |
| received-protocol = [ protocol-name "/" ] protocol-version |  | received-protocol = [ protocol-name "/" ] protocol-version |
|  |  | ; see Section 6.7 |
| received-by = ( uri-host [ ":" port ] ) / pseudonym |  | received-by = ( uri-host [ ":" port ] ) / pseudonym |
| pseudonym = token |  | pseudonym = token |
| The received-protocol indicates the protocol version of the message |  | The received-protocol indicates the protocol version of the message |
| received by the server or client along each segment of the request/ |  | received by the server or client along each segment of the request/ |
| response chain. The received-protocol version is appended to the Via |  | response chain. The received-protocol version is appended to the Via |
| field value when the message is forwarded so that information about |  | field value when the message is forwarded so that information about |
| the protocol capabilities of upstream applications remains visible to |  | the protocol capabilities of upstream applications remains visible to |
| all recipients. |  | all recipients. |
| skipping to change at page 44, line 33 |  | skipping to change at page 46, line 32 |
| received-protocol values. For example, |  | received-protocol values. For example, |
| Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy |  | Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy |
| could be collapsed to |  | could be collapsed to |
| Via: 1.0 ricky, 1.1 mertz, 1.0 lucy |  | Via: 1.0 ricky, 1.1 mertz, 1.0 lucy |
| Senders SHOULD NOT combine multiple entries unless they are all under |  | Senders SHOULD NOT combine multiple entries unless they are all under |
| the same organizational control and the hosts have already been |  | the same organizational control and the hosts have already been |
| replaced by pseudonyms. Senders MUST NOT combine entries which have |  | replaced by pseudonyms. Senders MUST NOT combine entries that have |
| different received-protocol values. |  | different received-protocol values. |
| 5.8. Message Transforming |  | 5.7.2. Transformations |
|  |  | Some intermediaries include features for transforming messages and |
|  |  | their payloads. A transforming proxy might, for example, convert |
|  |  | between image formats in order to save cache space or to reduce the |
|  |  | amount of traffic on a slow link. However, operational problems |
|  |  | might occur when these transformations are applied to payloads |
|  |  | intended for critical applications, such as medical imaging or |
|  |  | scientific data analysis, particularly when integrity checks or |
|  |  | digital signatures are used to ensure that the payload received is |
|  |  | identical to the original. |
| If a proxy receives a request-target with a host name that is not a |  | If a proxy receives a request-target with a host name that is not a |
| fully qualified domain name, it MAY add its own domain to the host |  | fully qualified domain name, it MAY add its own domain to the host |
| name it received when forwarding the request. A proxy MUST NOT |  | name it received when forwarding the request. A proxy MUST NOT |
| change the host name if it is a fully qualified domain name. |  | change the host name if it is a fully qualified domain name. |
| A non-transforming proxy MUST NOT modify the "path-absolute" and |  | A proxy MUST NOT modify the "absolute-path" and "query" parts of the |
| "query" parts of the received request-target when forwarding it to |  | received request-target when forwarding it to the next inbound |
| the next inbound server, except as noted above to replace an empty |  | server, except as noted above to replace an empty path with "/" or |
| path with "/" or "*". |  | "*". |
| A non-transforming proxy MUST preserve the message payload (Section |  |  |
| 3.3 of [Part2]), though it MAY change the message body through |  |  |
| application or removal of a transfer-coding (Section 4). |  |  |
| A non-transforming proxy SHOULD NOT modify header fields that provide |  |  |
| information about the end points of the communication chain, the |  |  |
| resource state, or the selected representation. |  |  |
| A non-transforming proxy MUST NOT modify any of the following fields |  |  |
| in a request or response, and it MUST NOT add any of these fields if |  |  |
| not already present: |  |  |
| o Allow (Section 8.4.1 of [Part2]) |  |  |
| o Content-Location (Section 3.1.4.2 of [Part2]) |  |  |
| o Content-MD5 (Section 14.15 of [RFC2616]) |  |  |
| o ETag (Section 2.3 of [Part4]) |  |  |
| o Last-Modified (Section 2.2 of [Part4]) |  |  |
| o Server (Section 8.4.2 of [Part2]) |  |  |
| A non-transforming proxy MUST NOT modify an Expires header field |  |  |
| (Section 7.3 of [Part6]) if already present in a response, but it MAY |  |  |
| add an Expires header field with a field-value identical to that of |  |  |
| the Date header field. |  |  |
| A proxy MUST NOT modify or add any of the following fields in a |  |  |
| message that contains the no-transform cache-control directive: |  |  |
| o Content-Encoding (Section 3.1.2.2 of [Part2]) |  |  |
| o Content-Range (Section 5.2 of [Part5]) |  | A proxy MUST NOT modify header fields that provide information about |
|  |  | the end points of the communication chain, the resource state, or the |
|  |  | selected representation. A proxy MAY change the message body through |
|  |  | application or removal of a transfer coding (Section 4). |
| o Content-Type (Section 3.1.1.5 of [Part2]) |  | A non-transforming proxy MUST preserve the message payload (Section |
|  |  | 3.3 of [Part2]). A transforming proxy MUST preserve the payload of a |
|  |  | message that contains the no-transform cache-control directive. |
| A transforming proxy MAY modify or add these fields to a message that |  | A transforming proxy MAY transform the payload of a message that does |
| does not include no-transform, but if it does so, it MUST add a |  | not contain the no-transform cache-control directive; if the payload |
| Warning 214 (Transformation applied) if one does not already appear |  | is transformed, the transforming proxy MUST add a Warning 214 |
|  |  | (Transformation applied) header field if one does not already appear |
| in the message (see Section 7.5 of [Part6]). |  | in the message (see Section 7.5 of [Part6]). |
| Warning: Unnecessary modification of header fields might cause |  |  |
| authentication failures if stronger authentication mechanisms are |  |  |
| introduced in later versions of HTTP. Such authentication |  |  |
| mechanisms MAY rely on the values of header fields not listed |  |  |
| here. |  |  |
| 5.9. Associating a Response to a Request |  |  |
| HTTP does not include a request identifier for associating a given |  |  |
| request message with its corresponding one or more response messages. |  |  |
| Hence, it relies on the order of response arrival to correspond |  |  |
| exactly to the order in which requests are made on the same |  |  |
| connection. More than one response message per request only occurs |  |  |
| when one or more informational responses (1xx, see Section 7.2 of |  |  |
| [Part2]) precede a final response to the same request. |  |  |
| A client that uses persistent connections and sends more than one |  |  |
| request per connection MUST maintain a list of outstanding requests |  |  |
| in the order sent on that connection and MUST associate each received |  |  |
| response message to the highest ordered request that has not yet |  |  |
| received a final (non-1xx) response. |  |  |
| 6. Connection Management |  | 6. Connection Management |
| HTTP messaging is independent of the underlying transport or session- |  | HTTP messaging is independent of the underlying transport or session- |
| layer connection protocol(s). HTTP only presumes a reliable |  | layer connection protocol(s). HTTP only presumes a reliable |
| transport with in-order delivery of requests and the corresponding |  | transport with in-order delivery of requests and the corresponding |
| in-order delivery of responses. The mapping of HTTP request and |  | in-order delivery of responses. The mapping of HTTP request and |
| response structures onto the data units of an underlying transport |  | response structures onto the data units of an underlying transport |
| protocol is outside the scope of this specification. |  | protocol is outside the scope of this specification. |
| As described in Section 5.2, the specific connection protocols to be |  | As described in Section 5.2, the specific connection protocols to be |
| skipping to change at page 47, line 6 |  | skipping to change at page 48, line 13 |
| fair use and detect denial of service attacks. |  | fair use and detect denial of service attacks. |
| 6.1. Connection |  | 6.1. Connection |
| The "Connection" header field allows the sender to indicate desired |  | The "Connection" header field allows the sender to indicate desired |
| control options for the current connection. In order to avoid |  | control options for the current connection. In order to avoid |
| confusing downstream recipients, a proxy or gateway MUST remove or |  | confusing downstream recipients, a proxy or gateway MUST remove or |
| replace any received connection options before forwarding the |  | replace any received connection options before forwarding the |
| message. |  | message. |
| When a header field is used to supply control information for or |  | When a header field aside from Connection is used to supply control |
| about the current connection, the sender SHOULD list the |  | information for or about the current connection, the sender MUST list |
| corresponding field-name within the "Connection" header field. A |  | the corresponding field-name within the "Connection" header field. A |
| proxy or gateway MUST parse a received Connection header field before |  | proxy or gateway MUST parse a received Connection header field before |
| a message is forwarded and, for each connection-option in this field, |  | a message is forwarded and, for each connection-option in this field, |
| remove any header field(s) from the message with the same name as the |  | remove any header field(s) from the message with the same name as the |
| connection-option, and then remove the Connection header field itself |  | connection-option, and then remove the Connection header field itself |
| (or replace it with the intermediary's own connection options for the |  | (or replace it with the intermediary's own connection options for the |
| forwarded message). |  | forwarded message). |
| Hence, the Connection header field provides a declarative way of |  | Hence, the Connection header field provides a declarative way of |
| distinguishing header fields that are only intended for the immediate |  | distinguishing header fields that are only intended for the immediate |
| recipient ("hop-by-hop") from those fields that are intended for all |  | recipient ("hop-by-hop") from those fields that are intended for all |
| skipping to change at page 47, line 31 |  | skipping to change at page 48, line 38 |
| to be deployed without fear that they will be blindly forwarded by |  | to be deployed without fear that they will be blindly forwarded by |
| older intermediaries. |  | older intermediaries. |
| The Connection header field's value has the following grammar: |  | The Connection header field's value has the following grammar: |
| Connection = 1#connection-option |  | Connection = 1#connection-option |
| connection-option = token |  | connection-option = token |
| Connection options are case-insensitive. |  | Connection options are case-insensitive. |
| A sender MUST NOT include field-names in the Connection header field- |  | A sender MUST NOT send a connection option corresponding to a header |
| value for fields that are defined as expressing constraints for all |  | field that is intended for all recipients of the payload. For |
| recipients in the request or response chain, such as the Cache- |  | example, Cache-Control is never appropriate as a connection option |
| Control header field (Section 7.2 of [Part6]). |  | (Section 7.2 of [Part6]). |
| The connection options do not have to correspond to a header field |  | The connection options do not have to correspond to a header field |
| present in the message, since a connection-specific header field |  | present in the message, since a connection-specific header field |
| might not be needed if there are no parameters associated with that |  | might not be needed if there are no parameters associated with that |
| connection option. Recipients that trigger certain connection |  | connection option. Recipients that trigger certain connection |
| behavior based on the presence of connection options MUST do so based |  | behavior based on the presence of connection options MUST do so based |
| on the presence of the connection-option rather than only the |  | on the presence of the connection-option rather than only the |
| presence of the optional header field. In other words, if the |  | presence of the optional header field. In other words, if the |
| connection option is received as a header field but not indicated |  | connection option is received as a header field but not indicated |
| within the Connection field-value, then the recipient MUST ignore the |  | within the Connection field-value, then the recipient MUST ignore the |
| skipping to change at page 48, line 16 |  | skipping to change at page 49, line 22 |
| since it would be unwise for senders to use that field-name for |  | since it would be unwise for senders to use that field-name for |
| anything else. |  | anything else. |
| The "close" connection option is defined for a sender to signal that |  | The "close" connection option is defined for a sender to signal that |
| this connection will be closed after completion of the response. For |  | this connection will be closed after completion of the response. For |
| example, |  | example, |
| Connection: close |  | Connection: close |
| in either the request or the response header fields indicates that |  | in either the request or the response header fields indicates that |
| the connection SHOULD be closed after the current request/response is |  | the connection MUST be closed after the current request/response is |
| complete (Section 6.2.5). |  | complete (Section 6.6). |
| A client that does not support persistent connections MUST send the |  | A client that does not support persistent connections MUST send the |
| "close" connection option in every request message. |  | "close" connection option in every request message. |
| A server that does not support persistent connections MUST send the |  | A server that does not support persistent connections MUST send the |
| "close" connection option in every response message that does not |  | "close" connection option in every response message that does not |
| have a 1xx (Informational) status code. |  | have a 1xx (Informational) status code. |
| 6.2. Persistent Connections |  | 6.2. Establishment |
| HTTP was originally designed to use a separate connection for each |  |  |
| request/response pair. As the Web evolved and embedded requests |  |  |
| became common for inline images, the connection establishment |  |  |
| overhead was a significant drain on performance and a concern for |  |  |
| Internet congestion. Message framing (via Content-Length) and |  |  |
| optional long-lived connections (via Keep-Alive) were added to |  |  |
| HTTP/1.0 in order to improve performance for some requests. However, |  |  |
| these extensions were insufficient for dynamically generated |  |  |
| responses and difficult to use with intermediaries. |  |  |
| HTTP/1.1 defaults to the use of "persistent connections", which allow |  |  |
| multiple requests and responses to be carried over a single |  |  |
| connection. The "close" connection-option is used to signal that a |  |  |
| connection will close after the current request/response. Persistent |  |  |
| connections have a number of advantages: |  |  |
| o By opening and closing fewer connections, CPU time is saved in |  |  |
| routers and hosts (clients, servers, proxies, gateways, tunnels, |  |  |
| or caches), and memory used for protocol control blocks can be |  |  |
| saved in hosts. |  |  |
| o Most requests and responses can be pipelined on a connection. |  |  |
| Pipelining allows a client to make multiple requests without |  |  |
| waiting for each response, allowing a single connection to be used |  |  |
| much more efficiently and with less overall latency. |  |  |
| o For TCP connections, network congestion is reduced by eliminating |  |  |
| the packets associated with the three way handshake and graceful |  |  |
| close procedures, and by allowing sufficient time to determine the |  |  |
| congestion state of the network. |  |  |
| o Latency on subsequent requests is reduced since there is no time |  |  |
| spent in the connection opening handshake. |  |  |
| o HTTP can evolve more gracefully, since most errors can be reported |  |  |
| without the penalty of closing the connection. Clients using |  |  |
| future versions of HTTP might optimistically try a new feature, |  |  |
| but if communicating with an older server, retry with old |  |  |
| semantics after an error is reported. |  |  |
| HTTP implementations SHOULD implement persistent connections. |  |  |
| 6.2.1. Establishment |  |  |
| It is beyond the scope of this specification to describe how |  | It is beyond the scope of this specification to describe how |
| connections are established via various transport or session-layer |  | connections are established via various transport or session-layer |
| protocols. Each connection applies to only one transport link. |  | protocols. Each connection applies to only one transport link. |
|  |  | 6.3. Persistence |
|  |  | HTTP/1.1 defaults to the use of "persistent connections", allowing |
|  |  | multiple requests and responses to be carried over a single |
|  |  | connection. The "close" connection-option is used to signal that a |
|  |  | connection will not persist after the current request/response. HTTP |
|  |  | implementations SHOULD support persistent connections. |
| A recipient determines whether a connection is persistent or not |  | A recipient determines whether a connection is persistent or not |
| based on the most recently received message's protocol version and |  | based on the most recently received message's protocol version and |
| Connection header field (if any): |  | Connection header field (if any): |
| o If the close connection option is present, the connection will not |  | o If the close connection option is present, the connection will not |
| persist after the current response; else, |  | persist after the current response; else, |
| o If the received protocol is HTTP/1.1 (or later), the connection |  | o If the received protocol is HTTP/1.1 (or later), the connection |
| will persist after the current response; else, |  | will persist after the current response; else, |
| o If the received protocol is HTTP/1.0, the "keep-alive" connection |  | o If the received protocol is HTTP/1.0, the "keep-alive" connection |
| option is present, the recipient is not a proxy, and the recipient |  | option is present, the recipient is not a proxy, and the recipient |
| wishes to honor the HTTP/1.0 "keep-alive" mechanism, the |  | wishes to honor the HTTP/1.0 "keep-alive" mechanism, the |
| connection will persist after the current response; otherwise, |  | connection will persist after the current response; otherwise, |
| o The connection will close after the current response. |  | o The connection will close after the current response. |
| A proxy server MUST NOT maintain a persistent connection with an |  |  |
| HTTP/1.0 client (see Section 19.7.1 of [RFC2068] for information and |  |  |
| discussion of the problems with the Keep-Alive header field |  |  |
| implemented by many HTTP/1.0 clients). |  |  |
| 6.2.2. Reuse |  |  |
| In order to remain persistent, all messages on a connection MUST have |  |  |
| a self-defined message length (i.e., one not defined by closure of |  |  |
| the connection), as described in Section 3.3. |  |  |
| A server MAY assume that an HTTP/1.1 client intends to maintain a |  | A server MAY assume that an HTTP/1.1 client intends to maintain a |
| persistent connection until a close connection option is received in |  | persistent connection until a close connection option is received in |
| a request. |  | a request. |
| A client MAY reuse a persistent connection until it sends or receives |  | A client MAY reuse a persistent connection until it sends or receives |
| a close connection option or receives an HTTP/1.0 response without a |  | a close connection option or receives an HTTP/1.0 response without a |
| "keep-alive" connection option. |  | "keep-alive" connection option. |
|  |  | In order to remain persistent, all messages on a connection MUST have |
|  |  | a self-defined message length (i.e., one not defined by closure of |
|  |  | the connection), as described in Section 3.3. A server MUST read the |
|  |  | entire request message body or close the connection after sending its |
|  |  | response, since otherwise the remaining data on a persistent |
|  |  | connection would be misinterpreted as the next request. Likewise, a |
|  |  | client MUST read the entire response message body if it intends to |
|  |  | reuse the same connection for a subsequent request. |
|  |  | A proxy server MUST NOT maintain a persistent connection with an |
|  |  | HTTP/1.0 client (see Section 19.7.1 of [RFC2068] for information and |
|  |  | discussion of the problems with the Keep-Alive header field |
|  |  | implemented by many HTTP/1.0 clients). |
| Clients and servers SHOULD NOT assume that a persistent connection is |  | Clients and servers SHOULD NOT assume that a persistent connection is |
| maintained for HTTP versions less than 1.1 unless it is explicitly |  | maintained for HTTP versions less than 1.1 unless it is explicitly |
| signaled. See Appendix A.1.2 for more information on backward |  | signaled. See Appendix A.1.2 for more information on backward |
| compatibility with HTTP/1.0 clients. |  | compatibility with HTTP/1.0 clients. |
| 6.2.2.1. Pipelining |  | 6.3.1. Retrying Requests |
|  |  | Connections can be closed at any time, with or without intention. |
|  |  | Implementations ought to anticipate the need to recover from |
|  |  | asynchronous close events. |
|  |  | When an inbound connection is closed prematurely, a client MAY open a |
|  |  | new connection and automatically retransmit an aborted sequence of |
|  |  | requests if all of those requests have idempotent methods (Section |
|  |  | 4.2.2 of [Part2]). A proxy MUST NOT automatically retry non- |
|  |  | idempotent requests. |
|  |  | A user agent MUST NOT automatically retry a request with a non- |
|  |  | idempotent method unless it has some means to know that the request |
|  |  | semantics are actually idempotent, regardless of the method, or some |
|  |  | means to detect that the original request was never applied. For |
|  |  | example, a user agent that knows (through design or configuration) |
|  |  | that a POST request to a given resource is safe can repeat that |
|  |  | request automatically. Likewise, a user agent designed specifically |
|  |  | to operate on a version control repository might be able to recover |
|  |  | from partial failure conditions by checking the target resource |
|  |  | revision(s) after a failed connection, reverting or fixing any |
|  |  | changes that were partially applied, and then automatically retrying |
|  |  | the requests that failed. |
|  |  | An automatic retry SHOULD NOT be repeated if it fails. |
|  |  | 6.3.2. Pipelining |
| A client that supports persistent connections MAY "pipeline" its |  | A client that supports persistent connections MAY "pipeline" its |
| requests (i.e., send multiple requests without waiting for each |  | requests (i.e., send multiple requests without waiting for each |
| response). A server MUST send its responses to those requests in the |  | response). A server MAY process a sequence of pipelined requests in |
| same order that the requests were received. |  | parallel if they all have safe methods (Section 4.2.1 of [Part2]), |
|  |  | but MUST send the corresponding responses in the same order that the |
| Clients which assume persistent connections and pipeline immediately |  | requests were received. |
| after connection establishment SHOULD be prepared to retry their |  |  |
| connection if the first pipelined attempt fails. If a client does |  |  |
| such a retry, it MUST NOT pipeline before it knows the connection is |  |  |
| persistent. Clients MUST also be prepared to resend their requests |  |  |
| if the server closes the connection before sending all of the |  |  |
| corresponding responses. |  |  |
| Clients SHOULD NOT pipeline requests using non-idempotent request |  | A client that pipelines requests MUST be prepared to retry those |
| methods or non-idempotent sequences of request methods (see Section |  | requests if the connection closes before it receives all of the |
| 5.2.2 of [Part2]). Otherwise, a premature termination of the |  | corresponding responses. A client that assumes a persistent |
| transport connection could lead to indeterminate results. A client |  | connection and pipelines immediately after connection establishment |
| wishing to send a non-idempotent request SHOULD wait to send that |  | MUST NOT pipeline on a retry connection until it knows the connection |
| request until it has received the response status line for the |  | is persistent. |
| previous request. |  |  |
| 6.2.2.2. Retrying Requests |  | Idempotent methods (Section 4.2.2 of [Part2]) are significant to |
|  |  | pipelining because they can be automatically retried after a |
|  |  | connection failure. A user agent SHOULD NOT pipeline requests after |
|  |  | a non-idempotent method until the final response status code for that |
|  |  | method has been received, unless the user agent has a means to detect |
|  |  | and recover from partial failure conditions involving the pipelined |
|  |  | sequence. |
| Senders can close the transport connection at any time. Therefore, |  | An intermediary that receives pipelined requests MAY pipeline those |
| clients, servers, and proxies MUST be able to recover from |  | requests when forwarding them inbound, since it can rely on the |
| asynchronous close events. Client software MAY reopen the transport |  | outbound user agent(s) to determine what requests can be safely |
| connection and retransmit the aborted sequence of requests without |  | pipelined. If the inbound connection fails before receiving a |
| user interaction so long as the request sequence is idempotent (see |  | response, the pipelining intermediary MAY attempt to retry a sequence |
| Section 5.2.2 of [Part2]). Non-idempotent request methods or |  | of requests that have yet to receive a response if the requests all |
| sequences MUST NOT be automatically retried, although user agents MAY |  | have idempotent methods; otherwise, the pipelining intermediary |
| offer a human operator the choice of retrying the request(s). |  | SHOULD forward any received responses and then close the |
| Confirmation by user-agent software with semantic understanding of |  | corresponding outbound connection(s) so that the outbound user |
| the application MAY substitute for user confirmation. The automatic |  | agent(s) can recover accordingly. |
| retry SHOULD NOT be repeated if the second sequence of requests |  |  |
| fails. |  |  |
| 6.2.3. Concurrency |  | 6.4. Concurrency |
| Clients SHOULD limit the number of simultaneous connections that they |  | Clients SHOULD limit the number of simultaneous connections that they |
| maintain to a given server. |  | maintain to a given server. |
| Previous revisions of HTTP gave a specific number of connections as a |  | Previous revisions of HTTP gave a specific number of connections as a |
| ceiling, but this was found to be impractical for many applications. |  | ceiling, but this was found to be impractical for many applications. |
| As a result, this specification does not mandate a particular maximum |  | As a result, this specification does not mandate a particular maximum |
| number of connections, but instead encourages clients to be |  | number of connections, but instead encourages clients to be |
| conservative when opening multiple connections. |  | conservative when opening multiple connections. |
| Multiple connections are typically used to avoid the "head-of-line |  | Multiple connections are typically used to avoid the "head-of-line |
| blocking" problem, wherein a request that takes significant server- |  | blocking" problem, wherein a request that takes significant server- |
| side processing and/or has a large payload blocks subsequent requests |  | side processing and/or has a large payload blocks subsequent requests |
| on the same connection. However, each connection consumes server |  | on the same connection. However, each connection consumes server |
| resources. Furthermore, using multiple connections can cause |  | resources. Furthermore, using multiple connections can cause |
| undesirable side effects in congested networks. |  | undesirable side effects in congested networks. |
| Note that servers might reject traffic that they deem abusive, |  | Note that servers might reject traffic that they deem abusive, |
| including an excessive number of connections from a client. |  | including an excessive number of connections from a client. |
| 6.2.4. Failures and Time-outs |  | 6.5. Failures and Time-outs |
| Servers will usually have some time-out value beyond which they will |  | Servers will usually have some time-out value beyond which they will |
| no longer maintain an inactive connection. Proxy servers might make |  | no longer maintain an inactive connection. Proxy servers might make |
| this a higher value since it is likely that the client will be making |  | this a higher value since it is likely that the client will be making |
| more connections through the same server. The use of persistent |  | more connections through the same server. The use of persistent |
| connections places no requirements on the length (or existence) of |  | connections places no requirements on the length (or existence) of |
| this time-out for either the client or the server. |  | this time-out for either the client or the server. |
| When a client or server wishes to time-out it SHOULD issue a graceful |  | When a client or server wishes to time-out it SHOULD issue a graceful |
| close on the transport connection. Clients and servers SHOULD both |  | close on the transport connection. Clients and servers SHOULD both |
| skipping to change at page 52, line 20 |  | skipping to change at page 53, line 13 |
| underlying transport's flow control mechanisms to resolve temporary |  | underlying transport's flow control mechanisms to resolve temporary |
| overloads, rather than terminate connections with the expectation |  | overloads, rather than terminate connections with the expectation |
| that clients will retry. The latter technique can exacerbate network |  | that clients will retry. The latter technique can exacerbate network |
| congestion. |  | congestion. |
| A client sending a message body SHOULD monitor the network connection |  | A client sending a message body SHOULD monitor the network connection |
| for an error status code while it is transmitting the request. If |  | for an error status code while it is transmitting the request. If |
| the client sees an error status code, it SHOULD immediately cease |  | the client sees an error status code, it SHOULD immediately cease |
| transmitting the body and close the connection. |  | transmitting the body and close the connection. |
| 6.2.5. Tear-down |  | 6.6. Tear-down |
| The Connection header field (Section 6.1) provides a "close" |  | The Connection header field (Section 6.1) provides a "close" |
| connection option that a sender SHOULD send when it wishes to close |  | connection option that a sender SHOULD send when it wishes to close |
| the connection after the current request/response pair. |  | the connection after the current request/response pair. |
| A client that sends a close connection option MUST NOT send further |  | A client that sends a close connection option MUST NOT send further |
| requests on that connection (after the one containing close) and MUST |  | requests on that connection (after the one containing close) and MUST |
| close the connection after reading the final response message |  | close the connection after reading the final response message |
| corresponding to this request. |  | corresponding to this request. |
| A server that receives a close connection option MUST initiate a |  | A server that receives a close connection option MUST initiate a |
| lingering close of the connection after it sends the final response |  | lingering close (see below) of the connection after it sends the |
| to the request that contained close. The server SHOULD include a |  | final response to the request that contained close. The server |
| close connection option in its final response on that connection. |  | SHOULD send a close connection option in its final response on that |
| The server MUST NOT process any further requests received on that |  | connection. The server MUST NOT process any further requests |
| connection. |  | received on that connection. |
| A server that sends a close connection option MUST initiate a |  | A server that sends a close connection option MUST initiate a |
| lingering close of the connection after it sends the response |  | lingering close of the connection after it sends the response |
| containing close. The server MUST NOT process any further requests |  | containing close. The server MUST NOT process any further requests |
| received on that connection. |  | received on that connection. |
| A client that receives a close connection option MUST cease sending |  | A client that receives a close connection option MUST cease sending |
| requests on that connection and close the connection after reading |  | requests on that connection and close the connection after reading |
| the response message containing the close; if additional pipelined |  | the response message containing the close; if additional pipelined |
| requests had been sent on the connection, the client SHOULD assume |  | requests had been sent on the connection, the client SHOULD assume |
| skipping to change at page 53, line 23 |  | skipping to change at page 54, line 17 |
| write connection (a half-close) and continuing to read from the |  | write connection (a half-close) and continuing to read from the |
| connection until the connection is closed by the client or the server |  | connection until the connection is closed by the client or the server |
| is reasonably certain that its own TCP stack has received the |  | is reasonably certain that its own TCP stack has received the |
| client's acknowledgement of the packet(s) containing the server's |  | client's acknowledgement of the packet(s) containing the server's |
| last response. It is then safe for the server to fully close the |  | last response. It is then safe for the server to fully close the |
| connection. |  | connection. |
| It is unknown whether the reset problem is exclusive to TCP or might |  | It is unknown whether the reset problem is exclusive to TCP or might |
| also be found in other transport connection protocols. |  | also be found in other transport connection protocols. |
| 6.3. Upgrade |  | 6.7. Upgrade |
| The "Upgrade" header field is intended to provide a simple mechanism |  | The "Upgrade" header field is intended to provide a simple mechanism |
| for transitioning from HTTP/1.1 to some other protocol on the same |  | for transitioning from HTTP/1.1 to some other protocol on the same |
| connection. A client MAY send a list of protocols in the Upgrade |  | connection. A client MAY send a list of protocols in the Upgrade |
| header field of a request to invite the server to switch to one or |  | header field of a request to invite the server to switch to one or |
| more of those protocols before sending the final response. A server |  | more of those protocols before sending the final response. A server |
| MUST send an Upgrade header field in 101 (Switching Protocols) |  | MUST send an Upgrade header field in 101 (Switching Protocols) |
| responses to indicate which protocol(s) are being switched to, and |  | responses to indicate which protocol(s) are being switched to, and |
| MUST send it in 426 (Upgrade Required) responses to indicate |  | MUST send it in 426 (Upgrade Required) responses to indicate |
| acceptable protocols. A server MAY send an Upgrade header field in |  | acceptable protocols. A server MAY send an Upgrade header field in |
| skipping to change at page 54, line 14 |  | skipping to change at page 55, line 7 |
| or target resource). |  | or target resource). |
| Upgrade cannot be used to insist on a protocol change; its acceptance |  | Upgrade cannot be used to insist on a protocol change; its acceptance |
| and use by the server is optional. The capabilities and nature of |  | and use by the server is optional. The capabilities and nature of |
| the application-level communication after the protocol change is |  | the application-level communication after the protocol change is |
| entirely dependent upon the new protocol chosen, although the first |  | entirely dependent upon the new protocol chosen, although the first |
| action after changing the protocol MUST be a response to the initial |  | action after changing the protocol MUST be a response to the initial |
| HTTP request that contained the Upgrade header field. |  | HTTP request that contained the Upgrade header field. |
| For example, if the Upgrade header field is received in a GET request |  | For example, if the Upgrade header field is received in a GET request |
| and the server decides to switch protocols, then it MUST first |  | and the server decides to switch protocols, then it first responds |
| respond with a 101 (Switching Protocols) message in HTTP/1.1 and then |  | with a 101 (Switching Protocols) message in HTTP/1.1 and then |
| immediately follow that with the new protocol's equivalent of a |  | immediately follows that with the new protocol's equivalent of a |
| response to a GET on the target resource. This allows a connection |  | response to a GET on the target resource. This allows a connection |
| to be upgraded to protocols with the same semantics as HTTP without |  | to be upgraded to protocols with the same semantics as HTTP without |
| the latency cost of an additional round-trip. A server MUST NOT |  | the latency cost of an additional round-trip. A server MUST NOT |
| switch protocols unless the received message semantics can be honored |  | switch protocols unless the received message semantics can be honored |
| by the new protocol; an OPTIONS request can be honored by any |  | by the new protocol; an OPTIONS request can be honored by any |
| protocol. |  | protocol. |
| When Upgrade is sent, a sender MUST also send a Connection header |  | When Upgrade is sent, a sender MUST also send a Connection header |
| field (Section 6.1) that contains the "upgrade" connection option, in |  | field (Section 6.1) that contains the "upgrade" connection option, in |
| order to prevent Upgrade from being accidentally forwarded by |  | order to prevent Upgrade from being accidentally forwarded by |
| intermediaries that might not implement the listed protocols. A |  | intermediaries that might not implement the listed protocols. A |
| server MUST ignore an Upgrade header field that is received in an |  | server MUST ignore an Upgrade header field that is received in an |
| HTTP/1.0 request. |  | HTTP/1.0 request. |
| The Upgrade header field only applies to switching application-level |  | The Upgrade header field only applies to switching application-level |
| protocols on the existing connection; it cannot be used to switch to |  | protocols on the existing connection; it cannot be used to switch to |
| a protocol on a different connection. For that purpose, it is more |  | a protocol on a different connection. For that purpose, it is more |
| appropriate to use a 3xx (Redirection) response (Section 7.4 of |  | appropriate to use a 3xx (Redirection) response (Section 6.4 of |
| [Part2]). |  | [Part2]). |
| This specification only defines the protocol name "HTTP" for use by |  | This specification only defines the protocol name "HTTP" for use by |
| the family of Hypertext Transfer Protocols, as defined by the HTTP |  | the family of Hypertext Transfer Protocols, as defined by the HTTP |
| version rules of Section 2.6 and future updates to this |  | version rules of Section 2.6 and future updates to this |
| specification. Additional tokens can be registered with IANA using |  | specification. Additional tokens ought to be registered with IANA |
| the registration procedure defined in Section 7.6. |  | using the registration procedure defined in Section 7.6. |
| 7. IANA Considerations |  | 7. IANA Considerations |
| 7.1. Header Field Registration |  | 7.1. Header Field Registration |
| HTTP header fields are registered within the Message Header Field |  | HTTP header fields are registered within the Message Header Field |
| Registry [RFC3864] maintained by IANA at <http://www.iana.org/ |  | Registry [BCP90] maintained by IANA at <http://www.iana.org/ |
| assignments/message-headers/message-header-index.html>. |  | assignments/message-headers/message-header-index.html>. |
| This document defines the following HTTP header fields, so their |  | This document defines the following HTTP header fields, so their |
| associated registry entries shall be updated according to the |  | associated registry entries shall be updated according to the |
| permanent registrations below: |  | permanent registrations below: |
| +-------------------+----------+----------+---------------+ |  | +-------------------+----------+----------+---------------+ |
| | Header Field Name | Protocol | Status | Reference | |  | | Header Field Name | Protocol | Status | Reference | |
| +-------------------+----------+----------+---------------+ |  | +-------------------+----------+----------+---------------+ |
| | Connection | http | standard | Section 6.1 | |  | | Connection | http | standard | Section 6.1 | |
| | Content-Length | http | standard | Section 3.3.2 | |  | | Content-Length | http | standard | Section 3.3.2 | |
| | Host | http | standard | Section 5.4 | |  | | Host | http | standard | Section 5.4 | |
| | TE | http | standard | Section 4.3 | |  | | TE | http | standard | Section 4.3 | |
| | Trailer | http | standard | Section 4.1.1 | |  | | Trailer | http | standard | Section 4.1.1 | |
| | Transfer-Encoding | http | standard | Section 3.3.1 | |  | | Transfer-Encoding | http | standard | Section 3.3.1 | |
| | Upgrade | http | standard | Section 6.3 | |  | | Upgrade | http | standard | Section 6.7 | |
| | Via | http | standard | Section 5.7 | |  | | Via | http | standard | Section 5.7.1 | |
| +-------------------+----------+----------+---------------+ |  | +-------------------+----------+----------+---------------+ |
| Furthermore, the header field-name "Close" shall be registered as |  | Furthermore, the header field-name "Close" shall be registered as |
| "reserved", since using that name as an HTTP header field might |  | "reserved", since using that name as an HTTP header field might |
| conflict with the "close" connection option of the "Connection" |  | conflict with the "close" connection option of the "Connection" |
| header field (Section 6.1). |  | header field (Section 6.1). |
| +-------------------+----------+----------+-------------+ |  | +-------------------+----------+----------+-------------+ |
| | Header Field Name | Protocol | Status | Reference | |  | | Header Field Name | Protocol | Status | Reference | |
| +-------------------+----------+----------+-------------+ |  | +-------------------+----------+----------+-------------+ |
| | Close | http | reserved | Section 7.1 | |  | | Close | http | reserved | Section 7.1 | |
| +-------------------+----------+----------+-------------+ |  | +-------------------+----------+----------+-------------+ |
| The change controller is: "IETF (iesg@ietf.org) - Internet |  | The change controller is: "IETF (iesg@ietf.org) - Internet |
| Engineering Task Force". |  | Engineering Task Force". |
| 7.2. URI Scheme Registration |  | 7.2. URI Scheme Registration |
| IANA maintains the registry of URI Schemes [RFC4395] at |  | IANA maintains the registry of URI Schemes [BCP115] at |
| <http://www.iana.org/assignments/uri-schemes.html>. |  | <http://www.iana.org/assignments/uri-schemes.html>. |
| This document defines the following URI schemes, so their associated |  | This document defines the following URI schemes, so their associated |
| registry entries shall be updated according to the permanent |  | registry entries shall be updated according to the permanent |
| registrations below: |  | registrations below: |
| +------------+------------------------------------+---------------+ |  | +------------+------------------------------------+---------------+ |
| | URI Scheme | Description | Reference | |  | | URI Scheme | Description | Reference | |
| +------------+------------------------------------+---------------+ |  | +------------+------------------------------------+---------------+ |
| | http | Hypertext Transfer Protocol | Section 2.7.1 | |  | | http | Hypertext Transfer Protocol | Section 2.7.1 | |
| | https | Hypertext Transfer Protocol Secure | Section 2.7.2 | |  | | https | Hypertext Transfer Protocol Secure | Section 2.7.2 | |
| +------------+------------------------------------+---------------+ |  | +------------+------------------------------------+---------------+ |
| 7.3. Internet Media Type Registrations |  | 7.3. Internet Media Type Registration |
| This document serves as the specification for the Internet media |  | This document serves as the specification for the Internet media |
| types "message/http" and "application/http". The following is to be |  | types "message/http" and "application/http". The following is to be |
| registered with IANA (see [RFC4288]). |  | registered with IANA (see [BCP13]). |
| 7.3.1. Internet Media Type message/http |  | 7.3.1. Internet Media Type message/http |
| The message/http type can be used to enclose a single HTTP request or |  | The message/http type can be used to enclose a single HTTP request or |
| response message, provided that it obeys the MIME restrictions for |  | response message, provided that it obeys the MIME restrictions for |
| all "message" types regarding line length and encodings. |  | all "message" types regarding line length and encodings. |
| Type name: message |  | Type name: message |
| Subtype name: http |  | Subtype name: http |
| skipping to change at page 58, line 47 |  | skipping to change at page 59, line 41 |
| Values to be added to this name space require IETF Review (see |  | Values to be added to this name space require IETF Review (see |
| Section 4.1 of [RFC5226]), and MUST conform to the purpose of |  | Section 4.1 of [RFC5226]), and MUST conform to the purpose of |
| transfer coding defined in this section. Use of program names for |  | transfer coding defined in this section. Use of program names for |
| the identification of encoding formats is not desirable and is |  | the identification of encoding formats is not desirable and is |
| discouraged for future encodings. |  | discouraged for future encodings. |
| 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>. |
| 7.5. Transfer Coding Registrations |  | 7.5. Transfer Coding Registration |
| The HTTP Transfer Coding Registry shall be updated with the |  | The HTTP Transfer Coding Registry shall be updated with the |
| registrations below: |  | registrations below: |
| +----------+----------------------------------------+---------------+ |  | +----------+----------------------------------------+---------------+ |
| | Name | Description | Reference | |  | | Name | Description | Reference | |
| +----------+----------------------------------------+---------------+ |  | +----------+----------------------------------------+---------------+ |
| | chunked | Transfer in a series of chunks | Section 4.1 | |  | | chunked | Transfer in a series of chunks | Section 4.1 | |
| | compress | UNIX "compress" program method | Section 4.2.1 | |  | | compress | UNIX "compress" program method | Section 4.2.1 | |
| | deflate | "deflate" compression mechanism | Section 4.2.2 | |  | | deflate | "deflate" compression mechanism | Section 4.2.2 | |
| skipping to change at page 60, line 23 |  | skipping to change at page 61, line 23 |
| +-------+----------------------+----------------------+-------------+ |  | +-------+----------------------+----------------------+-------------+ |
| | HTTP | Hypertext Transfer | any DIGIT.DIGIT | Section 2.6 | |  | | HTTP | Hypertext Transfer | any DIGIT.DIGIT | Section 2.6 | |
| | | Protocol | (e.g, "2.0") | | |  | | | Protocol | (e.g, "2.0") | | |
| +-------+----------------------+----------------------+-------------+ |  | +-------+----------------------+----------------------+-------------+ |
| The responsible party is: "IETF (iesg@ietf.org) - Internet |  | The responsible party is: "IETF (iesg@ietf.org) - Internet |
| Engineering Task Force". |  | Engineering Task Force". |
| 8. Security Considerations |  | 8. Security Considerations |
| This section is meant to inform application developers, information |  | This section is meant to inform developers, information providers, |
| providers, and users of the security limitations in HTTP/1.1 as |  | and users of known security concerns relevant to HTTP/1.1 message |
| described by this document. The discussion does not include |  | syntax, parsing, and routing. |
| definitive solutions to the problems revealed, though it does make |  |  |
| some suggestions for reducing security risks. |  |  |
| 8.1. Personal Information |  |  |
| HTTP clients are often privy to large amounts of personal |  |  |
| information, including both information provided by the user to |  |  |
| interact with resources (e.g., the user's name, location, mail |  |  |
| address, passwords, encryption keys, etc.) and information about the |  |  |
| user's browsing activity over time (e.g., history, bookmarks, etc.). |  |  |
| HTTP implementations need to prevent unintentional leakage of this |  |  |
| information. |  |  |
| 8.2. Abuse of Server Log Information |  |  |
| A server is in the position to save personal data about a user's |  |  |
| requests which might identify their reading patterns or subjects of |  |  |
| interest. In particular, log information gathered at an intermediary |  |  |
| often contains a history of user agent interaction, across a |  |  |
| multitude of sites, that can be traced to individual users. |  |  |
| HTTP log information is confidential in nature; its handling is often |  |  |
| constrained by laws and regulations. Log information needs to be |  |  |
| securely stored and appropriate guidelines followed for its analysis. |  |  |
| Anonymization of personal information within individual entries |  |  |
| helps, but is generally not sufficient to prevent real log traces |  |  |
| from being re-identified based on correlation with other access |  |  |
| characteristics. As such, access traces that are keyed to a specific |  |  |
| client should not be published even if the key is pseudonymous. |  |  |
| To minimize the risk of theft or accidental publication, log |  |  |
| information should be purged of personally identifiable information, |  |  |
| including user identifiers, IP addresses, and user-provided query |  |  |
| parameters, as soon as that information is no longer necessary to |  |  |
| support operational needs for security, auditing, or fraud control. |  |  |
| 8.3. Attacks Based On File and Path Names |  |  |
| Origin servers SHOULD be careful to restrict the documents returned |  |  |
| by HTTP requests to be only those that were intended by the server |  |  |
| administrators. If an HTTP server translates HTTP URIs directly into |  |  |
| file system calls, the server MUST take special care not to serve |  |  |
| files that were not intended to be delivered to HTTP clients. For |  |  |
| example, UNIX, Microsoft Windows, and other operating systems use |  |  |
| ".." as a path component to indicate a directory level above the |  |  |
| current one. On such a system, an HTTP server MUST disallow any such |  |  |
| construct in the request-target if it would otherwise allow access to |  |  |
| a resource outside those intended to be accessible via the HTTP |  |  |
| server. Similarly, files intended for reference only internally to |  |  |
| the server (such as access control files, configuration files, and |  |  |
| script code) MUST be protected from inappropriate retrieval, since |  |  |
| they might contain sensitive information. |  |  |
| 8.4. DNS-related Attacks |  | 8.1. DNS-related Attacks |
| HTTP clients rely heavily on the Domain Name Service (DNS), and are |  | HTTP clients rely heavily on the Domain Name Service (DNS), and are |
| thus generally prone to security attacks based on the deliberate |  | thus generally prone to security attacks based on the deliberate |
| misassociation of IP addresses and DNS names not protected by DNSSec. |  | misassociation of IP addresses and DNS names not protected by DNSSEC. |
| Clients need to be cautious in assuming the validity of an IP number/ |  | Clients need to be cautious in assuming the validity of an IP number/ |
| DNS name association unless the response is protected by DNSSec |  | DNS name association unless the response is protected by DNSSEC |
| ([RFC4033]). |  | ([RFC4033]). |
| 8.5. Intermediaries and Caching |  | 8.2. Intermediaries and Caching |
| By their very nature, HTTP intermediaries are men-in-the-middle, and |  | By their very nature, HTTP intermediaries are men-in-the-middle, and |
| represent an opportunity for man-in-the-middle attacks. Compromise |  | represent an opportunity for man-in-the-middle attacks. Compromise |
| of the systems on which the intermediaries run can result in serious |  | of the systems on which the intermediaries run can result in serious |
| security and privacy problems. Intermediaries have access to |  | security and privacy problems. Intermediaries have access to |
| security-related information, personal information about individual |  | security-related information, personal information about individual |
| users and organizations, and proprietary information belonging to |  | users and organizations, and proprietary information belonging to |
| users and content providers. A compromised intermediary, or an |  | users and content providers. A compromised intermediary, or an |
| intermediary implemented or configured without regard to security and |  | intermediary implemented or configured without regard to security and |
| privacy considerations, might be used in the commission of a wide |  | privacy considerations, might be used in the commission of a wide |
| skipping to change at page 62, line 16 |  | skipping to change at page 62, line 11 |
| to cache poisoning attacks. |  | to cache poisoning attacks. |
| Implementers need to consider the privacy and security implications |  | Implementers need to consider the privacy and security implications |
| of their design and coding decisions, and of the configuration |  | of their design and coding decisions, and of the configuration |
| options they provide to operators (especially the default |  | options they provide to operators (especially the default |
| configuration). |  | configuration). |
| Users need to be aware that intermediaries are no more trustworthy |  | Users need to be aware that intermediaries are no more trustworthy |
| than the people who run them; HTTP itself cannot solve this problem. |  | than the people who run them; HTTP itself cannot solve this problem. |
| 8.6. Protocol Element Size Overflows |  | 8.3. Buffer Overflows |
| Because HTTP uses mostly textual, character-delimited fields, |  | Because HTTP uses mostly textual, character-delimited fields, |
| attackers can overflow buffers in implementations, and/or perform a |  | attackers can overflow buffers in implementations, and/or perform a |
| Denial of Service against implementations that accept fields with |  | Denial of Service against implementations that accept fields with |
| unlimited lengths. |  | unlimited lengths. |
| To promote interoperability, this specification makes specific |  | To promote interoperability, this specification makes specific |
| recommendations for minimum size limits on request-line |  | recommendations for minimum size limits on request-line |
| (Section 3.1.1) and blocks of header fields (Section 3.2). These are |  | (Section 3.1.1) and blocks of header fields (Section 3.2). These are |
| minimum recommendations, chosen to be supportable even by |  | minimum recommendations, chosen to be supportable even by |
| implementations with limited resources; it is expected that most |  | implementations with limited resources; it is expected that most |
| implementations will choose substantially higher limits. |  | implementations will choose substantially higher limits. |
| This specification also provides a way for servers to reject messages |  | This specification also provides a way for servers to reject messages |
| that have request-targets that are too long (Section 7.5.12 of |  | that have request-targets that are too long (Section 6.5.12 of |
| [Part2]) or request entities that are too large (Section 7.5 of |  | [Part2]) or request entities that are too large (Section 6.5 of |
| [Part2]). |  | [Part2]). |
| Recipients SHOULD carefully limit the extent to which they read other |  | Recipients SHOULD carefully limit the extent to which they read other |
| fields, including (but not limited to) request methods, response |  | fields, including (but not limited to) request methods, response |
| status phrases, header field-names, and body chunks, so as to avoid |  | status phrases, header field-names, and body chunks, so as to avoid |
| denial of service attacks without impeding interoperability. |  | denial of service attacks without impeding interoperability. |
|  |  | 8.4. Message Integrity |
|  |  | HTTP does not define a specific mechanism for ensuring message |
|  |  | integrity, instead relying on the error-detection ability of |
|  |  | underlying transport protocols and the use of length or chunk- |
|  |  | delimited framing to detect completeness. Additional integrity |
|  |  | mechanisms, such as hash functions or digital signatures applied to |
|  |  | the content, can be selectively added to messages via extensible |
|  |  | metadata header fields. Historically, the lack of a single integrity |
|  |  | mechanism has been justified by the informal nature of most HTTP |
|  |  | communication. However, the prevalence of HTTP as an information |
|  |  | access mechanism has resulted in its increasing use within |
|  |  | environments where verification of message integrity is crucial. |
|  |  | User agents are encouraged to implement configurable means for |
|  |  | detecting and reporting failures of message integrity such that those |
|  |  | means can be enabled within environments for which integrity is |
|  |  | necessary. For example, a browser being used to view medical history |
|  |  | or drug interaction information needs to indicate to the user when |
|  |  | such information is detected by the protocol to be incomplete, |
|  |  | expired, or corrupted during transfer. Such mechanisms might be |
|  |  | selectively enabled via user agent extensions or the presence of |
|  |  | message integrity metadata in a response. At a minimum, user agents |
|  |  | ought to provide some indication that allows a user to distinguish |
|  |  | between a complete and incomplete response message (Section 3.4) when |
|  |  | such verification is desired. |
|  |  | 8.5. Server Log Information |
|  |  | A server is in the position to save personal data about a user's |
|  |  | requests over time, which might identify their reading patterns or |
|  |  | subjects of interest. In particular, log information gathered at an |
|  |  | intermediary often contains a history of user agent interaction, |
|  |  | across a multitude of sites, that can be traced to individual users. |
|  |  | HTTP log information is confidential in nature; its handling is often |
|  |  | constrained by laws and regulations. Log information needs to be |
|  |  | securely stored and appropriate guidelines followed for its analysis. |
|  |  | Anonymization of personal information within individual entries |
|  |  | helps, but is generally not sufficient to prevent real log traces |
|  |  | from being re-identified based on correlation with other access |
|  |  | characteristics. As such, access traces that are keyed to a specific |
|  |  | client should not be published even if the key is pseudonymous. |
|  |  | To minimize the risk of theft or accidental publication, log |
|  |  | information should be purged of personally identifiable information, |
|  |  | including user identifiers, IP addresses, and user-provided query |
|  |  | parameters, as soon as that information is no longer necessary to |
|  |  | support operational needs for security, auditing, or fraud control. |
| 9. Acknowledgments |  | 9. Acknowledgments |
| This edition of HTTP builds on the many contributions that went into |  | This edition of HTTP/1.1 builds on the many contributions that went |
| RFC 1945, RFC 2068, RFC 2145, and RFC 2616, including substantial |  | into RFC 1945, RFC 2068, RFC 2145, and RFC 2616, including |
| contributions made by the previous authors, editors, and working |  | substantial contributions made by the previous authors, editors, and |
| group chairs: Tim Berners-Lee, Ari Luotonen, Roy T. Fielding, Henrik |  | working group chairs: Tim Berners-Lee, Ari Luotonen, Roy T. Fielding, |
| Frystyk Nielsen, Jim Gettys, Jeffrey C. Mogul, Larry Masinter, Paul |  | Henrik Frystyk Nielsen, Jim Gettys, Jeffrey C. Mogul, Larry Masinter, |
| J. Leach, and Mark Nottingham. See Section 16 of [RFC2616] for |  | and Paul J. Leach. Mark Nottingham oversaw this effort as working |
| additional acknowledgements from prior revisions. |  | group chair. |
| Since 1999, the following contributors have helped improve the HTTP |  | Since 1999, the following contributors have helped improve the HTTP |
| specification by reporting bugs, asking smart questions, drafting or |  | specification by reporting bugs, asking smart questions, drafting or |
| reviewing text, and evaluating open issues: |  | reviewing text, and evaluating open issues: |
| Adam Barth, Adam Roach, Addison Phillips, Adrian Chadd, Adrien W. de |  | Adam Barth, Adam Roach, Addison Phillips, Adrian Chadd, Adrien W. de |
| Croy, Alan Ford, Alan Ruttenberg, Albert Lunde, Alek Storm, Alex |  | Croy, Alan Ford, Alan Ruttenberg, Albert Lunde, Alek Storm, Alex |
| Rousskov, Alexandre Morgaut, Alexey Melnikov, Alisha Smith, Amichai |  | Rousskov, Alexandre Morgaut, Alexey Melnikov, Alisha Smith, Amichai |
| Rothman, Amit Klein, Amos Jeffries, Andreas Maier, Andreas Petersson, |  | Rothman, Amit Klein, Amos Jeffries, Andreas Maier, Andreas Petersson, |
| Anil Sharma, Anne van Kesteren, Anthony Bryan, Asbjorn Ulsberg, |  | Anil Sharma, Anne van Kesteren, Anthony Bryan, Asbjorn Ulsberg, Ashok |
| Balachander Krishnamurthy, Barry Leiba, Ben Laurie, Benjamin Niven- |  | Kumar, Balachander Krishnamurthy, Barry Leiba, Ben Laurie, Benjamin |
| Jenkins, Bil Corry, Bill Burke, Bjoern Hoehrmann, Bob Scheifler, |  | Niven-Jenkins, Bil Corry, Bill Burke, Bjoern Hoehrmann, Bob |
| Boris Zbarsky, Brett Slatkin, Brian Kell, Brian McBarron, Brian Pane, |  | Scheifler, Boris Zbarsky, Brett Slatkin, Brian Kell, Brian McBarron, |
| Brian Smith, Bryce Nesbitt, Cameron Heavon-Jones, Carl Kugler, |  | Brian Pane, Brian Smith, Bryce Nesbitt, Cameron Heavon-Jones, Carl |
| Carsten Bormann, Charles Fry, Chris Newman, Cyrus Daboo, Dale Robert |  | Kugler, Carsten Bormann, Charles Fry, Chris Newman, Chris Weber, |
| Anderson, Dan Wing, Dan Winship, Daniel Stenberg, Dave Cridland, Dave |  | Cyrus Daboo, Dale Robert Anderson, Dan Wing, Dan Winship, Daniel |
| Crocker, Dave Kristol, David Booth, David Singer, David W. Morris, |  | Stenberg, Darrel Miller, Dave Cridland, Dave Crocker, Dave Kristol, |
| Diwakar Shetty, Dmitry Kurochkin, Drummond Reed, Duane Wessels, |  | David Booth, David Singer, David W. Morris, Diwakar Shetty, Dmitry |
| Edward Lee, Eliot Lear, Eran Hammer-Lahav, Eric D. Williams, Eric J. |  | Kurochkin, Drummond Reed, Duane Wessels, Duncan Cragg, Edward Lee, |
| Bowman, Eric Lawrence, Eric Rescorla, Erik Aronesty, Evan Prodromou, |  | Eliot Lear, Eran Hammer-Lahav, Eric D. Williams, Eric J. Bowman, Eric |
| Florian Weimer, Frank Ellermann, Fred Bohle, Gabriel Montenegro, |  | Lawrence, Eric Rescorla, Erik Aronesty, Evan Prodromou, Florian |
| Geoffrey Sneddon, Gervase Markham, Grahame Grieve, Greg Wilkins, |  | Weimer, Frank Ellermann, Fred Bohle, Gabriel Montenegro, Geoffrey |
| Harald Tveit Alvestrand, Harry Halpin, Helge Hess, Henrik Nordstrom, |  | Sneddon, Gervase Markham, Grahame Grieve, Greg Wilkins, Harald Tveit |
| Henry S. Thompson, Henry Story, Herbert van de Sompel, Howard Melman, |  | Alvestrand, Harry Halpin, Helge Hess, Henrik Nordstrom, Henry S. |
| Hugo Haas, Ian Fette, Ian Hickson, Ido Safruti, Ingo Struck, J. Ross |  | Thompson, Henry Story, Herbert van de Sompel, Howard Melman, Hugo |
| Nicoll, James H. Manger, James Lacey, James M. Snell, Jamie Lokier, |  | Haas, Ian Fette, Ian Hickson, Ido Safruti, Ilya Grigorik, Ingo |
| Jan Algermissen, Jeff Hodges (who came up with the term 'effective |  | Struck, J. Ross Nicoll, James H. Manger, James Lacey, James M. Snell, |
| Request-URI'), Jeff Walden, Jim Luther, Joe D. Williams, Joe |  | Jamie Lokier, Jan Algermissen, Jeff Hodges (who came up with the term |
| Gregorio, Joe Orton, John C. Klensin, John C. Mallery, John Cowan, |  | 'effective Request-URI'), Jeff Walden, Jeroen de Borst, Jim Luther, |
| John Kemp, John Panzer, John Schneider, John Stracke, John Sullivan, |  | Joe D. Williams, Joe Gregorio, Joe Orton, John C. Klensin, John C. |
| Jonas Sicking, Jonathan Billington, Jonathan Moore, Jonathan Rees, |  | Mallery, John Cowan, John Kemp, John Panzer, John Schneider, John |
| Jonathan Silvera, Jordi Ros, Joris Dobbelsteen, Josh Cohen, Julien |  | Stracke, John Sullivan, Jonas Sicking, Jonathan A. Rees, Jonathan |
| Pierre, Jungshik Shin, Justin Chapweske, Justin Erenkrantz, Justin |  | Billington, Jonathan Moore, Jonathan Rees, Jonathan Silvera, Jordi |
| James, Kalvinder Singh, Karl Dubost, Keith Hoffman, Keith Moore, Koen |  | Ros, Joris Dobbelsteen, Josh Cohen, Julien Pierre, Jungshik Shin, |
| Holtman, Konstantin Voronkov, Kris Zyp, Lisa Dusseault, Maciej |  | Justin Chapweske, Justin Erenkrantz, Justin James, Kalvinder Singh, |
| Stachowiak, Marc Schneider, Marc Slemko, Mark Baker, Mark Pauley, |  | Karl Dubost, Keith Hoffman, Keith Moore, Ken Murchison, Koen Holtman, |
| Mark Watson, Markus Isomaki, Markus Lanthaler, Martin J. Duerst, |  | Konstantin Voronkov, Kris Zyp, Lisa Dusseault, Maciej Stachowiak, |
| Martin Musatov, Martin Nilsson, Martin Thomson, Matt Lynch, Matthew |  | Marc Schneider, Marc Slemko, Mark Baker, Mark Pauley, Mark Watson, |
| Cox, Max Clark, Michael Burrows, Michael Hausenblas, Mike Amundsen, |  | Markus Isomaki, Markus Lanthaler, Martin J. Duerst, Martin Musatov, |
| Mike Belshe, Mike Kelly, Mike Schinkel, Miles Sabin, Murray S. |  | Martin Nilsson, Martin Thomson, Matt Lynch, Matthew Cox, Max Clark, |
| Kucherawy, Mykyta Yevstifeyev, Nathan Rixham, Nicholas Shanks, Nico |  | Michael Burrows, Michael Hausenblas, Mike Amundsen, Mike Belshe, Mike |
| Williams, Nicolas Alvarez, Nicolas Mailhot, Noah Slater, Pablo |  | Kelly, Mike Schinkel, Miles Sabin, Murray S. Kucherawy, Mykyta |
| Castro, Pat Hayes, Patrick R. McManus, Paul E. Jones, Paul Hoffman, |  | Yevstifeyev, Nathan Rixham, Nicholas Shanks, Nico Williams, Nicolas |
|  |  | Alvarez, Nicolas Mailhot, Noah Slater, Pablo Castro, Pat Hayes, |
|  |  | Patrick R. McManus, Patrik Faltstrom, Paul E. Jones, Paul Hoffman, |
| Paul Marquess, Peter Lepeska, Peter Saint-Andre, Peter Watkins, Phil |  | Paul Marquess, Peter Lepeska, Peter Saint-Andre, Peter Watkins, Phil |
| Archer, Philippe Mougin, Phillip Hallam-Baker, Poul-Henning Kamp, |  | Archer, Philippe Mougin, Phillip Hallam-Baker, Poul-Henning Kamp, |
| Preethi Natarajan, Rajeev Bector, Ray Polk, Reto Bachmann-Gmuer, |  | Preethi Natarajan, Rajeev Bector, Ray Polk, Reto Bachmann-Gmuer, |
| Richard Cyganiak, Robert Brewer, Robert Collins, Robert O'Callahan, |  | Richard Cyganiak, Robert Brewer, Robert Collins, Robert O'Callahan, |
| Robert Olofsson, Robert Sayre, Robert Siemer, Robert de Wilde, |  | Robert Olofsson, Robert Sayre, Robert Siemer, Robert de Wilde, |
| Roberto Javier Godoy, Roberto Peon, Ronny Widjaja, S. Mike Dierken, |  | Roberto Javier Godoy, Roberto Peon, Roland Zink, Ronny Widjaja, S. |
| Salvatore Loreto, Sam Johnston, Sam Ruby, Scott Lawrence (who |  | Mike Dierken, Salvatore Loreto, Sam Johnston, Sam Ruby, Scott |
| maintained the original issues list), Sean B. Palmer, Shane McCarron, |  | Lawrence (who maintained the original issues list), Sean B. Palmer, |
| Stefan Eissing, Stefan Tilkov, Stefanos Harhalakis, Stephane |  | Shane McCarron, Stefan Eissing, Stefan Tilkov, Stefanos Harhalakis, |
| Bortzmeyer, Stephen Farrell, Stephen Ludin, Stuart Williams, Subbu |  | Stephane Bortzmeyer, Stephen Farrell, Stephen Ludin, Stuart Williams, |
| Allamaraju, Sylvain Hellegouarch, Tapan Divekar, Tatsuya Hayashi, Ted |  | Subbu Allamaraju, Subramanian Moonesamy, Sylvain Hellegouarch, Tapan |
| Hardie, Thomas Broyer, Thomas Nordin, Thomas Roessler, Tim Bray, Tim |  | Divekar, Tatsuya Hayashi, Ted Hardie, Thomas Broyer, Thomas Fossati, |
| Morgan, Tim Olsen, Tom Zhou, Travis Snoozy, Tyler Close, Vincent |  | Thomas Nordin, Thomas Roessler, Tim Bray, Tim Morgan, Tim Olsen, |
|  |  | Tobias Oberstein, Tom Zhou, Travis Snoozy, Tyler Close, Vincent |
| Murphy, Wenbo Zhu, Werner Baumann, Wilbur Streett, Wilfredo Sanchez |  | Murphy, Wenbo Zhu, Werner Baumann, Wilbur Streett, Wilfredo Sanchez |
| Vega, William A. Rowe Jr., William Chan, Willy Tarreau, Xiaoshu Wang, |  | Vega, William A. Rowe Jr., William Chan, Willy Tarreau, Xiaoshu Wang, |
| Yaron Goland, Yngve Nysaeter Pettersen, Yoav Nir, Yogesh Bang, Yutaka |  | Yaron Goland, Yngve Nysaeter Pettersen, Yoav Nir, Yogesh Bang, Yutaka |
| Oiwa, Yves Lafon (long-time member of the editor team), Zed A. Shaw, |  | Oiwa, Yves Lafon (long-time member of the editor team), Zed A. Shaw, |
| and Zhong Yu. |  | and Zhong Yu. |
|  |  | See Section 16 of [RFC2616] for additional acknowledgements from |
|  |  | prior revisions. |
| 10. References |  | 10. References |
| 10.1. Normative References |  | 10.1. Normative References |
| [Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext |  | [Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext |
| Transfer Protocol (HTTP/1.1): Semantics and Content", |  | Transfer Protocol (HTTP/1.1): Semantics and Content", |
| draft-ietf-httpbis-p2-semantics-21 (work in progress), |  | draft-ietf-httpbis-p2-semantics-22 (work in progress), |
| October 2012. |  | February 2013. |
| [Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext |  | [Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext |
| Transfer Protocol (HTTP/1.1): Conditional Requests", |  | Transfer Protocol (HTTP/1.1): Conditional Requests", |
| draft-ietf-httpbis-p4-conditional-21 (work in |  | draft-ietf-httpbis-p4-conditional-22 (work in |
| progress), October 2012. |  | progress), February 2013. |
| [Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |  | [Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |
| "Hypertext Transfer Protocol (HTTP/1.1): Range |  | "Hypertext Transfer Protocol (HTTP/1.1): Range |
| Requests", draft-ietf-httpbis-p5-range-21 (work in |  | Requests", draft-ietf-httpbis-p5-range-22 (work in |
| progress), October 2012. |  | progress), February 2013. |
| [Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, |  | [Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, |
| Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", |  | Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", |
| draft-ietf-httpbis-p6-cache-21 (work in progress), |  | draft-ietf-httpbis-p6-cache-22 (work in progress), |
| October 2012. |  | February 2013. |
| [Part7] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext |  | [Part7] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext |
| Transfer Protocol (HTTP/1.1): Authentication", |  | Transfer Protocol (HTTP/1.1): Authentication", |
| draft-ietf-httpbis-p7-auth-21 (work in progress), |  | draft-ietf-httpbis-p7-auth-22 (work in progress), |
| October 2012. |  | February 2013. |
| [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. |
| [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format |  | [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format |
| Specification version 1.3", RFC 1951, May 1996. |  | Specification version 1.3", RFC 1951, May 1996. |
| [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and |  | [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and |
| G. Randers-Pehrson, "GZIP file format specification |  | G. Randers-Pehrson, "GZIP file format specification |
| version 4.3", RFC 1952, May 1996. |  | version 4.3", RFC 1952, May 1996. |
| skipping to change at page 65, line 22 |  | skipping to change at page 66, line 26 |
| [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for |  | [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for |
| Syntax Specifications: ABNF", STD 68, RFC 5234, |  | Syntax Specifications: ABNF", STD 68, RFC 5234, |
| January 2008. |  | January 2008. |
| [USASCII] American National Standards Institute, "Coded Character |  | [USASCII] American National Standards Institute, "Coded Character |
| Set -- 7-bit American Standard Code for Information |  | Set -- 7-bit American Standard Code for Information |
| Interchange", ANSI X3.4, 1986. |  | Interchange", ANSI X3.4, 1986. |
| 10.2. Informative References |  | 10.2. Informative References |
|  |  | [BCP115] Hansen, T., Hardie, T., and L. Masinter, "Guidelines |
|  |  | and Registration Procedures for New URI Schemes", |
|  |  | BCP 115, RFC 4395, February 2006. |
|  |  | [BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type |
|  |  | Specifications and Registration Procedures", BCP 13, |
|  |  | RFC 6838, January 2013. |
|  |  | [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration |
|  |  | Procedures for Message Header Fields", BCP 90, |
|  |  | RFC 3864, September 2004. |
| [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. |
| [Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and |  | [Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and |
| Politics", ACM Transactions on Internet Technology Vol. |  | Politics", ACM Transactions on Internet Technology Vol. |
| 1, #2, November 2001, |  | 1, #2, November 2001, |
| <http://arxiv.org/abs/cs.SE/0105018>. |  | <http://arxiv.org/abs/cs.SE/0105018>. |
| skipping to change at page 66, line 15 |  | skipping to change at page 67, line 31 |
| [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., |  | [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext |  | Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext |
| Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. |  | Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. |
| [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within |  | [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within |
| HTTP/1.1", RFC 2817, May 2000. |  | HTTP/1.1", RFC 2817, May 2000. |
| [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. |  | [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. |
| [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management |  |  |
| Mechanism", RFC 2965, October 2000. |  |  |
| [RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web |  | [RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web |
| Replication and Caching Taxonomy", RFC 3040, |  | Replication and Caching Taxonomy", RFC 3040, |
| January 2001. |  | January 2001. |
| [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration |  |  |
| Procedures for Message Header Fields", BCP 90, |  |  |
| RFC 3864, September 2004. |  |  |
| [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. |  | [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. |
| Rose, "DNS Security Introduction and Requirements", |  | Rose, "DNS Security Introduction and Requirements", |
| RFC 4033, March 2005. |  | RFC 4033, March 2005. |
| [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications |  |  |
| and Registration Procedures", BCP 13, RFC 4288, |  |  |
| December 2005. |  |  |
| [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines |  |  |
| and Registration Procedures for New URI Schemes", |  |  |
| BCP 115, RFC 4395, February 2006. |  |  |
| [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based |  | [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based |
| Kerberos and NTLM HTTP Authentication in Microsoft |  | Kerberos and NTLM HTTP Authentication in Microsoft |
| Windows", RFC 4559, June 2006. |  | Windows", RFC 4559, June 2006. |
| [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing |  | [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing |
| an IANA Considerations Section in RFCs", BCP 26, |  | an IANA Considerations Section in RFCs", BCP 26, |
| RFC 5226, May 2008. |  | RFC 5226, May 2008. |
| [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer |  | [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer |
| Security (TLS) Protocol Version 1.2", RFC 5246, |  | Security (TLS) Protocol Version 1.2", RFC 5246, |
| skipping to change at page 68, line 35 |  | skipping to change at page 69, line 40 |
| In HTTP/1.0, each connection is established by the client prior to |  | In HTTP/1.0, each connection is established by the client prior to |
| the request and closed by the server after sending the response. |  | the request and closed by the server after sending the response. |
| However, some implementations implement the explicitly negotiated |  | However, some implementations implement the explicitly negotiated |
| ("Keep-Alive") version of persistent connections described in Section |  | ("Keep-Alive") version of persistent connections described in Section |
| 19.7.1 of [RFC2068]. |  | 19.7.1 of [RFC2068]. |
| Some clients and servers might wish to be compatible with these |  | Some clients and servers might wish to be compatible with these |
| previous approaches to persistent connections, by explicitly |  | previous approaches to persistent connections, by explicitly |
| negotiating for them with a "Connection: keep-alive" request header |  | negotiating for them with a "Connection: keep-alive" request header |
| field. However, some experimental implementations of HTTP/1.0 |  | field. However, some experimental implementations of HTTP/1.0 |
| persistent connections are faulty; for example, if a HTTP/1.0 proxy |  | persistent connections are faulty; for example, if an HTTP/1.0 proxy |
| server doesn't understand Connection, it will erroneously forward |  | server doesn't understand Connection, it will erroneously forward |
| that header field to the next inbound server, which would result in a |  | that header field to the next inbound server, which would result in a |
| hung connection. |  | hung connection. |
| One attempted solution was the introduction of a Proxy-Connection |  | One attempted solution was the introduction of a Proxy-Connection |
| header field, targeted specifically at proxies. In practice, this |  | header field, targeted specifically at proxies. In practice, this |
| was also unworkable, because proxies are often deployed in multiple |  | was also unworkable, because proxies are often deployed in multiple |
| layers, bringing about the same problem discussed above. |  | layers, bringing about the same problem discussed above. |
| As a result, clients are encouraged not to send the Proxy-Connection |  | As a result, clients are encouraged not to send the Proxy-Connection |
| skipping to change at page 69, line 9 |  | skipping to change at page 70, line 15 |
| Clients are also encouraged to consider the use of Connection: keep- |  | Clients are also encouraged to consider the use of Connection: keep- |
| alive in requests carefully; while they can enable persistent |  | alive in requests carefully; while they can enable persistent |
| connections with HTTP/1.0 servers, clients using them need will need |  | connections with HTTP/1.0 servers, clients using them need will need |
| to monitor the connection for "hung" requests (which indicate that |  | to monitor the connection for "hung" requests (which indicate that |
| the client ought stop sending the header field), and this mechanism |  | the client ought stop sending the header field), and this mechanism |
| ought not be used by clients at all when a proxy is being used. |  | ought not be used by clients at all when a proxy is being used. |
| A.1.3. Introduction of Transfer-Encoding |  | A.1.3. Introduction of Transfer-Encoding |
| HTTP/1.1 introduces the Transfer-Encoding header field |  | HTTP/1.1 introduces the Transfer-Encoding header field |
| (Section 3.3.1). Proxies/gateways MUST remove any transfer-coding |  | (Section 3.3.1). Transfer codings need to be decoded prior to |
| prior to forwarding a message via a MIME-compliant protocol. |  | forwarding an HTTP message over a MIME-compliant protocol. |
| A.2. Changes from RFC 2616 |  | A.2. Changes from RFC 2616 |
| Clarify that the string "HTTP" in the HTTP-version ABNF production is |  | HTTP's approach to error handling has been explained. (Section 2.5) |
| case sensitive. Restrict the version numbers to be single digits due |  |  |
| to the fact that implementations are known to handle multi-digit |  |  |
| version numbers incorrectly. (Section 2.6) |  |  |
| Require that invalid whitespace around field-names be rejected. |  | The expectation to support HTTP/0.9 requests has been removed. |
| Change ABNF productions for header fields to only define the field |  |  |
|  |  | The term "Effective Request URI" has been introduced. (Section 5.5) |
|  |  | HTTP messages can be (and often are) buffered by implementations; |
|  |  | despite it sometimes being available as a stream, HTTP is |
|  |  | fundamentally a message-oriented protocol. (Section 3) |
|  |  | Minimum supported sizes for various protocol elements have been |
|  |  | suggested, to improve interoperability. |
|  |  | Header fields that span multiple lines ("line folding") are |
|  |  | deprecated. (Section 3.2.4) |
|  |  | The HTTP-version ABNF production has been clarified to be case- |
|  |  | sensitive. Additionally, version numbers has been restricted to |
|  |  | single digits, due to the fact that implementations are known to |
|  |  | handle multi-digit version numbers incorrectly. (Section 2.6) |
|  |  | The HTTPS URI scheme is now defined by this specification; |
|  |  | previously, it was done in Section 2.4 of [RFC2818]. (Section 2.7.2) |
|  |  | The HTTPS URI scheme implies end-to-end security. (Section 2.7.2) |
|  |  | Userinfo (i.e., username and password) are now disallowed in HTTP and |
|  |  | HTTPS URIs, because of security issues related to their transmission |
|  |  | on the wire. (Section 2.7.1) |
|  |  | Invalid whitespace around field-names is now required to be rejected, |
|  |  | because accepting it represents a security vulnerability. |
|  |  | (Section 3.2) |
|  |  | The ABNF productions defining header fields now only list the field |
| value. (Section 3.2) |  | value. (Section 3.2) |
| Rules about implicit linear whitespace between certain grammar |  | Rules about implicit linear whitespace between certain grammar |
| productions have been removed; now whitespace is only allowed where |  | productions have been removed; now whitespace is only allowed where |
| specifically defined in the ABNF. (Section 3.2.1) |  | specifically defined in the ABNF. (Section 3.2.3) |
|  |  | The NUL octet is no longer allowed in comment and quoted-string text, |
|  |  | and handling of backslash-escaping in them has been clarified. |
|  |  | (Section 3.2.6) |
| The NUL octet is no longer allowed in comment and quoted-string text. |  |  |
| The quoted-pair rule no longer allows escaping control characters |  | The quoted-pair rule no longer allows escaping control characters |
| other than HTAB. Non-ASCII content in header fields and reason |  | other than HTAB. (Section 3.2.6) |
| phrase has been obsoleted and made opaque (the TEXT rule was |  |  |
| removed). (Section 3.2.4) |  |  |
| Require recipients to handle bogus "Content-Length" header fields as |  | Non-ASCII content in header fields and the reason phrase has been |
| errors. (Section 3.3) |  | obsoleted and made opaque (the TEXT rule was removed). |
|  |  | (Section 3.2.6) |
| Remove reference to non-existent identity transfer-coding value |  | Bogus "Content-Length" header fields are now required to be handled |
| tokens. (Sections 3.3 and 4) |  | as errors by recipients. (Section 3.3.2) |
| Clarification that the chunk length does not include the count of the |  | The "identity" transfer coding token has been removed. (Sections 3.3 |
| octets in the chunk header and trailer. Furthermore disallowed line |  | and 4) |
| folding in chunk extensions, and deprecate their use. (Section 4.1) |  |  |
| Update use of abs_path production from RFC 1808 to the path-absolute |  | The algorithm for determining the message body length has been |
| + query components of RFC 3986. State that the asterisk form is |  | clarified to indicate all of the special cases (e.g., driven by |
| allowed for the OPTIONS request method only. (Section 5.3) |  | methods or status codes) that affect it, and that new protocol |
|  |  | elements cannot define such special cases. (Section 3.3.3) |
| Clarify exactly when "close" connection options have to be sent; drop |  | "multipart/byteranges" is no longer a way of determining message body |
| notion of header fields being "hop-by-hop" without being listed in |  | length detection. (Section 3.3.3) |
| the Connection header field. (Section 6.1) |  |  |
| Remove hard limit of two connections per server. Remove requirement |  | CONNECT is a new, special case in determining message body length. |
| to retry a sequence of requests as long it was idempotent. Remove |  | (Section 3.3.3) |
| requirements about when servers are allowed to close connections |  |  |
| prematurely. (Section 6.2) |  |  |
| Remove requirement to retry requests under certain circumstances when |  | Chunk length does not include the count of the octets in the chunk |
| the server prematurely closes the connection. (Section 6.2.2) |  | header and trailer. (Section 4.1) |
| Define the semantics of the Upgrade header field in responses other |  | Use of chunk extensions is deprecated, and line folding in them is |
| than 101 (this was incorporated from [RFC2817]). (Section 6.3) |  | disallowed. (Section 4.1) |
|  |  | The segment + query components of RFC3986 have been used to define |
|  |  | the request-target, instead of abs_path from RFC 1808. (Section 5.3) |
|  |  | The asterisk form of the request-target is only allowed in the |
|  |  | OPTIONS method. (Section 5.3) |
|  |  | Exactly when "close" connection options have to be sent has been |
|  |  | clarified. (Section 6.1) |
|  |  | "hop-by-hop" header fields are required to appear in the Connection |
|  |  | header field; just because they're defined as hop-by-hop in this |
|  |  | specification doesn't exempt them. (Section 6.1) |
|  |  | The limit of two connections per server has been removed. |
|  |  | (Section 6.3) |
|  |  | An idempotent sequence of requests is no longer required to be |
|  |  | retried. (Section 6.3) |
|  |  | The requirement to retry requests under certain circumstances when |
|  |  | the server prematurely closes the connection has been removed. |
|  |  | (Section 6.3) |
|  |  | Some extraneous requirements about when servers are allowed to close |
|  |  | connections prematurely have been removed. (Section 6.3) |
|  |  | The semantics of the Upgrade header field is now defined in responses |
|  |  | other than 101 (this was incorporated from [RFC2817]). (Section 6.7) |
| Registration of Transfer Codings now requires IETF Review |  | Registration of Transfer Codings now requires IETF Review |
| (Section 7.4) |  | (Section 7.4) |
| Take over the Upgrade Token Registry, previously defined in Section |  | The meaning of the "deflate" content coding has been clarified. |
| 7.2 of [RFC2817]. (Section 7.6) |  | (Section 4.2.2) |
| Empty list elements in list productions have been deprecated. |  | This specification now defines the Upgrade Token Registry, previously |
| (Appendix B) |  | defined in Section 7.2 of [RFC2817]. (Section 7.6) |
|  |  | Empty list elements in list productions (e.g., a list header |
|  |  | containing ", ,") have been deprecated. (Appendix B) |
|  |  | Issues with the Keep-Alive and Proxy-Connection headers in requests |
|  |  | are pointed out, with use of the latter being discouraged altogether. |
|  |  | (Appendix A.1.2) |
| Appendix B. ABNF list extension: #rule |  | Appendix B. ABNF list extension: #rule |
| A #rule extension to the ABNF rules of [RFC5234] is used to improve |  | A #rule extension to the ABNF rules of [RFC5234] is used to improve |
| readability in the definitions of some header field values. |  | readability in the definitions of some header field values. |
| A construct "#" is defined, similar to "*", for defining comma- |  | A construct "#" is defined, similar to "*", for defining comma- |
| delimited lists of elements. The full form is "<n>#<m>element" |  | delimited lists of elements. The full form is "<n>#<m>element" |
| indicating at least <n> and at most <m> elements, each separated by a |  | indicating at least <n> and at most <m> elements, each separated by a |
| single comma (",") and optional whitespace (OWS). |  | single comma (",") and optional whitespace (OWS). |
| skipping to change at page 71, line 11 |  | skipping to change at page 73, line 31 |
| #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ] |  | #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ] |
| 1#element => *( "," OWS ) element *( OWS "," [ OWS element ] ) |  | 1#element => *( "," OWS ) element *( OWS "," [ OWS element ] ) |
| Note that empty elements do not contribute to the count of elements |  | Note that empty elements do not contribute to the count of elements |
| present, though. |  | present, though. |
| For example, given these ABNF productions: |  | For example, given these ABNF productions: |
| example-list = 1#example-list-elmt |  | example-list = 1#example-list-elmt |
| example-list-elmt = token ; see Section 3.2.4 |  | example-list-elmt = token ; see Section 3.2.6 |
| Then these are valid values for example-list (not including the |  | Then these are valid values for example-list (not including the |
| double quotes, which are present for delimitation only): |  | double quotes, which are present for delimitation only): |
| "foo,bar" |  | "foo,bar" |
| "foo ,bar," |  | "foo ,bar," |
| "foo , ,bar,charlie " |  | "foo , ,bar,charlie " |
| But these values would be invalid, as at least one non-empty element |  | But these values would be invalid, as at least one non-empty element |
| is required: |  | is required: |
| skipping to change at page 72, line 14 |  | skipping to change at page 74, line 32 |
| URI-reference = <URI-reference, defined in [RFC3986], Section 4.1> |  | URI-reference = <URI-reference, defined in [RFC3986], Section 4.1> |
| Upgrade = *( "," OWS ) protocol *( OWS "," [ OWS protocol ] ) |  | Upgrade = *( "," OWS ) protocol *( OWS "," [ OWS protocol ] ) |
| Via = *( "," OWS ) ( received-protocol RWS received-by [ RWS comment |  | Via = *( "," OWS ) ( received-protocol RWS received-by [ RWS comment |
| ] ) *( OWS "," [ OWS ( received-protocol RWS received-by [ RWS |  | ] ) *( OWS "," [ OWS ( received-protocol RWS received-by [ RWS |
| comment ] ) ] ) |  | comment ] ) ] ) |
| absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3> |  | absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3> |
| absolute-form = absolute-URI |  | absolute-form = absolute-URI |
|  |  | absolute-path = 1*( "/" segment ) |
| asterisk-form = "*" |  | asterisk-form = "*" |
| attribute = token |  | attribute = token |
| authority = <authority, defined in [RFC3986], Section 3.2> |  | authority = <authority, defined in [RFC3986], Section 3.2> |
| authority-form = authority |  | authority-form = authority |
| chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF |  | chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF |
| chunk-data = 1*OCTET |  | chunk-data = 1*OCTET |
| chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-val ] ) |  | chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-val ] ) |
| chunk-ext-name = token |  | chunk-ext-name = token |
| chunk-ext-val = token / quoted-str-nf |  | chunk-ext-val = token / quoted-str-nf |
| chunk-size = 1*HEXDIG |  | chunk-size = 1*HEXDIG |
| chunked-body = *chunk last-chunk trailer-part CRLF |  | chunked-body = *chunk last-chunk trailer-part CRLF |
| comment = "(" *( ctext / quoted-cpair / comment ) ")" |  | comment = "(" *( ctext / quoted-cpair / comment ) ")" |
| connection-option = token |  | connection-option = token |
| ctext = OWS / %x21-27 ; '!'-''' |  | ctext = HTAB / SP / %x21-27 ; '!'-''' |
| / %x2A-5B ; '*'-'[' |  | / %x2A-5B ; '*'-'[' |
| / %x5D-7E ; ']'-'~' |  | / %x5D-7E ; ']'-'~' |
| / obs-text |  | / obs-text |
| field-content = *( HTAB / SP / VCHAR / obs-text ) |  | field-content = *( HTAB / SP / VCHAR / obs-text ) |
| field-name = token |  | field-name = token |
| field-value = *( field-content / obs-fold ) |  | field-value = *( field-content / obs-fold ) |
| header-field = field-name ":" OWS field-value BWS |  | header-field = field-name ":" OWS field-value BWS |
| http-URI = "http://" authority path-abempty [ "?" query ] |  | http-URI = "http://" authority path-abempty [ "?" query ] |
| https-URI = "https://" authority path-abempty [ "?" query ] |  | https-URI = "https://" authority path-abempty [ "?" query ] |
| last-chunk = 1*"0" [ chunk-ext ] CRLF |  | last-chunk = 1*"0" [ chunk-ext ] CRLF |
| message-body = *OCTET |  | message-body = *OCTET |
| method = token |  | method = token |
| obs-fold = CRLF ( SP / HTAB ) |  | obs-fold = CRLF ( SP / HTAB ) |
| obs-text = %x80-FF |  | obs-text = %x80-FF |
| origin-form = path-absolute [ "?" query ] |  | origin-form = absolute-path [ "?" query ] |
| partial-URI = relative-part [ "?" query ] |  | partial-URI = relative-part [ "?" query ] |
| path-abempty = <path-abempty, defined in [RFC3986], Section 3.3> |  | path-abempty = <path-abempty, defined in [RFC3986], Section 3.3> |
| path-absolute = <path-absolute, defined in [RFC3986], Section 3.3> |  |  |
| port = <port, defined in [RFC3986], Section 3.2.3> |  | port = <port, defined in [RFC3986], Section 3.2.3> |
| protocol = protocol-name [ "/" protocol-version ] |  | protocol = protocol-name [ "/" protocol-version ] |
| protocol-name = token |  | protocol-name = token |
| protocol-version = token |  | protocol-version = token |
| pseudonym = token |  | pseudonym = token |
| qdtext = OWS / "!" / %x23-5B ; '#'-'[' |  | qdtext = HTAB / SP / "!" / %x23-5B ; '#'-'[' |
| / %x5D-7E ; ']'-'~' |  | / %x5D-7E ; ']'-'~' |
| / obs-text |  | / obs-text |
| qdtext-nf = HTAB / SP / "!" / %x23-5B ; '#'-'[' |  | qdtext-nf = HTAB / SP / "!" / %x23-5B ; '#'-'[' |
| / %x5D-7E ; ']'-'~' |  | / %x5D-7E ; ']'-'~' |
| / obs-text |  | / obs-text |
| query = <query, defined in [RFC3986], Section 3.4> |  | query = <query, defined in [RFC3986], Section 3.4> |
| quoted-cpair = "\" ( HTAB / SP / VCHAR / obs-text ) |  | quoted-cpair = "\" ( HTAB / SP / VCHAR / obs-text ) |
| quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text ) |  | quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text ) |
| quoted-str-nf = DQUOTE *( qdtext-nf / quoted-pair ) DQUOTE |  | quoted-str-nf = DQUOTE *( qdtext-nf / quoted-pair ) DQUOTE |
| quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE |  | quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE |
| rank = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] ) |  | rank = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] ) |
| reason-phrase = *( HTAB / SP / VCHAR / obs-text ) |  | reason-phrase = *( HTAB / SP / VCHAR / obs-text ) |
| received-by = ( uri-host [ ":" port ] ) / pseudonym |  | received-by = ( uri-host [ ":" port ] ) / pseudonym |
| received-protocol = [ protocol-name "/" ] protocol-version |  | received-protocol = [ protocol-name "/" ] protocol-version |
| relative-part = <relative-part, defined in [RFC3986], Section 4.2> |  | relative-part = <relative-part, defined in [RFC3986], Section 4.2> |
| request-line = method SP request-target SP HTTP-version CRLF |  | request-line = method SP request-target SP HTTP-version CRLF |
| request-target = origin-form / absolute-form / authority-form / |  | request-target = origin-form / absolute-form / authority-form / |
| asterisk-form |  | asterisk-form |
|  |  | segment = <segment, defined in [RFC3986], Section 3.3> |
| special = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" / |  | special = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" / |
| DQUOTE / "/" / "[" / "]" / "?" / "=" / "{" / "}" |  | DQUOTE / "/" / "[" / "]" / "?" / "=" / "{" / "}" |
| start-line = request-line / status-line |  | start-line = request-line / status-line |
| status-code = 3DIGIT |  | status-code = 3DIGIT |
| status-line = HTTP-version SP status-code SP reason-phrase CRLF |  | status-line = HTTP-version SP status-code SP reason-phrase CRLF |
| t-codings = "trailers" / ( transfer-coding [ t-ranking ] ) |  | t-codings = "trailers" / ( transfer-coding [ t-ranking ] ) |
| t-ranking = OWS ";" OWS "q=" rank |  | t-ranking = OWS ";" OWS "q=" rank |
| tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." / |  | tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." / |
| "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA |  | "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA |
| skipping to change at page 74, line 4 |  | skipping to change at page 76, line 24 |
| token = 1*tchar |  | token = 1*tchar |
| trailer-part = *( header-field CRLF ) |  | trailer-part = *( header-field CRLF ) |
| transfer-coding = "chunked" / "compress" / "deflate" / "gzip" / |  | transfer-coding = "chunked" / "compress" / "deflate" / "gzip" / |
| transfer-extension |  | transfer-extension |
| transfer-extension = token *( OWS ";" OWS transfer-parameter ) |  | transfer-extension = token *( OWS ";" OWS transfer-parameter ) |
| transfer-parameter = attribute BWS "=" BWS value |  | transfer-parameter = attribute BWS "=" BWS value |
| uri-host = <host, defined in [RFC3986], Section 3.2.2> |  | uri-host = <host, defined in [RFC3986], Section 3.2.2> |
| value = word |  | value = word |
| word = token / quoted-string |  | word = token / quoted-string |
| Appendix D. Change Log (to be removed by RFC Editor before publication) |  | Appendix D. Change Log (to be removed by RFC Editor before publication) |
| D.1. Since RFC 2616 |  | D.1. Since RFC 2616 |
| Extracted relevant partitions from [RFC2616]. |  | Changes up to the first Working Group Last Call draft are summarized |
|  |  | in <http://trac.tools.ietf.org/html/ |
| D.2. Since draft-ietf-httpbis-p1-messaging-00 |  | draft-ietf-httpbis-p1-messaging-21#appendix-D>. |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/1>: "HTTP Version |  |  |
| should be case sensitive" |  |  |
| (<http://purl.org/NET/http-errata#verscase>) |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/2>: "'unsafe' |  |  |
| characters" (<http://purl.org/NET/http-errata#unsafe-uri>) |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/3>: "Chunk Size |  |  |
| Definition" (<http://purl.org/NET/http-errata#chunk-size>) |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/4>: "Message Length" |  |  |
| (<http://purl.org/NET/http-errata#msg-len-chars>) |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/8>: "Media Type |  |  |
| Registrations" (<http://purl.org/NET/http-errata#media-reg>) |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/11>: "URI includes |  |  |
| query" (<http://purl.org/NET/http-errata#uriquery>) |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/15>: "No close on |  |  |
| 1xx responses" (<http://purl.org/NET/http-errata#noclose1xx>) |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/16>: "Remove |  |  |
| 'identity' token references" |  |  |
| (<http://purl.org/NET/http-errata#identity>) |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/26>: "Import query |  |  |
| BNF" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/31>: "qdtext BNF" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and |  |  |
| Informative references" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/42>: "RFC2606 |  |  |
| Compliance" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/45>: "RFC977 |  |  |
| reference" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/46>: "RFC1700 |  |  |
| references" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/47>: "inconsistency |  |  |
| in date format explanation" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/48>: "Date reference |  |  |
| typo" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/65>: "Informative |  |  |
| references" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/66>: "ISO-8859-1 |  |  |
| Reference" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/86>: "Normative up- |  |  |
| to-date references" |  |  |
| Other changes: |  |  |
| o Update media type registrations to use RFC4288 template. |  |  |
| o Use names of RFC4234 core rules DQUOTE and HTAB, fix broken ABNF |  |  |
| for chunk-data (work in progress on |  |  |
| <http://tools.ietf.org/wg/httpbis/trac/ticket/36>) |  |  |
| D.3. Since draft-ietf-httpbis-p1-messaging-01 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/19>: "Bodies on GET |  |  |
| (and other) requests" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/55>: "Updating to |  |  |
| RFC4288" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/57>: "Status Code |  |  |
| and Reason Phrase" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/82>: "rel_path not |  |  |
| used" |  |  |
| Ongoing work on ABNF conversion |  |  |
| (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |  |  |
| o Get rid of duplicate BNF rule names ("host" -> "uri-host", |  |  |
| "trailer" -> "trailer-part"). |  |  |
| o Avoid underscore character in rule names ("http_URL" -> "http- |  |  |
| URL", "abs_path" -> "path-absolute"). |  |  |
| o Add rules for terms imported from URI spec ("absoluteURI", |  |  |
| "authority", "path-absolute", "port", "query", "relativeURI", |  |  |
| "host) -- these will have to be updated when switching over to |  |  |
| RFC3986. |  |  |
| o Synchronize core rules with RFC5234. |  |  |
| o Get rid of prose rules that span multiple lines. |  |  |
| o Get rid of unused rules LOALPHA and UPALPHA. |  |  |
| o Move "Product Tokens" section (back) into Part 1, as "token" is |  |  |
| used in the definition of the Upgrade header field. |  |  |
| o Add explicit references to BNF syntax and rules imported from |  |  |
| other parts of the specification. |  |  |
| o Rewrite prose rule "token" in terms of "tchar", rewrite prose rule |  |  |
| "TEXT". |  |  |
| D.4. Since draft-ietf-httpbis-p1-messaging-02 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/51>: "HTTP-date vs. |  |  |
| rfc1123-date" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/64>: "WS in quoted- |  |  |
| pair" |  |  |
| Ongoing work on IANA Message Header Field Registration |  |  |
| (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>): |  |  |
| o Reference RFC 3984, and update header field registrations for |  |  |
| header fields defined in this document. |  |  |
| Ongoing work on ABNF conversion |  |  |
| (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |  |  |
| o Replace string literals when the string really is case-sensitive |  |  |
| (HTTP-version). |  |  |
| D.5. Since draft-ietf-httpbis-p1-messaging-03 |  | D.2. Since draft-ietf-httpbis-p1-messaging-21 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/28>: "Connection |  |  |
| closing" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/97>: "Move |  |  |
| registrations and registry information to IANA Considerations" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/120>: "need new URL |  |  |
| for PAD1995 reference" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/127>: "IANA |  |  |
| Considerations: update HTTP URI scheme registration" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/128>: "Cite HTTPS |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/128>: "Cite HTTPS |
| URI scheme definition" |  | URI scheme definition" (the spec now includes the HTTPs scheme |
|  |  | definition and thus updates RFC 2818) |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/129>: "List-type |  |  |
| header fields vs Set-Cookie" |  |  |
| Ongoing work on ABNF conversion |  |  |
| (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |  |  |
| o Replace string literals when the string really is case-sensitive |  |  |
| (HTTP-Date). |  |  |
| o Replace HEX by HEXDIG for future consistence with RFC 5234's core |  |  |
| rules. |  |  |
| D.6. Since draft-ietf-httpbis-p1-messaging-04 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/34>: "Out-of-date |  |  |
| reference for URIs" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/132>: "RFC 2822 is |  |  |
| updated by RFC 5322" |  |  |
| Ongoing work on ABNF conversion |  |  |
| (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |  |  |
| o Use "/" instead of "|" for alternatives. |  |  |
| o Get rid of RFC822 dependency; use RFC5234 plus extensions instead. |  |  |
| o Only reference RFC 5234's core rules. |  |  |
| o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional |  |  |
| whitespace ("OWS") and required whitespace ("RWS"). |  |  |
| o Rewrite ABNFs to spell out whitespace rules, factor out header |  |  |
| field value format definitions. |  |  |
| D.7. Since draft-ietf-httpbis-p1-messaging-05 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/30>: "Header LWS" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/52>: "Sort 1.3 |  |  |
| Terminology" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/63>: "RFC2047 |  |  |
| encoded words" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/74>: "Character |  |  |
| Encodings in TEXT" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/77>: "Line Folding" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/83>: "OPTIONS * and |  |  |
| proxies" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/94>: "reason-phrase |  |  |
| BNF" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/111>: "Use of TEXT" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/118>: "Join |  |  |
| "Differences Between HTTP Entities and RFC 2045 Entities"?" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/134>: "RFC822 |  |  |
| reference left in discussion of date formats" |  |  |
| Final work on ABNF conversion |  |  |
| (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |  |  |
| o Rewrite definition of list rules, deprecate empty list elements. |  |  |
| o Add appendix containing collected and expanded ABNF. |  |  |
| Other changes: |  |  |
| o Rewrite introduction; add mostly new Architecture Section. |  |  |
| o Move definition of quality values from Part 3 into Part 1; make TE |  |  |
| request header field grammar independent of accept-params (defined |  |  |
| in Part 3). |  |  |
| D.8. Since draft-ietf-httpbis-p1-messaging-06 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/161>: "base for |  |  |
| numeric protocol elements" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/162>: "comment ABNF" |  |  |
| Partly resolved issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/88>: "205 Bodies" |  |  |
| (took out language that implied that there might be methods for |  |  |
| which a payload body MUST NOT be included) |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/163>: "editorial |  |  |
| improvements around HTTP-date" |  |  |
| D.9. Since draft-ietf-httpbis-p1-messaging-07 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/93>: "Repeating |  |  |
| single-value header fields" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/131>: "increase |  |  |
| connection limit" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/157>: "IP addresses |  |  |
| in URLs" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/172>: "take over |  |  |
| HTTP Upgrade Token Registry" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/173>: "CR and LF in |  |  |
| chunk extension values" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/184>: "HTTP/0.9 |  |  |
| support" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/188>: "pick IANA |  |  |
| policy (RFC5226) for Transfer Coding / Content Coding" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/189>: "move |  |  |
| definitions of gzip/deflate/compress to part 1" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/194>: "disallow |  |  |
| control characters in quoted-pair" |  |  |
| Partly resolved issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/148>: "update IANA |  |  |
| requirements wrt Transfer-Coding values" (add the IANA |  |  |
| Considerations subsection) |  |  |
| D.10. Since draft-ietf-httpbis-p1-messaging-08 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/201>: "header |  |  |
| parsing, treatment of leading and trailing OWS" |  |  |
| Partly resolved issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/60>: "Placement of |  |  |
| 13.5.1 and 13.5.2" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/200>: "use of term |  |  |
| "word" when talking about header field structure" |  |  |
| D.11. Since draft-ietf-httpbis-p1-messaging-09 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/73>: "Clarification |  |  |
| of the term 'deflate'" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/83>: "OPTIONS * and |  |  |
| proxies" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/122>: "MIME-Version |  |  |
| not listed in P1, general header fields" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/143>: "IANA registry |  |  |
| for content/transfer encodings" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/165>: "Case- |  |  |
| sensitivity of HTTP-date" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/200>: "use of term |  |  |
| "word" when talking about header field structure" |  |  |
| Partly resolved issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/196>: "Term for the |  |  |
| requested resource's URI" |  |  |
| D.12. Since draft-ietf-httpbis-p1-messaging-10 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/28>: "Connection |  |  |
| Closing" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/90>: "Delimiting |  |  |
| messages with multipart/byteranges" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/95>: "Handling |  |  |
| multiple Content-Length header fields" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/109>: "Clarify |  |  |
| entity / representation / variant terminology" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider |  |  |
| removing the 'changes from 2068' sections" |  |  |
| Partly resolved issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/159>: "HTTP(s) URI |  |  |
| scheme definitions" |  |  |
| D.13. Since draft-ietf-httpbis-p1-messaging-11 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/193>: "Trailer |  |  |
| requirements" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/204>: "Text about |  |  |
| clock requirement for caches belongs in p6" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/221>: "effective |  |  |
| request URI: handling of missing host in HTTP/1.0" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/248>: "confusing |  |  |
| Date requirements for clients" |  |  |
| Partly resolved issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/95>: "Handling |  |  |
| multiple Content-Length header fields" |  |  |
| D.14. Since draft-ietf-httpbis-p1-messaging-12 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/75>: "RFC2145 |  |  |
| Normative" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/159>: "HTTP(s) URI |  |  |
| scheme definitions" (tune the requirements on userinfo) |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/210>: "define |  |  |
| 'transparent' proxy" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/224>: "Header Field |  |  |
| Classification" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/233>: "Is * usable |  |  |
| as a request-uri for new methods?" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/240>: "Migrate |  |  |
| Upgrade details from RFC2817" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle |  |  |
| ABNFs for header fields" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/279>: "update RFC |  |  |
| 2109 reference" |  |  |
| D.15. Since draft-ietf-httpbis-p1-messaging-13 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/53>: "Allow is not |  |  |
| in 13.5.2" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/95>: "Handling |  |  |
| multiple Content-Length header fields" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle |  |  |
| ABNFs for header fields" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/286>: "Content- |  |  |
| Length ABNF broken" |  |  |
| D.16. Since draft-ietf-httpbis-p1-messaging-14 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/273>: "HTTP-version |  |  |
| should be redefined as fixed length pair of DIGIT . DIGIT" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/282>: "Recommend |  |  |
| minimum sizes for protocol elements" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/283>: "Set |  |  |
| expectations around buffering" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/288>: "Considering |  |  |
| messages in isolation" |  |  |
| D.17. Since draft-ietf-httpbis-p1-messaging-15 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/100>: "DNS Spoofing |  |  |
| / DNS Binding advice" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/254>: "move RFCs |  |  |
| 2145, 2616, 2817 to Historic status" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/270>: "\-escaping in |  |  |
| quoted strings" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/305>: "'Close' |  |  |
| should be reserved in the HTTP header field registry" |  |  |
| D.18. Since draft-ietf-httpbis-p1-messaging-16 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/186>: "Document |  |  |
| HTTP's error-handling philosophy" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/215>: "Explain |  |  |
| header field registration" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/219>: "Revise |  |  |
| Acknowledgements Sections" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/297>: "Retrying |  |  |
| Requests" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/318>: "Closing the |  |  |
| connection on server error" |  |  |
| D.19. Since draft-ietf-httpbis-p1-messaging-17 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/158>: "Proxy- |  |  |
| Connection and Keep-Alive" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/166>: "Clarify 'User |  |  |
| Agent'" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/300>: "Define non- |  |  |
| final responses" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/323>: "intended |  |  |
| maturity level vs normative references" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/324>: "Intermediary |  |  |
| rewriting of queries" |  |  |
| D.20. Since draft-ietf-httpbis-p1-messaging-18 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/250>: "message-body |  |  |
| in CONNECT response" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/302>: "Misplaced |  |  |
| text on connection handling in p2" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/335>: "wording of |  |  |
| line folding rule" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/343>: "chunk- |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/389>: "mention of |
| extensions" |  | 'proxies' in section about caches" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/346>: "make IANA |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/390>: "use of ABNF |
| policy definitions consistent" |  | terms from RFC 3986" |
| D.21. Since draft-ietf-httpbis-p1-messaging-19 |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/392>: "editorial |
|  |  | improvements to message length definition" |
| Closed issues: |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/395>: "Connection |
|  |  | header field MUST vs SHOULD" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/346>: "make IANA |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/396>: "editorial |
| policy definitions consistent" |  | improvements to persistent connections section" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/359>: "clarify |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/397>: "URI |
| connection header field values are case-insensitive" |  | normalization vs empty path" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/361>: "ABNF |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/408>: "p1 feedback" |
| requirements for recipients" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/368>: "note |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/409>: "is parsing |
| introduction of new IANA registries as normative changes" |  | OBS-FOLD mandatory?" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/374>: "Reference to |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/410>: "HTTPS and |
| ISO-8859-1 is informative" |  | Shared Caching" |
| D.22. Since draft-ietf-httpbis-p1-messaging-20 |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/411>: "Requirements |
|  |  | for recipients of ws between start-line and first header field" |
| Closed issues: |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/412>: "SP and HT |
|  |  | when being tolerant" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/378>: "is 'q=' case- |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/414>: "Message |
| sensitive?" |  | Parsing Strictness" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/383>: "Semantics of |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/415>: "'Render'" |
| HTTPS" |  |  |
| Other changes: |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/418>: "No-Transform" |
| o Drop notion of header fields being "hop-by-hop" without being |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/419>: "p2 editorial |
| listed in the Connection header field. |  | feedback" |
| o Section about connection management rewritten; dropping some |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/420>: "Content- |
| historic information. |  | Length SHOULD be sent" |
| o Move description of "100-continue" into Part 2. |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/431>: "origin-form |
|  |  | does not allow path starting with "//"" |
| o Rewrite the persistent connection and Upgrade requirements to be |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/433>: "ambiguity in |
| actionable by role and consistent with the rest of HTTP. |  | part 1 example" |
| Index |  | Index |
| A |  | A |
| absolute-form (of request-target) 39 |  | absolute-form (of request-target) 40 |
| accelerator 10 |  | accelerator 10 |
| application/http Media Type 57 |  | application/http Media Type 58 |
| asterisk-form (of request-target) 39 |  | asterisk-form (of request-target) 41 |
| authority-form (of request-target) 39 |  | authority-form (of request-target) 41 |
| B |  | B |
| browser 7 |  | browser 7 |
| C |  | C |
| cache 11 |  | cache 11 |
| cacheable 12 |  | cacheable 12 |
| captive portal 11 |  | captive portal 11 |
| chunked (Coding Format) 33 |  | chunked (Coding Format) 27, 30, 34 |
| client 7 |  | client 7 |
| close 46, 52 |  | close 48, 53 |
| compress (Coding Format) 35 |  | compress (Coding Format) 37 |
| connection 7 |  | connection 7 |
| Connection header field 46, 52 |  | Connection header field 48, 53 |
| Content-Length header field 28 |  | Content-Length header field 28 |
| D |  | D |
| deflate (Coding Format) 35 |  | deflate (Coding Format) 37 |
| downstream 9 |  | downstream 9 |
| E |  | E |
| effective request URI 41 |  | effective request URI 43 |
| G |  | G |
| gateway 10 |  | gateway 10 |
| Grammar |  | Grammar |
| absolute-form 38 |  | absolute-form 40 |
| absolute-URI 15 |  | absolute-path 16 |
|  |  | absolute-URI 16 |
| ALPHA 6 |  | ALPHA 6 |
| asterisk-form 38 |  | asterisk-form 40 |
| attribute 33 |  | attribute 34 |
| authority 15 |  | authority 16 |
| authority-form 38 |  | authority-form 40 |
| BWS 23 |  | BWS 24 |
| chunk 33 |  | chunk 35 |
| chunk-data 33 |  | chunk-data 35 |
| chunk-ext 33 |  | chunk-ext 35 |
| chunk-ext-name 33 |  | chunk-ext-name 35 |
| chunk-ext-val 33 |  | chunk-ext-val 35 |
| chunk-size 33 |  | chunk-size 35 |
| chunked-body 33 |  | chunked-body 35 |
| comment 25 |  | comment 26 |
| Connection 47 |  | Connection 48 |
| connection-option 47 |  | connection-option 48 |
| Content-Length 28 |  | Content-Length 29 |
| CR 6 |  | CR 6 |
| CRLF 6 |  | CRLF 6 |
| ctext 25 |  | ctext 26 |
| CTL 6 |  | CTL 6 |
| date2 33 |  | date2 34 |
| date3 33 |  | date3 34 |
| DIGIT 6 |  | DIGIT 6 |
| DQUOTE 6 |  | DQUOTE 6 |
| field-content 21 |  | field-content 22 |
| field-name 21 |  | field-name 22 |
| field-value 21 |  | field-value 22 |
| header-field 21 |  | header-field 22 |
| HEXDIG 6 |  | HEXDIG 6 |
| Host 40 |  | Host 42 |
| HTAB 6 |  | HTAB 6 |
| HTTP-message 18 |  | HTTP-message 19 |
| HTTP-name 13 |  | HTTP-name 13 |
| http-URI 16 |  | http-URI 16 |
| HTTP-version 13 |  | HTTP-version 13 |
| https-URI 17 |  | https-URI 18 |
| last-chunk 33 |  | last-chunk 35 |
| LF 6 |  | LF 6 |
| message-body 26 |  | message-body 26 |
| method 20 |  | method 20 |
| obs-fold 21 |  | obs-fold 22 |
| obs-text 25 |  | obs-text 26 |
| OCTET 6 |  | OCTET 6 |
| origin-form 38 |  | origin-form 40 |
| OWS 23 |  | OWS 24 |
| partial-URI 15 |  | partial-URI 16 |
| path-absolute 15 |  | port 16 |
| port 15 |  | protocol-name 45 |
| protocol-name 43 |  | protocol-version 45 |
| protocol-version 43 |  | pseudonym 45 |
| pseudonym 43 |  | qdtext 26 |
| qdtext 25 |  | qdtext-nf 35 |
| qdtext-nf 33 |  | query 16 |
| query 15 |  | quoted-cpair 26 |
| quoted-cpair 25 |  | quoted-pair 26 |
| quoted-pair 25 |  | quoted-str-nf 35 |
| quoted-str-nf 33 |  | quoted-string 26 |
| quoted-string 25 |  | rank 37 |
| rank 36 |  |  |
| reason-phrase 21 |  | reason-phrase 21 |
| received-by 43 |  | received-by 45 |
| received-protocol 43 |  | received-protocol 45 |
| request-line 20 |  | request-line 20 |
| request-target 38 |  | request-target 40 |
| RWS 23 |  | RWS 24 |
|  |  | segment 16 |
| SP 6 |  | SP 6 |
| special 25 |  | special 25 |
| start-line 19 |  | start-line 20 |
| status-code 21 |  | status-code 21 |
| status-line 21 |  | status-line 21 |
| t-codings 36 |  | t-codings 37 |
| t-ranking 36 |  | t-ranking 37 |
| tchar 25 |  | tchar 25 |
| TE 36 |  | TE 37 |
| token 25 |  | token 25 |
| Trailer 34 |  | Trailer 35 |
| trailer-part 33 |  | trailer-part 35 |
| transfer-coding 33 |  | transfer-coding 34 |
| Transfer-Encoding 26 |  | Transfer-Encoding 27 |
| transfer-extension 33 |  | transfer-extension 34 |
| transfer-parameter 33 |  | transfer-parameter 34 |
| Upgrade 53 |  | Upgrade 54 |
| uri-host 15 |  | uri-host 16 |
| URI-reference 15 |  | URI-reference 16 |
| value 33 |  | value 34 |
| VCHAR 6 |  | VCHAR 6 |
| Via 43 |  | Via 45 |
| word 25 |  | word 25 |
| gzip (Coding Format) 36 |  | gzip (Coding Format) 37 |
| H |  | H |
| header field 18 |  | header field 19 |
| header section 18 |  | header section 19 |
| headers 18 |  | headers 19 |
| Host header field 40 |  | Host header field 41 |
| http URI scheme 16 |  | http URI scheme 16 |
| https URI scheme 17 |  | https URI scheme 17 |
| I |  | I |
| inbound 9 |  | inbound 9 |
| interception proxy 11 |  | interception proxy 11 |
| intermediary 9 |  | intermediary 9 |
| M |  | M |
| Media Type |  | Media Type |
| application/http 57 |  | application/http 58 |
| message/http 56 |  | message/http 57 |
| message 7 |  | message 7 |
| message/http Media Type 56 |  | message/http Media Type 57 |
| method 20 |  | method 20 |
| N |  | N |
| non-transforming proxy 10 |  | non-transforming proxy 10 |
| O |  | O |
| origin server 7 |  | origin server 7 |
| origin-form (of request-target) 38 |  | origin-form (of request-target) 40 |
| outbound 9 |  | outbound 9 |
| P |  | P |
| proxy 10 |  | proxy 10 |
| R |  | R |
| recipient 7 |  | recipient 7 |
| request 7 |  | request 7 |
| request-target 20 |  | request-target 20 |
| resource 15 |  | resource 15 |
| response 7 |  | response 7 |
| reverse proxy 10 |  | reverse proxy 10 |
| S |  | S |
| sender 7 |  | sender 7 |
| server 7 |  | server 7 |
| spider 7 |  | spider 7 |
| T |  | T |
| target resource 37 |  | target resource 38 |
| target URI 37 |  | target URI 38 |
| TE header field 36 |  | TE header field 37 |
| Trailer header field 34 |  | Trailer header field 35 |
| Transfer-Encoding header field 26 |  | Transfer-Encoding header field 27 |
| transforming proxy 10 |  | transforming proxy 10 |
| transparent proxy 11 |  | transparent proxy 11 |
| tunnel 11 |  | tunnel 11 |
| U |  | U |
| Upgrade header field 53 |  | Upgrade header field 54 |
| upstream 9 |  | upstream 9 |
| URI scheme |  | URI scheme |
| http 16 |  | http 16 |
| https 17 |  | https 17 |
| user agent 7 |  | user agent 7 |
| V |  | V |
| Via header field 43 |  | Via header field 45 |
| Authors' Addresses |  | Authors' Addresses |
| Roy T. Fielding (editor) |  | Roy T. Fielding (editor) |
| Adobe Systems Incorporated |  | Adobe Systems Incorporated |
| 345 Park Ave |  | 345 Park Ave |
| San Jose, CA 95110 |  | San Jose, CA 95110 |
| USA |  | USA |
| EMail: fielding@gbiv.com |  | EMail: fielding@gbiv.com |
End of changes. 270 change blocks.
| 1397 lines changed or deleted |  | 972 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/