| draft-ietf-httpbis-p1-messaging-01.txt |  | draft-ietf-httpbis-p1-messaging-02.txt |
--- | --- | --- | --- | ---
| Network Working Group R. Fielding, Ed. |  | Network 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 |  | Intended status: Standards Track One Laptop per Child |
| Expires: July 15, 2008 J. Mogul |  | Expires: August 27, 2008 J. Mogul |
| HP |  | 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 |
| January 12, 2008 |  | February 24, 2008 |
| 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-01 |  | draft-ietf-httpbis-p1-messaging-02 |
| Status of this Memo |  | Status of this Memo |
| By submitting this Internet-Draft, each author represents that any |  | By submitting this Internet-Draft, each author represents that any |
| applicable patent or other IPR claims of which he or she is aware |  | applicable patent or other IPR claims of which he or she is aware |
| have been or will be disclosed, and any of which he or she becomes |  | have been or will be disclosed, and any of which he or she becomes |
| aware will be disclosed, in accordance with Section 6 of BCP 79. |  | aware will be disclosed, in accordance with Section 6 of BCP 79. |
| Internet-Drafts are working documents of the Internet Engineering |  | Internet-Drafts are working documents of the Internet Engineering |
| Task Force (IETF), its areas, and its working groups. Note that |  | Task Force (IETF), its areas, and its working groups. Note that |
| skipping to change at page 1, line 49 |  | skipping to change at page 1, line 49 |
| 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 July 15, 2008. |  | This Internet-Draft will expire on August 27, 2008. |
| Copyright Notice |  | Copyright Notice |
| Copyright (C) The IETF Trust (2008). |  | Copyright (C) The IETF Trust (2008). |
| Abstract |  | Abstract |
| The Hypertext Transfer Protocol (HTTP) is an application-level |  | The Hypertext Transfer Protocol (HTTP) is an application-level |
| protocol for distributed, collaborative, hypermedia information |  | protocol for distributed, collaborative, hypermedia information |
| systems. HTTP has been in use by the World Wide Web global |  | systems. HTTP has been in use by the World Wide Web global |
| skipping to change at page 3, line 15 |  | skipping to change at page 3, line 15 |
| Table of Contents |  | Table of Contents |
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 |  | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 |
| 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 5 |  | 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 5 |
| 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 |  | 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 |
| 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 |  | 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 |
| 1.4. Overall Operation . . . . . . . . . . . . . . . . . . . . 9 |  | 1.4. Overall Operation . . . . . . . . . . . . . . . . . . . . 9 |
| 2. Notational Conventions and Generic Grammar . . . . . . . . . . 11 |  | 2. Notational Conventions and Generic Grammar . . . . . . . . . . 11 |
| 2.1. Augmented BNF . . . . . . . . . . . . . . . . . . . . . . 11 |  | 2.1. Augmented BNF . . . . . . . . . . . . . . . . . . . . . . 11 |
| 2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . . . 13 |  | 2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . . . 13 |
| 3. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 15 |  | 2.3. ABNF Rules defined in other Parts of the Specification . . 16 |
| 3.1. HTTP Version . . . . . . . . . . . . . . . . . . . . . . . 15 |  | 3. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 16 |
| 3.2. Uniform Resource Identifiers . . . . . . . . . . . . . . . 16 |  | 3.1. HTTP Version . . . . . . . . . . . . . . . . . . . . . . . 16 |
|  |  | 3.2. Uniform Resource Identifiers . . . . . . . . . . . . . . . 17 |
| 3.2.1. General Syntax . . . . . . . . . . . . . . . . . . . . 17 |  | 3.2.1. General Syntax . . . . . . . . . . . . . . . . . . . . 17 |
| 3.2.2. http URL . . . . . . . . . . . . . . . . . . . . . . . 17 |  | 3.2.2. http URL . . . . . . . . . . . . . . . . . . . . . . . 18 |
| 3.2.3. URI Comparison . . . . . . . . . . . . . . . . . . . . 18 |  | 3.2.3. URI Comparison . . . . . . . . . . . . . . . . . . . . 18 |
| 3.3. Date/Time Formats . . . . . . . . . . . . . . . . . . . . 18 |  | 3.3. Date/Time Formats . . . . . . . . . . . . . . . . . . . . 19 |
| 3.3.1. Full Date . . . . . . . . . . . . . . . . . . . . . . 18 |  | 3.3.1. Full Date . . . . . . . . . . . . . . . . . . . . . . 19 |
| 3.4. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 19 |  | 3.4. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 20 |
| 3.4.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 20 |  | 3.4.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 21 |
| 4. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . . 22 |  | 3.5. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 23 |
| 4.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 22 |  | 4. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . . 24 |
| 4.2. Message Headers . . . . . . . . . . . . . . . . . . . . . 23 |  | 4.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 24 |
| 4.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 24 |  | 4.2. Message Headers . . . . . . . . . . . . . . . . . . . . . 24 |
| 4.4. Message Length . . . . . . . . . . . . . . . . . . . . . . 25 |  | 4.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 25 |
| 4.5. General Header Fields . . . . . . . . . . . . . . . . . . 26 |  | 4.4. Message Length . . . . . . . . . . . . . . . . . . . . . . 26 |
| 5. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 |  | 4.5. General Header Fields . . . . . . . . . . . . . . . . . . 28 |
| 5.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 27 |  | 5. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 |
| 5.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 27 |  | 5.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 28 |
| 5.1.2. Request-URI . . . . . . . . . . . . . . . . . . . . . 27 |  | 5.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 29 |
| 5.2. The Resource Identified by a Request . . . . . . . . . . . 29 |  | 5.1.2. Request-URI . . . . . . . . . . . . . . . . . . . . . 29 |
| 6. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 |  | 5.2. The Resource Identified by a Request . . . . . . . . . . . 30 |
| 6.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 30 |  | 6. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 |
| 6.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 30 |  | 6.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 31 |
| 7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 30 |  | 6.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 31 |
| 7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 31 |  | 7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 32 |
| 7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 31 |  | 7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 32 |
| 7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 31 |  | 7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 32 |
| 7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 33 |  | 7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 33 |
| 7.1.4. Practical Considerations . . . . . . . . . . . . . . . 33 |  | 7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 34 |
| 7.2. Message Transmission Requirements . . . . . . . . . . . . 34 |  | 7.1.4. Practical Considerations . . . . . . . . . . . . . . . 35 |
| 7.2.1. Persistent Connections and Flow Control . . . . . . . 34 |  | 7.2. Message Transmission Requirements . . . . . . . . . . . . 36 |
| 7.2.2. Monitoring Connections for Error Status Messages . . . 34 |  | 7.2.1. Persistent Connections and Flow Control . . . . . . . 36 |
| 7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 35 |  | 7.2.2. Monitoring Connections for Error Status Messages . . . 36 |
|  |  | 7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 36 |
| 7.2.4. Client Behavior if Server Prematurely Closes |  | 7.2.4. Client Behavior if Server Prematurely Closes |
| Connection . . . . . . . . . . . . . . . . . . . . . . 37 |  | Connection . . . . . . . . . . . . . . . . . . . . . . 38 |
| 8. Header Field Definitions . . . . . . . . . . . . . . . . . . . 37 |  | 8. Header Field Definitions . . . . . . . . . . . . . . . . . . . 39 |
| 8.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 38 |  | 8.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 39 |
| 8.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 39 |  | 8.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 40 |
| 8.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 |  | 8.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 |
| 8.3.1. Clockless Origin Server Operation . . . . . . . . . . 40 |  | 8.3.1. Clockless Origin Server Operation . . . . . . . . . . 42 |
| 8.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 |  | 8.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 |
| 8.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 |  | 8.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 |
| 8.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 42 |  | 8.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 44 |
| 8.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 43 |  | 8.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 44 |
| 8.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 43 |  | 8.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 45 |
| 8.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 |  | 8.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 |
| 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 |  | 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 |
| 10. Security Considerations . . . . . . . . . . . . . . . . . . . 46 |  | 10. Security Considerations . . . . . . . . . . . . . . . . . . . 47 |
| 10.1. Personal Information . . . . . . . . . . . . . . . . . . . 46 |  | 10.1. Personal Information . . . . . . . . . . . . . . . . . . . 48 |
| 10.2. Abuse of Server Log Information . . . . . . . . . . . . . 46 |  | 10.2. Abuse of Server Log Information . . . . . . . . . . . . . 48 |
| 10.3. Attacks Based On File and Path Names . . . . . . . . . . . 47 |  | 10.3. Attacks Based On File and Path Names . . . . . . . . . . . 48 |
| 10.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 47 |  | 10.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 49 |
| 10.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 48 |  | 10.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 49 |
| 10.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 48 |  | 10.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 50 |
| 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 49 |  | 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50 |
| 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50 |  | 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51 |
| 12.1. Normative References . . . . . . . . . . . . . . . . . . . 50 |  | 12.1. Normative References . . . . . . . . . . . . . . . . . . . 51 |
| 12.2. Informative References . . . . . . . . . . . . . . . . . . 51 |  | 12.2. Informative References . . . . . . . . . . . . . . . . . . 52 |
| Appendix A. Internet Media Types . . . . . . . . . . . . . . . . 53 |  | Appendix A. Internet Media Types . . . . . . . . . . . . . . . . 54 |
| A.1. Internet Media Type message/http . . . . . . . . . . . . . 53 |  | A.1. Internet Media Type message/http . . . . . . . . . . . . . 54 |
| A.2. Internet Media Type application/http . . . . . . . . . . . 54 |  | A.2. Internet Media Type application/http . . . . . . . . . . . 56 |
| Appendix B. Tolerant Applications . . . . . . . . . . . . . . . . 55 |  | Appendix B. Tolerant Applications . . . . . . . . . . . . . . . . 57 |
| Appendix C. Conversion of Date Formats . . . . . . . . . . . . . 56 |  | Appendix C. Conversion of Date Formats . . . . . . . . . . . . . 58 |
| Appendix D. Compatibility with Previous Versions . . . . . . . . 56 |  | Appendix D. Compatibility with Previous Versions . . . . . . . . 58 |
| D.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 57 |  | D.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 58 |
| D.1.1. Changes to Simplify Multi-homed Web Servers and |  | D.1.1. Changes to Simplify Multi-homed Web Servers and |
| Conserve IP Addresses . . . . . . . . . . . . . . . . 57 |  | Conserve IP Addresses . . . . . . . . . . . . . . . . 59 |
| D.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 58 |  | D.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 59 |
| D.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 58 |  | D.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 60 |
| D.4. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 59 |  | D.4. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 60 |
| Appendix E. Change Log (to be removed by RFC Editor before |  | Appendix E. Change Log (to be removed by RFC Editor before |
| publication) . . . . . . . . . . . . . . . . . . . . 59 |  | publication) . . . . . . . . . . . . . . . . . . . . 61 |
| E.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 59 |  | E.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 61 |
| E.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 59 |  | E.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 61 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 |  | E.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 62 |
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 64 |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 |
| Intellectual Property and Copyright Statements . . . . . . . . . . 68 |  | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 67 |
|  |  | Intellectual Property and Copyright Statements . . . . . . . . . . 70 |
| 1. Introduction |  | 1. Introduction |
| The Hypertext Transfer Protocol (HTTP) is an application-level |  | The Hypertext Transfer Protocol (HTTP) is an application-level |
| protocol for distributed, collaborative, hypermedia information |  | protocol for distributed, collaborative, hypermedia information |
| systems. HTTP has been in use by the World-Wide Web global |  | systems. HTTP has been in use by the World-Wide Web global |
| information initiative since 1990. The first version of HTTP, |  | information initiative since 1990. The first version of HTTP, |
| commonly referred to as HTTP/0.9, was a simple protocol for raw data |  | commonly referred to as HTTP/0.9, was a simple protocol for raw data |
| transfer across the Internet with only a single method and no |  | transfer across the Internet with only a single method and no |
| metadata. HTTP/1.0, as defined by [RFC1945], improved the protocol |  | metadata. HTTP/1.0, as defined by [RFC1945], improved the protocol |
| skipping to change at page 7, line 18 |  | skipping to change at page 7, line 18 |
| A network data object or service that can be identified by a URI, |  | A network data object or service that can be identified by a URI, |
| as defined in Section 3.2. Resources may be available in multiple |  | as defined in Section 3.2. Resources may be available in multiple |
| representations (e.g. multiple languages, data formats, size, and |  | representations (e.g. multiple languages, data formats, size, and |
| resolutions) or vary in other ways. |  | resolutions) or vary in other ways. |
| entity |  | entity |
| The information transferred as the payload of a request or |  | The information transferred as the payload of a request or |
| response. An entity consists of metainformation in the form of |  | response. An entity consists of metainformation in the form of |
| entity-header fields and content in the form of an entity-body, as |  | entity-header fields and content in the form of an entity-body, as |
| described in Section 3 of [Part3]. |  | described in Section 4 of [Part3]. |
| representation |  | representation |
| An entity included with a response that is subject to content |  | An entity included with a response that is subject to content |
| negotiation, as described in Section 4 of [Part3]. There may |  | negotiation, as described in Section 5 of [Part3]. There may |
| exist multiple representations associated with a particular |  | exist multiple representations associated with a particular |
| response status. |  | response status. |
| content negotiation |  | content negotiation |
| The mechanism for selecting the appropriate representation when |  | The mechanism for selecting the appropriate representation when |
| servicing a request, as described in Section 4 of [Part3]. The |  | servicing a request, as described in Section 5 of [Part3]. The |
| representation of entities in any response can be negotiated |  | representation of entities in any response can be negotiated |
| (including error responses). |  | (including error responses). |
| variant |  | variant |
| A resource may have one, or more than one, representation(s) |  | A resource may have one, or more than one, representation(s) |
| associated with it at any given instant. Each of these |  | associated with it at any given instant. Each of these |
| representations is termed a `variant'. Use of the term `variant' |  | representations is termed a `variant'. Use of the term `variant' |
| does not necessarily imply that the resource is subject to content |  | does not necessarily imply that the resource is subject to content |
| negotiation. |  | negotiation. |
| skipping to change at page 9, line 33 |  | skipping to change at page 9, line 33 |
| messages flow from upstream to downstream. |  | messages flow from upstream to downstream. |
| inbound/outbound |  | inbound/outbound |
| Inbound and outbound refer to the request and response paths for |  | Inbound and outbound refer to the request and response paths for |
| messages: "inbound" means "traveling toward the origin server", |  | messages: "inbound" means "traveling toward the origin server", |
| and "outbound" means "traveling toward the user agent" |  | and "outbound" means "traveling toward the user agent" |
| 1.4. Overall Operation |  | 1.4. Overall Operation |
| The HTTP protocol is a request/response protocol. A client sends a |  | HTTP is a request/response protocol. A client sends a request to the |
| request to the server in the form of a request method, URI, and |  | server in the form of a request method, URI, and protocol version, |
| protocol version, followed by a MIME-like message containing request |  | followed by a MIME-like message containing request modifiers, client |
| modifiers, client information, and possible body content over a |  | information, and possible body content over a connection with a |
| connection with a server. The server responds with a status line, |  | server. The server responds with a status line, including the |
| including the message's protocol version and a success or error code, |  | message's protocol version and a success or error code, followed by a |
| followed by a MIME-like message containing server information, entity |  | MIME-like message containing server information, entity |
| metainformation, and possible entity-body content. The relationship |  | metainformation, and possible entity-body content. The relationship |
| between HTTP and MIME is described in Appendix A of [Part3]. |  | between HTTP and MIME is described in Appendix A of [Part3]. |
| Most HTTP communication is initiated by a user agent and consists of |  | Most HTTP communication is initiated by a user agent and consists of |
| a request to be applied to a resource on some origin server. In the |  | 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) |  | simplest case, this may be accomplished via a single connection (v) |
| between the user agent (UA) and the origin server (O). |  | between the user agent (UA) and the origin server (O). |
| request chain ------------------------> |  | request chain ------------------------> |
| UA -------------------v------------------- O |  | UA -------------------v------------------- O |
| skipping to change at page 14, line 5 |  | skipping to change at page 14, line 5 |
| separators) MUST exist between any two tokens (for the definition |  | separators) MUST exist between any two tokens (for the definition |
| of "token" below), since they would otherwise be interpreted as a |  | of "token" below), since they would otherwise be interpreted as a |
| single token. |  | single token. |
| 2.2. Basic Rules |  | 2.2. Basic Rules |
| The following rules are used throughout this specification to |  | The following rules are used throughout this specification to |
| describe basic parsing constructs. The US-ASCII coded character set |  | describe basic parsing constructs. The US-ASCII coded character set |
| is defined by ANSI X3.4-1986 [USASCII]. |  | is defined by ANSI X3.4-1986 [USASCII]. |
| OCTET = <any 8-bit sequence of data> |  | OCTET = %x00-FF |
| CHAR = <any US-ASCII character (octets 0 - 127)> |  | ; any 8-bit sequence of data |
| UPALPHA = <any US-ASCII uppercase letter "A".."Z"> |  | CHAR = %x01-7F |
| LOALPHA = <any US-ASCII lowercase letter "a".."z"> |  | ; any US-ASCII character, excluding NUL |
| ALPHA = UPALPHA | LOALPHA |  | ALPHA = %x41-5A | %x61-7A |
| DIGIT = <any US-ASCII digit "0".."9"> |  | ; A-Z | a-z |
| CTL = <any US-ASCII control character |  | DIGIT = %x30-39 |
| (octets 0 - 31) and DEL (127)> |  | ; any US-ASCII digit "0".."9" |
| CR = <US-ASCII CR, carriage return (13)> |  | CTL = %x00-1F | %x7F |
| LF = <US-ASCII LF, linefeed (10)> |  | ; (octets 0 - 31) and DEL (127) |
| SP = <US-ASCII SP, space (32)> |  | CR = %x0D |
| HTAB = <US-ASCII HT, horizontal-tab (9)> |  | ; US-ASCII CR, carriage return (13) |
| DQUOTE = <US-ASCII double-quote mark (34)> |  | LF = %x0A |
|  |  | ; US-ASCII LF, linefeed (10) |
|  |  | SP = %x20 |
|  |  | ; US-ASCII SP, space (32) |
|  |  | HTAB = %x09 |
|  |  | ; US-ASCII HT, horizontal-tab (9) |
|  |  | DQUOTE = %x22 |
|  |  | ; US-ASCII double-quote mark (34) |
| 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 B for tolerant |  | protocol elements except the entity-body (see Appendix B 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 3.3 of |
| [Part3]. |  | [Part3]. |
| CRLF = CR LF |  | CRLF = CR LF |
| HTTP/1.1 header field values can be folded onto multiple lines if the |  | HTTP/1.1 header field values can be folded onto multiple lines if the |
| continuation line begins with a space or horizontal tab. All linear |  | continuation line begins with a space or horizontal tab. All linear |
| white space, including folding, has the same semantics as SP. A |  | white space, including folding, has the same semantics as SP. A |
| recipient MAY replace any linear white space with a single SP before |  | recipient MAY replace any linear white space with a single SP before |
| interpreting the field value or forwarding the message downstream. |  | interpreting the field value or forwarding the message downstream. |
| LWS = [CRLF] 1*( SP | HTAB ) |  | LWS = [CRLF] 1*( SP | HTAB ) |
| The TEXT rule is only used for descriptive field contents and values |  | The TEXT rule is only used for descriptive field contents and values |
| that are not intended to be interpreted by the message parser. Words |  | that are not intended to be interpreted by the message parser. Words |
| of *TEXT MAY contain characters from character sets other than ISO- |  | of *TEXT MAY contain characters from character sets other than ISO- |
| 8859-1 [ISO-8859-1] only when encoded according to the rules of |  | 8859-1 [ISO-8859-1] only when encoded according to the rules of |
| [RFC2047]. |  | [RFC2047]. |
| TEXT = <any OCTET except CTLs, |  | TEXT = %x20-7E | %x80-FF | LWS |
| but including LWS> |  | ; any OCTET except CTLs, but including LWS |
| A CRLF is allowed in the definition of TEXT only as part of a header |  | A CRLF is allowed in the definition of TEXT only as part of a header |
| field continuation. It is expected that the folding LWS will be |  | field continuation. It is expected that the folding LWS will be |
| replaced with a single SP before interpretation of the TEXT value. |  | replaced with a single SP before interpretation of the TEXT value. |
| Hexadecimal numeric characters are used in several protocol elements. |  | Hexadecimal numeric characters are used in several protocol elements. |
| HEX = "A" | "B" | "C" | "D" | "E" | "F" |  | HEX = "A" | "B" | "C" | "D" | "E" | "F" |
| | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT |  | | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT |
| Many HTTP/1.1 header field values consist of words separated by LWS |  | Many HTTP/1.1 header field values consist of words separated by LWS |
| or special characters. These special characters MUST be in a quoted |  | or special characters. These special characters MUST be in a quoted |
| string to be used within a parameter value (as defined in |  | string to be used within a parameter value (as defined in |
| Section 3.4). |  | Section 3.4). |
| token = 1*<any CHAR except CTLs or separators> |  |  |
| separators = "(" | ")" | "<" | ">" | "@" |  | separators = "(" | ")" | "<" | ">" | "@" |
| | "," | ";" | ":" | "\" | DQUOTE |  | | "," | ";" | ":" | "\" | DQUOTE |
| | "/" | "[" | "]" | "?" | "=" |  | | "/" | "[" | "]" | "?" | "=" |
| | "{" | "}" | SP | HTAB |  | | "{" | "}" | SP | HTAB |
|  |  | tchar = "!" | "#" | "$" | "%" | "&" | "'" | "*" |
|  |  | | "+" | "-" | "." | "^" | "_" | "`" | "|" | "~" |
|  |  | | DIGIT | ALPHA |
|  |  | ; any CHAR except CTLs or separators |
|  |  | token = 1*tchar |
| 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 |  | In all other fields, parentheses are considered part of the field |
| value. |  | value. |
| comment = "(" *( ctext | quoted-pair | comment ) ")" |  | comment = "(" *( ctext | quoted-pair | comment ) ")" |
| ctext = <any TEXT excluding "(" and ")"> |  | ctext = <any TEXT excluding "(" and ")"> |
| 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 = <any TEXT excluding DQUOTE and "\"> |  | qdtext = <any TEXT excluding DQUOTE and "\"> |
| The backslash character ("\") MAY be used as a single-character |  | The backslash character ("\") MAY be used as a single-character |
| quoting mechanism only within quoted-string and comment constructs. |  | quoting mechanism only within quoted-string and comment constructs. |
| quoted-pair = "\" CHAR |  | quoted-pair = "\" CHAR |
|  |  | 2.3. ABNF Rules defined in other Parts of the Specification |
|  |  | The ABNF rules below are defined in other parts: |
|  |  | request-header = <request-header, defined in [Part2], Section 4> |
|  |  | response-header = <response-header, defined in [Part2], Section 6> |
|  |  | accept-params = <accept-params, defined in [Part3], Section 6.1> |
|  |  | entity-body = <entity-body, defined in [Part3], Section 4.2> |
|  |  | entity-header = <entity-header, defined in [Part3], Section 4.1> |
|  |  | Cache-Control = <Cache-Control, defined in [Part6], Section 16.4> |
|  |  | Pragma = <Pragma, defined in [Part6], Section 16.4> |
|  |  | Warning = <Warning, defined in [Part6], Section 16.6> |
| 3. Protocol Parameters |  | 3. Protocol Parameters |
| 3.1. HTTP Version |  | 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 |
| skipping to change at page 17, line 16 |  | skipping to change at page 17, line 50 |
| 3.2.1. General Syntax |  | 3.2.1. General Syntax |
| URIs in HTTP can be represented in absolute form or relative to some |  | URIs in HTTP can be represented in absolute form or relative to some |
| known base URI [RFC1808], depending upon the context of their use. |  | known base URI [RFC1808], depending upon the context of their use. |
| The two forms are differentiated by the fact that absolute URIs |  | The two forms are differentiated by the fact that absolute URIs |
| always begin with a scheme name followed by a colon. For definitive |  | always begin with a scheme name followed by a colon. For definitive |
| information on URL syntax and semantics, see "Uniform Resource |  | information on URL syntax and semantics, see "Uniform Resource |
| Identifiers (URI): Generic Syntax and Semantics," [RFC2396] (which |  | Identifiers (URI): Generic Syntax and Semantics," [RFC2396] (which |
| replaces [RFC1738] and [RFC1808]). This specification adopts the |  | replaces [RFC1738] and [RFC1808]). This specification adopts the |
| definitions of "URI-reference", "absoluteURI", "relativeURI", "port", |  | definitions of "URI-reference", "absoluteURI", "fragment", |
| "host", "abs_path", "rel_path", "query", and "authority" from that |  | "relativeURI", "port", "host", "abs_path", "query", and "authority" |
| specification. |  | from that specification: |
| The HTTP protocol does not place any a priori limit on the length of |  | absoluteURI = <absoluteURI, defined in [RFC2396], Section 3> |
| a URI. Servers MUST be able to handle the URI of any resource they |  | authority = <authority, defined in [RFC2396], Section 3.2> |
| serve, and SHOULD be able to handle URIs of unbounded length if they |  | fragment = <fragment, defined in [RFC2396], Section 4.1> |
| provide GET-based forms that could generate such URIs. A server |  | path-absolute = <abs_path, defined in [RFC2396], Section 3> |
| SHOULD return 414 (Request-URI Too Long) status if a URI is longer |  | port = <port, defined in [RFC2396], Section 3.2.2> |
| than the server can handle (see Section 9.4.15 of [Part2]). |  | query = <query, defined in [RFC2396], Section 3.4> |
|  |  | relativeURI = <relativeURI, defined in [RFC2396], Section 5> |
|  |  | uri-host = <host, defined in [RFC2396], Section 3.2.2> |
|  |  | HTTP does not place any a priori limit on the length of a URI. |
|  |  | Servers MUST be able to handle the URI of any resource they serve, |
|  |  | and SHOULD be able to handle URIs of unbounded length if they provide |
|  |  | GET-based forms that could generate such URIs. A server SHOULD |
|  |  | return 414 (Request-URI Too Long) status if a URI is longer than the |
|  |  | server can handle (see Section 9.4.15 of [Part2]). |
| Note: Servers ought to be cautious about depending on URI lengths |  | Note: Servers ought to be cautious about depending on URI lengths |
| above 255 bytes, because some older client or proxy |  | above 255 bytes, because some older client or proxy |
| implementations might not properly support these lengths. |  | implementations might not properly support these lengths. |
| 3.2.2. http URL |  | 3.2.2. http URL |
| The "http" scheme is used to locate network resources via the HTTP |  | The "http" scheme is used to locate network resources via the HTTP |
| protocol. This section defines the scheme-specific syntax and |  | protocol. This section defines the scheme-specific syntax and |
| semantics for http URLs. |  | semantics for http URLs. |
| http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]] |  | http-URL = "http:" "//" uri-host [ ":" port ] |
|  |  | [ path-absolute [ "?" query ]] |
| If the port is empty or not given, port 80 is assumed. The semantics |  | 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 |  | are that the identified resource is located at the server listening |
| for TCP connections on that port of that host, and the Request-URI |  | for TCP connections on that port of that host, and the Request-URI |
| for the resource is abs_path (Section 5.1.2). The use of IP |  | for the resource is path-absolute (Section 5.1.2). The use of IP |
| addresses in URLs SHOULD be avoided whenever possible (see |  | addresses in URLs SHOULD be avoided whenever possible (see |
| [RFC1900]). If the abs_path is not present in the URL, it MUST be |  | [RFC1900]). If the path-absolute is not present in the URL, it MUST |
| given as "/" when used as a Request-URI for a resource |  | be given as "/" when used as a Request-URI for a resource |
| (Section 5.1.2). If a proxy receives a host name which is not a |  | (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 |  | 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 |  | it received. If a proxy receives a fully qualified domain name, the |
| proxy MUST NOT change the host name. |  | proxy MUST NOT change the host name. |
| 3.2.3. URI Comparison |  | 3.2.3. URI Comparison |
| When comparing two URIs to decide if they match or not, a client |  | When comparing two URIs to decide if they match or not, a client |
| SHOULD use a case-sensitive octet-by-octet comparison of the entire |  | SHOULD use a case-sensitive octet-by-octet comparison of the entire |
| URIs, with these exceptions: |  | URIs, with these exceptions: |
| o A port that is empty or not given is equivalent to the default |  | o A port that is empty or not given is equivalent to the default |
| port for that URI-reference; |  | port for that URI-reference; |
| o Comparisons of host names MUST be case-insensitive; |  | o Comparisons of host names MUST be case-insensitive; |
| o Comparisons of scheme names MUST be case-insensitive; |  | o Comparisons of scheme names MUST be case-insensitive; |
| o An empty abs_path is equivalent to an abs_path of "/". |  | o An empty path-absolute is equivalent to an path-absolute of "/". |
| Characters other than those in the "reserved" set (see [RFC2396]) are |  | Characters other than those in the "reserved" set (see [RFC2396]) are |
| equivalent to their ""%" HEX HEX" encoding. |  | equivalent to their ""%" HEX HEX" encoding. |
| For example, the following three URIs are equivalent: |  | For example, the following three URIs are equivalent: |
| http://example.com:80/~smith/home.html |  | http://example.com:80/~smith/home.html |
| http://EXAMPLE.com/%7Esmith/home.html |  | http://EXAMPLE.com/%7Esmith/home.html |
| http://EXAMPLE.com:/%7esmith/home.html |  | http://EXAMPLE.com:/%7esmith/home.html |
| skipping to change at page 20, line 32 |  | skipping to change at page 21, line 25 |
| values of MIME [RFC2045], which were designed to enable safe |  | values of MIME [RFC2045], which were designed to enable safe |
| transport of binary data over a 7-bit transport service. However, |  | transport of binary data over a 7-bit transport service. However, |
| safe transport has a different focus for an 8bit-clean transfer |  | safe transport has a different focus for an 8bit-clean transfer |
| protocol. In HTTP, the only unsafe characteristic of message-bodies |  | protocol. In HTTP, the only unsafe characteristic of message-bodies |
| is the difficulty in determining the exact body length (Section 4.4), |  | is the difficulty in determining the exact body length (Section 4.4), |
| or the desire to encrypt data over a shared transport. |  | or the desire to encrypt data over a shared transport. |
| The Internet Assigned Numbers Authority (IANA) acts as a registry for |  | The Internet Assigned Numbers Authority (IANA) acts as a registry for |
| transfer-coding value tokens. Initially, the registry contains the |  | transfer-coding value tokens. Initially, the registry contains the |
| following tokens: "chunked" (Section 3.4.1), "gzip", "compress", and |  | following tokens: "chunked" (Section 3.4.1), "gzip", "compress", and |
| "deflate" (Section 2.2 of [Part3]). |  | "deflate" (Section 3.2 of [Part3]). |
| New transfer-coding value tokens SHOULD be registered in the same way |  | New transfer-coding value tokens SHOULD be registered in the same way |
| as new content-coding value tokens (Section 2.2 of [Part3]). |  | as new content-coding value tokens (Section 3.2 of [Part3]). |
| A server which receives an entity-body with a transfer-coding it does |  | A server which receives an entity-body with a transfer-coding it does |
| not understand SHOULD return 501 (Not Implemented), and close the |  | not understand SHOULD return 501 (Not Implemented), and close the |
| connection. A server MUST NOT send transfer-codings to an HTTP/1.0 |  | connection. A server MUST NOT send transfer-codings to an HTTP/1.0 |
| client. |  | client. |
| 3.4.1. Chunked Transfer Coding |  | 3.4.1. Chunked Transfer Coding |
| The chunked encoding modifies the body of a message in order to |  | The chunked encoding modifies the body of a message in order to |
| transfer it as a series of chunks, each with its own size indicator, |  | transfer it as a series of chunks, each with its own size indicator, |
| followed by an OPTIONAL trailer containing entity-header fields. |  | followed by an OPTIONAL trailer containing entity-header fields. |
| This allows dynamically produced content to be transferred along with |  | This allows dynamically produced content to be transferred along with |
| the information necessary for the recipient to verify that it has |  | the information necessary for the recipient to verify that it has |
| received the full message. |  | received the full message. |
| Chunked-Body = *chunk |  | Chunked-Body = *chunk |
| last-chunk |  | last-chunk |
| trailer |  | trailer-part |
| CRLF |  | CRLF |
| chunk = chunk-size [ chunk-extension ] CRLF |  | chunk = chunk-size [ chunk-extension ] CRLF |
| chunk-data CRLF |  | chunk-data CRLF |
| chunk-size = 1*HEX |  | chunk-size = 1*HEX |
| last-chunk = 1*("0") [ chunk-extension ] CRLF |  | last-chunk = 1*("0") [ chunk-extension ] CRLF |
| chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] ) |  | chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] ) |
| chunk-ext-name = token |  | chunk-ext-name = token |
| chunk-ext-val = token | quoted-string |  | chunk-ext-val = token | quoted-string |
| chunk-data = 1*OCTET ; a sequence of chunk-size octets |  | chunk-data = 1*OCTET ; a sequence of chunk-size octets |
| trailer = *(entity-header CRLF) |  | trailer-part = *(entity-header CRLF) |
| The chunk-size field is a string of hex digits indicating the size of |  | The chunk-size field is a string of hex digits indicating the size of |
| the chunk-data in octets. The chunked encoding is ended by any chunk |  | the chunk-data in octets. The chunked encoding is ended by any chunk |
| whose size is zero, followed by the trailer, which is terminated by |  | whose size is zero, followed by the trailer, which is terminated by |
| an empty line. |  | an empty line. |
| The trailer allows the sender to include additional HTTP header |  | The trailer allows the sender to include additional HTTP header |
| fields at the end of the message. The Trailer header field can be |  | fields at the end of the message. The Trailer header field can be |
| used to indicate which header fields are included in a trailer (see |  | used to indicate which header fields are included in a trailer (see |
| Section 8.6). |  | Section 8.6). |
| skipping to change at page 22, line 28 |  | skipping to change at page 23, line 28 |
| append entity-header to existing header fields |  | append entity-header to existing header fields |
| read entity-header |  | read entity-header |
| } |  | } |
| Content-Length := length |  | Content-Length := length |
| Remove "chunked" from Transfer-Encoding |  | Remove "chunked" from Transfer-Encoding |
| All HTTP/1.1 applications MUST be able to receive and decode the |  | All HTTP/1.1 applications MUST be able to receive and decode the |
| "chunked" transfer-coding, and MUST ignore chunk-extension extensions |  | "chunked" transfer-coding, and MUST ignore chunk-extension extensions |
| they do not understand. |  | they do not understand. |
|  |  | 3.5. 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 white space. 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). |
| 4. HTTP Message |  | 4. HTTP Message |
| 4.1. Message Types |  | 4.1. Message Types |
| HTTP messages consist of requests from client to server and responses |  | HTTP messages consist of requests from client to server and responses |
| from server to client. |  | from server to client. |
| HTTP-message = Request | Response ; HTTP/1.1 messages |  | HTTP-message = Request | Response ; HTTP/1.1 messages |
| Request (Section 5) and Response (Section 6) messages use the generic |  | Request (Section 5) and Response (Section 6) messages use the generic |
| skipping to change at page 23, line 16 |  | skipping to change at page 24, line 41 |
| Certain buggy HTTP/1.0 client implementations generate extra CRLF's |  | Certain buggy HTTP/1.0 client implementations generate extra CRLF's |
| after a POST request. To restate what is explicitly forbidden by the |  | 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 |  | BNF, an HTTP/1.1 client MUST NOT preface or follow a request with an |
| extra CRLF. |  | extra CRLF. |
| 4.2. Message Headers |  | 4.2. Message Headers |
| HTTP header fields, which include general-header (Section 4.5), |  | HTTP header fields, which include general-header (Section 4.5), |
| request-header (Section 4 of [Part2]), response-header (Section 6 of |  | request-header (Section 4 of [Part2]), response-header (Section 6 of |
| [Part2]), and entity-header (Section 3.1 of [Part3]) fields, follow |  | [Part2]), and entity-header (Section 4.1 of [Part3]) fields, follow |
| the same generic format as that given in Section 2.1 of [RFC2822]. |  | the same generic format as that given in Section 2.1 of [RFC2822]. |
| Each header field consists of a name followed by a colon (":") and |  | Each header field consists of a name followed by a colon (":") and |
| the field value. Field names are case-insensitive. The field value |  | the field value. Field names are case-insensitive. The field value |
| MAY be preceded by any amount of LWS, though a single SP is |  | MAY be preceded by any amount of LWS, though a single SP is |
| preferred. Header fields can be extended over multiple lines by |  | preferred. Header fields can be extended over multiple lines by |
| preceding each extra line with at least one SP or HTAB. Applications |  | preceding each extra line with at least one SP or HTAB. Applications |
| ought to follow "common form", where one is known or indicated, when |  | ought to follow "common form", where one is known or indicated, when |
| generating HTTP constructs, since there might exist some |  | generating HTTP constructs, since there might exist some |
| implementations that fail to accept anything beyond the common forms. |  | implementations that fail to accept anything beyond the common forms. |
| message-header = field-name ":" [ field-value ] |  | message-header = field-name ":" [ field-value ] |
| field-name = token |  | field-name = token |
| field-value = *( field-content | LWS ) |  | field-value = *( field-content | LWS ) |
| field-content = <the OCTETs making up the field-value |  | field-content = <field content> |
| and consisting of either *TEXT or combinations |  | ; the OCTETs making up the field-value |
| of token, separators, and quoted-string> |  | ; and consisting of either *TEXT or combinations |
|  |  | ; of token, separators, and quoted-string |
| The field-content does not include any leading or trailing LWS: |  | The field-content does not include any leading or trailing LWS: |
| linear white space occurring before the first non-whitespace |  | linear white space 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. Such leading or trailing LWS MAY be |  | character of the field-value. Such leading or trailing LWS MAY be |
| removed without changing the semantics of the field value. Any LWS |  | removed without changing the semantics of the field value. Any LWS |
| that occurs between field-content MAY be replaced with a single SP |  | that occurs between field-content MAY be replaced with a single SP |
| before interpreting the field value or forwarding the message |  | before interpreting the field value or forwarding the message |
| downstream. |  | downstream. |
| skipping to change at page 24, line 36 |  | skipping to change at page 26, line 14 |
| request/response chain. (However, Section 3.4 places restrictions on |  | request/response chain. (However, Section 3.4 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. A message-body MUST NOT be included |  | the request's message-headers. A message-body MUST NOT be included |
| in a request if the specification of the request method (Section 3 of |  | in a request if the specification of the request method (Section 3 of |
| [Part2]) does not allow sending an entity-body in requests. A server |  | [Part2]) explicitly disallows an entity-body in requests. When a |
| SHOULD read and forward a message-body on any request; if the request |  | request message contains both a message-body of non-zero length and a |
| method does not include defined semantics for an entity-body, then |  | method that does not define any semantics for that request message- |
| the message-body SHOULD be ignored when handling the request. |  | body, then an origin server SHOULD either ignore the message-body or |
|  |  | respond with an appropriate error message (e.g., 413). A proxy or |
|  |  | gateway, when presented the same request, SHOULD either forward the |
|  |  | request inbound with the message-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 6.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. |
| skipping to change at page 26, line 30 |  | skipping to change at page 28, line 12 |
| 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 |  | 4.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 15.2 |  | general-header = Cache-Control ; [Part6], Section 16.2 |
| | Connection ; Section 8.1 |  | | Connection ; Section 8.1 |
| | Date ; Section 8.3 |  | | Date ; Section 8.3 |
| | Pragma ; [Part6], Section 15.4 |  | | Pragma ; [Part6], Section 16.4 |
| | Trailer ; Section 8.6 |  | | Trailer ; Section 8.6 |
| | Transfer-Encoding ; Section 8.7 |  | | Transfer-Encoding ; Section 8.7 |
| | Upgrade ; Section 8.8 |  | | Upgrade ; Section 8.8 |
| | Via ; Section 8.9 |  | | Via ; Section 8.9 |
| | Warning ; [Part6], Section 15.6 |  | | Warning ; [Part6], Section 16.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 |  | 5. 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 5.1 |
| *(( general-header ; Section 4.5 |  | *(( general-header ; Section 4.5 |
| | request-header ; [Part2], Section 4 |  | | request-header ; [Part2], Section 4 |
| | entity-header ) CRLF) ; [Part3], Section 3.1 |  | | entity-header ) CRLF) ; [Part3], Section 4.1 |
| CRLF |  | CRLF |
| [ message-body ] ; Section 4.3 |  | [ message-body ] ; Section 4.3 |
| 5.1. Request-Line |  | 5.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- |
| URI and the protocol version, and ending with CRLF. The elements are |  | URI and the protocol version, and ending with CRLF. The elements are |
| separated by SP characters. No CR or LF is allowed except in the |  | separated by SP characters. No CR or LF is allowed except in the |
| final CRLF sequence. |  | final CRLF sequence. |
| skipping to change at page 27, line 36 |  | skipping to change at page 29, line 19 |
| Method = token |  | Method = token |
| 5.1.2. Request-URI |  | 5.1.2. Request-URI |
| The Request-URI is a Uniform Resource Identifier (Section 3.2) and |  | The Request-URI is a Uniform Resource Identifier (Section 3.2) and |
| identifies the resource upon which to apply the request. |  | identifies the resource upon which to apply the request. |
| Request-URI = "*" |  | Request-URI = "*" |
| | absoluteURI |  | | absoluteURI |
| | ( abs_path [ "?" query ] ) |  | | ( path-absolute [ "?" query ] ) |
| | authority |  | | authority |
| The four options for Request-URI are dependent on the nature of the |  | The four options for Request-URI are dependent on the nature of the |
| request. The asterisk "*" means that the request does not apply to a |  | request. The asterisk "*" means that the request does not apply to a |
| particular resource, but to the server itself, and is only allowed |  | particular resource, but to the server itself, and is only allowed |
| when the method used does not necessarily apply to a resource. One |  | when the method used does not necessarily apply to a resource. One |
| example would be |  | example would be |
| OPTIONS * HTTP/1.1 |  | OPTIONS * HTTP/1.1 |
| skipping to change at page 28, line 20 |  | skipping to change at page 29, line 51 |
| To allow for transition to absoluteURIs in all requests in future |  | To allow for transition to absoluteURIs in all requests in future |
| versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI |  | versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI |
| 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 8.9 of |  | The authority form is only used by the CONNECT method (Section 8.9 of |
| [Part2]). |  | [Part2]). |
| The most common form of Request-URI is that used to identify a |  | The most common form of Request-URI 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 3.2.1, abs_path) as |  | path of the URI MUST be transmitted (see Section 3.2.1, path- |
| the Request-URI, and the network location of the URI (authority) MUST |  | absolute) as the Request-URI, and the network location of the URI |
| be transmitted in a Host header field. For example, a client wishing |  | (authority) MUST be transmitted in a Host header field. For example, |
| to retrieve the resource above directly from the origin server would |  | a client wishing to retrieve the resource above directly from the |
| create a TCP connection to port 80 of the host "www.example.org" and |  | origin server would create a TCP connection to port 80 of the host |
| 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 |
| path cannot be empty; if none is present in the original URI, it MUST |  | path cannot be empty; if none is present in the original URI, it MUST |
| be given as "/" (the server root). |  | be given as "/" (the server root). |
| The Request-URI is transmitted in the format specified in |  | The Request-URI is transmitted in the format specified in |
| Section 3.2.1. If the Request-URI is encoded using the "% HEX HEX" |  | Section 3.2.1. If the Request-URI is encoded using the "% HEX HEX" |
| encoding [RFC2396], the origin server MUST decode the Request-URI in |  | encoding [RFC2396], the origin server MUST decode the Request-URI in |
| order to properly interpret the request. Servers SHOULD respond to |  | order to properly interpret the request. Servers SHOULD respond to |
| invalid Request-URIs with an appropriate status code. |  | invalid Request-URIs with an appropriate status code. |
| A transparent proxy MUST NOT rewrite the "abs_path" part of the |  | A transparent proxy MUST NOT rewrite the "path-absolute" part of the |
| received Request-URI when forwarding it to the next inbound server, |  | received Request-URI when forwarding it to the next inbound server, |
| except as noted above to replace a null abs_path with "/". |  | 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 |
| meaning of the request when the origin server is improperly using |  | meaning of the request when the origin server is improperly using |
| a non-reserved URI character for a reserved purpose. Implementors |  | a non-reserved URI character for a reserved purpose. Implementors |
| should be aware that some pre-HTTP/1.1 proxies have been known to |  | should be aware that some pre-HTTP/1.1 proxies have been known to |
| rewrite the Request-URI. |  | rewrite the Request-URI. |
| 5.2. The Resource Identified by a Request |  | 5.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 |
| skipping to change at page 29, line 45 |  | skipping to change at page 31, line 26 |
| exact resource is being requested. |  | exact resource is being requested. |
| 6. Response |  | 6. 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 6.1 |
| *(( general-header ; Section 4.5 |  | *(( general-header ; Section 4.5 |
| | response-header ; [Part2], Section 6 |  | | response-header ; [Part2], Section 6 |
| | entity-header ) CRLF) ; [Part3], Section 3.1 |  | | entity-header ) CRLF) ; [Part3], Section 4.1 |
| CRLF |  | CRLF |
| [ message-body ] ; Section 4.3 |  | [ message-body ] ; Section 4.3 |
| 6.1. Status-Line |  | 6.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 |  | 6.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 9 of [Part2]. The Reason-Phrase is intended to |  | defined in Section 9 of [Part2]. The Reason Phrase exists for the |
| give a short textual description of the Status-Code. The Status-Code |  | sole purpose of providing a textual description associated with the |
| is intended for use by automata and the Reason-Phrase is intended for |  | numeric status code, out of deference to earlier Internet application |
| the human user. The client is not required to examine or display the |  | protocols that were more frequently used with interactive text |
| 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. |
| The last two digits do not have any categorization role. There are 5 |  | The last two digits do not have any categorization role. There are 5 |
| values for the first digit: |  | values for the first digit: |
| o 1xx: Informational - Request received, continuing process |  | o 1xx: Informational - Request received, continuing process |
| o 2xx: Success - The action was successfully received, understood, |  | o 2xx: Success - The action was successfully received, understood, |
| and accepted |  | and accepted |
| skipping to change at page 41, line 11 |  | skipping to change at page 42, line 33 |
| The Host request-header field 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, as obtained from the original |
| URI given by the user or referring resource (generally an HTTP URL, |  | URI given by the user or referring resource (generally an HTTP URL, |
| as described in Section 3.2.2). The Host field value MUST represent |  | as described in Section 3.2.2). The Host field value MUST represent |
| the naming authority of the origin server or gateway given by the |  | the naming authority of the origin server or gateway given by the |
| original URL. This allows the origin server or gateway to |  | original URL. This allows the origin server or gateway to |
| differentiate between internally-ambiguous URLs, such as the root "/" |  | differentiate between internally-ambiguous URLs, such as the root "/" |
| URL of a server for multiple host names on a single IP address. |  | URL of a server for multiple host names on a single IP address. |
| Host = "Host" ":" host [ ":" port ] ; Section 3.2.2 |  | Host = "Host" ":" uri-host [ ":" port ] ; Section 3.2.2 |
| 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 |
| skipping to change at page 42, line 31 |  | skipping to change at page 44, line 4 |
| 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 2.4 of |  | is accompanied by a qvalue of 0. (As defined in Section 3.4 of |
| [Part3], a qvalue of 0 means "not acceptable.") |  | [Part3], a 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. |
| skipping to change at page 45, line 9 |  | skipping to change at page 46, line 31 |
| agent and the server on requests, and between the origin server and |  | agent and the server on requests, and between the origin server and |
| the client on responses. It is analogous to the "Received" field of |  | the client on responses. It is analogous to the "Received" field of |
| [RFC2822] and is intended to be used for tracking message forwards, |  | [RFC2822] and is intended to be used for tracking message forwards, |
| avoiding request loops, and identifying the protocol capabilities of |  | avoiding request loops, and identifying the protocol capabilities of |
| all senders along the request/response chain. |  | all senders along the request/response chain. |
| Via = "Via" ":" 1#( received-protocol received-by [ comment ] ) |  | Via = "Via" ":" 1#( received-protocol received-by [ comment ] ) |
| received-protocol = [ protocol-name "/" ] protocol-version |  | received-protocol = [ protocol-name "/" ] protocol-version |
| protocol-name = token |  | protocol-name = token |
| protocol-version = token |  | protocol-version = token |
| received-by = ( host [ ":" port ] ) | pseudonym |  | received-by = ( uri-host [ ":" port ] ) | pseudonym |
| pseudonym = token |  | pseudonym = token |
| The received-protocol indicates the protocol version of the message |  | The received-protocol indicates the protocol version of the message |
| received by the server or client along each segment of the request/ |  | received by the server or client along each segment of the request/ |
| response chain. The received-protocol version is appended to the Via |  | response chain. The received-protocol version is appended to the Via |
| field value when the message is forwarded so that information about |  | field value when the message is forwarded so that information about |
| the protocol capabilities of upstream applications remains visible to |  | the protocol capabilities of upstream applications remains visible to |
| all recipients. |  | all recipients. |
| The protocol-name is optional if and only if it would be "HTTP". The |  | The protocol-name is optional if and only if it would be "HTTP". The |
| skipping to change at page 46, line 23 |  | skipping to change at page 47, line 45 |
| 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 |  | 9. IANA Considerations |
| TBD. |  | [[anchor1: TBD.]] |
| 10. Security Considerations |  | 10. 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 |  | 10.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 via the HTTP protocol to other sources. |  | leakage of this information. We very strongly recommend that a |
| We very strongly recommend that a convenient interface be provided |  | convenient interface be provided for the user to control |
| for the user to control dissemination of such information, and that |  | dissemination of such information, and that designers and |
| designers and implementors be particularly careful in this area. |  | implementors be particularly careful in this area. History shows |
| History shows that errors in this area often create serious security |  | that errors in this area often create serious security and/or privacy |
| and/or privacy problems and generate highly adverse publicity for the |  | problems and generate highly adverse publicity for the implementor's |
| implementor's company. |  | company. |
| 10.2. Abuse of Server Log Information |  | 10.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 the HTTP protocol to provide data are responsible for ensuring |  | using HTTP to provide data are responsible for ensuring that such |
| that such material is not distributed without the permission of any |  | material is not distributed without the permission of any individuals |
| individuals that are identifiable by the published results. |  | that are identifiable by the published results. |
| 10.3. Attacks Based On File and Path Names |  | 10.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 |
| skipping to change at page 49, line 14 |  | skipping to change at page 50, line 34 |
| 11. Acknowledgments |  | 11. Acknowledgments |
| 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 [RFC822ABNF]. Similarly, |  | constructs defined by David H. Crocker for [RFC822ABNF]. Similarly, |
| it reuses many of the definitions provided by Nathaniel Borenstein |  | it reuses many of the definitions provided by Nathaniel Borenstein |
| and Ned Freed for MIME [RFC2045]. We hope that their inclusion in |  | and Ned Freed for MIME [RFC2045]. We hope that their inclusion in |
| this specification will help reduce past confusion over the |  | this specification will help reduce past confusion over the |
| relationship between HTTP and Internet mail message formats. |  | relationship between HTTP and Internet mail message formats. |
| The HTTP protocol has evolved considerably over the years. It has |  | HTTP has evolved considerably over the years. It has benefited from |
| benefited from a large and active developer community--the many |  | a large and active developer community--the many people who have |
| people who have participated on the www-talk mailing list--and it is |  | participated on the www-talk mailing list--and it is that community |
| that community which has been most responsible for the success of |  | which has been most responsible for the success of HTTP and of the |
| HTTP and of the World-Wide Web in general. Marc Andreessen, Robert |  | World-Wide Web in general. Marc Andreessen, Robert Cailliau, Daniel |
| Cailliau, Daniel W. Connolly, Bob Denny, John Franks, Jean-Francois |  | W. Connolly, Bob Denny, John Franks, Jean-Francois Groff, Phillip M. |
| Groff, Phillip M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob |  | Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob McCool, Lou Montulli, |
| McCool, Lou Montulli, Dave Raggett, Tony Sanders, and Marc |  | Dave Raggett, Tony Sanders, and Marc VanHeyningen deserve special |
| VanHeyningen deserve special recognition for their efforts in |  | recognition for their efforts in defining early aspects of the |
| defining early aspects of the protocol. |  | protocol. |
| This document has benefited greatly from the comments of all those |  | This document has benefited greatly from the comments of all those |
| participating in the HTTP-WG. In addition to those already |  | participating in the HTTP-WG. In addition to those already |
| mentioned, the following individuals have contributed to this |  | mentioned, the following individuals have contributed to this |
| specification: |  | specification: |
| Gary Adams, Harald Tveit Alvestrand, Keith Ball, Brian Behlendorf, |  | Gary Adams, Harald Tveit Alvestrand, Keith Ball, Brian Behlendorf, |
| Paul Burchard, Maurizio Codogno, Mike Cowlishaw, Roman Czyborra, |  | Paul Burchard, Maurizio Codogno, Mike Cowlishaw, Roman Czyborra, |
| Michael A. Dolan, Daniel DuBois, David J. Fiander, Alan Freier, Marc |  | Michael A. Dolan, Daniel DuBois, David J. Fiander, Alan Freier, Marc |
| Hedlund, Greg Herlihy, Koen Holtman, Alex Hopmann, Bob Jernigan, Shel |  | Hedlund, Greg Herlihy, Koen Holtman, Alex Hopmann, Bob Jernigan, Shel |
| skipping to change at page 50, line 21 |  | skipping to change at page 51, line 43 |
| [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-01 (work in |  | Semantics", draft-ietf-httpbis-p2-semantics-02 (work in |
| progress), January 2008. |  | progress), February 2008. |
| [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-01 |  | and Content Negotiation", draft-ietf-httpbis-p3-payload-02 |
| (work in progress), January 2008. |  | (work in progress), February 2008. |
| [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-01 (work |  | Partial Responses", draft-ietf-httpbis-p5-range-02 (work |
| in progress), January 2008. |  | in progress), February 2008. |
| [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., |
| and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", |  | and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", |
| draft-ietf-httpbis-p6-cache-01 (work in progress), |  | draft-ietf-httpbis-p6-cache-02 (work in progress), |
| January 2008. |  | February 2008. |
| [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail |  | [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail |
| Extensions (MIME) Part One: Format of Internet Message |  | Extensions (MIME) Part One: Format of Internet Message |
| Bodies", RFC 2045, November 1996. |  | Bodies", RFC 2045, November 1996. |
| [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) |  | [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) |
| Part Three: Message Header Extensions for Non-ASCII Text", |  | Part Three: Message Header Extensions for Non-ASCII Text", |
| RFC 2047, November 1996. |  | RFC 2047, November 1996. |
| [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. |
| [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform |  | [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform |
| Resource Identifiers (URI): Generic Syntax", RFC 2396, |  | Resource Identifiers (URI): Generic Syntax", RFC 2396, |
| August 1998. |  | August 1998. |
| [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and |  |  |
| Registration Procedures", BCP 13, RFC 4288, December 2005. |  |  |
| [RFC822ABNF] |  | [RFC822ABNF] |
| Crocker, D., "Standard for the format of ARPA Internet |  | Crocker, D., "Standard for the format of ARPA Internet |
| text messages", STD 11, RFC 822, August 1982. |  | text messages", STD 11, RFC 822, August 1982. |
| [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 |  | 12.2. Informative References |
| skipping to change at page 52, line 47 |  | skipping to change at page 54, line 16 |
| [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, |  | [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, |
| April 2001. |  | April 2001. |
| [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, |  | [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, |
| April 2001. |  | April 2001. |
| [RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)", |  | [RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)", |
| RFC 3977, October 2006. |  | RFC 3977, October 2006. |
|  |  | [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and |
|  |  | Registration Procedures", BCP 13, RFC 4288, December 2005. |
| [RFC822] Crocker, D., "Standard for the format of ARPA Internet |  | [RFC822] Crocker, D., "Standard for the format of ARPA Internet |
| text messages", STD 11, RFC 822, August 1982. |  | text messages", STD 11, RFC 822, August 1982. |
| [RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol", |  | [RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol", |
| STD 9, RFC 959, October 1985. |  | STD 9, RFC 959, October 1985. |
| [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 |
| skipping to change at page 53, line 21 |  | skipping to change at page 54, line 41 |
| (original report dated Aug. 1996) |  | (original report dated Aug. 1996) |
| [WAIS] Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T., |  | [WAIS] Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T., |
| Wang, R., Sui, J., and M. Grinbaum, "WAIS Interface |  | Wang, R., Sui, J., and M. Grinbaum, "WAIS Interface |
| Protocol Prototype Functional Specification (v1.5)", |  | Protocol Prototype Functional Specification (v1.5)", |
| Thinking Machines Corporation , April 1990. |  | Thinking Machines Corporation , April 1990. |
| Appendix A. Internet Media Types |  | Appendix A. Internet Media Types |
| In addition to defining the HTTP/1.1 protocol, this document serves |  | In addition to defining HTTP/1.1, this document serves as the |
| as the specification for the Internet media type "message/http" and |  | specification for the Internet media type "message/http" and |
| "application/http". The following is to be registered with IANA |  | "application/http". The following is to be registered with IANA |
| [RFC4288]. |  | [RFC4288]. |
| A.1. Internet Media Type message/http |  | A.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 |
| skipping to change at page 59, line 25 |  | skipping to change at page 60, line 47 |
| 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.4, 3.4.1, and 8.5) |  | clients.(Section 3.4, 3.4.1, and 8.5) |
| D.4. Changes from RFC 2616 |  | D.4. Changes from RFC 2616 |
| Clarify that HTTP-Version is case sensitive. (Section 3.1) |  | The CHAR rule does not allow the NUL character anymore (this affects |
|  |  | the comment and quoted-string rules). (Section 2.2) |
|  |  | Clarify that HTTP-Version is case sensitive. (Section 3.1) |
| Remove reference to non-existant identity transfer-coding value |  | Remove reference to non-existant identity transfer-coding value |
| tokens. (Sections 3.4 and 4.4) |  | tokens. (Sections 3.4 and 4.4) |
| Clarification that the chunk length does not include the count of the |  | Clarification that the chunk length does not include the count of the |
| octets in the chunk header and trailer. (Section 3.4.1) |  | octets in the chunk header and trailer. (Section 3.4.1) |
| Fix BNF to add query, as the abs_path production in Section 3 of |  | Fix BNF to add query, as the abs_path production in Section 3 of |
| [RFC2396] doesn't define it. (Section 5.1.2) |  | [RFC2396] doesn't define it. (Section 5.1.2) |
| Clarify exactly when close connection options must be sent. |  | Clarify exactly when close connection options must be sent. |
| skipping to change at page 61, line 18 |  | skipping to change at page 62, line 45 |
| up-to-date references" |  | up-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 HTAB, fix broken ABNF |  | o Use names of RFC4234 core rules DQUOTE and HTAB, fix broken ABNF |
| for chunk-data (work in progress on |  | for chunk-data (work in progress on |
| <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36>) |  | <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36>) |
|  |  | E.3. Since draft-ietf-httpbis-p1-messaging-01 |
|  |  | Closed issues: |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/19>: "Bodies on |
|  |  | GET (and other) requests" |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/55>: "Updating |
|  |  | to RFC4288" |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/57>: "Status |
|  |  | Code and Reason Phrase" |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/82>: "rel_path |
|  |  | not used" |
|  |  | Ongoing work on ABNF conversion |
|  |  | (<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36>): |
|  |  | o Get rid of duplicate BNF rule names ("host" -> "uri-host", |
|  |  | "trailer" -> "trailer-part"). |
|  |  | o Avoid underscore character in rule names ("http_URL" -> "http- |
|  |  | URL", "abs_path" -> "path-absolute"). |
|  |  | o Add rules for terms imported from URI spec ("absoluteURI", |
|  |  | "authority", "path-absolute", "port", "query", "relativeURI", |
|  |  | "host) -- these will have to be updated when switching over to |
|  |  | RFC3986. |
|  |  | o Synchronize core rules with RFC5234 (this includes a change to |
|  |  | CHAR which now excludes NUL). |
|  |  | o Get rid of prose rules that span multiple lines. |
|  |  | o Get rid of unused rules LOALPHA and UPALPHA. |
|  |  | o Move "Product Tokens" section (back) into Part 1, as "token" is |
|  |  | used in the definition of the Upgrade header. |
|  |  | o Add explicit references to BNF syntax and rules imported from |
|  |  | other parts of the specification. |
|  |  | o Rewrite prose rule "token" in terms of "tchar", rewrite prose rule |
|  |  | "TEXT". |
| Index |  | Index |
| A |  | A |
| application/http Media Type 54 |  | application/http Media Type 56 |
| C |  | C |
| cache 8 |  | cache 8 |
| cacheable 9 |  | cacheable 9 |
| client 7 |  | client 7 |
| connection 6 |  | connection 6 |
| Connection header 38 |  | Connection header 39 |
| content negotiation 7 |  | content negotiation 7 |
| Content-Length header 39 |  | Content-Length header 40 |
| D |  | D |
| Date header 39 |  | Date header 41 |
| downstream 9 |  | downstream 9 |
| E |  | E |
| entity 7 |  | entity 7 |
| G |  | G |
| gateway 8 |  | gateway 8 |
| Grammar |  | Grammar |
|  |  | absoluteURI 18 |
| ALPHA 14 |  | ALPHA 14 |
| asctime-date 19 |  | asctime-date 20 |
| attribute 20 |  | attribute 20 |
|  |  | authority 18 |
| CHAR 14 |  | CHAR 14 |
| chunk 21 |  | chunk 22 |
| chunk-data 21 |  | chunk-data 22 |
| chunk-ext-name 21 |  | chunk-ext-name 22 |
| chunk-ext-val 21 |  | chunk-ext-val 22 |
| chunk-extension 21 |  | chunk-extension 22 |
| chunk-size 21 |  | chunk-size 22 |
| Chunked-Body 21 |  | Chunked-Body 22 |
| comment 15 |  | comment 15 |
| Connection 38 |  | Connection 39 |
| connection-token 38 |  | connection-token 39 |
| Content-Length 39 |  | Content-Length 40 |
| CR 14 |  | CR 14 |
| CRLF 14 |  | CRLF 14 |
| ctext 15 |  | ctext 15 |
| CTL 14 |  | CTL 14 |
| Date 39 |  | Date 41 |
| date1 19 |  | date1 20 |
| date2 19 |  | date2 20 |
| date3 19 |  | date3 20 |
| DIGIT 14 |  | DIGIT 14 |
| DQUOTE 14 |  | DQUOTE 14 |
| extension-code 30 |  | extension-code 32 |
| extension-method 27 |  | extension-method 29 |
| field-content 23 |  | field-content 25 |
| field-name 23 |  | field-name 25 |
| field-value 23 |  | field-value 25 |
| general-header 26 |  | general-header 28 |
| generic-message 22 |  | generic-message 24 |
| HEX 14 |  | HEX 15 |
| Host 41 |  | Host 42 |
| HTAB 14 |  | HTAB 14 |
| HTTP-date 19 |  | HTTP-date 20 |
| HTTP-message 22 |  | HTTP-message 24 |
|  |  | http-URL 18 |
| HTTP-Version 16 |  | HTTP-Version 16 |
| http_URL 17 |  | last-chunk 22 |
| last-chunk 21 |  |  |
| LF 14 |  | LF 14 |
| LOALPHA 14 |  |  |
| LWS 14 |  | LWS 14 |
| message-body 24 |  | message-body 25 |
| message-header 23 |  | message-header 25 |
| Method 27 |  | Method 29 |
| month 19 |  | month 20 |
| OCTET 14 |  | OCTET 14 |
| parameter 20 |  | parameter 20 |
| protocol-name 45 |  | path-absolute 18 |
| protocol-version 45 |  | port 18 |
| pseudonym 45 |  | product 23 |
|  |  | product-version 23 |
|  |  | protocol-name 46 |
|  |  | protocol-version 46 |
|  |  | pseudonym 46 |
| qdtext 15 |  | qdtext 15 |
|  |  | query 18 |
| quoted-pair 15 |  | quoted-pair 15 |
| quoted-string 15 |  | quoted-string 15 |
| Reason-Phrase 30 |  | Reason-Phrase 32 |
| received-by 45 |  | received-by 46 |
| received-protocol 45 |  | received-protocol 46 |
| Request 27 |  | relativeURI 18 |
| Request-Line 27 |  | Request 28 |
| Request-URI 27 |  | Request-Line 28 |
| Response 29 |  | Request-URI 29 |
| rfc850-date 19 |  | Response 31 |
| rfc1123-date 19 |  | rfc850-date 20 |
|  |  | rfc1123-date 20 |
| separators 15 |  | separators 15 |
| SP 14 |  | SP 14 |
| start-line 22 |  | start-line 24 |
| Status-Code 30 |  | Status-Code 32 |
| Status-Line 30 |  | Status-Line 31 |
| t-codings 41 |  | t-codings 43 |
| TE 41 |  | tchar 15 |
|  |  | TE 43 |
| TEXT 14 |  | TEXT 14 |
| time 19 |  | time 20 |
| token 15 |  | token 15 |
| Trailer 42 |  | Trailer 44 |
| trailer 21 |  | trailer-part 22 |
| transfer-coding 19 |  | transfer-coding 20 |
| Transfer-Encoding 43 |  | Transfer-Encoding 44 |
| transfer-extension 19 |  | transfer-extension 20 |
| UPALPHA 14 |  | Upgrade 45 |
| Upgrade 43 |  | uri-host 18 |
| value 20 |  | value 20 |
| Via 45 |  | Via 46 |
| weekday 19 |  | weekday 20 |
| wkday 19 |  | wkday 20 |
| H |  | H |
| Headers |  | Headers |
| Connection 38 |  | Connection 39 |
| Content-Length 39 |  | Content-Length 40 |
| Date 39 |  | Date 41 |
| Host 40 |  | Host 42 |
| TE 41 |  | TE 43 |
| Trailer 42 |  | Trailer 44 |
| Transfer-Encoding 43 |  | Transfer-Encoding 44 |
| Upgrade 43 |  | Upgrade 45 |
| Via 44 |  | Via 46 |
| Host header 40 |  | Host header 42 |
| I |  | I |
| inbound 9 |  | inbound 9 |
| M |  | M |
| Media Type |  | Media Type |
| application/http 54 |  | application/http 56 |
| message/http 53 |  | message/http 54 |
| message 6 |  | message 6 |
| message/http Media Type 53 |  | message/http Media Type 54 |
| O |  | O |
| origin server 8 |  | origin server 8 |
| outbound 9 |  | outbound 9 |
| P |  | P |
| proxy 8 |  | proxy 8 |
| R |  | R |
| representation 7 |  | representation 7 |
| request 6 |  | request 6 |
| resource 7 |  | resource 7 |
| response 6 |  | response 6 |
| S |  | S |
| server 8 |  | server 8 |
| T |  | T |
| TE header 41 |  | TE header 43 |
| Trailer header 42 |  | Trailer header 44 |
| Transfer-Encoding header 43 |  | Transfer-Encoding header 44 |
| tunnel 8 |  | tunnel 8 |
| U |  | U |
| Upgrade header 43 |  | Upgrade header 45 |
| upstream 9 |  | upstream 9 |
| user agent 7 |  | user agent 7 |
| V |  | V |
| variant 7 |  | variant 7 |
| Via header 44 |  | 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. 90 change blocks.
| 270 lines changed or deleted |  | 396 lines changed or added |
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/