| draft-ietf-httpbis-p1-messaging-25.txt |  | draft-ietf-httpbis-p1-messaging-26.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 November 17, 2013 |  | Intended status: Standards Track February 6, 2014 |
| Expires: May 21, 2014 |  | Expires: August 10, 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-25 |  | draft-ietf-httpbis-p1-messaging-26 |
| Abstract |  | Abstract |
| The Hypertext Transfer Protocol (HTTP) is an application-level |  | The Hypertext Transfer Protocol (HTTP) is a stateless application- |
| protocol for distributed, collaborative, hypertext information |  | level protocol for distributed, collaborative, hypertext information |
| systems. HTTP has been in use by the World Wide Web global |  | systems. This document provides an overview of HTTP architecture and |
| information initiative since 1990. This document provides an |  | its associated terminology, defines the "http" and "https" Uniform |
| overview of HTTP architecture and its associated terminology, defines |  | Resource Identifier (URI) schemes, defines the HTTP/1.1 message |
| the "http" and "https" Uniform Resource Identifier (URI) schemes, |  | syntax and parsing requirements, and describes related security |
| defines the HTTP/1.1 message syntax and parsing requirements, and |  | concerns for implementations. |
| describes general security concerns for implementations. |  |  |
| Editorial Note (To be removed by RFC Editor) |  | Editorial Note (To be removed by RFC Editor) |
| 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 C.2. |  | The changes in this draft are summarized in Appendix C.3. |
| 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 August 10, 2014. |
| This Internet-Draft will expire on May 21, 2014. |  |  |
| Copyright Notice |  | Copyright Notice |
| Copyright (c) 2013 IETF Trust and the persons identified as the |  | Copyright (c) 2014 IETF Trust and the persons identified as the |
| document authors. All rights reserved. |  | document authors. All rights reserved. |
| This document is subject to BCP 78 and the IETF Trust's Legal |  | This document is subject to BCP 78 and the IETF Trust's Legal |
| Provisions Relating to IETF Documents |  | Provisions Relating to IETF Documents |
| (http://trustee.ietf.org/license-info) in effect on the date of |  | (http://trustee.ietf.org/license-info) in effect on the date of |
| publication of this document. Please review these documents |  | publication of this document. Please review these documents |
| carefully, as they describe your rights and restrictions with respect |  | carefully, as they describe your rights and restrictions with respect |
| to this document. Code Components extracted from this document must |  | to this document. Code Components extracted from this document must |
| include Simplified BSD License text as described in Section 4.e of |  | include Simplified BSD License text as described in Section 4.e of |
| the Trust Legal Provisions and are provided without warranty as |  | the Trust Legal Provisions and are provided without warranty as |
| skipping to change at page 2, line 46 |  | skipping to change at page 2, line 44 |
| 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 . . . . . . . . . . . . . . . . . . . 14 |  | 2.6. Protocol Versioning . . . . . . . . . . . . . . . . . . . 13 |
| 2.7. Uniform Resource Identifiers . . . . . . . . . . . . . . . 16 |  | 2.7. Uniform Resource Identifiers . . . . . . . . . . . . . . . 16 |
| 2.7.1. http URI scheme . . . . . . . . . . . . . . . . . . . 17 |  | 2.7.1. http URI scheme . . . . . . . . . . . . . . . . . . . 16 |
| 2.7.2. https URI scheme . . . . . . . . . . . . . . . . . . . 18 |  | 2.7.2. https URI scheme . . . . . . . . . . . . . . . . . . . 18 |
| 2.7.3. http and https URI Normalization and Comparison . . . 19 |  | 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 . . . . . . . . . . . . . . . . . . . . . 21 |  | 3.1.1. Request Line . . . . . . . . . . . . . . . . . . . . . 21 |
| 3.1.2. Status Line . . . . . . . . . . . . . . . . . . . . . 22 |  | 3.1.2. Status Line . . . . . . . . . . . . . . . . . . . . . 22 |
| 3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 22 |  | 3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 22 |
| 3.2.1. Field Extensibility . . . . . . . . . . . . . . . . . 23 |  | 3.2.1. Field Extensibility . . . . . . . . . . . . . . . . . 23 |
| 3.2.2. Field Order . . . . . . . . . . . . . . . . . . . . . 23 |  | 3.2.2. Field Order . . . . . . . . . . . . . . . . . . . . . 23 |
| 3.2.3. Whitespace . . . . . . . . . . . . . . . . . . . . . . 24 |  | 3.2.3. Whitespace . . . . . . . . . . . . . . . . . . . . . . 24 |
| 3.2.4. Field Parsing . . . . . . . . . . . . . . . . . . . . 24 |  | 3.2.4. Field Parsing . . . . . . . . . . . . . . . . . . . . 25 |
| 3.2.5. Field Limits . . . . . . . . . . . . . . . . . . . . . 26 |  | 3.2.5. Field Limits . . . . . . . . . . . . . . . . . . . . . 26 |
| 3.2.6. Field value components . . . . . . . . . . . . . . . . 26 |  | 3.2.6. Field value components . . . . . . . . . . . . . . . . 26 |
| 3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 27 |  | 3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 27 |
| 3.3.1. Transfer-Encoding . . . . . . . . . . . . . . . . . . 28 |  | 3.3.1. Transfer-Encoding . . . . . . . . . . . . . . . . . . 28 |
| 3.3.2. Content-Length . . . . . . . . . . . . . . . . . . . . 30 |  | 3.3.2. Content-Length . . . . . . . . . . . . . . . . . . . . 30 |
| 3.3.3. Message Body Length . . . . . . . . . . . . . . . . . 31 |  | 3.3.3. Message Body Length . . . . . . . . . . . . . . . . . 31 |
| 3.4. Handling Incomplete Messages . . . . . . . . . . . . . . . 33 |  | 3.4. Handling Incomplete Messages . . . . . . . . . . . . . . . 33 |
| 3.5. Message Parsing Robustness . . . . . . . . . . . . . . . . 34 |  | 3.5. Message Parsing Robustness . . . . . . . . . . . . . . . . 34 |
| 4. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . . 35 |  | 4. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . . 35 |
| 4.1. Chunked Transfer Coding . . . . . . . . . . . . . . . . . 35 |  | 4.1. Chunked Transfer Coding . . . . . . . . . . . . . . . . . 35 |
| 4.1.1. Chunk Extensions . . . . . . . . . . . . . . . . . . . 36 |  | 4.1.1. Chunk Extensions . . . . . . . . . . . . . . . . . . . 36 |
| 4.1.2. Chunked Trailer Part . . . . . . . . . . . . . . . . . 36 |  | 4.1.2. Chunked Trailer Part . . . . . . . . . . . . . . . . . 36 |
| 4.1.3. Decoding Chunked . . . . . . . . . . . . . . . . . . . 37 |  | 4.1.3. Decoding Chunked . . . . . . . . . . . . . . . . . . . 37 |
| 4.2. Compression Codings . . . . . . . . . . . . . . . . . . . 38 |  | 4.2. Compression Codings . . . . . . . . . . . . . . . . . . . 38 |
| 4.2.1. Compress Coding . . . . . . . . . . . . . . . . . . . 38 |  | 4.2.1. Compress Coding . . . . . . . . . . . . . . . . . . . 38 |
| 4.2.2. Deflate Coding . . . . . . . . . . . . . . . . . . . . 38 |  | 4.2.2. Deflate Coding . . . . . . . . . . . . . . . . . . . . 38 |
| 4.2.3. Gzip Coding . . . . . . . . . . . . . . . . . . . . . 38 |  | 4.2.3. Gzip Coding . . . . . . . . . . . . . . . . . . . . . 38 |
| 4.3. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 |  | 4.3. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 |
| 4.4. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 40 |  | 4.4. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 39 |
| 5. Message Routing . . . . . . . . . . . . . . . . . . . . . . . 40 |  | 5. Message Routing . . . . . . . . . . . . . . . . . . . . . . . 40 |
| 5.1. Identifying a Target Resource . . . . . . . . . . . . . . 40 |  | 5.1. Identifying a Target Resource . . . . . . . . . . . . . . 40 |
| 5.2. Connecting Inbound . . . . . . . . . . . . . . . . . . . . 40 |  | 5.2. Connecting Inbound . . . . . . . . . . . . . . . . . . . . 40 |
| 5.3. Request Target . . . . . . . . . . . . . . . . . . . . . . 41 |  | 5.3. Request Target . . . . . . . . . . . . . . . . . . . . . . 41 |
|  |  | 5.3.1. origin-form . . . . . . . . . . . . . . . . . . . . . 41 |
|  |  | 5.3.2. absolute-form . . . . . . . . . . . . . . . . . . . . 42 |
|  |  | 5.3.3. authority-form . . . . . . . . . . . . . . . . . . . . 42 |
|  |  | 5.3.4. asterisk-form . . . . . . . . . . . . . . . . . . . . 42 |
| 5.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 |  | 5.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 |
| 5.5. Effective Request URI . . . . . . . . . . . . . . . . . . 44 |  | 5.5. Effective Request URI . . . . . . . . . . . . . . . . . . 44 |
| 5.6. Associating a Response to a Request . . . . . . . . . . . 46 |  | 5.6. Associating a Response to a Request . . . . . . . . . . . 46 |
| 5.7. Message Forwarding . . . . . . . . . . . . . . . . . . . . 46 |  | 5.7. Message Forwarding . . . . . . . . . . . . . . . . . . . . 46 |
| 5.7.1. Via . . . . . . . . . . . . . . . . . . . . . . . . . 46 |  | 5.7.1. Via . . . . . . . . . . . . . . . . . . . . . . . . . 47 |
| 5.7.2. Transformations . . . . . . . . . . . . . . . . . . . 48 |  | 5.7.2. Transformations . . . . . . . . . . . . . . . . . . . 48 |
| 6. Connection Management . . . . . . . . . . . . . . . . . . . . 49 |  | 6. Connection Management . . . . . . . . . . . . . . . . . . . . 49 |
| 6.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 49 |  | 6.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 50 |
| 6.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 51 |  | 6.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 51 |
| 6.3. Persistence . . . . . . . . . . . . . . . . . . . . . . . 51 |  | 6.3. Persistence . . . . . . . . . . . . . . . . . . . . . . . 52 |
| 6.3.1. Retrying Requests . . . . . . . . . . . . . . . . . . 52 |  | 6.3.1. Retrying Requests . . . . . . . . . . . . . . . . . . 53 |
| 6.3.2. Pipelining . . . . . . . . . . . . . . . . . . . . . . 53 |  | 6.3.2. Pipelining . . . . . . . . . . . . . . . . . . . . . . 53 |
| 6.4. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 53 |  | 6.4. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 54 |
| 6.5. Failures and Time-outs . . . . . . . . . . . . . . . . . . 54 |  | 6.5. Failures and Time-outs . . . . . . . . . . . . . . . . . . 54 |
| 6.6. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 55 |  | 6.6. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 55 |
| 6.7. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 56 |  | 6.7. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 56 |
| 7. ABNF list extension: #rule . . . . . . . . . . . . . . . . . . 58 |  | 7. ABNF list extension: #rule . . . . . . . . . . . . . . . . . . 58 |
| 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59 |  | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 60 |
| 8.1. Header Field Registration . . . . . . . . . . . . . . . . 59 |  | 8.1. Header Field Registration . . . . . . . . . . . . . . . . 60 |
| 8.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 60 |  | 8.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 60 |
| 8.3. Internet Media Type Registration . . . . . . . . . . . . . 60 |  | 8.3. Internet Media Type Registration . . . . . . . . . . . . . 61 |
| 8.3.1. Internet Media Type message/http . . . . . . . . . . . 60 |  | 8.3.1. Internet Media Type message/http . . . . . . . . . . . 61 |
| 8.3.2. Internet Media Type application/http . . . . . . . . . 61 |  | 8.3.2. Internet Media Type application/http . . . . . . . . . 62 |
| 8.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 63 |  | 8.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 63 |
| 8.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 63 |  | 8.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 63 |
| 8.4.2. Registration . . . . . . . . . . . . . . . . . . . . . 63 |  | 8.4.2. Registration . . . . . . . . . . . . . . . . . . . . . 64 |
| 8.5. Content Coding Registration . . . . . . . . . . . . . . . 64 |  | 8.5. Content Coding Registration . . . . . . . . . . . . . . . 64 |
| 8.6. Upgrade Token Registry . . . . . . . . . . . . . . . . . . 64 |  | 8.6. Upgrade Token Registry . . . . . . . . . . . . . . . . . . 65 |
| 8.6.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 64 |  | 8.6.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 65 |
| 8.6.2. Upgrade Token Registration . . . . . . . . . . . . . . 65 |  | 8.6.2. Upgrade Token Registration . . . . . . . . . . . . . . 66 |
| 9. Security Considerations . . . . . . . . . . . . . . . . . . . 65 |  | 9. Security Considerations . . . . . . . . . . . . . . . . . . . 66 |
| 9.1. DNS-related Attacks . . . . . . . . . . . . . . . . . . . 65 |  | 9.1. Establishing Authority . . . . . . . . . . . . . . . . . . 66 |
| 9.2. Intermediaries and Caching . . . . . . . . . . . . . . . . 65 |  | 9.2. Risks of Intermediaries . . . . . . . . . . . . . . . . . 67 |
| 9.3. Buffer Overflows . . . . . . . . . . . . . . . . . . . . . 66 |  | 9.3. Attacks via Protocol Element Length . . . . . . . . . . . 68 |
| 9.4. Message Integrity . . . . . . . . . . . . . . . . . . . . 66 |  | 9.4. Response Splitting . . . . . . . . . . . . . . . . . . . . 68 |
| 9.5. Server Log Information . . . . . . . . . . . . . . . . . . 67 |  | 9.5. Request Smuggling . . . . . . . . . . . . . . . . . . . . 69 |
| 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 68 |  | 9.6. Message Integrity . . . . . . . . . . . . . . . . . . . . 69 |
| 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 69 |  | 9.7. Message Confidentiality . . . . . . . . . . . . . . . . . 70 |
| 11.1. Normative References . . . . . . . . . . . . . . . . . . . 69 |  | 9.8. Privacy of Server Log Information . . . . . . . . . . . . 70 |
| 11.2. Informative References . . . . . . . . . . . . . . . . . . 71 |  | 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 71 |
| Appendix A. HTTP Version History . . . . . . . . . . . . . . . . 72 |  | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 72 |
| A.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 73 |  | 11.1. Normative References . . . . . . . . . . . . . . . . . . . 72 |
| A.1.1. Multi-homed Web Servers . . . . . . . . . . . . . . . 73 |  | 11.2. Informative References . . . . . . . . . . . . . . . . . . 74 |
| A.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 74 |  | Appendix A. HTTP Version History . . . . . . . . . . . . . . . . 76 |
| A.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 74 |  | A.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 77 |
| A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 74 |  | A.1.1. Multi-homed Web Servers . . . . . . . . . . . . . . . 77 |
| Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 77 |  | A.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 77 |
|  |  | A.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 78 |
|  |  | A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 78 |
|  |  | Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 80 |
| Appendix C. Change Log (to be removed by RFC Editor before |  | Appendix C. Change Log (to be removed by RFC Editor before |
| publication) . . . . . . . . . . . . . . . . . . . . 79 |  | publication) . . . . . . . . . . . . . . . . . . . . 82 |
| C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 79 |  | C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 82 |
| C.2. Since draft-ietf-httpbis-p1-messaging-24 . . . . . . . . . 79 |  | C.2. Since draft-ietf-httpbis-p1-messaging-24 . . . . . . . . . 83 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 |  | C.3. Since draft-ietf-httpbis-p1-messaging-25 . . . . . . . . . 83 |
|  |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 |
| 1. Introduction |  | 1. Introduction |
| The Hypertext Transfer Protocol (HTTP) is an application-level |  | The Hypertext Transfer Protocol (HTTP) is a stateless application- |
| request/response protocol that uses extensible semantics and self- |  | level request/response protocol that uses extensible semantics and |
| descriptive message payloads for flexible interaction with network- |  | self-descriptive message payloads for flexible interaction with |
| based hypertext information systems. This document is the first in a |  | network-based hypertext information systems. This document is the |
| series of documents that collectively form the HTTP/1.1 |  | first in a series of documents that collectively form the HTTP/1.1 |
| specification: |  | specification: |
| RFC xxx1: Message Syntax and Routing |  | RFC xxx1: Message Syntax and Routing |
| RFC xxx2: Semantics and Content |  | RFC xxx2: Semantics and Content |
| RFC xxx3: Conditional Requests |  | RFC xxx3: Conditional Requests |
| RFC xxx4: Range Requests |  | RFC xxx4: Range Requests |
| RFC xxx5: Caching |  | RFC xxx5: Caching |
| RFC xxx6: Authentication |  | RFC xxx6: Authentication |
| This HTTP/1.1 specification obsoletes and moves to historic status |  | This HTTP/1.1 specification obsoletes RFC 2616 and RFC 2145 (on HTTP |
| RFC 2616, its predecessor RFC 2068, and RFC 2145 (on HTTP |  |  |
| versioning). This specification also updates the use of CONNECT to |  | versioning). This specification also updates the use of CONNECT to |
| establish a tunnel, previously defined in RFC 2817, and defines the |  | establish a tunnel, previously defined in RFC 2817, and defines the |
| "https" URI scheme that was described informally in RFC 2818. |  | "https" URI scheme that was described informally in RFC 2818. |
| HTTP is a generic interface protocol for information systems. It is |  | HTTP is a generic interface protocol for information systems. It is |
| designed to hide the details of how a service is implemented by |  | designed to hide the details of how a service is implemented by |
| presenting a uniform interface to clients that is independent of the |  | presenting a uniform interface to clients that is independent of the |
| types of resources provided. Likewise, servers do not need to be |  | types of resources provided. Likewise, servers do not need to be |
| aware of each client's purpose: an HTTP request can be considered in |  | aware of each client's purpose: an HTTP request can be considered in |
| isolation rather than being associated with a specific type of client |  | isolation rather than being associated with a specific type of client |
| skipping to change at page 6, line 31 |  | skipping to change at page 6, line 30 |
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |  | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |  | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |
| document are to be interpreted as described in [RFC2119]. |  | document are to be interpreted as described in [RFC2119]. |
| 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 a list extension, defined in Section 7, |
| Section 7. Appendix B shows the collected ABNF with the list rule |  | that allows for compact definition of comma-separated lists using a |
| expanded. |  | '#' operator (similar to how the '*' operator indicates repetition). |
|  |  | Appendix B shows the collected grammar with all list operators |
|  |  | expanded to standard ABNF notation. |
| The following core rules are included by reference, as defined in |  | The following core rules are included by reference, as defined in |
| [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF |  | [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF |
| (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), |  | (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), |
| HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line |  | HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line |
| feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any |  | feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any |
| visible [USASCII] character). |  | visible [USASCII] character). |
| As a convention, ABNF rule names prefixed with "obs-" denote |  | As a convention, ABNF rule names prefixed with "obs-" denote |
| "obsolete" grammar rules that appear for historical reasons. |  | "obsolete" grammar rules that appear for historical reasons. |
| 2. Architecture |  | 2. Architecture |
| HTTP was created for the World Wide Web architecture and has evolved |  | HTTP was created for the World Wide Web (WWW) architecture and has |
| over time to support the scalability needs of a worldwide hypertext |  | evolved over time to support the scalability needs of a worldwide |
| system. Much of that architecture is reflected in the terminology |  | hypertext system. Much of that architecture is reflected in the |
| and syntax productions used to define HTTP. |  | terminology and syntax productions used to define HTTP. |
| 2.1. Client/Server Messaging |  | 2.1. Client/Server Messaging |
| HTTP is a stateless request/response protocol that operates by |  | HTTP is a stateless request/response protocol that operates by |
| exchanging messages (Section 3) across a reliable transport or |  | exchanging messages (Section 3) across a reliable transport or |
| session-layer "connection" (Section 6). An HTTP "client" is a |  | session-layer "connection" (Section 6). An HTTP "client" is a |
| program that establishes a connection to a server for the purpose of |  | program that establishes a connection to a server for the purpose of |
| sending one or more HTTP requests. An HTTP "server" is a program |  | sending one or more HTTP requests. An HTTP "server" is a program |
| that accepts connections in order to service HTTP requests by sending |  | that accepts connections in order to service HTTP requests by sending |
| HTTP responses. |  | HTTP responses. |
| The terms client and server refer only to the roles that these |  | The terms client and server refer only to the roles that these |
| programs perform for a particular connection. The same program might |  | programs perform for a particular connection. The same program might |
| act as a client on some connections and a server on others. We use |  | act as a client on some connections and a server on others. The term |
| the term "user agent" to refer to any of the various client programs |  | "user agent" refers to any of the various client programs that |
| that initiate a request, including (but not limited to) browsers, |  | initiate a request, including (but not limited to) browsers, spiders |
| spiders (web-based robots), command-line tools, native applications, |  | (web-based robots), command-line tools, custom applications, and |
| and mobile apps. The term "origin server" is used to refer to the |  | mobile apps. The term "origin server" refers to the program that can |
| program that can originate authoritative responses to a request. For |  | originate authoritative responses for a given target resource. The |
| general requirements, we use the terms "sender" and "recipient" to |  | terms "sender" and "recipient" refer to any implementation that sends |
| refer to any component that sends or receives, respectively, a given |  | or receives a given message, respectively. |
| message. |  |  |
| HTTP relies upon the Uniform Resource Identifier (URI) standard |  | HTTP relies upon the Uniform Resource Identifier (URI) standard |
| [RFC3986] to indicate the target resource (Section 5.1) and |  | [RFC3986] to indicate the target resource (Section 5.1) and |
| relationships between resources. Messages are passed in a format |  | relationships between resources. Messages are passed in a format |
| similar to that used by Internet mail [RFC5322] and the Multipurpose |  | similar to that used by Internet mail [RFC5322] and the Multipurpose |
| Internet Mail Extensions (MIME) [RFC2045] (see Appendix A of [Part2] |  | Internet Mail Extensions (MIME) [RFC2045] (see Appendix A of [Part2] |
| for the differences between HTTP and MIME messages). |  | for the differences between HTTP and MIME messages). |
| Most HTTP communication consists of a retrieval request (GET) for a |  | Most HTTP communication consists of a retrieval request (GET) for a |
| representation of some resource identified by a URI. In the simplest |  | representation of some resource identified by a URI. In the simplest |
| skipping to change at page 8, line 16 |  | skipping to change at page 8, line 15 |
| phrase (Section 3.1.2), possibly followed by header fields containing |  | phrase (Section 3.1.2), possibly followed by header fields containing |
| server information, resource metadata, and representation metadata |  | server information, resource metadata, and representation metadata |
| (Section 3.2), an empty line to indicate the end of the header |  | (Section 3.2), an empty line to indicate the end of the header |
| section, and finally a message body containing the payload body (if |  | section, and finally a message body containing the payload body (if |
| any, Section 3.3). |  | any, Section 3.3). |
| A connection might be used for multiple request/response exchanges, |  | A connection might be used for multiple request/response exchanges, |
| as defined in Section 6.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 (Section 4.3.1 of [Part2]) 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: |
| skipping to change at page 9, line 14 |  | skipping to change at page 9, line 14 |
| The term "user agent" does not imply that there is a human user |  | The term "user agent" does not imply that there is a human user |
| directly interacting with the software agent at the time of a |  | directly interacting with the software agent at the time of a |
| request. In many cases, a user agent is installed or configured to |  | request. In many cases, a user agent is installed or configured to |
| run in the background and save its results for later inspection (or |  | run in the background and save its results for later inspection (or |
| save only a subset of those results that might be interesting or |  | save only a subset of those results that might be interesting or |
| erroneous). Spiders, for example, are typically given a start URI |  | erroneous). Spiders, for example, are typically given a start URI |
| and configured to follow certain behavior while crawling the Web as a |  | and configured to follow certain behavior while crawling the Web as a |
| hypertext graph. |  | hypertext graph. |
| The implementation diversity of HTTP means that we cannot assume the |  | The implementation diversity of HTTP means that not all user agents |
| user agent can make interactive suggestions to a user or provide |  | can make interactive suggestions to their user or provide adequate |
| adequate warning for security or privacy options. In the few cases |  | warning for security or privacy concerns. In the few cases where |
| where this specification requires reporting of errors to the user, it |  | this specification requires reporting of errors to the user, it is |
| is acceptable for such reporting to only be observable in an error |  | acceptable for such reporting to only be observable in an error |
| console or log file. Likewise, requirements that an automated action |  | console or log file. Likewise, requirements that an automated action |
| be confirmed by the user before proceeding might be met via advance |  | be confirmed by the user before proceeding might be met via advance |
| configuration choices, run-time options, or simple avoidance of the |  | configuration choices, run-time options, or simple avoidance of the |
| unsafe action; confirmation does not imply any specific user |  | unsafe action; confirmation does not imply any specific user |
| interface or interruption of normal processing if the user has |  | interface or interruption of normal processing if the user has |
| already made that choice. |  | already made that choice. |
| 2.3. Intermediaries |  | 2.3. Intermediaries |
| HTTP enables the use of intermediaries to satisfy requests through a |  | HTTP enables the use of intermediaries to satisfy requests through a |
| skipping to change at page 9, line 52 |  | skipping to change at page 9, line 52 |
| with the nearest, non-tunnel neighbor, only to the end-points of the |  | with the nearest, non-tunnel neighbor, only to the end-points of the |
| chain, or to all connections along the chain. Although the diagram |  | chain, or to all connections along the chain. Although the diagram |
| is linear, each participant might be engaged in multiple, |  | is linear, each participant might be engaged in multiple, |
| simultaneous communications. For example, B might be receiving |  | simultaneous communications. For example, B might be receiving |
| requests from many clients other than A, and/or forwarding requests |  | requests from many clients other than A, and/or forwarding requests |
| to servers other than C, at the same time that it is handling A's |  | to servers other than C, at the same time that it is handling A's |
| request. Likewise, later requests might be sent through a different |  | request. Likewise, later requests might be sent through a different |
| path of connections, often based on dynamic configuration for load |  | path of connections, often based on dynamic configuration for load |
| balancing. |  | balancing. |
| We use the terms "upstream" and "downstream" to describe various |  | The terms "upstream" and "downstream" are used to describe |
| requirements in relation to the directional flow of a message: all |  | directional requirements in relation to the message flow: all |
| messages flow from upstream to downstream. Likewise, we use the |  | messages flow from upstream to downstream. The terms inbound and |
| terms inbound and outbound to refer to directions in relation to the |  | outbound are used to describe directional requirements in relation to |
| request path: "inbound" means toward the origin server and "outbound" |  | the request route: "inbound" means toward the origin server and |
| means toward the user agent. |  | "outbound" means toward the user agent. |
| A "proxy" is a message forwarding agent that is selected by the |  | A "proxy" is a message forwarding agent that is selected by the |
| client, usually via local configuration rules, to receive requests |  | client, usually via local configuration rules, to receive requests |
| for some type(s) of absolute URI and attempt to satisfy those |  | for some type(s) of absolute URI and attempt to satisfy those |
| requests via translation through the HTTP interface. Some |  | requests via translation through the HTTP interface. Some |
| translations are minimal, such as for proxy requests for "http" URIs, |  | translations are minimal, such as for proxy requests for "http" URIs, |
| whereas other requests might require translation to and from entirely |  | whereas other requests might require translation to and from entirely |
| different application-level protocols. Proxies are often used to |  | different application-level protocols. Proxies are often used to |
| group an organization's HTTP requests through a common intermediary |  | group an organization's HTTP requests through a common intermediary |
| for the sake of security, annotation services, or shared caching. |  | for the sake of security, annotation services, or shared caching. |
|  |  | Some proxies are designed to apply transformations to selected |
| An HTTP-to-HTTP proxy is called a "transforming proxy" if it is |  | messages or payloads while they are being forwarded, as described in |
| designed or configured to modify request or response messages in a |  | Section 5.7.2. |
| semantically meaningful way (i.e., modifications, beyond those |  |  |
| required by normal HTTP processing, that change the message in a way |  |  |
| that would be significant to the original sender or potentially |  |  |
| significant to downstream recipients). For example, a transforming |  |  |
| proxy might be acting as a shared annotation server (modifying |  |  |
| responses to include references to a local annotation database), a |  |  |
| malware filter, a format transcoder, or an intranet-to-Internet |  |  |
| privacy filter. Such transformations are presumed to be desired by |  |  |
| the client (or client organization) that selected the proxy and are |  |  |
| beyond the scope of this specification. However, when a proxy is not |  |  |
| intended to transform a given message, we use the term "non- |  |  |
| transforming proxy" to target requirements that preserve HTTP message |  |  |
| semantics. See Section 6.3.4 of [Part2] and Section 5.5 of [Part6] |  |  |
| 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. |
| All HTTP requirements applicable to an origin server also apply to |  | All HTTP requirements applicable to an origin server also apply to |
| skipping to change at page 11, line 18 |  | skipping to change at page 11, line 4 |
| initiated by an HTTP request. A tunnel ceases to exist when both |  | initiated by an HTTP request. A tunnel ceases to exist when both |
| ends of the relayed connection are closed. Tunnels are used to |  | ends of the relayed connection are closed. Tunnels are used to |
| extend a virtual connection through an intermediary, such as when |  | extend a virtual connection through an intermediary, such as when |
| Transport Layer Security (TLS, [RFC5246]) is used to establish |  | Transport Layer Security (TLS, [RFC5246]) is used to establish |
| confidential communication through a shared firewall proxy. |  | confidential communication through a shared firewall proxy. |
| The above categories for intermediary only consider those acting as |  | The above categories for intermediary only consider those acting as |
| participants in the HTTP communication. There are also |  | participants in the HTTP communication. There are also |
| intermediaries that can act on lower layers of the network protocol |  | intermediaries that can act on lower layers of the network protocol |
| stack, filtering or redirecting HTTP traffic without the knowledge or |  | stack, filtering or redirecting HTTP traffic without the knowledge or |
| permission of message senders. Network intermediaries often |  | permission of message senders. Network intermediaries are |
| introduce security flaws or interoperability problems by violating |  | indistinguishable (at a protocol level) from a man-in-the-middle |
| HTTP semantics. For example, an "interception proxy" [RFC3040] (also |  | attack, often introducing security flaws or interoperability problems |
| commonly known as a "transparent proxy" [RFC1919] or "captive |  | due to mistakenly violating HTTP semantics. |
| portal") differs from an HTTP proxy because it is not selected by the |  |  |
| client. Instead, an interception proxy filters or redirects outgoing |  | For example, an "interception proxy" [RFC3040] (also commonly known |
| TCP port 80 packets (and occasionally other common port traffic). |  | as a "transparent proxy" [RFC1919] or "captive portal") differs from |
| Interception proxies are commonly found on public network access |  | an HTTP proxy because it is not selected by the client. Instead, an |
| points, as a means of enforcing account subscription prior to |  | interception proxy filters or redirects outgoing TCP port 80 packets |
| allowing use of non-local Internet services, and within corporate |  | (and occasionally other common port traffic). Interception proxies |
| firewalls to enforce network usage policies. They are |  | are commonly found on public network access points, as a means of |
| indistinguishable from a man-in-the-middle attack. |  | enforcing account subscription prior to allowing use of non-local |
|  |  | Internet services, and within corporate firewalls to enforce network |
|  |  | usage policies. |
| 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, a |  | dynamically load-balance requests across multiple servers. Hence, a |
| server 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. |
| skipping to change at page 16, line 22 |  | skipping to change at page 16, line 12 |
| sufficiently backwards-compatible to be safely processed by any |  | sufficiently backwards-compatible to be safely processed by any |
| implementation of the same major version. |  | implementation of the same major version. |
| 2.7. Uniform Resource Identifiers |  | 2.7. Uniform Resource Identifiers |
| Uniform Resource Identifiers (URIs) [RFC3986] are used throughout |  | Uniform Resource Identifiers (URIs) [RFC3986] are used throughout |
| HTTP as the means for identifying resources (Section 2 of [Part2]). |  | HTTP as the means for identifying resources (Section 2 of [Part2]). |
| URI references are used to target requests, indicate redirects, and |  | URI references are used to target requests, indicate redirects, and |
| define relationships. |  | define relationships. |
| This specification adopts the definitions of "URI-reference", |  | The definitions of "URI-reference", "absolute-URI", "relative-part", |
| "absolute-URI", "relative-part", "authority", "port", "host", "path- |  | "scheme", "authority", "port", "host", "path-abempty", "segment", |
| abempty", "segment", "query", and "fragment" from the URI generic |  | "query", and "fragment" are adopted from the URI generic syntax. An |
| syntax. In addition, we define an "absolute-path" rule (that differs |  | "absolute-path" rule is defined for protocol elements that can |
| from RFC 3986's "path-absolute" in that it allows a leading "//") and |  | contain a non-empty path component. (This rule differs slightly from |
| a "partial-URI" rule for protocol elements that allow a relative URI |  | RFC 3986's path-abempty rule, which allows for an empty path to be |
| but not a fragment. |  | used in references, and path-absolute rule, which does not allow |
|  |  | paths that begin with "//".) A "partial-URI" rule is defined for |
|  |  | protocol elements that can contain a relative URI but not a fragment |
|  |  | component. |
| URI-reference = <URI-reference, defined in [RFC3986], Section 4.1> |  | URI-reference = <URI-reference, defined in [RFC3986], Section 4.1> |
| absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3> |  | absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3> |
| relative-part = <relative-part, defined in [RFC3986], Section 4.2> |  | relative-part = <relative-part, defined in [RFC3986], Section 4.2> |
|  |  | scheme = <scheme, defined in [RFC3986], Section 3.1> |
| authority = <authority, defined in [RFC3986], Section 3.2> |  | authority = <authority, defined in [RFC3986], Section 3.2> |
| uri-host = <host, defined in [RFC3986], Section 3.2.2> |  | uri-host = <host, defined in [RFC3986], Section 3.2.2> |
| port = <port, defined in [RFC3986], Section 3.2.3> |  | port = <port, defined in [RFC3986], Section 3.2.3> |
| path-abempty = <path-abempty, defined in [RFC3986], Section 3.3> |  | path-abempty = <path-abempty, defined in [RFC3986], Section 3.3> |
| segment = <segment, defined in [RFC3986], Section 3.3> |  | segment = <segment, defined in [RFC3986], Section 3.3> |
| query = <query, defined in [RFC3986], Section 3.4> |  | query = <query, defined in [RFC3986], Section 3.4> |
| fragment = <fragment, defined in [RFC3986], Section 3.5> |  | fragment = <fragment, defined in [RFC3986], Section 3.5> |
| absolute-path = 1*( "/" segment ) |  | absolute-path = 1*( "/" segment ) |
| partial-URI = relative-part [ "?" query ] |  | partial-URI = relative-part [ "?" query ] |
| skipping to change at page 17, line 13 |  | skipping to change at page 17, line 4 |
| are parsed relative to the effective request URI (Section 5.5). |  | are parsed relative to the effective request URI (Section 5.5). |
| 2.7.1. http URI scheme |  | 2.7.1. http URI scheme |
| The "http" URI scheme is hereby defined for the purpose of minting |  | The "http" URI scheme is hereby defined for the purpose of minting |
| identifiers according to their association with the hierarchical |  | identifiers according to their association with the hierarchical |
| namespace governed by a potential HTTP origin server listening for |  | namespace governed by a potential HTTP origin server listening for |
| TCP ([RFC0793]) connections on a given port. |  | TCP ([RFC0793]) connections on a given port. |
| 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 origin server for an "http" URI is identified by the authority |
| authority component, which includes a host identifier and optional |  | component, which includes a host identifier and optional TCP port |
| TCP port ([RFC3986], Section 3.2.2). The remainder of the URI, |  | ([RFC3986], Section 3.2.2). The hierarchical path component and |
| consisting of both the hierarchical path component and optional query |  | optional query component serve as an identifier for a potential |
| component, serves as an identifier for a potential resource within |  | target resource within that origin server's name space. The optional |
| that origin server's name space. |  | fragment component allows for indirect identification of a secondary |
|  |  | resource, independent of the URI scheme, as defined in Section 3.5 of |
|  |  | [RFC3986]. |
| A sender MUST NOT generate an "http" URI with an empty host |  | A sender MUST NOT generate an "http" URI with an empty host |
| identifier. A recipient that processes such a URI reference MUST |  | identifier. A recipient that processes such a URI reference MUST |
| reject it as invalid. |  | 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, the origin |
| server is any listener on the indicated TCP port at that IP address. |  | server is the listener (if any) on the indicated TCP port at that IP |
| If host is a registered name, then that name is considered an |  | address. If host is a registered name, the registered name is an |
| indirect identifier and the recipient might use a name resolution |  | indirect identifier for use with a name resolution service, such as |
| service, such as DNS, to find the address of a listener for that |  | DNS, to find an address for that origin server. If the port |
| host. If the port subcomponent is empty or not given, then TCP port |  | subcomponent is empty or not given, TCP port 80 (the reserved port |
| 80 is assumed (the default reserved port for WWW services). |  | for WWW services) is the default. |
| Regardless of the form of host identifier, access to that host is not |  | Note that the presence of a URI with a given authority component does |
| implied by the mere presence of its name or address. The host might |  | not imply that there is always an HTTP server listening for |
| or might not exist and, even when it does exist, might or might not |  | connections on that host and port. Anyone can mint a URI. What the |
| be running an HTTP server or listening to the indicated port. The |  | authority component determines is who has the right to respond |
| "http" URI scheme makes use of the delegated nature of Internet names |  | authoritatively to requests that target the identified resource. The |
| and addresses to establish a naming authority (whatever entity has |  | delegated nature of registered names and IP addresses creates a |
| the ability to place an HTTP server at that Internet name or address) |  | federated namespace, based on control over the indicated host and |
| and allows that authority to determine which names are valid and how |  | port, whether or not an HTTP server is present. See Section 9.1 for |
| they might be used. |  | security considerations related to establishing authority. |
| When an "http" URI is used within a context that calls for access to |  | When an "http" URI is used within a context that calls for access to |
| the indicated resource, a client MAY attempt access by resolving the |  | the indicated resource, a client MAY attempt access by resolving the |
| host to an IP address, establishing a TCP connection to that address |  | host to an IP address, establishing a TCP connection to that address |
| on the indicated port, and sending an HTTP request message |  | on the indicated port, and sending an HTTP request message |
| (Section 3) containing the URI's identifying data (Section 5) to the |  | (Section 3) containing the URI's identifying data (Section 5) to the |
| server. If the server responds to that request with a non-interim |  | server. If the server responds to that request with a non-interim |
| HTTP response message, as described in Section 6 of [Part2], then |  | HTTP response message, as described in Section 6 of [Part2], then |
| that response is considered an authoritative answer to the client's |  | that response is considered an authoritative answer to the client's |
| request. |  | request. |
| skipping to change at page 18, line 25 |  | skipping to change at page 18, line 19 |
| 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. A sender MUST NOT |  | usage might expose a user identifier or password. A sender MUST NOT |
| generate the userinfo subcomponent (and its "@" delimiter) when an |  | generate the userinfo subcomponent (and its "@" delimiter) when an |
| "http" URI reference is generated within a message as a request |  | "http" URI reference is generated within a message as a request |
| target or header field value. Before making use of an "http" URI |  | target or header field value. Before making use of an "http" URI |
| reference received from an untrusted source, a recipient ought to |  | reference received from an untrusted source, a recipient SHOULD parse |
| parse for userinfo and treat its presence as an error; it is likely |  | for userinfo and treat its presence as an error; it is likely being |
| being used to obscure the authority for the sake of phishing attacks. |  | 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 ([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 TCP port 443 is the |
| of 443 is assumed if the port subcomponent is empty or not given, and |  | default if the port subcomponent is empty or not given, and the user |
| the user agent MUST ensure that its connection to the origin server |  | agent MUST ensure that its connection to the origin server is secured |
| is secured through the use of strong encryption, end-to-end, prior to |  | through the use of strong encryption, end-to-end, prior to sending |
| sending the first HTTP request. |  | 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 15 |  | skipping to change at page 19, line 10 |
| to impact communication with other services within a matching group |  | to impact communication with other services within a matching group |
| of host domains. |  | of host domains. |
| The process for authoritative access to an "https" identified |  | The process for authoritative access to an "https" identified |
| resource is defined in [RFC2818]. |  | resource is defined in [RFC2818]. |
| 2.7.3. http and https URI Normalization and Comparison |  | 2.7.3. http and https URI Normalization and Comparison |
| Since the "http" and "https" schemes conform to the URI generic |  | Since the "http" and "https" schemes conform to the URI generic |
| syntax, such URIs are normalized and compared according to the |  | syntax, such URIs are normalized and compared according to the |
| algorithm defined in [RFC3986], Section 6, using the defaults |  | algorithm defined in Section 6 of [RFC3986], using the defaults |
| described above for each scheme. |  | described above for each scheme. |
| If the port is equal to the default port for a scheme, the normal |  | If the port is equal to the default port for a scheme, the normal |
| form is to omit the port subcomponent. When not being used in |  | form is to omit the port subcomponent. When not being used in |
| absolute form as the request target of an OPTIONS request, an empty |  | absolute form as the request target of an OPTIONS request, an empty |
| path component is equivalent to an absolute path of "/", so the |  | path component is equivalent to an absolute path of "/", so the |
| normal form is to provide a path of "/" instead. The scheme and host |  | normal form is to provide a path of "/" instead. The scheme and host |
| are case-insensitive and normally provided in lowercase; all other |  | are case-insensitive and normally provided in lowercase; all other |
| components are compared in a case-sensitive manner. Characters other |  | components are compared in a case-sensitive manner. Characters other |
| than those in the "reserved" set are equivalent to their percent- |  | than those in the "reserved" set are equivalent to their percent- |
| encoded octets (see [RFC3986], Section 2.1): the normal form is to |  | encoded octets: the normal form is to not encode them (see Sections |
| not encode them. |  | 2.1 and 2.2 of [RFC3986]). |
| For example, the following three URIs are equivalent: |  | For example, the following three URIs are equivalent: |
| http://example.com:80/~smith/home.html |  | http://example.com:80/~smith/home.html |
| http://EXAMPLE.com/%7Esmith/home.html |  | http://EXAMPLE.com/%7Esmith/home.html |
| http://EXAMPLE.com:/%7esmith/home.html |  | http://EXAMPLE.com:/%7esmith/home.html |
| 3. Message Format |  | 3. Message Format |
| All HTTP/1.1 messages consist of a start-line followed by a sequence |  | All HTTP/1.1 messages consist of a start-line followed by a sequence |
| skipping to change at page 21, line 43 |  | skipping to change at page 21, line 40 |
| 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. A recipient 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, as described in Section 2.5. A server that receives a method |
| implements SHOULD respond with a 501 (Not Implemented) status code. |  | longer than any that it implements SHOULD respond with a 501 (Not |
| A server ought to be prepared to receive URIs of unbounded length, as |  | Implemented) status code. A server that receives a request-target |
| described in Section 2.5, and MUST respond with a 414 (URI Too Long) |  | longer than any URI it wishes to parse MUST respond with a 414 (URI |
| status code if the received request-target is longer than the server |  | Too Long) status code (see 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 37 |  | skipping to change at page 22, line 36 |
| The reason-phrase element exists for the sole purpose of providing a |  | The reason-phrase element exists for the sole purpose of providing a |
| textual description associated with the numeric status code, mostly |  | textual description associated with the numeric status code, mostly |
| out of deference to earlier Internet application protocols that were |  | out of deference to earlier Internet application protocols that were |
| more frequently used with interactive text clients. A client SHOULD |  | more frequently used with interactive text clients. A client SHOULD |
| ignore the reason-phrase content. |  | ignore the reason-phrase content. |
| reason-phrase = *( HTAB / SP / VCHAR / obs-text ) |  | reason-phrase = *( HTAB / SP / VCHAR / obs-text ) |
| 3.2. Header Fields |  | 3.2. Header Fields |
| Each HTTP header field consists of a case-insensitive field name |  | Each header field consists of a case-insensitive field name followed |
| followed by a colon (":"), optional leading whitespace, the field |  | by a colon (":"), optional leading whitespace, the field value, and |
| value, and optional trailing whitespace. |  | optional trailing whitespace. |
| header-field = field-name ":" OWS field-value OWS |  | header-field = field-name ":" OWS field-value OWS |
| field-name = token |  | field-name = token |
| field-value = *( field-content / obs-fold ) |  | field-value = *( field-content / obs-fold ) |
| field-content = *( HTAB / SP / VCHAR / obs-text ) |  | field-content = field-vchar [ 1*( SP / HTAB ) field-vchar ] |
| obs-fold = CRLF ( SP / HTAB ) |  | field-vchar = VCHAR / obs-text |
|  |  | obs-fold = CRLF 1*( SP / HTAB ) |
| ; 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 |
| 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 this document |
| standard. |  | set. |
| New header fields can be defined such that, when they are understood |  | New header fields can be defined such that, when they are understood |
| by a recipient, they might override or enhance the interpretation of |  | by a recipient, they might override or enhance the interpretation of |
| previously defined header fields, define preconditions on request |  | previously defined header fields, define preconditions on request |
| evaluation, or refine the meaning of responses. |  | evaluation, or refine the meaning of responses. |
| A proxy MUST forward unrecognized header fields unless the field-name |  | 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 listed in the Connection header field (Section 6.1) or the proxy |
| is specifically configured to block, or otherwise transform, such |  | is specifically configured to block, or otherwise transform, such |
| fields. Other recipients SHOULD ignore unrecognized header fields. |  | fields. Other recipients SHOULD ignore unrecognized header fields. |
| These requirements allow HTTP's functionality to be enhanced without |  | These requirements allow HTTP's functionality to be enhanced without |
| requiring prior update of deployed intermediaries. |  | requiring prior update of deployed intermediaries. |
| All defined header fields ought to be registered with IANA in the |  | 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]. |  | [Part2]. |
| 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 NOT |
| wait until the entire header section is received before interpreting |  | apply a request to the target resource until the entire request |
| a request message, since later header fields might include |  | header section is received, 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). |
| A recipient MAY combine multiple header fields with the same field |  | A recipient MAY combine multiple header fields with the same field |
| name into one "field-name: field-value" pair, without changing the |  | name into one "field-name: field-value" pair, without changing the |
| skipping to change at page 24, line 48 |  | skipping to change at page 25, line 7 |
| OWS = *( SP / HTAB ) |  | OWS = *( SP / HTAB ) |
| ; optional whitespace |  | ; optional whitespace |
| RWS = 1*( SP / HTAB ) |  | RWS = 1*( SP / HTAB ) |
| ; required whitespace |  | ; required whitespace |
| BWS = OWS |  | BWS = OWS |
| ; "bad" whitespace |  | ; "bad" whitespace |
| 3.2.4. Field Parsing |  | 3.2.4. Field Parsing |
|  |  | Messages are parsed using a generic algorithm, independent of the |
|  |  | individual header field names. The contents within a given field |
|  |  | value are not parsed until a later stage of message interpretation |
|  |  | (usually after the message's entire header section has been |
|  |  | processed). Consequently, this specification does not use ABNF rules |
|  |  | to define each "Field-Name: Field Value" pair, as was done in |
|  |  | previous editions. Instead, this specification uses ABNF rules which |
|  |  | are named according to each registered field name, wherein the rule |
|  |  | defines the valid grammar for that field's corresponding field values |
|  |  | (i.e., after the field-value has been extracted from the header |
|  |  | section by a generic field parser). |
| No whitespace is allowed between the header field-name and colon. In |  | No whitespace is allowed between the header field-name and colon. In |
| the past, differences in the handling of such whitespace have led to |  | the past, differences in the handling of such whitespace have led to |
| security vulnerabilities in request routing and response handling. A |  | security vulnerabilities in request routing and response handling. A |
| server MUST reject any received request message that contains |  | server MUST reject any received request message that contains |
| whitespace between a header field-name and colon with a response code |  | whitespace between a header field-name and colon with a response code |
| of 400 (Bad Request). A proxy MUST remove any such whitespace from a |  | of 400 (Bad Request). A proxy MUST remove any such whitespace from a |
| response message before forwarding the message downstream. |  | response message before forwarding the message downstream. |
| A field value is preceded by optional whitespace (OWS); a single SP |  | A field value might be preceded and/or followed by optional |
| is preferred. The field value does not include any leading or |  | whitespace (OWS); a single SP preceding the field-value is preferred |
| trailing white space: OWS occurring before the first non-whitespace |  | for consistent readability by humans. The field value does not |
| octet of the field value or after the last non-whitespace octet of |  | include any leading or trailing white space: OWS occurring before the |
| the field value ought to be excluded by parsers when extracting the |  | first non-whitespace octet of the field value or after the last non- |
| field value from a header field. |  | whitespace octet of the field value ought to be excluded by parsers |
|  |  | when extracting the field value from a header field. |
| A recipient of field-content containing multiple sequential octets of |  |  |
| optional (OWS) or required (RWS) whitespace SHOULD either replace the |  |  |
| sequence with a single SP or transform any non-SP octets in the |  |  |
| sequence to SP octets before interpreting the field value or |  |  |
| 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 8.3.1). A sender MUST NOT generate a message that includes |  | (Section 8.3.1). A sender MUST NOT generate a message that includes |
| line folding (i.e., that has any field-value that contains a match to |  | line folding (i.e., that has any field-value that contains a match to |
| the obs-fold rule) unless the message is intended for packaging |  | the obs-fold rule) unless the message is intended for packaging |
| within the message/http media type. |  | within the message/http media type. |
| skipping to change at page 26, line 19 |  | skipping to change at page 26, line 31 |
| 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 section as a whole, as described |  | field or on the length of the header section as a whole, as described |
| in Section 2.5. Various ad-hoc limitations on individual header |  | in Section 2.5. Various ad-hoc limitations on individual header |
| field length are found in practice, often depending on the specific |  | field length are found in practice, often depending on the specific |
| field semantics. |  | field semantics. |
| A server ought to be prepared to receive request header fields of |  | A server that receives a request header field, or set of fields, |
| unbounded length and MUST respond with an appropriate 4xx (Client |  | larger than it wishes to process MUST respond with an appropriate 4xx |
| Error) status code if the received header field(s) are larger than |  | (Client Error) status code. Ignoring such header fields would |
| the server wishes to process. |  | increase the server's vulnerability to request smuggling attacks |
|  |  | (Section 9.5). |
| A client ought to be prepared to receive response header fields of |  | A client MAY discard or truncate received header fields that are |
| unbounded length. A client MAY discard or truncate received header |  | larger than the client wishes to process if the field semantics are |
| fields that are larger than the client wishes to process if the field |  | such that the dropped value(s) can be safely ignored without changing |
| semantics are such that the dropped value(s) can be safely ignored |  | the message framing or 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- |  | Most HTTP header field values are defined using common syntax |
| string) separated by whitespace or special characters. |  | components (token, quoted-string, and comment) separated by |
|  |  | whitespace or specific delimiting characters. Delimiters are chosen |
| word = token / quoted-string |  | from the set of US-ASCII visual characters not allowed in a token |
|  |  | (DQUOTE and "(),/:;<=>?@[\]{}"). |
| token = 1*tchar |  | token = 1*tchar |
| tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" |  | tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" |
| / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" |  | / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" |
| / DIGIT / ALPHA |  | / DIGIT / ALPHA |
| ; any VCHAR, except special |  | ; any VCHAR, except delimiters |
| special = "(" / ")" / "<" / ">" / "@" / "," |  |  |
| / ";" / ":" / "\" / DQUOTE / "/" / "[" |  |  |
| / "]" / "?" / "=" / "{" / "}" |  |  |
| A string of text is parsed as a single word if it is quoted using |  | A string of text is parsed as a single value if it is quoted using |
| double-quote marks. |  | double-quote marks. |
| quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE |  | quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE |
| qdtext = HTAB / SP /%x21 / %x23-5B / %x5D-7E / obs-text |  | qdtext = HTAB / SP /%x21 / %x23-5B / %x5D-7E / obs-text |
| obs-text = %x80-FF |  | obs-text = %x80-FF |
| The backslash octet ("\") can be used as a single-octet quoting |  |  |
| mechanism within quoted-string constructs: |  |  |
| quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text ) |  |  |
| Recipients that process the value of a quoted-string MUST handle a |  |  |
| quoted-pair as if it were replaced by the octet following the |  |  |
| backslash. |  |  |
| A sender SHOULD NOT generate a quoted-pair in a quoted-string except |  |  |
| where necessary to quote DQUOTE and backslash octets occurring within |  |  |
| that string. |  |  |
| Comments can be included in some HTTP header fields by surrounding |  | Comments can be included in some HTTP header fields by surrounding |
| the comment text with parentheses. Comments are only allowed in |  | the comment text with parentheses. Comments are only allowed in |
| fields containing "comment" as part of their field value definition. |  | fields containing "comment" as part of their field value definition. |
| comment = "(" *( ctext / quoted-cpair / comment ) ")" |  | comment = "(" *( ctext / quoted-pair / 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 quoted-string and comment constructs. Recipients |
|  |  | that process the value of a quoted-string MUST handle a quoted-pair |
|  |  | as if it were replaced by the octet following the backslash. |
| quoted-cpair = "\" ( HTAB / SP / VCHAR / obs-text ) |  | quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text ) |
| A sender SHOULD NOT escape octets in comments that do not require |  | A sender SHOULD NOT generate a quoted-pair in a quoted-string except |
| escaping (i.e., other than the backslash octet "\" and the |  | where necessary to quote DQUOTE and backslash octets occurring within |
| parentheses "(" and ")"). |  | that string. A sender SHOULD NOT generate a quoted-pair in a comment |
|  |  | except where necessary to quote parentheses ["(" and ")"] and |
|  |  | backslash octets occurring within that comment. |
| 3.3. Message Body |  | 3.3. Message Body |
| The message body (if any) of an HTTP message is used to carry the |  | The message body (if any) of an HTTP message is used to carry the |
| payload body of that request or response. The message body is |  | payload body of that request or response. The message body is |
| identical to the payload body unless a transfer coding has been |  | identical to the payload body unless a transfer coding has been |
| applied, as described in Section 3.3.1. |  | applied, as described in Section 3.3.1. |
| message-body = *OCTET |  | message-body = *OCTET |
| The rules for when a message body is allowed in a message differ for |  | The rules for when a message body is allowed in a message differ for |
| requests and responses. |  | requests and responses. |
| The presence of a message body in a request is signaled by a Content- |  | The presence of a message body in a request is signaled by a Content- |
| Length or Transfer-Encoding header field. Request message framing is |  | Length or Transfer-Encoding header field. Request message framing is |
| independent of method semantics, even if the method does not define |  | independent of method semantics, even if the method does not define |
| any use for a message body. |  | any use for a message body. |
| The presence of a message body in a response depends on both the |  | The presence of a message body in a response depends on both the |
| request method to which it is responding and the response status code |  | request method to which it is responding and the response status code |
| (Section 3.1.2). Responses to the HEAD request method never include |  | (Section 3.1.2). Responses to the HEAD request method (Section 4.3.2 |
| a message body because the associated response header fields (e.g., |  | of [Part2]) never include a message body because the associated |
| Transfer-Encoding, Content-Length, etc.), if present, indicate only |  | response header fields (e.g., Transfer-Encoding, Content-Length, |
| what their values would have been if the request method had been GET |  | etc.), if present, indicate only what their values would have been if |
| (Section 4.3.2 of [Part2]). 2xx (Successful) responses to CONNECT |  | the request method had been GET (Section 4.3.1 of [Part2]). 2xx |
| switch to tunnel mode instead of having a message body (Section 4.3.6 |  | (Successful) responses to a CONNECT request method (Section 4.3.6 of |
| of [Part2]). All 1xx (Informational), 204 (No Content), and 304 (Not |  | [Part2]) switch to tunnel mode instead of having a message body. All |
| Modified) responses do not include a message body. All other |  | 1xx (Informational), 204 (No Content), and 304 (Not Modified) |
| responses do include a message body, although the body might be of |  | responses do not include a message body. All other responses do |
| zero length. |  | include a message body, although the body might be of zero length. |
| 3.3.1. Transfer-Encoding |  | 3.3.1. Transfer-Encoding |
| The Transfer-Encoding header field lists the transfer coding names |  | The Transfer-Encoding header field lists the transfer coding names |
| corresponding to the sequence of transfer codings that have been (or |  | corresponding to the sequence of transfer codings that have been (or |
| will be) applied to the payload body in order to form the message |  | will be) applied to the payload body in order to form the message |
| body. Transfer codings are defined in Section 4. |  | body. Transfer codings are defined in Section 4. |
| Transfer-Encoding = 1#transfer-coding |  | Transfer-Encoding = 1#transfer-coding |
| skipping to change at page 29, line 19 |  | skipping to change at page 29, line 19 |
| 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- |
| Encoding is a property of the message, not of the representation, and |  | Encoding is a property of the message, not of the representation, and |
| any recipient along the request/response chain MAY decode the |  | any recipient along the request/response chain MAY decode the |
| received transfer coding(s) or apply additional transfer coding(s) to |  | received transfer coding(s) or apply additional transfer coding(s) to |
| the message body, assuming that corresponding changes are made to the |  | the message body, assuming that corresponding changes are made to the |
| Transfer-Encoding field-value. Additional information about the |  | Transfer-Encoding field-value. Additional information about the |
| encoding parameters MAY be provided by other header fields not |  | encoding parameters can be provided by other header fields not |
| defined by this specification. |  | defined by this specification. |
| Transfer-Encoding MAY be sent in a response to a HEAD request or in a |  | Transfer-Encoding MAY be sent in a response to a HEAD request or in a |
| 304 (Not Modified) response (Section 4.1 of [Part4]) to a GET |  | 304 (Not Modified) response (Section 4.1 of [Part4]) to a GET |
| request, neither of which includes a message body, to indicate that |  | request, neither of which includes a message body, to indicate that |
| the origin server would have applied a transfer coding to the message |  | the origin server would have applied a transfer coding to the message |
| body if the request had been an unconditional GET. This indication |  | body if the request had been an unconditional GET. This indication |
| is not required, however, because any recipient on the response chain |  | is not required, however, because any recipient on the response chain |
| (including the origin server) can remove transfer codings when they |  | (including the origin server) can remove transfer codings when they |
| are not needed. |  | are not needed. |
| skipping to change at page 32, line 19 |  | skipping to change at page 32, line 19 |
| message body length is determined by reading the connection until |  | message body length is determined by reading the connection until |
| it is closed by the server. If a Transfer-Encoding header field |  | it is closed by the server. If a Transfer-Encoding header field |
| is present in a request and the chunked transfer coding is not |  | is present in a request and the chunked transfer coding is not |
| the final encoding, the message body length cannot be determined |  | the final encoding, the message body length cannot be determined |
| reliably; the server MUST respond with the 400 (Bad Request) |  | reliably; the server MUST respond with the 400 (Bad Request) |
| status code and then close the connection. |  | status code and then close the connection. |
| If a message is received with both a Transfer-Encoding and a |  | If a message is received with both a Transfer-Encoding and a |
| Content-Length header field, the Transfer-Encoding overrides the |  | Content-Length header field, the Transfer-Encoding overrides the |
| Content-Length. Such a message might indicate an attempt to |  | Content-Length. Such a message might indicate an attempt to |
| perform request or response smuggling (bypass of security-related |  | perform request smuggling (Section 9.5) or response splitting |
| checks on message routing or content) and thus ought to be |  | (Section 9.4) and ought to be handled as an error. A sender MUST |
| handled as an error. A sender MUST remove the received Content- |  | remove the received Content-Length field prior to forwarding such |
| Length field prior to forwarding such a message downstream. |  | 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 the |  | invalid value, then the message framing is invalid and the |
| recipient MUST treat it as an unrecoverable error to prevent |  | recipient MUST treat it as an unrecoverable error. If this is a |
| request or response smuggling. If this is a request message, the |  | request message, the server MUST respond with a 400 (Bad Request) |
| server MUST respond with a 400 (Bad Request) status code and then |  | status code and then close the connection. If this is a response |
| close the connection. If this is a response message received by |  | message received by a proxy, the proxy MUST close the connection |
| a proxy, the proxy MUST close the connection to the server, |  | to the server, discard the received response, and send a 502 (Bad |
| discard the received response, and send a 502 (Bad Gateway) |  | Gateway) response to the client. If this is a response message |
| response to the client. If this is a response message received |  | received by a user agent, the user agent MUST close the |
| by a user agent, the user agent MUST close the connection to the |  | connection to the server and discard the received response. |
| 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). |
| skipping to change at page 34, line 43 |  | skipping to change at page 34, line 43 |
| 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, a recipient 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. However, lenient parsing can |
|  |  | result in security vulnerabilities if there are multiple recipients |
|  |  | of the message and each has its own unique interpretation of |
|  |  | robustness (see Section 9.5). |
| When a server listening only for HTTP request messages, or processing |  | When a server listening only for HTTP request messages, or processing |
| what appears from the start-line to be an HTTP request message, |  | what appears from the start-line to be an HTTP request message, |
| receives a sequence of octets that does not match the HTTP-message |  | receives a sequence of octets that does not match the HTTP-message |
| grammar aside from the robustness exceptions listed above, the server |  | grammar aside from the robustness exceptions listed above, the server |
| SHOULD respond with a 400 (Bad Request) response. |  | SHOULD respond with a 400 (Bad Request) response. |
| 4. Transfer Codings |  | 4. Transfer Codings |
| Transfer coding names are used to indicate an encoding transformation |  | Transfer coding names are used to indicate an encoding transformation |
| skipping to change at page 35, line 21 |  | skipping to change at page 35, line 22 |
| property of the message rather than a property of the representation |  | property of the message rather than a property of the representation |
| that is being transferred. |  | that is being transferred. |
| transfer-coding = "chunked" ; Section 4.1 |  | transfer-coding = "chunked" ; Section 4.1 |
| / "compress" ; Section 4.2.1 |  | / "compress" ; Section 4.2.1 |
| / "deflate" ; Section 4.2.2 |  | / "deflate" ; Section 4.2.2 |
| / "gzip" ; Section 4.2.3 |  | / "gzip" ; Section 4.2.3 |
| / transfer-extension |  | / transfer-extension |
| transfer-extension = token *( OWS ";" OWS transfer-parameter ) |  | transfer-extension = token *( OWS ";" OWS transfer-parameter ) |
| Parameters are in the form of attribute/value pairs. |  | Parameters are in the form of a name or name=value pair. |
| transfer-parameter = attribute BWS "=" BWS value |  | transfer-parameter = token BWS "=" BWS ( token / quoted-string ) |
| attribute = token |  |  |
| 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 8.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 wraps the payload body in order to |  | The chunked transfer coding wraps the payload body in order to |
| transfer it as a series of chunks, each with its own size indicator, |  | transfer it as a series of chunks, each with its own size indicator, |
| skipping to change at page 36, line 23 |  | skipping to change at page 36, line 23 |
| 4.1.1. Chunk Extensions |  | 4.1.1. Chunk Extensions |
| The chunked encoding allows each chunk to include zero or more chunk |  | The chunked encoding allows each chunk to include zero or more chunk |
| extensions, immediately following the chunk-size, for the sake of |  | extensions, immediately following the chunk-size, for the sake of |
| supplying per-chunk metadata (such as a signature or hash), mid- |  | supplying per-chunk metadata (such as a signature or hash), mid- |
| message control information, or randomization of message body size. |  | 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-string |
| quoted-str-nf = DQUOTE *( qdtext-nf / quoted-pair ) DQUOTE |  |  |
| ; like quoted-string, but disallowing line folding |  |  |
| qdtext-nf = HTAB / SP / %x21 / %x23-5B / %x5D-7E / obs-text |  |  |
| The chunked encoding is specific to each connection and is likely to |  | The chunked encoding is specific to each connection and is likely to |
| be removed or recoded by each recipient (including intermediaries) |  | be removed or recoded by each recipient (including intermediaries) |
| before any higher-level application would have a chance to inspect |  | before any higher-level application would have a chance to inspect |
| the extensions. Hence, use of chunk extensions is generally limited |  | the extensions. Hence, use of chunk extensions is generally limited |
| to specialized HTTP services such as "long polling" (where client and |  | to specialized HTTP services such as "long polling" (where client and |
| server can have shared expectations regarding the use of chunk |  | server can have shared expectations regarding the use of chunk |
| extensions) or for padding within an end-to-end secured connection. |  | extensions) or for padding within an end-to-end secured connection. |
| A recipient MUST ignore unrecognized chunk extensions. A server |  | A recipient MUST ignore unrecognized chunk extensions. A server |
| skipping to change at page 37, line 7 |  | skipping to change at page 36, line 52 |
| 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 fields are identical to header fields, except |  | status. The trailer fields are identical to header fields, except |
| they are sent in a chunked trailer instead of the message's header |  | they are sent in a chunked trailer instead of the message's header |
| section. |  | section. |
| trailer-part = *( header-field CRLF ) |  | trailer-part = *( header-field CRLF ) |
| A sender MUST NOT generate a trailer that contains a field which |  | A sender MUST NOT generate a trailer that contains a field necessary |
| needs to be known by the recipient before it can begin processing the |  | for message framing (e.g., Transfer-Encoding and Content-Length), |
| message body. For example, most recipients need to know the values |  | routing (e.g., Host), request modifiers (e.g., controls and |
| of Content-Encoding and Content-Type in order to select a content |  | conditionals in Section 5 of [Part2]), authentication (e.g., see |
| handler, so placing those fields in a trailer would force the |  | [Part7] and [RFC6265]), response control data (e.g., see Section 7.1 |
| recipient to buffer the entire body before it could begin, greatly |  | of [Part2]), or determining how to process the payload (e.g., |
| increasing user-perceived latency and defeating one of the main |  | Content-Encoding, Content-Type, Content-Range, and Trailer). |
| 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 generate an empty trailer with the chunked transfer |  |  |
| coding unless at least one of the following is true: |  |  |
| 1. the request included a TE header field that indicates "trailers" |  |  |
| is acceptable in the transfer coding of the response, as |  |  |
| described in Section 4.3; or, |  |  |
| 2. the trailer fields consist entirely of optional metadata and the |  | When a chunked message containing a non-empty trailer is received, |
| recipient could use the message (in a manner acceptable to the |  | the recipient MAY process the fields (aside from those forbidden |
| generating server) without receiving that metadata. In other |  | above) as if they were appended to the message's header section. A |
| words, the generating server is willing to accept the possibility |  | recipient MUST ignore (or consider as an error) any fields that are |
| that the trailer fields might be silently discarded along the |  | forbidden to be sent in a trailer, since processing them as if they |
| path to the client. |  | were present in the header section might bypass external security |
|  |  | filters. |
| The above requirement prevents the need for an infinite buffer when a |  | Unless the request includes a TE header field indicating "trailers" |
| message is being received by an HTTP/1.1 (or later) proxy and |  | is acceptable, as described in Section 4.3, a server SHOULD NOT |
| forwarded to an HTTP/1.0 recipient. |  | generate trailer fields that it believes are necessary for the user |
|  |  | agent to receive. Without a TE containing "trailers", the server |
|  |  | ought to assume that the trailer fields might be silently discarded |
|  |  | along the path to the user agent. This requirement allows |
|  |  | intermediaries to forward a de-chunked message to an HTTP/1.0 |
|  |  | recipient without buffering the entire response. |
| 4.1.3. 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 |
| read chunk-size, chunk-ext (if any), and CRLF |  | read chunk-size, chunk-ext (if any), and CRLF |
| } |  | } |
| read header-field |  | read trailer field |
| while (header-field not empty) { |  | while (trailer field is not empty) { |
| append header-field to existing header fields |  | if (trailer field is allowed to be sent in a trailer) { |
| read header-field |  | append trailer field to existing header fields |
|  |  | } |
|  |  | read trailer-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 |
| 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. |
| skipping to change at page 38, line 40 |  | skipping to change at page 38, line 23 |
| [Welch] that is commonly produced by the UNIX file compression |  | [Welch] that is commonly produced by the UNIX file compression |
| program "compress". A recipient 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 non-conformant implementations send the "deflate" |
| data without the zlib wrapper. |  | compressed 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]. A |  | commonly produced by the gzip file compression program [RFC1952]. A |
| recipient 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, |
| skipping to change at page 41, line 38 |  | skipping to change at page 41, line 24 |
| request message (Section 3) with a request-target derived from the |  | request message (Section 3) with a request-target derived from the |
| target URI. There are four distinct formats for the request-target, |  | target URI. There are four distinct formats for the request-target, |
| depending on both the method being requested and whether the request |  | depending on both the method being requested and whether the request |
| is to a proxy. |  | is to a proxy. |
| request-target = origin-form |  | request-target = origin-form |
| / absolute-form |  | / absolute-form |
| / authority-form |  | / authority-form |
| / asterisk-form |  | / asterisk-form |
| origin-form = absolute-path [ "?" query ] |  | 5.3.1. origin-form |
| absolute-form = absolute-URI |  |  |
| authority-form = authority |  |  |
| asterisk-form = "*" |  |  |
| origin-form |  | The most common form of request-target is the origin-form. |
| The most common form of request-target is the origin-form. When |  | origin-form = absolute-path [ "?" query ] |
| making a request directly to an origin server, other than a CONNECT |  |  |
| or server-wide OPTIONS request (as detailed below), a client MUST |  | When making a request directly to an origin server, other than a |
| send only the absolute path and query components of the target URI as |  | CONNECT or server-wide OPTIONS request (as detailed below), a client |
| the request-target. If the target URI's path component is empty, |  | MUST send only the absolute path and query components of the target |
| then the client MUST send "/" as the path within the origin-form of |  | URI as the request-target. If the target URI's path component is |
|  |  | empty, 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. |  | Section 5.4. |
| 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: |
| GET /where?q=now HTTP/1.1 |  | GET /where?q=now HTTP/1.1 |
| Host: www.example.org |  | Host: www.example.org |
| followed by the remainder of the request message. |  | followed by the remainder of the request message. |
| absolute-form |  | 5.3.2. absolute-form |
| When making a request to a proxy, other than a CONNECT or server-wide |  | When making a request to a proxy, other than a CONNECT or server-wide |
| OPTIONS request (as detailed below), a client MUST send the target |  | OPTIONS request (as detailed below), a client MUST send the target |
| URI in absolute-form as the request-target. The proxy is requested |  | URI in absolute-form as the request-target. |
| to either service that request from a valid cache, if possible, or |  |  |
| make the same request on the client's behalf to either the next |  | absolute-form = absolute-URI |
| inbound proxy server or directly to the origin server indicated by |  |  |
| the request-target. Requirements on such "forwarding" of messages |  | The proxy is requested to either service that request from a valid |
| are defined in Section 5.7. |  | cache, if possible, or make the same request on the client's behalf |
|  |  | to either the next inbound proxy server or directly to the origin |
|  |  | server indicated by the request-target. Requirements on such |
|  |  | "forwarding" of messages 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, a server MUST accept the absolute-form in |  | future version of HTTP, a server MUST accept the absolute-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 |  | 5.3.3. 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]). |
| to establish a tunnel through one or more proxies, a client MUST send |  |  |
| only the target URI's authority component (excluding any userinfo and |  | authority-form = authority |
| its "@" delimiter) as the request-target. For example, |  |  |
|  |  | When making a CONNECT request to establish a tunnel through one or |
|  |  | more proxies, a client MUST send only the target URI's authority |
|  |  | component (excluding any userinfo and 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 |  | 5.3.4. 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]). |
| request OPTIONS for the server as a whole, as opposed to a specific |  |  |
| named resource of that server, the client MUST send only "*" (%x2A) |  |  |
| as the request-target. For example, |  |  |
|  |  | asterisk-form = "*" |
|  |  | When a client wishes to request OPTIONS for the server as a whole, as |
|  |  | opposed to a specific named resource of that server, the client MUST |
|  |  | send only "*" (%x2A) as the request-target. For example, |
| OPTIONS * HTTP/1.1 |  | OPTIONS * HTTP/1.1 |
| If a proxy receives an OPTIONS request with an absolute-form of |  | If a proxy receives an OPTIONS request with an absolute-form of |
| request-target in which the URI has an empty path and no query |  | request-target in which the URI has an empty path and no query |
| component, then the last proxy on the request chain MUST send a |  | component, then the last proxy on the request chain MUST send a |
| request-target of "*" when it forwards the request to the indicated |  | request-target of "*" when it forwards the request to the indicated |
| origin server. |  | origin server. |
| For example, the request |  | For example, the request |
| skipping to change at page 44, line 34 |  | skipping to change at page 44, line 30 |
| the intercepted connection is targeting a valid IP address for that |  | the intercepted connection is targeting a valid IP address for that |
| host. |  | host. |
| A server MUST respond with a 400 (Bad Request) status code to any |  | A server MUST respond with a 400 (Bad Request) status code to any |
| HTTP/1.1 request message that lacks a Host header field and to any |  | HTTP/1.1 request message that lacks a Host header field and to any |
| request message that contains more than one Host header field or a |  | request message that contains more than one Host header field or a |
| Host header field with an invalid field-value. |  | Host header field with an invalid field-value. |
| 5.5. Effective Request URI |  | 5.5. Effective Request URI |
| A server that receives an HTTP request message MUST reconstruct the |  | Since the request-target often contains only part of the user agent's |
| user agent's original target URI, based on the pieces of information |  | target URI, a server reconstructs the intended target as an |
| learned from the request-target, Host header field, and connection |  | "effective request URI" to properly service the request. This |
| context, in order to identify the intended target resource and |  | reconstruction involves both the server's local configuration and |
| properly service the request. The URI derived from this |  | information communicated in the request-target, Host header field, |
| reconstruction process is referred to as the "effective request URI". |  | and connection context. |
| For a user agent, the effective request URI is the target URI. |  | For a user agent, the effective request URI is the target URI. |
| If the request-target is in absolute-form, then the effective request |  | If the request-target is in absolute-form, the effective request URI |
| URI is the same as the request-target. Otherwise, the effective |  | is the same as the request-target. Otherwise, the effective request |
| request URI is constructed as follows. |  | URI is constructed as follows: |
| If the request is received over a TLS-secured TCP connection, then |  | If the server's configuration (or outbound gateway) provides a |
| the effective request URI's scheme is "https"; otherwise, the scheme |  | fixed URI scheme, that scheme is used for the effective request |
| is "http". |  | URI. Otherwise, if the request is received over a TLS-secured TCP |
|  |  | connection, the effective request URI's scheme is "https"; if not, |
|  |  | the scheme is "http". |
| If the request-target is in authority-form, then the effective |  | If the server's configuration (or outbound gateway) provides a |
| request URI's authority component is the same as the request-target. |  | fixed URI authority component, that authority is used for the |
| Otherwise, if a Host header field is supplied with a non-empty field- |  | effective request URI. If not, then if the request-target is in |
| value, then the authority component is the same as the Host field- |  | authority-form, the effective request URI's authority component is |
| value. Otherwise, the authority component is the concatenation of |  | the same as the request-target. If not, then if a Host header |
| the default host name configured for the server, a colon (":"), and |  | field is supplied with a non-empty field-value, the authority |
| the connection's incoming TCP port number in decimal form. |  | component is the same as the Host field-value. Otherwise, the |
|  |  | authority component is assigned the default name configured for |
|  |  | the server and, if the connection's incoming TCP port number |
|  |  | differs from the default port for the effective request URI's |
|  |  | scheme, then a colon (":") and the incoming port number (in |
|  |  | decimal form) are appended to the authority component. |
| If the request-target is in authority-form or asterisk-form, then the |  | If the request-target is in authority-form or asterisk-form, the |
| effective request URI's combined path and query component is empty. |  | effective request URI's combined path and query component is |
| Otherwise, the combined path and query component is the same as the |  | empty. Otherwise, the combined path and query component is the |
| request-target. |  | same as the request-target. |
| The components of the effective request URI, once determined as |  | The components of the effective request URI, once determined as |
| above, can be combined into absolute-URI form by concatenating the |  | above, can be combined into absolute-URI form by concatenating the |
| scheme, "://", authority, and combined path and query component. |  | scheme, "://", authority, and combined path and query component. |
| Example 1: the following message received over an insecure TCP |  | Example 1: the following message received over an insecure TCP |
| connection |  | connection |
| GET /pub/WWW/TheProject.html HTTP/1.1 |  | GET /pub/WWW/TheProject.html HTTP/1.1 |
| Host: www.example.org:8080 |  | Host: www.example.org:8080 |
| has an effective request URI of |  | has an effective request URI of |
| http://www.example.org:8080/pub/WWW/TheProject.html |  | http://www.example.org:8080/pub/WWW/TheProject.html |
| skipping to change at page 45, line 40 |  | skipping to change at page 45, line 43 |
| Example 2: the following message received over a TLS-secured TCP |  | Example 2: the following message received over a TLS-secured TCP |
| connection |  | connection |
| OPTIONS * HTTP/1.1 |  | OPTIONS * HTTP/1.1 |
| Host: www.example.org |  | Host: www.example.org |
| has an effective request URI of |  | has an effective request URI of |
| https://www.example.org |  | https://www.example.org |
| An origin server that does not allow resources to differ by requested |  | Recipients of an HTTP/1.0 request that lacks a Host header field |
| host MAY ignore the Host field-value and instead replace it with a |  | might need to use heuristics (e.g., examination of the URI path for |
| configured server name when constructing the effective request URI. |  |  |
| Recipients of an HTTP/1.0 request that lacks a Host header field MAY |  |  |
| attempt to use heuristics (e.g., examination of the URI path for |  |  |
| something unique to a particular host) in order to guess the |  | something unique to a particular host) in order to guess the |
| effective request URI's authority component. |  | effective request URI's authority component. |
|  |  | Once the effective request URI has been constructed, an origin server |
|  |  | needs to decide whether or not to provide service for that URI via |
|  |  | the connection in which the request was received. For example, the |
|  |  | request might have been misdirected, deliberately or accidentally, |
|  |  | such that the information within a received request-target or Host |
|  |  | header field differs from the host or port upon which the connection |
|  |  | has been made. If the connection is from a trusted gateway, that |
|  |  | inconsistency might be expected; otherwise, it might indicate an |
|  |  | attempt to bypass security filters, trick the server into delivering |
|  |  | non-public content, or poison a cache. See Section 9 for security |
|  |  | considerations regarding message routing. |
| 5.6. Associating a Response to a Request |  | 5.6. Associating a Response to a Request |
| HTTP does not include a request identifier for associating a given |  | HTTP does not include a request identifier for associating a given |
| request message with its corresponding one or more response messages. |  | request message with its corresponding one or more response messages. |
| Hence, it relies on the order of response arrival to correspond |  | Hence, it relies on the order of response arrival to correspond |
| exactly to the order in which requests are made on the same |  | exactly to the order in which requests are made on the same |
| connection. More than one response message per request only occurs |  | connection. More than one response message per request only occurs |
| when one or more informational responses (1xx, see Section 6.2 of |  | when one or more informational responses (1xx, see Section 6.2 of |
| [Part2]) precede a final response to the same request. |  | [Part2]) precede a final response to the same request. |
| skipping to change at page 47, line 33 |  | skipping to change at page 47, line 43 |
| For each intermediary, the received-protocol indicates the protocol |  | For each intermediary, the received-protocol indicates the protocol |
| and protocol version used by the upstream sender of the message. |  | and protocol version used by the upstream sender of the message. |
| Hence, the Via field value records the advertised protocol |  | Hence, the Via field value records the advertised protocol |
| 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 portion of the field value is normally the host and |
| of a recipient server or client that subsequently forwarded the |  | optional port number of a recipient server or client that |
| message. However, if the real host is considered to be sensitive |  | subsequently forwarded the message. However, if the real host is |
| information, a sender MAY replace it with a pseudonym. If a port is |  | considered to be sensitive information, a sender MAY replace it with |
| not provided, a recipient MAY interpret that as meaning it was |  | a pseudonym. If a port is not provided, a recipient MAY interpret |
| received on the default TCP port, if any, for the received-protocol. |  | that as meaning it was received on the default TCP port, if any, for |
|  |  | the received-protocol. |
| A sender MAY generate comments in the Via header field to identify |  | A sender MAY generate comments in the Via header field to identify |
| the software of each recipient, analogous to the User-Agent and |  | the software of each recipient, analogous to the User-Agent and |
| Server header fields. However, all comments in the Via field are |  | Server header fields. However, all comments in the Via field are |
| optional and a recipient MAY remove them prior to forwarding the |  | optional and a recipient MAY remove them prior to forwarding the |
| message. |  | 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 |
| skipping to change at page 48, line 31 |  | skipping to change at page 48, line 41 |
| Via: 1.0 ricky, 1.1 mertz, 1.0 lucy |  | Via: 1.0 ricky, 1.1 mertz, 1.0 lucy |
| A sender SHOULD NOT combine multiple entries unless they are all |  | A sender SHOULD NOT combine multiple entries unless they are all |
| under the same organizational control and the hosts have already been |  | under the same organizational control and the hosts have already been |
| replaced by pseudonyms. A sender 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 proxy might, for example, convert between image |
| between image formats in order to save cache space or to reduce the |  | formats in order to save cache space or to reduce the amount of |
| amount of traffic on a slow link. However, operational problems |  | traffic on a slow link. However, operational problems might occur |
| might occur when these transformations are applied to payloads |  | when these transformations are applied to payloads intended for |
| intended for critical applications, such as medical imaging or |  | critical applications, such as medical imaging or scientific data |
| scientific data analysis, particularly when integrity checks or |  | analysis, particularly when integrity checks or digital signatures |
| digital signatures are used to ensure that the payload received is |  | are used to ensure that the payload received is identical to the |
| identical to the original. |  | original. |
|  |  | An HTTP-to-HTTP proxy is called a "transforming proxy" if it is |
|  |  | designed or configured to modify messages in a semantically |
|  |  | meaningful way (i.e., modifications, beyond those required by normal |
|  |  | HTTP processing, that change the message in a way that would be |
|  |  | significant to the original sender or potentially significant to |
|  |  | downstream recipients). For example, a transforming proxy might be |
|  |  | acting as a shared annotation server (modifying responses to include |
|  |  | references to a local annotation database), a malware filter, a |
|  |  | format transcoder, or a privacy filter. Such transformations are |
|  |  | presumed to be desired by whichever client (or client organization) |
|  |  | selected the proxy. |
| If a proxy receives a request-target with a host name that is not a |  | If a proxy receives a request-target with a host name that is not a |
| fully qualified domain name, it MAY add its own domain to the host |  | fully qualified domain name, it MAY add its own domain to the host |
| name it received when forwarding the request. A proxy MUST NOT |  | name it received when forwarding the request. A proxy MUST NOT |
| change the host name if it is a fully qualified domain name. |  | change the host name if the request-target contains a fully qualified |
|  |  | domain name. |
| A proxy MUST NOT modify the "absolute-path" and "query" parts of the |  | A proxy MUST NOT modify the "absolute-path" and "query" parts of the |
| received request-target when forwarding it to the next inbound |  | received request-target when forwarding it to the next inbound |
| server, except as noted above to replace an empty path with "/" or |  | server, except as noted above to replace an empty path with "/" or |
| "*". |  | "*". |
| A proxy MUST NOT modify header fields that provide information about |  | A proxy MAY modify the message body through application or removal of |
| the end points of the communication chain, the resource state, or the |  | a transfer coding (Section 4). |
| selected representation. A proxy MAY change the message body through |  |  |
| application or removal of a transfer coding (Section 4). |  |  |
| A non-transforming proxy MUST NOT modify the message payload (Section |  | A proxy MUST NOT transform the payload (Section 3.3 of [Part2]) of a |
| 3.3 of [Part2]). A transforming proxy MUST NOT modify the payload of |  | message that contains a no-transform cache-control directive (Section |
| a message that contains the no-transform cache-control directive. |  | 5.2 of [Part6]). |
| A transforming proxy MAY transform the payload of a message that does |  | A proxy MAY transform the payload of a message that does not contain |
| not contain the no-transform cache-control directive; if the payload |  | a no-transform cache-control directive. A proxy that transforms a |
| is transformed, the transforming proxy MUST add a Warning header |  | payload MUST add a Warning header field with the warn-code of 214 |
| field with the warn-code of 214 ("Transformation Applied") if one |  | ("Transformation Applied") if one is not already in the message (see |
| does not already appear in the message (see Section 5.5 of [Part6]). |  | Section 5.5 of [Part6]). A proxy that transforms the payload of a |
| If the payload of a 200 (OK) response is transformed, the |  | 200 (OK) response can further 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]). |
|  |  | A proxy SHOULD NOT modify header fields that provide information |
|  |  | about the end points of the communication chain, the resource state, |
|  |  | or the selected representation (other than the payload) unless the |
|  |  | field's definition specifically allows such modification or the |
|  |  | modification is deemed necessary for privacy or security. |
| 6. Connection Management |  | 6. Connection Management |
| HTTP messaging is independent of the underlying transport or session- |  | HTTP messaging is independent of the underlying transport or session- |
| layer connection protocol(s). HTTP only presumes a reliable |  | layer connection protocol(s). HTTP only presumes a reliable |
| transport with in-order delivery of requests and the corresponding |  | transport with in-order delivery of requests and the corresponding |
| in-order delivery of responses. The mapping of HTTP request and |  | in-order delivery of responses. The mapping of HTTP request and |
| response structures onto the data units of an underlying transport |  | response structures onto the data units of an underlying transport |
| protocol is outside the scope of this specification. |  | protocol is outside the scope of this specification. |
| As described in Section 5.2, the specific connection protocols to be |  | As described in Section 5.2, the specific connection protocols to be |
| skipping to change at page 52, line 5 |  | skipping to change at page 52, line 30 |
| o If the received protocol is HTTP/1.1 (or later), the connection |  | o If the received protocol is HTTP/1.1 (or later), the connection |
| will persist after the current response; else, |  | will persist after the current response; else, |
| o If the received protocol is HTTP/1.0, the "keep-alive" connection |  | o If the received protocol is HTTP/1.0, the "keep-alive" connection |
| option is present, the recipient is not a proxy, and the recipient |  | option is present, the recipient is not a proxy, and the recipient |
| wishes to honor the HTTP/1.0 "keep-alive" mechanism, the |  | wishes to honor the HTTP/1.0 "keep-alive" mechanism, the |
| connection will persist after the current response; otherwise, |  | connection will persist after the current response; otherwise, |
| o The connection will close after the current response. |  | o The connection will close after the current response. |
| A server MAY assume that an HTTP/1.1 client intends to maintain a |  | A client MAY send additional requests on a persistent connection |
| persistent connection until a close connection option is received in |  | until it sends or receives a close connection option or receives an |
| a request. |  | HTTP/1.0 response without a "keep-alive" connection option. |
| 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 |  |  |
| "keep-alive" connection option. |  |  |
| In order to remain persistent, all messages on a connection need to |  | In order to remain persistent, all messages on a connection need to |
| have a self-defined message length (i.e., one not defined by closure |  | have a self-defined message length (i.e., one not defined by closure |
| of the connection), as described in Section 3.3. A server MUST read |  | of the connection), as described in Section 3.3. A server MUST read |
| the entire request message body or close the connection after sending |  | the entire request message body or close the connection after sending |
| its 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 |  | See Appendix A.1.2 for more information on backward compatibility |
| maintained for HTTP versions less than 1.1 unless it is explicitly |  | with HTTP/1.0 clients. |
| signaled. See Appendix A.1.2 for more information on backward |  |  |
| compatibility with HTTP/1.0 clients. |  |  |
| 6.3.1. Retrying Requests |  | 6.3.1. Retrying Requests |
| Connections can be closed at any time, with or without intention. |  | Connections can be closed at any time, with or without intention. |
| Implementations ought to anticipate the need to recover from |  | Implementations ought to anticipate the need to recover from |
| asynchronous close events. |  | asynchronous close events. |
| When an inbound connection is closed prematurely, a client MAY open a |  | When an inbound connection is closed prematurely, a client MAY open a |
| new connection and automatically retransmit an aborted sequence of |  | new connection and automatically retransmit an aborted sequence of |
| requests if all of those requests have idempotent methods (Section |  | requests if all of those requests have idempotent methods (Section |
| skipping to change at page 53, line 50 |  | skipping to change at page 54, line 23 |
| 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 |
| A client SHOULD limit the number of simultaneous open connections |  | A client ought to limit the number of simultaneous open connections |
| that it maintains 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 |
| on the same connection. However, each connection consumes server |  | on the same connection. However, each connection consumes server |
| resources. Furthermore, using multiple connections can cause |  | resources. Furthermore, using multiple connections can cause |
| undesirable side effects in congested networks. |  | undesirable side effects in congested networks. |
| Note that servers might reject traffic that they deem abusive, |  | Note that a server might reject traffic that it deems abusive or |
| including an excessive number of connections from a client. |  | characteristic of a denial of service attack, such as an excessive |
|  |  | number of open connections from a single client. |
| 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 proxy server. The use of |
| connections places no requirements on the length (or existence) of |  | persistent connections places no requirements on the length (or |
| this time-out for either the client or the server. |  | existence) of this time-out for either the client or the server. |
| A client or server that wishes to time-out SHOULD issue a graceful |  | A client or server that wishes to time-out SHOULD issue a graceful |
| close on the connection. Implementations SHOULD constantly monitor |  | close on the connection. Implementations SHOULD constantly monitor |
| open connections for a received closure signal and respond to it as |  | open connections for a received closure signal and respond to it as |
| appropriate, since prompt closure of both sides of a connection |  | appropriate, since prompt closure of both sides of a connection |
| enables allocated system resources to be reclaimed. |  | enables allocated system resources to be reclaimed. |
| 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" |
| skipping to change at page 56, line 19 |  | skipping to change at page 56, line 42 |
| 6.7. Upgrade |  | 6.7. Upgrade |
| The "Upgrade" header field is intended to provide a simple mechanism |  | The "Upgrade" header field is intended to provide a simple mechanism |
| for transitioning from HTTP/1.1 to some other protocol on the same |  | for transitioning from HTTP/1.1 to some other protocol on the same |
| connection. A client MAY send a list of protocols in the Upgrade |  | connection. A client MAY send a list of protocols in the Upgrade |
| header field of a request to invite the server to switch to one or |  | header field of a request to invite the server to switch to one or |
| more of those protocols, in order of descending preference, before |  | more of those protocols, in order of descending preference, before |
| sending the final response. A server MAY ignore a received Upgrade |  | sending the final response. A server MAY ignore a received Upgrade |
| header field if it wishes to continue using the current protocol on |  | header field if it wishes to continue using the current protocol on |
| that connection. |  | that connection. Upgrade cannot be used to insist on a protocol |
|  |  | change. |
| 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 |
| skipping to change at page 57, line 5 |  | skipping to change at page 57, line 28 |
| 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 |  | The capabilities and nature of the application-level communication |
| and use by the server is optional. The capabilities and nature of |  | after the protocol change is entirely dependent upon the new |
| the application-level communication after the protocol change is |  | protocol(s) chosen. However, immediately after sending the 101 |
| entirely dependent upon the new protocol(s) chosen. However, |  | response, the server is expected to continue responding to the |
| immediately after sending the 101 response, the server is expected to |  | original request as if it had received its equivalent within the new |
| continue responding to the original request as if it had received its |  | protocol (i.e., the server still has an outstanding request to |
| equivalent within the new protocol (i.e., the server still has an |  | satisfy after the protocol has been changed, and is expected to do so |
| outstanding request to satisfy after the protocol has been changed, |  | without requiring the request to be repeated). |
| 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 58, line 25 |  | skipping to change at page 59, line 5 |
| 7. ABNF list extension: #rule |  | 7. ABNF list extension: #rule |
| A #rule extension to the ABNF rules of [RFC5234] is used to improve |  | A #rule extension to the ABNF rules of [RFC5234] is used to improve |
| readability in the definitions of some header field values. |  | readability in the definitions of some header field values. |
| A construct "#" is defined, similar to "*", for defining comma- |  | A construct "#" is defined, similar to "*", for defining comma- |
| delimited lists of elements. The full form is "<n>#<m>element" |  | delimited lists of elements. The full form is "<n>#<m>element" |
| indicating at least <n> and at most <m> elements, each separated by a |  | indicating at least <n> and at most <m> elements, each separated by a |
| single comma (",") and optional whitespace (OWS). |  | single comma (",") and optional whitespace (OWS). |
| Thus, a sender MUST expand the list construct as follows: |  | In any production that uses the list construct, a sender MUST NOT |
|  |  | generate empty list elements. In other words, a sender MUST generate |
|  |  | lists that satisfy the following syntax: |
| 1#element => element *( OWS "," OWS element ) |  | 1#element => element *( OWS "," OWS element ) |
| and: |  | and: |
| #element => [ 1#element ] |  | #element => [ 1#element ] |
| and for n >= 1 and m > 1: |  | and for n >= 1 and m > 1: |
| <n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element ) |  | <n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element ) |
| For compatibility with legacy list rules, a recipient MUST parse and |  | For compatibility with legacy list rules, a recipient MUST parse and |
| ignore a reasonable number of empty list elements: enough to handle |  | ignore a reasonable number of empty list elements: enough to handle |
| common mistakes by senders that merge values, but not so much that |  | 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, |  | they could be used as a denial of service mechanism. In other words, |
| a recipient MUST expand the list construct as follows: |  | a recipient MUST accept lists that satisfy the following syntax: |
| #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ] |  | #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ] |
| 1#element => *( "," OWS ) element *( OWS "," [ OWS element ] ) |  | 1#element => *( "," OWS ) element *( OWS "," [ OWS element ] ) |
| Empty elements do not contribute to the count of elements present. |  | Empty elements do not contribute to the count of elements present. |
| For example, given these ABNF productions: |  | For example, given these ABNF productions: |
| example-list = 1#example-list-elmt |  | example-list = 1#example-list-elmt |
| example-list-elmt = token ; see Section 3.2.6 |  | example-list-elmt = token ; see Section 3.2.6 |
| skipping to change at page 59, line 19 |  | skipping to change at page 59, line 49 |
| "foo ,bar," |  | "foo ,bar," |
| "foo , ,bar,charlie " |  | "foo , ,bar,charlie " |
| In contrast, the following values would be invalid, since at least |  | In contrast, the following values would be invalid, since at least |
| one non-empty element is required by the example-list production: |  | one non-empty element is required by the example-list production: |
| "" |  | "" |
| "," |  | "," |
| ", ," |  | ", ," |
| Appendix B shows the collected ABNF after the list constructs have |  | Appendix B shows the collected ABNF for recipients after the list |
| been expanded, as described above, for recipients. |  | constructs have been expanded. |
| 8. IANA Considerations |  | 8. IANA Considerations |
| 8.1. Header Field Registration |  | 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 |  | Registry maintained at |
| <http://www.iana.org/assignments/message-headers/>. |  | <http://www.iana.org/assignments/message-headers/>. |
| This document defines the following HTTP header fields, so their |  | This document defines the following HTTP header fields, so their |
| skipping to change at page 60, line 49 |  | skipping to change at page 61, line 31 |
| 8.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: N/A |
| Optional parameters: version, msgtype |  | Optional parameters: version, msgtype |
| version: The HTTP-version number of the enclosed message (e.g., |  | version: The HTTP-version number of the enclosed message (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. |
| msgtype: The message type -- "request" or "response". If not |  | msgtype: The message type -- "request" or "response". If not |
| 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: see Section 9 |
| Interoperability considerations: none |  |  |
|  |  | Interoperability considerations: N/A |
| Published specification: This specification (see Section 8.3.1). |  | Published specification: This specification (see Section 8.3.1). |
| Applications that use this media type: |  | Applications that use this media type: N/A |
|  |  | Fragment identifier considerations: N/A |
| Additional information: |  | Additional information: |
| Magic number(s): none |  | Magic number(s): N/A |
| File extension(s): none |  | Deprecated alias names for this type: N/A |
| Macintosh file type code(s): none |  | File extension(s): N/A |
|  |  | Macintosh file type code(s): N/A |
| 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: N/A |
| Author: See Authors Section. |  | Author: See Authors Section. |
| Change controller: IESG |  | Change controller: IESG |
| 8.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: N/A |
| 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. |
| msgtype: The message type -- "request" or "response". If not |  | msgtype: The message type -- "request" or "response". If not |
| 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: 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: see Section 9 |
| Interoperability considerations: none |  | Interoperability considerations: N/A |
| Published specification: This specification (see Section 8.3.2). |  | Published specification: This specification (see Section 8.3.2). |
| Applications that use this media type: |  | Applications that use this media type: N/A |
|  |  | Fragment identifier considerations: N/A |
| Additional information: |  | Additional information: |
| Magic number(s): none |  | Deprecated alias names for this type: N/A |
| File extension(s): none |  | Magic number(s): N/A |
| Macintosh file type code(s): none |  | File extension(s): N/A |
|  |  | Macintosh file type code(s): N/A |
| 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: N/A |
| Author: See Authors Section. |  | Author: See Authors Section. |
| Change controller: IESG |  | Change controller: IESG |
| 8.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>. |
| skipping to change at page 65, line 35 |  | skipping to change at page 66, line 27 |
| | 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". |
| 9. 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 considerations relevant to HTTP message |
| syntax, parsing, and routing. |  | syntax, parsing, and routing. Security considerations about HTTP |
|  |  | semantics and payloads are addressed in [Part2]. |
| 9.1. DNS-related Attacks |  | 9.1. Establishing Authority |
| HTTP clients rely heavily on the Domain Name Service (DNS), and are |  | HTTP relies on the notion of an authoritative response: a response |
| thus generally prone to security attacks based on the deliberate |  | that has been determined by (or at the direction of) the authority |
| misassociation of IP addresses and DNS names not protected by DNSSEC. |  | identified within the target URI to be the most appropriate response |
| Clients need to be cautious in assuming the validity of an IP number/ |  | for that request given the state of the target resource at the time |
| DNS name association unless the response is protected by DNSSEC |  | of response message origination. Providing a response from a non- |
| ([RFC4033]). |  | authoritative source, such as a shared cache, is often useful to |
|  |  | improve performance and availability, but only to the extent that the |
|  |  | source can be trusted or the distrusted response can be safely used. |
| 9.2. Intermediaries and Caching |  | Unfortunately, establishing authority can be difficult. For example, |
|  |  | phishing is an attack on the user's perception of authority, where |
|  |  | that perception can be misled by presenting similar branding in |
|  |  | hypertext, possibly aided by userinfo obfuscating the authority |
|  |  | component (see Section 2.7.1). User agents can reduce the impact of |
|  |  | phishing attacks by enabling users to easily inspect a target URI |
|  |  | prior to making an action, by prominently distinguishing (or |
|  |  | rejecting) userinfo when present, and by not sending stored |
|  |  | credentials and cookies when the referring document is from an |
|  |  | unknown or untrusted source. |
|  |  | When a registered name is used in the authority component, the "http" |
|  |  | URI scheme (Section 2.7.1) relies on the user's local name resolution |
|  |  | service to determine where it can find authoritative responses. This |
|  |  | means that any attack on a user's network host table, cached names, |
|  |  | or name resolution libraries becomes an avenue for attack on |
|  |  | establishing authority. Likewise, the user's choice of server for |
|  |  | Domain Name Service (DNS), and the hierarchy of servers from which it |
|  |  | obtains resolution results, could impact the authenticity of address |
|  |  | mappings; DNSSEC ([RFC4033]) is one way to improve authenticity. |
|  |  | Furthermore, after an IP address is obtained, establishing authority |
|  |  | for an "http" URI is vulnerable to attacks on Internet Protocol |
|  |  | routing. |
|  |  | The "https" scheme (Section 2.7.2) is intended to prevent (or at |
|  |  | least reveal) many of these potential attacks on establishing |
|  |  | authority, provided that the negotiated TLS connection is secured and |
|  |  | the client properly verifies that the communicating server's identity |
|  |  | matches the target URI's authority component (see [RFC2818]). |
|  |  | Correctly implementing such verification can be difficult (see |
|  |  | [Georgiev]). |
|  |  | 9.2. Risks of Intermediaries |
| 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 |  | thus represent an opportunity for man-in-the-middle attacks. |
| of the systems on which the intermediaries run can result in serious |  | Compromise of the systems on which the intermediaries run can result |
| security and privacy problems. Intermediaries have access to |  | in serious security and privacy problems. Intermediaries might have |
| security-related information, personal information about individual |  | access to security-related information, personal information about |
| users and organizations, and proprietary information belonging to |  | individual users and organizations, and proprietary information |
| users and content providers. A compromised intermediary, or an |  | belonging to users and content providers. A compromised |
| intermediary implemented or configured without regard to security and |  | intermediary, or an intermediary implemented or configured without |
| privacy considerations, might be used in the commission of a wide |  | regard to security and privacy considerations, might be used in the |
| range of potential attacks. |  | commission of a wide range of potential attacks. |
| Intermediaries that contain a shared cache are especially vulnerable |  | Intermediaries that contain a shared cache are especially vulnerable |
| to cache poisoning attacks. |  | to cache poisoning attacks, as described in Section 8 of [Part6]. |
| 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. |
| 9.3. Buffer Overflows |  | 9.3. Attacks via Protocol Element Length |
| Because HTTP uses mostly textual, character-delimited fields, |  | Because HTTP uses mostly textual, character-delimited fields, parsers |
| attackers can overflow buffers in implementations, and/or perform a |  | are often vulnerable to attacks based on sending very long (or very |
| Denial of Service against implementations that accept fields with |  | slow) streams of data, particularly where an implementation is |
| unlimited lengths. |  | expecting a protocol element with no predefined length. |
| To promote interoperability, this specification makes specific |  | To promote interoperability, specific recommendations are made for |
| recommendations for minimum size limits on request-line |  | minimum size limits on request-line (Section 3.1.1) and header fields |
| (Section 3.1.1) and header fields (Section 3.2). These are minimum |  | (Section 3.2). These are minimum recommendations, chosen to be |
| recommendations, chosen to be supportable even by implementations |  | supportable even by implementations with limited resources; it is |
| with limited resources; it is expected that most implementations will |  | expected that most implementations will choose substantially higher |
| choose substantially higher limits. |  | limits. |
| This specification also provides a way for servers to reject messages |  | A server can reject a message that has a request-target that is too |
| that have request-targets that are too long (Section 6.5.12 of |  | long (Section 6.5.12 of [Part2]) or a request payload that is too |
| [Part2]) or request entities that are too large (Section 6.5 of |  | large (Section 6.5.11 of [Part2]). Additional status codes related |
| [Part2]). Additional status codes related to capacity limits have |  | to capacity limits have been defined by extensions to HTTP [RFC6585]. |
| been defined by extensions to HTTP [RFC6585]. |  |  |
| Recipients ought to carefully limit the extent to which they read |  | Recipients ought to carefully limit the extent to which they process |
| other fields, including (but not limited to) request methods, |  | other protocol elements, including (but not limited to) request |
| response status phrases, header field-names, and body chunks, so as |  | methods, response status phrases, header field-names, numeric values, |
| to avoid denial of service attacks without impeding interoperability. |  | and body chunks. Failure to limit such processing can result in |
|  |  | buffer overflows, arithmetic overflows, or increased vulnerability to |
|  |  | denial of service attacks. |
| 9.4. Message Integrity |  | 9.4. Response Splitting |
|  |  | Response splitting (a.k.a, CRLF injection) is a common technique, |
|  |  | used in various attacks on Web usage, that exploits the line-based |
|  |  | nature of HTTP message framing and the ordered association of |
|  |  | requests to responses on persistent connections [Klein]. This |
|  |  | technique can be particularly damaging when the requests pass through |
|  |  | a shared cache. |
|  |  | Response splitting exploits a vulnerability in servers (usually |
|  |  | within an application server) where an attacker can send encoded data |
|  |  | within some parameter of the request that is later decoded and echoed |
|  |  | within any of the response header fields of the response. If the |
|  |  | decoded data is crafted to look like the response has ended and a |
|  |  | subsequent response has begun, the response has been split and the |
|  |  | content within the apparent second response is controlled by the |
|  |  | attacker. The attacker can then make any other request on the same |
|  |  | persistent connection and trick the recipients (including |
|  |  | intermediaries) into believing that the second half of the split is |
|  |  | an authoritative answer to the second request. |
|  |  | For example, a parameter within the request-target might be read by |
|  |  | an application server and reused within a redirect, resulting in the |
|  |  | same parameter being echoed in the Location header field of the |
|  |  | response. If the parameter is decoded by the application and not |
|  |  | properly encoded when placed in the response field, the attacker can |
|  |  | send encoded CRLF octets and other content that will make the |
|  |  | application's single response look like two or more responses. |
|  |  | A common defense against response splitting is to filter requests for |
|  |  | data that looks like encoded CR and LF (e.g., "%0D" and "%0A"). |
|  |  | However, that assumes the application server is only performing URI |
|  |  | decoding, rather than more obscure data transformations like charset |
|  |  | transcoding, XML entity translation, base64 decoding, sprintf |
|  |  | reformatting, etc. A more effective mitigation is to prevent |
|  |  | anything other than the server's core protocol libraries from sending |
|  |  | a CR or LF within the header section, which means restricting the |
|  |  | output of header fields to APIs that filter for bad octets and not |
|  |  | allowing application servers to write directly to the protocol |
|  |  | stream. |
|  |  | 9.5. Request Smuggling |
|  |  | Request smuggling ([Linhart]) is a technique that exploits |
|  |  | differences in protocol parsing among various recipients to hide |
|  |  | additional requests (which might otherwise be blocked or disabled by |
|  |  | policy) within an apparently harmless request. Like response |
|  |  | splitting, request smuggling can lead to a variety of attacks on HTTP |
|  |  | usage. |
|  |  | This specification has introduced new requirements on request |
|  |  | parsing, particularly with regard to message framing in |
|  |  | Section 3.3.3, to reduce the effectiveness of request smuggling. |
|  |  | 9.6. 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 67, line 26 |  | skipping to change at page 70, line 15 |
| 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. |
| 9.5. Server Log Information |  | 9.7. Message Confidentiality |
|  |  | HTTP relies on underlying transport protocols to provide message |
|  |  | confidentiality when that is desired. HTTP has been specifically |
|  |  | designed to be independent of the transport protocol, such that it |
|  |  | can be used over many different forms of encrypted connection, with |
|  |  | the selection of such transports being identified by the choice of |
|  |  | URI scheme or within user agent configuration. |
|  |  | The "https" scheme can be used to identify resources that require a |
|  |  | confidential connection, as described in Section 2.7.2. |
|  |  | 9.8. Privacy of Server Log Information |
| A server is in the position to save personal data about a user's |  | A server is in the position to save personal data about a user's |
| requests 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. |
| skipping to change at page 68, line 19 |  | skipping to change at page 71, line 19 |
| 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 |
| specification by reporting bugs, asking smart questions, drafting or |  | specification by reporting bugs, asking smart questions, drafting or |
| reviewing text, and evaluating open issues: |  | reviewing text, and evaluating open issues: |
| Adam Barth, Adam Roach, Addison Phillips, Adrian Chadd, Adrien W. de |  | Adam Barth, Adam Roach, Addison Phillips, Adrian Chadd, Adrian Cole, |
| Croy, Alan Ford, Alan Ruttenberg, Albert Lunde, Alek Storm, Alex |  | Adrien W. de Croy, Alan Ford, Alan Ruttenberg, Albert Lunde, Alek |
| Rousskov, Alexandre Morgaut, Alexey Melnikov, Alisha Smith, Amichai |  | Storm, Alex Rousskov, Alexandre Morgaut, Alexey Melnikov, Alisha |
| Rothman, Amit Klein, Amos Jeffries, Andreas Maier, Andreas Petersson, |  | Smith, Amichai Rothman, Amit Klein, Amos Jeffries, Andreas Maier, |
| Andrei Popov, Anil Sharma, Anne van Kesteren, Anthony Bryan, Asbjorn |  | Andreas Petersson, Andrei Popov, Anil Sharma, Anne van Kesteren, |
| Ulsberg, Ashok Kumar, Balachander Krishnamurthy, Barry Leiba, Ben |  | Anthony Bryan, Asbjorn Ulsberg, Ashok Kumar, Balachander |
| Laurie, Benjamin Carlyle, Benjamin Niven-Jenkins, Bil Corry, Bill |  | Krishnamurthy, Barry Leiba, Ben Laurie, Benjamin Carlyle, Benjamin |
| Burke, Bjoern Hoehrmann, Bob Scheifler, Boris Zbarsky, Brett Slatkin, |  | Niven-Jenkins, Benoit Claise, Bil Corry, Bill Burke, Bjoern |
| Brian Kell, Brian McBarron, Brian Pane, Brian Raymor, Brian Smith, |  | Hoehrmann, Bob Scheifler, Boris Zbarsky, Brett Slatkin, Brian Kell, |
|  |  | Brian McBarron, Brian Pane, Brian Raymor, Brian Smith, Bruce Perens, |
| Bryce Nesbitt, Cameron Heavon-Jones, Carl Kugler, Carsten Bormann, |  | Bryce Nesbitt, Cameron Heavon-Jones, Carl Kugler, Carsten Bormann, |
| Charles Fry, Chris Newman, Cyrus Daboo, Dale Robert Anderson, Dan |  | Charles Fry, Chris Burdess, Chris Newman, Christian Huitema, Cyrus |
| Wing, Dan Winship, Daniel Stenberg, Darrel Miller, Dave Cridland, |  | Daboo, Dale Robert Anderson, Dan Wing, Dan Winship, Daniel Stenberg, |
| Dave Crocker, Dave Kristol, Dave Thaler, David Booth, David Singer, |  | Darrel Miller, Dave Cridland, Dave Crocker, Dave Kristol, Dave |
| David W. Morris, Diwakar Shetty, Dmitry Kurochkin, Drummond Reed, |  | Thaler, David Booth, David Singer, David W. Morris, Diwakar Shetty, |
| Duane Wessels, Edward Lee, Eitan Adler, Eliot Lear, Emile Stephan, |  | Dmitry Kurochkin, Drummond Reed, Duane Wessels, Edward Lee, Eitan |
| Eran Hammer-Lahav, Eric D. Williams, Eric J. Bowman, Eric Lawrence, |  | Adler, Eliot Lear, Emile Stephan, Eran Hammer-Lahav, Eric D. |
| Eric Rescorla, Erik Aronesty, EungJun Yi, Evan Prodromou, Felix |  | Williams, Eric J. Bowman, Eric Lawrence, Eric Rescorla, Erik |
| Geisendoerfer, Florian Weimer, Frank Ellermann, Fred Akalin, Fred |  | Aronesty, EungJun Yi, Evan Prodromou, Felix Geisendoerfer, Florian |
| Bohle, Frederic Kayser, Gabor Molnar, Gabriel Montenegro, Geoffrey |  | Weimer, Frank Ellermann, Fred Akalin, Fred Bohle, Frederic Kayser, |
| Sneddon, Gervase Markham, Gili Tzabari, Grahame Grieve, Greg Wilkins, |  | Gabor Molnar, Gabriel Montenegro, Geoffrey Sneddon, Gervase Markham, |
| Grzegorz Calkowski, Harald Tveit Alvestrand, Harry Halpin, Helge |  | Gili Tzabari, Grahame Grieve, Greg Slepak, Greg Wilkins, Grzegorz |
| Hess, Henrik Nordstrom, Henry S. Thompson, Henry Story, Herbert van |  | Calkowski, Harald Tveit Alvestrand, Harry Halpin, Helge Hess, Henrik |
| de Sompel, Herve Ruellan, Howard Melman, Hugo Haas, Ian Fette, Ian |  | Nordstrom, Henry S. Thompson, Henry Story, Herbert van de Sompel, |
| Hickson, Ido Safruti, Ilari Liusvaara, Ilya Grigorik, Ingo Struck, J. |  | Herve Ruellan, Howard Melman, Hugo Haas, Ian Fette, Ian Hickson, Ido |
| Ross Nicoll, James Cloos, James H. Manger, James Lacey, James M. |  | Safruti, Ilari Liusvaara, Ilya Grigorik, Ingo Struck, J. Ross Nicoll, |
| Snell, Jamie Lokier, Jan Algermissen, Jeff Hodges (who came up with |  | James Cloos, James H. Manger, James Lacey, James M. Snell, Jamie |
|  |  | Lokier, Jan Algermissen, Jari Arkko, Jeff Hodges (who came up with |
| the term 'effective Request-URI'), Jeff Pinner, Jeff Walden, Jim |  | the term 'effective Request-URI'), Jeff Pinner, Jeff Walden, Jim |
| Luther, Jitu Padhye, Joe D. Williams, Joe Gregorio, Joe Orton, John |  | Luther, Jitu Padhye, Joe D. Williams, Joe Gregorio, Joe Orton, Joel |
| C. Klensin, John C. Mallery, John Cowan, John Kemp, John Panzer, John |  | Jaeggli, John C. Klensin, John C. Mallery, John Cowan, John Kemp, |
| Schneider, John Stracke, John Sullivan, Jonas Sicking, Jonathan A. |  | John Panzer, John Schneider, John Stracke, John Sullivan, Jonas |
| Rees, Jonathan Billington, Jonathan Moore, Jonathan Silvera, Jordi |  | Sicking, Jonathan A. Rees, Jonathan Billington, Jonathan Moore, |
| Ros, Joris Dobbelsteen, Josh Cohen, Julien Pierre, Jungshik Shin, |  | Jonathan Silvera, Jordi Ros, Joris Dobbelsteen, Josh Cohen, Julien |
| Justin Chapweske, Justin Erenkrantz, Justin James, Kalvinder Singh, |  | Pierre, Jungshik Shin, Justin Chapweske, Justin Erenkrantz, Justin |
| Karl Dubost, Keith Hoffman, Keith Moore, Ken Murchison, Koen Holtman, |  | James, Kalvinder Singh, Karl Dubost, Kathleen Moriarty, Keith |
| Konstantin Voronkov, Kris Zyp, Leif Hedstrom, Lisa Dusseault, Maciej |  | Hoffman, Keith Moore, Ken Murchison, Koen Holtman, Konstantin |
| Stachowiak, Manu Sporny, Marc Schneider, Marc Slemko, Mark Baker, |  | Voronkov, Kris Zyp, Leif Hedstrom, Lionel Morand, Lisa Dusseault, |
| Mark Pauley, Mark Watson, Markus Isomaki, Markus Lanthaler, Martin J. |  | Maciej Stachowiak, Manu Sporny, Marc Schneider, Marc Slemko, Mark |
| Duerst, Martin Musatov, Martin Nilsson, Martin Thomson, Matt Lynch, |  | Baker, Mark Pauley, Mark Watson, Markus Isomaki, Markus Lanthaler, |
| Matthew Cox, Max Clark, Michael Burrows, Michael Hausenblas, Michael |  | Martin J. Duerst, Martin Musatov, Martin Nilsson, Martin Thomson, |
|  |  | Matt Lynch, Matthew Cox, Matthew Kerwin, Max Clark, Menachem Dodge, |
|  |  | Meral Shirazipour, Michael Burrows, Michael Hausenblas, Michael |
| Scharf, Michael Sweet, Michael Tuexen, Michael Welzl, Mike Amundsen, |  | Scharf, Michael Sweet, Michael Tuexen, Michael Welzl, Mike Amundsen, |
| Mike Belshe, Mike Bishop, Mike Kelly, Mike Schinkel, Miles Sabin, |  | Mike Belshe, Mike Bishop, Mike Kelly, Mike Schinkel, Miles Sabin, |
| Murray S. Kucherawy, Mykyta Yevstifeyev, Nathan Rixham, Nicholas |  | Murray S. Kucherawy, Mykyta Yevstifeyev, Nathan Rixham, Nicholas |
| Shanks, Nico Williams, Nicolas Alvarez, Nicolas Mailhot, Noah Slater, |  | Shanks, Nico Williams, Nicolas Alvarez, Nicolas Mailhot, Noah Slater, |
| Osama Mazahir, Pablo Castro, Pat Hayes, Patrick R. McManus, Paul E. |  | Osama Mazahir, Pablo Castro, Pat Hayes, Patrick R. McManus, Paul E. |
| Jones, Paul Hoffman, Paul Marquess, Peter Lepeska, Peter Occil, Peter |  | Jones, Paul Hoffman, Paul Marquess, Pete Resnick, Peter Lepeska, |
| Saint-Andre, Peter Watkins, Phil Archer, Philippe Mougin, Phillip |  | Peter Occil, Peter Saint-Andre, Peter Watkins, Phil Archer, Phil |
| Hallam-Baker, Piotr Dobrogost, Poul-Henning Kamp, Preethi Natarajan, |  | Hunt, Philippe Mougin, Phillip Hallam-Baker, Piotr Dobrogost, Poul- |
| Rajeev Bector, Ray Polk, Reto Bachmann-Gmuer, Richard Cyganiak, Robby |  | Henning Kamp, Preethi Natarajan, Rajeev Bector, Ray Polk, Reto |
|  |  | Bachmann-Gmuer, Richard Barnes, Richard Cyganiak, Rob Trace, Robby |
| Simpson, Robert Brewer, Robert Collins, Robert Mattson, Robert |  | Simpson, Robert Brewer, Robert Collins, Robert Mattson, Robert |
| O'Callahan, Robert Olofsson, Robert Sayre, Robert Siemer, Robert de |  | O'Callahan, Robert Olofsson, Robert Sayre, Robert Siemer, Robert de |
| Wilde, Roberto Javier Godoy, Roberto Peon, Roland Zink, Ronny |  | Wilde, Roberto Javier Godoy, Roberto Peon, Roland Zink, Ronny |
| Widjaja, Ryan Hamilton, S. Mike Dierken, Salvatore Loreto, Sam |  | Widjaja, Ryan Hamilton, S. Mike Dierken, Salvatore Loreto, Sam |
| Johnston, Sam Pullara, Sam Ruby, Saurabh Kulkarni, Scott Lawrence |  | Johnston, Sam Pullara, Sam Ruby, Saurabh Kulkarni, Scott Lawrence |
| (who maintained the original issues list), Sean B. Palmer, Sebastien |  | (who maintained the original issues list), Sean B. Palmer, Sean |
| Barnoud, Shane McCarron, Shigeki Ohtsu, Stefan Eissing, Stefan |  | Turner, Sebastien Barnoud, Shane McCarron, Shigeki Ohtsu, Simon |
| Tilkov, Stefanos Harhalakis, Stephane Bortzmeyer, Stephen Farrell, |  | Yarde, Stefan Eissing, Stefan Tilkov, Stefanos Harhalakis, Stephane |
| Stephen Ludin, Stuart Williams, Subbu Allamaraju, Subramanian |  | Bortzmeyer, Stephen Farrell, Stephen Kent, Stephen Ludin, Stuart |
| Moonesamy, Sylvain Hellegouarch, Tapan Divekar, Tatsuhiro Tsujikawa, |  | Williams, Subbu Allamaraju, Subramanian Moonesamy, Susan Hares, |
| Tatsuya Hayashi, Ted Hardie, Thomas Broyer, Thomas Fossati, Thomas |  | Sylvain Hellegouarch, Tapan Divekar, Tatsuhiro Tsujikawa, Tatsuya |
| Maslen, Thomas Nordin, Thomas Roessler, Tim Bray, Tim Morgan, Tim |  | Hayashi, Ted Hardie, Ted Lemon, Thomas Broyer, Thomas Fossati, Thomas |
| Olsen, Tom Zhou, Travis Snoozy, Tyler Close, Vincent Murphy, Wenbo |  | Maslen, Thomas Nadeau, Thomas Nordin, Thomas Roessler, Tim Bray, Tim |
| Zhu, Werner Baumann, Wilbur Streett, Wilfredo Sanchez Vega, William |  | Morgan, Tim Olsen, Tom Zhou, Travis Snoozy, Tyler Close, Vincent |
| A. Rowe Jr., William Chan, Willy Tarreau, Xiaoshu Wang, Yaron Goland, |  | Murphy, Wenbo Zhu, Werner Baumann, Wilbur Streett, Wilfredo Sanchez |
| Yngve Nysaeter Pettersen, Yoav Nir, Yogesh Bang, Yuchung Cheng, |  | Vega, William A. Rowe Jr., William Chan, Willy Tarreau, Xiaoshu Wang, |
| Yutaka Oiwa, Yves Lafon (long-time member of the editor team), Zed A. |  | Yaron Goland, Yngve Nysaeter Pettersen, Yoav Nir, Yogesh Bang, |
| Shaw, and Zhong Yu. |  | Yuchung Cheng, 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. |
| 11. References |  | 11. References |
| 11.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-25 (work in progress), |  | draft-ietf-httpbis-p2-semantics-26 (work in progress), |
| November 2013. |  | February 2014. |
| [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-25 (work in |  | draft-ietf-httpbis-p4-conditional-26 (work in |
| progress), November 2013. |  | progress), February 2014. |
| [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-25 (work in |  | Requests", draft-ietf-httpbis-p5-range-26 (work in |
| progress), November 2013. |  | progress), February 2014. |
| [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-25 (work in progress), |  | draft-ietf-httpbis-p6-cache-26 (work in progress), |
| November 2013. |  | February 2014. |
| [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-25 (work in progress), |  | draft-ietf-httpbis-p7-auth-26 (work in progress), |
| November 2013. |  | February 2014. |
| [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 71, line 19 |  | skipping to change at page 74, line 24 |
| 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 |
| Procedures for Message Header Fields", BCP 90, |  | Procedures for Message Header Fields", BCP 90, |
| RFC 3864, September 2004. |  | RFC 3864, September 2004. |
|  |  | [Georgiev] Georgiev, M., Iyengar, S., Jana, S., Anubhai, R., |
|  |  | Boneh, D., and V. Shmatikov, "The Most Dangerous Code |
|  |  | in the World: Validating SSL Certificates in Non- |
|  |  | browser Software", In Proceedings of the 2012 ACM |
|  |  | Conference on Computer and Communications Security (CCS |
|  |  | '12), pp. 38-49, October 2012, |
|  |  | <http://doi.acm.org/10.1145/2382196.2382204>. |
| [ISO-8859-1] International Organization for Standardization, |  | [ISO-8859-1] International Organization for Standardization, |
| "Information technology -- 8-bit single-byte coded |  | "Information technology -- 8-bit single-byte coded |
| graphic character sets -- Part 1: Latin alphabet No. |  | graphic character sets -- Part 1: Latin alphabet No. |
| 1", ISO/IEC 8859-1:1998, 1998. |  | 1", ISO/IEC 8859-1:1998, 1998. |
|  |  | [Klein] Klein, A., "Divide and Conquer - HTTP Response |
|  |  | Splitting, Web Cache Poisoning Attacks, and Related |
|  |  | Topics", March 2004, <http://packetstormsecurity.com/ |
|  |  | papers/general/whitepaper_httpresponse.pdf>. |
| [Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and |  | [Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and |
| Politics", ACM Transactions on Internet |  | Politics", ACM Transactions on Internet |
| Technology 1(2), November 2001, |  | Technology 1(2), November 2001, |
| <http://arxiv.org/abs/cs.SE/0105018>. |  | <http://arxiv.org/abs/cs.SE/0105018>. |
|  |  | [Linhart] Linhart, C., Klein, A., Heled, R., and S. Orrin, "HTTP |
|  |  | Request Smuggling", June 2005, |
|  |  | <http://www.watchfire.com/news/whitepapers.aspx>. |
| [RFC1919] Chatel, M., "Classical versus Transparent IP Proxies", |  | [RFC1919] Chatel, M., "Classical versus Transparent IP Proxies", |
| RFC 1919, March 1996. |  | RFC 1919, March 1996. |
| [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, |  | [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, |
| "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, |  | "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, |
| May 1996. |  | May 1996. |
| [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet |  | [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet |
| Mail Extensions (MIME) Part One: Format of Internet |  | Mail Extensions (MIME) Part One: Format of Internet |
| Message Bodies", RFC 2045, November 1996. |  | Message Bodies", RFC 2045, November 1996. |
| skipping to change at page 72, line 43 |  | skipping to change at page 76, line 18 |
| October 2008. |  | October 2008. |
| [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, |  | [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, |
| April 2011. |  | April 2011. |
| [RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status |  | [RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status |
| Codes", RFC 6585, April 2012. |  | Codes", RFC 6585, April 2012. |
| Appendix A. HTTP Version History |  | Appendix A. HTTP Version History |
| HTTP has been in use by the World-Wide Web global information |  | HTTP has been in use since 1990. The first version, later referred |
| initiative since 1990. The first version of HTTP, later referred to |  | to as HTTP/0.9, was a simple protocol for hypertext data transfer |
| as HTTP/0.9, was a simple protocol for hypertext data transfer across |  | across the Internet, using only a single request method (GET) and no |
| the Internet with only a single request method (GET) and no metadata. |  | metadata. HTTP/1.0, as defined by [RFC1945], added a range of |
| HTTP/1.0, as defined by [RFC1945], added a range of request methods |  | request methods and MIME-like messaging, allowing for metadata to be |
| and MIME-like messaging that could include metadata about the data |  | transferred and modifiers placed on the request/response semantics. |
| transferred and modifiers on the request/response semantics. |  |  |
| However, HTTP/1.0 did not sufficiently take into consideration the |  | However, HTTP/1.0 did not sufficiently take into consideration the |
| effects of hierarchical proxies, caching, the need for persistent |  | effects of hierarchical proxies, caching, the need for persistent |
| connections, or name-based virtual hosts. The proliferation of |  | connections, or name-based virtual hosts. The proliferation of |
| incompletely-implemented applications calling themselves "HTTP/1.0" |  | incompletely-implemented applications calling themselves "HTTP/1.0" |
| further necessitated a protocol version change in order for two |  | further necessitated a protocol version change in order for two |
| communicating applications to determine each other's true |  | communicating applications to determine each other's true |
| capabilities. |  | capabilities. |
| HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent |  | HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent |
| requirements that enable reliable implementations, adding only those |  | requirements that enable reliable implementations, adding only those |
| new features that will either be safely ignored by an HTTP/1.0 |  | features that can either be safely ignored by an HTTP/1.0 recipient |
| recipient or only sent when communicating with a party advertising |  | or only sent when communicating with a party advertising conformance |
| conformance with HTTP/1.1. |  | with HTTP/1.1. |
| It is beyond the scope of a protocol specification to mandate |  | HTTP/1.1 has been designed to make supporting previous versions easy. |
| conformance with previous versions. HTTP/1.1 was deliberately |  | A general-purpose HTTP/1.1 server ought to be able to understand any |
| designed, however, to make supporting previous versions easy. We |  | valid request in the format of HTTP/1.0, responding appropriately |
| would expect a general-purpose HTTP/1.1 server to understand any |  |  |
| valid request in the format of HTTP/1.0 and respond appropriately |  |  |
| with an HTTP/1.1 message that only uses features understood (or |  | with an HTTP/1.1 message that only uses features understood (or |
| safely ignored) by HTTP/1.0 clients. Likewise, we would expect an |  | safely ignored) by HTTP/1.0 clients. Likewise, an HTTP/1.1 client |
| HTTP/1.1 client to understand any valid HTTP/1.0 response. |  | can be expected to understand any valid HTTP/1.0 response. |
| Since HTTP/0.9 did not support header fields in a request, there is |  | Since HTTP/0.9 did not support header fields in a request, there is |
| no mechanism for it to support name-based virtual hosts (selection of |  | no mechanism for it to support name-based virtual hosts (selection of |
| resource by inspection of the Host header field). Any server that |  | resource by inspection of the Host header field). Any server that |
| implements name-based virtual hosts ought to disable support for |  | implements name-based virtual hosts ought to disable support for |
| HTTP/0.9. Most requests that appear to be HTTP/0.9 are, in fact, |  | HTTP/0.9. Most requests that appear to be HTTP/0.9 are, in fact, |
| badly constructed HTTP/1.x requests wherein a buggy client failed to |  | badly constructed HTTP/1.x requests caused by a client failing to |
| properly encode linear whitespace found in a URI reference and placed |  | properly encode the request-target. |
| in the request-target. |  |  |
| A.1. Changes from HTTP/1.0 |  | A.1. Changes from HTTP/1.0 |
| This section summarizes major differences between versions HTTP/1.0 |  | This section summarizes major differences between versions HTTP/1.0 |
| and HTTP/1.1. |  | and HTTP/1.1. |
| A.1.1. Multi-homed Web Servers |  | A.1.1. Multi-homed Web Servers |
| The requirements that clients and servers support the Host header |  | The requirements that clients and servers support the Host header |
| field (Section 5.4), report an error if it is missing from an |  | field (Section 5.4), report an error if it is missing from an |
| skipping to change at page 77, line 33 |  | skipping to change at page 81, line 4 |
| RWS = 1*( SP / HTAB ) |  | RWS = 1*( SP / HTAB ) |
| TE = [ ( "," / t-codings ) *( OWS "," [ OWS t-codings ] ) ] |  | TE = [ ( "," / t-codings ) *( OWS "," [ OWS t-codings ] ) ] |
| Trailer = *( "," OWS ) field-name *( OWS "," [ OWS field-name ] ) |  | Trailer = *( "," OWS ) field-name *( OWS "," [ OWS field-name ] ) |
| Transfer-Encoding = *( "," OWS ) transfer-coding *( OWS "," [ OWS |  | Transfer-Encoding = *( "," OWS ) transfer-coding *( OWS "," [ OWS |
| transfer-coding ] ) |  | transfer-coding ] ) |
| URI-reference = <URI-reference, defined in [RFC3986], Section 4.1> |  | URI-reference = <URI-reference, defined in [RFC3986], Section 4.1> |
| Upgrade = *( "," OWS ) protocol *( OWS "," [ OWS protocol ] ) |  | Upgrade = *( "," OWS ) protocol *( OWS "," [ OWS protocol ] ) |
| Via = *( "," OWS ) ( received-protocol RWS received-by [ RWS comment |  | Via = *( "," OWS ) ( received-protocol RWS received-by [ RWS comment |
| ] ) *( OWS "," [ OWS ( received-protocol RWS received-by [ RWS |  | ] ) *( OWS "," [ OWS ( received-protocol RWS received-by [ RWS |
| comment ] ) ] ) |  | comment ] ) ] ) |
| absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3> |  | absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3> |
| absolute-form = absolute-URI |  | absolute-form = absolute-URI |
| absolute-path = 1*( "/" segment ) |  | absolute-path = 1*( "/" segment ) |
| asterisk-form = "*" |  | asterisk-form = "*" |
| attribute = token |  |  |
| authority = <authority, defined in [RFC3986], Section 3.2> |  | authority = <authority, defined in [RFC3986], Section 3.2> |
| authority-form = authority |  | authority-form = authority |
| chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF |  | chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF |
| chunk-data = 1*OCTET |  | chunk-data = 1*OCTET |
| chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-val ] ) |  | chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-val ] ) |
| chunk-ext-name = token |  | chunk-ext-name = token |
| chunk-ext-val = token / quoted-str-nf |  | chunk-ext-val = token / quoted-string |
| chunk-size = 1*HEXDIG |  | chunk-size = 1*HEXDIG |
| chunked-body = *chunk last-chunk trailer-part CRLF |  | chunked-body = *chunk last-chunk trailer-part CRLF |
| comment = "(" *( ctext / quoted-cpair / comment ) ")" |  | comment = "(" *( ctext / quoted-pair / comment ) ")" |
| connection-option = token |  | connection-option = token |
| ctext = HTAB / SP / %x21-27 ; '!'-''' |  | ctext = HTAB / SP / %x21-27 ; '!'-''' |
| / %x2A-5B ; '*'-'[' |  | / %x2A-5B ; '*'-'[' |
| / %x5D-7E ; ']'-'~' |  | / %x5D-7E ; ']'-'~' |
| / obs-text |  | / obs-text |
| field-content = *( HTAB / SP / VCHAR / obs-text ) |  | field-content = field-vchar [ 1*( SP / HTAB ) field-vchar ] |
| field-name = token |  | field-name = token |
| field-value = *( field-content / obs-fold ) |  | field-value = *( field-content / obs-fold ) |
|  |  | field-vchar = VCHAR / obs-text |
| fragment = <fragment, defined in [RFC3986], Section 3.5> |  | fragment = <fragment, defined in [RFC3986], Section 3.5> |
| header-field = field-name ":" OWS field-value OWS |  | header-field = field-name ":" OWS field-value OWS |
| http-URI = "http://" authority path-abempty [ "?" query ] [ "#" |  | http-URI = "http://" authority path-abempty [ "?" query ] [ "#" |
| fragment ] |  | fragment ] |
| https-URI = "https://" authority path-abempty [ "?" query ] [ "#" |  | https-URI = "https://" authority path-abempty [ "?" query ] [ "#" |
| fragment ] |  | fragment ] |
| last-chunk = 1*"0" [ chunk-ext ] CRLF |  | last-chunk = 1*"0" [ chunk-ext ] CRLF |
| message-body = *OCTET |  | message-body = *OCTET |
| method = token |  | method = token |
| obs-fold = CRLF ( SP / HTAB ) |  | obs-fold = CRLF 1*( SP / HTAB ) |
| obs-text = %x80-FF |  | obs-text = %x80-FF |
| origin-form = absolute-path [ "?" query ] |  | origin-form = absolute-path [ "?" query ] |
| partial-URI = relative-part [ "?" query ] |  | partial-URI = relative-part [ "?" query ] |
| path-abempty = <path-abempty, defined in [RFC3986], Section 3.3> |  | path-abempty = <path-abempty, defined in [RFC3986], Section 3.3> |
| port = <port, defined in [RFC3986], Section 3.2.3> |  | port = <port, defined in [RFC3986], Section 3.2.3> |
| protocol = protocol-name [ "/" protocol-version ] |  | protocol = protocol-name [ "/" protocol-version ] |
| protocol-name = token |  | protocol-name = token |
| protocol-version = token |  | protocol-version = token |
| pseudonym = token |  | pseudonym = token |
| qdtext = HTAB / SP / "!" / %x23-5B ; '#'-'[' |  | qdtext = HTAB / SP / "!" / %x23-5B ; '#'-'[' |
| / %x5D-7E ; ']'-'~' |  | / %x5D-7E ; ']'-'~' |
| / obs-text |  | / obs-text |
| qdtext-nf = HTAB / SP / "!" / %x23-5B ; '#'-'[' |  |  |
| / %x5D-7E ; ']'-'~' |  |  |
| / obs-text |  |  |
| query = <query, defined in [RFC3986], Section 3.4> |  | query = <query, defined in [RFC3986], Section 3.4> |
| quoted-cpair = "\" ( HTAB / SP / VCHAR / obs-text ) |  |  |
| quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text ) |  | quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text ) |
| quoted-str-nf = DQUOTE *( qdtext-nf / quoted-pair ) DQUOTE |  |  |
| quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE |  | quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE |
| rank = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] ) |  | rank = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] ) |
| reason-phrase = *( HTAB / SP / VCHAR / obs-text ) |  | reason-phrase = *( HTAB / SP / VCHAR / obs-text ) |
| received-by = ( uri-host [ ":" port ] ) / pseudonym |  | received-by = ( uri-host [ ":" port ] ) / pseudonym |
| received-protocol = [ protocol-name "/" ] protocol-version |  | received-protocol = [ protocol-name "/" ] protocol-version |
| relative-part = <relative-part, defined in [RFC3986], Section 4.2> |  | relative-part = <relative-part, defined in [RFC3986], Section 4.2> |
| request-line = method SP request-target SP HTTP-version CRLF |  | request-line = method SP request-target SP HTTP-version CRLF |
| request-target = origin-form / absolute-form / authority-form / |  | request-target = origin-form / absolute-form / authority-form / |
| asterisk-form |  | asterisk-form |
|  |  | scheme = <scheme, defined in [RFC3986], Section 3.1> |
| segment = <segment, defined in [RFC3986], Section 3.3> |  | segment = <segment, defined in [RFC3986], Section 3.3> |
| special = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" / |  |  |
| DQUOTE / "/" / "[" / "]" / "?" / "=" / "{" / "}" |  |  |
| start-line = request-line / status-line |  | start-line = request-line / status-line |
| status-code = 3DIGIT |  | status-code = 3DIGIT |
| status-line = HTTP-version SP status-code SP reason-phrase CRLF |  | status-line = HTTP-version SP status-code SP reason-phrase CRLF |
| t-codings = "trailers" / ( transfer-coding [ t-ranking ] ) |  | t-codings = "trailers" / ( transfer-coding [ t-ranking ] ) |
| t-ranking = OWS ";" OWS "q=" rank |  | t-ranking = OWS ";" OWS "q=" rank |
| tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." / |  | tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." / |
| "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA |  | "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA |
| token = 1*tchar |  | token = 1*tchar |
| trailer-part = *( header-field CRLF ) |  | trailer-part = *( header-field CRLF ) |
| transfer-coding = "chunked" / "compress" / "deflate" / "gzip" / |  | transfer-coding = "chunked" / "compress" / "deflate" / "gzip" / |
| transfer-extension |  | transfer-extension |
| transfer-extension = token *( OWS ";" OWS transfer-parameter ) |  | transfer-extension = token *( OWS ";" OWS transfer-parameter ) |
| transfer-parameter = attribute BWS "=" BWS value |  | transfer-parameter = token BWS "=" BWS ( token / quoted-string ) |
| uri-host = <host, defined in [RFC3986], Section 3.2.2> |  | uri-host = <host, defined in [RFC3986], Section 3.2.2> |
| value = word |  |  |
| word = token / quoted-string |  |  |
| Appendix C. Change Log (to be removed by RFC Editor before publication) |  | Appendix C. Change Log (to be removed by RFC Editor before publication) |
| C.1. Since RFC 2616 |  | C.1. Since RFC 2616 |
| Changes up to the IETF Last Call draft are summarized in <http:// |  | Changes up to the IETF Last Call draft are summarized in <http:// |
| trac.tools.ietf.org/html/ |  | trac.tools.ietf.org/html/ |
| draft-ietf-httpbis-p1-messaging-24#appendix-C>. |  | draft-ietf-httpbis-p1-messaging-24#appendix-C>. |
| C.2. Since draft-ietf-httpbis-p1-messaging-24 |  | C.2. Since draft-ietf-httpbis-p1-messaging-24 |
| skipping to change at page 80, line 11 |  | skipping to change at page 83, line 18 |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/502>: "APPSDIR |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/502>: "APPSDIR |
| review of draft-ietf-httpbis-p1-messaging-24" |  | review of draft-ietf-httpbis-p1-messaging-24" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/507>: "integer value |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/507>: "integer value |
| parsing" |  | parsing" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/517>: "move IANA |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/517>: "move IANA |
| registrations to correct draft" |  | registrations to correct draft" |
|  |  | C.3. Since draft-ietf-httpbis-p1-messaging-25 |
|  |  | Closed issues: |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/526>: "check media |
|  |  | type registration templates" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/528>: "Redundant |
|  |  | rule quoted-str-nf" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/531>: "IESG ballot |
|  |  | on draft-ietf-httpbis-p1-messaging-25" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/538>: "add |
|  |  | 'stateless' to Abstract" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/540>: "clarify ABNF |
|  |  | layering" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/541>: "use of 'word' |
|  |  | ABNF production" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/542>: "improve |
|  |  | introduction of list rule" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/544>: "moving 2616/ |
|  |  | 2068/2145 to historic" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/549>: "augment |
|  |  | security considerations with pointers to current research" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/551>: |
|  |  | "intermediaries handling trailers" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/552>: "allow privacy |
|  |  | proxies to be conformant" |
| Index |  | Index |
| A |  | A |
| absolute-form (of request-target) 42 |  | absolute-form (of request-target) 42 |
| accelerator 10 |  | accelerator 10 |
| application/http Media Type 61 |  | application/http Media Type 62 |
| asterisk-form (of request-target) 42 |  | asterisk-form (of request-target) 42 |
|  |  | authoritative response 66 |
| authority-form (of request-target) 42 |  | authority-form (of request-target) 42 |
| B |  | B |
| browser 7 |  | browser 7 |
| C |  | C |
| cache 11 |  | cache 11 |
| cacheable 12 |  | cacheable 11 |
| captive portal 11 |  | captive portal 11 |
| chunked (Coding Format) 28, 31, 35 |  | chunked (Coding Format) 28, 31, 35 |
| client 7 |  | client 7 |
| close 49, 55 |  | close 50, 55 |
| compress (Coding Format) 38 |  | compress (Coding Format) 38 |
| connection 7 |  | connection 7 |
| Connection header field 49, 55 |  | Connection header field 50, 55 |
| Content-Length header field 30 |  | Content-Length header field 30 |
| D |  | D |
| deflate (Coding Format) 38 |  | deflate (Coding Format) 38 |
|  |  | Delimiters 26 |
| downstream 9 |  | downstream 9 |
| E |  | E |
| effective request URI 44 |  | effective request URI 44 |
| G |  | G |
| gateway 10 |  | gateway 10 |
| Grammar |  | Grammar |
| absolute-form 41 |  | absolute-form 41-42 |
| absolute-path 16 |  | absolute-path 16 |
| absolute-URI 16 |  | absolute-URI 16 |
| ALPHA 6 |  | ALPHA 6 |
| asterisk-form 41 |  | asterisk-form 41-42 |
| attribute 35 |  |  |
| authority 16 |  | authority 16 |
| authority-form 41 |  | authority-form 41-42 |
| BWS 24 |  | BWS 24 |
| chunk 35-36 |  | chunk 35 |
| chunk-data 35-36 |  | chunk-data 35 |
| chunk-ext 35-36 |  | chunk-ext 35-36 |
| chunk-ext-name 35-36 |  | chunk-ext-name 36 |
| chunk-ext-val 35-36 |  | chunk-ext-val 36 |
| chunk-size 35-36 |  | chunk-size 35 |
| chunked-body 35-36 |  | chunked-body 35-36 |
| comment 27 |  | comment 27 |
| Connection 50 |  | Connection 51 |
| connection-option 50 |  | connection-option 51 |
| Content-Length 30 |  | Content-Length 30 |
| CR 6 |  | CR 6 |
| CRLF 6 |  | CRLF 6 |
| ctext 27 |  | ctext 27 |
| CTL 6 |  | CTL 6 |
| date2 35 |  |  |
| date3 35 |  |  |
| DIGIT 6 |  | DIGIT 6 |
| DQUOTE 6 |  | DQUOTE 6 |
| field-content 22 |  | field-content 22 |
| field-name 22 |  | field-name 22, 39 |
| field-value 22 |  | field-value 22 |
|  |  | field-vchar 22 |
| fragment 16 |  | fragment 16 |
| header-field 22 |  | header-field 22, 36 |
| HEXDIG 6 |  | HEXDIG 6 |
| Host 43 |  | Host 43 |
| HTAB 6 |  | HTAB 6 |
| HTTP-message 19 |  | HTTP-message 19 |
| HTTP-name 14 |  | HTTP-name 13 |
| http-URI 17 |  | http-URI 16 |
| HTTP-version 14 |  | HTTP-version 13 |
| https-URI 18 |  | https-URI 18 |
| last-chunk 35-36 |  | last-chunk 35 |
| LF 6 |  | LF 6 |
| message-body 27 |  | message-body 27 |
| method 21 |  | method 21 |
| obs-fold 22 |  | obs-fold 22 |
| obs-text 27 |  | obs-text 27 |
| OCTET 6 |  | OCTET 6 |
| origin-form 41 |  | origin-form 41 |
| OWS 24 |  | OWS 24 |
| partial-URI 16 |  | partial-URI 16 |
| port 16 |  | port 16 |
| protocol-name 47 |  | protocol-name 47 |
| protocol-version 47 |  | protocol-version 47 |
| pseudonym 47 |  | pseudonym 47 |
| qdtext 27 |  | qdtext 27 |
| qdtext-nf 35-36 |  |  |
| query 16 |  | query 16 |
| quoted-cpair 27 |  |  |
| quoted-pair 27 |  | quoted-pair 27 |
| quoted-str-nf 35-36 |  |  |
| quoted-string 27 |  | quoted-string 27 |
| rank 39 |  | rank 38 |
| reason-phrase 22 |  | reason-phrase 22 |
| received-by 47 |  | received-by 47 |
| received-protocol 47 |  | received-protocol 47 |
| request-line 21 |  | request-line 21 |
| request-target 41 |  | request-target 41 |
| RWS 24 |  | RWS 24 |
|  |  | scheme 16 |
| segment 16 |  | segment 16 |
| SP 6 |  | SP 6 |
| special 26 |  | start-line 20 |
| start-line 21 |  |  |
| status-code 22 |  | status-code 22 |
| status-line 22 |  | status-line 22 |
| t-codings 39 |  | t-codings 38 |
| t-ranking 39 |  | t-ranking 38 |
| tchar 26 |  | tchar 27 |
| TE 39 |  | TE 38 |
| token 26 |  | token 27 |
| Trailer 40 |  | Trailer 39 |
| trailer-part 35-37 |  | trailer-part 35-36 |
| transfer-coding 35 |  | transfer-coding 35 |
| Transfer-Encoding 28 |  | Transfer-Encoding 28 |
| transfer-extension 35 |  | transfer-extension 35 |
| transfer-parameter 35 |  | transfer-parameter 35 |
| Upgrade 56 |  | Upgrade 56 |
| uri-host 16 |  | uri-host 16 |
| URI-reference 16 |  | URI-reference 16 |
| value 35 |  |  |
| VCHAR 6 |  | VCHAR 6 |
| Via 47 |  | Via 47 |
| word 26 |  |  |
| gzip (Coding Format) 38 |  | 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 43 |  | Host header field 43 |
| http URI scheme 17 |  | http URI scheme 16 |
| https URI scheme 18 |  | 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 61 |  | application/http 62 |
| message/http 60 |  | message/http 61 |
| message 7 |  | message 7 |
| message/http Media Type 60 |  | message/http Media Type 61 |
| method 21 |  | method 21 |
| N |  | N |
| non-transforming proxy 10 |  | non-transforming proxy 48 |
| O |  | O |
| origin server 7 |  | origin server 7 |
| origin-form (of request-target) 41 |  | origin-form (of request-target) 41 |
| outbound 9 |  | outbound 9 |
| P |  | P |
|  |  | phishing 66 |
| proxy 10 |  | proxy 10 |
| R |  | R |
| recipient 7 |  | recipient 7 |
| request 7 |  | request 7 |
| request-target 21 |  | request-target 21 |
| resource 16 |  | 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 40 |  | target resource 40 |
| target URI 40 |  | target URI 40 |
| TE header field 38 |  | TE header field 38 |
| Trailer header field 40 |  | Trailer header field 39 |
| Transfer-Encoding header field 28 |  | Transfer-Encoding header field 28 |
| transforming proxy 10 |  | transforming proxy 48 |
| transparent proxy 11 |  | transparent proxy 11 |
| tunnel 11 |  | tunnel 10 |
| U |  | U |
| Upgrade header field 56 |  | Upgrade header field 56 |
| upstream 9 |  | upstream 9 |
| URI scheme |  | URI scheme |
| http 17 |  | http 16 |
| https 18 |  | https 18 |
| user agent 7 |  | user agent 7 |
| V |  | V |
| Via header field 46 |  | Via header field 47 |
| 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. 208 change blocks.
| 622 lines changed or deleted |  | 804 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/