| draft-ietf-httpbis-p1-messaging-18.txt |  | draft-ietf-httpbis-p1-messaging-19.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. Gettys |  | Obsoletes: 2145,2616 (if approved) Y. Lafon, Ed. |
| Updates: 2817 (if approved) Alcatel-Lucent |  | Updates: 2817 (if approved) W3C |
| Intended status: Standards Track J. Mogul |  | Intended status: Standards Track J. Reschke, Ed. |
| Expires: July 7, 2012 HP |  | Expires: September 13, 2012 greenbytes |
| H. Frystyk |  | March 12, 2012 |
| Microsoft |  |  |
| L. Masinter |  |  |
| Adobe |  |  |
| P. Leach |  |  |
| Microsoft |  |  |
| T. Berners-Lee |  |  |
| W3C/MIT |  |  |
| Y. Lafon, Ed. |  |  |
| W3C |  |  |
| J. Reschke, Ed. |  |  |
| greenbytes |  |  |
| January 4, 2012 |  |  |
| HTTP/1.1, part 1: URIs, Connections, and Message Parsing |  | HTTP/1.1, part 1: URIs, Connections, and Message Parsing |
| draft-ietf-httpbis-p1-messaging-18 |  | draft-ietf-httpbis-p1-messaging-19 |
| Abstract |  | Abstract |
| The Hypertext Transfer Protocol (HTTP) is an application-level |  | The Hypertext Transfer Protocol (HTTP) is an application-level |
| protocol for distributed, collaborative, hypertext information |  | protocol for distributed, collaborative, hypertext information |
| systems. HTTP has been in use by the World Wide Web global |  | systems. HTTP has been in use by the World Wide Web global |
| information initiative since 1990. This document is Part 1 of the |  | information initiative since 1990. This document is Part 1 of the |
| seven-part specification that defines the protocol referred to as |  | seven-part specification that defines the protocol referred to as |
| "HTTP/1.1" and, taken together, obsoletes RFC 2616 and moves it to |  | "HTTP/1.1" and, taken together, obsoletes RFC 2616 and moves it to |
| historic status, along with its predecessor RFC 2068. |  | historic status, along with its predecessor RFC 2068. |
| skipping to change at page 2, line 11 |  | skipping to change at page 1, line 45 |
| Discussion of this draft should take place on the HTTPBIS working |  | Discussion of this draft should take place on the HTTPBIS working |
| group mailing list (ietf-http-wg@w3.org), which is archived at |  | group mailing list (ietf-http-wg@w3.org), which is archived at |
| <http://lists.w3.org/Archives/Public/ietf-http-wg/>. |  | <http://lists.w3.org/Archives/Public/ietf-http-wg/>. |
| The current issues list is at |  | The current issues list is at |
| <http://tools.ietf.org/wg/httpbis/trac/report/3> and related |  | <http://tools.ietf.org/wg/httpbis/trac/report/3> and related |
| documents (including fancy diffs) can be found at |  | documents (including fancy diffs) can be found at |
| <http://tools.ietf.org/wg/httpbis/>. |  | <http://tools.ietf.org/wg/httpbis/>. |
| The changes in this draft are summarized in Appendix C.19. |  | The changes in this draft are summarized in Appendix C.20. |
| Status of This Memo |  | Status of This Memo |
| This Internet-Draft is submitted in full conformance with the |  | This Internet-Draft is submitted in full conformance with the |
| provisions of BCP 78 and BCP 79. |  | provisions of BCP 78 and BCP 79. |
| Internet-Drafts are working documents of the Internet Engineering |  | Internet-Drafts are working documents of the Internet Engineering |
| Task Force (IETF). Note that other groups may also distribute |  | Task Force (IETF). Note that other groups may also distribute |
| working documents as Internet-Drafts. The list of current Internet- |  | working documents as Internet-Drafts. The list of current Internet- |
| Drafts is at http://datatracker.ietf.org/drafts/current/. |  | Drafts is at http://datatracker.ietf.org/drafts/current/. |
| Internet-Drafts are draft documents valid for a maximum of six months |  | Internet-Drafts are draft documents valid for a maximum of six months |
| and may be updated, replaced, or obsoleted by other documents at any |  | and may be updated, replaced, or obsoleted by other documents at any |
| time. It is inappropriate to use Internet-Drafts as reference |  | time. It is inappropriate to use Internet-Drafts as reference |
| material or to cite them other than as "work in progress." |  | material or to cite them other than as "work in progress." |
| This Internet-Draft will expire on July 7, 2012. |  | This Internet-Draft will expire on September 13, 2012. |
| Copyright Notice |  | Copyright Notice |
| Copyright (c) 2012 IETF Trust and the persons identified as the |  | Copyright (c) 2012 IETF Trust and the persons identified as the |
| document authors. All rights reserved. |  | document authors. All rights reserved. |
| This document is subject to BCP 78 and the IETF Trust's Legal |  | This document is subject to BCP 78 and the IETF Trust's Legal |
| Provisions Relating to IETF Documents |  | Provisions Relating to IETF Documents |
| (http://trustee.ietf.org/license-info) in effect on the date of |  | (http://trustee.ietf.org/license-info) in effect on the date of |
| publication of this document. Please review these documents |  | publication of this document. Please review these documents |
| skipping to change at page 3, line 12 |  | skipping to change at page 2, line 48 |
| Without obtaining an adequate license from the person(s) controlling |  | Without obtaining an adequate license from the person(s) controlling |
| the copyright in such materials, this document may not be modified |  | the copyright in such materials, this document may not be modified |
| outside the IETF Standards Process, and derivative works of it may |  | outside the IETF Standards Process, and derivative works of it may |
| not be created outside the IETF Standards Process, except to format |  | not be created outside the IETF Standards Process, except to format |
| it for publication as an RFC or to translate it into languages other |  | it for publication as an RFC or to translate it into languages other |
| than English. |  | than English. |
| Table of Contents |  | Table of Contents |
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 |  | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 |
| 1.1. Conformance and Error Handling . . . . . . . . . . . . . . 7 |  | 1.1. Requirement Notation . . . . . . . . . . . . . . . . . . . 7 |
| 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7 |  | 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7 |
| 1.2.1. ABNF Extension: #rule . . . . . . . . . . . . . . . . 8 |  | 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 7 |
| 1.2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . 9 |  | 2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 7 |
| 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 9 |  | 2.2. Connections and Transport Independence . . . . . . . . . . 9 |
| 2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 10 |  | 2.3. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 9 |
| 2.2. Message Orientation and Buffering . . . . . . . . . . . . 11 |  | 2.4. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 12 |
| 2.3. Connections and Transport Independence . . . . . . . . . . 12 |  | 2.5. Conformance and Error Handling . . . . . . . . . . . . . . 12 |
| 2.4. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 12 |  | 2.6. Protocol Versioning . . . . . . . . . . . . . . . . . . . 13 |
| 2.5. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 14 |  | 2.7. Uniform Resource Identifiers . . . . . . . . . . . . . . . 15 |
| 2.6. Protocol Versioning . . . . . . . . . . . . . . . . . . . 15 |  | 2.7.1. http URI scheme . . . . . . . . . . . . . . . . . . . 16 |
| 2.7. Uniform Resource Identifiers . . . . . . . . . . . . . . . 17 |  | 2.7.2. https URI scheme . . . . . . . . . . . . . . . . . . . 17 |
| 2.7.1. http URI scheme . . . . . . . . . . . . . . . . . . . 18 |  | 2.7.3. http and https URI Normalization and Comparison . . . 18 |
| 2.7.2. https URI scheme . . . . . . . . . . . . . . . . . . . 19 |  | 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 19 |
| 2.7.3. http and https URI Normalization and Comparison . . . 20 |  | 3.1. Start Line . . . . . . . . . . . . . . . . . . . . . . . . 19 |
| 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 21 |  | 3.1.1. Request Line . . . . . . . . . . . . . . . . . . . . . 20 |
| 3.1. Start Line . . . . . . . . . . . . . . . . . . . . . . . . 21 |  | 3.1.2. Status Line . . . . . . . . . . . . . . . . . . . . . 21 |
| 3.1.1. Request-Line . . . . . . . . . . . . . . . . . . . . . 22 |  | 3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 21 |
| 3.1.2. Response Status-Line . . . . . . . . . . . . . . . . . 23 |  | 3.2.1. Whitespace . . . . . . . . . . . . . . . . . . . . . . 23 |
| 3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 23 |  | 3.2.2. Field Parsing . . . . . . . . . . . . . . . . . . . . 23 |
| 3.2.1. Field Parsing . . . . . . . . . . . . . . . . . . . . 25 |  | 3.2.3. Field Length . . . . . . . . . . . . . . . . . . . . . 24 |
| 3.2.2. Field Length . . . . . . . . . . . . . . . . . . . . . 25 |  | 3.2.4. Field value components . . . . . . . . . . . . . . . . 25 |
| 3.2.3. Common Field ABNF Rules . . . . . . . . . . . . . . . 26 |  | 3.2.5. ABNF list extension: #rule . . . . . . . . . . . . . . 26 |
| 3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 27 |  | 3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 27 |
| 3.4. Handling Incomplete Messages . . . . . . . . . . . . . . . 30 |  | 3.3.1. Transfer-Encoding . . . . . . . . . . . . . . . . . . 27 |
| 3.5. Message Parsing Robustness . . . . . . . . . . . . . . . . 31 |  | 3.3.2. Content-Length . . . . . . . . . . . . . . . . . . . . 29 |
| 4. Message Routing . . . . . . . . . . . . . . . . . . . . . . . 31 |  | 3.3.3. Message Body Length . . . . . . . . . . . . . . . . . 30 |
| 4.1. Types of Request Target . . . . . . . . . . . . . . . . . 31 |  | 3.4. Handling Incomplete Messages . . . . . . . . . . . . . . . 32 |
| 4.2. The Resource Identified by a Request . . . . . . . . . . . 33 |  | 3.5. Message Parsing Robustness . . . . . . . . . . . . . . . . 33 |
| 4.3. Effective Request URI . . . . . . . . . . . . . . . . . . 34 |  | 4. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . . 33 |
| 5. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 35 |  | 4.1. Chunked Transfer Coding . . . . . . . . . . . . . . . . . 34 |
| 5.1. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 35 |  | 4.2. Compression Codings . . . . . . . . . . . . . . . . . . . 36 |
| 5.1.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 36 |  | 4.2.1. Compress Coding . . . . . . . . . . . . . . . . . . . 36 |
| 5.1.2. Compression Codings . . . . . . . . . . . . . . . . . 38 |  | 4.2.2. Deflate Coding . . . . . . . . . . . . . . . . . . . . 36 |
| 5.1.3. Transfer Coding Registry . . . . . . . . . . . . . . . 39 |  | 4.2.3. Gzip Coding . . . . . . . . . . . . . . . . . . . . . 36 |
| 5.2. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 39 |  | 4.3. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 |
| 5.3. Quality Values . . . . . . . . . . . . . . . . . . . . . . 40 |  | 4.3.1. Quality Values . . . . . . . . . . . . . . . . . . . . 38 |
| 6. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 40 |  | 4.4. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 38 |
| 6.1. Persistent Connections . . . . . . . . . . . . . . . . . . 40 |  | 5. Message Routing . . . . . . . . . . . . . . . . . . . . . . . 39 |
| 6.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 40 |  | 5.1. Identifying a Target Resource . . . . . . . . . . . . . . 39 |
| 6.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 41 |  | 5.2. Connecting Inbound . . . . . . . . . . . . . . . . . . . . 39 |
| 6.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 42 |  | 5.3. Request Target . . . . . . . . . . . . . . . . . . . . . . 40 |
| 6.1.4. Practical Considerations . . . . . . . . . . . . . . . 45 |  | 5.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 |
| 6.1.5. Retrying Requests . . . . . . . . . . . . . . . . . . 46 |  | 5.5. Effective Request URI . . . . . . . . . . . . . . . . . . 43 |
| 6.2. Message Transmission Requirements . . . . . . . . . . . . 46 |  | 5.6. Intermediary Forwarding . . . . . . . . . . . . . . . . . 44 |
| 6.2.1. Persistent Connections and Flow Control . . . . . . . 46 |  | 5.6.1. End-to-end and Hop-by-hop Header Fields . . . . . . . 45 |
| 6.2.2. Monitoring Connections for Error Status Messages . . . 46 |  | 5.6.2. Non-modifiable Header Fields . . . . . . . . . . . . . 46 |
| 6.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 46 |  | 5.7. Associating a Response to a Request . . . . . . . . . . . 47 |
| 7. Miscellaneous notes that might disappear . . . . . . . . . . . 48 |  | 6. Connection Management . . . . . . . . . . . . . . . . . . . . 47 |
| 7.1. Scheme aliases considered harmful . . . . . . . . . . . . 48 |  | 6.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 47 |
| 7.2. Use of HTTP for proxy communication . . . . . . . . . . . 49 |  | 6.2. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 |
| 7.3. Interception of HTTP for access control . . . . . . . . . 49 |  | 6.3. Persistent Connections . . . . . . . . . . . . . . . . . . 50 |
| 7.4. Use of HTTP by other protocols . . . . . . . . . . . . . . 49 |  | 6.3.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 50 |
| 7.5. Use of HTTP by media type specification . . . . . . . . . 49 |  | 6.3.2. Overall Operation . . . . . . . . . . . . . . . . . . 51 |
| 8. Header Field Definitions . . . . . . . . . . . . . . . . . . . 49 |  | 6.3.3. Practical Considerations . . . . . . . . . . . . . . . 52 |
| 8.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 49 |  | 6.3.4. Retrying Requests . . . . . . . . . . . . . . . . . . 53 |
| 8.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 51 |  | 6.4. Message Transmission Requirements . . . . . . . . . . . . 54 |
| 8.3. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 |  | 6.4.1. Persistent Connections and Flow Control . . . . . . . 54 |
| 8.4. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 |  | 6.4.2. Monitoring Connections for Error Status Messages . . . 54 |
| 8.5. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 54 |  | 6.4.3. Use of the 100 (Continue) Status . . . . . . . . . . . 54 |
| 8.6. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 54 |  | 6.4.4. Closing Connections on Error . . . . . . . . . . . . . 56 |
| 8.7. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 55 |  | 6.5. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 56 |
| 8.7.1. Upgrade Token Registry . . . . . . . . . . . . . . . . 56 |  | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58 |
| 8.8. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 |  | 7.1. Header Field Registration . . . . . . . . . . . . . . . . 58 |
| 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58 |  | 7.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 58 |
| 9.1. Header Field Registration . . . . . . . . . . . . . . . . 58 |  | 7.3. Internet Media Type Registrations . . . . . . . . . . . . 59 |
| 9.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 59 |  | 7.3.1. Internet Media Type message/http . . . . . . . . . . . 59 |
| 9.3. Internet Media Type Registrations . . . . . . . . . . . . 59 |  | 7.3.2. Internet Media Type application/http . . . . . . . . . 60 |
| 9.3.1. Internet Media Type message/http . . . . . . . . . . . 59 |  | 7.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 61 |
| 9.3.2. Internet Media Type application/http . . . . . . . . . 61 |  | 7.5. Transfer Coding Registrations . . . . . . . . . . . . . . 62 |
| 9.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 62 |  | 7.6. Upgrade Token Registry . . . . . . . . . . . . . . . . . . 62 |
| 9.5. Upgrade Token Registration . . . . . . . . . . . . . . . . 62 |  | 7.7. Upgrade Token Registration . . . . . . . . . . . . . . . . 63 |
| 10. Security Considerations . . . . . . . . . . . . . . . . . . . 62 |  | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 63 |
| 10.1. Personal Information . . . . . . . . . . . . . . . . . . . 63 |  | 8.1. Personal Information . . . . . . . . . . . . . . . . . . . 63 |
| 10.2. Abuse of Server Log Information . . . . . . . . . . . . . 63 |  | 8.2. Abuse of Server Log Information . . . . . . . . . . . . . 63 |
| 10.3. Attacks Based On File and Path Names . . . . . . . . . . . 63 |  | 8.3. Attacks Based On File and Path Names . . . . . . . . . . . 64 |
| 10.4. DNS-related Attacks . . . . . . . . . . . . . . . . . . . 63 |  | 8.4. DNS-related Attacks . . . . . . . . . . . . . . . . . . . 64 |
| 10.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 64 |  | 8.5. Intermediaries and Caching . . . . . . . . . . . . . . . . 64 |
| 10.6. Protocol Element Size Overflows . . . . . . . . . . . . . 64 |  | 8.6. Protocol Element Size Overflows . . . . . . . . . . . . . 65 |
| 10.7. Denial of Service Attacks on Proxies . . . . . . . . . . . 65 |  | 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 66 |
| 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 65 |  | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 67 |
| 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 66 |  | 10.1. Normative References . . . . . . . . . . . . . . . . . . . 67 |
| 12.1. Normative References . . . . . . . . . . . . . . . . . . . 66 |  | 10.2. Informative References . . . . . . . . . . . . . . . . . . 68 |
| 12.2. Informative References . . . . . . . . . . . . . . . . . . 67 |  | Appendix A. HTTP Version History . . . . . . . . . . . . . . . . 70 |
| Appendix A. HTTP Version History . . . . . . . . . . . . . . . . 69 |  | A.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 71 |
| A.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 70 |  | A.1.1. Multi-homed Web Servers . . . . . . . . . . . . . . . 71 |
| A.1.1. Multi-homed Web Servers . . . . . . . . . . . . . . . 70 |  |  |
| A.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 71 |  | A.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 71 |
|  |  | A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 72 |
| A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 71 |  | A.3. Changes from RFC 2817 . . . . . . . . . . . . . . . . . . 73 |
| Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 72 |  | Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 73 |
| Appendix C. Change Log (to be removed by RFC Editor before |  | Appendix C. Change Log (to be removed by RFC Editor before |
| publication) . . . . . . . . . . . . . . . . . . . . 75 |  | publication) . . . . . . . . . . . . . . . . . . . . 76 |
| C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 75 |  | C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 76 |
| C.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 75 |  | C.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 76 |
| C.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 77 |  | C.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 78 |
| C.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 78 |  | C.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 79 |
| C.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 78 |  | C.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 79 |
| C.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 79 |  | C.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 80 |
| C.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 79 |  | C.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 80 |
| C.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 80 |  | C.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 81 |
| C.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 81 |  | C.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 82 |
| C.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 82 |  | C.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 82 |
| C.11. Since draft-ietf-httpbis-p1-messaging-09 . . . . . . . . . 82 |  | C.11. Since draft-ietf-httpbis-p1-messaging-09 . . . . . . . . . 83 |
| C.12. Since draft-ietf-httpbis-p1-messaging-10 . . . . . . . . . 82 |  | C.12. Since draft-ietf-httpbis-p1-messaging-10 . . . . . . . . . 83 |
| C.13. Since draft-ietf-httpbis-p1-messaging-11 . . . . . . . . . 83 |  | C.13. Since draft-ietf-httpbis-p1-messaging-11 . . . . . . . . . 84 |
| C.14. Since draft-ietf-httpbis-p1-messaging-12 . . . . . . . . . 83 |  | C.14. Since draft-ietf-httpbis-p1-messaging-12 . . . . . . . . . 84 |
| C.15. Since draft-ietf-httpbis-p1-messaging-13 . . . . . . . . . 84 |  | C.15. Since draft-ietf-httpbis-p1-messaging-13 . . . . . . . . . 85 |
| C.16. Since draft-ietf-httpbis-p1-messaging-14 . . . . . . . . . 84 |  | C.16. Since draft-ietf-httpbis-p1-messaging-14 . . . . . . . . . 85 |
| C.17. Since draft-ietf-httpbis-p1-messaging-15 . . . . . . . . . 85 |  | C.17. Since draft-ietf-httpbis-p1-messaging-15 . . . . . . . . . 85 |
| C.18. Since draft-ietf-httpbis-p1-messaging-16 . . . . . . . . . 85 |  | C.18. Since draft-ietf-httpbis-p1-messaging-16 . . . . . . . . . 86 |
| C.19. Since draft-ietf-httpbis-p1-messaging-17 . . . . . . . . . 85 |  | C.19. Since draft-ietf-httpbis-p1-messaging-17 . . . . . . . . . 86 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 |  | C.20. Since draft-ietf-httpbis-p1-messaging-18 . . . . . . . . . 87 |
|  |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 |
| 1. Introduction |  | 1. Introduction |
| The Hypertext Transfer Protocol (HTTP) is an application-level |  | The Hypertext Transfer Protocol (HTTP) is an application-level |
| request/response protocol that uses extensible semantics and MIME- |  | request/response protocol that uses extensible semantics and MIME- |
| like message payloads for flexible interaction with network-based |  | like message payloads for flexible interaction with network-based |
| hypertext information systems. HTTP relies upon the Uniform Resource |  | hypertext information systems. HTTP relies upon the Uniform Resource |
| Identifier (URI) standard [RFC3986] to indicate the target resource |  | Identifier (URI) standard [RFC3986] to indicate the target resource |
| and relationships between resources. Messages are passed in a format |  | (Section 5.1) and relationships between resources. Messages are |
| similar to that used by Internet mail [RFC5322] and the Multipurpose |  | passed in a format similar to that used by Internet mail [RFC5322] |
| Internet Mail Extensions (MIME) [RFC2045] (see Appendix A of [Part3] |  | and the Multipurpose Internet Mail Extensions (MIME) [RFC2045] (see |
| for the differences between HTTP and MIME messages). |  | Appendix A of [Part3] for the differences between HTTP and MIME |
|  |  | messages). |
| HTTP is a generic interface protocol for information systems. It is |  | HTTP is a generic interface protocol for information systems. It is |
| designed to hide the details of how a service is implemented by |  | designed to hide the details of how a service is implemented by |
| presenting a uniform interface to clients that is independent of the |  | presenting a uniform interface to clients that is independent of the |
| types of resources provided. Likewise, servers do not need to be |  | types of resources provided. Likewise, servers do not need to be |
| aware of each client's purpose: an HTTP request can be considered in |  | aware of each client's purpose: an HTTP request can be considered in |
| isolation rather than being associated with a specific type of client |  | isolation rather than being associated with a specific type of client |
| or a predetermined sequence of application steps. The result is a |  | or a predetermined sequence of application steps. The result is a |
| protocol that can be used effectively in many different contexts and |  | protocol that can be used effectively in many different contexts and |
| for which implementations can evolve independently over time. |  | for which implementations can evolve independently over time. |
| skipping to change at page 7, line 6 |  | skipping to change at page 7, line 7 |
| defining the protocol referred to as "HTTP/1.1", obsoleting [RFC2616] |  | defining the protocol referred to as "HTTP/1.1", obsoleting [RFC2616] |
| and [RFC2145]. Part 1 describes the architectural elements that are |  | and [RFC2145]. Part 1 describes the architectural elements that are |
| used or referred to in HTTP, defines the "http" and "https" URI |  | used or referred to in HTTP, defines the "http" and "https" URI |
| schemes, describes overall network operation and connection |  | schemes, describes overall network operation and connection |
| management, and defines HTTP message framing and forwarding |  | management, and defines HTTP message framing and forwarding |
| requirements. Our goal is to define all of the mechanisms necessary |  | requirements. Our goal is to define all of the mechanisms necessary |
| for HTTP message handling that are independent of message semantics, |  | for HTTP message handling that are independent of message semantics, |
| thereby defining the complete set of requirements for message parsers |  | thereby defining the complete set of requirements for message parsers |
| and message-forwarding intermediaries. |  | and message-forwarding intermediaries. |
| 1.1. Conformance and Error Handling |  | 1.1. Requirement Notation |
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |  | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |  | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |
| document are to be interpreted as described in [RFC2119]. |  | document are to be interpreted as described in [RFC2119]. |
| This document defines conformance criteria for several roles in HTTP |  |  |
| communication, including Senders, Recipients, Clients, Servers, User- |  |  |
| Agents, Origin Servers, Intermediaries, Proxies and Gateways. See |  |  |
| Section 2 for definitions of these terms. |  |  |
| An implementation is considered conformant if it complies with all of |  |  |
| the requirements associated with its role(s). Note that SHOULD-level |  |  |
| requirements are relevant here, unless one of the documented |  |  |
| exceptions is applicable. |  |  |
| This document also uses ABNF to define valid protocol elements |  |  |
| (Section 1.2). In addition to the prose requirements placed upon |  |  |
| them, Senders MUST NOT generate protocol elements that are invalid. |  |  |
| Unless noted otherwise, Recipients MAY take steps to recover a usable |  |  |
| protocol element from an invalid construct. However, HTTP does not |  |  |
| define specific error handling mechanisms, except in cases where it |  |  |
| has direct impact on security. This is because different uses of the |  |  |
| protocol require different error handling strategies; for example, a |  |  |
| Web browser may wish to transparently recover from a response where |  |  |
| the Location header field doesn't parse according to the ABNF, |  |  |
| whereby in a systems control protocol using HTTP, this type of error |  |  |
| recovery could lead to dangerous consequences. |  |  |
| 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]. |  | notation of [RFC5234] with the list rule extension defined in |
|  |  | Section 3.2.5. Appendix B shows the collected ABNF with the list |
|  |  | rule expanded. |
| The following core rules are included by reference, as defined in |  | The following core rules are included by reference, as defined in |
| [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF |  | [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF |
| (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), |  | (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), |
| HEXDIG (hexadecimal 0-9/A-F/a-f), 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 syntactic convention, ABNF rule names prefixed with "obs-" |  | As a convention, ABNF rule names prefixed with "obs-" denote |
| denote "obsolete" grammar rules that appear for historical reasons. |  | "obsolete" grammar rules that appear for historical reasons. |
| 1.2.1. ABNF Extension: #rule |  |  |
| The #rule extension to the ABNF rules of [RFC5234] is used to improve |  |  |
| readability. |  |  |
| A construct "#" is defined, similar to "*", for defining comma- |  |  |
| delimited lists of elements. The full form is "<n>#<m>element" |  |  |
| indicating at least <n> and at most <m> elements, each separated by a |  |  |
| single comma (",") and optional whitespace (OWS, Section 1.2.2). |  |  |
| Thus, |  |  |
| 1#element => element *( OWS "," OWS element ) |  |  |
| and: |  |  |
| #element => [ 1#element ] |  |  |
| and for n >= 1 and m > 1: |  |  |
| <n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element ) |  |  |
| For compatibility with legacy list rules, recipients SHOULD accept |  |  |
| empty list elements. In other words, consumers would follow the list |  |  |
| productions: |  |  |
| #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ] |  |  |
| 1#element => *( "," OWS ) element *( OWS "," [ OWS element ] ) |  |  |
| Note that empty elements do not contribute to the count of elements |  |  |
| present, though. |  |  |
| For example, given these ABNF productions: |  |  |
| example-list = 1#example-list-elmt |  |  |
| example-list-elmt = token ; see Section 3.2.3 |  |  |
| Then these are valid values for example-list (not including the |  |  |
| double quotes, which are present for delimitation only): |  |  |
| "foo,bar" |  |  |
| "foo ,bar," |  |  |
| "foo , ,bar,charlie " |  |  |
| But these values would be invalid, as at least one non-empty element |  |  |
| is required: |  |  |
| "" |  |  |
| "," |  |  |
| ", ," |  |  |
| Appendix B shows the collected ABNF, with the list rules expanded as |  |  |
| explained above. |  |  |
| 1.2.2. Basic Rules |  |  |
| This specification uses three rules to denote the use of linear |  |  |
| whitespace: OWS (optional whitespace), RWS (required whitespace), and |  |  |
| BWS ("bad" whitespace). |  |  |
| The OWS rule is used where zero or more linear whitespace octets |  |  |
| might appear. OWS SHOULD either not be produced or be produced as a |  |  |
| single SP. Multiple OWS octets that occur within field-content |  |  |
| SHOULD either be replaced with a single SP or transformed to all SP |  |  |
| octets (each octet other than SP replaced with SP) before |  |  |
| interpreting the field value or forwarding the message downstream. |  |  |
| RWS is used when at least one linear whitespace octet is required to |  |  |
| separate field tokens. RWS SHOULD be produced as a single SP. |  |  |
| Multiple RWS octets that occur within field-content SHOULD either be |  |  |
| replaced with a single SP or transformed to all SP octets before |  |  |
| interpreting the field value or forwarding the message downstream. |  |  |
| BWS is used where the grammar allows optional whitespace for |  |  |
| historical reasons but senders SHOULD NOT produce it in messages. |  |  |
| HTTP/1.1 recipients MUST accept such bad optional whitespace and |  |  |
| remove it before interpreting the field value or forwarding the |  |  |
| message downstream. |  |  |
| OWS = *( SP / HTAB / obs-fold ) |  |  |
| ; "optional" whitespace |  |  |
| RWS = 1*( SP / HTAB / obs-fold ) |  |  |
| ; "required" whitespace |  |  |
| BWS = OWS |  |  |
| ; "bad" whitespace |  |  |
| obs-fold = CRLF ( SP / HTAB ) |  |  |
| ; obsolete line folding |  |  |
| ; see Section 3.2.1 |  |  |
| 2. Architecture |  | 2. Architecture |
| HTTP was created for the World Wide Web architecture and has evolved |  | HTTP was created for the World Wide Web architecture and has evolved |
| over time to support the scalability needs of a worldwide hypertext |  | over time to support the scalability needs of a worldwide hypertext |
| system. Much of that architecture is reflected in the terminology |  | system. Much of that architecture is reflected in the terminology |
| and syntax productions used to define HTTP. |  | and syntax productions used to define HTTP. |
| 2.1. Client/Server Messaging |  | 2.1. Client/Server Messaging |
| skipping to change at page 10, line 47 |  | skipping to change at page 8, line 30 |
| connection (===) between the user agent (UA) and the origin server |  | connection (===) between the user agent (UA) and the origin server |
| (O). |  | (O). |
| request > |  | request > |
| UA ======================================= O |  | UA ======================================= O |
| < response |  | < response |
| A client sends an HTTP request to the server in the form of a request |  | A client sends an HTTP request to the server in the form of a request |
| message, beginning with a request-line that includes a method, URI, |  | message, beginning with a request-line that includes a method, URI, |
| and protocol version (Section 3.1.1), followed by MIME-like header |  | and protocol version (Section 3.1.1), followed by MIME-like header |
| fields containing request modifiers, client information, and payload |  | fields containing request modifiers, client information, and |
|  |  | representation metadata (Section 3.2), an empty line to indicate the |
|  |  | end of the header section, and finally a message body containing the |
|  |  | payload body (if any, Section 3.3). |
|  |  | A server responds to the client's request by sending one or more HTTP |
|  |  | response messages, each beginning with a status line that includes |
|  |  | the protocol version, a success or error code, and textual reason |
|  |  | phrase (Section 3.1.2), possibly followed by MIME-like header fields |
|  |  | containing server information, resource metadata, and representation |
| metadata (Section 3.2), an empty line to indicate the end of the |  | metadata (Section 3.2), an empty line to indicate the end of the |
| header section, and finally a message body containing the payload |  | header section, and finally a message body containing the payload |
| body (if any, Section 3.3). |  | body (if any, Section 3.3). |
| A server responds to the client's request by sending an HTTP response |  |  |
| message, beginning with a status line that includes the protocol |  |  |
| version, a success or error code, and textual reason phrase |  |  |
| (Section 3.1.2), followed by MIME-like header fields containing |  |  |
| server information, resource metadata, and payload metadata |  |  |
| (Section 3.2), an empty line to indicate the end of the header |  |  |
| section, and finally a message body containing the payload body (if |  |  |
| any, Section 3.3). |  |  |
| Note that 1xx responses (Section 7.1 of [Part2]) are not final; |  |  |
| therefore, a server can send zero or more 1xx responses, followed by |  |  |
| exactly one final response (with any other status code). |  |  |
| The following example illustrates a typical message exchange for a |  | The following example illustrates a typical message exchange for a |
| GET request on the URI "http://www.example.com/hello.txt": |  | GET request on the URI "http://www.example.com/hello.txt": |
| client request: |  | client request: |
| GET /hello.txt HTTP/1.1 |  | GET /hello.txt HTTP/1.1 |
| User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 |  | User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 |
| Host: www.example.com |  | Host: www.example.com |
| Accept: */* |  | Accept: */* |
| skipping to change at page 11, line 42 |  | skipping to change at page 9, line 26 |
| Server: Apache |  | Server: Apache |
| Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT |  | Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT |
| ETag: "34aa387-d-1568eb00" |  | ETag: "34aa387-d-1568eb00" |
| Accept-Ranges: bytes |  | Accept-Ranges: bytes |
| Content-Length: 14 |  | Content-Length: 14 |
| Vary: Accept-Encoding |  | Vary: Accept-Encoding |
| Content-Type: text/plain |  | Content-Type: text/plain |
| Hello World! |  | Hello World! |
| 2.2. Message Orientation and Buffering |  | 2.2. Connections and Transport Independence |
| Fundamentally, HTTP is a message-based protocol. Although message |  |  |
| bodies can be chunked (Section 5.1.1) and implementations often make |  |  |
| parts of a message available progressively, this is not required, and |  |  |
| some widely-used implementations only make a message available when |  |  |
| it is complete. Furthermore, while most proxies will progressively |  |  |
| stream messages, some amount of buffering will take place, and some |  |  |
| proxies might buffer messages to perform transformations, check |  |  |
| content or provide other services. |  |  |
| Therefore, extensions to and uses of HTTP cannot rely on the |  |  |
| availability of a partial message, or assume that messages will not |  |  |
| be buffered. There are strategies that can be used to test for |  |  |
| buffering in a given connection, but it should be understood that |  |  |
| behaviors can differ across connections, and between requests and |  |  |
| responses. |  |  |
| Recipients MUST consider every message in a connection in isolation; |  |  |
| because HTTP is a stateless protocol, it cannot be assumed that two |  |  |
| requests on the same connection are from the same client or share any |  |  |
| other common attributes. In particular, intermediaries might mix |  |  |
| requests from different clients into a single server connection. |  |  |
| Note that some existing HTTP extensions (e.g., [RFC4559]) violate |  |  |
| this requirement, thereby potentially causing interoperability and |  |  |
| security problems. |  |  |
| 2.3. Connections and Transport Independence |  |  |
| HTTP messaging is independent of the underlying transport or session- |  | HTTP messaging is independent of the underlying transport or session- |
| layer connection protocol(s). HTTP only presumes a reliable |  | layer connection protocol(s). HTTP only presumes a reliable |
| transport with in-order delivery of requests and the corresponding |  | transport with in-order delivery of requests and the corresponding |
| in-order delivery of responses. The mapping of HTTP request and |  | in-order delivery of responses. The mapping of HTTP request and |
| response structures onto the data units of the underlying transport |  | response structures onto the data units of the underlying transport |
| protocol is outside the scope of this specification. |  | protocol is outside the scope of this specification. |
| The specific connection protocols to be used for an interaction are |  | The specific connection protocols to be used for an interaction are |
| determined by client configuration and the target resource's URI. |  | determined by client configuration and the target URI (Section 5.1). |
| For example, the "http" URI scheme (Section 2.7.1) indicates a |  | For example, the "http" URI scheme (Section 2.7.1) indicates a |
| default connection of TCP over IP, with a default TCP port of 80, but |  | default connection of TCP over IP, with a default TCP port of 80, but |
| the client might be configured to use a proxy via some other |  | the client might be configured to use a proxy via some other |
| connection port or protocol instead of using the defaults. |  | connection port or protocol instead of using the defaults. |
| A connection might be used for multiple HTTP request/response |  | A connection might be used for multiple HTTP request/response |
| exchanges, as defined in Section 6.1. |  | exchanges, as defined in Section 6.3. |
| 2.4. Intermediaries |  | 2.3. Intermediaries |
| HTTP enables the use of intermediaries to satisfy requests through a |  | HTTP enables the use of intermediaries to satisfy requests through a |
| chain of connections. There are three common forms of HTTP |  | chain of connections. There are three common forms of HTTP |
| intermediary: proxy, gateway, and tunnel. In some cases, a single |  | intermediary: proxy, gateway, and tunnel. In some cases, a single |
| intermediary might act as an origin server, proxy, gateway, or |  | intermediary might act as an origin server, proxy, gateway, or |
| tunnel, switching behavior based on the nature of each request. |  | tunnel, switching behavior based on the nature of each request. |
| > > > > |  | > > > > |
| UA =========== A =========== B =========== C =========== O |  | UA =========== A =========== B =========== C =========== O |
| < < < < |  | < < < < |
| skipping to change at page 14, line 16 |  | skipping to change at page 11, line 21 |
| enable partitioning or load-balancing of HTTP services across |  | enable partitioning or load-balancing of HTTP services across |
| multiple machines. |  | multiple machines. |
| A gateway behaves as an origin server on its outbound connection and |  | A gateway behaves as an origin server on its outbound connection and |
| as a user agent on its inbound connection. All HTTP requirements |  | as a user agent on its inbound connection. All HTTP requirements |
| applicable to an origin server also apply to the outbound |  | applicable to an origin server also apply to the outbound |
| communication of a gateway. A gateway communicates with inbound |  | communication of a gateway. A gateway communicates with inbound |
| servers using any protocol that it desires, including private |  | servers using any protocol that it desires, including private |
| extensions to HTTP that are outside the scope of this specification. |  | extensions to HTTP that are outside the scope of this specification. |
| However, an HTTP-to-HTTP gateway that wishes to interoperate with |  | However, an HTTP-to-HTTP gateway that wishes to interoperate with |
| third-party HTTP servers MUST comply with HTTP user agent |  | third-party HTTP servers MUST conform to HTTP user agent requirements |
| requirements on the gateway's inbound connection and MUST implement |  | on the gateway's inbound connection and MUST implement the Connection |
| the Connection (Section 8.1) and Via (Section 8.8) header fields for |  | (Section 6.1) and Via (Section 6.2) header fields for both |
| both connections. |  | connections. |
| A "tunnel" acts as a blind relay between two connections without |  | A "tunnel" acts as a blind relay between two connections without |
| changing the messages. Once active, a tunnel is not considered a |  | changing the messages. Once active, a tunnel is not considered a |
| party to the HTTP communication, though the tunnel might have been |  | party to the HTTP communication, though the tunnel might have been |
| initiated by an HTTP request. A tunnel ceases to exist when both |  | initiated by an HTTP request. A tunnel ceases to exist when both |
| ends of the relayed connection are closed. Tunnels are used to |  | ends of the relayed connection are closed. Tunnels are used to |
| extend a virtual connection through an intermediary, such as when |  | extend a virtual connection through an intermediary, such as when |
| transport-layer security is used to establish private communication |  | transport-layer security is used to establish private communication |
| through a shared firewall proxy. |  | through a shared firewall proxy. |
| skipping to change at page 14, line 45 |  | skipping to change at page 11, line 50 |
| proxy" [RFC3040], "transparent proxy" [RFC1919], or "captive portal", |  | proxy" [RFC3040], "transparent proxy" [RFC1919], or "captive portal", |
| differs from an HTTP proxy because it has not been selected by the |  | differs from an HTTP proxy because it has not been selected by the |
| client. Instead, the network intermediary redirects outgoing TCP |  | client. Instead, the network intermediary redirects outgoing TCP |
| port 80 packets (and occasionally other common port traffic) to an |  | port 80 packets (and occasionally other common port traffic) to an |
| internal HTTP server. Interception proxies are commonly found on |  | internal HTTP server. Interception proxies are commonly found on |
| public network access points, as a means of enforcing account |  | public network access points, as a means of enforcing account |
| subscription prior to allowing use of non-local Internet services, |  | subscription prior to allowing use of non-local Internet services, |
| and within corporate firewalls to enforce network usage policies. |  | and within corporate firewalls to enforce network usage policies. |
| They are indistinguishable from a man-in-the-middle attack. |  | They are indistinguishable from a man-in-the-middle attack. |
| 2.5. Caches |  | HTTP is defined as a stateless protocol, meaning that each request |
|  |  | message can be understood in isolation. Many implementations depend |
|  |  | on HTTP's stateless design in order to reuse proxied connections or |
|  |  | dynamically load balance requests across multiple servers. Hence, |
|  |  | servers MUST NOT assume that two requests on the same connection are |
|  |  | from the same user agent unless the connection is secured and |
|  |  | specific to that agent. Some non-standard HTTP extensions (e.g., |
|  |  | [RFC4559]) have been known to violate this requirement, resulting in |
|  |  | security and interoperability problems. |
|  |  | 2.4. Caches |
| A "cache" is a local store of previous response messages and the |  | A "cache" is a local store of previous response messages and the |
| subsystem that controls its message storage, retrieval, and deletion. |  | subsystem that controls its message storage, retrieval, and deletion. |
| A cache stores cacheable responses in order to reduce the response |  | A cache stores cacheable responses in order to reduce the response |
| time and network bandwidth consumption on future, equivalent |  | time and network bandwidth consumption on future, equivalent |
| requests. Any client or server MAY employ a cache, though a cache |  | requests. Any client or server MAY employ a cache, though a cache |
| cannot be used by a server while it is acting as a tunnel. |  | cannot be used by a server while it is acting as a tunnel. |
| The effect of a cache is that the request/response chain is shortened |  | The effect of a cache is that the request/response chain is shortened |
| if one of the participants along the chain has a cached response |  | if one of the participants along the chain has a cached response |
| skipping to change at page 15, line 31 |  | skipping to change at page 12, line 46 |
| cache behavior and cacheable responses are defined in Section 2 of |  | cache behavior and cacheable responses are defined in Section 2 of |
| [Part6]. |  | [Part6]. |
| There are a wide variety of architectures and configurations of |  | There are a wide variety of architectures and configurations of |
| caches and proxies deployed across the World Wide Web and inside |  | caches and proxies deployed across the World Wide Web and inside |
| large organizations. These systems include national hierarchies of |  | large organizations. These systems include national hierarchies of |
| proxy caches to save transoceanic bandwidth, systems that broadcast |  | proxy caches to save transoceanic bandwidth, systems that broadcast |
| or multicast cache entries, organizations that distribute subsets of |  | or multicast cache entries, organizations that distribute subsets of |
| cached data via optical media, and so on. |  | cached data via optical media, and so on. |
|  |  | 2.5. Conformance and Error Handling |
|  |  | This specification targets conformance criteria according to the role |
|  |  | of a participant in HTTP communication. Hence, HTTP requirements are |
|  |  | placed on senders, recipients, clients, servers, user agents, |
|  |  | intermediaries, origin servers, proxies, gateways, or caches, |
|  |  | depending on what behavior is being constrained by the requirement. |
|  |  | An implementation is considered conformant if it complies with all of |
|  |  | the requirements associated with the roles it partakes in HTTP. |
|  |  | Senders MUST NOT generate protocol elements that do not match the |
|  |  | grammar defined by the ABNF rules for those protocol elements. |
|  |  | Unless otherwise noted, recipients MAY attempt to recover a usable |
|  |  | protocol element from an invalid construct. HTTP does not define |
|  |  | specific error handling mechanisms except when they have a direct |
|  |  | impact on security, since different applications of the protocol |
|  |  | require different error handling strategies. For example, a Web |
|  |  | browser might wish to transparently recover from a response where the |
|  |  | Location header field doesn't parse according to the ABNF, whereas a |
|  |  | systems control client might consider any form of error recovery to |
|  |  | be dangerous. |
| 2.6. Protocol Versioning |  | 2.6. Protocol Versioning |
| HTTP uses a "<major>.<minor>" numbering scheme to indicate versions |  | HTTP uses a "<major>.<minor>" numbering scheme to indicate versions |
| of the protocol. This specification defines version "1.1". The |  | of the protocol. This specification defines version "1.1". The |
| protocol version as a whole indicates the sender's compliance with |  | protocol version as a whole indicates the sender's conformance with |
| the set of requirements laid out in that version's corresponding |  | the set of requirements laid out in that version's corresponding |
| specification of HTTP. |  | specification of HTTP. |
| The version of an HTTP message is indicated by an HTTP-Version field |  | The version of an HTTP message is indicated by an HTTP-version field |
| in the first line of the message. HTTP-Version is case-sensitive. |  | in the first line of the message. HTTP-version is case-sensitive. |
| HTTP-Version = HTTP-Prot-Name "/" DIGIT "." DIGIT |  | HTTP-version = HTTP-name "/" DIGIT "." DIGIT |
| HTTP-Prot-Name = %x48.54.54.50 ; "HTTP", case-sensitive |  | HTTP-name = %x48.54.54.50 ; "HTTP", case-sensitive |
| The HTTP version number consists of two decimal digits separated by a |  | The HTTP version number consists of two decimal digits separated by a |
| "." (period or decimal point). The first digit ("major version") |  | "." (period or decimal point). The first digit ("major version") |
| indicates the HTTP messaging syntax, whereas the second digit ("minor |  | indicates the HTTP messaging syntax, whereas the second digit ("minor |
| version") indicates the highest minor version to which the sender is |  | version") indicates the highest minor version to which the sender is |
| at least conditionally compliant and able to understand for future |  | conformant and able to understand for future communication. The |
| communication. The minor version advertises the sender's |  | minor version advertises the sender's communication capabilities even |
| communication capabilities even when the sender is only using a |  | when the sender is only using a backwards-compatible subset of the |
| backwards-compatible subset of the protocol, thereby letting the |  | protocol, thereby letting the recipient know that more advanced |
| recipient know that more advanced features can be used in response |  | features can be used in response (by servers) or in future requests |
| (by servers) or in future requests (by clients). |  | (by clients). |
| When an HTTP/1.1 message is sent to an HTTP/1.0 recipient [RFC1945] |  | When an HTTP/1.1 message is sent to an HTTP/1.0 recipient [RFC1945] |
| or a recipient whose version is unknown, the HTTP/1.1 message is |  | or a recipient whose version is unknown, the HTTP/1.1 message is |
| constructed such that it can be interpreted as a valid HTTP/1.0 |  | constructed such that it can be interpreted as a valid HTTP/1.0 |
| message if all of the newer features are ignored. This specification |  | message if all of the newer features are ignored. This specification |
| places recipient-version requirements on some new features so that a |  | places recipient-version requirements on some new features so that a |
| compliant sender will only use compatible features until it has |  | conformant sender will only use compatible features until it has |
| determined, through configuration or the receipt of a message, that |  | determined, through configuration or the receipt of a message, that |
| the recipient supports HTTP/1.1. |  | the recipient supports HTTP/1.1. |
| The interpretation of an HTTP header field does not change between |  | The interpretation of a header field does not change between minor |
| minor versions of the same major version, though the default behavior |  | versions of the same major HTTP version, though the default behavior |
| of a recipient in the absence of such a field can change. Unless |  | of a recipient in the absence of such a field can change. Unless |
| specified otherwise, header fields defined in HTTP/1.1 are defined |  | specified otherwise, header fields defined in HTTP/1.1 are defined |
| for all versions of HTTP/1.x. In particular, the Host and Connection |  | for all versions of HTTP/1.x. In particular, the Host and Connection |
| header fields ought to be implemented by all HTTP/1.x implementations |  | header fields ought to be implemented by all HTTP/1.x implementations |
| whether or not they advertise compliance with HTTP/1.1. |  | whether or not they advertise conformance with HTTP/1.1. |
| New header fields can be defined such that, when they are understood |  | New header fields can be defined such that, when they are understood |
| by a recipient, they might override or enhance the interpretation of |  | by a recipient, they might override or enhance the interpretation of |
| previously defined header fields. When an implementation receives an |  | previously defined header fields. When an implementation receives an |
| unrecognized header field, the recipient MUST ignore that header |  | unrecognized header field, the recipient MUST ignore that header |
| field for local processing regardless of the message's HTTP version. |  | field for local processing regardless of the message's HTTP version. |
| An unrecognized header field received by a proxy MUST be forwarded |  | An unrecognized header field received by a proxy MUST be forwarded |
| downstream unless the header field's field-name is listed in the |  | downstream unless the header field's field-name is listed in the |
| message's Connection header-field (see Section 8.1). These |  | message's Connection header-field (see Section 6.1). These |
| requirements allow HTTP's functionality to be enhanced without |  | requirements allow HTTP's functionality to be enhanced without |
| requiring prior update of all compliant intermediaries. |  | requiring prior update of deployed intermediaries. |
| Intermediaries that process HTTP messages (i.e., all intermediaries |  | Intermediaries that process HTTP messages (i.e., all intermediaries |
| other than those acting as a tunnel) MUST send their own HTTP-Version |  | other than those acting as tunnels) MUST send their own HTTP-version |
| in forwarded messages. In other words, they MUST NOT blindly forward |  | in forwarded messages. In other words, they MUST NOT blindly forward |
| the first line of an HTTP message without ensuring that the protocol |  | the first line of an HTTP message without ensuring that the protocol |
| version matches what the intermediary understands, and is at least |  | version in that message matches a version to which that intermediary |
| conditionally compliant to, for both the receiving and sending of |  | is conformant for both the receiving and sending of messages. |
| messages. Forwarding an HTTP message without rewriting the HTTP- |  | Forwarding an HTTP message without rewriting the HTTP-version might |
| Version might result in communication errors when downstream |  | result in communication errors when downstream recipients use the |
| recipients use the message sender's version to determine what |  | message sender's version to determine what features are safe to use |
| features are safe to use for later communication with that sender. |  | for later communication with that sender. |
| An HTTP client SHOULD send a request version equal to the highest |  | An HTTP client SHOULD send a request version equal to the highest |
| version for which the client is at least conditionally compliant and |  | version to which the client is conformant and whose major version is |
| whose major version is no higher than the highest version supported |  | no higher than the highest version supported by the server, if this |
| by the server, if this is known. An HTTP client MUST NOT send a |  | is known. An HTTP client MUST NOT send a version to which it is not |
| version for which it is not at least conditionally compliant. |  | conformant. |
| An HTTP client MAY send a lower request version if it is known that |  | An HTTP client MAY send a lower request version if it is known that |
| the server incorrectly implements the HTTP specification, but only |  | the server incorrectly implements the HTTP specification, but only |
| after the client has attempted at least one normal request and |  | after the client has attempted at least one normal request and |
| determined from the response status or header fields (e.g., Server) |  | determined from the response status or header fields (e.g., Server) |
| that the server improperly handles higher request versions. |  | that the server improperly handles higher request versions. |
| An HTTP server SHOULD send a response version equal to the highest |  | An HTTP server SHOULD send a response version equal to the highest |
| version for which the server is at least conditionally compliant and |  | version to which the server is conformant and whose major version is |
| whose major version is less than or equal to the one received in the |  | less than or equal to the one received in the request. An HTTP |
| request. An HTTP server MUST NOT send a version for which it is not |  | server MUST NOT send a version to which it is not conformant. A |
| at least conditionally compliant. A server MAY send a 505 (HTTP |  | server MAY send a 505 (HTTP Version Not Supported) response if it |
| Version Not Supported) response if it cannot send a response using |  | cannot send a response using the major version used in the client's |
| the major version used in the client's request. |  | request. |
| An HTTP server MAY send an HTTP/1.0 response to an HTTP/1.0 request |  | An HTTP server MAY send an HTTP/1.0 response to an HTTP/1.0 request |
| if it is known or suspected that the client incorrectly implements |  | if it is known or suspected that the client incorrectly implements |
| the HTTP specification and is incapable of correctly processing later |  | the HTTP specification and is incapable of correctly processing later |
| version responses, such as when a client fails to parse the version |  | version responses, such as when a client fails to parse the version |
| number correctly or when an intermediary is known to blindly forward |  | number correctly or when an intermediary is known to blindly forward |
| the HTTP-Version even when it doesn't comply with the given minor |  | the HTTP-version even when it doesn't conform to the given minor |
| version of the protocol. Such protocol downgrades SHOULD NOT be |  | version of the protocol. Such protocol downgrades SHOULD NOT be |
| performed unless triggered by specific client attributes, such as |  | performed unless triggered by specific client attributes, such as |
| when one or more of the request header fields (e.g., User-Agent) |  | when one or more of the request header fields (e.g., User-Agent) |
| uniquely match the values sent by a client known to be in error. |  | uniquely match the values sent by a client known to be in error. |
| The intention of HTTP's versioning design is that the major number |  | The intention of HTTP's versioning design is that the major number |
| will only be incremented if an incompatible message syntax is |  | will only be incremented if an incompatible message syntax is |
| introduced, and that the minor number will only be incremented when |  | introduced, and that the minor number will only be incremented when |
| changes made to the protocol have the effect of adding to the message |  | changes made to the protocol have the effect of adding to the message |
| semantics or implying additional capabilities of the sender. |  | semantics or implying additional capabilities of the sender. |
| skipping to change at page 18, line 23 |  | skipping to change at page 16, line 22 |
| query = <query, defined in [RFC3986], Section 3.4> |  | query = <query, defined in [RFC3986], Section 3.4> |
| uri-host = <host, defined in [RFC3986], Section 3.2.2> |  | uri-host = <host, defined in [RFC3986], Section 3.2.2> |
| partial-URI = relative-part [ "?" query ] |  | partial-URI = relative-part [ "?" query ] |
| Each protocol element in HTTP that allows a URI reference will |  | Each protocol element in HTTP that allows a URI reference will |
| indicate in its ABNF production whether the element allows any form |  | indicate in its ABNF production whether the element allows any form |
| of reference (URI-reference), only a URI in absolute form (absolute- |  | of reference (URI-reference), only a URI in absolute form (absolute- |
| URI), only the path and optional query components, or some |  | URI), only the path and optional query components, or some |
| combination of the above. Unless otherwise indicated, URI references |  | combination of the above. Unless otherwise indicated, URI references |
| are parsed relative to the effective request URI, which defines the |  | are parsed relative to the effective request URI (Section 5.5). |
| default base URI for references in both the request and its |  |  |
| corresponding response. |  |  |
| 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 connections on a given port. |  | TCP connections on a given port. |
| http-URI = "http:" "//" authority path-abempty [ "?" query ] |  | http-URI = "http:" "//" authority path-abempty [ "?" query ] |
| skipping to change at page 19, line 19 |  | skipping to change at page 17, line 15 |
| "http" URI scheme makes use of the delegated nature of Internet names |  | "http" URI scheme makes use of the delegated nature of Internet names |
| and addresses to establish a naming authority (whatever entity has |  | and addresses to establish a naming authority (whatever entity has |
| the ability to place an HTTP server at that Internet name or address) |  | the ability to place an HTTP server at that Internet name or address) |
| and allows that authority to determine which names are valid and how |  | and allows that authority to determine which names are valid and how |
| they might be used. |  | they might be used. |
| When an "http" URI is used within a context that calls for access to |  | When an "http" URI is used within a context that calls for access to |
| the indicated resource, a client MAY attempt access by resolving the |  | the indicated resource, a client MAY attempt access by resolving the |
| host to an IP address, establishing a TCP connection to that address |  | host to an IP address, establishing a TCP connection to that address |
| on the indicated port, and sending an HTTP request message |  | on the indicated port, and sending an HTTP request message |
| (Section 3) containing the URI's identifying data (Section 4) 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 4 of [Part2], then |  | HTTP response message, as described in Section 4 of [Part2], then |
| that response is considered an authoritative answer to the client's |  | that response is considered an authoritative answer to the client's |
| request. |  | request. |
| Although HTTP is independent of the transport protocol, the "http" |  | Although HTTP is independent of the transport protocol, the "http" |
| scheme is specific to TCP-based services because the name delegation |  | scheme is specific to TCP-based services because the name delegation |
| process depends on TCP for establishing authority. An HTTP service |  | process depends on TCP for establishing authority. An HTTP service |
| based on some other underlying connection protocol would presumably |  | based on some other underlying connection protocol would presumably |
| be identified using a different URI scheme, just as the "https" |  | be identified using a different URI scheme, just as the "https" |
| skipping to change at page 21, line 15 |  | skipping to change at page 19, line 12 |
| 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 |
| of octets in a format similar to the Internet Message Format |  | of octets in a format similar to the Internet Message Format |
| [RFC5322]: zero or more header fields (collectively referred to as |  | [RFC5322]: zero or more header fields (collectively referred to as |
| the "headers" or the "header section"), an empty line indicating the |  | the "headers" or the "header section"), an empty line indicating the |
| end of the header section, and an optional message-body. |  | end of the header section, and an optional message body. |
| HTTP-message = start-line |  | HTTP-message = start-line |
| *( header-field CRLF ) |  | *( header-field CRLF ) |
| CRLF |  | CRLF |
| [ message-body ] |  | [ message-body ] |
| The normal procedure for parsing an HTTP message is to read the |  | The normal procedure for parsing an HTTP message is to read the |
| start-line into a structure, read each header field into a hash table |  | start-line into a structure, read each header field into a hash table |
| by field name until the empty line, and then use the parsed data to |  | by field name until the empty line, and then use the parsed data to |
| determine if a message-body is expected. If a message-body has been |  | determine if a message body is expected. If a message body has been |
| indicated, then it is read as a stream until an amount of octets |  | indicated, then it is read as a stream until an amount of octets |
| equal to the message-body length is read or the connection is closed. |  | equal to the message body length is read or the connection is closed. |
| Recipients MUST parse an HTTP message as a sequence of octets in an |  | Recipients MUST parse an HTTP message as a sequence of octets in an |
| encoding that is a superset of US-ASCII [USASCII]. Parsing an HTTP |  | encoding that is a superset of US-ASCII [USASCII]. Parsing an HTTP |
| message as a stream of Unicode characters, without regard for the |  | message as a stream of Unicode characters, without regard for the |
| specific encoding, creates security vulnerabilities due to the |  | specific encoding, creates security vulnerabilities due to the |
| varying ways that string processing libraries handle invalid |  | varying ways that string processing libraries handle invalid |
| multibyte character sequences that contain the octet LF (%x0A). |  | multibyte character sequences that contain the octet LF (%x0A). |
| String-based parsers can only be safely used within protocol elements |  | String-based parsers can only be safely used within protocol elements |
| after the element has been extracted from the message, such as within |  | after the element has been extracted from the message, such as within |
| a header field-value after message parsing has delineated the |  | a header field-value after message parsing has delineated the |
| individual fields. |  | individual fields. |
|  |  | An HTTP message can be parsed as a stream for incremental processing |
|  |  | or forwarding downstream. However, recipients cannot rely on |
|  |  | incremental delivery of partial messages, since some implementations |
|  |  | will buffer or delay message forwarding for the sake of network |
|  |  | efficiency, security checks, or payload transformations. |
| 3.1. Start Line |  | 3.1. Start Line |
| An HTTP message can either be a request from client to server or a |  | An HTTP message can either be a request from client to server or a |
| response from server to client. Syntactically, the two types of |  | response from server to client. Syntactically, the two types of |
| message differ only in the start-line, which is either a Request-Line |  | message differ only in the start-line, which is either a request-line |
| (for requests) or a Status-Line (for responses), and in the algorithm |  | (for requests) or a status-line (for responses), and in the algorithm |
| for determining the length of the message-body (Section 3.3). In |  | for determining the length of the message body (Section 3.3). In |
| theory, a client could receive requests and a server could receive |  | theory, a client could receive requests and a server could receive |
| responses, distinguishing them by their different start-line formats, |  | responses, distinguishing them by their different start-line formats, |
| but in practice servers are implemented to only expect a request (a |  | but in practice servers are implemented to only expect a request (a |
| response is interpreted as an unknown or invalid request method) and |  | response is interpreted as an unknown or invalid request method) and |
| clients are implemented to only expect a response. |  | clients are implemented to only expect a response. |
| start-line = Request-Line / Status-Line |  | start-line = request-line / status-line |
| Implementations MUST NOT send whitespace between the start-line and |  | Implementations MUST NOT send whitespace between the start-line and |
| the first header field. The presence of such whitespace in a request |  | the first header field. The presence of such whitespace in a request |
| might be an attempt to trick a server into ignoring that field or |  | might be an attempt to trick a server into ignoring that field or |
| processing the line after it as a new request, either of which might |  | processing the line after it as a new request, either of which might |
| result in a security vulnerability if other implementations within |  | result in a security vulnerability if other implementations within |
| the request chain interpret the same message differently. Likewise, |  | the request chain interpret the same message differently. Likewise, |
| the presence of such whitespace in a response might be ignored by |  | the presence of such whitespace in a response might be ignored by |
| some clients or cause others to cease parsing. |  | some clients or cause others to cease parsing. |
| 3.1.1. Request-Line |  | 3.1.1. Request Line |
| The Request-Line begins with a method token, followed by a single |  |  |
| space (SP), the request-target, another single space (SP), the |  |  |
| protocol version, and ending with CRLF. |  |  |
| Request-Line = Method SP request-target SP HTTP-Version CRLF |  | A request-line begins with a method token, followed by a single space |
|  |  | (SP), the request-target, another single space (SP), the protocol |
|  |  | version, and ending with CRLF. |
| 3.1.1.1. Method |  | request-line = method SP request-target SP HTTP-version CRLF |
| The Method token indicates the request method to be performed on the |  | The method token indicates the request method to be performed on the |
| target resource. The request method is case-sensitive. |  | target resource. The request method is case-sensitive. |
| Method = token |  | method = token |
| See Section 2 of [Part2] for further information, such as the list of |  |  |
| methods defined by this specification, the IANA registry, and |  |  |
| considerations for new methods. |  |  |
| 3.1.1.2. request-target |  | The methods defined by this specification can be found in Section 2 |
|  |  | of [Part2], along with information regarding the HTTP method registry |
|  |  | and considerations for defining new methods. |
| The request-target identifies the target resource upon which to apply |  | The request-target identifies the target resource upon which to apply |
| the request. The four options for request-target are described in |  | the request, as defined in Section 5.3. |
| Section 4.1. |  |  |
| request-target = "*" |  | No whitespace is allowed inside the method, request-target, and |
| / absolute-URI |  | protocol version. Hence, recipients typically parse the request-line |
| / ( path-absolute [ "?" query ] ) |  | into its component parts by splitting on the SP characters. |
| / authority |  |  |
|  |  | Unfortunately, some user agents fail to properly encode hypertext |
|  |  | references that have embedded whitespace, sending the characters |
|  |  | directly instead of properly percent-encoding the disallowed |
|  |  | characters. Recipients of an invalid request-line SHOULD respond |
|  |  | with either a 400 (Bad Request) error or a 301 (Moved Permanently) |
|  |  | redirect with the request-target properly encoded. Recipients SHOULD |
|  |  | NOT attempt to autocorrect and then process the request without a |
|  |  | redirect, since the invalid request-line might be deliberately |
|  |  | crafted to bypass security filters along the request chain. |
| HTTP does not place a pre-defined limit on the length of a request- |  | HTTP does not place a pre-defined limit on the length of a request- |
| target. A server MUST be prepared to receive URIs of unbounded |  | line. A server that receives a method longer than any that it |
| length and respond with the 414 (URI Too Long) status code if the |  | implements SHOULD respond with either a 404 (Not Allowed), if it is |
| received request-target would be longer than the server wishes to |  | an origin server, or a 501 (Not Implemented) status code. A server |
| handle (see Section 7.4.15 of [Part2]). |  | MUST be prepared to receive URIs of unbounded length and respond with |
|  |  | the 414 (URI Too Long) status code if the received request-target |
|  |  | would be longer than the server wishes to handle (see Section 7.4.12 |
|  |  | of [Part2]). |
| Various ad-hoc limitations on request-target 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 request-target lengths of 8000 or more octets. |  | support, at a minimum, request-line lengths of up to 8000 octets. |
| Note: Fragments ([RFC3986], Section 3.5) are not part of the |  |  |
| request-target and thus will not be transmitted in an HTTP |  |  |
| request. |  |  |
| 3.1.2. Response Status-Line |  | 3.1.2. Status Line |
| The first line of a Response message is the Status-Line, consisting |  | The first line of a response message is the status-line, consisting |
| of the protocol version, a space (SP), the status code, another |  | of the protocol version, a space (SP), the status code, another |
| space, a possibly-empty textual phrase describing the status code, |  | space, a possibly-empty textual phrase describing the status code, |
| and ending with CRLF. |  | and ending with CRLF. |
| Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF |  | status-line = HTTP-version SP status-code SP reason-phrase CRLF |
| 3.1.2.1. Status Code |  |  |
| The Status-Code element is a 3-digit integer result code of the |  | The status-code element is a 3-digit integer result code of the |
| attempt to understand and satisfy the request. See Section 4 of |  | attempt to understand and satisfy the request. See Section 4 of |
| [Part2] for further information, such as the list of status codes |  | [Part2] for further information, such as the list of status codes |
| defined by this specification, the IANA registry, and considerations |  | defined by this specification, the IANA registry, and considerations |
| for new status codes. |  | for new status codes. |
| Status-Code = 3DIGIT |  | status-code = 3DIGIT |
| 3.1.2.2. Reason Phrase |  |  |
| The Reason Phrase exists for the sole purpose of providing a textual |  | The reason-phrase element exists for the sole purpose of providing a |
| description associated with the numeric status code, out of deference |  | textual description associated with the numeric status code, mostly |
| to earlier Internet application protocols that were more frequently |  | out of deference to earlier Internet application protocols that were |
| used with interactive text clients. A client SHOULD ignore the |  | more frequently used with interactive text clients. A client SHOULD |
| content of the Reason Phrase. |  | 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 HTTP header field consists of a case-insensitive field name |
| followed by a colon (":"), optional whitespace, and the field value. |  | followed by a colon (":"), optional whitespace, and the field value. |
| header-field = field-name ":" OWS field-value BWS |  | header-field = field-name ":" OWS field-value BWS |
| field-name = token |  | field-name = token |
| field-value = *( field-content / obs-fold ) |  | field-value = *( field-content / obs-fold ) |
| field-content = *( HTAB / SP / VCHAR / obs-text ) |  | field-content = *( HTAB / SP / VCHAR / obs-text ) |
|  |  | obs-fold = CRLF ( SP / HTAB ) |
|  |  | ; obsolete line folding |
|  |  | ; see Section 3.2.2 |
| The field-name token labels the corresponding field-value as having |  | The field-name token labels the corresponding field-value as having |
| the semantics defined by that header field. For example, the Date |  | the semantics defined by that header field. For example, the Date |
| header field is defined in Section 9.2 of [Part2] as containing the |  | header field is defined in Section 10.2 of [Part2] as containing the |
| origination timestamp for the message in which it appears. |  | origination timestamp for the message in which it appears. |
| HTTP header fields are fully extensible: there is no limit on the |  | HTTP header fields are fully extensible: there is no limit on the |
| introduction of new field names, each presumably defining new |  | introduction of new field names, each presumably defining new |
| semantics, or on the number of header fields used in a given message. |  | semantics, or on the number of header fields used in a given message. |
| Existing fields are defined in each part of this specification and in |  | Existing fields are defined in each part of this specification and in |
| many other specifications outside the standards process. New header |  | many other specifications outside the standards process. New header |
| fields can be introduced without changing the protocol version if |  | fields can be introduced without changing the protocol version if |
| their defined semantics allow them to be safely ignored by recipients |  | their defined semantics allow them to be safely ignored by recipients |
| that do not recognize them. |  | that do not recognize them. |
| New HTTP header fields SHOULD be registered with IANA according to |  | New HTTP header fields SHOULD be registered with IANA according to |
| the procedures in Section 3.1 of [Part2]. Unrecognized header fields |  | the procedures in Section 3.1 of [Part2]. Unrecognized header fields |
| MUST be forwarded by a proxy unless the field-name is listed in the |  | MUST be forwarded by a proxy unless the field-name is listed in the |
| Connection header field (Section 8.1) or the proxy is specifically |  | Connection header field (Section 6.1) or the proxy is specifically |
| configured to block or otherwise transform such fields. Unrecognized |  | configured to block or otherwise transform such fields. Unrecognized |
| header fields SHOULD be ignored by other recipients. |  | header fields SHOULD be ignored by other recipients. |
| The order in which header fields with differing field names are |  | The order in which header fields with differing field names are |
| received is not significant. However, it is "good practice" to send |  | received is not significant. However, it is "good practice" to send |
| header fields that contain control data first, such as Host on |  | header fields that contain control data first, such as Host on |
| requests and Date on responses, so that implementations can decide |  | requests and Date on responses, so that implementations can decide |
| when not to handle a message as early as possible. A server MUST |  | when not to handle a message as early as possible. A server MUST |
| wait until the entire header section is received before interpreting |  | wait until the entire header section is received before interpreting |
| a request message, since later header fields might include |  | a request message, since later header fields might include |
| skipping to change at page 25, line 5 |  | skipping to change at page 23, line 12 |
| the same field name are received is therefore significant to the |  | the same field name are received is therefore significant to the |
| interpretation of the combined field value; a proxy MUST NOT change |  | interpretation of the combined field value; a proxy MUST NOT change |
| the order of these field values when forwarding a message. |  | the order of these field values when forwarding a message. |
| Note: The "Set-Cookie" header field as implemented in practice can |  | Note: The "Set-Cookie" header field as implemented in practice can |
| occur multiple times, but does not use the list syntax, and thus |  | occur multiple times, but does not use the list syntax, and thus |
| cannot be combined into a single line ([RFC6265]). (See Appendix |  | cannot be combined into a single line ([RFC6265]). (See Appendix |
| A.2.3 of [Kri2001] for details.) Also note that the Set-Cookie2 |  | A.2.3 of [Kri2001] for details.) Also note that the Set-Cookie2 |
| header field specified in [RFC2965] does not share this problem. |  | header field specified in [RFC2965] does not share this problem. |
| 3.2.1. Field Parsing |  | 3.2.1. Whitespace |
|  |  | This specification uses three rules to denote the use of linear |
|  |  | whitespace: OWS (optional whitespace), RWS (required whitespace), and |
|  |  | BWS ("bad" whitespace). |
|  |  | The OWS rule is used where zero or more linear whitespace octets |
|  |  | might appear. OWS SHOULD either not be produced or be produced as a |
|  |  | single SP. Multiple OWS octets that occur within field-content |
|  |  | SHOULD either be replaced with a single SP or transformed to all SP |
|  |  | octets (each octet other than SP replaced with SP) before |
|  |  | interpreting the field value or forwarding the message downstream. |
|  |  | RWS is used when at least one linear whitespace octet is required to |
|  |  | separate field tokens. RWS SHOULD be produced as a single SP. |
|  |  | Multiple RWS octets that occur within field-content SHOULD either be |
|  |  | replaced with a single SP or transformed to all SP octets before |
|  |  | interpreting the field value or forwarding the message downstream. |
|  |  | BWS is used where the grammar allows optional whitespace for |
|  |  | historical reasons but senders SHOULD NOT produce it in messages. |
|  |  | HTTP/1.1 recipients MUST accept such bad optional whitespace and |
|  |  | remove it before interpreting the field value or forwarding the |
|  |  | message downstream. |
|  |  | OWS = *( SP / HTAB ) |
|  |  | ; "optional" whitespace |
|  |  | RWS = 1*( SP / HTAB ) |
|  |  | ; "required" whitespace |
|  |  | BWS = OWS |
|  |  | ; "bad" whitespace |
|  |  | 3.2.2. Field Parsing |
| No whitespace is allowed between the header field-name and colon. In |  | No whitespace is allowed between the header field-name and colon. In |
| the past, differences in the handling of such whitespace have led to |  | the past, differences in the handling of such whitespace have led to |
| security vulnerabilities in request routing and response handling. |  | security vulnerabilities in request routing and response handling. |
| Any received request message that contains whitespace between a |  | Any received request message that contains whitespace between a |
| header field-name and colon MUST be rejected with a response code of |  | header field-name and colon MUST be rejected with a response code of |
| 400 (Bad Request). A proxy MUST remove any such whitespace from a |  | 400 (Bad Request). A proxy MUST remove any such whitespace from a |
| response message before forwarding the message downstream. |  | response message before forwarding the message downstream. |
| A field value MAY be preceded by optional whitespace (OWS); a single |  | A field value MAY be preceded by optional whitespace (OWS); a single |
| SP is preferred. The field value does not include any leading or |  | SP is preferred. The field value does not include any leading or |
| trailing white space: OWS occurring before the first non-whitespace |  | trailing white space: OWS occurring before the first non-whitespace |
| octet of the field value or after the last non-whitespace octet of |  | octet of the field value or after the last non-whitespace octet of |
| the field value is ignored and SHOULD be removed before further |  | the field value is ignored and SHOULD be removed before further |
| processing (as this does not change the meaning of the header field). |  | processing (as this does not change the meaning of the header field). |
| Historically, HTTP header field values could be extended over |  | Historically, HTTP header field values could be extended over |
| multiple lines by preceding each extra line with at least one space |  | multiple lines by preceding each extra line with at least one space |
| or horizontal tab (obs-fold). This specification deprecates such |  | or horizontal tab (obs-fold). This specification deprecates such |
| line folding except within the message/http media type |  | line folding except within the message/http media type |
| (Section 9.3.1). HTTP senders MUST NOT produce messages that include |  | (Section 7.3.1). HTTP senders MUST NOT produce messages that include |
| line folding (i.e., that contain any field-content that matches the |  | line folding (i.e., that contain any field-value that matches the |
| obs-fold rule) unless the message is intended for packaging within |  | obs-fold rule) unless the message is intended for packaging within |
| the message/http media type. HTTP recipients SHOULD accept line |  | the message/http media type. HTTP recipients SHOULD accept line |
| folding and replace any embedded obs-fold whitespace with either a |  | folding and replace any embedded obs-fold whitespace with either a |
| single SP or a matching number of SP octets (to avoid buffer copying) |  | single SP or a matching number of SP octets (to avoid buffer copying) |
| prior to interpreting the field value or forwarding the message |  | prior to interpreting the field value or forwarding the message |
| downstream. |  | downstream. |
| Historically, HTTP has allowed field content with text in the ISO- |  | Historically, HTTP has allowed field content with text in the ISO- |
| 8859-1 [ISO-8859-1] character encoding and supported other character |  | 8859-1 [ISO-8859-1] character encoding and supported other character |
| sets only through use of [RFC2047] encoding. In practice, most HTTP |  | sets only through use of [RFC2047] encoding. In practice, most HTTP |
| header field values use only a subset of the US-ASCII character |  | header field values use only a subset of the US-ASCII character |
| encoding [USASCII]. Newly defined header fields SHOULD limit their |  | encoding [USASCII]. Newly defined header fields SHOULD limit their |
| field values to US-ASCII octets. Recipients SHOULD treat other (obs- |  | field values to US-ASCII octets. Recipients SHOULD treat other (obs- |
| text) octets in field content as opaque data. |  | text) octets in field content as opaque data. |
| 3.2.2. Field Length |  | 3.2.3. Field Length |
| HTTP does not place a pre-defined limit on the length of header |  | HTTP does not place a pre-defined limit on the length of header |
| fields, either in isolation or as a set. A server MUST be prepared |  | fields, either in isolation or as a set. A server MUST be prepared |
| to receive request header fields of unbounded length and respond with |  | to receive request header fields of unbounded length and respond with |
| a 4xx status code if the received header field(s) would be longer |  | a 4xx status code if the received header field(s) would be longer |
| than the server wishes to handle. |  | than the server wishes to handle. |
| A client that receives response headers that are longer than it |  | A client that receives response headers that are longer than it |
| wishes to handle can only treat it as a server error. |  | wishes to handle can only treat it as a server error. |
| Various ad-hoc limitations on header length are found in practice. |  | Various ad-hoc limitations on header length are found in practice. |
| It is RECOMMENDED that all HTTP senders and recipients support |  | It is RECOMMENDED that all HTTP senders and recipients support |
| messages whose combined header fields have 4000 or more octets. |  | messages whose combined header fields have 4000 or more octets. |
| 3.2.3. Common Field ABNF Rules |  | 3.2.4. Field value components |
| Many HTTP/1.1 header field values consist of words (token or quoted- |  | Many HTTP/1.1 header field values consist of words (token or quoted- |
| string) separated by whitespace or special characters. These special |  | string) separated by whitespace or special characters. These special |
| characters MUST be in a quoted string to be used within a parameter |  | characters MUST be in a quoted string to be used within a parameter |
| value (as defined in Section 5.1). |  | value (as defined in Section 4). |
| word = token / quoted-string |  | word = token / quoted-string |
| token = 1*tchar |  | token = 1*tchar |
| tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" |  | tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" |
| / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" |  | / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" |
| / DIGIT / ALPHA |  | / DIGIT / ALPHA |
| ; any VCHAR, except special |  | ; any VCHAR, except special |
| skipping to change at page 27, line 9 |  | skipping to change at page 26, line 5 |
| Comments can be included in some HTTP header fields by surrounding |  | Comments can be included in some HTTP header fields by surrounding |
| the comment text with parentheses. Comments are only allowed in |  | the comment text with parentheses. Comments are only allowed in |
| fields containing "comment" as part of their field value definition. |  | fields containing "comment" as part of their field value definition. |
| comment = "(" *( ctext / quoted-cpair / comment ) ")" |  | comment = "(" *( ctext / quoted-cpair / comment ) ")" |
| ctext = OWS / %x21-27 / %x2A-5B / %x5D-7E / obs-text |  | ctext = OWS / %x21-27 / %x2A-5B / %x5D-7E / obs-text |
| The backslash octet ("\") can be used as a single-octet quoting |  | The backslash octet ("\") can be used as a single-octet quoting |
| mechanism within comment constructs: |  | mechanism within comment constructs: |
| quoted-cpair = "\" ( HTAB / SP / VCHAR / obs-text ) |  | quoted-cpair = "\" ( HTAB / SP / VCHAR / obs-text ) |
| Senders SHOULD NOT escape octets in comments that do not require |  | Senders SHOULD NOT escape octets in comments that do not require |
| escaping (i.e., other than the backslash octet "\" and the |  | escaping (i.e., other than the backslash octet "\" and the |
| parentheses "(" and ")"). |  | parentheses "(" and ")"). |
|  |  | 3.2.5. ABNF list extension: #rule |
|  |  | A #rule extension to the ABNF rules of [RFC5234] is used to improve |
|  |  | readability in the definitions of some header field values. |
|  |  | A construct "#" is defined, similar to "*", for defining comma- |
|  |  | delimited lists of elements. The full form is "<n>#<m>element" |
|  |  | indicating at least <n> and at most <m> elements, each separated by a |
|  |  | single comma (",") and optional whitespace (OWS). |
|  |  | Thus, |
|  |  | 1#element => element *( OWS "," OWS element ) |
|  |  | and: |
|  |  | #element => [ 1#element ] |
|  |  | and for n >= 1 and m > 1: |
|  |  | <n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element ) |
|  |  | For compatibility with legacy list rules, recipients SHOULD accept |
|  |  | empty list elements. In other words, consumers would follow the list |
|  |  | productions: |
|  |  | #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ] |
|  |  | 1#element => *( "," OWS ) element *( OWS "," [ OWS element ] ) |
|  |  | Note that empty elements do not contribute to the count of elements |
|  |  | present, though. |
|  |  | For example, given these ABNF productions: |
|  |  | example-list = 1#example-list-elmt |
|  |  | example-list-elmt = token ; see Section 3.2.4 |
|  |  | Then these are valid values for example-list (not including the |
|  |  | double quotes, which are present for delimitation only): |
|  |  | "foo,bar" |
|  |  | "foo ,bar," |
|  |  | "foo , ,bar,charlie " |
|  |  | But these values would be invalid, as at least one non-empty element |
|  |  | is required: |
|  |  | "" |
|  |  | "," |
|  |  | ", ," |
|  |  | Appendix B shows the collected ABNF, with the list rules expanded as |
|  |  | explained above. |
| 3.3. Message Body |  | 3.3. Message Body |
| The message-body (if any) of an HTTP message is used to carry the |  | The message body (if any) of an HTTP message is used to carry the |
| payload body associated with the request or response. |  | payload body of that request or response. The message body is |
|  |  | identical to the payload body unless a transfer coding has been |
|  |  | applied, as described in Section 3.3.1. |
| message-body = *OCTET |  | message-body = *OCTET |
| The message-body differs from the payload body only when a transfer- |  | The rules for when a message body is allowed in a message differ for |
| coding has been applied, as indicated by the Transfer-Encoding header |  | requests and responses. |
| field (Section 8.6). If more than one Transfer-Encoding header field |  |  |
| is present in a message, the multiple field-values MUST be combined |  |  |
| into one field-value, according to the algorithm defined in |  |  |
| Section 3.2, before determining the message-body length. |  |  |
| When one or more transfer-codings are applied to a payload in order |  | The presence of a message body in a request is signaled by a a |
| to form the message-body, the Transfer-Encoding header field MUST |  | Content-Length or Transfer-Encoding header field. Request message |
| contain the list of transfer-codings applied. Transfer-Encoding is a |  | framing is independent of method semantics, even if the method does |
| property of the message, not of the payload, and thus MAY be added or |  | not define any use for a message body. |
| removed by any implementation along the request/response chain under |  |  |
| the constraints found in Section 5.1. |  |  |
| If a message is received that has multiple Content-Length header |  | The presence of a message body in a response depends on both the |
| fields (Section 8.2) with field-values consisting of the same decimal |  | request method to which it is responding and the response status code |
| value, or a single Content-Length header field with a field value |  | (Paragraph 2). Responses to the HEAD request method never include a |
| containing a list of identical decimal values (e.g., "Content-Length: |  | message body because the associated response header fields (e.g., |
| 42, 42"), indicating that duplicate Content-Length header fields have |  | Transfer-Encoding, Content-Length, etc.) only indicate what their |
| been generated or combined by an upstream message processor, then the |  | values would have been if the request method had been GET. |
| recipient MUST either reject the message as invalid or replace the |  | Successful (2xx) responses to CONNECT switch to tunnel mode instead |
| duplicated field-values with a single valid Content-Length field |  | of having a message body. All 1xx (Informational), 204 (No Content), |
| containing that decimal value prior to determining the message-body |  | and 304 (Not Modified) responses MUST NOT include a message body. |
| length. |  | All other responses do include a message body, although the body MAY |
|  |  | be of zero length. |
| The rules for when a message-body is allowed in a message differ for |  | 3.3.1. Transfer-Encoding |
| requests and responses. |  |  |
| The presence of a message-body in a request is signaled by the |  | When one or more transfer codings are applied to a payload body in |
| inclusion of a Content-Length or Transfer-Encoding header field in |  | order to form the message body, a Transfer-Encoding header field MUST |
| the request's header fields, even if the request method does not |  | be sent in the message and MUST contain the list of corresponding |
| define any use for a message-body. This allows the request message |  | transfer-coding names in the same order that they were applied. |
| framing algorithm to be independent of method semantics. |  | Transfer codings are defined in Section 4. |
| For response messages, whether or not a message-body is included with |  | Transfer-Encoding = 1#transfer-coding |
| a message is dependent on both the request method and the response |  |  |
| status code (Section 3.1.2.1). Responses to the HEAD request method |  |  |
| never include a message-body because the associated response header |  |  |
| fields (e.g., Transfer-Encoding, Content-Length, etc.) only indicate |  |  |
| what their values would have been if the request method had been GET. |  |  |
| All 1xx (Informational), 204 (No Content), and 304 (Not Modified) |  |  |
| responses MUST NOT include a message-body. All other responses do |  |  |
| include a message-body, although the body MAY be of zero length. |  |  |
| The length of the message-body is determined by one of the following |  | Transfer-Encoding is analogous to the Content-Transfer-Encoding field |
|  |  | of MIME, which was designed to enable safe transport of binary data |
|  |  | over a 7-bit transport service ([RFC2045], Section 6). However, safe |
|  |  | transport has a different focus for an 8bit-clean transfer protocol. |
|  |  | In HTTP's case, Transfer-Encoding is primarily intended to accurately |
|  |  | delimit a dynamically generated payload and to distinguish payload |
|  |  | encodings that are only applied for transport efficiency or security |
|  |  | from those that are characteristics of the target resource. |
|  |  | The "chunked" transfer-coding (Section 4.1) MUST be implemented by |
|  |  | all HTTP/1.1 recipients because it plays a crucial role in delimiting |
|  |  | messages when the payload body size is not known in advance. When |
|  |  | the "chunked" transfer-coding is used, it MUST be the last transfer- |
|  |  | coding applied to form the message body and MUST NOT be applied more |
|  |  | than once in a message body. If any transfer-coding is applied to a |
|  |  | request payload body, the final transfer-coding applied MUST be |
|  |  | "chunked". If any transfer-coding is applied to a response payload |
|  |  | body, then either the final transfer-coding applied MUST be "chunked" |
|  |  | or the message MUST be terminated by closing the connection. |
|  |  | For example, |
|  |  | Transfer-Encoding: gzip, chunked |
|  |  | indicates that the payload body has been compressed using the gzip |
|  |  | coding and then chunked using the chunked coding while forming the |
|  |  | message body. |
|  |  | If more than one Transfer-Encoding header field is present in a |
|  |  | message, the multiple field-values MUST be combined into one field- |
|  |  | value, according to the algorithm defined in Section 3.2, before |
|  |  | determining the message body length. |
|  |  | Unlike Content-Encoding (Section 2.2 of [Part3]), Transfer-Encoding |
|  |  | is a property of the message, not of the payload, and thus MAY be |
|  |  | added or removed by any implementation along the request/response |
|  |  | chain. Additional information about the encoding parameters MAY be |
|  |  | provided by other header fields not defined by this specification. |
|  |  | Transfer-Encoding MAY be sent in a response to a HEAD request or in a |
|  |  | 304 response to a GET request, neither of which includes a message |
|  |  | body, to indicate that the origin server would have applied a |
|  |  | transfer coding to the message body if the request had been an |
|  |  | unconditional GET. This indication is not required, however, because |
|  |  | any recipient on the response chain (including the origin server) can |
|  |  | remove transfer codings when they are not needed. |
|  |  | Transfer-Encoding was added in HTTP/1.1. It is generally assumed |
|  |  | that implementations advertising only HTTP/1.0 support will not |
|  |  | understand how to process a transfer-encoded payload. A client MUST |
|  |  | NOT send a request containing Transfer-Encoding unless it knows the |
|  |  | server will handle HTTP/1.1 (or later) requests; such knowledge might |
|  |  | be in the form of specific user configuration or by remembering the |
|  |  | version of a prior received response. A server MUST NOT send a |
|  |  | response containing Transfer-Encoding unless the corresponding |
|  |  | request indicates HTTP/1.1 (or later). |
|  |  | A server that receives a request message with a transfer-coding it |
|  |  | does not understand SHOULD respond with 501 (Not Implemented) and |
|  |  | then close the connection. |
|  |  | 3.3.2. Content-Length |
|  |  | When a message does not have a Transfer-Encoding header field and the |
|  |  | payload body length can be determined prior to being transferred, a |
|  |  | Content-Length header field SHOULD be sent to indicate the length of |
|  |  | the payload body that is either present as the message body, for |
|  |  | requests and non-HEAD responses other than 304, or would have been |
|  |  | present had the request been an unconditional GET. The length is |
|  |  | expressed as a decimal number of octets. |
|  |  | Content-Length = 1*DIGIT |
|  |  | An example is |
|  |  | Content-Length: 3495 |
|  |  | In the case of a response to a HEAD request, Content-Length indicates |
|  |  | the size of the payload body (without any potential transfer-coding) |
|  |  | that would have been sent had the request been a GET. In the case of |
|  |  | a 304 (Not Modified) response to a GET request, Content-Length |
|  |  | indicates the size of the payload body (without any potential |
|  |  | transfer-coding) that would have been sent in a 200 (OK) response. |
|  |  | HTTP's use of Content-Length is significantly different from how it |
|  |  | is used in MIME, where it is an optional field used only within the |
|  |  | "message/external-body" media-type. |
|  |  | Any Content-Length field value greater than or equal to zero is |
|  |  | valid. Since there is no predefined limit to the length of an HTTP |
|  |  | payload, recipients SHOULD anticipate potentially large decimal |
|  |  | numerals and prevent parsing errors due to integer conversion |
|  |  | overflows (Section 8.6). |
|  |  | If a message is received that has multiple Content-Length header |
|  |  | fields (Section 3.3.2) with field-values consisting of the same |
|  |  | decimal value, or a single Content-Length header field with a field |
|  |  | value containing a list of identical decimal values (e.g., "Content- |
|  |  | Length: 42, 42"), indicating that duplicate Content-Length header |
|  |  | fields have been generated or combined by an upstream message |
|  |  | processor, then the recipient MUST either reject the message as |
|  |  | invalid or replace the duplicated field-values with a single valid |
|  |  | Content-Length field containing that decimal value prior to |
|  |  | determining the message body length. |
|  |  | 3.3.3. Message Body Length |
|  |  | The length of a message body is determined by one of the following |
| (in order of precedence): |  | (in order of precedence): |
| 1. Any response to a HEAD request and any response with a status |  | 1. Any response to a HEAD request and any response with a status |
| code of 100-199, 204, or 304 is always terminated by the first |  | code of 100-199, 204, or 304 is always terminated by the first |
| empty line after the header fields, regardless of the header |  | empty line after the header fields, regardless of the header |
| fields present in the message, and thus cannot contain a message- |  | fields present in the message, and thus cannot contain a message |
| body. |  | body. |
| 2. If a Transfer-Encoding header field is present and the "chunked" |  | 2. Any successful (2xx) response to a CONNECT request implies that |
| transfer-coding (Section 5.1) is the final encoding, the message- |  | the connection will become a tunnel immediately after the empty |
|  |  | line that concludes the header fields. A client MUST ignore any |
|  |  | Content-Length or Transfer-Encoding header fields received in |
|  |  | such a message. |
|  |  | 3. If a Transfer-Encoding header field is present and the "chunked" |
|  |  | transfer-coding (Section 4.1) is the final encoding, the message |
| body length is determined by reading and decoding the chunked |  | body length is determined by reading and decoding the chunked |
| data until the transfer-coding indicates the data is complete. |  | data until the transfer-coding indicates the data is complete. |
| If a Transfer-Encoding header field is present in a response and |  | If a Transfer-Encoding header field is present in a response and |
| the "chunked" transfer-coding is not the final encoding, the |  | the "chunked" transfer-coding is not the final encoding, the |
| message-body length is determined by reading the connection until |  | message body length is determined by reading the connection until |
| it is closed by the server. If a Transfer-Encoding header field |  | it is closed by the server. If a Transfer-Encoding header field |
| is present in a request and the "chunked" transfer-coding is not |  | is present in a request and the "chunked" transfer-coding is not |
| the final encoding, the message-body length cannot be determined |  | the final encoding, the message body length cannot be determined |
| reliably; the server MUST respond with the 400 (Bad Request) |  | reliably; the server MUST respond with the 400 (Bad Request) |
| status code and then close the connection. |  | status code and then close the connection. |
| If a message is received with both a Transfer-Encoding header |  | If a message is received with both a Transfer-Encoding header |
| field and a Content-Length header field, the Transfer-Encoding |  | field and a Content-Length header field, the Transfer-Encoding |
| overrides the Content-Length. Such a message might indicate an |  | overrides the Content-Length. Such a message might indicate an |
| attempt to perform request or response smuggling (bypass of |  | attempt to perform request or response smuggling (bypass of |
| security-related checks on message routing or content) and thus |  | security-related checks on message routing or content) and thus |
| ought to be handled as an error. The provided Content-Length |  | ought to be handled as an error. The provided Content-Length |
| MUST be removed, prior to forwarding the message downstream, or |  | MUST be removed, prior to forwarding the message downstream, or |
| replaced with the real message-body length after the transfer- |  | replaced with the real message body length after the transfer- |
| coding is decoded. |  | coding is decoded. |
| 3. If a message is received without Transfer-Encoding and with |  | 4. If a message is received without Transfer-Encoding and with |
| either multiple Content-Length header fields having differing |  | either multiple Content-Length header fields having differing |
| field-values or a single Content-Length header field having an |  | field-values or a single Content-Length header field having an |
| invalid value, then the message framing is invalid and MUST be |  | invalid value, then the message framing is invalid and MUST be |
| treated as an error to prevent request or response smuggling. If |  | treated as an error to prevent request or response smuggling. If |
| this is a request message, the server MUST respond with a 400 |  | this is a request message, the server MUST respond with a 400 |
| (Bad Request) status code and then close the connection. If this |  | (Bad Request) status code and then close the connection. If this |
| is a response message received by a proxy, the proxy MUST discard |  | is a response message received by a proxy, the proxy MUST discard |
| the received response, send a 502 (Bad Gateway) status code as |  | the received response, send a 502 (Bad Gateway) status code as |
| its downstream response, and then close the connection. If this |  | its downstream response, and then close the connection. If this |
| is a response message received by a user-agent, it MUST be |  | is a response message received by a user-agent, it MUST be |
| treated as an error by discarding the message and closing the |  | treated as an error by discarding the message and closing the |
| connection. |  | connection. |
| 4. If a valid Content-Length header field is present without |  | 5. If a valid Content-Length header field is present without |
| Transfer-Encoding, its decimal value defines the message-body |  | Transfer-Encoding, its decimal value defines the message body |
| length in octets. If the actual number of octets sent in the |  | length in octets. If the actual number of octets sent in the |
| message is less than the indicated Content-Length, the recipient |  | message is less than the indicated Content-Length, the recipient |
| MUST consider the message to be incomplete and treat the |  | MUST consider the message to be incomplete and treat the |
| connection as no longer usable. If the actual number of octets |  | connection as no longer usable. If the actual number of octets |
| sent in the message is more than the indicated Content-Length, |  | sent in the message is more than the indicated Content-Length, |
| the recipient MUST only process the message-body up to the field |  | the recipient MUST only process the message body up to the field |
| value's number of octets; the remainder of the message MUST |  | value's number of octets; the remainder of the message MUST |
| either be discarded or treated as the next message in a pipeline. |  | either be discarded or treated as the next message in a pipeline. |
| For the sake of robustness, a user-agent MAY attempt to detect |  | For the sake of robustness, a user-agent MAY attempt to detect |
| and correct such an error in message framing if it is parsing the |  | and correct such an error in message framing if it is parsing the |
| response to the last request on a connection and the connection |  | response to the last request on a connection and the connection |
| has been closed by the server. |  | has been closed by the server. |
| 5. 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). |
| 6. Otherwise, this is a response message without a declared message- |  | 7. Otherwise, this is a response message without a declared message |
| body length, so the message-body length is determined by the |  | body length, so the message body length is determined by the |
| number of octets received prior to the server closing the |  | number of octets received prior to the server closing the |
| connection. |  | connection. |
| Since there is no way to distinguish a successfully completed, close- |  | Since there is no way to distinguish a successfully completed, close- |
| delimited message from a partially-received message interrupted by |  | delimited message from a partially-received message interrupted by |
| network failure, implementations SHOULD use encoding or length- |  | network failure, implementations SHOULD use encoding or length- |
| delimited messages whenever possible. The close-delimiting feature |  | delimited messages whenever possible. The close-delimiting feature |
| exists primarily for backwards compatibility with HTTP/1.0. |  | exists primarily for backwards compatibility with HTTP/1.0. |
| A server MAY reject a request that contains a message-body but not a |  | A server MAY reject a request that contains a message body but not a |
| Content-Length by responding with 411 (Length Required). |  | Content-Length by responding with 411 (Length Required). |
| Unless a transfer-coding other than "chunked" has been applied, a |  | Unless a transfer-coding other than "chunked" has been applied, a |
| client that sends a request containing a message-body SHOULD use a |  | client that sends a request containing a message body SHOULD use a |
| valid Content-Length header field if the message-body length is known |  | valid Content-Length header field if the message body length is known |
| in advance, rather than the "chunked" encoding, since some existing |  | in advance, rather than the "chunked" encoding, since some existing |
| services respond to "chunked" with a 411 (Length Required) status |  | services respond to "chunked" with a 411 (Length Required) status |
| code even though they understand the chunked encoding. This is |  | code even though they understand the chunked encoding. This is |
| typically because such services are implemented via a gateway that |  | typically because such services are implemented via a gateway that |
| requires a content-length in advance of being called and the server |  | requires a content-length in advance of being called and the server |
| is unable or unwilling to buffer the entire request before |  | is unable or unwilling to buffer the entire request before |
| processing. |  | processing. |
| A client that sends a request containing a message-body MUST include |  | A client that sends a request containing a message body MUST include |
| a valid Content-Length header field if it does not know the server |  | a valid Content-Length header field if it does not know the server |
| will handle HTTP/1.1 (or later) requests; such knowledge can be in |  | will handle HTTP/1.1 (or later) requests; such knowledge can be in |
| the form of specific user configuration or by remembering the version |  | the form of specific user configuration or by remembering the version |
| of a prior received response. |  | of a prior received response. |
| 3.4. Handling Incomplete Messages |  | 3.4. Handling Incomplete Messages |
| Request messages that are prematurely terminated, possibly due to a |  | Request messages that are prematurely terminated, possibly due to a |
| cancelled connection or a server-imposed time-out exception, MUST |  | cancelled connection or a server-imposed time-out exception, MUST |
| result in closure of the connection; sending an HTTP/1.1 error |  | result in closure of the connection; sending an HTTP/1.1 error |
| response prior to closing the connection is OPTIONAL. |  | response prior to closing the connection is OPTIONAL. |
| Response messages that are prematurely terminated, usually by closure |  | Response messages that are prematurely terminated, usually by closure |
| of the connection prior to receiving the expected number of octets or |  | of the connection prior to receiving the expected number of octets or |
| by failure to decode a transfer-encoded message-body, MUST be |  | by failure to decode a transfer-encoded message body, MUST be |
| recorded as incomplete. A response that terminates in the middle of |  | recorded as incomplete. A response that terminates in the middle of |
| the header block (before the empty line is received) cannot be |  | the header block (before the empty line is received) cannot be |
| assumed to convey the full semantics of the response and MUST be |  | assumed to convey the full semantics of the response and MUST be |
| treated as an error. |  | treated as an error. |
| A message-body that uses the chunked transfer encoding is incomplete |  | A message body that uses the chunked transfer encoding is incomplete |
| if the zero-sized chunk that terminates the encoding has not been |  | if the zero-sized chunk that terminates the encoding has not been |
| received. A message that uses a valid Content-Length is incomplete |  | received. A message that uses a valid Content-Length is incomplete |
| if the size of the message-body received (in octets) is less than the |  | if the size of the message body received (in octets) is less than the |
| value given by Content-Length. A response that has neither chunked |  | value given by Content-Length. A response that has neither chunked |
| transfer encoding nor Content-Length is terminated by closure of the |  | transfer encoding nor Content-Length is terminated by closure of the |
| connection, and thus is considered complete regardless of the number |  | connection, and thus is considered complete regardless of the number |
| of message-body octets received, provided that the header block was |  | of message body octets received, provided that the header block was |
| received intact. |  | received intact. |
| A user agent MUST NOT render an incomplete response message-body as |  | A user agent MUST NOT render an incomplete response message body as |
| if it were complete (i.e., some indication must be given to the user |  | if it were complete (i.e., some indication must be given to the user |
| that an error occurred). Cache requirements for incomplete responses |  | that an error occurred). Cache requirements for incomplete responses |
| are defined in Section 2.1 of [Part6]. |  | are defined in Section 2.1 of [Part6]. |
| A server MUST read the entire request message-body or close the |  | A server MUST read the entire request message body or close the |
| connection after sending its response, since otherwise the remaining |  | connection after sending its response, since otherwise the remaining |
| data on a persistent connection would be misinterpreted as the next |  | data on a persistent connection would be misinterpreted as the next |
| request. Likewise, a client MUST read the entire response message- |  | request. Likewise, a client MUST read the entire response message |
| body if it intends to reuse the same connection for a subsequent |  | body if it intends to reuse the same connection for a subsequent |
| request. Pipelining multiple requests on a connection is described |  | request. Pipelining multiple requests on a connection is described |
| in Section 6.1.2.2. |  | in Section 6.3.2.2. |
| 3.5. Message Parsing Robustness |  | 3.5. Message Parsing Robustness |
| Older HTTP/1.0 client implementations might send an extra CRLF after |  | Older HTTP/1.0 client implementations might send an extra CRLF after |
| a POST request as a lame workaround for some early server |  | a POST request as a lame workaround for some early server |
| applications that failed to read message-body content that was not |  | applications that failed to read message body content that was not |
| terminated by a line-ending. An HTTP/1.1 client MUST NOT preface or |  | terminated by a line-ending. An HTTP/1.1 client MUST NOT preface or |
| follow a request with an extra CRLF. If terminating the request |  | follow a request with an extra CRLF. If terminating the request |
| message-body with a line-ending is desired, then the client MUST |  | message body with a line-ending is desired, then the client MUST |
| include the terminating CRLF octets as part of the message-body |  | include the terminating CRLF octets as part of the message body |
| length. |  | length. |
| In the interest of robustness, servers SHOULD ignore at least one |  | In the interest of robustness, servers SHOULD ignore at least one |
| empty line received where a Request-Line is expected. In other |  | empty line received where a request-line is expected. In other |
| words, if the server is reading the protocol stream at the beginning |  | words, if the server is reading the protocol stream at the beginning |
| of a message and receives a CRLF first, it SHOULD ignore the CRLF. |  | of a message and receives a CRLF first, it SHOULD ignore the CRLF. |
| Likewise, although the line terminator for the start-line and header |  | Likewise, although the line terminator for the start-line and header |
| fields is the sequence CRLF, we recommend that recipients recognize a |  | fields is the sequence CRLF, we recommend that recipients recognize a |
| single LF as a line terminator and ignore any CR. |  | single LF as a line terminator and ignore any CR. |
| When a server listening only for HTTP request messages, or processing |  | When a server listening only for HTTP request messages, or processing |
| what appears from the start-line to be an HTTP request message, |  | what appears from the start-line to be an HTTP request message, |
| receives a sequence of octets that does not match the HTTP-message |  | receives a sequence of octets that does not match the HTTP-message |
| grammar aside from the robustness exceptions listed above, the server |  | grammar aside from the robustness exceptions listed above, the server |
| MUST respond with an HTTP/1.1 400 (Bad Request) response. |  | MUST respond with an HTTP/1.1 400 (Bad Request) response. |
| 4. Message Routing |  | 4. Transfer Codings |
| In most cases, the user agent is provided a URI reference from which |  |  |
| it determines an absolute URI for identifying the target resource. |  |  |
| When a request to the resource is initiated, all or part of that URI |  |  |
| is used to construct the HTTP request-target. |  |  |
| 4.1. Types of Request Target |  |  |
| The four options for request-target are dependent on the nature of |  |  |
| the request. |  |  |
| The asterisk "*" form of request-target, which MUST NOT be used with |  |  |
| any request method other than OPTIONS, means that the request applies |  |  |
| to the server as a whole (the listening process) rather than to a |  |  |
| specific named resource at that server. For example, |  |  |
| OPTIONS * HTTP/1.1 |  |  |
| The "absolute-URI" form is REQUIRED when the request is being made to |  |  |
| a proxy. The proxy is requested to either forward the request or |  |  |
| service it from a valid cache, and then return the response. Note |  |  |
| that the proxy MAY forward the request on to another proxy or |  |  |
| directly to the server specified by the absolute-URI. In order to |  |  |
| avoid request loops, a proxy that forwards requests to other proxies |  |  |
| MUST be able to recognize and exclude all of its own server names, |  |  |
| including any aliases, local variations, and the numeric IP address. |  |  |
| An example Request-Line would be: |  |  |
| GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1 |  |  |
| To allow for transition to absolute-URIs in all requests in future |  |  |
| versions of HTTP, all HTTP/1.1 servers MUST accept the absolute-URI |  |  |
| form in requests, even though HTTP/1.1 clients will only generate |  |  |
| them in requests to proxies. |  |  |
| If a proxy receives a host name that is not a fully qualified domain |  |  |
| name, it MAY add its domain to the host name it received. If a proxy |  |  |
| receives a fully qualified domain name, the proxy MUST NOT change the |  |  |
| host name. |  |  |
| The "authority form" is only used by the CONNECT request method |  |  |
| (Section 6.9 of [Part2]). |  |  |
| The most common form of request-target is that used when making a |  |  |
| request to an origin server ("origin form"). In this case, the |  |  |
| absolute path and query components of the URI MUST be transmitted as |  |  |
| the request-target, and the authority component MUST be transmitted |  |  |
| in a Host header field. For example, a client wishing to retrieve a |  |  |
| representation of the resource, as identified above, directly from |  |  |
| the origin server would open (or reuse) a TCP connection to port 80 |  |  |
| of the host "www.example.org" and send the lines: |  |  |
| GET /pub/WWW/TheProject.html HTTP/1.1 |  |  |
| Host: www.example.org |  |  |
| followed by the remainder of the Request. Note that the origin form |  |  |
| of request-target always starts with an absolute path; if the target |  |  |
| resource's URI path is empty, then an absolute path of "/" MUST be |  |  |
| provided in the request-target. |  |  |
| If a proxy receives an OPTIONS request with an absolute-URI form of |  |  |
| request-target in which the URI has an empty path and no query |  |  |
| component, then the last proxy on the request chain MUST use a |  |  |
| request-target of "*" when it forwards the request to the indicated |  |  |
| origin server. |  |  |
| For example, the request |  |  |
| OPTIONS http://www.example.org:8001 HTTP/1.1 |  |  |
| would be forwarded by the final proxy as |  |  |
| OPTIONS * HTTP/1.1 |  |  |
| Host: www.example.org:8001 |  |  |
| after connecting to port 8001 of host "www.example.org". |  |  |
| The request-target is transmitted in the format specified in |  |  |
| Section 2.7.1. If the request-target is percent-encoded ([RFC3986], |  |  |
| Section 2.1), the origin server MUST decode the request-target in |  |  |
| order to properly interpret the request. Servers SHOULD respond to |  |  |
| invalid request-targets with an appropriate status code. |  |  |
| A non-transforming proxy MUST NOT rewrite the "path-absolute" and |  |  |
| "query" parts of the received request-target when forwarding it to |  |  |
| the next inbound server, except as noted above to replace a null |  |  |
| path-absolute with "/" or "*". |  |  |
| Note: The "no rewrite" rule prevents the proxy from changing the |  |  |
| meaning of the request when the origin server is improperly using |  |  |
| a non-reserved URI character for a reserved purpose. Implementors |  |  |
| need to be aware that some pre-HTTP/1.1 proxies have been known to |  |  |
| rewrite the request-target. |  |  |
| 4.2. The Resource Identified by a Request |  |  |
| The exact resource identified by an Internet request is determined by |  |  |
| examining both the request-target and the Host header field. |  |  |
| An origin server that does not allow resources to differ by the |  |  |
| requested host MAY ignore the Host header field value when |  |  |
| determining the resource identified by an HTTP/1.1 request. (But see |  |  |
| Appendix A.1.1 for other requirements on Host support in HTTP/1.1.) |  |  |
| An origin server that does differentiate resources based on the host |  |  |
| requested (sometimes referred to as virtual hosts or vanity host |  |  |
| names) MUST use the following rules for determining the requested |  |  |
| resource on an HTTP/1.1 request: |  |  |
| 1. If request-target is an absolute-URI, the host is part of the |  |  |
| request-target. Any Host header field value in the request MUST |  |  |
| be ignored. |  |  |
| 2. If the request-target is not an absolute-URI, and the request |  |  |
| includes a Host header field, the host is determined by the Host |  |  |
| header field value. |  |  |
| 3. If the host as determined by rule 1 or 2 is not a valid host on |  |  |
| the server, the response MUST be a 400 (Bad Request) error |  |  |
| message. |  |  |
| 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 determine what |  |  |
| exact resource is being requested. |  |  |
| 4.3. Effective Request URI |  |  |
| HTTP requests often do not carry the absolute URI ([RFC3986], Section |  |  |
| 4.3) for the target resource; instead, the URI needs to be inferred |  |  |
| from the request-target, Host header field, and connection context. |  |  |
| The result of this process is called the "effective request URI". |  |  |
| The "target resource" is the resource identified by the effective |  |  |
| request URI. |  |  |
| If the request-target is an absolute-URI, then the effective request |  |  |
| URI is the request-target. |  |  |
| If the request-target uses the origin form or the asterisk form, and |  |  |
| the Host header field is present, then the effective request URI is |  |  |
| constructed by concatenating |  |  |
| o the scheme name: "http" if the request was received over an |  |  |
| insecure TCP connection, or "https" when received over a SSL/ |  |  |
| TLS-secured TCP connection, |  |  |
| o the octet sequence "://", |  |  |
| o the authority component, as specified in the Host header field |  |  |
| (Section 8.3), and |  |  |
| o the request-target obtained from the Request-Line, unless the |  |  |
| request-target is just the asterisk "*". |  |  |
| If the request-target uses the origin form or the asterisk form, and |  |  |
| the Host header field is not present, then the effective request URI |  |  |
| is undefined. |  |  |
| Otherwise, when request-target uses the authority form, the effective |  |  |
| request URI is undefined. |  |  |
| Example 1: the effective request URI for the message |  |  |
| GET /pub/WWW/TheProject.html HTTP/1.1 |  |  |
| Host: www.example.org:8080 |  |  |
| (received over an insecure TCP connection) is "http", plus "://", |  |  |
| plus the authority component "www.example.org:8080", plus the |  |  |
| request-target "/pub/WWW/TheProject.html", thus |  |  |
| "http://www.example.org:8080/pub/WWW/TheProject.html". |  |  |
| Example 2: the effective request URI for the message |  |  |
| OPTIONS * HTTP/1.1 |  |  |
| Host: www.example.org |  |  |
| (received over an SSL/TLS secured TCP connection) is "https", plus |  |  |
| "://", plus the authority component "www.example.org", thus |  |  |
| "https://www.example.org". |  |  |
| Effective request URIs are compared using the rules described in |  |  |
| Section 2.7.3, except that empty path components MUST NOT be treated |  |  |
| as equivalent to an absolute path of "/". |  |  |
| 5. Protocol Parameters |  |  |
| 5.1. Transfer Codings |  |  |
| Transfer-coding values are used to indicate an encoding |  | Transfer-coding values are used to indicate an encoding |
| transformation that has been, can be, or might need to be applied to |  | transformation that has been, can be, or might need to be applied to |
| a payload body in order to ensure "safe transport" through the |  | a payload body in order to ensure "safe transport" through the |
| network. This differs from a content coding in that the transfer- |  | network. This differs from a content coding in that the transfer- |
| coding is a property of the message rather than a property of the |  | coding is a property of the message rather than a property of the |
| representation that is being transferred. |  | representation that is being transferred. |
| transfer-coding = "chunked" ; Section 5.1.1 |  | transfer-coding = "chunked" ; Section 4.1 |
| / "compress" ; Section 5.1.2.1 |  | / "compress" ; Section 4.2.1 |
| / "deflate" ; Section 5.1.2.2 |  | / "deflate" ; Section 4.2.2 |
| / "gzip" ; Section 5.1.2.3 |  | / "gzip" ; Section 4.2.3 |
| / transfer-extension |  | / transfer-extension |
| transfer-extension = token *( OWS ";" OWS transfer-parameter ) |  | transfer-extension = token *( OWS ";" OWS transfer-parameter ) |
| Parameters are in the form of attribute/value pairs. |  | Parameters are in the form of attribute/value pairs. |
| transfer-parameter = attribute BWS "=" BWS value |  | transfer-parameter = attribute BWS "=" BWS value |
| attribute = token |  | attribute = token |
| value = word |  | value = word |
| All transfer-coding values are case-insensitive. HTTP/1.1 uses |  |  |
| transfer-coding values in the TE header field (Section 8.4) and in |  |  |
| the Transfer-Encoding header field (Section 8.6). |  |  |
| Transfer-codings are analogous to the Content-Transfer-Encoding |  |  |
| values of MIME, which were designed to enable safe transport of |  |  |
| binary data over a 7-bit transport service ([RFC2045], Section 6). |  |  |
| However, safe transport has a different focus for an 8bit-clean |  |  |
| transfer protocol. In HTTP, the only unsafe characteristic of |  |  |
| message-bodies is the difficulty in determining the exact message |  |  |
| body length (Section 3.3), or the desire to encrypt data over a |  |  |
| shared transport. |  |  |
| A server that receives a request message with a transfer-coding it |  | All transfer-coding values are case-insensitive. The HTTP Transfer |
| does not understand SHOULD respond with 501 (Not Implemented) and |  | Coding registry is defined in Section 7.4. HTTP/1.1 uses transfer- |
| then close the connection. A server MUST NOT send transfer-codings |  | coding values in the TE header field (Section 4.3) and in the |
| to an HTTP/1.0 client. |  | Transfer-Encoding header field (Section 3.3.1). |
| 5.1.1. Chunked Transfer Coding |  | 4.1. Chunked Transfer Coding |
| The chunked encoding modifies the body of a message in order to |  | The chunked encoding modifies the body of a message 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, |
| followed by an OPTIONAL trailer containing header fields. This |  | followed by an OPTIONAL trailer containing header fields. This |
| allows dynamically produced content to be transferred along with the |  | allows dynamically produced content to be transferred along with the |
| information necessary for the recipient to verify that it has |  | information necessary for the recipient to verify that it has |
| received the full message. |  | received the full message. |
| Chunked-Body = *chunk |  | chunked-body = *chunk |
| last-chunk |  | last-chunk |
| trailer-part |  | trailer-part |
| CRLF |  | CRLF |
| chunk = chunk-size [ chunk-ext ] CRLF |  | chunk = chunk-size [ chunk-ext ] CRLF |
| chunk-data CRLF |  | chunk-data CRLF |
| chunk-size = 1*HEXDIG |  | chunk-size = 1*HEXDIG |
| last-chunk = 1*("0") [ chunk-ext ] CRLF |  | last-chunk = 1*("0") [ chunk-ext ] CRLF |
| chunk-ext = *( ";" chunk-ext-name |  | chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-val ] ) |
| [ "=" chunk-ext-val ] ) |  |  |
| chunk-ext-name = token |  | chunk-ext-name = token |
| chunk-ext-val = token / quoted-str-nf |  | chunk-ext-val = token / quoted-str-nf |
| chunk-data = 1*OCTET ; a sequence of chunk-size octets |  | chunk-data = 1*OCTET ; a sequence of chunk-size octets |
| trailer-part = *( header-field CRLF ) |  | trailer-part = *( header-field CRLF ) |
| quoted-str-nf = DQUOTE *( qdtext-nf / quoted-pair ) DQUOTE |  | quoted-str-nf = DQUOTE *( qdtext-nf / quoted-pair ) DQUOTE |
| ; like quoted-string, but disallowing line folding |  | ; like quoted-string, but disallowing line folding |
| qdtext-nf = HTAB / SP / %x21 / %x23-5B / %x5D-7E / obs-text |  | qdtext-nf = HTAB / SP / %x21 / %x23-5B / %x5D-7E / obs-text |
| The chunk-size field is a string of hex digits indicating the size of |  | The chunk-size field is a string of hex digits indicating the size of |
| the chunk-data in octets. The chunked encoding is ended by any chunk |  | the chunk-data in octets. The chunked encoding is ended by any chunk |
| whose size is zero, followed by the trailer, which is terminated by |  | whose size is zero, followed by the trailer, which is terminated by |
| an empty line. |  | an empty line. |
| The trailer allows the sender to include additional HTTP header |  | The trailer allows the sender to include additional HTTP header |
| fields at the end of the message. The Trailer header field can be |  | fields at the end of the message. The Trailer header field can be |
| used to indicate which header fields are included in a trailer (see |  | used to indicate which header fields are included in a trailer (see |
| Section 8.5). |  | Section 4.4). |
| A server using chunked transfer-coding in a response MUST NOT use the |  | A server using chunked transfer-coding in a response MUST NOT use the |
| trailer for any header fields unless at least one of the following is |  | trailer for any header fields unless at least one of the following is |
| true: |  | true: |
| 1. the request included a TE header field that indicates "trailers" |  | 1. the request included a TE header field that indicates "trailers" |
| is acceptable in the transfer-coding of the response, as |  | is acceptable in the transfer-coding of the response, as |
| described in Section 8.4; or, |  | described in Section 4.3; or, |
| 2. the trailer fields consist entirely of optional metadata, and the |  | 2. the trailer fields consist entirely of optional metadata, and the |
| recipient could use the message (in a manner acceptable to the |  | recipient could use the message (in a manner acceptable to the |
| server where the field originated) without receiving it. In |  | server where the field originated) without receiving it. In |
| other words, the server that generated the header (often but not |  | other words, the server that generated the header (often but not |
| always the origin server) is willing to accept the possibility |  | always the origin server) is willing to accept the possibility |
| that the trailer fields might be silently discarded along the |  | that the trailer fields might be silently discarded along the |
| path to the client. |  | path to the client. |
| This requirement prevents an interoperability failure when the |  | This requirement prevents an interoperability failure when the |
| message is being received by an HTTP/1.1 (or later) proxy and |  | message is being received by an HTTP/1.1 (or later) proxy and |
| forwarded to an HTTP/1.0 recipient. It avoids a situation where |  | forwarded to an HTTP/1.0 recipient. It avoids a situation where |
| compliance with the protocol would have necessitated a possibly |  | conformance with the protocol would have necessitated a possibly |
| infinite buffer on the proxy. |  | infinite buffer on the proxy. |
| A process for decoding the "chunked" transfer-coding can be |  | A process for decoding the "chunked" transfer-coding can be |
| represented in pseudo-code as: |  | represented in pseudo-code as: |
| 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 |
| skipping to change at page 38, line 10 |  | skipping to change at page 36, line 10 |
| append header-field to existing header fields |  | append header-field to existing header fields |
| read header-field |  | read header-field |
| } |  | } |
| Content-Length := length |  | Content-Length := length |
| Remove "chunked" from Transfer-Encoding |  | Remove "chunked" from Transfer-Encoding |
| All HTTP/1.1 applications MUST be able to receive and decode the |  | All HTTP/1.1 applications MUST be able to receive and decode the |
| "chunked" transfer-coding and MUST ignore chunk-ext extensions they |  | "chunked" transfer-coding and MUST ignore chunk-ext extensions they |
| do not understand. |  | do not understand. |
| Since "chunked" is the only transfer-coding required to be understood |  | Use of chunk-ext extensions by senders is deprecated; they SHOULD NOT |
| by HTTP/1.1 recipients, it plays a crucial role in delimiting |  | be sent and definition of new chunk-extensions is discouraged. |
| messages on a persistent connection. Whenever a transfer-coding is |  |  |
| applied to a payload body in a request, the final transfer-coding |  |  |
| applied MUST be "chunked". If a transfer-coding is applied to a |  |  |
| response payload body, then either the final transfer-coding applied |  |  |
| MUST be "chunked" or the message MUST be terminated by closing the |  |  |
| connection. When the "chunked" transfer-coding is used, it MUST be |  |  |
| the last transfer-coding applied to form the message-body. The |  |  |
| "chunked" transfer-coding MUST NOT be applied more than once in a |  |  |
| message-body. |  |  |
| 5.1.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. |
| Note: Use of program names for the identification of encoding |  | Note: Use of program names for the identification of encoding |
| formats is not desirable and is discouraged for future encodings. |  | formats is not desirable and is discouraged for future encodings. |
| Their use here is representative of historical practice, not good |  | Their use here is representative of historical practice, not good |
| design. |  | design. |
| Note: For compatibility with previous implementations of HTTP, |  | Note: For compatibility with previous implementations of HTTP, |
| applications SHOULD consider "x-gzip" and "x-compress" to be |  | applications SHOULD consider "x-gzip" and "x-compress" to be |
| equivalent to "gzip" and "compress" respectively. |  | equivalent to "gzip" and "compress" respectively. |
| 5.1.2.1. Compress Coding |  | 4.2.1. Compress Coding |
| The "compress" format is produced by the common UNIX file compression |  | The "compress" format is produced by the common UNIX file compression |
| program "compress". This format is an adaptive Lempel-Ziv-Welch |  | program "compress". This format is an adaptive Lempel-Ziv-Welch |
| coding (LZW). |  | coding (LZW). |
| 5.1.2.2. Deflate Coding |  | 4.2.2. Deflate Coding |
| The "deflate" format is defined as the "deflate" compression |  | The "deflate" format is defined as the "deflate" compression |
| mechanism (described in [RFC1951]) used inside the "zlib" data format |  | mechanism (described in [RFC1951]) used inside the "zlib" data format |
| ([RFC1950]). |  | ([RFC1950]). |
| Note: Some incorrect implementations send the "deflate" compressed |  | Note: Some incorrect implementations send the "deflate" compressed |
| data without the zlib wrapper. |  | data without the zlib wrapper. |
| 5.1.2.3. Gzip Coding |  | 4.2.3. Gzip Coding |
| The "gzip" format is produced by the file compression program "gzip" |  | The "gzip" format is produced by the file compression program "gzip" |
| (GNU zip), as described in [RFC1952]. This format is a Lempel-Ziv |  | (GNU zip), as described in [RFC1952]. This format is a Lempel-Ziv |
| coding (LZ77) with a 32 bit CRC. |  | coding (LZ77) with a 32 bit CRC. |
| 5.1.3. Transfer Coding Registry |  | 4.3. TE |
| The HTTP Transfer Coding Registry defines the name space for the |  |  |
| transfer coding names. |  |  |
| Registrations MUST include the following fields: |  | The "TE" header field indicates what extension transfer-codings the |
|  |  | client is willing to accept in the response, and whether or not it is |
|  |  | willing to accept trailer fields in a chunked transfer-coding. |
| o Name |  | Its value consists of the keyword "trailers" and/or a comma-separated |
|  |  | list of extension transfer-coding names with optional accept |
|  |  | parameters (as described in Section 4). |
| o Description |  | TE = #t-codings |
|  |  | t-codings = "trailers" / ( transfer-extension [ te-params ] ) |
|  |  | te-params = OWS ";" OWS "q=" qvalue *( te-ext ) |
|  |  | te-ext = OWS ";" OWS token [ "=" word ] |
| o Pointer to specification text |  | The presence of the keyword "trailers" indicates that the client is |
|  |  | willing to accept trailer fields in a chunked transfer-coding, as |
|  |  | defined in Section 4.1. This keyword is reserved for use with |
|  |  | transfer-coding values even though it does not itself represent a |
|  |  | transfer-coding. |
| Names of transfer codings MUST NOT overlap with names of content |  | Examples of its use are: |
| codings (Section 2.2 of [Part3]), unless the encoding transformation |  |  |
| is identical (as it is the case for the compression codings defined |  |  |
| in Section 5.1.2). |  |  |
| Values to be added to this name space require a specification (see |  | TE: deflate |
| "Specification Required" in Section 4.1 of [RFC5226]), and MUST |  | TE: |
| conform to the purpose of transfer coding defined in this section. |  | TE: trailers, deflate;q=0.5 |
| The registry itself is maintained at |  | The TE header field only applies to the immediate connection. |
| <http://www.iana.org/assignments/http-parameters>. |  | Therefore, the keyword MUST be supplied within a Connection header |
|  |  | field (Section 6.1) whenever TE is present in an HTTP/1.1 message. |
| 5.2. Product Tokens |  | A server tests whether a transfer-coding is acceptable, according to |
|  |  | a TE field, using these rules: |
| Product tokens are used to allow communicating applications to |  | 1. The "chunked" transfer-coding is always acceptable. If the |
| identify themselves by software name and version. Most fields using |  | keyword "trailers" is listed, the client indicates that it is |
| product tokens also allow sub-products which form a significant part |  | willing to accept trailer fields in the chunked response on |
| of the application to be listed, separated by whitespace. By |  | behalf of itself and any downstream clients. The implication is |
| convention, the products are listed in order of their significance |  | that, if given, the client is stating that either all downstream |
| for identifying the application. |  | clients are willing to accept trailer fields in the forwarded |
|  |  | response, or that it will attempt to buffer the response on |
|  |  | behalf of downstream recipients. |
| product = token ["/" product-version] |  | Note: HTTP/1.1 does not define any means to limit the size of a |
| product-version = token |  | chunked response such that a client can be assured of buffering |
|  |  | the entire response. |
| Examples: |  | 2. If the transfer-coding being tested is one of the transfer- |
|  |  | codings listed in the TE field, then it is acceptable unless it |
|  |  | is accompanied by a qvalue of 0. (As defined in Section 4.3.1, a |
|  |  | qvalue of 0 means "not acceptable".) |
| User-Agent: CERN-LineMode/2.15 libwww/2.17b3 |  | 3. If multiple transfer-codings are acceptable, then the acceptable |
| Server: Apache/0.8.4 |  | transfer-coding with the highest non-zero qvalue is preferred. |
|  |  | The "chunked" transfer-coding always has a qvalue of 1. |
| Product tokens SHOULD be short and to the point. They MUST NOT be |  | If the TE field-value is empty or if no TE field is present, the only |
| used for advertising or other non-essential information. Although |  | acceptable transfer-coding is "chunked". A message with no transfer- |
| any token octet MAY appear in a product-version, this token SHOULD |  | coding is always acceptable. |
| only be used for a version identifier (i.e., successive versions of |  |  |
| the same product SHOULD only differ in the product-version portion of |  |  |
| the product value). |  |  |
| 5.3. Quality Values |  | 4.3.1. Quality Values |
| Both transfer codings (TE request header field, Section 8.4) and |  | Both transfer codings (TE request header field, Section 4.3) and |
| content negotiation (Section 5 of [Part3]) use short "floating point" |  | content negotiation (Section 5 of [Part3]) use short "floating point" |
| numbers to indicate the relative importance ("weight") of various |  | numbers to indicate the relative importance ("weight") of various |
| negotiable parameters. A weight is normalized to a real number in |  | negotiable parameters. A weight is normalized to a real number in |
| the range 0 through 1, where 0 is the minimum and 1 the maximum |  | the range 0 through 1, where 0 is the minimum and 1 the maximum |
| value. If a parameter has a quality value of 0, then content with |  | value. If a parameter has a quality value of 0, then content with |
| this parameter is "not acceptable" for the client. HTTP/1.1 |  | this parameter is "not acceptable" for the client. HTTP/1.1 |
| applications MUST NOT generate more than three digits after the |  | applications MUST NOT generate more than three digits after the |
| decimal point. User configuration of these values SHOULD also be |  | decimal point. User configuration of these values SHOULD also be |
| limited in this fashion. |  | limited in this fashion. |
| qvalue = ( "0" [ "." 0*3DIGIT ] ) |  | qvalue = ( "0" [ "." 0*3DIGIT ] ) |
| / ( "1" [ "." 0*3("0") ] ) |  | / ( "1" [ "." 0*3("0") ] ) |
| Note: "Quality values" is a misnomer, since these values merely |  | Note: "Quality values" is a misnomer, since these values merely |
| represent relative degradation in desired quality. |  | represent relative degradation in desired quality. |
| 6. Connections |  | 4.4. Trailer |
| 6.1. Persistent Connections |  | The "Trailer" header field indicates that the given set of header |
|  |  | fields is present in the trailer of a message encoded with chunked |
|  |  | transfer-coding. |
| 6.1.1. Purpose |  | Trailer = 1#field-name |
| Prior to persistent connections, a separate TCP connection was |  | An HTTP/1.1 message SHOULD include a Trailer header field in a |
| established for each request, increasing the load on HTTP servers and |  | message using chunked transfer-coding with a non-empty trailer. |
| causing congestion on the Internet. The use of inline images and |  | Doing so allows the recipient to know which header fields to expect |
| other associated data often requires a client to make multiple |  | in the trailer. |
| requests of the same server in a short amount of time. Analysis of |  |  |
| these performance problems and results from a prototype |  |  |
| implementation are available [Pad1995] [Spe]. Implementation |  |  |
| experience and measurements of actual HTTP/1.1 implementations show |  |  |
| good results [Nie1997]. Alternatives have also been explored, for |  |  |
| example, T/TCP [Tou1998]. |  |  |
| Persistent HTTP connections have a number of advantages: |  | If no Trailer header field is present, the trailer SHOULD NOT include |
|  |  | any header fields. See Section 4.1 for restrictions on the use of |
|  |  | trailer fields in a "chunked" transfer-coding. |
| o By opening and closing fewer TCP connections, CPU time is saved in |  | Message header fields listed in the Trailer header field MUST NOT |
| routers and hosts (clients, servers, proxies, gateways, tunnels, |  | include the following header fields: |
| or caches), and memory used for TCP protocol control blocks can be |  |  |
| saved in hosts. |  |  |
| o HTTP requests and responses can be pipelined on a connection. |  | o Transfer-Encoding |
| Pipelining allows a client to make multiple requests without |  |  |
| waiting for each response, allowing a single TCP connection to be |  |  |
| used much more efficiently, with much lower elapsed time. |  |  |
| o Network congestion is reduced by reducing the number of packets |  | o Content-Length |
| caused by TCP opens, and by allowing TCP sufficient time to |  |  |
| determine the congestion state of the network. |  |  |
| o Latency on subsequent requests is reduced since there is no time |  | o Trailer |
| spent in TCP's connection opening handshake. |  |  |
| o HTTP can evolve more gracefully, since errors can be reported |  | 5. Message Routing |
| without the penalty of closing the TCP connection. Clients using |  |  |
| future versions of HTTP might optimistically try a new feature, |  |  |
| but if communicating with an older server, retry with old |  |  |
| semantics after an error is reported. |  |  |
| HTTP implementations SHOULD implement persistent connections. |  | HTTP request message routing is determined by each client based on |
|  |  | the target resource, the client's proxy configuration, and |
|  |  | establishment or reuse of an inbound connection. The corresponding |
|  |  | response routing follows the same connection chain back to the |
|  |  | client. |
| 6.1.2. Overall Operation |  | 5.1. Identifying a Target Resource |
| A significant difference between HTTP/1.1 and earlier versions of |  | HTTP is used in a wide variety of applications, ranging from general- |
| HTTP is that persistent connections are the default behavior of any |  | purpose computers to home appliances. In some cases, communication |
| HTTP connection. That is, unless otherwise indicated, the client |  | options are hard-coded in a client's configuration. However, most |
| SHOULD assume that the server will maintain a persistent connection, |  | HTTP clients rely on the same resource identification mechanism and |
| even after error responses from the server. |  | configuration techniques as general-purpose Web browsers. |
| Persistent connections provide a mechanism by which a client and a |  | HTTP communication is initiated by a user agent for some purpose. |
| server can signal the close of a TCP connection. This signaling |  | The purpose is a combination of request semantics, which are defined |
| takes place using the Connection header field (Section 8.1). Once a |  | in [Part2], and a target resource upon which to apply those |
| close has been signaled, the client MUST NOT send any more requests |  | semantics. A URI reference (Section 2.7) is typically used as an |
| on that connection. |  | identifier for the "target resource", which a user agent would |
|  |  | resolve to its absolute form in order to obtain the "target URI". |
|  |  | The target URI excludes the reference's fragment identifier |
|  |  | component, if any, since fragment identifiers are reserved for |
|  |  | client-side processing ([RFC3986], Section 3.5). |
| 6.1.2.1. Negotiation |  | HTTP intermediaries obtain the request semantics and target URI from |
|  |  | the request-line of an incoming request message. |
| An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to |  | 5.2. Connecting Inbound |
| maintain a persistent connection unless a Connection header field |  |  |
| including the connection-token "close" was sent in the request. If |  |  |
| the server chooses to close the connection immediately after sending |  |  |
| the response, it SHOULD send a Connection header field including the |  |  |
| connection-token "close". |  |  |
| An HTTP/1.1 client MAY expect a connection to remain open, but would |  | Once the target URI is determined, a client needs to decide whether a |
| decide to keep it open based on whether the response from a server |  | network request is necessary to accomplish the desired semantics and, |
| contains a Connection header field with the connection-token close. |  | if so, where that request is to be directed. |
| In case the client does not want to maintain a connection for more |  | If the client has a response cache and the request semantics can be |
| than that request, it SHOULD send a Connection header field including |  | satisfied by a cache ([Part6]), then the request is usually directed |
| the connection-token close. |  | to the cache first. |
| If either the client or the server sends the close token in the |  | If the request is not satisfied by a cache, then a typical client |
| Connection header field, that request becomes the last one for the |  | will check its configuration to determine whether a proxy is to be |
| connection. |  | used to satisfy the request. Proxy configuration is implementation- |
|  |  | dependent, but is often based on URI prefix matching, selective |
|  |  | authority matching, or both, and the proxy itself is usually |
|  |  | identified by an "http" or "https" URI. If a proxy is applicable, |
|  |  | the client connects inbound by establishing (or reusing) a connection |
|  |  | to that proxy. |
| Clients and servers SHOULD NOT assume that a persistent connection is |  | If no proxy is applicable, a typical client will invoke a handler |
| maintained for HTTP versions less than 1.1 unless it is explicitly |  | routine, usually specific to the target URI's scheme, to connect |
| signaled. See Appendix A.1.2 for more information on backward |  | directly to an authority for the target resource. How that is |
| compatibility with HTTP/1.0 clients. |  | accomplished is dependent on the target URI scheme and defined by its |
|  |  | associated specification, similar to how this specification defines |
|  |  | origin server access for resolution of the "http" (Section 2.7.1) and |
|  |  | "https" (Section 2.7.2) schemes. |
| In order to remain persistent, all messages on the connection MUST |  | 5.3. Request Target |
| have a self-defined message length (i.e., one not defined by closure |  |  |
| of the connection), as described in Section 3.3. |  |  |
| 6.1.2.2. Pipelining |  | Once an inbound connection is obtained (Section 6), the client sends |
|  |  | an HTTP request message (Section 3) with a request-target derived |
|  |  | from the target URI. There are four distinct formats for the |
|  |  | request-target, depending on both the method being requested and |
|  |  | whether the request is to a proxy. |
| A client that supports persistent connections MAY "pipeline" its |  | request-target = origin-form |
| requests (i.e., send multiple requests without waiting for each |  | / absolute-form |
| response). A server MUST send its responses to those requests in the |  | / authority-form |
| same order that the requests were received. |  | / asterisk-form |
| Clients which assume persistent connections and pipeline immediately |  | origin-form = path-absolute [ "?" query ] |
| after connection establishment SHOULD be prepared to retry their |  | absolute-form = absolute-URI |
| connection if the first pipelined attempt fails. If a client does |  | authority-form = authority |
| such a retry, it MUST NOT pipeline before it knows the connection is |  | asterisk-form = "*" |
| persistent. Clients MUST also be prepared to resend their requests |  |  |
| if the server closes the connection before sending all of the |  |  |
| corresponding responses. |  |  |
| Clients SHOULD NOT pipeline requests using non-idempotent request |  | The most common form of request-target is the origin-form. When |
| methods or non-idempotent sequences of request methods (see Section |  | making a request directly to an origin server, other than a CONNECT |
| 6.1.2 of [Part2]). Otherwise, a premature termination of the |  | or server-wide OPTIONS request (as detailed below), a client MUST |
| transport connection could lead to indeterminate results. A client |  | send only the absolute path and query components of the target URI as |
| wishing to send a non-idempotent request SHOULD wait to send that |  | the request-target. If the target URI's path component is empty, |
| request until it has received the response status line for the |  | then the client MUST send "/" as the path within the origin-form of |
| previous request. |  | request-target. A Host header field is also sent, as defined in |
|  |  | Section 5.4, containing the target URI's authority component |
|  |  | (excluding any userinfo). |
| 6.1.3. Proxy Servers |  | For example, a client wishing to retrieve a representation of the |
|  |  | resource identified as |
| It is especially important that proxies correctly implement the |  | http://www.example.org/where?q=now |
| properties of the Connection header field as specified in |  |  |
| Section 8.1. |  |  |
| The proxy server MUST signal persistent connections separately with |  | directly from the origin server would open (or reuse) a TCP |
| its clients and the origin servers (or other proxy servers) that it |  | connection to port 80 of the host "www.example.org" and send the |
| connects to. Each persistent connection applies to only one |  | lines: |
| transport link. |  |  |
| A proxy server MUST NOT establish a HTTP/1.1 persistent connection |  | GET /where?q=now HTTP/1.1 |
| with an HTTP/1.0 client (but see Section 19.7.1 of [RFC2068] for |  | Host: www.example.org |
| information and discussion of the problems with the Keep-Alive header |  |  |
| field implemented by many HTTP/1.0 clients). |  |  |
| 6.1.3.1. End-to-end and Hop-by-hop Header Fields |  | followed by the remainder of the request message. |
|  |  | 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 |
|  |  | URI in absolute-form as the request-target. The proxy is requested |
|  |  | 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 |
|  |  | 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.6. |
|  |  | An example absolute-form of request-line would be: |
|  |  | 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 |
|  |  | future version of HTTP, HTTP/1.1 servers MUST accept the absolute- |
|  |  | form in requests, even though HTTP/1.1 clients will only send them in |
|  |  | requests to proxies. |
|  |  | The authority-form of request-target is only used for CONNECT |
|  |  | requests (Section 6.9 of [Part2]). 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) as |
|  |  | the request-target. For example, |
|  |  | CONNECT www.example.com:80 HTTP/1.1 |
|  |  | The asterisk-form of request-target is only used for a server-wide |
|  |  | OPTIONS request (Section 6.2 of [Part2]). When a client wishes to |
|  |  | 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 |
|  |  | 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 |
|  |  | component, then the last proxy on the request chain MUST send a |
|  |  | request-target of "*" when it forwards the request to the indicated |
|  |  | origin server. |
|  |  | For example, the request |
|  |  | OPTIONS http://www.example.org:8001 HTTP/1.1 |
|  |  | would be forwarded by the final proxy as |
|  |  | OPTIONS * HTTP/1.1 |
|  |  | Host: www.example.org:8001 |
|  |  | after connecting to port 8001 of host "www.example.org". |
|  |  | 5.4. Host |
|  |  | The "Host" header field in a request provides the host and port |
|  |  | information from the target URI, enabling the origin server to |
|  |  | distinguish among resources while servicing requests for multiple |
|  |  | host names on a single IP address. Since the Host field-value is |
|  |  | critical information for handling a request, it SHOULD be sent as the |
|  |  | first header field following the request-line. |
|  |  | Host = uri-host [ ":" port ] ; Section 2.7.1 |
|  |  | A client MUST send a Host header field in all HTTP/1.1 request |
|  |  | messages. If the target URI includes an authority component, then |
|  |  | the Host field-value MUST be identical to that authority component |
|  |  | after excluding any userinfo (Section 2.7.1). If the authority |
|  |  | component is missing or undefined for the target URI, then the Host |
|  |  | header field MUST be sent with an empty field-value. |
|  |  | For example, a GET request to the origin server for |
|  |  | <http://www.example.org/pub/WWW/> would begin with: |
|  |  | GET /pub/WWW/ HTTP/1.1 |
|  |  | Host: www.example.org |
|  |  | The Host header field MUST be sent in an HTTP/1.1 request even if the |
|  |  | request-target is in the absolute-form, since this allows the Host |
|  |  | information to be forwarded through ancient HTTP/1.0 proxies that |
|  |  | might not have implemented Host. |
|  |  | When an HTTP/1.1 proxy receives a request with an absolute-form of |
|  |  | request-target, the proxy MUST ignore the received Host header field |
|  |  | (if any) and instead replace it with the host information of the |
|  |  | request-target. If the proxy forwards the request, it MUST generate |
|  |  | a new Host field-value based on the received request-target rather |
|  |  | than forward the received Host field-value. |
|  |  | Since the Host header field acts as an application-level routing |
|  |  | mechanism, it is a frequent target for malware seeking to poison a |
|  |  | shared cache or redirect a request to an unintended server. An |
|  |  | interception proxy is particularly vulnerable if it relies on the |
|  |  | Host field-value for redirecting requests to internal servers, or for |
|  |  | use as a cache key in a shared cache, without first verifying that |
|  |  | the intercepted connection is targeting a valid IP address for that |
|  |  | host. |
|  |  | 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 |
|  |  | request message that contains more than one Host header field or a |
|  |  | Host header field with an invalid field-value. |
|  |  | 5.5. Effective Request URI |
|  |  | A server that receives an HTTP request message MUST reconstruct the |
|  |  | user agent's original target URI, based on the pieces of information |
|  |  | learned from the request-target, Host, and connection context, in |
|  |  | order to identify the intended target resource and properly service |
|  |  | the request. The URI derived from this reconstruction process is |
|  |  | referred to as the "effective request 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 |
|  |  | URI is the same as the request-target. Otherwise, the effective |
|  |  | request URI is constructed as follows. |
|  |  | If the request is received over an SSL/TLS-secured TCP connection, |
|  |  | then the effective request URI's scheme is "https"; otherwise, the |
|  |  | scheme is "http". |
|  |  | If the request-target is in authority-form, then the effective |
|  |  | request URI's authority component is the same as the request-target. |
|  |  | Otherwise, if a Host header field is supplied with a non-empty field- |
|  |  | value, then the authority component is the same as the Host field- |
|  |  | value. Otherwise, the authority component is the concatenation of |
|  |  | the default hostname configured for the server, a colon (":"), and |
|  |  | the connection's incoming TCP port number in decimal form. |
|  |  | If the request-target is in authority-form or asterisk-form, then the |
|  |  | effective request URI's combined path and query component is empty. |
|  |  | Otherwise, the combined path and query component is the same as the |
|  |  | request-target. |
|  |  | The components of the effective request URI, once determined as |
|  |  | above, can be combined into absolute-URI form by concatenating the |
|  |  | scheme, "://", authority, and combined path and query component. |
|  |  | Example 1: the following message received over an insecure TCP |
|  |  | connection |
|  |  | GET /pub/WWW/TheProject.html HTTP/1.1 |
|  |  | Host: www.example.org:8080 |
|  |  | has an effective request URI of |
|  |  | http://www.example.org:8080/pub/WWW/TheProject.html |
|  |  | Example 2: the following message received over an SSL/TLS-secured TCP |
|  |  | connection |
|  |  | OPTIONS * HTTP/1.1 |
|  |  | Host: www.example.org |
|  |  | has an effective request URI of |
|  |  | https://www.example.org |
|  |  | An origin server that does not allow resources to differ by requested |
|  |  | host MAY ignore the Host field-value and instead replace it with a |
|  |  | 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 |
|  |  | effective request URI's authority component. |
|  |  | 5.6. Intermediary Forwarding |
|  |  | As described in Section 2.3, intermediaries can serve a variety of |
|  |  | roles in the processing of HTTP requests and responses. Some |
|  |  | intermediaries are used to improve performance or availability. |
|  |  | Others are used for access control or to filter content. Since an |
|  |  | HTTP stream has characteristics similar to a pipe-and-filter |
|  |  | architecture, there are no inherent limits to the extent an |
|  |  | intermediary can enhance (or interfere) with either direction of the |
|  |  | stream. |
|  |  | In order to avoid request loops, a proxy that forwards requests to |
|  |  | other proxies MUST be able to recognize and exclude all of its own |
|  |  | server names, including any aliases, local variations, or literal IP |
|  |  | addresses. |
|  |  | If a proxy receives a request-target with a host name that is not a |
|  |  | fully qualified domain name, it MAY add its domain to the host name |
|  |  | it received when forwarding the request. A proxy MUST NOT change the |
|  |  | host name if it is a fully qualified domain name. |
|  |  | A non-transforming proxy MUST NOT rewrite the "path-absolute" and |
|  |  | "query" parts of the received request-target when forwarding it to |
|  |  | the next inbound server, except as noted above to replace an empty |
|  |  | path with "/" or "*". |
|  |  | Intermediaries that forward a message MUST implement the Connection |
|  |  | header field as specified in Section 6.1. |
|  |  | 5.6.1. End-to-end and Hop-by-hop Header Fields |
| For the purpose of defining the behavior of caches and non-caching |  | For the purpose of defining the behavior of caches and non-caching |
| proxies, we divide HTTP header fields into two categories: |  | proxies, we divide HTTP header fields into two categories: |
| o End-to-end header fields, which are transmitted to the ultimate |  | o End-to-end header fields, which are transmitted to the ultimate |
| recipient of a request or response. End-to-end header fields in |  | recipient of a request or response. End-to-end header fields in |
| responses MUST be stored as part of a cache entry and MUST be |  | responses MUST be stored as part of a cache entry and MUST be |
| transmitted in any response formed from a cache entry. |  | transmitted in any response formed from a cache entry. |
| o Hop-by-hop header fields, which are meaningful only for a single |  | o Hop-by-hop header fields, which are meaningful only for a single |
| skipping to change at page 43, line 48 |  | skipping to change at page 45, line 50 |
| o Trailer |  | o Trailer |
| o Transfer-Encoding |  | o Transfer-Encoding |
| o Upgrade |  | o Upgrade |
| All other header fields defined by HTTP/1.1 are end-to-end header |  | All other header fields defined by HTTP/1.1 are end-to-end header |
| fields. |  | fields. |
| Other hop-by-hop header fields MUST be listed in a Connection header |  | Other hop-by-hop header fields MUST be listed in a Connection header |
| field (Section 8.1). |  | field (Section 6.1). |
| 6.1.3.2. Non-modifiable Header Fields |  | 5.6.2. Non-modifiable Header Fields |
| Some features of HTTP/1.1, such as Digest Authentication, depend on |  | Some features of HTTP/1.1, such as Digest Authentication, depend on |
| the value of certain end-to-end header fields. A non-transforming |  | the value of certain end-to-end header fields. A non-transforming |
| proxy SHOULD NOT modify an end-to-end header field unless the |  | proxy SHOULD NOT modify an end-to-end header field unless the |
| definition of that header field requires or specifically allows that. |  | definition of that header field requires or specifically allows that. |
| A non-transforming proxy MUST NOT modify any of the following fields |  | A non-transforming proxy MUST NOT modify any of the following fields |
| in a request or response, and it MUST NOT add any of these fields if |  | in a request or response, and it MUST NOT add any of these fields if |
| not already present: |  | not already present: |
| skipping to change at page 45, line 12 |  | skipping to change at page 47, line 12 |
| Warning 214 (Transformation applied) if one does not already appear |  | Warning 214 (Transformation applied) if one does not already appear |
| in the message (see Section 3.6 of [Part6]). |  | in the message (see Section 3.6 of [Part6]). |
| Warning: Unnecessary modification of end-to-end header fields |  | Warning: Unnecessary modification of end-to-end header fields |
| might cause authentication failures if stronger authentication |  | might cause authentication failures if stronger authentication |
| mechanisms are introduced in later versions of HTTP. Such |  | mechanisms are introduced in later versions of HTTP. Such |
| authentication mechanisms MAY rely on the values of header fields |  | authentication mechanisms MAY rely on the values of header fields |
| not listed here. |  | not listed here. |
| A non-transforming proxy MUST preserve the message payload ([Part3]), |  | A non-transforming proxy MUST preserve the message payload ([Part3]), |
| though it MAY change the message-body through application or removal |  | though it MAY change the message body through application or removal |
| of a transfer-coding (Section 5.1). |  | of a transfer-coding (Section 4). |
| 6.1.4. Practical Considerations |  | 5.7. Associating a Response to a Request |
|  |  | HTTP does not include a request identifier for associating a given |
|  |  | request message with its corresponding one or more response messages. |
|  |  | Hence, it relies on the order of response arrival to correspond |
|  |  | exactly to the order in which requests are made on the same |
|  |  | connection. More than one response message per request only occurs |
|  |  | when one or more informational responses (1xx, see Section 7.1 of |
|  |  | [Part2]) precede a final response to the same request. |
|  |  | A client that uses persistent connections and sends more than one |
|  |  | request per connection MUST maintain a list of outstanding requests |
|  |  | in the order sent on that connection and MUST associate each received |
|  |  | response message to the highest ordered request that has not yet |
|  |  | received a final (non-1xx) response. |
|  |  | 6. Connection Management |
|  |  | 6.1. Connection |
|  |  | The "Connection" header field allows the sender to specify options |
|  |  | that are desired only for that particular connection. Such |
|  |  | connection options MUST be removed or replaced before the message can |
|  |  | be forwarded downstream by a proxy or gateway. This mechanism also |
|  |  | allows the sender to indicate which HTTP header fields used in the |
|  |  | message are only intended for the immediate recipient ("hop-by-hop"), |
|  |  | as opposed to all recipients on the chain ("end-to-end"), enabling |
|  |  | the message to be self-descriptive and allowing future connection- |
|  |  | specific extensions to be deployed in HTTP without fear that they |
|  |  | will be blindly forwarded by previously deployed intermediaries. |
|  |  | The Connection header field's value has the following grammar: |
|  |  | Connection = 1#connection-token |
|  |  | connection-token = token |
|  |  | A proxy or gateway MUST parse a received Connection header field |
|  |  | before a message is forwarded and, for each connection-token in this |
|  |  | field, remove any header field(s) from the message with the same name |
|  |  | as the connection-token, and then remove the Connection header field |
|  |  | itself or replace it with the sender's own connection options for the |
|  |  | forwarded message. |
|  |  | A sender MUST NOT include field-names in the Connection header field- |
|  |  | value for fields that are defined as expressing constraints for all |
|  |  | recipients in the request or response chain, such as the Cache- |
|  |  | Control header field (Section 3.2 of [Part6]). |
|  |  | The connection options do not have to correspond to a header field |
|  |  | present in the message, since a connection-specific header field |
|  |  | might not be needed if there are no parameters associated with that |
|  |  | connection option. Recipients that trigger certain connection |
|  |  | behavior based on the presence of connection options MUST do so based |
|  |  | on the presence of the connection-token rather than only the presence |
|  |  | of the optional header field. In other words, if the connection |
|  |  | option is received as a header field but not indicated within the |
|  |  | Connection field-value, then the recipient MUST ignore the |
|  |  | connection-specific header field because it has likely been forwarded |
|  |  | by an intermediary that is only partially conformant. |
|  |  | When defining new connection options, specifications ought to |
|  |  | carefully consider existing deployed header fields and ensure that |
|  |  | the new connection-token does not share the same name as an unrelated |
|  |  | header field that might already be deployed. Defining a new |
|  |  | connection-token essentially reserves that potential field-name for |
|  |  | carrying additional information related to the connection option, |
|  |  | since it would be unwise for senders to use that field-name for |
|  |  | anything else. |
|  |  | HTTP/1.1 defines the "close" connection option for the sender to |
|  |  | signal that the connection will be closed after completion of the |
|  |  | response. For example, |
|  |  | Connection: close |
|  |  | in either the request or the response header fields indicates that |
|  |  | the connection SHOULD NOT be considered "persistent" (Section 6.3) |
|  |  | after the current request/response is complete. |
|  |  | An HTTP/1.1 client that does not support persistent connections MUST |
|  |  | include the "close" connection option in every request message. |
|  |  | An HTTP/1.1 server that does not support persistent connections MUST |
|  |  | include the "close" connection option in every response message that |
|  |  | does not have a 1xx (Informational) status code. |
|  |  | 6.2. Via |
|  |  | The "Via" header field MUST be sent by a proxy or gateway to indicate |
|  |  | the intermediate protocols and recipients between the user agent and |
|  |  | the server on requests, and between the origin server and the client |
|  |  | on responses. It is analogous to the "Received" field used by email |
|  |  | systems (Section 3.6.7 of [RFC5322]) and is intended to be used for |
|  |  | tracking message forwards, avoiding request loops, and identifying |
|  |  | the protocol capabilities of all senders along the request/response |
|  |  | chain. |
|  |  | Via = 1#( received-protocol RWS received-by |
|  |  | [ RWS comment ] ) |
|  |  | received-protocol = [ protocol-name "/" ] protocol-version |
|  |  | received-by = ( uri-host [ ":" port ] ) / pseudonym |
|  |  | pseudonym = token |
|  |  | The received-protocol indicates the protocol version of the message |
|  |  | received by the server or client along each segment of the request/ |
|  |  | response chain. The received-protocol version is appended to the Via |
|  |  | field value when the message is forwarded so that information about |
|  |  | the protocol capabilities of upstream applications remains visible to |
|  |  | all recipients. |
|  |  | The protocol-name is excluded if and only if it would be "HTTP". The |
|  |  | received-by field is normally the host and optional port number of a |
|  |  | recipient server or client that subsequently forwarded the message. |
|  |  | However, if the real host is considered to be sensitive information, |
|  |  | it MAY be replaced by a pseudonym. If the port is not given, it MAY |
|  |  | be assumed to be the default port of the received-protocol. |
|  |  | Multiple Via field values represent each proxy or gateway that has |
|  |  | forwarded the message. Each recipient MUST append its information |
|  |  | such that the end result is ordered according to the sequence of |
|  |  | forwarding applications. |
|  |  | Comments MAY be used in the Via header field to identify the software |
|  |  | of each recipient, analogous to the User-Agent and Server header |
|  |  | fields. However, all comments in the Via field are optional and MAY |
|  |  | be removed by any recipient prior to forwarding the message. |
|  |  | 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 |
|  |  | forward the request to a public proxy at p.example.net, which |
|  |  | completes the request by forwarding it to the origin server at |
|  |  | www.example.com. The request received by www.example.com would then |
|  |  | have the following Via header field: |
|  |  | Via: 1.0 fred, 1.1 p.example.net (Apache/1.1) |
|  |  | A proxy or gateway used as a portal through a network firewall SHOULD |
|  |  | NOT forward the names and ports of hosts within the firewall region |
|  |  | unless it is explicitly enabled to do so. If not enabled, the |
|  |  | received-by host of any host behind the firewall SHOULD be replaced |
|  |  | by an appropriate pseudonym for that host. |
|  |  | For organizations that have strong privacy requirements for hiding |
|  |  | internal structures, a proxy or gateway MAY combine an ordered |
|  |  | subsequence of Via header field entries with identical received- |
|  |  | protocol values into a single such entry. For example, |
|  |  | Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy |
|  |  | could be collapsed to |
|  |  | Via: 1.0 ricky, 1.1 mertz, 1.0 lucy |
|  |  | Senders SHOULD NOT combine multiple entries unless they are all under |
|  |  | the same organizational control and the hosts have already been |
|  |  | replaced by pseudonyms. Senders MUST NOT combine entries which have |
|  |  | different received-protocol values. |
|  |  | 6.3. Persistent Connections |
|  |  | 6.3.1. Purpose |
|  |  | Prior to persistent connections, a separate TCP connection was |
|  |  | established for each request, increasing the load on HTTP servers and |
|  |  | causing congestion on the Internet. The use of inline images and |
|  |  | other associated data often requires a client to make multiple |
|  |  | requests of the same server in a short amount of time. Analysis of |
|  |  | these performance problems and results from a prototype |
|  |  | implementation are available [Pad1995] [Spe]. Implementation |
|  |  | experience and measurements of actual HTTP/1.1 implementations show |
|  |  | good results [Nie1997]. Alternatives have also been explored, for |
|  |  | example, T/TCP [Tou1998]. |
|  |  | Persistent HTTP connections have a number of advantages: |
|  |  | o By opening and closing fewer TCP connections, CPU time is saved in |
|  |  | routers and hosts (clients, servers, proxies, gateways, tunnels, |
|  |  | or caches), and memory used for TCP protocol control blocks can be |
|  |  | saved in hosts. |
|  |  | o HTTP requests and responses can be pipelined on a connection. |
|  |  | Pipelining allows a client to make multiple requests without |
|  |  | waiting for each response, allowing a single TCP connection to be |
|  |  | used much more efficiently, with much lower elapsed time. |
|  |  | o Network congestion is reduced by reducing the number of packets |
|  |  | caused by TCP opens, and by allowing TCP sufficient time to |
|  |  | determine the congestion state of the network. |
|  |  | o Latency on subsequent requests is reduced since there is no time |
|  |  | spent in TCP's connection opening handshake. |
|  |  | o HTTP can evolve more gracefully, since errors can be reported |
|  |  | without the penalty of closing the TCP connection. Clients using |
|  |  | future versions of HTTP might optimistically try a new feature, |
|  |  | but if communicating with an older server, retry with old |
|  |  | semantics after an error is reported. |
|  |  | HTTP implementations SHOULD implement persistent connections. |
|  |  | 6.3.2. Overall Operation |
|  |  | A significant difference between HTTP/1.1 and earlier versions of |
|  |  | HTTP is that persistent connections are the default behavior of any |
|  |  | HTTP connection. That is, unless otherwise indicated, the client |
|  |  | SHOULD assume that the server will maintain a persistent connection, |
|  |  | even after error responses from the server. |
|  |  | Persistent connections provide a mechanism by which a client and a |
|  |  | server can signal the close of a TCP connection. This signaling |
|  |  | takes place using the Connection header field (Section 6.1). Once a |
|  |  | close has been signaled, the client MUST NOT send any more requests |
|  |  | on that connection. |
|  |  | 6.3.2.1. Negotiation |
|  |  | An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to |
|  |  | maintain a persistent connection unless a Connection header field |
|  |  | including the connection-token "close" was sent in the request. If |
|  |  | the server chooses to close the connection immediately after sending |
|  |  | the response, it SHOULD send a Connection header field including the |
|  |  | connection-token "close". |
|  |  | An HTTP/1.1 client MAY expect a connection to remain open, but would |
|  |  | decide to keep it open based on whether the response from a server |
|  |  | contains a Connection header field with the connection-token close. |
|  |  | In case the client does not want to maintain a connection for more |
|  |  | than that request, it SHOULD send a Connection header field including |
|  |  | the connection-token close. |
|  |  | If either the client or the server sends the close token in the |
|  |  | Connection header field, that request becomes the last one for the |
|  |  | connection. |
|  |  | Clients and servers SHOULD NOT assume that a persistent connection is |
|  |  | maintained for HTTP versions less than 1.1 unless it is explicitly |
|  |  | signaled. See Appendix A.1.2 for more information on backward |
|  |  | compatibility with HTTP/1.0 clients. |
|  |  | Each persistent connection applies to only one transport link. |
|  |  | A proxy server MUST NOT establish a HTTP/1.1 persistent connection |
|  |  | with an HTTP/1.0 client (but see Section 19.7.1 of [RFC2068] for |
|  |  | information and discussion of the problems with the Keep-Alive header |
|  |  | field implemented by many HTTP/1.0 clients). |
|  |  | In order to remain persistent, all messages on the connection MUST |
|  |  | have a self-defined message length (i.e., one not defined by closure |
|  |  | of the connection), as described in Section 3.3. |
|  |  | 6.3.2.2. Pipelining |
|  |  | A client that supports persistent connections MAY "pipeline" its |
|  |  | requests (i.e., send multiple requests without waiting for each |
|  |  | response). A server MUST send its responses to those requests in the |
|  |  | same order that the requests were received. |
|  |  | Clients which assume persistent connections and pipeline immediately |
|  |  | after connection establishment SHOULD be prepared to retry their |
|  |  | connection if the first pipelined attempt fails. If a client does |
|  |  | such a retry, it MUST NOT pipeline before it knows the connection is |
|  |  | persistent. Clients MUST also be prepared to resend their requests |
|  |  | if the server closes the connection before sending all of the |
|  |  | corresponding responses. |
|  |  | Clients SHOULD NOT pipeline requests using non-idempotent request |
|  |  | methods or non-idempotent sequences of request methods (see Section |
|  |  | 6.1.2 of [Part2]). Otherwise, a premature termination of the |
|  |  | transport connection could lead to indeterminate results. A client |
|  |  | wishing to send a non-idempotent request SHOULD wait to send that |
|  |  | request until it has received the response status line for the |
|  |  | previous request. |
|  |  | 6.3.3. Practical Considerations |
| Servers will usually have some time-out value beyond which they will |  | Servers will usually have some time-out value beyond which they will |
| no longer maintain an inactive connection. Proxy servers might make |  | no longer maintain an inactive connection. Proxy servers might make |
| this a higher value since it is likely that the client will be making |  | this a higher value since it is likely that the client will be making |
| more connections through the same server. The use of persistent |  | more connections through the same server. The use of persistent |
| connections places no requirements on the length (or existence) of |  | connections places no requirements on the length (or existence) of |
| this time-out for either the client or the server. |  | this time-out for either the client or the server. |
| When a client or server wishes to time-out it SHOULD issue a graceful |  | When a client or server wishes to time-out it SHOULD issue a graceful |
| close on the transport connection. Clients and servers SHOULD both |  | close on the transport connection. Clients and servers SHOULD both |
| skipping to change at page 46, line 9 |  | skipping to change at page 53, line 42 |
| line blocking" problem (whereby a request that takes significant |  | line blocking" problem (whereby a request that takes significant |
| server-side processing and/or has a large payload can block |  | server-side processing and/or has a large payload can block |
| subsequent requests on the same connection), each connection used |  | subsequent requests on the same connection), each connection used |
| consumes server resources (sometimes significantly), and furthermore |  | consumes server resources (sometimes significantly), and furthermore |
| using multiple connections can cause undesirable side effects in |  | using multiple connections can cause undesirable side effects in |
| congested networks. |  | congested networks. |
| Note that servers might reject traffic that they deem abusive, |  | Note that servers might reject traffic that they deem abusive, |
| including an excessive number of connections from a client. |  | including an excessive number of connections from a client. |
| 6.1.5. Retrying Requests |  | 6.3.4. Retrying Requests |
| Senders can close the transport connection at any time. Therefore, |  | Senders can close the transport connection at any time. Therefore, |
| clients, servers, and proxies MUST be able to recover from |  | clients, servers, and proxies MUST be able to recover from |
| asynchronous close events. Client software MAY reopen the transport |  | asynchronous close events. Client software MAY reopen the transport |
| connection and retransmit the aborted sequence of requests without |  | connection and retransmit the aborted sequence of requests without |
| user interaction so long as the request sequence is idempotent (see |  | user interaction so long as the request sequence is idempotent (see |
| Section 6.1.2 of [Part2]). Non-idempotent request methods or |  | Section 6.1.2 of [Part2]). Non-idempotent request methods or |
| sequences MUST NOT be automatically retried, although user agents MAY |  | sequences MUST NOT be automatically retried, although user agents MAY |
| offer a human operator the choice of retrying the request(s). |  | offer a human operator the choice of retrying the request(s). |
| Confirmation by user-agent software with semantic understanding of |  | Confirmation by user-agent software with semantic understanding of |
| the application MAY substitute for user confirmation. The automatic |  | the application MAY substitute for user confirmation. The automatic |
| retry SHOULD NOT be repeated if the second sequence of requests |  | retry SHOULD NOT be repeated if the second sequence of requests |
| fails. |  | fails. |
| 6.2. Message Transmission Requirements |  | 6.4. Message Transmission Requirements |
| 6.2.1. Persistent Connections and Flow Control |  | 6.4.1. Persistent Connections and Flow Control |
| HTTP/1.1 servers SHOULD maintain persistent connections and use TCP's |  | HTTP/1.1 servers SHOULD maintain persistent connections and use TCP's |
| flow control mechanisms to resolve temporary overloads, rather than |  | flow control mechanisms to resolve temporary overloads, rather than |
| terminating connections with the expectation that clients will retry. |  | terminating connections with the expectation that clients will retry. |
| The latter technique can exacerbate network congestion. |  | The latter technique can exacerbate network congestion. |
| 6.2.2. Monitoring Connections for Error Status Messages |  | 6.4.2. Monitoring Connections for Error Status Messages |
| An HTTP/1.1 (or later) client sending a message-body SHOULD monitor |  | An HTTP/1.1 (or later) client sending a message body SHOULD monitor |
| the network connection for an error status code while it is |  | the network connection for an error status code while it is |
| transmitting the request. If the client sees an error status code, |  | transmitting the request. If the client sees an error status code, |
| it SHOULD immediately cease transmitting the body. If the body is |  | it SHOULD immediately cease transmitting the body. If the body is |
| being sent using a "chunked" encoding (Section 5.1), a zero length |  | being sent using a "chunked" encoding (Section 4), a zero length |
| chunk and empty trailer MAY be used to prematurely mark the end of |  | chunk and empty trailer MAY be used to prematurely mark the end of |
| the message. If the body was preceded by a Content-Length header |  | the message. If the body was preceded by a Content-Length header |
| field, the client MUST close the connection. |  | field, the client MUST close the connection. |
| 6.2.3. Use of the 100 (Continue) Status |  | 6.4.3. Use of the 100 (Continue) Status |
| The purpose of the 100 (Continue) status code (see Section 7.1.1 of |  | The purpose of the 100 (Continue) status code (see Section 7.1.1 of |
| [Part2]) is to allow a client that is sending a request message with |  | [Part2]) is to allow a client that is sending a request message with |
| a request body to determine if the origin server is willing to accept |  | a request body to determine if the origin server is willing to accept |
| the request (based on the request header fields) before the client |  | the request (based on the request header fields) before the client |
| sends the request body. In some cases, it might either be |  | sends the request body. In some cases, it might either be |
| inappropriate or highly inefficient for the client to send the body |  | inappropriate or highly inefficient for the client to send the body |
| if the server will reject the message without looking at the body. |  | if the server will reject the message without looking at the body. |
| Requirements for HTTP/1.1 clients: |  | Requirements for HTTP/1.1 clients: |
| o If a client will wait for a 100 (Continue) response before sending |  | o If a client will wait for a 100 (Continue) response before sending |
| the request body, it MUST send an Expect header field (Section 9.3 |  | the request body, it MUST send an Expect header field (Section |
| of [Part2]) with the "100-continue" expectation. |  | 10.3 of [Part2]) with the "100-continue" expectation. |
| o A client MUST NOT send an Expect header field (Section 9.3 of |  | o A client MUST NOT send an Expect header field (Section 10.3 of |
| [Part2]) with the "100-continue" expectation if it does not intend |  | [Part2]) with the "100-continue" expectation if it does not intend |
| to send a request body. |  | to send a request body. |
| Because of the presence of older implementations, the protocol allows |  | Because of the presence of older implementations, the protocol allows |
| ambiguous situations in which a client might send "Expect: 100- |  | ambiguous situations in which a client might send "Expect: 100- |
| continue" without receiving either a 417 (Expectation Failed) or a |  | continue" without receiving either a 417 (Expectation Failed) or a |
| 100 (Continue) status code. Therefore, when a client sends this |  | 100 (Continue) status code. Therefore, when a client sends this |
| header field to an origin server (possibly via a proxy) from which it |  | header field to an origin server (possibly via a proxy) from which it |
| has never seen a 100 (Continue) status code, the client SHOULD NOT |  | has never seen a 100 (Continue) status code, the client SHOULD NOT |
| wait for an indefinite period before sending the request body. |  | wait for an indefinite period before sending the request body. |
| skipping to change at page 48, line 18 |  | skipping to change at page 55, line 51 |
| connection prematurely. |  | connection prematurely. |
| o If an origin server receives a request that does not include an |  | o If an origin server receives a request that does not include an |
| Expect header field with the "100-continue" expectation, the |  | Expect header field with the "100-continue" expectation, the |
| request includes a request body, and the server responds with a |  | request includes a request body, and the server responds with a |
| final status code before reading the entire request body from the |  | final status code before reading the entire request body from the |
| transport connection, then the server SHOULD NOT close the |  | transport connection, then the server SHOULD NOT close the |
| transport connection until it has read the entire request, or |  | transport connection until it has read the entire request, or |
| until the client closes the connection. Otherwise, the client |  | until the client closes the connection. Otherwise, the client |
| might not reliably receive the response message. However, this |  | might not reliably receive the response message. However, this |
| requirement is not be construed as preventing a server from |  | requirement ought not be construed as preventing a server from |
| defending itself against denial-of-service attacks, or from badly |  | defending itself against denial-of-service attacks, or from badly |
| broken client implementations. |  | broken client implementations. |
| Requirements for HTTP/1.1 proxies: |  | Requirements for HTTP/1.1 proxies: |
| o If a proxy receives a request that includes an Expect header field |  | o If a proxy receives a request that includes an Expect header field |
| with the "100-continue" expectation, and the proxy either knows |  | with the "100-continue" expectation, and the proxy either knows |
| that the next-hop server complies with HTTP/1.1 or higher, or does |  | that the next-hop server complies with HTTP/1.1 or higher, or does |
| not know the HTTP version of the next-hop server, it MUST forward |  | not know the HTTP version of the next-hop server, it MUST forward |
| the request, including the Expect header field. |  | the request, including the Expect header field. |
| skipping to change at page 48, line 43 |  | skipping to change at page 56, line 28 |
| o Proxies SHOULD maintain a record of the HTTP version numbers |  | o Proxies SHOULD maintain a record of the HTTP version numbers |
| received from recently-referenced next-hop servers. |  | received from recently-referenced next-hop servers. |
| o A proxy MUST NOT forward a 100 (Continue) response if the request |  | o A proxy MUST NOT forward a 100 (Continue) response if the request |
| message was received from an HTTP/1.0 (or earlier) client and did |  | message was received from an HTTP/1.0 (or earlier) client and did |
| not include an Expect header field with the "100-continue" |  | not include an Expect header field with the "100-continue" |
| expectation. This requirement overrides the general rule for |  | expectation. This requirement overrides the general rule for |
| forwarding of 1xx responses (see Section 7.1 of [Part2]). |  | forwarding of 1xx responses (see Section 7.1 of [Part2]). |
| 7. Miscellaneous notes that might disappear |  | 6.4.4. Closing Connections on Error |
| 7.1. Scheme aliases considered harmful |  |  |
| [[TBD-aliases-harmful: describe why aliases like webcal are |  |  |
| harmful.]] |  |  |
| 7.2. Use of HTTP for proxy communication |  |  |
| [[TBD-proxy-other: Configured to use HTTP to proxy HTTP or other |  |  |
| protocols.]] |  |  |
| 7.3. Interception of HTTP for access control |  |  |
| [[TBD-intercept: Interception of HTTP traffic for initiating access |  |  |
| control.]] |  |  |
| 7.4. Use of HTTP by other protocols |  |  |
| [[TBD-profiles: Profiles of HTTP defined by other protocol. |  |  |
| Extensions of HTTP like WebDAV.]] |  |  |
| 7.5. Use of HTTP by media type specification |  |  |
| [[TBD-hypertext: Instructions on composing HTTP requests via |  |  |
| hypertext formats.]] |  |  |
| 8. Header Field Definitions |  |  |
| This section defines the syntax and semantics of HTTP header fields |  |  |
| related to message origination, framing, and routing. |  |  |
| +-------------------+---------------+ |  |  |
| | Header Field Name | Defined in... | |  |  |
| +-------------------+---------------+ |  |  |
| | Connection | Section 8.1 | |  |  |
| | Content-Length | Section 8.2 | |  |  |
| | Host | Section 8.3 | |  |  |
| | TE | Section 8.4 | |  |  |
| | Trailer | Section 8.5 | |  |  |
| | Transfer-Encoding | Section 8.6 | |  |  |
| | Upgrade | Section 8.7 | |  |  |
| | Via | Section 8.8 | |  |  |
| +-------------------+---------------+ |  |  |
| 8.1. Connection |  |  |
| The "Connection" header field allows the sender to specify options |  |  |
| that are desired only for that particular connection. Such |  |  |
| connection options MUST be removed or replaced before the message can |  |  |
| be forwarded downstream by a proxy or gateway. This mechanism also |  |  |
| allows the sender to indicate which HTTP header fields used in the |  |  |
| message are only intended for the immediate recipient ("hop-by-hop"), |  |  |
| as opposed to all recipients on the chain ("end-to-end"), enabling |  |  |
| the message to be self-descriptive and allowing future connection- |  |  |
| specific extensions to be deployed in HTTP without fear that they |  |  |
| will be blindly forwarded by previously deployed intermediaries. |  |  |
| The Connection header field's value has the following grammar: |  |  |
| Connection = 1#connection-token |  |  |
| connection-token = token |  |  |
| A proxy or gateway MUST parse a received Connection header field |  |  |
| before a message is forwarded and, for each connection-token in this |  |  |
| field, remove any header field(s) from the message with the same name |  |  |
| as the connection-token, and then remove the Connection header field |  |  |
| itself or replace it with the sender's own connection options for the |  |  |
| forwarded message. |  |  |
| A sender MUST NOT include field-names in the Connection header field- |  |  |
| value for fields that are defined as expressing constraints for all |  |  |
| recipients in the request or response chain, such as the Cache- |  |  |
| Control header field (Section 3.2 of [Part6]). |  |  |
| The connection options do not have to correspond to a header field |  |  |
| present in the message, since a connection-specific header field |  |  |
| might not be needed if there are no parameters associated with that |  |  |
| connection option. Recipients that trigger certain connection |  |  |
| behavior based on the presence of connection options MUST do so based |  |  |
| on the presence of the connection-token rather than only the presence |  |  |
| of the optional header field. In other words, if the connection |  |  |
| option is received as a header field but not indicated within the |  |  |
| Connection field-value, then the recipient MUST ignore the |  |  |
| connection-specific header field because it has likely been forwarded |  |  |
| by an intermediary that is only partially compliant. |  |  |
| When defining new connection options, specifications ought to |  |  |
| carefully consider existing deployed header fields and ensure that |  |  |
| the new connection-token does not share the same name as an unrelated |  |  |
| header field that might already be deployed. Defining a new |  |  |
| connection-token essentially reserves that potential field-name for |  |  |
| carrying additional information related to the connection option, |  |  |
| since it would be unwise for senders to use that field-name for |  |  |
| anything else. |  |  |
| HTTP/1.1 defines the "close" connection option for the sender to |  |  |
| signal that the connection will be closed after completion of the |  |  |
| response. For example, |  |  |
| Connection: close |  |  |
| in either the request or the response header fields indicates that |  |  |
| the connection SHOULD NOT be considered "persistent" (Section 6.1) |  |  |
| after the current request/response is complete. |  |  |
| An HTTP/1.1 client that does not support persistent connections MUST |  |  |
| include the "close" connection option in every request message. |  |  |
| An HTTP/1.1 server that does not support persistent connections MUST |  |  |
| include the "close" connection option in every response message that |  |  |
| does not have a 1xx (Informational) status code. |  |  |
| 8.2. Content-Length |  |  |
| The "Content-Length" header field indicates the size of the message- |  |  |
| body, in decimal number of octets, for any message other than a |  |  |
| response to a HEAD request or a response with a status code of 304. |  |  |
| In the case of a response to a HEAD request, Content-Length indicates |  |  |
| the size of the payload body (not including any potential transfer- |  |  |
| coding) that would have been sent had the request been a GET. In the |  |  |
| case of a 304 (Not Modified) response to a GET request, Content- |  |  |
| Length indicates the size of the payload body (not including any |  |  |
| potential transfer-coding) that would have been sent in a 200 (OK) |  |  |
| response. |  |  |
| Content-Length = 1*DIGIT |  |  |
| An example is |  |  |
| Content-Length: 3495 |  |  |
| Implementations SHOULD use this field to indicate the message-body |  |  |
| length when no transfer-coding is being applied and the payload's |  |  |
| body length can be determined prior to being transferred. |  |  |
| Section 3.3 describes how recipients determine the length of a |  |  |
| message-body. |  |  |
| Any Content-Length greater than or equal to zero is a valid value. |  |  |
| Note that the use of this field in HTTP is significantly different |  |  |
| from the corresponding definition in MIME, where it is an optional |  |  |
| field used within the "message/external-body" content-type. |  |  |
| 8.3. Host |  |  |
| The "Host" header field in a request provides the host and port |  |  |
| information from the target resource's URI, enabling the origin |  |  |
| server to distinguish between resources while servicing requests for |  |  |
| multiple host names on a single IP address. Since the Host field- |  |  |
| value is critical information for handling a request, it SHOULD be |  |  |
| sent as the first header field following the Request-Line. |  |  |
| Host = uri-host [ ":" port ] ; Section 2.7.1 |  |  |
| A client MUST send a Host header field in all HTTP/1.1 request |  |  |
| messages. If the target resource's URI includes an authority |  |  |
| component, then the Host field-value MUST be identical to that |  |  |
| authority component after excluding any userinfo (Section 2.7.1). If |  |  |
| the authority component is missing or undefined for the target |  |  |
| resource's URI, then the Host header field MUST be sent with an empty |  |  |
| field-value. |  |  |
| For example, a GET request to the origin server for |  |  |
| <http://www.example.org/pub/WWW/> would begin with: |  |  |
| GET /pub/WWW/ HTTP/1.1 |  |  |
| Host: www.example.org |  |  |
| The Host header field MUST be sent in an HTTP/1.1 request even if the |  |  |
| request-target is in the form of an absolute-URI, since this allows |  |  |
| the Host information to be forwarded through ancient HTTP/1.0 proxies |  |  |
| that might not have implemented Host. |  |  |
| When an HTTP/1.1 proxy receives a request with a request-target in |  |  |
| the form of an absolute-URI, the proxy MUST ignore the received Host |  |  |
| header field (if any) and instead replace it with the host |  |  |
| information of the request-target. When a proxy forwards a request, |  |  |
| it MUST generate the Host header field based on the received |  |  |
| absolute-URI rather than the received Host. |  |  |
| Since the Host header field acts as an application-level routing |  |  |
| mechanism, it is a frequent target for malware seeking to poison a |  |  |
| shared cache or redirect a request to an unintended server. An |  |  |
| interception proxy is particularly vulnerable if it relies on the |  |  |
| Host header field value for redirecting requests to internal servers, |  |  |
| or for use as a cache key in a shared cache, without first verifying |  |  |
| that the intercepted connection is targeting a valid IP address for |  |  |
| that host. |  |  |
| 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 |  |  |
| request message that contains more than one Host header field or a |  |  |
| Host header field with an invalid field-value. |  |  |
| See Sections 4.2 and A.1.1 for other requirements relating to Host. |  |  |
| 8.4. TE |  |  |
| The "TE" header field indicates what extension transfer-codings it is |  |  |
| willing to accept in the response, and whether or not it is willing |  |  |
| to accept trailer fields in a chunked transfer-coding. |  |  |
| Its value consists of the keyword "trailers" and/or a comma-separated |  |  |
| list of extension transfer-coding names with optional accept |  |  |
| parameters (as described in Section 5.1). |  |  |
| TE = #t-codings |  |  |
| t-codings = "trailers" / ( transfer-extension [ te-params ] ) |  |  |
| te-params = OWS ";" OWS "q=" qvalue *( te-ext ) |  |  |
| te-ext = OWS ";" OWS token [ "=" word ] |  |  |
| The presence of the keyword "trailers" indicates that the client is |  |  |
| willing to accept trailer fields in a chunked transfer-coding, as |  |  |
| defined in Section 5.1.1. This keyword is reserved for use with |  |  |
| transfer-coding values even though it does not itself represent a |  |  |
| transfer-coding. |  |  |
| Examples of its use are: |  |  |
| TE: deflate |  |  |
| TE: |  |  |
| TE: trailers, deflate;q=0.5 |  |  |
| The TE header field only applies to the immediate connection. |  |  |
| Therefore, the keyword MUST be supplied within a Connection header |  |  |
| field (Section 8.1) whenever TE is present in an HTTP/1.1 message. |  |  |
| A server tests whether a transfer-coding is acceptable, according to |  |  |
| a TE field, using these rules: |  |  |
| 1. The "chunked" transfer-coding is always acceptable. If the |  |  |
| keyword "trailers" is listed, the client indicates that it is |  |  |
| willing to accept trailer fields in the chunked response on |  |  |
| behalf of itself and any downstream clients. The implication is |  |  |
| that, if given, the client is stating that either all downstream |  |  |
| clients are willing to accept trailer fields in the forwarded |  |  |
| response, or that it will attempt to buffer the response on |  |  |
| behalf of downstream recipients. |  |  |
| Note: HTTP/1.1 does not define any means to limit the size of a |  |  |
| chunked response such that a client can be assured of buffering |  |  |
| the entire response. |  |  |
| 2. If the transfer-coding being tested is one of the transfer- |  |  |
| codings listed in the TE field, then it is acceptable unless it |  |  |
| is accompanied by a qvalue of 0. (As defined in Section 5.3, a |  |  |
| qvalue of 0 means "not acceptable".) |  |  |
| 3. If multiple transfer-codings are acceptable, then the acceptable |  |  |
| transfer-coding with the highest non-zero qvalue is preferred. |  |  |
| The "chunked" transfer-coding always has a qvalue of 1. |  |  |
| If the TE field-value is empty or if no TE field is present, the only |  |  |
| transfer-coding is "chunked". A message with no transfer-coding is |  |  |
| always acceptable. |  |  |
| 8.5. Trailer |  |  |
| The "Trailer" header field indicates that the given set of header |  |  |
| fields is present in the trailer of a message encoded with chunked |  |  |
| transfer-coding. |  |  |
| Trailer = 1#field-name |  |  |
| An HTTP/1.1 message SHOULD include a Trailer header field in a |  |  |
| message using chunked transfer-coding with a non-empty trailer. |  |  |
| Doing so allows the recipient to know which header fields to expect |  |  |
| in the trailer. |  |  |
| If no Trailer header field is present, the trailer SHOULD NOT include |  |  |
| any header fields. See Section 5.1.1 for restrictions on the use of |  |  |
| trailer fields in a "chunked" transfer-coding. |  |  |
| Message header fields listed in the Trailer header field MUST NOT |  |  |
| include the following header fields: |  |  |
| o Transfer-Encoding |  |  |
| o Content-Length |  |  |
| o Trailer |  |  |
| 8.6. Transfer-Encoding |  |  |
| The "Transfer-Encoding" header field indicates what transfer-codings |  |  |
| (if any) have been applied to the message body. It differs from |  |  |
| Content-Encoding (Section 2.2 of [Part3]) in that transfer-codings |  |  |
| are a property of the message (and therefore are removed by |  |  |
| intermediaries), whereas content-codings are not. |  |  |
| Transfer-Encoding = 1#transfer-coding |  |  |
| Transfer-codings are defined in Section 5.1. An example is: |  |  |
| Transfer-Encoding: chunked |  |  |
| If multiple encodings have been applied to a representation, the |  |  |
| transfer-codings MUST be listed in the order in which they were |  |  |
| applied. Additional information about the encoding parameters MAY be |  |  |
| provided by other header fields not defined by this specification. |  |  |
| Many older HTTP/1.0 applications do not understand the Transfer- |  | If the client is sending data, a server implementation using TCP |
| Encoding header field. |  | SHOULD be careful to ensure that the client acknowledges receipt of |
|  |  | the packet(s) containing the response, before the server closes the |
|  |  | input connection. If the client continues sending data to the server |
|  |  | after the close, the server's TCP stack will send a reset packet to |
|  |  | the client, which might erase the client's unacknowledged input |
|  |  | buffers before they can be read and interpreted by the HTTP |
|  |  | application. |
| 8.7. Upgrade |  | 6.5. Upgrade |
| The "Upgrade" header field allows the client to specify what |  | The "Upgrade" header field allows the client to specify what |
| additional communication protocols it would like to use, if the |  | additional communication protocols it would like to use, if the |
| server chooses to switch protocols. Servers can use it to indicate |  | server chooses to switch protocols. Servers can use it to indicate |
| what protocols they are willing to switch to. |  | what protocols they are willing to switch to. |
| Upgrade = 1#product |  | Upgrade = 1#protocol |
|  |  | protocol = protocol-name ["/" protocol-version] |
|  |  | protocol-name = token |
|  |  | protocol-version = token |
| For example, |  | For example, |
| Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 |  | Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 |
| The Upgrade header field is intended to provide a simple mechanism |  | The Upgrade header field is intended to provide a simple mechanism |
| for transition from HTTP/1.1 to some other, incompatible protocol. |  | for transitioning from HTTP/1.1 to some other, incompatible protocol. |
| It does so by allowing the client to advertise its desire to use |  | It does so by allowing the client to advertise its desire to use |
| another protocol, such as a later version of HTTP with a higher major |  | another protocol, such as a later version of HTTP with a higher major |
| version number, even though the current request has been made using |  | version number, even though the current request has been made using |
| HTTP/1.1. This eases the difficult transition between incompatible |  | HTTP/1.1. This eases the difficult transition between incompatible |
| protocols by allowing the client to initiate a request in the more |  | protocols by allowing the client to initiate a request in the more |
| commonly supported protocol while indicating to the server that it |  | commonly supported protocol while indicating to the server that it |
| would like to use a "better" protocol if available (where "better" is |  | would like to use a "better" protocol if available (where "better" is |
| determined by the server, possibly according to the nature of the |  | determined by the server, possibly according to the nature of the |
| request method or target resource). |  | request method or target resource). |
| skipping to change at page 56, line 4 |  | skipping to change at page 57, line 32 |
| protocols upon the existing transport-layer connection. Upgrade |  | protocols upon the existing transport-layer connection. Upgrade |
| cannot be used to insist on a protocol change; its acceptance and use |  | cannot be used to insist on a protocol change; its acceptance and use |
| by the server is optional. The capabilities and nature of the |  | by the server is optional. The capabilities and nature of the |
| application-layer communication after the protocol change is entirely |  | application-layer communication after the protocol change is entirely |
| dependent upon the new protocol chosen, although the first action |  | dependent upon the new protocol chosen, although the first action |
| after changing the protocol MUST be a response to the initial HTTP |  | after changing the protocol MUST be a response to the initial HTTP |
| request containing the Upgrade header field. |  | request containing the Upgrade header field. |
| The Upgrade header field only applies to the immediate connection. |  | The Upgrade header field only applies to the immediate connection. |
| Therefore, the upgrade keyword MUST be supplied within a Connection |  | Therefore, the upgrade keyword MUST be supplied within a Connection |
| header field (Section 8.1) whenever Upgrade is present in an HTTP/1.1 |  | header field (Section 6.1) whenever Upgrade is present in an HTTP/1.1 |
| message. |  | message. |
| The Upgrade header field cannot be used to indicate a switch to a |  | The Upgrade header field cannot be used to indicate a switch to a |
| protocol on a different connection. For that purpose, it is more |  | protocol on a different connection. For that purpose, it is more |
| appropriate to use a 3xx redirection response (Section 7.3 of |  | appropriate to use a 3xx redirection response (Section 7.3 of |
| [Part2]). |  | [Part2]). |
| Servers MUST include the "Upgrade" header field in 101 (Switching |  | Servers MUST include the "Upgrade" header field in 101 (Switching |
| Protocols) responses to indicate which protocol(s) are being switched |  | Protocols) responses to indicate which protocol(s) are being switched |
| to, and MUST include it in 426 (Upgrade Required) responses to |  | to, and MUST include it in 426 (Upgrade Required) responses to |
| indicate acceptable protocols to upgrade to. Servers MAY include it |  | indicate acceptable protocols to upgrade to. Servers MAY include it |
| in any other response to indicate that they are willing to upgrade to |  | in any other response to indicate that they are willing to upgrade to |
| one of the specified protocols. |  | one of the specified protocols. |
| This specification only defines the protocol name "HTTP" for use by |  | This specification only defines the protocol name "HTTP" for use by |
| the family of Hypertext Transfer Protocols, as defined by the HTTP |  | the family of Hypertext Transfer Protocols, as defined by the HTTP |
| version rules of Section 2.6 and future updates to this |  | version rules of Section 2.6 and future updates to this |
| specification. Additional tokens can be registered with IANA using |  | specification. Additional tokens can be registered with IANA using |
| the registration procedure defined below. |  | the registration procedure defined in Section 7.6. |
| 8.7.1. Upgrade Token Registry |  |  |
| The HTTP Upgrade Token Registry defines the name space for product |  |  |
| tokens used to identify protocols in the Upgrade header field. Each |  |  |
| registered token is associated with contact information and an |  |  |
| optional set of specifications that details how the connection will |  |  |
| be processed after it has been upgraded. |  |  |
| Registrations are allowed on a First Come First Served basis as |  |  |
| described in Section 4.1 of [RFC5226]. The specifications need not |  |  |
| be IETF documents or be subject to IESG review. Registrations are |  |  |
| subject to the following rules: |  |  |
| 1. A token, once registered, stays registered forever. |  |  |
| 2. The registration MUST name a responsible party for the |  |  |
| registration. |  |  |
| 3. The registration MUST name a point of contact. |  |  |
| 4. The registration MAY name a set of specifications associated with |  |  |
| that token. Such specifications need not be publicly available. |  |  |
| 5. The responsible party MAY change the registration at any time. |  |  |
| The IANA will keep a record of all such changes, and make them |  |  |
| available upon request. |  |  |
| 6. The responsible party for the first registration of a "product" |  |  |
| token MUST approve later registrations of a "version" token |  |  |
| together with that "product" token before they can be registered. |  |  |
| 7. If absolutely required, the IESG MAY reassign the responsibility |  |  |
| for a token. This will normally only be used in the case when a |  |  |
| responsible party cannot be contacted. |  |  |
| 8.8. Via |  |  |
| The "Via" header field MUST be sent by a proxy or gateway to indicate |  |  |
| the intermediate protocols and recipients between the user agent and |  |  |
| the server on requests, and between the origin server and the client |  |  |
| on responses. It is analogous to the "Received" field used by email |  |  |
| systems (Section 3.6.7 of [RFC5322]) and is intended to be used for |  |  |
| tracking message forwards, avoiding request loops, and identifying |  |  |
| the protocol capabilities of all senders along the request/response |  |  |
| chain. |  |  |
| Via = 1#( received-protocol RWS received-by |  |  |
| [ RWS comment ] ) |  |  |
| received-protocol = [ protocol-name "/" ] protocol-version |  |  |
| protocol-name = token |  |  |
| protocol-version = token |  |  |
| received-by = ( uri-host [ ":" port ] ) / pseudonym |  |  |
| pseudonym = token |  |  |
| The received-protocol indicates the protocol version of the message |  |  |
| received by the server or client along each segment of the request/ |  |  |
| response chain. The received-protocol version is appended to the Via |  |  |
| field value when the message is forwarded so that information about |  |  |
| the protocol capabilities of upstream applications remains visible to |  |  |
| all recipients. |  |  |
| The protocol-name is excluded if and only if it would be "HTTP". The |  |  |
| received-by field is normally the host and optional port number of a |  |  |
| recipient server or client that subsequently forwarded the message. |  |  |
| However, if the real host is considered to be sensitive information, |  |  |
| it MAY be replaced by a pseudonym. If the port is not given, it MAY |  |  |
| be assumed to be the default port of the received-protocol. |  |  |
| Multiple Via field values represent each proxy or gateway that has |  |  |
| forwarded the message. Each recipient MUST append its information |  |  |
| such that the end result is ordered according to the sequence of |  |  |
| forwarding applications. |  |  |
| Comments MAY be used in the Via header field to identify the software |  |  |
| of each recipient, analogous to the User-Agent and Server header |  |  |
| fields. However, all comments in the Via field are optional and MAY |  |  |
| be removed by any recipient prior to forwarding the message. |  |  |
| 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 |  |  |
| forward the request to a public proxy at p.example.net, which |  |  |
| completes the request by forwarding it to the origin server at |  |  |
| www.example.com. The request received by www.example.com would then |  |  |
| have the following Via header field: |  |  |
| Via: 1.0 fred, 1.1 p.example.net (Apache/1.1) |  |  |
| A proxy or gateway used as a portal through a network firewall SHOULD |  |  |
| NOT forward the names and ports of hosts within the firewall region |  |  |
| unless it is explicitly enabled to do so. If not enabled, the |  |  |
| received-by host of any host behind the firewall SHOULD be replaced |  |  |
| by an appropriate pseudonym for that host. |  |  |
| For organizations that have strong privacy requirements for hiding |  |  |
| internal structures, a proxy or gateway MAY combine an ordered |  |  |
| subsequence of Via header field entries with identical received- |  |  |
| protocol values into a single such entry. For example, |  |  |
| Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy |  |  |
| could be collapsed to |  |  |
| Via: 1.0 ricky, 1.1 mertz, 1.0 lucy |  |  |
| Senders SHOULD NOT combine multiple entries unless they are all under |  | 7. IANA Considerations |
| the same organizational control and the hosts have already been |  |  |
| replaced by pseudonyms. Senders MUST NOT combine entries which have |  |  |
| different received-protocol values. |  |  |
| 9. IANA Considerations |  | 7.1. Header Field Registration |
| 9.1. Header Field Registration |  | HTTP header fields are registered within the Message Header Field |
|  |  | Registry [RFC3864] maintained by IANA at <http://www.iana.org/ |
|  |  | assignments/message-headers/message-header-index.html>. |
| The Message Header Field Registry located at <http://www.iana.org/ |  | This document defines the following HTTP header fields, so their |
| assignments/message-headers/message-header-index.html> shall be |  | associated registry entries shall be updated according to the |
| updated with the permanent registrations below (see [RFC3864]): |  | permanent registrations below: |
| +-------------------+----------+----------+-------------+ |  | +-------------------+----------+----------+---------------+ |
| | Header Field Name | Protocol | Status | Reference | |  | | Header Field Name | Protocol | Status | Reference | |
| +-------------------+----------+----------+-------------+ |  | +-------------------+----------+----------+---------------+ |
| | Connection | http | standard | Section 8.1 | |  | | Connection | http | standard | Section 6.1 | |
| | Content-Length | http | standard | Section 8.2 | |  | | Content-Length | http | standard | Section 3.3.2 | |
| | Host | http | standard | Section 8.3 | |  | | Host | http | standard | Section 5.4 | |
| | TE | http | standard | Section 8.4 | |  | | TE | http | standard | Section 4.3 | |
| | Trailer | http | standard | Section 8.5 | |  | | Trailer | http | standard | Section 4.4 | |
| | Transfer-Encoding | http | standard | Section 8.6 | |  | | Transfer-Encoding | http | standard | Section 3.3.1 | |
| | Upgrade | http | standard | Section 8.7 | |  | | Upgrade | http | standard | Section 6.5 | |
| | Via | http | standard | Section 8.8 | |  | | Via | http | standard | Section 6.2 | |
| +-------------------+----------+----------+-------------+ |  | +-------------------+----------+----------+---------------+ |
| Furthermore, the header field name "Close" shall be registered as |  | Furthermore, the header field-name "Close" shall be registered as |
| "reserved", as its use as HTTP header field would be in conflict with |  | "reserved", since using that name as an HTTP header field might |
| the use of the "close" connection option for the "Connection" header |  | conflict with the "close" connection option of the "Connection" |
| field (Section 8.1). |  | header field (Section 6.1). |
| +-------------------+----------+----------+-------------+ |  | +-------------------+----------+----------+-------------+ |
| | Header Field Name | Protocol | Status | Reference | |  | | Header Field Name | Protocol | Status | Reference | |
| +-------------------+----------+----------+-------------+ |  | +-------------------+----------+----------+-------------+ |
| | Close | http | reserved | Section 9.1 | |  | | Close | http | reserved | Section 7.1 | |
| +-------------------+----------+----------+-------------+ |  | +-------------------+----------+----------+-------------+ |
| The change controller is: "IETF (iesg@ietf.org) - Internet |  | The change controller is: "IETF (iesg@ietf.org) - Internet |
| Engineering Task Force". |  | Engineering Task Force". |
| 9.2. URI Scheme Registration |  | 7.2. URI Scheme Registration |
| The entries for the "http" and "https" URI Schemes in the registry |  | IANA maintains the registry of URI Schemes [RFC4395] at |
| located at <http://www.iana.org/assignments/uri-schemes.html> shall |  | <http://www.iana.org/assignments/uri-schemes.html>. |
| be updated to point to Sections 2.7.1 and 2.7.2 of this document (see |  |  |
| [RFC4395]). |  |  |
| 9.3. Internet Media Type Registrations |  | This document defines the following URI schemes, so their associated |
|  |  | registry entries shall be updated according to the permanent |
|  |  | registrations below: |
|  |  | +------------+------------------------------------+---------------+ |
|  |  | | URI Scheme | Description | Reference | |
|  |  | +------------+------------------------------------+---------------+ |
|  |  | | http | Hypertext Transfer Protocol | Section 2.7.1 | |
|  |  | | https | Hypertext Transfer Protocol Secure | Section 2.7.2 | |
|  |  | +------------+------------------------------------+---------------+ |
|  |  | 7.3. Internet Media Type Registrations |
| This document serves as the specification for the Internet media |  | This document serves as the specification for the Internet media |
| types "message/http" and "application/http". The following is to be |  | types "message/http" and "application/http". The following is to be |
| registered with IANA (see [RFC4288]). |  | registered with IANA (see [RFC4288]). |
| 9.3.1. Internet Media Type message/http |  | 7.3.1. Internet Media Type message/http |
| The message/http type can be used to enclose a single HTTP request or |  | The message/http type can be used to enclose a single HTTP request or |
| response message, provided that it obeys the MIME restrictions for |  | response message, provided that it obeys the MIME restrictions for |
| all "message" types regarding line length and encodings. |  | all "message" types regarding line length and encodings. |
| Type name: message |  | Type name: message |
| Subtype name: http |  | Subtype name: http |
| Required parameters: none |  | Required parameters: none |
| 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: none |
| Interoperability considerations: none |  | Interoperability considerations: none |
| Published specification: This specification (see Section 9.3.1). |  | Published specification: This specification (see Section 7.3.1). |
| Applications that use this media type: |  | Applications that use this media type: |
| Additional information: |  | Additional information: |
| Magic number(s): none |  | Magic number(s): none |
| File extension(s): none |  | File extension(s): none |
| Macintosh file type code(s): none |  | Macintosh file type code(s): none |
| Person and email address to contact for further information: See |  | Person and email address to contact for further information: See |
| Authors Section. |  | Authors Section. |
| Intended usage: COMMON |  | Intended usage: COMMON |
| Restrictions on usage: none |  | Restrictions on usage: none |
| Author/Change controller: IESG |  | Author/Change controller: IESG |
| 9.3.2. Internet Media Type application/http |  | 7.3.2. Internet Media Type application/http |
| The application/http type can be used to enclose a pipeline of one or |  | The application/http type can be used to enclose a pipeline of one or |
| more HTTP request or response messages (not intermixed). |  | more HTTP request or response messages (not intermixed). |
| Type name: application |  | Type name: application |
| Subtype name: http |  | Subtype name: http |
| Required parameters: none |  | Required parameters: none |
| Optional parameters: version, msgtype |  | Optional parameters: version, msgtype |
| version: The HTTP-Version number of the enclosed messages (e.g., |  | version: The HTTP-version number of the enclosed messages (e.g., |
| "1.1"). If not present, the version can be determined from the |  | "1.1"). If not present, the version can be determined from the |
| first line of the body. |  | first line of the body. |
| 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: none |
| Interoperability considerations: none |  | Interoperability considerations: none |
|  |  | Published specification: This specification (see Section 7.3.2). |
| Published specification: This specification (see Section 9.3.2). |  |  |
| Applications that use this media type: |  | Applications that use this media type: |
| Additional information: |  | Additional information: |
| Magic number(s): none |  | Magic number(s): none |
| File extension(s): none |  | File extension(s): none |
| Macintosh file type code(s): none |  | Macintosh file type code(s): none |
| skipping to change at page 62, line 4 |  | skipping to change at page 61, line 20 |
| Magic number(s): none |  | Magic number(s): none |
| File extension(s): none |  | File extension(s): none |
| Macintosh file type code(s): none |  | Macintosh file type code(s): none |
| Person and email address to contact for further information: See |  | Person and email address to contact for further information: See |
| Authors Section. |  | Authors Section. |
| Intended usage: COMMON |  | Intended usage: COMMON |
| Restrictions on usage: none |  | Restrictions on usage: none |
| Author/Change controller: IESG |  | Author/Change controller: IESG |
| 9.4. Transfer Coding Registry |  | 7.4. Transfer Coding Registry |
| The registration procedure for HTTP Transfer Codings is now defined |  | The HTTP Transfer Coding Registry defines the name space for transfer |
| by Section 5.1.3 of this document. |  | coding names. |
| The HTTP Transfer Codings Registry located at |  | Registrations MUST include the following fields: |
| <http://www.iana.org/assignments/http-parameters> shall be updated |  |  |
| with the registrations below: |  |  |
| +----------+--------------------------------------+-----------------+ |  | o Name |
| | Name | Description | Reference | |  |  |
| +----------+--------------------------------------+-----------------+ |  |  |
| | chunked | Transfer in a series of chunks | Section 5.1.1 | |  |  |
| | compress | UNIX "compress" program method | Section 5.1.2.1 | |  |  |
| | deflate | "deflate" compression mechanism | Section 5.1.2.2 | |  |  |
| | | ([RFC1951]) used inside the "zlib" | | |  |  |
| | | data format ([RFC1950]) | | |  |  |
| | gzip | Same as GNU zip [RFC1952] | Section 5.1.2.3 | |  |  |
| +----------+--------------------------------------+-----------------+ |  |  |
| 9.5. Upgrade Token Registration |  | o Description |
| The registration procedure for HTTP Upgrade Tokens -- previously |  | o Pointer to specification text |
| defined in Section 7.2 of [RFC2817] -- is now defined by |  |  |
| Section 8.7.1 of this document. |  |  |
| The HTTP Status Code Registry located at |  | Names of transfer codings MUST NOT overlap with names of content |
| <http://www.iana.org/assignments/http-upgrade-tokens/> shall be |  | codings (Section 2.2 of [Part3]) unless the encoding transformation |
| updated with the registration below: |  | is identical, as it is the case for the compression codings defined |
|  |  | in Section 4.2. |
| +-------+---------------------------+-------------------------------+ |  | Values to be added to this name space require IETF Review (see |
| | Value | Description | Reference | |  | Section 4.1 of [RFC5226]), and MUST conform to the purpose of |
| +-------+---------------------------+-------------------------------+ |  | transfer coding defined in this section. |
| | HTTP | Hypertext Transfer | Section 2.6 of this | |  |  |
| | | Protocol | specification | |  |  |
| +-------+---------------------------+-------------------------------+ |  |  |
| 10. Security Considerations |  | The registry itself is maintained at |
|  |  | <http://www.iana.org/assignments/http-parameters>. |
|  |  | 7.5. Transfer Coding Registrations |
|  |  | The HTTP Transfer Coding Registry shall be updated with the |
|  |  | registrations below: |
|  |  | +----------+----------------------------------------+---------------+ |
|  |  | | Name | Description | Reference | |
|  |  | +----------+----------------------------------------+---------------+ |
|  |  | | chunked | Transfer in a series of chunks | Section 4.1 | |
|  |  | | compress | UNIX "compress" program method | Section 4.2.1 | |
|  |  | | deflate | "deflate" compression mechanism | Section 4.2.2 | |
|  |  | | | ([RFC1951]) used inside the "zlib" | | |
|  |  | | | data format ([RFC1950]) | | |
|  |  | | gzip | Same as GNU zip [RFC1952] | Section 4.2.3 | |
|  |  | +----------+----------------------------------------+---------------+ |
|  |  | 7.6. Upgrade Token Registry |
|  |  | The HTTP Upgrade Token Registry defines the name space for protocol- |
|  |  | name tokens used to identify protocols in the Upgrade header field. |
|  |  | Each registered protocol-name is associated with contact information |
|  |  | and an optional set of specifications that details how the connection |
|  |  | will be processed after it has been upgraded. |
|  |  | Registrations require IETF Review (see Section 4.1 of [RFC5226]) and |
|  |  | are subject to the following rules: |
|  |  | 1. A protocol-name token, once registered, stays registered forever. |
|  |  | 2. The registration MUST name a responsible party for the |
|  |  | registration. |
|  |  | 3. The registration MUST name a point of contact. |
|  |  | 4. The registration MAY name a set of specifications associated with |
|  |  | that token. Such specifications need not be publicly available. |
|  |  | 5. The registration SHOULD name a set of expected "protocol-version" |
|  |  | tokens associated with that token at the time of registration. |
|  |  | 6. The responsible party MAY change the registration at any time. |
|  |  | The IANA will keep a record of all such changes, and make them |
|  |  | available upon request. |
|  |  | 7. The IESG MAY reassign responsibility for a protocol token. This |
|  |  | will normally only be used in the case when a responsible party |
|  |  | cannot be contacted. |
|  |  | This registration procedure for HTTP Upgrade Tokens replaces that |
|  |  | previously defined in Section 7.2 of [RFC2817]. |
|  |  | 7.7. Upgrade Token Registration |
|  |  | The HTTP Upgrade Token Registry shall be updated with the |
|  |  | registration below: |
|  |  | +-------+----------------------+----------------------+-------------+ |
|  |  | | Value | Description | Expected Version | Reference | |
|  |  | | | | Tokens | | |
|  |  | +-------+----------------------+----------------------+-------------+ |
|  |  | | HTTP | Hypertext Transfer | any DIGIT.DIGIT | Section 2.6 | |
|  |  | | | Protocol | (e.g, "2.0") | | |
|  |  | +-------+----------------------+----------------------+-------------+ |
|  |  | The responsible party is: "IETF (iesg@ietf.org) - Internet |
|  |  | Engineering Task Force". |
|  |  | 8. Security Considerations |
| This section is meant to inform application developers, information |  | This section is meant to inform application developers, information |
| providers, and users of the security limitations in HTTP/1.1 as |  | providers, and users of the security limitations in HTTP/1.1 as |
| described by this document. The discussion does not include |  | described by this document. The discussion does not include |
| definitive solutions to the problems revealed, though it does make |  | definitive solutions to the problems revealed, though it does make |
| some suggestions for reducing security risks. |  | some suggestions for reducing security risks. |
| 10.1. Personal Information |  | 8.1. Personal Information |
| HTTP clients are often privy to large amounts of personal information |  | HTTP clients are often privy to large amounts of personal information |
| (e.g., the user's name, location, mail address, passwords, encryption |  | (e.g., the user's name, location, mail address, passwords, encryption |
| keys, etc.), and SHOULD be very careful to prevent unintentional |  | keys, etc.), and SHOULD be very careful to prevent unintentional |
| leakage of this information. We very strongly recommend that a |  | leakage of this information. We very strongly recommend that a |
| convenient interface be provided for the user to control |  | convenient interface be provided for the user to control |
| dissemination of such information, and that designers and |  | dissemination of such information, and that designers and |
| implementors be particularly careful in this area. History shows |  | implementors be particularly careful in this area. History shows |
| that errors in this area often create serious security and/or privacy |  | that errors in this area often create serious security and/or privacy |
| problems and generate highly adverse publicity for the implementor's |  | problems and generate highly adverse publicity for the implementor's |
| company. |  | company. |
| 10.2. Abuse of Server Log Information |  | 8.2. Abuse of Server Log Information |
| A server is in the position to save personal data about a user's |  | A server is in the position to save personal data about a user's |
| requests which might identify their reading patterns or subjects of |  | requests which might identify their reading patterns or subjects of |
| interest. This information is clearly confidential in nature and its |  | interest. In particular, log information gathered at an intermediary |
| handling can be constrained by law in certain countries. People |  | often contains a history of user agent interaction, across a |
| using HTTP to provide data are responsible for ensuring that such |  | multitude of sites, that can be traced to individual users. |
| material is not distributed without the permission of any individuals |  |  |
| that are identifiable by the published results. |  |  |
| 10.3. Attacks Based On File and Path Names |  | HTTP log information is confidential in nature; its handling is often |
|  |  | constrained by laws and regulations. Log information needs to be |
|  |  | securely stored and appropriate guidelines followed for its analysis. |
|  |  | Anonymization of personal information within individual entries |
|  |  | helps, but is generally not sufficient to prevent real log traces |
|  |  | from being re-identified based on correlation with other access |
|  |  | characteristics. As such, access traces that are keyed to a specific |
|  |  | client should not be published even if the key is pseudonymous. |
|  |  | To minimize the risk of theft or accidental publication, log |
|  |  | information should be purged of personally identifiable information, |
|  |  | including user identifiers, IP addresses, and user-provided query |
|  |  | parameters, as soon as that information is no longer necessary to |
|  |  | support operational needs for security, auditing, or fraud control. |
|  |  | 8.3. Attacks Based On File and Path Names |
| Implementations of HTTP origin servers SHOULD be careful to restrict |  | Implementations of HTTP origin servers SHOULD be careful to restrict |
| the documents returned by HTTP requests to be only those that were |  | the documents returned by HTTP requests to be only those that were |
| intended by the server administrators. If an HTTP server translates |  | intended by the server administrators. If an HTTP server translates |
| HTTP URIs directly into file system calls, the server MUST take |  | HTTP URIs directly into file system calls, the server MUST take |
| special care not to serve files that were not intended to be |  | special care not to serve files that were not intended to be |
| delivered to HTTP clients. For example, UNIX, Microsoft Windows, and |  | delivered to HTTP clients. For example, UNIX, Microsoft Windows, and |
| other operating systems use ".." as a path component to indicate a |  | other operating systems use ".." as a path component to indicate a |
| directory level above the current one. On such a system, an HTTP |  | directory level above the current one. On such a system, an HTTP |
| server MUST disallow any such construct in the request-target if it |  | server MUST disallow any such construct in the request-target if it |
| would otherwise allow access to a resource outside those intended to |  | would otherwise allow access to a resource outside those intended to |
| be accessible via the HTTP server. Similarly, files intended for |  | be accessible via the HTTP server. Similarly, files intended for |
| reference only internally to the server (such as access control |  | reference only internally to the server (such as access control |
| files, configuration files, and script code) MUST be protected from |  | files, configuration files, and script code) MUST be protected from |
| inappropriate retrieval, since they might contain sensitive |  | inappropriate retrieval, since they might contain sensitive |
| information. Experience has shown that minor bugs in such HTTP |  | information. Experience has shown that minor bugs in such HTTP |
| server implementations have turned into security risks. |  | server implementations have turned into security risks. |
| 10.4. DNS-related Attacks |  | 8.4. DNS-related Attacks |
| HTTP clients rely heavily on the Domain Name Service (DNS), and are |  | HTTP clients rely heavily on the Domain Name Service (DNS), and are |
| thus generally prone to security attacks based on the deliberate |  | thus generally prone to security attacks based on the deliberate |
| misassociation of IP addresses and DNS names not protected by DNSSec. |  | misassociation of IP addresses and DNS names not protected by DNSSec. |
| Clients need to be cautious in assuming the validity of an IP number/ |  | Clients need to be cautious in assuming the validity of an IP number/ |
| DNS name association unless the response is protected by DNSSec |  | DNS name association unless the response is protected by DNSSec |
| ([RFC4033]). |  | ([RFC4033]). |
| 10.5. Proxies and Caching |  | 8.5. Intermediaries and Caching |
| By their very nature, HTTP proxies are men-in-the-middle, and |  | By their very nature, HTTP intermediaries are men-in-the-middle, and |
| represent an opportunity for man-in-the-middle attacks. Compromise |  | represent an opportunity for man-in-the-middle attacks. Compromise |
| of the systems on which the proxies run can result in serious |  | of the systems on which the intermediaries run can result in serious |
| security and privacy problems. Proxies have access to security- |  | security and privacy problems. Intermediaries have access to |
| related information, personal information about individual users and |  | security-related information, personal information about individual |
| organizations, and proprietary information belonging to users and |  | users and organizations, and proprietary information belonging to |
| content providers. A compromised proxy, or a proxy implemented or |  | users and content providers. A compromised intermediary, or an |
| configured without regard to security and privacy considerations, |  | intermediary implemented or configured without regard to security and |
| might be used in the commission of a wide range of potential attacks. |  | privacy considerations, might be used in the commission of a wide |
|  |  | range of potential attacks. |
| Proxy operators need to protect the systems on which proxies run as |  | Intermediaries that contain a shared cache are especially vulnerable |
| they would protect any system that contains or transports sensitive |  | to cache poisoning attacks. |
| information. In particular, log information gathered at proxies |  |  |
| often contains highly sensitive personal information, and/or |  |  |
| information about organizations. Log information needs to be |  |  |
| carefully guarded, and appropriate guidelines for use need to be |  |  |
| developed and followed. (Section 10.2). |  |  |
| Proxy implementors need to consider the privacy and security |  | Implementors need to consider the privacy and security implications |
| implications of their design and coding decisions, and of the |  | of their design and coding decisions, and of the configuration |
| configuration options they provide to proxy operators (especially the |  | options they provide to operators (especially the default |
| default configuration). |  | configuration). |
| Users of a proxy need to be aware that proxies are no trustworthier |  | Users need to be aware that intermediaries are no more trustworthy |
| than the people who run them; HTTP itself cannot solve this problem. |  | than the people who run them; HTTP itself cannot solve this problem. |
| The judicious use of cryptography, when appropriate, might suffice to |  | The judicious use of cryptography, when appropriate, might suffice to |
| protect against a broad range of security and privacy attacks. Such |  | protect against a broad range of security and privacy attacks. Such |
| cryptography is beyond the scope of the HTTP/1.1 specification. |  | cryptography is beyond the scope of the HTTP/1.1 specification. |
| 10.6. Protocol Element Size Overflows |  | 8.6. Protocol Element Size Overflows |
| Because HTTP uses mostly textual, character-delimited fields, |  | Because HTTP uses mostly textual, character-delimited fields, |
| attackers can overflow buffers in implementations, and/or perform a |  | attackers can overflow buffers in implementations, and/or perform a |
| Denial of Service against implementations that accept fields with |  | Denial of Service against implementations that accept fields with |
| unlimited lengths. |  | unlimited lengths. |
| To promote interoperability, this specification makes specific |  | To promote interoperability, this specification makes specific |
| recommendations for size limits on request-targets (Section 3.1.1.2) |  | recommendations for minimum size limits on request-line |
| and blocks of header fields (Section 3.2). These are minimum |  | (Section 3.1.1) and blocks of header fields (Section 3.2). These are |
| recommendations, chosen to be supportable even by implementations |  | minimum recommendations, chosen to be supportable even by |
| with limited resources; it is expected that most implementations will |  | implementations with limited resources; it is expected that most |
| choose substantially higher limits. |  | implementations will choose substantially higher limits. |
| This specification also provides a way for servers to reject messages |  | This specification also provides a way for servers to reject messages |
| that have request-targets that are too long (Section 7.4.15 of |  | that have request-targets that are too long (Section 7.4.12 of |
| [Part2]) or request entities that are too large (Section 7.4 of |  | [Part2]) or request entities that are too large (Section 7.4 of |
| [Part2]). |  | [Part2]). |
| Other fields (including but not limited to request methods, response |  | Other fields (including but not limited to request methods, response |
| status phrases, header field-names, and body chunks) SHOULD be |  | status phrases, header field-names, and body chunks) SHOULD be |
| limited by implementations carefully, so as to not impede |  | limited by implementations carefully, so as to not impede |
| interoperability. |  | interoperability. |
| 10.7. Denial of Service Attacks on Proxies |  | 9. Acknowledgments |
| They exist. They are hard to defend against. Research continues. |  |  |
| Beware. |  |  |
| 11. Acknowledgments |  |  |
| This document revision builds on the work that went into RFC 2616 and |  | This edition of HTTP builds on the many contributions that went into |
| its predecessors. See Section 16 of [RFC2616] for detailed |  | RFC 1945, RFC 2068, RFC 2145, and RFC 2616, including substantial |
| acknowledgements. |  | contributions made by the previous authors, editors, and working |
|  |  | group chairs: Tim Berners-Lee, Ari Luotonen, Roy T. Fielding, Henrik |
|  |  | Frystyk Nielsen, Jim Gettys, Jeffrey C. Mogul, Larry Masinter, Paul |
|  |  | J. Leach, and Mark Nottingham. See Section 16 of [RFC2616] for |
|  |  | additional acknowledgements from prior revisions. |
| Since 1999, many contributors have helped by reporting bugs, asking |  | Since 1999, the following contributors have helped improve the HTTP |
| smart questions, drafting and reviewing text, and discussing open |  | specification by reporting bugs, asking smart questions, drafting or |
| issues: |  | reviewing text, and evaluating open issues: |
| Adam Barth, Adam Roach, Addison Phillips, Adrian Chadd, Adrien de |  | Adam Barth, Adam Roach, Addison Phillips, Adrian Chadd, Adrien de |
| Croy, Alan Ford, Alan Ruttenberg, Albert Lunde, Alex Rousskov, Alexey |  | Croy, Alan Ford, Alan Ruttenberg, Albert Lunde, Alex Rousskov, Alexey |
| Melnikov, Alisha Smith, Amichai Rothman, Amit Klein, Amos Jeffries, |  | Melnikov, Alisha Smith, Amichai Rothman, Amit Klein, Amos Jeffries, |
| Andreas Maier, Andreas Petersson, Anne van Kesteren, Anthony Bryan, |  | Andreas Maier, Andreas Petersson, Anne van Kesteren, Anthony Bryan, |
| Asbjorn Ulsberg, Balachander Krishnamurthy, Barry Leiba, Ben Laurie, |  | Asbjorn Ulsberg, Balachander Krishnamurthy, Barry Leiba, Ben Laurie, |
| Benjamin Niven-Jenkins, Bil Corry, Bill Burke, Bjoern Hoehrmann, Bob |  | Benjamin Niven-Jenkins, Bil Corry, Bill Burke, Bjoern Hoehrmann, Bob |
| Scheifler, Boris Zbarsky, Brett Slatkin, Brian Kell, Brian McBarron, |  | Scheifler, Boris Zbarsky, Brett Slatkin, Brian Kell, Brian McBarron, |
| Brian Pane, Brian Smith, Bryce Nesbitt, Cameron Heavon-Jones, Carl |  | Brian Pane, Brian Smith, Bryce Nesbitt, Cameron Heavon-Jones, Carl |
| Kugler, Charles Fry, Chris Newman, Cyrus Daboo, Dale Robert Anderson, |  | Kugler, Carsten Bormann, Charles Fry, Chris Newman, Cyrus Daboo, Dale |
| Dan Winship, Daniel Stenberg, Dave Cridland, Dave Crocker, Dave |  | Robert Anderson, Dan Winship, Daniel Stenberg, Dave Cridland, Dave |
| Kristol, David Booth, David Singer, David W. Morris, Diwakar Shetty, |  | Crocker, Dave Kristol, David Booth, David Singer, David W. Morris, |
| Dmitry Kurochkin, Drummond Reed, Duane Wessels, Edward Lee, Eliot |  | Diwakar Shetty, Dmitry Kurochkin, Drummond Reed, Duane Wessels, |
| Lear, Eran Hammer-Lahav, Eric D. Williams, Eric J. Bowman, Eric |  | Edward Lee, Eliot Lear, Eran Hammer-Lahav, Eric D. Williams, Eric J. |
| Lawrence, Erik Aronesty, Florian Weimer, Frank Ellermann, Fred Bohle, |  | Bowman, Eric Lawrence, Eric Rescorla, Erik Aronesty, Florian Weimer, |
| Geoffrey Sneddon, Gervase Markham, Greg Wilkins, Harald Tveit |  | Frank Ellermann, Fred Bohle, Geoffrey Sneddon, Gervase Markham, Greg |
| Alvestrand, Harry Halpin, Helge Hess, Henrik Nordstrom, Henry S. |  | Wilkins, Harald Tveit Alvestrand, Harry Halpin, Helge Hess, Henrik |
| Thompson, Henry Story, Herbert van de Sompel, Howard Melman, Hugo |  | Nordstrom, Henry S. Thompson, Henry Story, Herbert van de Sompel, |
| Haas, Ian Hickson, Ingo Struck, J. Ross Nicoll, James H. Manger, |  | Howard Melman, Hugo Haas, Ian Hickson, Ingo Struck, J. Ross Nicoll, |
| James Lacey, James M. Snell, Jamie Lokier, Jan Algermissen, Jeff |  | James H. Manger, James Lacey, James M. Snell, Jamie Lokier, Jan |
| Hodges (for coming up with the term 'effective Request-URI'), Jeff |  | Algermissen, Jeff Hodges (for coming up with the term 'effective |
| Walden, Jim Luther, Joe D. Williams, Joe Gregorio, Joe Orton, John C. |  | Request-URI'), Jeff Walden, Jim Luther, Joe D. Williams, Joe |
| Klensin, John C. Mallery, John Cowan, John Kemp, John Panzer, John |  | Gregorio, Joe Orton, John C. Klensin, John C. Mallery, John Cowan, |
| Schneider, John Stracke, Jonas Sicking, Jonathan Moore, Jonathan |  | John Kemp, John Panzer, John Schneider, John Stracke, Jonas Sicking, |
| Rees, Jordi Ros, Joris Dobbelsteen, Josh Cohen, Julien Pierre, |  | Jonathan Billington, Jonathan Moore, Jonathan Rees, Jordi Ros, Joris |
| Jungshik Shin, Justin Chapweske, Justin Erenkrantz, Justin James, |  | Dobbelsteen, Josh Cohen, Julien Pierre, Jungshik Shin, Justin |
| Kalvinder Singh, Karl Dubost, Keith Hoffman, Keith Moore, Koen |  | Chapweske, Justin Erenkrantz, Justin James, Kalvinder Singh, Karl |
| Holtman, Konstantin Voronkov, Kris Zyp, Lisa Dusseault, Maciej |  | Dubost, Keith Hoffman, Keith Moore, Koen Holtman, Konstantin |
| Stachowiak, Marc Schneider, Marc Slemko, Mark Baker, Mark Nottingham |  | Voronkov, Kris Zyp, Lisa Dusseault, Maciej Stachowiak, Marc |
| (Working Group chair), Mark Pauley, Martin J. Duerst, Martin Thomson, |  | Schneider, Marc Slemko, Mark Baker, Mark Pauley, Markus Lanthaler, |
| Matt Lynch, Matthew Cox, Max Clark, Michael Burrows, Michael |  | Martin J. Duerst, Martin Thomson, Matt Lynch, Matthew Cox, Max Clark, |
| Hausenblas, Mike Amundsen, Mike Kelly, Mike Schinkel, Miles Sabin, |  | Michael Burrows, Michael Hausenblas, Mike Amundsen, Mike Belshe, Mike |
| Mykyta Yevstifeyev, Nathan Rixham, Nicholas Shanks, Nico Williams, |  | Kelly, Mike Schinkel, Miles Sabin, Mykyta Yevstifeyev, Nathan Rixham, |
| Nicolas Alvarez, Noah Slater, Pablo Castro, Pat Hayes, Patrick R. |  | Nicholas Shanks, Nico Williams, Nicolas Alvarez, Nicolas Mailhot, |
| McManus, Paul E. Jones, Paul Hoffman, Paul Marquess, Peter Saint- |  | Noah Slater, Pablo Castro, Pat Hayes, Patrick R. McManus, Paul E. |
| Andre, Peter Watkins, Phil Archer, Phillip Hallam-Baker, Poul-Henning |  |  |
| Kamp, Preethi Natarajan, Reto Bachmann-Gmuer, Richard Cyganiak, |  |  |
| Robert Brewer, Robert Collins, Robert O'Callahan, Robert Olofsson, |  |  |
| Robert Sayre, Robert Siemer, Robert de Wilde, Roberto Javier Godoy, |  |  |
| Ronny Widjaja, S. Mike Dierken, Salvatore Loreto, Sam Johnston, Sam |  |  |
| Ruby, Scott Lawrence (for maintaining the original issues list), Sean |  |  |
| B. Palmer, Shane McCarron, Stefan Eissing, Stefan Tilkov, Stefanos |  |  |
| Harhalakis, Stephane Bortzmeyer, Stuart Williams, Subbu Allamaraju, |  |  |
| Sylvain Hellegouarch, Tapan Divekar, Thomas Broyer, Thomas Nordin, |  |  |
| Thomas Roessler, Tim Morgan, Tim Olsen, Travis Snoozy, Tyler Close, |  |  |
| Vincent Murphy, Wenbo Zhu, Werner Baumann, Wilbur Streett, Wilfredo |  |  |
| Sanchez Vega, William A. Rowe Jr., William Chan, Willy Tarreau, |  |  |
| Xiaoshu Wang, Yaron Goland, Yngve Nysaeter Pettersen, Yogesh Bang, |  |  |
| Yutaka Oiwa, and Zed A. Shaw. |  |  |
| 12. References |  | Jones, Paul Hoffman, Paul Marquess, Peter Saint-Andre, Peter Watkins, |
|  |  | Phil Archer, Phillip Hallam-Baker, Poul-Henning Kamp, Preethi |
|  |  | Natarajan, Ray Polk, Reto Bachmann-Gmuer, Richard Cyganiak, Robert |
|  |  | Brewer, Robert Collins, Robert O'Callahan, Robert Olofsson, Robert |
|  |  | Sayre, Robert Siemer, Robert de Wilde, Roberto Javier Godoy, Ronny |
|  |  | Widjaja, S. Mike Dierken, Salvatore Loreto, Sam Johnston, Sam Ruby, |
|  |  | Scott Lawrence (for maintaining the original issues list), Sean B. |
|  |  | Palmer, Shane McCarron, Stefan Eissing, Stefan Tilkov, Stefanos |
|  |  | Harhalakis, Stephane Bortzmeyer, Stephen Farrell, Stuart Williams, |
|  |  | Subbu Allamaraju, Sylvain Hellegouarch, Tapan Divekar, Ted Hardie, |
|  |  | Thomas Broyer, Thomas Nordin, Thomas Roessler, Tim Morgan, Tim Olsen, |
|  |  | Travis Snoozy, Tyler Close, Vincent Murphy, Wenbo Zhu, Werner |
|  |  | Baumann, Wilbur Streett, Wilfredo Sanchez Vega, William A. Rowe Jr., |
|  |  | William Chan, Willy Tarreau, Xiaoshu Wang, Yaron Goland, Yngve |
|  |  | Nysaeter Pettersen, Yogesh Bang, Yutaka Oiwa, Zed A. Shaw, and Zhong |
|  |  | Yu. |
| 12.1. Normative References |  | 10. References |
|  |  | 10.1. Normative References |
| [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. |
| [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part2] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., |  | "HTTP/1.1, part 2: Message Semantics", |
| Ed., and J. Reschke, Ed., "HTTP/1.1, part 2: Message |  | draft-ietf-httpbis-p2-semantics-19 (work in progress), |
| Semantics", draft-ietf-httpbis-p2-semantics-18 (work in |  | March 2012. |
| progress), January 2012. |  |  |
| [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part3] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., |  | "HTTP/1.1, part 3: Message Payload and Content |
| Ed., and J. Reschke, Ed., "HTTP/1.1, part 3: Message |  | Negotiation", draft-ietf-httpbis-p3-payload-19 (work in |
| Payload and Content Negotiation", |  | progress), March 2012. |
| draft-ietf-httpbis-p3-payload-18 (work in progress), |  |  |
| January 2012. |  |  |
| [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part6] Fielding, R., Ed., Lafon, Y., Ed., Nottingham, M., Ed., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., |  | and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", |
| Ed., Nottingham, M., Ed., and J. Reschke, Ed., |  | draft-ietf-httpbis-p6-cache-19 (work in progress), |
| "HTTP/1.1, part 6: Caching", |  | March 2012. |
| draft-ietf-httpbis-p6-cache-18 (work in progress), |  |  |
| January 2012. |  |  |
| [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data |  | [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data |
| Format Specification version 3.3", RFC 1950, May 1996. |  | Format Specification version 3.3", RFC 1950, May 1996. |
| [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format |  | [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format |
| Specification version 1.3", RFC 1951, May 1996. |  | Specification version 1.3", RFC 1951, May 1996. |
| [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and |  | [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and |
| G. Randers-Pehrson, "GZIP file format specification |  | G. Randers-Pehrson, "GZIP file format specification |
| version 4.3", RFC 1952, May 1996. |  | version 4.3", RFC 1952, May 1996. |
| skipping to change at page 67, line 37 |  | skipping to change at page 68, line 22 |
| STD 66, RFC 3986, January 2005. |  | STD 66, RFC 3986, January 2005. |
| [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for |  | [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for |
| Syntax Specifications: ABNF", STD 68, RFC 5234, |  | Syntax Specifications: ABNF", STD 68, RFC 5234, |
| January 2008. |  | January 2008. |
| [USASCII] American National Standards Institute, "Coded Character |  | [USASCII] American National Standards Institute, "Coded Character |
| Set -- 7-bit American Standard Code for Information |  | Set -- 7-bit American Standard Code for Information |
| Interchange", ANSI X3.4, 1986. |  | Interchange", ANSI X3.4, 1986. |
| 12.2. Informative References |  | 10.2. Informative References |
| [Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and |  | [Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and |
| Politics", ACM Transactions on Internet Technology Vol. |  | Politics", ACM Transactions on Internet Technology Vol. |
| 1, #2, November 2001, |  | 1, #2, November 2001, |
| <http://arxiv.org/abs/cs.SE/0105018>. |  | <http://arxiv.org/abs/cs.SE/0105018>. |
| [Nie1997] Frystyk, H., Gettys, J., Prud'hommeaux, E., Lie, H., |  | [Nie1997] Frystyk, H., Gettys, J., Prud'hommeaux, E., Lie, H., |
| and C. Lilley, "Network Performance Effects of |  | and C. Lilley, "Network Performance Effects of |
| HTTP/1.1, CSS1, and PNG", ACM Proceedings of the ACM |  | HTTP/1.1, CSS1, and PNG", ACM Proceedings of the ACM |
| SIGCOMM '97 conference on Applications, technologies, |  | SIGCOMM '97 conference on Applications, technologies, |
| skipping to change at page 70, line 11 |  | skipping to change at page 70, line 45 |
| 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 |  | new features that will either be safely ignored by an HTTP/1.0 |
| recipient or only sent when communicating with a party advertising |  | recipient or only sent when communicating with a party advertising |
| compliance with HTTP/1.1. |  | conformance with HTTP/1.1. |
| It is beyond the scope of a protocol specification to mandate |  | It is beyond the scope of a protocol specification to mandate |
| compliance with previous versions. HTTP/1.1 was deliberately |  | conformance with previous versions. HTTP/1.1 was deliberately |
| designed, however, to make supporting previous versions easy. We |  | designed, however, to make supporting previous versions easy. We |
| would expect a general-purpose HTTP/1.1 server to understand any |  | would expect a general-purpose HTTP/1.1 server to understand any |
| valid request in the format of HTTP/1.0 and respond appropriately |  | 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, would expect an |  | safely ignored) by HTTP/1.0 clients. Likewise, we would expect an |
| HTTP/1.1 client to understand any valid HTTP/1.0 response. |  | HTTP/1.1 client 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 wherein a buggy client failed to |
| properly encode linear whitespace found in a URI reference and placed |  | properly encode linear whitespace found in a URI reference and placed |
| in 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 8.3), report an error if it is missing from an |  | field (Section 5.4), report an error if it is missing from an |
| HTTP/1.1 request, and accept absolute URIs (Section 3.1.1.2) are |  | HTTP/1.1 request, and accept absolute URIs (Section 5.3) are among |
| among the most important changes defined by HTTP/1.1. |  | the most important changes defined by HTTP/1.1. |
| Older HTTP/1.0 clients assumed a one-to-one relationship of IP |  | Older HTTP/1.0 clients assumed a one-to-one relationship of IP |
| addresses and servers; there was no other established mechanism for |  | addresses and servers; there was no other established mechanism for |
| distinguishing the intended server of a request than the IP address |  | distinguishing the intended server of a request than the IP address |
| to which that request was directed. The Host header field was |  | to which that request was directed. The Host header field was |
| introduced during the development of HTTP/1.1 and, though it was |  | introduced during the development of HTTP/1.1 and, though it was |
| quickly implemented by most HTTP/1.0 browsers, additional |  | quickly implemented by most HTTP/1.0 browsers, additional |
| requirements were placed on all HTTP/1.1 requests in order to ensure |  | requirements were placed on all HTTP/1.1 requests in order to ensure |
| complete adoption. At the time of this writing, most HTTP-based |  | complete adoption. At the time of this writing, most HTTP-based |
| services are dependent upon the Host header field for targeting |  | services are dependent upon the Host header field for targeting |
| skipping to change at page 71, line 40 |  | skipping to change at page 72, line 25 |
| Clients are also encouraged to consider the use of Connection: keep- |  | Clients are also encouraged to consider the use of Connection: keep- |
| alive in requests carefully; while they can enable persistent |  | alive in requests carefully; while they can enable persistent |
| connections with HTTP/1.0 servers, clients using them need will need |  | connections with HTTP/1.0 servers, clients using them need will need |
| to monitor the connection for "hung" requests (which indicate that |  | to monitor the connection for "hung" requests (which indicate that |
| the client ought stop sending the header), and this mechanism ought |  | the client ought stop sending the header), and this mechanism ought |
| not be used by clients at all when a proxy is being used. |  | not be used by clients at all when a proxy is being used. |
| A.2. Changes from RFC 2616 |  | A.2. Changes from RFC 2616 |
| Empty list elements in list productions have been deprecated. |  | Clarify that the string "HTTP" in the HTTP-version ABFN production is |
| (Section 1.2.1) |  |  |
| Rules about implicit linear whitespace between certain grammar |  |  |
| productions have been removed; now it's only allowed when |  |  |
| specifically pointed out in the ABNF. (Section 1.2.2) |  |  |
| Clarify that the string "HTTP" in the HTTP-Version ABFN production is |  |  |
| case sensitive. Restrict the version numbers to be single digits due |  | case sensitive. Restrict the version numbers to be single digits due |
| to the fact that implementations are known to handle multi-digit |  | to the fact that implementations are known to handle multi-digit |
| version numbers incorrectly. (Section 2.6) |  | version numbers incorrectly. (Section 2.6) |
|  |  | Update use of abs_path production from RFC 1808 to the path-absolute |
|  |  | + query components of RFC 3986. State that the asterisk form is |
|  |  | allowed for the OPTIONS request method only. (Section 5.3) |
| Require that invalid whitespace around field-names be rejected. |  | Require that invalid whitespace around field-names be rejected. |
| (Section 3.2) |  | (Section 3.2) |
|  |  | Rules about implicit linear whitespace between certain grammar |
|  |  | productions have been removed; now whitespace is only allowed where |
|  |  | specifically defined in the ABNF. (Section 3.2.1) |
| The NUL octet is no longer allowed in comment and quoted-string text. |  | The NUL octet is no longer allowed in comment and quoted-string text. |
| The quoted-pair rule no longer allows escaping control characters |  | The quoted-pair rule no longer allows escaping control characters |
| other than HTAB. Non-ASCII content in header fields and reason |  | other than HTAB. Non-ASCII content in header fields and reason |
| phrase has been obsoleted and made opaque (the TEXT rule was |  | phrase has been obsoleted and made opaque (the TEXT rule was |
| removed). (Section 3.2.3) |  | removed). (Section 3.2.4) |
|  |  | Empty list elements in list productions have been deprecated. |
|  |  | (Section 3.2.5) |
| Require recipients to handle bogus Content-Length header fields as |  | Require recipients to handle bogus Content-Length header fields as |
| errors. (Section 3.3) |  | errors. (Section 3.3) |
| Remove reference to non-existent identity transfer-coding value |  | Remove reference to non-existent identity transfer-coding value |
| tokens. (Sections 3.3 and 5.1) |  | tokens. (Sections 3.3 and 4) |
| Update use of abs_path production from RFC 1808 to the path-absolute |  |  |
| + query components of RFC 3986. State that the asterisk form is |  |  |
| allowed for the OPTIONS request method only. (Section 3.1.1.2) |  |  |
| Clarification that the chunk length does not include the count of the |  | Clarification that the chunk length does not include the count of the |
| octets in the chunk header and trailer. Furthermore disallowed line |  | octets in the chunk header and trailer. Furthermore disallowed line |
| folding in chunk extensions. (Section 5.1.1) |  | folding in chunk extensions, and deprecate their use. (Section 4.1) |
|  |  | Registration of Transfer Codings now requires IETF Review |
|  |  | (Section 7.4) |
| Remove hard limit of two connections per server. Remove requirement |  | Remove hard limit of two connections per server. Remove requirement |
| to retry a sequence of requests as long it was idempotent. Remove |  | to retry a sequence of requests as long it was idempotent. Remove |
| requirements about when servers are allowed to close connections |  | requirements about when servers are allowed to close connections |
| prematurely. (Section 6.1.4) |  | prematurely. (Section 6.3.3) |
| Remove requirement to retry requests under certain cirumstances when |  | Remove requirement to retry requests under certain cirumstances when |
| the server prematurely closes the connection. (Section 6.2) |  | the server prematurely closes the connection. (Section 6.4) |
| Change ABNF productions for header fields to only define the field |  | Change ABNF productions for header fields to only define the field |
| value. (Section 8) |  | value. |
| Clarify exactly when close connection options must be sent. |  | Clarify exactly when close connection options must be sent. |
| (Section 8.1) |  | (Section 6.1) |
| Define the semantics of the "Upgrade" header field in responses other |  | Define the semantics of the "Upgrade" header field in responses other |
| than 101 (this was incorporated from [RFC2817]). (Section 8.7) |  | than 101 (this was incorporated from [RFC2817]). (Section 6.5) |
|  |  | A.3. Changes from RFC 2817 |
|  |  | Registration of Upgrade tokens now requires IETF Review (Section 7.6) |
| Appendix B. Collected ABNF |  | Appendix B. Collected ABNF |
| BWS = OWS |  | BWS = OWS |
| Chunked-Body = *chunk last-chunk trailer-part CRLF |  |  |
| Connection = *( "," OWS ) connection-token *( OWS "," [ OWS |  | Connection = *( "," OWS ) connection-token *( OWS "," [ OWS |
| connection-token ] ) |  | connection-token ] ) |
| Content-Length = 1*DIGIT |  | Content-Length = 1*DIGIT |
| HTTP-Prot-Name = %x48.54.54.50 ; HTTP |  |  |
| HTTP-Version = HTTP-Prot-Name "/" DIGIT "." DIGIT |  |  |
| HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body |  | HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body |
| ] |  | ] |
|  |  | HTTP-name = %x48.54.54.50 ; HTTP |
|  |  | HTTP-version = HTTP-name "/" DIGIT "." DIGIT |
| Host = uri-host [ ":" port ] |  | Host = uri-host [ ":" port ] |
| Method = token |  | OWS = *( SP / HTAB ) |
| OWS = *( SP / HTAB / obs-fold ) |  |  |
| RWS = 1*( SP / HTAB / obs-fold ) |  |  |
| Reason-Phrase = *( HTAB / SP / VCHAR / obs-text ) |  |  |
| Request-Line = Method SP request-target SP HTTP-Version CRLF |  |  |
| Status-Code = 3DIGIT |  |  |
| Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF |  |  |
|  |  | 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 ) product *( OWS "," [ OWS product ] ) |  | Upgrade = *( "," OWS ) protocol *( OWS "," [ OWS protocol ] ) |
| Via = *( "," OWS ) received-protocol RWS received-by [ RWS comment ] |  | Via = *( "," OWS ) received-protocol RWS received-by [ RWS comment ] |
| *( OWS "," [ OWS received-protocol RWS received-by [ RWS comment ] ] |  | *( OWS "," [ OWS received-protocol RWS received-by [ RWS comment ] ] |
| ) |  | ) |
| absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3> |  | absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3> |
|  |  | absolute-form = absolute-URI |
|  |  | asterisk-form = "*" |
| attribute = token |  | attribute = token |
| authority = <authority, defined in [RFC3986], Section 3.2> |  | authority = <authority, defined in [RFC3986], Section 3.2> |
|  |  | authority-form = authority |
| chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF |  | chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF |
| chunk-data = 1*OCTET |  | chunk-data = 1*OCTET |
| chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-val ] ) |  | chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-val ] ) |
| chunk-ext-name = token |  | chunk-ext-name = token |
| chunk-ext-val = token / quoted-str-nf |  | chunk-ext-val = token / quoted-str-nf |
| chunk-size = 1*HEXDIG |  | chunk-size = 1*HEXDIG |
|  |  | chunked-body = *chunk last-chunk trailer-part CRLF |
| comment = "(" *( ctext / quoted-cpair / comment ) ")" |  | comment = "(" *( ctext / quoted-cpair / comment ) ")" |
| connection-token = token |  | connection-token = token |
| ctext = OWS / %x21-27 ; '!'-''' |  | ctext = OWS / %x21-27 ; '!'-''' |
| / %x2A-5B ; '*'-'[' |  | / %x2A-5B ; '*'-'[' |
| / %x5D-7E ; ']'-'~' |  | / %x5D-7E ; ']'-'~' |
| / obs-text |  | / obs-text |
| field-content = *( HTAB / SP / VCHAR / obs-text ) |  | field-content = *( HTAB / SP / VCHAR / obs-text ) |
| field-name = token |  | field-name = token |
| field-value = *( field-content / obs-fold ) |  | field-value = *( field-content / obs-fold ) |
| header-field = field-name ":" OWS field-value BWS |  | header-field = field-name ":" OWS field-value BWS |
| http-URI = "http://" authority path-abempty [ "?" query ] |  | http-URI = "http://" authority path-abempty [ "?" query ] |
| https-URI = "https://" authority path-abempty [ "?" query ] |  | https-URI = "https://" authority path-abempty [ "?" query ] |
| last-chunk = 1*"0" [ chunk-ext ] CRLF |  | last-chunk = 1*"0" [ chunk-ext ] CRLF |
| message-body = *OCTET |  | message-body = *OCTET |
|  |  | method = token |
| obs-fold = CRLF ( SP / HTAB ) |  | obs-fold = CRLF ( SP / HTAB ) |
| obs-text = %x80-FF |  | obs-text = %x80-FF |
|  |  | origin-form = path-absolute [ "?" query ] |
| partial-URI = relative-part [ "?" query ] |  | partial-URI = relative-part [ "?" query ] |
| path-abempty = <path-abempty, defined in [RFC3986], Section 3.3> |  | path-abempty = <path-abempty, defined in [RFC3986], Section 3.3> |
| path-absolute = <path-absolute, defined in [RFC3986], Section 3.3> |  | path-absolute = <path-absolute, defined in [RFC3986], Section 3.3> |
| port = <port, defined in [RFC3986], Section 3.2.3> |  | port = <port, defined in [RFC3986], Section 3.2.3> |
| product = token [ "/" product-version ] |  | protocol = protocol-name [ "/" protocol-version ] |
| product-version = token |  |  |
| protocol-name = token |  | protocol-name = token |
| protocol-version = token |  | protocol-version = token |
| pseudonym = token |  | pseudonym = token |
| qdtext = OWS / "!" / %x23-5B ; '#'-'[' |  | qdtext = OWS / "!" / %x23-5B ; '#'-'[' |
| / %x5D-7E ; ']'-'~' |  | / %x5D-7E ; ']'-'~' |
| / obs-text |  | / obs-text |
| qdtext-nf = HTAB / SP / "!" / %x23-5B ; '#'-'[' |  | qdtext-nf = HTAB / SP / "!" / %x23-5B ; '#'-'[' |
| / %x5D-7E ; ']'-'~' |  | / %x5D-7E ; ']'-'~' |
| / obs-text |  | / obs-text |
| query = <query, defined in [RFC3986], Section 3.4> |  | query = <query, defined in [RFC3986], Section 3.4> |
| quoted-cpair = "\" ( HTAB / SP / VCHAR / obs-text ) |  | quoted-cpair = "\" ( HTAB / SP / VCHAR / obs-text ) |
| quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text ) |  | quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text ) |
| quoted-str-nf = DQUOTE *( qdtext-nf / quoted-pair ) DQUOTE |  | quoted-str-nf = DQUOTE *( qdtext-nf / quoted-pair ) DQUOTE |
| quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE |  | quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE |
| qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] ) |  | qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] ) |
|  |  | 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-target = "*" / absolute-URI / ( path-absolute [ "?" query ] ) |  | request-line = method SP request-target SP HTTP-version CRLF |
| / authority |  | request-target = origin-form / absolute-form / authority-form / |
|  |  | asterisk-form |
| special = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" / |  | special = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" / |
| DQUOTE / "/" / "[" / "]" / "?" / "=" / "{" / "}" |  | DQUOTE / "/" / "[" / "]" / "?" / "=" / "{" / "}" |
| start-line = Request-Line / Status-Line |  | start-line = request-line / status-line |
|  |  | status-code = 3DIGIT |
|  |  | status-line = HTTP-version SP status-code SP reason-phrase CRLF |
| t-codings = "trailers" / ( transfer-extension [ te-params ] ) |  | t-codings = "trailers" / ( transfer-extension [ te-params ] ) |
| tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." / |  | tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." / |
| "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA |  | "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA |
| te-ext = OWS ";" OWS token [ "=" word ] |  | te-ext = OWS ";" OWS token [ "=" word ] |
| te-params = OWS ";" OWS "q=" qvalue *te-ext |  | te-params = OWS ";" OWS "q=" qvalue *te-ext |
| token = 1*tchar |  | token = 1*tchar |
| trailer-part = *( header-field CRLF ) |  | trailer-part = *( header-field CRLF ) |
| transfer-coding = "chunked" / "compress" / "deflate" / "gzip" / |  | transfer-coding = "chunked" / "compress" / "deflate" / "gzip" / |
| transfer-extension |  | transfer-extension |
| skipping to change at page 75, line 23 |  | skipping to change at page 76, line 14 |
| transfer-parameter = attribute BWS "=" BWS value |  | transfer-parameter = attribute BWS "=" BWS value |
| uri-host = <host, defined in [RFC3986], Section 3.2.2> |  | uri-host = <host, defined in [RFC3986], Section 3.2.2> |
| value = word |  | value = word |
| word = token / quoted-string |  | word = token / quoted-string |
| ABNF diagnostics: |  | ABNF diagnostics: |
| ; Chunked-Body defined but not used |  |  |
| ; Connection defined but not used |  | ; Connection defined but not used |
| ; Content-Length defined but not used |  | ; Content-Length defined but not used |
| ; HTTP-message defined but not used |  | ; HTTP-message defined but not used |
| ; Host defined but not used |  | ; Host defined but not used |
| ; TE defined but not used |  | ; TE defined but not used |
| ; Trailer defined but not used |  | ; Trailer defined but not used |
| ; Transfer-Encoding defined but not used |  | ; Transfer-Encoding defined but not used |
| ; URI-reference defined but not used |  | ; URI-reference defined but not used |
| ; Upgrade defined but not used |  | ; Upgrade defined but not used |
| ; Via defined but not used |  | ; Via defined but not used |
|  |  | ; chunked-body defined but not used |
| ; http-URI defined but not used |  | ; http-URI defined but not used |
| ; https-URI defined but not used |  | ; https-URI defined but not used |
| ; partial-URI defined but not used |  | ; partial-URI defined but not used |
| ; special defined but not used |  | ; special defined but not used |
| 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 |
| Extracted relevant partitions from [RFC2616]. |  | Extracted relevant partitions from [RFC2616]. |
| skipping to change at page 78, line 36 |  | skipping to change at page 79, line 28 |
| Ongoing work on IANA Message Header Field Registration |  | Ongoing work on IANA Message Header Field Registration |
| (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>): |  | (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>): |
| o Reference RFC 3984, and update header field registrations for |  | o Reference RFC 3984, and update header field registrations for |
| headers defined in this document. |  | headers defined in this document. |
| Ongoing work on ABNF conversion |  | Ongoing work on ABNF conversion |
| (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |  | (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |
| o Replace string literals when the string really is case-sensitive |  | o Replace string literals when the string really is case-sensitive |
| (HTTP-Version). |  | (HTTP-version). |
| C.5. Since draft-ietf-httpbis-p1-messaging-03 |  | C.5. Since draft-ietf-httpbis-p1-messaging-03 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/28>: "Connection |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/28>: "Connection |
| closing" |  | closing" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/97>: "Move |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/97>: "Move |
| registrations and registry information to IANA Considerations" |  | registrations and registry information to IANA Considerations" |
| skipping to change at page 80, line 16 |  | skipping to change at page 81, line 10 |
| encoded words" |  | encoded words" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/74>: "Character |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/74>: "Character |
| Encodings in TEXT" |  | Encodings in TEXT" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/77>: "Line Folding" |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/77>: "Line Folding" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/83>: "OPTIONS * and |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/83>: "OPTIONS * and |
| proxies" |  | proxies" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/94>: "Reason-Phrase |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/94>: "reason-phrase |
| BNF" |  | BNF" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/111>: "Use of TEXT" |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/111>: "Use of TEXT" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/118>: "Join |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/118>: "Join |
| "Differences Between HTTP Entities and RFC 2045 Entities"?" |  | "Differences Between HTTP Entities and RFC 2045 Entities"?" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/134>: "RFC822 |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/134>: "RFC822 |
| reference left in discussion of date formats" |  | reference left in discussion of date formats" |
| skipping to change at page 84, line 43 |  | skipping to change at page 85, line 31 |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle |
| ABNFs for header fields" |  | ABNFs for header fields" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/286>: "Content- |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/286>: "Content- |
| Length ABNF broken" |  | Length ABNF broken" |
| C.16. Since draft-ietf-httpbis-p1-messaging-14 |  | C.16. Since draft-ietf-httpbis-p1-messaging-14 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/273>: "HTTP-Version |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/273>: "HTTP-version |
| should be redefined as fixed length pair of DIGIT . DIGIT" |  | should be redefined as fixed length pair of DIGIT . DIGIT" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/282>: "Recommend |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/282>: "Recommend |
| minimum sizes for protocol elements" |  | minimum sizes for protocol elements" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/283>: "Set |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/283>: "Set |
| expectations around buffering" |  | expectations around buffering" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/288>: "Considering |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/288>: "Considering |
| messages in isolation" |  | messages in isolation" |
| skipping to change at page 86, line 14 |  | skipping to change at page 87, line 5 |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/323>: "intended |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/323>: "intended |
| maturity level vs normative references" |  | maturity level vs normative references" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/324>: "Intermediary |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/324>: "Intermediary |
| rewriting of queries" |  | rewriting of queries" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/158>: "Proxy- |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/158>: "Proxy- |
| Connection and Keep-Alive" |  | Connection and Keep-Alive" |
|  |  | C.20. Since draft-ietf-httpbis-p1-messaging-18 |
|  |  | Closed issues: |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/250>: "message-body |
|  |  | in CONNECT response" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/302>: "Misplaced |
|  |  | text on connection handling in p2" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/335>: "wording of |
|  |  | line folding rule" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/343>: "chunk- |
|  |  | extensions" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/346>: "make IANA |
|  |  | policy definitions consistent" |
| Index |  | Index |
| A |  | A |
| absolute-URI form (of request-target) 32 |  | absolute-form (of request-target) 41 |
| accelerator 13 |  | accelerator 11 |
| application/http Media Type 61 |  | application/http Media Type 60 |
| asterisk form (of request-target) 31 |  | asterisk-form (of request-target) 41 |
| authority form (of request-target) 32 |  | authority-form (of request-target) 41 |
| B |  | B |
| browser 10 |  | browser 7 |
| C |  | C |
| cache 14 |  | cache 12 |
| cacheable 15 |  | cacheable 12 |
| captive portal 14 |  | captive portal 11 |
| chunked (Coding Format) 36 |  | chunked (Coding Format) 34 |
| client 10 |  | client 7 |
| Coding Format |  | Coding Format |
| chunked 36 |  | chunked 34 |
| compress 38 |  | compress 36 |
| deflate 38 |  | deflate 36 |
| gzip 39 |  | gzip 36 |
| compress (Coding Format) 38 |  | compress (Coding Format) 36 |
| connection 10 |  | connection 7 |
| Connection header field 49 |  | Connection header field 47 |
| Content-Length header field 51 |  | Content-Length header field 29 |
| D |  | D |
| deflate (Coding Format) 38 |  | deflate (Coding Format) 36 |
| downstream 13 |  | downstream 10 |
| E |  | E |
| effective request URI 34 |  | effective request URI 43 |
| G |  | G |
| gateway 13 |  | gateway 11 |
| Grammar |  | Grammar |
| absolute-URI 18 |  | absolute-form 40 |
|  |  | absolute-URI 16 |
| ALPHA 7 |  | ALPHA 7 |
| attribute 35 |  | asterisk-form 40 |
| authority 18 |  | attribute 34 |
| BWS 9 |  | authority 16 |
| chunk 36 |  | authority-form 40 |
| chunk-data 36 |  | BWS 23 |
| chunk-ext 36 |  | chunk 34 |
| chunk-ext-name 36 |  | chunk-data 34 |
| chunk-ext-val 36 |  | chunk-ext 34 |
| chunk-size 36 |  | chunk-ext-name 34 |
| Chunked-Body 36 |  | chunk-ext-val 34 |
| comment 26 |  | chunk-size 34 |
| Connection 50 |  | chunked-body 34 |
| connection-token 50 |  | comment 25 |
| Content-Length 51 |  | Connection 47 |
|  |  | connection-token 47 |
|  |  | Content-Length 29 |
| CR 7 |  | CR 7 |
| CRLF 7 |  | CRLF 7 |
| ctext 26 |  | ctext 25 |
| CTL 7 |  | CTL 7 |
| date2 35 |  | date2 34 |
| date3 35 |  | date3 34 |
| DIGIT 7 |  | DIGIT 7 |
| DQUOTE 7 |  | DQUOTE 7 |
| field-content 23 |  | field-content 22 |
| field-name 23 |  | field-name 22 |
| field-value 23 |  | field-value 22 |
| header-field 23 |  | header-field 22 |
| HEXDIG 7 |  | HEXDIG 7 |
| Host 52 |  | Host 42 |
| HTAB 7 |  | HTAB 7 |
| HTTP-message 21 |  | HTTP-message 19 |
| HTTP-Prot-Name 15 |  | HTTP-name 13 |
| http-URI 18 |  | http-URI 16 |
| HTTP-Version 15 |  | HTTP-version 13 |
| https-URI 20 |  | https-URI 18 |
| last-chunk 36 |  | last-chunk 34 |
| LF 7 |  | LF 7 |
| message-body 27 |  | message-body 27 |
| Method 22 |  | method 20 |
| obs-text 26 |  | obs-fold 22 |
|  |  | obs-text 25 |
| OCTET 7 |  | OCTET 7 |
| OWS 9 |  | origin-form 40 |
| path-absolute 18 |  | OWS 23 |
| port 18 |  | path-absolute 16 |
| product 39 |  | port 16 |
| product-version 39 |  | protocol-name 49 |
| protocol-name 57 |  | protocol-version 49 |
| protocol-version 57 |  | pseudonym 49 |
| pseudonym 57 |  | qdtext 25 |
| qdtext 26 |  | qdtext-nf 34 |
| qdtext-nf 36 |  | query 16 |
| query 18 |  | quoted-cpair 26 |
| quoted-cpair 27 |  | quoted-pair 25 |
| quoted-pair 26 |  | quoted-str-nf 34 |
| quoted-str-nf 36 |  | quoted-string 25 |
| quoted-string 26 |  | qvalue 38 |
| qvalue 40 |  | reason-phrase 21 |
| Reason-Phrase 23 |  | received-by 49 |
| received-by 57 |  | received-protocol 49 |
| received-protocol 57 |  | request-line 20 |
| Request-Line 22 |  | request-target 40 |
| request-target 22 |  | RWS 23 |
| RWS 9 |  |  |
| SP 7 |  | SP 7 |
| special 26 |  | special 25 |
| start-line 21 |  | start-line 20 |
| Status-Code 23 |  | status-code 21 |
| Status-Line 23 |  | status-line 21 |
| t-codings 53 |  | t-codings 37 |
| tchar 26 |  | tchar 25 |
| TE 53 |  | TE 37 |
| te-ext 53 |  | te-ext 37 |
| te-params 53 |  | te-params 37 |
| token 26 |  | token 25 |
| Trailer 54 |  | Trailer 38 |
| trailer-part 36 |  | trailer-part 34 |
| transfer-coding 35 |  | transfer-coding 34 |
| Transfer-Encoding 54 |  | Transfer-Encoding 28 |
| transfer-extension 35 |  | transfer-extension 34 |
| transfer-parameter 35 |  | transfer-parameter 34 |
| Upgrade 55 |  | Upgrade 56 |
| uri-host 18 |  | uri-host 16 |
| URI-reference 18 |  | URI-reference 16 |
| value 35 |  | value 34 |
| VCHAR 7 |  | VCHAR 7 |
| Via 57 |  | Via 49 |
| word 26 |  | word 25 |
| gzip (Coding Format) 39 |  | gzip (Coding Format) 36 |
| H |  | H |
| header field 21 |  | header field 19 |
| Header Fields |  | Header Fields |
| Connection 49 |  | Connection 47 |
| Content-Length 51 |  | Content-Length 29 |
| Host 51 |  | Host 42 |
| TE 53 |  | TE 36 |
| Trailer 54 |  | Trailer 38 |
| Transfer-Encoding 54 |  | Transfer-Encoding 27 |
| Upgrade 55 |  | Upgrade 56 |
| Via 57 |  | Via 49 |
| header section 21 |  | header section 19 |
| headers 21 |  | headers 19 |
| Host header field 51 |  | Host header field 42 |
| http URI scheme 18 |  | http URI scheme 16 |
| https URI scheme 19 |  | https URI scheme 17 |
| I |  | I |
| inbound 13 |  | inbound 10 |
| interception proxy 14 |  | interception proxy 11 |
| intermediary 12 |  | intermediary 9 |
| M |  | M |
| Media Type |  | Media Type |
| application/http 61 |  | application/http 60 |
| message/http 59 |  | message/http 59 |
| message 10 |  | message 8 |
| message/http Media Type 59 |  | message/http Media Type 59 |
|  |  | method 20 |
| N |  | N |
| non-transforming proxy 13 |  | non-transforming proxy 10 |
| O |  | O |
| origin form (of request-target) 32 |  | origin server 7 |
| origin server 10 |  | origin-form (of request-target) 40 |
| outbound 13 |  | outbound 10 |
| P |  | P |
| proxy 13 |  | proxy 10 |
| R |  | R |
| recipient 10 |  | recipient 7 |
| request 10 |  | request 8 |
| resource 17 |  | request-target 20 |
| response 10 |  | resource 15 |
| reverse proxy 13 |  | response 8 |
|  |  | reverse proxy 11 |
| S |  | S |
| sender 10 |  | sender 7 |
| server 10 |  | server 7 |
| spider 10 |  | spider 7 |
| T |  | T |
| target resource 34 |  | target resource 39 |
| TE header field 53 |  | target URI 39 |
| Trailer header field 54 |  | TE header field 36 |
| Transfer-Encoding header field 54 |  | Trailer header field 38 |
| transforming proxy 13 |  | Transfer-Encoding header field 27 |
| transparent proxy 14 |  | transforming proxy 10 |
| tunnel 14 |  | transparent proxy 11 |
|  |  | tunnel 11 |
| U |  | U |
| Upgrade header field 55 |  | Upgrade header field 56 |
| upstream 13 |  | upstream 10 |
| URI scheme |  | URI scheme |
| http 18 |  | http 16 |
| https 19 |  | https 17 |
| user agent 10 |  | user agent 7 |
| V |  | V |
| Via header field 57 |  | Via header field 49 |
| Authors' Addresses |  | Authors' Addresses |
| Roy T. Fielding (editor) |  | Roy T. Fielding (editor) |
| Adobe Systems Incorporated |  | Adobe Systems Incorporated |
| 345 Park Ave |  | 345 Park Ave |
| San Jose, CA 95110 |  | San Jose, CA 95110 |
| USA |  | USA |
| EMail: fielding@gbiv.com |  | EMail: fielding@gbiv.com |
| URI: http://roy.gbiv.com/ |  | URI: http://roy.gbiv.com/ |
| Jim Gettys |  |  |
| Alcatel-Lucent Bell Labs |  |  |
| 21 Oak Knoll Road |  |  |
| Carlisle, MA 01741 |  |  |
| USA |  |  |
| EMail: jg@freedesktop.org |  |  |
| URI: http://gettys.wordpress.com/ |  |  |
| Jeffrey C. Mogul |  |  |
| Hewlett-Packard Company |  |  |
| HP Labs, Large Scale Systems Group |  |  |
| 1501 Page Mill Road, MS 1177 |  |  |
| Palo Alto, CA 94304 |  |  |
| USA |  |  |
| EMail: JeffMogul@acm.org |  |  |
| Henrik Frystyk Nielsen |  |  |
| Microsoft Corporation |  |  |
| 1 Microsoft Way |  |  |
| Redmond, WA 98052 |  |  |
| USA |  |  |
| EMail: henrikn@microsoft.com |  |  |
| Larry Masinter |  |  |
| Adobe Systems Incorporated |  |  |
| 345 Park Ave |  |  |
| San Jose, CA 95110 |  |  |
| USA |  |  |
| EMail: LMM@acm.org |  |  |
| URI: http://larry.masinter.net/ |  |  |
| Paul J. Leach |  |  |
| Microsoft Corporation |  |  |
| 1 Microsoft Way |  |  |
| Redmond, WA 98052 |  |  |
| EMail: paulle@microsoft.com |  |  |
| Tim Berners-Lee |  |  |
| World Wide Web Consortium |  |  |
| MIT Computer Science and Artificial Intelligence Laboratory |  |  |
| The Stata Center, Building 32 |  |  |
| 32 Vassar Street |  |  |
| Cambridge, MA 02139 |  |  |
| USA |  |  |
| EMail: timbl@w3.org |  |  |
| URI: http://www.w3.org/People/Berners-Lee/ |  |  |
| Yves Lafon (editor) |  | Yves Lafon (editor) |
| World Wide Web Consortium |  | World Wide Web Consortium |
| W3C / ERCIM |  | W3C / ERCIM |
| 2004, rte des Lucioles |  | 2004, rte des Lucioles |
| Sophia-Antipolis, AM 06902 |  | Sophia-Antipolis, AM 06902 |
| France |  | France |
| EMail: ylafon@w3.org |  | EMail: ylafon@w3.org |
| URI: http://www.raubacapeu.net/people/yves/ |  | URI: http://www.raubacapeu.net/people/yves/ |
End of changes. 312 change blocks.
| 1698 lines changed or deleted |  | 1695 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/