| draft-ietf-httpbis-p1-messaging-12.txt |  | draft-ietf-httpbis-p1-messaging-13.txt |
--- | --- | --- | --- | ---
| HTTPbis Working Group R. Fielding, Ed. |  | HTTPbis Working Group R. Fielding, Ed. |
| Internet-Draft Day Software |  | Internet-Draft Adobe |
| Obsoletes: 2616 (if approved) J. Gettys |  | Obsoletes: 2145,2616 J. Gettys |
| Updates: 2817 (if approved) Alcatel-Lucent |  | (if approved) Alcatel-Lucent |
| Intended status: Standards Track J. Mogul |  | Updates: 2817 (if approved) J. Mogul |
| Expires: April 28, 2011 HP |  | Intended status: Standards Track HP |
| H. Frystyk |  | Expires: September 15, 2011 H. Frystyk |
| Microsoft |  | Microsoft |
| L. Masinter |  | L. Masinter |
| Adobe Systems |  | Adobe |
| P. Leach |  | P. Leach |
| Microsoft |  | Microsoft |
| T. Berners-Lee |  | T. Berners-Lee |
| W3C/MIT |  | W3C/MIT |
| Y. Lafon, Ed. |  | Y. Lafon, Ed. |
| W3C |  | W3C |
| J. Reschke, Ed. |  | J. Reschke, Ed. |
| greenbytes |  | greenbytes |
| October 25, 2010 |  | March 14, 2011 |
| 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-12 |  | draft-ietf-httpbis-p1-messaging-13 |
| 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. Part 1 provides |  | "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides |
| an overview of HTTP and its associated terminology, defines the |  | an overview of HTTP and its associated terminology, defines the |
| skipping to change at page 1, line 47 |  | skipping to change at page 1, line 47 |
| frames, and describes general security concerns for implementations. |  | frames, and describes general security concerns for implementations. |
| Editorial Note (To be removed by RFC Editor) |  | Editorial Note (To be removed by RFC Editor) |
| Discussion of this draft 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). The current issues list is |  | group mailing list (ietf-http-wg@w3.org). The current issues list is |
| at <http://tools.ietf.org/wg/httpbis/trac/report/3> and related |  | at <http://tools.ietf.org/wg/httpbis/trac/report/3> and related |
| documents (including fancy diffs) can be found at |  | documents (including fancy diffs) can be found at |
| <http://tools.ietf.org/wg/httpbis/>. |  | <http://tools.ietf.org/wg/httpbis/>. |
| The changes in this draft are summarized in Appendix D.13. |  | The changes in this draft are summarized in Appendix D.14. |
| Status of This Memo |  | Status of This Memo |
| This Internet-Draft is submitted in full conformance with the |  | This Internet-Draft is submitted in full conformance with the |
| provisions of BCP 78 and BCP 79. |  | provisions of BCP 78 and BCP 79. |
| Internet-Drafts are working documents of the Internet Engineering |  | Internet-Drafts are working documents of the Internet Engineering |
| Task Force (IETF). Note that other groups may also distribute |  | Task Force (IETF). Note that other groups may also distribute |
| working documents as Internet-Drafts. The list of current Internet- |  | working documents as Internet-Drafts. The list of current Internet- |
| Drafts is at http://datatracker.ietf.org/drafts/current/. |  | Drafts is at http://datatracker.ietf.org/drafts/current/. |
| Internet-Drafts are draft documents valid for a maximum of six months |  | Internet-Drafts are draft documents valid for a maximum of six months |
| and may be updated, replaced, or obsoleted by other documents at any |  | and may be updated, replaced, or obsoleted by other documents at any |
| time. It is inappropriate to use Internet-Drafts as reference |  | time. It is inappropriate to use Internet-Drafts as reference |
| material or to cite them other than as "work in progress." |  | material or to cite them other than as "work in progress." |
| This Internet-Draft will expire on April 28, 2011. |  | This Internet-Draft will expire on September 15, 2011. |
| Copyright Notice |  | Copyright Notice |
| Copyright (c) 2010 IETF Trust and the persons identified as the |  | Copyright (c) 2011 IETF Trust and the persons identified as the |
| document authors. All rights reserved. |  | document authors. All rights reserved. |
| This document is subject to BCP 78 and the IETF Trust's Legal |  | This document is subject to BCP 78 and the IETF Trust's Legal |
| Provisions Relating to IETF Documents |  | Provisions Relating to IETF Documents |
| (http://trustee.ietf.org/license-info) in effect on the date of |  | (http://trustee.ietf.org/license-info) in effect on the date of |
| publication of this document. Please review these documents |  | publication of this document. Please review these documents |
| carefully, as they describe your rights and restrictions with respect |  | carefully, as they describe your rights and restrictions with respect |
| to this document. Code Components extracted from this document must |  | to this document. Code Components extracted from this document must |
| include Simplified BSD License text as described in Section 4.e of |  | include Simplified BSD License text as described in Section 4.e of |
| the Trust Legal Provisions and are provided without warranty as |  | the Trust Legal Provisions and are provided without warranty as |
| skipping to change at page 3, line 5 |  | skipping to change at page 3, line 5 |
| 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. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7 |  | 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7 |
| 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7 |  | 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7 |
| 1.2.1. ABNF Extension: #rule . . . . . . . . . . . . . . . . 7 |  | 1.2.1. ABNF Extension: #rule . . . . . . . . . . . . . . . . 7 |
| 1.2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . 8 |  | 1.2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . 8 |
| 1.2.3. ABNF Rules defined in other Parts of the |  |  |
| Specification . . . . . . . . . . . . . . . . . . . . 10 |  |  |
| 2. HTTP-related architecture . . . . . . . . . . . . . . . . . . 10 |  | 2. HTTP-related architecture . . . . . . . . . . . . . . . . . . 10 |
| 2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 10 |  | 2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 10 |
| 2.2. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 12 |  | 2.2. Connections and Transport Independence . . . . . . . . . . 12 |
| 2.3. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 13 |  | 2.3. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 12 |
| 2.4. Transport Independence . . . . . . . . . . . . . . . . . . 14 |  | 2.4. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 14 |
| 2.5. HTTP Version . . . . . . . . . . . . . . . . . . . . . . . 14 |  | 2.5. Protocol Versioning . . . . . . . . . . . . . . . . . . . 15 |
| 2.6. Uniform Resource Identifiers . . . . . . . . . . . . . . . 16 |  | 2.6. Uniform Resource Identifiers . . . . . . . . . . . . . . . 17 |
| 2.6.1. http URI scheme . . . . . . . . . . . . . . . . . . . 16 |  | 2.6.1. http URI scheme . . . . . . . . . . . . . . . . . . . 18 |
| 2.6.2. https URI scheme . . . . . . . . . . . . . . . . . . . 18 |  | 2.6.2. https URI scheme . . . . . . . . . . . . . . . . . . . 19 |
| 2.6.3. http and https URI Normalization and Comparison . . . 18 |  | 2.6.3. http and https URI Normalization and Comparison . . . 20 |
| 3. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . . 19 |  | 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 20 |
| 3.1. Message Parsing Robustness . . . . . . . . . . . . . . . . 20 |  | 3.1. Message Parsing Robustness . . . . . . . . . . . . . . . . 21 |
| 3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 20 |  | 3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 22 |
| 3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 22 |  | 3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 24 |
| 3.4. General Header Fields . . . . . . . . . . . . . . . . . . 25 |  | 3.4. General Header Fields . . . . . . . . . . . . . . . . . . 27 |
| 4. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 |  | 4. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 |
| 4.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 26 |  | 4.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 28 |
| 4.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 26 |  | 4.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 28 |
| 4.1.2. request-target . . . . . . . . . . . . . . . . . . . . 27 |  | 4.1.2. request-target . . . . . . . . . . . . . . . . . . . . 28 |
| 4.2. The Resource Identified by a Request . . . . . . . . . . . 29 |  | 4.2. The Resource Identified by a Request . . . . . . . . . . . 30 |
| 4.3. Effective Request URI . . . . . . . . . . . . . . . . . . 29 |  | 4.3. Effective Request URI . . . . . . . . . . . . . . . . . . 31 |
| 5. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 |  | 5. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 |
| 5.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 31 |  | 5.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 33 |
| 5.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 31 |  | 5.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 33 |
| 6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 32 |  | 6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 33 |
| 6.1. Date/Time Formats: Full Date . . . . . . . . . . . . . . . 32 |  | 6.1. Date/Time Formats: Full Date . . . . . . . . . . . . . . . 33 |
| 6.2. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 34 |  | 6.2. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 36 |
| 6.2.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 35 |  | 6.2.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 37 |
| 6.2.2. Compression Codings . . . . . . . . . . . . . . . . . 37 |  | 6.2.2. Compression Codings . . . . . . . . . . . . . . . . . 39 |
| 6.2.3. Transfer Coding Registry . . . . . . . . . . . . . . . 38 |  | 6.2.3. Transfer Coding Registry . . . . . . . . . . . . . . . 40 |
| 6.3. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 39 |  | 6.3. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 41 |
| 6.4. Quality Values . . . . . . . . . . . . . . . . . . . . . . 39 |  | 6.4. Quality Values . . . . . . . . . . . . . . . . . . . . . . 41 |
| 7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 39 |  | 7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 41 |
| 7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 40 |  | 7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 42 |
| 7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 40 |  | 7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 42 |
| 7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 40 |  | 7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 42 |
| 7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 42 |  | 7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 44 |
| 7.1.4. Practical Considerations . . . . . . . . . . . . . . . 44 |  | 7.1.4. Practical Considerations . . . . . . . . . . . . . . . 46 |
| 7.2. Message Transmission Requirements . . . . . . . . . . . . 45 |  | 7.2. Message Transmission Requirements . . . . . . . . . . . . 47 |
| 7.2.1. Persistent Connections and Flow Control . . . . . . . 45 |  | 7.2.1. Persistent Connections and Flow Control . . . . . . . 47 |
| 7.2.2. Monitoring Connections for Error Status Messages . . . 45 |  | 7.2.2. Monitoring Connections for Error Status Messages . . . 47 |
| 7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 46 |  | 7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 48 |
| 7.2.4. Client Behavior if Server Prematurely Closes |  | 7.2.4. Client Behavior if Server Prematurely Closes |
| Connection . . . . . . . . . . . . . . . . . . . . . . 48 |  | Connection . . . . . . . . . . . . . . . . . . . . . . 50 |
| 8. Miscellaneous notes that might disappear . . . . . . . . . . . 49 |  | 8. Miscellaneous notes that might disappear . . . . . . . . . . . 51 |
| 8.1. Scheme aliases considered harmful . . . . . . . . . . . . 49 |  | 8.1. Scheme aliases considered harmful . . . . . . . . . . . . 51 |
| 8.2. Use of HTTP for proxy communication . . . . . . . . . . . 49 |  | 8.2. Use of HTTP for proxy communication . . . . . . . . . . . 51 |
| 8.3. Interception of HTTP for access control . . . . . . . . . 49 |  | 8.3. Interception of HTTP for access control . . . . . . . . . 51 |
| 8.4. Use of HTTP by other protocols . . . . . . . . . . . . . . 49 |  | 8.4. Use of HTTP by other protocols . . . . . . . . . . . . . . 51 |
| 8.5. Use of HTTP by media type specification . . . . . . . . . 49 |  | 8.5. Use of HTTP by media type specification . . . . . . . . . 51 |
| 9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 49 |  | 9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 51 |
| 9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 49 |  | 9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 51 |
| 9.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 50 |  | 9.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 53 |
| 9.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 |  | 9.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 |
| 9.3.1. Clockless Origin Server Operation . . . . . . . . . . 52 |  | 9.3.1. Clockless Origin Server Operation . . . . . . . . . . 54 |
| 9.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 |  | 9.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 |
| 9.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 |  | 9.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 |
| 9.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 54 |  | 9.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 57 |
| 9.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 55 |  | 9.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 58 |
| 9.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 55 |  | 9.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 58 |
| 9.8.1. Upgrade Token Registry . . . . . . . . . . . . . . . . 56 |  | 9.8.1. Upgrade Token Registry . . . . . . . . . . . . . . . . 59 |
| 9.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 |  | 9.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 |
| 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59 |  | 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 62 |
| 10.1. Header Field Registration . . . . . . . . . . . . . . . . 59 |  | 10.1. Header Field Registration . . . . . . . . . . . . . . . . 62 |
| 10.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 59 |  | 10.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 62 |
| 10.3. Internet Media Type Registrations . . . . . . . . . . . . 59 |  | 10.3. Internet Media Type Registrations . . . . . . . . . . . . 62 |
| 10.3.1. Internet Media Type message/http . . . . . . . . . . . 59 |  | 10.3.1. Internet Media Type message/http . . . . . . . . . . . 62 |
| 10.3.2. Internet Media Type application/http . . . . . . . . . 61 |  | 10.3.2. Internet Media Type application/http . . . . . . . . . 64 |
| 10.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 62 |  | 10.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 65 |
| 10.5. Upgrade Token Registration . . . . . . . . . . . . . . . . 62 |  | 10.5. Upgrade Token Registration . . . . . . . . . . . . . . . . 65 |
| 11. Security Considerations . . . . . . . . . . . . . . . . . . . 62 |  | 11. Security Considerations . . . . . . . . . . . . . . . . . . . 65 |
| 11.1. Personal Information . . . . . . . . . . . . . . . . . . . 63 |  | 11.1. Personal Information . . . . . . . . . . . . . . . . . . . 66 |
| 11.2. Abuse of Server Log Information . . . . . . . . . . . . . 63 |  | 11.2. Abuse of Server Log Information . . . . . . . . . . . . . 66 |
| 11.3. Attacks Based On File and Path Names . . . . . . . . . . . 63 |  | 11.3. Attacks Based On File and Path Names . . . . . . . . . . . 66 |
| 11.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 63 |  | 11.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 66 |
| 11.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 64 |  | 11.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 67 |
| 11.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 65 |  | 11.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 68 |
| 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 65 |  | 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 68 |
| 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 66 |  | 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 69 |
| 13.1. Normative References . . . . . . . . . . . . . . . . . . . 66 |  | 13.1. Normative References . . . . . . . . . . . . . . . . . . . 69 |
| 13.2. Informative References . . . . . . . . . . . . . . . . . . 68 |  | 13.2. Informative References . . . . . . . . . . . . . . . . . . 71 |
| Appendix A. Tolerant Applications . . . . . . . . . . . . . . . . 70 |  | Appendix A. Tolerant Applications . . . . . . . . . . . . . . . . 74 |
| Appendix B. Compatibility with Previous Versions . . . . . . . . 71 |  | Appendix B. HTTP Version History . . . . . . . . . . . . . . . . 75 |
| B.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 71 |  | B.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 75 |
| B.1.1. Changes to Simplify Multi-homed Web Servers and |  | B.1.1. Multi-homed Web Servers . . . . . . . . . . . . . . . 76 |
| Conserve IP Addresses . . . . . . . . . . . . . . . . 72 |  | B.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 76 |
| B.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 72 |  | B.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 77 |
| B.3. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 73 |  | Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 77 |
| Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 74 |  |  |
| Appendix D. Change Log (to be removed by RFC Editor before |  | Appendix D. Change Log (to be removed by RFC Editor before |
| publication) . . . . . . . . . . . . . . . . . . . . 78 |  | publication) . . . . . . . . . . . . . . . . . . . . 82 |
| D.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 78 |  | D.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 82 |
| D.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 78 |  | D.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 82 |
| D.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 80 |  | D.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 83 |
| D.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 81 |  | D.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 84 |
| D.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 81 |  | D.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 85 |
| D.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 82 |  | D.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 85 |
| D.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 82 |  | D.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 86 |
| D.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 83 |  | D.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 87 |
| D.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 84 |  | D.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 87 |
| D.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 84 |  | D.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 88 |
| D.11. Since draft-ietf-httpbis-p1-messaging-09 . . . . . . . . . 85 |  | D.11. Since draft-ietf-httpbis-p1-messaging-09 . . . . . . . . . 88 |
| D.12. Since draft-ietf-httpbis-p1-messaging-10 . . . . . . . . . 85 |  | D.12. Since draft-ietf-httpbis-p1-messaging-10 . . . . . . . . . 89 |
| D.13. Since draft-ietf-httpbis-p1-messaging-11 . . . . . . . . . 86 |  | D.13. Since draft-ietf-httpbis-p1-messaging-11 . . . . . . . . . 89 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 |  | D.14. Since draft-ietf-httpbis-p1-messaging-12 . . . . . . . . . 90 |
|  |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 |
| 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 request targets and |  | Identifier (URI) standard [RFC3986] to indicate the target resource |
| relationships between resources. Messages are passed in a format |  | and relationships between resources. Messages are passed in a format |
| similar to that used by Internet mail [RFC5322] and the Multipurpose |  | similar to that used by Internet mail [RFC5322] and the Multipurpose |
| Internet Mail Extensions (MIME) [RFC2045] (see Appendix A of [Part3] |  | Internet Mail Extensions (MIME) [RFC2045] (see Appendix A of [Part3] |
| for the differences between HTTP and MIME messages). |  | 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 |
| skipping to change at page 6, line 45 |  | skipping to change at page 6, line 45 |
| defined in terms of what occurs behind the interface. Instead, we |  | defined in terms of what occurs behind the interface. Instead, we |
| are limited to defining the syntax of communication, the intent of |  | are limited to defining the syntax of communication, the intent of |
| received communication, and the expected behavior of recipients. If |  | received communication, and the expected behavior of recipients. If |
| the communication is considered in isolation, then successful actions |  | the communication is considered in isolation, then successful actions |
| ought to be reflected in corresponding changes to the observable |  | ought to be reflected in corresponding changes to the observable |
| interface provided by servers. However, since multiple clients might |  | interface provided by servers. However, since multiple clients might |
| act in parallel and perhaps at cross-purposes, we cannot require that |  | act in parallel and perhaps at cross-purposes, we cannot require that |
| such changes be observable beyond the scope of a single response. |  | such changes be observable beyond the scope of a single response. |
| This document is Part 1 of the seven-part specification of HTTP, |  | This document is Part 1 of the seven-part specification of HTTP, |
| defining the protocol referred to as "HTTP/1.1" and obsoleting |  | defining the protocol referred to as "HTTP/1.1", obsoleting [RFC2616] |
| [RFC2616]. Part 1 describes the architectural elements that are used |  | and [RFC2145]. Part 1 describes the architectural elements that are |
| or referred to in HTTP, defines the "http" and "https" URI schemes, |  | used or referred to in HTTP, defines the "http" and "https" URI |
| describes overall network operation and connection management, and |  | schemes, describes overall network operation and connection |
| defines HTTP message framing and forwarding requirements. Our goal |  | management, and defines HTTP message framing and forwarding |
| is to define all of the mechanisms necessary for HTTP message |  | requirements. Our goal is to define all of the mechanisms necessary |
| handling that are independent of message semantics, thereby defining |  | for HTTP message handling that are independent of message semantics, |
| the complete set of requirements for message parsers and message- |  | thereby defining the complete set of requirements for message parsers |
| forwarding intermediaries. |  | and message-forwarding intermediaries. |
| 1.1. Requirements |  | 1.1. Requirements |
| 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]. |
| An implementation is not compliant if it fails to satisfy one or more |  | An implementation is not compliant if it fails to satisfy one or more |
| of the "MUST" or "REQUIRED" level requirements for the protocols it |  | of the "MUST" or "REQUIRED" level requirements for the protocols it |
| implements. An implementation that satisfies all the "MUST" or |  | implements. An implementation that satisfies all the "MUST" or |
| skipping to change at page 9, line 9 |  | skipping to change at page 9, line 9 |
| 1.2.2. Basic Rules |  | 1.2.2. Basic Rules |
| HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all |  | HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all |
| protocol elements other than the message-body (see Appendix A for |  | protocol elements other than the message-body (see Appendix A for |
| tolerant applications). |  | tolerant applications). |
| This specification uses three rules to denote the use of linear |  | This specification uses three rules to denote the use of linear |
| whitespace: OWS (optional whitespace), RWS (required whitespace), and |  | whitespace: OWS (optional whitespace), RWS (required whitespace), and |
| BWS ("bad" whitespace). |  | BWS ("bad" whitespace). |
| The OWS rule is used where zero or more linear whitespace characters |  | The OWS rule is used where zero or more linear whitespace octets |
| might appear. OWS SHOULD either not be produced or be produced as a |  | might appear. OWS SHOULD either not be produced or be produced as a |
| single SP character. Multiple OWS characters that occur within |  | single SP. Multiple OWS octets that occur within field-content |
| field-content SHOULD be replaced with a single SP before interpreting |  |  |
| the field value or forwarding the message downstream. |  |  |
| RWS is used when at least one linear whitespace character is required |  |  |
| to separate field tokens. RWS SHOULD be produced as a single SP |  |  |
| character. Multiple RWS characters that occur within field-content |  |  |
| SHOULD be replaced with a single SP before interpreting the field |  | SHOULD be replaced with a single SP before interpreting the field |
| value or forwarding the message downstream. |  | 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 be |
|  |  | replaced with a single SP before interpreting the field value or |
|  |  | forwarding the message downstream. |
| BWS is used where the grammar allows optional whitespace for |  | BWS is used where the grammar allows optional whitespace for |
| historical reasons but senders SHOULD NOT produce it in messages. |  | historical reasons but senders SHOULD NOT produce it in messages. |
| HTTP/1.1 recipients MUST accept such bad optional whitespace and |  | HTTP/1.1 recipients MUST accept such bad optional whitespace and |
| remove it before interpreting the field value or forwarding the |  | remove it before interpreting the field value or forwarding the |
| message downstream. |  | message downstream. |
| OWS = *( [ obs-fold ] WSP ) |  | OWS = *( [ obs-fold ] WSP ) |
| ; "optional" whitespace |  | ; "optional" whitespace |
| RWS = 1*( [ obs-fold ] WSP ) |  | RWS = 1*( [ obs-fold ] WSP ) |
| ; "required" whitespace |  | ; "required" whitespace |
| skipping to change at page 10, line 14 |  | skipping to change at page 10, line 14 |
| / "]" / "?" / "=" / "{" / "}" |  | / "]" / "?" / "=" / "{" / "}" |
| A string of text is parsed as a single word if it is quoted using |  | A string of text is parsed as a single word if it is quoted using |
| double-quote marks. |  | double-quote marks. |
| quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE |  | quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE |
| qdtext = OWS / %x21 / %x23-5B / %x5D-7E / obs-text |  | qdtext = OWS / %x21 / %x23-5B / %x5D-7E / obs-text |
| ; OWS / <VCHAR except DQUOTE and "\"> / obs-text |  | ; OWS / <VCHAR except DQUOTE and "\"> / obs-text |
| obs-text = %x80-FF |  | obs-text = %x80-FF |
| The backslash character ("\") can be used as a single-character |  | The backslash octet ("\") can be used as a single-octet quoting |
| quoting mechanism within quoted-string constructs: |  | mechanism within quoted-string constructs: |
| quoted-pair = "\" ( WSP / VCHAR / obs-text ) |  | quoted-pair = "\" ( WSP / VCHAR / obs-text ) |
| Producers SHOULD NOT escape characters that do not require escaping |  | Senders SHOULD NOT escape octets that do not require escaping (i.e., |
| (i.e., other than DQUOTE and the backslash character). |  | other than DQUOTE and the backslash octet). |
| 1.2.3. ABNF Rules defined in other Parts of the Specification |  |  |
| The ABNF rules below are defined in other parts: |  |  |
| request-header = <request-header, defined in [Part2], Section 3> |  |  |
| response-header = <response-header, defined in [Part2], Section 5> |  |  |
| MIME-Version = <MIME-Version, defined in [Part3], Appendix A.1> |  |  |
| Cache-Control = <Cache-Control, defined in [Part6], Section 3.4> |  |  |
| Pragma = <Pragma, defined in [Part6], Section 3.4> |  |  |
| Warning = <Warning, defined in [Part6], Section 3.6> |  |  |
| 2. HTTP-related architecture |  | 2. HTTP-related 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 12, line 19 |  | skipping to change at page 12, line 5 |
| 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. Intermediaries |  | 2.2. Connections and Transport Independence |
| A more complicated situation occurs when one or more intermediaries |  | HTTP messaging is independent of the underlying transport or session- |
| are present in the request/response chain. There are three common |  | layer connection protocol(s). HTTP only presumes a reliable |
| forms of intermediary: proxy, gateway, and tunnel. In some cases, a |  | transport with in-order delivery of requests and the corresponding |
| single intermediary might act as an origin server, proxy, gateway, or |  | in-order delivery of responses. The mapping of HTTP request and |
|  |  | response structures onto the data units of the underlying transport |
|  |  | protocol is outside the scope of this specification. |
|  |  | The specific connection protocols to be used for an interaction are |
|  |  | determined by client configuration and the target resource's URI. |
|  |  | For example, the "http" URI scheme (Section 2.6.1) indicates a |
|  |  | 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 |
|  |  | connection port or protocol instead of using the defaults. |
|  |  | A connection might be used for multiple HTTP request/response |
|  |  | exchanges, as defined in Section 7.1. |
|  |  | 2.3. Intermediaries |
|  |  | HTTP enables the use of intermediaries to satisfy requests through a |
|  |  | chain of connections. There are three common forms of HTTP |
|  |  | intermediary: proxy, gateway, and tunnel. In some cases, a single |
|  |  | 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 |
| < < < < |  | < < < < |
| The figure above shows three intermediaries (A, B, and C) between the |  | The figure above shows three intermediaries (A, B, and C) between the |
| user agent and origin server. A request or response message that |  | user agent and origin server. A request or response message that |
| travels the whole chain will pass through four separate connections. |  | travels the whole chain will pass through four separate connections. |
| Some HTTP communication options might apply only to the connection |  | Some HTTP communication options might apply only to the connection |
| skipping to change at page 13, line 11 |  | skipping to change at page 13, line 16 |
| A "proxy" is a message forwarding agent that is selected by the |  | A "proxy" is a message forwarding agent that is selected by the |
| client, usually via local configuration rules, to receive requests |  | client, usually via local configuration rules, to receive requests |
| for some type(s) of absolute URI and attempt to satisfy those |  | for some type(s) of absolute URI and attempt to satisfy those |
| requests via translation through the HTTP interface. Some |  | requests via translation through the HTTP interface. Some |
| translations are minimal, such as for proxy requests for "http" URIs, |  | translations are minimal, such as for proxy requests for "http" URIs, |
| whereas other requests might require translation to and from entirely |  | whereas other requests might require translation to and from entirely |
| different application-layer protocols. Proxies are often used to |  | different application-layer protocols. Proxies are often used to |
| group an organization's HTTP requests through a common intermediary |  | group an organization's HTTP requests through a common intermediary |
| for the sake of security, annotation services, or shared caching. |  | for the sake of security, annotation services, or shared caching. |
|  |  | An HTTP-to-HTTP proxy is called a "transforming proxy" if it is |
|  |  | designed or configured to modify request or response messages in a |
|  |  | semantically meaningful way (i.e., modifications, beyond those |
|  |  | required by normal HTTP processing, that change the message in a way |
|  |  | that would be significant to the original sender or potentially |
|  |  | significant to downstream recipients). For example, a transforming |
|  |  | proxy might be acting as a shared annotation server (modifying |
|  |  | responses to include references to a local annotation database), a |
|  |  | malware filter, a format transcoder, or an intranet-to-Internet |
|  |  | privacy filter. Such transformations are presumed to be desired by |
|  |  | the client (or client organization) that selected the proxy and are |
|  |  | beyond the scope of this specification. However, when a proxy is not |
|  |  | intended to transform a given message, we use the term "non- |
|  |  | transforming proxy" to target requirements that preserve HTTP message |
|  |  | semantics. |
| A "gateway" (a.k.a., "reverse proxy") is a receiving agent that acts |  | A "gateway" (a.k.a., "reverse proxy") is a receiving agent that acts |
| as a layer above some other server(s) and translates the received |  | as a layer above some other server(s) and translates the received |
| requests to the underlying server's protocol. Gateways are often |  | requests to the underlying server's protocol. Gateways are often |
| used for load balancing or partitioning HTTP services across multiple |  | used to encapsulate legacy or untrusted information services, to |
| machines. Unlike a proxy, a gateway receives requests as if it were |  | improve server performance through "accelerator" caching, and to |
| the origin server for the target resource; the requesting client will |  | enable partitioning or load-balancing of HTTP services across |
| not be aware that it is communicating with a gateway. A gateway |  | multiple machines. |
| communicates with the client as if the gateway is the origin server |  |  |
| and thus is subject to all of the requirements on origin servers for |  | A gateway behaves as an origin server on its outbound connection and |
| that connection. A gateway communicates with inbound servers using |  | as a user agent on its inbound connection. All HTTP requirements |
| any protocol it desires, including private extensions to HTTP that |  | applicable to an origin server also apply to the outbound |
| are outside the scope of this specification. |  | communication of a gateway. A gateway communicates with inbound |
|  |  | servers using any protocol that it desires, including private |
|  |  | extensions to HTTP that are outside the scope of this specification. |
|  |  | However, an HTTP-to-HTTP gateway that wishes to interoperate with |
|  |  | third-party HTTP servers MUST comply with HTTP user agent |
|  |  | requirements on the gateway's inbound connection and MUST implement |
|  |  | the Connection (Section 9.1) and Via (Section 9.9) header fields for |
|  |  | both 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. |
| 2.3. Caches |  | In addition, there may exist network intermediaries that are not |
|  |  | considered part of the HTTP communication but nevertheless act as |
|  |  | filters or redirecting agents (usually violating HTTP semantics, |
|  |  | causing security problems, and otherwise making a mess of things). |
|  |  | Such a network intermediary, often referred to as an "interception |
|  |  | proxy" [RFC3040], "transparent proxy" [RFC1919], or "captive portal", |
|  |  | differs from an HTTP proxy because it has not been selected by the |
|  |  | client. Instead, the network intermediary redirects outgoing TCP |
|  |  | port 80 packets (and occasionally other common port traffic) to an |
|  |  | internal HTTP server. Interception proxies are commonly found on |
|  |  | public network access points, as a means of enforcing account |
|  |  | subscription prior to allowing use of non-local Internet services, |
|  |  | and within corporate firewalls to enforce network usage policies. |
|  |  | They are indistinguishable from a man-in-the-middle attack. |
|  |  | 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 14, line 20 |  | skipping to change at page 15, line 14 |
| 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.4. Transport Independence |  | 2.5. Protocol Versioning |
| HTTP systems are used in a wide variety of environments, from |  |  |
| corporate intranets with high-bandwidth links to long-distance |  |  |
| communication over low-power radio links and intermittent |  |  |
| connectivity. |  |  |
| HTTP communication usually takes place over TCP/IP connections. The |  |  |
| default port is TCP 80 |  |  |
| (<http://www.iana.org/assignments/port-numbers>), but other ports can |  |  |
| be used. This does not preclude HTTP from being implemented on top |  |  |
| of any other protocol on the Internet, or on other networks. HTTP |  |  |
| only presumes a reliable transport; any protocol that provides such |  |  |
| guarantees can be used; the mapping of the HTTP/1.1 request and |  |  |
| response structures onto the transport data units of the protocol in |  |  |
| question is outside the scope of this specification. |  |  |
| In HTTP/1.0, most implementations used a new connection for each |  |  |
| request/response exchange. In HTTP/1.1, a connection might be used |  |  |
| for one or more request/response exchanges, although connections |  |  |
| might be closed for a variety of reasons (see Section 7.1). |  |  |
| 2.5. HTTP Version |  |  |
| HTTP uses a "<major>.<minor>" numbering scheme to indicate versions |  | HTTP uses a "<major>.<minor>" numbering scheme to indicate versions |
| of the protocol. The protocol versioning policy is intended to allow |  | of the protocol. This specification defines version "1.1". The |
| the sender to indicate the format of a message and its capacity for |  | protocol version as a whole indicates the sender's compliance with |
| understanding further HTTP communication, rather than the features |  | the set of requirements laid out in that version's corresponding |
| obtained via that communication. No change is made to the version |  | specification of HTTP. |
| number for the addition of message components which do not affect |  |  |
| communication behavior or which only add to extensible field values. |  |  |
| The <minor> number is incremented when the changes made to the |  |  |
| protocol add features which do not change the general message parsing |  |  |
| algorithm, but which might add to the message semantics and imply |  |  |
| additional capabilities of the sender. The <major> number is |  |  |
| incremented when the format of a message within the protocol is |  |  |
| changed. See [RFC2145] for a fuller explanation. |  |  |
| 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 "/" 1*DIGIT "." 1*DIGIT |  | HTTP-Version = HTTP-Prot-Name "/" 1*DIGIT "." 1*DIGIT |
| HTTP-Prot-Name = %x48.54.54.50 ; "HTTP", case-sensitive |  | HTTP-Prot-Name = %x48.54.54.50 ; "HTTP", case-sensitive |
| Note that the major and minor numbers MUST be treated as separate |  | The HTTP version number consists of two non-negative decimal integers |
| integers and that each MAY be incremented higher than a single digit. |  | separated by a "." (period or decimal point). The first number |
| Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is |  | ("major version") indicates the HTTP messaging syntax, whereas the |
| lower than HTTP/12.3. Leading zeros MUST be ignored by recipients |  | second number ("minor version") indicates the highest minor version |
| and MUST NOT be sent. |  | to which the sender is at least conditionally compliant and able to |
|  |  | understand for future communication. The minor version advertises |
|  |  | the sender's communication capabilities even when the sender is only |
|  |  | using a backwards-compatible subset of the protocol, thereby letting |
|  |  | the recipient know that more advanced features can be used in |
|  |  | response (by servers) or in future requests (by clients). |
| An application that sends a request or response message that includes |  | When comparing HTTP versions, the numbers MUST be compared |
| HTTP-Version of "HTTP/1.1" MUST be at least conditionally compliant |  | numerically rather than lexically. For example, HTTP/2.4 is a lower |
| with this specification. Applications that are at least |  | version than HTTP/2.13, which in turn is lower than HTTP/12.3. |
| conditionally compliant with this specification SHOULD use an HTTP- |  | Leading zeros MUST be ignored by recipients and MUST NOT be sent. |
| Version of "HTTP/1.1" in their messages, and MUST do so for any |  |  |
| message that is not compatible with HTTP/1.0. For more details on |  |  |
| when to send specific HTTP-Version values, see [RFC2145]. |  |  |
| The HTTP version of an application is the highest HTTP version for |  | When an HTTP/1.1 message is sent to an HTTP/1.0 recipient [RFC1945] |
| which the application is at least conditionally compliant. |  | 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 |
|  |  | message if all of the newer features are ignored. This specification |
|  |  | places recipient-version requirements on some new features so that a |
|  |  | compliant sender will only use compatible features until it has |
|  |  | determined, through configuration or the receipt of a message, that |
|  |  | the recipient supports HTTP/1.1. |
| Proxy and gateway applications need to be careful when forwarding |  | The interpretation of an HTTP header field does not change between |
| messages in protocol versions different from that of the application. |  | minor versions of the same major version, though the default behavior |
| Since the protocol version indicates the protocol capability of the |  | of a recipient in the absence of such a field can change. Unless |
| sender, a proxy/gateway MUST NOT send a message with a version |  | specified otherwise, header fields defined in HTTP/1.1 are defined |
| indicator which is greater than its actual version. If a higher |  | for all versions of HTTP/1.x. In particular, the Host and Connection |
| version request is received, the proxy/gateway MUST either downgrade |  | header fields ought to be implemented by all HTTP/1.x implementations |
| the request version, or respond with an error, or switch to tunnel |  | whether or not they advertise compliance with HTTP/1.1. |
| behavior. |  |  |
| Due to interoperability problems with HTTP/1.0 proxies discovered |  | New header fields can be defined such that, when they are understood |
| since the publication of [RFC2068], caching proxies MUST, gateways |  | by a recipient, they might override or enhance the interpretation of |
| MAY, and tunnels MUST NOT upgrade the request to the highest version |  | previously defined header fields. When an implementation receives an |
| they support. The proxy/gateway's response to that request MUST be |  | unrecognized header field, the recipient MUST ignore that header |
| in the same major version as the request. |  | field for local processing regardless of the message's HTTP version. |
|  |  | An unrecognized header field received by a proxy MUST be forwarded |
|  |  | downstream unless the header field's field-name is listed in the |
|  |  | message's Connection header-field (see Section 9.1). These |
|  |  | requirements allow HTTP's functionality to be enhanced without |
|  |  | requiring prior update of all compliant intermediaries. |
| Note: Converting between versions of HTTP might involve |  | Intermediaries that process HTTP messages (i.e., all intermediaries |
| modification of header fields required or forbidden by the |  | other than those acting as a tunnel) MUST send their own HTTP-Version |
| versions involved. |  | in forwarded messages. In other words, they MUST NOT blindly forward |
|  |  | the first line of an HTTP message without ensuring that the protocol |
|  |  | version matches what the intermediary understands, and is at least |
|  |  | conditionally compliant to, for both the receiving and sending of |
|  |  | messages. Forwarding an HTTP message without rewriting the HTTP- |
|  |  | Version might result in communication errors when downstream |
|  |  | recipients use the message sender's version to determine what |
|  |  | features are safe to use for later communication with that sender. |
|  |  | An HTTP client SHOULD send a request version equal to the highest |
|  |  | version for which the client is at least conditionally compliant and |
|  |  | whose major version is no higher than the highest version supported |
|  |  | by the server, if this is known. An HTTP client MUST NOT send a |
|  |  | version for which it is not at least conditionally compliant. |
|  |  | An HTTP client MAY send a lower request version if it is known that |
|  |  | the server incorrectly implements the HTTP specification, but only |
|  |  | after the client has attempted at least one normal request and |
|  |  | determined from the response status or header fields (e.g., Server) |
|  |  | that the server improperly handles higher request versions. |
|  |  | An HTTP server SHOULD send a response version equal to the highest |
|  |  | version for which the server is at least conditionally compliant and |
|  |  | whose major version is less than or equal to the one received in the |
|  |  | request. An HTTP server MUST NOT send a version for which it is not |
|  |  | at least conditionally compliant. A server MAY send a 505 (HTTP |
|  |  | Version Not Supported) response if it cannot send a response using |
|  |  | the major version used in the client's 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 |
|  |  | the HTTP specification and is incapable of correctly processing later |
|  |  | version responses, such as when a client fails to parse the version |
|  |  | number correctly or when an intermediary is known to blindly forward |
|  |  | the HTTP-Version even when it doesn't comply with the given minor |
|  |  | version of the protocol. Such protocol downgrades SHOULD NOT be |
|  |  | performed unless triggered by specific client attributes, such as |
|  |  | 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. |
|  |  | The intention of HTTP's versioning design is that the major number |
|  |  | will only be incremented if an incompatible message syntax is |
|  |  | introduced, and that the minor number will only be incremented when |
|  |  | changes made to the protocol have the effect of adding to the message |
|  |  | semantics or implying additional capabilities of the sender. |
|  |  | However, the minor version was not incremented for the changes |
|  |  | introduced between [RFC2068] and [RFC2616], and this revision is |
|  |  | specifically avoiding any such changes to the protocol. |
| 2.6. Uniform Resource Identifiers |  | 2.6. Uniform Resource Identifiers |
| Uniform Resource Identifiers (URIs) [RFC3986] are used throughout |  | Uniform Resource Identifiers (URIs) [RFC3986] are used throughout |
| HTTP as the means for identifying resources. URI references are used |  | HTTP as the means for identifying resources. URI references are used |
| to target requests, indicate redirects, and define relationships. |  | to target requests, indicate redirects, and define relationships. |
| HTTP does not limit what a resource might be; it merely defines an |  | HTTP does not limit what a resource might be; it merely defines an |
| interface that can be used to interact with a resource via HTTP. |  | interface that can be used to interact with a resource via HTTP. |
| More information on the scope of URIs and resources can be found in |  | More information on the scope of URIs and resources can be found in |
| [RFC3986]. |  | [RFC3986]. |
| This specification adopts the definitions of "URI-reference", |  | This specification adopts the definitions of "URI-reference", |
| "absolute-URI", "relative-part", "port", "host", "path-abempty", |  | "absolute-URI", "relative-part", "port", "host", "path-abempty", |
| "path-absolute", "query", and "authority" from [RFC3986]. In |  | "path-absolute", "query", and "authority" from the URI generic syntax |
| addition, we define a partial-URI rule for protocol elements that |  | [RFC3986]. In addition, we define a partial-URI rule for protocol |
| allow a relative URI without a fragment. |  | elements that allow a relative URI but not a fragment. |
| URI-reference = <URI-reference, defined in [RFC3986], Section 4.1> |  | URI-reference = <URI-reference, defined in [RFC3986], Section 4.1> |
| absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3> |  | absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3> |
| relative-part = <relative-part, defined in [RFC3986], Section 4.2> |  | relative-part = <relative-part, defined in [RFC3986], Section 4.2> |
| authority = <authority, defined in [RFC3986], Section 3.2> |  | authority = <authority, defined in [RFC3986], Section 3.2> |
| path-abempty = <path-abempty, defined in [RFC3986], Section 3.3> |  | path-abempty = <path-abempty, defined in [RFC3986], Section 3.3> |
| path-absolute = <path-absolute, defined in [RFC3986], Section 3.3> |  | path-absolute = <path-absolute, defined in [RFC3986], Section 3.3> |
| port = <port, defined in [RFC3986], Section 3.2.3> |  | port = <port, defined in [RFC3986], Section 3.2.3> |
| query = <query, defined in [RFC3986], Section 3.4> |  | query = <query, defined in [RFC3986], Section 3.4> |
| uri-host = <host, defined in [RFC3986], Section 3.2.2> |  | uri-host = <host, defined in [RFC3986], Section 3.2.2> |
| skipping to change at page 16, line 30 |  | skipping to change at page 18, line 4 |
| URI-reference = <URI-reference, defined in [RFC3986], Section 4.1> |  | URI-reference = <URI-reference, defined in [RFC3986], Section 4.1> |
| absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3> |  | absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3> |
| relative-part = <relative-part, defined in [RFC3986], Section 4.2> |  | relative-part = <relative-part, defined in [RFC3986], Section 4.2> |
| authority = <authority, defined in [RFC3986], Section 3.2> |  | authority = <authority, defined in [RFC3986], Section 3.2> |
| path-abempty = <path-abempty, defined in [RFC3986], Section 3.3> |  | path-abempty = <path-abempty, defined in [RFC3986], Section 3.3> |
| path-absolute = <path-absolute, defined in [RFC3986], Section 3.3> |  | path-absolute = <path-absolute, defined in [RFC3986], Section 3.3> |
| port = <port, defined in [RFC3986], Section 3.2.3> |  | port = <port, defined in [RFC3986], Section 3.2.3> |
| query = <query, defined in [RFC3986], Section 3.4> |  | query = <query, defined in [RFC3986], Section 3.4> |
| 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 only a URI |  | indicate in its ABNF production whether the element allows any form |
| in absolute form (absolute-URI), any relative reference (relative- |  | of reference (URI-reference), only a URI in absolute form (absolute- |
| ref), or some other subset of the URI-reference grammar. Unless |  | URI), only the path and optional query components, or some |
| otherwise indicated, URI references are parsed relative to the |  | combination of the above. Unless otherwise indicated, URI references |
| request target (the default base URI for both the request and its |  | are parsed relative to the effective request URI, which defines the |
| corresponding response). |  | default base URI for references in both the request and its |
|  |  | corresponding response. |
| 2.6.1. http URI scheme |  | 2.6.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. The HTTP server is identified via |  | TCP connections on a given port. |
| the generic syntax's authority component, which includes a host |  |  |
| identifier and optional TCP port, and the remainder of the URI is |  |  |
| considered to be identifying data corresponding to a resource for |  |  |
| which that server might provide an HTTP interface. |  |  |
| http-URI = "http:" "//" authority path-abempty [ "?" query ] |  | http-URI = "http:" "//" authority path-abempty [ "?" query ] |
| The host identifier within an authority component is defined in |  | The HTTP origin server is identified by the generic syntax's |
| [RFC3986], Section 3.2.2. If host is provided as an IP literal or |  | authority component, which includes a host identifier and optional |
| IPv4 address, then the HTTP server is any listener on the indicated |  | TCP port ([RFC3986], Section 3.2.2). The remainder of the URI, |
| TCP port at that IP address. If host is a registered name, then that |  | consisting of both the hierarchical path component and optional query |
| name is considered an indirect identifier and the recipient might use |  | component, serves as an identifier for a potential resource within |
| a name resolution service, such as DNS, to find the address of a |  | that origin server's name space. |
| listener for that host. The host MUST NOT be empty; if an "http" URI |  |  |
| is received with an empty host, then it MUST be rejected as invalid. |  | If the host identifier is provided as an IP literal or IPv4 address, |
| If the port subcomponent is empty or not given, then TCP port 80 is |  | then the origin server is any listener on the indicated TCP port at |
|  |  | that IP address. If host is a registered name, then that name is |
|  |  | considered an indirect identifier and the recipient might use a name |
|  |  | resolution service, such as DNS, to find the address of a listener |
|  |  | for that host. The host MUST NOT be empty; if an "http" URI is |
|  |  | received with an empty host, then it MUST be rejected as invalid. If |
|  |  | the port subcomponent is empty or not given, then TCP port 80 is |
| assumed (the default reserved port for WWW services). |  | assumed (the default reserved port for WWW services). |
| Regardless of the form of host identifier, access to that host is not |  | Regardless of the form of host identifier, access to that host is not |
| implied by the mere presence of its name or address. The host might |  | implied by the mere presence of its name or address. The host might |
| or might not exist and, even when it does exist, might or might not |  | or might not exist and, even when it does exist, might or might not |
| be running an HTTP server or listening to the indicated port. The |  | be running an HTTP server or listening to the indicated port. The |
| "http" URI scheme makes use of the delegated nature of Internet names |  | "http" URI scheme makes use of the delegated nature of Internet names |
| and addresses to establish a naming authority (whatever entity has |  | and addresses to establish a naming authority (whatever entity has |
| the ability to place an HTTP server at that Internet name or address) |  | the ability to place an HTTP server at that Internet name or address) |
| and allows that authority to determine which names are valid and how |  | and allows that authority to determine which names are valid and how |
| skipping to change at page 17, line 42 |  | skipping to change at page 19, line 19 |
| HTTP response message, as described in Section 5, then that response |  | HTTP response message, as described in Section 5, then that response |
| is considered an authoritative answer to the client's request. |  | is considered an authoritative answer to the client's request. |
| Although HTTP is independent of the transport protocol, the "http" |  | Although HTTP is independent of the transport protocol, the "http" |
| scheme is specific to TCP-based services because the name delegation |  | scheme is specific to TCP-based services because the name delegation |
| process depends on TCP for establishing authority. An HTTP service |  | process depends on TCP for establishing authority. An HTTP service |
| based on some other underlying connection protocol would presumably |  | based on some other underlying connection protocol would presumably |
| be identified using a different URI scheme, just as the "https" |  | be identified using a different URI scheme, just as the "https" |
| scheme (below) is used for servers that require an SSL/TLS transport |  | scheme (below) is used for servers that require an SSL/TLS transport |
| layer on a connection. Other protocols might also be used to provide |  | layer on a connection. Other protocols might also be used to provide |
| access to "http" identified resources --- it is only the |  | access to "http" identified resources -- it is only the authoritative |
| authoritative interface used for mapping the namespace that is |  | interface used for mapping the namespace that is specific to TCP. |
| specific to TCP. |  |  |
| The URI generic syntax for authority also includes a deprecated |  | The URI generic syntax for authority also includes a deprecated |
| userinfo subcomponent ([RFC3986], Section 3.2.1) for including user |  | userinfo subcomponent ([RFC3986], Section 3.2.1) for including user |
| authentication information in the URI. The userinfo subcomponent |  | authentication information in the URI. Some implementations make use |
| (and its "@" delimiter) MUST NOT be used in an "http" URI. URI |  | of the userinfo component for internal configuration of |
| reference recipients SHOULD parse for the existence of userinfo and |  | authentication information, such as within command invocation |
| treat its presence as an error, likely indicating that the deprecated |  | options, configuration files, or bookmark lists, even though such |
| subcomponent is being used to obscure the authority for the sake of |  | usage might expose a user identifier or password. Senders MUST NOT |
| phishing attacks. |  | include a userinfo subcomponent (and its "@" delimiter) when |
|  |  | transmitting an "http" URI in a message. Recipients of HTTP messages |
|  |  | that contain a URI reference SHOULD parse for the existence of |
|  |  | userinfo and treat its presence as an error, likely indicating that |
|  |  | the deprecated subcomponent is being used to obscure the authority |
|  |  | for the sake of phishing attacks. |
| 2.6.2. https URI scheme |  | 2.6.2. https URI scheme |
| The "https" URI scheme is hereby defined for the purpose of minting |  | The "https" URI scheme is hereby defined for the purpose of minting |
| identifiers according to their association with the hierarchical |  | identifiers according to their association with the hierarchical |
| namespace governed by a potential HTTP origin server listening for |  | namespace governed by a potential HTTP origin server listening for |
| SSL/TLS-secured connections on a given TCP port. |  | SSL/TLS-secured connections on a given TCP port. |
| All of the requirements listed above for the "http" scheme are also |  | All of the requirements listed above for the "http" scheme are also |
| requirements for the "https" scheme, except that a default TCP port |  | requirements for the "https" scheme, except that a default TCP port |
| of 443 is assumed if the port subcomponent is empty or not given, and |  | of 443 is assumed if the port subcomponent is empty or not given, and |
| the TCP connection MUST be secured for privacy through the use of |  | the TCP connection MUST be secured for privacy through the use of |
| strong encryption prior to sending the first HTTP request. |  | strong encryption prior to sending the first HTTP request. |
| https-URI = "https:" "//" authority path-abempty [ "?" query ] |  | https-URI = "https:" "//" authority path-abempty [ "?" query ] |
| Unlike the "http" scheme, responses to "https" identified requests |  | Unlike the "http" scheme, responses to "https" identified requests |
| are never "public" and thus are ineligible for shared caching. Their |  | are never "public" and thus MUST NOT be reused for shared caching. |
| default is "private" and might be further constrained via use of the |  | They can, however, be reused in a private cache if the message is |
| Cache-Control header field. |  | cacheable by default in HTTP or specifically indicated as such by the |
|  |  | Cache-Control header field (Section 3.2 of [Part6]). |
| Resources made available via the "https" scheme have no shared |  | Resources made available via the "https" scheme have no shared |
| identity with the "http" scheme even if their resource identifiers |  | identity with the "http" scheme even if their resource identifiers |
| only differ by the single "s" in the scheme name. They are different |  | indicate the same authority (the same host listening to the same TCP |
| services governed by different authorities. However, some extensions |  | port). They are distinct name spaces and are considered to be |
| to HTTP that apply to entire host domains, such as the Cookie |  | distinct origin servers. However, an extension to HTTP that is |
| protocol, do allow one service to effect communication with the other |  | defined to apply to entire host domains, such as the Cookie protocol |
| services based on host domain matching. |  | [draft-ietf-httpstate-cookie], can allow information set by one |
|  |  | service to impact communication with other services within a matching |
|  |  | group of host domains. |
| The process for authoritative access to an "https" identified |  | The process for authoritative access to an "https" identified |
| resource is defined in [RFC2818]. |  | resource is defined in [RFC2818]. |
| 2.6.3. http and https URI Normalization and Comparison |  | 2.6.3. http and https URI Normalization and Comparison |
| Since the "http" and "https" schemes conform to the URI generic |  | Since the "http" and "https" schemes conform to the URI generic |
| syntax, such URIs are normalized and compared according to the |  | syntax, such URIs are normalized and compared according to the |
| algorithm defined in [RFC3986], Section 6, using the defaults |  | algorithm defined in [RFC3986], Section 6, using the defaults |
| described above for each scheme. |  | described above for each scheme. |
| skipping to change at page 19, line 12 |  | skipping to change at page 20, line 45 |
| than those in the "reserved" set are equivalent to their percent- |  | than those in the "reserved" set are equivalent to their percent- |
| encoded octets (see [RFC3986], Section 2.1): the normal form is to |  | encoded octets (see [RFC3986], Section 2.1): the normal form is to |
| not encode them. |  | not encode them. |
| For example, the following three URIs are equivalent: |  | For example, the following three URIs are equivalent: |
| http://example.com:80/~smith/home.html |  | http://example.com:80/~smith/home.html |
| http://EXAMPLE.com/%7Esmith/home.html |  | http://EXAMPLE.com/%7Esmith/home.html |
| http://EXAMPLE.com:/%7esmith/home.html |  | http://EXAMPLE.com:/%7esmith/home.html |
| [[TODO-not-here: This paragraph does not belong here. --roy]] If |  | 3. Message Format |
| path-abempty is the empty string (i.e., there is no slash "/" path |  |  |
| separator following the authority), then the "http" URI MUST be given |  |  |
| as "/" when used as a request-target (Section 4.1.2). If a proxy |  |  |
| receives a host name which 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. |  |  |
| 3. HTTP Message |  |  |
| 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 characters 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. |
| 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 |
| skipping to change at page 19, line 46 |  | skipping to change at page 21, line 22 |
| 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. |
| HTTP-message = start-line |  | HTTP-message = start-line |
| *( header-field CRLF ) |  | *( header-field CRLF ) |
| CRLF |  | CRLF |
| [ message-body ] |  | [ message-body ] |
| start-line = Request-Line / Status-Line |  | start-line = Request-Line / Status-Line |
| Whitespace (WSP) MUST NOT be sent between the start-line and the |  | Implementations MUST NOT send whitespace between the start-line and |
| first header field. The presence of whitespace might be an attempt |  | the first header field. The presence of such whitespace in a request |
| to trick a noncompliant implementation of HTTP into ignoring that |  | might be an attempt to trick a server into ignoring that field or |
| field or processing the next line as a new request, either of which |  | processing the line after it as a new request, either of which might |
| might result in security issues when implementations within the |  | result in a security vulnerability if other implementations within |
| request chain interpret the same message differently. HTTP/1.1 |  | the request chain interpret the same message differently. Likewise, |
| servers MUST reject such a message with a 400 (Bad Request) response. |  | the presence of such whitespace in a response might be ignored by |
|  |  | some clients or cause others to cease parsing. |
| 3.1. Message Parsing Robustness |  | 3.1. Message Parsing Robustness |
| 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. |
| Some old HTTP/1.0 client implementations generate an extra CRLF after |  | Some old HTTP/1.0 client implementations send an extra CRLF after a |
| a POST request as a lame workaround for some early server |  | POST request as a lame workaround for some early server applications |
| applications that failed to read message-body content that was not |  | that failed to read message-body content that was not terminated by a |
| terminated by a line-ending. An HTTP/1.1 client MUST NOT preface or |  | line-ending. An HTTP/1.1 client MUST NOT preface or follow a request |
| follow a request with an extra CRLF. If terminating the request |  | with an extra CRLF. If terminating the request message-body with a |
| message-body with a line-ending is desired, then the client MUST |  | line-ending is desired, then the client MUST include the terminating |
| include the terminating CRLF octets as part of the message-body |  | CRLF octets as part of the message-body length. |
| length. |  |  |
|  |  | When a server listening only for HTTP request messages, or processing |
|  |  | what appears from the start-line to be an HTTP request message, |
|  |  | receives a sequence of octets that does not match the HTTP-message |
|  |  | grammar aside from the robustness exceptions listed above, the server |
|  |  | MUST respond with an HTTP/1.1 400 (Bad Request) response. |
| 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. |
| Care must be taken to parse an HTTP message as a sequence of octets |  | Care must be taken to parse an HTTP message as a sequence of octets |
| in an encoding that is a superset of US-ASCII. Attempting to parse |  | in an encoding that is a superset of US-ASCII. Attempting to parse |
| HTTP as a stream of Unicode characters in a character encoding like |  | HTTP as a stream of Unicode characters in a character encoding like |
| UTF-16 might introduce security flaws due to the differing ways that |  | UTF-16 might introduce security flaws due to the differing ways that |
| such parsers interpret invalid characters. |  | such parsers interpret invalid characters. |
| HTTP allows the set of defined header fields to be extended without |  | HTTP allows the set of defined header fields to be extended without |
| changing the protocol version (see Section 10.1). However, such |  | changing the protocol version (see Section 10.1). Unrecognized |
| fields might not be recognized by a downstream recipient and might be |  | header fields MUST be forwarded by a proxy unless the proxy is |
| stripped by non-transparent intermediaries. Unrecognized header |  | specifically configured to block or otherwise transform such fields. |
| fields MUST be forwarded by transparent proxies and SHOULD be ignored |  | Unrecognized header fields SHOULD be ignored by other recipients. |
| by a recipient. |  |  |
| 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 ] OWS |  | header-field = field-name ":" OWS [ field-value ] OWS |
| field-name = token |  | field-name = token |
| field-value = *( field-content / OWS ) |  | field-value = *( field-content / OWS ) |
| field-content = *( WSP / VCHAR / obs-text ) |  | field-content = *( WSP / VCHAR / obs-text ) |
| skipping to change at page 21, line 4 |  | skipping to change at page 22, line 32 |
| 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 ] OWS |  | header-field = field-name ":" OWS [ field-value ] OWS |
| field-name = token |  | field-name = token |
| field-value = *( field-content / OWS ) |  | field-value = *( field-content / OWS ) |
| field-content = *( WSP / VCHAR / obs-text ) |  | field-content = *( WSP / VCHAR / obs-text ) |
| No whitespace is allowed between the header field name and colon. |  | No whitespace is allowed between the header field name and colon. |
| For security reasons, any request message received containing such |  | For security reasons, any request message received containing such |
| whitespace MUST be rejected with a response code of 400 (Bad |  | whitespace MUST be rejected with a response code of 400 (Bad |
| Request). A proxy MUST remove any such whitespace from a response |  | Request). A proxy MUST remove any such whitespace from a response |
| message before forwarding the message downstream. |  | 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 |
| character of the field value or after the last non-whitespace |  | octet of the field value or after the last non-whitespace octet of |
| character of the field value is ignored and SHOULD be removed before |  | the field value is ignored and SHOULD be removed before further |
| further processing (as this does not change the meaning of the header |  | processing (as this does not change the meaning of the header field). |
| field). |  |  |
| The order in which header fields with differing field names are |  | The order in which header fields with differing field names are |
| received is not significant. However, it is "good practice" to send |  | received is not significant. However, it is "good practice" to send |
| header fields that contain control data first, such as Host on |  | header fields that contain control data first, such as Host on |
| requests and Date on responses, so that implementations can decide |  | requests and Date on responses, so that implementations can decide |
| when not to handle a message as early as possible. A server MUST |  | when not to handle a message as early as possible. A server MUST |
| wait until the entire header section is received before interpreting |  | wait until the entire header section is received before interpreting |
| a request message, since later header fields might include |  | a request message, since later header fields might include |
| conditionals, authentication credentials, or deliberately misleading |  | conditionals, authentication credentials, or deliberately misleading |
| duplicate header fields that would impact request processing. |  | duplicate header fields that would impact request processing. |
| skipping to change at page 21, line 39 |  | skipping to change at page 23, line 17 |
| message unless the entire field value for that header field is |  | message unless the entire field value for that header field is |
| defined as a comma-separated list [i.e., #(values)]. Multiple header |  | defined as a comma-separated list [i.e., #(values)]. Multiple header |
| fields with the same field name can be combined into one "field-name: |  | fields with the same field name can be combined into one "field-name: |
| field-value" pair, without changing the semantics of the message, by |  | field-value" pair, without changing the semantics of the message, by |
| appending each subsequent field value to the combined field value in |  | appending each subsequent field value to the combined field value in |
| order, separated by a comma. The order in which header fields with |  | order, separated by a comma. The order in which header fields with |
| 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 (as |  | Note: The "Set-Cookie" header field as implemented in practice can |
| opposed to how it is specified in [RFC2109]) can occur multiple |  | occur multiple times, but does not use the list syntax, and thus |
| times, but does not use the list syntax, and thus cannot be |  | cannot be combined into a single line |
| combined into a single line. (See Appendix A.2.3 of [Kri2001] for |  | ([draft-ietf-httpstate-cookie]). (See Appendix A.2.3 of [Kri2001] |
| details.) Also note that the Set-Cookie2 header field specified |  | for details.) Also note that the Set-Cookie2 header field |
| in [RFC2965] does not share this problem. |  | specified in [RFC2965] does not share this problem. |
| 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 character (line folding). This specification |  | or horizontal tab octet (line folding). This specification |
| deprecates such line folding except within the message/http media |  | deprecates such line folding except within the message/http media |
| type (Section 10.3.1). HTTP/1.1 senders MUST NOT produce messages |  | type (Section 10.3.1). HTTP/1.1 senders MUST NOT produce messages |
| that include line folding (i.e., that contain any field-content that |  | that include line folding (i.e., that contain any field-content that |
| matches the obs-fold rule) unless the message is intended for |  | matches the obs-fold rule) unless the message is intended for |
| packaging within the message/http media type. HTTP/1.1 recipients |  | packaging within the message/http media type. HTTP/1.1 recipients |
| SHOULD accept line folding and replace any embedded obs-fold |  | SHOULD accept line folding and replace any embedded obs-fold |
| whitespace with a single SP prior to interpreting the field value or |  | whitespace with a single SP prior to interpreting the field value or |
| forwarding the message downstream. |  | forwarding the message 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 characters. Recipients SHOULD treat other |  | field values to US-ASCII octets. Recipients SHOULD treat other (obs- |
| (obs-text) octets in field content as opaque data. |  | text) octets in field content as opaque data. |
| 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 |
| ; OWS / <VCHAR except "(", ")", and "\"> / obs-text |  | ; OWS / <VCHAR except "(", ")", and "\"> / obs-text |
| The backslash character ("\") can be used as a single-character |  | The backslash octet ("\") can be used as a single-octet quoting |
| quoting mechanism within comment constructs: |  | mechanism within comment constructs: |
| quoted-cpair = "\" ( WSP / VCHAR / obs-text ) |  | quoted-cpair = "\" ( WSP / VCHAR / obs-text ) |
| Producers SHOULD NOT escape characters that do not require escaping |  | Senders SHOULD NOT escape octets that do not require escaping (i.e., |
| (i.e., other than the backslash character "\" and the parentheses "(" |  | other than the backslash octet "\" and the parentheses "(" and ")"). |
| and ")"). |  |  |
| 3.3. Message Body |  | 3.3. Message Body |
| The message-body (if any) of an HTTP message is used to carry the |  | The message-body (if any) of an HTTP message is used to carry the |
| payload body associated with the request or response. |  | payload body associated with the request or response. |
| message-body = *OCTET |  | message-body = *OCTET |
| The message-body differs from the payload body only when a transfer- |  | The message-body differs from the payload body only when a transfer- |
| coding has been applied, as indicated by the Transfer-Encoding header |  | coding has been applied, as indicated by the Transfer-Encoding header |
| field (Section 9.7). When one or more transfer-codings are applied |  | field (Section 9.7). If more than one Transfer-Encoding header field |
| to a payload in order to form the message-body, the Transfer-Encoding |  | is present in a message, the multiple field-values MUST be combined |
| header field MUST contain the list of transfer-codings applied. |  | into one field-value, according to the algorithm defined in |
| Transfer-Encoding is a property of the message, not of the payload, |  | Section 3.2, before determining the message-body length. |
| and thus MAY be added or removed by any implementation along the |  |  |
| request/response chain under the constraints found in Section 6.2. |  | When one or more transfer-codings are applied to a payload in order |
|  |  | to form the message-body, the Transfer-Encoding header field MUST |
|  |  | contain the list of transfer-codings applied. 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 under |
|  |  | the constraints found in Section 6.2. |
|  |  | If a message is received that has multiple Content-Length header |
|  |  | fields (Section 9.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 replace the duplicated fields or field-values with a |
|  |  | single valid Content-Length field containing that decimal value prior |
|  |  | to determining the message-body length. |
| The rules for when a message-body is allowed in a message differ for |  | The rules for when a message-body is allowed in a message differ for |
| requests and responses. |  | requests and responses. |
| The presence of a message-body in a request is signaled by the |  | The presence of a message-body in a request is signaled by the |
| inclusion of a Content-Length or Transfer-Encoding header field in |  | inclusion of a Content-Length or Transfer-Encoding header field in |
| the request's header fields, even if the request method does not |  | the request's header fields, even if the request method does not |
| define any use for a message-body. This allows the request message |  | define any use for a message-body. This allows the request message |
| framing algorithm to be independent of method semantics. |  | framing algorithm to be independent of method semantics. |
| For response messages, whether or not a message-body is included with |  | For response messages, whether or not a message-body is included with |
| a message is dependent on both the request method and the response |  | a message is dependent on both the request method and the response |
| status code (Section 5.1.1). Responses to the HEAD request method |  | status code (Section 5.1.1). Responses to the HEAD request method |
| never include a message-body because the associated response header |  | never include a message-body because the associated response header |
| fields (e.g., Transfer-Encoding, Content-Length, etc.) only indicate |  | fields (e.g., Transfer-Encoding, Content-Length, etc.) only indicate |
| what their values would have been if the method had been GET. All |  | what their values would have been if the request method had been GET. |
| 1xx (Informational), 204 (No Content), and 304 (Not Modified) |  | All 1xx (Informational), 204 (No Content), and 304 (Not Modified) |
| responses MUST NOT include a message-body. All other responses do |  | responses MUST NOT include a message-body. All other responses do |
| include a message-body, although the body MAY be of zero length. |  | 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 |  | The length of the 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 (Section 9.7) is present and |  | 2. If a Transfer-Encoding header field is present and the "chunked" |
| the "chunked" transfer-coding (Section 6.2) is the final |  | transfer-coding (Section 6.2) is the final encoding, the message- |
| encoding, the message-body length is determined by reading and |  | body length is determined by reading and decoding the chunked |
| decoding the chunked data until the transfer-coding indicates the |  | data until the transfer-coding indicates the data is complete. |
| 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. |
| skipping to change at page 24, line 7 |  | skipping to change at page 25, line 49 |
| 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 |  | 3. If a message is received without Transfer-Encoding and with |
| either multiple Content-Length header fields or a single Content- |  | either multiple Content-Length header fields having differing |
| Length header field with an invalid value, then the message |  | field-values or a single Content-Length header field having an |
| framing is invalid and MUST be treated as an error to prevent |  | invalid value, then the message framing is invalid and MUST be |
| request or response smuggling. If this is a request message, the |  | treated as an error to prevent request or response smuggling. If |
| server MUST respond with a 400 (Bad Request) status code and then |  | this is a request message, the server MUST respond with a 400 |
| close the connection. If this is a response message received by |  | (Bad Request) status code and then close the connection. If this |
| a proxy or gateway, the proxy or gateway MUST discard the |  | is a response message received by a proxy, the proxy MUST discard |
| received response, send a 502 (Bad Gateway) status code as its |  | the received response, send a 502 (Bad Gateway) status code as |
| downstream response, and then close the connection. If this is a |  | its downstream response, and then close the connection. If this |
| response message received by a user-agent, it SHOULD be treated |  | is a response message received by a user-agent, it MUST be |
| as an error by discarding the message and closing the connection. |  | treated as an error by discarding the message and closing the |
|  |  | connection. |
| 4. If a valid Content-Length header field (Section 9.2) is present |  | 4. If a valid Content-Length header field is present without |
| without Transfer-Encoding, its decimal value defines the message- |  | Transfer-Encoding, its decimal value defines the message-body |
| body length in octets. If the actual number of octets sent in |  | length in octets. If the actual number of octets sent in the |
| the message is less than the indicated Content-Length, the |  | message is less than the indicated Content-Length, the recipient |
| recipient MUST consider the message to be incomplete and treat |  | MUST consider the message to be incomplete and treat the |
| the connection as no longer usable. If the actual number of |  | connection as no longer usable. If the actual number of octets |
| octets sent in the message is more than the indicated Content- |  | sent in the message is more than the indicated Content-Length, |
| Length, the recipient MUST only process the message-body up to |  | the recipient MUST only process the message-body up to the field |
| the field value's number of octets; the remainder of the message |  | value's number of octets; the remainder of the message MUST |
| MUST either be discarded or treated as the next message in a |  | either be discarded or treated as the next message in a pipeline. |
| pipeline. For the sake of robustness, a user-agent MAY attempt |  | For the sake of robustness, a user-agent MAY attempt to detect |
| to detect and correct such an error in message framing if it is |  | and correct such an error in message framing if it is parsing the |
| parsing the response to the last request on on a connection and |  | response to the last request on on a connection and the |
| the connection has been closed by the server. |  | connection has been closed by the server. |
| 5. If this is a request message and none of the above are true, then |  | 5. 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- |  | 6. 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- |
| skipping to change at page 26, line 5 |  | skipping to change at page 27, line 41 |
| request. Pipelining multiple requests on a connection is described |  | request. Pipelining multiple requests on a connection is described |
| in Section 7.1.2.2. |  | in Section 7.1.2.2. |
| 3.4. General Header Fields |  | 3.4. General Header Fields |
| There are a few header fields which have general applicability for |  | There are a few header fields which have general applicability for |
| both request and response messages, but which do not apply to the |  | both request and response messages, but which do not apply to the |
| payload being transferred. These header fields apply only to the |  | payload being transferred. These header fields apply only to the |
| message being transmitted. |  | message being transmitted. |
| general-header = Cache-Control ; [Part6], Section 3.2 |  | +-------------------+---------------+ |
| / Connection ; Section 9.1 |  | | Header Field Name | Defined in... | |
| / Date ; Section 9.3 |  | +-------------------+---------------+ |
| / Pragma ; [Part6], Section 3.4 |  | | Connection | Section 9.1 | |
| / Trailer ; Section 9.6 |  | | Date | Section 9.3 | |
| / Transfer-Encoding ; Section 9.7 |  | | Trailer | Section 9.6 | |
| / Upgrade ; Section 9.8 |  | | Transfer-Encoding | Section 9.7 | |
| / Via ; Section 9.9 |  | | Upgrade | Section 9.8 | |
| / Warning ; [Part6], Section 3.6 |  | | Via | Section 9.9 | |
| / MIME-Version ; [Part3], Appendix A.1 |  | +-------------------+---------------+ |
| General-header field names can be extended reliably only in |  |  |
| combination with a change in the protocol version. However, new or |  |  |
| experimental header fields might be given the semantics of general |  |  |
| header fields if all parties in the communication recognize them to |  |  |
| be general-header fields. |  |  |
| 4. Request |  | 4. Request |
| A request message from a client to a server includes, within the |  | A request message from a client to a server begins with a Request- |
| first line of that message, the method to be applied to the resource, |  | Line, followed by zero or more header fields, an empty line |
| the identifier of the resource, and the protocol version in use. |  | signifying the end of the header block, and an optional message body. |
| Request = Request-Line ; Section 4.1 |  | Request = Request-Line ; Section 4.1 |
| *( header-field CRLF ) ; Section 3.2 |  | *( header-field CRLF ) ; Section 3.2 |
| CRLF |  | CRLF |
| [ message-body ] ; Section 3.3 |  | [ message-body ] ; Section 3.3 |
| 4.1. Request-Line |  | 4.1. Request-Line |
| The Request-Line begins with a method token, followed by the request- |  | The Request-Line begins with a method token, followed by a single |
| target and the protocol version, and ending with CRLF. The elements |  | space (SP), the request-target, another single space (SP), the |
| are separated by SP characters. No CR or LF is allowed except in the |  | protocol version, and ending with CRLF. |
| final CRLF sequence. |  |  |
| Request-Line = Method SP request-target SP HTTP-Version CRLF |  | Request-Line = Method SP request-target SP HTTP-Version CRLF |
| 4.1.1. Method |  | 4.1.1. Method |
| The Method token indicates the method to be performed on the resource |  | The Method token indicates the request method to be performed on the |
| identified by the request-target. The method is case-sensitive. |  | target resource. The request method is case-sensitive. |
| Method = token |  | Method = token |
| 4.1.2. request-target |  | 4.1.2. request-target |
| The request-target identifies the resource upon which to apply the |  | The request-target identifies the target resource upon which to apply |
| request. |  | the request. 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. |
| request-target = "*" |  | request-target = "*" |
| / absolute-URI |  | / absolute-URI |
| / ( path-absolute [ "?" query ] ) |  | / ( path-absolute [ "?" query ] ) |
| / authority |  | / authority |
| The four options for request-target are dependent on the nature of |  | The four options for request-target are dependent on the nature of |
| the request. |  | the request. |
| The asterisk "*" ("asterisk form") means that the request does not |  | The asterisk "*" form of request-target, which MUST NOT be used with |
| apply to a particular resource, but to the server itself, and is only |  | any request method other than OPTIONS, means that the request applies |
| allowed when the method used does not necessarily apply to a |  | to the server as a whole (the listening process) rather than to a |
| resource. One example would be |  | specific named resource at that server. For example, |
| OPTIONS * HTTP/1.1 |  | OPTIONS * HTTP/1.1 |
| The absolute-URI form is REQUIRED when the request is being made to a |  | The "absolute-URI" form is REQUIRED when the request is being made to |
| proxy. The proxy is requested to forward the request or service it |  | a proxy. The proxy is requested to either forward the request or |
| from a valid cache, and return the response. Note that the proxy MAY |  | service it from a valid cache, and then return the response. Note |
| forward the request on to another proxy or directly to the server |  | that the proxy MAY forward the request on to another proxy or |
| specified by the absolute-URI. In order to avoid request loops, a |  | directly to the server specified by the absolute-URI. In order to |
| proxy MUST be able to recognize all of its server names, including |  | avoid request loops, a proxy that forwards requests to other proxies |
| any aliases, local variations, and the numeric IP address. An |  | MUST be able to recognize and exclude all of its own server names, |
| example Request-Line would be: |  | 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 |  | GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1 |
| To allow for transition to absolute-URIs in all requests in future |  | 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 |  | 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 |  | form in requests, even though HTTP/1.1 clients will only generate |
| them in requests to proxies. |  | them in requests to proxies. |
| The authority form is only used by the CONNECT method (Section 7.9 of |  | If a proxy receives a host name that is not a fully qualified domain |
| [Part2]). |  | 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 most common form of request-target is that used to identify a |  | The "authority form" is only used by the CONNECT request method |
| resource on an origin server or gateway ("path-absolute form"). In |  | (Section 7.9 of [Part2]). |
| this case the absolute path of the URI MUST be transmitted (see |  |  |
| Section 2.6.1, path-absolute) as the request-target, and the network |  | The most common form of request-target is that used when making a |
| location of the URI (authority) MUST be transmitted in a Host header |  | request to an origin server ("origin form"). In this case, the |
| field. For example, a client wishing to retrieve the resource above |  | absolute path and query components of the URI MUST be transmitted as |
| directly from the origin server would create a TCP connection to port |  | the request-target, and the authority component MUST be transmitted |
| 80 of the host "www.example.org" and send the lines: |  | 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 |  | GET /pub/WWW/TheProject.html HTTP/1.1 |
| Host: www.example.org |  | Host: www.example.org |
| followed by the remainder of the Request. Note that the absolute |  | followed by the remainder of the Request. Note that the origin form |
| path cannot be empty; if none is present in the original URI, it MUST |  | of request-target always starts with an absolute path; if the target |
| be given as "/" (the server root). |  | resource's URI path is empty, then an absolute path of "/" MUST be |
|  |  | provided in the request-target. |
| If a proxy receives a request without any path in the request-target |  | If a proxy receives an OPTIONS request with an absolute-URI form of |
| and the method specified is capable of supporting the asterisk form |  | request-target in which the URI has an empty path and no query |
| of request-target, then the last proxy on the request chain MUST |  | component, then the last proxy on the request chain MUST use a |
| forward the request with "*" as the final request-target. |  | request-target of "*" when it forwards the request to the indicated |
|  |  | origin server. |
| For example, the request |  | For example, the request |
| OPTIONS http://www.example.org:8001 HTTP/1.1 |  | OPTIONS http://www.example.org:8001 HTTP/1.1 |
| would be forwarded by the proxy as |  | would be forwarded by the final proxy as |
| OPTIONS * HTTP/1.1 |  | OPTIONS * HTTP/1.1 |
| Host: www.example.org:8001 |  | Host: www.example.org:8001 |
| after connecting to port 8001 of host "www.example.org". |  | after connecting to port 8001 of host "www.example.org". |
| The request-target is transmitted in the format specified in |  | The request-target is transmitted in the format specified in |
| Section 2.6.1. If the request-target is percent-encoded ([RFC3986], |  | Section 2.6.1. If the request-target is percent-encoded ([RFC3986], |
| Section 2.1), the origin server MUST decode the request-target in |  | Section 2.1), the origin server MUST decode the request-target in |
| order to properly interpret the request. Servers SHOULD respond to |  | order to properly interpret the request. Servers SHOULD respond to |
| invalid request-targets with an appropriate status code. |  | invalid request-targets with an appropriate status code. |
| A transparent proxy MUST NOT rewrite the "path-absolute" part of the |  | A non-transforming proxy MUST NOT rewrite the "path-absolute" part of |
| received request-target when forwarding it to the next inbound |  | the received request-target when forwarding it to the next inbound |
| server, except as noted above to replace a null path-absolute with |  | server, except as noted above to replace a null path-absolute with |
| "/" or "*". |  | "/" or "*". |
| Note: The "no rewrite" rule prevents the proxy from changing the |  | Note: The "no rewrite" rule prevents the proxy from changing the |
| meaning of the request when the origin server is improperly using |  | meaning of the request when the origin server is improperly using |
| a non-reserved URI character for a reserved purpose. Implementors |  | 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 |  | need to be aware that some pre-HTTP/1.1 proxies have been known to |
| rewrite the request-target. |  | rewrite the request-target. |
| 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- |
| skipping to change at page 30, line 14 |  | skipping to change at page 31, line 50 |
| URI is the request-target. |  | URI is the request-target. |
| If the request-target uses the path-absolute form or the asterisk |  | If the request-target uses the path-absolute form or the asterisk |
| form, and the Host header field is present, then the effective |  | form, and the Host header field is present, then the effective |
| request URI is constructed by concatenating |  | request URI is constructed by concatenating |
| o the scheme name: "http" if the request was received over an |  | o the scheme name: "http" if the request was received over an |
| insecure TCP connection, or "https" when received over a SSL/ |  | insecure TCP connection, or "https" when received over a SSL/ |
| TLS-secured TCP connection, |  | TLS-secured TCP connection, |
| o the character sequence "://", |  | o the octet sequence "://", |
| o the authority component, as specified in the Host header field |  | o the authority component, as specified in the Host header field |
| (Section 9.4), and |  | (Section 9.4), and |
| o the request-target obtained from the Request-Line, unless the |  | o the request-target obtained from the Request-Line, unless the |
| request-target is just the asterisk "*". |  | request-target is just the asterisk "*". |
| If the request-target uses the path-absolute form or the asterisk |  | If the request-target uses the path-absolute form or the asterisk |
| form, and the Host header field is not present, then the effective |  | form, and the Host header field is not present, then the effective |
| request URI is undefined. |  | request URI is undefined. |
| skipping to change at page 31, line 18 |  | skipping to change at page 33, line 8 |
| with an HTTP response message. |  | with an HTTP response message. |
| Response = Status-Line ; Section 5.1 |  | Response = Status-Line ; Section 5.1 |
| *( header-field CRLF ) ; Section 3.2 |  | *( header-field CRLF ) ; Section 3.2 |
| CRLF |  | CRLF |
| [ message-body ] ; Section 3.3 |  | [ message-body ] ; Section 3.3 |
| 5.1. Status-Line |  | 5.1. 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 followed by a numeric status code and its |  | of the protocol version, a space (SP), the status code, another |
| associated textual phrase, with each element separated by SP |  | space, a possibly-empty textual phrase describing the status code, |
| characters. No CR or LF is allowed except in the final CRLF |  | and ending with CRLF. |
| sequence. |  |  |
| Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF |  | Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF |
| 5.1.1. Status Code and Reason Phrase |  | 5.1.1. Status Code and Reason Phrase |
| 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. These codes are fully |  | attempt to understand and satisfy the request. These codes are fully |
| defined in Section 8 of [Part2]. The Reason Phrase exists for the |  | defined in Section 8 of [Part2]. The Reason Phrase exists for the |
| sole purpose of providing a textual description associated with the |  | sole purpose of providing a textual description associated with the |
| numeric status code, out of deference to earlier Internet application |  | numeric status code, out of deference to earlier Internet application |
| skipping to change at page 39, line 24 |  | skipping to change at page 41, line 24 |
| product = token ["/" product-version] |  | product = token ["/" product-version] |
| product-version = token |  | product-version = token |
| Examples: |  | Examples: |
| User-Agent: CERN-LineMode/2.15 libwww/2.17b3 |  | User-Agent: CERN-LineMode/2.15 libwww/2.17b3 |
| Server: Apache/0.8.4 |  | Server: Apache/0.8.4 |
| Product tokens SHOULD be short and to the point. They MUST NOT be |  | Product tokens SHOULD be short and to the point. They MUST NOT be |
| used for advertising or other non-essential information. Although |  | used for advertising or other non-essential information. Although |
| any token character MAY appear in a product-version, this token |  | any token octet MAY appear in a product-version, this token SHOULD |
| SHOULD only be used for a version identifier (i.e., successive |  | only be used for a version identifier (i.e., successive versions of |
| versions of the same product SHOULD only differ in the product- |  | the same product SHOULD only differ in the product-version portion of |
| version portion of the product value). |  | the product value). |
| 6.4. Quality Values |  | 6.4. Quality Values |
| Both transfer codings (TE request header field, Section 9.5) and |  | Both transfer codings (TE request header field, Section 9.5) 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 |
| skipping to change at page 40, line 9 |  | skipping to change at page 42, line 9 |
| 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. |
| 7. Connections |  | 7. Connections |
| 7.1. Persistent Connections |  | 7.1. Persistent Connections |
| 7.1.1. Purpose |  | 7.1.1. Purpose |
| Prior to persistent connections, a separate TCP connection was |  | Prior to persistent connections, a separate TCP connection was |
| established to fetch each URL, increasing the load on HTTP servers |  | established for each request, increasing the load on HTTP servers and |
| and causing congestion on the Internet. The use of inline images and |  | causing congestion on the Internet. The use of inline images and |
| other associated data often requires a client to make multiple |  | other associated data often requires a client to make multiple |
| requests of the same server in a short amount of time. Analysis of |  | requests of the same server in a short amount of time. Analysis of |
| these performance problems and results from a prototype |  | these performance problems and results from a prototype |
| implementation are available [Pad1995] [Spe]. Implementation |  | implementation are available [Pad1995] [Spe]. Implementation |
| experience and measurements of actual HTTP/1.1 implementations show |  | experience and measurements of actual HTTP/1.1 implementations show |
| good results [Nie1997]. Alternatives have also been explored, for |  | good results [Nie1997]. Alternatives have also been explored, for |
| example, T/TCP [Tou1998]. |  | example, T/TCP [Tou1998]. |
| Persistent HTTP connections have a number of advantages: |  | Persistent HTTP connections have a number of advantages: |
| skipping to change at page 41, line 34 |  | skipping to change at page 43, line 34 |
| In case the client does not want to maintain a connection for more |  | In case the client does not want to maintain a connection for more |
| than that request, it SHOULD send a Connection header field including |  | than that request, it SHOULD send a Connection header field including |
| the connection-token close. |  | the connection-token close. |
| If either the client or the server sends the close token in the |  | 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 header field, that request becomes the last one for the |
| connection. |  | connection. |
| Clients and servers SHOULD NOT assume that a persistent connection is |  | Clients and servers SHOULD NOT assume that a persistent connection is |
| maintained for HTTP versions less than 1.1 unless it is explicitly |  | maintained for HTTP versions less than 1.1 unless it is explicitly |
| signaled. See Appendix B.2 for more information on backward |  | signaled. See Appendix B.1.2 for more information on backward |
| compatibility with HTTP/1.0 clients. |  | compatibility with HTTP/1.0 clients. |
| In order to remain persistent, all messages on the connection MUST |  | In order to remain persistent, all messages on the connection MUST |
| have a self-defined message length (i.e., one not defined by closure |  | have a self-defined message length (i.e., one not defined by closure |
| of the connection), as described in Section 3.3. |  | of the connection), as described in Section 3.3. |
| 7.1.2.2. Pipelining |  | 7.1.2.2. Pipelining |
| A client that supports persistent connections MAY "pipeline" its |  | A client that supports persistent connections MAY "pipeline" its |
| requests (i.e., send multiple requests without waiting for each |  | requests (i.e., send multiple requests without waiting for each |
| skipping to change at page 42, line 8 |  | skipping to change at page 44, line 8 |
| same order that the requests were received. |  | same order that the requests were received. |
| Clients which assume persistent connections and pipeline immediately |  | Clients which assume persistent connections and pipeline immediately |
| after connection establishment SHOULD be prepared to retry their |  | after connection establishment SHOULD be prepared to retry their |
| connection if the first pipelined attempt fails. If a client does |  | connection if the first pipelined attempt fails. If a client does |
| such a retry, it MUST NOT pipeline before it knows the connection is |  | such a retry, it MUST NOT pipeline before it knows the connection is |
| persistent. Clients MUST also be prepared to resend their requests |  | persistent. Clients MUST also be prepared to resend their requests |
| if the server closes the connection before sending all of the |  | if the server closes the connection before sending all of the |
| corresponding responses. |  | corresponding responses. |
| Clients SHOULD NOT pipeline requests using non-idempotent methods or |  | Clients SHOULD NOT pipeline requests using non-idempotent request |
| non-idempotent sequences of methods (see Section 7.1.2 of [Part2]). |  | methods or non-idempotent sequences of request methods (see Section |
| Otherwise, a premature termination of the transport connection could |  | 7.1.2 of [Part2]). Otherwise, a premature termination of the |
| lead to indeterminate results. A client wishing to send a non- |  | transport connection could lead to indeterminate results. A client |
| idempotent request SHOULD wait to send that request until it has |  | wishing to send a non-idempotent request SHOULD wait to send that |
| received the response status line for the previous request. |  | request until it has received the response status line for the |
|  |  | previous request. |
| 7.1.3. Proxy Servers |  | 7.1.3. Proxy Servers |
| It is especially important that proxies correctly implement the |  | It is especially important that proxies correctly implement the |
| properties of the Connection header field as specified in |  | properties of the Connection header field as specified in |
| Section 9.1. |  | Section 9.1. |
| The proxy server MUST signal persistent connections separately with |  | The proxy server MUST signal persistent connections separately with |
| its clients and the origin servers (or other proxy servers) that it |  | its clients and the origin servers (or other proxy servers) that it |
| connects to. Each persistent connection applies to only one |  | connects to. Each persistent connection applies to only one |
| skipping to change at page 43, line 25 |  | skipping to change at page 45, line 25 |
| 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 9.1). |  | field (Section 9.1). |
| 7.1.3.2. Non-modifiable Header Fields |  | 7.1.3.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 transparent proxy |  | the value of certain end-to-end header fields. A non-transforming |
| SHOULD NOT modify an end-to-end header field unless the definition of |  | proxy SHOULD NOT modify an end-to-end header field unless the |
| that header field requires or specifically allows that. |  | definition of that header field requires or specifically allows that. |
| A transparent proxy MUST NOT modify any of the following fields in a |  | A non-transforming proxy MUST NOT modify any of the following fields |
| request or response, and it MUST NOT add any of these fields if not |  | in a request or response, and it MUST NOT add any of these fields if |
| already present: |  | not already present: |
| o Content-Location |  | o Content-Location |
| o Content-MD5 |  | o Content-MD5 |
| o ETag |  | o ETag |
| o Last-Modified |  | o Last-Modified |
| A transparent proxy MUST NOT modify any of the following fields in a |  | A non-transforming proxy MUST NOT modify any of the following fields |
| response: |  | in a response: |
| o Expires |  | o Expires |
| but it MAY add any of these fields if not already present. If an |  | but it MAY add any of these fields if not already present. If an |
| Expires header field is added, it MUST be given a field-value |  | Expires header field is added, it MUST be given a field-value |
| identical to that of the Date header field in that response. |  | identical to that of the Date header field in that response. |
| A proxy MUST NOT modify or add any of the following fields in a |  | A proxy MUST NOT modify or add any of the following fields in a |
| message that contains the no-transform cache-control directive, or in |  | message that contains the no-transform cache-control directive, or in |
| any request: |  | any request: |
| o Content-Encoding |  | o Content-Encoding |
| o Content-Range |  | o Content-Range |
| o Content-Type |  | o Content-Type |
| A non-transparent proxy MAY modify or add these fields to a message |  | A transforming proxy MAY modify or add these fields to a message that |
| that does not include no-transform, but if it does so, it MUST add a |  | does not include no-transform, but if it does so, it MUST add a |
| Warning 214 (Transformation applied) if one does not already appear |  | Warning 214 (Transformation applied) if one does not already appear |
| in the message (see Section 3.6 of [Part6]). |  | in the message (see Section 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 transparent 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 6.2). |  | of a transfer-coding (Section 6.2). |
| 7.1.4. Practical Considerations |  | 7.1.4. 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 |
| skipping to change at page 45, line 6 |  | skipping to change at page 47, line 6 |
| time. For example, a client might have started to send a new request |  | time. For example, a client might have started to send a new request |
| at the same time that the server has decided to close the "idle" |  | at the same time that the server has decided to close the "idle" |
| connection. From the server's point of view, the connection is being |  | connection. From the server's point of view, the connection is being |
| closed while it was idle, but from the client's point of view, a |  | closed while it was idle, but from the client's point of view, a |
| request is in progress. |  | request is in progress. |
| This means that clients, servers, and proxies MUST be able to recover |  | This means that clients, servers, and proxies MUST be able to recover |
| from asynchronous close events. Client software SHOULD reopen the |  | from asynchronous close events. Client software SHOULD reopen the |
| transport connection and retransmit the aborted sequence of requests |  | transport connection and retransmit the aborted sequence of requests |
| without user interaction so long as the request sequence is |  | without user interaction so long as the request sequence is |
| idempotent (see Section 7.1.2 of [Part2]). Non-idempotent methods or |  | idempotent (see Section 7.1.2 of [Part2]). Non-idempotent request |
| sequences MUST NOT be automatically retried, although user agents MAY |  | methods or sequences MUST NOT be automatically retried, although user |
| offer a human operator the choice of retrying the request(s). |  | agents MAY offer a human operator the choice of retrying the |
| Confirmation by user-agent software with semantic understanding of |  | request(s). Confirmation by user-agent software with semantic |
| the application MAY substitute for user confirmation. The automatic |  | understanding of the application MAY substitute for user |
| retry SHOULD NOT be repeated if the second sequence of requests |  | confirmation. The automatic retry SHOULD NOT be repeated if the |
| fails. |  | second sequence of requests fails. |
| Servers SHOULD always respond to at least one request per connection, |  | Servers SHOULD always respond to at least one request per connection, |
| if at all possible. Servers SHOULD NOT close a connection in the |  | if at all possible. Servers SHOULD NOT close a connection in the |
| middle of transmitting a response, unless a network or client failure |  | middle of transmitting a response, unless a network or client failure |
| is suspected. |  | is suspected. |
| Clients (including proxies) SHOULD limit the number of simultaneous |  | Clients (including proxies) SHOULD limit the number of simultaneous |
| connections that they maintain to a given server (including proxies). |  | connections that they maintain to a given server (including proxies). |
| Previous revisions of HTTP gave a specific number of connections as a |  | Previous revisions of HTTP gave a specific number of connections as a |
| skipping to change at page 46, line 24 |  | skipping to change at page 48, line 24 |
| [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 request-header field |  | the request body, it MUST send an Expect header field (Section 9.2 |
| (Section 9.2 of [Part2]) with the "100-continue" expectation. |  | of [Part2]) with the "100-continue" expectation. |
| o A client MUST NOT send an Expect request-header field (Section 9.2 |  | o A client MUST NOT send an Expect header field (Section 9.2 of |
| of [Part2]) with the "100-continue" expectation if it does not |  | [Part2]) with the "100-continue" expectation if it does not intend |
| 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. |
| Requirements for HTTP/1.1 origin servers: |  | Requirements for HTTP/1.1 origin servers: |
| o Upon receiving a request which includes an Expect request-header |  | o Upon receiving a request which includes an Expect header field |
| field with the "100-continue" expectation, an origin server MUST |  | with the "100-continue" expectation, an origin server MUST either |
| either respond with 100 (Continue) status code and continue to |  | respond with 100 (Continue) status code and continue to read from |
| read from the input stream, or respond with a final status code. |  | the input stream, or respond with a final status code. The origin |
| The origin server MUST NOT wait for the request body before |  | server MUST NOT wait for the request body before sending the 100 |
| sending the 100 (Continue) response. If it responds with a final |  | (Continue) response. If it responds with a final status code, it |
| status code, it MAY close the transport connection or it MAY |  | MAY close the transport connection or it MAY continue to read and |
| continue to read and discard the rest of the request. It MUST NOT |  | discard the rest of the request. It MUST NOT perform the request |
| perform the requested method if it returns a final status code. |  | method if it returns a final status code. |
| o An origin server SHOULD NOT send a 100 (Continue) response if the |  | o An origin server SHOULD NOT send a 100 (Continue) response if the |
| request message does not include an Expect request-header field |  | request message does not include an Expect header field with the |
| with the "100-continue" expectation, and MUST NOT send a 100 |  | "100-continue" expectation, and MUST NOT send a 100 (Continue) |
| (Continue) response if such a request comes from an HTTP/1.0 (or |  | response if such a request comes from an HTTP/1.0 (or earlier) |
| earlier) client. There is an exception to this rule: for |  | client. There is an exception to this rule: for compatibility |
| compatibility with [RFC2068], a server MAY send a 100 (Continue) |  | with [RFC2068], a server MAY send a 100 (Continue) status code in |
| status code in response to an HTTP/1.1 PUT or POST request that |  | response to an HTTP/1.1 PUT or POST request that does not include |
| does not include an Expect request-header field with the "100- |  | an Expect header field with the "100-continue" expectation. This |
| continue" expectation. This exception, the purpose of which is to |  | exception, the purpose of which is to minimize any client |
| minimize any client processing delays associated with an |  | processing delays associated with an undeclared wait for 100 |
| undeclared wait for 100 (Continue) status code, applies only to |  | (Continue) status code, applies only to HTTP/1.1 requests, and not |
| HTTP/1.1 requests, and not to requests with any other HTTP-version |  | to requests with any other HTTP-version value. |
| value. |  |  |
| o An origin server MAY omit a 100 (Continue) response if it has |  | o An origin server MAY omit a 100 (Continue) response if it has |
| already received some or all of the request body for the |  | already received some or all of the request body for the |
| corresponding request. |  | corresponding request. |
| o An origin server that sends a 100 (Continue) response MUST |  | o An origin server that sends a 100 (Continue) response MUST |
| ultimately send a final status code, once the request body is |  | ultimately send a final status code, once the request body is |
| received and processed, unless it terminates the transport |  | received and processed, unless it terminates the transport |
| 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 request-header field with the "100-continue" expectation, |  | Expect header field with the "100-continue" expectation, the |
| the request includes a request body, and the server responds with |  | request includes a request body, and the server responds with a |
| a final status code before reading the entire request body from |  | final status code before reading the entire request body from the |
| 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 is 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 request- |  | o If a proxy receives a request that includes an Expect header field |
| header field with the "100-continue" expectation, and the proxy |  | with the "100-continue" expectation, and the proxy either knows |
| either knows that the next-hop server complies with HTTP/1.1 or |  | that the next-hop server complies with HTTP/1.1 or higher, or does |
| higher, or does not know the HTTP version of the next-hop server, |  | not know the HTTP version of the next-hop server, it MUST forward |
| it MUST forward the request, including the Expect header field. |  | the request, including the Expect header field. |
| o If the proxy knows that the version of the next-hop server is |  | o If the proxy knows that the version of the next-hop server is |
| HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST |  | HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST |
| respond with a 417 (Expectation Failed) status code. |  | respond with a 417 (Expectation Failed) status code. |
| o Proxies SHOULD maintain a cache recording the HTTP version numbers |  | o Proxies SHOULD maintain a cache recording 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 request-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 8.1 of [Part2]). |  | forwarding of 1xx responses (see Section 8.1 of [Part2]). |
| 7.2.4. Client Behavior if Server Prematurely Closes Connection |  | 7.2.4. Client Behavior if Server Prematurely Closes Connection |
| If an HTTP/1.1 client sends a request which includes a request body, |  | If an HTTP/1.1 client sends a request which includes a request body, |
| but which does not include an Expect request-header field with the |  | but which does not include an Expect header field with the "100- |
| "100-continue" expectation, and if the client is not directly |  | continue" expectation, and if the client is not directly connected to |
| connected to an HTTP/1.1 origin server, and if the client sees the |  | an HTTP/1.1 origin server, and if the client sees the connection |
| connection close before receiving a status line from the server, the |  | close before receiving a status line from the server, the client |
| client SHOULD retry the request. If the client does retry this |  | SHOULD retry the request. If the client does retry this request, it |
| request, it MAY use the following "binary exponential backoff" |  | MAY use the following "binary exponential backoff" algorithm to be |
| algorithm to be assured of obtaining a reliable response: |  | assured of obtaining a reliable response: |
| 1. Initiate a new connection to the server |  | 1. Initiate a new connection to the server |
| 2. Transmit the request-header fields |  | 2. Transmit the request-line, header fields, and the CRLF that |
|  |  | indicates the end of header fields. |
| 3. Initialize a variable R to the estimated round-trip time to the |  | 3. Initialize a variable R to the estimated round-trip time to the |
| server (e.g., based on the time it took to establish the |  | server (e.g., based on the time it took to establish the |
| connection), or to a constant value of 5 seconds if the round- |  | connection), or to a constant value of 5 seconds if the round- |
| trip time is not available. |  | trip time is not available. |
| 4. Compute T = R * (2**N), where N is the number of previous retries |  | 4. Compute T = R * (2**N), where N is the number of previous retries |
| of this request. |  | of this request. |
| 5. Wait either for an error response from the server, or for T |  | 5. Wait either for an error response from the server, or for T |
| skipping to change at page 49, line 36 |  | skipping to change at page 51, line 34 |
| [[TBD-profiles: Profiles of HTTP defined by other protocol. |  | [[TBD-profiles: Profiles of HTTP defined by other protocol. |
| Extensions of HTTP like WebDAV.]] |  | Extensions of HTTP like WebDAV.]] |
| 8.5. Use of HTTP by media type specification |  | 8.5. Use of HTTP by media type specification |
| [[TBD-hypertext: Instructions on composing HTTP requests via |  | [[TBD-hypertext: Instructions on composing HTTP requests via |
| hypertext formats.]] |  | hypertext formats.]] |
| 9. Header Field Definitions |  | 9. Header Field Definitions |
| This section defines the syntax and semantics of HTTP/1.1 header |  | This section defines the syntax and semantics of HTTP header fields |
| fields related to message framing and transport protocols. |  | related to message framing and transport protocols. |
| 9.1. Connection |  | 9.1. Connection |
| The "Connection" general-header field allows the sender to specify |  | The "Connection" header field allows the sender to specify options |
| options that are desired for that particular connection and MUST NOT |  | that are desired only for that particular connection. Such |
| be communicated by proxies over further connections. |  | 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: |  | The Connection header field's value has the following grammar: |
| Connection = "Connection" ":" OWS Connection-v |  | Connection = "Connection" ":" OWS Connection-v |
| Connection-v = 1#connection-token |  | Connection-v = 1#connection-token |
| connection-token = token |  | connection-token = token |
| HTTP/1.1 proxies MUST parse the Connection header field before a |  | A proxy or gateway MUST parse a received Connection header field |
| message is forwarded and, for each connection-token in this field, |  | before a message is forwarded and, for each connection-token in this |
| remove any header field(s) from the message with the same name as the |  | field, remove any header field(s) from the message with the same name |
| connection-token. Connection options are signaled by the presence of |  | as the connection-token, and then remove the Connection header field |
| a connection-token in the Connection header field, not by any |  | itself or replace it with the sender's own connection options for the |
| corresponding additional header field(s), since the additional header |  | forwarded message. |
| field might not be sent if there are no parameters associated with |  |  |
| that connection option. |  |  |
| Message header fields listed in the Connection header field MUST NOT |  | A sender MUST NOT include field-names in the Connection header field- |
| include end-to-end header fields, such as Cache-Control. |  | 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 |  | HTTP/1.1 defines the "close" connection option for the sender to |
| signal that the connection will be closed after completion of the |  | signal that the connection will be closed after completion of the |
| response. For example, |  | response. For example, |
| Connection: close |  | Connection: close |
| in either the request or the response header fields indicates that |  | in either the request or the response header fields indicates that |
| the connection SHOULD NOT be considered "persistent" (Section 7.1) |  | the connection SHOULD NOT be considered "persistent" (Section 7.1) |
| after the current request/response is complete. |  | after the current request/response is complete. |
| An HTTP/1.1 client that does not support persistent connections MUST |  | An HTTP/1.1 client that does not support persistent connections MUST |
| include the "close" connection option in every request message. |  | include the "close" connection option in every request message. |
| An HTTP/1.1 server that does not support persistent connections MUST |  | An HTTP/1.1 server that does not support persistent connections MUST |
| include the "close" connection option in every response message that |  | include the "close" connection option in every response message that |
| does not have a 1xx (Informational) status code. |  | does not have a 1xx (Informational) status code. |
| A system receiving an HTTP/1.0 (or lower-version) message that |  |  |
| includes a Connection header field MUST, for each connection-token in |  |  |
| this field, remove and ignore any header field(s) from the message |  |  |
| with the same name as the connection-token. This protects against |  |  |
| mistaken forwarding of such header fields by pre-HTTP/1.1 proxies. |  |  |
| See Appendix B.2. |  |  |
| 9.2. Content-Length |  | 9.2. Content-Length |
| The "Content-Length" header field indicates the size of the message- |  | The "Content-Length" header field indicates the size of the message- |
| body, in decimal number of octets, for any message other than a |  | body, in decimal number of octets, for any message other than a |
| response to the HEAD method or a response with a status code of 304. |  | response to a HEAD request or a response with a status code of 304. |
| In the case of responses to the HEAD method, it indicates the size of |  | In the case of a response to a HEAD request, Content-Length indicates |
| the payload body (not including any potential transfer-coding) that |  | the size of the payload body (not including any potential transfer- |
| would have been sent had the request been a GET. In the case of the |  | coding) that would have been sent had the request been a GET. In the |
| 304 (Not Modified) response, it indicates the size of the payload |  | case of a 304 (Not Modified) response to a GET request, Content- |
| body (not including any potential transfer-coding) that would have |  | Length indicates the size of the payload body (not including any |
| been sent in a 200 (OK) response. |  | potential transfer-coding) that would have been sent in a 200 (OK) |
|  |  | response. |
| Content-Length = "Content-Length" ":" OWS 1*Content-Length-v |  | Content-Length = "Content-Length" ":" OWS 1*Content-Length-v |
| Content-Length-v = 1*DIGIT |  | Content-Length-v = 1*DIGIT |
| An example is |  | An example is |
| Content-Length: 3495 |  | Content-Length: 3495 |
| Implementations SHOULD use this field to indicate the message-body |  | Implementations SHOULD use this field to indicate the message-body |
| length when no transfer-coding is being applied and the payload's |  | length when no transfer-coding is being applied and the payload's |
| skipping to change at page 51, line 24 |  | skipping to change at page 53, line 44 |
| message-body. |  | message-body. |
| Any Content-Length greater than or equal to zero is a valid value. |  | 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 |  | Note that the use of this field in HTTP is significantly different |
| from the corresponding definition in MIME, where it is an optional |  | from the corresponding definition in MIME, where it is an optional |
| field used within the "message/external-body" content-type. |  | field used within the "message/external-body" content-type. |
| 9.3. Date |  | 9.3. Date |
| The "Date" general-header field represents the date and time at which |  | The "Date" header field represents the date and time at which the |
| the message was originated, having the same semantics as the |  | message was originated, having the same semantics as the Origination |
| Origination Date Field (orig-date) defined in Section 3.6.1 of |  | Date Field (orig-date) defined in Section 3.6.1 of [RFC5322]. The |
| [RFC5322]. The field value is an HTTP-date, as described in |  | field value is an HTTP-date, as described in Section 6.1; it MUST be |
| Section 6.1; it MUST be sent in rfc1123-date format. |  | sent in rfc1123-date format. |
| Date = "Date" ":" OWS Date-v |  | Date = "Date" ":" OWS Date-v |
| Date-v = HTTP-date |  | Date-v = HTTP-date |
| An example is |  | An example is |
| Date: Tue, 15 Nov 1994 08:12:31 GMT |  | Date: Tue, 15 Nov 1994 08:12:31 GMT |
| Origin servers MUST include a Date header field in all responses, |  | Origin servers MUST include a Date header field in all responses, |
| except in these cases: |  | except in these cases: |
| skipping to change at page 52, line 7 |  | skipping to change at page 54, line 27 |
| (Internal Server Error) or 503 (Service Unavailable), and it is |  | (Internal Server Error) or 503 (Service Unavailable), and it is |
| inconvenient or impossible to generate a valid Date. |  | inconvenient or impossible to generate a valid Date. |
| 3. If the server does not have a clock that can provide a reasonable |  | 3. If the server does not have a clock that can provide a reasonable |
| approximation of the current time, its responses MUST NOT include |  | approximation of the current time, its responses MUST NOT include |
| a Date header field. In this case, the rules in Section 9.3.1 |  | a Date header field. In this case, the rules in Section 9.3.1 |
| MUST be followed. |  | MUST be followed. |
| A received message that does not have a Date header field MUST be |  | A received message that does not have a Date header field MUST be |
| assigned one by the recipient if the message will be cached by that |  | assigned one by the recipient if the message will be cached by that |
| recipient or gatewayed via a protocol which requires a Date. |  | recipient. |
| Clients can use the Date header field as well; in order to keep |  | Clients can use the Date header field as well; in order to keep |
| request messages small, they are advised not to include it when it |  | request messages small, they are advised not to include it when it |
| doesn't convey any useful information (as it is usually the case for |  | doesn't convey any useful information (as it is usually the case for |
| requests that do not contain a payload). |  | requests that do not contain a payload). |
| The HTTP-date sent in a Date header field SHOULD NOT represent a date |  | The HTTP-date sent in a Date header field SHOULD NOT represent a date |
| and time subsequent to the generation of the message. It SHOULD |  | and time subsequent to the generation of the message. It SHOULD |
| represent the best available approximation of the date and time of |  | represent the best available approximation of the date and time of |
| message generation, unless the implementation has no means of |  | message generation, unless the implementation has no means of |
| skipping to change at page 52, line 36 |  | skipping to change at page 55, line 7 |
| An origin server without a clock MUST NOT assign Expires or Last- |  | An origin server without a clock MUST NOT assign Expires or Last- |
| Modified values to a response, unless these values were associated |  | Modified values to a response, unless these values were associated |
| with the resource by a system or user with a reliable clock. It MAY |  | with the resource by a system or user with a reliable clock. It MAY |
| assign an Expires value that is known, at or before server |  | assign an Expires value that is known, at or before server |
| configuration time, to be in the past (this allows "pre-expiration" |  | configuration time, to be in the past (this allows "pre-expiration" |
| of responses without storing separate Expires values for each |  | of responses without storing separate Expires values for each |
| resource). |  | resource). |
| 9.4. Host |  | 9.4. Host |
| The "Host" request-header field specifies the Internet host and port |  | The "Host" header field in a request provides the host and port |
| number of the resource being requested, allowing the origin server or |  | information from the target resource's URI, enabling the origin |
| gateway to differentiate between internally-ambiguous URLs, such as |  | server to distinguish between resources while servicing requests for |
| the root "/" URL of a server for multiple host names on a single IP |  | multiple host names on a single IP address. Since the Host field- |
| address. |  | value is critical information for handling a request, it SHOULD be |
|  |  | sent as the first header field following the Request-Line. |
| The Host field value MUST represent the naming authority of the |  |  |
| origin server or gateway given by the original URL obtained from the |  |  |
| user or referring resource (generally an http URI, as described in |  |  |
| Section 2.6.1). |  |  |
| Host = "Host" ":" OWS Host-v |  | Host = "Host" ":" OWS Host-v |
| Host-v = uri-host [ ":" port ] ; Section 2.6.1 |  | Host-v = uri-host [ ":" port ] ; Section 2.6.1 |
| A "host" without any trailing port information implies the default |  | A client MUST send a Host header field in all HTTP/1.1 request |
| port for the service requested (e.g., "80" for an HTTP URL). For |  | messages. If the target resource's URI includes an authority |
| example, a request on the origin server for |  | component, then the Host field-value MUST be identical to that |
| <http://www.example.org/pub/WWW/> would properly include: |  | authority component after excluding any userinfo (Section 2.6.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 |  | GET /pub/WWW/ HTTP/1.1 |
| Host: www.example.org |  | Host: www.example.org |
| A client MUST include a Host header field in all HTTP/1.1 request |  | The Host header field MUST be sent in an HTTP/1.1 request even if the |
| messages. If the requested URI does not include an Internet host |  | request-target is in the form of an absolute-URI, since this allows |
| name for the service being requested, then the Host header field MUST |  | the Host information to be forwarded through ancient HTTP/1.0 proxies |
| be given with an empty value. An HTTP/1.1 proxy MUST ensure that any |  | that might not have implemented Host. |
| request message it forwards does contain an appropriate Host header |  |  |
| field that identifies the service being requested by the proxy. All |  | When an HTTP/1.1 proxy receives a request with a request-target in |
| Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request) |  | the form of an absolute-URI, the proxy MUST ignore the received Host |
| status code to any HTTP/1.1 request message which lacks a Host header |  | header field (if any) and instead replace it with the host |
| field. |  | 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 B.1.1 for other requirements relating to Host. |  | See Sections 4.2 and B.1.1 for other requirements relating to Host. |
| 9.5. TE |  | 9.5. TE |
| The "TE" request-header field indicates what extension transfer- |  | The "TE" header field indicates what extension transfer-codings it is |
| codings it is willing to accept in the response, and whether or not |  | willing to accept in the response, and whether or not it is willing |
| it is willing to accept trailer fields in a chunked transfer-coding. |  | to accept trailer fields in a chunked transfer-coding. |
| Its value consists of the keyword "trailers" and/or a comma-separated |  | Its value consists of the keyword "trailers" and/or a comma-separated |
| list of extension transfer-coding names with optional accept |  | list of extension transfer-coding names with optional accept |
| parameters (as described in Section 6.2). |  | parameters (as described in Section 6.2). |
| TE = "TE" ":" OWS TE-v |  | TE = "TE" ":" OWS TE-v |
| TE-v = #t-codings |  | TE-v = #t-codings |
| t-codings = "trailers" / ( transfer-extension [ te-params ] ) |  | t-codings = "trailers" / ( transfer-extension [ te-params ] ) |
| te-params = OWS ";" OWS "q=" qvalue *( te-ext ) |  | te-params = OWS ";" OWS "q=" qvalue *( te-ext ) |
| te-ext = OWS ";" OWS token [ "=" word ] |  | te-ext = OWS ";" OWS token [ "=" word ] |
| skipping to change at page 54, line 36 |  | skipping to change at page 57, line 25 |
| 3. If multiple transfer-codings are acceptable, then the acceptable |  | 3. If multiple transfer-codings are acceptable, then the acceptable |
| transfer-coding with the highest non-zero qvalue is preferred. |  | transfer-coding with the highest non-zero qvalue is preferred. |
| The "chunked" transfer-coding always has a qvalue of 1. |  | The "chunked" transfer-coding always has a qvalue of 1. |
| If the TE field-value is empty or if no TE field is present, the only |  | If the TE field-value is empty or if no TE field is present, the only |
| transfer-coding is "chunked". A message with no transfer-coding is |  | transfer-coding is "chunked". A message with no transfer-coding is |
| always acceptable. |  | always acceptable. |
| 9.6. Trailer |  | 9.6. Trailer |
| The "Trailer" general-header field indicates that the given set of |  | The "Trailer" header field indicates that the given set of header |
| header fields is present in the trailer of a message encoded with |  | fields is present in the trailer of a message encoded with chunked |
| chunked transfer-coding. |  | transfer-coding. |
| Trailer = "Trailer" ":" OWS Trailer-v |  | Trailer = "Trailer" ":" OWS Trailer-v |
| Trailer-v = 1#field-name |  | Trailer-v = 1#field-name |
| An HTTP/1.1 message SHOULD include a Trailer header field in a |  | An HTTP/1.1 message SHOULD include a Trailer header field in a |
| message using chunked transfer-coding with a non-empty trailer. |  | message using chunked transfer-coding with a non-empty trailer. |
| Doing so allows the recipient to know which header fields to expect |  | Doing so allows the recipient to know which header fields to expect |
| in the trailer. |  | in the trailer. |
| If no Trailer header field is present, the trailer SHOULD NOT include |  | If no Trailer header field is present, the trailer SHOULD NOT include |
| skipping to change at page 55, line 14 |  | skipping to change at page 58, line 7 |
| include the following header fields: |  | include the following header fields: |
| o Transfer-Encoding |  | o Transfer-Encoding |
| o Content-Length |  | o Content-Length |
| o Trailer |  | o Trailer |
| 9.7. Transfer-Encoding |  | 9.7. Transfer-Encoding |
| The "Transfer-Encoding" general-header field indicates what transfer- |  | The "Transfer-Encoding" header field indicates what transfer-codings |
| codings (if any) have been applied to the message body. It differs |  | (if any) have been applied to the message body. It differs from |
| from Content-Encoding (Section 2.2 of [Part3]) in that transfer- |  | Content-Encoding (Section 2.2 of [Part3]) in that transfer-codings |
| codings are a property of the message (and therefore are removed by |  | are a property of the message (and therefore are removed by |
| intermediaries), whereas content-codings are not. |  | intermediaries), whereas content-codings are not. |
| Transfer-Encoding = "Transfer-Encoding" ":" OWS |  | Transfer-Encoding = "Transfer-Encoding" ":" OWS |
| Transfer-Encoding-v |  | Transfer-Encoding-v |
| Transfer-Encoding-v = 1#transfer-coding |  | Transfer-Encoding-v = 1#transfer-coding |
| Transfer-codings are defined in Section 6.2. An example is: |  | Transfer-codings are defined in Section 6.2. An example is: |
| Transfer-Encoding: chunked |  | Transfer-Encoding: chunked |
| If multiple encodings have been applied to a representation, the |  | If multiple encodings have been applied to a representation, the |
| transfer-codings MUST be listed in the order in which they were |  | transfer-codings MUST be listed in the order in which they were |
| applied. Additional information about the encoding parameters MAY be |  | applied. Additional information about the encoding parameters MAY be |
| provided by other header fields not defined by this specification. |  | provided by other header fields not defined by this specification. |
| Many older HTTP/1.0 applications do not understand the Transfer- |  | Many older HTTP/1.0 applications do not understand the Transfer- |
| Encoding header field. |  | Encoding header field. |
| 9.8. Upgrade |  | 9.8. Upgrade |
| The "Upgrade" general-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. Additionally, the server MUST |  | server chooses to switch protocols. Servers can use it to indicate |
| use the Upgrade header field within a 101 (Switching Protocols) |  | what protocols they are willing to switch to. |
| response to indicate which protocol(s) are being switched to. |  |  |
| Upgrade = "Upgrade" ":" OWS Upgrade-v |  | Upgrade = "Upgrade" ":" OWS Upgrade-v |
| Upgrade-v = 1#product |  | Upgrade-v = 1#product |
| 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 transition 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 |
| method and/or resource being requested). |  | request method or target resource). |
| The Upgrade header field only applies to switching application-layer |  | The Upgrade header field only applies to switching application-layer |
| 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 9.1) whenever Upgrade is present in an HTTP/1.1 |  | header field (Section 9.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 301, 302, 303, or 305 redirection response. |  | appropriate to use a 3xx redirection response (Section 8.3 of |
|  |  | [Part2]). |
|  |  | Servers MUST include the "Upgrade" header field in 101 (Switching |
|  |  | Protocols) responses to indicate which protocol(s) are being switched |
|  |  | to, and MUST include it in 426 (Upgrade Required) responses to |
|  |  | indicate acceptable protocols to upgrade to. Servers MAY include it |
|  |  | in any other response to indicate that they are willing to upgrade to |
|  |  | 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.5 and future updates to this |  | version rules of Section 2.5 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 below. |
| 9.8.1. Upgrade Token Registry |  | 9.8.1. Upgrade Token Registry |
| The HTTP Upgrade Token Registry defines the name space for product |  | The HTTP Upgrade Token Registry defines the name space for product |
| skipping to change at page 57, line 29 |  | skipping to change at page 60, line 29 |
| 6. The responsible party for the first registration of a "product" |  | 6. The responsible party for the first registration of a "product" |
| token MUST approve later registrations of a "version" token |  | token MUST approve later registrations of a "version" token |
| together with that "product" token before they can be registered. |  | together with that "product" token before they can be registered. |
| 7. If absolutely required, the IESG MAY reassign the responsibility |  | 7. If absolutely required, the IESG MAY reassign the responsibility |
| for a token. This will normally only be used in the case when a |  | for a token. This will normally only be used in the case when a |
| responsible party cannot be contacted. |  | responsible party cannot be contacted. |
| 9.9. Via |  | 9.9. Via |
| The "Via" general-header field MUST be used by gateways and proxies |  | The "Via" header field MUST be sent by a proxy or gateway to indicate |
| to indicate the intermediate protocols and recipients between the |  | the intermediate protocols and recipients between the user agent and |
| user agent and the server on requests, and between the origin server |  | the server on requests, and between the origin server and the client |
| and the client on responses. It is analogous to the "Received" field |  | on responses. It is analogous to the "Received" field used by email |
| defined in Section 3.6.7 of [RFC5322] and is intended to be used for |  | systems (Section 3.6.7 of [RFC5322]) and is intended to be used for |
| tracking message forwards, avoiding request loops, and identifying |  | tracking message forwards, avoiding request loops, and identifying |
| the protocol capabilities of all senders along the request/response |  | the protocol capabilities of all senders along the request/response |
| chain. |  | chain. |
| Via = "Via" ":" OWS Via-v |  | Via = "Via" ":" OWS Via-v |
| Via-v = 1#( received-protocol RWS received-by |  | Via-v = 1#( received-protocol RWS received-by |
| [ RWS comment ] ) |  | [ RWS comment ] ) |
| received-protocol = [ protocol-name "/" ] protocol-version |  | received-protocol = [ protocol-name "/" ] protocol-version |
| protocol-name = token |  | protocol-name = token |
| protocol-version = token |  | protocol-version = token |
| received-by = ( uri-host [ ":" port ] ) / pseudonym |  | received-by = ( uri-host [ ":" port ] ) / pseudonym |
| pseudonym = token |  | pseudonym = token |
| The received-protocol indicates the protocol version of the message |  | The received-protocol indicates the protocol version of the message |
| received by the server or client along each segment of the request/ |  | received by the server or client along each segment of the request/ |
| response chain. The received-protocol version is appended to the Via |  | response chain. The received-protocol version is appended to the Via |
| field value when the message is forwarded so that information about |  | field value when the message is forwarded so that information about |
| the protocol capabilities of upstream applications remains visible to |  | the protocol capabilities of upstream applications remains visible to |
| all recipients. |  | all recipients. |
| The protocol-name is optional if and only if it would be "HTTP". The |  | 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 |  | received-by field is normally the host and optional port number of a |
| recipient server or client that subsequently forwarded the message. |  | recipient server or client that subsequently forwarded the message. |
| However, if the real host is considered to be sensitive information, |  | 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 |  | 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. |  | be assumed to be the default port of the received-protocol. |
| Multiple Via field values represent each proxy or gateway that has |  | Multiple Via field values represent each proxy or gateway that has |
| forwarded the message. Each recipient MUST append its information |  | forwarded the message. Each recipient MUST append its information |
| such that the end result is ordered according to the sequence of |  | such that the end result is ordered according to the sequence of |
| forwarding applications. |  | forwarding applications. |
| Comments MAY be used in the Via header field to identify the software |  | Comments MAY be used in the Via header field to identify the software |
| of the recipient proxy or gateway, analogous to the User-Agent and |  | of each recipient, analogous to the User-Agent and Server header |
| Server header fields. However, all comments in the Via field are |  | fields. However, all comments in the Via field are optional and MAY |
| optional and MAY be removed by any recipient prior to forwarding the |  | be removed by any recipient prior to forwarding the message. |
| message. |  |  |
| For example, a request message could be sent from an HTTP/1.0 user |  | For example, a request message could be sent from an HTTP/1.0 user |
| agent to an internal proxy code-named "fred", which uses HTTP/1.1 to |  | agent to an internal proxy code-named "fred", which uses HTTP/1.1 to |
| forward the request to a public proxy at p.example.net, which |  | forward the request to a public proxy at p.example.net, which |
| completes the request by forwarding it to the origin server at |  | completes the request by forwarding it to the origin server at |
| www.example.com. The request received by www.example.com would then |  | www.example.com. The request received by www.example.com would then |
| have the following Via header field: |  | have the following Via header field: |
| Via: 1.0 fred, 1.1 p.example.net (Apache/1.1) |  | Via: 1.0 fred, 1.1 p.example.net (Apache/1.1) |
| Proxies and gateways used as a portal through a network firewall |  | A proxy or gateway used as a portal through a network firewall SHOULD |
| SHOULD NOT, by default, forward the names and ports of hosts within |  | NOT forward the names and ports of hosts within the firewall region |
| the firewall region. This information SHOULD only be propagated if |  | unless it is explicitly enabled to do so. If not enabled, the |
| explicitly enabled. If not enabled, the received-by host of any host |  | received-by host of any host behind the firewall SHOULD be replaced |
| behind the firewall SHOULD be replaced by an appropriate pseudonym |  | by an appropriate pseudonym for that host. |
| for that host. |  |  |
| For organizations that have strong privacy requirements for hiding |  | For organizations that have strong privacy requirements for hiding |
| internal structures, a proxy MAY combine an ordered subsequence of |  | internal structures, a proxy or gateway MAY combine an ordered |
| Via header field entries with identical received-protocol values into |  | subsequence of Via header field entries with identical received- |
| a single such entry. For example, |  | protocol values into a single such entry. For example, |
| Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy |  | Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy |
| could be collapsed to |  | could be collapsed to |
| Via: 1.0 ricky, 1.1 mertz, 1.0 lucy |  | Via: 1.0 ricky, 1.1 mertz, 1.0 lucy |
| Applications SHOULD NOT combine multiple entries unless they are all |  | Senders SHOULD NOT combine multiple entries unless they are all under |
| under the same organizational control and the hosts have already been |  | the same organizational control and the hosts have already been |
| replaced by pseudonyms. Applications MUST NOT combine entries which |  | replaced by pseudonyms. Senders MUST NOT combine entries which have |
| have different received-protocol values. |  | different received-protocol values. |
| 10. IANA Considerations |  | 10. IANA Considerations |
| 10.1. Header Field Registration |  | 10.1. Header Field Registration |
| The Message Header Field Registry located at <http://www.iana.org/ |  | The Message Header Field Registry located at <http://www.iana.org/ |
| assignments/message-headers/message-header-index.html> shall be |  | assignments/message-headers/message-header-index.html> shall be |
| updated with the permanent registrations below (see [RFC3864]): |  | updated with the permanent registrations below (see [RFC3864]): |
| +-------------------+----------+----------+-------------+ |  | +-------------------+----------+----------+-------------+ |
| skipping to change at page 65, line 22 |  | skipping to change at page 68, line 22 |
| cryptography is beyond the scope of the HTTP/1.1 specification. |  | cryptography is beyond the scope of the HTTP/1.1 specification. |
| 11.6. Denial of Service Attacks on Proxies |  | 11.6. Denial of Service Attacks on Proxies |
| They exist. They are hard to defend against. Research continues. |  | They exist. They are hard to defend against. Research continues. |
| Beware. |  | Beware. |
| 12. Acknowledgments |  | 12. Acknowledgments |
| HTTP has evolved considerably over the years. It has benefited from |  | HTTP has evolved considerably over the years. It has benefited from |
| a large and active developer community--the many people who have |  | a large and active developer community -- the many people who have |
| participated on the www-talk mailing list--and it is that community |  | participated on the www-talk mailing list -- and it is that community |
| which has been most responsible for the success of HTTP and of the |  | which has been most responsible for the success of HTTP and of the |
| World-Wide Web in general. Marc Andreessen, Robert Cailliau, Daniel |  | World-Wide Web in general. Marc Andreessen, Robert Cailliau, Daniel |
| W. Connolly, Bob Denny, John Franks, Jean-Francois Groff, Phillip M. |  | W. Connolly, Bob Denny, John Franks, Jean-Francois Groff, Phillip M. |
| Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob McCool, Lou Montulli, |  | Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob McCool, Lou Montulli, |
| Dave Raggett, Tony Sanders, and Marc VanHeyningen deserve special |  | Dave Raggett, Tony Sanders, and Marc VanHeyningen deserve special |
| recognition for their efforts in defining early aspects of the |  | recognition for their efforts in defining early aspects of the |
| protocol. |  | protocol. |
| This document has benefited greatly from the comments of all those |  | This document has benefited greatly from the comments of all those |
| participating in the HTTP-WG. In addition to those already |  | participating in the HTTP-WG. In addition to those already |
| skipping to change at page 66, line 28 |  | skipping to change at page 69, line 28 |
| constructs defined by David H. Crocker for [RFC5234]. Similarly, it |  | constructs defined by David H. Crocker for [RFC5234]. Similarly, it |
| reuses many of the definitions provided by Nathaniel Borenstein and |  | reuses many of the definitions provided by Nathaniel Borenstein and |
| Ned Freed for MIME [RFC2045]. We hope that their inclusion in this |  | Ned Freed for MIME [RFC2045]. We hope that their inclusion in this |
| specification will help reduce past confusion over the relationship |  | specification will help reduce past confusion over the relationship |
| between HTTP and Internet mail message formats. |  | between HTTP and Internet mail message formats. |
| 13. References |  | 13. References |
| 13.1. Normative References |  | 13.1. Normative References |
| [ISO-8859-1] International Organization for Standardization, |  | [ISO-8859-1] International Organization for |
| "Information technology -- 8-bit single-byte coded |  | Standardization, "Information |
| graphic character sets -- Part 1: Latin alphabet No. |  | technology -- 8-bit single-byte coded |
| 1", ISO/IEC 8859-1:1998, 1998. |  | graphic character sets -- Part 1: |
|  |  | Latin alphabet No. 1", ISO/ |
|  |  | IEC 8859-1:1998, 1998. |
| [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part2] Fielding, R., Ed., Gettys, J., Mogul, |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., |  | J., Frystyk, H., Masinter, L., Leach, |
| Ed., and J. Reschke, Ed., "HTTP/1.1, part 2: Message |  | P., Berners-Lee, T., Lafon, Y., Ed., |
| Semantics", draft-ietf-httpbis-p2-semantics-12 (work in |  | and J. Reschke, Ed., "HTTP/1.1, part |
| progress), October 2010. |  | 2: Message Semantics", |
|  |  | draft-ietf-httpbis-p2-semantics-13 |
|  |  | (work in progress), March 2011. |
| [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part3] Fielding, R., Ed., Gettys, J., Mogul, |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., |  | J., Frystyk, H., Masinter, L., Leach, |
| Ed., and J. Reschke, Ed., "HTTP/1.1, part 3: Message |  | P., Berners-Lee, T., Lafon, Y., Ed., |
| Payload and Content Negotiation", |  | and J. Reschke, Ed., "HTTP/1.1, part |
| draft-ietf-httpbis-p3-payload-12 (work in progress), |  | 3: Message Payload and Content |
| October 2010. |  | Negotiation", |
|  |  | draft-ietf-httpbis-p3-payload-13 (work |
|  |  | in progress), March 2011. |
| [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part6] Fielding, R., Ed., Gettys, J., Mogul, |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., |  | J., Frystyk, H., Masinter, L., Leach, |
| Ed., Nottingham, M., Ed., and J. Reschke, Ed., |  | P., Berners-Lee, T., Lafon, Y., Ed., |
| "HTTP/1.1, part 6: Caching", |  | Nottingham, M., Ed., and J. Reschke, |
| draft-ietf-httpbis-p6-cache-12 (work in progress), |  | Ed., "HTTP/1.1, part 6: Caching", |
| October 2010. |  | draft-ietf-httpbis-p6-cache-13 (work |
|  |  | in progress), March 2011. |
| [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data |  | [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB |
| Format Specification version 3.3", RFC 1950, May 1996. |  | Compressed Data Format Specification |
|  |  | version 3.3", RFC 1950, May 1996. |
| RFC 1950 is an Informational RFC, thus it might be less |  | RFC 1950 is an Informational RFC, thus |
| stable than this specification. On the other hand, |  | it might be less stable than this |
| this downward reference was present since the |  | specification. On the other hand, |
| publication of RFC 2068 in 1997 ([RFC2068]), therefore |  | this downward reference was present |
| it is unlikely to cause problems in practice. See also |  | since the publication of RFC 2068 in |
| [BCP97]. |  | 1997 ([RFC2068]), therefore it is |
|  |  | unlikely to cause problems in |
|  |  | practice. See also [BCP97]. |
| [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format |  | [RFC1951] Deutsch, P., "DEFLATE Compressed Data |
| Specification version 1.3", RFC 1951, May 1996. |  | Format Specification version 1.3", |
|  |  | RFC 1951, May 1996. |
| RFC 1951 is an Informational RFC, thus it might be less |  | RFC 1951 is an Informational RFC, thus |
| stable than this specification. On the other hand, |  | it might be less stable than this |
| this downward reference was present since the |  | specification. On the other hand, |
| publication of RFC 2068 in 1997 ([RFC2068]), therefore |  | this downward reference was present |
| it is unlikely to cause problems in practice. See also |  | since the publication of RFC 2068 in |
| [BCP97]. |  | 1997 ([RFC2068]), therefore it is |
|  |  | unlikely to cause problems in |
|  |  | practice. See also [BCP97]. |
| [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and |  | [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., |
| G. Randers-Pehrson, "GZIP file format specification |  | Deutsch, L., and G. Randers-Pehrson, |
| version 4.3", RFC 1952, May 1996. |  | "GZIP file format specification |
|  |  | version 4.3", RFC 1952, May 1996. |
| RFC 1952 is an Informational RFC, thus it might be less |  | RFC 1952 is an Informational RFC, thus |
| stable than this specification. On the other hand, |  | it might be less stable than this |
| this downward reference was present since the |  | specification. On the other hand, |
| publication of RFC 2068 in 1997 ([RFC2068]), therefore |  | this downward reference was present |
| it is unlikely to cause problems in practice. See also |  | since the publication of RFC 2068 in |
| [BCP97]. |  | 1997 ([RFC2068]), therefore it is |
|  |  | unlikely to cause problems in |
|  |  | practice. See also [BCP97]. |
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |  | [RFC2119] Bradner, S., "Key words for use in |
| Requirement Levels", BCP 14, RFC 2119, March 1997. |  | RFCs to Indicate Requirement Levels", |
|  |  | BCP 14, RFC 2119, March 1997. |
| [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, |  | [RFC3986] Berners-Lee, T., Fielding, R., and L. |
| "Uniform Resource Identifier (URI): Generic Syntax", |  | Masinter, "Uniform Resource Identifier |
| STD 66, RFC 3986, January 2005. |  | (URI): Generic Syntax", STD 66, |
|  |  | RFC 3986, January 2005. |
| [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for |  | [RFC5234] Crocker, D., Ed. and P. Overell, |
| Syntax Specifications: ABNF", STD 68, RFC 5234, |  | "Augmented BNF for Syntax |
| January 2008. |  | Specifications: ABNF", STD 68, |
|  |  | RFC 5234, January 2008. |
| [USASCII] American National Standards Institute, "Coded Character |  | [USASCII] American National Standards Institute, |
| Set -- 7-bit American Standard Code for Information |  | "Coded Character Set -- 7-bit American |
| Interchange", ANSI X3.4, 1986. |  | Standard Code for Information |
|  |  | Interchange", ANSI X3.4, 1986. |
| 13.2. Informative References |  | 13.2. Informative References |
| [BCP97] Klensin, J. and S. Hartman, "Handling Normative |  | [BCP97] Klensin, J. and S. Hartman, "Handling |
| References to Standards-Track Documents", BCP 97, |  | Normative References to Standards- |
| RFC 4897, June 2007. |  | Track Documents", BCP 97, RFC 4897, |
|  |  | June 2007. |
| [Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and |  | [Kri2001] Kristol, D., "HTTP Cookies: Standards, |
| Politics", ACM Transactions on Internet Technology Vol. |  | Privacy, and Politics", ACM |
| 1, #2, November 2001, |  | Transactions on Internet |
| <http://arxiv.org/abs/cs.SE/0105018>. |  | Technology Vol. 1, #2, November 2001, |
|  |  | <http://arxiv.org/abs/cs.SE/0105018>. |
| [Nie1997] Frystyk, H., Gettys, J., Prud'hommeaux, E., Lie, H., |  | [Nie1997] Frystyk, H., Gettys, J., |
| and C. Lilley, "Network Performance Effects of |  | Prud'hommeaux, E., Lie, H., and C. |
| HTTP/1.1, CSS1, and PNG", ACM Proceedings of the ACM |  | Lilley, "Network Performance Effects |
| SIGCOMM '97 conference on Applications, technologies, |  | of HTTP/1.1, CSS1, and PNG", |
| architectures, and protocols for computer communication |  | ACM Proceedings of the ACM SIGCOMM '97 |
| SIGCOMM '97, September 1997, |  | conference on Applications, |
| <http://doi.acm.org/10.1145/263105.263157>. |  | technologies, architectures, and |
|  |  | protocols for computer communication |
|  |  | SIGCOMM '97, September 1997, <http:// |
|  |  | doi.acm.org/10.1145/263105.263157>. |
| [Pad1995] Padmanabhan, V. and J. Mogul, "Improving HTTP Latency", |  | [Pad1995] Padmanabhan, V. and J. Mogul, |
| Computer Networks and ISDN Systems v. 28, pp. 25-35, |  | "Improving HTTP Latency", Computer |
| December 1995, |  | Networks and ISDN Systems v. 28, pp. |
| <http://portal.acm.org/citation.cfm?id=219094>. |  | 25-35, December 1995, <http:// |
|  |  | portal.acm.org/ |
|  |  | citation.cfm?id=219094>. |
| [RFC1123] Braden, R., "Requirements for Internet Hosts - |  | [RFC1123] Braden, R., "Requirements for Internet |
| Application and Support", STD 3, RFC 1123, |  | Hosts - Application and Support", |
| October 1989. |  | STD 3, RFC 1123, October 1989. |
| [RFC1900] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", |  | [RFC1900] Carpenter, B. and Y. Rekhter, |
| RFC 1900, February 1996. |  | "Renumbering Needs Work", RFC 1900, |
|  |  | February 1996. |
| [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, |  | [RFC1919] Chatel, M., "Classical versus |
| "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, |  | Transparent IP Proxies", RFC 1919, |
| May 1996. |  | March 1996. |
| [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet |  | [RFC1945] Berners-Lee, T., Fielding, R., and H. |
| Mail Extensions (MIME) Part One: Format of Internet |  | Nielsen, "Hypertext Transfer Protocol |
| Message Bodies", RFC 2045, November 1996. |  | -- HTTP/1.0", RFC 1945, May 1996. |
| [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail |  | [RFC2045] Freed, N. and N. Borenstein, |
| Extensions) Part Three: Message Header Extensions for |  | "Multipurpose Internet Mail Extensions |
| Non-ASCII Text", RFC 2047, November 1996. |  | (MIME) Part One: Format of Internet |
|  |  | Message Bodies", RFC 2045, |
|  |  | November 1996. |
| [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and |  | [RFC2047] Moore, K., "MIME (Multipurpose |
| T. Berners-Lee, "Hypertext Transfer Protocol -- |  | Internet Mail Extensions) Part Three: |
| HTTP/1.1", RFC 2068, January 1997. |  | Message Header Extensions for Non- |
|  |  | ASCII Text", RFC 2047, November 1996. |
| [RFC2109] Kristol, D. and L. Montulli, "HTTP State Management |  | [RFC2068] Fielding, R., Gettys, J., Mogul, J., |
| Mechanism", RFC 2109, February 1997. |  | Nielsen, H., and T. Berners-Lee, |
|  |  | "Hypertext Transfer Protocol -- |
|  |  | HTTP/1.1", RFC 2068, January 1997. |
| [RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, |  | [RFC2145] Mogul, J., Fielding, R., Gettys, J., |
| "Use and Interpretation of HTTP Version Numbers", |  | and H. Nielsen, "Use and |
| RFC 2145, May 1997. |  | Interpretation of HTTP Version |
|  |  | Numbers", RFC 2145, May 1997. |
| [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., |  | [RFC2616] Fielding, R., Gettys, J., Mogul, J., |
| Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext |  | Frystyk, H., Masinter, L., Leach, P., |
| Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. |  | and T. Berners-Lee, "Hypertext |
|  |  | Transfer Protocol -- HTTP/1.1", |
|  |  | RFC 2616, June 1999. |
| [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within |  | [RFC2817] Khare, R. and S. Lawrence, "Upgrading |
| HTTP/1.1", RFC 2817, May 2000. |  | to TLS Within HTTP/1.1", RFC 2817, |
|  |  | May 2000. |
| [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. |  | [RFC2818] Rescorla, E., "HTTP Over TLS", |
|  |  | RFC 2818, May 2000. |
| [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management |  | [RFC2965] Kristol, D. and L. Montulli, "HTTP |
| Mechanism", RFC 2965, October 2000. |  | State Management Mechanism", RFC 2965, |
|  |  | October 2000. |
| [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration |  | [RFC3040] Cooper, I., Melve, I., and G. |
| Procedures for Message Header Fields", BCP 90, |  | Tomlinson, "Internet Web Replication |
| RFC 3864, September 2004. |  | and Caching Taxonomy", RFC 3040, |
|  |  | January 2001. |
| [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications |  | [RFC3864] Klyne, G., Nottingham, M., and J. |
| and Registration Procedures", BCP 13, RFC 4288, |  | Mogul, "Registration Procedures for |
| December 2005. |  | Message Header Fields", BCP 90, |
|  |  | RFC 3864, September 2004. |
| [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines |  | [RFC4288] Freed, N. and J. Klensin, "Media Type |
| and Registration Procedures for New URI Schemes", |  | Specifications and Registration |
| BCP 115, RFC 4395, February 2006. |  | Procedures", BCP 13, RFC 4288, |
|  |  | December 2005. |
| [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing |  | [RFC4395] Hansen, T., Hardie, T., and L. |
| an IANA Considerations Section in RFCs", BCP 26, |  | Masinter, "Guidelines and Registration |
| RFC 5226, May 2008. |  | Procedures for New URI Schemes", |
|  |  | BCP 115, RFC 4395, February 2006. |
| [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, |  | [RFC5226] Narten, T. and H. Alvestrand, |
| October 2008. |  | "Guidelines for Writing an IANA |
|  |  | Considerations Section in RFCs", |
|  |  | BCP 26, RFC 5226, May 2008. |
| [Spe] Spero, S., "Analysis of HTTP Performance Problems", |  | [RFC5322] Resnick, P., "Internet Message |
| <http://sunsite.unc.edu/mdma-release/http-prob.html>. |  | Format", RFC 5322, October 2008. |
| [Tou1998] Touch, J., Heidemann, J., and K. Obraczka, "Analysis of |  | [Spe] Spero, S., "Analysis of HTTP |
| HTTP Performance", ISI Research Report ISI/RR-98-463, |  | Performance Problems", <http:// |
| Aug 1998, <http://www.isi.edu/touch/pubs/http-perf96/>. |  | sunsite.unc.edu/mdma-release/ |
|  |  | http-prob.html>. |
| (original report dated Aug. 1996) |  | [Tou1998] Touch, J., Heidemann, J., and K. |
|  |  | Obraczka, "Analysis of HTTP |
|  |  | Performance", ISI Research Report ISI/ |
|  |  | RR-98-463, Aug 1998, <http:// |
|  |  | www.isi.edu/touch/pubs/http-perf96/>. |
|  |  | (original report dated Aug. 1996) |
|  |  | [draft-ietf-httpstate-cookie] Barth, A., "HTTP State Management |
|  |  | Mechanism", |
|  |  | draft-ietf-httpstate-cookie-23 (work |
|  |  | in progress), March 2011. |
| Appendix A. Tolerant Applications |  | Appendix A. Tolerant Applications |
| Although this document specifies the requirements for the generation |  | Although this document specifies the requirements for the generation |
| of HTTP/1.1 messages, not all applications will be correct in their |  | of HTTP/1.1 messages, not all applications will be correct in their |
| implementation. We therefore recommend that operational applications |  | implementation. We therefore recommend that operational applications |
| be tolerant of deviations whenever those deviations can be |  | be tolerant of deviations whenever those deviations can be |
| interpreted unambiguously. |  | interpreted unambiguously. |
| Clients SHOULD be tolerant in parsing the Status-Line and servers |  |  |
| SHOULD be tolerant when parsing the Request-Line. In particular, |  |  |
| they SHOULD accept any amount of WSP characters between fields, even |  |  |
| though only a single SP is required. |  |  |
| The line terminator for header fields is the sequence CRLF. However, |  | The line terminator for header fields is the sequence CRLF. However, |
| we recommend that applications, when parsing such headers fields, |  | we recommend that applications, when parsing such headers fields, |
| recognize a single LF as a line terminator and ignore the leading CR. |  | recognize a single LF as a line terminator and ignore the leading CR. |
| The character set of a representation SHOULD be labeled as the lowest |  | The character encoding of a representation SHOULD be labeled as the |
| common denominator of the character codes used within that |  | lowest common denominator of the character codes used within that |
| representation, with the exception that not labeling the |  | representation, with the exception that not labeling the |
| representation is preferred over labeling the representation with the |  | representation is preferred over labeling the representation with the |
| labels US-ASCII or ISO-8859-1. See [Part3]. |  | labels US-ASCII or ISO-8859-1. See [Part3]. |
| Additional rules for requirements on parsing and encoding of dates |  | Additional rules for requirements on parsing and encoding of dates |
| and other potential problems with date encodings include: |  | and other potential problems with date encodings include: |
| o HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date |  | o HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date |
| which appears to be more than 50 years in the future is in fact in |  | which appears to be more than 50 years in the future is in fact in |
| the past (this helps solve the "year 2000" problem). |  | the past (this helps solve the "year 2000" problem). |
| skipping to change at page 71, line 5 |  | skipping to change at page 75, line 5 |
| proper value. |  | proper value. |
| o All expiration-related calculations MUST be done in GMT. The |  | o All expiration-related calculations MUST be done in GMT. The |
| local time zone MUST NOT influence the calculation or comparison |  | local time zone MUST NOT influence the calculation or comparison |
| of an age or expiration time. |  | of an age or expiration time. |
| o If an HTTP header field incorrectly carries a date value with a |  | o If an HTTP header field incorrectly carries a date value with a |
| time zone other than GMT, it MUST be converted into GMT using the |  | time zone other than GMT, it MUST be converted into GMT using the |
| most conservative possible conversion. |  | most conservative possible conversion. |
| Appendix B. Compatibility with Previous Versions |  | Appendix B. HTTP Version History |
| HTTP has been in use by the World-Wide Web global information |  | HTTP has been in use by the World-Wide Web global information |
| initiative since 1990. The first version of HTTP, later referred to |  | initiative since 1990. The first version of HTTP, later referred to |
| as HTTP/0.9, was a simple protocol for hypertext data transfer across |  | as HTTP/0.9, was a simple protocol for hypertext data transfer across |
| the Internet with only a single method and no metadata. HTTP/1.0, as |  | the Internet with only a single request method (GET) and no metadata. |
| defined by [RFC1945], added a range of request methods and MIME-like |  | HTTP/1.0, as defined by [RFC1945], added a range of request methods |
| messaging that could include metadata about the data transferred and |  | and MIME-like messaging that could include metadata about the data |
| modifiers on the request/response semantics. However, HTTP/1.0 did |  | transferred and modifiers on the request/response semantics. |
| not sufficiently take into consideration the effects of hierarchical |  | However, HTTP/1.0 did not sufficiently take into consideration the |
| proxies, caching, the need for persistent connections, or name-based |  | effects of hierarchical proxies, caching, the need for persistent |
| virtual hosts. The proliferation of incompletely-implemented |  | connections, or name-based virtual hosts. The proliferation of |
| applications calling themselves "HTTP/1.0" further necessitated a |  | incompletely-implemented applications calling themselves "HTTP/1.0" |
| protocol version change in order for two communicating applications |  | further necessitated a protocol version change in order for two |
| to determine each other's true capabilities. |  | communicating applications to determine each other's true |
|  |  | 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. |  | compliance 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 |  | compliance with previous versions. HTTP/1.1 was deliberately |
| designed, however, to make supporting previous versions easy. It is |  | designed, however, to make supporting previous versions easy. We |
| worth noting that, at the time of composing this specification, we |  | would expect a general-purpose HTTP/1.1 server to understand any |
| would expect general-purpose HTTP/1.1 servers to: |  | valid request in the format of HTTP/1.0 and respond appropriately |
|  |  | with an HTTP/1.1 message that only uses features understood (or |
| o understand any valid request in the format of HTTP/1.0 and 1.1; |  | safely ignored) by HTTP/1.0 clients. Likewise, would expect an |
|  |  | HTTP/1.1 client to understand any valid HTTP/1.0 response. |
| o respond appropriately with a message in the same major version |  |  |
| used by the client. |  |  |
| And we would expect HTTP/1.1 clients to: |  |  |
| o understand any valid response in the format of HTTP/1.0 or 1.1. |  |  |
| For most implementations of HTTP/1.0, each connection is established |  | Since HTTP/0.9 did not support header fields in a request, there is |
| by the client prior to the request and closed by the server after |  | no mechanism for it to support name-based virtual hosts (selection of |
| sending the response. Some implementations implement the Keep-Alive |  | resource by inspection of the Host header field). Any server that |
| version of persistent connections described in Section 19.7.1 of |  | implements name-based virtual hosts ought to disable support for |
| [RFC2068]. |  | 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 |
|  |  | properly encode linear whitespace found in a URI reference and placed |
|  |  | in the request-target. |
| B.1. Changes from HTTP/1.0 |  | B.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. |
| B.1.1. Changes to Simplify Multi-homed Web Servers and Conserve IP |  | B.1.1. Multi-homed Web Servers |
| Addresses |  |  |
| The requirements that clients and servers support the Host request- |  | The requirements that clients and servers support the Host header |
| header field (Section 9.4), report an error if it is missing from an |  | field (Section 9.4), report an error if it is missing from an |
| HTTP/1.1 request, and accept absolute URIs (Section 4.1.2) are among |  | HTTP/1.1 request, and accept absolute URIs (Section 4.1.2) are among |
| the most important changes defined by this specification. |  | 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 changes outlined above will |  | to which that request was directed. The Host header field was |
| allow the Internet, once older HTTP clients are no longer common, to |  | introduced during the development of HTTP/1.1 and, though it was |
| support multiple Web sites from a single IP address, greatly |  | quickly implemented by most HTTP/1.0 browsers, additional |
| simplifying large operational Web servers, where allocation of many |  | requirements were placed on all HTTP/1.1 requests in order to ensure |
| IP addresses to a single host has created serious problems. The |  | complete adoption. At the time of this writing, most HTTP-based |
| Internet will also be able to recover the IP addresses that have been |  | services are dependent upon the Host header field for targeting |
| allocated for the sole purpose of allowing special-purpose domain |  | requests. |
| names to be used in root-level HTTP URLs. Given the rate of growth |  |  |
| of the Web, and the number of servers already deployed, it is |  |  |
| extremely important that all implementations of HTTP (including |  |  |
| updates to existing HTTP/1.0 applications) correctly implement these |  |  |
| requirements: |  |  |
| o Both clients and servers MUST support the Host request-header |  |  |
| field. |  |  |
| o A client that sends an HTTP/1.1 request MUST send a Host header |  |  |
| field. |  |  |
| o Servers MUST report a 400 (Bad Request) error if an HTTP/1.1 |  |  |
| request does not include a Host request-header field. |  |  |
| o Servers MUST accept absolute URIs. |  | B.1.2. Keep-Alive Connections |
| B.2. Compatibility with HTTP/1.0 Persistent Connections |  | For most implementations of HTTP/1.0, each connection is established |
|  |  | by the client prior to the request and closed by the server after |
|  |  | sending the response. However, some implementations implement the |
|  |  | Keep-Alive version of persistent connections described in Section |
|  |  | 19.7.1 of [RFC2068]. |
| Some clients and servers might wish to be compatible with some |  | Some clients and servers might wish to be compatible with some |
| previous implementations of persistent connections in HTTP/1.0 |  | previous implementations of persistent connections in HTTP/1.0 |
| clients and servers. Persistent connections in HTTP/1.0 are |  | clients and servers. Persistent connections in HTTP/1.0 are |
| explicitly negotiated as they are not the default behavior. HTTP/1.0 |  | explicitly negotiated as they are not the default behavior. HTTP/1.0 |
| experimental implementations of persistent connections are faulty, |  | experimental implementations of persistent connections are faulty, |
| and the new facilities in HTTP/1.1 are designed to rectify these |  | and the new facilities in HTTP/1.1 are designed to rectify these |
| problems. The problem was that some existing HTTP/1.0 clients might |  | problems. The problem was that some existing HTTP/1.0 clients might |
| send Keep-Alive to a proxy server that doesn't understand Connection, |  | send Keep-Alive to a proxy server that doesn't understand Connection, |
| which would then erroneously forward it to the next inbound server, |  | which would then erroneously forward it to the next inbound server, |
| skipping to change at page 73, line 15 |  | skipping to change at page 77, line 5 |
| talking to proxies. |  | talking to proxies. |
| However, talking to proxies is the most important use of persistent |  | However, talking to proxies is the most important use of persistent |
| connections, so that prohibition is clearly unacceptable. Therefore, |  | connections, so that prohibition is clearly unacceptable. Therefore, |
| we need some other mechanism for indicating a persistent connection |  | we need some other mechanism for indicating a persistent connection |
| is desired, which is safe to use even when talking to an old proxy |  | is desired, which is safe to use even when talking to an old proxy |
| that ignores Connection. Persistent connections are the default for |  | that ignores Connection. Persistent connections are the default for |
| HTTP/1.1 messages; we introduce a new keyword (Connection: close) for |  | HTTP/1.1 messages; we introduce a new keyword (Connection: close) for |
| declaring non-persistence. See Section 9.1. |  | declaring non-persistence. See Section 9.1. |
| The original HTTP/1.0 form of persistent connections (the Connection: |  | B.2. Changes from RFC 2616 |
| Keep-Alive and Keep-Alive header field) is documented in Section |  |  |
| 19.7.1 of [RFC2068]. |  |  |
| B.3. Changes from RFC 2616 |  |  |
| Empty list elements in list productions have been deprecated. |  | Empty list elements in list productions have been deprecated. |
| (Section 1.2.1) |  | (Section 1.2.1) |
| Rules about implicit linear whitespace between certain grammar |  | Rules about implicit linear whitespace between certain grammar |
| productions have been removed; now it's only allowed when |  | productions have been removed; now it's only allowed when |
| specifically pointed out in the ABNF. The NUL character is no longer |  | specifically pointed out in the ABNF. The NUL octet is no longer |
| allowed in comment and quoted-string text. The quoted-pair rule no |  | allowed in comment and quoted-string text. The quoted-pair rule no |
| longer allows escaping control characters other than HTAB. Non-ASCII |  | longer allows escaping control characters other than HTAB. Non-ASCII |
| content in header fields and reason phrase has been obsoleted and |  | content in header fields and reason phrase has been obsoleted and |
| made opaque (the TEXT rule was removed) (Section 1.2.2) |  | made opaque (the TEXT rule was removed) (Section 1.2.2) |
| Clarify that HTTP-Version is case sensitive. (Section 2.5) |  | Clarify that HTTP-Version is case sensitive. (Section 2.5) |
| Require that invalid whitespace around field-names be rejected. |  | Require that invalid whitespace around field-names be rejected. |
| (Section 3.2) |  | (Section 3.2) |
| 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 6.2) |  | tokens. (Sections 3.3 and 6.2) |
| Update use of abs_path production from RFC 1808 to the path-absolute |  | Update use of abs_path production from RFC 1808 to the path-absolute |
| + query components of RFC 3986. (Section 4.1.2) |  | + query components of RFC 3986. State that the asterisk form is |
|  |  | allowed for the OPTIONS request method only. (Section 4.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 6.2.1) |  | folding in chunk extensions. (Section 6.2.1) |
| Remove hard limit of two connections per server. (Section 7.1.4) |  | Remove hard limit of two connections per server. (Section 7.1.4) |
| Clarify exactly when close connection options must be sent. |  | Clarify exactly when close connection options must be sent. |
| (Section 9.1) |  | (Section 9.1) |
|  |  | Define the semantics of the "Upgrade" header field in responses other |
|  |  | than 101 (this was incorporated from [RFC2817]). (Section 9.8) |
| Appendix C. Collected ABNF |  | Appendix C. Collected ABNF |
| BWS = OWS |  | BWS = OWS |
| Cache-Control = <Cache-Control, defined in [Part6], Section 3.4> |  |  |
| Chunked-Body = *chunk last-chunk trailer-part CRLF |  | Chunked-Body = *chunk last-chunk trailer-part CRLF |
| Connection = "Connection:" OWS Connection-v |  | Connection = "Connection:" OWS Connection-v |
| Connection-v = *( "," OWS ) connection-token *( OWS "," [ OWS |  | Connection-v = *( "," OWS ) connection-token *( OWS "," [ OWS |
| connection-token ] ) |  | connection-token ] ) |
| Content-Length = "Content-Length:" OWS 1*Content-Length-v |  | Content-Length = "Content-Length:" OWS 1*Content-Length-v |
| Content-Length-v = 1*DIGIT |  | Content-Length-v = 1*DIGIT |
| Date = "Date:" OWS Date-v |  | Date = "Date:" OWS Date-v |
| Date-v = HTTP-date |  | Date-v = HTTP-date |
| GMT = %x47.4D.54 ; GMT |  | GMT = %x47.4D.54 ; GMT |
| HTTP-Prot-Name = %x48.54.54.50 ; HTTP |  | HTTP-Prot-Name = %x48.54.54.50 ; HTTP |
| HTTP-Version = HTTP-Prot-Name "/" 1*DIGIT "." 1*DIGIT |  | HTTP-Version = HTTP-Prot-Name "/" 1*DIGIT "." 1*DIGIT |
| skipping to change at page 74, line 32 |  | skipping to change at page 78, line 21 |
| GMT = %x47.4D.54 ; GMT |  | GMT = %x47.4D.54 ; GMT |
| HTTP-Prot-Name = %x48.54.54.50 ; HTTP |  | HTTP-Prot-Name = %x48.54.54.50 ; HTTP |
| HTTP-Version = HTTP-Prot-Name "/" 1*DIGIT "." 1*DIGIT |  | HTTP-Version = HTTP-Prot-Name "/" 1*DIGIT "." 1*DIGIT |
| HTTP-date = rfc1123-date / obs-date |  | HTTP-date = rfc1123-date / obs-date |
| HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body |  | HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body |
| ] |  | ] |
| Host = "Host:" OWS Host-v |  | Host = "Host:" OWS Host-v |
| Host-v = uri-host [ ":" port ] |  | Host-v = uri-host [ ":" port ] |
| MIME-Version = <MIME-Version, defined in [Part3], Appendix A.1> |  |  |
| Method = token |  | Method = token |
| OWS = *( [ obs-fold ] WSP ) |  | OWS = *( [ obs-fold ] WSP ) |
| Pragma = <Pragma, defined in [Part6], Section 3.4> |  |  |
| RWS = 1*( [ obs-fold ] WSP ) |  | RWS = 1*( [ obs-fold ] WSP ) |
| Reason-Phrase = *( WSP / VCHAR / obs-text ) |  | Reason-Phrase = *( WSP / VCHAR / obs-text ) |
| Request = Request-Line *( header-field CRLF ) CRLF [ message-body ] |  | Request = Request-Line *( header-field CRLF ) CRLF [ message-body ] |
| Request-Line = Method SP request-target SP HTTP-Version CRLF |  | Request-Line = Method SP request-target SP HTTP-Version CRLF |
| Response = Status-Line *( header-field CRLF ) CRLF [ message-body ] |  | Response = Status-Line *( header-field CRLF ) CRLF [ message-body ] |
| Status-Code = 3DIGIT |  | Status-Code = 3DIGIT |
| Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF |  | Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF |
| TE = "TE:" OWS TE-v |  | TE = "TE:" OWS TE-v |
| skipping to change at page 75, line 17 |  | skipping to change at page 78, line 51 |
| URI-reference = <URI-reference, defined in [RFC3986], Section 4.1> |  | URI-reference = <URI-reference, defined in [RFC3986], Section 4.1> |
| Upgrade = "Upgrade:" OWS Upgrade-v |  | Upgrade = "Upgrade:" OWS Upgrade-v |
| Upgrade-v = *( "," OWS ) product *( OWS "," [ OWS product ] ) |  | Upgrade-v = *( "," OWS ) product *( OWS "," [ OWS product ] ) |
| Via = "Via:" OWS Via-v |  | Via = "Via:" OWS Via-v |
| Via-v = *( "," OWS ) received-protocol RWS received-by [ RWS comment |  | Via-v = *( "," 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 ] |
| ] ) |  | ] ) |
| Warning = <Warning, defined in [Part6], Section 3.6> |  |  |
| absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3> |  | absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3> |
| asctime-date = day-name SP date3 SP time-of-day SP year |  | asctime-date = day-name SP date3 SP time-of-day SP year |
| attribute = token |  | attribute = token |
| authority = <authority, defined in [RFC3986], Section 3.2> |  | authority = <authority, defined in [RFC3986], Section 3.2> |
| chunk = chunk-size *WSP [ chunk-ext ] CRLF chunk-data CRLF |  | chunk = chunk-size *WSP [ chunk-ext ] CRLF chunk-data CRLF |
| chunk-data = 1*OCTET |  | chunk-data = 1*OCTET |
| chunk-ext = *( ";" *WSP chunk-ext-name [ "=" chunk-ext-val ] *WSP ) |  | chunk-ext = *( ";" *WSP chunk-ext-name [ "=" chunk-ext-val ] *WSP ) |
| chunk-ext-name = token |  | chunk-ext-name = token |
| chunk-ext-val = token / quoted-str-nf |  | chunk-ext-val = token / quoted-str-nf |
| skipping to change at page 76, line 17 |  | skipping to change at page 79, line 43 |
| / %x57.65.64.6E.65.73.64.61.79 ; Wednesday |  | / %x57.65.64.6E.65.73.64.61.79 ; Wednesday |
| / %x54.68.75.72.73.64.61.79 ; Thursday |  | / %x54.68.75.72.73.64.61.79 ; Thursday |
| / %x46.72.69.64.61.79 ; Friday |  | / %x46.72.69.64.61.79 ; Friday |
| / %x53.61.74.75.72.64.61.79 ; Saturday |  | / %x53.61.74.75.72.64.61.79 ; Saturday |
| / %x53.75.6E.64.61.79 ; Sunday |  | / %x53.75.6E.64.61.79 ; Sunday |
| field-content = *( WSP / VCHAR / obs-text ) |  | field-content = *( WSP / VCHAR / obs-text ) |
| field-name = token |  | field-name = token |
| field-value = *( field-content / OWS ) |  | field-value = *( field-content / OWS ) |
| general-header = Cache-Control / Connection / Date / Pragma / Trailer |  |  |
| / Transfer-Encoding / Upgrade / Via / Warning / MIME-Version |  |  |
| header-field = field-name ":" OWS [ field-value ] OWS |  | header-field = field-name ":" OWS [ field-value ] OWS |
| hour = 2DIGIT |  | hour = 2DIGIT |
| 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" *WSP [ chunk-ext ] CRLF |  | last-chunk = 1*"0" *WSP [ chunk-ext ] CRLF |
| message-body = *OCTET |  | message-body = *OCTET |
| minute = 2DIGIT |  | minute = 2DIGIT |
| month = %x4A.61.6E ; Jan |  | month = %x4A.61.6E ; Jan |
| skipping to change at page 77, line 23 |  | skipping to change at page 80, line 47 |
| query = <query, defined in [RFC3986], Section 3.4> |  | query = <query, defined in [RFC3986], Section 3.4> |
| quoted-cpair = "\" ( WSP / VCHAR / obs-text ) |  | quoted-cpair = "\" ( WSP / VCHAR / obs-text ) |
| quoted-pair = "\" ( WSP / VCHAR / obs-text ) |  | quoted-pair = "\" ( WSP / 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" ] ) |
| 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-header = <request-header, defined in [Part2], Section 3> |  |  |
| request-target = "*" / absolute-URI / ( path-absolute [ "?" query ] ) |  | request-target = "*" / absolute-URI / ( path-absolute [ "?" query ] ) |
| / authority |  | / authority |
| response-header = <response-header, defined in [Part2], Section 5> |  |  |
| rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT |  | rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT |
| rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT |  | rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT |
| second = 2DIGIT |  | second = 2DIGIT |
| special = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" / |  | special = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" / |
| DQUOTE / "/" / "[" / "]" / "?" / "=" / "{" / "}" |  | DQUOTE / "/" / "[" / "]" / "?" / "=" / "{" / "}" |
| start-line = Request-Line / Status-Line |  | start-line = Request-Line / Status-Line |
| 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 |
| skipping to change at page 78, line 4 |  | skipping to change at page 81, line 25 |
| token = 1*tchar |  | token = 1*tchar |
| trailer-part = *( header-field CRLF ) |  | trailer-part = *( header-field CRLF ) |
| transfer-coding = "chunked" / "compress" / "deflate" / "gzip" / |  | transfer-coding = "chunked" / "compress" / "deflate" / "gzip" / |
| transfer-extension |  | transfer-extension |
| transfer-extension = token *( OWS ";" OWS transfer-parameter ) |  | transfer-extension = token *( OWS ";" OWS transfer-parameter ) |
| transfer-parameter = attribute BWS "=" BWS value |  | transfer-parameter = attribute BWS "=" BWS value |
| uri-host = <host, defined in [RFC3986], Section 3.2.2> |  | uri-host = <host, defined in [RFC3986], Section 3.2.2> |
| value = word |  | value = word |
| word = token / quoted-string |  | word = token / quoted-string |
| year = 4DIGIT |  | year = 4DIGIT |
| ABNF diagnostics: |  | ABNF diagnostics: |
| ; Chunked-Body defined but not used |  | ; Chunked-Body defined but not used |
|  |  | ; Connection defined but not used |
| ; Content-Length defined but not used |  | ; Content-Length defined but not used |
|  |  | ; Date 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 |
| ; Request defined but not used |  | ; Request defined but not used |
| ; Response defined but not used |  | ; Response defined but not used |
| ; TE defined but not used |  | ; TE defined but not used |
|  |  | ; Trailer defined but not used |
|  |  | ; Transfer-Encoding defined but not used |
| ; URI-reference defined but not used |  | ; URI-reference defined but not used |
| ; general-header defined but not used |  | ; Upgrade defined but not used |
|  |  | ; Via 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 |
| ; request-header defined but not used |  |  |
| ; response-header defined but not used |  |  |
| ; special defined but not used |  | ; special defined but not used |
| Appendix D. Change Log (to be removed by RFC Editor before publication) |  | Appendix D. Change Log (to be removed by RFC Editor before publication) |
| D.1. Since RFC 2616 |  | D.1. Since RFC 2616 |
| Extracted relevant partitions from [RFC2616]. |  | Extracted relevant partitions from [RFC2616]. |
| D.2. Since draft-ietf-httpbis-p1-messaging-00 |  | D.2. Since draft-ietf-httpbis-p1-messaging-00 |
| skipping to change at page 86, line 31 |  | skipping to change at page 90, line 8 |
| request URI: handling of missing host in HTTP/1.0" |  | request URI: handling of missing host in HTTP/1.0" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/248>: "confusing |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/248>: "confusing |
| Date requirements for clients" |  | Date requirements for clients" |
| Partly resolved issues: |  | Partly resolved issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/95>: "Handling |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/95>: "Handling |
| multiple Content-Length headers" |  | multiple Content-Length headers" |
|  |  | D.14. Since draft-ietf-httpbis-p1-messaging-12 |
|  |  | Closed issues: |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/75>: "RFC2145 |
|  |  | Normative" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/159>: "HTTP(s) URI |
|  |  | scheme definitions" (tune the requirements on userinfo) |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/210>: "define |
|  |  | 'transparent' proxy" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/224>: "Header |
|  |  | Classification" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/233>: "Is * usable |
|  |  | as a request-uri for new methods?" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/240>: "Migrate |
|  |  | Upgrade details from RFC2817" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle |
|  |  | ABNFs for header fields" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/279>: "update RFC |
|  |  | 2109 reference" |
| Index |  | Index |
| A |  | A |
| absolute-URI form (of request-target) 27 |  | absolute-URI form (of request-target) 29 |
| application/http Media Type 61 |  | accelerator 13 |
| asterisk form (of request-target) 27 |  | application/http Media Type 64 |
| authority form (of request-target) 27 |  | asterisk form (of request-target) 28 |
|  |  | authority form (of request-target) 29 |
| B |  | B |
| browser 10 |  | browser 10 |
| C |  | C |
| cache 13 |  | cache 14 |
| cacheable 14 |  | cacheable 14 |
| chunked (Coding Format) 35 |  | captive portal 14 |
|  |  | chunked (Coding Format) 37 |
| client 10 |  | client 10 |
| Coding Format |  | Coding Format |
| chunked 35 |  | chunked 37 |
| compress 38 |  | compress 40 |
| deflate 38 |  | deflate 40 |
| gzip 38 |  | gzip 40 |
| compress (Coding Format) 38 |  | compress (Coding Format) 40 |
| connection 10 |  | connection 10 |
| Connection header 49 |  | Connection header field 51 |
| Content-Length header 50 |  | Content-Length header field 53 |
| D |  | D |
| Date header 51 |  | Date header field 53 |
| deflate (Coding Format) 38 |  | deflate (Coding Format) 40 |
| downstream 12 |  | downstream 12 |
| E |  | E |
| effective request URI 29 |  | effective request URI 31 |
| G |  | G |
| gateway 13 |  | gateway 13 |
| Grammar |  | Grammar |
| absolute-URI 16 |  | absolute-URI 17 |
| ALPHA 7 |  | ALPHA 7 |
| asctime-date 34 |  | asctime-date 36 |
| attribute 34 |  | attribute 36 |
| authority 16 |  | authority 17 |
| BWS 9 |  | BWS 9 |
| chunk 35 |  | chunk 37 |
| chunk-data 35 |  | chunk-data 37 |
| chunk-ext 35 |  | chunk-ext 37 |
| chunk-ext-name 35 |  | chunk-ext-name 37 |
| chunk-ext-val 35 |  | chunk-ext-val 37 |
| chunk-size 35 |  | chunk-size 37 |
| Chunked-Body 35 |  | Chunked-Body 37 |
| comment 22 |  | comment 23 |
| Connection 49 |  | Connection 52 |
| connection-token 49 |  | connection-token 52 |
| Connection-v 49 |  | Connection-v 52 |
| Content-Length 50 |  | Content-Length 53 |
| Content-Length-v 50 |  | Content-Length-v 53 |
| CR 7 |  | CR 7 |
| CRLF 7 |  | CRLF 7 |
| ctext 22 |  | ctext 23 |
| CTL 7 |  | CTL 7 |
| Date 51 |  | Date 53 |
| Date-v 51 |  | Date-v 53 |
| date1 33 |  | date1 35 |
| date2 34 |  | date2 36 |
| date3 34 |  | date3 36 |
| day 33 |  | day 35 |
| day-name 33 |  | day-name 35 |
| day-name-l 33 |  | day-name-l 35 |
| DIGIT 7 |  | DIGIT 7 |
| DQUOTE 7 |  | DQUOTE 7 |
| extension-code 32 |  | field-content 22 |
| extension-method 26 |  | field-name 22 |
| field-content 20 |  | field-value 22 |
| field-name 20 |  | GMT 35 |
| field-value 20 |  | header-field 22 |
| general-header 26 |  |  |
| GMT 33 |  |  |
| header-field 20 |  |  |
| HEXDIG 7 |  | HEXDIG 7 |
| Host 52 |  | Host 55 |
| Host-v 52 |  | Host-v 55 |
| hour 33 |  | hour 35 |
| HTTP-date 32 |  | HTTP-date 34 |
| HTTP-message 19 |  | HTTP-message 21 |
| HTTP-Prot-Name 15 |  | HTTP-Prot-Name 15 |
| http-URI 16 |  | http-URI 18 |
| HTTP-Version 15 |  | HTTP-Version 15 |
| https-URI 18 |  | https-URI 19 |
| last-chunk 35 |  | last-chunk 37 |
| LF 7 |  | LF 7 |
| message-body 22 |  | message-body 24 |
| Method 26 |  | Method 28 |
| minute 33 |  | minute 35 |
| month 33 |  | month 35 |
| obs-date 33 |  | obs-date 35 |
| obs-text 10 |  | obs-text 10 |
| OCTET 7 |  | OCTET 7 |
| OWS 9 |  | OWS 9 |
| path-absolute 16 |  | path-absolute 17 |
| port 16 |  | port 17 |
| product 39 |  | product 41 |
| product-version 39 |  | product-version 41 |
| protocol-name 57 |  | protocol-name 60 |
| protocol-version 57 |  | protocol-version 60 |
| pseudonym 57 |  | pseudonym 60 |
| qdtext 10 |  | qdtext 10 |
| qdtext-nf 35 |  | qdtext-nf 37 |
| query 16 |  | query 17 |
| quoted-cpair 22 |  | quoted-cpair 24 |
| quoted-pair 10 |  | quoted-pair 10 |
| quoted-str-nf 35 |  | quoted-str-nf 37 |
| quoted-string 10 |  | quoted-string 10 |
| qvalue 39 |  | qvalue 41 |
| Reason-Phrase 32 |  | Reason-Phrase 33 |
| received-by 57 |  | received-by 60 |
| received-protocol 57 |  | received-protocol 60 |
| Request 26 |  | Request 28 |
| Request-Line 26 |  | Request-Line 28 |
| request-target 27 |  | request-target 28 |
| Response 31 |  | Response 32 |
| rfc850-date 34 |  | rfc850-date 36 |
| rfc1123-date 33 |  | rfc1123-date 35 |
| RWS 9 |  | RWS 9 |
| second 33 |  | second 35 |
| SP 7 |  | SP 7 |
| special 9 |  | special 9 |
| Status-Code 32 |  | Status-Code 33 |
| Status-Line 31 |  | Status-Line 33 |
| t-codings 53 |  | t-codings 56 |
| tchar 9 |  | tchar 9 |
| TE 53 |  | TE 56 |
| te-ext 53 |  | te-ext 56 |
| te-params 53 |  | te-params 56 |
| TE-v 53 |  | TE-v 56 |
| time-of-day 33 |  | time-of-day 35 |
| token 9 |  | token 9 |
| Trailer 54 |  | Trailer 57 |
| trailer-part 35 |  | trailer-part 37 |
| Trailer-v 54 |  | Trailer-v 57 |
| transfer-coding 34 |  | transfer-coding 36 |
| Transfer-Encoding 55 |  | Transfer-Encoding 58 |
| Transfer-Encoding-v 55 |  | Transfer-Encoding-v 58 |
| transfer-extension 34 |  | transfer-extension 36 |
| transfer-parameter 34 |  | transfer-parameter 36 |
| Upgrade 55 |  | Upgrade 58 |
| Upgrade-v 55 |  | Upgrade-v 58 |
| uri-host 16 |  | uri-host 17 |
| URI-reference 16 |  | URI-reference 17 |
| value 34 |  | value 36 |
| VCHAR 7 |  | VCHAR 7 |
| Via 57 |  | Via 60 |
| Via-v 57 |  | Via-v 60 |
| word 9 |  | word 9 |
| WSP 7 |  | WSP 7 |
| year 33 |  | year 35 |
| gzip (Coding Format) 38 |  | gzip (Coding Format) 40 |
| H |  | H |
| header field 19 |  | header field 20 |
| header section 19 |  | Header Fields |
| Headers |  | Connection 51 |
| Connection 49 |  | Content-Length 53 |
| Content-Length 50 |  | Date 53 |
| Date 51 |  | Host 55 |
| Host 52 |  | TE 56 |
| TE 53 |  | Trailer 57 |
| Trailer 54 |  | Transfer-Encoding 58 |
| Transfer-Encoding 55 |  | Upgrade 58 |
| Upgrade 55 |  | Via 60 |
| Via 57 |  | header section 20 |
| headers 19 |  | headers 20 |
| Host header 52 |  | Host header field 55 |
| http URI scheme 16 |  | http URI scheme 18 |
| https URI scheme 18 |  | https URI scheme 19 |
| I |  | I |
| inbound 12 |  | inbound 12 |
|  |  | interception proxy 14 |
| intermediary 12 |  | intermediary 12 |
| M |  | M |
| Media Type |  | Media Type |
| application/http 61 |  | application/http 64 |
| message/http 59 |  | message/http 62 |
| message 11 |  | message 11 |
| message/http Media Type 59 |  | message/http Media Type 62 |
|  |  | N |
|  |  | non-transforming proxy 13 |
| O |  | O |
|  |  | origin form (of request-target) 29 |
| origin server 10 |  | origin server 10 |
| outbound 12 |  | outbound 12 |
| P |  | P |
| path-absolute form (of request-target) 27 |  | proxy 13 |
| proxy 12 |  |  |
| R |  | R |
| request 11 |  | request 11 |
| resource 16 |  | resource 17 |
| response 11 |  | response 11 |
| reverse proxy 13 |  | reverse proxy 13 |
| S |  | S |
| server 10 |  | server 10 |
| spider 10 |  | spider 10 |
| T |  | T |
| target resource 29 |  | target resource 31 |
| TE header 53 |  | TE header field 56 |
| Trailer header 54 |  | Trailer header field 57 |
| Transfer-Encoding header 55 |  | Transfer-Encoding header field 58 |
| tunnel 13 |  | transforming proxy 13 |
|  |  | transparent proxy 14 |
|  |  | tunnel 14 |
| U |  | U |
| Upgrade header 55 |  | Upgrade header field 58 |
| upstream 12 |  | upstream 12 |
| URI scheme |  | URI scheme |
| http 16 |  | http 18 |
| https 18 |  | https 19 |
| user agent 10 |  | user agent 10 |
| V |  | V |
| Via header 57 |  | Via header field 60 |
| Authors' Addresses |  | Authors' Addresses |
| Roy T. Fielding (editor) |  | Roy T. Fielding (editor) |
| Day Software |  | Adobe Systems Incorporated |
| 23 Corporate Plaza DR, Suite 280 |  | 345 Park Ave |
| Newport Beach, CA 92660 |  | San Jose, CA 95110 |
| USA |  | USA |
| Phone: +1-949-706-5300 |  |  |
| Fax: +1-949-706-5305 |  |  |
| EMail: fielding@gbiv.com |  | EMail: fielding@gbiv.com |
| URI: http://roy.gbiv.com/ |  | URI: http://roy.gbiv.com/ |
| Jim Gettys |  | Jim Gettys |
| Alcatel-Lucent Bell Labs |  | Alcatel-Lucent Bell Labs |
| 21 Oak Knoll Road |  | 21 Oak Knoll Road |
| Carlisle, MA 01741 |  | Carlisle, MA 01741 |
| USA |  | USA |
| EMail: jg@freedesktop.org |  | EMail: jg@freedesktop.org |
| skipping to change at page 91, line 33 |  | skipping to change at page 96, line 4 |
| URI: http://roy.gbiv.com/ |  | URI: http://roy.gbiv.com/ |
| Jim Gettys |  | Jim Gettys |
| Alcatel-Lucent Bell Labs |  | Alcatel-Lucent Bell Labs |
| 21 Oak Knoll Road |  | 21 Oak Knoll Road |
| Carlisle, MA 01741 |  | Carlisle, MA 01741 |
| USA |  | USA |
| EMail: jg@freedesktop.org |  | EMail: jg@freedesktop.org |
| URI: http://gettys.wordpress.com/ |  | URI: http://gettys.wordpress.com/ |
| Jeffrey C. Mogul |  | Jeffrey C. Mogul |
| Hewlett-Packard Company |  | Hewlett-Packard Company |
| HP Labs, Large Scale Systems Group |  | HP Labs, Large Scale Systems Group |
| 1501 Page Mill Road, MS 1177 |  | 1501 Page Mill Road, MS 1177 |
| Palo Alto, CA 94304 |  | Palo Alto, CA 94304 |
| USA |  | USA |
| EMail: JeffMogul@acm.org |  | EMail: JeffMogul@acm.org |
| Henrik Frystyk Nielsen |  | Henrik Frystyk Nielsen |
| Microsoft Corporation |  | Microsoft Corporation |
| 1 Microsoft Way |  | 1 Microsoft Way |
| Redmond, WA 98052 |  | Redmond, WA 98052 |
| USA |  | USA |
| EMail: henrikn@microsoft.com |  | EMail: henrikn@microsoft.com |
| Larry Masinter |  | Larry Masinter |
| Adobe Systems, Incorporated |  | Adobe Systems Incorporated |
| 345 Park Ave |  | 345 Park Ave |
| San Jose, CA 95110 |  | San Jose, CA 95110 |
| USA |  | USA |
| EMail: LMM@acm.org |  | EMail: LMM@acm.org |
| URI: http://larry.masinter.net/ |  | URI: http://larry.masinter.net/ |
| Paul J. Leach |  | Paul J. Leach |
| Microsoft Corporation |  | Microsoft Corporation |
| 1 Microsoft Way |  | 1 Microsoft Way |
End of changes. 230 change blocks.
| 957 lines changed or deleted |  | 1157 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/