| draft-ietf-httpbis-p1-messaging-23.txt |  | draft-ietf-httpbis-p1-messaging-24.txt |
--- | --- | --- | --- | ---
| HTTPbis Working Group R. Fielding, Ed. |  | HTTPbis Working Group R. Fielding, Ed. |
| Internet-Draft Adobe |  | Internet-Draft Adobe |
| Obsoletes: 2145,2616 (if approved) J. Reschke, Ed. |  | Obsoletes: 2145,2616 (if approved) J. Reschke, Ed. |
| Updates: 2817,2818 (if approved) greenbytes |  | Updates: 2817,2818 (if approved) greenbytes |
| Intended status: Standards Track July 15, 2013 |  | Intended status: Standards Track September 25, 2013 |
| Expires: January 16, 2014 |  | Expires: March 29, 2014 |
| Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing |  | Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing |
| draft-ietf-httpbis-p1-messaging-23 |  | draft-ietf-httpbis-p1-messaging-24 |
| Abstract |  | Abstract |
| The Hypertext Transfer Protocol (HTTP) is an application-level |  | The Hypertext Transfer Protocol (HTTP) is an application-level |
| protocol for distributed, collaborative, hypertext information |  | protocol for distributed, collaborative, hypertext information |
| systems. HTTP has been in use by the World Wide Web global |  | systems. HTTP has been in use by the World Wide Web global |
| information initiative since 1990. This document provides an |  | information initiative since 1990. This document provides an |
| overview of HTTP architecture and its associated terminology, defines |  | overview of HTTP architecture and its associated terminology, defines |
| the "http" and "https" Uniform Resource Identifier (URI) schemes, |  | the "http" and "https" Uniform Resource Identifier (URI) schemes, |
| defines the HTTP/1.1 message syntax and parsing requirements, and |  | defines the HTTP/1.1 message syntax and parsing requirements, and |
| skipping to change at page 1, line 35 |  | skipping to change at page 1, line 35 |
| Discussion of this draft takes place on the HTTPBIS working group |  | Discussion of this draft takes place on the HTTPBIS working group |
| mailing list (ietf-http-wg@w3.org), which is archived at |  | mailing list (ietf-http-wg@w3.org), which is archived at |
| <http://lists.w3.org/Archives/Public/ietf-http-wg/>. |  | <http://lists.w3.org/Archives/Public/ietf-http-wg/>. |
| The current issues list is at |  | The current issues list is at |
| <http://tools.ietf.org/wg/httpbis/trac/report/3> and related |  | <http://tools.ietf.org/wg/httpbis/trac/report/3> and related |
| documents (including fancy diffs) can be found at |  | documents (including fancy diffs) can be found at |
| <http://tools.ietf.org/wg/httpbis/>. |  | <http://tools.ietf.org/wg/httpbis/>. |
| The changes in this draft are summarized in Appendix D.3. |  | The changes in this draft are summarized in Appendix C.4. |
| 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 January 16, 2014. |  | This Internet-Draft will expire on March 29, 2014. |
| Copyright Notice |  | Copyright Notice |
| Copyright (c) 2013 IETF Trust and the persons identified as the |  | Copyright (c) 2013 IETF Trust and the persons identified as the |
| document authors. All rights reserved. |  | document authors. All rights reserved. |
| This document is subject to BCP 78 and the IETF Trust's Legal |  | This document is subject to BCP 78 and the IETF Trust's Legal |
| Provisions Relating to IETF Documents |  | Provisions Relating to IETF Documents |
| (http://trustee.ietf.org/license-info) in effect on the date of |  | (http://trustee.ietf.org/license-info) in effect on the date of |
| publication of this document. Please review these documents |  | publication of this document. Please review these documents |
| skipping to change at page 2, line 46 |  | skipping to change at page 2, line 46 |
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 |  | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 |
| 1.1. Requirement Notation . . . . . . . . . . . . . . . . . . . 6 |  | 1.1. Requirement Notation . . . . . . . . . . . . . . . . . . . 6 |
| 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 |  | 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 |
| 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 6 |  | 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 6 |
| 2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 7 |  | 2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 7 |
| 2.2. Implementation Diversity . . . . . . . . . . . . . . . . . 8 |  | 2.2. Implementation Diversity . . . . . . . . . . . . . . . . . 8 |
| 2.3. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 9 |  | 2.3. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 9 |
| 2.4. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 11 |  | 2.4. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 11 |
| 2.5. Conformance and Error Handling . . . . . . . . . . . . . . 12 |  | 2.5. Conformance and Error Handling . . . . . . . . . . . . . . 12 |
| 2.6. Protocol Versioning . . . . . . . . . . . . . . . . . . . 13 |  | 2.6. Protocol Versioning . . . . . . . . . . . . . . . . . . . 14 |
| 2.7. Uniform Resource Identifiers . . . . . . . . . . . . . . . 15 |  | 2.7. Uniform Resource Identifiers . . . . . . . . . . . . . . . 16 |
| 2.7.1. http URI scheme . . . . . . . . . . . . . . . . . . . 16 |  | 2.7.1. http URI scheme . . . . . . . . . . . . . . . . . . . 17 |
| 2.7.2. https URI scheme . . . . . . . . . . . . . . . . . . . 17 |  | 2.7.2. https URI scheme . . . . . . . . . . . . . . . . . . . 18 |
| 2.7.3. http and https URI Normalization and Comparison . . . 18 |  | 2.7.3. http and https URI Normalization and Comparison . . . 19 |
| 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 19 |  | 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 19 |
| 3.1. Start Line . . . . . . . . . . . . . . . . . . . . . . . . 20 |  | 3.1. Start Line . . . . . . . . . . . . . . . . . . . . . . . . 20 |
| 3.1.1. Request Line . . . . . . . . . . . . . . . . . . . . . 20 |  | 3.1.1. Request Line . . . . . . . . . . . . . . . . . . . . . 21 |
| 3.1.2. Status Line . . . . . . . . . . . . . . . . . . . . . 21 |  | 3.1.2. Status Line . . . . . . . . . . . . . . . . . . . . . 22 |
| 3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 22 |  | 3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 22 |
| 3.2.1. Field Extensibility . . . . . . . . . . . . . . . . . 22 |  | 3.2.1. Field Extensibility . . . . . . . . . . . . . . . . . 23 |
| 3.2.2. Field Order . . . . . . . . . . . . . . . . . . . . . 22 |  | 3.2.2. Field Order . . . . . . . . . . . . . . . . . . . . . 23 |
| 3.2.3. Whitespace . . . . . . . . . . . . . . . . . . . . . . 23 |  | 3.2.3. Whitespace . . . . . . . . . . . . . . . . . . . . . . 24 |
| 3.2.4. Field Parsing . . . . . . . . . . . . . . . . . . . . 24 |  | 3.2.4. Field Parsing . . . . . . . . . . . . . . . . . . . . 24 |
| 3.2.5. Field Limits . . . . . . . . . . . . . . . . . . . . . 25 |  | 3.2.5. Field Limits . . . . . . . . . . . . . . . . . . . . . 26 |
| 3.2.6. Field value components . . . . . . . . . . . . . . . . 25 |  | 3.2.6. 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 . . . . . . . . . . . . . . . . . . 28 |
| 3.3.2. Content-Length . . . . . . . . . . . . . . . . . . . . 29 |  | 3.3.2. Content-Length . . . . . . . . . . . . . . . . . . . . 30 |
| 3.3.3. Message Body Length . . . . . . . . . . . . . . . . . 30 |  | 3.3.3. Message Body Length . . . . . . . . . . . . . . . . . 31 |
| 3.4. Handling Incomplete Messages . . . . . . . . . . . . . . . 32 |  | 3.4. Handling Incomplete Messages . . . . . . . . . . . . . . . 33 |
| 3.5. Message Parsing Robustness . . . . . . . . . . . . . . . . 33 |  | 3.5. Message Parsing Robustness . . . . . . . . . . . . . . . . 34 |
| 4. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . . 34 |  | 4. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . . 35 |
| 4.1. Chunked Transfer Coding . . . . . . . . . . . . . . . . . 34 |  | 4.1. Chunked Transfer Coding . . . . . . . . . . . . . . . . . 35 |
| 4.1.1. Trailer . . . . . . . . . . . . . . . . . . . . . . . 35 |  | 4.1.1. Chunk Extensions . . . . . . . . . . . . . . . . . . . 36 |
| 4.1.2. Decoding chunked . . . . . . . . . . . . . . . . . . . 36 |  | 4.1.2. Chunked Trailer Part . . . . . . . . . . . . . . . . . 36 |
| 4.2. Compression Codings . . . . . . . . . . . . . . . . . . . 37 |  | 4.1.3. Decoding Chunked . . . . . . . . . . . . . . . . . . . 37 |
| 4.2.1. Compress Coding . . . . . . . . . . . . . . . . . . . 37 |  | 4.2. Compression Codings . . . . . . . . . . . . . . . . . . . 38 |
| 4.2.2. Deflate Coding . . . . . . . . . . . . . . . . . . . . 37 |  | 4.2.1. Compress Coding . . . . . . . . . . . . . . . . . . . 38 |
| 4.2.3. Gzip Coding . . . . . . . . . . . . . . . . . . . . . 37 |  | 4.2.2. Deflate Coding . . . . . . . . . . . . . . . . . . . . 38 |
| 4.3. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 |  | 4.2.3. Gzip Coding . . . . . . . . . . . . . . . . . . . . . 38 |
| 5. Message Routing . . . . . . . . . . . . . . . . . . . . . . . 38 |  | 4.3. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 |
| 5.1. Identifying a Target Resource . . . . . . . . . . . . . . 38 |  | 4.4. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 40 |
| 5.2. Connecting Inbound . . . . . . . . . . . . . . . . . . . . 39 |  | 5. Message Routing . . . . . . . . . . . . . . . . . . . . . . . 40 |
| 5.3. Request Target . . . . . . . . . . . . . . . . . . . . . . 39 |  | 5.1. Identifying a Target Resource . . . . . . . . . . . . . . 40 |
| 5.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 |  | 5.2. Connecting Inbound . . . . . . . . . . . . . . . . . . . . 40 |
| 5.5. Effective Request URI . . . . . . . . . . . . . . . . . . 43 |  | 5.3. Request Target . . . . . . . . . . . . . . . . . . . . . . 41 |
| 5.6. Associating a Response to a Request . . . . . . . . . . . 44 |  | 5.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 |
| 5.7. Message Forwarding . . . . . . . . . . . . . . . . . . . . 44 |  | 5.5. Effective Request URI . . . . . . . . . . . . . . . . . . 44 |
| 5.7.1. Via . . . . . . . . . . . . . . . . . . . . . . . . . 45 |  | 5.6. Associating a Response to a Request . . . . . . . . . . . 46 |
| 5.7.2. Transformations . . . . . . . . . . . . . . . . . . . 46 |  | 5.7. Message Forwarding . . . . . . . . . . . . . . . . . . . . 46 |
| 6. Connection Management . . . . . . . . . . . . . . . . . . . . 47 |  | 5.7.1. Via . . . . . . . . . . . . . . . . . . . . . . . . . 46 |
| 6.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 48 |  | 5.7.2. Transformations . . . . . . . . . . . . . . . . . . . 48 |
| 6.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 49 |  | 6. Connection Management . . . . . . . . . . . . . . . . . . . . 49 |
| 6.3. Persistence . . . . . . . . . . . . . . . . . . . . . . . 49 |  | 6.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 49 |
| 6.3.1. Retrying Requests . . . . . . . . . . . . . . . . . . 51 |  | 6.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 51 |
| 6.3.2. Pipelining . . . . . . . . . . . . . . . . . . . . . . 51 |  | 6.3. Persistence . . . . . . . . . . . . . . . . . . . . . . . 51 |
| 6.4. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 52 |  | 6.3.1. Retrying Requests . . . . . . . . . . . . . . . . . . 52 |
| 6.5. Failures and Time-outs . . . . . . . . . . . . . . . . . . 52 |  | 6.3.2. Pipelining . . . . . . . . . . . . . . . . . . . . . . 53 |
| 6.6. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 53 |  | 6.4. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 54 |
| 6.7. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 54 |  | 6.5. Failures and Time-outs . . . . . . . . . . . . . . . . . . 54 |
| 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56 |  | 6.6. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 55 |
| 7.1. Header Field Registration . . . . . . . . . . . . . . . . 56 |  | 6.7. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 56 |
| 7.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 57 |  | 7. ABNF list extension: #rule . . . . . . . . . . . . . . . . . . 58 |
| 7.3. Internet Media Type Registration . . . . . . . . . . . . . 57 |  | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59 |
| 7.3.1. Internet Media Type message/http . . . . . . . . . . . 57 |  | 8.1. Header Field Registration . . . . . . . . . . . . . . . . 59 |
| 7.3.2. Internet Media Type application/http . . . . . . . . . 58 |  | 8.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 60 |
| 7.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 60 |  | 8.3. Internet Media Type Registration . . . . . . . . . . . . . 60 |
| 7.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 60 |  | 8.3.1. Internet Media Type message/http . . . . . . . . . . . 61 |
| 7.4.2. Registration . . . . . . . . . . . . . . . . . . . . . 60 |  | 8.3.2. Internet Media Type application/http . . . . . . . . . 62 |
| 7.5. Upgrade Token Registry . . . . . . . . . . . . . . . . . . 61 |  | 8.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 63 |
| 7.5.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 61 |  | 8.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 63 |
| 7.5.2. Upgrade Token Registration . . . . . . . . . . . . . . 61 |  | 8.4.2. Registration . . . . . . . . . . . . . . . . . . . . . 63 |
| 8. Security Considerations . . . . . . . . . . . . . . . . . . . 62 |  | 8.5. Upgrade Token Registry . . . . . . . . . . . . . . . . . . 64 |
| 8.1. DNS-related Attacks . . . . . . . . . . . . . . . . . . . 62 |  | 8.5.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 64 |
| 8.2. Intermediaries and Caching . . . . . . . . . . . . . . . . 62 |  | 8.5.2. Upgrade Token Registration . . . . . . . . . . . . . . 65 |
| 8.3. Buffer Overflows . . . . . . . . . . . . . . . . . . . . . 63 |  | 9. Security Considerations . . . . . . . . . . . . . . . . . . . 65 |
| 8.4. Message Integrity . . . . . . . . . . . . . . . . . . . . 63 |  | 9.1. DNS-related Attacks . . . . . . . . . . . . . . . . . . . 65 |
| 8.5. Server Log Information . . . . . . . . . . . . . . . . . . 64 |  | 9.2. Intermediaries and Caching . . . . . . . . . . . . . . . . 65 |
| 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 64 |  | 9.3. Buffer Overflows . . . . . . . . . . . . . . . . . . . . . 66 |
| 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 66 |  | 9.4. Message Integrity . . . . . . . . . . . . . . . . . . . . 66 |
| 10.1. Normative References . . . . . . . . . . . . . . . . . . . 66 |  | 9.5. Server Log Information . . . . . . . . . . . . . . . . . . 67 |
| 10.2. Informative References . . . . . . . . . . . . . . . . . . 67 |  | 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 67 |
| Appendix A. HTTP Version History . . . . . . . . . . . . . . . . 69 |  | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 69 |
| A.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 70 |  | 11.1. Normative References . . . . . . . . . . . . . . . . . . . 69 |
| A.1.1. Multi-homed Web Servers . . . . . . . . . . . . . . . 70 |  | 11.2. Informative References . . . . . . . . . . . . . . . . . . 70 |
| A.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 70 |  | Appendix A. HTTP Version History . . . . . . . . . . . . . . . . 72 |
| A.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 71 |  | A.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 73 |
| A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 71 |  | A.1.1. Multi-homed Web Servers . . . . . . . . . . . . . . . 73 |
| Appendix B. ABNF list extension: #rule . . . . . . . . . . . . . 74 |  | A.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 73 |
| Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 75 |  | A.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 74 |
| Appendix D. Change Log (to be removed by RFC Editor before |  | A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 74 |
| publication) . . . . . . . . . . . . . . . . . . . . 77 |  | Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 76 |
| D.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 77 |  | Appendix C. Change Log (to be removed by RFC Editor before |
| D.2. Since draft-ietf-httpbis-p1-messaging-21 . . . . . . . . . 77 |  | publication) . . . . . . . . . . . . . . . . . . . . 79 |
| D.3. Since draft-ietf-httpbis-p1-messaging-22 . . . . . . . . . 79 |  | C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 79 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 |  | C.2. Since draft-ietf-httpbis-p1-messaging-21 . . . . . . . . . 79 |
|  |  | C.3. Since draft-ietf-httpbis-p1-messaging-22 . . . . . . . . . 80 |
|  |  | C.4. Since draft-ietf-httpbis-p1-messaging-23 . . . . . . . . . 82 |
|  |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 |
| 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 self- |  | request/response protocol that uses extensible semantics and self- |
| descriptive message payloads for flexible interaction with network- |  | descriptive message payloads for flexible interaction with network- |
| based hypertext information systems. This document is the first in a |  | based hypertext information systems. This document is the first in a |
| series of documents that collectively form the HTTP/1.1 |  | series of documents that collectively form the HTTP/1.1 |
| specification: |  | specification: |
| skipping to change at page 6, line 32 |  | skipping to change at page 6, line 32 |
| "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]. |
| Conformance criteria and considerations regarding error handling are |  | Conformance criteria and considerations regarding error handling are |
| defined in Section 2.5. |  | defined in Section 2.5. |
| 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 |
| Appendix B. Appendix C shows the collected ABNF with the list rule |  | Section 7. Appendix B shows the collected ABNF with the list 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 |
| skipping to change at page 8, line 18 |  | skipping to change at page 8, line 18 |
| (Section 3.2), an empty line to indicate the end of the header |  | (Section 3.2), an empty line to indicate the end of the header |
| section, and finally a message body containing the payload body (if |  | section, and finally a message body containing the payload body (if |
| any, Section 3.3). |  | any, Section 3.3). |
| A connection might be used for multiple request/response exchanges, |  | A connection might be used for multiple request/response exchanges, |
| as defined in Section 6.3. |  | as defined in Section 6.3. |
| The following example illustrates a typical message exchange for a |  | The following example illustrates a typical message exchange for a |
| GET request on the URI "http://www.example.com/hello.txt": |  | GET request on the URI "http://www.example.com/hello.txt": |
| client request: |  | Client request: |
| GET /hello.txt HTTP/1.1 |  | GET /hello.txt HTTP/1.1 |
| User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 |  | User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 |
| Host: www.example.com |  | Host: www.example.com |
| Accept-Language: en, mi |  | Accept-Language: en, mi |
| 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: 51 |  | Content-Length: 51 |
| Vary: Accept-Encoding |  | Vary: Accept-Encoding |
| Content-Type: text/plain |  | Content-Type: text/plain |
| skipping to change at page 10, line 34 |  | skipping to change at page 10, line 34 |
| that would be significant to the original sender or potentially |  | that would be significant to the original sender or potentially |
| significant to downstream recipients). For example, a transforming |  | significant to downstream recipients). For example, a transforming |
| proxy might be acting as a shared annotation server (modifying |  | proxy might be acting as a shared annotation server (modifying |
| responses to include references to a local annotation database), a |  | responses to include references to a local annotation database), a |
| malware filter, a format transcoder, or an intranet-to-Internet |  | malware filter, a format transcoder, or an intranet-to-Internet |
| privacy filter. Such transformations are presumed to be desired by |  | privacy filter. Such transformations are presumed to be desired by |
| the client (or client organization) that selected the proxy and are |  | the client (or client organization) that selected the proxy and are |
| beyond the scope of this specification. However, when a proxy is not |  | beyond the scope of this specification. However, when a proxy is not |
| intended to transform a given message, we use the term "non- |  | intended to transform a given message, we use the term "non- |
| transforming proxy" to target requirements that preserve HTTP message |  | transforming proxy" to target requirements that preserve HTTP message |
| semantics. See Section 6.3.4 of [Part2] and Section 7.5 of [Part6] |  | semantics. See Section 6.3.4 of [Part2] and Section 5.5 of [Part6] |
| for status and warning codes related to transformations. |  | for status and warning codes related to transformations. |
| A "gateway" (a.k.a., "reverse proxy") is an intermediary that acts as |  | A "gateway" (a.k.a., "reverse proxy") is an intermediary that acts as |
| an origin server for the outbound connection, but translates received |  | an origin server for the outbound connection, but translates received |
| requests and forwards them inbound to another server or servers. |  | requests and forwards them inbound to another server or servers. |
| Gateways are often used to encapsulate legacy or untrusted |  | Gateways are often used to encapsulate legacy or untrusted |
| information services, to improve server performance through |  | information services, to improve server performance through |
| "accelerator" caching, and to enable partitioning or load balancing |  | "accelerator" caching, and to enable partitioning or load balancing |
| of HTTP services across multiple machines. |  | of HTTP services across multiple machines. |
| skipping to change at page 11, line 34 |  | skipping to change at page 11, line 34 |
| TCP port 80 packets (and occasionally other common port traffic). |  | TCP port 80 packets (and occasionally other common port traffic). |
| Interception proxies are commonly found on public network access |  | Interception proxies are commonly found on public network access |
| points, as a means of enforcing account subscription prior to |  | points, as a means of enforcing account subscription prior to |
| allowing use of non-local Internet services, and within corporate |  | allowing use of non-local Internet services, and within corporate |
| firewalls to enforce network usage policies. They are |  | firewalls to enforce network usage policies. They are |
| indistinguishable from a man-in-the-middle attack. |  | indistinguishable from a man-in-the-middle attack. |
| HTTP is defined as a stateless protocol, meaning that each request |  | HTTP is defined as a stateless protocol, meaning that each request |
| message can be understood in isolation. Many implementations depend |  | message can be understood in isolation. Many implementations depend |
| on HTTP's stateless design in order to reuse proxied connections or |  | on HTTP's stateless design in order to reuse proxied connections or |
| dynamically load-balance requests across multiple servers. Hence, |  | dynamically load-balance requests across multiple servers. Hence, a |
| servers MUST NOT assume that two requests on the same connection are |  | server MUST NOT assume that two requests on the same connection are |
| from the same user agent unless the connection is secured and |  | from the same user agent unless the connection is secured and |
| specific to that agent. Some non-standard HTTP extensions (e.g., |  | specific to that agent. Some non-standard HTTP extensions (e.g., |
| [RFC4559]) have been known to violate this requirement, resulting in |  | [RFC4559]) have been known to violate this requirement, resulting in |
| security and interoperability problems. |  | security and interoperability problems. |
| 2.4. Caches |  | 2.4. Caches |
| A "cache" is a local store of previous response messages and the |  | A "cache" is a local store of previous response messages and the |
| subsystem that controls its message storage, retrieval, and deletion. |  | subsystem that controls its message storage, retrieval, and deletion. |
| A cache stores cacheable responses in order to reduce the response |  | A cache stores cacheable responses in order to reduce the response |
| skipping to change at page 12, line 44 |  | skipping to change at page 12, line 44 |
| resource owners, and protocol element registrations when they apply |  | resource owners, and protocol element registrations when they apply |
| beyond the scope of a single communication. |  | beyond the scope of a single communication. |
| The verb "generate" is used instead of "send" where a requirement |  | The verb "generate" is used instead of "send" where a requirement |
| differentiates between creating a protocol element and merely |  | differentiates between creating a protocol element and merely |
| forwarding a received element downstream. |  | 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. |
| Conformance applies to both the syntax and semantics of HTTP protocol |  | Conformance includes both the syntax and semantics of HTTP protocol |
| elements. A sender MUST NOT generate protocol elements that convey a |  | elements. A sender MUST NOT generate protocol elements that convey a |
| meaning that is known by that sender to be false. A sender MUST NOT |  | meaning that is known by that sender to be false. A sender MUST NOT |
| generate protocol elements that do not match the grammar defined by |  | generate protocol elements that do not match the grammar defined by |
| the ABNF rules for those protocol elements that are applicable to the |  | the corresponding ABNF rules. Within a given message, a sender MUST |
| sender's role. If a received protocol element is processed, the |  | NOT generate protocol elements or syntax alternatives that are only |
| recipient MUST be able to parse any value that would match the ABNF |  | allowed to be generated by participants in other roles (i.e., a role |
| rules for that protocol element, excluding only those rules not |  | that the sender does not have for that message). |
| applicable to the recipient's role. |  |  |
|  |  | When a received protocol element is parsed, the recipient MUST be |
|  |  | able to parse any value of reasonable length that is applicable to |
|  |  | the recipient's role and matches the grammar defined by the |
|  |  | corresponding ABNF rules. Note, however, that some received protocol |
|  |  | elements might not be parsed. For example, an intermediary |
|  |  | forwarding a message might parse a header-field into generic field- |
|  |  | name and field-value components, but then forward the header field |
|  |  | without further parsing inside the field-value. |
|  |  | HTTP does not have specific length limitations for many of its |
|  |  | protocol elements because the lengths that might be appropriate will |
|  |  | vary widely, depending on the deployment context and purpose of the |
|  |  | implementation. Hence, interoperability between senders and |
|  |  | recipients depends on shared expectations regarding what is a |
|  |  | reasonable length for each protocol element. Furthermore, what is |
|  |  | commonly understood to be a reasonable length for some protocol |
|  |  | elements has changed over the course of the past two decades of HTTP |
|  |  | use, and is expected to continue changing in the future. |
|  |  | At a minimum, a recipient MUST be able to parse and process protocol |
|  |  | element lengths that are at least as long as the values that it |
|  |  | generates for those same protocol elements in other messages. For |
|  |  | example, an origin server that publishes very long URI references to |
|  |  | its own resources needs to be able to parse and process those same |
|  |  | references when received as a request target. |
|  |  | A recipient MUST interpret a received protocol element according to |
|  |  | the semantics defined for it by this specification, including |
|  |  | extensions to this specification, unless the recipient has determined |
|  |  | (through experience or configuration) that the sender incorrectly |
|  |  | implements what is implied by those semantics. For example, an |
|  |  | origin server might disregard the contents of a received Accept- |
|  |  | Encoding header field if inspection of the User-Agent header field |
|  |  | indicates a specific implementation version that is known to fail on |
|  |  | receipt of certain content codings. |
| Unless noted otherwise, a recipient 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. |
| skipping to change at page 14, line 10 |  | skipping to change at page 14, line 47 |
| the recipient supports HTTP/1.1. |  | the recipient supports HTTP/1.1. |
| The interpretation of a header field does not change between minor |  | The interpretation of a header field does not change between minor |
| versions of the same major HTTP version, though the default behavior |  | versions of the same major HTTP version, though the default behavior |
| of a recipient in the absence of such a field can change. Unless |  | of a recipient in the absence of such a field can change. Unless |
| specified otherwise, header fields defined in HTTP/1.1 are defined |  | specified otherwise, header fields defined in HTTP/1.1 are defined |
| for all versions of HTTP/1.x. In particular, the Host and Connection |  | for all versions of HTTP/1.x. In particular, the Host and Connection |
| 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 introduced without changing the protocol |
| by a recipient, they might override or enhance the interpretation of |  | version if their defined semantics allow them to be safely ignored by |
| previously defined header fields. When an implementation receives an |  | recipients that do not recognize them. Header field extensibility is |
| unrecognized header field, the recipient MUST ignore that header |  | discussed in Section 3.2.1. |
| field for local processing regardless of the message's HTTP version. |  |  |
| An unrecognized header field received by a proxy MUST be forwarded |  |  |
| downstream unless the header field's field-name is listed in the |  |  |
| message's Connection header field (see Section 6.1). These |  |  |
| requirements allow HTTP's functionality to be enhanced without |  |  |
| 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 |
| result in communication errors when downstream recipients use the |  | result in communication errors when downstream recipients use the |
| message sender's version to determine what features are safe to use |  | message sender's version to determine what features are safe to use |
| skipping to change at page 14, line 41 |  | skipping to change at page 15, line 23 |
| A client SHOULD send a request version equal to the highest version |  | A client SHOULD send a request version equal to the highest version |
| to which the client is conformant and whose major version is no |  | to which the client is conformant and whose major version is no |
| higher than the highest version supported by the server, if this is |  | higher than the highest version supported by the server, if this is |
| known. A client MUST NOT send a version to which it is not |  | known. A client MUST NOT send a version to which it is not |
| conformant. |  | conformant. |
| A client MAY send a lower request version if it is known that the |  | A client MAY send a lower request version if it is known that the |
| server incorrectly implements the HTTP specification, but only after |  | server incorrectly implements the HTTP specification, but only after |
| the client has attempted at least one normal request and determined |  | the client has attempted at least one normal request and determined |
| from the response status or header fields (e.g., Server) that the |  | from the response status code or header fields (e.g., Server) that |
| server improperly handles higher request versions. |  | the server improperly handles higher request versions. |
| A server SHOULD send a response version equal to the highest version |  | A server SHOULD send a response version equal to the highest version |
| to which the server is conformant and whose major version is less |  | to which the server is conformant and whose major version is less |
| than or equal to the one received in the request. A server MUST NOT |  | than or equal to the one received in the request. A server MUST NOT |
| send a version to which it is not conformant. A server MAY send a |  | send a version to which it is not conformant. A server MAY send a |
| 505 (HTTP Version Not Supported) response if it cannot send a |  | 505 (HTTP Version Not Supported) response if it cannot send a |
| response using the major version used in the client's request. |  | response using the major version used in the client's request. |
| A server MAY send an HTTP/1.0 response to a request if it is known or |  | A server MAY send an HTTP/1.0 response to a request if it is known or |
| suspected that the client incorrectly implements the HTTP |  | suspected that the client incorrectly implements the HTTP |
| skipping to change at page 16, line 43 |  | skipping to change at page 17, line 22 |
| http-URI = "http:" "//" authority path-abempty [ "?" query ] |  | http-URI = "http:" "//" authority path-abempty [ "?" query ] |
| [ "#" fragment ] |  | [ "#" fragment ] |
| The HTTP origin server is identified by the generic syntax's |  | The HTTP origin server is identified by the generic syntax's |
| authority component, which includes a host identifier and optional |  | authority component, which includes a host identifier and optional |
| TCP port ([RFC3986], Section 3.2.2). The remainder of the URI, |  | TCP port ([RFC3986], Section 3.2.2). The remainder of the URI, |
| consisting of both the hierarchical path component and optional query |  | consisting of both the hierarchical path component and optional query |
| component, serves as an identifier for a potential resource within |  | component, serves as an identifier for a potential resource within |
| that origin server's name space. |  | that origin server's name space. |
|  |  | A sender MUST NOT generate an "http" URI with an empty host |
|  |  | identifier. A recipient that processes such a URI reference MUST |
|  |  | reject it as invalid. |
| If the host identifier is provided as an IP address, then the origin |  | If the host identifier is provided as an IP address, then the origin |
| server is any listener on the indicated TCP port at that IP address. |  | server is any listener on the indicated TCP port at that IP address. |
| If host is a registered name, then that name is considered an |  | If host is a registered name, then that name is considered an |
| indirect identifier and the recipient might use a name resolution |  | indirect identifier and the recipient might use a name resolution |
| service, such as DNS, to find the address of a listener for that |  | service, such as DNS, to find the address of a listener for that |
| host. The host MUST NOT be empty; if an "http" URI is received with |  | host. If the port subcomponent is empty or not given, then TCP port |
| an empty host, then it MUST be rejected as invalid. If the port |  | 80 is assumed (the default reserved port for WWW services). |
| subcomponent is empty or not given, then TCP port 80 is assumed (the |  |  |
| default reserved port for WWW services). |  |  |
| Regardless of the form of host identifier, access to that host is not |  | Regardless of the form of host identifier, access to that host is not |
| implied by the mere presence of its name or address. The host might |  | implied by the mere presence of its name or address. The host might |
| or might not exist and, even when it does exist, might or might not |  | or might not exist and, even when it does exist, might or might not |
| be running an HTTP server or listening to the indicated port. The |  | be running an HTTP server or listening to the indicated port. The |
| "http" URI scheme makes use of the delegated nature of Internet names |  | "http" URI scheme makes use of the delegated nature of Internet names |
| and addresses to establish a naming authority (whatever entity has |  | and addresses to establish a naming authority (whatever entity has |
| the ability to place an HTTP server at that Internet name or address) |  | the ability to place an HTTP server at that Internet name or address) |
| and allows that authority to determine which names are valid and how |  | and allows that authority to determine which names are valid and how |
| they might be used. |  | they might be used. |
| skipping to change at page 17, line 41 |  | skipping to change at page 18, line 21 |
| secured connection. Other protocols might also be used to provide |  | secured connection. Other protocols might also be used to provide |
| access to "http" identified resources -- it is only the authoritative |  | access to "http" identified resources -- it is only the authoritative |
| interface that is specific to TCP. |  | interface that is specific to TCP. |
| The URI generic syntax for authority also includes a deprecated |  | The URI generic syntax for authority also includes a deprecated |
| userinfo subcomponent ([RFC3986], Section 3.2.1) for including user |  | userinfo subcomponent ([RFC3986], Section 3.2.1) for including user |
| authentication information in the URI. Some implementations make use |  | authentication information in the URI. Some implementations make use |
| of the userinfo component for internal configuration of |  | of the userinfo component for internal configuration of |
| authentication information, such as within command invocation |  | authentication information, such as within command invocation |
| options, configuration files, or bookmark lists, even though such |  | options, configuration files, or bookmark lists, even though such |
| usage might expose a user identifier or password. Senders MUST |  | usage might expose a user identifier or password. A sender MUST NOT |
| exclude the userinfo subcomponent (and its "@" delimiter) when an |  | generate the userinfo subcomponent (and its "@" delimiter) when an |
| "http" URI is transmitted within a message as a request target or |  | "http" URI reference is generated within a message as a request |
| header field value. Recipients of an "http" URI reference SHOULD |  | target or header field value. Before making use of an "http" URI |
| parse for userinfo and treat its presence as an error, since it is |  | reference received from an untrusted source, a recipient ought to |
| likely being used to obscure the authority for the sake of phishing |  | parse for userinfo and treat its presence as an error; it is likely |
| attacks. |  | being used to obscure the authority for the sake of phishing attacks. |
| 2.7.2. https URI scheme |  | 2.7.2. https URI scheme |
| The "https" URI scheme is hereby defined for the purpose of minting |  | The "https" URI scheme is hereby defined for the purpose of minting |
| identifiers according to their association with the hierarchical |  | identifiers according to their association with the hierarchical |
| namespace governed by a potential HTTP origin server listening to a |  | namespace governed by a potential HTTP origin server listening to a |
| given TCP port for TLS-secured connections ([RFC0793], [RFC5246]). |  | given TCP port for TLS-secured connections ([RFC0793], [RFC5246]). |
| All of the requirements listed above for the "http" scheme are also |  | All of the requirements listed above for the "http" scheme are also |
| requirements for the "https" scheme, except that a default TCP port |  | requirements for the "https" scheme, except that a default TCP port |
| of 443 is assumed if the port subcomponent is empty or not given, and |  | of 443 is assumed if the port subcomponent is empty or not given, and |
| the TCP connection MUST be secured, end-to-end, through the use of |  | the user agent MUST ensure that its connection to the origin server |
| strong encryption prior to sending the first HTTP request. |  | is secured through the use of strong encryption, end-to-end, prior to |
|  |  | sending the first HTTP request. |
| https-URI = "https:" "//" authority path-abempty [ "?" query ] |  | https-URI = "https:" "//" authority path-abempty [ "?" query ] |
| [ "#" fragment ] |  | [ "#" fragment ] |
| Note that the "https" URI scheme depends on both TLS and TCP for |  | Note that the "https" URI scheme depends on both TLS and TCP for |
| establishing authority. Resources made available via the "https" |  | establishing authority. Resources made available via the "https" |
| scheme have no shared identity with the "http" scheme even if their |  | scheme have no shared identity with the "http" scheme even if their |
| resource identifiers indicate the same authority (the same host |  | resource identifiers indicate the same authority (the same host |
| listening to the same TCP port). They are distinct name spaces and |  | listening to the same TCP port). They are distinct name spaces and |
| are considered to be distinct origin servers. However, an extension |  | are considered to be distinct origin servers. However, an extension |
| skipping to change at page 19, line 26 |  | skipping to change at page 20, line 7 |
| CRLF |  | CRLF |
| [ message-body ] |  | [ message-body ] |
| The normal procedure for parsing an HTTP message is to read the |  | The normal procedure for parsing an HTTP message is to read the |
| start-line into a structure, read each header field into a hash table |  | start-line into a structure, read each header field into a hash table |
| by field name until the empty line, and then use the parsed data to |  | by field name until the empty line, and then use the parsed data to |
| determine if a message body is expected. If a message body has been |  | determine if a message body is expected. If a message body has been |
| indicated, then it is read as a stream until an amount of octets |  | indicated, then it is read as a stream until an amount of octets |
| equal to the message body length is read or the connection is closed. |  | equal to the message body length is read or the connection is closed. |
| Recipients MUST parse an HTTP message as a sequence of octets in an |  | A recipient MUST parse an HTTP message as a sequence of octets in an |
| encoding that is a superset of US-ASCII [USASCII]. Parsing an HTTP |  | encoding that is a superset of US-ASCII [USASCII]. Parsing an HTTP |
| message as a stream of Unicode characters, without regard for the |  | message as a stream of Unicode characters, without regard for the |
| specific encoding, creates security vulnerabilities due to the |  | specific encoding, creates security vulnerabilities due to the |
| varying ways that string processing libraries handle invalid |  | varying ways that string processing libraries handle invalid |
| multibyte character sequences that contain the octet LF (%x0A). |  | multibyte character sequences that contain the octet LF (%x0A). |
| String-based parsers can only be safely used within protocol elements |  | String-based parsers can only be safely used within protocol elements |
| after the element has been extracted from the message, such as within |  | after the element has been extracted from the message, such as within |
| a header field-value after message parsing has delineated the |  | a header field-value after message parsing has delineated the |
| individual fields. |  | individual fields. |
| skipping to change at page 19, line 49 |  | skipping to change at page 20, line 30 |
| incremental delivery of partial messages, since some implementations |  | incremental delivery of partial messages, since some implementations |
| will buffer or delay message forwarding for the sake of network |  | will buffer or delay message forwarding for the sake of network |
| efficiency, security checks, or payload transformations. |  | efficiency, security checks, or payload transformations. |
| A sender MUST NOT send whitespace between the start-line and the |  | A sender MUST NOT send whitespace between the start-line and the |
| first header field. A recipient that receives whitespace between the |  | first header field. A recipient that receives whitespace between the |
| start-line and the first header field MUST either reject the message |  | start-line and the first header field MUST either reject the message |
| as invalid or consume each whitespace-preceded line without further |  | as invalid or consume each whitespace-preceded line without further |
| processing of it (i.e., ignore the entire line, along with any |  | processing of it (i.e., ignore the entire line, along with any |
| subsequent lines preceded by whitespace, until a properly formed |  | subsequent lines preceded by whitespace, until a properly formed |
| header field is received or the header block is terminated). |  | header field is received or the header section is terminated). |
| The presence of such whitespace in a request might be an attempt to |  | The presence of such whitespace in a request might be an attempt to |
| trick a server into ignoring that field or processing the line after |  | trick a server into ignoring that field or processing the line after |
| it as a new request, either of which might result in a security |  | it as a new request, either of which might result in a security |
| vulnerability if other implementations within the request chain |  | vulnerability if other implementations within the request chain |
| interpret the same message differently. Likewise, the presence of |  | interpret the same message differently. Likewise, the presence of |
| such whitespace in a response might be ignored by some clients or |  | such whitespace in a response might be ignored by some clients or |
| cause others to cease parsing. |  | cause others to cease parsing. |
| 3.1. Start Line |  | 3.1. Start Line |
| skipping to change at page 20, line 40 |  | skipping to change at page 21, line 21 |
| (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 |
| 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 4 |  | The request methods defined by this specification can be found in |
| of [Part2], along with information regarding the HTTP method registry |  | Section 4 of [Part2], along with information regarding the HTTP |
| and considerations for defining new methods. |  | method registry and considerations for defining new methods. |
| The request-target identifies the target resource upon which to apply |  | The request-target identifies the target resource upon which to apply |
| the request, as defined in Section 5.3. |  | the request, as defined in Section 5.3. |
| Recipients typically parse the request-line into its component parts |  | Recipients typically parse the request-line into its component parts |
| by splitting on whitespace (see Section 3.5), since no whitespace is |  | by splitting on whitespace (see Section 3.5), since no whitespace is |
| allowed in the three components. Unfortunately, some user agents |  | allowed in the three components. Unfortunately, some user agents |
| fail to properly encode or exclude whitespace found in hypertext |  | fail to properly encode or exclude whitespace found in hypertext |
| references, resulting in those disallowed characters being sent in a |  | references, resulting in those disallowed characters being sent in a |
| request-target. |  | request-target. |
| Recipients of an invalid request-line SHOULD respond with either a |  | Recipients of an invalid request-line SHOULD respond with either a |
| 400 (Bad Request) error or a 301 (Moved Permanently) redirect with |  | 400 (Bad Request) error or a 301 (Moved Permanently) redirect with |
| the request-target properly encoded. Recipients SHOULD NOT attempt |  | the request-target properly encoded. A recipient SHOULD NOT attempt |
| to autocorrect and then process the request without a redirect, since |  | to autocorrect and then process the request without a redirect, since |
| the invalid request-line might be deliberately crafted to bypass |  | the invalid request-line might be deliberately crafted to bypass |
| security filters along the request chain. |  | 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 a 501 (Not Implemented) status code. |  | implements SHOULD respond with a 501 (Not Implemented) status code. |
| A server MUST be prepared to receive URIs of unbounded length and |  | A server ought to be prepared to receive URIs of unbounded length, as |
| respond with the 414 (URI Too Long) status code if the received |  | described in Section 2.5, and MUST respond with a 414 (URI Too Long) |
| request-target would be longer than the server wishes to handle (see |  | status code if the received request-target is longer than the server |
| Section 6.5.12 of [Part2]). |  | wishes to parse (see Section 6.5.12 of [Part2]). |
| Various ad-hoc limitations on request-line length are found in |  | Various ad-hoc limitations on request-line length are found in |
| practice. It is RECOMMENDED that all HTTP senders and recipients |  | practice. It is RECOMMENDED that all HTTP senders and recipients |
| support, at a minimum, request-line lengths of 8000 octets. |  | support, at a minimum, request-line lengths of 8000 octets. |
| 3.1.2. Status Line |  | 3.1.2. Status Line |
| The first line of a response message is the status-line, consisting |  | The first line of a response message is the status-line, consisting |
| of the protocol version, a space (SP), the status code, another |  | of the protocol version, a space (SP), the status code, another |
| space, a possibly-empty textual phrase describing the status code, |  | space, a possibly-empty textual phrase describing the status code, |
| skipping to change at page 22, line 28 |  | skipping to change at page 23, line 8 |
| ; obsolete line folding |  | ; obsolete line folding |
| ; see Section 3.2.4 |  | ; see Section 3.2.4 |
| The field-name token labels the corresponding field-value as having |  | The field-name token labels the corresponding field-value as having |
| the semantics defined by that header field. For example, the Date |  | the semantics defined by that header field. For example, the Date |
| header field is defined in Section 7.1.1.2 of [Part2] as containing |  | header field is defined in Section 7.1.1.2 of [Part2] as containing |
| the origination timestamp for the message in which it appears. |  | the origination timestamp for the message in which it appears. |
| 3.2.1. Field Extensibility |  | 3.2.1. Field Extensibility |
| HTTP header fields are fully extensible: there is no limit on the |  | 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, nor on the number of header fields used in a given |  | semantics, nor on the number of header fields used in a given |
| message. Existing fields are defined in each part of this |  | message. Existing fields are defined in each part of this |
| specification and in many other specifications outside the core |  | specification and in many other specifications outside the core |
| standard. New header fields can be introduced without changing the |  | standard. |
| protocol version if their defined semantics allow them to be safely |  |  |
| ignored by recipients that do not recognize them. |  |  |
| New HTTP header fields ought to be registered with IANA in the |  | New header fields can be defined such that, when they are understood |
|  |  | by a recipient, they might override or enhance the interpretation of |
|  |  | previously defined header fields, define preconditions on request |
|  |  | evaluation, or refine the meaning of responses. |
|  |  | A proxy MUST forward unrecognized header fields unless the field-name |
|  |  | is listed in the Connection header field (Section 6.1) or the proxy |
|  |  | is specifically configured to block, or otherwise transform, such |
|  |  | fields. Other recipients SHOULD ignore unrecognized header fields. |
|  |  | These requirements allow HTTP's functionality to be enhanced without |
|  |  | requiring prior update of deployed intermediaries. |
|  |  | All defined header fields ought to be registered with IANA in the |
| Message Header Field Registry, as described in Section 8.3 of |  | Message Header Field Registry, as described in Section 8.3 of |
| [Part2]. A proxy MUST forward unrecognized header fields unless the |  | [Part2]. |
| field-name is listed in the Connection header field (Section 6.1) or |  |  |
| the proxy is specifically configured to block, or otherwise |  |  |
| transform, such fields. Other recipients SHOULD ignore unrecognized |  |  |
| header fields. |  |  |
| 3.2.2. Field Order |  | 3.2.2. Field Order |
| The order in which header fields with differing field names are |  | The order in which header fields with differing field names are |
| received is not significant. However, it is "good practice" to send |  | received is not significant. However, it is "good practice" to send |
| header fields that contain control data first, such as Host on |  | header fields that contain control data first, such as Host on |
| requests and Date on responses, so that implementations can decide |  | requests and Date on responses, so that implementations can decide |
| when not to handle a message as early as possible. A server MUST |  | when not to handle a message as early as possible. A server MUST |
| wait until the entire header section is received before interpreting |  | wait until the entire header section is received before interpreting |
| a request message, since later header fields might include |  | a request message, since later header fields might include |
| conditionals, authentication credentials, or deliberately misleading |  | conditionals, authentication credentials, or deliberately misleading |
| duplicate header fields that would impact request processing. |  | duplicate header fields that would impact request processing. |
| A sender MUST NOT generate multiple header fields with the same field |  | A sender MUST NOT generate multiple header fields with the same field |
| name in a message unless either the entire field value for that |  | name in a message unless either the entire field value for that |
| header field is defined as a comma-separated list [i.e., #(values)] |  | header field is defined as a comma-separated list [i.e., #(values)] |
| or the header field is a well-known exception (as noted below). |  | or the header field is a well-known exception (as noted below). |
| Multiple header fields with the same field name can be combined into |  | A recipient MAY combine multiple header fields with the same field |
| one "field-name: field-value" pair, without changing the semantics of |  | name into one "field-name: field-value" pair, without changing the |
| the message, by appending each subsequent field value to the combined |  | semantics of the message, by appending each subsequent field value to |
| field value in order, separated by a comma. The order in which |  | the combined field value in order, separated by a comma. The order |
| header fields with the same field name are received is therefore |  | in which header fields with the same field name are received is |
| significant to the interpretation of the combined field value; a |  | therefore significant to the interpretation of the combined field |
| proxy MUST NOT change the order of these field values when forwarding |  | value; a proxy MUST NOT change the order of these field values when |
| a message. |  | forwarding a message. |
| Note: In practice, the "Set-Cookie" header field ([RFC6265]) often |  | Note: In practice, the "Set-Cookie" header field ([RFC6265]) often |
| appears multiple times in a response message and does not use the |  | appears multiple times in a response message and does not use the |
| list syntax, violating the above requirements on multiple header |  | list syntax, violating the above requirements on multiple header |
| fields with the same name. Since it cannot be combined into a |  | fields with the same name. Since it cannot be combined into a |
| single field-value, recipients ought to handle "Set-Cookie" as a |  | single field-value, recipients ought to handle "Set-Cookie" as a |
| special case while processing header fields. (See Appendix A.2.3 |  | special case while processing header fields. (See Appendix A.2.3 |
| of [Kri2001] for details.) |  | of [Kri2001] for details.) |
| 3.2.3. Whitespace |  | 3.2.3. Whitespace |
| skipping to change at page 24, line 39 |  | skipping to change at page 25, line 26 |
| A recipient of field-content containing multiple sequential octets of |  | A recipient of field-content containing multiple sequential octets of |
| optional (OWS) or required (RWS) whitespace SHOULD either replace the |  | optional (OWS) or required (RWS) whitespace SHOULD either replace the |
| sequence with a single SP or transform any non-SP octets in the |  | sequence with a single SP or transform any non-SP octets in the |
| sequence to SP octets before interpreting the field value or |  | sequence to SP octets before interpreting the field value or |
| forwarding the message downstream. |  | forwarding the message downstream. |
| Historically, HTTP header field values could be extended over |  | Historically, HTTP header field values could be extended over |
| multiple lines by preceding each extra line with at least one space |  | multiple lines by preceding each extra line with at least one space |
| or horizontal tab (obs-fold). This specification deprecates such |  | or horizontal tab (obs-fold). This specification deprecates such |
| line folding except within the message/http media type |  | line folding except within the message/http media type |
| (Section 7.3.1). Senders MUST NOT generate messages that include |  | (Section 8.3.1). A sender MUST NOT generate a message that includes |
| line folding (i.e., that contain any field-value that contains a |  | line folding (i.e., that has any field-value that contains a match to |
| match to the obs-fold rule) unless the message is intended for |  | the obs-fold rule) unless the message is intended for packaging |
| packaging within the message/http media type. |  | within the message/http media type. |
| A server that receives an obs-fold in a request message that is not |  | A server that receives an obs-fold in a request message that is not |
| within a message/http container MUST either reject the message by |  | within a message/http container MUST either reject the message by |
| sending a 400 (Bad Request), preferably with a representation |  | sending a 400 (Bad Request), preferably with a representation |
| explaining that obsolete line folding is unacceptable, or replace |  | explaining that obsolete line folding is unacceptable, or replace |
| each received obs-fold with one or more SP octets prior to |  | each received obs-fold with one or more SP octets prior to |
| interpreting the field value or forwarding the message downstream. |  | interpreting the field value or forwarding the message downstream. |
| A proxy or gateway that receives an obs-fold in a response message |  | A proxy or gateway that receives an obs-fold in a response message |
| that is not within a message/http container MUST either discard the |  | that is not within a message/http container MUST either discard the |
| skipping to change at page 25, line 20 |  | skipping to change at page 26, line 8 |
| A user agent that receives an obs-fold in a response message that is |  | A user agent that receives an obs-fold in a response message that is |
| not within a message/http container MUST replace each received obs- |  | not within a message/http container MUST replace each received obs- |
| fold with one or more SP octets prior to interpreting the field |  | fold with one or more SP octets prior to interpreting the field |
| value. |  | value. |
| Historically, HTTP has allowed field content with text in the ISO- |  | Historically, HTTP has allowed field content with text in the ISO- |
| 8859-1 [ISO-8859-1] charset, supporting other charsets only through |  | 8859-1 [ISO-8859-1] charset, supporting other charsets only through |
| use of [RFC2047] encoding. In practice, most HTTP header field |  | use of [RFC2047] encoding. In practice, most HTTP header field |
| values use only a subset of the US-ASCII charset [USASCII]. Newly |  | values use only a subset of the US-ASCII charset [USASCII]. Newly |
| defined header fields SHOULD limit their field values to US-ASCII |  | defined header fields SHOULD limit their field values to US-ASCII |
| octets. Recipients SHOULD treat other octets in field content (obs- |  | octets. A recipient SHOULD treat other octets in field content (obs- |
| text) as opaque data. |  | text) as opaque data. |
| 3.2.5. Field Limits |  | 3.2.5. Field Limits |
| HTTP does not place a pre-defined limit on the length of each header |  | HTTP does not place a pre-defined limit on the length of each header |
| field or on the length of the header block as a whole. Various ad- |  | field or on the length of the header section as a whole, as described |
| hoc limitations on individual header field length are found in |  | in Section 2.5. Various ad-hoc limitations on individual header |
| practice, often depending on the specific field semantics. |  | field length are found in practice, often depending on the specific |
|  |  | field semantics. |
| A server MUST be prepared to receive request header fields of |  | A server ought to be prepared to receive request header fields of |
| unbounded length and respond with an appropriate 4xx (Client Error) |  | unbounded length and MUST respond with an appropriate 4xx (Client |
| status code if the received header field(s) are larger than the |  | Error) status code if the received header field(s) are larger than |
| server wishes to process. |  | the server wishes to process. |
| A client MUST be prepared to receive response header fields of |  | A client ought to be prepared to receive response header fields of |
| unbounded length. A client MAY discard or truncate received header |  | unbounded length. A client MAY discard or truncate received header |
| fields that are larger than the client wishes to process if the field |  | fields that are larger than the client wishes to process if the field |
| semantics are such that the dropped value(s) can be safely ignored |  | semantics are such that the dropped value(s) can be safely ignored |
| without changing the response semantics. |  | without changing the message framing or response semantics. |
| 3.2.6. Field value components |  | 3.2.6. Field value components |
| Many HTTP header field values consist of words (token or quoted- |  | Many HTTP header field values consist of words (token or quoted- |
| string) separated by whitespace or special characters. These special |  | string) separated by whitespace or special characters. |
| characters MUST be in a quoted string to be used within a parameter |  |  |
| value (as defined in Section 4). |  |  |
| word = token / quoted-string |  | word = token / quoted-string |
| token = 1*tchar |  | token = 1*tchar |
| tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" |  | tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" |
| / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" |  | / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" |
| / DIGIT / ALPHA |  | / DIGIT / ALPHA |
| ; any VCHAR, except special |  | ; any VCHAR, except special |
| skipping to change at page 26, line 34 |  | skipping to change at page 27, line 18 |
| The backslash octet ("\") can be used as a single-octet quoting |  | The backslash octet ("\") can be used as a single-octet quoting |
| mechanism within quoted-string constructs: |  | mechanism within quoted-string constructs: |
| quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text ) |  | quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text ) |
| Recipients that process the value of a quoted-string MUST handle a |  | Recipients that process the value of a quoted-string MUST handle a |
| quoted-pair as if it were replaced by the octet following the |  | quoted-pair as if it were replaced by the octet following the |
| backslash. |  | backslash. |
| Senders SHOULD NOT generate a quoted-pair in a quoted-string except |  | A sender SHOULD NOT generate a quoted-pair in a quoted-string except |
| where necessary to quote DQUOTE and backslash octets occurring within |  | where necessary to quote DQUOTE and backslash octets occurring within |
| that string. |  | that string. |
| Comments can be included in some HTTP header fields by surrounding |  | Comments can be included in some HTTP header fields by surrounding |
| the comment text with parentheses. Comments are only allowed in |  | the comment text with parentheses. Comments are only allowed in |
| fields containing "comment" as part of their field value definition. |  | fields containing "comment" as part of their field value definition. |
| comment = "(" *( ctext / quoted-cpair / comment ) ")" |  | comment = "(" *( ctext / quoted-cpair / comment ) ")" |
| ctext = HTAB / SP / %x21-27 / %x2A-5B / %x5D-7E / obs-text |  | ctext = HTAB / SP / %x21-27 / %x2A-5B / %x5D-7E / obs-text |
| The backslash octet ("\") can be used as a single-octet quoting |  | The backslash octet ("\") can be used as a single-octet quoting |
| mechanism within comment constructs: |  | mechanism within comment constructs: |
| quoted-cpair = "\" ( HTAB / SP / VCHAR / obs-text ) |  | quoted-cpair = "\" ( HTAB / SP / VCHAR / obs-text ) |
| Senders SHOULD NOT escape octets in comments that do not require |  | A sender 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.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. |
| skipping to change at page 28, line 5 |  | skipping to change at page 28, line 37 |
| Transfer-Encoding is analogous to the Content-Transfer-Encoding field |  | Transfer-Encoding is analogous to the Content-Transfer-Encoding field |
| of MIME, which was designed to enable safe transport of binary data |  | of MIME, which was designed to enable safe transport of binary data |
| over a 7-bit transport service ([RFC2045], Section 6). However, safe |  | over a 7-bit transport service ([RFC2045], Section 6). However, safe |
| transport has a different focus for an 8bit-clean transfer protocol. |  | transport has a different focus for an 8bit-clean transfer protocol. |
| In HTTP's case, Transfer-Encoding is primarily intended to accurately |  | In HTTP's case, Transfer-Encoding is primarily intended to accurately |
| delimit a dynamically generated payload and to distinguish payload |  | delimit a dynamically generated payload and to distinguish payload |
| encodings that are only applied for transport efficiency or security |  | encodings that are only applied for transport efficiency or security |
| from those that are characteristics of the selected resource. |  | from those that are characteristics of the selected resource. |
| All HTTP/1.1 recipients MUST implement the chunked transfer coding |  | A recipient MUST be able to parse the chunked transfer coding |
| (Section 4.1) because it plays a crucial role in framing messages |  | (Section 4.1) because it plays a crucial role in framing messages |
| when the payload body size is not known in advance. If chunked is |  | when the payload body size is not known in advance. A sender MUST |
| applied to a payload body, the sender MUST NOT apply chunked more |  | NOT apply chunked more than once to a message body (i.e., chunking an |
| than once (i.e., chunking an already chunked message is not allowed). |  | already chunked message is not allowed). If any transfer coding |
| If any transfer coding is applied to a request payload body, the |  | other than chunked is applied to a request payload body, the sender |
| sender MUST apply chunked as the final transfer coding to ensure that |  | MUST apply chunked as the final transfer coding to ensure that the |
| the message is properly framed. If any transfer coding is applied to |  | message is properly framed. If any transfer coding other than |
| a response payload body, the sender MUST either apply chunked as the |  | chunked is applied to a response payload body, the sender MUST either |
| final transfer coding or terminate the message by closing the |  | apply chunked as the final transfer coding or terminate the message |
| connection. |  | by closing the connection. |
| For example, |  | For example, |
| Transfer-Encoding: gzip, chunked |  | Transfer-Encoding: gzip, chunked |
| indicates that the payload body has been compressed using the gzip |  | indicates that the payload body has been compressed using the gzip |
| coding and then chunked using the chunked coding while forming the |  | coding and then chunked using the chunked coding while forming the |
| message body. |  | message body. |
| Unlike Content-Encoding (Section 3.1.2.1 of [Part2]), Transfer- |  | Unlike Content-Encoding (Section 3.1.2.1 of [Part2]), Transfer- |
| skipping to change at page 28, line 43 |  | skipping to change at page 29, line 31 |
| Transfer-Encoding MAY be sent in a response to a HEAD request or in a |  | Transfer-Encoding MAY be sent in a response to a HEAD request or in a |
| 304 (Not Modified) response (Section 4.1 of [Part4]) to a GET |  | 304 (Not Modified) response (Section 4.1 of [Part4]) to a GET |
| request, neither of which includes a message body, to indicate that |  | request, neither of which includes a message body, to indicate that |
| the origin server would have applied a transfer coding to the message |  | the origin server would have applied a transfer coding to the message |
| body if the request had been an unconditional GET. This indication |  | body if the request had been an unconditional GET. This indication |
| is not required, however, because any recipient on the response chain |  | is not required, however, because any recipient on the response chain |
| (including the origin server) can remove transfer codings when they |  | (including the origin server) can remove transfer codings when they |
| are not needed. |  | are not needed. |
|  |  | A server MUST NOT send a Transfer-Encoding header field in any |
|  |  | response with a status code of 1xx (Informational) or 204 (No |
|  |  | Content). A server MUST NOT send a Transfer-Encoding header field in |
|  |  | any 2xx (Successful) response to a CONNECT request (Section 4.3.6 of |
|  |  | [Part2]). |
| 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 52 |  | skipping to change at page 30, line 49 |
| A server MAY send a Content-Length header field in a 304 (Not |  | A server MAY send a Content-Length header field in a 304 (Not |
| Modified) response to a conditional GET request (Section 4.1 of |  | Modified) response to a conditional GET request (Section 4.1 of |
| [Part4]); a server MUST NOT send Content-Length in such a response |  | [Part4]); a server MUST NOT send Content-Length in such a response |
| unless its field-value equals the decimal number of octets that would |  | unless its field-value equals the decimal number of octets that would |
| have been sent in the payload body of a 200 (OK) response to the same |  | have been sent in the payload body of a 200 (OK) response to the same |
| request. |  | request. |
| A server MUST NOT send a Content-Length header field in any response |  | A server MUST NOT send a Content-Length header field in any response |
| with a status code of 1xx (Informational) or 204 (No Content). A |  | with a status code of 1xx (Informational) or 204 (No Content). A |
| server SHOULD NOT send a Content-Length header field in any 2xx |  | server MUST NOT send a Content-Length header field in any 2xx |
| (Successful) response to a CONNECT request (Section 4.3.6 of |  | (Successful) response to a CONNECT request (Section 4.3.6 of |
| [Part2]). |  | [Part2]). |
| Aside from the cases defined above, in the absence of Transfer- |  | Aside from the cases defined above, in the absence of Transfer- |
| Encoding, an origin server SHOULD send a Content-Length header field |  | Encoding, an origin server SHOULD send a Content-Length header field |
| when the payload body size is known prior to sending the complete |  | when the payload body size is known prior to sending the complete |
| header block. This will allow downstream recipients to measure |  | header section. This will allow downstream recipients to measure |
| transfer progress, know when a received message is complete, and |  | transfer progress, know when a received message is complete, and |
| potentially reuse the connection for additional requests. |  | potentially reuse the connection for additional requests. |
| Any Content-Length field value greater than or equal to zero is |  | Any Content-Length field value greater than or equal to zero is |
| valid. Since there is no predefined limit to the length of a |  | valid. Since there is no predefined limit to the length of a |
| payload, recipients SHOULD anticipate potentially large decimal |  | payload, a recipient 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.3). |  | overflows (Section 9.3). |
| If a message is received that has multiple Content-Length header |  | If a message is received that has multiple Content-Length header |
| fields with field-values consisting of the same decimal value, or a |  | fields with field-values consisting of the same decimal value, or a |
| single Content-Length header field with a field value containing a |  | single Content-Length header field with a field value containing a |
| list of identical decimal values (e.g., "Content-Length: 42, 42"), |  | list of identical decimal values (e.g., "Content-Length: 42, 42"), |
| indicating that duplicate Content-Length header fields have been |  | indicating that duplicate Content-Length header fields have been |
| generated or combined by an upstream message processor, then the |  | generated or combined by an upstream message processor, then the |
| recipient MUST either reject the message as invalid or replace the |  | recipient MUST either reject the message as invalid or replace the |
| duplicated field-values with a single valid Content-Length field |  | duplicated field-values with a single valid Content-Length field |
| containing that decimal value prior to determining the message body |  | containing that decimal value prior to determining the message body |
| length. |  | length or forwarding the message. |
| Note: HTTP's use of Content-Length for message framing differs |  | Note: HTTP's use of Content-Length for message framing differs |
| significantly from the same field's use in MIME, where it is an |  | significantly from the same field's use in MIME, where it is an |
| optional field used only within the "message/external-body" media- |  | optional field used only within the "message/external-body" media- |
| type. |  | 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): |
| skipping to change at page 31, line 30 |  | skipping to change at page 32, line 27 |
| Content-Length header field, the Transfer-Encoding overrides the |  | Content-Length header field, the Transfer-Encoding overrides the |
| Content-Length. Such a message might indicate an attempt to |  | Content-Length. Such a message might indicate an attempt to |
| perform request or response smuggling (bypass of security-related |  | perform request or response smuggling (bypass of security-related |
| checks on message routing or content) and thus ought to be |  | checks on message routing or content) and thus ought to be |
| handled as an error. A sender MUST remove the received Content- |  | handled as an error. A sender MUST remove the received Content- |
| Length field prior to forwarding such a message downstream. |  | Length field prior to forwarding such a message downstream. |
| 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 the |
| treated as an error to prevent request or response smuggling. If |  | recipient MUST treat it as an unrecoverable error to prevent |
| this is a request message, the server MUST respond with a 400 |  | request or response smuggling. If this is a request message, the |
| (Bad Request) status code and then close the connection. If this |  | server MUST respond with a 400 (Bad Request) status code and then |
| is a response message received by a proxy, the proxy MUST close |  | close the connection. If this is a response message received by |
| the connection to the server, discard the received response, and |  | a proxy, the proxy MUST close the connection to the server, |
| send a 502 (Bad Gateway) response to the client. If this is a |  | discard the received response, and send a 502 (Bad Gateway) |
| response message received by a user agent, it MUST be treated as |  | response to the client. If this is a response message received |
| an error by discarding the message and closing the connection. |  | by a user agent, the user agent MUST close the connection to the |
|  |  | server and discard the received response. |
| 5. If a valid Content-Length header field is present without |  | 5. If a valid Content-Length header field is present without |
| Transfer-Encoding, its decimal value defines the expected message |  | Transfer-Encoding, its decimal value defines the expected message |
| body length in octets. If the sender closes the connection or |  | body length in octets. If the sender closes the connection or |
| the recipient times out before the indicated number of octets are |  | the recipient times out before the indicated number of octets are |
| received, the recipient MUST consider the message to be |  | received, the recipient MUST consider the message to be |
| incomplete and close the connection. |  | incomplete and close the connection. |
| 6. If this is a request message and none of the above are true, then |  | 6. If this is a request message and none of the above are true, then |
| the message body length is zero (no message body is present). |  | the message body length is zero (no message body is present). |
| 7. Otherwise, this is a response message without a declared message |  | 7. Otherwise, this is a response message without a declared message |
| body length, so the message body length is determined by the |  | body length, so the message body length is determined by the |
| number of octets received prior to the server closing the |  | number of octets received prior to the server closing the |
| connection. |  | connection. |
| Since there is no way to distinguish a successfully completed, close- |  | Since there is no way to distinguish a successfully completed, close- |
| delimited message from a partially-received message interrupted by |  | delimited message from a partially-received message interrupted by |
| network failure, a server SHOULD use encoding or length-delimited |  | network failure, a server SHOULD generate encoding or length- |
| messages whenever possible. The close-delimiting feature exists |  | delimited messages whenever possible. The close-delimiting feature |
| primarily for backwards compatibility with HTTP/1.0. |  | exists primarily for backwards compatibility with HTTP/1.0. |
| A server MAY reject a request that contains a message body but not a |  | A server MAY reject a request that contains a message body but not a |
| Content-Length by responding with 411 (Length Required). |  | Content-Length by responding with 411 (Length Required). |
| Unless a transfer coding other than chunked has been applied, a |  | Unless a transfer coding other than chunked has been applied, a |
| client that sends a request containing a message body SHOULD use a |  | client that sends a request containing a message body SHOULD use a |
| valid Content-Length header field if the message body length is known |  | valid Content-Length header field if the message body length is known |
| in advance, rather than the chunked transfer coding, since some |  | in advance, rather than the chunked transfer coding, since some |
| existing services respond to chunked with a 411 (Length Required) |  | existing services respond to chunked with a 411 (Length Required) |
| status code even though they understand the chunked transfer coding. |  | status code even though they understand the chunked transfer coding. |
| skipping to change at page 33, line 5 |  | skipping to change at page 33, line 52 |
| A server that receives an incomplete request message, usually due to |  | A server that receives an incomplete request message, usually due to |
| a canceled request or a triggered time-out exception, MAY send an |  | a canceled request or a triggered time-out exception, MAY send an |
| error response prior to closing the connection. |  | error response prior to closing the connection. |
| A client that receives an incomplete response message, which can |  | A client that receives an incomplete response message, which can |
| occur when a connection is closed prematurely or when decoding a |  | occur when a connection is closed prematurely or when decoding a |
| supposedly chunked transfer coding fails, MUST record the message as |  | supposedly chunked transfer coding fails, MUST record the message as |
| incomplete. Cache requirements for incomplete responses are defined |  | incomplete. Cache requirements for incomplete responses are defined |
| in Section 3 of [Part6]. |  | in Section 3 of [Part6]. |
| If a response terminates in the middle of the header block (before |  | If a response terminates in the middle of the header section (before |
| the empty line is received) and the status code might rely on header |  | the empty line is received) and the status code might rely on header |
| fields to convey the full meaning of the response, then the client |  | fields to convey the full meaning of the response, then the client |
| cannot assume that meaning has been conveyed; the client might need |  | cannot assume that meaning has been conveyed; the client might need |
| to repeat the request in order to determine what action to take next. |  | to repeat the request in order to determine what action to take next. |
| A message body that uses the chunked transfer coding is incomplete if |  | A message body that uses the chunked transfer coding is incomplete if |
| the zero-sized chunk that terminates the encoding has not been |  | 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 coding nor Content-Length is terminated by closure of the |  | transfer coding nor Content-Length is terminated by closure of the |
| connection, and thus is considered complete regardless of the number |  | connection, and thus is considered complete regardless of the number |
| of message body octets received, provided that the header block was |  | of message body octets received, provided that the header section was |
| received intact. |  | received intact. |
| 3.5. Message Parsing Robustness |  | 3.5. Message Parsing Robustness |
| Older HTTP/1.0 user agent implementations might send an extra CRLF |  | Older HTTP/1.0 user agent implementations might send an extra CRLF |
| after a POST request as a workaround for some early server |  | after a POST request as a workaround for some early server |
| applications that failed to read message body content that was not |  | applications that failed to read message body content that was not |
| terminated by a line-ending. An HTTP/1.1 user agent MUST NOT preface |  | terminated by a line-ending. An HTTP/1.1 user agent MUST NOT preface |
| or follow a request with an extra CRLF. If terminating the request |  | or follow a request with an extra CRLF. If terminating the request |
| message body with a line-ending is desired, then the user agent MUST |  | message body with a line-ending is desired, then the user agent MUST |
| count the terminating CRLF octets as part of the message body length. |  | count the terminating CRLF octets as part of the message body length. |
| In the interest of robustness, servers SHOULD ignore at least one |  | In the interest of robustness, a server that is expecting to receive |
| empty line received where a request-line is expected. In other |  | and parse a request-line SHOULD ignore at least one empty line (CRLF) |
| words, if a server is reading the protocol stream at the beginning of |  | received prior to the request-line. |
| a message and receives a CRLF first, the server SHOULD ignore the |  |  |
| CRLF. |  |  |
| Although the line terminator for the start-line and header fields is |  | Although the line terminator for the start-line and header fields is |
| the sequence CRLF, recipients MAY recognize a single LF as a line |  | the sequence CRLF, a recipient MAY recognize a single LF as a line |
| terminator and ignore any preceding CR. |  | terminator and ignore any preceding CR. |
| Although the request-line and status-line grammar rules require that |  | Although the request-line and status-line grammar rules require that |
| each of the component elements be separated by a single SP octet, |  | each of the component elements be separated by a single SP octet, |
| recipients MAY instead parse on whitespace-delimited word boundaries |  | recipients MAY instead parse on whitespace-delimited word boundaries |
| and, aside from the CRLF terminator, treat any form of whitespace as |  | and, aside from the CRLF terminator, treat any form of whitespace as |
| the SP separator while ignoring preceding or trailing whitespace; |  | the SP separator while ignoring preceding or trailing whitespace; |
| such whitespace includes one or more of the following octets: SP, |  | such whitespace includes one or more of the following octets: SP, |
| HTAB, VT (%x0B), FF (%x0C), or bare CR. |  | HTAB, VT (%x0B), FF (%x0C), or bare CR. |
| skipping to change at page 34, line 30 |  | skipping to change at page 35, line 29 |
| transfer-extension = token *( OWS ";" OWS transfer-parameter ) |  | transfer-extension = token *( OWS ";" OWS transfer-parameter ) |
| Parameters are in the form of attribute/value pairs. |  | Parameters are in the form of attribute/value pairs. |
| transfer-parameter = attribute BWS "=" BWS value |  | transfer-parameter = attribute BWS "=" BWS value |
| attribute = token |  | attribute = token |
| value = word |  | value = word |
| All transfer-coding names are case-insensitive and ought to be |  | All transfer-coding names are case-insensitive and ought to be |
| registered within the HTTP Transfer Coding registry, as defined in |  | registered within the HTTP Transfer Coding registry, as defined in |
| Section 7.4. They are used in the TE (Section 4.3) and Transfer- |  | Section 8.4. They are used in the TE (Section 4.3) and Transfer- |
| Encoding (Section 3.3.1) header fields. |  | Encoding (Section 3.3.1) header fields. |
| 4.1. Chunked Transfer Coding |  | 4.1. Chunked Transfer Coding |
| The chunked transfer coding modifies the body of a message in order |  | The chunked transfer coding wraps the payload body in order to |
| to transfer it as a series of chunks, each with its own size |  | transfer it as a series of chunks, each with its own size indicator, |
| indicator, followed by an OPTIONAL trailer containing header fields. |  | followed by an OPTIONAL trailer containing header fields. Chunked |
| This allows dynamically generated content to be transferred along |  | enables content streams of unknown size to be transferred as a |
| with the information necessary for the recipient to verify that it |  | sequence of length-delimited buffers, which enables the sender to |
| has received the full message. |  | retain connection persistence and the recipient to know when it has |
|  |  | received the entire message. |
| chunked-body = *chunk |  | chunked-body = *chunk |
| last-chunk |  | last-chunk |
| trailer-part |  | trailer-part |
| CRLF |  | CRLF |
| chunk = chunk-size [ chunk-ext ] CRLF |  | chunk = chunk-size [ chunk-ext ] CRLF |
| chunk-data CRLF |  | chunk-data CRLF |
| chunk-size = 1*HEXDIG |  | chunk-size = 1*HEXDIG |
| last-chunk = 1*("0") [ chunk-ext ] CRLF |  | last-chunk = 1*("0") [ chunk-ext ] CRLF |
|  |  | chunk-data = 1*OCTET ; a sequence of chunk-size octets |
|  |  | The chunk-size field is a string of hex digits indicating the size of |
|  |  | the chunk-data in octets. The chunked transfer coding is complete |
|  |  | when a chunk with a chunk-size of zero is received, possibly followed |
|  |  | by a trailer, and finally terminated by an empty line. |
|  |  | A recipient MUST be able to parse and decode the chunked transfer |
|  |  | coding. |
|  |  | 4.1.1. Chunk Extensions |
|  |  | The chunked encoding allows each chunk to include zero or more chunk |
|  |  | extensions, immediately following the chunk-size, for the sake of |
|  |  | supplying per-chunk metadata (such as a signature or hash), mid- |
|  |  | message control information, or randomization of message body size. |
| chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-val ] ) |  | chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-val ] ) |
| chunk-ext-name = token |  | chunk-ext-name = token |
| chunk-ext-val = token / quoted-str-nf |  | chunk-ext-val = token / quoted-str-nf |
| chunk-data = 1*OCTET ; a sequence of chunk-size octets |  |  |
| trailer-part = *( header-field CRLF ) |  |  |
| quoted-str-nf = DQUOTE *( qdtext-nf / quoted-pair ) DQUOTE |  | quoted-str-nf = DQUOTE *( qdtext-nf / quoted-pair ) DQUOTE |
| ; like quoted-string, but disallowing line folding |  | ; like quoted-string, but disallowing line folding |
| qdtext-nf = HTAB / SP / %x21 / %x23-5B / %x5D-7E / obs-text |  | qdtext-nf = HTAB / SP / %x21 / %x23-5B / %x5D-7E / obs-text |
| Chunk extensions within the chunked transfer coding are deprecated. |  | The chunked encoding is specific to each connection and is likely to |
| Senders SHOULD NOT send chunk-ext. Definition of new chunk |  | be removed or recoded by each recipient (including intermediaries) |
| extensions is discouraged. |  | before any higher-level application would have a chance to inspect |
|  |  | the extensions. Hence, use of chunk extensions is generally limited |
|  |  | to specialized HTTP services such as "long polling" (where client and |
|  |  | server can have shared expectations regarding the use of chunk |
|  |  | extensions) or for padding within an end-to-end secured connection. |
| The chunk-size field is a string of hex digits indicating the size of |  | A recipient MUST ignore unrecognized chunk extensions. A server |
| the chunk-data in octets. The chunked transfer coding is complete |  | ought to limit the total length of chunk extensions received in a |
| when a chunk with a chunk-size of zero is received, possibly followed |  | request to an amount reasonable for the services provided, in the |
| by a trailer, and finally terminated by an empty line. |  | same way that it applies length limitations and timeouts for other |
|  |  | parts of a message, and generate an appropriate 4xx (Client Error) |
|  |  | response if that amount is exceeded. |
| 4.1.1. Trailer |  | 4.1.2. Chunked Trailer Part |
| A trailer allows the sender to include additional fields at the end |  | A trailer allows the sender to include additional fields at the end |
| of a chunked message in order to supply metadata that might be |  | of a chunked message in order to supply metadata that might be |
| dynamically generated while the message body is sent, such as a |  | dynamically generated while the message body is sent, such as a |
| message integrity check, digital signature, or post-processing |  | message integrity check, digital signature, or post-processing |
| status. The trailer MUST NOT contain fields that need to be known |  | status. The trailer fields are identical to header fields, except |
| before a recipient processes the body, such as Transfer-Encoding, |  | they are sent in a chunked trailer instead of the message's header |
| Content-Length, and Trailer. |  | section. |
| When a message includes a message body encoded with the chunked |  |  |
| transfer coding and the sender desires to send metadata in the form |  |  |
| of trailer fields at the end of the message, the sender SHOULD send a |  |  |
| Trailer header field before the message body to indicate which fields |  |  |
| will be present in the trailers. This allows the recipient to |  |  |
| prepare for receipt of that metadata before it starts processing the |  |  |
| body, which is useful if the message is being streamed and the |  |  |
| recipient wishes to confirm an integrity check on the fly. |  |  |
| Trailer = 1#field-name |  | trailer-part = *( header-field CRLF ) |
| If no Trailer header field is present, the sender of a chunked |  | A sender MUST NOT generate a trailer that contains a field which |
| message body SHOULD send an empty trailer. |  | needs to be known by the recipient before it can begin processing the |
|  |  | message body. For example, most recipients need to know the values |
|  |  | of Content-Encoding and Content-Type in order to select a content |
|  |  | handler, so placing those fields in a trailer would force the |
|  |  | recipient to buffer the entire body before it could begin, greatly |
|  |  | increasing user-perceived latency and defeating one of the main |
|  |  | advantages of using chunked to send data streams of unknown length. |
|  |  | A sender MUST NOT generate a trailer containing a Transfer-Encoding, |
|  |  | Content-Length, or Trailer field. |
| A server MUST send an empty trailer with the chunked transfer coding |  | A server MUST generate an empty trailer with the chunked transfer |
| unless at least one of the following is true: |  | coding unless at least one of the following is true: |
| 1. the request included a TE header field that indicates "trailers" |  | 1. the request included a TE header field that indicates "trailers" |
| is acceptable in the transfer coding of the response, as |  | is acceptable in the transfer coding of the response, as |
| described in Section 4.3; or, |  | described in Section 4.3; or, |
| 2. the trailer fields consist entirely of optional metadata and the |  | 2. the trailer fields consist entirely of optional metadata and the |
| recipient could use the message (in a manner acceptable to the |  | recipient could use the message (in a manner acceptable to the |
| server where the field originated) without receiving that |  | generating server) without receiving that metadata. In other |
| metadata. In other words, the server that generated the header |  | words, the generating server is willing to accept the possibility |
| field is willing to accept the possibility that the trailer |  | that the trailer fields might be silently discarded along the |
| fields might be silently discarded along the path to the client. |  | path to the client. |
| The above requirement prevents the need for an infinite buffer when a |  | The above requirement prevents the need for an infinite buffer when a |
| message is being received by an HTTP/1.1 (or later) proxy and |  | message is being received by an HTTP/1.1 (or later) proxy and |
| forwarded to an HTTP/1.0 recipient. |  | forwarded to an HTTP/1.0 recipient. |
| 4.1.2. Decoding chunked |  | 4.1.3. Decoding Chunked |
| A process for decoding the chunked transfer coding can be represented |  | A process for decoding the chunked transfer coding can be represented |
| in pseudo-code as: |  | in pseudo-code as: |
| length := 0 |  | length := 0 |
| read chunk-size, chunk-ext (if any), and CRLF |  | read chunk-size, chunk-ext (if any), and CRLF |
| while (chunk-size > 0) { |  | while (chunk-size > 0) { |
| read chunk-data and CRLF |  | read chunk-data and CRLF |
| append chunk-data to decoded-body |  | append chunk-data to decoded-body |
| length := length + chunk-size |  | length := length + chunk-size |
| skipping to change at page 36, line 50 |  | skipping to change at page 38, line 22 |
| } |  | } |
| read header-field |  | read header-field |
| while (header-field not empty) { |  | while (header-field not empty) { |
| append header-field to existing header fields |  | append header-field to existing header fields |
| read header-field |  | read header-field |
| } |  | } |
| Content-Length := length |  | Content-Length := length |
| Remove "chunked" from Transfer-Encoding |  | Remove "chunked" from Transfer-Encoding |
| Remove Trailer from existing header fields |  | Remove Trailer from existing header fields |
| All recipients MUST be able to receive and decode the chunked |  |  |
| transfer coding and MUST ignore chunk-ext extensions they do not |  |  |
| understand. |  |  |
| 4.2. Compression Codings |  | 4.2. Compression Codings |
| The codings defined below can be used to compress the payload of a |  | The codings defined below can be used to compress the payload of a |
| message. |  | message. |
| 4.2.1. Compress Coding |  | 4.2.1. Compress Coding |
| The "compress" coding is an adaptive Lempel-Ziv-Welch (LZW) coding |  | The "compress" coding is an adaptive Lempel-Ziv-Welch (LZW) coding |
| [Welch] that is commonly produced by the UNIX file compression |  | [Welch] that is commonly produced by the UNIX file compression |
| program "compress". Recipients SHOULD consider "x-compress" to be |  | program "compress". A recipient SHOULD consider "x-compress" to be |
| equivalent to "compress". |  | equivalent to "compress". |
| 4.2.2. Deflate Coding |  | 4.2.2. Deflate Coding |
| The "deflate" coding is a "zlib" data format [RFC1950] containing a |  | The "deflate" coding is a "zlib" data format [RFC1950] containing a |
| "deflate" compressed data stream [RFC1951] that uses a combination of |  | "deflate" compressed data stream [RFC1951] that uses a combination of |
| the Lempel-Ziv (LZ77) compression algorithm and Huffman coding. |  | the Lempel-Ziv (LZ77) compression algorithm and Huffman coding. |
| Note: Some incorrect implementations send the "deflate" compressed |  | Note: Some incorrect implementations send the "deflate" compressed |
| data without the zlib wrapper. |  | data without the zlib wrapper. |
| 4.2.3. Gzip Coding |  | 4.2.3. Gzip Coding |
| The "gzip" coding is an LZ77 coding with a 32 bit CRC that is |  | The "gzip" coding is an LZ77 coding with a 32 bit CRC that is |
| commonly produced by the gzip file compression program [RFC1952]. |  | commonly produced by the gzip file compression program [RFC1952]. A |
| Recipients SHOULD consider "x-gzip" to be equivalent to "gzip". |  | recipient SHOULD consider "x-gzip" to be equivalent to "gzip". |
| 4.3. TE |  | 4.3. TE |
| The "TE" header field in a request indicates what transfer codings, |  | The "TE" header field in a request indicates what transfer codings, |
| besides chunked, the client is willing to accept in response, and |  | besides chunked, the client is willing to accept in response, and |
| whether or not the client is willing to accept trailer fields in a |  | whether or not the client is willing to accept trailer fields in a |
| chunked transfer coding. |  | chunked transfer coding. |
| The TE field-value consists of a comma-separated list of transfer |  | The TE field-value consists of a comma-separated list of transfer |
| coding names, each allowing for optional parameters (as described in |  | coding names, each allowing for optional parameters (as described in |
| Section 4), and/or the keyword "trailers". Clients MUST NOT send the |  | Section 4), and/or the keyword "trailers". A client MUST NOT send |
| chunked transfer coding name in TE; chunked is always acceptable for |  | the chunked transfer coding name in TE; chunked is always acceptable |
| HTTP/1.1 recipients. |  | for HTTP/1.1 recipients. |
| TE = #t-codings |  | TE = #t-codings |
| t-codings = "trailers" / ( transfer-coding [ t-ranking ] ) |  | t-codings = "trailers" / ( transfer-coding [ t-ranking ] ) |
| t-ranking = OWS ";" OWS "q=" rank |  | t-ranking = OWS ";" OWS "q=" rank |
| rank = ( "0" [ "." 0*3DIGIT ] ) |  | rank = ( "0" [ "." 0*3DIGIT ] ) |
| / ( "1" [ "." 0*3("0") ] ) |  | / ( "1" [ "." 0*3("0") ] ) |
| Three examples of TE use are below. |  | Three examples of TE use are below. |
| TE: deflate |  | TE: deflate |
| TE: |  | TE: |
| TE: trailers, deflate;q=0.5 |  | TE: trailers, deflate;q=0.5 |
| The presence of the keyword "trailers" indicates that the client is |  | The presence of the keyword "trailers" indicates that the client is |
| willing to accept trailer fields in a chunked transfer coding, as |  | willing to accept trailer fields in a chunked transfer coding, as |
| defined in Section 4.1, on behalf of itself and any downstream |  | defined in Section 4.1.2, on behalf of itself and any downstream |
| clients. For requests from an intermediary, this implies that |  | clients. For requests from an intermediary, this implies that |
| either: (a) all downstream clients are willing to accept trailer |  | either: (a) all downstream clients are willing to accept trailer |
| fields in the forwarded response; or, (b) the intermediary will |  | fields in the forwarded response; or, (b) the intermediary will |
| attempt to buffer the response on behalf of downstream recipients. |  | attempt to buffer the response on behalf of downstream recipients. |
| Note that HTTP/1.1 does not define any means to limit the size of a |  | Note that HTTP/1.1 does not define any means to limit the size of a |
| chunked response such that an intermediary can be assured of |  | chunked response such that an intermediary can be assured of |
| buffering the entire response. |  | buffering the entire response. |
| When multiple transfer codings are acceptable, the client MAY rank |  | When multiple transfer codings are acceptable, the client MAY rank |
| the codings by preference using a case-insensitive "q" parameter |  | the codings by preference using a case-insensitive "q" parameter |
| skipping to change at page 38, line 37 |  | skipping to change at page 40, line 5 |
| If the TE field-value is empty or if no TE field is present, the only |  | If the TE field-value is empty or if no TE field is present, the only |
| acceptable transfer coding is chunked. A message with no transfer |  | acceptable transfer coding is chunked. A message with no transfer |
| coding is always acceptable. |  | coding is always acceptable. |
| Since the TE header field only applies to the immediate connection, a |  | Since the TE header field only applies to the immediate connection, a |
| sender of TE MUST also send a "TE" connection option within the |  | sender of TE MUST also send a "TE" connection option within the |
| Connection header field (Section 6.1) in order to prevent the TE |  | Connection header field (Section 6.1) in order to prevent the TE |
| field from being forwarded by intermediaries that do not support its |  | field from being forwarded by intermediaries that do not support its |
| semantics. |  | semantics. |
|  |  | 4.4. Trailer |
|  |  | When a message includes a message body encoded with the chunked |
|  |  | transfer coding and the sender desires to send metadata in the form |
|  |  | of trailer fields at the end of the message, the sender SHOULD |
|  |  | generate a Trailer header field before the message body to indicate |
|  |  | which fields will be present in the trailers. This allows the |
|  |  | recipient to prepare for receipt of that metadata before it starts |
|  |  | processing the body, which is useful if the message is being streamed |
|  |  | and the recipient wishes to confirm an integrity check on the fly. |
|  |  | Trailer = 1#field-name |
| 5. Message Routing |  | 5. Message Routing |
| HTTP request message routing is determined by each client based on |  | HTTP request message routing is determined by each client based on |
| the target resource, the client's proxy configuration, and |  | the target resource, the client's proxy configuration, and |
| establishment or reuse of an inbound connection. The corresponding |  | establishment or reuse of an inbound connection. The corresponding |
| response routing follows the same connection chain back to the |  | response routing follows the same connection chain back to the |
| client. |  | client. |
| 5.1. Identifying a Target Resource |  | 5.1. Identifying a Target Resource |
| skipping to change at page 40, line 24 |  | skipping to change at page 41, line 52 |
| origin-form |  | origin-form |
| The most common form of request-target is the origin-form. When |  | The most common form of request-target is the origin-form. When |
| making a request directly to an origin server, other than a CONNECT |  | making a request directly to an origin server, other than a CONNECT |
| or server-wide OPTIONS request (as detailed below), a client MUST |  | or server-wide OPTIONS request (as detailed below), a client MUST |
| send only the absolute path and query components of the target URI as |  | send only the absolute path and query components of the target URI as |
| the request-target. If the target URI's path component is empty, |  | the request-target. If the target URI's path component is empty, |
| then the client MUST send "/" as the path within the origin-form of |  | then the client MUST send "/" as the path within the origin-form of |
| request-target. A Host header field is also sent, as defined in |  | request-target. A Host header field is also sent, as defined in |
| Section 5.4, containing the target URI's authority component |  | Section 5.4. |
| (excluding any userinfo). |  |  |
| For example, a client wishing to retrieve a representation of the |  | For example, a client wishing to retrieve a representation of the |
| resource identified as |  | resource identified as |
| http://www.example.org/where?q=now |  | http://www.example.org/where?q=now |
| directly from the origin server would open (or reuse) a TCP |  | directly from the origin server would open (or reuse) a TCP |
| connection to port 80 of the host "www.example.org" and send the |  | connection to port 80 of the host "www.example.org" and send the |
| lines: |  | lines: |
| skipping to change at page 41, line 8 |  | skipping to change at page 42, line 35 |
| make the same request on the client's behalf to either the next |  | make the same request on the client's behalf to either the next |
| inbound proxy server or directly to the origin server indicated by |  | inbound proxy server or directly to the origin server indicated by |
| the request-target. Requirements on such "forwarding" of messages |  | the request-target. Requirements on such "forwarding" of messages |
| are defined in Section 5.7. |  | are defined in Section 5.7. |
| An example absolute-form of request-line would be: |  | An example absolute-form of request-line would be: |
| GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1 |  | GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1 |
| To allow for transition to the absolute-form for all requests in some |  | To allow for transition to the absolute-form for all requests in some |
| future version of HTTP, HTTP/1.1 servers MUST accept the absolute- |  | future version of HTTP, a server MUST accept the absolute-form in |
| form in requests, even though HTTP/1.1 clients will only send them in |  | requests, even though HTTP/1.1 clients will only send them in |
| requests to proxies. |  | requests to proxies. |
| authority-form |  | authority-form |
| The authority-form of request-target is only used for CONNECT |  | The authority-form of request-target is only used for CONNECT |
| requests (Section 4.3.6 of [Part2]). When making a CONNECT request |  | requests (Section 4.3.6 of [Part2]). When making a CONNECT request |
| to establish a tunnel through one or more proxies, a client MUST send |  | to establish a tunnel through one or more proxies, a client MUST send |
| only the target URI's authority component (excluding any userinfo) as |  | only the target URI's authority component (excluding any userinfo and |
| the request-target. For example, |  | its "@" delimiter) as the request-target. For example, |
| CONNECT www.example.com:80 HTTP/1.1 |  | CONNECT www.example.com:80 HTTP/1.1 |
| asterisk-form |  | asterisk-form |
| The asterisk-form of request-target is only used for a server-wide |  | The asterisk-form of request-target is only used for a server-wide |
| OPTIONS request (Section 4.3.7 of [Part2]). When a client wishes to |  | OPTIONS request (Section 4.3.7 of [Part2]). When a client wishes to |
| request OPTIONS for the server as a whole, as opposed to a specific |  | request OPTIONS for the server as a whole, as opposed to a specific |
| named resource of that server, the client MUST send only "*" (%x2A) |  | named resource of that server, the client MUST send only "*" (%x2A) |
| as the request-target. For example, |  | as the request-target. For example, |
| skipping to change at page 42, line 5 |  | skipping to change at page 43, line 32 |
| OPTIONS * HTTP/1.1 |  | OPTIONS * HTTP/1.1 |
| Host: www.example.org:8001 |  | Host: www.example.org:8001 |
| after connecting to port 8001 of host "www.example.org". |  | after connecting to port 8001 of host "www.example.org". |
| 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. |
| critical information for handling a request, it SHOULD be sent as the |  |  |
| first header field following the request-line. |  |  |
| Host = uri-host [ ":" port ] ; Section 2.7.1 |  | Host = uri-host [ ":" port ] ; Section 2.7.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 a |
| the Host field-value MUST be identical to that authority component |  | client MUST send a field-value for Host that is identical to that |
| after excluding any userinfo (Section 2.7.1). If the authority |  | authority component, excluding any userinfo subcomponent and its "@" |
| component is missing or undefined for the target URI, then the Host |  | delimiter (Section 2.7.1). If the authority component is missing or |
| header field MUST be sent with an empty field-value. |  | undefined for the target URI, then a client MUST send a Host header |
|  |  | field with an empty field-value. |
|  |  | Since the Host field-value is critical information for handling a |
|  |  | request, a user agent SHOULD generate Host as the first header field |
|  |  | following the request-line. |
| 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 |  | A client MUST send a Host header field in an HTTP/1.1 request even if |
| request-target is in the absolute-form, since this allows the Host |  | the request-target is in the absolute-form, since this allows the |
| information to be forwarded through ancient HTTP/1.0 proxies that |  | Host information to be forwarded through ancient HTTP/1.0 proxies |
| might not have implemented Host. |  | that might not have implemented Host. |
| When a proxy receives a request with an absolute-form of request- |  | When a proxy receives a request with an absolute-form of request- |
| target, the proxy MUST ignore the received Host header field (if any) |  | target, the proxy MUST ignore the received Host header field (if any) |
| and instead replace it with the host information of the request- |  | and instead replace it with the host information of the request- |
| target. If the proxy forwards the request, it MUST generate a new |  | target. A proxy that forwards such a request MUST generate a new |
| Host field-value based on the received request-target rather than |  | Host field-value based on the received request-target rather than |
| forward the received Host field-value. |  | forward the received Host field-value. |
| Since the Host header field acts as an application-level routing |  | Since the Host header field acts as an application-level routing |
| mechanism, it is a frequent target for malware seeking to poison a |  | mechanism, it is a frequent target for malware seeking to poison a |
| shared cache or redirect a request to an unintended server. An |  | shared cache or redirect a request to an unintended server. An |
| interception proxy is particularly vulnerable if it relies on the |  | interception proxy is particularly vulnerable if it relies on the |
| Host field-value for redirecting requests to internal servers, or for |  | Host field-value for redirecting requests to internal servers, or for |
| use as a cache key in a shared cache, without first verifying that |  | use as a cache key in a shared cache, without first verifying that |
| the intercepted connection is targeting a valid IP address for that |  | the intercepted connection is targeting a valid IP address for that |
| skipping to change at page 44, line 51 |  | skipping to change at page 46, line 32 |
| As described in Section 2.3, intermediaries can serve a variety of |  | As described in Section 2.3, intermediaries can serve a variety of |
| roles in the processing of HTTP requests and responses. Some |  | roles in the processing of HTTP requests and responses. Some |
| intermediaries are used to improve performance or availability. |  | intermediaries are used to improve performance or availability. |
| Others are used for access control or to filter content. Since an |  | Others are used for access control or to filter content. Since an |
| HTTP stream has characteristics similar to a pipe-and-filter |  | HTTP stream has characteristics similar to a pipe-and-filter |
| architecture, there are no inherent limits to the extent an |  | architecture, there are no inherent limits to the extent an |
| intermediary can enhance (or interfere) with either direction of the |  | intermediary can enhance (or interfere) with either direction of the |
| stream. |  | stream. |
| Intermediaries that forward a message MUST implement the Connection |  | An intermediary not acting as a tunnel MUST implement the Connection |
| header field, as specified in Section 6.1, to exclude fields that are |  | header field, as specified in Section 6.1, and exclude fields from |
| only intended for the incoming connection. |  | being forwarded that are only intended for the incoming connection. |
| In order to avoid request loops, a proxy that forwards requests to |  | An intermediary MUST NOT forward a message to itself unless it is |
| other proxies MUST be able to recognize and exclude all of its own |  | protected from an infinite request loop. In general, an intermediary |
| server names, including any aliases, local variations, or literal IP |  | ought to recognize its own server names, including any aliases, local |
| addresses. |  | variations, or literal IP addresses, and respond to such requests |
|  |  | directly. |
| 5.7.1. Via |  | 5.7.1. Via |
| The "Via" header field indicates the presence of intermediate |  | The "Via" header field indicates the presence of intermediate |
| protocols and recipients between the user agent and the server (on |  | protocols and recipients between the user agent and the server (on |
| requests) or between the origin server and the client (on responses), |  | requests) or between the origin server and the client (on responses), |
| similar to the "Received" header field in email (Section 3.6.7 of |  | similar to the "Received" header field in email (Section 3.6.7 of |
| [RFC5322]). Via can be used for tracking message forwards, avoiding |  | [RFC5322]). Via can be used for tracking message forwards, avoiding |
| request loops, and identifying the protocol capabilities of senders |  | request loops, and identifying the protocol capabilities of senders |
| along the request/response chain. |  | along the request/response chain. |
| skipping to change at page 46, line 4 |  | skipping to change at page 47, line 36 |
| capabilities of the request/response chain such that they remain |  | capabilities of the request/response chain such that they remain |
| visible to downstream recipients; this can be useful for determining |  | visible to downstream recipients; this can be useful for determining |
| what backwards-incompatible features might be safe to use in |  | what backwards-incompatible features might be safe to use in |
| response, or within a later request, as described in Section 2.6. |  | response, or within a later request, as described in Section 2.6. |
| For brevity, the protocol-name is omitted when the received protocol |  | For brevity, the protocol-name is omitted when the received protocol |
| is HTTP. |  | is HTTP. |
| The received-by field is normally the host and optional port number |  | The received-by field is normally the host and optional port number |
| of a recipient server or client that subsequently forwarded the |  | of a recipient server or client that subsequently forwarded the |
| message. However, if the real host is considered to be sensitive |  | message. However, if the real host is considered to be sensitive |
| information, it MAY be replaced by a pseudonym. If the port is not |  | information, a sender MAY replace it with a pseudonym. If a port is |
| given, it MAY be assumed to be the default port of the received- |  | not provided, a recipient MAY interpret that as meaning it was |
| protocol. |  | received on the default TCP port, if any, for the received-protocol. |
| Comments MAY be used in the Via header field to identify the software |  | A sender MAY generate comments in the Via header field to identify |
| of each recipient, analogous to the User-Agent and Server header |  | the software of each recipient, analogous to the User-Agent and |
| fields. However, all comments in the Via field are optional and MAY |  | Server header fields. However, all comments in the Via field are |
| be removed by any recipient prior to forwarding the message. |  | optional and a recipient MAY remove them prior to forwarding the |
|  |  | message. |
| For example, a request message could be sent from an HTTP/1.0 user |  | For example, a request message could be sent from an HTTP/1.0 user |
| agent to an internal proxy code-named "fred", which uses HTTP/1.1 to |  | agent to an internal proxy code-named "fred", which uses HTTP/1.1 to |
| forward the request to a public proxy at p.example.net, which |  | forward the request to a public proxy at p.example.net, which |
| completes the request by forwarding it to the origin server at |  | completes the request by forwarding it to the origin server at |
| www.example.com. The request received by www.example.com would then |  | www.example.com. The request received by www.example.com would then |
| have the following Via header field: |  | have the following Via header field: |
| Via: 1.0 fred, 1.1 p.example.net |  | Via: 1.0 fred, 1.1 p.example.net |
| A proxy or gateway used as a portal through a network firewall SHOULD |  | An intermediary used as a portal through a network firewall SHOULD |
| NOT forward the names and ports of hosts within the firewall region |  | NOT forward the names and ports of hosts within the firewall region |
| unless it is explicitly enabled to do so. If not enabled, the |  | unless it is explicitly enabled to do so. If not enabled, such an |
| received-by host of any host behind the firewall SHOULD be replaced |  | intermediary SHOULD replace each received-by host of any host behind |
| by an appropriate pseudonym for that host. |  | the firewall by an appropriate pseudonym for that host. |
| A proxy or gateway MAY combine an ordered subsequence of Via header |  | An intermediary MAY combine an ordered subsequence of Via header |
| field entries into a single such entry if the entries have identical |  | field entries into a single such entry if the entries have identical |
| received-protocol values. For example, |  | received-protocol values. For example, |
| Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy |  | Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy |
| could be collapsed to |  | could be collapsed to |
| Via: 1.0 ricky, 1.1 mertz, 1.0 lucy |  | Via: 1.0 ricky, 1.1 mertz, 1.0 lucy |
| Senders SHOULD NOT combine multiple entries unless they are all under |  | A sender SHOULD NOT combine multiple entries unless they are all |
| the same organizational control and the hosts have already been |  | under the same organizational control and the hosts have already been |
| replaced by pseudonyms. Senders MUST NOT combine entries that have |  | replaced by pseudonyms. A sender MUST NOT combine entries that have |
| different received-protocol values. |  | different received-protocol values. |
| 5.7.2. Transformations |  | 5.7.2. Transformations |
| Some intermediaries include features for transforming messages and |  | Some intermediaries include features for transforming messages and |
| their payloads. A transforming proxy might, for example, convert |  | their payloads. A transforming proxy might, for example, convert |
| between image formats in order to save cache space or to reduce the |  | between image formats in order to save cache space or to reduce the |
| amount of traffic on a slow link. However, operational problems |  | amount of traffic on a slow link. However, operational problems |
| might occur when these transformations are applied to payloads |  | might occur when these transformations are applied to payloads |
| intended for critical applications, such as medical imaging or |  | intended for critical applications, such as medical imaging or |
| skipping to change at page 47, line 30 |  | skipping to change at page 49, line 14 |
| application or removal of a transfer coding (Section 4). |  | application or removal of a transfer coding (Section 4). |
| A non-transforming proxy MUST NOT modify the message payload (Section |  | A non-transforming proxy MUST NOT modify the message payload (Section |
| 3.3 of [Part2]). A transforming proxy MUST NOT modify the payload of |  | 3.3 of [Part2]). A transforming proxy MUST NOT modify the payload of |
| a message that contains the no-transform cache-control directive. |  | a message that contains the no-transform cache-control directive. |
| A transforming proxy MAY transform the payload of a message that does |  | A transforming proxy MAY transform the payload of a message that does |
| not contain the no-transform cache-control directive; if the payload |  | not contain the no-transform cache-control directive; if the payload |
| is transformed, the transforming proxy MUST add a Warning header |  | is transformed, the transforming proxy MUST add a Warning header |
| field with the warn-code of 214 ("Transformation Applied") if one |  | field with the warn-code of 214 ("Transformation Applied") if one |
| does not already appear in the message (see Section 7.5 of [Part6]). |  | does not already appear in the message (see Section 5.5 of [Part6]). |
| If the payload of a 200 (OK) response is transformed, the |  | If the payload of a 200 (OK) response is transformed, the |
| transforming proxy can also inform downstream recipients that a |  | transforming proxy can also inform downstream recipients that a |
| transformation has been applied by changing the response status code |  | transformation has been applied by changing the response status code |
| to 203 (Non-Authoritative Information) (Section 6.3.4 of [Part2]). |  | to 203 (Non-Authoritative Information) (Section 6.3.4 of [Part2]). |
| 6. Connection Management |  | 6. Connection Management |
| HTTP messaging is independent of the underlying transport or session- |  | HTTP messaging is independent of the underlying transport or session- |
| layer connection protocol(s). HTTP only presumes a reliable |  | layer connection protocol(s). HTTP only presumes a reliable |
| transport with in-order delivery of requests and the corresponding |  | transport with in-order delivery of requests and the corresponding |
| skipping to change at page 48, line 51 |  | skipping to change at page 50, line 34 |
| The Connection header field's value has the following grammar: |  | The Connection header field's value has the following grammar: |
| Connection = 1#connection-option |  | Connection = 1#connection-option |
| connection-option = token |  | connection-option = token |
| Connection options are case-insensitive. |  | Connection options are case-insensitive. |
| A sender MUST NOT send a connection option corresponding to a header |  | A sender MUST NOT send a connection option corresponding to a header |
| field that is intended for all recipients of the payload. For |  | field that is intended for all recipients of the payload. For |
| example, Cache-Control is never appropriate as a connection option |  | example, Cache-Control is never appropriate as a connection option |
| (Section 7.2 of [Part6]). |  | (Section 5.2 of [Part6]). |
| The connection options do not have to correspond to a header field |  | The connection options do not have to correspond to a header field |
| present in the message, since a connection-specific header field |  | present in the message, since a connection-specific header field |
| might not be needed if there are no parameters associated with that |  | might not be needed if there are no parameters associated with that |
| connection option. Recipients that trigger certain connection |  | connection option. Recipients that trigger certain connection |
| behavior based on the presence of connection options MUST do so based |  | behavior based on the presence of connection options MUST do so based |
| on the presence of the connection-option rather than only the |  | on the presence of the connection-option rather than only the |
| presence of the optional header field. In other words, if the |  | presence of the optional header field. In other words, if the |
| connection option is received as a header field but not indicated |  | connection option is received as a header field but not indicated |
| within the Connection field-value, then the recipient MUST ignore the |  | within the Connection field-value, then the recipient MUST ignore the |
| skipping to change at page 49, line 33 |  | skipping to change at page 51, line 16 |
| since it would be unwise for senders to use that field-name for |  | since it would be unwise for senders to use that field-name for |
| anything else. |  | anything else. |
| The "close" connection option is defined for a sender to signal that |  | The "close" connection option is defined for a sender to signal that |
| this connection will be closed after completion of the response. For |  | this connection will be closed after completion of the response. For |
| example, |  | example, |
| Connection: close |  | Connection: close |
| in either the request or the response header fields indicates that |  | in either the request or the response header fields indicates that |
| the connection MUST be closed after the current request/response is |  | the sender is going to close the connection after the current |
| complete (Section 6.6). |  | request/response is complete (Section 6.6). |
| A client that does not support persistent connections MUST send the |  | A client that does not support persistent connections MUST send the |
| "close" connection option in every request message. |  | "close" connection option in every request message. |
| A server that does not support persistent connections MUST send the |  | A server that does not support persistent connections MUST send the |
| "close" connection option in every response message that does not |  | "close" connection option in every response message that does not |
| have a 1xx (Informational) status code. |  | have a 1xx (Informational) status code. |
| 6.2. Establishment |  | 6.2. Establishment |
| skipping to change at page 50, line 33 |  | skipping to change at page 52, line 17 |
| o The connection will close after the current response. |  | o The connection will close after the current response. |
| A server MAY assume that an HTTP/1.1 client intends to maintain a |  | A server MAY assume that an HTTP/1.1 client intends to maintain a |
| persistent connection until a close connection option is received in |  | persistent connection until a close connection option is received in |
| a request. |  | a request. |
| A client MAY reuse a persistent connection until it sends or receives |  | A client MAY reuse a persistent connection until it sends or receives |
| a close connection option or receives an HTTP/1.0 response without a |  | a close connection option or receives an HTTP/1.0 response without a |
| "keep-alive" connection option. |  | "keep-alive" connection option. |
| In order to remain persistent, all messages on a connection MUST have |  | In order to remain persistent, all messages on a connection need to |
| a self-defined message length (i.e., one not defined by closure of |  | have a self-defined message length (i.e., one not defined by closure |
| the connection), as described in Section 3.3. A server MUST read the |  | of the connection), as described in Section 3.3. A server MUST read |
| entire request message body or close the connection after sending its |  | the entire request message body or close the connection after sending |
| response, since otherwise the remaining data on a persistent |  | its response, since otherwise the remaining data on a persistent |
| connection would be misinterpreted as the next request. Likewise, a |  | connection would be misinterpreted as the next request. Likewise, a |
| client MUST read the entire response message body if it intends to |  | client MUST read the entire response message body if it intends to |
| reuse the same connection for a subsequent request. |  | reuse the same connection for a subsequent request. |
| A proxy server MUST NOT maintain a persistent connection with an |  | A proxy server MUST NOT maintain a persistent connection with an |
| HTTP/1.0 client (see Section 19.7.1 of [RFC2068] for information and |  | HTTP/1.0 client (see Section 19.7.1 of [RFC2068] for information and |
| discussion of the problems with the Keep-Alive header field |  | discussion of the problems with the Keep-Alive header field |
| implemented by many HTTP/1.0 clients). |  | implemented by many HTTP/1.0 clients). |
| Clients and servers SHOULD NOT assume that a persistent connection is |  | Clients and servers SHOULD NOT assume that a persistent connection is |
| skipping to change at page 51, line 30 |  | skipping to change at page 53, line 13 |
| means to detect that the original request was never applied. For |  | means to detect that the original request was never applied. For |
| example, a user agent that knows (through design or configuration) |  | example, a user agent that knows (through design or configuration) |
| that a POST request to a given resource is safe can repeat that |  | that a POST request to a given resource is safe can repeat that |
| request automatically. Likewise, a user agent designed specifically |  | request automatically. Likewise, a user agent designed specifically |
| to operate on a version control repository might be able to recover |  | to operate on a version control repository might be able to recover |
| from partial failure conditions by checking the target resource |  | from partial failure conditions by checking the target resource |
| revision(s) after a failed connection, reverting or fixing any |  | revision(s) after a failed connection, reverting or fixing any |
| changes that were partially applied, and then automatically retrying |  | changes that were partially applied, and then automatically retrying |
| the requests that failed. |  | the requests that failed. |
| An automatic retry SHOULD NOT be repeated if it fails. |  | A client SHOULD NOT automatically retry a failed automatic retry. |
| 6.3.2. Pipelining |  | 6.3.2. Pipelining |
| A client that supports persistent connections MAY "pipeline" its |  | A client that supports persistent connections MAY "pipeline" its |
| requests (i.e., send multiple requests without waiting for each |  | requests (i.e., send multiple requests without waiting for each |
| response). A server MAY process a sequence of pipelined requests in |  | response). A server MAY process a sequence of pipelined requests in |
| parallel if they all have safe methods (Section 4.2.1 of [Part2]), |  | parallel if they all have safe methods (Section 4.2.1 of [Part2]), |
| but MUST send the corresponding responses in the same order that the |  | but MUST send the corresponding responses in the same order that the |
| requests were received. |  | requests were received. |
| A client that pipelines requests MUST be prepared to retry those |  | A client that pipelines requests SHOULD retry unanswered requests if |
| requests if the connection closes before it receives all of the |  | the connection closes before it receives all of the corresponding |
| corresponding responses. A client that assumes a persistent |  | responses. When retrying pipelined requests after a failed |
| connection and pipelines immediately after connection establishment |  | connection (a connection not explicitly closed by the server in its |
| MUST NOT pipeline on a retry connection until it knows the connection |  | last complete response), a client MUST NOT pipeline immediately after |
| is persistent. |  | connection establishment, since the first remaining request in the |
|  |  | prior pipeline might have caused an error response that can be lost |
|  |  | again if multiple requests are sent on a prematurely closed |
|  |  | connection (see the TCP reset problem described in Section 6.6). |
| Idempotent methods (Section 4.2.2 of [Part2]) are significant to |  | Idempotent methods (Section 4.2.2 of [Part2]) are significant to |
| pipelining because they can be automatically retried after a |  | pipelining because they can be automatically retried after a |
| connection failure. A user agent SHOULD NOT pipeline requests after |  | connection failure. A user agent SHOULD NOT pipeline requests after |
| a non-idempotent method until the final response status code for that |  | a non-idempotent method, until the final response status code for |
| method has been received, unless the user agent has a means to detect |  | that method has been received, unless the user agent has a means to |
| and recover from partial failure conditions involving the pipelined |  | detect and recover from partial failure conditions involving the |
| sequence. |  | pipelined sequence. |
| An intermediary that receives pipelined requests MAY pipeline those |  | An intermediary that receives pipelined requests MAY pipeline those |
| requests when forwarding them inbound, since it can rely on the |  | requests when forwarding them inbound, since it can rely on the |
| outbound user agent(s) to determine what requests can be safely |  | outbound user agent(s) to determine what requests can be safely |
| pipelined. If the inbound connection fails before receiving a |  | pipelined. If the inbound connection fails before receiving a |
| response, the pipelining intermediary MAY attempt to retry a sequence |  | response, the pipelining intermediary MAY attempt to retry a sequence |
| of requests that have yet to receive a response if the requests all |  | of requests that have yet to receive a response if the requests all |
| have idempotent methods; otherwise, the pipelining intermediary |  | have idempotent methods; otherwise, the pipelining intermediary |
| SHOULD forward any received responses and then close the |  | SHOULD forward any received responses and then close the |
| corresponding outbound connection(s) so that the outbound user |  | corresponding outbound connection(s) so that the outbound user |
| agent(s) can recover accordingly. |  | agent(s) can recover accordingly. |
| 6.4. Concurrency |  | 6.4. Concurrency |
| Clients SHOULD limit the number of simultaneous connections that they |  | A client SHOULD limit the number of simultaneous open connections |
| maintain to a given server. |  | that it maintains to a given server. |
| Previous revisions of HTTP gave a specific number of connections as a |  | Previous revisions of HTTP gave a specific number of connections as a |
| ceiling, but this was found to be impractical for many applications. |  | ceiling, but this was found to be impractical for many applications. |
| As a result, this specification does not mandate a particular maximum |  | As a result, this specification does not mandate a particular maximum |
| number of connections, but instead encourages clients to be |  | number of connections, but instead encourages clients to be |
| conservative when opening multiple connections. |  | conservative when opening multiple connections. |
| Multiple connections are typically used to avoid the "head-of-line |  | Multiple connections are typically used to avoid the "head-of-line |
| blocking" problem, wherein a request that takes significant server- |  | blocking" problem, wherein a request that takes significant server- |
| side processing and/or has a large payload blocks subsequent requests |  | side processing and/or has a large payload blocks subsequent requests |
| skipping to change at page 52, line 48 |  | skipping to change at page 54, line 35 |
| 6.5. Failures and Time-outs |  | 6.5. Failures and Time-outs |
| Servers will usually have some time-out value beyond which they will |  | Servers will usually have some time-out value beyond which they will |
| no longer maintain an inactive connection. Proxy servers might make |  | no longer maintain an inactive connection. Proxy servers might make |
| this a higher value since it is likely that the client will be making |  | this a higher value since it is likely that the client will be making |
| more connections through the same server. The use of persistent |  | more connections through the same server. The use of persistent |
| connections places no requirements on the length (or existence) of |  | connections places no requirements on the length (or existence) of |
| this time-out for either the client or the server. |  | this time-out for either the client or the server. |
| When a client or server wishes to time-out it SHOULD issue a graceful |  | A client or server that wishes to time-out SHOULD issue a graceful |
| close on the transport connection. Clients and servers SHOULD both |  | close on the connection. Implementations SHOULD constantly monitor |
| constantly watch for the other side of the transport close, and |  | open connections for a received closure signal and respond to it as |
| respond to it as appropriate. If a client or server does not detect |  | appropriate, since prompt closure of both sides of a connection |
| the other side's close promptly it could cause unnecessary resource |  | enables allocated system resources to be reclaimed. |
| drain on the network. |  |  |
| A client, server, or proxy MAY close the transport connection at any |  | A client, server, or proxy MAY close the transport connection at any |
| time. For example, a client might have started to send a new request |  | time. For example, a client might have started to send a new request |
| at the same time that the server has decided to close the "idle" |  | at the same time that the server has decided to close the "idle" |
| connection. From the server's point of view, the connection is being |  | connection. From the server's point of view, the connection is being |
| closed while it was idle, but from the client's point of view, a |  | closed while it was idle, but from the client's point of view, a |
| request is in progress. |  | request is in progress. |
| Servers SHOULD maintain persistent connections and allow the |  | A server SHOULD sustain persistent connections, when possible, and |
| underlying transport's flow control mechanisms to resolve temporary |  | allow the underlying transport's flow control mechanisms to resolve |
| overloads, rather than terminate connections with the expectation |  | temporary overloads, rather than terminate connections with the |
| that clients will retry. The latter technique can exacerbate network |  | expectation that clients will retry. The latter technique can |
| congestion. |  | exacerbate network congestion. |
| A client sending a message body SHOULD monitor the network connection |  | A client sending a message body SHOULD monitor the network connection |
| for an error response while it is transmitting the request. If the |  | for an error response while it is transmitting the request. If the |
| client sees an error response, it SHOULD immediately cease |  | client sees a response that indicates the server does not wish to |
| transmitting the body and close the connection. |  | receive the message body and is closing the connection, the client |
|  |  | SHOULD immediately cease transmitting the body and close its side of |
|  |  | the connection. |
| 6.6. Tear-down |  | 6.6. Tear-down |
| The Connection header field (Section 6.1) provides a "close" |  | The Connection header field (Section 6.1) provides a "close" |
| connection option that a sender SHOULD send when it wishes to close |  | connection option that a sender SHOULD send when it wishes to close |
| the connection after the current request/response pair. |  | the connection after the current request/response pair. |
| A client that sends a close connection option MUST NOT send further |  | A client that sends a close connection option MUST NOT send further |
| requests on that connection (after the one containing close) and MUST |  | requests on that connection (after the one containing close) and MUST |
| close the connection after reading the final response message |  | close the connection after reading the final response message |
| skipping to change at page 54, line 48 |  | skipping to change at page 56, line 34 |
| Upgrade = 1#protocol |  | Upgrade = 1#protocol |
| protocol = protocol-name ["/" protocol-version] |  | protocol = protocol-name ["/" protocol-version] |
| protocol-name = token |  | protocol-name = token |
| protocol-version = token |  | protocol-version = token |
| A server that sends a 101 (Switching Protocols) response MUST send an |  | A server that sends a 101 (Switching Protocols) response MUST send an |
| Upgrade header field to indicate the new protocol(s) to which the |  | Upgrade header field to indicate the new protocol(s) to which the |
| connection is being switched; if multiple protocol layers are being |  | connection is being switched; if multiple protocol layers are being |
| switched, the new protocols MUST be listed in layer-ascending order. |  | switched, the sender MUST list the protocols in layer-ascending |
| A server MUST NOT switch to a protocol that was not indicated by the |  | order. A server MUST NOT switch to a protocol that was not indicated |
| client in the corresponding request's Upgrade header field. A server |  | by the client in the corresponding request's Upgrade header field. A |
| MAY choose to ignore the order of preference indicated by the client |  | server MAY choose to ignore the order of preference indicated by the |
| and select the new protocol(s) based on other factors, such as the |  | client and select the new protocol(s) based on other factors, such as |
| nature of the request or the current load on the server. |  | the nature of the request or the current load on the server. |
| A server that sends a 426 (Upgrade Required) response MUST send an |  | A server that sends a 426 (Upgrade Required) response MUST send an |
| Upgrade header field to indicate the acceptable protocols, in order |  | Upgrade header field to indicate the acceptable protocols, in order |
| of descending preference. |  | of descending preference. |
| A server MAY send an Upgrade header field in any other response to |  | A server MAY send an Upgrade header field in any other response to |
| advertise that it implements support for upgrading to the listed |  | advertise that it implements support for upgrading to the listed |
| protocols, in order of descending preference, when appropriate for a |  | protocols, in order of descending preference, when appropriate for a |
| future request. |  | future request. |
| The following is a hypothetical example sent by a client: |  | The following is a hypothetical example sent by a client: |
| GET /hello.txt HTTP/1.1 |  | GET /hello.txt HTTP/1.1 |
| Host: www.example.com |  | Host: www.example.com |
| Connection: upgrade |  | Connection: upgrade |
| Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 |  | Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 |
| Upgrade cannot be used to insist on a protocol change; its acceptance |  | Upgrade cannot be used to insist on a protocol change; its acceptance |
| and use by the server is optional. The capabilities and nature of |  | and use by the server is optional. The capabilities and nature of |
| the application-level communication after the protocol change is |  | the application-level communication after the protocol change is |
| entirely dependent upon the new protocol(s) chosen, although the |  | entirely dependent upon the new protocol(s) chosen. However, |
| first action after changing the protocol MUST be a response to the |  | immediately after sending the 101 response, the server is expected to |
| initial HTTP request that contained the Upgrade header field. |  | continue responding to the original request as if it had received its |
|  |  | equivalent within the new protocol (i.e., the server still has an |
|  |  | outstanding request to satisfy after the protocol has been changed, |
|  |  | and is expected to do so without requiring the request to be |
|  |  | repeated). |
| For example, if the Upgrade header field is received in a GET request |  | For example, if the Upgrade header field is received in a GET request |
| and the server decides to switch protocols, it first responds with a |  | and the server decides to switch protocols, it first responds with a |
| 101 (Switching Protocols) message in HTTP/1.1 and then immediately |  | 101 (Switching Protocols) message in HTTP/1.1 and then immediately |
| follows that with the new protocol's equivalent of a response to a |  | follows that with the new protocol's equivalent of a response to a |
| GET on the target resource. This allows a connection to be upgraded |  | GET on the target resource. This allows a connection to be upgraded |
| to protocols with the same semantics as HTTP without the latency cost |  | to protocols with the same semantics as HTTP without the latency cost |
| of an additional round-trip. A server MUST NOT switch protocols |  | of an additional round-trip. A server MUST NOT switch protocols |
| unless the received message semantics can be honored by the new |  | unless the received message semantics can be honored by the new |
| protocol; an OPTIONS request can be honored by any protocol. |  | protocol; an OPTIONS request can be honored by any protocol. |
| skipping to change at page 56, line 10 |  | skipping to change at page 57, line 50 |
| [... data stream switches to HTTP/2.0 with an appropriate response |  | [... data stream switches to HTTP/2.0 with an appropriate response |
| (as defined by new protocol) to the "GET /hello.txt" request ...] |  | (as defined by new protocol) to the "GET /hello.txt" request ...] |
| When Upgrade is sent, the sender MUST also send a Connection header |  | When Upgrade is sent, the sender MUST also send a Connection header |
| field (Section 6.1) that contains an "upgrade" connection option, in |  | field (Section 6.1) that contains an "upgrade" connection option, in |
| order to prevent Upgrade from being accidentally forwarded by |  | order to prevent Upgrade from being accidentally forwarded by |
| intermediaries that might not implement the listed protocols. A |  | intermediaries that might not implement the listed protocols. A |
| server MUST ignore an Upgrade header field that is received in an |  | server MUST ignore an Upgrade header field that is received in an |
| HTTP/1.0 request. |  | HTTP/1.0 request. |
|  |  | A client cannot begin using an upgraded protocol on the connection |
|  |  | until it has completely sent the request message (i.e., the client |
|  |  | can't change the protocol it is sending in the middle of a message). |
|  |  | If a server receives both Upgrade and an Expect header field with the |
|  |  | "100-continue" expectation (Section 5.1.1 of [Part2]), the server |
|  |  | MUST send a 100 (Continue) response before sending a 101 (Switching |
|  |  | Protocols) response. |
| The Upgrade header field only applies to switching protocols on top |  | The Upgrade header field only applies to switching protocols on top |
| of the existing connection; it cannot be used to switch the |  | of the existing connection; it cannot be used to switch the |
| underlying connection (transport) protocol, nor to switch the |  | underlying connection (transport) protocol, nor to switch the |
| existing communication to a different connection. For those |  | existing communication to a different connection. For those |
| purposes, it is more appropriate to use a 3xx (Redirection) response |  | purposes, it is more appropriate to use a 3xx (Redirection) response |
| (Section 6.4 of [Part2]). |  | (Section 6.4 of [Part2]). |
| This specification only defines the protocol name "HTTP" for use by |  | This specification only defines the protocol name "HTTP" for use by |
| the family of Hypertext Transfer Protocols, as defined by the HTTP |  | the family of Hypertext Transfer Protocols, as defined by the HTTP |
| version rules of Section 2.6 and future updates to this |  | version rules of Section 2.6 and future updates to this |
| specification. Additional tokens ought to be registered with IANA |  | specification. Additional tokens ought to be registered with IANA |
| using the registration procedure defined in Section 7.5. |  | using the registration procedure defined in Section 8.5. |
| 7. IANA Considerations |  | 7. ABNF list extension: #rule |
| 7.1. Header Field Registration |  | 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, a sender MUST expand the list construct as follows: |
|  |  | 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, a recipient MUST parse and |
|  |  | ignore a reasonable number of empty list elements: enough to handle |
|  |  | common mistakes by senders that merge values, but not so much that |
|  |  | they could be used as a denial of service mechanism. In other words, |
|  |  | a recipient MUST expand the list construct as follows: |
|  |  | #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ] |
|  |  | 1#element => *( "," OWS ) element *( OWS "," [ OWS element ] ) |
|  |  | Empty elements do not contribute to the count of elements present. |
|  |  | For example, given these ABNF productions: |
|  |  | example-list = 1#example-list-elmt |
|  |  | example-list-elmt = token ; see Section 3.2.6 |
|  |  | Then the following are valid values for example-list (not including |
|  |  | the double quotes, which are present for delimitation only): |
|  |  | "foo,bar" |
|  |  | "foo ,bar," |
|  |  | "foo , ,bar,charlie " |
|  |  | In contrast, the following values would be invalid, since at least |
|  |  | one non-empty element is required by the example-list production: |
|  |  | "" |
|  |  | "," |
|  |  | ", ," |
|  |  | Appendix B shows the collected ABNF after the list constructs have |
|  |  | been expanded, as described above, for recipients. |
|  |  | 8. IANA Considerations |
|  |  | 8.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 maintained at <http://www.iana.org/assignments/ |  | Registry maintained at <http://www.iana.org/assignments/ |
| message-headers/message-header-index.html>. |  | message-headers/message-header-index.html>. |
| This document defines the following HTTP header fields, so their |  | This document defines the following HTTP header fields, so their |
| associated registry entries shall be updated according to the |  | associated registry entries shall be updated according to the |
| permanent registrations below (see [BCP90]): |  | permanent registrations below (see [BCP90]): |
| +-------------------+----------+----------+---------------+ |  | +-------------------+----------+----------+---------------+ |
| | Header Field Name | Protocol | Status | Reference | |  | | Header Field Name | Protocol | Status | Reference | |
| +-------------------+----------+----------+---------------+ |  | +-------------------+----------+----------+---------------+ |
| | Connection | http | standard | Section 6.1 | |  | | Connection | http | standard | Section 6.1 | |
| | Content-Length | http | standard | Section 3.3.2 | |  | | Content-Length | http | standard | Section 3.3.2 | |
| | Host | http | standard | Section 5.4 | |  | | Host | http | standard | Section 5.4 | |
| | TE | http | standard | Section 4.3 | |  | | TE | http | standard | Section 4.3 | |
| | Trailer | http | standard | Section 4.1.1 | |  | | Trailer | http | standard | Section 4.4 | |
| | Transfer-Encoding | http | standard | Section 3.3.1 | |  | | Transfer-Encoding | http | standard | Section 3.3.1 | |
| | Upgrade | http | standard | Section 6.7 | |  | | Upgrade | http | standard | Section 6.7 | |
| | Via | http | standard | Section 5.7.1 | |  | | Via | http | standard | Section 5.7.1 | |
| +-------------------+----------+----------+---------------+ |  | +-------------------+----------+----------+---------------+ |
| Furthermore, the header field-name "Close" shall be registered as |  | Furthermore, the header field-name "Close" shall be registered as |
| "reserved", since using that name as an HTTP header field might |  | "reserved", since using that name as an HTTP header field might |
| conflict with the "close" connection option of the "Connection" |  | conflict with the "close" connection option of the "Connection" |
| header field (Section 6.1). |  | header field (Section 6.1). |
| +-------------------+----------+----------+-------------+ |  | +-------------------+----------+----------+-------------+ |
| | Header Field Name | Protocol | Status | Reference | |  | | Header Field Name | Protocol | Status | Reference | |
| +-------------------+----------+----------+-------------+ |  | +-------------------+----------+----------+-------------+ |
| | Close | http | reserved | Section 7.1 | |  | | Close | http | reserved | Section 8.1 | |
| +-------------------+----------+----------+-------------+ |  | +-------------------+----------+----------+-------------+ |
| The change controller is: "IETF (iesg@ietf.org) - Internet |  | The change controller is: "IETF (iesg@ietf.org) - Internet |
| Engineering Task Force". |  | Engineering Task Force". |
| 7.2. URI Scheme Registration |  | 8.2. URI Scheme Registration |
| IANA maintains the registry of URI Schemes [BCP115] at |  | IANA maintains the registry of URI Schemes [BCP115] at |
| <http://www.iana.org/assignments/uri-schemes.html>. |  | <http://www.iana.org/assignments/uri-schemes.html>. |
| This document defines the following URI schemes, so their associated |  | This document defines the following URI schemes, so their associated |
| registry entries shall be updated according to the permanent |  | registry entries shall be updated according to the permanent |
| registrations below: |  | registrations below: |
| +------------+------------------------------------+---------------+ |  | +------------+------------------------------------+---------------+ |
| | URI Scheme | Description | Reference | |  | | URI Scheme | Description | Reference | |
| +------------+------------------------------------+---------------+ |  | +------------+------------------------------------+---------------+ |
| | http | Hypertext Transfer Protocol | Section 2.7.1 | |  | | http | Hypertext Transfer Protocol | Section 2.7.1 | |
| | https | Hypertext Transfer Protocol Secure | Section 2.7.2 | |  | | https | Hypertext Transfer Protocol Secure | Section 2.7.2 | |
| +------------+------------------------------------+---------------+ |  | +------------+------------------------------------+---------------+ |
| 7.3. Internet Media Type Registration |  | 8.3. Internet Media Type Registration |
| This document serves as the specification for the Internet media |  | This document serves as the specification for the Internet media |
| types "message/http" and "application/http". The following is to be |  | types "message/http" and "application/http". The following is to be |
| registered with IANA (see [BCP13]). |  | registered with IANA (see [BCP13]). |
| 7.3.1. Internet Media Type message/http |  | 8.3.1. Internet Media Type message/http |
| The message/http type can be used to enclose a single HTTP request or |  | The message/http type can be used to enclose a single HTTP request or |
| response message, provided that it obeys the MIME restrictions for |  | response message, provided that it obeys the MIME restrictions for |
| all "message" types regarding line length and encodings. |  | all "message" types regarding line length and encodings. |
| Type name: message |  | Type name: message |
| Subtype name: http |  | Subtype name: http |
| Required parameters: none |  | Required parameters: none |
| skipping to change at page 58, line 19 |  | skipping to change at page 61, line 34 |
| present, the type can be determined from the first line of the |  | present, the type can be determined from the first line of the |
| body. |  | body. |
| Encoding considerations: only "7bit", "8bit", or "binary" are |  | Encoding considerations: only "7bit", "8bit", or "binary" are |
| permitted |  | permitted |
| Security considerations: none |  | Security considerations: none |
| Interoperability considerations: none |  | Interoperability considerations: none |
| Published specification: This specification (see Section 7.3.1). |  | Published specification: This specification (see Section 8.3.1). |
| Applications that use this media type: |  | Applications that use this media type: |
| Additional information: |  | Additional information: |
| Magic number(s): none |  | Magic number(s): none |
| File extension(s): none |  | File extension(s): none |
| Macintosh file type code(s): none |  | Macintosh file type code(s): none |
| skipping to change at page 58, line 35 |  | skipping to change at page 62, line 4 |
| Magic number(s): none |  | Magic number(s): none |
| File extension(s): none |  | File extension(s): none |
| Macintosh file type code(s): none |  | Macintosh file type code(s): none |
| Person and email address to contact for further information: See |  | Person and email address to contact for further information: See |
| Authors Section. |  | Authors Section. |
| Intended usage: COMMON |  | Intended usage: COMMON |
| Restrictions on usage: none |  | Restrictions on usage: none |
| Author: See Authors Section. |  | Author: See Authors Section. |
| Change controller: IESG |  | Change controller: IESG |
| 7.3.2. Internet Media Type application/http |  | 8.3.2. Internet Media Type application/http |
| The application/http type can be used to enclose a pipeline of one or |  | The application/http type can be used to enclose a pipeline of one or |
| more HTTP request or response messages (not intermixed). |  | more HTTP request or response messages (not intermixed). |
| Type name: application |  | Type name: application |
| Subtype name: http |  | Subtype name: http |
| Required parameters: none |  | Required parameters: none |
| Optional parameters: version, msgtype |  | Optional parameters: version, msgtype |
| version: The HTTP-version number of the enclosed messages (e.g., |  | version: The HTTP-version number of the enclosed messages (e.g., |
| "1.1"). If not present, the version can be determined from the |  | "1.1"). If not present, the version can be determined from the |
| first line of the body. |  | first line of the body. |
| skipping to change at page 59, line 26 |  | skipping to change at page 62, line 39 |
| body. |  | body. |
| Encoding considerations: HTTP messages enclosed by this type are in |  | Encoding considerations: HTTP messages enclosed by this type are in |
| "binary" format; use of an appropriate Content-Transfer-Encoding |  | "binary" format; use of an appropriate Content-Transfer-Encoding |
| is required when transmitted via E-mail. |  | is required when transmitted via E-mail. |
| Security considerations: none |  | Security considerations: none |
| Interoperability considerations: none |  | Interoperability considerations: none |
| Published specification: This specification (see Section 7.3.2). |  | Published specification: This specification (see Section 8.3.2). |
| Applications that use this media type: |  | Applications that use this media type: |
| Additional information: |  | Additional information: |
| Magic number(s): none |  | Magic number(s): none |
| File extension(s): none |  | File extension(s): none |
| Macintosh file type code(s): none |  | Macintosh file type code(s): none |
| Person and email address to contact for further information: See |  | Person and email address to contact for further information: See |
| Authors Section. |  | Authors Section. |
| Intended usage: COMMON |  | Intended usage: COMMON |
| Restrictions on usage: none |  | Restrictions on usage: none |
| Author: See Authors Section. |  | Author: See Authors Section. |
| skipping to change at page 60, line 5 |  | skipping to change at page 63, line 17 |
| Authors Section. |  | Authors Section. |
| Intended usage: COMMON |  | Intended usage: COMMON |
| Restrictions on usage: none |  | Restrictions on usage: none |
| Author: See Authors Section. |  | Author: See Authors Section. |
| Change controller: IESG |  | Change controller: IESG |
| 7.4. Transfer Coding Registry |  | 8.4. Transfer Coding Registry |
| The HTTP Transfer Coding Registry defines the name space for transfer |  | The HTTP Transfer Coding Registry defines the name space for transfer |
| coding names. It is maintained at |  | coding names. It is maintained at |
| <http://www.iana.org/assignments/http-parameters>. |  | <http://www.iana.org/assignments/http-parameters>. |
| 7.4.1. Procedure |  | 8.4.1. Procedure |
| 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 |
| skipping to change at page 60, line 33 |  | skipping to change at page 63, line 45 |
| transformation is identical, as is the case for the compression |  | transformation is identical, as is the case for the compression |
| codings defined in Section 4.2. |  | codings defined 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 specification. |  | transfer coding defined in this specification. |
| Use of program names for the identification of encoding formats is |  | Use of program names for the identification of encoding formats is |
| not desirable and is discouraged for future encodings. |  | not desirable and is discouraged for future encodings. |
| 7.4.2. Registration |  | 8.4.2. Registration |
| The HTTP Transfer Coding Registry shall be updated with the |  | The HTTP Transfer Coding Registry shall be updated with the |
| registrations below: |  | registrations below: |
| +------------+--------------------------------------+---------------+ |  | +------------+--------------------------------------+---------------+ |
| | Name | Description | Reference | |  | | Name | Description | Reference | |
| +------------+--------------------------------------+---------------+ |  | +------------+--------------------------------------+---------------+ |
| | chunked | Transfer in a series of chunks | Section 4.1 | |  | | chunked | Transfer in a series of chunks | Section 4.1 | |
| | compress | UNIX "compress" data format [Welch] | Section 4.2.1 | |  | | compress | UNIX "compress" data format [Welch] | Section 4.2.1 | |
| | deflate | "deflate" compressed data | Section 4.2.2 | |  | | deflate | "deflate" compressed data | Section 4.2.2 | |
| | | ([RFC1951]) inside the "zlib" data | | |  | | | ([RFC1951]) inside the "zlib" data | | |
| | | format ([RFC1950]) | | |  | | | format ([RFC1950]) | | |
| | gzip | GZIP file format [RFC1952] | Section 4.2.3 | |  | | gzip | GZIP file format [RFC1952] | Section 4.2.3 | |
| | x-compress | Deprecated (alias for compress) | Section 4.2.1 | |  | | x-compress | Deprecated (alias for compress) | Section 4.2.1 | |
| | x-gzip | Deprecated (alias for gzip) | Section 4.2.3 | |  | | x-gzip | Deprecated (alias for gzip) | Section 4.2.3 | |
| +------------+--------------------------------------+---------------+ |  | +------------+--------------------------------------+---------------+ |
| 7.5. Upgrade Token Registry |  | 8.5. 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. |
| The registry is maintained at |  | The registry is maintained at |
| <http://www.iana.org/assignments/http-upgrade-tokens>. |  | <http://www.iana.org/assignments/http-upgrade-tokens>. |
| 7.5.1. Procedure |  | 8.5.1. Procedure |
| 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 happen on a "First Come First Served" basis (see |  | Registrations happen on a "First Come First Served" basis (see |
| Section 4.1 of [RFC5226]) and 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. |
| skipping to change at page 61, line 45 |  | skipping to change at page 65, line 9 |
| The IANA will keep a record of all such changes, and make them |  | The IANA will keep a record of all such changes, and make them |
| available upon request. |  | available upon request. |
| 7. The IESG MAY reassign responsibility for a protocol token. This |  | 7. The IESG MAY reassign responsibility for a protocol token. This |
| will normally only be used in the case when a responsible party |  | will normally only be used in the case when a responsible party |
| cannot be contacted. |  | cannot be contacted. |
| This registration procedure for HTTP Upgrade Tokens replaces that |  | This registration procedure for HTTP Upgrade Tokens replaces that |
| previously defined in Section 7.2 of [RFC2817]. |  | previously defined in Section 7.2 of [RFC2817]. |
| 7.5.2. Upgrade Token Registration |  | 8.5.2. 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.6 | |
| | | Protocol | (e.g, "2.0") | | |  | | | Protocol | (e.g, "2.0") | | |
| +-------+----------------------+----------------------+-------------+ |  | +-------+----------------------+----------------------+-------------+ |
| The responsible party is: "IETF (iesg@ietf.org) - Internet |  | The responsible party is: "IETF (iesg@ietf.org) - Internet |
| Engineering Task Force". |  | Engineering Task Force". |
| 8. Security Considerations |  | 9. Security Considerations |
| This section is meant to inform developers, information providers, |  | This section is meant to inform developers, information providers, |
| and users of known security concerns relevant to HTTP/1.1 message |  | and users of known security concerns relevant to HTTP/1.1 message |
| syntax, parsing, and routing. |  | syntax, parsing, and routing. |
| 8.1. DNS-related Attacks |  | 9.1. DNS-related Attacks |
| HTTP clients rely heavily on the Domain Name Service (DNS), and are |  | HTTP clients rely heavily on the Domain Name Service (DNS), and are |
| thus generally prone to security attacks based on the deliberate |  | thus generally prone to security attacks based on the deliberate |
| misassociation of IP addresses and DNS names not protected by DNSSEC. |  | misassociation of IP addresses and DNS names not protected by DNSSEC. |
| Clients need to be cautious in assuming the validity of an IP number/ |  | Clients need to be cautious in assuming the validity of an IP number/ |
| DNS name association unless the response is protected by DNSSEC |  | DNS name association unless the response is protected by DNSSEC |
| ([RFC4033]). |  | ([RFC4033]). |
| 8.2. Intermediaries and Caching |  | 9.2. Intermediaries and Caching |
| By their very nature, HTTP intermediaries are men-in-the-middle, and |  | By their very nature, HTTP intermediaries are men-in-the-middle, and |
| represent an opportunity for man-in-the-middle attacks. Compromise |  | represent an opportunity for man-in-the-middle attacks. Compromise |
| of the systems on which the intermediaries run can result in serious |  | of the systems on which the intermediaries run can result in serious |
| security and privacy problems. Intermediaries have access to |  | security and privacy problems. Intermediaries have access to |
| security-related information, personal information about individual |  | security-related information, personal information about individual |
| users and organizations, and proprietary information belonging to |  | users and organizations, and proprietary information belonging to |
| users and content providers. A compromised intermediary, or an |  | users and content providers. A compromised intermediary, or an |
| intermediary implemented or configured without regard to security and |  | intermediary implemented or configured without regard to security and |
| privacy considerations, might be used in the commission of a wide |  | privacy considerations, might be used in the commission of a wide |
| skipping to change at page 63, line 6 |  | skipping to change at page 66, line 16 |
| to cache poisoning attacks. |  | to cache poisoning attacks. |
| Implementers need to consider the privacy and security implications |  | Implementers need to consider the privacy and security implications |
| of their design and coding decisions, and of the configuration |  | of their design and coding decisions, and of the configuration |
| options they provide to operators (especially the default |  | options they provide to operators (especially the default |
| configuration). |  | configuration). |
| Users need to be aware that intermediaries are no more trustworthy |  | Users need to be aware that intermediaries are no more trustworthy |
| than the people who run them; HTTP itself cannot solve this problem. |  | than the people who run them; HTTP itself cannot solve this problem. |
| 8.3. Buffer Overflows |  | 9.3. Buffer Overflows |
| Because HTTP uses mostly textual, character-delimited fields, |  | Because HTTP uses mostly textual, character-delimited fields, |
| attackers can overflow buffers in implementations, and/or perform a |  | attackers can overflow buffers in implementations, and/or perform a |
| Denial of Service against implementations that accept fields with |  | Denial of Service against implementations that accept fields with |
| unlimited lengths. |  | unlimited lengths. |
| To promote interoperability, this specification makes specific |  | To promote interoperability, this specification makes specific |
| recommendations for minimum size limits on request-line |  | recommendations for minimum size limits on request-line |
| (Section 3.1.1) and blocks of header fields (Section 3.2). These are |  | (Section 3.1.1) and header fields (Section 3.2). These are minimum |
| minimum recommendations, chosen to be supportable even by |  | recommendations, chosen to be supportable even by implementations |
| implementations with limited resources; it is expected that most |  | with limited resources; it is expected that most implementations will |
| implementations will choose substantially higher limits. |  | 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 6.5.12 of |  | that have request-targets that are too long (Section 6.5.12 of |
| [Part2]) or request entities that are too large (Section 6.5 of |  | [Part2]) or request entities that are too large (Section 6.5 of |
| [Part2]). Additional status codes related to capacity limits have |  | [Part2]). Additional status codes related to capacity limits have |
| been defined by extensions to HTTP [RFC6585]. |  | been defined by extensions to HTTP [RFC6585]. |
| Recipients SHOULD carefully limit the extent to which they read other |  | Recipients ought to carefully limit the extent to which they read |
| fields, including (but not limited to) request methods, response |  | other fields, including (but not limited to) request methods, |
| status phrases, header field-names, and body chunks, so as to avoid |  | response status phrases, header field-names, and body chunks, so as |
| denial of service attacks without impeding interoperability. |  | to avoid denial of service attacks without impeding interoperability. |
| 8.4. Message Integrity |  | 9.4. Message Integrity |
| HTTP does not define a specific mechanism for ensuring message |  | HTTP does not define a specific mechanism for ensuring message |
| integrity, instead relying on the error-detection ability of |  | integrity, instead relying on the error-detection ability of |
| underlying transport protocols and the use of length or chunk- |  | underlying transport protocols and the use of length or chunk- |
| delimited framing to detect completeness. Additional integrity |  | delimited framing to detect completeness. Additional integrity |
| mechanisms, such as hash functions or digital signatures applied to |  | mechanisms, such as hash functions or digital signatures applied to |
| the content, can be selectively added to messages via extensible |  | the content, can be selectively added to messages via extensible |
| metadata header fields. Historically, the lack of a single integrity |  | metadata header fields. Historically, the lack of a single integrity |
| mechanism has been justified by the informal nature of most HTTP |  | mechanism has been justified by the informal nature of most HTTP |
| communication. However, the prevalence of HTTP as an information |  | communication. However, the prevalence of HTTP as an information |
| skipping to change at page 64, line 10 |  | skipping to change at page 67, line 19 |
| necessary. For example, a browser being used to view medical history |  | necessary. For example, a browser being used to view medical history |
| or drug interaction information needs to indicate to the user when |  | or drug interaction information needs to indicate to the user when |
| such information is detected by the protocol to be incomplete, |  | such information is detected by the protocol to be incomplete, |
| expired, or corrupted during transfer. Such mechanisms might be |  | expired, or corrupted during transfer. Such mechanisms might be |
| selectively enabled via user agent extensions or the presence of |  | selectively enabled via user agent extensions or the presence of |
| message integrity metadata in a response. At a minimum, user agents |  | message integrity metadata in a response. At a minimum, user agents |
| ought to provide some indication that allows a user to distinguish |  | ought to provide some indication that allows a user to distinguish |
| between a complete and incomplete response message (Section 3.4) when |  | between a complete and incomplete response message (Section 3.4) when |
| such verification is desired. |  | such verification is desired. |
| 8.5. Server Log Information |  | 9.5. 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 over time, which might identify their reading patterns or |  | requests over time, which might identify their reading patterns or |
| subjects of interest. In particular, log information gathered at an |  | subjects of interest. In particular, log information gathered at an |
| intermediary often contains a history of user agent interaction, |  | intermediary often contains a history of user agent interaction, |
| across a multitude of sites, that can be traced to individual users. |  | across a multitude of sites, that can be traced to individual users. |
| HTTP log information is confidential in nature; its handling is often |  | HTTP log information is confidential in nature; its handling is often |
| constrained by laws and regulations. Log information needs to be |  | constrained by laws and regulations. Log information needs to be |
| securely stored and appropriate guidelines followed for its analysis. |  | securely stored and appropriate guidelines followed for its analysis. |
| Anonymization of personal information within individual entries |  | Anonymization of personal information within individual entries |
| helps, but is generally not sufficient to prevent real log traces |  | helps, but is generally not sufficient to prevent real log traces |
| from being re-identified based on correlation with other access |  | from being re-identified based on correlation with other access |
| characteristics. As such, access traces that are keyed to a specific |  | characteristics. As such, access traces that are keyed to a specific |
| client should not be published even if the key is pseudonymous. |  | client are unsafe to publish even if the key is pseudonymous. |
| To minimize the risk of theft or accidental publication, log |  | To minimize the risk of theft or accidental publication, log |
| information should be purged of personally identifiable information, |  | information ought to be purged of personally identifiable |
| including user identifiers, IP addresses, and user-provided query |  | information, including user identifiers, IP addresses, and user- |
| parameters, as soon as that information is no longer necessary to |  | provided query parameters, as soon as that information is no longer |
| support operational needs for security, auditing, or fraud control. |  | necessary to support operational needs for security, auditing, or |
|  |  | fraud control. |
| 9. Acknowledgments |  | 10. Acknowledgments |
| This edition of HTTP/1.1 builds on the many contributions that went |  | This edition of HTTP/1.1 builds on the many contributions that went |
| into RFC 1945, RFC 2068, RFC 2145, and RFC 2616, including |  | into RFC 1945, RFC 2068, RFC 2145, and RFC 2616, including |
| substantial contributions made by the previous authors, editors, and |  | substantial contributions made by the previous authors, editors, and |
| working group chairs: Tim Berners-Lee, Ari Luotonen, Roy T. Fielding, |  | working group chairs: Tim Berners-Lee, Ari Luotonen, Roy T. Fielding, |
| Henrik Frystyk Nielsen, Jim Gettys, Jeffrey C. Mogul, Larry Masinter, |  | Henrik Frystyk Nielsen, Jim Gettys, Jeffrey C. Mogul, Larry Masinter, |
| and Paul J. Leach. Mark Nottingham oversaw this effort as working |  | and Paul J. Leach. Mark Nottingham oversaw this effort as working |
| group chair. |  | group chair. |
| Since 1999, the following contributors have helped improve the HTTP |  | Since 1999, the following contributors have helped improve the HTTP |
| skipping to change at page 65, line 38 |  | skipping to change at page 68, line 48 |
| Stracke, John Sullivan, Jonas Sicking, Jonathan A. Rees, Jonathan |  | Stracke, John Sullivan, Jonas Sicking, Jonathan A. Rees, Jonathan |
| Billington, Jonathan Moore, Jonathan Silvera, Jordi Ros, Joris |  | Billington, Jonathan Moore, Jonathan Silvera, Jordi Ros, Joris |
| Dobbelsteen, Josh Cohen, Julien Pierre, Jungshik Shin, Justin |  | Dobbelsteen, Josh Cohen, Julien Pierre, Jungshik Shin, Justin |
| Chapweske, Justin Erenkrantz, Justin James, Kalvinder Singh, Karl |  | Chapweske, Justin Erenkrantz, Justin James, Kalvinder Singh, Karl |
| Dubost, Keith Hoffman, Keith Moore, Ken Murchison, Koen Holtman, |  | Dubost, Keith Hoffman, Keith Moore, Ken Murchison, Koen Holtman, |
| Konstantin Voronkov, Kris Zyp, Lisa Dusseault, Maciej Stachowiak, |  | Konstantin Voronkov, Kris Zyp, Lisa Dusseault, Maciej Stachowiak, |
| Manu Sporny, Marc Schneider, Marc Slemko, Mark Baker, Mark Pauley, |  | Manu Sporny, Marc Schneider, Marc Slemko, Mark Baker, Mark Pauley, |
| Mark Watson, Markus Isomaki, Markus Lanthaler, Martin J. Duerst, |  | Mark Watson, Markus Isomaki, Markus Lanthaler, Martin J. Duerst, |
| Martin Musatov, Martin Nilsson, Martin Thomson, Matt Lynch, Matthew |  | Martin Musatov, Martin Nilsson, Martin Thomson, Matt Lynch, Matthew |
| Cox, Max Clark, Michael Burrows, Michael Hausenblas, Michael Sweet, |  | Cox, Max Clark, Michael Burrows, Michael Hausenblas, Michael Sweet, |
| Mike Amundsen, Mike Belshe, Mike Bishop, Mike Kelly, Mike Schinkel, |  | Michael Tuexen, Michael Welzl, Mike Amundsen, Mike Belshe, Mike |
| Miles Sabin, Murray S. Kucherawy, Mykyta Yevstifeyev, Nathan Rixham, |  | Bishop, Mike Kelly, Mike Schinkel, Miles Sabin, Murray S. Kucherawy, |
| Nicholas Shanks, Nico Williams, Nicolas Alvarez, Nicolas Mailhot, |  | Mykyta Yevstifeyev, Nathan Rixham, Nicholas Shanks, Nico Williams, |
| Noah Slater, Osama Mazahir, Pablo Castro, Pat Hayes, Patrick R. |  | Nicolas Alvarez, Nicolas Mailhot, Noah Slater, Osama Mazahir, Pablo |
| McManus, Paul E. Jones, Paul Hoffman, Paul Marquess, Peter Lepeska, |  | Castro, Pat Hayes, Patrick R. McManus, Paul E. Jones, Paul Hoffman, |
| Peter Occil, Peter Saint-Andre, Peter Watkins, Phil Archer, Philippe |  | Paul Marquess, Peter Lepeska, Peter Occil, Peter Saint-Andre, Peter |
| Mougin, Phillip Hallam-Baker, Piotr Dobrogost, Poul-Henning Kamp, |  | Watkins, Phil Archer, Philippe Mougin, Phillip Hallam-Baker, Piotr |
| Preethi Natarajan, Rajeev Bector, Ray Polk, Reto Bachmann-Gmuer, |  | Dobrogost, Poul-Henning Kamp, Preethi Natarajan, Rajeev Bector, Ray |
| Richard Cyganiak, Robby Simpson, Robert Brewer, Robert Collins, |  | Polk, Reto Bachmann-Gmuer, Richard Cyganiak, Robby Simpson, Robert |
| Robert Mattson, Robert O'Callahan, Robert Olofsson, Robert Sayre, |  | Brewer, Robert Collins, Robert Mattson, Robert O'Callahan, Robert |
| Robert Siemer, Robert de Wilde, Roberto Javier Godoy, Roberto Peon, |  | Olofsson, Robert Sayre, Robert Siemer, Robert de Wilde, Roberto |
| Roland Zink, Ronny Widjaja, S. Mike Dierken, Salvatore Loreto, Sam |  | Javier Godoy, Roberto Peon, Roland Zink, Ronny Widjaja, Ryan |
| Johnston, Sam Pullara, Sam Ruby, Scott Lawrence (who maintained the |  | Hamilton, S. Mike Dierken, Salvatore Loreto, Sam Johnston, Sam |
| original issues list), Sean B. Palmer, Shane McCarron, Shigeki Ohtsu, |  | Pullara, Sam Ruby, Scott Lawrence (who maintained the original issues |
| Stefan Eissing, Stefan Tilkov, Stefanos Harhalakis, Stephane |  | list), Sean B. Palmer, Sebastien Barnoud, Shane McCarron, Shigeki |
|  |  | Ohtsu, Stefan Eissing, Stefan Tilkov, Stefanos Harhalakis, Stephane |
| Bortzmeyer, Stephen Farrell, Stephen Ludin, Stuart Williams, Subbu |  | Bortzmeyer, Stephen Farrell, Stephen Ludin, Stuart Williams, Subbu |
| Allamaraju, Sylvain Hellegouarch, Tapan Divekar, Tatsuya Hayashi, Ted |  | Allamaraju, Sylvain Hellegouarch, Tapan Divekar, Tatsuhiro Tsujikawa, |
| Hardie, Thomas Broyer, Thomas Fossati, Thomas Maslen, Thomas Nordin, |  | Tatsuya Hayashi, Ted Hardie, Thomas Broyer, Thomas Fossati, Thomas |
| Thomas Roessler, Tim Bray, Tim Morgan, Tim Olsen, Tom Zhou, Travis |  | Maslen, Thomas Nordin, Thomas Roessler, Tim Bray, Tim Morgan, Tim |
| Snoozy, Tyler Close, Vincent Murphy, Wenbo Zhu, Werner Baumann, |  | Olsen, Tom Zhou, Travis Snoozy, Tyler Close, Vincent Murphy, Wenbo |
| Wilbur Streett, Wilfredo Sanchez Vega, William A. Rowe Jr., William |  | Zhu, Werner Baumann, Wilbur Streett, Wilfredo Sanchez Vega, William |
| Chan, Willy Tarreau, Xiaoshu Wang, Yaron Goland, Yngve Nysaeter |  | A. Rowe Jr., William Chan, Willy Tarreau, Xiaoshu Wang, Yaron Goland, |
| Pettersen, Yoav Nir, Yogesh Bang, Yutaka Oiwa, Yves Lafon (long-time |  | Yngve Nysaeter Pettersen, Yoav Nir, Yogesh Bang, Yuchung Cheng, |
| member of the editor team), Zed A. Shaw, and Zhong Yu. |  | Yutaka Oiwa, Yves Lafon (long-time member of the editor team), Zed A. |
|  |  | Shaw, and Zhong Yu. |
| See Section 16 of [RFC2616] for additional acknowledgements from |  | See Section 16 of [RFC2616] for additional acknowledgements from |
| prior revisions. |  | prior revisions. |
| 10. References |  | 11. References |
| 10.1. Normative References |  | 11.1. Normative References |
| [Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext |  | [Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext |
| Transfer Protocol (HTTP/1.1): Semantics and Content", |  | Transfer Protocol (HTTP/1.1): Semantics and Content", |
| draft-ietf-httpbis-p2-semantics-23 (work in progress), |  | draft-ietf-httpbis-p2-semantics-24 (work in progress), |
| July 2013. |  | September 2013. |
| [Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext |  | [Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext |
| Transfer Protocol (HTTP/1.1): Conditional Requests", |  | Transfer Protocol (HTTP/1.1): Conditional Requests", |
| draft-ietf-httpbis-p4-conditional-23 (work in |  | draft-ietf-httpbis-p4-conditional-24 (work in |
| progress), July 2013. |  | progress), September 2013. |
| [Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |  | [Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |
| "Hypertext Transfer Protocol (HTTP/1.1): Range |  | "Hypertext Transfer Protocol (HTTP/1.1): Range |
| Requests", draft-ietf-httpbis-p5-range-23 (work in |  | Requests", draft-ietf-httpbis-p5-range-24 (work in |
| progress), July 2013. |  | progress), September 2013. |
| [Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, |  | [Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, |
| Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", |  | Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", |
| draft-ietf-httpbis-p6-cache-23 (work in progress), |  | draft-ietf-httpbis-p6-cache-24 (work in progress), |
| July 2013. |  | September 2013. |
| [Part7] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext |  | [Part7] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext |
| Transfer Protocol (HTTP/1.1): Authentication", |  | Transfer Protocol (HTTP/1.1): Authentication", |
| draft-ietf-httpbis-p7-auth-23 (work in progress), |  | draft-ietf-httpbis-p7-auth-24 (work in progress), |
| July 2013. |  | September 2013. |
| [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, |  | [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, |
| RFC 793, September 1981. |  | RFC 793, September 1981. |
| [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. |
| skipping to change at page 67, line 30 |  | skipping to change at page 70, line 41 |
| 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. |
| [Welch] Welch, T., "A Technique for High Performance Data |  | [Welch] Welch, T., "A Technique for High Performance Data |
| Compression", IEEE Computer 17(6), June 1984. |  | Compression", IEEE Computer 17(6), June 1984. |
| 10.2. Informative References |  | 11.2. Informative References |
| [BCP115] Hansen, T., Hardie, T., and L. Masinter, "Guidelines |  | [BCP115] Hansen, T., Hardie, T., and L. Masinter, "Guidelines |
| and Registration Procedures for New URI Schemes", |  | and Registration Procedures for New URI Schemes", |
| BCP 115, RFC 4395, February 2006. |  | BCP 115, RFC 4395, February 2006. |
| [BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type |  | [BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type |
| Specifications and Registration Procedures", BCP 13, |  | Specifications and Registration Procedures", BCP 13, |
| RFC 6838, January 2013. |  | RFC 6838, January 2013. |
| [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration |  | [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration |
| skipping to change at page 71, line 27 |  | skipping to change at page 74, line 39 |
| A.1.3. Introduction of Transfer-Encoding |  | A.1.3. Introduction of Transfer-Encoding |
| HTTP/1.1 introduces the Transfer-Encoding header field |  | HTTP/1.1 introduces the Transfer-Encoding header field |
| (Section 3.3.1). Transfer codings need to be decoded prior to |  | (Section 3.3.1). Transfer codings need to be decoded prior to |
| forwarding an HTTP message over a MIME-compliant protocol. |  | forwarding an HTTP message over a MIME-compliant protocol. |
| A.2. Changes from RFC 2616 |  | A.2. Changes from RFC 2616 |
| HTTP's approach to error handling has been explained. (Section 2.5) |  | HTTP's approach to error handling has been explained. (Section 2.5) |
| The expectation to support HTTP/0.9 requests has been removed. |  |  |
| The term "Effective Request URI" has been introduced. (Section 5.5) |  |  |
| HTTP messages can be (and often are) buffered by implementations; |  |  |
| despite it sometimes being available as a stream, HTTP is |  |  |
| fundamentally a message-oriented protocol. (Section 3) |  |  |
| Minimum supported sizes for various protocol elements have been |  |  |
| suggested, to improve interoperability. |  |  |
| Header fields that span multiple lines ("line folding") are |  |  |
| deprecated. (Section 3.2.4) |  |  |
| The HTTP-version ABNF production has been clarified to be case- |  | The HTTP-version ABNF production has been clarified to be case- |
| sensitive. Additionally, version numbers has been restricted to |  | sensitive. Additionally, version numbers has been restricted to |
| single digits, due to the fact that implementations are known to |  | single digits, due to the fact that implementations are known to |
| handle multi-digit version numbers incorrectly. (Section 2.6) |  | handle multi-digit version numbers incorrectly. (Section 2.6) |
| The HTTPS URI scheme is now defined by this specification; |  |  |
| previously, it was done in Section 2.4 of [RFC2818]. (Section 2.7.2) |  |  |
| The HTTPS URI scheme implies end-to-end security. (Section 2.7.2) |  |  |
| Userinfo (i.e., username and password) are now disallowed in HTTP and |  | Userinfo (i.e., username and password) are now disallowed in HTTP and |
| HTTPS URIs, because of security issues related to their transmission |  | HTTPS URIs, because of security issues related to their transmission |
| on the wire. (Section 2.7.1) |  | on the wire. (Section 2.7.1) |
|  |  | The HTTPS URI scheme is now defined by this specification; |
|  |  | previously, it was done in Section 2.4 of [RFC2818]. Furthermore, it |
|  |  | implies end-to-end security. (Section 2.7.2) |
|  |  | HTTP messages can be (and often are) buffered by implementations; |
|  |  | despite it sometimes being available as a stream, HTTP is |
|  |  | fundamentally a message-oriented protocol. Minimum supported sizes |
|  |  | for various protocol elements have been suggested, to improve |
|  |  | interoperability. (Section 3) |
| Invalid whitespace around field-names is now required to be rejected, |  | Invalid whitespace around field-names is now required to be rejected, |
| because accepting it represents a security vulnerability. |  | because accepting it represents a security vulnerability. The ABNF |
|  |  | productions defining header fields now only list the field value. |
| (Section 3.2) |  | (Section 3.2) |
| The ABNF productions defining header fields now only list the field |  |  |
| value. (Section 3.2) |  |  |
| Rules about implicit linear whitespace between certain grammar |  | Rules about implicit linear whitespace between certain grammar |
| productions have been removed; now whitespace is only allowed where |  | productions have been removed; now whitespace is only allowed where |
| specifically defined in the ABNF. (Section 3.2.3) |  | specifically defined in the ABNF. (Section 3.2.3) |
| The NUL octet is no longer allowed in comment and quoted-string text, |  | Header fields that span multiple lines ("line folding") are |
| and handling of backslash-escaping in them has been clarified. |  | deprecated. (Section 3.2.4) |
| (Section 3.2.6) |  |  |
| The quoted-pair rule no longer allows escaping control characters |  |  |
| other than HTAB. (Section 3.2.6) |  |  |
| Non-ASCII content in header fields and the reason phrase has been |  | The NUL octet is no longer allowed in comment and quoted-string text, |
| obsoleted and made opaque (the TEXT rule was removed). |  | and handling of backslash-escaping in them has been clarified. The |
|  |  | quoted-pair rule no longer allows escaping control characters other |
|  |  | than HTAB. Non-ASCII content in header fields and the reason phrase |
|  |  | has been obsoleted and made opaque (the TEXT rule was removed). |
| (Section 3.2.6) |  | (Section 3.2.6) |
| Bogus "Content-Length" header fields are now required to be handled |  | Bogus "Content-Length" header fields are now required to be handled |
| as errors by recipients. (Section 3.3.2) |  | as errors by recipients. (Section 3.3.2) |
| The "identity" transfer coding token has been removed. (Sections 3.3 |  |  |
| and 4) |  |  |
| The algorithm for determining the message body length has been |  | The algorithm for determining the message body length has been |
| clarified to indicate all of the special cases (e.g., driven by |  | clarified to indicate all of the special cases (e.g., driven by |
| methods or status codes) that affect it, and that new protocol |  | methods or status codes) that affect it, and that new protocol |
| elements cannot define such special cases. (Section 3.3.3) |  | elements cannot define such special cases. CONNECT is a new, special |
|  |  | case in determining message body length. "multipart/byteranges" is no |
| "multipart/byteranges" is no longer a way of determining message body |  | longer a way of determining message body length detection. |
| length detection. (Section 3.3.3) |  |  |
| CONNECT is a new, special case in determining message body length. |  |  |
| (Section 3.3.3) |  | (Section 3.3.3) |
|  |  | The "identity" transfer coding token has been removed. (Sections 3.3 |
|  |  | and 4) |
| Chunk length does not include the count of the octets in the chunk |  | Chunk length does not include the count of the octets in the chunk |
| header and trailer. (Section 4.1) |  | header and trailer. Line folding in chunk extensions is disallowed. |
|  |  | (Section 4.1) |
| Use of chunk extensions is deprecated, and line folding in them is |  | The meaning of the "deflate" content coding has been clarified. |
| disallowed. (Section 4.1) |  | (Section 4.2.2) |
| The segment + query components of RFC3986 have been used to define |  |  |
| the request-target, instead of abs_path from RFC 1808. (Section 5.3) |  |  |
| The asterisk form of the request-target is only allowed in the |  | The segment + query components of RFC 3986 have been used to define |
| OPTIONS method. (Section 5.3) |  | the request-target, instead of abs_path from RFC 1808. The asterisk- |
|  |  | form of the request-target is only allowed with the OPTIONS method. |
| Exactly when "close" connection options have to be sent has been |  | (Section 5.3) |
| clarified. (Section 6.1) |  |  |
| "hop-by-hop" header fields are required to appear in the Connection |  | The term "Effective Request URI" has been introduced. (Section 5.5) |
| header field; just because they're defined as hop-by-hop in this |  |  |
| specification doesn't exempt them. (Section 6.1) |  |  |
| The limit of two connections per server has been removed. |  | Gateways do not need to generate Via header fields anymore. |
| (Section 6.3) |  | (Section 5.7.1) |
| An idempotent sequence of requests is no longer required to be |  | Exactly when "close" connection options have to be sent has been |
| retried. (Section 6.3) |  | clarified. Also, "hop-by-hop" header fields are required to appear |
|  |  | in the Connection header field; just because they're defined as hop- |
|  |  | by-hop in this specification doesn't exempt them. (Section 6.1) |
|  |  | The limit of two connections per server has been removed. An |
|  |  | idempotent sequence of requests is no longer required to be retried. |
| The requirement to retry requests under certain circumstances when |  | The requirement to retry requests under certain circumstances when |
| the server prematurely closes the connection has been removed. |  | the server prematurely closes the connection has been removed. Also, |
| (Section 6.3) |  | some extraneous requirements about when servers are allowed to close |
| Some extraneous requirements about when servers are allowed to close |  |  |
| connections prematurely have been removed. (Section 6.3) |  | connections prematurely have been removed. (Section 6.3) |
| The semantics of the Upgrade header field is now defined in responses |  | The semantics of the Upgrade header field is now defined in responses |
| other than 101 (this was incorporated from [RFC2817]). (Section 6.7) |  | other than 101 (this was incorporated from [RFC2817]). Furthermore, |
|  |  | the ordering in the field value is now significant. (Section 6.7) |
| Registration of Transfer Codings now requires IETF Review |  | Empty list elements in list productions (e.g., a list header field |
| (Section 7.4) |  | containing ", ,") have been deprecated. (Section 7) |
| The meaning of the "deflate" content coding has been clarified. |  | Registration of Transfer Codings now requires IETF Review |
| (Section 4.2.2) |  | (Section 8.4) |
| This specification now defines the Upgrade Token Registry, previously |  | This specification now defines the Upgrade Token Registry, previously |
| defined in Section 7.2 of [RFC2817]. (Section 7.5) |  | defined in Section 7.2 of [RFC2817]. (Section 8.5) |
|  |  | The expectation to support HTTP/0.9 requests has been removed. |
|  |  | (Appendix A) |
| Issues with the Keep-Alive and Proxy-Connection header fields in |  | Issues with the Keep-Alive and Proxy-Connection header fields in |
| requests are pointed out, with use of the latter being discouraged |  | requests are pointed out, with use of the latter being discouraged |
| altogether. (Appendix A.1.2) |  | altogether. (Appendix A.1.2) |
| Empty list elements in list productions (e.g., a list header field |  | Appendix B. Collected ABNF |
| containing ", ,") have been deprecated. (Appendix B) |  |  |
| Appendix B. 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.6 |  |  |
| 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-option *( OWS "," [ OWS |  | Connection = *( "," OWS ) connection-option *( OWS "," [ OWS |
| connection-option ] ) |  | 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 ) |
| RWS = 1*( SP / HTAB ) |  | RWS = 1*( SP / HTAB ) |
| skipping to change at page 77, line 40 |  | skipping to change at page 79, line 24 |
| transfer-extension |  | transfer-extension |
| transfer-extension = token *( OWS ";" OWS transfer-parameter ) |  | transfer-extension = token *( OWS ";" OWS transfer-parameter ) |
| transfer-parameter = attribute BWS "=" BWS value |  | transfer-parameter = attribute BWS "=" BWS value |
| uri-host = <host, defined in [RFC3986], Section 3.2.2> |  | uri-host = <host, defined in [RFC3986], Section 3.2.2> |
| value = word |  | value = word |
| word = token / quoted-string |  | word = token / quoted-string |
| Appendix D. Change Log (to be removed by RFC Editor before publication) |  | Appendix C. Change Log (to be removed by RFC Editor before publication) |
| D.1. Since RFC 2616 |  | C.1. Since RFC 2616 |
| Changes up to the first Working Group Last Call draft are summarized |  | Changes up to the first Working Group Last Call draft are summarized |
| in <http://trac.tools.ietf.org/html/ |  | in <http://trac.tools.ietf.org/html/ |
| draft-ietf-httpbis-p1-messaging-21#appendix-D>. |  | draft-ietf-httpbis-p1-messaging-21#appendix-D>. |
| D.2. Since draft-ietf-httpbis-p1-messaging-21 |  | C.2. Since draft-ietf-httpbis-p1-messaging-21 |
| Closed issues: |  | Closed issues: |
| 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" (the spec now includes the HTTPs scheme |  | URI scheme definition" (the spec now includes the HTTPs scheme |
| definition and thus updates RFC 2818) |  | definition and thus updates RFC 2818) |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/389>: "mention of |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/389>: "mention of |
| 'proxies' in section about caches" |  | 'proxies' in section about caches" |
| skipping to change at page 79, line 14 |  | skipping to change at page 80, line 47 |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/420>: "Content- |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/420>: "Content- |
| Length SHOULD be sent" |  | Length SHOULD be sent" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/431>: "origin-form |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/431>: "origin-form |
| does not allow path starting with "//"" |  | does not allow path starting with "//"" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/433>: "ambiguity in |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/433>: "ambiguity in |
| part 1 example" |  | part 1 example" |
| D.3. Since draft-ietf-httpbis-p1-messaging-22 |  | C.3. Since draft-ietf-httpbis-p1-messaging-22 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/435>: "Part1 should |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/435>: "Part1 should |
| have a reference to TCP (RFC 793)" |  | have a reference to TCP (RFC 793)" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/438>: "media type |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/438>: "media type |
| registration template issues" |  | registration template issues" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/441>: P1 editorial |
|  |  | nits |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/442>: "BWS" (vs |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/442>: "BWS" (vs |
| conformance) |  | conformance) |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/444>: "obs-fold |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/444>: "obs-fold |
| language" |  | language" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/445>: "Ordering in |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/445>: "Ordering in |
| Upgrade" |  | Upgrade" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/446>: "p1 editorial |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/446>: "p1 editorial |
| skipping to change at page 80, line 14 |  | skipping to change at page 82, line 5 |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/476>: "SHOULD and |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/476>: "SHOULD and |
| conformance" |  | conformance" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/477>: "Pipelining |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/477>: "Pipelining |
| language" |  | language" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/482>: "proxy |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/482>: "proxy |
| handling of a really bad Content-Length" |  | handling of a really bad Content-Length" |
|  |  | C.4. Since draft-ietf-httpbis-p1-messaging-23 |
|  |  | Closed issues: |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/343>: "chunk- |
|  |  | extensions" (un-deprecated and explained) |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/483>: "MUST fix |
|  |  | Content-Length?" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/492>: "list notation |
|  |  | defined in appendix" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/497>: "Fine-Tuning |
|  |  | when Upgrade takes effect" |
| Index |  | Index |
| A |  | A |
| absolute-form (of request-target) 40 |  | absolute-form (of request-target) 42 |
| accelerator 10 |  | accelerator 10 |
| application/http Media Type 58 |  | application/http Media Type 62 |
| asterisk-form (of request-target) 41 |  | asterisk-form (of request-target) 42 |
| authority-form (of request-target) 41 |  | authority-form (of request-target) 42 |
| B |  | B |
| browser 7 |  | browser 7 |
| C |  | C |
| cache 11 |  | cache 11 |
| cacheable 12 |  | cacheable 12 |
| captive portal 11 |  | captive portal 11 |
| chunked (Coding Format) 27, 30, 34 |  | chunked (Coding Format) 28, 31, 35 |
| client 7 |  | client 7 |
| close 48, 53 |  | close 49, 55 |
| compress (Coding Format) 37 |  | compress (Coding Format) 38 |
| connection 7 |  | connection 7 |
| Connection header field 48, 53 |  | Connection header field 49, 55 |
| Content-Length header field 29 |  | Content-Length header field 30 |
| D |  | D |
| deflate (Coding Format) 37 |  | deflate (Coding Format) 38 |
| downstream 9 |  | downstream 9 |
| E |  | E |
| effective request URI 43 |  | effective request URI 44 |
| G |  | G |
| gateway 10 |  | gateway 10 |
| Grammar |  | Grammar |
| absolute-form 40 |  | absolute-form 41 |
| absolute-path 16 |  | absolute-path 16 |
| absolute-URI 16 |  | absolute-URI 16 |
| ALPHA 6 |  | ALPHA 6 |
| asterisk-form 40 |  | asterisk-form 41 |
| attribute 34 |  | attribute 35 |
| authority 16 |  | authority 16 |
| authority-form 40 |  | authority-form 41 |
| BWS 24 |  | BWS 24 |
| chunk 35 |  | chunk 35-36 |
| chunk-data 35 |  | chunk-data 35-36 |
| chunk-ext 35 |  | chunk-ext 35-36 |
| chunk-ext-name 35 |  | chunk-ext-name 35-36 |
| chunk-ext-val 35 |  | chunk-ext-val 35-36 |
| chunk-size 35 |  | chunk-size 35-36 |
| chunked-body 35 |  | chunked-body 35-36 |
| comment 26 |  | comment 27 |
| Connection 48 |  | Connection 50 |
| connection-option 48 |  | connection-option 50 |
| Content-Length 29 |  | Content-Length 30 |
| CR 6 |  | CR 6 |
| CRLF 6 |  | CRLF 6 |
| ctext 26 |  | ctext 27 |
| CTL 6 |  | CTL 6 |
| date2 34 |  | date2 35 |
| date3 34 |  | date3 35 |
| DIGIT 6 |  | DIGIT 6 |
| DQUOTE 6 |  | DQUOTE 6 |
| field-content 22 |  | field-content 22 |
| field-name 22 |  | field-name 22 |
| field-value 22 |  | field-value 22 |
| fragment 16 |  | fragment 16 |
| header-field 22 |  | header-field 22 |
| HEXDIG 6 |  | HEXDIG 6 |
| Host 42 |  | Host 43 |
| HTAB 6 |  | HTAB 6 |
| HTTP-message 19 |  | HTTP-message 19 |
| HTTP-name 13 |  | HTTP-name 14 |
| http-URI 16 |  | http-URI 17 |
| HTTP-version 13 |  | HTTP-version 14 |
| https-URI 18 |  | https-URI 18 |
| last-chunk 35 |  | last-chunk 35-36 |
| LF 6 |  | LF 6 |
| message-body 27 |  | message-body 27 |
| method 20 |  | method 21 |
| obs-fold 22 |  | obs-fold 22 |
| obs-text 26 |  | obs-text 27 |
| OCTET 6 |  | OCTET 6 |
| origin-form 40 |  | origin-form 41 |
| OWS 24 |  | OWS 24 |
| partial-URI 16 |  | partial-URI 16 |
| port 16 |  | port 16 |
| protocol-name 45 |  | protocol-name 47 |
| protocol-version 45 |  | protocol-version 47 |
| pseudonym 45 |  | pseudonym 47 |
| qdtext 26 |  | qdtext 27 |
| qdtext-nf 35 |  | qdtext-nf 35-36 |
| query 16 |  | query 16 |
| quoted-cpair 26 |  | quoted-cpair 27 |
| quoted-pair 26 |  | quoted-pair 27 |
| quoted-str-nf 35 |  | quoted-str-nf 35-36 |
| quoted-string 26 |  | quoted-string 27 |
| rank 37 |  | rank 39 |
| reason-phrase 21 |  | reason-phrase 22 |
| received-by 45 |  | received-by 47 |
| received-protocol 45 |  | received-protocol 47 |
| request-line 20 |  | request-line 21 |
| request-target 40 |  | request-target 41 |
| RWS 24 |  | RWS 24 |
| segment 16 |  | segment 16 |
| SP 6 |  | SP 6 |
| special 26 |  | 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 39 |
| t-ranking 37 |  | t-ranking 39 |
| tchar 26 |  | tchar 26 |
| TE 37 |  | TE 39 |
| token 26 |  | token 26 |
| Trailer 35 |  | Trailer 40 |
| trailer-part 35 |  | trailer-part 35-37 |
| transfer-coding 34 |  | transfer-coding 35 |
| Transfer-Encoding 27 |  | Transfer-Encoding 28 |
| transfer-extension 34 |  | transfer-extension 35 |
| transfer-parameter 34 |  | transfer-parameter 35 |
| Upgrade 54 |  | Upgrade 56 |
| uri-host 16 |  | uri-host 16 |
| URI-reference 16 |  | URI-reference 16 |
| value 34 |  | value 35 |
| VCHAR 6 |  | VCHAR 6 |
| Via 45 |  | Via 47 |
| word 26 |  | word 26 |
| gzip (Coding Format) 37 |  | gzip (Coding Format) 38 |
| H |  | H |
| header field 19 |  | header field 19 |
| header section 19 |  | header section 19 |
| headers 19 |  | headers 19 |
| Host header field 41 |  | Host header field 43 |
| http URI scheme 16 |  | http URI scheme 17 |
| https URI scheme 17 |  | https URI scheme 18 |
| I |  | I |
| inbound 9 |  | inbound 9 |
| interception proxy 11 |  | interception proxy 11 |
| intermediary 9 |  | intermediary 9 |
| M |  | M |
| Media Type |  | Media Type |
| application/http 58 |  | application/http 62 |
| message/http 57 |  | message/http 61 |
| message 7 |  | message 7 |
| message/http Media Type 57 |  | message/http Media Type 61 |
| method 20 |  | method 21 |
| N |  | N |
| non-transforming proxy 10 |  | non-transforming proxy 10 |
| O |  | O |
| origin server 7 |  | origin server 7 |
| origin-form (of request-target) 40 |  | origin-form (of request-target) 41 |
| outbound 9 |  | outbound 9 |
| P |  | P |
| proxy 10 |  | proxy 10 |
| R |  | R |
| recipient 7 |  | recipient 7 |
| request 7 |  | request 7 |
| request-target 20 |  | request-target 21 |
| resource 15 |  | resource 16 |
| response 7 |  | response 7 |
| reverse proxy 10 |  | reverse proxy 10 |
| S |  | S |
| sender 7 |  | sender 7 |
| server 7 |  | server 7 |
| spider 7 |  | spider 7 |
| T |  | T |
| target resource 38 |  | target resource 40 |
| target URI 38 |  | target URI 40 |
| TE header field 37 |  | TE header field 38 |
| Trailer header field 35 |  | Trailer header field 40 |
| Transfer-Encoding header field 27 |  | Transfer-Encoding header field 28 |
| transforming proxy 10 |  | transforming proxy 10 |
| transparent proxy 11 |  | transparent proxy 11 |
| tunnel 11 |  | tunnel 11 |
| U |  | U |
| Upgrade header field 54 |  | Upgrade header field 56 |
| upstream 9 |  | upstream 9 |
| URI scheme |  | URI scheme |
| http 16 |  | http 17 |
| https 17 |  | https 18 |
| user agent 7 |  | user agent 7 |
| V |  | V |
| Via header field 45 |  | Via header field 46 |
| Authors' Addresses |  | Authors' Addresses |
| Roy T. Fielding (editor) |  | Roy T. Fielding (editor) |
| Adobe Systems Incorporated |  | Adobe Systems Incorporated |
| 345 Park Ave |  | 345 Park Ave |
| San Jose, CA 95110 |  | San Jose, CA 95110 |
| USA |  | USA |
| EMail: fielding@gbiv.com |  | EMail: fielding@gbiv.com |
End of changes. 212 change blocks.
| 633 lines changed or deleted |  | 734 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/