| draft-ietf-httpbis-p1-messaging-19.txt |  | draft-ietf-httpbis-p1-messaging-20.txt |
--- | --- | --- | --- | ---
| HTTPbis Working Group R. Fielding, Ed. |  | HTTPbis Working Group R. Fielding, Ed. |
| Internet-Draft Adobe |  | Internet-Draft Adobe |
| Obsoletes: 2145,2616 (if approved) Y. Lafon, Ed. |  | Obsoletes: 2145,2616 (if approved) Y. Lafon, Ed. |
| Updates: 2817 (if approved) W3C |  | Updates: 2817 (if approved) W3C |
| Intended status: Standards Track J. Reschke, Ed. |  | Intended status: Standards Track J. Reschke, Ed. |
| Expires: September 13, 2012 greenbytes |  | Expires: January 17, 2013 greenbytes |
| March 12, 2012 |  | July 16, 2012 |
| HTTP/1.1, part 1: URIs, Connections, and Message Parsing |  | HTTP/1.1, part 1: Message Routing and Syntax" |
| draft-ietf-httpbis-p1-messaging-19 |  | draft-ietf-httpbis-p1-messaging-20 |
| Abstract |  | Abstract |
| The Hypertext Transfer Protocol (HTTP) is an application-level |  | The Hypertext Transfer Protocol (HTTP) is an application-level |
| protocol for distributed, collaborative, hypertext information |  | protocol for distributed, collaborative, hypertext information |
| systems. HTTP has been in use by the World Wide Web global |  | systems. HTTP has been in use by the World Wide Web global |
| information initiative since 1990. This document is Part 1 of the |  | information initiative since 1990. This document provides an |
| seven-part specification that defines the protocol referred to as |  | overview of HTTP architecture and its associated terminology, defines |
| "HTTP/1.1" and, taken together, obsoletes RFC 2616 and moves it to |  | the "http" and "https" Uniform Resource Identifier (URI) schemes, |
| historic status, along with its predecessor RFC 2068. |  | defines the HTTP/1.1 message syntax and parsing requirements, and |
|  |  | describes general security concerns for implementations. |
| Part 1 provides an overview of HTTP and its associated terminology, |  |  |
| defines the "http" and "https" Uniform Resource Identifier (URI) |  |  |
| schemes, defines the generic message syntax and parsing requirements |  |  |
| for HTTP message frames, and describes general security concerns for |  |  |
| implementations. |  |  |
| This part also obsoletes RFCs 2145 (on HTTP version numbers) and 2817 |  |  |
| (on using CONNECT for TLS upgrades) and moves them to historic |  |  |
| status. |  |  |
| Editorial Note (To be removed by RFC Editor) |  | Editorial Note (To be removed by RFC Editor) |
| Discussion of this draft should take place on the HTTPBIS working |  | Discussion of this draft takes place on the HTTPBIS working group |
| 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 C.20. |  | The changes in this draft are summarized in Appendix D.21. |
| 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 September 13, 2012. |  | This Internet-Draft will expire on January 17, 2013. |
| Copyright Notice |  | Copyright Notice |
| Copyright (c) 2012 IETF Trust and the persons identified as the |  | Copyright (c) 2012 IETF Trust and the persons identified as the |
| document authors. All rights reserved. |  | document authors. All rights reserved. |
| This document is subject to BCP 78 and the IETF Trust's Legal |  | This document is subject to BCP 78 and the IETF Trust's Legal |
| Provisions Relating to IETF Documents |  | Provisions Relating to IETF Documents |
| (http://trustee.ietf.org/license-info) in effect on the date of |  | (http://trustee.ietf.org/license-info) in effect on the date of |
| publication of this document. Please review these documents |  | publication of this document. Please review these documents |
| skipping to change at page 3, line 4 |  | skipping to change at page 2, line 43 |
| it for publication as an RFC or to translate it into languages other |  | it for publication as an RFC or to translate it into languages other |
| than English. |  | than English. |
| Table of Contents |  | Table of Contents |
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 |  | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 |
| 1.1. Requirement Notation . . . . . . . . . . . . . . . . . . . 7 |  | 1.1. Requirement Notation . . . . . . . . . . . . . . . . . . . 7 |
| 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7 |  | 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7 |
| 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 7 |  | 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 7 |
| 2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 7 |  | 2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 7 |
| 2.2. Connections and Transport Independence . . . . . . . . . . 9 |  | 2.2. Implementation Diversity . . . . . . . . . . . . . . . . . 9 |
| 2.3. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 9 |  | 2.3. Connections and Transport Independence . . . . . . . . . . 10 |
| 2.4. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 12 |  | 2.4. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 10 |
| 2.5. Conformance and Error Handling . . . . . . . . . . . . . . 12 |  | 2.5. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 13 |
| 2.6. Protocol Versioning . . . . . . . . . . . . . . . . . . . 13 |  | 2.6. Conformance and Error Handling . . . . . . . . . . . . . . 13 |
| 2.7. Uniform Resource Identifiers . . . . . . . . . . . . . . . 15 |  | 2.7. Protocol Versioning . . . . . . . . . . . . . . . . . . . 14 |
| 2.7.1. http URI scheme . . . . . . . . . . . . . . . . . . . 16 |  | 2.8. Uniform Resource Identifiers . . . . . . . . . . . . . . . 16 |
| 2.7.2. https URI scheme . . . . . . . . . . . . . . . . . . . 17 |  | 2.8.1. http URI scheme . . . . . . . . . . . . . . . . . . . 17 |
| 2.7.3. http and https URI Normalization and Comparison . . . 18 |  | 2.8.2. https URI scheme . . . . . . . . . . . . . . . . . . . 18 |
| 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 19 |  | 2.8.3. http and https URI Normalization and Comparison . . . 19 |
| 3.1. Start Line . . . . . . . . . . . . . . . . . . . . . . . . 19 |  | 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 20 |
| 3.1.1. Request Line . . . . . . . . . . . . . . . . . . . . . 20 |  | 3.1. Start Line . . . . . . . . . . . . . . . . . . . . . . . . 20 |
| 3.1.2. Status Line . . . . . . . . . . . . . . . . . . . . . 21 |  | 3.1.1. Request Line . . . . . . . . . . . . . . . . . . . . . 21 |
| 3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 21 |  | 3.1.2. Status Line . . . . . . . . . . . . . . . . . . . . . 22 |
| 3.2.1. Whitespace . . . . . . . . . . . . . . . . . . . . . . 23 |  | 3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 23 |
| 3.2.2. Field Parsing . . . . . . . . . . . . . . . . . . . . 23 |  | 3.2.1. Whitespace . . . . . . . . . . . . . . . . . . . . . . 24 |
| 3.2.3. Field Length . . . . . . . . . . . . . . . . . . . . . 24 |  | 3.2.2. Field Parsing . . . . . . . . . . . . . . . . . . . . 25 |
| 3.2.4. Field value components . . . . . . . . . . . . . . . . 25 |  | 3.2.3. Field Length . . . . . . . . . . . . . . . . . . . . . 25 |
| 3.2.5. ABNF list extension: #rule . . . . . . . . . . . . . . 26 |  | 3.2.4. Field value components . . . . . . . . . . . . . . . . 26 |
| 3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 27 |  | 3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 27 |
| 3.3.1. Transfer-Encoding . . . . . . . . . . . . . . . . . . 27 |  | 3.3.1. Transfer-Encoding . . . . . . . . . . . . . . . . . . 27 |
| 3.3.2. Content-Length . . . . . . . . . . . . . . . . . . . . 29 |  | 3.3.2. Content-Length . . . . . . . . . . . . . . . . . . . . 29 |
| 3.3.3. Message Body Length . . . . . . . . . . . . . . . . . 30 |  | 3.3.3. Message Body Length . . . . . . . . . . . . . . . . . 30 |
| 3.4. Handling Incomplete Messages . . . . . . . . . . . . . . . 32 |  | 3.4. Handling Incomplete Messages . . . . . . . . . . . . . . . 32 |
| 3.5. Message Parsing Robustness . . . . . . . . . . . . . . . . 33 |  | 3.5. Message Parsing Robustness . . . . . . . . . . . . . . . . 33 |
| 4. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . . 33 |  | 4. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . . 33 |
| 4.1. Chunked Transfer Coding . . . . . . . . . . . . . . . . . 34 |  | 4.1. Chunked Transfer Coding . . . . . . . . . . . . . . . . . 34 |
| 4.2. Compression Codings . . . . . . . . . . . . . . . . . . . 36 |  | 4.2. Compression Codings . . . . . . . . . . . . . . . . . . . 36 |
| 4.2.1. Compress Coding . . . . . . . . . . . . . . . . . . . 36 |  | 4.2.1. Compress Coding . . . . . . . . . . . . . . . . . . . 36 |
| skipping to change at page 4, line 6 |  | skipping to change at page 3, line 45 |
| 5.6. Intermediary Forwarding . . . . . . . . . . . . . . . . . 44 |  | 5.6. Intermediary Forwarding . . . . . . . . . . . . . . . . . 44 |
| 5.6.1. End-to-end and Hop-by-hop Header Fields . . . . . . . 45 |  | 5.6.1. End-to-end and Hop-by-hop Header Fields . . . . . . . 45 |
| 5.6.2. Non-modifiable Header Fields . . . . . . . . . . . . . 46 |  | 5.6.2. Non-modifiable Header Fields . . . . . . . . . . . . . 46 |
| 5.7. Associating a Response to a Request . . . . . . . . . . . 47 |  | 5.7. Associating a Response to a Request . . . . . . . . . . . 47 |
| 6. Connection Management . . . . . . . . . . . . . . . . . . . . 47 |  | 6. Connection Management . . . . . . . . . . . . . . . . . . . . 47 |
| 6.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 47 |  | 6.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 47 |
| 6.2. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 |  | 6.2. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 |
| 6.3. Persistent Connections . . . . . . . . . . . . . . . . . . 50 |  | 6.3. Persistent Connections . . . . . . . . . . . . . . . . . . 50 |
| 6.3.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 50 |  | 6.3.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 50 |
| 6.3.2. Overall Operation . . . . . . . . . . . . . . . . . . 51 |  | 6.3.2. Overall Operation . . . . . . . . . . . . . . . . . . 51 |
| 6.3.3. Practical Considerations . . . . . . . . . . . . . . . 52 |  | 6.3.3. Practical Considerations . . . . . . . . . . . . . . . 53 |
| 6.3.4. Retrying Requests . . . . . . . . . . . . . . . . . . 53 |  | 6.3.4. Retrying Requests . . . . . . . . . . . . . . . . . . 53 |
| 6.4. Message Transmission Requirements . . . . . . . . . . . . 54 |  | 6.4. Message Transmission Requirements . . . . . . . . . . . . 54 |
| 6.4.1. Persistent Connections and Flow Control . . . . . . . 54 |  | 6.4.1. Persistent Connections and Flow Control . . . . . . . 54 |
| 6.4.2. Monitoring Connections for Error Status Messages . . . 54 |  | 6.4.2. Monitoring Connections for Error Status Messages . . . 54 |
| 6.4.3. Use of the 100 (Continue) Status . . . . . . . . . . . 54 |  | 6.4.3. Use of the 100 (Continue) Status . . . . . . . . . . . 54 |
| 6.4.4. Closing Connections on Error . . . . . . . . . . . . . 56 |  | 6.4.4. Closing Connections on Error . . . . . . . . . . . . . 56 |
| 6.5. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 56 |  | 6.5. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 56 |
| 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58 |  | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58 |
| 7.1. Header Field Registration . . . . . . . . . . . . . . . . 58 |  | 7.1. Header Field Registration . . . . . . . . . . . . . . . . 58 |
| 7.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 58 |  | 7.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 59 |
| 7.3. Internet Media Type Registrations . . . . . . . . . . . . 59 |  | 7.3. Internet Media Type Registrations . . . . . . . . . . . . 59 |
| 7.3.1. Internet Media Type message/http . . . . . . . . . . . 59 |  | 7.3.1. Internet Media Type message/http . . . . . . . . . . . 59 |
| 7.3.2. Internet Media Type application/http . . . . . . . . . 60 |  | 7.3.2. Internet Media Type application/http . . . . . . . . . 60 |
| 7.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 61 |  | 7.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 61 |
| 7.5. Transfer Coding Registrations . . . . . . . . . . . . . . 62 |  | 7.5. Transfer Coding Registrations . . . . . . . . . . . . . . 62 |
| 7.6. Upgrade Token Registry . . . . . . . . . . . . . . . . . . 62 |  | 7.6. Upgrade Token Registry . . . . . . . . . . . . . . . . . . 62 |
| 7.7. Upgrade Token Registration . . . . . . . . . . . . . . . . 63 |  | 7.7. Upgrade Token Registration . . . . . . . . . . . . . . . . 63 |
| 8. Security Considerations . . . . . . . . . . . . . . . . . . . 63 |  | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 63 |
| 8.1. Personal Information . . . . . . . . . . . . . . . . . . . 63 |  | 8.1. Personal Information . . . . . . . . . . . . . . . . . . . 63 |
| 8.2. Abuse of Server Log Information . . . . . . . . . . . . . 63 |  | 8.2. Abuse of Server Log Information . . . . . . . . . . . . . 64 |
| 8.3. Attacks Based On File and Path Names . . . . . . . . . . . 64 |  | 8.3. Attacks Based On File and Path Names . . . . . . . . . . . 64 |
| 8.4. DNS-related Attacks . . . . . . . . . . . . . . . . . . . 64 |  | 8.4. DNS-related Attacks . . . . . . . . . . . . . . . . . . . 65 |
| 8.5. Intermediaries and Caching . . . . . . . . . . . . . . . . 64 |  | 8.5. Intermediaries and Caching . . . . . . . . . . . . . . . . 65 |
| 8.6. Protocol Element Size Overflows . . . . . . . . . . . . . 65 |  | 8.6. Protocol Element Size Overflows . . . . . . . . . . . . . 65 |
| 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 66 |  | 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 66 |
| 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 67 |  | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 67 |
| 10.1. Normative References . . . . . . . . . . . . . . . . . . . 67 |  | 10.1. Normative References . . . . . . . . . . . . . . . . . . . 67 |
| 10.2. Informative References . . . . . . . . . . . . . . . . . . 68 |  | 10.2. Informative References . . . . . . . . . . . . . . . . . . 68 |
| Appendix A. HTTP Version History . . . . . . . . . . . . . . . . 70 |  | Appendix A. HTTP Version History . . . . . . . . . . . . . . . . 71 |
| A.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 71 |  | A.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 71 |
| A.1.1. Multi-homed Web Servers . . . . . . . . . . . . . . . 71 |  | A.1.1. Multi-homed Web Servers . . . . . . . . . . . . . . . 72 |
| A.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 71 |  | A.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 72 |
| A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 72 |  | A.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 73 |
| A.3. Changes from RFC 2817 . . . . . . . . . . . . . . . . . . 73 |  | A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 73 |
| Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 73 |  | Appendix B. ABNF list extension: #rule . . . . . . . . . . . . . 74 |
| Appendix C. Change Log (to be removed by RFC Editor before |  | Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 75 |
| publication) . . . . . . . . . . . . . . . . . . . . 76 |  | Appendix D. Change Log (to be removed by RFC Editor before |
| C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 76 |  | publication) . . . . . . . . . . . . . . . . . . . . 78 |
| C.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 76 |  | D.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 78 |
| C.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 78 |  | D.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 78 |
| C.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 79 |  | D.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 79 |
| C.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 79 |  | D.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 80 |
| C.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 80 |  | D.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 81 |
| C.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 80 |  | D.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 81 |
| C.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 81 |  | D.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 82 |
| C.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 82 |  | D.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 83 |
| C.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 82 |  | D.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 83 |
| C.11. Since draft-ietf-httpbis-p1-messaging-09 . . . . . . . . . 83 |  | D.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 84 |
| C.12. Since draft-ietf-httpbis-p1-messaging-10 . . . . . . . . . 83 |  | D.11. Since draft-ietf-httpbis-p1-messaging-09 . . . . . . . . . 84 |
| C.13. Since draft-ietf-httpbis-p1-messaging-11 . . . . . . . . . 84 |  | D.12. Since draft-ietf-httpbis-p1-messaging-10 . . . . . . . . . 85 |
| C.14. Since draft-ietf-httpbis-p1-messaging-12 . . . . . . . . . 84 |  | D.13. Since draft-ietf-httpbis-p1-messaging-11 . . . . . . . . . 85 |
| C.15. Since draft-ietf-httpbis-p1-messaging-13 . . . . . . . . . 85 |  | D.14. Since draft-ietf-httpbis-p1-messaging-12 . . . . . . . . . 86 |
| C.16. Since draft-ietf-httpbis-p1-messaging-14 . . . . . . . . . 85 |  | D.15. Since draft-ietf-httpbis-p1-messaging-13 . . . . . . . . . 86 |
| C.17. Since draft-ietf-httpbis-p1-messaging-15 . . . . . . . . . 85 |  | D.16. Since draft-ietf-httpbis-p1-messaging-14 . . . . . . . . . 87 |
| C.18. Since draft-ietf-httpbis-p1-messaging-16 . . . . . . . . . 86 |  | D.17. Since draft-ietf-httpbis-p1-messaging-15 . . . . . . . . . 87 |
| C.19. Since draft-ietf-httpbis-p1-messaging-17 . . . . . . . . . 86 |  | D.18. Since draft-ietf-httpbis-p1-messaging-16 . . . . . . . . . 87 |
| C.20. Since draft-ietf-httpbis-p1-messaging-18 . . . . . . . . . 87 |  | D.19. Since draft-ietf-httpbis-p1-messaging-17 . . . . . . . . . 88 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 |  | D.20. Since draft-ietf-httpbis-p1-messaging-18 . . . . . . . . . 88 |
|  |  | D.21. Since draft-ietf-httpbis-p1-messaging-19 . . . . . . . . . 89 |
|  |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 |
| 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 MIME- |
| like message payloads for flexible interaction with network-based |  | like message payloads for flexible interaction with network-based |
| hypertext information systems. HTTP relies upon the Uniform Resource |  | hypertext information systems. This document is the first in a |
| Identifier (URI) standard [RFC3986] to indicate the target resource |  | series of documents that collectively form the HTTP/1.1 |
| (Section 5.1) and relationships between resources. Messages are |  | specification: |
| passed in a format similar to that used by Internet mail [RFC5322] |  |  |
| and the Multipurpose Internet Mail Extensions (MIME) [RFC2045] (see |  | RFC xxx1: Message Routing and Syntax |
| Appendix A of [Part3] for the differences between HTTP and MIME |  |  |
| messages). |  | RFC xxx2: Semantics and Payloads |
|  |  | RFC xxx3: Conditional Requests |
|  |  | RFC xxx4: Range Requests |
|  |  | RFC xxx5: Caching |
|  |  | RFC xxx6: Authentication |
|  |  | This HTTP/1.1 specification obsoletes and moves to historic status |
|  |  | RFC 2616, its predecessor RFC 2068, RFC 2145 (on HTTP versioning), |
|  |  | and RFC 2817 (on using CONNECT for TLS upgrades). |
| 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. |
| skipping to change at page 6, line 45 |  | skipping to change at page 7, line 8 |
| One consequence of HTTP flexibility is that the protocol cannot be |  | One consequence of HTTP 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 is Part 1 of the seven-part specification of HTTP, |  | This document describes the architectural elements that are used or |
| defining the protocol referred to as "HTTP/1.1", obsoleting [RFC2616] |  | referred to in HTTP, defines the "http" and "https" URI schemes, |
| and [RFC2145]. Part 1 describes the architectural elements that are |  | describes overall network operation and connection management, and |
| used or referred to in HTTP, defines the "http" and "https" URI |  | defines HTTP message framing and forwarding requirements. Our goal |
| schemes, describes overall network operation and connection |  | is to define all of the mechanisms necessary for HTTP message |
| management, and defines HTTP message framing and forwarding |  | handling that are independent of message semantics, thereby defining |
| requirements. Our goal is to define all of the mechanisms necessary |  | the complete set of requirements for message parsers and message- |
| for HTTP message handling that are independent of message semantics, |  | forwarding intermediaries. |
| thereby defining the complete set of requirements for message parsers |  |  |
| and message-forwarding intermediaries. |  |  |
| 1.1. Requirement Notation |  | 1.1. Requirement Notation |
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |  | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |  | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |
| document are to be interpreted as described in [RFC2119]. |  | document are to be interpreted as described in [RFC2119]. |
| 1.2. Syntax Notation |  | 1.2. Syntax Notation |
| This specification uses the Augmented Backus-Naur Form (ABNF) |  | This specification uses the Augmented Backus-Naur Form (ABNF) |
| notation of [RFC5234] with the list rule extension defined in |  | notation of [RFC5234] with the list rule extension defined in |
| Section 3.2.5. Appendix B shows the collected ABNF with the list |  | Appendix B. Appendix C shows the collected ABNF with the list rule |
| rule expanded. |  | expanded. |
| The following core rules are included by reference, as defined in |  | The following core rules are included by reference, as defined in |
| [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF |  | [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF |
| (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), |  | (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), |
| HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line |  | HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line |
| feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any |  | feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any |
| visible [USASCII] character). |  | visible [USASCII] character). |
| As a convention, ABNF rule names prefixed with "obs-" denote |  | As a convention, ABNF rule names prefixed with "obs-" denote |
| "obsolete" grammar rules that appear for historical reasons. |  | "obsolete" grammar rules that appear for historical reasons. |
| skipping to change at page 7, line 47 |  | skipping to change at page 8, line 9 |
| 2.1. Client/Server Messaging |  | 2.1. Client/Server Messaging |
| HTTP is a stateless request/response protocol that operates by |  | HTTP is a stateless request/response protocol that operates by |
| exchanging messages (Section 3) across a reliable transport or |  | exchanging messages (Section 3) across a reliable transport or |
| session-layer "connection". An HTTP "client" is a program that |  | session-layer "connection". An HTTP "client" is a program that |
| establishes a connection to a server for the purpose of sending one |  | establishes a connection to a server for the purpose of sending one |
| or more HTTP requests. An HTTP "server" is a program that accepts |  | or more HTTP requests. An HTTP "server" is a program that accepts |
| connections in order to service HTTP requests by sending HTTP |  | connections in order to service HTTP requests by sending HTTP |
| responses. |  | responses. |
| Note that the terms client and server refer only to the roles that |  | The terms client and server refer only to the roles that these |
| these programs perform for a particular connection. The same program |  | programs perform for a particular connection. The same program might |
| might act as a client on some connections and a server on others. We |  | act as a client on some connections and a server on others. We use |
| use the term "user agent" to refer to the program that initiates a |  | the term "user agent" to refer to the program that initiates a |
| request, such as a WWW browser, editor, or spider (web-traversing |  | request, such as a WWW browser, editor, or spider (web-traversing |
| robot), and the term "origin server" to refer to the program that can |  | robot), and the term "origin server" to refer to the program that can |
| originate authoritative responses to a request. For general |  | originate authoritative responses to a request. For general |
| requirements, we use the term "sender" to refer to whichever |  | requirements, we use the term "sender" to refer to whichever |
| component sent a given message and the term "recipient" to refer to |  | component sent a given message and the term "recipient" to refer to |
| any component that receives the message. |  | any component that receives the message. |
| Note: The term 'user agent' covers both those situations where |  | HTTP relies upon the Uniform Resource Identifier (URI) standard |
| there is a user (human) interacting with the software agent (and |  | [RFC3986] to indicate the target resource (Section 5.1) and |
| for which user interface or interactive suggestions might be made, |  | relationships between resources. Messages are passed in a format |
| e.g., warning the user or given the user an option in the case of |  | similar to that used by Internet mail [RFC5322] and the Multipurpose |
| security or privacy options) and also those where the software |  | Internet Mail Extensions (MIME) [RFC2045] (see Appendix A of [Part2] |
| agent may act autonomously. |  | 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 |
| case, this might be accomplished via a single bidirectional |  | case, this might be accomplished via a single bidirectional |
| connection (===) between the user agent (UA) and the origin server |  | connection (===) between the user agent (UA) and the origin server |
| (O). |  | (O). |
| request > |  | request > |
| UA ======================================= O |  | UA ======================================= O |
| < response |  | < response |
| A client sends an HTTP request to the server in the form of a request |  | A client sends an HTTP request to a server in the form of a request |
| message, beginning with a request-line that includes a method, URI, |  | message, beginning with a request-line that includes a method, URI, |
| and protocol version (Section 3.1.1), followed by MIME-like header |  | and protocol version (Section 3.1.1), followed by header fields |
| fields containing request modifiers, client information, and |  | containing request modifiers, client information, and representation |
| representation metadata (Section 3.2), an empty line to indicate the |  |  |
| end of the header section, and finally a message body containing the |  |  |
| payload body (if any, Section 3.3). |  |  |
| A server responds to the client's request by sending one or more HTTP |  |  |
| response messages, each beginning with a status line that includes |  |  |
| the protocol version, a success or error code, and textual reason |  |  |
| phrase (Section 3.1.2), possibly followed by MIME-like header fields |  |  |
| containing server information, resource metadata, and representation |  |  |
| metadata (Section 3.2), an empty line to indicate the end of the |  | metadata (Section 3.2), an empty line to indicate the end of the |
| header section, and finally a message body containing the payload |  | header section, and finally a message body containing the payload |
| body (if any, Section 3.3). |  | body (if any, Section 3.3). |
|  |  | A server responds to a client's request by sending one or more HTTP |
|  |  | response messages, each beginning with a status line that includes |
|  |  | the protocol version, a success or error code, and textual reason |
|  |  | phrase (Section 3.1.2), possibly followed by header fields containing |
|  |  | server information, resource metadata, and representation metadata |
|  |  | (Section 3.2), an empty line to indicate the end of the header |
|  |  | section, and finally a message body containing the payload body (if |
|  |  | any, Section 3.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: */* |  | Accept-Language: en, mi |
| server response: |  | server response: |
| HTTP/1.1 200 OK |  | HTTP/1.1 200 OK |
| Date: Mon, 27 Jul 2009 12:28:53 GMT |  | Date: Mon, 27 Jul 2009 12:28:53 GMT |
| 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! |
| 2.2. Connections and Transport Independence |  | 2.2. Implementation Diversity |
|  |  | 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 |
|  |  | origin servers are large public websites. That is not the case in |
|  |  | practice. Common HTTP user agents include household appliances, |
|  |  | stereos, scales, software/firmware updaters, command-line programs, |
|  |  | mobile apps, and communication devices in a multitude of shapes and |
|  |  | sizes. Likewise, common HTTP origin servers include home automation |
|  |  | units, configurable networking components, office machines, |
|  |  | autonomous robots, news feeds, traffic cameras, ad selectors, and |
|  |  | video delivery platforms. |
|  |  | The term "user agent" does not imply that there is a human user |
|  |  | directly interacting with the software agent at the time of a |
|  |  | request. In many cases, a user agent is installed or configured to |
|  |  | run in the background and save its results for later inspection (or |
|  |  | save only a subset of those results that might be interesting or |
|  |  | erroneous). Spiders, for example, are typically given a start URI |
|  |  | and configured to follow certain behavior while crawling the Web as a |
|  |  | hypertext graph. |
|  |  | The implementation diversity of HTTP means that we cannot assume the |
|  |  | user agent can make interactive suggestions to a user or provide |
|  |  | adequate warning for security or privacy options. In the few cases |
|  |  | where this specification requires reporting of errors to the user, it |
|  |  | is acceptable for such reporting to only be visible in an error |
|  |  | console or log file. Likewise, requirements that an automated action |
|  |  | be confirmed by the user before proceeding can me met via advance |
|  |  | configuration choices, run-time options, or simply not proceeding |
|  |  | with the unsafe action. |
|  |  | 2.3. Connections and Transport Independence |
| 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 the underlying transport |  | response structures onto the data units of the underlying transport |
| protocol is outside the scope of this specification. |  | protocol is outside the scope of this specification. |
| The specific connection protocols to be used for an interaction are |  | The specific connection protocols to be used for an interaction are |
| determined by client configuration and the target URI (Section 5.1). |  | determined by client configuration and the target URI (Section 5.1). |
| For example, the "http" URI scheme (Section 2.7.1) indicates a |  | For example, the "http" URI scheme (Section 2.8.1) indicates a |
| default connection of TCP over IP, with a default TCP port of 80, but |  | default connection of TCP over IP, with a default TCP port of 80, but |
| the client might be configured to use a proxy via some other |  | the client might be configured to use a proxy via some other |
| connection port or protocol instead of using the defaults. |  | connection port or protocol instead of using the defaults. |
| A connection might be used for multiple HTTP request/response |  | A connection might be used for multiple HTTP request/response |
| exchanges, as defined in Section 6.3. |  | exchanges, as defined in Section 6.3. |
| 2.3. Intermediaries |  | 2.4. 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. |
| > > > > |  | > > > > |
| UA =========== A =========== B =========== C =========== O |  | UA =========== A =========== B =========== C =========== O |
| < < < < |  | < < < < |
| skipping to change at page 10, line 52 |  | skipping to change at page 11, line 40 |
| 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.2.4 of [Part2] and Section 3.6 of [Part6] |  | semantics. See Section 4.4.4 of [Part2] and Section 7.6 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. |
| skipping to change at page 11, line 35 |  | skipping to change at page 12, line 24 |
| 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 is used to establish private communication |  | transport-layer security is used to establish private communication |
| through a shared firewall proxy. |  | through a shared firewall proxy. |
| In addition, there may exist network intermediaries that are not |  | The above categories for intermediary only consider those acting as |
| considered part of the HTTP communication but nevertheless act as |  | participants in the HTTP communication. There are also |
| filters or redirecting agents (usually violating HTTP semantics, |  | intermediaries that can act on lower layers of the network protocol |
| causing security problems, and otherwise making a mess of things). |  | stack, filtering or redirecting HTTP traffic without the knowledge or |
| Such a network intermediary, often referred to as an "interception |  | permission of message senders. Network intermediaries often |
| proxy" [RFC3040], "transparent proxy" [RFC1919], or "captive portal", |  | introduce security flaws or interoperability problems by violating |
| differs from an HTTP proxy because it has not been selected by the |  | HTTP semantics. For example, an "interception proxy" [RFC3040] (also |
| client. Instead, the network intermediary redirects outgoing TCP |  | commonly known as a "transparent proxy" [RFC1919] or "captive |
| port 80 packets (and occasionally other common port traffic) to an |  | portal") differs from an HTTP proxy because it is not selected by the |
| internal HTTP server. Interception proxies are commonly found on |  | client. Instead, an interception proxy filters or redirects outgoing |
| public network access points, as a means of enforcing account |  | TCP port 80 packets (and occasionally other common port traffic). |
| subscription prior to allowing use of non-local Internet services, |  | Interception proxies are commonly found on public network access |
| and within corporate firewalls to enforce network usage policies. |  | points, as a means of enforcing account subscription prior to |
| They are indistinguishable from a man-in-the-middle attack. |  | allowing use of non-local Internet services, and within corporate |
|  |  | firewalls to enforce network usage policies. They are |
|  |  | 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.5. 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 |
| skipping to change at page 12, line 46 |  | skipping to change at page 13, line 39 |
| 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 and proxies deployed across the World Wide Web and inside |
| large organizations. These systems include national hierarchies of |  | large organizations. These systems include national hierarchies of |
| proxy caches to save transoceanic bandwidth, systems that broadcast |  | proxy caches to save transoceanic bandwidth, systems that broadcast |
| or multicast cache entries, organizations that distribute subsets of |  | or multicast cache entries, organizations that distribute subsets of |
| cached data via optical media, and so on. |  | cached data via optical media, and so on. |
| 2.5. Conformance and Error Handling |  | 2.6. 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. |
|  |  | The verb "generate" is used instead of "send" where a requirement |
|  |  | differentiates between creating a protocol element and merely |
|  |  | forwarding a received element downstream. |
| An implementation is considered conformant if it complies with all of |  | An implementation is considered conformant if it complies with all of |
| the requirements associated with the roles it partakes in HTTP. |  | the requirements associated with the roles it partakes in HTTP. Note |
|  |  | that SHOULD-level requirements are relevant here, unless one of the |
|  |  | documented exceptions is applicable. |
| Senders MUST NOT generate protocol elements that do not match the |  | In addition to the prose requirements placed upon them, senders MUST |
| grammar defined by the ABNF rules for those protocol elements. |  | NOT generate protocol elements that do not match the grammar defined |
|  |  | by the ABNF rules for those protocol elements that are applicable to |
|  |  | the sender's role. If a received protocol element is processed, the |
|  |  | recipient MUST be able to parse any value that would match the ABNF |
|  |  | rules for that protocol element, excluding only those rules not |
|  |  | applicable to the recipient's role. |
| Unless otherwise noted, recipients MAY attempt to recover a usable |  | Unless noted otherwise, a recipient MAY attempt to recover a usable |
| protocol element from an invalid construct. HTTP does not define |  | protocol element from an invalid construct. HTTP does not define |
| specific error handling mechanisms except when they have a direct |  | specific error handling mechanisms except when they have a direct |
| impact on security, since different applications of the protocol |  | impact on security, since different applications of the protocol |
| require different error handling strategies. For example, a Web |  | require different error handling strategies. For example, a Web |
| browser might wish to transparently recover from a response where the |  | browser might wish to transparently recover from a response where the |
| Location header field doesn't parse according to the ABNF, whereas a |  | Location header field doesn't parse according to the ABNF, whereas a |
| systems control client might consider any form of error recovery to |  | systems control client might consider any form of error recovery to |
| be dangerous. |  | be dangerous. |
| 2.6. Protocol Versioning |  | 2.7. Protocol Versioning |
| HTTP uses a "<major>.<minor>" numbering scheme to indicate versions |  | HTTP uses a "<major>.<minor>" numbering scheme to indicate versions |
| of the protocol. This specification defines version "1.1". The |  | of the protocol. This specification defines version "1.1". The |
| protocol version as a whole indicates the sender's conformance with |  | protocol version as a whole indicates the sender's conformance with |
| the set of requirements laid out in that version's corresponding |  | the set of requirements laid out in that version's corresponding |
| specification of HTTP. |  | specification of HTTP. |
| The version of an HTTP message is indicated by an HTTP-version field |  | The version of an HTTP message is indicated by an HTTP-version field |
| in the first line of the message. HTTP-version is case-sensitive. |  | in the first line of the message. HTTP-version is case-sensitive. |
| skipping to change at page 14, line 23 |  | skipping to change at page 15, line 26 |
| header fields ought to be implemented by all HTTP/1.x implementations |  | header fields ought to be implemented by all HTTP/1.x implementations |
| whether or not they advertise conformance with HTTP/1.1. |  | whether or not they advertise conformance with HTTP/1.1. |
| New header fields can be defined such that, when they are understood |  | New header fields can be defined such that, when they are understood |
| by a recipient, they might override or enhance the interpretation of |  | by a recipient, they might override or enhance the interpretation of |
| previously defined header fields. When an implementation receives an |  | previously defined header fields. When an implementation receives an |
| unrecognized header field, the recipient MUST ignore that header |  | unrecognized header field, the recipient MUST ignore that header |
| field for local processing regardless of the message's HTTP version. |  | field for local processing regardless of the message's HTTP version. |
| An unrecognized header field received by a proxy MUST be forwarded |  | An unrecognized header field received by a proxy MUST be forwarded |
| downstream unless the header field's field-name is listed in the |  | downstream unless the header field's field-name is listed in the |
| message's Connection header-field (see Section 6.1). These |  | message's Connection header field (see Section 6.1). These |
| requirements allow HTTP's functionality to be enhanced without |  | requirements allow HTTP's functionality to be enhanced without |
| requiring prior update of deployed intermediaries. |  | requiring prior update of deployed intermediaries. |
| Intermediaries that process HTTP messages (i.e., all intermediaries |  | Intermediaries that process HTTP messages (i.e., all intermediaries |
| other than those acting as tunnels) MUST send their own HTTP-version |  | other than those acting as tunnels) MUST send their own HTTP-version |
| in forwarded messages. In other words, they MUST NOT blindly forward |  | in forwarded messages. In other words, they MUST NOT blindly forward |
| the first line of an HTTP message without ensuring that the protocol |  | the first line of an HTTP message without ensuring that the protocol |
| version in that message matches a version to which that intermediary |  | version in that message matches a version to which that intermediary |
| is conformant for both the receiving and sending of messages. |  | is conformant for both the receiving and sending of messages. |
| Forwarding an HTTP message without rewriting the HTTP-version might |  | Forwarding an HTTP message without rewriting the HTTP-version might |
| skipping to change at page 15, line 30 |  | skipping to change at page 16, line 33 |
| 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 is |
| specifically avoiding any such changes to the protocol. |  | specifically avoiding any such changes to the protocol. |
| 2.7. Uniform Resource Identifiers |  | 2.8. 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. URI references are used |  | HTTP as the means for identifying resources. URI references are used |
| to target requests, indicate redirects, and define relationships. |  | to target requests, indicate redirects, and define relationships. |
| HTTP does not limit what a resource might be; it merely defines an |  | HTTP does not limit what a resource might be; it merely defines an |
| interface that can be used to interact with a resource via HTTP. |  | interface that can be used to interact with a resource via HTTP. |
| More information on the scope of URIs and resources can be found in |  | More information on the scope of URIs and resources can be found in |
| [RFC3986]. |  | [RFC3986]. |
| This specification adopts the definitions of "URI-reference", |  | This specification adopts the definitions of "URI-reference", |
| skipping to change at page 16, line 24 |  | skipping to change at page 17, line 24 |
| 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.8.1. http URI scheme |
| The "http" URI scheme is hereby defined for the purpose of minting |  | The "http" 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 for |  | namespace governed by a potential HTTP origin server listening for |
| TCP connections on a given port. |  | TCP connections on a given port. |
| 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 |
| skipping to change at page 17, line 45 |  | skipping to change at page 18, line 45 |
| 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 NOT |
| include a userinfo subcomponent (and its "@" delimiter) when |  | include a userinfo subcomponent (and its "@" delimiter) when |
| transmitting an "http" URI in a message. Recipients of HTTP messages |  | transmitting an "http" URI in a message. Recipients of HTTP messages |
| that contain a URI reference SHOULD parse for the existence of |  | that contain a URI reference SHOULD parse for the existence of |
| userinfo and treat its presence as an error, likely indicating that |  | userinfo and treat its presence as an error, likely indicating that |
| the deprecated subcomponent is being used to obscure the authority |  | the deprecated subcomponent is being used to obscure the authority |
| for the sake of phishing attacks. |  | for the sake of phishing attacks. |
| 2.7.2. https URI scheme |  | 2.8.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 for |  | namespace governed by a potential HTTP origin server listening for |
| SSL/TLS-secured connections on a given TCP port. |  | SSL/TLS-secured connections on a given TCP port. |
| 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 for privacy through the use of |  | the TCP connection MUST be secured for privacy 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 |  | Unlike the "http" scheme, responses to "https" identified requests |
| are never "public" and thus MUST NOT be reused for shared caching. |  | 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 |  | 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 |  | cacheable by default in HTTP or specifically indicated as such by the |
| Cache-Control header field (Section 3.2 of [Part6]). |  | 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. |
| The process for authoritative access to an "https" identified |  | The process for authoritative access to an "https" identified |
| resource is defined in [RFC2818]. |  | resource is defined in [RFC2818]. |
| 2.7.3. http and https URI Normalization and Comparison |  | 2.8.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. Likewise, an empty path |
| component is equivalent to an absolute path of "/", so the normal |  | component is equivalent to an absolute path of "/", so the normal |
| form is to provide a path of "/" instead. The scheme and host are |  | form is to provide a path of "/" instead. The scheme and host are |
| skipping to change at page 20, line 27 |  | skipping to change at page 21, line 27 |
| some clients or cause others to cease parsing. |  | some clients or cause others to cease parsing. |
| 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 2 |  | The methods defined by this specification can be found in Section 2 |
| 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 |
| skipping to change at page 21, line 7 |  | skipping to change at page 22, line 10 |
| directly instead of properly percent-encoding the disallowed |  | directly instead of properly percent-encoding 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 404 (Not Allowed), if it is |  | implements SHOULD respond with either a 405 (Method Not Allowed), if |
| an origin server, or a 501 (Not Implemented) status code. A server |  | it is an origin server, or a 501 (Not Implemented) status code. A |
| MUST be prepared to receive URIs of unbounded length and respond with |  | server MUST be prepared to receive URIs of unbounded length and |
| the 414 (URI Too Long) status code if the received request-target |  | respond with the 414 (URI Too Long) status code if the received |
| would be longer than the server wishes to handle (see Section 7.4.12 |  | request-target would be longer than the server wishes to handle (see |
| of [Part2]). |  | Section 4.6.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 up to 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 |
| The status-code element is a 3-digit integer result code of the |  | A client MUST be able to parse any received message that begins with |
| attempt to understand and satisfy the request. See Section 4 of |  | a status-line and matches the ABNF rule for HTTP-message. |
| [Part2] for further information, such as the list of status codes |  |  |
| defined by this specification, the IANA registry, and considerations |  | The status-code element is a 3-digit integer code describing the |
| for new status codes. |  | result of the server's attempt to understand and satisfy the client's |
|  |  | corresponding request. The rest of the response message is to be |
|  |  | interpreted in light of the semantics defined for that status code. |
|  |  | See Section 4 of [Part2] for information about the semantics of |
|  |  | status codes, including the classes of status code (indicated by the |
|  |  | first digit), the status codes defined by this specification, |
|  |  | considerations for the definition of new status codes, and the IANA |
|  |  | 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 |
| more frequently used with interactive text clients. A client SHOULD |  | more frequently used with interactive text clients. A client SHOULD |
| ignore the reason-phrase content. |  | ignore the reason-phrase content. |
| reason-phrase = *( HTAB / SP / VCHAR / obs-text ) |  | reason-phrase = *( HTAB / SP / VCHAR / obs-text ) |
| skipping to change at page 22, line 15 |  | skipping to change at page 23, line 20 |
| 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.2 |
| 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 10.2 of [Part2] as containing the |  | header field is defined in Section 9.10 of [Part2] as containing the |
| origination timestamp for the message in which it appears. |  | origination timestamp for the message in which it appears. |
| 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, or on the number of header fields used in a given message. |
| Existing fields are defined in each part of this specification and in |  | Existing fields are defined in each part of this specification and in |
| many other specifications outside the standards process. New header |  | many other specifications outside the standards process. New header |
| fields can be introduced without changing the protocol version if |  | fields can be introduced without changing the protocol version if |
| their defined semantics allow them to be safely ignored by recipients |  | their defined semantics allow them to be safely ignored by recipients |
| that do not recognize them. |  | that do not recognize them. |
| skipping to change at page 24, line 40 |  | skipping to change at page 25, line 48 |
| header field values use only a subset of the US-ASCII character |  | header field values use only a subset of the US-ASCII character |
| encoding [USASCII]. Newly defined header fields SHOULD limit their |  | encoding [USASCII]. Newly defined header fields SHOULD limit their |
| field values to US-ASCII octets. Recipients SHOULD treat other (obs- |  | field values to US-ASCII octets. Recipients SHOULD treat other (obs- |
| text) octets in field content as opaque data. |  | text) octets in field content as opaque data. |
| 3.2.3. Field Length |  | 3.2.3. Field Length |
| 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 header |
| fields, either in isolation or as a set. A server MUST be prepared |  | fields, either in isolation or as a set. A server MUST be prepared |
| to receive request header fields of unbounded length and respond with |  | to receive request header fields of unbounded length and respond with |
| a 4xx status code if the received header field(s) would be longer |  | a 4xx (Client Error) status code if the received header field(s) |
| than the server wishes to handle. |  | would be longer than the server wishes to handle. |
| A client that receives response headers that are longer than it |  | A client that receives response header fields that are longer than it |
| wishes to handle can only treat it as a server error. |  | wishes to handle can only treat it as a server error. |
| Various ad-hoc limitations on header length are found in practice. |  | Various ad-hoc limitations on header field length are found in |
| It is RECOMMENDED that all HTTP senders and recipients support |  | practice. It is RECOMMENDED that all HTTP senders and recipients |
| messages whose combined header fields have 4000 or more octets. |  | support messages whose combined header fields have 4000 or more |
|  |  | octets. |
| 3.2.4. Field value components |  | 3.2.4. Field value components |
| Many HTTP/1.1 header field values consist of words (token or quoted- |  | Many HTTP/1.1 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 |
| skipping to change at page 26, line 11 |  | skipping to change at page 27, line 17 |
| 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 ")"). |
| 3.2.5. ABNF list extension: #rule |  |  |
| A #rule extension to the ABNF rules of [RFC5234] is used to improve |  |  |
| readability in the definitions of some header field values. |  |  |
| A construct "#" is defined, similar to "*", for defining comma- |  |  |
| delimited lists of elements. The full form is "<n>#<m>element" |  |  |
| indicating at least <n> and at most <m> elements, each separated by a |  |  |
| single comma (",") and optional whitespace (OWS). |  |  |
| Thus, |  |  |
| 1#element => element *( OWS "," OWS element ) |  |  |
| and: |  |  |
| #element => [ 1#element ] |  |  |
| and for n >= 1 and m > 1: |  |  |
| <n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element ) |  |  |
| For compatibility with legacy list rules, recipients SHOULD accept |  |  |
| empty list elements. In other words, consumers would follow the list |  |  |
| productions: |  |  |
| #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ] |  |  |
| 1#element => *( "," OWS ) element *( OWS "," [ OWS element ] ) |  |  |
| Note that empty elements do not contribute to the count of elements |  |  |
| present, though. |  |  |
| For example, given these ABNF productions: |  |  |
| example-list = 1#example-list-elmt |  |  |
| example-list-elmt = token ; see Section 3.2.4 |  |  |
| Then these are valid values for example-list (not including the |  |  |
| double quotes, which are present for delimitation only): |  |  |
| "foo,bar" |  |  |
| "foo ,bar," |  |  |
| "foo , ,bar,charlie " |  |  |
| But these values would be invalid, as at least one non-empty element |  |  |
| is required: |  |  |
| "" |  |  |
| "," |  |  |
| ", ," |  |  |
| Appendix B shows the collected ABNF, with the list rules expanded as |  |  |
| explained above. |  |  |
| 3.3. Message Body |  | 3.3. Message Body |
| 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 a |
| Content-Length or Transfer-Encoding header field. Request message |  | Content-Length or Transfer-Encoding header field. Request message |
| framing is independent of method semantics, even if the method does |  | framing is independent of method semantics, even if the method does |
| not define any use for a message body. |  | not define 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 |
| (Paragraph 2). Responses to the HEAD request method never include a |  | (Section 3.1.2). Responses to the HEAD request method never include |
| 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.) only indicate what their |  | Transfer-Encoding, Content-Length, etc.) only indicate what their |
| values would have been if the request method had been GET. |  | values would have been if the request method had been GET. 2xx |
| Successful (2xx) responses to CONNECT switch to tunnel mode instead |  | (Successful) responses to CONNECT switch to tunnel mode instead of |
| of having a message body. All 1xx (Informational), 204 (No Content), |  | having a message body. All 1xx (Informational), 204 (No Content), |
| and 304 (Not Modified) responses MUST NOT include a message body. |  | and 304 (Not Modified) responses MUST NOT include a message body. |
| All other responses do include a message body, although the body MAY |  | All other responses do include a message body, although the body MAY |
| be of zero length. |  | be of 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 |  | When one or more transfer codings are applied to a payload body in |
| order to form the message body, a Transfer-Encoding header field MUST |  | order to form the message body, a Transfer-Encoding header field MUST |
| be sent in the message and MUST contain the list of corresponding |  | be sent in the message and MUST contain the list of corresponding |
| transfer-coding names in the same order that they were applied. |  | transfer-coding names in the same order that they were applied. |
| skipping to change at page 28, line 42 |  | skipping to change at page 28, line 40 |
| 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 |  | If more than one Transfer-Encoding header field is present in a |
| message, the multiple field-values MUST be combined into one field- |  | message, the multiple field-values MUST be combined into one field- |
| value, according to the algorithm defined in Section 3.2, before |  | value, according to the algorithm defined in Section 3.2, before |
| determining the message body length. |  | determining the message body length. |
| Unlike Content-Encoding (Section 2.2 of [Part3]), Transfer-Encoding |  | Unlike Content-Encoding (Section 5.4 of [Part2]), Transfer-Encoding |
| is a property of the message, not of the payload, and thus MAY be |  | is a property of the message, not of the payload, and thus MAY be |
| added or removed by any implementation along the request/response |  | added or removed by any implementation along the request/response |
| chain. Additional information about the encoding parameters MAY be |  | chain. Additional information about the encoding parameters MAY be |
| provided by other header fields not defined by this specification. |  | provided by other header fields not defined by this specification. |
| 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 response to a GET request, neither of which includes a message |  | 304 (Not Modified) response (Section 4.1 of [Part4]) to a GET |
| body, to indicate that the origin server would have applied a |  | request, neither of which includes a message body, to indicate that |
| transfer coding to the message body if the request had been an |  | the origin server would have applied a transfer coding to the message |
| unconditional GET. This indication is not required, however, because |  | body if the request had been an unconditional GET. This indication |
| any recipient on the response chain (including the origin server) can |  | is not required, however, because any recipient on the response chain |
| remove transfer codings when they are not needed. |  | (including the origin server) can remove transfer codings when they |
|  |  | 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). |
| skipping to change at page 29, line 28 |  | skipping to change at page 29, line 26 |
| 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) and |
| then close the connection. |  | then close the connection. |
| 3.3.2. Content-Length |  | 3.3.2. Content-Length |
| When a message does not have a Transfer-Encoding header field and the |  | When a message does not have a Transfer-Encoding header field and the |
| payload body length can be determined prior to being transferred, a |  | payload body length can be determined prior to being transferred, a |
| Content-Length header field SHOULD be sent to indicate the length of |  | Content-Length header field SHOULD be sent to indicate the length of |
| the payload body that is either present as the message body, for |  | the payload body that is either present as the message body, for |
| requests and non-HEAD responses other than 304, or would have been |  | requests and non-HEAD responses other than 304 (Not Modified), or |
| present had the request been an unconditional GET. The length is |  | would have been present had the request been an unconditional GET. |
| expressed as a decimal number of octets. |  | The length is expressed as a decimal number of octets. |
| Content-Length = 1*DIGIT |  | Content-Length = 1*DIGIT |
| An example is |  | An example is |
| Content-Length: 3495 |  | Content-Length: 3495 |
| In the case of a response to a HEAD request, Content-Length indicates |  | In the case of a response to a HEAD request, Content-Length indicates |
| the size of the payload body (without any potential transfer-coding) |  | the size of the payload body (without any potential transfer-coding) |
| that would have been sent had the request been a GET. In the case of |  | that would have been sent had the request been a GET. In the case of |
| a 304 (Not Modified) response to a GET request, Content-Length |  | a 304 (Not Modified) response (Section 4.1 of [Part4]) to a GET |
| indicates the size of the payload body (without any potential |  | request, Content-Length indicates the size of the payload body |
| transfer-coding) that would have been sent in a 200 (OK) response. |  | (without any potential transfer-coding) that would have been sent in |
|  |  | a 200 (OK) response. |
| HTTP's use of Content-Length is significantly different from how it |  |  |
| is used in MIME, where it is an optional field used only within the |  |  |
| "message/external-body" media-type. |  |  |
| 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 an HTTP |
| 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.6). |
| If a message is received that has multiple Content-Length header |  | If a message is received that has multiple Content-Length header |
| fields (Section 3.3.2) with field-values consisting of the same |  | fields with field-values consisting of the same decimal value, or a |
| decimal value, or a single Content-Length header field with a field |  | single Content-Length header field with a field value containing a |
| value containing a list of identical decimal values (e.g., "Content- |  | list of identical decimal values (e.g., "Content-Length: 42, 42"), |
| Length: 42, 42"), indicating that duplicate Content-Length header |  | indicating that duplicate Content-Length header fields have been |
| fields have been generated or combined by an upstream message |  | generated or combined by an upstream message processor, then the |
| processor, then the recipient MUST either reject the message as |  | recipient MUST either reject the message as invalid or replace the |
| invalid or replace the duplicated field-values with a single valid |  | duplicated field-values with a single valid Content-Length field |
| Content-Length field containing that decimal value prior to |  | containing that decimal value prior to determining the message body |
| determining the message body length. |  | length. |
|  |  | Note: HTTP's use of Content-Length for message framing differs |
|  |  | significantly from the same field's use in MIME, where it is an |
|  |  | optional field used only within the "message/external-body" media- |
|  |  | type. |
| 3.3.3. Message Body Length |  | 3.3.3. Message Body Length |
| The length of a message body is determined by one of the following |  | The length of a message body is determined by one of the following |
| (in order of precedence): |  | (in order of precedence): |
| 1. Any response to a HEAD request and any response with a status |  | 1. Any response to a HEAD request and any response with a 1xx |
| code of 100-199, 204, or 304 is always terminated by the first |  | (Informational), 204 (No Content), or 304 (Not Modified) status |
| empty line after the header fields, regardless of the header |  | code is always terminated by the first empty line after the |
| fields present in the message, and thus cannot contain a message |  | header fields, regardless of the header fields present in the |
| body. |  | message, and thus cannot contain a message body. |
| 2. Any successful (2xx) 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 header |  | If a message is received with both a Transfer-Encoding and a |
| field and a Content-Length header field, the Transfer-Encoding |  | Content-Length header field, the Transfer-Encoding overrides the |
| overrides the Content-Length. Such a message might indicate an |  | Content-Length. Such a message might indicate an attempt to |
| attempt to perform request or response smuggling (bypass of |  | perform request or response smuggling (bypass of security-related |
| security-related checks on message routing or content) and thus |  | checks on message routing or content) and thus ought to be |
| ought to be handled as an error. The provided Content-Length |  | handled as an error. The provided Content-Length MUST be |
| MUST be removed, prior to forwarding the message downstream, or |  | removed, prior to forwarding the message downstream, or replaced |
| replaced with the real message body length after the transfer- |  | with the real message body length after the transfer-coding is |
| coding is decoded. |  | 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 |
| skipping to change at page 32, line 29 |  | skipping to change at page 32, line 29 |
| A client that sends a request containing a message body MUST include |  | A client that sends a request containing a message body MUST include |
| 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. |
| 3.4. Handling Incomplete Messages |  | 3.4. Handling Incomplete Messages |
| Request messages that are prematurely terminated, possibly due to a |  | Request messages that are prematurely terminated, possibly due to a |
| cancelled connection or a server-imposed time-out exception, MUST |  | canceled connection or a server-imposed time-out exception, MUST |
| result in closure of the connection; sending an HTTP/1.1 error |  | result in closure of the connection; sending an HTTP/1.1 error |
| response prior to closing the connection is OPTIONAL. |  | response prior to closing the connection is OPTIONAL. |
| Response messages that are prematurely terminated, usually by closure |  | Response messages that are prematurely terminated, usually by closure |
| of the connection prior to receiving the expected number of octets or |  | of the connection prior to receiving the expected number of octets or |
| by failure to decode a transfer-encoded message body, MUST be |  | by failure to decode a transfer-encoded message body, MUST be |
| recorded as incomplete. A response that terminates in the middle of |  | recorded as incomplete. A response that terminates in the middle of |
| the header block (before the empty line is received) cannot be |  | the header block (before the empty line is received) cannot be |
| assumed to convey the full semantics of the response and MUST be |  | assumed to convey the full semantics of the response and MUST be |
| treated as an error. |  | treated as an error. |
| skipping to change at page 33, line 4 |  | skipping to change at page 33, line 4 |
| if the zero-sized chunk that terminates the encoding has not been |  | 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 encoding 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 |  | A user agent MUST NOT render an incomplete response message body as |
| if it were complete (i.e., some indication must be given to the user |  | if it were complete (i.e., some indication needs to be given to the |
| that an error occurred). Cache requirements for incomplete responses |  | user that an error occurred). Cache requirements for incomplete |
| are defined in Section 2.1 of [Part6]. |  | responses are defined in Section 3 of [Part6]. |
| A server MUST read the entire request message body or close the |  | A server MUST read the entire request message body or close the |
| connection after sending its response, since otherwise the remaining |  | connection after sending its response, since otherwise the remaining |
| data on a persistent connection would be misinterpreted as the next |  | data on a persistent connection would be misinterpreted as the next |
| request. Likewise, a client MUST read the entire response message |  | request. Likewise, a client MUST read the entire response message |
| body if it intends to reuse the same connection for a subsequent |  | body if it intends to reuse the same connection for a subsequent |
| request. Pipelining multiple requests on a connection is described |  | request. Pipelining multiple requests on a connection is described |
| in Section 6.3.2.2. |  | in Section 6.3.2.2. |
| 3.5. Message Parsing Robustness |  | 3.5. Message Parsing Robustness |
| skipping to change at page 35, line 24 |  | skipping to change at page 35, line 24 |
| trailer for any header fields unless at least one of the following is |  | trailer for any header fields unless at least one of the following is |
| true: |  | 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 it. In |  | server where the field originated) without receiving it. In |
| other words, the server that generated the header (often but not |  | other words, the server that generated the header field (often |
| always the origin server) is willing to accept the possibility |  | but not always the origin server) is willing to accept the |
| that the trailer fields might be silently discarded along the |  | possibility that the trailer fields might be silently discarded |
| path to the client. |  | along the path to the client. |
| This requirement prevents an interoperability failure when the |  | This requirement prevents an interoperability failure when the |
| 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. It avoids a situation where |  | forwarded to an HTTP/1.0 recipient. It avoids a situation where |
| conformance with the protocol would have necessitated a possibly |  | conformance with the protocol would have necessitated a possibly |
| infinite buffer on the proxy. |  | infinite buffer on the proxy. |
| A process for decoding the "chunked" transfer-coding can be |  | A process for decoding the "chunked" transfer-coding can be |
| represented in pseudo-code as: |  | represented in pseudo-code as: |
| skipping to change at page 38, line 16 |  | skipping to change at page 38, line 16 |
| transfer-coding with the highest non-zero qvalue is preferred. |  | transfer-coding with the highest non-zero qvalue is preferred. |
| The "chunked" transfer-coding always has a qvalue of 1. |  | The "chunked" transfer-coding always has a qvalue of 1. |
| 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. |
| 4.3.1. Quality Values |  | 4.3.1. Quality Values |
| Both transfer codings (TE request header field, Section 4.3) and |  | Both transfer codings (TE request header field, Section 4.3) and |
| content negotiation (Section 5 of [Part3]) use short "floating point" |  | content negotiation (Section 8 of [Part2]) use short "floating point" |
| numbers to indicate the relative importance ("weight") of various |  | numbers to indicate the relative importance ("weight") of various |
| negotiable parameters. A weight is normalized to a real number in |  | negotiable parameters. A weight is normalized to a real number in |
| the range 0 through 1, where 0 is the minimum and 1 the maximum |  | the range 0 through 1, where 0 is the minimum and 1 the maximum |
| value. If a parameter has a quality value of 0, then content with |  | value. If a parameter has a quality value of 0, then content with |
| this parameter is "not acceptable" for the client. HTTP/1.1 |  | this parameter is "not acceptable" for the client. HTTP/1.1 |
| applications MUST NOT generate more than three digits after the |  | applications MUST NOT generate more than three digits after the |
| decimal point. User configuration of these values SHOULD also be |  | decimal point. User configuration of these values SHOULD also be |
| limited in this fashion. |  | limited in this fashion. |
| qvalue = ( "0" [ "." 0*3DIGIT ] ) |  | qvalue = ( "0" [ "." 0*3DIGIT ] ) |
| skipping to change at page 39, line 30 |  | skipping to change at page 39, line 30 |
| HTTP is used in a wide variety of applications, ranging from general- |  | HTTP is used in a wide variety of applications, ranging from general- |
| purpose computers to home appliances. In some cases, communication |  | purpose computers to home appliances. In some cases, communication |
| options are hard-coded in a client's configuration. However, most |  | options are hard-coded in a client's configuration. However, most |
| HTTP clients rely on the same resource identification mechanism and |  | HTTP clients rely on the same resource identification mechanism and |
| configuration techniques as general-purpose Web browsers. |  | configuration techniques as general-purpose Web browsers. |
| HTTP communication is initiated by a user agent for some purpose. |  | HTTP communication is initiated by a user agent for some purpose. |
| The purpose is a combination of request semantics, which are defined |  | The purpose is a combination of request semantics, which are defined |
| in [Part2], and a target resource upon which to apply those |  | in [Part2], and a target resource upon which to apply those |
| semantics. A URI reference (Section 2.7) is typically used as an |  | semantics. A URI reference (Section 2.8) is typically used as an |
| identifier for the "target resource", which a user agent would |  | identifier for the "target resource", which a user agent would |
| resolve to its absolute form in order to obtain the "target URI". |  | resolve to its absolute form in order to obtain the "target URI". |
| The target URI excludes the reference's fragment identifier |  | The target URI excludes the reference's fragment identifier |
| component, if any, since fragment identifiers are reserved for |  | component, if any, since fragment identifiers are reserved for |
| client-side processing ([RFC3986], Section 3.5). |  | client-side processing ([RFC3986], Section 3.5). |
| HTTP intermediaries obtain the request semantics and target URI from |  | HTTP intermediaries obtain the request semantics and target URI from |
| the request-line of an incoming request message. |  | the request-line of an incoming request message. |
| 5.2. Connecting Inbound |  | 5.2. Connecting Inbound |
| skipping to change at page 40, line 15 |  | skipping to change at page 40, line 15 |
| authority matching, or both, and the proxy itself is usually |  | authority matching, or both, and the proxy itself is usually |
| identified by an "http" or "https" URI. If a proxy is applicable, |  | identified by an "http" or "https" URI. If a proxy is applicable, |
| the client connects inbound by establishing (or reusing) a connection |  | the client connects inbound by establishing (or reusing) a connection |
| to that proxy. |  | to that proxy. |
| If no proxy is applicable, a typical client will invoke a handler |  | If no proxy is applicable, a typical client will invoke a handler |
| routine, usually specific to the target URI's scheme, to connect |  | routine, usually specific to the target URI's scheme, to connect |
| directly to an authority for the target resource. How that is |  | directly to an authority for the target resource. How that is |
| accomplished is dependent on the target URI scheme and defined by its |  | accomplished is dependent on the target URI scheme and defined by its |
| associated specification, similar to how this specification defines |  | associated specification, similar to how this specification defines |
| origin server access for resolution of the "http" (Section 2.7.1) and |  | origin server access for resolution of the "http" (Section 2.8.1) and |
| "https" (Section 2.7.2) schemes. |  | "https" (Section 2.8.2) schemes. |
| 5.3. Request Target |  | 5.3. Request Target |
| Once an inbound connection is obtained (Section 6), the client sends |  | Once an inbound connection is obtained (Section 6), the client sends |
| an HTTP request message (Section 3) with a request-target derived |  | an HTTP request message (Section 3) with a request-target derived |
| from the target URI. There are four distinct formats for the |  | from the target URI. There are four distinct formats for the |
| request-target, depending on both the method being requested and |  | request-target, depending on both the method being requested and |
| whether the request is to a proxy. |  | whether the request is to a proxy. |
| request-target = origin-form |  | request-target = origin-form |
| skipping to change at page 41, line 31 |  | skipping to change at page 41, line 31 |
| 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. |
| The authority-form of request-target is only used for CONNECT |  | The authority-form of request-target is only used for CONNECT |
| requests (Section 6.9 of [Part2]). When making a CONNECT request to |  | requests (Section 2.3.8 of [Part2]). When making a CONNECT request |
| 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 |
| 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 6.2 of [Part2]). When a client wishes to |  | OPTIONS request (Section 2.3.1 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 |
| skipping to change at page 42, line 25 |  | skipping to change at page 42, line 25 |
| 5.4. Host |  | 5.4. Host |
| The "Host" header field in a request provides the host and port |  | The "Host" header field in a request provides the host and port |
| information from the target URI, enabling the origin server to |  | information from the target URI, enabling the origin server to |
| distinguish among resources while servicing requests for multiple |  | distinguish among resources while servicing requests for multiple |
| host names on a single IP address. Since the Host field-value is |  | host names on a single IP address. Since the Host field-value is |
| critical information for handling a request, it SHOULD be sent as the |  | critical information for handling a request, it SHOULD be sent as the |
| first header field following the request-line. |  | first header field following the request-line. |
| Host = uri-host [ ":" port ] ; Section 2.7.1 |  | Host = uri-host [ ":" port ] ; Section 2.8.1 |
| A client MUST send a Host header field in all HTTP/1.1 request |  | A client MUST send a Host header field in all HTTP/1.1 request |
| messages. If the target URI includes an authority component, then |  | messages. If the target URI includes an authority component, then |
| the Host field-value MUST be identical to that authority component |  | the Host field-value MUST be identical to that authority component |
| after excluding any userinfo (Section 2.7.1). If the authority |  | after excluding any userinfo (Section 2.8.1). If the authority |
| component is missing or undefined for the target URI, then the Host |  | component is missing or undefined for the target URI, then the Host |
| header field MUST be sent with an empty field-value. |  | header field MUST be sent with an empty field-value. |
| For example, a GET request to the origin server for |  | For example, a GET request to the origin server for |
| <http://www.example.org/pub/WWW/> would begin with: |  | <http://www.example.org/pub/WWW/> would begin with: |
| GET /pub/WWW/ HTTP/1.1 |  | GET /pub/WWW/ HTTP/1.1 |
| Host: www.example.org |  | Host: www.example.org |
| The Host header field MUST be sent in an HTTP/1.1 request even if the |  | The Host header field MUST be sent in an HTTP/1.1 request even if the |
| skipping to change at page 43, line 21 |  | skipping to change at page 43, line 21 |
| A server MUST respond with a 400 (Bad Request) status code to any |  | A server MUST respond with a 400 (Bad Request) status code to any |
| HTTP/1.1 request message that lacks a Host header field and to any |  | HTTP/1.1 request message that lacks a Host header field and to any |
| request message that contains more than one Host header field or a |  | request message that contains more than one Host header field or a |
| Host header field with an invalid field-value. |  | Host header field with an invalid field-value. |
| 5.5. Effective Request URI |  | 5.5. Effective Request URI |
| A server that receives an HTTP request message MUST reconstruct the |  | A server that receives an HTTP request message MUST reconstruct the |
| user agent's original target URI, based on the pieces of information |  | user agent's original target URI, based on the pieces of information |
| learned from the request-target, Host, and connection context, in |  | learned from the request-target, Host header field, and connection |
| order to identify the intended target resource and properly service |  | context, in order to identify the intended target resource and |
| the request. The URI derived from this reconstruction process is |  | properly service the request. The URI derived from this |
| referred to as the "effective request URI". |  | reconstruction process is referred to as the "effective request URI". |
| For a user agent, the effective request URI is the target URI. |  | For a user agent, the effective request URI is the target URI. |
| If the request-target is in absolute-form, then the effective request |  | If the request-target is in absolute-form, then the effective request |
| URI is the same as the request-target. Otherwise, the effective |  | URI is the same as the request-target. Otherwise, the effective |
| request URI is constructed as follows. |  | request URI is constructed as follows. |
| If the request is received over an SSL/TLS-secured TCP connection, |  | If the request is received over an SSL/TLS-secured TCP connection, |
| then the effective request URI's scheme is "https"; otherwise, the |  | then the effective request URI's scheme is "https"; otherwise, the |
| scheme is "http". |  | scheme is "http". |
| If the request-target is in authority-form, then the effective |  | If the request-target is in authority-form, then the effective |
| request URI's authority component is the same as the request-target. |  | request URI's authority component is the same as the request-target. |
| Otherwise, if a Host header field is supplied with a non-empty field- |  | Otherwise, if a Host header field is supplied with a non-empty field- |
| value, then the authority component is the same as the Host field- |  | value, then the authority component is the same as the Host field- |
| value. Otherwise, the authority component is the concatenation of |  | value. Otherwise, the authority component is the concatenation of |
| the default hostname configured for the server, a colon (":"), and |  | the default host name configured for the server, a colon (":"), and |
| the connection's incoming TCP port number in decimal form. |  | the connection's incoming TCP port number in decimal form. |
| If the request-target is in authority-form or asterisk-form, then the |  | If the request-target is in authority-form or asterisk-form, then the |
| effective request URI's combined path and query component is empty. |  | effective request URI's combined path and query component is empty. |
| Otherwise, the combined path and query component is the same as the |  | Otherwise, the combined path and query component is the same as the |
| request-target. |  | request-target. |
| The components of the effective request URI, once determined as |  | The components of the effective request URI, once determined as |
| above, can be combined into absolute-URI form by concatenating the |  | above, can be combined into absolute-URI form by concatenating the |
| scheme, "://", authority, and combined path and query component. |  | scheme, "://", authority, and combined path and query component. |
| skipping to change at page 44, line 36 |  | skipping to change at page 44, line 36 |
| 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. Intermediary Forwarding |  | 5.6. Intermediary Forwarding |
| As described in Section 2.3, intermediaries can serve a variety of |  | As described in Section 2.4, 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. |
| 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 |
| skipping to change at page 45, line 32 |  | skipping to change at page 45, line 32 |
| transmitted in any response formed from a cache entry. |  | transmitted in any response formed from a cache entry. |
| o Hop-by-hop header fields, which are meaningful only for a single |  | o Hop-by-hop header fields, which are meaningful only for a single |
| transport-level connection, and are not stored by caches or |  | transport-level connection, and are not stored by caches or |
| forwarded by proxies. |  | forwarded by proxies. |
| The following HTTP/1.1 header fields are hop-by-hop header fields: |  | The following HTTP/1.1 header fields are hop-by-hop header fields: |
| o Connection |  | o Connection |
| o Keep-Alive |  | o Keep-Alive (Section 19.7.1.1 of [RFC2068]) |
| o Proxy-Authenticate |  | o Proxy-Authenticate (Section 4.2 of [Part7]) |
| o Proxy-Authorization |  | o Proxy-Authorization (Section 4.3 of [Part7]) |
| o TE |  | o TE |
| o Trailer |  | o Trailer |
| o Transfer-Encoding |  | o Transfer-Encoding |
| o Upgrade |  | o Upgrade |
| All other header fields defined by HTTP/1.1 are end-to-end header |  | All other header fields defined by HTTP/1.1 are end-to-end header |
| skipping to change at page 46, line 16 |  | skipping to change at page 46, line 16 |
| Some features of HTTP/1.1, such as Digest Authentication, depend on |  | Some features of HTTP/1.1, such as Digest Authentication, depend on |
| the value of certain end-to-end header fields. A non-transforming |  | the value of certain end-to-end header fields. A non-transforming |
| proxy SHOULD NOT modify an end-to-end header field unless the |  | proxy SHOULD NOT modify an end-to-end header field unless the |
| definition of that header field requires or specifically allows that. |  | definition of that header field requires or specifically allows that. |
| A non-transforming proxy MUST NOT modify any of the following fields |  | 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 |  | in a request or response, and it MUST NOT add any of these fields if |
| not already present: |  | not already present: |
| o Allow |  | o Allow (Section 9.5 of [Part2]) |
| o Content-Location |  | o Content-Location (Section 9.8 of [Part2]) |
| o Content-MD5 |  | o Content-MD5 (Section 14.15 of [RFC2616]) |
| o ETag |  | o ETag (Section 2.3 of [Part4]) |
| o Last-Modified |  | o Last-Modified (Section 2.2 of [Part4]) |
| o Server |  | o Server (Section 9.17 of [Part2]) |
| A non-transforming proxy MUST NOT modify any of the following fields |  | A non-transforming proxy MUST NOT modify any of the following fields |
| in a response: |  | in a response: |
| o Expires |  | o Expires (Section 7.3 of [Part6]) |
| but it MAY add any of these fields if not already present. If an |  | but it MAY add any of these fields if not already present. If an |
| Expires header field is added, it MUST be given a field-value |  | Expires header field is added, it MUST be given a field value |
| identical to that of the Date header field in that response. |  | identical to that of the Date header field in that response. |
| A proxy MUST NOT modify or add any of the following fields in a |  | A proxy MUST NOT modify or add any of the following fields in a |
| message that contains the no-transform cache-control directive, or in |  | message that contains the no-transform cache-control directive, or in |
| any request: |  | any request: |
| o Content-Encoding |  | o Content-Encoding (Section 9.6 of [Part2]) |
| o Content-Range |  | o Content-Range (Section 5.2 of [Part5]) |
| o Content-Type |  | o Content-Type (Section 9.9 of [Part2]) |
| A transforming proxy MAY modify or add these fields to a message that |  | A transforming proxy MAY modify or add these fields to a message that |
| does not include no-transform, but if it does so, it MUST add a |  | does not include no-transform, but if it does so, it MUST add a |
| Warning 214 (Transformation applied) if one does not already appear |  | Warning 214 (Transformation applied) if one does not already appear |
| in the message (see Section 3.6 of [Part6]). |  | in the message (see Section 7.6 of [Part6]). |
| Warning: Unnecessary modification of end-to-end header fields |  | Warning: Unnecessary modification of end-to-end header fields |
| might cause authentication failures if stronger authentication |  | might cause authentication failures if stronger authentication |
| mechanisms are introduced in later versions of HTTP. Such |  | mechanisms are introduced in later versions of HTTP. Such |
| authentication mechanisms MAY rely on the values of header fields |  | authentication mechanisms MAY rely on the values of header fields |
| not listed here. |  | not listed here. |
| A non-transforming proxy MUST preserve the message payload ([Part3]), |  | A non-transforming proxy MUST preserve the message payload ([Part2]), |
| though it MAY change the message body through application or removal |  | though it MAY change the message body through application or removal |
| of a transfer-coding (Section 4). |  | of a transfer-coding (Section 4). |
| 5.7. Associating a Response to a Request |  | 5.7. Associating a Response to a Request |
| HTTP does not include a request identifier for associating a given |  | HTTP does not include a request identifier for associating a given |
| request message with its corresponding one or more response messages. |  | request message with its corresponding one or more response messages. |
| Hence, it relies on the order of response arrival to correspond |  | Hence, it relies on the order of response arrival to correspond |
| exactly to the order in which requests are made on the same |  | exactly to the order in which requests are made on the same |
| connection. More than one response message per request only occurs |  | connection. More than one response message per request only occurs |
| when one or more informational responses (1xx, see Section 7.1 of |  | when one or more informational responses (1xx, see Section 4.3 of |
| [Part2]) precede a final response to the same request. |  | [Part2]) precede a final response to the same request. |
| A client that uses persistent connections and sends more than one |  | A client that uses persistent connections and sends more than one |
| request per connection MUST maintain a list of outstanding requests |  | request per connection MUST maintain a list of outstanding requests |
| in the order sent on that connection and MUST associate each received |  | in the order sent on that connection and MUST associate each received |
| response message to the highest ordered request that has not yet |  | response message to the highest ordered request that has not yet |
| received a final (non-1xx) response. |  | received a final (non-1xx) response. |
| 6. Connection Management |  | 6. Connection Management |
| skipping to change at page 47, line 48 |  | skipping to change at page 47, line 48 |
| be forwarded downstream by a proxy or gateway. This mechanism also |  | be forwarded downstream by a proxy or gateway. This mechanism also |
| allows the sender to indicate which HTTP header fields used in the |  | allows the sender to indicate which HTTP header fields used in the |
| message are only intended for the immediate recipient ("hop-by-hop"), |  | message are only intended for the immediate recipient ("hop-by-hop"), |
| as opposed to all recipients on the chain ("end-to-end"), enabling |  | as opposed to all recipients on the chain ("end-to-end"), enabling |
| the message to be self-descriptive and allowing future connection- |  | the message to be self-descriptive and allowing future connection- |
| specific extensions to be deployed in HTTP without fear that they |  | specific extensions to be deployed in HTTP without fear that they |
| will be blindly forwarded by previously deployed intermediaries. |  | will be blindly forwarded by previously deployed intermediaries. |
| The Connection header field's value has the following grammar: |  | The Connection header field's value has the following grammar: |
| Connection = 1#connection-token |  | Connection = 1#connection-option |
| connection-token = token |  | connection-option = token |
|  |  | Connection options are compared case-insensitively. |
| A proxy or gateway MUST parse a received Connection header field |  | A proxy or gateway MUST parse a received Connection header field |
| before a message is forwarded and, for each connection-token in this |  | before a message is forwarded and, for each connection-option in this |
| field, remove any header field(s) from the message with the same name |  | field, remove any header field(s) from the message with the same name |
| as the connection-token, and then remove the Connection header field |  | as the connection-option, and then remove the Connection header field |
| itself or replace it with the sender's own connection options for the |  | itself or replace it with the sender's own connection options for the |
| forwarded message. |  | forwarded message. |
| A sender MUST NOT include field-names in the Connection header field- |  | A sender MUST NOT include field-names in the Connection header field- |
| value for fields that are defined as expressing constraints for all |  | value for fields that are defined as expressing constraints for all |
| recipients in the request or response chain, such as the Cache- |  | recipients in the request or response chain, such as the Cache- |
| Control header field (Section 3.2 of [Part6]). |  | Control header field (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-token rather than only the presence |  | on the presence of the connection-option rather than only the |
| of the optional header field. In other words, if the connection |  | presence of the optional header field. In other words, if the |
| option is received as a header field but not indicated within the |  | connection option is received as a header field but not indicated |
| Connection field-value, then the recipient MUST ignore the |  | within the Connection field-value, then the recipient MUST ignore the |
| connection-specific header field because it has likely been forwarded |  | connection-specific header field because it has likely been forwarded |
| by an intermediary that is only partially conformant. |  | by an intermediary that is only partially conformant. |
| When defining new connection options, specifications ought to |  | When defining new connection options, specifications ought to |
| carefully consider existing deployed header fields and ensure that |  | carefully consider existing deployed header fields and ensure that |
| the new connection-token does not share the same name as an unrelated |  | the new connection option does not share the same name as an |
| header field that might already be deployed. Defining a new |  | unrelated header field that might already be deployed. Defining a |
| connection-token essentially reserves that potential field-name for |  | new connection option essentially reserves that potential field-name |
| carrying additional information related to the connection option, |  | for carrying additional information related to the connection option, |
| 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. |
| HTTP/1.1 defines the "close" connection option for the sender to |  | HTTP/1.1 defines the "close" connection option for the sender to |
| signal that the connection will be closed after completion of the |  | signal that the connection will be closed after completion of the |
| response. For example, |  | response. For 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 |
| skipping to change at page 51, line 40 |  | skipping to change at page 51, line 43 |
| Persistent connections provide a mechanism by which a client and a |  | Persistent connections provide a mechanism by which a client and a |
| server can signal the close of a TCP connection. This signaling |  | server can signal the close of a TCP connection. This signaling |
| takes place using the Connection header field (Section 6.1). Once a |  | takes place using the Connection header field (Section 6.1). Once a |
| close has been signaled, the client MUST NOT send any more requests |  | close has been signaled, the client MUST NOT send any more requests |
| on that connection. |  | on that connection. |
| 6.3.2.1. Negotiation |  | 6.3.2.1. Negotiation |
| An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to |  | An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to |
| maintain a persistent connection unless a Connection header field |  | maintain a persistent connection unless a Connection header field |
| including the connection-token "close" was sent in the request. If |  | including the connection option "close" was sent in the request. If |
| the server chooses to close the connection immediately after sending |  | the server chooses to close the connection immediately after sending |
| the response, it SHOULD send a Connection header field including the |  | the response, it SHOULD send a Connection header field including the |
| connection-token "close". |  | connection option "close". |
| An HTTP/1.1 client MAY expect a connection to remain open, but would |  | An HTTP/1.1 client MAY expect a connection to remain open, but would |
| decide to keep it open based on whether the response from a server |  | decide to keep it open based on whether the response from a server |
| contains a Connection header field with the connection-token close. |  | contains a Connection header field with the connection option |
| In case the client does not want to maintain a connection for more |  | "close". In case the client does not want to maintain a connection |
| than that request, it SHOULD send a Connection header field including |  | for more than that request, it SHOULD send a Connection header field |
| the connection-token close. |  | including the connection option "close". |
| If either the client or the server sends the close token in the |  | If either the client or the server sends the "close" option in the |
| Connection header field, that request becomes the last one for the |  | Connection header field, that request becomes the last one for the |
| connection. |  | connection. |
| 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. |
| Each persistent connection applies to only one transport link. |  | Each persistent connection applies to only one transport link. |
| skipping to change at page 52, line 42 |  | skipping to change at page 52, line 43 |
| Clients which assume persistent connections and pipeline immediately |  | Clients which assume persistent connections and pipeline immediately |
| after connection establishment SHOULD be prepared to retry their |  | after connection establishment SHOULD be prepared to retry their |
| connection if the first pipelined attempt fails. If a client does |  | connection if the first pipelined attempt fails. If a client does |
| such a retry, it MUST NOT pipeline before it knows the connection is |  | such a retry, it MUST NOT pipeline before it knows the connection is |
| persistent. Clients MUST also be prepared to resend their requests |  | persistent. Clients MUST also be prepared to resend their requests |
| if the server closes the connection before sending all of the |  | if the server closes the connection before sending all of the |
| corresponding responses. |  | corresponding responses. |
| Clients SHOULD NOT pipeline requests using non-idempotent request |  | Clients SHOULD NOT pipeline requests using non-idempotent request |
| methods or non-idempotent sequences of request methods (see Section |  | methods or non-idempotent sequences of request methods (see Section |
| 6.1.2 of [Part2]). Otherwise, a premature termination of the |  | 2.1.2 of [Part2]). Otherwise, a premature termination of the |
| transport connection could lead to indeterminate results. A client |  | transport connection could lead to indeterminate results. A client |
| wishing to send a non-idempotent request SHOULD wait to send that |  | wishing to send a non-idempotent request SHOULD wait to send that |
| request until it has received the response status line for the |  | request until it has received the response status line for the |
| previous request. |  | previous request. |
| 6.3.3. Practical Considerations |  | 6.3.3. Practical Considerations |
| 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 |
| skipping to change at page 53, line 49 |  | skipping to change at page 54, line 6 |
| 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.3.4. Retrying Requests |  | 6.3.4. Retrying Requests |
| Senders can close the transport connection at any time. Therefore, |  | Senders can close the transport connection at any time. Therefore, |
| clients, servers, and proxies MUST be able to recover from |  | clients, servers, and proxies MUST be able to recover from |
| asynchronous close events. Client software MAY reopen the transport |  | asynchronous close events. Client software MAY reopen the transport |
| connection and retransmit the aborted sequence of requests without |  | connection and retransmit the aborted sequence of requests without |
| user interaction so long as the request sequence is idempotent (see |  | user interaction so long as the request sequence is idempotent (see |
| Section 6.1.2 of [Part2]). Non-idempotent request methods or |  | Section 2.1.2 of [Part2]). Non-idempotent request methods or |
| sequences MUST NOT be automatically retried, although user agents MAY |  | sequences MUST NOT be automatically retried, although user agents MAY |
| offer a human operator the choice of retrying the request(s). |  | offer a human operator the choice of retrying the request(s). |
| Confirmation by user-agent software with semantic understanding of |  | Confirmation by user-agent software with semantic understanding of |
| the application MAY substitute for user confirmation. The automatic |  | the application MAY substitute for user confirmation. The automatic |
| retry SHOULD NOT be repeated if the second sequence of requests |  | retry SHOULD NOT be repeated if the second sequence of requests |
| fails. |  | fails. |
| 6.4. Message Transmission Requirements |  | 6.4. Message Transmission Requirements |
| 6.4.1. Persistent Connections and Flow Control |  | 6.4.1. Persistent Connections and Flow Control |
| HTTP/1.1 servers SHOULD maintain persistent connections and use TCP's |  | HTTP/1.1 servers SHOULD maintain persistent connections and use TCP's |
| skipping to change at page 54, line 32 |  | skipping to change at page 54, line 36 |
| the network connection for an error status code while it is |  | the network connection for an error status code while it is |
| transmitting the request. If the client sees an error status code, |  | transmitting the request. If the client sees an error status code, |
| it SHOULD immediately cease transmitting the body. If the body is |  | it SHOULD immediately cease transmitting the body. If the body is |
| being sent using a "chunked" encoding (Section 4), a zero length |  | being sent using a "chunked" encoding (Section 4), a zero length |
| chunk and empty trailer MAY be used to prematurely mark the end of |  | chunk and empty trailer MAY be used to prematurely mark the end of |
| the message. If the body was preceded by a Content-Length header |  | the message. If the body was preceded by a Content-Length header |
| field, the client MUST close the connection. |  | field, the client MUST close the connection. |
| 6.4.3. Use of the 100 (Continue) Status |  | 6.4.3. Use of the 100 (Continue) Status |
| The purpose of the 100 (Continue) status code (see Section 7.1.1 of |  | The purpose of the 100 (Continue) status code (see Section 4.3.1 of |
| [Part2]) is to allow a client that is sending a request message with |  | [Part2]) is to allow a client that is sending a request message with |
| a request body to determine if the origin server is willing to accept |  | a request body to determine if the origin server is willing to accept |
| the request (based on the request header fields) before the client |  | the request (based on the request header fields) before the client |
| sends the request body. In some cases, it might either be |  | sends the request body. In some cases, it might either be |
| inappropriate or highly inefficient for the client to send the body |  | inappropriate or highly inefficient for the client to send the body |
| if the server will reject the message without looking at the body. |  | if the server will reject the message without looking at the body. |
| Requirements for HTTP/1.1 clients: |  | Requirements for HTTP/1.1 clients: |
| o If a client will wait for a 100 (Continue) response before sending |  | o If a client will wait for a 100 (Continue) response before sending |
| the request body, it MUST send an Expect header field (Section |  | the request body, it MUST send an Expect header field (Section |
| 10.3 of [Part2]) with the "100-continue" expectation. |  | 9.11 of [Part2]) with the "100-continue" expectation. |
| o A client MUST NOT send an Expect header field (Section 10.3 of |  | o A client MUST NOT send an Expect header field with the "100- |
| [Part2]) with the "100-continue" expectation if it does not intend |  | continue" expectation if it does not intend to send a request |
| to send a request body. |  | body. |
| Because of the presence of older implementations, the protocol allows |  | Because of the presence of older implementations, the protocol allows |
| ambiguous situations in which a client might send "Expect: 100- |  | ambiguous situations in which a client might send "Expect: 100- |
| continue" without receiving either a 417 (Expectation Failed) or a |  | continue" without receiving either a 417 (Expectation Failed) or a |
| 100 (Continue) status code. Therefore, when a client sends this |  | 100 (Continue) status code. Therefore, when a client sends this |
| header field to an origin server (possibly via a proxy) from which it |  | header field to an origin server (possibly via a proxy) from which it |
| has never seen a 100 (Continue) status code, the client SHOULD NOT |  | has never seen a 100 (Continue) status code, the client SHOULD NOT |
| wait for an indefinite period before sending the request body. |  | wait for an indefinite period before sending the request body. |
| Requirements for HTTP/1.1 origin servers: |  | Requirements for HTTP/1.1 origin servers: |
| skipping to change at page 56, line 26 |  | skipping to change at page 56, line 31 |
| HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST |  | HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST |
| respond with a 417 (Expectation Failed) status code. |  | respond with a 417 (Expectation Failed) status code. |
| o Proxies SHOULD maintain a record of the HTTP version numbers |  | o Proxies SHOULD maintain a record of the HTTP version numbers |
| received from recently-referenced next-hop servers. |  | received from recently-referenced next-hop servers. |
| o A proxy MUST NOT forward a 100 (Continue) response if the request |  | o A proxy MUST NOT forward a 100 (Continue) response if the request |
| message was received from an HTTP/1.0 (or earlier) client and did |  | message was received from an HTTP/1.0 (or earlier) client and did |
| not include an Expect header field with the "100-continue" |  | not include an Expect header field with the "100-continue" |
| expectation. This requirement overrides the general rule for |  | expectation. This requirement overrides the general rule for |
| forwarding of 1xx responses (see Section 7.1 of [Part2]). |  | forwarding of 1xx responses (see Section 4.3 of [Part2]). |
| 6.4.4. Closing Connections on Error |  | 6.4.4. Closing Connections on Error |
| If the client is sending data, a server implementation using TCP |  | If the client is sending data, a server implementation using TCP |
| SHOULD be careful to ensure that the client acknowledges receipt of |  | SHOULD be careful to ensure that the client acknowledges receipt of |
| the packet(s) containing the response, before the server closes the |  | the packet(s) containing the response, before the server closes the |
| input connection. If the client continues sending data to the server |  | input connection. If the client continues sending data to the server |
| after the close, the server's TCP stack will send a reset packet to |  | after the close, the server's TCP stack will send a reset packet to |
| the client, which might erase the client's unacknowledged input |  | the client, which might erase the client's unacknowledged input |
| buffers before they can be read and interpreted by the HTTP |  | buffers before they can be read and interpreted by the HTTP |
| skipping to change at page 57, line 37 |  | skipping to change at page 57, line 43 |
| after changing the protocol MUST be a response to the initial HTTP |  | after changing the protocol MUST be a response to the initial HTTP |
| request containing the Upgrade header field. |  | request containing the Upgrade header field. |
| The Upgrade header field only applies to the immediate connection. |  | The Upgrade header field only applies to the immediate connection. |
| Therefore, the upgrade keyword MUST be supplied within a Connection |  | Therefore, the upgrade keyword MUST be supplied within a Connection |
| header field (Section 6.1) whenever Upgrade is present in an HTTP/1.1 |  | header field (Section 6.1) whenever Upgrade is present in an HTTP/1.1 |
| message. |  | message. |
| The Upgrade header field cannot be used to indicate a switch to a |  | The Upgrade header field cannot be used to indicate a switch to a |
| protocol on a different connection. For that purpose, it is more |  | protocol on a different connection. For that purpose, it is more |
| appropriate to use a 3xx redirection response (Section 7.3 of |  | appropriate to use a 3xx (Redirection) response (Section 4.5 of |
| [Part2]). |  | [Part2]). |
| Servers MUST include the "Upgrade" header field in 101 (Switching |  | Servers MUST include the "Upgrade" header field in 101 (Switching |
| Protocols) responses to indicate which protocol(s) are being switched |  | Protocols) responses to indicate which protocol(s) are being switched |
| to, and MUST include it in 426 (Upgrade Required) responses to |  | to, and MUST include it in 426 (Upgrade Required) responses to |
| indicate acceptable protocols to upgrade to. Servers MAY include it |  | indicate acceptable protocols to upgrade to. Servers MAY include it |
| in any other response to indicate that they are willing to upgrade to |  | in any other response to indicate that they are willing to upgrade to |
| one of the specified protocols. |  | one of the specified protocols. |
| 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.7 and future updates to this |
| specification. Additional tokens can be registered with IANA using |  | specification. Additional tokens can be registered with IANA using |
| the registration procedure defined in Section 7.6. |  | 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 [RFC3864] maintained by IANA at <http://www.iana.org/ |
| assignments/message-headers/message-header-index.html>. |  | assignments/message-headers/message-header-index.html>. |
| skipping to change at page 59, line 8 |  | skipping to change at page 59, line 17 |
| IANA maintains the registry of URI Schemes [RFC4395] at |  | IANA maintains the registry of URI Schemes [RFC4395] 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.8.1 | |
| | https | Hypertext Transfer Protocol Secure | Section 2.7.2 | |  | | https | Hypertext Transfer Protocol Secure | Section 2.8.2 | |
| +------------+------------------------------------+---------------+ |  | +------------+------------------------------------+---------------+ |
| 7.3. Internet Media Type Registrations |  | 7.3. Internet Media Type Registrations |
| 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 [RFC4288]). |
| 7.3.1. Internet Media Type message/http |  | 7.3.1. Internet Media Type message/http |
| skipping to change at page 61, line 39 |  | skipping to change at page 61, line 52 |
| Registrations MUST include the following fields: |  | Registrations MUST include the following fields: |
| o Name |  | o Name |
| o Description |  | o Description |
| o Pointer to specification text |  | o Pointer to specification text |
| Names of transfer codings MUST NOT overlap with names of content |  | Names of transfer codings MUST NOT overlap with names of content |
| codings (Section 2.2 of [Part3]) unless the encoding transformation |  | codings (Section 5.4 of [Part2]) unless the encoding transformation |
| is identical, as it is the case for the compression codings defined |  | is identical, as it is the case for the compression codings defined |
| in Section 4.2. |  | in Section 4.2. |
| 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. |  | transfer coding defined in this section. |
| The registry itself is maintained at |  | The registry itself is maintained at |
| <http://www.iana.org/assignments/http-parameters>. |  | <http://www.iana.org/assignments/http-parameters>. |
| skipping to change at page 62, line 25 |  | skipping to change at page 62, line 34 |
| | deflate | "deflate" compression mechanism | Section 4.2.2 | |  | | deflate | "deflate" compression mechanism | Section 4.2.2 | |
| | | ([RFC1951]) used inside the "zlib" | | |  | | | ([RFC1951]) used inside the "zlib" | | |
| | | data format ([RFC1950]) | | |  | | | data format ([RFC1950]) | | |
| | gzip | Same as GNU zip [RFC1952] | Section 4.2.3 | |  | | gzip | Same as GNU zip [RFC1952] | Section 4.2.3 | |
| +----------+----------------------------------------+---------------+ |  | +----------+----------------------------------------+---------------+ |
| 7.6. Upgrade Token Registry |  | 7.6. Upgrade Token Registry |
| The HTTP Upgrade Token Registry defines the name space for protocol- |  | The HTTP Upgrade Token Registry defines the name space for protocol- |
| name tokens used to identify protocols in the Upgrade header field. |  | name tokens used to identify protocols in the Upgrade header field. |
| Each registered protocol-name is associated with contact information |  | Each registered protocol name is associated with contact information |
| and an optional set of specifications that details how the connection |  | and an optional set of specifications that details how the connection |
| will be processed after it has been upgraded. |  | will be processed after it has been upgraded. |
| Registrations require IETF Review (see Section 4.1 of [RFC5226]) and |  | Registrations happen on a "First Come First Served" basis (see |
| are subject to the following rules: |  | Section 4.1 of [RFC5226]) and are subject to the following rules: |
| 1. A protocol-name token, once registered, stays registered forever. |  | 1. A protocol-name token, once registered, stays registered forever. |
| 2. The registration MUST name a responsible party for the |  | 2. The registration MUST name a responsible party for the |
| registration. |  | registration. |
| 3. The registration MUST name a point of contact. |  | 3. The registration MUST name a point of contact. |
| 4. The registration MAY name a set of specifications associated with |  | 4. The registration MAY name a set of specifications associated with |
| that token. Such specifications need not be publicly available. |  | that token. Such specifications need not be publicly available. |
| skipping to change at page 63, line 17 |  | skipping to change at page 63, line 28 |
| 7.7. Upgrade Token Registration |  | 7.7. Upgrade Token Registration |
| The HTTP Upgrade Token Registry shall be updated with the |  | The HTTP Upgrade Token Registry shall be updated with the |
| registration below: |  | registration below: |
| +-------+----------------------+----------------------+-------------+ |  | +-------+----------------------+----------------------+-------------+ |
| | Value | Description | Expected Version | Reference | |  | | Value | Description | Expected Version | Reference | |
| | | | Tokens | | |  | | | | Tokens | | |
| +-------+----------------------+----------------------+-------------+ |  | +-------+----------------------+----------------------+-------------+ |
| | HTTP | Hypertext Transfer | any DIGIT.DIGIT | Section 2.6 | |  | | HTTP | Hypertext Transfer | any DIGIT.DIGIT | Section 2.7 | |
| | | 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 application developers, information |
| providers, and users of the security limitations in HTTP/1.1 as |  | providers, and users of the security limitations in HTTP/1.1 as |
| skipping to change at page 63, line 40 |  | skipping to change at page 63, line 51 |
| some suggestions for reducing security risks. |  | some suggestions for reducing security risks. |
| 8.1. Personal Information |  | 8.1. Personal Information |
| HTTP clients are often privy to large amounts of personal information |  | HTTP clients are often privy to large amounts of personal information |
| (e.g., the user's name, location, mail address, passwords, encryption |  | (e.g., the user's name, location, mail address, passwords, encryption |
| keys, etc.), and SHOULD be very careful to prevent unintentional |  | keys, etc.), and SHOULD be very careful to prevent unintentional |
| leakage of this information. We very strongly recommend that a |  | leakage of this information. We very strongly recommend that a |
| convenient interface be provided for the user to control |  | convenient interface be provided for the user to control |
| dissemination of such information, and that designers and |  | dissemination of such information, and that designers and |
| implementors be particularly careful in this area. History shows |  | implementers be particularly careful in this area. History shows |
| that errors in this area often create serious security and/or privacy |  | that errors in this area often create serious security and/or privacy |
| problems and generate highly adverse publicity for the implementor's |  | problems and generate highly adverse publicity for the implementer's |
| company. |  | company. |
| 8.2. Abuse of Server Log Information |  | 8.2. Abuse of Server Log Information |
| A server is in the position to save personal data about a user's |  | A server is in the position to save personal data about a user's |
| requests which might identify their reading patterns or subjects of |  | requests which might identify their reading patterns or subjects of |
| interest. In particular, log information gathered at an intermediary |  | interest. In particular, log information gathered at an intermediary |
| often contains a history of user agent interaction, across a |  | often contains a history of user agent interaction, across a |
| multitude of sites, that can be traced to individual users. |  | multitude of sites, that can be traced to individual users. |
| skipping to change at page 65, line 15 |  | skipping to change at page 65, line 30 |
| 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 |
| range of potential attacks. |  | range of potential attacks. |
| Intermediaries that contain a shared cache are especially vulnerable |  | Intermediaries that contain a shared cache are especially vulnerable |
| to cache poisoning attacks. |  | to cache poisoning attacks. |
| Implementors 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. |
| The judicious use of cryptography, when appropriate, might suffice to |  | The judicious use of cryptography, when appropriate, might suffice to |
| protect against a broad range of security and privacy attacks. Such |  | protect against a broad range of security and privacy attacks. Such |
| cryptography is beyond the scope of the HTTP/1.1 specification. |  | cryptography is beyond the scope of the HTTP/1.1 specification. |
| skipping to change at page 65, line 42 |  | skipping to change at page 66, line 8 |
| 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.4.12 of |  | that have request-targets that are too long (Section 4.6.12 of |
| [Part2]) or request entities that are too large (Section 7.4 of |  | [Part2]) or request entities that are too large (Section 4.6 of |
| [Part2]). |  | [Part2]). |
| Other fields (including but not limited to request methods, response |  | Other fields (including but not limited to request methods, response |
| status phrases, header field-names, and body chunks) SHOULD be |  | status phrases, header field-names, and body chunks) SHOULD be |
| limited by implementations carefully, so as to not impede |  | limited by implementations carefully, so as to not impede |
| interoperability. |  | interoperability. |
| 9. Acknowledgments |  | 9. Acknowledgments |
| This edition of HTTP builds on the many contributions that went into |  | This edition of HTTP builds on the many contributions that went into |
| skipping to change at page 66, line 19 |  | skipping to change at page 66, line 31 |
| contributions made by the previous authors, editors, and working |  | contributions made by the previous authors, editors, and working |
| group chairs: Tim Berners-Lee, Ari Luotonen, Roy T. Fielding, Henrik |  | group chairs: Tim Berners-Lee, Ari Luotonen, Roy T. Fielding, Henrik |
| Frystyk Nielsen, Jim Gettys, Jeffrey C. Mogul, Larry Masinter, Paul |  | Frystyk Nielsen, Jim Gettys, Jeffrey C. Mogul, Larry Masinter, Paul |
| J. Leach, and Mark Nottingham. See Section 16 of [RFC2616] for |  | J. Leach, and Mark Nottingham. See Section 16 of [RFC2616] for |
| additional acknowledgements from prior revisions. |  | additional acknowledgements from prior revisions. |
| 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 de |  | Adam Barth, Adam Roach, Addison Phillips, Adrian Chadd, Adrien W. de |
| Croy, Alan Ford, Alan Ruttenberg, Albert Lunde, Alex Rousskov, Alexey |  | Croy, Alan Ford, Alan Ruttenberg, Albert Lunde, Alek Storm, Alex |
| Melnikov, Alisha Smith, Amichai Rothman, Amit Klein, Amos Jeffries, |  | Rousskov, Alexandre Morgaut, Alexey Melnikov, Alisha Smith, Amichai |
| Andreas Maier, Andreas Petersson, Anne van Kesteren, Anthony Bryan, |  | Rothman, Amit Klein, Amos Jeffries, Andreas Maier, Andreas Petersson, |
| Asbjorn Ulsberg, Balachander Krishnamurthy, Barry Leiba, Ben Laurie, |  | Anne van Kesteren, Anthony Bryan, Asbjorn Ulsberg, Balachander |
| Benjamin Niven-Jenkins, Bil Corry, Bill Burke, Bjoern Hoehrmann, Bob |  | Krishnamurthy, Barry Leiba, Ben Laurie, Benjamin Niven-Jenkins, Bil |
| Scheifler, Boris Zbarsky, Brett Slatkin, Brian Kell, Brian McBarron, |  | Corry, Bill Burke, Bjoern Hoehrmann, Bob Scheifler, Boris Zbarsky, |
| Brian Pane, Brian Smith, Bryce Nesbitt, Cameron Heavon-Jones, Carl |  | Brett Slatkin, Brian Kell, Brian McBarron, Brian Pane, Brian Smith, |
| Kugler, Carsten Bormann, Charles Fry, Chris Newman, Cyrus Daboo, Dale |  | Bryce Nesbitt, Cameron Heavon-Jones, Carl Kugler, Carsten Bormann, |
| Robert Anderson, Dan Winship, Daniel Stenberg, Dave Cridland, Dave |  | Charles Fry, Chris Newman, Cyrus Daboo, Dale Robert Anderson, Dan |
| Crocker, Dave Kristol, David Booth, David Singer, David W. Morris, |  | Winship, Daniel Stenberg, 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, Edward Lee, Eliot Lear, Eran |
| Bowman, Eric Lawrence, Eric Rescorla, Erik Aronesty, Florian Weimer, |  | Hammer-Lahav, Eric D. Williams, Eric J. Bowman, Eric Lawrence, Eric |
| Frank Ellermann, Fred Bohle, Geoffrey Sneddon, Gervase Markham, Greg |  | Rescorla, Erik Aronesty, Florian Weimer, Frank Ellermann, Fred Bohle, |
| Wilkins, Harald Tveit Alvestrand, Harry Halpin, Helge Hess, Henrik |  | Geoffrey Sneddon, Gervase Markham, Greg Wilkins, Harald Tveit |
| Nordstrom, Henry S. Thompson, Henry Story, Herbert van de Sompel, |  | Alvestrand, Harry Halpin, Helge Hess, Henrik Nordstrom, Henry S. |
| Howard Melman, Hugo Haas, Ian Hickson, Ingo Struck, J. Ross Nicoll, |  | Thompson, Henry Story, Herbert van de Sompel, Howard Melman, Hugo |
| James H. Manger, James Lacey, James M. Snell, Jamie Lokier, Jan |  | Haas, Ian Hickson, Ingo Struck, J. Ross Nicoll, James H. Manger, |
| Algermissen, Jeff Hodges (for coming up with the term 'effective |  | James Lacey, James M. Snell, Jamie Lokier, Jan Algermissen, Jeff |
| Request-URI'), Jeff Walden, Jim Luther, Joe D. Williams, Joe |  | Hodges (who came up with the term 'effective Request-URI'), Jeff |
| Gregorio, Joe Orton, John C. Klensin, John C. Mallery, John Cowan, |  | Walden, Jim Luther, Joe D. Williams, Joe Gregorio, Joe Orton, John C. |
| John Kemp, John Panzer, John Schneider, John Stracke, Jonas Sicking, |  | Klensin, John C. Mallery, John Cowan, John Kemp, John Panzer, John |
| Jonathan Billington, Jonathan Moore, Jonathan Rees, Jordi Ros, Joris |  | Schneider, John Stracke, John Sullivan, Jonas Sicking, Jonathan |
| Dobbelsteen, Josh Cohen, Julien Pierre, Jungshik Shin, Justin |  | Billington, Jonathan Moore, Jonathan Rees, Jonathan Silvera, Jordi |
| Chapweske, Justin Erenkrantz, Justin James, Kalvinder Singh, Karl |  | Ros, Joris Dobbelsteen, Josh Cohen, Julien Pierre, Jungshik Shin, |
| Dubost, Keith Hoffman, Keith Moore, Koen Holtman, Konstantin |  | Justin Chapweske, Justin Erenkrantz, Justin James, Kalvinder Singh, |
|  |  | Karl Dubost, Keith Hoffman, Keith Moore, Koen Holtman, Konstantin |
| Voronkov, Kris Zyp, Lisa Dusseault, Maciej Stachowiak, Marc |  | Voronkov, Kris Zyp, Lisa Dusseault, Maciej Stachowiak, Marc |
| Schneider, Marc Slemko, Mark Baker, Mark Pauley, Markus Lanthaler, |  | Schneider, Marc Slemko, Mark Baker, Mark Pauley, Mark Watson, Markus |
| Martin J. Duerst, Martin Thomson, Matt Lynch, Matthew Cox, Max Clark, |  | Isomaki, Markus Lanthaler, Martin J. Duerst, Martin Musatov, Martin |
| Michael Burrows, Michael Hausenblas, Mike Amundsen, Mike Belshe, Mike |  | Nilsson, Martin Thomson, Matt Lynch, Matthew Cox, Max Clark, Michael |
| Kelly, Mike Schinkel, Miles Sabin, Mykyta Yevstifeyev, Nathan Rixham, |  | Burrows, Michael Hausenblas, Mike Amundsen, Mike Belshe, Mike Kelly, |
| Nicholas Shanks, Nico Williams, Nicolas Alvarez, Nicolas Mailhot, |  | Mike Schinkel, Miles Sabin, Murray S. Kucherawy, Mykyta Yevstifeyev, |
| Noah Slater, Pablo Castro, Pat Hayes, Patrick R. McManus, Paul E. |  | Nathan Rixham, Nicholas Shanks, Nico Williams, Nicolas Alvarez, |
|  |  | Nicolas Mailhot, Noah Slater, Pablo Castro, Pat Hayes, Patrick R. |
| Jones, Paul Hoffman, Paul Marquess, Peter Saint-Andre, Peter Watkins, |  | McManus, Paul E. Jones, Paul Hoffman, Paul Marquess, Peter Lepeska, |
| Phil Archer, Phillip Hallam-Baker, Poul-Henning Kamp, Preethi |  | Peter Saint-Andre, Peter Watkins, Phil Archer, Phillip Hallam-Baker, |
| Natarajan, Ray Polk, Reto Bachmann-Gmuer, Richard Cyganiak, Robert |  | Poul-Henning Kamp, Preethi Natarajan, Ray Polk, Reto Bachmann-Gmuer, |
| Brewer, Robert Collins, Robert O'Callahan, Robert Olofsson, Robert |  | Richard Cyganiak, Robert Brewer, Robert Collins, Robert O'Callahan, |
| Sayre, Robert Siemer, Robert de Wilde, Roberto Javier Godoy, Ronny |  | Robert Olofsson, Robert Sayre, Robert Siemer, Robert de Wilde, |
| Widjaja, S. Mike Dierken, Salvatore Loreto, Sam Johnston, Sam Ruby, |  | Roberto Javier Godoy, Roberto Peon, Ronny Widjaja, S. Mike Dierken, |
| Scott Lawrence (for maintaining the original issues list), Sean B. |  | Salvatore Loreto, Sam Johnston, Sam Ruby, Scott Lawrence (who |
| Palmer, Shane McCarron, Stefan Eissing, Stefan Tilkov, Stefanos |  | maintained the original issues list), Sean B. Palmer, Shane McCarron, |
| Harhalakis, Stephane Bortzmeyer, Stephen Farrell, Stuart Williams, |  | Stefan Eissing, Stefan Tilkov, Stefanos Harhalakis, Stephane |
| Subbu Allamaraju, Sylvain Hellegouarch, Tapan Divekar, Ted Hardie, |  | Bortzmeyer, Stephen Farrell, Stephen Ludin, Stuart Williams, Subbu |
| Thomas Broyer, Thomas Nordin, Thomas Roessler, Tim Morgan, Tim Olsen, |  | Allamaraju, Sylvain Hellegouarch, Tapan Divekar, Tatsuya Hayashi, Ted |
| Travis Snoozy, Tyler Close, Vincent Murphy, Wenbo Zhu, Werner |  | Hardie, Thomas Broyer, Thomas Nordin, Thomas Roessler, Tim Bray, Tim |
| Baumann, Wilbur Streett, Wilfredo Sanchez Vega, William A. Rowe Jr., |  | Morgan, Tim Olsen, Tom Zhou, Travis Snoozy, Tyler Close, Vincent |
| William Chan, Willy Tarreau, Xiaoshu Wang, Yaron Goland, Yngve |  | Murphy, Wenbo Zhu, Werner Baumann, Wilbur Streett, Wilfredo Sanchez |
| Nysaeter Pettersen, Yogesh Bang, Yutaka Oiwa, Zed A. Shaw, and Zhong |  | Vega, William A. Rowe Jr., William Chan, Willy Tarreau, Xiaoshu Wang, |
| Yu. |  | Yaron Goland, Yngve Nysaeter Pettersen, Yoav Nir, Yogesh Bang, Yutaka |
|  |  | Oiwa, Zed A. Shaw, and Zhong Yu. |
| 10. References |  | 10. References |
| 10.1. Normative References |  | 10.1. Normative References |
| [ISO-8859-1] International Organization for Standardization, |  |  |
| "Information technology -- 8-bit single-byte coded |  |  |
| graphic character sets -- Part 1: Latin alphabet No. |  |  |
| 1", ISO/IEC 8859-1:1998, 1998. |  |  |
| [Part2] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |  | [Part2] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |
| "HTTP/1.1, part 2: Message Semantics", |  | "HTTP/1.1, part 2: Semantics and Payloads", |
| draft-ietf-httpbis-p2-semantics-19 (work in progress), |  | draft-ietf-httpbis-p2-semantics-20 (work in progress), |
| March 2012. |  | July 2012. |
| [Part3] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |  | [Part4] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |
| "HTTP/1.1, part 3: Message Payload and Content |  | "HTTP/1.1, part 4: Conditional Requests", |
| Negotiation", draft-ietf-httpbis-p3-payload-19 (work in |  | draft-ietf-httpbis-p4-conditional-20 (work in |
| progress), March 2012. |  | progress), July 2012. |
|  |  | [Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |
|  |  | "HTTP/1.1, part 5: Range Requests", |
|  |  | draft-ietf-httpbis-p5-range-20 (work in progress), |
|  |  | July 2012. |
| [Part6] Fielding, R., Ed., Lafon, Y., Ed., Nottingham, M., Ed., |  | [Part6] Fielding, R., Ed., Lafon, Y., Ed., Nottingham, M., Ed., |
| and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", |  | and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", |
| draft-ietf-httpbis-p6-cache-19 (work in progress), |  | draft-ietf-httpbis-p6-cache-20 (work in progress), |
| March 2012. |  | July 2012. |
|  |  | [Part7] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |
|  |  | "HTTP/1.1, part 7: Authentication", |
|  |  | draft-ietf-httpbis-p7-auth-20 (work in progress), |
|  |  | July 2012. |
| [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 68, line 24 |  | skipping to change at page 68, line 45 |
| [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 |
|  |  | [ISO-8859-1] International Organization for Standardization, |
|  |  | "Information technology -- 8-bit single-byte coded |
|  |  | graphic character sets -- Part 1: Latin alphabet No. |
|  |  | 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>. |
| [Nie1997] Frystyk, H., Gettys, J., Prud'hommeaux, E., Lie, H., |  | [Nie1997] Frystyk, H., Gettys, J., Prud'hommeaux, E., Lie, H., |
| and C. Lilley, "Network Performance Effects of |  | and C. Lilley, "Network Performance Effects of |
| HTTP/1.1, CSS1, and PNG", ACM Proceedings of the ACM |  | HTTP/1.1, CSS1, and PNG", ACM Proceedings of the ACM |
| SIGCOMM '97 conference on Applications, technologies, |  | SIGCOMM '97 conference on Applications, technologies, |
| architectures, and protocols for computer communication |  | architectures, and protocols for computer communication |
| SIGCOMM '97, September 1997, |  | SIGCOMM '97, September 1997, |
| <http://doi.acm.org/10.1145/263105.263157>. |  | <http://doi.acm.org/10.1145/263105.263157>. |
| skipping to change at page 72, line 5 |  | skipping to change at page 72, line 37 |
| 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 a HTTP/1.0 proxy |
| server doesn't understand Connection, it will erroneously forward |  | server doesn't understand Connection, it will erroneously forward |
| that header to the next inbound server, which would result in a hung |  | that header field to the next inbound server, which would result in a |
| connection. |  | hung connection. |
| One attempted solution was the introduction of a Proxy-Connection |  | One attempted solution was the introduction of a Proxy-Connection |
| header, targeted specifically at proxies. In practice, this was also |  | header field, targeted specifically at proxies. In practice, this |
| unworkable, because proxies are often deployed in multiple layers, |  | was also unworkable, because proxies are often deployed in multiple |
| 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 |
| header in any requests. |  | header field in any requests. |
| 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), and this mechanism ought |  | the client ought stop sending the header field), and this mechanism |
| 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 |
|  |  | HTTP/1.1 introduces the Transfer-Encoding header field |
|  |  | (Section 3.3.1). Proxies/gateways MUST remove any transfer-coding |
|  |  | prior to forwarding a message via 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 ABFN production is |  | Clarify that the string "HTTP" in the HTTP-version ABNF production is |
| case sensitive. Restrict the version numbers to be single digits due |  | case sensitive. Restrict the version numbers to be single digits due |
| to the fact that implementations are known to handle multi-digit |  | to the fact that implementations are known to handle multi-digit |
| version numbers incorrectly. (Section 2.6) |  | version numbers incorrectly. (Section 2.7) |
| Update use of abs_path production from RFC 1808 to the path-absolute |  | Update use of abs_path production from RFC 1808 to the path-absolute |
| + query components of RFC 3986. State that the asterisk form is |  | + query components of RFC 3986. State that the asterisk form is |
| allowed for the OPTIONS request method only. (Section 5.3) |  | allowed for the OPTIONS request method only. (Section 5.3) |
| Require that invalid whitespace around field-names be rejected. |  | Require that invalid whitespace around field-names be rejected. |
| (Section 3.2) |  | (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.1) |
| The NUL octet is no longer allowed in comment and quoted-string text. |  | 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. Non-ASCII content in header fields and reason |
| phrase has been obsoleted and made opaque (the TEXT rule was |  | phrase has been obsoleted and made opaque (the TEXT rule was |
| removed). (Section 3.2.4) |  | removed). (Section 3.2.4) |
| Empty list elements in list productions have been deprecated. |  | Empty list elements in list productions have been deprecated. |
| (Section 3.2.5) |  | (Appendix B) |
| Require recipients to handle bogus Content-Length header fields as |  | Require recipients to handle bogus Content-Length header fields as |
| errors. (Section 3.3) |  | errors. (Section 3.3) |
| Remove reference to non-existent identity transfer-coding value |  | Remove reference to non-existent identity transfer-coding value |
| tokens. (Sections 3.3 and 4) |  | tokens. (Sections 3.3 and 4) |
| Clarification that the chunk length does not include the count of the |  | Clarification that the chunk length does not include the count of the |
| octets in the chunk header and trailer. Furthermore disallowed line |  | octets in the chunk header and trailer. Furthermore disallowed line |
| folding in chunk extensions, and deprecate their use. (Section 4.1) |  | folding in chunk extensions, and deprecate their use. (Section 4.1) |
| Registration of Transfer Codings now requires IETF Review |  | Registration of Transfer Codings now requires IETF Review |
| (Section 7.4) |  | (Section 7.4) |
| Remove hard limit of two connections per server. Remove requirement |  | Remove hard limit of two connections per server. Remove requirement |
| to retry a sequence of requests as long it was idempotent. Remove |  | to retry a sequence of requests as long it was idempotent. Remove |
| requirements about when servers are allowed to close connections |  | requirements about when servers are allowed to close connections |
| prematurely. (Section 6.3.3) |  | prematurely. (Section 6.3.3) |
| Remove requirement to retry requests under certain cirumstances when |  | Remove requirement to retry requests under certain circumstances when |
| the server prematurely closes the connection. (Section 6.4) |  | the server prematurely closes the connection. (Section 6.4) |
| Change ABNF productions for header fields to only define the field |  | Change ABNF productions for header fields to only define the field |
| value. |  | value. |
| Clarify exactly when close connection options must be sent. |  | Clarify exactly when "close" connection options have to be sent. |
| (Section 6.1) |  | (Section 6.1) |
| Define the semantics of the "Upgrade" header field in responses other |  | Define the semantics of the Upgrade header field in responses other |
| than 101 (this was incorporated from [RFC2817]). (Section 6.5) |  | than 101 (this was incorporated from [RFC2817]). (Section 6.5) |
| A.3. Changes from RFC 2817 |  | Take over the Upgrade Token Registry, previously defined in Section |
|  |  | 7.2 of [RFC2817]. (Section 7.6) |
| Registration of Upgrade tokens now requires IETF Review (Section 7.6) |  | Appendix B. ABNF list extension: #rule |
| Appendix B. Collected ABNF |  | A #rule extension to the ABNF rules of [RFC5234] is used to improve |
|  |  | readability in the definitions of some header field values. |
|  |  | A construct "#" is defined, similar to "*", for defining comma- |
|  |  | delimited lists of elements. The full form is "<n>#<m>element" |
|  |  | indicating at least <n> and at most <m> elements, each separated by a |
|  |  | single comma (",") and optional whitespace (OWS). |
|  |  | Thus, |
|  |  | 1#element => element *( OWS "," OWS element ) |
|  |  | and: |
|  |  | #element => [ 1#element ] |
|  |  | and for n >= 1 and m > 1: |
|  |  | <n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element ) |
|  |  | For compatibility with legacy list rules, recipients SHOULD accept |
|  |  | empty list elements. In other words, consumers would follow the list |
|  |  | productions: |
|  |  | #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ] |
|  |  | 1#element => *( "," OWS ) element *( OWS "," [ OWS element ] ) |
|  |  | Note that empty elements do not contribute to the count of elements |
|  |  | present, though. |
|  |  | For example, given these ABNF productions: |
|  |  | example-list = 1#example-list-elmt |
|  |  | example-list-elmt = token ; see Section 3.2.4 |
|  |  | Then these are valid values for example-list (not including the |
|  |  | double quotes, which are present for delimitation only): |
|  |  | "foo,bar" |
|  |  | "foo ,bar," |
|  |  | "foo , ,bar,charlie " |
|  |  | But these values would be invalid, as at least one non-empty element |
|  |  | is required: |
|  |  | "" |
|  |  | "," |
|  |  | ", ," |
|  |  | Appendix C shows the collected ABNF, with the list rules expanded as |
|  |  | explained above. |
|  |  | Appendix C. Collected ABNF |
| BWS = OWS |  | BWS = OWS |
| Connection = *( "," OWS ) connection-token *( OWS "," [ OWS |  | Connection = *( "," OWS ) connection-option *( OWS "," [ OWS |
| connection-token ] ) |  | connection-option ] ) |
| Content-Length = 1*DIGIT |  | Content-Length = 1*DIGIT |
| HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body |  | HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body |
| ] |  | ] |
| HTTP-name = %x48.54.54.50 ; HTTP |  | HTTP-name = %x48.54.54.50 ; HTTP |
| HTTP-version = HTTP-name "/" DIGIT "." DIGIT |  | HTTP-version = HTTP-name "/" DIGIT "." DIGIT |
| Host = uri-host [ ":" port ] |  | Host = uri-host [ ":" port ] |
| OWS = *( SP / HTAB ) |  | OWS = *( SP / HTAB ) |
| skipping to change at page 74, line 4 |  | skipping to change at page 75, line 48 |
| HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body |  | HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body |
| ] |  | ] |
| HTTP-name = %x48.54.54.50 ; HTTP |  | HTTP-name = %x48.54.54.50 ; HTTP |
| HTTP-version = HTTP-name "/" DIGIT "." DIGIT |  | HTTP-version = HTTP-name "/" DIGIT "." DIGIT |
| Host = uri-host [ ":" port ] |  | Host = uri-host [ ":" port ] |
| OWS = *( SP / HTAB ) |  | OWS = *( SP / HTAB ) |
| RWS = 1*( SP / HTAB ) |  | RWS = 1*( SP / HTAB ) |
| TE = [ ( "," / t-codings ) *( OWS "," [ OWS t-codings ] ) ] |  | TE = [ ( "," / t-codings ) *( OWS "," [ OWS t-codings ] ) ] |
| Trailer = *( "," OWS ) field-name *( OWS "," [ OWS field-name ] ) |  | Trailer = *( "," OWS ) field-name *( OWS "," [ OWS field-name ] ) |
| Transfer-Encoding = *( "," OWS ) transfer-coding *( OWS "," [ OWS |  | Transfer-Encoding = *( "," OWS ) transfer-coding *( OWS "," [ OWS |
| transfer-coding ] ) |  | transfer-coding ] ) |
| 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 comment ] ] |  | ] ) *( OWS "," [ OWS ( received-protocol RWS received-by [ RWS |
| ) |  | 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 |
| 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-token = token |  | connection-option = token |
| ctext = OWS / %x21-27 ; '!'-''' |  | ctext = OWS / %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 |
| skipping to change at page 76, line 5 |  | skipping to change at page 78, line 4 |
| tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." / |  | tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." / |
| "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA |  | "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA |
| te-ext = OWS ";" OWS token [ "=" word ] |  | te-ext = OWS ";" OWS token [ "=" word ] |
| te-params = OWS ";" OWS "q=" qvalue *te-ext |  | te-params = OWS ";" OWS "q=" qvalue *te-ext |
| 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 |
| ABNF diagnostics: |  | Appendix D. Change Log (to be removed by RFC Editor before publication) |
| ; Connection defined but not used |  |  |
| ; Content-Length defined but not used |  |  |
| ; HTTP-message defined but not used |  |  |
| ; Host defined but not used |  |  |
| ; TE defined but not used |  |  |
| ; Trailer defined but not used |  |  |
| ; Transfer-Encoding defined but not used |  |  |
| ; URI-reference defined but not used |  |  |
| ; Upgrade defined but not used |  |  |
| ; Via defined but not used |  |  |
| ; chunked-body defined but not used |  |  |
| ; http-URI defined but not used |  |  |
| ; https-URI defined but not used |  |  |
| ; partial-URI defined but not used |  |  |
| ; special defined but not used |  |  |
| Appendix C. Change Log (to be removed by RFC Editor before publication) |  |  |
| C.1. Since RFC 2616 |  | D.1. Since RFC 2616 |
| Extracted relevant partitions from [RFC2616]. |  | Extracted relevant partitions from [RFC2616]. |
| C.2. Since draft-ietf-httpbis-p1-messaging-00 |  | D.2. Since draft-ietf-httpbis-p1-messaging-00 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/1>: "HTTP Version |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/1>: "HTTP Version |
| should be case sensitive" |  | should be case sensitive" |
| (<http://purl.org/NET/http-errata#verscase>) |  | (<http://purl.org/NET/http-errata#verscase>) |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/2>: "'unsafe' |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/2>: "'unsafe' |
| characters" (<http://purl.org/NET/http-errata#unsafe-uri>) |  | characters" (<http://purl.org/NET/http-errata#unsafe-uri>) |
| skipping to change at page 78, line 11 |  | skipping to change at page 79, line 39 |
| to-date references" |  | to-date references" |
| Other changes: |  | Other changes: |
| o Update media type registrations to use RFC4288 template. |  | o Update media type registrations to use RFC4288 template. |
| o Use names of RFC4234 core rules DQUOTE and HTAB, fix broken ABNF |  | o Use names of RFC4234 core rules DQUOTE and HTAB, fix broken ABNF |
| for chunk-data (work in progress on |  | for chunk-data (work in progress on |
| <http://tools.ietf.org/wg/httpbis/trac/ticket/36>) |  | <http://tools.ietf.org/wg/httpbis/trac/ticket/36>) |
| C.3. Since draft-ietf-httpbis-p1-messaging-01 |  | D.3. Since draft-ietf-httpbis-p1-messaging-01 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/19>: "Bodies on GET |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/19>: "Bodies on GET |
| (and other) requests" |  | (and other) requests" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/55>: "Updating to |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/55>: "Updating to |
| RFC4288" |  | RFC4288" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/57>: "Status Code |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/57>: "Status Code |
| skipping to change at page 79, line 8 |  | skipping to change at page 80, line 37 |
| o Move "Product Tokens" section (back) into Part 1, as "token" is |  | o Move "Product Tokens" section (back) into Part 1, as "token" is |
| used in the definition of the Upgrade header field. |  | used in the definition of the Upgrade header field. |
| o Add explicit references to BNF syntax and rules imported from |  | o Add explicit references to BNF syntax and rules imported from |
| other parts of the specification. |  | other parts of the specification. |
| o Rewrite prose rule "token" in terms of "tchar", rewrite prose rule |  | o Rewrite prose rule "token" in terms of "tchar", rewrite prose rule |
| "TEXT". |  | "TEXT". |
| C.4. Since draft-ietf-httpbis-p1-messaging-02 |  | D.4. Since draft-ietf-httpbis-p1-messaging-02 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/51>: "HTTP-date vs. |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/51>: "HTTP-date vs. |
| rfc1123-date" |  | rfc1123-date" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/64>: "WS in quoted- |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/64>: "WS in quoted- |
| pair" |  | pair" |
| Ongoing work on IANA Message Header Field Registration |  | Ongoing work on IANA Message Header Field Registration |
| (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>): |  | (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>): |
| o Reference RFC 3984, and update header field registrations for |  | o Reference RFC 3984, and update header field registrations for |
| headers defined in this document. |  | header fields defined in this document. |
| Ongoing work on ABNF conversion |  | Ongoing work on ABNF conversion |
| (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |  | (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |
| o Replace string literals when the string really is case-sensitive |  | o Replace string literals when the string really is case-sensitive |
| (HTTP-version). |  | (HTTP-version). |
| C.5. Since draft-ietf-httpbis-p1-messaging-03 |  | D.5. Since draft-ietf-httpbis-p1-messaging-03 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/28>: "Connection |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/28>: "Connection |
| closing" |  | closing" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/97>: "Move |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/97>: "Move |
| registrations and registry information to IANA Considerations" |  | registrations and registry information to IANA Considerations" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/120>: "need new URL |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/120>: "need new URL |
| for PAD1995 reference" |  | for PAD1995 reference" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/127>: "IANA |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/127>: "IANA |
| Considerations: update HTTP URI scheme registration" |  | 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" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/129>: "List-type |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/129>: "List-type |
| headers vs Set-Cookie" |  | header fields vs Set-Cookie" |
| Ongoing work on ABNF conversion |  | Ongoing work on ABNF conversion |
| (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |  | (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |
| o Replace string literals when the string really is case-sensitive |  | o Replace string literals when the string really is case-sensitive |
| (HTTP-Date). |  | (HTTP-Date). |
| o Replace HEX by HEXDIG for future consistence with RFC 5234's core |  | o Replace HEX by HEXDIG for future consistence with RFC 5234's core |
| rules. |  | rules. |
| C.6. Since draft-ietf-httpbis-p1-messaging-04 |  | D.6. Since draft-ietf-httpbis-p1-messaging-04 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/34>: "Out-of-date |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/34>: "Out-of-date |
| reference for URIs" |  | reference for URIs" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/132>: "RFC 2822 is |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/132>: "RFC 2822 is |
| updated by RFC 5322" |  | updated by RFC 5322" |
| Ongoing work on ABNF conversion |  | Ongoing work on ABNF conversion |
| skipping to change at page 80, line 37 |  | skipping to change at page 82, line 18 |
| o Get rid of RFC822 dependency; use RFC5234 plus extensions instead. |  | o Get rid of RFC822 dependency; use RFC5234 plus extensions instead. |
| o Only reference RFC 5234's core rules. |  | o Only reference RFC 5234's core rules. |
| o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional |  | o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional |
| whitespace ("OWS") and required whitespace ("RWS"). |  | whitespace ("OWS") and required whitespace ("RWS"). |
| o Rewrite ABNFs to spell out whitespace rules, factor out header |  | o Rewrite ABNFs to spell out whitespace rules, factor out header |
| field value format definitions. |  | field value format definitions. |
| C.7. Since draft-ietf-httpbis-p1-messaging-05 |  | D.7. Since draft-ietf-httpbis-p1-messaging-05 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/30>: "Header LWS" |  | 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 |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/52>: "Sort 1.3 |
| Terminology" |  | Terminology" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/63>: "RFC2047 |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/63>: "RFC2047 |
| encoded words" |  | encoded words" |
| skipping to change at page 81, line 36 |  | skipping to change at page 83, line 17 |
| o Add appendix containing collected and expanded ABNF. |  | o Add appendix containing collected and expanded ABNF. |
| Other changes: |  | Other changes: |
| o Rewrite introduction; add mostly new Architecture Section. |  | o Rewrite introduction; add mostly new Architecture Section. |
| o Move definition of quality values from Part 3 into Part 1; make TE |  | o Move definition of quality values from Part 3 into Part 1; make TE |
| request header field grammar independent of accept-params (defined |  | request header field grammar independent of accept-params (defined |
| in Part 3). |  | in Part 3). |
| C.8. Since draft-ietf-httpbis-p1-messaging-06 |  | D.8. Since draft-ietf-httpbis-p1-messaging-06 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/161>: "base for |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/161>: "base for |
| numeric protocol elements" |  | numeric protocol elements" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/162>: "comment ABNF" |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/162>: "comment ABNF" |
| Partly resolved issues: |  | Partly resolved issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/88>: "205 Bodies" |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/88>: "205 Bodies" |
| (took out language that implied that there might be methods for |  | (took out language that implied that there might be methods for |
| which a request body MUST NOT be included) |  | which a request body MUST NOT be included) |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/163>: "editorial |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/163>: "editorial |
| improvements around HTTP-date" |  | improvements around HTTP-date" |
| C.9. Since draft-ietf-httpbis-p1-messaging-07 |  | D.9. Since draft-ietf-httpbis-p1-messaging-07 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/93>: "Repeating |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/93>: "Repeating |
| single-value headers" |  | single-value header fields" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/131>: "increase |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/131>: "increase |
| connection limit" |  | connection limit" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/157>: "IP addresses |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/157>: "IP addresses |
| in URLs" |  | in URLs" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/172>: "take over |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/172>: "take over |
| HTTP Upgrade Token Registry" |  | HTTP Upgrade Token Registry" |
| skipping to change at page 82, line 42 |  | skipping to change at page 84, line 23 |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/194>: "disallow |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/194>: "disallow |
| control characters in quoted-pair" |  | control characters in quoted-pair" |
| Partly resolved issues: |  | Partly resolved issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/148>: "update IANA |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/148>: "update IANA |
| requirements wrt Transfer-Coding values" (add the IANA |  | requirements wrt Transfer-Coding values" (add the IANA |
| Considerations subsection) |  | Considerations subsection) |
| C.10. Since draft-ietf-httpbis-p1-messaging-08 |  | D.10. Since draft-ietf-httpbis-p1-messaging-08 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/201>: "header |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/201>: "header |
| parsing, treatment of leading and trailing OWS" |  | parsing, treatment of leading and trailing OWS" |
| Partly resolved issues: |  | Partly resolved issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/60>: "Placement of |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/60>: "Placement of |
| 13.5.1 and 13.5.2" |  | 13.5.1 and 13.5.2" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/200>: "use of term |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/200>: "use of term |
| "word" when talking about header structure" |  | "word" when talking about header field structure" |
| C.11. Since draft-ietf-httpbis-p1-messaging-09 |  | D.11. Since draft-ietf-httpbis-p1-messaging-09 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/73>: "Clarification |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/73>: "Clarification |
| of the term 'deflate'" |  | of the term 'deflate'" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/83>: "OPTIONS * and |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/83>: "OPTIONS * and |
| proxies" |  | proxies" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/122>: "MIME-Version |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/122>: "MIME-Version |
| not listed in P1, general header fields" |  | not listed in P1, general header fields" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/143>: "IANA registry |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/143>: "IANA registry |
| for content/transfer encodings" |  | for content/transfer encodings" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/165>: "Case- |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/165>: "Case- |
| sensitivity of HTTP-date" |  | sensitivity of HTTP-date" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/200>: "use of term |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/200>: "use of term |
| "word" when talking about header structure" |  | "word" when talking about header field structure" |
| Partly resolved issues: |  | Partly resolved issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/196>: "Term for the |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/196>: "Term for the |
| requested resource's URI" |  | requested resource's URI" |
| C.12. Since draft-ietf-httpbis-p1-messaging-10 |  | D.12. Since draft-ietf-httpbis-p1-messaging-10 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/28>: "Connection |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/28>: "Connection |
| Closing" |  | Closing" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/90>: "Delimiting |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/90>: "Delimiting |
| messages with multipart/byteranges" |  | messages with multipart/byteranges" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/95>: "Handling |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/95>: "Handling |
| multiple Content-Length headers" |  | multiple Content-Length header fields" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/109>: "Clarify |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/109>: "Clarify |
| entity / representation / variant terminology" |  | entity / representation / variant terminology" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider |
| removing the 'changes from 2068' sections" |  | removing the 'changes from 2068' sections" |
| Partly resolved issues: |  | Partly resolved issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/159>: "HTTP(s) URI |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/159>: "HTTP(s) URI |
| scheme definitions" |  | scheme definitions" |
| C.13. Since draft-ietf-httpbis-p1-messaging-11 |  | D.13. Since draft-ietf-httpbis-p1-messaging-11 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/193>: "Trailer |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/193>: "Trailer |
| requirements" |  | requirements" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/204>: "Text about |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/204>: "Text about |
| clock requirement for caches belongs in p6" |  | clock requirement for caches belongs in p6" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/221>: "effective |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/221>: "effective |
| request URI: handling of missing host in HTTP/1.0" |  | request URI: handling of missing host in HTTP/1.0" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/248>: "confusing |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/248>: "confusing |
| Date requirements for clients" |  | Date requirements for clients" |
| Partly resolved issues: |  | Partly resolved issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/95>: "Handling |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/95>: "Handling |
| multiple Content-Length headers" |  | multiple Content-Length header fields" |
| C.14. Since draft-ietf-httpbis-p1-messaging-12 |  | D.14. Since draft-ietf-httpbis-p1-messaging-12 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/75>: "RFC2145 |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/75>: "RFC2145 |
| Normative" |  | Normative" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/159>: "HTTP(s) URI |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/159>: "HTTP(s) URI |
| scheme definitions" (tune the requirements on userinfo) |  | scheme definitions" (tune the requirements on userinfo) |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/210>: "define |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/210>: "define |
| 'transparent' proxy" |  | 'transparent' proxy" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/224>: "Header |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/224>: "Header Field |
| Classification" |  | Classification" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/233>: "Is * usable |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/233>: "Is * usable |
| as a request-uri for new methods?" |  | as a request-uri for new methods?" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/240>: "Migrate |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/240>: "Migrate |
| Upgrade details from RFC2817" |  | Upgrade details from RFC2817" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle |
| ABNFs for header fields" |  | ABNFs for header fields" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/279>: "update RFC |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/279>: "update RFC |
| 2109 reference" |  | 2109 reference" |
| C.15. Since draft-ietf-httpbis-p1-messaging-13 |  | D.15. Since draft-ietf-httpbis-p1-messaging-13 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/53>: "Allow is not |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/53>: "Allow is not |
| in 13.5.2" |  | in 13.5.2" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/95>: "Handling |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/95>: "Handling |
| multiple Content-Length headers" |  | multiple Content-Length header fields" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle |
| ABNFs for header fields" |  | ABNFs for header fields" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/286>: "Content- |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/286>: "Content- |
| Length ABNF broken" |  | Length ABNF broken" |
| C.16. Since draft-ietf-httpbis-p1-messaging-14 |  | D.16. Since draft-ietf-httpbis-p1-messaging-14 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/273>: "HTTP-version |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/273>: "HTTP-version |
| should be redefined as fixed length pair of DIGIT . DIGIT" |  | should be redefined as fixed length pair of DIGIT . DIGIT" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/282>: "Recommend |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/282>: "Recommend |
| minimum sizes for protocol elements" |  | minimum sizes for protocol elements" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/283>: "Set |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/283>: "Set |
| expectations around buffering" |  | expectations around buffering" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/288>: "Considering |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/288>: "Considering |
| messages in isolation" |  | messages in isolation" |
| C.17. Since draft-ietf-httpbis-p1-messaging-15 |  | D.17. Since draft-ietf-httpbis-p1-messaging-15 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/100>: "DNS Spoofing |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/100>: "DNS Spoofing |
| / DNS Binding advice" |  | / DNS Binding advice" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/254>: "move RFCs |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/254>: "move RFCs |
| 2145, 2616, 2817 to Historic status" |  | 2145, 2616, 2817 to Historic status" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/270>: "\-escaping in |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/270>: "\-escaping in |
| quoted strings" |  | quoted strings" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/305>: "'Close' |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/305>: "'Close' |
| should be reserved in the HTTP header field registry" |  | should be reserved in the HTTP header field registry" |
| C.18. Since draft-ietf-httpbis-p1-messaging-16 |  | D.18. Since draft-ietf-httpbis-p1-messaging-16 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/186>: "Document |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/186>: "Document |
| HTTP's error-handling philosophy" |  | HTTP's error-handling philosophy" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/215>: "Explain |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/215>: "Explain |
| header registration" |  | header field registration" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/219>: "Revise |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/219>: "Revise |
| Acknowledgements Sections" |  | Acknowledgements Sections" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/297>: "Retrying |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/297>: "Retrying |
| Requests" |  | Requests" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/318>: "Closing the |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/318>: "Closing the |
| connection on server error" |  | connection on server error" |
| C.19. Since draft-ietf-httpbis-p1-messaging-17 |  | D.19. Since draft-ietf-httpbis-p1-messaging-17 |
| Closed issues: |  | 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 |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/166>: "Clarify 'User |
| Agent'" |  | Agent'" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/300>: "Define non- |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/300>: "Define non- |
| final responses" |  | final responses" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/323>: "intended |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/323>: "intended |
| maturity level vs normative references" |  | maturity level vs normative references" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/324>: "Intermediary |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/324>: "Intermediary |
| rewriting of queries" |  | rewriting of queries" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/158>: "Proxy- |  | D.20. Since draft-ietf-httpbis-p1-messaging-18 |
| Connection and Keep-Alive" |  |  |
| C.20. Since draft-ietf-httpbis-p1-messaging-18 |  |  |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/250>: "message-body |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/250>: "message-body |
| in CONNECT response" |  | in CONNECT response" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/302>: "Misplaced |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/302>: "Misplaced |
| text on connection handling in p2" |  | text on connection handling in p2" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/335>: "wording of |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/335>: "wording of |
| line folding rule" |  | line folding rule" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/343>: "chunk- |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/343>: "chunk- |
| extensions" |  | extensions" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/346>: "make IANA |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/346>: "make IANA |
| policy definitions consistent" |  | policy definitions consistent" |
|  |  | D.21. Since draft-ietf-httpbis-p1-messaging-19 |
|  |  | Closed issues: |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/346>: "make IANA |
|  |  | policy definitions consistent" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/359>: "clarify |
|  |  | connection header field values are case-insensitive" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/361>: "ABNF |
|  |  | requirements for recipients" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/368>: "note |
|  |  | introduction of new IANA registries as normative changes" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/374>: "Reference to |
|  |  | ISO-8859-1 is informative" |
| Index |  | Index |
| A |  | A |
| absolute-form (of request-target) 41 |  | absolute-form (of request-target) 41 |
| accelerator 11 |  | accelerator 11 |
| application/http Media Type 60 |  | application/http Media Type 60 |
| asterisk-form (of request-target) 41 |  | asterisk-form (of request-target) 41 |
| authority-form (of request-target) 41 |  | authority-form (of request-target) 41 |
| B |  | B |
| browser 7 |  | browser 8 |
| C |  | C |
| cache 12 |  | cache 13 |
| cacheable 12 |  | cacheable 13 |
| captive portal 11 |  | captive portal 12 |
| chunked (Coding Format) 34 |  | chunked (Coding Format) 34 |
| client 7 |  | client 7 |
| Coding Format |  | Coding Format |
| chunked 34 |  | chunked 34 |
| compress 36 |  | compress 36 |
| deflate 36 |  | deflate 36 |
| gzip 36 |  | gzip 36 |
| compress (Coding Format) 36 |  | compress (Coding Format) 36 |
| connection 7 |  | connection 7 |
| Connection header field 47 |  | Connection header field 47 |
| Content-Length header field 29 |  | Content-Length header field 29 |
| D |  | D |
| deflate (Coding Format) 36 |  | deflate (Coding Format) 36 |
| downstream 10 |  | downstream 11 |
| E |  | E |
| effective request URI 43 |  | effective request URI 43 |
| G |  | G |
| gateway 11 |  | gateway 11 |
| Grammar |  | Grammar |
| absolute-form 40 |  | absolute-form 40 |
| absolute-URI 16 |  | absolute-URI 17 |
| ALPHA 7 |  | ALPHA 7 |
| asterisk-form 40 |  | asterisk-form 40 |
| attribute 34 |  | attribute 34 |
| authority 16 |  | authority 17 |
| authority-form 40 |  | authority-form 40 |
| BWS 23 |  | BWS 24 |
| chunk 34 |  | chunk 34 |
| chunk-data 34 |  | chunk-data 34 |
| chunk-ext 34 |  | chunk-ext 34 |
| chunk-ext-name 34 |  | chunk-ext-name 34 |
| chunk-ext-val 34 |  | chunk-ext-val 34 |
| chunk-size 34 |  | chunk-size 34 |
| chunked-body 34 |  | chunked-body 34 |
| comment 25 |  | comment 27 |
| Connection 47 |  | Connection 47 |
| connection-token 47 |  | connection-option 47 |
| Content-Length 29 |  | Content-Length 29 |
| CR 7 |  | CR 7 |
| CRLF 7 |  | CRLF 7 |
| ctext 25 |  | ctext 27 |
| CTL 7 |  | CTL 7 |
| date2 34 |  | date2 34 |
| date3 34 |  | date3 34 |
| DIGIT 7 |  | DIGIT 7 |
| DQUOTE 7 |  | DQUOTE 7 |
| field-content 22 |  | field-content 23 |
| field-name 22 |  | field-name 23 |
| field-value 22 |  | field-value 23 |
| header-field 22 |  | header-field 23 |
| HEXDIG 7 |  | HEXDIG 7 |
| Host 42 |  | Host 42 |
| HTAB 7 |  | HTAB 7 |
| HTTP-message 19 |  | HTTP-message 20 |
| HTTP-name 13 |  | HTTP-name 14 |
| http-URI 16 |  | http-URI 17 |
| HTTP-version 13 |  | HTTP-version 14 |
| https-URI 18 |  | https-URI 19 |
| last-chunk 34 |  | last-chunk 34 |
| LF 7 |  | LF 7 |
| message-body 27 |  | message-body 27 |
| method 20 |  | method 21 |
| obs-fold 22 |  | obs-fold 23 |
| obs-text 25 |  | obs-text 26 |
| OCTET 7 |  | OCTET 7 |
| origin-form 40 |  | origin-form 40 |
| OWS 23 |  | OWS 24 |
| path-absolute 16 |  | partial-URI 17 |
| port 16 |  | path-absolute 17 |
|  |  | port 17 |
| protocol-name 49 |  | protocol-name 49 |
| protocol-version 49 |  | protocol-version 49 |
| pseudonym 49 |  | pseudonym 49 |
| qdtext 25 |  | qdtext 26 |
| qdtext-nf 34 |  | qdtext-nf 34 |
| query 16 |  | query 17 |
| quoted-cpair 26 |  | quoted-cpair 27 |
| quoted-pair 25 |  | quoted-pair 26 |
| quoted-str-nf 34 |  | quoted-str-nf 34 |
| quoted-string 25 |  | quoted-string 26 |
| qvalue 38 |  | qvalue 38 |
| reason-phrase 21 |  | reason-phrase 22 |
| received-by 49 |  | received-by 49 |
| received-protocol 49 |  | received-protocol 49 |
| request-line 20 |  | request-line 21 |
| request-target 40 |  | request-target 40 |
| RWS 23 |  | RWS 24 |
| SP 7 |  | SP 7 |
| special 25 |  | special 26 |
| start-line 20 |  | start-line 21 |
| status-code 21 |  | status-code 22 |
| status-line 21 |  | status-line 22 |
| t-codings 37 |  | t-codings 37 |
| tchar 25 |  | tchar 26 |
| TE 37 |  | TE 37 |
| te-ext 37 |  | te-ext 37 |
| te-params 37 |  | te-params 37 |
| token 25 |  | token 26 |
| Trailer 38 |  | Trailer 38 |
| trailer-part 34 |  | trailer-part 34 |
| transfer-coding 34 |  | transfer-coding 34 |
| Transfer-Encoding 28 |  | Transfer-Encoding 28 |
| transfer-extension 34 |  | transfer-extension 34 |
| transfer-parameter 34 |  | transfer-parameter 34 |
| Upgrade 56 |  | Upgrade 57 |
| uri-host 16 |  | uri-host 17 |
| URI-reference 16 |  | URI-reference 17 |
| value 34 |  | value 34 |
| VCHAR 7 |  | VCHAR 7 |
| Via 49 |  | Via 49 |
| word 25 |  | word 26 |
| gzip (Coding Format) 36 |  | gzip (Coding Format) 36 |
| H |  | H |
| header field 19 |  | header field 20 |
| Header Fields |  | Header Fields |
| Connection 47 |  | Connection 47 |
| Content-Length 29 |  | Content-Length 29 |
| Host 42 |  | Host 42 |
| TE 36 |  | TE 36 |
| Trailer 38 |  | Trailer 38 |
| Transfer-Encoding 27 |  | Transfer-Encoding 27 |
| Upgrade 56 |  | Upgrade 56 |
| Via 49 |  | Via 49 |
| header section 19 |  | header section 20 |
| headers 19 |  | headers 20 |
| Host header field 42 |  | Host header field 42 |
| http URI scheme 16 |  | http URI scheme 17 |
| https URI scheme 17 |  | https URI scheme 18 |
| I |  | I |
| inbound 10 |  | inbound 11 |
| interception proxy 11 |  | interception proxy 12 |
| intermediary 9 |  | intermediary 10 |
| M |  | M |
| Media Type |  | Media Type |
| application/http 60 |  | application/http 60 |
| message/http 59 |  | message/http 59 |
| message 8 |  | message 8 |
| message/http Media Type 59 |  | message/http Media Type 59 |
| method 20 |  | method 21 |
| N |  | N |
| non-transforming proxy 10 |  | non-transforming proxy 11 |
| O |  | O |
| origin server 7 |  | origin server 8 |
| origin-form (of request-target) 40 |  | origin-form (of request-target) 40 |
| outbound 10 |  | outbound 11 |
| P |  | P |
| proxy 10 |  | proxy 11 |
| R |  | R |
| recipient 7 |  | recipient 8 |
| request 8 |  | request 8 |
| request-target 20 |  | request-target 21 |
| resource 15 |  | resource 16 |
| response 8 |  | response 8 |
| reverse proxy 11 |  | reverse proxy 11 |
| S |  | S |
| sender 7 |  | sender 8 |
| server 7 |  | server 7 |
| spider 7 |  | spider 8 |
| T |  | T |
| target resource 39 |  | target resource 39 |
| target URI 39 |  | target URI 39 |
| TE header field 36 |  | TE header field 36 |
| Trailer header field 38 |  | Trailer header field 38 |
| Transfer-Encoding header field 27 |  | Transfer-Encoding header field 27 |
| transforming proxy 10 |  | transforming proxy 11 |
| transparent proxy 11 |  | transparent proxy 12 |
| tunnel 11 |  | tunnel 12 |
| U |  | U |
| Upgrade header field 56 |  | Upgrade header field 56 |
| upstream 10 |  | upstream 11 |
| URI scheme |  | URI scheme |
| http 16 |  | http 17 |
| https 17 |  | https 18 |
| user agent 7 |  | user agent 8 |
| V |  | V |
| Via header field 49 |  | Via header field 49 |
| 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 |
| skipping to change at page 92, line 20 |  | skipping to change at page 94, line 20 |
| EMail: ylafon@w3.org |  | EMail: ylafon@w3.org |
| URI: http://www.raubacapeu.net/people/yves/ |  | URI: http://www.raubacapeu.net/people/yves/ |
| Julian F. Reschke (editor) |  | Julian F. Reschke (editor) |
| greenbytes GmbH |  | greenbytes GmbH |
| Hafenweg 16 |  | Hafenweg 16 |
| Muenster, NW 48155 |  | Muenster, NW 48155 |
| Germany |  | Germany |
| Phone: +49 251 2807760 |  |  |
| Fax: +49 251 2807761 |  |  |
| EMail: julian.reschke@greenbytes.de |  | EMail: julian.reschke@greenbytes.de |
| URI: http://greenbytes.de/tech/webdav/ |  | URI: http://greenbytes.de/tech/webdav/ |
End of changes. 219 change blocks.
| 562 lines changed or deleted |  | 643 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/