| draft-ietf-httpbis-p1-messaging-07.txt |  | draft-ietf-httpbis-p1-messaging-08.txt |
--- | --- | --- | --- | ---
| HTTPbis Working Group R. Fielding, Ed. |  | HTTPbis Working Group R. Fielding, Ed. |
| Internet-Draft Day Software |  | Internet-Draft Day Software |
| Obsoletes: 2616 (if approved) J. Gettys |  | Obsoletes: 2616 (if approved) J. Gettys |
| Intended status: Standards Track One Laptop per Child |  | Updates: 2817 (if approved) One Laptop per Child |
| Expires: January 14, 2010 J. Mogul |  | Intended status: Standards Track J. Mogul |
| HP |  | Expires: April 29, 2010 HP |
| H. Frystyk |  | H. Frystyk |
| Microsoft |  | Microsoft |
| L. Masinter |  | L. Masinter |
| Adobe Systems |  | Adobe Systems |
| 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 |
| July 13, 2009 |  | October 26, 2009 |
| 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-07 |  | draft-ietf-httpbis-p1-messaging-08 |
| Status of this Memo |  | Status of this Memo |
| This Internet-Draft is submitted to IETF in full conformance with the |  | This Internet-Draft is submitted to IETF in full conformance with the |
| provisions of BCP 78 and BCP 79. This document may contain material |  | provisions of BCP 78 and BCP 79. This document may contain material |
| from IETF Documents or IETF Contributions published or made publicly |  | from IETF Documents or IETF Contributions published or made publicly |
| available before November 10, 2008. The person(s) controlling the |  | available before November 10, 2008. The person(s) controlling the |
| copyright in some of this material may not have granted the IETF |  | copyright in some of this material may not have granted the IETF |
| Trust the right to allow modifications of such material outside the |  | Trust the right to allow modifications of such material outside the |
| IETF Standards Process. Without obtaining an adequate license from |  | IETF Standards Process. Without obtaining an adequate license from |
| skipping to change at page 2, line 10 |  | skipping to change at page 2, line 10 |
| 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." |
| The list of current Internet-Drafts can be accessed at |  | The list of current Internet-Drafts can be accessed at |
| http://www.ietf.org/ietf/1id-abstracts.txt. |  | http://www.ietf.org/ietf/1id-abstracts.txt. |
| The list of Internet-Draft Shadow Directories can be accessed at |  | The list of Internet-Draft Shadow Directories can be accessed at |
| http://www.ietf.org/shadow.html. |  | http://www.ietf.org/shadow.html. |
| This Internet-Draft will expire on January 14, 2010. |  | This Internet-Draft will expire on April 29, 2010. |
| Copyright Notice |  | Copyright Notice |
| Copyright (c) 2009 IETF Trust and the persons identified as the |  | Copyright (c) 2009 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 in effect on the date of |  | Provisions Relating to IETF Documents in effect on the date of |
| publication of this document (http://trustee.ietf.org/license-info). |  | publication of this document (http://trustee.ietf.org/license-info). |
| Please review these documents carefully, as they describe your rights |  | Please review these documents carefully, as they describe your rights |
| skipping to change at page 2, line 44 |  | skipping to change at page 2, line 44 |
| 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/11> and related |  | at <http://tools.ietf.org/wg/httpbis/trac/report/11> 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 E.8. |  | The changes in this draft are summarized in Appendix D.9. |
| 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 |  | 1.2.3. ABNF Rules defined in other Parts of the |
| Specification . . . . . . . . . . . . . . . . . . . . 9 |  | Specification . . . . . . . . . . . . . . . . . . . . 9 |
| 2. HTTP architecture . . . . . . . . . . . . . . . . . . . . . . 10 |  | 2. HTTP architecture . . . . . . . . . . . . . . . . . . . . . . 10 |
| 2.1. Uniform Resource Identifiers . . . . . . . . . . . . . . . 10 |  | 2.1. Client/Server Operation . . . . . . . . . . . . . . . . . 10 |
| 2.1.1. http URI scheme . . . . . . . . . . . . . . . . . . . 11 |  | 2.2. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 11 |
| 2.1.2. https URI scheme . . . . . . . . . . . . . . . . . . . 11 |  | 2.3. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 12 |
| 2.1.3. URI Comparison . . . . . . . . . . . . . . . . . . . . 11 |  | 2.4. Transport Independence . . . . . . . . . . . . . . . . . . 13 |
| 2.1.4. Scheme aliases considered harmful . . . . . . . . . . 12 |  | 2.5. HTTP Version . . . . . . . . . . . . . . . . . . . . . . . 14 |
| 2.2. Overall Operation . . . . . . . . . . . . . . . . . . . . 12 |  | 2.6. Uniform Resource Identifiers . . . . . . . . . . . . . . . 15 |
| 2.3. Use of HTTP for proxy communication . . . . . . . . . . . 14 |  | 2.6.1. http URI scheme . . . . . . . . . . . . . . . . . . . 16 |
| 2.4. Interception of HTTP for access control . . . . . . . . . 14 |  | 2.6.2. https URI scheme . . . . . . . . . . . . . . . . . . . 17 |
| 2.5. Use of HTTP by other protocols . . . . . . . . . . . . . . 14 |  | 2.6.3. http and https URI Normalization and Comparison . . . 17 |
| 2.6. Use of HTTP by media type specification . . . . . . . . . 14 |  | 3. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . . 18 |
| 3. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 14 |  | 3.1. Message Parsing Robustness . . . . . . . . . . . . . . . . 19 |
| 3.1. HTTP Version . . . . . . . . . . . . . . . . . . . . . . . 14 |  | 3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 19 |
| 3.2. Date/Time Formats: Full Date . . . . . . . . . . . . . . . 15 |  | 3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 21 |
| 3.3. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 18 |  | 3.4. Message Length . . . . . . . . . . . . . . . . . . . . . . 22 |
| 3.3.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 19 |  | 3.5. General Header Fields . . . . . . . . . . . . . . . . . . 23 |
| 3.4. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 21 |  | 4. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 |
| 3.5. Quality Values . . . . . . . . . . . . . . . . . . . . . . 22 |  | 4.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 24 |
| 4. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . . 22 |  | 4.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 24 |
| 4.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 22 |  | 4.1.2. request-target . . . . . . . . . . . . . . . . . . . . 24 |
| 4.2. Message Headers . . . . . . . . . . . . . . . . . . . . . 23 |  | 4.2. The Resource Identified by a Request . . . . . . . . . . . 26 |
| 4.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 24 |  | 5. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 |
| 4.4. Message Length . . . . . . . . . . . . . . . . . . . . . . 25 |  | 5.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 27 |
| 4.5. General Header Fields . . . . . . . . . . . . . . . . . . 27 |  | 5.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 28 |
| 5. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 |  | 6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 28 |
| 5.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 27 |  | 6.1. Date/Time Formats: Full Date . . . . . . . . . . . . . . . 28 |
| 5.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 28 |  | 6.2. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 31 |
| 5.1.2. request-target . . . . . . . . . . . . . . . . . . . . 28 |  | 6.2.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 32 |
| 5.2. The Resource Identified by a Request . . . . . . . . . . . 30 |  | 6.2.2. Compression Codings . . . . . . . . . . . . . . . . . 34 |
| 6. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 |  | 6.2.3. Transfer Coding Registry . . . . . . . . . . . . . . . 35 |
| 6.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 31 |  | 6.3. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 35 |
| 6.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 31 |  | 6.4. Quality Values . . . . . . . . . . . . . . . . . . . . . . 36 |
| 7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 32 |  | 7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 36 |
| 7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 32 |  | 7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 36 |
| 7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 32 |  | 7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 36 |
| 7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 32 |  | 7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 37 |
| 7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 34 |  | 7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 38 |
| 7.1.4. Practical Considerations . . . . . . . . . . . . . . . 34 |  | 7.1.4. Practical Considerations . . . . . . . . . . . . . . . 39 |
| 7.2. Message Transmission Requirements . . . . . . . . . . . . 35 |  | 7.2. Message Transmission Requirements . . . . . . . . . . . . 40 |
| 7.2.1. Persistent Connections and Flow Control . . . . . . . 35 |  | 7.2.1. Persistent Connections and Flow Control . . . . . . . 40 |
| 7.2.2. Monitoring Connections for Error Status Messages . . . 35 |  | 7.2.2. Monitoring Connections for Error Status Messages . . . 40 |
| 7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 36 |  | 7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 40 |
| 7.2.4. Client Behavior if Server Prematurely Closes |  | 7.2.4. Client Behavior if Server Prematurely Closes |
| Connection . . . . . . . . . . . . . . . . . . . . . . 38 |  | Connection . . . . . . . . . . . . . . . . . . . . . . 42 |
| 8. Header Field Definitions . . . . . . . . . . . . . . . . . . . 38 |  | 8. Miscellaneous notes that may disappear . . . . . . . . . . . . 43 |
| 8.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 39 |  | 8.1. Scheme aliases considered harmful . . . . . . . . . . . . 43 |
| 8.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 40 |  | 8.2. Use of HTTP for proxy communication . . . . . . . . . . . 43 |
| 8.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 |  | 8.3. Interception of HTTP for access control . . . . . . . . . 43 |
| 8.3.1. Clockless Origin Server Operation . . . . . . . . . . 41 |  | 8.4. Use of HTTP by other protocols . . . . . . . . . . . . . . 44 |
| 8.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 |  | 8.5. Use of HTTP by media type specification . . . . . . . . . 44 |
| 8.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 |  | 9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 44 |
| 8.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 44 |  | 9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 44 |
| 8.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 44 |  | 9.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 45 |
| 8.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 45 |  | 9.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 |
| 8.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 |  | 9.3.1. Clockless Origin Server Operation . . . . . . . . . . 47 |
| 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 |  | 9.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 |
| 9.1. Message Header Registration . . . . . . . . . . . . . . . 47 |  | 9.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 |
| 9.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 48 |  | 9.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 49 |
| 9.3. Internet Media Type Registrations . . . . . . . . . . . . 48 |  | 9.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 49 |
| 9.3.1. Internet Media Type message/http . . . . . . . . . . . 48 |  | 9.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 50 |
| 9.3.2. Internet Media Type application/http . . . . . . . . . 49 |  | 9.8.1. Upgrade Token Registry . . . . . . . . . . . . . . . . 51 |
| 10. Security Considerations . . . . . . . . . . . . . . . . . . . 50 |  | 9.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 |
| 10.1. Personal Information . . . . . . . . . . . . . . . . . . . 51 |  | 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 |
| 10.2. Abuse of Server Log Information . . . . . . . . . . . . . 51 |  | 10.1. Message Header Registration . . . . . . . . . . . . . . . 53 |
| 10.3. Attacks Based On File and Path Names . . . . . . . . . . . 51 |  | 10.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 54 |
| 10.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 51 |  | 10.3. Internet Media Type Registrations . . . . . . . . . . . . 54 |
| 10.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 52 |  | 10.3.1. Internet Media Type message/http . . . . . . . . . . . 54 |
| 10.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 53 |  | 10.3.2. Internet Media Type application/http . . . . . . . . . 55 |
| 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53 |  | 10.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 56 |
| 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54 |  | 10.5. Upgrade Token Registration . . . . . . . . . . . . . . . . 57 |
| 12.1. Normative References . . . . . . . . . . . . . . . . . . . 54 |  | 11. Security Considerations . . . . . . . . . . . . . . . . . . . 57 |
| 12.2. Informative References . . . . . . . . . . . . . . . . . . 55 |  | 11.1. Personal Information . . . . . . . . . . . . . . . . . . . 57 |
| Appendix A. Tolerant Applications . . . . . . . . . . . . . . . . 57 |  | 11.2. Abuse of Server Log Information . . . . . . . . . . . . . 58 |
| Appendix B. Compatibility with Previous Versions . . . . . . . . 58 |  | 11.3. Attacks Based On File and Path Names . . . . . . . . . . . 58 |
| B.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 59 |  | 11.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 58 |
|  |  | 11.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 59 |
|  |  | 11.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 60 |
|  |  | 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 60 |
|  |  | 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 61 |
|  |  | 13.1. Normative References . . . . . . . . . . . . . . . . . . . 61 |
|  |  | 13.2. Informative References . . . . . . . . . . . . . . . . . . 62 |
|  |  | Appendix A. Tolerant Applications . . . . . . . . . . . . . . . . 64 |
|  |  | Appendix B. Compatibility with Previous Versions . . . . . . . . 65 |
|  |  | B.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 66 |
| B.1.1. Changes to Simplify Multi-homed Web Servers and |  | B.1.1. Changes to Simplify Multi-homed Web Servers and |
| Conserve IP Addresses . . . . . . . . . . . . . . . . 59 |  | Conserve IP Addresses . . . . . . . . . . . . . . . . 66 |
| B.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 59 |  | B.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 67 |
| B.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 60 |  | B.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 67 |
| B.4. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 61 |  | B.4. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 68 |
| Appendix C. Terminology . . . . . . . . . . . . . . . . . . . . . 61 |  | Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 69 |
| Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 64 |  | Appendix D. Change Log (to be removed by RFC Editor before |
| Appendix E. Change Log (to be removed by RFC Editor before |  | publication) . . . . . . . . . . . . . . . . . . . . 73 |
| publication) . . . . . . . . . . . . . . . . . . . . 69 |  | D.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 73 |
| E.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 69 |  | D.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 73 |
| E.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 69 |  | D.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 75 |
| E.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 70 |  | D.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 76 |
| E.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 71 |  | D.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 76 |
| E.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 72 |  | D.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 77 |
| E.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 72 |  | D.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 77 |
| E.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 73 |  | D.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 78 |
| E.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 74 |  | D.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 79 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 |
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 78 |  | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 84 |
| 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 request targets and |
| relationships between resources. Messages are passed in a format |  | relationships between resources. Messages are passed in a format |
| similar to that used by Internet mail [RFC5322] and the Multipurpose |  | similar to that used by Internet mail [RFC5322] and the Multipurpose |
| skipping to change at page 6, line 47 |  | skipping to change at page 6, line 47 |
| 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 |
| should be reflected in corresponding changes to the observable |  | should be reflected in corresponding changes to the observable |
| interface provided by servers. However, since multiple clients may |  | interface provided by servers. However, since multiple clients may |
| 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" and obsoleting |
| [RFC2616]. Part 1 describes the architectural elements that are used |  | [RFC2616]. Part 1 describes the architectural elements that are used |
| or referred to in HTTP and defines the URI schemes specific to HTTP- |  | or referred to in HTTP, defines the "http" and "https" URI schemes, |
| based resources, overall network operation, connection management, |  | describes overall network operation and connection management, and |
| and HTTP message framing and forwarding requirements. Our goal is to |  | defines HTTP message framing and forwarding requirements. Our goal |
| define all of the mechanisms necessary for HTTP message handling that |  | is to define all of the mechanisms necessary for HTTP message |
| are independent of message semantics, thereby defining the complete |  | handling that are independent of message semantics, thereby defining |
| set of requirements for message parsers and message-forwarding |  | the complete set of requirements for message parsers and message- |
| intermediaries. |  | 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 8, line 16 |  | skipping to change at page 8, line 16 |
| <n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element ) |  | <n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element ) |
| For compatibility with legacy list rules, recipients SHOULD accept |  | For compatibility with legacy list rules, recipients SHOULD accept |
| empty list elements. In other words, consumers would follow the list |  | empty list elements. In other words, consumers would follow the list |
| productions: |  | productions: |
| #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ] |  | #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ] |
| 1#element => *( "," OWS ) element *( OWS "," [ OWS element ] ) |  | 1#element => *( "," OWS ) element *( OWS "," [ OWS element ] ) |
| Appendix D shows the collected ABNF, with the list rules expanded as |  | Appendix C shows the collected ABNF, with the list rules expanded as |
| explained above. |  | explained above. |
| 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 except the entity-body (see Appendix A for tolerant |  | protocol elements except the entity-body (see Appendix A for tolerant |
| applications). The end-of-line marker within an entity-body is |  | applications). The end-of-line marker within an entity-body is |
| defined by its associated media type, as described in Section 2.3 of |  | defined by its associated media type, as described in Section 2.3 of |
| [Part3]. |  | [Part3]. |
| skipping to change at page 9, line 12 |  | skipping to change at page 9, line 12 |
| 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 |
| BWS = OWS |  | BWS = OWS |
| ; "bad" whitespace |  | ; "bad" whitespace |
| obs-fold = CRLF |  | obs-fold = CRLF |
| ; see Section 4.2 |  | ; see Section 3.2 |
| Many HTTP/1.1 header field values consist of words separated by |  | Many HTTP/1.1 header field values consist of words separated by |
| whitespace or special characters. These special characters MUST be |  | whitespace or special characters. These special characters MUST be |
| in a quoted string to be used within a parameter value (as defined in |  | in a quoted string to be used within a parameter value (as defined in |
| Section 3.3). |  | Section 6.2). |
| tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" |  | tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" |
| / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" |  | / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" |
| / DIGIT / ALPHA |  | / DIGIT / ALPHA |
| token = 1*tchar |  | token = 1*tchar |
| 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 ("\") MAY be used as a single-character |  | The backslash character ("\") can be used as a single-character |
| quoting mechanism only within quoted-string and comment constructs. |  | quoting mechanism within quoted-string constructs: |
| quoted-text = %x01-09 / |  | quoted-pair = "\" ( WSP / VCHAR / obs-text ) |
| %x0B-0C / |  |  |
| %x0E-FF ; Characters excluding NUL, CR and LF |  | Producers SHOULD NOT escape characters that do not require escaping |
| quoted-pair = "\" quoted-text |  | (i.e., other than DQUOTE and the backslash character). |
| 1.2.3. ABNF Rules defined in other Parts of the Specification |  | 1.2.3. ABNF Rules defined in other Parts of the Specification |
| The ABNF rules below are defined in other parts: |  | The ABNF rules below are defined in other parts: |
| request-header = <request-header, defined in [Part2], Section 3> |  | request-header = <request-header, defined in [Part2], Section 3> |
| response-header = <response-header, defined in [Part2], Section 5> |  | response-header = <response-header, defined in [Part2], Section 5> |
| entity-body = <entity-body, defined in [Part3], Section 3.2> |  | entity-body = <entity-body, defined in [Part3], Section 3.2> |
| entity-header = <entity-header, defined in [Part3], Section 3.1> |  | entity-header = <entity-header, defined in [Part3], Section 3.1> |
| Cache-Control = <Cache-Control, defined in [Part6], Section 3.4> |  | Cache-Control = <Cache-Control, defined in [Part6], Section 3.4> |
| Pragma = <Pragma, defined in [Part6], Section 3.4> |  | Pragma = <Pragma, defined in [Part6], Section 3.4> |
| Warning = <Warning, defined in [Part6], Section 3.6> |  | Warning = <Warning, defined in [Part6], Section 3.6> |
| 2. HTTP architecture |  | 2. HTTP architecture |
| HTTP was created with a specific architecture in mind, the World Wide |  | HTTP was created for the World Wide Web architecture and has evolved |
| Web, and has evolved over time to support the scalability needs of a |  | over time to support the scalability needs of a worldwide hypertext |
| worldwide hypertext system. Much of that architecture is reflected |  | system. Much of that architecture is reflected in the terminology |
| in the terminology and syntax productions used to define HTTP. |  | and syntax productions used to define HTTP. |
| 2.1. Uniform Resource Identifiers |  |  |
| Uniform Resource Identifiers (URIs) [RFC3986] are used throughout |  |  |
| HTTP as the means for identifying resources. URI references are used |  |  |
| to target requests, redirect responses, and define relationships. |  |  |
| HTTP does not limit what a resource may be; it merely defines an |  |  |
| 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 |  |  |
| [RFC3986]. |  |  |
| This specification adopts the definitions of "URI-reference", |  |  |
| "absolute-URI", "relative-part", "fragment", "port", "host", "path- |  |  |
| abempty", "path-absolute", "query", and "authority" from [RFC3986]. |  |  |
| In addition, we define a partial-URI rule for protocol elements that |  |  |
| allow a relative URI without a fragment. |  |  |
| URI = <URI, defined in [RFC3986], Section 3> |  |  |
| URI-reference = <URI-reference, defined in [RFC3986], Section 4.1> |  |  |
| absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3> |  |  |
| relative-part = <relative-part, defined in [RFC3986], Section 4.2> |  |  |
| authority = <authority, defined in [RFC3986], Section 3.2> |  |  |
| fragment = <fragment, defined in [RFC3986], Section 3.5> |  |  |
| path-abempty = <path-abempty, 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> |  |  |
| query = <query, defined in [RFC3986], Section 3.4> |  |  |
| uri-host = <host, defined in [RFC3986], Section 3.2.2> |  |  |
| partial-URI = relative-part [ "?" query ] |  |  |
| Each protocol element in HTTP that allows a URI reference will |  |  |
| indicate in its ABNF production whether the element allows only a URI |  |  |
| in absolute form (absolute-URI), any relative reference (relative- |  |  |
| ref), or some other subset of the URI-reference grammar. Unless |  |  |
| otherwise indicated, URI references are parsed relative to the |  |  |
| request target (the default base URI for both the request and its |  |  |
| corresponding response). |  |  |
| 2.1.1. http URI scheme |  |  |
| The "http" scheme is used to locate network resources via the HTTP |  |  |
| protocol. |  |  |
| http-URI = "http:" "//" authority path-abempty [ "?" query ] |  |  |
| If the port is empty or not given, port 80 is assumed. The semantics |  |  |
| are that the identified resource is located at the server listening |  |  |
| for TCP connections on that port of that host, and the request-target |  |  |
| for the resource is path-absolute (Section 5.1.2). The use of IP |  |  |
| addresses in URLs SHOULD be avoided whenever possible (see |  |  |
| [RFC1900]). If the path-absolute is not present in the URL, it MUST |  |  |
| be given as "/" when used as a request-target for a resource |  |  |
| (Section 5.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. |  |  |
| 2.1.2. https URI scheme |  |  |
| [[anchor1: TBD: Define and explain purpose of https scheme.]] |  |  |
| Note: the "https" scheme is defined in [RFC2818]. |  |  |
| 2.1.3. URI Comparison |  | 2.1. Client/Server Operation |
| When comparing two URIs to decide if they match or not, a client |  | HTTP is a request/response protocol that operates by exchanging |
| SHOULD use a case-sensitive octet-by-octet comparison of the entire |  | messages across a reliable transport or session-layer connection. An |
| URIs, with these exceptions: |  | HTTP client is a program that establishes a connection to a server |
|  |  | for the purpose of sending one or more HTTP requests. An HTTP server |
|  |  | is a program that accepts connections in order to service HTTP |
|  |  | requests by sending HTTP responses. |
| o A port that is empty or not given is equivalent to the default |  | Note that the terms "client" and "server" refer only to the roles |
| port for that URI-reference; |  | that these programs perform for a particular connection. The same |
|  |  | program may act as a client on some connections and a server on |
|  |  | others. We use the term "user agent" to refer to the program that |
|  |  | initiates a request, such as a WWW browser, editor, or spider (web- |
|  |  | traversing robot), and the term "origin server" to refer to the |
|  |  | program that can originate authoritative responses to a request. |
| o Comparisons of host names MUST be case-insensitive; |  | Most HTTP communication consists of a retrieval request (GET) for a |
|  |  | representation of some resource identified by a URI. In the simplest |
|  |  | case, this may be accomplished via a single connection (v) between |
|  |  | the user agent (UA) and the origin server (O). |
| o Comparisons of scheme names MUST be case-insensitive; |  | request chain ------------------------> |
|  |  | UA -------------------v------------------- O |
|  |  | <----------------------- response chain |
| o An empty path-absolute is equivalent to a path-absolute of "/". |  | A client sends an HTTP request to the server in the form of a request |
|  |  | message (Section 4), beginning with a method, URI, and protocol |
|  |  | version, followed by MIME-like header fields containing request |
|  |  | modifiers, client information, and payload metadata, an empty line to |
|  |  | indicate the end of the header section, and finally the payload body |
|  |  | (if any). |
| o Characters other than those in the "reserved" set are equivalent |  | A server responds to the client's request by sending an HTTP response |
| to their percent-encoded octets (see [RFC3986], Section 2.1). |  | message (Section 5), beginning with a status line that includes the |
|  |  | protocol version, a success or error code, and textual reason phrase, |
|  |  | followed by MIME-like header fields containing server information, |
|  |  | resource metadata, and payload metadata, an empty line to indicate |
|  |  | the end of the header section, and finally the payload body (if any). |
| For example, the following three URIs are equivalent: |  | The following example illustrates a typical message exchange for a |
|  |  | GET request on the URI "http://www.example.com/hello.txt": |
| http://example.com:80/~smith/home.html |  | client request: |
| http://EXAMPLE.com/%7Esmith/home.html |  |  |
| http://EXAMPLE.com:/%7esmith/home.html |  |  |
| 2.1.4. Scheme aliases considered harmful |  | GET /hello.txt HTTP/1.1 |
|  |  | User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 |
|  |  | Host: www.example.com |
|  |  | Accept: */* |
| 2.2. Overall Operation |  | server response: |
| HTTP is a request/response protocol. A client sends a request to the |  | HTTP/1.1 200 OK |
| server in the form of a request method, URI, and protocol version, |  | Date: Mon, 27 Jul 2009 12:28:53 GMT |
| followed by a MIME-like message containing request modifiers, client |  | Server: Apache |
| information, and possible body content over a connection with a |  | Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT |
| server. The server responds with a status line, including the |  | ETag: "34aa387-d-1568eb00" |
| message's protocol version and a success or error code, followed by a |  | Accept-Ranges: bytes |
| MIME-like message containing server information, entity |  | Content-Length: 14 |
| metainformation, and possible entity-body content. |  | Vary: Accept-Encoding |
|  |  | Content-Type: text/plain |
| Most HTTP communication is initiated by a user agent and consists of |  | Hello World! |
| a request to be applied to a resource on some origin server. In the |  |  |
| simplest case, this may be accomplished via a single connection (v) |  |  |
| between the user agent (UA) and the origin server (O). |  |  |
| request chain ------------------------> |  | 2.2. Intermediaries |
| UA -------------------v------------------- O |  |  |
| <----------------------- response chain |  |  |
| A more complicated situation occurs when one or more intermediaries |  | A more complicated situation occurs when one or more intermediaries |
| are present in the request/response chain. There are three common |  | are present in the request/response chain. There are three common |
| forms of intermediary: proxy, gateway, and tunnel. A proxy is a |  | forms of intermediary: proxy, gateway, and tunnel. In some cases, a |
| forwarding agent, receiving requests for a URI in its absolute form, |  | single intermediary may act as an origin server, proxy, gateway, or |
| rewriting all or part of the message, and forwarding the reformatted |  | tunnel, switching behavior based on the nature of each request. |
| request toward the server identified by the URI. A gateway is a |  |  |
| receiving agent, acting as a layer above some other server(s) and, if |  |  |
| necessary, translating the requests to the underlying server's |  |  |
| protocol. A tunnel acts as a relay point between two connections |  |  |
| without changing the messages; tunnels are used when the |  |  |
| communication needs to pass through an intermediary (such as a |  |  |
| firewall) even when the intermediary cannot understand the contents |  |  |
| of the messages. |  |  |
| request chain --------------------------------------> |  | request chain --------------------------------------> |
| UA -----v----- A -----v----- B -----v----- C -----v----- O |  | UA -----v----- A -----v----- B -----v----- C -----v----- O |
| <------------------------------------- response chain |  | <------------------------------------- response chain |
| 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. |
| This distinction is important because some HTTP communication options |  | Some HTTP communication options may apply only to the connection with |
| may apply only to the connection with the nearest, non-tunnel |  | the nearest, non-tunnel neighbor, only to the end-points of the |
| neighbor, only to the end-points of the chain, or to all connections |  | chain, or to all connections along the chain. Although the diagram |
| along the chain. Although the diagram is linear, each participant |  | is linear, each participant may be engaged in multiple, simultaneous |
| may be engaged in multiple, simultaneous communications. For |  | communications. For example, B may be receiving requests from many |
| example, B may be receiving requests from many clients other than A, |  | clients other than A, and/or forwarding requests to servers other |
| and/or forwarding requests to servers other than C, at the same time |  | than C, at the same time that it is handling A's request. |
| that it is handling A's request. |  |  |
| Any party to the communication which is not acting as a tunnel may |  | We use the terms "upstream" and "downstream" to describe various |
| employ an internal cache for handling requests. The effect of a |  | requirements in relation to the directional flow of a message: all |
| cache is that the request/response chain is shortened if one of the |  | messages flow from upstream to downstream. Likewise, we use the |
| participants along the chain has a cached response applicable to that |  | terms "inbound" and "outbound" to refer to directions in relation to |
| request. The following illustrates the resulting chain if B has a |  | the request path: "inbound" means toward the origin server and |
| cached copy of an earlier response from O (via C) for a request which |  | "outbound" means toward the user agent. |
| has not been cached by UA or A. |  |  |
|  |  | A proxy is a message forwarding agent that is selected by the client, |
|  |  | usually via local configuration rules, to receive requests for some |
|  |  | type(s) of absolute URI and attempt to satisfy those requests via |
|  |  | translation through the HTTP interface. Some translations are |
|  |  | minimal, such as for proxy requests for "http" URIs, whereas other |
|  |  | requests may require translation to and from entirely different |
|  |  | application-layer protocols. Proxies are often used to group an |
|  |  | organization's HTTP requests through a common intermediary for the |
|  |  | sake of security, annotation services, or shared caching. |
|  |  | 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 requests |
|  |  | to the underlying server's protocol. Gateways are often used for |
|  |  | load balancing or partitioning HTTP services across multiple |
|  |  | machines. Unlike a proxy, a gateway receives requests as if it were |
|  |  | the origin server for the requested resource; the requesting client |
|  |  | will not be aware that it is communicating with a gateway. A gateway |
|  |  | 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 |
|  |  | that connection. A gateway communicates with inbound servers using |
|  |  | any protocol it desires, including private extensions to HTTP that |
|  |  | are outside the scope of this specification. |
|  |  | A tunnel acts as a blind relay between two connections without |
|  |  | changing the messages. Once active, a tunnel is not considered a |
|  |  | party to the HTTP communication, though the tunnel may have been |
|  |  | initiated by an HTTP request. A tunnel ceases to exist when both |
|  |  | ends of the relayed connection are closed. Tunnels are used to |
|  |  | extend a virtual connection through an intermediary, such as when |
|  |  | transport-layer security is used to establish private communication |
|  |  | through a shared firewall proxy. |
|  |  | 2.3. Caches |
|  |  | Any party to HTTP communication that is not acting as a tunnel may |
|  |  | employ an internal cache for handling requests. A cache is a local |
|  |  | store of previous response messages and the subsystem that controls |
|  |  | its message storage, retrieval, and deletion. A cache stores |
|  |  | cacheable responses in order to reduce the response time and network |
|  |  | bandwidth consumption on future, equivalent requests. Any client or |
|  |  | server may include a cache, though a cache 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 |
|  |  | if one of the participants along the chain has a cached response |
|  |  | applicable to that request. The following illustrates the resulting |
|  |  | chain if B has a cached copy of an earlier response from O (via C) |
|  |  | for a request which has not been cached by UA or A. |
| request chain ----------> |  | request chain ----------> |
| UA -----v----- A -----v----- B - - - - - - C - - - - - - O |  | UA -----v----- A -----v----- B - - - - - - C - - - - - - O |
| <--------- response chain |  | <--------- response chain |
| Not all responses are usefully cacheable, and some requests may |  | A response is cacheable if a cache is allowed to store a copy of the |
| contain modifiers which place special requirements on cache behavior. |  | response message for use in answering subsequent requests. Even when |
| HTTP requirements for cache behavior and cacheable responses are |  | a response is cacheable, there may be additional constraints placed |
| defined in Section 1 of [Part6]. |  | by the client or by the origin server on when that cached response |
|  |  | can be used for a particular request. HTTP requirements for cache |
|  |  | behavior and cacheable responses are defined in Section 2 of [Part6]. |
| In fact, there are a wide variety of architectures and configurations |  | There are a wide variety of architectures and configurations of |
| of caches and proxies currently being experimented with or deployed |  | caches and proxies deployed across the World Wide Web and inside |
| across the World Wide Web. These systems include national hierarchies |  | large organizations. These systems include national hierarchies of |
| of proxy caches to save transoceanic bandwidth, systems that |  | proxy caches to save transoceanic bandwidth, systems that broadcast |
| broadcast or multicast cache entries, organizations that distribute |  | or multicast cache entries, organizations that distribute subsets of |
| subsets of cached data via CD-ROM, and so on. HTTP systems are used |  | cached data via optical media, and so on. |
| in corporate intranets over high-bandwidth links, and for access via |  |  |
| PDAs with low-power radio links and intermittent connectivity. The |  | 2.4. Transport Independence |
| goal of HTTP/1.1 is to support the wide diversity of configurations |  |  |
| already deployed while introducing protocol constructs that meet the |  | HTTP systems are used in a wide variety of environments, from |
| needs of those who build web applications that require high |  | corporate intranets with high-bandwidth links to long-distance |
| reliability and, failing that, at least reliable indications of |  | communication over low-power radio links and intermittent |
| failure. |  | connectivity. |
| HTTP communication usually takes place over TCP/IP connections. The |  | HTTP communication usually takes place over TCP/IP connections. The |
| default port is TCP 80 |  | default port is TCP 80 |
| (<http://www.iana.org/assignments/port-numbers>), but other ports can |  | (<http://www.iana.org/assignments/port-numbers>), but other ports can |
| be used. This does not preclude HTTP from being implemented on top |  | be used. This does not preclude HTTP from being implemented on top |
| of any other protocol on the Internet, or on other networks. HTTP |  | of any other protocol on the Internet, or on other networks. HTTP |
| only presumes a reliable transport; any protocol that provides such |  | only presumes a reliable transport; any protocol that provides such |
| guarantees can be used; the mapping of the HTTP/1.1 request and |  | guarantees can be used; the mapping of the HTTP/1.1 request and |
| response structures onto the transport data units of the protocol in |  | response structures onto the transport data units of the protocol in |
| question is outside the scope of this specification. |  | question is outside the scope of this specification. |
| In HTTP/1.0, most implementations used a new connection for each |  | In HTTP/1.0, most implementations used a new connection for each |
| request/response exchange. In HTTP/1.1, a connection may be used for |  | request/response exchange. In HTTP/1.1, a connection may be used for |
| one or more request/response exchanges, although connections may be |  | one or more request/response exchanges, although connections may be |
| closed for a variety of reasons (see Section 7.1). |  | closed for a variety of reasons (see Section 7.1). |
| 2.3. Use of HTTP for proxy communication |  | 2.5. HTTP Version |
| [[anchor2: TBD: Configured to use HTTP to proxy HTTP or other |  |  |
| protocols.]] |  |  |
| 2.4. Interception of HTTP for access control |  |  |
| [[anchor3: TBD: Interception of HTTP traffic for initiating access |  |  |
| control.]] |  |  |
| 2.5. Use of HTTP by other protocols |  |  |
| [[anchor4: TBD: Profiles of HTTP defined by other protocol. |  |  |
| Extensions of HTTP like WebDAV.]] |  |  |
| 2.6. Use of HTTP by media type specification |  |  |
| [[anchor5: TBD: Instructions on composing HTTP requests via hypertext |  |  |
| formats.]] |  |  |
| 3. Protocol Parameters |  |  |
| 3.1. 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. The protocol versioning policy is intended to allow |
| the sender to indicate the format of a message and its capacity for |  | the sender to indicate the format of a message and its capacity for |
| understanding further HTTP communication, rather than the features |  | understanding further HTTP communication, rather than the features |
| obtained via that communication. No change is made to the version |  | obtained via that communication. No change is made to the version |
| number for the addition of message components which do not affect |  | number for the addition of message components which do not affect |
| communication behavior or which only add to extensible field values. |  | communication behavior or which only add to extensible field values. |
| The <minor> number is incremented when the changes made to the |  | The <minor> number is incremented when the changes made to the |
| protocol add features which do not change the general message parsing |  | protocol add features which do not change the general message parsing |
| skipping to change at page 15, line 41 |  | skipping to change at page 15, line 17 |
| Due to interoperability problems with HTTP/1.0 proxies discovered |  | Due to interoperability problems with HTTP/1.0 proxies discovered |
| since the publication of [RFC2068], caching proxies MUST, gateways |  | since the publication of [RFC2068], caching proxies MUST, gateways |
| MAY, and tunnels MUST NOT upgrade the request to the highest version |  | MAY, and tunnels MUST NOT upgrade the request to the highest version |
| they support. The proxy/gateway's response to that request MUST be |  | they support. The proxy/gateway's response to that request MUST be |
| in the same major version as the request. |  | in the same major version as the request. |
| Note: Converting between versions of HTTP may involve modification |  | Note: Converting between versions of HTTP may involve modification |
| of header fields required or forbidden by the versions involved. |  | of header fields required or forbidden by the versions involved. |
| 3.2. Date/Time Formats: Full Date |  | 2.6. Uniform Resource Identifiers |
| HTTP applications have historically allowed three different formats |  |  |
| for the representation of date/time stamps: |  |  |
| Sun, 06 Nov 1994 08:49:37 GMT ; RFC 1123 |  |  |
| Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format |  |  |
| Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format |  |  |
| The first format is preferred as an Internet standard and represents |  |  |
| a fixed-length subset of that defined by [RFC1123]. The other |  |  |
| formats are described here only for compatibility with obsolete |  |  |
| implementations. HTTP/1.1 clients and servers that parse the date |  |  |
| value MUST accept all three formats (for compatibility with |  |  |
| HTTP/1.0), though they MUST only generate the RFC 1123 format for |  |  |
| representing HTTP-date values in header fields. See Appendix A for |  |  |
| further information. |  |  |
| All HTTP date/time stamps MUST be represented in Greenwich Mean Time |  |  |
| (GMT), without exception. For the purposes of HTTP, GMT is exactly |  |  |
| equal to UTC (Coordinated Universal Time). This is indicated in the |  |  |
| first two formats by the inclusion of "GMT" as the three-letter |  |  |
| abbreviation for time zone, and MUST be assumed when reading the |  |  |
| asctime format. HTTP-date is case sensitive and MUST NOT include |  |  |
| additional whitespace beyond that specifically included as SP in the |  |  |
| grammar. |  |  |
| HTTP-date = rfc1123-date / obs-date |  |  |
| Preferred format: |  |  |
| rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT |  |  |
| day-name = %x4D.6F.6E ; "Mon", case-sensitive |  |  |
| / %x54.75.65 ; "Tue", case-sensitive |  |  |
| / %x57.65.64 ; "Wed", case-sensitive |  |  |
| / %x54.68.75 ; "Thu", case-sensitive |  |  |
| / %x46.72.69 ; "Fri", case-sensitive |  |  |
| / %x53.61.74 ; "Sat", case-sensitive |  |  |
| / %x53.75.6E ; "Sun", case-sensitive |  |  |
| date1 = day SP month SP year |  |  |
| day = 2DIGIT |  |  |
| month = %x4A.61.6E ; "Jan", case-sensitive |  |  |
| / %x46.65.62 ; "Feb", case-sensitive |  |  |
| / %x4D.61.72 ; "Mar", case-sensitive |  |  |
| / %x41.70.72 ; "Apr", case-sensitive |  |  |
| / %x4D.61.79 ; "May", case-sensitive |  |  |
| / %x4A.75.6E ; "Jun", case-sensitive |  |  |
| / %x4A.75.6C ; "Jul", case-sensitive |  |  |
| / %x41.75.67 ; "Aug", case-sensitive |  |  |
| / %x53.65.70 ; "Sep", case-sensitive |  |  |
| / %x4F.63.74 ; "Oct", case-sensitive |  |  |
| / %x4E.6F.76 ; "Nov", case-sensitive |  |  |
| / %x44.65.63 ; "Dec", case-sensitive |  |  |
| year = 4DIGIT |  |  |
| GMT = %x47.4D.54 ; "GMT", case-sensitive |  |  |
| time-of-day = hour ":" minute ":" second |  |  |
| ; 00:00:00 - 23:59:59 |  |  |
| hour = 2DIGIT |  |  |
| minute = 2DIGIT |  |  |
| second = 2DIGIT |  |  |
| The semantics of day-name, day, month, year, and time-of-day are the |  |  |
| same as those defined for the RFC 5322 constructs with the |  |  |
| corresponding name ([RFC5322], Section 3.3). |  |  |
| Obsolete formats: |  |  |
| obs-date = rfc850-date / asctime-date |  |  |
| rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT |  |  |
| date2 = day "-" month "-" 2DIGIT |  |  |
| ; day-month-year (e.g., 02-Jun-82) |  |  |
| day-name-l = %x4D.6F.6E.64.61.79 ; "Monday", case-sensitive |  |  |
| / %x54.75.65.73.64.61.79 ; "Tuesday", case-sensitive |  |  |
| / %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive |  |  |
| / %x54.68.75.72.73.64.61.79 ; "Thursday", case-sensitive |  |  |
| / %x46.72.69.64.61.79 ; "Friday", case-sensitive |  |  |
| / %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive |  |  |
| / %x53.75.6E.64.61.79 ; "Sunday", case-sensitive |  |  |
| asctime-date = day-name SP date3 SP time-of-day SP year |  |  |
| date3 = month SP ( 2DIGIT / ( SP 1DIGIT )) |  |  |
| ; month day (e.g., Jun 2) |  |  |
| Note: Recipients of date values are encouraged to be robust in |  |  |
| accepting date values that may have been sent by non-HTTP |  |  |
| applications, as is sometimes the case when retrieving or posting |  |  |
| messages via proxies/gateways to SMTP or NNTP. |  |  |
| Note: HTTP requirements for the date/time stamp format apply only |  |  |
| to their usage within the protocol stream. Clients and servers |  |  |
| are not required to use these formats for user presentation, |  |  |
| request logging, etc. |  |  |
| 3.3. Transfer Codings |  |  |
| Transfer-coding values are used to indicate an encoding |  |  |
| transformation that has been, can be, or may need to be applied to an |  |  |
| entity-body in order to ensure "safe transport" through the network. |  |  |
| This differs from a content coding in that the transfer-coding is a |  |  |
| property of the message, not of the original entity. |  |  |
| transfer-coding = "chunked" / transfer-extension |  |  |
| transfer-extension = token *( OWS ";" OWS transfer-parameter ) |  |  |
| Parameters are in the form of attribute/value pairs. |  |  |
| transfer-parameter = attribute BWS "=" BWS value |  |  |
| attribute = token |  |  |
| value = token / quoted-string |  |  |
| All transfer-coding values are case-insensitive. HTTP/1.1 uses |  |  |
| transfer-coding values in the TE header field (Section 8.5) and in |  |  |
| the Transfer-Encoding header field (Section 8.7). |  |  |
| Whenever a transfer-coding is applied to a message-body, the set of |  |  |
| transfer-codings MUST include "chunked", unless the message indicates |  |  |
| it is terminated by closing the connection. When the "chunked" |  |  |
| transfer-coding is used, it MUST be the last transfer-coding applied |  |  |
| to the message-body. The "chunked" transfer-coding MUST NOT be |  |  |
| applied more than once to a message-body. These rules allow the |  |  |
| recipient to determine the transfer-length of the message |  |  |
| (Section 4.4). |  |  |
| Transfer-codings are analogous to the Content-Transfer-Encoding |  |  |
| values of MIME [RFC2045], which were designed to enable safe |  |  |
| transport of binary data over a 7-bit transport service. However, |  |  |
| safe transport has a different focus for an 8bit-clean transfer |  |  |
| protocol. In HTTP, the only unsafe characteristic of message-bodies |  |  |
| is the difficulty in determining the exact body length (Section 4.4), |  |  |
| or the desire to encrypt data over a shared transport. |  |  |
| The Internet Assigned Numbers Authority (IANA) acts as a registry for |  |  |
| transfer-coding value tokens. Initially, the registry contains the |  |  |
| following tokens: "chunked" (Section 3.3.1), "gzip", "compress", and |  |  |
| "deflate" (Section 2.2 of [Part3]). |  |  |
| New transfer-coding value tokens SHOULD be registered in the same way |  |  |
| as new content-coding value tokens (Section 2.2 of [Part3]). |  |  |
| A server which receives an entity-body with a transfer-coding it does |  |  |
| not understand SHOULD return 501 (Not Implemented), and close the |  |  |
| connection. A server MUST NOT send transfer-codings to an HTTP/1.0 |  |  |
| client. |  |  |
| 3.3.1. Chunked Transfer Coding |  |  |
| The chunked encoding modifies the body of a message in order to |  |  |
| transfer it as a series of chunks, each with its own size indicator, |  |  |
| followed by an OPTIONAL trailer containing entity-header fields. |  |  |
| This allows dynamically produced content to be transferred along with |  |  |
| the information necessary for the recipient to verify that it has |  |  |
| received the full message. |  |  |
| Chunked-Body = *chunk |  |  |
| last-chunk |  |  |
| trailer-part |  |  |
| CRLF |  |  |
| chunk = chunk-size *WSP [ chunk-ext ] CRLF |  | Uniform Resource Identifiers (URIs) [RFC3986] are used throughout |
| chunk-data CRLF |  | HTTP as the means for identifying resources. URI references are used |
| chunk-size = 1*HEXDIG |  | to target requests, indicate redirects, and define relationships. |
| last-chunk = 1*("0") *WSP [ chunk-ext ] CRLF |  | HTTP does not limit what a resource may be; it merely defines an |
|  |  | 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 |
|  |  | [RFC3986]. |
| chunk-ext = *( ";" *WSP chunk-ext-name |  | This specification adopts the definitions of "URI-reference", |
| [ "=" chunk-ext-val ] *WSP ) |  | "absolute-URI", "relative-part", "port", "host", "path-abempty", |
| chunk-ext-name = token |  | "path-absolute", "query", and "authority" from [RFC3986]. In |
| chunk-ext-val = token / quoted-string |  | addition, we define a partial-URI rule for protocol elements that |
| chunk-data = 1*OCTET ; a sequence of chunk-size octets |  | allow a relative URI without a fragment. |
| trailer-part = *( entity-header CRLF ) |  |  |
| The chunk-size field is a string of hex digits indicating the size of |  | URI = <URI, defined in [RFC3986], Section 3> |
| the chunk-data in octets. The chunked encoding is ended by any chunk |  | URI-reference = <URI-reference, defined in [RFC3986], Section 4.1> |
| whose size is zero, followed by the trailer, which is terminated by |  | absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3> |
| an empty line. |  | relative-part = <relative-part, defined in [RFC3986], Section 4.2> |
|  |  | authority = <authority, defined in [RFC3986], Section 3.2> |
|  |  | path-abempty = <path-abempty, 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> |
|  |  | query = <query, defined in [RFC3986], Section 3.4> |
|  |  | uri-host = <host, defined in [RFC3986], Section 3.2.2> |
| The trailer allows the sender to include additional HTTP header |  | partial-URI = relative-part [ "?" query ] |
| fields at the end of the message. The Trailer header field can be |  |  |
| used to indicate which header fields are included in a trailer (see |  |  |
| Section 8.6). |  |  |
| A server using chunked transfer-coding in a response MUST NOT use the |  | Each protocol element in HTTP that allows a URI reference will |
| trailer for any header fields unless at least one of the following is |  | indicate in its ABNF production whether the element allows only a URI |
| true: |  | in absolute form (absolute-URI), any relative reference (relative- |
|  |  | ref), or some other subset of the URI-reference grammar. Unless |
|  |  | otherwise indicated, URI references are parsed relative to the |
|  |  | request target (the default base URI for both the request and its |
|  |  | corresponding response). |
| 1. the request included a TE header field that indicates "trailers" |  | 2.6.1. http URI scheme |
| is acceptable in the transfer-coding of the response, as |  |  |
| described in Section 8.5; or, |  |  |
| 2. the server is the origin server for the response, the trailer |  | The "http" URI scheme is hereby defined for the purpose of minting |
| fields consist entirely of optional metadata, and the recipient |  | identifiers according to their association with the hierarchical |
| could use the message (in a manner acceptable to the origin |  | namespace governed by a potential HTTP origin server listening for |
| server) without receiving this metadata. In other words, the |  | TCP connections on a given port. The HTTP server is identified via |
| origin server is willing to accept the possibility that the |  | the generic syntax's authority component, which includes a host |
| trailer fields might be silently discarded along the path to the |  | identifier and optional TCP port, and the remainder of the URI is |
| client. |  | considered to be identifying data corresponding to a resource for |
|  |  | which that server might provide an HTTP interface. |
| This requirement prevents an interoperability failure when the |  | http-URI = "http:" "//" authority path-abempty [ "?" query ] |
| message is being received by an HTTP/1.1 (or later) proxy and |  |  |
| forwarded to an HTTP/1.0 recipient. It avoids a situation where |  |  |
| compliance with the protocol would have necessitated a possibly |  |  |
| infinite buffer on the proxy. |  |  |
| A process for decoding the "chunked" transfer-coding can be |  | The host identifier within an authority component is defined in |
| represented in pseudo-code as: |  | [RFC3986], Section 3.2.2. If host is provided as an IP literal or |
|  |  | IPv4 address, then the HTTP 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). |
| length := 0 |  | Regardless of the form of host identifier, access to that host is not |
| read chunk-size, chunk-ext (if any) and CRLF |  | implied by the mere presence of its name or address. The host may or |
| while (chunk-size > 0) { |  | may not exist and, even when it does exist, may or may not be running |
| read chunk-data and CRLF |  | an HTTP server or listening to the indicated port. The "http" URI |
| append chunk-data to entity-body |  | scheme makes use of the delegated nature of Internet names and |
| length := length + chunk-size |  | addresses to establish a naming authority (whatever entity has the |
| read chunk-size and CRLF |  | ability to place an HTTP server at that Internet name or address) and |
| } |  | allows that authority to determine which names are valid and how they |
| read entity-header |  | might be used. |
| while (entity-header not empty) { |  |  |
| append entity-header to existing header fields |  |  |
| read entity-header |  |  |
| } |  |  |
| Content-Length := length |  |  |
| Remove "chunked" from Transfer-Encoding |  |  |
| All HTTP/1.1 applications MUST be able to receive and decode the |  | When an "http" URI is used within a context that calls for access to |
| "chunked" transfer-coding, and MUST ignore chunk-ext extensions they |  | the indicated resource, a client MAY attempt access by resolving the |
| do not understand. |  | host to an IP address, establishing a TCP connection to that address |
|  |  | on the indicated port, and sending an HTTP request message to the |
|  |  | server containing the URI's identifying data as described in |
|  |  | Section 4. If the server responds to that request with a non-interim |
|  |  | HTTP response message, as described in Section 5, then that response |
|  |  | is considered an authoritative answer to the client's request. |
| 3.4. Product Tokens |  | Although HTTP is independent of the transport protocol, the "http" |
|  |  | scheme is specific to TCP-based services because the name delegation |
|  |  | process depends on TCP for establishing authority. An HTTP service |
|  |  | based on some other underlying connection protocol would presumably |
|  |  | be identified using a different URI scheme, just as the "https" |
|  |  | scheme (below) is used for servers that require an SSL/TLS transport |
|  |  | layer on a connection. Other protocols may also be used to provide |
|  |  | access to "http" identified resources --- it is only the |
|  |  | authoritative interface used for mapping the namespace that is |
|  |  | specific to TCP. |
| Product tokens are used to allow communicating applications to |  | 2.6.2. https URI scheme |
| identify themselves by software name and version. Most fields using |  |  |
| product tokens also allow sub-products which form a significant part |  |  |
| of the application to be listed, separated by whitespace. By |  |  |
| convention, the products are listed in order of their significance |  |  |
| for identifying the application. |  |  |
| product = token ["/" product-version] |  | The "https" URI scheme is hereby defined for the purpose of minting |
| product-version = token |  | identifiers according to their association with the hierarchical |
|  |  | namespace governed by a potential HTTP origin server listening for |
|  |  | SSL/TLS-secured connections on a given TCP port. The host and port |
|  |  | are determined in the same way as for the "http" scheme, except that |
|  |  | a default TCP port of 443 is assumed if the port subcomponent is |
|  |  | empty or not given. |
| Examples: |  | https-URI = "https:" "//" authority path-abempty [ "?" query ] |
| User-Agent: CERN-LineMode/2.15 libwww/2.17b3 |  | The primary difference between the "http" and "https" schemes is that |
| Server: Apache/0.8.4 |  | interaction with the latter is required to be secured for privacy |
|  |  | through the use of strong encryption. The URI cannot be sent in a |
|  |  | request until the connection is secure. Likewise, the default for |
|  |  | caching is that each response that would be considered "public" under |
|  |  | the "http" scheme is instead treated as "private" and thus not |
|  |  | eligible for shared caching. |
| Product tokens SHOULD be short and to the point. They MUST NOT be |  | The process for authoritative access to an "https" identified |
| used for advertising or other non-essential information. Although |  | resource is defined in [RFC2818]. |
| any token character MAY appear in a product-version, this token |  |  |
| SHOULD only be used for a version identifier (i.e., successive |  |  |
| versions of the same product SHOULD only differ in the product- |  |  |
| version portion of the product value). |  |  |
| 3.5. Quality Values |  | 2.6.3. http and https URI Normalization and Comparison |
| Both transfer codings (TE request header, Section 8.5) and content |  | Since the "http" and "https" schemes conform to the URI generic |
| negotiation (Section 4 of [Part3]) use short "floating point" numbers |  | syntax, such URIs are normalized and compared according to the |
| to indicate the relative importance ("weight") of various negotiable |  | algorithm defined in [RFC3986], Section 6, using the defaults |
| parameters. A weight is normalized to a real number in the range 0 |  | described above for each scheme. |
| through 1, where 0 is the minimum and 1 the maximum value. If a |  |  |
| parameter has a quality value of 0, then content with this parameter |  |  |
| is `not acceptable' for the client. HTTP/1.1 applications MUST NOT |  |  |
| generate more than three digits after the decimal point. User |  |  |
| configuration of these values SHOULD also be limited in this fashion. |  |  |
| qvalue = ( "0" [ "." 0*3DIGIT ] ) |  | If the port is equal to the default port for a scheme, the normal |
| / ( "1" [ "." 0*3("0") ] ) |  | form is to elide the port subcomponent. Likewise, an empty path |
|  |  | component is equivalent to an absolute path of "/", so the normal |
|  |  | form is to provide a path of "/" instead. The scheme and host are |
|  |  | case-insensitive and normally provided in lowercase; all other |
|  |  | components are compared in a case-sensitive manner. Characters other |
|  |  | than those in the "reserved" set are equivalent to their percent- |
|  |  | encoded octets (see [RFC3986], Section 2.1): the normal form is to |
|  |  | not encode them. |
| Note: "Quality values" is a misnomer, since these values merely |  | For example, the following three URIs are equivalent: |
| represent relative degradation in desired quality. |  |  |
| 4. HTTP Message |  | http://example.com:80/~smith/home.html |
|  |  | http://EXAMPLE.com/%7Esmith/home.html |
|  |  | http://EXAMPLE.com:/%7esmith/home.html |
| 4.1. Message Types |  | [[anchor1: [[This paragraph does not belong here. --Roy]]]] If 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. |
| HTTP messages consist of requests from client to server and responses |  | 3. HTTP Message |
| from server to client. |  |  |
| HTTP-message = Request / Response ; HTTP/1.1 messages |  | 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 |
|  |  | [RFC5322]: zero or more header fields (collectively referred to as |
|  |  | the "headers" or the "header section"), an empty line indicating the |
|  |  | end of the header section, and an optional message-body. |
| Request (Section 5) and Response (Section 6) messages use the generic |  | An HTTP message can either be a request from client to server or a |
| message format of [RFC5322] for transferring entities (the payload of |  | response from server to client. Syntactically, the two types of |
| the message). Both types of message consist of a start-line, zero or |  | message differ only in the start-line, which is either a Request-Line |
| more header fields (also known as "headers"), an empty line (i.e., a |  | (for requests) or a Status-Line (for responses), and in the algorithm |
| line with nothing preceding the CRLF) indicating the end of the |  | for determining the length of the message-body (Section 3.4). In |
| header fields, and possibly a message-body. |  | theory, a client could receive requests and a server could receive |
|  |  | responses, distinguishing them by their different start-line formats, |
|  |  | but in practice servers are implemented to only expect a request (a |
|  |  | response is interpreted as an unknown or invalid request method) and |
|  |  | clients are implemented to only expect a response. |
| generic-message = start-line |  | HTTP-message = start-line |
| *( message-header CRLF ) |  | *( header-field CRLF ) |
| CRLF |  | CRLF |
| [ message-body ] |  | [ message-body ] |
| start-line = Request-Line / Status-Line |  | start-line = Request-Line / Status-Line |
| In the interest of robustness, servers SHOULD ignore any empty |  |  |
| line(s) received where a Request-Line is expected. In other 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. |  |  |
| Certain buggy HTTP/1.0 client implementations generate extra CRLF's |  |  |
| after a POST request. To restate what is explicitly forbidden by the |  |  |
| BNF, an HTTP/1.1 client MUST NOT preface or follow a request with an |  |  |
| extra CRLF. |  |  |
| Whitespace (WSP) MUST NOT be sent between the start-line and the |  | Whitespace (WSP) MUST NOT be sent between the start-line and the |
| first header field. The presence of whitespace might be an attempt |  | first header field. The presence of whitespace might be an attempt |
| to trick a noncompliant implementation of HTTP into ignoring that |  | to trick a noncompliant implementation of HTTP into ignoring that |
| field or processing the next line as a new request, either of which |  | field or processing the next line as a new request, either of which |
| may result in security issues when implementations within the request |  | may result in security issues when implementations within the request |
| chain interpret the same message differently. HTTP/1.1 servers MUST |  | chain interpret the same message differently. HTTP/1.1 servers MUST |
| reject such a message with a 400 (Bad Request) response. |  | reject such a message with a 400 (Bad Request) response. |
| 4.2. Message Headers |  | 3.1. Message Parsing Robustness |
| HTTP header fields follow the same general format as Internet |  | In the interest of robustness, servers SHOULD ignore at least one |
| messages in Section 2.1 of [RFC5322]. Each header field consists of |  | empty line received where a Request-Line is expected. In other |
| a name followed by a colon (":"), optional whitespace, and the field |  | words, if the server is reading the protocol stream at the beginning |
| value. Field names are case-insensitive. |  | of a message and receives a CRLF first, it should ignore the CRLF. |
| message-header = field-name ":" OWS [ field-value ] OWS |  | Some old HTTP/1.0 client implementations generate an extra CRLF after |
|  |  | a POST request as a lame workaround for some early server |
|  |  | applications that failed to read message-body content that was not |
|  |  | terminated by a line-ending. An HTTP/1.1 client MUST NOT preface or |
|  |  | follow a request with an extra CRLF. If terminating the request |
|  |  | message-body with a line-ending is desired, then the client MUST |
|  |  | include the terminating CRLF octets as part of the message-body |
|  |  | length. |
|  |  | 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 |
|  |  | 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 |
|  |  | indicated, then it is read as a stream until an amount of OCTETs |
|  |  | equal to the message-length is read or the connection is closed. |
|  |  | 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 |
|  |  | HTTP as a stream of Unicode characters in a character encoding like |
|  |  | UTF-16 may introduce security flaws due to the differing ways that |
|  |  | such parsers interpret invalid characters. |
|  |  | 3.2. Header Fields |
|  |  | Each HTTP header field consists of a case-insensitive field name |
|  |  | followed by a colon (":"), optional whitespace, and the field value. |
|  |  | 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 ) |
| Historically, HTTP has allowed field-content with text in the ISO- |  | No whitespace is allowed between the header field name and colon. |
| 8859-1 [ISO-8859-1] character encoding (allowing other character sets |  |  |
| through use of [RFC2047] encoding). In practice, most HTTP header |  |  |
| field-values use only a subset of the US-ASCII charset [USASCII]. |  |  |
| Newly defined header fields SHOULD constrain their field-values to |  |  |
| US-ASCII characters. Recipients SHOULD treat other (obs-text) octets |  |  |
| in field-content as opaque data. |  |  |
| 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 Request) |  | whitespace MUST be rejected with a response code of 400 (Bad |
| and any such whitespace in a response message MUST be removed. |  | Request). A proxy MUST remove any such whitespace from a response |
|  |  | message before forwarding the message downstream. |
| The field value MAY be preceded by optional whitespace; a single SP |  | A field value MAY be preceded by optional whitespace (OWS); a single |
| 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 |  | character of the field value or after the last non-whitespace |
| character of the field-value is ignored and MAY be removed without |  | character of the field value is ignored and SHOULD be removed without |
| changing the meaning of the header field. |  | changing the meaning of the header field. |
|  |  | The order in which header fields with differing field names are |
|  |  | received is not significant. However, it is "good practice" to send |
|  |  | header fields that contain control data first, such as Host on |
|  |  | requests and Date on responses, so that implementations can decide |
|  |  | when not to handle a message as early as possible. A server MUST |
|  |  | wait until the entire header section is received before interpreting |
|  |  | a request message, since later header fields might include |
|  |  | conditionals, authentication credentials, or deliberately misleading |
|  |  | duplicate header fields that would impact request processing. |
|  |  | Multiple header fields with the same field name MUST NOT be sent in a |
|  |  | message unless the entire field value for that header field is |
|  |  | defined as a comma-separated list [i.e., #(values)]. Multiple header |
|  |  | fields with the same field name can be combined into one "field-name: |
|  |  | field-value" pair, without changing the semantics of the message, by |
|  |  | appending each subsequent field value to the combined field value in |
|  |  | order, separated by a comma. The order in which header fields with |
|  |  | the same field name are received is therefore significant to the |
|  |  | interpretation of the combined field value; a proxy MUST NOT change |
|  |  | the order of these field values when forwarding a message. |
|  |  | Note: the "Set-Cookie" header as implemented in practice (as |
|  |  | opposed to how it is specified in [RFC2109]) can occur multiple |
|  |  | times, but does not use the list syntax, and thus cannot be |
|  |  | combined into a single line. (See Appendix A.2.3 of [Kri2001] for |
|  |  | details.) Also note that the Set-Cookie2 header 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 character (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 9.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- |
|  |  | 8859-1 [ISO-8859-1] character encoding and supported other character |
|  |  | sets only through use of [RFC2047] encoding. In practice, most HTTP |
|  |  | header field values use only a subset of the US-ASCII character |
|  |  | encoding [USASCII]. Newly defined header fields SHOULD limit their |
|  |  | field values to US-ASCII characters. Recipients SHOULD treat other |
|  |  | (obs-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. |
| In all other fields, parentheses are considered part of the field |  |  |
| value. |  |  |
| comment = "(" *( ctext / quoted-pair / 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 order in which header fields with differing field names are |  | The backslash character ("\") can be used as a single-character |
| received is not significant. However, it is "good practice" to send |  | quoting mechanism within comment constructs: |
| general-header fields first, followed by request-header or response- |  |  |
| header fields, and ending with the entity-header fields. |  |  |
| Multiple message-header fields with the same field-name MAY be |  | quoted-cpair = "\" ( WSP / VCHAR / obs-text ) |
| present in a message if and only if the entire field-value for that |  |  |
| header field is defined as a comma-separated list [i.e., #(values)]. |  |  |
| It MUST be possible to combine the multiple header fields into one |  |  |
| "field-name: field-value" pair, without changing the semantics of the |  |  |
| message, by appending each subsequent field-value to the first, each |  |  |
| separated by a comma. The order in which header fields with the same |  |  |
| field-name are received is therefore significant to the |  |  |
| interpretation of the combined field value, and thus a proxy MUST NOT |  |  |
| change the order of these field values when a message is forwarded. |  |  |
| Note: the "Set-Cookie" header as implemented in practice (as |  | Producers SHOULD NOT escape characters that do not require escaping |
| opposed to how it is specified in [RFC2109]) can occur multiple |  | (i.e., other than the backslash character "\" and the parentheses "(" |
| times, but does not use the list syntax, and thus cannot be |  | and ")"). |
| combined into a single line. (See Appendix A.2.3 of [Kri2001] for |  |  |
| details.) Also note that the Set-Cookie2 header specified in |  |  |
| [RFC2965] does not share this problem. |  |  |
| 4.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 |
| entity-body associated with the request or response. The message- |  | entity-body associated with the request or response. The message- |
| body differs from the entity-body only when a transfer-coding has |  | body differs from the entity-body only when a transfer-coding has |
| been applied, as indicated by the Transfer-Encoding header field |  | been applied, as indicated by the Transfer-Encoding header field |
| (Section 8.7). |  | (Section 9.7). |
| message-body = entity-body |  | message-body = entity-body |
| / <entity-body encoded as per Transfer-Encoding> |  | / <entity-body encoded as per Transfer-Encoding> |
| Transfer-Encoding MUST be used to indicate any transfer-codings |  | Transfer-Encoding MUST be used to indicate any transfer-codings |
| applied by an application to ensure safe and proper transfer of the |  | applied by an application to ensure safe and proper transfer of the |
| message. Transfer-Encoding is a property of the message, not of the |  | message. Transfer-Encoding is a property of the message, not of the |
| entity, and thus MAY be added or removed by any application along the |  | entity, and thus MAY be added or removed by any application along the |
| request/response chain. (However, Section 3.3 places restrictions on |  | request/response chain. (However, Section 6.2 places restrictions on |
| when certain transfer-codings may be used.) |  | when certain transfer-codings may be used.) |
| 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 message-headers. When a request message contains both |  | the request's header fields. When a request message contains both a |
| a message-body of non-zero length and a method that does not define |  | message-body of non-zero length and a method that does not define any |
| any semantics for that request message-body, then an origin server |  | semantics for that request message-body, then an origin server SHOULD |
| SHOULD either ignore the message-body or respond with an appropriate |  | either ignore the message-body or respond with an appropriate error |
| error message (e.g., 413). A proxy or gateway, when presented the |  | message (e.g., 413). A proxy or gateway, when presented the same |
| same request, SHOULD either forward the request inbound with the |  | request, SHOULD either forward the request inbound with the message- |
| message-body or ignore the message-body when determining a response. |  | body or ignore the message-body when determining a response. |
| 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 6.1.1). All responses to the HEAD request |  | status code (Section 5.1.1). All responses to the HEAD request |
| method MUST NOT include a message-body, even though the presence of |  | method MUST NOT include a message-body, even though the presence of |
| entity-header fields might lead one to believe they do. All 1xx |  | entity-header fields might lead one to believe they do. All 1xx |
| (informational), 204 (No Content), and 304 (Not Modified) responses |  | (informational), 204 (No Content), and 304 (Not Modified) responses |
| MUST NOT include a message-body. All other responses do include a |  | MUST NOT include a message-body. All other responses do include a |
| message-body, although it MAY be of zero length. |  | message-body, although it MAY be of zero length. |
| 4.4. Message Length |  | 3.4. Message Length |
| The transfer-length of a message is the length of the message-body as |  | The transfer-length of a message is the length of the message-body as |
| it appears in the message; that is, after any transfer-codings have |  | it appears in the message; that is, after any transfer-codings have |
| been applied. When a message-body is included with a message, the |  | been applied. When a message-body is included with a message, the |
| transfer-length of that body is determined by one of the following |  | transfer-length of that body is determined by one of the following |
| (in order of precedence): |  | (in order of precedence): |
| 1. Any response message which "MUST NOT" include a message-body |  | 1. Any response message which "MUST NOT" include a message-body |
| (such as the 1xx, 204, and 304 responses and any response to a |  | (such as the 1xx, 204, and 304 responses and any response to a |
| HEAD request) is always terminated by the first empty line after |  | HEAD request) is always terminated by the first empty line after |
| the header fields, regardless of the entity-header fields present |  | the header fields, regardless of the entity-header fields present |
| in the message. |  | in the message. |
| 2. If a Transfer-Encoding header field (Section 8.7) is present and |  | 2. If a Transfer-Encoding header field (Section 9.7) is present and |
| the "chunked" transfer-coding (Section 3.3) is used, the |  | the "chunked" transfer-coding (Section 6.2) is used, the |
| transfer-length is defined by the use of this transfer-coding. |  | transfer-length is defined by the use of this transfer-coding. |
| If a Transfer-Encoding header field is present and the "chunked" |  | If a Transfer-Encoding header field is present and the "chunked" |
| transfer-coding is not present, the transfer-length is defined by |  | transfer-coding is not present, the transfer-length is defined by |
| the sender closing the connection. |  | the sender closing the connection. |
| 3. If a Content-Length header field (Section 8.2) is present, its |  | 3. If a Content-Length header field (Section 9.2) is present, its |
| value in OCTETs represents both the entity-length and the |  | value in OCTETs represents both the entity-length and the |
| transfer-length. The Content-Length header field MUST NOT be |  | transfer-length. The Content-Length header field MUST NOT be |
| sent if these two lengths are different (i.e., if a Transfer- |  | sent if these two lengths are different (i.e., if a Transfer- |
| Encoding header field is present). If a message is received with |  | Encoding header field is present). If a message is received with |
| both a Transfer-Encoding header field and a Content-Length header |  | both a Transfer-Encoding header field and a Content-Length header |
| field, the latter MUST be ignored. |  | field, the latter MUST be ignored. |
| 4. If the message uses the media type "multipart/byteranges", and |  | 4. If the message uses the media type "multipart/byteranges", and |
| the transfer-length is not otherwise specified, then this self- |  | the transfer-length is not otherwise specified, then this self- |
| delimiting media type defines the transfer-length. This media |  | delimiting media type defines the transfer-length. This media |
| skipping to change at page 26, line 44 |  | skipping to change at page 23, line 24 |
| For compatibility with HTTP/1.0 applications, HTTP/1.1 requests |  | For compatibility with HTTP/1.0 applications, HTTP/1.1 requests |
| containing a message-body MUST include a valid Content-Length header |  | containing a message-body MUST include a valid Content-Length header |
| field unless the server is known to be HTTP/1.1 compliant. If a |  | field unless the server is known to be HTTP/1.1 compliant. If a |
| request contains a message-body and a Content-Length is not given, |  | request contains a message-body and a Content-Length is not given, |
| the server SHOULD respond with 400 (Bad Request) if it cannot |  | the server SHOULD respond with 400 (Bad Request) if it cannot |
| determine the length of the message, or with 411 (Length Required) if |  | determine the length of the message, or with 411 (Length Required) if |
| it wishes to insist on receiving a valid Content-Length. |  | it wishes to insist on receiving a valid Content-Length. |
| All HTTP/1.1 applications that receive entities MUST accept the |  | All HTTP/1.1 applications that receive entities MUST accept the |
| "chunked" transfer-coding (Section 3.3), thus allowing this mechanism |  | "chunked" transfer-coding (Section 6.2), thus allowing this mechanism |
| to be used for messages when the message length cannot be determined |  | to be used for messages when the message length cannot be determined |
| in advance. |  | in advance. |
| Messages MUST NOT include both a Content-Length header field and a |  | Messages MUST NOT include both a Content-Length header field and a |
| transfer-coding. If the message does include a transfer-coding, the |  | transfer-coding. If the message does include a transfer-coding, the |
| Content-Length MUST be ignored. |  | Content-Length MUST be ignored. |
| When a Content-Length is given in a message where a message-body is |  | When a Content-Length is given in a message where a message-body is |
| allowed, its field value MUST exactly match the number of OCTETs in |  | allowed, its field value MUST exactly match the number of OCTETs in |
| the message-body. HTTP/1.1 user agents MUST notify the user when an |  | the message-body. HTTP/1.1 user agents MUST notify the user when an |
| invalid length is received and detected. |  | invalid length is received and detected. |
| 4.5. General Header Fields |  | 3.5. 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 |
| entity being transferred. These header fields apply only to the |  | entity being transferred. These header fields apply only to the |
| message being transmitted. |  | message being transmitted. |
| general-header = Cache-Control ; [Part6], Section 3.2 |  | general-header = Cache-Control ; [Part6], Section 3.2 |
| / Connection ; Section 8.1 |  | / Connection ; Section 9.1 |
| / Date ; Section 8.3 |  | / Date ; Section 9.3 |
| / Pragma ; [Part6], Section 3.4 |  | / Pragma ; [Part6], Section 3.4 |
| / Trailer ; Section 8.6 |  | / Trailer ; Section 9.6 |
| / Transfer-Encoding ; Section 8.7 |  | / Transfer-Encoding ; Section 9.7 |
| / Upgrade ; Section 8.8 |  | / Upgrade ; Section 9.8 |
| / Via ; Section 8.9 |  | / Via ; Section 9.9 |
| / Warning ; [Part6], Section 3.6 |  | / Warning ; [Part6], Section 3.6 |
| General-header field names can be extended reliably only in |  | General-header field names can be extended reliably only in |
| combination with a change in the protocol version. However, new or |  | combination with a change in the protocol version. However, new or |
| experimental header fields may be given the semantics of general |  | experimental header fields may be given the semantics of general |
| header fields if all parties in the communication recognize them to |  | header fields if all parties in the communication recognize them to |
| be general-header fields. Unrecognized header fields are treated as |  | be general-header fields. Unrecognized header fields are treated as |
| entity-header fields. |  | entity-header fields. |
| 5. Request |  | 4. Request |
| A request message from a client to a server includes, within the |  | A request message from a client to a server includes, within the |
| first line of that message, the method to be applied to the resource, |  | first line of that message, the method to be applied to the resource, |
| the identifier of the resource, and the protocol version in use. |  | the identifier of the resource, and the protocol version in use. |
| Request = Request-Line ; Section 5.1 |  | Request = Request-Line ; Section 4.1 |
| *(( general-header ; Section 4.5 |  | *(( general-header ; Section 3.5 |
| / request-header ; [Part2], Section 3 |  | / request-header ; [Part2], Section 3 |
| / entity-header ) CRLF ) ; [Part3], Section 3.1 |  | / entity-header ) CRLF ) ; [Part3], Section 3.1 |
| CRLF |  | CRLF |
| [ message-body ] ; Section 4.3 |  | [ message-body ] ; Section 3.3 |
| 5.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 the request- |
| target and the protocol version, and ending with CRLF. The elements |  | target and the protocol version, and ending with CRLF. The elements |
| are separated by SP characters. No CR or LF is allowed except in the |  | are separated by SP characters. No CR or LF is allowed except in the |
| final CRLF sequence. |  | final CRLF sequence. |
| Request-Line = Method SP request-target SP HTTP-Version CRLF |  | Request-Line = Method SP request-target SP HTTP-Version CRLF |
| 5.1.1. Method |  | 4.1.1. Method |
| The Method token indicates the method to be performed on the resource |  | The Method token indicates the method to be performed on the resource |
| identified by the request-target. The method is case-sensitive. |  | identified by the request-target. The method is case-sensitive. |
| Method = token |  | Method = token |
| 5.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 resource upon which to apply the |
| request. |  | request. |
| 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 |
| skipping to change at page 29, line 7 |  | skipping to change at page 25, line 32 |
| 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 |  | The authority form is only used by the CONNECT method (Section 7.9 of |
| [Part2]). |  | [Part2]). |
| The most common form of request-target is that used to identify a |  | The most common form of request-target is that used to identify a |
| resource on an origin server or gateway. In this case the absolute |  | resource on an origin server or gateway. In this case the absolute |
| path of the URI MUST be transmitted (see Section 2.1.1, path- |  | path of the URI MUST be transmitted (see Section 2.6.1, path- |
| absolute) as the request-target, and the network location of the URI |  | absolute) as the request-target, and the network location of the URI |
| (authority) MUST be transmitted in a Host header field. For example, |  | (authority) MUST be transmitted in a Host header field. For example, |
| a client wishing to retrieve the resource above directly from the |  | a client wishing to retrieve the resource above directly from the |
| origin server would create a TCP connection to port 80 of the host |  | origin server would create a TCP connection to port 80 of the host |
| "www.example.org" and send the lines: |  | "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 absolute |
| skipping to change at page 29, line 38 |  | skipping to change at page 26, line 17 |
| 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 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.1.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 transparent proxy MUST NOT rewrite the "path-absolute" part of the |
| received request-target when forwarding it to the next inbound |  | received request-target when forwarding it to the next inbound |
| server, except as noted above to replace a null path-absolute with |  | server, except as noted above to replace a null path-absolute with |
| "/". |  | "/". |
| Note: The "no rewrite" rule prevents the proxy from changing the |  | Note: The "no rewrite" rule prevents the proxy from changing the |
| skipping to change at page 30, line 15 |  | skipping to change at page 26, line 43 |
| HTTP does not place a pre-defined limit on the length of a request- |  | HTTP does not place a pre-defined limit on the length of a request- |
| target. A server MUST be prepared to receive URIs of unbounded |  | target. A server MUST be prepared to receive URIs of unbounded |
| length and respond with the 414 (URI Too Long) status if the received |  | length and respond with the 414 (URI Too Long) status if the received |
| request-target would be longer than the server wishes to handle (see |  | request-target would be longer than the server wishes to handle (see |
| Section 8.4.15 of [Part2]). |  | Section 8.4.15 of [Part2]). |
| Various ad-hoc limitations on request-target length are found in |  | Various ad-hoc limitations on request-target length are found in |
| practice. It is RECOMMENDED that all HTTP senders and recipients |  | practice. It is RECOMMENDED that all HTTP senders and recipients |
| support request-target lengths of 8000 or more OCTETs. |  | support request-target lengths of 8000 or more OCTETs. |
| 5.2. The Resource Identified by a Request |  | 4.2. The Resource Identified by a Request |
| The exact resource identified by an Internet request is determined by |  | The exact resource identified by an Internet request is determined by |
| examining both the request-target and the Host header field. |  | examining both the request-target and the Host header field. |
| An origin server that does not allow resources to differ by the |  | An origin server that does not allow resources to differ by the |
| requested host MAY ignore the Host header field value when |  | requested host MAY ignore the Host header field value when |
| determining the resource identified by an HTTP/1.1 request. (But see |  | determining the resource identified by an HTTP/1.1 request. (But see |
| Appendix B.1.1 for other requirements on Host support in HTTP/1.1.) |  | Appendix B.1.1 for other requirements on Host support in HTTP/1.1.) |
| An origin server that does differentiate resources based on the host |  | An origin server that does differentiate resources based on the host |
| requested (sometimes referred to as virtual hosts or vanity host |  | requested (sometimes referred to as virtual hosts or vanity host |
| names) MUST use the following rules for determining the requested |  | names) MUST use the following rules for determining the requested |
| resource on an HTTP/1.1 request: |  | resource on an HTTP/1.1 request: |
| 1. If request-target is an absolute-URI, the host is part of the |  | 1. If request-target is an absolute-URI, the host is part of the |
| request-target. Any Host header field value in the request MUST |  | request-target. Any Host header field value in the request MUST |
| be ignored. |  | be ignored. |
| 2. If the request-target is not an absolute-URI, and the request |  | 2. If the request-target is not an absolute-URI, and the request |
| skipping to change at page 30, line 47 |  | skipping to change at page 27, line 26 |
| 3. If the host as determined by rule 1 or 2 is not a valid host on |  | 3. If the host as determined by rule 1 or 2 is not a valid host on |
| the server, the response MUST be a 400 (Bad Request) error |  | the server, the response MUST be a 400 (Bad Request) error |
| message. |  | message. |
| Recipients of an HTTP/1.0 request that lacks a Host header field MAY |  | Recipients of an HTTP/1.0 request that lacks a Host header field MAY |
| attempt to use heuristics (e.g., examination of the URI path for |  | attempt to use heuristics (e.g., examination of the URI path for |
| something unique to a particular host) in order to determine what |  | something unique to a particular host) in order to determine what |
| exact resource is being requested. |  | exact resource is being requested. |
| 6. Response |  | 5. Response |
| After receiving and interpreting a request message, a server responds |  | After receiving and interpreting a request message, a server responds |
| with an HTTP response message. |  | with an HTTP response message. |
| Response = Status-Line ; Section 6.1 |  | Response = Status-Line ; Section 5.1 |
| *(( general-header ; Section 4.5 |  | *(( general-header ; Section 3.5 |
| / response-header ; [Part2], Section 5 |  | / response-header ; [Part2], Section 5 |
| / entity-header ) CRLF ) ; [Part3], Section 3.1 |  | / entity-header ) CRLF ) ; [Part3], Section 3.1 |
| CRLF |  | CRLF |
| [ message-body ] ; Section 4.3 |  | [ message-body ] ; Section 3.3 |
| 6.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 followed by a numeric status code and its |
| associated textual phrase, with each element separated by SP |  | associated textual phrase, with each element separated by SP |
| characters. No CR or LF is allowed except in the final CRLF |  | characters. No CR or LF is allowed except in the final CRLF |
| sequence. |  | sequence. |
| Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF |  | Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF |
| 6.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 |
| protocols that were more frequently used with interactive text |  | protocols that were more frequently used with interactive text |
| clients. A client SHOULD ignore the content of the Reason Phrase. |  | clients. A client SHOULD ignore the content of the Reason Phrase. |
| The first digit of the Status-Code defines the class of response. |  | The first digit of the Status-Code defines the class of response. |
| skipping to change at page 32, line 5 |  | skipping to change at page 28, line 36 |
| o 4xx: Client Error - The request contains bad syntax or cannot be |  | o 4xx: Client Error - The request contains bad syntax or cannot be |
| fulfilled |  | fulfilled |
| o 5xx: Server Error - The server failed to fulfill an apparently |  | o 5xx: Server Error - The server failed to fulfill an apparently |
| valid request |  | valid request |
| Status-Code = 3DIGIT |  | Status-Code = 3DIGIT |
| Reason-Phrase = *( WSP / VCHAR / obs-text ) |  | Reason-Phrase = *( WSP / VCHAR / obs-text ) |
|  |  | 6. Protocol Parameters |
|  |  | 6.1. Date/Time Formats: Full Date |
|  |  | HTTP applications have historically allowed three different formats |
|  |  | for the representation of date/time stamps: |
|  |  | Sun, 06 Nov 1994 08:49:37 GMT ; RFC 1123 |
|  |  | Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format |
|  |  | Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format |
|  |  | The first format is preferred as an Internet standard and represents |
|  |  | a fixed-length subset of that defined by [RFC1123]. The other |
|  |  | formats are described here only for compatibility with obsolete |
|  |  | implementations. HTTP/1.1 clients and servers that parse the date |
|  |  | value MUST accept all three formats (for compatibility with |
|  |  | HTTP/1.0), though they MUST only generate the RFC 1123 format for |
|  |  | representing HTTP-date values in header fields. See Appendix A for |
|  |  | further information. |
|  |  | All HTTP date/time stamps MUST be represented in Greenwich Mean Time |
|  |  | (GMT), without exception. For the purposes of HTTP, GMT is exactly |
|  |  | equal to UTC (Coordinated Universal Time). This is indicated in the |
|  |  | first two formats by the inclusion of "GMT" as the three-letter |
|  |  | abbreviation for time zone, and MUST be assumed when reading the |
|  |  | asctime format. HTTP-date is case sensitive and MUST NOT include |
|  |  | additional whitespace beyond that specifically included as SP in the |
|  |  | grammar. |
|  |  | HTTP-date = rfc1123-date / obs-date |
|  |  | Preferred format: |
|  |  | rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT |
|  |  | day-name = %x4D.6F.6E ; "Mon", case-sensitive |
|  |  | / %x54.75.65 ; "Tue", case-sensitive |
|  |  | / %x57.65.64 ; "Wed", case-sensitive |
|  |  | / %x54.68.75 ; "Thu", case-sensitive |
|  |  | / %x46.72.69 ; "Fri", case-sensitive |
|  |  | / %x53.61.74 ; "Sat", case-sensitive |
|  |  | / %x53.75.6E ; "Sun", case-sensitive |
|  |  | date1 = day SP month SP year |
|  |  | day = 2DIGIT |
|  |  | month = %x4A.61.6E ; "Jan", case-sensitive |
|  |  | / %x46.65.62 ; "Feb", case-sensitive |
|  |  | / %x4D.61.72 ; "Mar", case-sensitive |
|  |  | / %x41.70.72 ; "Apr", case-sensitive |
|  |  | / %x4D.61.79 ; "May", case-sensitive |
|  |  | / %x4A.75.6E ; "Jun", case-sensitive |
|  |  | / %x4A.75.6C ; "Jul", case-sensitive |
|  |  | / %x41.75.67 ; "Aug", case-sensitive |
|  |  | / %x53.65.70 ; "Sep", case-sensitive |
|  |  | / %x4F.63.74 ; "Oct", case-sensitive |
|  |  | / %x4E.6F.76 ; "Nov", case-sensitive |
|  |  | / %x44.65.63 ; "Dec", case-sensitive |
|  |  | year = 4DIGIT |
|  |  | GMT = %x47.4D.54 ; "GMT", case-sensitive |
|  |  | time-of-day = hour ":" minute ":" second |
|  |  | ; 00:00:00 - 23:59:59 |
|  |  | hour = 2DIGIT |
|  |  | minute = 2DIGIT |
|  |  | second = 2DIGIT |
|  |  | The semantics of day-name, day, month, year, and time-of-day are the |
|  |  | same as those defined for the RFC 5322 constructs with the |
|  |  | corresponding name ([RFC5322], Section 3.3). |
|  |  | Obsolete formats: |
|  |  | obs-date = rfc850-date / asctime-date |
|  |  | rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT |
|  |  | date2 = day "-" month "-" 2DIGIT |
|  |  | ; day-month-year (e.g., 02-Jun-82) |
|  |  | day-name-l = %x4D.6F.6E.64.61.79 ; "Monday", case-sensitive |
|  |  | / %x54.75.65.73.64.61.79 ; "Tuesday", case-sensitive |
|  |  | / %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive |
|  |  | / %x54.68.75.72.73.64.61.79 ; "Thursday", case-sensitive |
|  |  | / %x46.72.69.64.61.79 ; "Friday", case-sensitive |
|  |  | / %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive |
|  |  | / %x53.75.6E.64.61.79 ; "Sunday", case-sensitive |
|  |  | asctime-date = day-name SP date3 SP time-of-day SP year |
|  |  | date3 = month SP ( 2DIGIT / ( SP 1DIGIT )) |
|  |  | ; month day (e.g., Jun 2) |
|  |  | Note: Recipients of date values are encouraged to be robust in |
|  |  | accepting date values that may have been sent by non-HTTP |
|  |  | applications, as is sometimes the case when retrieving or posting |
|  |  | messages via proxies/gateways to SMTP or NNTP. |
|  |  | Note: HTTP requirements for the date/time stamp format apply only |
|  |  | to their usage within the protocol stream. Clients and servers |
|  |  | are not required to use these formats for user presentation, |
|  |  | request logging, etc. |
|  |  | 6.2. Transfer Codings |
|  |  | Transfer-coding values are used to indicate an encoding |
|  |  | transformation that has been, can be, or may need to be applied to an |
|  |  | entity-body in order to ensure "safe transport" through the network. |
|  |  | This differs from a content coding in that the transfer-coding is a |
|  |  | property of the message, not of the original entity. |
|  |  | transfer-coding = "chunked" ; Section 6.2.1 |
|  |  | / "compress" ; Section 6.2.2.1 |
|  |  | / "deflate" ; Section 6.2.2.2 |
|  |  | / "gzip" ; Section 6.2.2.3 |
|  |  | / transfer-extension |
|  |  | transfer-extension = token *( OWS ";" OWS transfer-parameter ) |
|  |  | Parameters are in the form of attribute/value pairs. |
|  |  | transfer-parameter = attribute BWS "=" BWS value |
|  |  | attribute = token |
|  |  | value = token / quoted-string |
|  |  | All transfer-coding values are case-insensitive. HTTP/1.1 uses |
|  |  | transfer-coding values in the TE header field (Section 9.5) and in |
|  |  | the Transfer-Encoding header field (Section 9.7). |
|  |  | Whenever a transfer-coding is applied to a message-body, the set of |
|  |  | transfer-codings MUST include "chunked", unless the message indicates |
|  |  | it is terminated by closing the connection. When the "chunked" |
|  |  | transfer-coding is used, it MUST be the last transfer-coding applied |
|  |  | to the message-body. The "chunked" transfer-coding MUST NOT be |
|  |  | applied more than once to a message-body. These rules allow the |
|  |  | recipient to determine the transfer-length of the message |
|  |  | (Section 3.4). |
|  |  | Transfer-codings are analogous to the Content-Transfer-Encoding |
|  |  | values of MIME, which were designed to enable safe transport of |
|  |  | binary data over a 7-bit transport service ([RFC2045], Section 6). |
|  |  | However, safe transport has a different focus for an 8bit-clean |
|  |  | transfer protocol. In HTTP, the only unsafe characteristic of |
|  |  | message-bodies is the difficulty in determining the exact body length |
|  |  | (Section 3.4), or the desire to encrypt data over a shared transport. |
|  |  | A server which receives an entity-body with a transfer-coding it does |
|  |  | not understand SHOULD return 501 (Not Implemented), and close the |
|  |  | connection. A server MUST NOT send transfer-codings to an HTTP/1.0 |
|  |  | client. |
|  |  | 6.2.1. Chunked Transfer Coding |
|  |  | The chunked encoding modifies the body of a message in order to |
|  |  | transfer it as a series of chunks, each with its own size indicator, |
|  |  | followed by an OPTIONAL trailer containing entity-header fields. |
|  |  | This allows dynamically produced content to be transferred along with |
|  |  | the information necessary for the recipient to verify that it has |
|  |  | received the full message. |
|  |  | Chunked-Body = *chunk |
|  |  | last-chunk |
|  |  | trailer-part |
|  |  | CRLF |
|  |  | chunk = chunk-size *WSP [ chunk-ext ] CRLF |
|  |  | chunk-data CRLF |
|  |  | chunk-size = 1*HEXDIG |
|  |  | last-chunk = 1*("0") *WSP [ chunk-ext ] CRLF |
|  |  | chunk-ext = *( ";" *WSP chunk-ext-name |
|  |  | [ "=" chunk-ext-val ] *WSP ) |
|  |  | chunk-ext-name = token |
|  |  | chunk-ext-val = token / quoted-str-nf |
|  |  | chunk-data = 1*OCTET ; a sequence of chunk-size octets |
|  |  | trailer-part = *( entity-header CRLF ) |
|  |  | quoted-str-nf = DQUOTE *( qdtext-nf / quoted-pair ) DQUOTE |
|  |  | ; like quoted-string, but disallowing line folding |
|  |  | qdtext-nf = WSP / %x21 / %x23-5B / %x5D-7E / obs-text |
|  |  | ; WSP / <VCHAR except DQUOTE and "\"> / obs-text |
|  |  | The chunk-size field is a string of hex digits indicating the size of |
|  |  | the chunk-data in octets. The chunked encoding is ended by any chunk |
|  |  | whose size is zero, followed by the trailer, which is terminated by |
|  |  | an empty line. |
|  |  | The trailer allows the sender to include additional HTTP header |
|  |  | fields at the end of the message. The Trailer header field can be |
|  |  | used to indicate which header fields are included in a trailer (see |
|  |  | Section 9.6). |
|  |  | A server using chunked transfer-coding in a response MUST NOT use the |
|  |  | trailer for any header fields unless at least one of the following is |
|  |  | true: |
|  |  | 1. the request included a TE header field that indicates "trailers" |
|  |  | is acceptable in the transfer-coding of the response, as |
|  |  | described in Section 9.5; or, |
|  |  | 2. the server is the origin server for the response, the trailer |
|  |  | fields consist entirely of optional metadata, and the recipient |
|  |  | could use the message (in a manner acceptable to the origin |
|  |  | server) without receiving this metadata. In other words, the |
|  |  | origin server is willing to accept the possibility that the |
|  |  | trailer fields might be silently discarded along the path to the |
|  |  | client. |
|  |  | This requirement prevents an interoperability failure when the |
|  |  | message is being received by an HTTP/1.1 (or later) proxy and |
|  |  | forwarded to an HTTP/1.0 recipient. It avoids a situation where |
|  |  | compliance with the protocol would have necessitated a possibly |
|  |  | infinite buffer on the proxy. |
|  |  | A process for decoding the "chunked" transfer-coding can be |
|  |  | represented in pseudo-code as: |
|  |  | length := 0 |
|  |  | read chunk-size, chunk-ext (if any) and CRLF |
|  |  | while (chunk-size > 0) { |
|  |  | read chunk-data and CRLF |
|  |  | append chunk-data to entity-body |
|  |  | length := length + chunk-size |
|  |  | read chunk-size and CRLF |
|  |  | } |
|  |  | read entity-header |
|  |  | while (entity-header not empty) { |
|  |  | append entity-header to existing header fields |
|  |  | read entity-header |
|  |  | } |
|  |  | Content-Length := length |
|  |  | Remove "chunked" from Transfer-Encoding |
|  |  | All HTTP/1.1 applications MUST be able to receive and decode the |
|  |  | "chunked" transfer-coding, and MUST ignore chunk-ext extensions they |
|  |  | do not understand. |
|  |  | 6.2.2. Compression Codings |
|  |  | The codings defined below can be used to compress the payload of a |
|  |  | message. |
|  |  | Note: Use of program names for the identification of encoding |
|  |  | formats is not desirable and is discouraged for future encodings. |
|  |  | Their use here is representative of historical practice, not good |
|  |  | design. |
|  |  | Note: For compatibility with previous implementations of HTTP, |
|  |  | applications SHOULD consider "x-gzip" and "x-compress" to be |
|  |  | equivalent to "gzip" and "compress" respectively. |
|  |  | 6.2.2.1. Compress Coding |
|  |  | The "compress" format is produced by the common UNIX file compression |
|  |  | program "compress". This format is an adaptive Lempel-Ziv-Welch |
|  |  | coding (LZW). |
|  |  | 6.2.2.2. Deflate Coding |
|  |  | The "zlib" format is defined in [RFC1950] in combination with the |
|  |  | "deflate" compression mechanism described in [RFC1951]. |
|  |  | 6.2.2.3. Gzip Coding |
|  |  | The "gzip" format is produced by the file compression program "gzip" |
|  |  | (GNU zip), as described in [RFC1952]. This format is a Lempel-Ziv |
|  |  | coding (LZ77) with a 32 bit CRC. |
|  |  | 6.2.3. Transfer Coding Registry |
|  |  | The HTTP Transfer Coding Registry defines the name space for the |
|  |  | transfer coding names. |
|  |  | Registrations MUST include the following fields: |
|  |  | o Name |
|  |  | o Description |
|  |  | o Pointer to specification text |
|  |  | Values to be added to this name space require expert review and a |
|  |  | specification (see "Expert Review" and "Specification Required" in |
|  |  | Section 4.1 of [RFC5226]), and MUST conform to the purpose of |
|  |  | transfer coding defined in this section. |
|  |  | The registry itself is maintained at |
|  |  | <http://www.iana.org/assignments/http-parameters>. |
|  |  | 6.3. Product Tokens |
|  |  | Product tokens are used to allow communicating applications to |
|  |  | identify themselves by software name and version. Most fields using |
|  |  | product tokens also allow sub-products which form a significant part |
|  |  | of the application to be listed, separated by whitespace. By |
|  |  | convention, the products are listed in order of their significance |
|  |  | for identifying the application. |
|  |  | product = token ["/" product-version] |
|  |  | product-version = token |
|  |  | Examples: |
|  |  | User-Agent: CERN-LineMode/2.15 libwww/2.17b3 |
|  |  | Server: Apache/0.8.4 |
|  |  | Product tokens SHOULD be short and to the point. They MUST NOT be |
|  |  | used for advertising or other non-essential information. Although |
|  |  | any token character MAY appear in a product-version, this token |
|  |  | SHOULD only be used for a version identifier (i.e., successive |
|  |  | versions of the same product SHOULD only differ in the product- |
|  |  | version portion of the product value). |
|  |  | 6.4. Quality Values |
|  |  | Both transfer codings (TE request header, Section 9.5) and content |
|  |  | negotiation (Section 4 of [Part3]) use short "floating point" numbers |
|  |  | to indicate the relative importance ("weight") of various 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 value. If a |
|  |  | parameter has a quality value of 0, then content with this parameter |
|  |  | is `not acceptable' for the client. HTTP/1.1 applications MUST NOT |
|  |  | generate more than three digits after the decimal point. User |
|  |  | configuration of these values SHOULD also be limited in this fashion. |
|  |  | qvalue = ( "0" [ "." 0*3DIGIT ] ) |
|  |  | / ( "1" [ "." 0*3("0") ] ) |
|  |  | Note: "Quality values" is a misnomer, since these values merely |
|  |  | 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 to fetch each URL, increasing the load on HTTP servers |
| and causing congestion on the Internet. The use of inline images and |  | and causing congestion on the Internet. The use of inline images and |
| other associated data often require a client to make multiple |  | other associated data often require a client to make multiple |
| skipping to change at page 33, line 10 |  | skipping to change at page 37, line 36 |
| 7.1.2. Overall Operation |  | 7.1.2. Overall Operation |
| A significant difference between HTTP/1.1 and earlier versions of |  | A significant difference between HTTP/1.1 and earlier versions of |
| HTTP is that persistent connections are the default behavior of any |  | HTTP is that persistent connections are the default behavior of any |
| HTTP connection. That is, unless otherwise indicated, the client |  | HTTP connection. That is, unless otherwise indicated, the client |
| SHOULD assume that the server will maintain a persistent connection, |  | SHOULD assume that the server will maintain a persistent connection, |
| even after error responses from the server. |  | even after error responses from the server. |
| Persistent connections provide a mechanism by which a client and a |  | Persistent connections provide a mechanism by which a client and a |
| server can signal the close of a TCP connection. This signaling |  | server can signal the close of a TCP connection. This signaling |
| takes place using the Connection header field (Section 8.1). Once a |  | takes place using the Connection header field (Section 9.1). Once a |
| close has been signaled, the client MUST NOT send any more requests |  | close has been signaled, the client MUST NOT send any more requests |
| on that connection. |  | on that connection. |
| 7.1.2.1. Negotiation |  | 7.1.2.1. Negotiation |
| An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to |  | An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to |
| maintain a persistent connection unless a Connection header including |  | maintain a persistent connection unless a Connection header including |
| the connection-token "close" was sent in the request. If the server |  | the connection-token "close" was sent in the request. If the server |
| chooses to close the connection immediately after sending the |  | chooses to close the connection immediately after sending the |
| response, it SHOULD send a Connection header including the |  | response, it SHOULD send a Connection header including the |
| skipping to change at page 33, line 41 |  | skipping to change at page 38, line 19 |
| Connection header, that request becomes the last one for the |  | Connection header, 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.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 4.4. |  | of the connection), as described in Section 3.4. |
| 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 |
| response). A server MUST send its responses to those requests in the |  | response). A server MUST send its responses to those requests in the |
| 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 |
| skipping to change at page 34, line 21 |  | skipping to change at page 38, line 47 |
| non-idempotent sequences of methods (see Section 7.1.2 of [Part2]). |  | non-idempotent sequences of methods (see Section 7.1.2 of [Part2]). |
| Otherwise, a premature termination of the transport connection could |  | Otherwise, a premature termination of the transport connection could |
| lead to indeterminate results. A client wishing to send a non- |  | lead to indeterminate results. A client wishing to send a non- |
| idempotent request SHOULD wait to send that request until it has |  | idempotent request SHOULD wait to send that request until it has |
| received the response status for the previous request. |  | received the response status 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 8.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 |
| transport link. |  | transport link. |
| A proxy server MUST NOT establish a HTTP/1.1 persistent connection |  | A proxy server MUST NOT establish a HTTP/1.1 persistent connection |
| with an HTTP/1.0 client (but see Section 19.7.1 of [RFC2068] for |  | with an HTTP/1.0 client (but see Section 19.7.1 of [RFC2068] for |
| information and discussion of the problems with the Keep-Alive header |  | information and discussion of the problems with the Keep-Alive header |
| implemented by many HTTP/1.0 clients). |  | implemented by many HTTP/1.0 clients). |
| skipping to change at page 35, line 25 |  | skipping to change at page 39, line 51 |
| Confirmation by user-agent software with semantic understanding of |  | Confirmation by user-agent software with semantic understanding of |
| the application MAY substitute for user confirmation. The automatic |  | the application MAY substitute for user confirmation. The automatic |
| retry SHOULD NOT be repeated if the second sequence of requests |  | retry SHOULD NOT be repeated if the second sequence of requests |
| fails. |  | fails. |
| 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 that use persistent connections SHOULD limit the number of |  | Clients (including proxies) SHOULD limit the number of simultaneous |
| simultaneous connections that they maintain to a given server. A |  | connections that they maintain to a given server (including proxies). |
| single-user client SHOULD NOT maintain more than 2 connections with |  |  |
| any server or proxy. A proxy SHOULD use up to 2*N connections to |  | Previous revisions of HTTP gave a specific number of connections as a |
| another server or proxy, where N is the number of simultaneously |  | ceiling, but this was found to be impractical for many applications. |
| active users. These guidelines are intended to improve HTTP response |  | As a result, this specification does not mandate a particular maximum |
| times and avoid congestion. |  | number of connections, but instead encourages clients to be |
|  |  | conservative when opening multiple connections. |
|  |  | In particular, while using multiple connections avoids the "head-of- |
|  |  | line blocking" problem (whereby a request that takes significant |
|  |  | server-side processing and/or has a large payload can block |
|  |  | subsequent requests on the same connection), each connection used |
|  |  | consumes server resources (sometimes significantly), and furthermore |
|  |  | using multiple connections can cause undesirable side effects in |
|  |  | congested networks. |
|  |  | Note that servers might reject traffic that they deem abusive, |
|  |  | including an excessive number of connections from a client. |
| 7.2. Message Transmission Requirements |  | 7.2. Message Transmission Requirements |
| 7.2.1. Persistent Connections and Flow Control |  | 7.2.1. Persistent Connections and Flow Control |
| HTTP/1.1 servers SHOULD maintain persistent connections and use TCP's |  | HTTP/1.1 servers SHOULD maintain persistent connections and use TCP's |
| flow control mechanisms to resolve temporary overloads, rather than |  | flow control mechanisms to resolve temporary overloads, rather than |
| terminating connections with the expectation that clients will retry. |  | terminating connections with the expectation that clients will retry. |
| The latter technique can exacerbate network congestion. |  | The latter technique can exacerbate network congestion. |
| 7.2.2. Monitoring Connections for Error Status Messages |  | 7.2.2. Monitoring Connections for Error Status Messages |
| An HTTP/1.1 (or later) client sending a message-body SHOULD monitor |  | An HTTP/1.1 (or later) client sending a message-body SHOULD monitor |
| the network connection for an error status while it is transmitting |  | the network connection for an error status while it is transmitting |
| the request. If the client sees an error status, it SHOULD |  | the request. If the client sees an error status, it SHOULD |
| immediately cease transmitting the body. If the body is being sent |  | immediately cease transmitting the body. If the body is being sent |
| using a "chunked" encoding (Section 3.3), a zero length chunk and |  | using a "chunked" encoding (Section 6.2), a zero length chunk and |
| empty trailer MAY be used to prematurely mark the end of the message. |  | empty trailer MAY be used to prematurely mark the end of the message. |
| If the body was preceded by a Content-Length header, the client MUST |  | If the body was preceded by a Content-Length header, the client MUST |
| close the connection. |  | close the connection. |
| 7.2.3. Use of the 100 (Continue) Status |  | 7.2.3. Use of the 100 (Continue) Status |
| The purpose of the 100 (Continue) status (see Section 8.1.1 of |  | The purpose of the 100 (Continue) status (see Section 8.1.1 of |
| [Part2]) is to allow a client that is sending a request message with |  | [Part2]) is to allow a client that is sending a request message with |
| a request body to determine if the origin server is willing to accept |  | a request body to determine if the origin server is willing to accept |
| the request (based on the request headers) before the client sends |  | the request (based on the request headers) before the client sends |
| skipping to change at page 38, line 46 |  | skipping to change at page 43, line 35 |
| received, or the user becomes impatient and terminates the retry |  | received, or the user becomes impatient and terminates the retry |
| process. |  | process. |
| If at any point an error status is received, the client |  | If at any point an error status is received, the client |
| o SHOULD NOT continue and |  | o SHOULD NOT continue and |
| o SHOULD close the connection if it has not completed sending the |  | o SHOULD close the connection if it has not completed sending the |
| request message. |  | request message. |
| 8. Header Field Definitions |  | 8. Miscellaneous notes that may disappear |
|  |  | 8.1. Scheme aliases considered harmful |
|  |  | [[anchor2: TBS: describe why aliases like webcal are harmful.]] |
|  |  | 8.2. Use of HTTP for proxy communication |
|  |  | [[anchor3: TBD: Configured to use HTTP to proxy HTTP or other |
|  |  | protocols.]] |
|  |  | 8.3. Interception of HTTP for access control |
|  |  | [[anchor4: TBD: Interception of HTTP traffic for initiating access |
|  |  | control.]] |
|  |  | 8.4. Use of HTTP by other protocols |
|  |  | [[anchor5: TBD: Profiles of HTTP defined by other protocol. |
|  |  | Extensions of HTTP like WebDAV.]] |
|  |  | 8.5. Use of HTTP by media type specification |
|  |  | [[anchor6: TBD: Instructions on composing HTTP requests via hypertext |
|  |  | formats.]] |
|  |  | 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/1.1 header |
| fields related to message framing and transport protocols. |  | fields related to message framing and transport protocols. |
| For entity-header fields, both sender and recipient refer to either |  | For entity-header fields, both sender and recipient refer to either |
| the client or the server, depending on who sends and who receives the |  | the client or the server, depending on who sends and who receives the |
| entity. |  | entity. |
| 8.1. Connection |  | 9.1. Connection |
| The general-header field "Connection" allows the sender to specify |  | The "Connection" general-header field allows the sender to specify |
| options that are desired for that particular connection and MUST NOT |  | options that are desired for that particular connection and MUST NOT |
| be communicated by proxies over further connections. |  | be communicated by proxies over further connections. |
| The Connection header's value has the following grammar: |  | The Connection header'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 |  | HTTP/1.1 proxies MUST parse the Connection header field before a |
| skipping to change at page 40, line 7 |  | skipping to change at page 45, line 24 |
| 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 |  | A system receiving an HTTP/1.0 (or lower-version) message that |
| includes a Connection header MUST, for each connection-token in this |  | includes a Connection header MUST, for each connection-token in this |
| field, remove and ignore any header field(s) from the message with |  | field, remove and ignore any header field(s) from the message with |
| the same name as the connection-token. This protects against |  | the same name as the connection-token. This protects against |
| mistaken forwarding of such header fields by pre-HTTP/1.1 proxies. |  | mistaken forwarding of such header fields by pre-HTTP/1.1 proxies. |
| See Appendix B.2. |  | See Appendix B.2. |
| 8.2. Content-Length |  | 9.2. Content-Length |
| The entity-header field "Content-Length" indicates the size of the |  | The "Content-Length" entity-header field indicates the size of the |
| entity-body, in number of OCTETs, sent to the recipient or, in the |  | entity-body, in number of OCTETs. In the case of responses to the |
| case of the HEAD method, the size of the entity-body that would have |  | HEAD method, it indicates the size of the entity-body that would have |
| been sent had the request been a GET. |  | been sent had the request been a GET. |
| 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 |
| Applications SHOULD use this field to indicate the transfer-length of |  | Applications SHOULD use this field to indicate the transfer-length of |
| the message-body, unless this is prohibited by the rules in |  | the message-body, unless this is prohibited by the rules in |
| Section 4.4. |  | Section 3.4. |
| 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. |
| Section 4.4 describes how to determine the length of a message-body |  | Section 3.4 describes how to determine the length of a message-body |
| if a Content-Length is not given. |  | if a Content-Length is not given. |
| Note that the meaning of this field is significantly different from |  | Note that the meaning of this field is significantly different from |
| the corresponding definition in MIME, where it is an optional field |  | the corresponding definition in MIME, where it is an optional field |
| used within the "message/external-body" content-type. In HTTP, it |  | used within the "message/external-body" content-type. In HTTP, it |
| SHOULD be sent whenever the message's length can be determined prior |  | SHOULD be sent whenever the message's length can be determined prior |
| to being transferred, unless this is prohibited by the rules in |  | to being transferred, unless this is prohibited by the rules in |
| Section 4.4. |  | Section 3.4. |
| 8.3. Date |  | 9.3. Date |
| The general-header field "Date" represents the date and time at which |  | The "Date" general-header field represents the date and time at which |
| the message was originated, having the same semantics as orig-date in |  | the message was originated, having the same semantics as orig-date in |
| Section 3.6.1 of [RFC5322]. The field value is an HTTP-date, as |  | Section 3.6.1 of [RFC5322]. The field value is an HTTP-date, as |
| described in Section 3.2; it MUST be sent in rfc1123-date format. |  | described in Section 6.1; it MUST be 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 41, line 15 |  | skipping to change at page 46, line 32 |
| 1. If the response status code is 100 (Continue) or 101 (Switching |  | 1. If the response status code is 100 (Continue) or 101 (Switching |
| Protocols), the response MAY include a Date header field, at the |  | Protocols), the response MAY include a Date header field, at the |
| server's option. |  | server's option. |
| 2. If the response status code conveys a server error, e.g. 500 |  | 2. If the response status code conveys a server error, e.g. 500 |
| (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 8.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. An HTTP |  | recipient or gatewayed via a protocol which requires a Date. An HTTP |
| implementation without a clock MUST NOT cache responses without |  | implementation without a clock MUST NOT cache responses without |
| revalidating them on every use. An HTTP cache, especially a shared |  | revalidating them on every use. An HTTP cache, especially a shared |
| cache, SHOULD use a mechanism, such as NTP [RFC1305], to synchronize |  | cache, SHOULD use a mechanism, such as NTP [RFC1305], to synchronize |
| its clock with a reliable external standard. |  | its clock with a reliable external standard. |
| skipping to change at page 41, line 40 |  | skipping to change at page 47, line 8 |
| The HTTP-date sent in a Date header SHOULD NOT represent a date and |  | The HTTP-date sent in a Date header SHOULD NOT represent a date and |
| time subsequent to the generation of the message. It SHOULD |  | 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 |
| generating a reasonably accurate date and time. In theory, the date |  | generating a reasonably accurate date and time. In theory, the date |
| ought to represent the moment just before the entity is generated. |  | ought to represent the moment just before the entity is generated. |
| In practice, the date can be generated at any time during the message |  | In practice, the date can be generated at any time during the message |
| origination without affecting its semantic value. |  | origination without affecting its semantic value. |
| 8.3.1. Clockless Origin Server Operation |  | 9.3.1. Clockless Origin Server Operation |
| Some origin server implementations might not have a clock available. |  | Some origin server implementations might not have a clock available. |
| 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). |
| 8.4. Host |  | 9.4. Host |
| The request-header field "Host" specifies the Internet host and port |  | The "Host" request-header field specifies the Internet host and port |
| number of the resource being requested, as obtained from the original |  | number of the resource being requested, allowing the origin server or |
| URI given by the user or referring resource (generally an http URI, |  | gateway to differentiate between internally-ambiguous URLs, such as |
| as described in Section 2.1.1). The Host field value MUST represent |  | the root "/" URL of a server for multiple host names on a single IP |
| the naming authority of the origin server or gateway given by the |  | address. |
| original URL. This allows the origin server or gateway to |  |  |
| differentiate between internally-ambiguous URLs, such as the root "/" |  | The Host field value MUST represent the naming authority of the |
| URL of a server for multiple host names on a single IP address. |  | 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.1.1 |  | Host-v = uri-host [ ":" port ] ; Section 2.6.1 |
| A "host" without any trailing port information implies the default |  | A "host" without any trailing port information implies the default |
| port for the service requested (e.g., "80" for an HTTP URL). For |  | port for the service requested (e.g., "80" for an HTTP URL). For |
| example, a request on the origin server for |  | example, a request on the origin server for |
| <http://www.example.org/pub/WWW/> would properly include: |  | <http://www.example.org/pub/WWW/> would properly include: |
| 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 |  | A client MUST include a Host header field in all HTTP/1.1 request |
| messages. If the requested URI does not include an Internet host |  | messages. If the requested URI does not include an Internet host |
| name for the service being requested, then the Host header field MUST |  | name for the service being requested, then the Host header field MUST |
| be given with an empty value. An HTTP/1.1 proxy MUST ensure that any |  | be given with an empty value. An HTTP/1.1 proxy MUST ensure that any |
| request message it forwards does contain an appropriate Host header |  | request message it forwards does contain an appropriate Host header |
| field that identifies the service being requested by the proxy. All |  | field that identifies the service being requested by the proxy. All |
| Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request) |  | Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request) |
| status code to any HTTP/1.1 request message which lacks a Host header |  | status code to any HTTP/1.1 request message which lacks a Host header |
| field. |  | field. |
| See Sections 5.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. |
| 8.5. TE |  | 9.5. TE |
|  |  | The "TE" request-header field indicates what extension transfer- |
|  |  | codings it is willing to accept in the response, and whether or not |
|  |  | it is willing to accept trailer fields in a chunked transfer-coding. |
| The request-header field "TE" indicates what extension transfer- |  |  |
| codings it is willing to accept in the response and whether or not it |  |  |
| is willing to accept trailer fields in a chunked transfer-coding. |  |  |
| Its value may consist of the keyword "trailers" and/or a comma- |  | Its value may consist of the keyword "trailers" and/or a comma- |
| separated list of extension transfer-coding names with optional |  | separated list of extension transfer-coding names with optional |
| accept parameters (as described in Section 3.3). |  | accept 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 [ "=" ( token / quoted-string ) ] |  | te-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ] |
| The presence of the keyword "trailers" indicates that the client is |  | The presence of the keyword "trailers" indicates that the client is |
| willing to accept trailer fields in a chunked transfer-coding, as |  | willing to accept trailer fields in a chunked transfer-coding, as |
| defined in Section 3.3.1. This keyword is reserved for use with |  | defined in Section 6.2.1. This keyword is reserved for use with |
| transfer-coding values even though it does not itself represent a |  | transfer-coding values even though it does not itself represent a |
| transfer-coding. |  | transfer-coding. |
| Examples of its use are: |  | Examples of its use are: |
| TE: deflate |  | TE: deflate |
| TE: |  | TE: |
| TE: trailers, deflate;q=0.5 |  | TE: trailers, deflate;q=0.5 |
| The TE header field only applies to the immediate connection. |  | The TE header field only applies to the immediate connection. |
| Therefore, the keyword MUST be supplied within a Connection header |  | Therefore, the keyword MUST be supplied within a Connection header |
| field (Section 8.1) whenever TE is present in an HTTP/1.1 message. |  | field (Section 9.1) whenever TE is present in an HTTP/1.1 message. |
| A server tests whether a transfer-coding is acceptable, according to |  | A server tests whether a transfer-coding is acceptable, according to |
| a TE field, using these rules: |  | a TE field, using these rules: |
| 1. The "chunked" transfer-coding is always acceptable. If the |  | 1. The "chunked" transfer-coding is always acceptable. If the |
| keyword "trailers" is listed, the client indicates that it is |  | keyword "trailers" is listed, the client indicates that it is |
| willing to accept trailer fields in the chunked response on |  | willing to accept trailer fields in the chunked response on |
| behalf of itself and any downstream clients. The implication is |  | behalf of itself and any downstream clients. The implication is |
| that, if given, the client is stating that either all downstream |  | that, if given, the client is stating that either all downstream |
| clients are willing to accept trailer fields in the forwarded |  | clients are willing to accept trailer fields in the forwarded |
| response, or that it will attempt to buffer the response on |  | response, or that it will attempt to buffer the response on |
| behalf of downstream recipients. |  | behalf of downstream recipients. |
| Note: HTTP/1.1 does not define any means to limit the size of a |  | Note: HTTP/1.1 does not define any means to limit the size of a |
| chunked response such that a client can be assured of buffering |  | chunked response such that a client can be assured of buffering |
| the entire response. |  | the entire response. |
| 2. If the transfer-coding being tested is one of the transfer- |  | 2. If the transfer-coding being tested is one of the transfer- |
| codings listed in the TE field, then it is acceptable unless it |  | codings listed in the TE field, then it is acceptable unless it |
| is accompanied by a qvalue of 0. (As defined in Section 3.5, a |  | is accompanied by a qvalue of 0. (As defined in Section 6.4, a |
| qvalue of 0 means "not acceptable.") |  | qvalue of 0 means "not acceptable.") |
| 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. |
| 8.6. Trailer |  | 9.6. Trailer |
| The general field "Trailer" indicates that the given set of header |  | The "Trailer" general-header field indicates that the given set of |
| fields is present in the trailer of a message encoded with chunked |  | header fields is present in the trailer of a message encoded with |
| transfer-coding. |  | chunked 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 |
| any header fields. See Section 3.3.1 for restrictions on the use of |  | any header fields. See Section 6.2.1 for restrictions on the use of |
| trailer fields in a "chunked" transfer-coding. |  | trailer fields in a "chunked" transfer-coding. |
| Message header fields listed in the Trailer header field MUST NOT |  | Message header fields listed in the Trailer header field MUST NOT |
| 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 |
| 8.7. Transfer-Encoding |  | 9.7. Transfer-Encoding |
| The general-header "Transfer-Encoding" field indicates what (if any) |  | The "Transfer-Encoding" general-header field indicates what transfer- |
| type of transformation has been applied to the message body in order |  | codings (if any) have been applied to the message body. It differs |
| to safely transfer it between the sender and the recipient. This |  | from Content-Encoding (Section 2.2 of [Part3]) in that transfer- |
| differs from the content-coding in that the transfer-coding is a |  | codings are a property of the message (and therefore are removed by |
| property of the message, not of the entity. |  | 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 3.3. 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 an entity, the transfer- |  | If multiple encodings have been applied to an entity, the transfer- |
| codings MUST be listed in the order in which they were applied. |  | codings MUST be listed in the order in which they were applied. |
| Additional information about the encoding parameters MAY be provided |  | Additional information about the encoding parameters MAY be provided |
| by other entity-header fields not defined by this specification. |  | by other entity-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. |  | Encoding header. |
| 8.8. Upgrade |  | 9.8. Upgrade |
| The general-header "Upgrade" allows the client to specify what |  | The "Upgrade" general-header field allows the client to specify what |
| additional communication protocols it supports and would like to use |  | additional communication protocols it would like to use, if the |
| if the server finds it appropriate to switch protocols. The server |  | server chooses to switch protocols. Additionally, the server MUST |
| MUST use the Upgrade header field within a 101 (Switching Protocols) |  | use the Upgrade header field within a 101 (Switching Protocols) |
| response to indicate which protocol(s) are being switched. |  | 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. |
| skipping to change at page 45, line 46 |  | skipping to change at page 51, line 12 |
| protocols upon the existing transport-layer connection. Upgrade |  | protocols upon the existing transport-layer connection. Upgrade |
| cannot be used to insist on a protocol change; its acceptance and use |  | cannot be used to insist on a protocol change; its acceptance and use |
| by the server is optional. The capabilities and nature of the |  | by the server is optional. The capabilities and nature of the |
| application-layer communication after the protocol change is entirely |  | application-layer communication after the protocol change is entirely |
| dependent upon the new protocol chosen, although the first action |  | dependent upon the new protocol chosen, although the first action |
| after changing the protocol MUST be a response to the initial HTTP |  | after changing the protocol MUST be a response to the initial HTTP |
| request containing the Upgrade header field. |  | request containing the Upgrade header field. |
| The Upgrade header field only applies to the immediate connection. |  | The Upgrade header field only applies to the immediate connection. |
| Therefore, the upgrade keyword MUST be supplied within a Connection |  | Therefore, the upgrade keyword MUST be supplied within a Connection |
| header field (Section 8.1) whenever Upgrade is present in an HTTP/1.1 |  | header field (Section 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 301, 302, 303, or 305 redirection response. |
| 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 3.1 and future updates to this |  | version rules of Section 2.5 and future updates to this |
| specification. Any token can be used as a protocol name; however, it |  | specification. Additional tokens can be registered with IANA using |
| will only be useful if both the client and server associate the name |  | the registration procedure defined below. |
| with the same protocol. |  |  |
| 8.9. Via |  | 9.8.1. Upgrade Token Registry |
| The general-header field "Via" MUST be used by gateways and proxies |  | The HTTP Upgrade Token Registry defines the name space for product |
|  |  | tokens used to identify protocols in the Upgrade header field. Each |
|  |  | registered token should be associated with one or a set of |
|  |  | specifications, and with contact information. |
|  |  | Registrations should be allowed on a First Come First Served basis as |
|  |  | described in Section 4.1 of [RFC5226]. These specifications need not |
|  |  | be IETF documents or be subject to IESG review, but should obey the |
|  |  | following rules: |
|  |  | 1. A token, once registered, stays registered forever. |
|  |  | 2. The registration MUST name a responsible party for the |
|  |  | registration. |
|  |  | 3. The registration MUST name a point of contact. |
|  |  | 4. The registration MAY name the documentation required for the |
|  |  | token. |
|  |  | 5. The responsible party MAY change the registration at any time. |
|  |  | The IANA will keep a record of all such changes, and make them |
|  |  | available upon request. |
|  |  | 6. The responsible party for the first registration of a "product" |
|  |  | token MUST approve later registrations of a "version" token |
|  |  | together with that "product" token before they can be registered. |
|  |  | 7. If absolutely required, the IESG MAY reassign the responsibility |
|  |  | for a token. This will normally only be used in the case when a |
|  |  | responsible party cannot be contacted. |
|  |  | It is not required that specifications for upgrade tokens be made |
|  |  | publicly available, but the contact information for the registration |
|  |  | should be. |
|  |  | 9.9. Via |
|  |  | The "Via" general-header field MUST be used by gateways and proxies |
| to indicate the intermediate protocols and recipients between the |  | to indicate the intermediate protocols and recipients between the |
| user agent and the server on requests, and between the origin server |  | user agent and the server on requests, and between the origin server |
| and the client on responses. It is analogous to the "Received" field |  | and the client on responses. It is analogous to the "Received" field |
| defined in Section 3.6.7 of [RFC5322] and is intended to be used for |  | defined in 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 |
| skipping to change at page 47, line 40 |  | skipping to change at page 53, line 45 |
| 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 |  | Applications SHOULD NOT combine multiple entries unless they are all |
| under the same organizational control and the hosts have already been |  | under the same organizational control and the hosts have already been |
| replaced by pseudonyms. Applications MUST NOT combine entries which |  | replaced by pseudonyms. Applications MUST NOT combine entries which |
| have different received-protocol values. |  | have different received-protocol values. |
| 9. IANA Considerations |  | 10. IANA Considerations |
| 9.1. Message Header Registration |  | 10.1. Message Header Registration |
| The Message Header Registry located at <http://www.iana.org/ |  | The Message Header Registry located at <http://www.iana.org/ |
| assignments/message-headers/message-header-index.html> should be |  | assignments/message-headers/message-header-index.html> should be |
| updated with the permanent registrations below (see [RFC3864]): |  | updated with the permanent registrations below (see [RFC3864]): |
| +-------------------+----------+----------+-------------+ |  | +-------------------+----------+----------+-------------+ |
| | Header Field Name | Protocol | Status | Reference | |  | | Header Field Name | Protocol | Status | Reference | |
| +-------------------+----------+----------+-------------+ |  | +-------------------+----------+----------+-------------+ |
| | Connection | http | standard | Section 8.1 | |  | | Connection | http | standard | Section 9.1 | |
| | Content-Length | http | standard | Section 8.2 | |  | | Content-Length | http | standard | Section 9.2 | |
| | Date | http | standard | Section 8.3 | |  | | Date | http | standard | Section 9.3 | |
| | Host | http | standard | Section 8.4 | |  | | Host | http | standard | Section 9.4 | |
| | TE | http | standard | Section 8.5 | |  | | TE | http | standard | Section 9.5 | |
| | Trailer | http | standard | Section 8.6 | |  | | Trailer | http | standard | Section 9.6 | |
| | Transfer-Encoding | http | standard | Section 8.7 | |  | | Transfer-Encoding | http | standard | Section 9.7 | |
| | Upgrade | http | standard | Section 8.8 | |  | | Upgrade | http | standard | Section 9.8 | |
| | Via | http | standard | Section 8.9 | |  | | Via | http | standard | Section 9.9 | |
| +-------------------+----------+----------+-------------+ |  | +-------------------+----------+----------+-------------+ |
| The change controller is: "IETF (iesg@ietf.org) - Internet |  | The change controller is: "IETF (iesg@ietf.org) - Internet |
| Engineering Task Force". |  | Engineering Task Force". |
| 9.2. URI Scheme Registration |  | 10.2. URI Scheme Registration |
| The entry for the "http" URI Scheme in the registry located at |  | The entries for the "http" and "https" URI Schemes in the registry |
| <http://www.iana.org/assignments/uri-schemes.html> should be updated |  | located at <http://www.iana.org/assignments/uri-schemes.html> should |
| to point to Section 2.1.1 of this document (see [RFC4395]). |  | be updated to point to Sections 2.6.1 and 2.6.2 of this document (see |
|  |  | [RFC4395]). |
| 9.3. Internet Media Type Registrations |  | 10.3. Internet Media Type Registrations |
| This document serves as the specification for the Internet media |  | This document serves as the specification for the Internet media |
| types "message/http" and "application/http". The following is to be |  | types "message/http" and "application/http". The following is to be |
| registered with IANA (see [RFC4288]). |  | registered with IANA (see [RFC4288]). |
| 9.3.1. Internet Media Type message/http |  | 10.3.1. Internet Media Type message/http |
| The message/http type can be used to enclose a single HTTP request or |  | The message/http type can be used to enclose a single HTTP request or |
| response message, provided that it obeys the MIME restrictions for |  | response message, provided that it obeys the MIME restrictions for |
| all "message" types regarding line length and encodings. |  | all "message" types regarding line length and encodings. |
| Type name: message |  | Type name: message |
| Subtype name: http |  | Subtype name: http |
| Required parameters: none |  | Required parameters: none |
| skipping to change at page 49, line 16 |  | skipping to change at page 55, line 19 |
| present, the type can be determined from the first line of the |  | present, the type can be determined from the first line of the |
| body. |  | body. |
| Encoding considerations: only "7bit", "8bit", or "binary" are |  | Encoding considerations: only "7bit", "8bit", or "binary" are |
| permitted |  | permitted |
| Security considerations: none |  | Security considerations: none |
| Interoperability considerations: none |  | Interoperability considerations: none |
| Published specification: This specification (see Section 9.3.1). |  | Published specification: This specification (see Section 10.3.1). |
| Applications that use this media type: |  | Applications that use this media type: |
| Additional information: |  | Additional information: |
| Magic number(s): none |  | Magic number(s): none |
| File extension(s): none |  | File extension(s): none |
| Macintosh file type code(s): none |  | Macintosh file type code(s): none |
| Person and email address to contact for further information: See |  | Person and email address to contact for further information: See |
| Authors Section. |  | Authors Section. |
| Intended usage: COMMON |  | Intended usage: COMMON |
| Restrictions on usage: none |  | Restrictions on usage: none |
| Author/Change controller: IESG |  | Author/Change controller: IESG |
| 9.3.2. Internet Media Type application/http |  | 10.3.2. Internet Media Type application/http |
| The application/http type can be used to enclose a pipeline of one or |  | The application/http type can be used to enclose a pipeline of one or |
| more HTTP request or response messages (not intermixed). |  | more HTTP request or response messages (not intermixed). |
| Type name: application |  | Type name: application |
| Subtype name: http |  | Subtype name: http |
| Required parameters: none |  | Required parameters: none |
| Optional parameters: version, msgtype |  | Optional parameters: version, msgtype |
| version: The HTTP-Version number of the enclosed messages (e.g., |  | version: The HTTP-Version number of the enclosed messages (e.g., |
| "1.1"). If not present, the version can be determined from the |  | "1.1"). If not present, the version can be determined from the |
| first line of the body. |  | first line of the body. |
| msgtype: The message type -- "request" or "response". If not |  | msgtype: The message type -- "request" or "response". If not |
| present, the type can be determined from the first line of the |  | present, the type can be determined from the first line of the |
| body. |  | body. |
| Encoding considerations: HTTP messages enclosed by this type are in |  | Encoding considerations: HTTP messages enclosed by this type are in |
| "binary" format; use of an appropriate Content-Transfer-Encoding |  | "binary" format; use of an appropriate Content-Transfer-Encoding |
| skipping to change at page 50, line 20 |  | skipping to change at page 56, line 24 |
| body. |  | body. |
| Encoding considerations: HTTP messages enclosed by this type are in |  | Encoding considerations: HTTP messages enclosed by this type are in |
| "binary" format; use of an appropriate Content-Transfer-Encoding |  | "binary" format; use of an appropriate Content-Transfer-Encoding |
| is required when transmitted via E-mail. |  | is required when transmitted via E-mail. |
| Security considerations: none |  | Security considerations: none |
| Interoperability considerations: none |  | Interoperability considerations: none |
| Published specification: This specification (see Section 9.3.2). |  | Published specification: This specification (see Section 10.3.2). |
| Applications that use this media type: |  | Applications that use this media type: |
| Additional information: |  | Additional information: |
| Magic number(s): none |  | Magic number(s): none |
| File extension(s): none |  | File extension(s): none |
| Macintosh file type code(s): none |  | Macintosh file type code(s): none |
| Person and email address to contact for further information: See |  | Person and email address to contact for further information: See |
| Authors Section. |  | Authors Section. |
| Intended usage: COMMON |  | Intended usage: COMMON |
| Restrictions on usage: none |  | Restrictions on usage: none |
| Author/Change controller: IESG |  | Author/Change controller: IESG |
| 10. Security Considerations |  | 10.4. Transfer Coding Registry |
|  |  | The registration procedure for HTTP Transfer Codings is now defined |
|  |  | by Section 6.2.3 of this document. |
|  |  | The HTTP Transfer Codings Registry located at |
|  |  | <http://www.iana.org/assignments/http-parameters> should be updated |
|  |  | with the registrations below: |
|  |  | +----------+--------------------------------------+-----------------+ |
|  |  | | Name | Description | Reference | |
|  |  | +----------+--------------------------------------+-----------------+ |
|  |  | | chunked | Transfer in a series of chunks | Section 6.2.1 | |
|  |  | | compress | UNIX "compress" program method | Section 6.2.2.1 | |
|  |  | | deflate | "zlib" format [RFC1950] with | Section 6.2.2.2 | |
|  |  | | | "deflate" compression | | |
|  |  | | gzip | Same as GNU zip [RFC1952] | Section 6.2.2.3 | |
|  |  | +----------+--------------------------------------+-----------------+ |
|  |  | 10.5. Upgrade Token Registration |
|  |  | The registration procedure for HTTP Upgrade Tokens -- previously |
|  |  | defined in Section 7.2 of [RFC2817] -- is now defined by |
|  |  | Section 9.8.1 of this document. |
|  |  | The HTTP Status Code Registry located at |
|  |  | <http://www.iana.org/assignments/http-upgrade-tokens/> should be |
|  |  | updated with the registration below: |
|  |  | +-------+---------------------------+-------------------------------+ |
|  |  | | Value | Description | Reference | |
|  |  | +-------+---------------------------+-------------------------------+ |
|  |  | | HTTP | Hypertext Transfer | Section 2.5 of this | |
|  |  | | | Protocol | specification | |
|  |  | +-------+---------------------------+-------------------------------+ |
|  |  | 11. Security Considerations |
| This section is meant to inform application developers, information |  | This section is meant to inform application developers, information |
| providers, and users of the security limitations in HTTP/1.1 as |  | providers, and users of the security limitations in HTTP/1.1 as |
| described by this document. The discussion does not include |  | described by this document. The discussion does not include |
| definitive solutions to the problems revealed, though it does make |  | definitive solutions to the problems revealed, though it does make |
| some suggestions for reducing security risks. |  | some suggestions for reducing security risks. |
| 10.1. Personal Information |  | 11.1. Personal Information |
| HTTP clients are often privy to large amounts of personal information |  | HTTP clients are often privy to large amounts of personal information |
| (e.g. the user's name, location, mail address, passwords, encryption |  | (e.g. the user's name, location, mail address, passwords, encryption |
| keys, etc.), and SHOULD be very careful to prevent unintentional |  | keys, etc.), and SHOULD be very careful to prevent unintentional |
| leakage of this information. We very strongly recommend that a |  | leakage of this information. We very strongly recommend that a |
| convenient interface be provided for the user to control |  | convenient interface be provided for the user to control |
| dissemination of such information, and that designers and |  | dissemination of such information, and that designers and |
| implementors be particularly careful in this area. History shows |  | implementors be particularly careful in this area. History shows |
| that errors in this area often create serious security and/or privacy |  | that errors in this area often create serious security and/or privacy |
| problems and generate highly adverse publicity for the implementor's |  | problems and generate highly adverse publicity for the implementor's |
| company. |  | company. |
| 10.2. Abuse of Server Log Information |  | 11.2. Abuse of Server Log Information |
| A server is in the position to save personal data about a user's |  | A server is in the position to save personal data about a user's |
| requests which might identify their reading patterns or subjects of |  | requests which might identify their reading patterns or subjects of |
| interest. This information is clearly confidential in nature and its |  | interest. This information is clearly confidential in nature and its |
| handling can be constrained by law in certain countries. People |  | handling can be constrained by law in certain countries. People |
| using HTTP to provide data are responsible for ensuring that such |  | using HTTP to provide data are responsible for ensuring that such |
| material is not distributed without the permission of any individuals |  | material is not distributed without the permission of any individuals |
| that are identifiable by the published results. |  | that are identifiable by the published results. |
| 10.3. Attacks Based On File and Path Names |  | 11.3. Attacks Based On File and Path Names |
| Implementations of HTTP origin servers SHOULD be careful to restrict |  | Implementations of HTTP origin servers SHOULD be careful to restrict |
| the documents returned by HTTP requests to be only those that were |  | the documents returned by HTTP requests to be only those that were |
| intended by the server administrators. If an HTTP server translates |  | intended by the server administrators. If an HTTP server translates |
| HTTP URIs directly into file system calls, the server MUST take |  | HTTP URIs directly into file system calls, the server MUST take |
| special care not to serve files that were not intended to be |  | special care not to serve files that were not intended to be |
| delivered to HTTP clients. For example, UNIX, Microsoft Windows, and |  | delivered to HTTP clients. For example, UNIX, Microsoft Windows, and |
| other operating systems use ".." as a path component to indicate a |  | other operating systems use ".." as a path component to indicate a |
| directory level above the current one. On such a system, an HTTP |  | directory level above the current one. On such a system, an HTTP |
| server MUST disallow any such construct in the request-target if it |  | server MUST disallow any such construct in the request-target if it |
| would otherwise allow access to a resource outside those intended to |  | would otherwise allow access to a resource outside those intended to |
| be accessible via the HTTP server. Similarly, files intended for |  | be accessible via the HTTP server. Similarly, files intended for |
| reference only internally to the server (such as access control |  | reference only internally to the server (such as access control |
| files, configuration files, and script code) MUST be protected from |  | files, configuration files, and script code) MUST be protected from |
| inappropriate retrieval, since they might contain sensitive |  | inappropriate retrieval, since they might contain sensitive |
| information. Experience has shown that minor bugs in such HTTP |  | information. Experience has shown that minor bugs in such HTTP |
| server implementations have turned into security risks. |  | server implementations have turned into security risks. |
| 10.4. DNS Spoofing |  | 11.4. DNS Spoofing |
| Clients using HTTP rely heavily on the Domain Name Service, and are |  | Clients using HTTP rely heavily on the Domain Name Service, and are |
| thus generally prone to security attacks based on the deliberate mis- |  | thus generally prone to security attacks based on the deliberate mis- |
| association of IP addresses and DNS names. Clients need to be |  | association of IP addresses and DNS names. Clients need to be |
| cautious in assuming the continuing validity of an IP number/DNS name |  | cautious in assuming the continuing validity of an IP number/DNS name |
| association. |  | association. |
| In particular, HTTP clients SHOULD rely on their name resolver for |  | In particular, HTTP clients SHOULD rely on their name resolver for |
| confirmation of an IP number/DNS name association, rather than |  | confirmation of an IP number/DNS name association, rather than |
| caching the result of previous host name lookups. Many platforms |  | caching the result of previous host name lookups. Many platforms |
| skipping to change at page 52, line 30 |  | skipping to change at page 59, line 20 |
| a previously-accessed server's IP address changes. As network |  | a previously-accessed server's IP address changes. As network |
| renumbering is expected to become increasingly common [RFC1900], the |  | renumbering is expected to become increasingly common [RFC1900], the |
| possibility of this form of attack will grow. Observing this |  | possibility of this form of attack will grow. Observing this |
| requirement thus reduces this potential security vulnerability. |  | requirement thus reduces this potential security vulnerability. |
| This requirement also improves the load-balancing behavior of clients |  | This requirement also improves the load-balancing behavior of clients |
| for replicated servers using the same DNS name and reduces the |  | for replicated servers using the same DNS name and reduces the |
| likelihood of a user's experiencing failure in accessing sites which |  | likelihood of a user's experiencing failure in accessing sites which |
| use that strategy. |  | use that strategy. |
| 10.5. Proxies and Caching |  | 11.5. Proxies and Caching |
| By their very nature, HTTP proxies are men-in-the-middle, and |  | By their very nature, HTTP proxies are men-in-the-middle, and |
| represent an opportunity for man-in-the-middle attacks. Compromise |  | represent an opportunity for man-in-the-middle attacks. Compromise |
| of the systems on which the proxies run can result in serious |  | of the systems on which the proxies run can result in serious |
| security and privacy problems. Proxies have access to security- |  | security and privacy problems. Proxies have access to security- |
| related information, personal information about individual users and |  | related information, personal information about individual users and |
| organizations, and proprietary information belonging to users and |  | organizations, and proprietary information belonging to users and |
| content providers. A compromised proxy, or a proxy implemented or |  | content providers. A compromised proxy, or a proxy implemented or |
| configured without regard to security and privacy considerations, |  | configured without regard to security and privacy considerations, |
| might be used in the commission of a wide range of potential attacks. |  | might be used in the commission of a wide range of potential attacks. |
| Proxy operators should protect the systems on which proxies run as |  | Proxy operators should protect the systems on which proxies run as |
| they would protect any system that contains or transports sensitive |  | they would protect any system that contains or transports sensitive |
| information. In particular, log information gathered at proxies |  | information. In particular, log information gathered at proxies |
| often contains highly sensitive personal information, and/or |  | often contains highly sensitive personal information, and/or |
| information about organizations. Log information should be carefully |  | information about organizations. Log information should be carefully |
| guarded, and appropriate guidelines for use developed and followed. |  | guarded, and appropriate guidelines for use developed and followed. |
| (Section 10.2). |  | (Section 11.2). |
| Proxy implementors should consider the privacy and security |  | Proxy implementors should consider the privacy and security |
| implications of their design and coding decisions, and of the |  | implications of their design and coding decisions, and of the |
| configuration options they provide to proxy operators (especially the |  | configuration options they provide to proxy operators (especially the |
| default configuration). |  | default configuration). |
| Users of a proxy need to be aware that they are no trustworthier than |  | Users of a proxy need to be aware that they are no trustworthier than |
| the people who run the proxy; HTTP itself cannot solve this problem. |  | the people who run the proxy; HTTP itself cannot solve this problem. |
| The judicious use of cryptography, when appropriate, may suffice to |  | The judicious use of cryptography, when appropriate, may suffice to |
| protect against a broad range of security and privacy attacks. Such |  | protect against a broad range of security and privacy attacks. Such |
| cryptography is beyond the scope of the HTTP/1.1 specification. |  | cryptography is beyond the scope of the HTTP/1.1 specification. |
| 10.6. 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. |
| 11. 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 |
| skipping to change at page 54, line 24 |  | skipping to change at page 61, line 14 |
| discovery of many of the problems that this document attempts to |  | discovery of many of the problems that this document attempts to |
| rectify. |  | rectify. |
| This specification makes heavy use of the augmented BNF and generic |  | This specification makes heavy use of the augmented BNF and generic |
| 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. |
| 12. References |  | 13. References |
| 12.1. Normative References |  | 13.1. Normative References |
| [ISO-8859-1] |  | [ISO-8859-1] |
| International Organization for Standardization, |  | International Organization for Standardization, |
| "Information technology -- 8-bit single-byte coded graphic |  | "Information technology -- 8-bit single-byte coded graphic |
| character sets -- Part 1: Latin alphabet No. 1", ISO/ |  | character sets -- Part 1: Latin alphabet No. 1", ISO/ |
| IEC 8859-1:1998, 1998. |  | IEC 8859-1:1998, 1998. |
| [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| and J. Reschke, Ed., "HTTP/1.1, part 2: Message |  | and J. Reschke, Ed., "HTTP/1.1, part 2: Message |
| Semantics", draft-ietf-httpbis-p2-semantics-07 (work in |  | Semantics", draft-ietf-httpbis-p2-semantics-08 (work in |
| progress), July 2009. |  | progress), October 2009. |
| [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload |  | and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload |
| and Content Negotiation", draft-ietf-httpbis-p3-payload-07 |  | and Content Negotiation", draft-ietf-httpbis-p3-payload-08 |
| (work in progress), July 2009. |  | (work in progress), October 2009. |
| [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and |  | and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and |
| Partial Responses", draft-ietf-httpbis-p5-range-07 (work |  | Partial Responses", draft-ietf-httpbis-p5-range-08 (work |
| in progress), July 2009. |  | in progress), October 2009. |
| [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part |  | Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part |
| 6: Caching", draft-ietf-httpbis-p6-cache-07 (work in |  | 6: Caching", draft-ietf-httpbis-p6-cache-08 (work in |
| progress), July 2009. |  | progress), October 2009. |
|  |  | [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format |
|  |  | Specification version 3.3", RFC 1950, May 1996. |
|  |  | RFC 1950 is an Informational RFC, thus it may be less |
|  |  | stable than this specification. On the other hand, this |
|  |  | downward reference was present since the publication of |
|  |  | RFC 2068 in 1997 ([RFC2068]), therefore it is unlikely to |
|  |  | cause problems in practice. See also [BCP97]. |
|  |  | [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification |
|  |  | version 1.3", RFC 1951, May 1996. |
|  |  | RFC 1951 is an Informational RFC, thus it may be less |
|  |  | stable than this specification. On the other hand, this |
|  |  | downward reference was present since the publication of |
|  |  | RFC 2068 in 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 G. |
|  |  | Randers-Pehrson, "GZIP file format specification version |
|  |  | 4.3", RFC 1952, May 1996. |
|  |  | RFC 1952 is an Informational RFC, thus it may be less |
|  |  | stable than this specification. On the other hand, this |
|  |  | downward reference was present since the publication of |
|  |  | RFC 2068 in 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 RFCs to Indicate |
| Requirement Levels", BCP 14, RFC 2119, March 1997. |  | Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform |  | [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform |
| Resource Identifier (URI): Generic Syntax", RFC 3986, |  | Resource Identifier (URI): Generic Syntax", RFC 3986, |
| STD 66, January 2005. |  | STD 66, January 2005. |
| [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax |  | [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax |
| Specifications: ABNF", STD 68, RFC 5234, January 2008. |  | Specifications: ABNF", STD 68, RFC 5234, January 2008. |
| [USASCII] American National Standards Institute, "Coded Character |  | [USASCII] American National Standards Institute, "Coded Character |
| Set -- 7-bit American Standard Code for Information |  | Set -- 7-bit American Standard Code for Information |
| Interchange", ANSI X3.4, 1986. |  | Interchange", ANSI X3.4, 1986. |
| 12.2. Informative References |  | 13.2. Informative References |
|  |  | [BCP97] Klensin, J. and S. Hartman, "Handling Normative References |
|  |  | to Standards-Track Documents", BCP 97, RFC 4897, |
|  |  | June 2007. |
| [Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and |  | [Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and |
| Politics", ACM Transactions on Internet Technology Vol. 1, |  | Politics", ACM Transactions on Internet Technology Vol. 1, |
| #2, November 2001, <http://arxiv.org/abs/cs.SE/0105018>. |  | #2, November 2001, <http://arxiv.org/abs/cs.SE/0105018>. |
| [Nie1997] Nielsen, H., Gettys, J., Prud'hommeaux, E., Lie, H., and |  | [Nie1997] Nielsen, H., Gettys, J., Prud'hommeaux, E., Lie, H., and |
| C. Lilley, "Network Performance Effects of HTTP/1.1, CSS1, |  | C. Lilley, "Network Performance Effects of HTTP/1.1, CSS1, |
| and PNG", ACM Proceedings of the ACM SIGCOMM '97 |  | and PNG", ACM Proceedings of the ACM SIGCOMM '97 |
| conference on Applications, technologies, architectures, |  | conference on Applications, technologies, architectures, |
| and protocols for computer communication SIGCOMM '97, |  | and protocols for computer communication SIGCOMM '97, |
| skipping to change at page 56, line 31 |  | skipping to change at page 64, line 5 |
| Mechanism", RFC 2109, February 1997. |  | Mechanism", RFC 2109, February 1997. |
| [RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use |  | [RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use |
| and Interpretation of HTTP Version Numbers", RFC 2145, |  | and Interpretation of HTTP Version Numbers", RFC 2145, |
| May 1997. |  | May 1997. |
| [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., |  | [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext |  | Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext |
| Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. |  | Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. |
|  |  | [RFC2817] Khare, R. and S. Lawrence, "Upgrading 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 State Management |
| Mechanism", RFC 2965, October 2000. |  | Mechanism", RFC 2965, October 2000. |
| [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration |  | [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration |
| Procedures for Message Header Fields", BCP 90, RFC 3864, |  | Procedures for Message Header Fields", BCP 90, RFC 3864, |
| September 2004. |  | September 2004. |
| [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and |  | [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and |
| Registration Procedures", BCP 13, RFC 4288, December 2005. |  | Registration Procedures", BCP 13, RFC 4288, December 2005. |
| [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and |  | [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and |
| Registration Procedures for New URI Schemes", BCP 115, |  | Registration Procedures for New URI Schemes", BCP 115, |
| RFC 4395, February 2006. |  | RFC 4395, February 2006. |
|  |  | [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an |
|  |  | IANA Considerations Section in RFCs", BCP 26, RFC 5226, |
|  |  | May 2008. |
| [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, |  | [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, |
| October 2008. |  | October 2008. |
| [Spe] Spero, S., "Analysis of HTTP Performance Problems", |  | [Spe] Spero, S., "Analysis of HTTP Performance Problems", |
| <http://sunsite.unc.edu/mdma-release/http-prob.html>. |  | <http://sunsite.unc.edu/mdma-release/http-prob.html>. |
| [Tou1998] Touch, J., Heidemann, J., and K. Obraczka, "Analysis of |  | [Tou1998] Touch, J., Heidemann, J., and K. Obraczka, "Analysis of |
| HTTP Performance", ISI Research Report ISI/RR-98-463, |  | HTTP Performance", ISI Research Report ISI/RR-98-463, |
| Aug 1998, <http://www.isi.edu/touch/pubs/http-perf96/>. |  | Aug 1998, <http://www.isi.edu/touch/pubs/http-perf96/>. |
| skipping to change at page 57, line 24 |  | skipping to change at page 65, line 5 |
| 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 |  | Clients SHOULD be tolerant in parsing the Status-Line and servers |
| tolerant when parsing the Request-Line. In particular, they SHOULD |  | tolerant when parsing the Request-Line. In particular, they SHOULD |
| accept any amount of WSP characters between fields, even though only |  | accept any amount of WSP characters between fields, even though only |
| a single SP is required. |  | a single SP is required. |
| The line terminator for message-header fields is the sequence CRLF. |  | The line terminator for header fields is the sequence CRLF. However, |
| However, we recommend that applications, when parsing such headers, |  | we recommend that applications, when parsing such headers, recognize |
| recognize a single LF as a line terminator and ignore the leading CR. |  | a single LF as a line terminator and ignore the leading CR. |
| The character set of an entity-body SHOULD be labeled as the lowest |  | The character set of an entity-body SHOULD be labeled as the lowest |
| common denominator of the character codes used within that body, with |  | common denominator of the character codes used within that body, with |
| the exception that not labeling the entity is preferred over labeling |  | the exception that not labeling the entity is preferred over labeling |
| the entity with the labels US-ASCII or ISO-8859-1. See [Part3]. |  | the entity with the 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 |
| skipping to change at page 58, line 30 |  | skipping to change at page 66, line 11 |
| 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. It is |
| worth noting that, at the time of composing this specification |  | worth noting that, at the time of composing this specification, we |
| (1996), we would expect commercial HTTP/1.1 servers to: |  | would expect general-purpose HTTP/1.1 servers to: |
| o recognize the format of the Request-Line for HTTP/0.9, 1.0, and |  |  |
| 1.1 requests; |  |  |
| o understand any valid request in the format of HTTP/0.9, 1.0, or |  | o understand any valid request in the format of HTTP/1.0 and 1.1; |
| 1.1; |  |  |
| o respond appropriately with a message in the same major version |  | o respond appropriately with a message in the same major version |
| used by the client. |  | used by the client. |
| And we would expect HTTP/1.1 clients to: |  | And we would expect HTTP/1.1 clients to: |
| o recognize the format of the Status-Line for HTTP/1.0 and 1.1 |  | o understand any valid response in the format of HTTP/1.0 or 1.1. |
| responses; |  |  |
| o understand any valid response in the format of HTTP/0.9, 1.0, or |  |  |
| 1.1. |  |  |
| For most implementations of HTTP/1.0, each connection is established |  | For most implementations of HTTP/1.0, each connection is established |
| by the client prior to the request and closed by the server after |  | by the client prior to the request and closed by the server after |
| sending the response. Some implementations implement the Keep-Alive |  | sending the response. Some implementations implement the Keep-Alive |
| version of persistent connections described in Section 19.7.1 of |  | version of persistent connections described in Section 19.7.1 of |
| [RFC2068]. |  | [RFC2068]. |
| 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. Changes to Simplify Multi-homed Web Servers and Conserve IP |
| Addresses |  | Addresses |
| The requirements that clients and servers support the Host request- |  | The requirements that clients and servers support the Host request- |
| header, report an error if the Host request-header (Section 8.4) is |  | header, report an error if the Host request-header (Section 9.4) is |
| missing from an HTTP/1.1 request, and accept absolute URIs |  | missing from an HTTP/1.1 request, and accept absolute URIs |
| (Section 5.1.2) are among the most important changes defined by this |  | (Section 4.1.2) are among the most important changes defined by this |
| specification. |  | specification. |
| 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 changes outlined above will |
| allow the Internet, once older HTTP clients are no longer common, to |  | allow the Internet, once older HTTP clients are no longer common, to |
| support multiple Web sites from a single IP address, greatly |  | support multiple Web sites from a single IP address, greatly |
| simplifying large operational Web servers, where allocation of many |  | simplifying large operational Web servers, where allocation of many |
| IP addresses to a single host has created serious problems. The |  | IP addresses to a single host has created serious problems. The |
| skipping to change at page 60, line 20 |  | skipping to change at page 67, line 42 |
| result in a hung HTTP/1.0 proxy waiting for the close on the |  | result in a hung HTTP/1.0 proxy waiting for the close on the |
| response. The result is that HTTP/1.0 clients must be prevented from |  | response. The result is that HTTP/1.0 clients must be prevented from |
| using Keep-Alive when talking to proxies. |  | using Keep-Alive when 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 8.1. |  | declaring non-persistence. See Section 9.1. |
| The original HTTP/1.0 form of persistent connections (the Connection: |  | The original HTTP/1.0 form of persistent connections (the Connection: |
| Keep-Alive and Keep-Alive header) is documented in Section 19.7.1 of |  | Keep-Alive and Keep-Alive header) is documented in Section 19.7.1 of |
| [RFC2068]. |  | [RFC2068]. |
| B.3. Changes from RFC 2068 |  | B.3. Changes from RFC 2068 |
| This specification has been carefully audited to correct and |  | This specification has been carefully audited to correct and |
| disambiguate key word usage; RFC 2068 had many problems in respect to |  | disambiguate key word usage; RFC 2068 had many problems in respect to |
| the conventions laid out in [RFC2119]. |  | the conventions laid out in [RFC2119]. |
| Transfer-coding and message lengths all interact in ways that |  | Transfer-coding and message lengths all interact in ways that |
| required fixing exactly when chunked encoding is used (to allow for |  | required fixing exactly when chunked encoding is used (to allow for |
| transfer encoding that may not be self delimiting); it was important |  | transfer encoding that may not be self delimiting); it was important |
| to straighten out exactly how message lengths are computed. |  | to straighten out exactly how message lengths are computed. |
| (Sections 3.3, 4.4, 8.2, see also [Part3], [Part5] and [Part6]) |  | (Sections 6.2, 3.4, 9.2, see also [Part3], [Part5] and [Part6]) |
| The use and interpretation of HTTP version numbers has been clarified |  | The use and interpretation of HTTP version numbers has been clarified |
| by [RFC2145]. Require proxies to upgrade requests to highest |  | by [RFC2145]. Require proxies to upgrade requests to highest |
| protocol version they support to deal with problems discovered in |  | protocol version they support to deal with problems discovered in |
| HTTP/1.0 implementations (Section 3.1) |  | HTTP/1.0 implementations (Section 2.5) |
| Quality Values of zero should indicate that "I don't want something" |  | Quality Values of zero should indicate that "I don't want something" |
| to allow clients to refuse a representation. (Section 3.5) |  | to allow clients to refuse a representation. (Section 6.4) |
| Transfer-coding had significant problems, particularly with |  | Transfer-coding had significant problems, particularly with |
| interactions with chunked encoding. The solution is that transfer- |  | interactions with chunked encoding. The solution is that transfer- |
| codings become as full fledged as content-codings. This involves |  | codings become as full fledged as content-codings. This involves |
| adding an IANA registry for transfer-codings (separate from content |  | adding an IANA registry for transfer-codings (separate from content |
| codings), a new header field (TE) and enabling trailer headers in the |  | codings), a new header field (TE) and enabling trailer headers in the |
| future. Transfer encoding is a major performance benefit, so it was |  | future. Transfer encoding is a major performance benefit, so it was |
| worth fixing [Nie1997]. TE also solves another, obscure, downward |  | worth fixing [Nie1997]. TE also solves another, obscure, downward |
| interoperability problem that could have occurred due to interactions |  | interoperability problem that could have occurred due to interactions |
| between authentication trailers, chunked encoding and HTTP/1.0 |  | between authentication trailers, chunked encoding and HTTP/1.0 |
| clients.(Section 3.3, 3.3.1, and 8.5) |  | clients.(Section 6.2, 6.2.1, and 9.5) |
| B.4. Changes from RFC 2616 |  | B.4. 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 character 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 NUL, CR or LF. Non-ASCII content in header |  | longer allows escaping control characters other than HTAB. Non-ASCII |
| fields and reason phrase has been obsoleted and made opaque (the TEXT |  | content in header fields and reason phrase has been obsoleted and |
| 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 3.1) |  | Clarify that HTTP-Version is case sensitive. (Section 2.5) |
| Remove reference to non-existant identity transfer-coding value |  | Remove reference to non-existant identity transfer-coding value |
| tokens. (Sections 3.3 and 4.4) |  | tokens. (Sections 6.2 and 3.4) |
| Clarification that the chunk length does not include the count of the |  |  |
| octets in the chunk header and trailer. (Section 3.3.1) |  |  |
| Require that invalid whitespace around field-names be rejected. |  | Require that invalid whitespace around field-names be rejected. |
| (Section 4.2) |  | (Section 3.2) |
| Update use of abs_path production from RFC1808 to the path-absolute + |  | Update use of abs_path production from RFC1808 to the path-absolute + |
| query components of RFC3986. (Section 5.1.2) |  | query components of RFC3986. (Section 4.1.2) |
| Clarify exactly when close connection options must be sent. |  |  |
| (Section 8.1) |  |  |
| Appendix C. Terminology |  |  |
| This specification uses a number of terms to refer to the roles |  |  |
| played by participants in, and objects of, the HTTP communication. |  |  |
| cache |  |  |
| A program's local store of response messages and the subsystem |  |  |
| that controls its message storage, retrieval, and deletion. A |  |  |
| cache stores cacheable responses in order to reduce the response |  |  |
| time and network bandwidth consumption on future, equivalent |  |  |
| requests. Any client or server may include a cache, though a |  |  |
| cache cannot be used by a server that is acting as a tunnel. |  |  |
| cacheable |  |  |
| A response is cacheable if a cache is allowed to store a copy of |  |  |
| the response message for use in answering subsequent requests. |  |  |
| The rules for determining the cacheability of HTTP responses are |  |  |
| defined in Section 1 of [Part6]. Even if a resource is cacheable, |  |  |
| there may be additional constraints on whether a cache can use the |  |  |
| cached copy for a particular request. |  |  |
| client |  |  |
| A program that establishes connections for the purpose of sending |  |  |
| requests. |  |  |
| connection |  |  |
| A transport layer virtual circuit established between two programs |  |  |
| for the purpose of communication. |  |  |
| content negotiation |  |  |
| The mechanism for selecting the appropriate representation when |  |  |
| servicing a request, as described in Section 4 of [Part3]. The |  |  |
| representation of entities in any response can be negotiated |  |  |
| (including error responses). |  |  |
| entity |  |  |
| The information transferred as the payload of a request or |  |  |
| response. An entity consists of metainformation in the form of |  |  |
| entity-header fields and content in the form of an entity-body, as |  |  |
| described in Section 3 of [Part3]. |  |  |
| gateway |  |  |
| A server which acts as an intermediary for some other server. |  |  |
| Unlike a proxy, a gateway receives requests as if it were the |  |  |
| origin server for the requested resource; the requesting client |  |  |
| may not be aware that it is communicating with a gateway. |  |  |
| inbound/outbound |  |  |
| Inbound and outbound refer to the request and response paths for |  |  |
| messages: "inbound" means "traveling toward the origin server", |  |  |
| and "outbound" means "traveling toward the user agent" |  |  |
| message |  |  |
| The basic unit of HTTP communication, consisting of a structured |  |  |
| sequence of octets matching the syntax defined in Section 4 and |  |  |
| transmitted via the connection. |  |  |
| origin server |  |  |
| The server on which a given resource resides or is to be created. |  |  |
| proxy |  |  |
| An intermediary program which acts as both a server and a client |  |  |
| for the purpose of making requests on behalf of other clients. |  |  |
| Requests are serviced internally or by passing them on, with |  |  |
| possible translation, to other servers. A proxy MUST implement |  |  |
| both the client and server requirements of this specification. A |  |  |
| "transparent proxy" is a proxy that does not modify the request or |  |  |
| response beyond what is required for proxy authentication and |  |  |
| identification. A "non-transparent proxy" is a proxy that |  |  |
| modifies the request or response in order to provide some added |  |  |
| service to the user agent, such as group annotation services, |  |  |
| media type transformation, protocol reduction, or anonymity |  |  |
| filtering. Except where either transparent or non-transparent |  |  |
| behavior is explicitly stated, the HTTP proxy requirements apply |  |  |
| to both types of proxies. |  |  |
| request |  |  |
| An HTTP request message, as defined in Section 5. |  |  |
| resource |  |  |
| A network data object or service that can be identified by a URI, |  |  |
| as defined in Section 2.1. Resources may be available in multiple |  |  |
| representations (e.g. multiple languages, data formats, size, and |  |  |
| resolutions) or vary in other ways. |  |  |
| response |  |  |
| An HTTP response message, as defined in Section 6. |  |  |
| representation |  |  |
| An entity included with a response that is subject to content |  |  |
| negotiation, as described in Section 4 of [Part3]. There may |  |  |
| exist multiple representations associated with a particular |  |  |
| response status. |  |  |
| server |  |  |
| An application program that accepts connections in order to |  |  |
| service requests by sending back responses. Any given program may |  |  |
| be capable of being both a client and a server; our use of these |  |  |
| terms refers only to the role being performed by the program for a |  |  |
| particular connection, rather than to the program's capabilities |  |  |
| in general. Likewise, any server may act as an origin server, |  |  |
| proxy, gateway, or tunnel, switching behavior based on the nature |  |  |
| of each request. |  |  |
| tunnel |  |  |
| An intermediary program which is acting as a blind relay between |  |  |
| two connections. Once active, a tunnel is not considered a party |  |  |
| to the HTTP communication, though the tunnel may have been |  |  |
| initiated by an HTTP request. The tunnel ceases to exist when |  |  |
| both ends of the relayed connections are closed. |  |  |
| upstream/downstream |  |  |
| Upstream and downstream describe the flow of a message: all |  |  |
| messages flow from upstream to downstream. |  |  |
| user agent |  |  |
| The client which initiates a request. These are often browsers, |  | Clarification that the chunk length does not include the count of the |
| editors, spiders (web-traversing robots), or other end user tools. |  | octets in the chunk header and trailer. Furthermore disallowed line |
|  |  | folding in chunk extensions. (Section 6.2.1) |
| variant |  | Remove hard limit of two connections per server. (Section 7.1.4) |
| A resource may have one, or more than one, representation(s) |  | Clarify exactly when close connection options must be sent. |
| associated with it at any given instant. Each of these |  | (Section 9.1) |
| representations is termed a `variant'. Use of the term `variant' |  |  |
| does not necessarily imply that the resource is subject to content |  |  |
| negotiation. |  |  |
| Appendix D. Collected ABNF |  | Appendix C. Collected ABNF |
| BWS = OWS |  | BWS = OWS |
| Cache-Control = <Cache-Control, defined in [Part6], Section 3.4> |  | 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 |
| HTTP-date = rfc1123-date / obs-date |  | HTTP-date = rfc1123-date / obs-date |
| HTTP-message = Request / Response |  | 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 ] |
| Method = token |  | Method = token |
| OWS = *( [ obs-fold ] WSP ) |  | OWS = *( [ obs-fold ] WSP ) |
| Pragma = <Pragma, defined in [Part6], Section 3.4> |  | Pragma = <Pragma, defined in [Part6], Section 3.4> |
| RWS = 1*( [ obs-fold ] WSP ) |  | RWS = 1*( [ obs-fold ] WSP ) |
| skipping to change at page 66, line 15 |  | skipping to change at page 70, line 40 |
| 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-string |  | chunk-ext-val = token / quoted-str-nf |
| chunk-size = 1*HEXDIG |  | chunk-size = 1*HEXDIG |
| comment = "(" *( ctext / quoted-pair / comment ) ")" |  | comment = "(" *( ctext / quoted-cpair / comment ) ")" |
| connection-token = token |  | connection-token = token |
| ctext = OWS / %x21-27 ; '!'-''' |  | ctext = OWS / %x21-27 ; '!'-''' |
| / %x2A-5B ; '*'-'[' |  | / %x2A-5B ; '*'-'[' |
| / %x5D-7E ; ']'-'~' |  | / %x5D-7E ; ']'-'~' |
| / obs-text |  | / obs-text |
| date1 = day SP month SP year |  | date1 = day SP month SP year |
| date2 = day "-" month "-" 2DIGIT |  | date2 = day "-" month "-" 2DIGIT |
| date3 = month SP ( 2DIGIT / ( SP DIGIT ) ) |  | date3 = month SP ( 2DIGIT / ( SP DIGIT ) ) |
| day = 2DIGIT |  | day = 2DIGIT |
| skipping to change at page 66, line 49 |  | skipping to change at page 71, line 26 |
| / %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 |
| entity-body = <entity-body, defined in [Part3], Section 3.2> |  | entity-body = <entity-body, defined in [Part3], Section 3.2> |
| entity-header = <entity-header, defined in [Part3], Section 3.1> |  | entity-header = <entity-header, defined in [Part3], Section 3.1> |
| 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 ) |
| fragment = <fragment, defined in [RFC3986], Section 3.5> |  |  |
| general-header = Cache-Control / Connection / Date / Pragma / Trailer |  | general-header = Cache-Control / Connection / Date / Pragma / Trailer |
| / Transfer-Encoding / Upgrade / Via / Warning |  | / Transfer-Encoding / Upgrade / Via / Warning |
| generic-message = start-line *( message-header CRLF ) CRLF [ |  |  |
| message-body ] |  |  |
|  |  | 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 ] |
| last-chunk = 1*"0" *WSP [ chunk-ext ] CRLF |  | last-chunk = 1*"0" *WSP [ chunk-ext ] CRLF |
| message-body = entity-body / |  | message-body = entity-body / |
| <entity-body encoded as per Transfer-Encoding> |  | <entity-body encoded as per Transfer-Encoding> |
| message-header = field-name ":" OWS [ field-value ] OWS |  |  |
| minute = 2DIGIT |  | minute = 2DIGIT |
| month = %x4A.61.6E ; Jan |  | month = %x4A.61.6E ; Jan |
| / %x46.65.62 ; Feb |  | / %x46.65.62 ; Feb |
| / %x4D.61.72 ; Mar |  | / %x4D.61.72 ; Mar |
| / %x41.70.72 ; Apr |  | / %x41.70.72 ; Apr |
| / %x4D.61.79 ; May |  | / %x4D.61.79 ; May |
| / %x4A.75.6E ; Jun |  | / %x4A.75.6E ; Jun |
| / %x4A.75.6C ; Jul |  | / %x4A.75.6C ; Jul |
| / %x41.75.67 ; Aug |  | / %x41.75.67 ; Aug |
| / %x53.65.70 ; Sep |  | / %x53.65.70 ; Sep |
| skipping to change at page 67, line 48 |  | skipping to change at page 72, line 21 |
| port = <port, defined in [RFC3986], Section 3.2.3> |  | port = <port, defined in [RFC3986], Section 3.2.3> |
| product = token [ "/" product-version ] |  | product = token [ "/" product-version ] |
| product-version = token |  | product-version = token |
| protocol-name = token |  | protocol-name = token |
| protocol-version = token |  | protocol-version = token |
| pseudonym = token |  | pseudonym = token |
| qdtext = OWS / "!" / %x23-5B ; '#'-'[' |  | qdtext = OWS / "!" / %x23-5B ; '#'-'[' |
| / %x5D-7E ; ']'-'~' |  | / %x5D-7E ; ']'-'~' |
| / obs-text |  | / obs-text |
|  |  | qdtext-nf = WSP / "!" / %x23-5B ; '#'-'[' |
|  |  | / %x5D-7E ; ']'-'~' |
|  |  | / obs-text |
| query = <query, defined in [RFC3986], Section 3.4> |  | query = <query, defined in [RFC3986], Section 3.4> |
| quoted-pair = "\" quoted-text |  | quoted-cpair = "\" ( WSP / VCHAR / obs-text ) |
|  |  | quoted-pair = "\" ( WSP / VCHAR / obs-text ) |
|  |  | quoted-str-nf = DQUOTE *( qdtext-nf / quoted-pair ) DQUOTE |
| quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE |  | quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE |
| quoted-text = %x01-09 / %x0B-0C / %x0E-FF |  |  |
| 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-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> |  | 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 |
| skipping to change at page 68, line 27 |  | skipping to change at page 73, line 4 |
| 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 [ "=" ( token / quoted-string ) ] |  | te-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ] |
| te-params = OWS ";" OWS "q=" qvalue *te-ext |  | te-params = OWS ";" OWS "q=" qvalue *te-ext |
| time-of-day = hour ":" minute ":" second |  | time-of-day = hour ":" minute ":" second |
| token = 1*tchar |  | token = 1*tchar |
| trailer-part = *( entity-header CRLF ) |  | trailer-part = *( entity-header CRLF ) |
| transfer-coding = "chunked" / transfer-extension |  | transfer-coding = "chunked" / "compress" / "deflate" / "gzip" / |
|  |  | 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 = token / quoted-string |  | value = token / quoted-string |
| year = 4DIGIT |  | year = 4DIGIT |
| ABNF diagnostics: |  | ABNF diagnostics: |
| ; Chunked-Body defined but not used |  | ; Chunked-Body defined but not used |
| ; Content-Length defined but not used |  | ; Content-Length defined but not used |
| ; HTTP-message defined but not used |  | ; HTTP-message defined but not used |
| ; Host defined but not used |  | ; Host defined but not used |
|  |  | ; Request defined but not used |
|  |  | ; Response defined but not used |
| ; TE defined but not used |  | ; TE defined but not used |
| ; URI defined but not used |  | ; URI defined but not used |
| ; URI-reference defined but not used |  | ; URI-reference defined but not used |
| ; fragment defined but not used |  |  |
| ; generic-message defined but not used |  |  |
| ; http-URI defined but not used |  | ; http-URI defined but not used |
|  |  | ; https-URI defined but not used |
| ; partial-URI defined but not used |  | ; partial-URI defined but not used |
| Appendix E. Change Log (to be removed by RFC Editor before publication) |  | Appendix D. Change Log (to be removed by RFC Editor before publication) |
| E.1. Since RFC2616 |  | D.1. Since RFC2616 |
| Extracted relevant partitions from [RFC2616]. |  | Extracted relevant partitions from [RFC2616]. |
| E.2. Since draft-ietf-httpbis-p1-messaging-00 |  | D.2. Since draft-ietf-httpbis-p1-messaging-00 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/1>: "HTTP Version |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/1>: "HTTP Version |
| should be case sensitive" |  | should be case sensitive" |
| (<http://purl.org/NET/http-errata#verscase>) |  | (<http://purl.org/NET/http-errata#verscase>) |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/2>: "'unsafe' |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/2>: "'unsafe' |
| characters" (<http://purl.org/NET/http-errata#unsafe-uri>) |  | characters" (<http://purl.org/NET/http-errata#unsafe-uri>) |
| skipping to change at page 70, line 24 |  | skipping to change at page 75, line 4 |
| typo" |  | typo" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/65>: "Informative |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/65>: "Informative |
| references" |  | references" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/66>: "ISO-8859-1 |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/66>: "ISO-8859-1 |
| Reference" |  | Reference" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/86>: "Normative up- |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/86>: "Normative up- |
| to-date references" |  | to-date references" |
| Other changes: |  | Other changes: |
| o Update media type registrations to use RFC4288 template. |  | o Update media type registrations to use RFC4288 template. |
| o Use names of RFC4234 core rules DQUOTE and WSP, fix broken ABNF |  | o Use names of RFC4234 core rules DQUOTE and WSP, fix broken ABNF |
| for chunk-data (work in progress on |  | for chunk-data (work in progress on |
| <http://tools.ietf.org/wg/httpbis/trac/ticket/36>) |  | <http://tools.ietf.org/wg/httpbis/trac/ticket/36>) |
| E.3. Since draft-ietf-httpbis-p1-messaging-01 |  | D.3. Since draft-ietf-httpbis-p1-messaging-01 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/19>: "Bodies on GET |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/19>: "Bodies on GET |
| (and other) requests" |  | (and other) requests" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/55>: "Updating to |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/55>: "Updating to |
| RFC4288" |  | RFC4288" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/57>: "Status Code |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/57>: "Status Code |
| skipping to change at page 71, line 31 |  | skipping to change at page 76, line 11 |
| o Move "Product Tokens" section (back) into Part 1, as "token" is |  | o Move "Product Tokens" section (back) into Part 1, as "token" is |
| used in the definition of the Upgrade header. |  | used in the definition of the Upgrade header. |
| o Add explicit references to BNF syntax and rules imported from |  | o Add explicit references to BNF syntax and rules imported from |
| other parts of the specification. |  | other parts of the specification. |
| o Rewrite prose rule "token" in terms of "tchar", rewrite prose rule |  | o Rewrite prose rule "token" in terms of "tchar", rewrite prose rule |
| "TEXT". |  | "TEXT". |
| E.4. Since draft-ietf-httpbis-p1-messaging-02 |  | D.4. Since draft-ietf-httpbis-p1-messaging-02 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/51>: "HTTP-date vs. |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/51>: "HTTP-date vs. |
| rfc1123-date" |  | rfc1123-date" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/64>: "WS in quoted- |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/64>: "WS in quoted- |
| pair" |  | pair" |
| Ongoing work on IANA Message Header Registration |  | Ongoing work on IANA Message Header Registration |
| skipping to change at page 72, line 5 |  | skipping to change at page 76, line 33 |
| o Reference RFC 3984, and update header registrations for headers |  | o Reference RFC 3984, and update header registrations for headers |
| defined in this document. |  | defined in this document. |
| Ongoing work on ABNF conversion |  | Ongoing work on ABNF conversion |
| (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |  | (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |
| o Replace string literals when the string really is case-sensitive |  | o Replace string literals when the string really is case-sensitive |
| (HTTP-Version). |  | (HTTP-Version). |
| E.5. Since draft-ietf-httpbis-p1-messaging-03 |  | D.5. Since draft-ietf-httpbis-p1-messaging-03 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/28>: "Connection |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/28>: "Connection |
| closing" |  | closing" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/97>: "Move |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/97>: "Move |
| registrations and registry information to IANA Considerations" |  | registrations and registry information to IANA Considerations" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/120>: "need new URL |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/120>: "need new URL |
| skipping to change at page 72, line 36 |  | skipping to change at page 77, line 16 |
| Ongoing work on ABNF conversion |  | Ongoing work on ABNF conversion |
| (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |  | (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |
| o Replace string literals when the string really is case-sensitive |  | o Replace string literals when the string really is case-sensitive |
| (HTTP-Date). |  | (HTTP-Date). |
| o Replace HEX by HEXDIG for future consistence with RFC 5234's core |  | o Replace HEX by HEXDIG for future consistence with RFC 5234's core |
| rules. |  | rules. |
| E.6. Since draft-ietf-httpbis-p1-messaging-04 |  | D.6. Since draft-ietf-httpbis-p1-messaging-04 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/34>: "Out-of-date |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/34>: "Out-of-date |
| reference for URIs" |  | reference for URIs" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/132>: "RFC 2822 is |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/132>: "RFC 2822 is |
| updated by RFC 5322" |  | updated by RFC 5322" |
| Ongoing work on ABNF conversion |  | Ongoing work on ABNF conversion |
| skipping to change at page 73, line 13 |  | skipping to change at page 77, line 41 |
| o Get rid of RFC822 dependency; use RFC5234 plus extensions instead. |  | o Get rid of RFC822 dependency; use RFC5234 plus extensions instead. |
| o Only reference RFC 5234's core rules. |  | o Only reference RFC 5234's core rules. |
| o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional |  | o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional |
| whitespace ("OWS") and required whitespace ("RWS"). |  | whitespace ("OWS") and required whitespace ("RWS"). |
| o Rewrite ABNFs to spell out whitespace rules, factor out header |  | o Rewrite ABNFs to spell out whitespace rules, factor out header |
| value format definitions. |  | value format definitions. |
| E.7. Since draft-ietf-httpbis-p1-messaging-05 |  | D.7. Since draft-ietf-httpbis-p1-messaging-05 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/30>: "Header LWS" |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/30>: "Header LWS" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/52>: "Sort 1.3 |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/52>: "Sort 1.3 |
| Terminology" |  | Terminology" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/63>: "RFC2047 |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/63>: "RFC2047 |
| encoded words" |  | encoded words" |
| skipping to change at page 74, line 11 |  | skipping to change at page 78, line 38 |
| o Add appendix containing collected and expanded ABNF. |  | o Add appendix containing collected and expanded ABNF. |
| Other changes: |  | Other changes: |
| o Rewrite introduction; add mostly new Architecture Section. |  | o Rewrite introduction; add mostly new Architecture Section. |
| o Move definition of quality values from Part 3 into Part 1; make TE |  | o Move definition of quality values from Part 3 into Part 1; make TE |
| request header grammar independent of accept-params (defined in |  | request header grammar independent of accept-params (defined in |
| Part 3). |  | Part 3). |
| E.8. Since draft-ietf-httpbis-p1-messaging-06 |  | D.8. Since draft-ietf-httpbis-p1-messaging-06 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/161>: "base for |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/161>: "base for |
| numeric protocol elements" |  | numeric protocol elements" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/162>: "comment ABNF" |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/162>: "comment ABNF" |
| Partly resolved issues: |  | Partly resolved issues: |
| skipping to change at page 74, line 25 |  | skipping to change at page 79, line 4 |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/161>: "base for |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/161>: "base for |
| numeric protocol elements" |  | numeric protocol elements" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/162>: "comment ABNF" |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/162>: "comment ABNF" |
| Partly resolved issues: |  | Partly resolved issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/88>: "205 Bodies" |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/88>: "205 Bodies" |
| (took out language that implied that there may be methods for |  | (took out language that implied that there may be methods for |
| which a request body MUST NOT be included) |  | which a request body MUST NOT be included) |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/163>: "editorial |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/163>: "editorial |
| improvements around HTTP-date" |  | improvements around HTTP-date" |
|  |  | D.9. Since draft-ietf-httpbis-p1-messaging-07 |
|  |  | Closed issues: |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/93>: "Repeating |
|  |  | single-value headers" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/131>: "increase |
|  |  | connection limit" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/157>: "IP addresses |
|  |  | in URLs" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/172>: "take over |
|  |  | HTTP Upgrade Token Registry" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/173>: "CR and LF in |
|  |  | chunk extension values" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/184>: "HTTP/0.9 |
|  |  | support" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/188>: "pick IANA |
|  |  | policy (RFC5226) for Transfer Coding / Content Coding" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/189>: "move |
|  |  | definitions of gzip/deflate/compress to part 1" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/194>: "disallow |
|  |  | control characters in quoted-pair" |
|  |  | Partly resolved issues: |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/148>: "update IANA |
|  |  | requirements wrt Transfer-Coding values" (add the IANA |
|  |  | Considerations subsection) |
| Index |  | Index |
| A |  | A |
| application/http Media Type 49 |  | application/http Media Type 55 |
| C |  | C |
| cache 61 |  | cache 12 |
| cacheable 62 |  | cacheable 13 |
| client 62 |  | chunked (Coding Format) 32 |
| connection 62 |  | client 10 |
| Connection header 39 |  | Coding Format |
| content negotiation 62 |  | chunked 32 |
| Content-Length header 40 |  | compress 34 |
|  |  | deflate 35 |
|  |  | gzip 35 |
|  |  | compress (Coding Format) 34 |
|  |  | connection 10 |
|  |  | Connection header 44 |
|  |  | Content-Length header 45 |
| D |  | D |
| Date header 40 |  | Date header 46 |
| downstream 64 |  | deflate (Coding Format) 35 |
|  |  | downstream 12 |
| E |  |  |
| entity 62 |  |  |
| G |  | G |
| gateway 62 |  | gateway 12 |
| Grammar |  | Grammar |
| absolute-URI 10 |  | absolute-URI 15 |
| ALPHA 7 |  | ALPHA 7 |
| asctime-date 18 |  | asctime-date 31 |
| attribute 18 |  | attribute 31 |
| authority 10 |  | authority 15 |
| BWS 9 |  | BWS 9 |
| chunk 20 |  | chunk 33 |
| chunk-data 20 |  | chunk-data 33 |
| chunk-ext 20 |  | chunk-ext 33 |
| chunk-ext-name 20 |  | chunk-ext-name 33 |
| chunk-ext-val 20 |  | chunk-ext-val 33 |
| chunk-size 20 |  | chunk-size 33 |
| Chunked-Body 20 |  | Chunked-Body 33 |
| comment 24 |  | comment 21 |
| Connection 39 |  | Connection 44 |
| connection-token 39 |  | connection-token 44 |
| Connection-v 39 |  | Connection-v 44 |
| Content-Length 40 |  | Content-Length 45 |
| Content-Length-v 40 |  | Content-Length-v 45 |
| CR 7 |  | CR 7 |
| CRLF 7 |  | CRLF 7 |
| ctext 24 |  | ctext 21 |
| CTL 7 |  | CTL 7 |
| Date 40 |  | Date 46 |
| Date-v 40 |  | Date-v 46 |
| date1 17 |  | date1 30 |
| date2 18 |  | date2 31 |
| date3 18 |  | date3 31 |
| day 17 |  | day 30 |
| day-name 17 |  | day-name 30 |
| day-name-l 17 |  | day-name-l 30 |
| DIGIT 7 |  | DIGIT 7 |
| DQUOTE 7 |  | DQUOTE 7 |
| extension-code 31 |  | extension-code 28 |
| extension-method 28 |  | extension-method 24 |
| field-content 23 |  | field-content 19 |
| field-name 23 |  | field-name 19 |
| field-value 23 |  | field-value 19 |
| general-header 27 |  | general-header 23 |
| generic-message 22 |  | GMT 30 |
| GMT 17 |  | header-field 19 |
| HEXDIG 7 |  | HEXDIG 7 |
| Host 42 |  | Host 47 |
| Host-v 42 |  | Host-v 47 |
| hour 17 |  | hour 30 |
| HTTP-date 16 |  | HTTP-date 29 |
| HTTP-message 22 |  | HTTP-message 18 |
| HTTP-Prot-Name 14 |  | HTTP-Prot-Name 14 |
| http-URI 11 |  | http-URI 16 |
| HTTP-Version 14 |  | HTTP-Version 14 |
| last-chunk 20 |  | https-URI 17 |
|  |  | last-chunk 33 |
| LF 7 |  | LF 7 |
| message-body 25 |  | message-body 21 |
| message-header 23 |  | Method 24 |
| Method 28 |  | minute 30 |
| minute 17 |  | month 30 |
| month 17 |  | obs-date 30 |
| obs-date 17 |  |  |
| obs-text 9 |  | obs-text 9 |
| OCTET 7 |  | OCTET 7 |
| OWS 9 |  | OWS 9 |
| path-absolute 10 |  | path-absolute 15 |
| port 10 |  | port 15 |
| product 21 |  | product 35 |
| product-version 21 |  | product-version 35 |
| protocol-name 46 |  | protocol-name 52 |
| protocol-version 46 |  | protocol-version 52 |
| pseudonym 46 |  | pseudonym 52 |
| qdtext 9 |  | qdtext 9 |
| query 10 |  | qdtext-nf 33 |
|  |  | query 15 |
|  |  | quoted-cpair 21 |
| quoted-pair 9 |  | quoted-pair 9 |
|  |  | quoted-str-nf 33 |
| quoted-string 9 |  | quoted-string 9 |
| quoted-text 9 |  | qvalue 36 |
| qvalue 22 |  | Reason-Phrase 28 |
| Reason-Phrase 31 |  | received-by 52 |
| received-by 46 |  | received-protocol 52 |
| received-protocol 46 |  | Request 24 |
| Request 27 |  | Request-Line 24 |
| Request-Line 28 |  | request-target 24 |
| request-target 28 |  | Response 27 |
| Response 31 |  | rfc850-date 31 |
| rfc850-date 18 |  | rfc1123-date 30 |
| rfc1123-date 17 |  |  |
| RWS 9 |  | RWS 9 |
| second 17 |  | second 30 |
| SP 7 |  | SP 7 |
| start-line 22 |  | Status-Code 28 |
| Status-Code 31 |  | Status-Line 27 |
| Status-Line 31 |  | t-codings 48 |
| t-codings 42 |  |  |
| tchar 9 |  | tchar 9 |
| TE 42 |  | TE 48 |
| te-ext 42 |  | te-ext 48 |
| te-params 42 |  | te-params 48 |
| TE-v 42 |  | TE-v 48 |
| time-of-day 17 |  | time-of-day 30 |
| token 9 |  | token 9 |
| Trailer 44 |  | Trailer 49 |
| trailer-part 20 |  | trailer-part 33 |
| Trailer-v 44 |  | Trailer-v 49 |
| transfer-coding 18 |  | transfer-coding 31 |
| Transfer-Encoding 44 |  | Transfer-Encoding 50 |
| Transfer-Encoding-v 44 |  | Transfer-Encoding-v 50 |
| transfer-extension 18 |  | transfer-extension 31 |
| transfer-parameter 18 |  | transfer-parameter 31 |
| Upgrade 45 |  | Upgrade 50 |
| Upgrade-v 45 |  | Upgrade-v 50 |
| uri-host 10 |  | uri-host 15 |
| URI-reference 10 |  | URI-reference 15 |
| value 18 |  | value 31 |
| VCHAR 7 |  | VCHAR 7 |
| Via 46 |  | Via 52 |
| Via-v 46 |  | Via-v 52 |
| WSP 7 |  | WSP 7 |
| year 17 |  | year 30 |
|  |  | gzip (Coding Format) 35 |
| H |  | H |
|  |  | header field 18 |
|  |  | header section 18 |
| Headers |  | Headers |
| Connection 39 |  | Connection 44 |
| Content-Length 40 |  | Content-Length 45 |
| Date 40 |  | Date 46 |
| Host 42 |  | Host 47 |
| TE 42 |  | TE 48 |
| Trailer 44 |  | Trailer 49 |
| Transfer-Encoding 44 |  | Transfer-Encoding 49 |
| Upgrade 45 |  | Upgrade 50 |
| Via 46 |  | Via 52 |
| Host header 42 |  | headers 18 |
| http URI scheme 11 |  | Host header 47 |
| https URI scheme 11 |  | http URI scheme 16 |
|  |  | https URI scheme 17 |
| I |  | I |
| inbound 62 |  | inbound 12 |
| M |  | M |
| Media Type |  | Media Type |
| application/http 49 |  | application/http 55 |
| message/http 48 |  | message/http 54 |
| message 63 |  | message 10 |
| message/http Media Type 48 |  | message/http Media Type 54 |
| O |  | O |
| origin server 63 |  | origin server 10 |
| outbound 62 |  | outbound 12 |
| P |  | P |
| proxy 63 |  | proxy 12 |
| R |  | R |
| representation 63 |  | request 10 |
| request 63 |  | resource 15 |
| resource 63 |  | response 10 |
| response 63 |  | reverse proxy 12 |
| S |  | S |
| server 64 |  | server 10 |
| T |  | T |
| TE header 42 |  | TE header 48 |
| Trailer header 44 |  | Trailer header 49 |
| Transfer-Encoding header 44 |  | Transfer-Encoding header 49 |
| tunnel 64 |  | tunnel 12 |
| U |  | U |
| Upgrade header 45 |  | Upgrade header 50 |
| upstream 64 |  | upstream 12 |
| URI scheme |  | URI scheme |
| http 11 |  | http 16 |
| https 11 |  | https 17 |
| user agent 64 |  | user agent 10 |
| V |  | V |
| variant 64 |  | Via header 52 |
| Via header 46 |  |  |
| Authors' Addresses |  | Authors' Addresses |
| Roy T. Fielding (editor) |  | Roy T. Fielding (editor) |
| Day Software |  | Day Software |
| 23 Corporate Plaza DR, Suite 280 |  | 23 Corporate Plaza DR, Suite 280 |
| Newport Beach, CA 92660 |  | Newport Beach, CA 92660 |
| USA |  | USA |
| Phone: +1-949-706-5300 |  | Phone: +1-949-706-5300 |
End of changes. 262 change blocks.
| 1094 lines changed or deleted |  | 1361 lines changed or added |
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/