| draft-ietf-httpbis-p1-messaging-00.txt |  | draft-ietf-httpbis-p1-messaging-01.txt |
--- | --- | --- | --- | ---
| Network Working Group R. Fielding, Ed. |  | Network Working Group R. Fielding, Ed. |
| Internet-Draft Day Software |  | Internet-Draft Day Software |
| Obsoletes: 2068, 2616 J. Gettys |  | Obsoletes: 2616 (if approved) J. Gettys |
| (if approved) One Laptop per Child |  | Intended status: Standards Track One Laptop per Child |
| Intended status: Standards Track J. Mogul |  | Expires: July 15, 2008 J. Mogul |
| Expires: June 22, 2008 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 |
| December 20, 2007 |  | Y. Lafon, Ed. |
|  |  | W3C |
|  |  | J. Reschke, Ed. |
|  |  | greenbytes |
|  |  | January 12, 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-00 |  | draft-ietf-httpbis-p1-messaging-01 |
| 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 45 |  | 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 June 22, 2008. |  | This Internet-Draft will expire on July 15, 2008. |
| Copyright Notice |  | Copyright Notice |
| Copyright (C) The IETF Trust (2007). |  | 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 |
| information initiative since 1990. This document is Part 1 of the |  | information initiative since 1990. This document is Part 1 of the |
| seven-part specification that defines the protocol referred to as |  | seven-part specification that defines the protocol referred to as |
| "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides |  | "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides |
| an overview of HTTP and its associated terminology, defines the |  | an overview of HTTP and its associated terminology, defines the |
| "http" and "https" Uniform Resource Identifier (URI) schemes, defines |  | "http" and "https" Uniform Resource Identifier (URI) schemes, defines |
| the generic message syntax and parsing requirements for HTTP message |  | the generic message syntax and parsing requirements for HTTP message |
| frames, and describes general security concerns for implementations. |  | frames, and describes general security concerns for implementations. |
| Editorial Note (To be removed by RFC Editor) |  | Editorial Note (To be removed by RFC Editor) |
| This version of the HTTP specification contains only minimal |  |  |
| editorial changes from [RFC2616] (abstract, introductory paragraph, |  |  |
| and authors' addresses). All other changes are due to partitioning |  |  |
| the original into seven mostly independent parts. The intent is for |  |  |
| readers of future drafts to able to use draft 00 as the basis for |  |  |
| comparison when the WG makes later changes to the specification text. |  |  |
| This draft will shortly be followed by draft 01 (containing the first |  |  |
| round of changes that have already been agreed to on the mailing |  |  |
| list). There is no point in reviewing this draft other than to |  |  |
| verify that the partitioning has been done correctly. Roy T. |  |  |
| Fielding, Yves Lafon, and Julian Reschke will be the editors after |  |  |
| draft 00 is submitted. |  |  |
| Discussion of this draft should take place on the HTTPBIS working |  | Discussion of this draft should take place on the HTTPBIS working |
| group mailing list (ietf-http-wg@w3.org). The current issues list is |  | group mailing list (ietf-http-wg@w3.org). The current issues list is |
| at <http://www3.tools.ietf.org/wg/httpbis/trac/report/11> and related |  | at <http://www.tools.ietf.org/wg/httpbis/trac/report/11> and related |
| documents (including fancy diffs) can be found at |  | documents (including fancy diffs) can be found at |
| <http://www3.tools.ietf.org/wg/httpbis/>. |  | <http://www.tools.ietf.org/wg/httpbis/>. |
|  |  | This draft incorporates those issue resolutions that were either |
|  |  | collected in the original RFC2616 errata list |
|  |  | (<http://purl.org/NET/http-errata>), or which were agreed upon on the |
|  |  | mailing list between October 2006 and November 2007 (as published in |
|  |  | "draft-lafon-rfc2616bis-03"). |
| 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 |  | 3. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 15 |
| 3.1. HTTP Version . . . . . . . . . . . . . . . . . . . . . . . 15 |  | 3.1. HTTP Version . . . . . . . . . . . . . . . . . . . . . . . 15 |
| 3.2. Uniform Resource Identifiers . . . . . . . . . . . . . . . 16 |  | 3.2. Uniform Resource Identifiers . . . . . . . . . . . . . . . 16 |
| 3.2.1. General Syntax . . . . . . . . . . . . . . . . . . . . 16 |  | 3.2.1. General Syntax . . . . . . . . . . . . . . . . . . . . 17 |
| 3.2.2. http URL . . . . . . . . . . . . . . . . . . . . . . . 17 |  | 3.2.2. http URL . . . . . . . . . . . . . . . . . . . . . . . 17 |
| 3.2.3. URI Comparison . . . . . . . . . . . . . . . . . . . . 17 |  | 3.2.3. URI Comparison . . . . . . . . . . . . . . . . . . . . 18 |
| 3.3. Date/Time Formats . . . . . . . . . . . . . . . . . . . . 18 |  | 3.3. Date/Time Formats . . . . . . . . . . . . . . . . . . . . 18 |
| 3.3.1. Full Date . . . . . . . . . . . . . . . . . . . . . . 18 |  | 3.3.1. Full Date . . . . . . . . . . . . . . . . . . . . . . 18 |
| 3.4. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 19 |  | 3.4. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 19 |
| 3.4.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 20 |  | 3.4.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 20 |
| 4. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . . 22 |  | 4. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . . 22 |
| 4.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 22 |  | 4.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 22 |
| 4.2. Message Headers . . . . . . . . . . . . . . . . . . . . . 23 |  | 4.2. Message Headers . . . . . . . . . . . . . . . . . . . . . 23 |
| 4.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 24 |  | 4.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 24 |
| 4.4. Message Length . . . . . . . . . . . . . . . . . . . . . . 25 |  | 4.4. Message Length . . . . . . . . . . . . . . . . . . . . . . 25 |
| 4.5. General Header Fields . . . . . . . . . . . . . . . . . . 26 |  | 4.5. General Header Fields . . . . . . . . . . . . . . . . . . 26 |
| 5. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 |  | 5. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 |
| 5.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 27 |  | 5.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 27 |
| 5.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 27 |  | 5.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 27 |
| 5.1.2. Request-URI . . . . . . . . . . . . . . . . . . . . . 27 |  | 5.1.2. Request-URI . . . . . . . . . . . . . . . . . . . . . 27 |
| 5.2. The Resource Identified by a Request . . . . . . . . . . . 28 |  | 5.2. The Resource Identified by a Request . . . . . . . . . . . 29 |
| 6. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 |  | 6. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 |
| 6.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 29 |  | 6.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 30 |
| 6.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 30 |  | 6.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 30 |
| 7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 30 |  | 7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 30 |
| 7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 30 |  | 7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 31 |
| 7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 30 |  | 7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 31 |
| 7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 31 |  | 7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 31 |
| 7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 33 |  | 7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 33 |
| 7.1.4. Practical Considerations . . . . . . . . . . . . . . . 33 |  | 7.1.4. Practical Considerations . . . . . . . . . . . . . . . 33 |
| 7.2. Message Transmission Requirements . . . . . . . . . . . . 34 |  | 7.2. Message Transmission Requirements . . . . . . . . . . . . 34 |
| 7.2.1. Persistent Connections and Flow Control . . . . . . . 34 |  | 7.2.1. Persistent Connections and Flow Control . . . . . . . 34 |
| 7.2.2. Monitoring Connections for Error Status Messages . . . 34 |  | 7.2.2. Monitoring Connections for Error Status Messages . . . 34 |
| 7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 34 |  | 7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 35 |
| 7.2.4. Client Behavior if Server Prematurely Closes |  | 7.2.4. Client Behavior if Server Prematurely Closes |
| Connection . . . . . . . . . . . . . . . . . . . . . . 36 |  | Connection . . . . . . . . . . . . . . . . . . . . . . 37 |
| 8. Header Field Definitions . . . . . . . . . . . . . . . . . . . 37 |  | 8. Header Field Definitions . . . . . . . . . . . . . . . . . . . 37 |
| 8.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 37 |  | 8.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 38 |
| 8.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 38 |  | 8.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 39 |
| 8.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 |  | 8.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 |
| 8.3.1. Clockless Origin Server Operation . . . . . . . . . . 40 |  | 8.3.1. Clockless Origin Server Operation . . . . . . . . . . 40 |
| 8.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 |  | 8.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 |
| 8.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 |  | 8.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 |
| 8.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 42 |  | 8.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 42 |
| 8.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 43 |  | 8.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 43 |
| 8.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 43 |  | 8.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 43 |
| 8.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 |  | 8.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 |
| 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 |  | 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 |
| 10. Security Considerations . . . . . . . . . . . . . . . . . . . 46 |  | 10. Security Considerations . . . . . . . . . . . . . . . . . . . 46 |
| 10.1. Personal Information . . . . . . . . . . . . . . . . . . . 46 |  | 10.1. Personal Information . . . . . . . . . . . . . . . . . . . 46 |
| 10.2. Abuse of Server Log Information . . . . . . . . . . . . . 46 |  | 10.2. Abuse of Server Log Information . . . . . . . . . . . . . 46 |
| 10.3. Attacks Based On File and Path Names . . . . . . . . . . . 46 |  | 10.3. Attacks Based On File and Path Names . . . . . . . . . . . 47 |
| 10.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 47 |  | 10.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 47 |
| 10.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 47 |  | 10.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 48 |
| 10.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 48 |  | 10.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 48 |
| 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 48 |  | 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 49 |
| 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50 |  | 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50 |
| Appendix A. Internet Media Type message/http and |  | 12.1. Normative References . . . . . . . . . . . . . . . . . . . 50 |
| application/http . . . . . . . . . . . . . . . . . . 53 |  | 12.2. Informative References . . . . . . . . . . . . . . . . . . 51 |
| Appendix B. Tolerant Applications . . . . . . . . . . . . . . . . 54 |  | Appendix A. Internet Media Types . . . . . . . . . . . . . . . . 53 |
| Appendix C. Conversion of Date Formats . . . . . . . . . . . . . 55 |  | A.1. Internet Media Type message/http . . . . . . . . . . . . . 53 |
| Appendix D. Compatibility with Previous Versions . . . . . . . . 55 |  | A.2. Internet Media Type application/http . . . . . . . . . . . 54 |
| D.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 56 |  | Appendix B. Tolerant Applications . . . . . . . . . . . . . . . . 55 |
|  |  | Appendix C. Conversion of Date Formats . . . . . . . . . . . . . 56 |
|  |  | Appendix D. Compatibility with Previous Versions . . . . . . . . 56 |
|  |  | D.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 57 |
| 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 . . . . . . . . . . . . . . . . 56 |  | Conserve IP Addresses . . . . . . . . . . . . . . . . 57 |
| D.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 56 |  | D.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 58 |
| D.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 57 |  | D.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 58 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 |  | D.4. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 59 |
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 61 |  | Appendix E. Change Log (to be removed by RFC Editor before |
| Intellectual Property and Copyright Statements . . . . . . . . . . 63 |  | publication) . . . . . . . . . . . . . . . . . . . . 59 |
|  |  | E.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 59 |
|  |  | E.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 59 |
|  |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 |
|  |  | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 64 |
|  |  | Intellectual Property and Copyright Statements . . . . . . . . . . 68 |
| 1. Introduction |  | 1. Introduction |
| This document will define aspects of HTTP related to overall network |  |  |
| operation, message framing, interaction with transport protocols, and |  |  |
| URI schemes. Right now it only includes the extracted relevant |  |  |
| sections of [RFC2616]. |  |  |
| 1.1. Purpose |  |  |
| 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, |
| referred to as HTTP/0.9, was a simple protocol for raw data transfer |  | commonly referred to as HTTP/0.9, was a simple protocol for raw data |
| across the Internet. HTTP/1.0, as defined by RFC 1945 [RFC1945], |  | transfer across the Internet with only a single method and no |
| improved the protocol by allowing messages to be in the format of |  | metadata. HTTP/1.0, as defined by [RFC1945], improved the protocol |
| MIME-like messages, containing metainformation about the data |  | by allowing messages to be in the format of MIME-like messages, |
| transferred and modifiers on the request/response semantics. |  | containing metadata about the data transferred and modifiers on the |
| However, HTTP/1.0 does not sufficiently take into consideration the |  | request/response semantics. However, HTTP/1.0 did not sufficiently |
| effects of hierarchical proxies, caching, the need for persistent |  | take into consideration the effects of hierarchical proxies, caching, |
| connections, or virtual hosts. In addition, the proliferation of |  | the need for persistent connections, or name-based virtual hosts. In |
| incompletely-implemented applications calling themselves "HTTP/1.0" |  | addition, the proliferation of incompletely-implemented applications |
| has necessitated a protocol version change in order for two |  | calling themselves "HTTP/1.0" necessitated a protocol version change |
| communicating applications to determine each other's true |  | in order for two communicating applications to determine each other's |
| capabilities. |  | true capabilities. |
| This specification defines the protocol referred to as "HTTP/1.1". |  | This document is Part 1 of the seven-part specification that defines |
| This protocol includes more stringent requirements than HTTP/1.0 in |  | the protocol referred to as "HTTP/1.1", obsoleting [RFC2616]. |
| order to ensure reliable implementation of its features. |  | HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent |
|  |  | requirements that enable reliable implementations and adding only |
|  |  | those new features that will either be safely ignored by an HTTP/1.0 |
|  |  | recipient or only sent when communicating with a party advertising |
|  |  | compliance with HTTP/1.1. Part 1 defines those aspects of HTTP/1.1 |
|  |  | related to overall network operation, message framing, interaction |
|  |  | with transport protocols, and URI schemes. |
|  |  | This document is currently disorganized in order to minimize the |
|  |  | changes between drafts and enable reviewers to see the smaller errata |
|  |  | changes. The next draft will reorganize the sections to better |
|  |  | reflect the content. In particular, the sections will be organized |
|  |  | according to the typical process of deciding when to use HTTP (URI |
|  |  | schemes), overall network operation, connection management, message |
|  |  | framing, and generic message parsing. The current mess reflects how |
|  |  | widely dispersed these topics and associated requirements had become |
|  |  | in [RFC2616]. |
|  |  | 1.1. Purpose |
| Practical information systems require more functionality than simple |  | Practical information systems require more functionality than simple |
| retrieval, including search, front-end update, and annotation. HTTP |  | retrieval, including search, front-end update, and annotation. HTTP |
| allows an open-ended set of methods and headers that indicate the |  | allows an open-ended set of methods and headers that indicate the |
| purpose of a request [RFC2324]. It builds on the discipline of |  | purpose of a request [RFC2324]. It builds on the discipline of |
| reference provided by the Uniform Resource Identifier (URI) |  | reference provided by the Uniform Resource Identifier (URI) |
| [RFC1630], as a location (URL) [RFC1738] or name (URN) [RFC1737], for |  | [RFC1630], as a location (URL) [RFC1738] or name (URN) [RFC1737], for |
| indicating the resource to which a method is to be applied. Messages |  | indicating the resource to which a method is to be applied. Messages |
| are passed in a format similar to that used by Internet mail [RFC822] |  | are passed in a format similar to that used by Internet mail |
| as defined by the Multipurpose Internet Mail Extensions (MIME) |  | [RFC2822] as defined by the Multipurpose Internet Mail Extensions |
| [RFC2045]. |  | (MIME) [RFC2045]. |
| HTTP is also used as a generic protocol for communication between |  | HTTP is also used as a generic protocol for communication between |
| user agents and proxies/gateways to other Internet systems, including |  | user agents and proxies/gateways to other Internet systems, including |
| those supported by the SMTP [RFC821], NNTP [RFC977], FTP [RFC959], |  | those supported by the SMTP [RFC2821], NNTP [RFC3977], FTP [RFC959], |
| Gopher [RFC1436], and WAIS [WAIS] protocols. In this way, HTTP |  | Gopher [RFC1436], and WAIS [WAIS] protocols. In this way, HTTP |
| allows basic hypermedia access to resources available from diverse |  | allows basic hypermedia access to resources available from diverse |
| applications. |  | applications. |
| 1.2. Requirements |  | 1.2. Requirements |
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |  | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |  | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |
| document are to be interpreted as described in RFC 2119 [RFC2119]. |  | document are to be interpreted as described in [RFC2119]. |
| An implementation is not compliant if it fails to satisfy one or more |  | An implementation is not compliant if it fails to satisfy one or more |
| of the MUST or REQUIRED level requirements for the protocols it |  | of the MUST or REQUIRED level requirements for the protocols it |
| implements. An implementation that satisfies all the MUST or |  | implements. An implementation that satisfies all the MUST or |
| REQUIRED level and all the SHOULD level requirements for its |  | REQUIRED level and all the SHOULD level requirements for its |
| protocols is said to be "unconditionally compliant"; one that |  | protocols is said to be "unconditionally compliant"; one that |
| satisfies all the MUST level requirements but not all the SHOULD |  | satisfies all the MUST level requirements but not all the SHOULD |
| level requirements for its protocols is said to be "conditionally |  | level requirements for its protocols is said to be "conditionally |
| compliant." |  | compliant." |
| skipping to change at page 7, line 27 |  | skipping to change at page 7, line 38 |
| 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 4 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 `varriant'. 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. |
| client |  | client |
| A program that establishes connections for the purpose of sending |  | A program that establishes connections for the purpose of sending |
| requests. |  | requests. |
| user agent |  | user agent |
| skipping to change at page 8, line 42 |  | skipping to change at page 9, line 4 |
| tunnel |  | tunnel |
| An intermediary program which is acting as a blind relay between |  | An intermediary program which is acting as a blind relay between |
| two connections. Once active, a tunnel is not considered a party |  | two connections. Once active, a tunnel is not considered a party |
| to the HTTP communication, though the tunnel may have been |  | to the HTTP communication, though the tunnel may have been |
| initiated by an HTTP request. The tunnel ceases to exist when |  | initiated by an HTTP request. The tunnel ceases to exist when |
| both ends of the relayed connections are closed. |  | both ends of the relayed connections are closed. |
| cache |  | cache |
| A program's local store of response messages and the subsystem |  | A program's local store of response messages and the subsystem |
| that controls its message storage, retrieval, and deletion. A |  | that controls its message storage, retrieval, and deletion. A |
| cache stores cacheable responses in order to reduce the response |  | cache stores cacheable responses in order to reduce the response |
| time and network bandwidth consumption on future, equivalent |  | time and network bandwidth consumption on future, equivalent |
| requests. Any client or server may include a cache, though a |  | requests. Any client or server may include a cache, though a |
| cache cannot be used by a server that is acting as a tunnel. |  | cache cannot be used by a server that is acting as a tunnel. |
| cacheable |  | cacheable |
| A response is cacheable if a cache is allowed to store a copy of |  | A response is cacheable if a cache is allowed to store a copy of |
| the response message for use in answering subsequent requests. |  | the response message for use in answering subsequent requests. |
| The rules for determining the cacheability of HTTP responses are |  | The rules for determining the cacheability of HTTP responses are |
| defined in Section 2 of [Part6]. Even if a resource is cacheable, |  | defined in Section 1 of [Part6]. Even if a resource is cacheable, |
| there may be additional constraints on whether a cache can use the |  | there may be additional constraints on whether a cache can use the |
| cached copy for a particular request. |  | cached copy for a particular request. |
| upstream/downstream |  | upstream/downstream |
| Upstream and downstream describe the flow of a message: all |  | Upstream and downstream describe the flow of a message: all |
| messages flow from upstream to downstream. |  | messages flow from upstream to downstream. |
| inbound/outbound |  | inbound/outbound |
| skipping to change at page 10, line 40 |  | skipping to change at page 10, line 49 |
| cached copy of an earlier response from O (via C) for a request which |  | cached copy of an earlier response from O (via C) for a request which |
| has not been cached by UA or A. |  | has not been cached by UA or A. |
| request chain ----------> |  | request chain ----------> |
| UA -----v----- A -----v----- B - - - - - - C - - - - - - O |  | UA -----v----- A -----v----- B - - - - - - C - - - - - - O |
| <--------- response chain |  | <--------- response chain |
| Not all responses are usefully cacheable, and some requests may |  | Not all responses are usefully cacheable, and some requests may |
| contain modifiers which place special requirements on cache behavior. |  | contain modifiers which place special requirements on cache behavior. |
| HTTP requirements for cache behavior and cacheable responses are |  | HTTP requirements for cache behavior and cacheable responses are |
| defined in Section 2 of [Part6]. |  | defined in Section 1 of [Part6]. |
| In fact, there are a wide variety of architectures and configurations |  | In fact, there are a wide variety of architectures and configurations |
| of caches and proxies currently being experimented with or deployed |  | of caches and proxies currently being experimented with or deployed |
| across the World Wide Web. These systems include national hierarchies |  | across the World Wide Web. These systems include national hierarchies |
| of proxy caches to save transoceanic bandwidth, systems that |  | of proxy caches to save transoceanic bandwidth, systems that |
| broadcast or multicast cache entries, organizations that distribute |  | broadcast or multicast cache entries, organizations that distribute |
| subsets of cached data via CD-ROM, and so on. HTTP systems are used |  | subsets of cached data via CD-ROM, and so on. HTTP systems are used |
| in corporate intranets over high-bandwidth links, and for access via |  | in corporate intranets over high-bandwidth links, and for access via |
| PDAs with low-power radio links and intermittent connectivity. The |  | PDAs with low-power radio links and intermittent connectivity. The |
| goal of HTTP/1.1 is to support the wide diversity of configurations |  | goal of HTTP/1.1 is to support the wide diversity of configurations |
| already deployed while introducing protocol constructs that meet the |  | already deployed while introducing protocol constructs that meet the |
| needs of those who build web applications that require high |  | needs of those who build web applications that require high |
| reliability and, failing that, at least reliable indications of |  | reliability and, failing that, at least reliable indications of |
| failure. |  | failure. |
| HTTP communication usually takes place over TCP/IP connections. The |  | HTTP communication usually takes place over TCP/IP connections. The |
| default port is TCP 80 [RFC1700], but other ports can be used. This |  | default port is TCP 80 |
| does not preclude HTTP from being implemented on top of any other |  | (<http://www.iana.org/assignments/port-numbers>), but other ports can |
| protocol on the Internet, or on other networks. HTTP only presumes a |  | be used. This does not preclude HTTP from being implemented on top |
| reliable transport; any protocol that provides such guarantees can be |  | of any other protocol on the Internet, or on other networks. HTTP |
| used; the mapping of the HTTP/1.1 request and response structures |  | only presumes a reliable transport; any protocol that provides such |
| onto the transport data units of the protocol in question is outside |  | guarantees can be used; the mapping of the HTTP/1.1 request and |
| the scope of this specification. |  | response structures onto the transport data units of the protocol in |
|  |  | question is outside the scope of this specification. |
| In HTTP/1.0, most implementations used a new connection for each |  | In HTTP/1.0, most implementations used a new connection for each |
| request/response exchange. In HTTP/1.1, a connection may be used for |  | request/response exchange. In HTTP/1.1, a connection may be used for |
| one or more request/response exchanges, although connections may be |  | one or more request/response exchanges, although connections may be |
| closed for a variety of reasons (see Section 7.1). |  | closed for a variety of reasons (see Section 7.1). |
| 2. Notational Conventions and Generic Grammar |  | 2. Notational Conventions and Generic Grammar |
| 2.1. Augmented BNF |  | 2.1. Augmented BNF |
| All of the mechanisms specified in this document are described in |  | All of the mechanisms specified in this document are described in |
| both prose and an augmented Backus-Naur Form (BNF) similar to that |  | both prose and an augmented Backus-Naur Form (BNF) similar to that |
| used by RFC 822 [RFC822]. Implementors will need to be familiar with |  | used by [RFC822ABNF]. Implementors will need to be familiar with the |
| the notation in order to understand this specification. The |  | notation in order to understand this specification. The augmented |
| augmented BNF includes the following constructs: |  | BNF includes the following constructs: |
| name = definition |  | name = definition |
| The name of a rule is simply the name itself (without any |  | The name of a rule is simply the name itself (without any |
| enclosing "<" and ">") and is separated from its definition by the |  | enclosing "<" and ">") and is separated from its definition by the |
| equal "=" character. White space is only significant in that |  | equal "=" character. White space is only significant in that |
| indentation of continuation lines is used to indicate a rule |  | indentation of continuation lines is used to indicate a rule |
| definition that spans more than one line. Certain basic rules are |  | definition that spans more than one line. Certain basic rules are |
| in uppercase, such as SP, LWS, HT, CRLF, DIGIT, ALPHA, etc. Angle |  | in uppercase, such as SP, LWS, HTAB, CRLF, DIGIT, ALPHA, etc. |
| brackets are used within definitions whenever their presence will |  | Angle brackets are used within definitions whenever their presence |
| facilitate discerning the use of rule names. |  | will facilitate discerning the use of rule names. |
| "literal" |  | "literal" |
| Quotation marks surround literal text. Unless stated otherwise, |  | Quotation marks surround literal text. Unless stated otherwise, |
| the text is case-insensitive. |  | the text is case-insensitive. |
| rule1 | rule2 |  | rule1 | rule2 |
| Elements separated by a bar ("|") are alternatives, e.g., "yes | |  | Elements separated by a bar ("|") are alternatives, e.g., "yes | |
| no" will accept yes or no. |  | no" will accept yes or no. |
| (rule1 rule2) |  | (rule1 rule2) |
| Elements enclosed in parentheses are treated as a single element. |  | Elements enclosed in parentheses are treated as a single element. |
| Thus, "(elem (foo | bar) elem)" allows the token sequences "elem |  | Thus, "(elem (foo | bar) elem)" allows the token sequences "elem |
| foo elem" and "elem bar elem". |  | foo elem" and "elem bar elem". |
| *rule |  | *rule |
| skipping to change at page 13, line 43 |  | skipping to change at page 14, line 16 |
| CHAR = <any US-ASCII character (octets 0 - 127)> |  | CHAR = <any US-ASCII character (octets 0 - 127)> |
| UPALPHA = <any US-ASCII uppercase letter "A".."Z"> |  | UPALPHA = <any US-ASCII uppercase letter "A".."Z"> |
| LOALPHA = <any US-ASCII lowercase letter "a".."z"> |  | LOALPHA = <any US-ASCII lowercase letter "a".."z"> |
| ALPHA = UPALPHA | LOALPHA |  | ALPHA = UPALPHA | LOALPHA |
| DIGIT = <any US-ASCII digit "0".."9"> |  | DIGIT = <any US-ASCII digit "0".."9"> |
| CTL = <any US-ASCII control character |  | CTL = <any US-ASCII control character |
| (octets 0 - 31) and DEL (127)> |  | (octets 0 - 31) and DEL (127)> |
| CR = <US-ASCII CR, carriage return (13)> |  | CR = <US-ASCII CR, carriage return (13)> |
| LF = <US-ASCII LF, linefeed (10)> |  | LF = <US-ASCII LF, linefeed (10)> |
| SP = <US-ASCII SP, space (32)> |  | SP = <US-ASCII SP, space (32)> |
| HT = <US-ASCII HT, horizontal-tab (9)> |  | HTAB = <US-ASCII HT, horizontal-tab (9)> |
| <"> = <US-ASCII double-quote mark (34)> |  | DQUOTE = <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 [Part3]. |  | defined by its associated media type, as described in Section 2.3 of |
|  |  | [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 | HT ) |  | 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] only when encoded according to the rules of RFC |  | 8859-1 [ISO-8859-1] only when encoded according to the rules of |
| 2047 [RFC2047]. |  | [RFC2047]. |
| TEXT = <any OCTET except CTLs, |  | TEXT = <any OCTET except CTLs, |
| but including LWS> |  | 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. |
| skipping to change at page 14, line 29 |  | skipping to change at page 15, line 4 |
| but including LWS> |  | 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> |  | token = 1*<any CHAR except CTLs or separators> |
| separators = "(" | ")" | "<" | ">" | "@" |  | separators = "(" | ")" | "<" | ">" | "@" |
| | "," | ";" | ":" | "\" | <"> |  | | "," | ";" | ":" | "\" | DQUOTE |
| | "/" | "[" | "]" | "?" | "=" |  | | "/" | "[" | "]" | "?" | "=" |
| | "{" | "}" | SP | HT |  | | "{" | "}" | SP | HTAB |
| 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 = ( <"> *(qdtext | quoted-pair ) <"> ) |  | quoted-string = ( DQUOTE *(qdtext | quoted-pair ) DQUOTE ) |
| qdtext = <any TEXT except <">> |  | 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 |
| 3. Protocol Parameters |  | 3. Protocol Parameters |
| 3.1. HTTP Version |  | 3.1. HTTP Version |
| skipping to change at page 15, line 29 |  | skipping to change at page 16, line 4 |
| the sender to indicate the format of a message and its capacity for |  | the sender to indicate the format of a message and its capacity for |
| understanding further HTTP communication, rather than the features |  | understanding further HTTP communication, rather than the features |
| obtained via that communication. No change is made to the version |  | obtained via that communication. No change is made to the version |
| number for the addition of message components which do not affect |  | number for the addition of message components which do not affect |
| communication behavior or which only add to extensible field values. |  | communication behavior or which only add to extensible field values. |
| The <minor> number is incremented when the changes made to the |  | The <minor> number is incremented when the changes made to the |
| protocol add features which do not change the general message parsing |  | protocol add features which do not change the general message parsing |
| algorithm, but which may add to the message semantics and imply |  | algorithm, but which may add to the message semantics and imply |
| additional capabilities of the sender. The <major> number is |  | additional capabilities of the sender. The <major> number is |
| incremented when the format of a message within the protocol is |  | incremented when the format of a message within the protocol is |
| changed. See RFC 2145 [RFC2145] for a fuller explanation. |  | changed. See [RFC2145] for a fuller explanation. |
| The version of an HTTP message is indicated by an HTTP-Version field |  | The version of an HTTP message is indicated by an HTTP-Version field |
| in the first line of the message. |  | in the first line of the message. HTTP-Version is case-sensitive. |
| HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT |  | HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT |
| Note that the major and minor numbers MUST be treated as separate |  | Note that the major and minor numbers MUST be treated as separate |
| integers and that each MAY be incremented higher than a single digit. |  | integers and that each MAY be incremented higher than a single digit. |
| Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is |  | Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is |
| lower than HTTP/12.3. Leading zeros MUST be ignored by recipients |  | lower than HTTP/12.3. Leading zeros MUST be ignored by recipients |
| and MUST NOT be sent. |  | and MUST NOT be sent. |
| An application that sends a request or response message that includes |  | An application that sends a request or response message that includes |
| HTTP-Version of "HTTP/1.1" MUST be at least conditionally compliant |  | HTTP-Version of "HTTP/1.1" MUST be at least conditionally compliant |
| with this specification. Applications that are at least |  | with this specification. Applications that are at least |
| conditionally compliant with this specification SHOULD use an HTTP- |  | conditionally compliant with this specification SHOULD use an HTTP- |
| Version of "HTTP/1.1" in their messages, and MUST do so for any |  | Version of "HTTP/1.1" in their messages, and MUST do so for any |
| message that is not compatible with HTTP/1.0. For more details on |  | message that is not compatible with HTTP/1.0. For more details on |
| when to send specific HTTP-Version values, see RFC 2145 [RFC2145]. |  | when to send specific HTTP-Version values, see [RFC2145]. |
| The HTTP version of an application is the highest HTTP version for |  | The HTTP version of an application is the highest HTTP version for |
| which the application is at least conditionally compliant. |  | which the application is at least conditionally compliant. |
| Proxy and gateway applications need to be careful when forwarding |  | Proxy and gateway applications need to be careful when forwarding |
| messages in protocol versions different from that of the application. |  | messages in protocol versions different from that of the application. |
| Since the protocol version indicates the protocol capability of the |  | Since the protocol version indicates the protocol capability of the |
| sender, a proxy/gateway MUST NOT send a message with a version |  | sender, a proxy/gateway MUST NOT send a message with a version |
| indicator which is greater than its actual version. If a higher |  | indicator which is greater than its actual version. If a higher |
| version request is received, the proxy/gateway MUST either downgrade |  | version request is received, the proxy/gateway MUST either downgrade |
| the request version, or respond with an error, or switch to tunnel |  | the request version, or respond with an error, or switch to tunnel |
| behavior. |  | behavior. |
| Due to interoperability problems with HTTP/1.0 proxies discovered |  | Due to interoperability problems with HTTP/1.0 proxies discovered |
| since the publication of RFC 2068 [RFC2068], caching proxies MUST, |  | since the publication of [RFC2068], caching proxies MUST, gateways |
| gateways MAY, and tunnels MUST NOT upgrade the request to the highest |  | MAY, and tunnels MUST NOT upgrade the request to the highest version |
| version they support. The proxy/gateway's response to that request |  | they support. The proxy/gateway's response to that request MUST be |
| MUST be in the same major version as the request. |  | in the same major version as the request. |
| Note: Converting between versions of HTTP may involve modification |  | Note: Converting between versions of HTTP may involve modification |
| of header fields required or forbidden by the versions involved. |  | of header fields required or forbidden by the versions involved. |
| 3.2. Uniform Resource Identifiers |  | 3.2. Uniform Resource Identifiers |
| URIs have been known by many names: WWW addresses, Universal Document |  | URIs have been known by many names: WWW addresses, Universal Document |
| Identifiers, Universal Resource Identifiers [RFC1630], and finally |  | Identifiers, Universal Resource Identifiers [RFC1630], and finally |
| the combination of Uniform Resource Locators (URL) [RFC1738] and |  | the combination of Uniform Resource Locators (URL) [RFC1738] and |
| Names (URN) [RFC1737]. As far as HTTP is concerned, Uniform Resource |  | Names (URN) [RFC1737]. As far as HTTP is concerned, Uniform Resource |
| Identifiers are simply formatted strings which identify--via name, |  | Identifiers are simply formatted strings which identify--via name, |
| location, or any other characteristic--a resource. |  | location, or any other characteristic--a resource. |
| 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," RFC 2396 [RFC2396] |  | Identifiers (URI): Generic Syntax and Semantics," [RFC2396] (which |
| (which replaces RFCs 1738 [RFC1738] and RFC 1808 [RFC1808]). This |  | replaces [RFC1738] and [RFC1808]). This specification adopts the |
| specification adopts the definitions of "URI-reference", |  | definitions of "URI-reference", "absoluteURI", "relativeURI", "port", |
| "absoluteURI", "relativeURI", "port", "host","abs_path", "rel_path", |  | "host", "abs_path", "rel_path", "query", and "authority" from that |
| and "authority" from that specification. |  | specification. |
| The HTTP protocol does not place any a priori limit on the length of |  | The HTTP protocol 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 |  | 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 |  | serve, and SHOULD be able to handle URIs of unbounded length if they |
| provide GET-based forms that could generate such URIs. A server |  | provide GET-based forms that could generate such URIs. A server |
| SHOULD return 414 (Request-URI Too Long) status if a URI is longer |  | 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]). |  | 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 |
| skipping to change at page 17, line 21 |  | skipping to change at page 17, line 43 |
| 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:" "//" host [ ":" port ] [ abs_path [ "?" 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 abs_path (Section 5.1.2). The use of IP |
| addresses in URLs SHOULD be avoided whenever possible (see RFC 1900 |  | 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 abs_path is not present in the URL, it MUST be |
| given as "/" when used as a Request-URI for a resource |  | 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 |
| skipping to change at page 17, line 44 |  | skipping to change at page 18, line 20 |
| 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 abs_path is equivalent to an abs_path of "/". |
| Characters other than those in the "reserved" and "unsafe" sets (see |  | Characters other than those in the "reserved" set (see [RFC2396]) are |
| RFC 2396 [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://abc.com:80/~smith/home.html |  | http://example.com:80/~smith/home.html |
| http://ABC.com/%7Esmith/home.html |  | http://EXAMPLE.com/%7Esmith/home.html |
| http://ABC.com:/%7esmith/home.html |  | http://EXAMPLE.com:/%7esmith/home.html |
| 3.3. Date/Time Formats |  | 3.3. Date/Time Formats |
| 3.3.1. Full Date |  | 3.3.1. Full Date |
| HTTP applications have historically allowed three different formats |  | HTTP applications have historically allowed three different formats |
| for the representation of date/time stamps: |  | for the representation of date/time stamps: |
| Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123 |  | Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123 |
| Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036 |  | Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format |
| Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format |  | Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format |
| The first format is preferred as an Internet standard and represents |  | The first format is preferred as an Internet standard and represents |
| a fixed-length subset of that defined by RFC 1123 [RFC1123] (an |  | a fixed-length subset of that defined by [RFC1123] (an update to |
| update to RFC 822 [RFC822]). The second format is in common use, but |  | [RFC822]). The other formats are described here only for |
| is based on the obsolete RFC 850 [RFC1036] date format and lacks a |  | compatibility with obsolete implementations. HTTP/1.1 clients and |
| four-digit year. HTTP/1.1 clients and servers that parse the date |  | servers that parse the date value MUST accept all three formats (for |
| value MUST accept all three formats (for compatibility with |  | compatibility with HTTP/1.0), though they MUST only generate the RFC |
| HTTP/1.0), though they MUST only generate the RFC 1123 format for |  | 1123 format for representing HTTP-date values in header fields. See |
| representing HTTP-date values in header fields. See Appendix B for |  | Appendix B for further information. |
| further information. |  |  |
| Note: Recipients of date values are encouraged to be robust in |  | Note: Recipients of date values are encouraged to be robust in |
| accepting date values that may have been sent by non-HTTP |  | accepting date values that may have been sent by non-HTTP |
| applications, as is sometimes the case when retrieving or posting |  | applications, as is sometimes the case when retrieving or posting |
| messages via proxies/gateways to SMTP or NNTP. |  | messages via proxies/gateways to SMTP or NNTP. |
| All HTTP date/time stamps MUST be represented in Greenwich Mean Time |  | All HTTP date/time stamps MUST be represented in Greenwich Mean Time |
| (GMT), without exception. For the purposes of HTTP, GMT is exactly |  | (GMT), without exception. For the purposes of HTTP, GMT is exactly |
| equal to UTC (Coordinated Universal Time). This is indicated in the |  | equal to UTC (Coordinated Universal Time). This is indicated in the |
| first two formats by the inclusion of "GMT" as the three-letter |  | first two formats by the inclusion of "GMT" as the three-letter |
| skipping to change at page 20, line 20 |  | skipping to change at page 20, line 31 |
| Transfer-codings are analogous to the Content-Transfer-Encoding |  | Transfer-codings are analogous to the Content-Transfer-Encoding |
| 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), "identity" (section |  | following tokens: "chunked" (Section 3.4.1), "gzip", "compress", and |
| 3.6.2), "gzip" ([Part3]), "compress" ([Part3]), and "deflate" |  | "deflate" (Section 2.2 of [Part3]). |
| ([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 ([Part3]). |  | as new content-coding value tokens (Section 2.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 (Unimplemented), 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 |
| skipping to change at page 21, line 18 |  | skipping to change at page 21, line 18 |
| 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 = chunk-size(OCTET) |  | chunk-data = 1*OCTET ; a sequence of chunk-size octets |
| trailer = *(entity-header CRLF) |  | trailer = *(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. The chunked encoding is ended by any chunk whose size is |  | the chunk-data in octets. The chunked encoding is ended by any chunk |
| zero, followed by the trailer, which is terminated by an empty line. |  | whose size is zero, followed by the trailer, which is terminated by |
|  |  | an empty line. |
| The trailer allows the sender to include additional HTTP header |  | 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). |
| A server using chunked transfer-coding in a response MUST NOT use the |  | A server using chunked transfer-coding in a response MUST NOT use the |
| trailer for any header fields unless at least one of the following is |  | trailer for any header fields unless at least one of the following is |
| true: |  | true: |
| skipping to change at page 22, line 36 |  | skipping to change at page 22, line 38 |
| 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 |
| message format of RFC 822 [RFC822] for transferring entities (the |  | message format of [RFC2822] for transferring entities (the payload of |
| payload of the message). Both types of message consist of a start- |  | the message). Both types of message consist of a start-line, zero or |
| line, zero or more header fields (also known as "headers"), an empty |  | more header fields (also known as "headers"), an empty line (i.e., a |
| line (i.e., a line with nothing preceding the CRLF) indicating the |  | line with nothing preceding the CRLF) indicating the end of the |
| end of the header fields, and possibly a message-body. |  | header fields, and possibly a message-body. |
| generic-message = start-line |  | generic-message = start-line |
| *(message-header CRLF) |  | *(message-header CRLF) |
| CRLF |  | CRLF |
| [ message-body ] |  | [ message-body ] |
| start-line = Request-Line | Status-Line |  | start-line = Request-Line | Status-Line |
| In the interest of robustness, servers SHOULD ignore any empty |  | In the interest of robustness, servers SHOULD ignore any empty |
| line(s) received where a Request-Line is expected. In other words, |  | line(s) received where a Request-Line is expected. In other words, |
| if the server is reading the protocol stream at the beginning of a |  | if the server is reading the protocol stream at the beginning of a |
| skipping to change at page 23, line 16 |  | skipping to change at page 23, line 17 |
| 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 3.1 of [Part3]) fields, follow |
| the same generic format as that given in Section 3.1 of RFC 822 |  | the same generic format as that given in Section 2.1 of [RFC2822]. |
| [RFC822]. Each header field consists of a name followed by a colon |  | Each header field consists of a name followed by a colon (":") and |
| (":") and the field value. Field names are case-insensitive. The |  | the field value. Field names are case-insensitive. The field value |
| field value MAY be preceded by any amount of LWS, though a single SP |  | MAY be preceded by any amount of LWS, though a single SP is |
| 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 HT. 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 = <the OCTETs making up the field-value |
| and consisting of either *TEXT or combinations |  | and consisting of either *TEXT or combinations |
| of token, separators, and quoted-string> |  | of token, separators, and quoted-string> |
| skipping to change at page 24, line 45 |  | skipping to change at page 24, line 46 |
| [Part2]) does not allow sending an entity-body in requests. A server |  | [Part2]) does not allow sending an entity-body in requests. A server |
| SHOULD read and forward a message-body on any request; if the request |  | SHOULD read and forward a message-body on any request; if the request |
| method does not include defined semantics for an entity-body, then |  | method does not include defined semantics for an entity-body, then |
| the message-body SHOULD be ignored when handling the request. |  | the message-body SHOULD be ignored when handling the request. |
| 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. |
| 4.4. Message Length |  | 4.4. Message Length |
| The transfer-length of a message is the length of the message-body as |  | The transfer-length of a message is the length of the message-body as |
| it appears in the message; that is, after any transfer-codings have |  | it appears in the message; that is, after any transfer-codings have |
| been applied. When a message-body is included with a message, the |  | been applied. When a message-body is included with a message, the |
| transfer-length of that body is determined by one of the following |  | transfer-length of that body is determined by one of the following |
| (in order of precedence): |  | (in order of precedence): |
| 1. Any response message which "MUST NOT" include a message-body |  | 1. Any response message which "MUST NOT" include a message-body |
| (such as the 1xx, 204, and 304 responses and any response to a |  | (such as the 1xx, 204, and 304 responses and any response to a |
| HEAD request) is always terminated by the first empty line after |  | HEAD request) is always terminated by the first empty line after |
| the header fields, regardless of the entity-header fields present |  | the header fields, regardless of the entity-header fields present |
| in the message. |  | in the message. |
| 2. If a Transfer-Encoding header field (Section 8.7) is present and |  | 2. If a Transfer-Encoding header field (Section 8.7) is present, |
| has any value other than "identity", then the transfer-length is |  | then the transfer-length is defined by use of the "chunked" |
| defined by use of the "chunked" transfer-coding (Section 3.4), |  | transfer-coding (Section 3.4), unless the message is terminated |
| unless the message is terminated by closing the connection. |  | by closing the connection. |
| 3. If a Content-Length header field (Section 8.2) is present, its |  | 3. If a Content-Length header field (Section 8.2) is present, its |
| decimal value in OCTETs represents both the entity-length and the |  | decimal value in OCTETs represents both the entity-length and the |
| transfer-length. The Content-Length header field MUST NOT be |  | transfer-length. The Content-Length header field MUST NOT be |
| sent if these two lengths are different (i.e., if a Transfer- |  | sent if these two lengths are different (i.e., if a Transfer- |
| Encoding header field is present). If a message is received with |  | Encoding header field is present). If a message is received with |
| both a Transfer-Encoding header field and a Content-Length header |  | both a Transfer-Encoding header field and a Content-Length header |
| field, the latter MUST be ignored. |  | field, the latter MUST be ignored. |
| 4. If the message uses the media type "multipart/byteranges", and |  | 4. If the message uses the media type "multipart/byteranges", and |
| the ransfer-length is not otherwise specified, then this self- |  | the transfer-length is not otherwise specified, then this self- |
| elimiting media type defines the transfer-length. This media |  | delimiting media type defines the transfer-length. This media |
| type UST NOT be used unless the sender knows that the recipient |  | type MUST NOT be used unless the sender knows that the recipient |
| can arse it; the presence in a request of a Range header with |  | can parse it; the presence in a request of a Range header with |
| ultiple byte-range specifiers from a 1.1 client implies that the |  | multiple byte-range specifiers from a 1.1 client implies that the |
| lient can parse multipart/byteranges responses. |  | client can parse multipart/byteranges responses. |
| A range header might be forwarded by a 1.0 proxy that does not |  | A range header might be forwarded by a 1.0 proxy that does not |
| understand multipart/byteranges; in this case the server MUST |  | understand multipart/byteranges; in this case the server MUST |
| delimit the message using methods defined in items 1, 3 or 5 |  | delimit the message using methods defined in items 1, 3 or 5 |
| of this section. |  | of this section. |
| 5. By the server closing the connection. (Closing the connection |  | 5. By the server closing the connection. (Closing the connection |
| cannot be used to indicate the end of a request body, since that |  | cannot be used to indicate the end of a request body, since that |
| would leave no possibility for the server to send back a |  | would leave no possibility for the server to send back a |
| response.) |  | response.) |
| For compatibility with HTTP/1.0 applications, HTTP/1.1 requests |  | For compatibility with HTTP/1.0 applications, HTTP/1.1 requests |
| containing a message-body MUST include a valid Content-Length header |  | containing a message-body MUST include a valid Content-Length header |
| field unless the server is known to be HTTP/1.1 compliant. If a |  | field unless the server is known to be HTTP/1.1 compliant. If a |
| request contains a message-body and a Content-Length is not given, |  | request contains a message-body and a Content-Length is not given, |
| the server SHOULD respond with 400 (bad request) if it cannot |  | the server SHOULD respond with 400 (Bad Request) if it cannot |
| determine the length of the message, or with 411 (length required) if |  | determine the length of the message, or with 411 (Length Required) if |
| it wishes to insist on receiving a valid Content-Length. |  | it wishes to insist on receiving a valid Content-Length. |
| All HTTP/1.1 applications that receive entities MUST accept the |  | All HTTP/1.1 applications that receive entities MUST accept the |
| "chunked" transfer-coding (Section 3.4), thus allowing this mechanism |  | "chunked" transfer-coding (Section 3.4), thus allowing this mechanism |
| to be used for messages when the message length cannot be determined |  | to be used for messages when the message length cannot be determined |
| in advance. |  | in advance. |
| Messages MUST NOT include both a Content-Length header field and a |  | Messages MUST NOT include both a Content-Length header field and a |
| non-identity transfer-coding. If the message does include a non- |  | transfer-coding. If the message does include a transfer-coding, the |
| identity transfer-coding, the Content-Length MUST be ignored. |  | Content-Length MUST be ignored. |
| When a Content-Length is given in a message where a message-body is |  | When a Content-Length is given in a message where a message-body is |
| allowed, its field value MUST exactly match the number of OCTETs in |  | allowed, its field value MUST exactly match the number of OCTETs in |
| the message-body. HTTP/1.1 user agents MUST notify the user when an |  | the message-body. HTTP/1.1 user agents MUST notify the user when an |
| invalid length is received and detected. |  | invalid length is received and detected. |
| 4.5. General Header Fields |  | 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 3.2 |  | general-header = Cache-Control ; [Part6], Section 15.2 |
| | Connection ; Section 8.1 |  | | Connection ; Section 8.1 |
| | Date ; Section 8.3 |  | | Date ; Section 8.3 |
| | Pragma ; [Part6], Section 3.4 |  | | Pragma ; [Part6], Section 15.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 3.6 |  | | Warning ; [Part6], Section 15.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 |
| skipping to change at page 27, line 34 |  | skipping to change at page 27, line 34 |
| The Method token indicates the method to be performed on the resource |  | The Method token indicates the method to be performed on the resource |
| identified by the Request-URI. The method is case-sensitive. |  | identified by the Request-URI. The method is case-sensitive. |
| 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 = "*" | absoluteURI | abs_path | authority |  | Request-URI = "*" |
|  |  | | absoluteURI |
|  |  | | ( abs_path [ "?" query ] ) |
|  |  | | 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 |
| The absoluteURI form is REQUIRED when the request is being made to a |  | The absoluteURI form is REQUIRED when the request is being made to a |
| proxy. The proxy is requested to forward the request or service it |  | proxy. The proxy is requested to forward the request or service it |
| from a valid cache, and return the response. Note that the proxy MAY |  | from a valid cache, and return the response. Note that the proxy MAY |
| forward the request on to another proxy or directly to the server |  | forward the request on to another proxy or directly to the server |
| specified by the absoluteURI. In order to avoid request loops, a |  | specified by the absoluteURI. In order to avoid request loops, a |
| proxy MUST be able to recognize all of its server names, including |  | proxy MUST be able to recognize all of its server names, including |
| any aliases, local variations, and the numeric IP address. An |  | any aliases, local variations, and the numeric IP address. An |
| example Request-Line would be: |  | example Request-Line would be: |
| GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1 |  | GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1 |
| To allow for transition to 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, abs_path) as |
| the Request-URI, and the network location of the URI (authority) MUST |  | the Request-URI, and the network location of the URI (authority) MUST |
| be transmitted in a Host header field. For example, a client wishing |  | be transmitted in a Host header field. For example, a client wishing |
| to retrieve the resource above directly from the origin server would |  | to retrieve the resource above directly from the origin server would |
| create a TCP connection to port 80 of the host "www.w3.org" and send |  | create a TCP connection to port 80 of the host "www.example.org" and |
| the lines: |  | send the lines: |
| GET /pub/WWW/TheProject.html HTTP/1.1 |  | GET /pub/WWW/TheProject.html HTTP/1.1 |
| Host: www.w3.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. |
| skipping to change at page 33, line 17 |  | skipping to change at page 33, line 27 |
| It is especially important that proxies correctly implement the |  | It is especially important that proxies correctly implement the |
| properties of the Connection header field as specified in |  | properties of the Connection header field as specified in |
| Section 8.1. |  | Section 8.1. |
| The proxy server MUST signal persistent connections separately with |  | The proxy server MUST signal persistent connections separately with |
| its clients and the origin servers (or other proxy servers) that it |  | its clients and the origin servers (or other proxy servers) that it |
| connects to. Each persistent connection applies to only one |  | connects to. Each persistent connection applies to only one |
| transport link. |  | transport link. |
| A proxy server MUST NOT establish a HTTP/1.1 persistent connection |  | A proxy server MUST NOT establish a HTTP/1.1 persistent connection |
| with an HTTP/1.0 client (but see RFC 2068 [RFC2068] for information |  | with an HTTP/1.0 client (but see [RFC2068] for information and |
| and discussion of the problems with the Keep-Alive header implemented |  | discussion of the problems with the Keep-Alive header implemented by |
| by many HTTP/1.0 clients). |  | many HTTP/1.0 clients). |
| 7.1.4. Practical Considerations |  | 7.1.4. Practical Considerations |
| Servers will usually have some time-out value beyond which they will |  | Servers will usually have some time-out value beyond which they will |
| no longer maintain an inactive connection. Proxy servers might make |  | no longer maintain an inactive connection. Proxy servers might make |
| this a higher value since it is likely that the client will be making |  | this a higher value since it is likely that the client will be making |
| more connections through the same server. The use of persistent |  | more connections through the same server. The use of persistent |
| connections places no requirements on the length (or existence) of |  | connections places no requirements on the length (or existence) of |
| this time-out for either the client or the server. |  | this time-out for either the client or the server. |
| skipping to change at page 35, line 38 |  | skipping to change at page 35, line 50 |
| the 100 (Continue) response. If it responds with a final status |  | the 100 (Continue) response. If it responds with a final status |
| code, it MAY close the transport connection or it MAY continue to |  | code, it MAY close the transport connection or it MAY continue to |
| read and discard the rest of the request. It MUST NOT perform the |  | read and discard the rest of the request. It MUST NOT perform the |
| requested method if it returns a final status code. |  | requested method if it returns a final status code. |
| o An origin server SHOULD NOT send a 100 (Continue) response if the |  | o An origin server SHOULD NOT send a 100 (Continue) response if the |
| request message does not include an Expect request-header field |  | request message does not include an Expect request-header field |
| with the "100-continue" expectation, and MUST NOT send a 100 |  | with the "100-continue" expectation, and MUST NOT send a 100 |
| (Continue) response if such a request comes from an HTTP/1.0 (or |  | (Continue) response if such a request comes from an HTTP/1.0 (or |
| earlier) client. There is an exception to this rule: for |  | earlier) client. There is an exception to this rule: for |
| compatibility with RFC 2068, a server MAY send a 100 (Continue) |  | compatibility with [RFC2068], a server MAY send a 100 (Continue) |
| status in response to an HTTP/1.1 PUT or POST request that does |  | status in response to an HTTP/1.1 PUT or POST request that does |
| not include an Expect request-header field with the "100-continue" |  | not include an Expect request-header field with the "100-continue" |
| expectation. This exception, the purpose of which is to minimize |  | expectation. This exception, the purpose of which is to minimize |
| any client processing delays associated with an undeclared wait |  | any client processing delays associated with an undeclared wait |
| for 100 (Continue) status, applies only to HTTP/1.1 requests, and |  | for 100 (Continue) status, applies only to HTTP/1.1 requests, and |
| not to requests with any other HTTP-version value. |  | not to requests with any other HTTP-version value. |
| o An origin server MAY omit a 100 (Continue) response if it has |  | o An origin server MAY omit a 100 (Continue) response if it has |
| already received some or all of the request body for the |  | already received some or all of the request body for the |
| corresponding request. |  | corresponding request. |
| skipping to change at page 37, line 34 |  | skipping to change at page 37, line 48 |
| If at any point an error status is received, the client |  | If at any point an error status is received, the client |
| o SHOULD NOT continue and |  | o SHOULD NOT continue and |
| o SHOULD close the connection if it has not completed sending the |  | o SHOULD close the connection if it has not completed sending the |
| request message. |  | request message. |
| 8. Header Field Definitions |  | 8. Header Field Definitions |
| This section defines the syntax and semantics of all standard |  | This section defines the syntax and semantics of HTTP/1.1 header |
| HTTP/1.1 header fields. For entity-header fields, both sender and |  | fields related to message framing and transport protocols. |
| recipient refer to either the client or the server, depending on who |  |  |
| sends and who receives the entity. |  | For entity-header fields, both sender and recipient refer to either |
|  |  | the client or the server, depending on who sends and who receives the |
|  |  | entity. |
| 8.1. Connection |  | 8.1. Connection |
| The Connection general-header field allows the sender to specify |  | The Connection general-header field allows the sender to specify |
| options that are desired for that particular connection and MUST NOT |  | options that are desired for that particular connection and MUST NOT |
| be communicated by proxies over further connections. |  | be communicated by proxies over further connections. |
| The Connection header has the following grammar: |  | The Connection header has the following grammar: |
| Connection = "Connection" ":" 1#(connection-token) |  | Connection = "Connection" ":" 1#(connection-token) |
| skipping to change at page 38, line 25 |  | skipping to change at page 38, line 40 |
| HTTP/1.1 defines the "close" connection option for the sender to |  | HTTP/1.1 defines the "close" connection option for the sender to |
| signal that the connection will be closed after completion of the |  | signal that the connection will be closed after completion of the |
| response. For example, |  | response. For example, |
| Connection: close |  | Connection: close |
| in either the request or the response header fields indicates that |  | in either the request or the response header fields indicates that |
| the connection SHOULD NOT be considered `persistent' (Section 7.1) |  | the connection SHOULD NOT be considered `persistent' (Section 7.1) |
| after the current request/response is complete. |  | after the current request/response is complete. |
| HTTP/1.1 applications that do not support persistent connections MUST |  | An HTTP/1.1 client that does not support persistent connections MUST |
| include the "close" connection option in every message. |  | include the "close" connection option in every request message. |
|  |  | An HTTP/1.1 server that does not support persistent connections MUST |
|  |  | include the "close" connection option in every response message that |
|  |  | does not have a 1xx (informational) status code. |
| A system receiving an HTTP/1.0 (or lower-version) message that |  | A system receiving an HTTP/1.0 (or lower-version) message that |
| includes a Connection header MUST, for each connection-token in this |  | includes a Connection header MUST, for each connection-token in this |
| field, remove and ignore any header field(s) from the message with |  | field, remove and ignore any header field(s) from the message with |
| the same name as the connection-token. This protects against |  | the same name as the connection-token. This protects against |
| mistaken forwarding of such header fields by pre-HTTP/1.1 proxies. |  | mistaken forwarding of such header fields by pre-HTTP/1.1 proxies. |
| See Appendix D.2. |  | See Appendix D.2. |
| 8.2. Content-Length |  | 8.2. Content-Length |
| The Content-Length entity-header field indicates the size of the |  | The Content-Length entity-header field indicates the size of the |
| entity-body, in decimal number of OCTETs, sent to the recipient or, |  | entity-body, in decimal number of OCTETs, sent to the recipient or, |
| in the case of the HEAD method, the size of the entity-body that |  | in the case of the HEAD method, the size of the entity-body that |
| would have been sent had the request been a GET. |  | would have been sent had the request been a GET. |
| Content-Length = "Content-Length" ":" 1*DIGIT |  | Content-Length = "Content-Length" ":" 1*DIGIT |
| skipping to change at page 39, line 20 |  | skipping to change at page 39, line 39 |
| the corresponding definition in MIME, where it is an optional field |  | the corresponding definition in MIME, where it is an optional field |
| used within the "message/external-body" content-type. In HTTP, it |  | used within the "message/external-body" content-type. In HTTP, it |
| SHOULD be sent whenever the message's length can be determined prior |  | SHOULD be sent whenever the message's length can be determined prior |
| to being transferred, unless this is prohibited by the rules in |  | to being transferred, unless this is prohibited by the rules in |
| Section 4.4. |  | Section 4.4. |
| 8.3. Date |  | 8.3. Date |
| The Date general-header field represents the date and time at which |  | The Date general-header field represents the date and time at which |
| the message was originated, having the same semantics as orig-date in |  | the message was originated, having the same semantics as orig-date in |
| RFC 822. The field value is an HTTP-date, as described in |  | Section 3.6.1 of [RFC2822]. The field value is an HTTP-date, as |
| Section 3.3.1; it MUST be sent in RFC 1123 [RFC1123]-date format. |  | described in Section 3.3.1; it MUST be sent in rfc1123-date format. |
| Date = "Date" ":" HTTP-date |  | Date = "Date" ":" HTTP-date |
| An example is |  | An example is |
| Date: Tue, 15 Nov 1994 08:12:31 GMT |  | Date: Tue, 15 Nov 1994 08:12:31 GMT |
| Origin servers MUST include a Date header field in all responses, |  | Origin servers MUST include a Date header field in all responses, |
| except in these cases: |  | except in these cases: |
| skipping to change at page 40, line 46 |  | skipping to change at page 41, line 16 |
| 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" ":" 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.w3.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.w3.org |  | Host: www.example.org |
| A client MUST include a Host header field in all HTTP/1.1 request |  | A client MUST include a Host header field in all HTTP/1.1 request |
| messages . If the requested URI does not include an Internet host |  | messages . If the requested URI does not include an Internet host |
| name for the service being requested, then the Host header field MUST |  | name for the service being requested, then the Host header field MUST |
| be given with an empty value. An HTTP/1.1 proxy MUST ensure that any |  | be given with an empty value. An HTTP/1.1 proxy MUST ensure that any |
| request message it forwards does contain an appropriate Host header |  | request message it forwards does contain an appropriate Host header |
| field that identifies the service being requested by the proxy. All |  | field that identifies the service being requested by the proxy. All |
| Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request) |  | Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request) |
| status code to any HTTP/1.1 request message which lacks a Host header |  | status code to any HTTP/1.1 request message which lacks a Host header |
| field. |  | field. |
| See sections 5.2 and D.1.1 for other requirements relating to Host. |  | See Sections 5.2 and D.1.1 for other requirements relating to Host. |
| 8.5. TE |  | 8.5. TE |
| The TE request-header field indicates what extension transfer-codings |  | The TE request-header field indicates what extension transfer-codings |
| it is willing to accept in the response and whether or not it is |  | it is willing to accept in the response and whether or not it is |
| willing to accept trailer fields in a chunked transfer-coding. Its |  | willing to accept trailer fields in a chunked transfer-coding. Its |
| value may consist of the keyword "trailers" and/or a comma-separated |  | value may consist of the keyword "trailers" and/or a comma-separated |
| list of extension transfer-coding names with optional accept |  | list of extension transfer-coding names with optional accept |
| parameters (as described in Section 3.4). |  | parameters (as described in Section 3.4). |
| skipping to change at page 44, line 36 |  | skipping to change at page 44, line 49 |
| specification. Any token can be used as a protocol name; however, it |  | specification. Any token can be used as a protocol name; however, it |
| will only be useful if both the client and server associate the name |  | will only be useful if both the client and server associate the name |
| with the same protocol. |  | with the same protocol. |
| 8.9. Via |  | 8.9. Via |
| The Via general-header field MUST be used by gateways and proxies to |  | The Via general-header field MUST be used by gateways and proxies to |
| indicate the intermediate protocols and recipients between the user |  | indicate the intermediate protocols and recipients between the user |
| 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 |
| RFC 822 [RFC822] and is intended to be used for tracking message |  | [RFC2822] and is intended to be used for tracking message forwards, |
| forwards, avoiding request loops, and identifying the protocol |  | avoiding request loops, and identifying the protocol capabilities of |
| 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 = ( 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/ |
| skipping to change at page 45, line 25 |  | skipping to change at page 45, line 39 |
| forwarding applications. |  | forwarding applications. |
| Comments MAY be used in the Via header field to identify the software |  | Comments MAY be used in the Via header field to identify the software |
| of the recipient proxy or gateway, analogous to the User-Agent and |  | of the recipient proxy or gateway, analogous to the User-Agent and |
| Server header fields. However, all comments in the Via field are |  | Server header fields. However, all comments in the Via field are |
| optional and MAY be removed by any recipient prior to forwarding the |  | optional and MAY be removed by any recipient prior to forwarding the |
| message. |  | message. |
| For example, a request message could be sent from an HTTP/1.0 user |  | For example, a request message could be sent from an HTTP/1.0 user |
| agent to an internal proxy code-named "fred", which uses HTTP/1.1 to |  | agent to an internal proxy code-named "fred", which uses HTTP/1.1 to |
| forward the request to a public proxy at nowhere.com, which completes |  | forward the request to a public proxy at p.example.net, which |
| the request by forwarding it to the origin server at www.ics.uci.edu. |  | completes the request by forwarding it to the origin server at |
| The request received by www.ics.uci.edu would then have the following |  | www.example.com. The request received by www.example.com would then |
| Via header field: |  | have the following Via header field: |
| Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1) |  | Via: 1.0 fred, 1.1 p.example.net (Apache/1.1) |
| Proxies and gateways used as a portal through a network firewall |  | Proxies and gateways used as a portal through a network firewall |
| SHOULD NOT, by default, forward the names and ports of hosts within |  | SHOULD NOT, by default, forward the names and ports of hosts within |
| the firewall region. This information SHOULD only be propagated if |  | the firewall region. This information SHOULD only be propagated if |
| explicitly enabled. If not enabled, the received-by host of any host |  | explicitly enabled. If not enabled, the received-by host of any host |
| behind the firewall SHOULD be replaced by an appropriate pseudonym |  | behind the firewall SHOULD be replaced by an appropriate pseudonym |
| for that host. |  | for that host. |
| For organizations that have strong privacy requirements for hiding |  | For organizations that have strong privacy requirements for hiding |
| internal structures, a proxy MAY combine an ordered subsequence of |  | internal structures, a proxy MAY combine an ordered subsequence of |
| skipping to change at page 48, line 38 |  | skipping to change at page 49, line 8 |
| cryptography is beyond the scope of the HTTP/1.1 specification. |  | cryptography is beyond the scope of the HTTP/1.1 specification. |
| 10.6. Denial of Service Attacks on Proxies |  | 10.6. Denial of Service Attacks on Proxies |
| They exist. They are hard to defend against. Research continues. |  | They exist. They are hard to defend against. Research continues. |
| Beware. |  | Beware. |
| 11. Acknowledgments |  | 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 RFC 822 [RFC822]. |  | constructs defined by David H. Crocker for [RFC822ABNF]. Similarly, |
| Similarly, it reuses many of the definitions provided by Nathaniel |  | it reuses many of the definitions provided by Nathaniel Borenstein |
| Borenstein and Ned Freed for MIME [RFC2045]. We hope that their |  | and Ned Freed for MIME [RFC2045]. We hope that their inclusion in |
| inclusion in this specification will help reduce past confusion over |  | this specification will help reduce past confusion over the |
| 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 |  | The HTTP protocol has evolved considerably over the years. It has |
| benefited from a large and active developer community--the many |  | benefited from a large and active developer community--the many |
| people who have participated on the www-talk mailing list--and it is |  | people who have participated on the www-talk mailing list--and it is |
| that community which has been most responsible for the success of |  | that community which has been most responsible for the success of |
| HTTP and of the World-Wide Web in general. Marc Andreessen, Robert |  | HTTP and of the World-Wide Web in general. Marc Andreessen, Robert |
| Cailliau, Daniel W. Connolly, Bob Denny, John Franks, Jean-Francois |  | Cailliau, Daniel W. Connolly, Bob Denny, John Franks, Jean-Francois |
| Groff, Phillip M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob |  | Groff, Phillip M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob |
| McCool, Lou Montulli, Dave Raggett, Tony Sanders, and Marc |  | McCool, Lou Montulli, Dave Raggett, Tony Sanders, and Marc |
| VanHeyningen deserve special recognition for their efforts in |  | VanHeyningen deserve special recognition for their efforts in |
| defining early aspects of the protocol. |  | defining early aspects of the 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 Ross Patterson |  | Gary Adams, Harald Tveit Alvestrand, Keith Ball, Brian Behlendorf, |
| Harald Tveit Alvestrand Albert Lunde |  | Paul Burchard, Maurizio Codogno, Mike Cowlishaw, Roman Czyborra, |
| Keith Ball John C. Mallery |  | Michael A. Dolan, Daniel DuBois, David J. Fiander, Alan Freier, Marc |
| Brian Behlendorf Jean-Philippe Martin-Flatin |  | Hedlund, Greg Herlihy, Koen Holtman, Alex Hopmann, Bob Jernigan, Shel |
| Paul Burchard Mitra |  | Kaphan, Rohit Khare, John Klensin, Martijn Koster, Alexei Kosut, |
| Maurizio Codogno David Morris |  | David M. Kristol, Daniel LaLiberte, Ben Laurie, Paul J. Leach, Albert |
| Mike Cowlishaw Gavin Nicol |  | Lunde, John C. Mallery, Jean-Philippe Martin-Flatin, Mitra, David |
| Roman Czyborra Bill Perry |  | Morris, Gavin Nicol, Ross Patterson, Bill Perry, Jeffrey Perry, Scott |
| Michael A. Dolan Jeffrey Perry |  | Powers, Owen Rees, Luigi Rizzo, David Robinson, Marc Salomon, Rich |
| David J. Fiander Scott Powers |  | Salz, Allan M. Schiffman, Jim Seidman, Chuck Shotton, Eric W. Sink, |
| Alan Freier Owen Rees |  | Simon E. Spero, Richard N. Taylor, Robert S. Thau, Bill (BearHeart) |
| Marc Hedlund Luigi Rizzo |  | Weinman, Francois Yergeau, Mary Ellen Zurko, Josh Cohen. |
| Greg Herlihy David Robinson |  |  |
| Koen Holtman Marc Salomon |  |  |
| Alex Hopmann Rich Salz |  |  |
| Bob Jernigan Allan M. Schiffman |  |  |
| Shel Kaphan Jim Seidman |  |  |
| Rohit Khare Chuck Shotton |  |  |
| John Klensin Eric W. Sink |  |  |
| Martijn Koster Simon E. Spero |  |  |
| Alexei Kosut Richard N. Taylor |  |  |
| David M. Kristol Robert S. Thau |  |  |
| Daniel LaLiberte Bill (BearHeart) Weinman |  |  |
| Ben Laurie Francois Yergeau |  |  |
| Paul J. Leach Mary Ellen Zurko |  |  |
| Daniel DuBois Josh Cohen |  |  |
| Thanks to the "cave men" of Palo Alto. You know who you are. |  | Thanks to the "cave men" of Palo Alto. You know who you are. |
| Jim Gettys (the current editor of this document) wishes particularly |  | Jim Gettys (the editor of [RFC2616]) wishes particularly to thank Roy |
| to thank Roy Fielding, the previous editor of this document, along |  | Fielding, the editor of [RFC2068], along with John Klensin, Jeff |
| with John Klensin, Jeff Mogul, Paul Leach, Dave Kristol, Koen |  | Mogul, Paul Leach, Dave Kristol, Koen Holtman, John Franks, Josh |
| Holtman, John Franks, Josh Cohen, Alex Hopmann, Scott Lawrence, and |  | Cohen, Alex Hopmann, Scott Lawrence, and Larry Masinter for their |
| Larry Masinter for their help. And thanks go particularly to Jeff |  | help. And thanks go particularly to Jeff Mogul and Scott Lawrence |
| Mogul and Scott Lawrence for performing the "MUST/MAY/SHOULD" audit. |  | for performing the "MUST/MAY/SHOULD" audit. |
| The Apache Group, Anselm Baird-Smith, author of Jigsaw, and Henrik |  | The Apache Group, Anselm Baird-Smith, author of Jigsaw, and Henrik |
| Frystyk implemented RFC 2068 early, and we wish to thank them for the |  | Frystyk implemented RFC 2068 early, and we wish to thank them for the |
| discovery of many of the problems that this document attempts to |  | discovery of many of the problems that this document attempts to |
| rectify. |  | rectify. |
| Based on an XML translation of RFC 2616 by Julian Reschke. |  |  |
| 12. References |  | 12. References |
| [ISO-8859] |  | 12.1. Normative References |
|  |  | [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", 1987-1990. |  | character sets -- Part 1: Latin alphabet No. 1", ISO/ |
|  |  | IEC 8859-1:1998, 1998. |
| Part 1: Latin alphabet No. 1, ISO-8859-1:1987. Part 2: |  | [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Latin alphabet No. 2, ISO-8859-2, 1987. Part 3: Latin |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| alphabet No. 3, ISO-8859-3, 1988. Part 4: Latin alphabet |  | and J. Reschke, Ed., "HTTP/1.1, part 2: Message |
| No. 4, ISO-8859-4, 1988. Part 5: Latin/Cyrillic alphabet, |  | Semantics", draft-ietf-httpbis-p2-semantics-01 (work in |
| ISO-8859-5, 1988. Part 6: Latin/Arabic alphabet, ISO- |  | progress), January 2008. |
| 8859-6, 1987. Part 7: Latin/Greek alphabet, ISO-8859-7, |  |  |
| 1987. Part 8: Latin/Hebrew alphabet, ISO-8859-8, 1988. |  | [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Part 9: Latin alphabet No. 5, ISO-8859-9, 1990. |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
|  |  | and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload |
|  |  | and Content Negotiation", draft-ietf-httpbis-p3-payload-01 |
|  |  | (work in progress), January 2008. |
|  |  | [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
|  |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
|  |  | and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and |
|  |  | Partial Responses", draft-ietf-httpbis-p5-range-01 (work |
|  |  | in progress), January 2008. |
|  |  | [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
|  |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
|  |  | and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", |
|  |  | draft-ietf-httpbis-p6-cache-01 (work in progress), |
|  |  | January 2008. |
|  |  | [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail |
|  |  | Extensions (MIME) Part One: Format of Internet Message |
|  |  | Bodies", RFC 2045, November 1996. |
|  |  | [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) |
|  |  | Part Three: Message Header Extensions for Non-ASCII Text", |
|  |  | RFC 2047, November 1996. |
|  |  | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |
|  |  | Requirement Levels", BCP 14, RFC 2119, March 1997. |
|  |  | [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform |
|  |  | Resource Identifiers (URI): Generic Syntax", RFC 2396, |
|  |  | August 1998. |
|  |  | [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and |
|  |  | Registration Procedures", BCP 13, RFC 4288, December 2005. |
|  |  | [RFC822ABNF] |
|  |  | Crocker, D., "Standard for the format of ARPA Internet |
|  |  | text messages", STD 11, RFC 822, August 1982. |
|  |  | [USASCII] American National Standards Institute, "Coded Character |
|  |  | Set -- 7-bit American Standard Code for Information |
|  |  | Interchange", ANSI X3.4, 1986. |
|  |  | 12.2. Informative References |
| [Nie1997] Nielsen, H., Gettys, J., Prud'hommeaux, E., Lie, H., and |  | [Nie1997] Nielsen, H., Gettys, J., Prud'hommeaux, E., Lie, H., and |
| C. Lilley, "Network Performance Effects of HTTP/1.1, CSS1, |  | C. Lilley, "Network Performance Effects of HTTP/1.1, CSS1, |
| and PNG", Proceedings of ACM SIGCOMM '97, Cannes France , |  | and PNG", ACM Proceedings of the ACM SIGCOMM '97 |
| Sep 1997. |  | conference on Applications, technologies, architectures, |
|  |  | and protocols for computer communication SIGCOMM '97, |
|  |  | September 1997, |
|  |  | <http://doi.acm.org/10.1145/263105.263157>. |
| [Pad1995] Padmanabhan, V. and J. Mogul, "Improving HTTP Latency", |  | [Pad1995] Padmanabhan, V. and J. Mogul, "Improving HTTP Latency", |
| Computer Networks and ISDN Systems v. 28, pp. 25-35, |  | Computer Networks and ISDN Systems v. 28, pp. 25-35, |
| Dec 1995. |  | December 1995. |
| Slightly revised version of paper in Proc. 2nd |  | Slightly revised version of paper in Proc. 2nd |
| International WWW Conference '94: Mosaic and the Web, Oct. |  | International WWW Conference '94: Mosaic and the Web, Oct. |
| 1994, which is available at <http://www.ncsa.uiuc.edu/SDG/ |  | 1994, which is available at <http://www.ncsa.uiuc.edu/SDG/ |
| IT94/Proceedings/DDay/mogul/HTTPLatency.html>. |  | IT94/Proceedings/DDay/mogul/HTTPLatency.html>. |
| [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  |  |
| Masinter, L., Leach, P., and T. Berners-Lee, "HTTP/1.1, |  |  |
| part 2: Message Semantics", |  |  |
| draft-ietf-httpbis-p2-semantics-00 (work in progress), |  |  |
| December 2007. |  |  |
| [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  |  |
| Masinter, L., Leach, P., and T. Berners-Lee, "HTTP/1.1, |  |  |
| part 3: Message Payload and Content Negotiation", |  |  |
| draft-ietf-httpbis-p3-payload-00 (work in progress), |  |  |
| December 2007. |  |  |
| [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  |  |
| Masinter, L., Leach, P., and T. Berners-Lee, "HTTP/1.1, |  |  |
| part 6: Caching", draft-ietf-httpbis-p6-cache-00 (work in |  |  |
| progress), December 2007. |  |  |
| [RFC1036] Horton, M. and R. Adams, "Standard for interchange of |  |  |
| USENET messages", RFC 1036, December 1987. |  |  |
| [RFC1123] Braden, R., "Requirements for Internet Hosts - Application |  | [RFC1123] Braden, R., "Requirements for Internet Hosts - Application |
| and Support", STD 3, RFC 1123, October 1989. |  | and Support", STD 3, RFC 1123, October 1989. |
| [RFC1305] Mills, D., "Network Time Protocol (Version 3) |  | [RFC1305] Mills, D., "Network Time Protocol (Version 3) |
| Specification, Implementation", RFC 1305, March 1992. |  | Specification, Implementation", RFC 1305, March 1992. |
| [RFC1436] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., |  | [RFC1436] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., |
| Torrey, D., and B. Alberti, "The Internet Gopher Protocol |  | Torrey, D., and B. Alberti, "The Internet Gopher Protocol |
| (a distributed document search and retrieval protocol)", |  | (a distributed document search and retrieval protocol)", |
| RFC 1436, March 1993. |  | RFC 1436, March 1993. |
| [RFC1590] Postel, J., "Media Type Registration Procedure", RFC 1590, |  |  |
| November 1996. |  |  |
| [RFC1630] Berners-Lee, T., "Universal Resource Identifiers in WWW: A |  | [RFC1630] Berners-Lee, T., "Universal Resource Identifiers in WWW: A |
| Unifying Syntax for the Expression of Names and Addresses |  | Unifying Syntax for the Expression of Names and Addresses |
| of Objects on the Network as used in the World-Wide Web", |  | of Objects on the Network as used in the World-Wide Web", |
| RFC 1630, June 1994. |  | RFC 1630, June 1994. |
| [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, |  |  |
| RFC 1700, October 1994. |  |  |
| [RFC1737] Masinter, L. and K. Sollins, "Functional Requirements for |  | [RFC1737] Masinter, L. and K. Sollins, "Functional Requirements for |
| Uniform Resource Names", RFC 1737, December 1994. |  | Uniform Resource Names", RFC 1737, December 1994. |
| [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform |  | [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform |
| Resource Locators (URL)", RFC 1738, December 1994. |  | Resource Locators (URL)", RFC 1738, December 1994. |
| [RFC1808] Fielding, R., "Relative Uniform Resource Locators", |  | [RFC1808] Fielding, R., "Relative Uniform Resource Locators", |
| RFC 1808, June 1995. |  | RFC 1808, June 1995. |
| [RFC1900] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", |  | [RFC1900] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", |
| RFC 1900, February 1996. |  | RFC 1900, February 1996. |
| [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext |  | [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext |
| Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. |  | Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. |
| [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail |  |  |
| Extensions (MIME) Part One: Format of Internet Message |  |  |
| Bodies", RFC 2045, November 1996. |  |  |
| [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) |  |  |
| Part Three: Message Header Extensions for Non-ASCII Text", |  |  |
| RFC 2047, November 1996. |  |  |
| [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. |  | [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. |
| Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", |  | Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", |
| RFC 2068, January 1997. |  | RFC 2068, January 1997. |
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |  |  |
| Requirement Levels", BCP 14, RFC 2119, March 1997. |  |  |
| [RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use |  | [RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use |
| and Interpretation of HTTP Version Numbers", RFC 2145, |  | and Interpretation of HTTP Version Numbers", RFC 2145, |
| May 1997. |  | May 1997. |
| [RFC2324] Masinter, L., "Hyper Text Coffee Pot Control Protocol |  | [RFC2324] Masinter, L., "Hyper Text Coffee Pot Control Protocol |
| (HTCPCP/1.0)", RFC 2324, April 1998. |  | (HTCPCP/1.0)", RFC 2324, April 1998. |
| [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform |  |  |
| Resource Identifiers (URI): Generic Syntax", RFC 2396, |  |  |
| August 1998. |  |  |
| [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., |  | [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext |  | Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext |
| Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. |  | Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. |
| [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, |  | [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, |
| RFC 821, August 1982. |  | April 2001. |
|  |  | [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, |
|  |  | April 2001. |
|  |  | [RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)", |
|  |  | RFC 3977, October 2006. |
| [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. |
| [RFC977] Kantor, B. and P. Lapsley, "Network News Transfer |  |  |
| Protocol", RFC 977, February 1986. |  |  |
| [Spe] Spero, S., "Analysis of HTTP Performance Problems", |  | [Spe] Spero, S., "Analysis of HTTP Performance Problems", |
| <http://sunsite.unc.edu/mdma-release/http-prob.html>. |  | <http://sunsite.unc.edu/mdma-release/http-prob.html>. |
| [Tou1998] Touch, J., Heidemann, J., and K. Obraczka, "Analysis of |  | [Tou1998] Touch, J., Heidemann, J., and K. Obraczka, "Analysis of |
| HTTP Performance", ISI Research Report ISI/RR-98-463 |  | HTTP Performance", ISI Research Report ISI/RR-98-463, |
| (original report dated Aug.1996), Aug 1998, |  | Aug 1998, <http://www.isi.edu/touch/pubs/http-perf96/>. |
| <http://www.isi.edu/touch/pubs/http-perf96/>. |  |  |
| [USASCII] American National Standards Institute, "Coded Character |  | (original report dated Aug. 1996) |
| Set -- 7-bit American Standard Code for Information |  |  |
| Interchange", ANSI X3.4, 1986. |  |  |
| [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 Type message/http and application/http |  | Appendix A. Internet Media Types |
| In addition to defining the HTTP/1.1 protocol, this document serves |  | In addition to defining the HTTP/1.1 protocol, this document serves |
| as the specification for the Internet media type "message/http" and |  | as the specification for the Internet media type "message/http" and |
| "application/http". The message/http type can be used to enclose a |  | "application/http". The following is to be registered with IANA |
| single HTTP request or response message, provided that it obeys the |  | [RFC4288]. |
| MIME restrictions for all "message" types regarding line length and |  |  |
| encodings. The application/http type can be used to enclose a |  |  |
| pipeline of one or more HTTP request or response messages (not |  |  |
| intermixed). The following is to be registered with IANA [RFC1590]. |  |  |
| Media Type name: message |  | A.1. Internet Media Type message/http |
| Media subtype name: http |  | The message/http type can be used to enclose a single HTTP request or |
|  |  | response message, provided that it obeys the MIME restrictions for |
|  |  | all "message" types regarding line length and encodings. |
|  |  | Type name: message |
|  |  | Subtype name: http |
| Required parameters: none |  | Required parameters: none |
| Optional parameters: version, msgtype |  | Optional parameters: version, msgtype |
| version: The HTTP-Version number of the enclosed message (e.g., |  | version: The HTTP-Version number of the enclosed message (e.g., |
| "1.1"). If not present, the version can be determined from the |  | "1.1"). If not present, the version can be determined from the |
| first line of the body. |  | first line of the body. |
| msgtype: The message type -- "request" or "response". If not |  | msgtype: The message type -- "request" or "response". If not |
| present, the type can be determined from the first line of the |  | present, the type can be determined from the first line of the |
| body. |  | body. |
| Encoding considerations: only "7bit", "8bit", or "binary" are |  | Encoding considerations: only "7bit", "8bit", or "binary" are |
| permitted |  | permitted |
| Security considerations: none |  | Security considerations: none |
| Media Type name: application |  | Interoperability considerations: none |
| Media subtype name: http |  | Published specification: This specification (see Appendix A.1). |
|  |  | Applications that use this media type: |
|  |  | Additional information: |
|  |  | Magic number(s): none |
|  |  | File extension(s): none |
|  |  | Macintosh file type code(s): none |
|  |  | Person and email address to contact for further information: See |
|  |  | Authors Section. |
|  |  | Intended usage: COMMON |
|  |  | Restrictions on usage: none |
|  |  | Author/Change controller: IESG |
|  |  | A.2. Internet Media Type application/http |
|  |  | The application/http type can be used to enclose a pipeline of one or |
|  |  | more HTTP request or response messages (not intermixed). |
|  |  | Type name: application |
|  |  | Subtype name: http |
| Required parameters: none |  | Required parameters: none |
| Optional parameters: version, msgtype |  | Optional parameters: version, msgtype |
| version: The HTTP-Version number of the enclosed messages (e.g., |  | version: The HTTP-Version number of the enclosed messages (e.g., |
| "1.1"). If not present, the version can be determined from the |  | "1.1"). If not present, the version can be determined from the |
| first line of the body. |  | first line of the body. |
| msgtype: The message type -- "request" or "response". If not |  | msgtype: The message type -- "request" or "response". If not |
| present, the type can be determined from the first line of the |  | present, the type can be determined from the first line of the |
| body. |  | body. |
| skipping to change at page 54, line 20 |  | skipping to change at page 55, line 15 |
| msgtype: The message type -- "request" or "response". If not |  | msgtype: The message type -- "request" or "response". If not |
| present, the type can be determined from the first line of the |  | present, the type can be determined from the first line of the |
| body. |  | body. |
| Encoding considerations: HTTP messages enclosed by this type are in |  | Encoding considerations: HTTP messages enclosed by this type are in |
| "binary" format; use of an appropriate Content-Transfer-Encoding |  | "binary" format; use of an appropriate Content-Transfer-Encoding |
| is required when transmitted via E-mail. |  | is required when transmitted via E-mail. |
| Security considerations: none |  | Security considerations: none |
|  |  | Interoperability considerations: none |
|  |  | Published specification: This specification (see Appendix A.2). |
|  |  | Applications that use this media type: |
|  |  | Additional information: |
|  |  | Magic number(s): none |
|  |  | File extension(s): none |
|  |  | Macintosh file type code(s): none |
|  |  | Person and email address to contact for further information: See |
|  |  | Authors Section. |
|  |  | Intended usage: COMMON |
|  |  | Restrictions on usage: none |
|  |  | Author/Change controller: IESG |
| Appendix B. Tolerant Applications |  | Appendix B. Tolerant Applications |
| Although this document specifies the requirements for the generation |  | Although this document specifies the requirements for the generation |
| of HTTP/1.1 messages, not all applications will be correct in their |  | of HTTP/1.1 messages, not all applications will be correct in their |
| implementation. We therefore recommend that operational applications |  | implementation. We therefore recommend that operational applications |
| be tolerant of deviations whenever those deviations can be |  | be tolerant of deviations whenever those deviations can be |
| interpreted unambiguously. |  | interpreted unambiguously. |
| Clients SHOULD be tolerant in parsing the Status-Line and servers |  | Clients SHOULD be tolerant in parsing the Status-Line and servers |
| tolerant when parsing the Request-Line. In particular, they SHOULD |  | tolerant when parsing the Request-Line. In particular, they SHOULD |
| accept any amount of SP or HT characters between fields, even though |  | accept any amount of SP or HTAB characters between fields, even |
| only a single SP is required. |  | though only a single SP is required. |
| The line terminator for message-header fields is the sequence CRLF. |  | The line terminator for message-header fields is the sequence CRLF. |
| However, we recommend that applications, when parsing such headers, |  | However, we recommend that applications, when parsing such headers, |
| recognize a single LF as a line terminator and ignore the leading CR. |  | recognize a single LF as a line terminator and ignore the leading CR. |
| The character set of an entity-body SHOULD be labeled as the lowest |  | The character set of an entity-body SHOULD be labeled as the lowest |
| common denominator of the character codes used within that body, with |  | common denominator of the character codes used within that body, with |
| the exception that not labeling the entity is preferred over labeling |  | the exception that not labeling the entity is preferred over labeling |
| the entity with the labels US-ASCII or ISO-8859-1. See [Part3]. |  | the entity with the labels US-ASCII or ISO-8859-1. See [Part3]. |
| Additional rules for requirements on parsing and encoding of dates |  | Additional rules for requirements on parsing and encoding of dates |
| and other potential problems with date encodings include: |  | and other potential problems with date encodings include: |
| skipping to change at page 56, line 5 |  | skipping to change at page 57, line 21 |
| o recognize the format of the Status-Line for HTTP/1.0 and 1.1 |  | o recognize the format of the Status-Line for HTTP/1.0 and 1.1 |
| responses; |  | responses; |
| o understand any valid response in the format of HTTP/0.9, 1.0, or |  | o understand any valid response in the format of HTTP/0.9, 1.0, or |
| 1.1. |  | 1.1. |
| For most implementations of HTTP/1.0, each connection is established |  | For most implementations of HTTP/1.0, each connection is established |
| by the client prior to the request and closed by the server after |  | by the client prior to the request and closed by the server after |
| sending the response. Some implementations implement the Keep-Alive |  | sending the response. Some implementations implement the Keep-Alive |
| version of persistent connections described in Section 19.7.1 of RFC |  | version of persistent connections described in Section 19.7.1 of |
| 2068 [RFC2068]. |  | [RFC2068]. |
| D.1. Changes from HTTP/1.0 |  | D.1. Changes from HTTP/1.0 |
| This section summarizes major differences between versions HTTP/1.0 |  | This section summarizes major differences between versions HTTP/1.0 |
| and HTTP/1.1. |  | and HTTP/1.1. |
| D.1.1. Changes to Simplify Multi-homed Web Servers and Conserve IP |  | D.1.1. Changes to Simplify Multi-homed Web Servers and Conserve IP |
| Addresses |  | Addresses |
| The requirements that clients and servers support the Host request- |  | The requirements that clients and servers support the Host request- |
| skipping to change at page 57, line 24 |  | skipping to change at page 58, line 40 |
| However, talking to proxies is the most important use of persistent |  | However, talking to proxies is the most important use of persistent |
| connections, so that prohibition is clearly unacceptable. Therefore, |  | connections, so that prohibition is clearly unacceptable. Therefore, |
| we need some other mechanism for indicating a persistent connection |  | we need some other mechanism for indicating a persistent connection |
| is desired, which is safe to use even when talking to an old proxy |  | is desired, which is safe to use even when talking to an old proxy |
| that ignores Connection. Persistent connections are the default for |  | that ignores Connection. Persistent connections are the default for |
| HTTP/1.1 messages; we introduce a new keyword (Connection: close) for |  | HTTP/1.1 messages; we introduce a new keyword (Connection: close) for |
| declaring non-persistence. See Section 8.1. |  | declaring non-persistence. See Section 8.1. |
| The original HTTP/1.0 form of persistent connections (the Connection: |  | The original HTTP/1.0 form of persistent connections (the Connection: |
| Keep-Alive and Keep-Alive header) is documented in RFC 2068. |  | Keep-Alive and Keep-Alive header) is documented in [RFC2068]. |
| [RFC2068] |  |  |
| D.3. Changes from RFC 2068 |  | D.3. Changes from RFC 2068 |
| This specification has been carefully audited to correct and |  | This specification has been carefully audited to correct and |
| disambiguate key word usage; RFC 2068 had many problems in respect to |  | disambiguate key word usage; RFC 2068 had many problems in respect to |
| the conventions laid out in RFC 2119 [RFC2119]. |  | the conventions laid out in [RFC2119]. |
| Transfer-coding and message lengths all interact in ways that |  | Transfer-coding and message lengths all interact in ways that |
| required fixing exactly when chunked encoding is used (to allow for |  | required fixing exactly when chunked encoding is used (to allow for |
| transfer encoding that may not be self delimiting); it was important |  | transfer encoding that may not be self delimiting); it was important |
| to straighten out exactly how message lengths are computed. |  | to straighten out exactly how message lengths are computed. |
| The use and interpretation of HTTP version numbers has been clarified |  | (Sections 3.4, 4.4, 8.2, see also [Part3], [Part5] and [Part6]) |
| by RFC 2145. Require proxies to upgrade requests to highest protocol |  |  |
| version they support to deal with problems discovered in HTTP/1.0 |  |  |
| implementations (Section 3.1) |  |  |
| Proxies should be able to add Content-Length when appropriate. |  | The use and interpretation of HTTP version numbers has been clarified |
|  |  | by [RFC2145]. Require proxies to upgrade requests to highest |
|  |  | protocol version they support to deal with problems discovered in |
|  |  | HTTP/1.0 implementations (Section 3.1) |
| Transfer-coding had significant problems, particularly with |  | Transfer-coding had significant problems, particularly with |
| interactions with chunked encoding. The solution is that transfer- |  | interactions with chunked encoding. The solution is that transfer- |
| codings become as full fledged as content-codings. This involves |  | codings become as full fledged as content-codings. This involves |
| adding an IANA registry for transfer-codings (separate from content |  | adding an IANA registry for transfer-codings (separate from content |
| codings), a new header field (TE) and enabling trailer headers in the |  | codings), a new header field (TE) and enabling trailer headers in the |
| future. Transfer encoding is a major performance benefit, so it was |  | future. Transfer encoding is a major performance benefit, so it was |
| worth fixing [Nie1997]. TE also solves another, obscure, downward |  | worth fixing [Nie1997]. TE also solves another, obscure, downward |
| interoperability problem that could have occurred due to interactions |  | interoperability problem that could have occurred due to interactions |
| between authentication trailers, chunked encoding and HTTP/1.0 |  | between authentication trailers, chunked encoding and HTTP/1.0 |
| clients.(Section 3.4, 3.4.1, and 8.5) |  | clients.(Section 3.4, 3.4.1, and 8.5) |
|  |  | D.4. Changes from RFC 2616 |
|  |  | Clarify that HTTP-Version is case sensitive. (Section 3.1) |
|  |  | Remove reference to non-existant identity transfer-coding value |
|  |  | tokens. (Sections 3.4 and 4.4) |
|  |  | Clarification that the chunk length does not include the count of the |
|  |  | 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 |
|  |  | [RFC2396] doesn't define it. (Section 5.1.2) |
|  |  | Clarify exactly when close connection options must be sent. |
|  |  | (Section 8.1) |
|  |  | Appendix E. Change Log (to be removed by RFC Editor before publication) |
|  |  | E.1. Since RFC2616 |
|  |  | Extracted relevant partitions from [RFC2616]. |
|  |  | E.2. Since draft-ietf-httpbis-p1-messaging-00 |
|  |  | Closed issues: |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/1>: "HTTP |
|  |  | Version should be case sensitive" |
|  |  | (<http://purl.org/NET/http-errata#verscase>) |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/2>: "'unsafe' |
|  |  | characters" (<http://purl.org/NET/http-errata#unsafe-uri>) |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/3>: "Chunk Size |
|  |  | Definition" (<http://purl.org/NET/http-errata#chunk-size>) |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/4>: "Message |
|  |  | Length" (<http://purl.org/NET/http-errata#msg-len-chars>) |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/8>: "Media Type |
|  |  | Registrations" (<http://purl.org/NET/http-errata#media-reg>) |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/11>: "URI |
|  |  | includes query" (<http://purl.org/NET/http-errata#uriquery>) |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/15>: "No close |
|  |  | on 1xx responses" (<http://purl.org/NET/http-errata#noclose1xx>) |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/16>: "Remove |
|  |  | 'identity' token references" |
|  |  | (<http://purl.org/NET/http-errata#identity>) |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/26>: "Import |
|  |  | query BNF" |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/31>: "qdtext |
|  |  | BNF" |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative |
|  |  | and Informative references" |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/42>: "RFC2606 |
|  |  | Compliance" |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/45>: "RFC977 |
|  |  | reference" |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/46>: "RFC1700 |
|  |  | references" |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/47>: |
|  |  | "inconsistency in date format explanation" |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/48>: "Date |
|  |  | reference typo" |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/65>: |
|  |  | "Informative references" |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/66>: |
|  |  | "ISO-8859-1 Reference" |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/86>: "Normative |
|  |  | up-to-date references" |
|  |  | Other changes: |
|  |  | o Update media type registrations to use RFC4288 template. |
|  |  | o Use names of RFC4234 core rules DQUOTE and HTAB, fix broken ABNF |
|  |  | for chunk-data (work in progress on |
|  |  | <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36>) |
| Index |  | Index |
| A |  | A |
| application/http Media Type 53 |  | application/http Media Type 54 |
| C |  | C |
| cache 8 |  | cache 8 |
| cacheable 8 |  | cacheable 9 |
| client 7 |  | client 7 |
| connection 6 |  | connection 6 |
| Connection header 37 |  | Connection header 38 |
| content negotiation 7 |  | content negotiation 7 |
| Content-Length header 38 |  | Content-Length header 39 |
| D |  | D |
| Date header 39 |  | Date header 39 |
| downstream 9 |  | downstream 9 |
| E |  | E |
| entity 6 |  | entity 7 |
| G |  | G |
| gateway 8 |  | gateway 8 |
| Grammar |  | Grammar |
| ALPHA 13 |  | ALPHA 14 |
| asctime-date 19 |  | asctime-date 19 |
| attribute 19 |  | attribute 20 |
| CHAR 13 |  | CHAR 14 |
| chunk 21 |  | chunk 21 |
| chunk-data 21 |  | chunk-data 21 |
| chunk-ext-name 21 |  | chunk-ext-name 21 |
| chunk-ext-val 21 |  | chunk-ext-val 21 |
| chunk-extension 21 |  | chunk-extension 21 |
| chunk-size 21 |  | chunk-size 21 |
| Chunked-Body 21 |  | Chunked-Body 21 |
| comment 14 |  | comment 15 |
| Connection 37 |  | Connection 38 |
| connection-token 37 |  | connection-token 38 |
| Content-Length 38 |  | Content-Length 39 |
| CR 13 |  | CR 14 |
| CRLF 13 |  | CRLF 14 |
| ctext 14 |  | ctext 15 |
| CTL 13 |  | CTL 14 |
| Date 39 |  | Date 39 |
| date1 19 |  | date1 19 |
| date2 19 |  | date2 19 |
| date3 19 |  | date3 19 |
| DIGIT 13 |  | DIGIT 14 |
|  |  | DQUOTE 14 |
| extension-code 30 |  | extension-code 30 |
| extension-method 27 |  | extension-method 27 |
| field-content 23 |  | field-content 23 |
| field-name 23 |  | field-name 23 |
| field-value 23 |  | field-value 23 |
| general-header 26 |  | general-header 26 |
| generic-message 22 |  | generic-message 22 |
| HEX 14 |  | HEX 14 |
| Host 40 |  | Host 41 |
| HT 13 |  | HTAB 14 |
| HTTP-date 19 |  | HTTP-date 19 |
| HTTP-message 22 |  | HTTP-message 22 |
| HTTP-Version 15 |  | HTTP-Version 16 |
| http_URL 17 |  | http_URL 17 |
| last-chunk 21 |  | last-chunk 21 |
| LF 13 |  | LF 14 |
| LOALPHA 13 |  | LOALPHA 14 |
| LWS 14 |  | LWS 14 |
| message-body 24 |  | message-body 24 |
| message-header 23 |  | message-header 23 |
| Method 27 |  | Method 27 |
| month 19 |  | month 19 |
| OCTET 13 |  | OCTET 14 |
| parameter 19 |  | parameter 20 |
| protocol-name 44 |  | protocol-name 45 |
| protocol-version 44 |  | protocol-version 45 |
| pseudonym 44 |  | pseudonym 45 |
| qdtext 15 |  | qdtext 15 |
| quoted-pair 15 |  | quoted-pair 15 |
| quoted-string 15 |  | quoted-string 15 |
| Reason-Phrase 30 |  | Reason-Phrase 30 |
| received-by 44 |  | received-by 45 |
| received-protocol 44 |  | received-protocol 45 |
| Request 27 |  | Request 27 |
| Request-Line 27 |  | Request-Line 27 |
| Request-URI 27 |  | Request-URI 27 |
| Response 29 |  | Response 29 |
| rfc850-date 19 |  | rfc850-date 19 |
| rfc1123-date 19 |  | rfc1123-date 19 |
| separators 14 |  | separators 15 |
| SP 13 |  | SP 14 |
| start-line 22 |  | start-line 22 |
| Status-Code 30 |  | Status-Code 30 |
| Status-Line 29 |  | Status-Line 30 |
| t-codings 41 |  | t-codings 41 |
| TE 41 |  | TE 41 |
| TEXT 14 |  | TEXT 14 |
| time 19 |  | time 19 |
| token 14 |  | token 15 |
| Trailer 42 |  | Trailer 42 |
| trailer 21 |  | trailer 21 |
| transfer-coding 19 |  | transfer-coding 19 |
| Transfer-Encoding 43 |  | Transfer-Encoding 43 |
| transfer-extension 19 |  | transfer-extension 19 |
| UPALPHA 13 |  | UPALPHA 14 |
| Upgrade 43 |  | Upgrade 43 |
| value 19 |  | value 20 |
| Via 44 |  | Via 45 |
| weekday 19 |  | weekday 19 |
| wkday 19 |  | wkday 19 |
| H |  | H |
| Headers |  | Headers |
| Connection 37 |  | Connection 38 |
| Content-Length 38 |  | Content-Length 39 |
| Date 39 |  | Date 39 |
| Host 40 |  | Host 40 |
| TE 41 |  | TE 41 |
| Trailer 42 |  | Trailer 42 |
| Transfer-Encoding 43 |  | Transfer-Encoding 43 |
| Upgrade 43 |  | Upgrade 43 |
| Via 44 |  | Via 44 |
| Host header 40 |  | Host header 40 |
| I |  | I |
| inbound 9 |  | inbound 9 |
| M |  | M |
| Media Type |  | Media Type |
| application/http 53 |  | application/http 54 |
| message/http 53 |  | message/http 53 |
| message 6 |  | message 6 |
| message/http Media Type 53 |  | message/http Media Type 53 |
| O |  | O |
| origin server 8 |  | origin server 8 |
| outbound 9 |  | outbound 9 |
| P |  | P |
| proxy 8 |  | proxy 8 |
| skipping to change at page 61, line 4 |  | skipping to change at page 64, line 14 |
| message/http 53 |  | message/http 53 |
| message 6 |  | message 6 |
| message/http Media Type 53 |  | message/http Media Type 53 |
| 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 6 |  | resource 7 |
| response 6 |  | response 6 |
| S |  | S |
| server 7 |  | server 8 |
| T |  | T |
| TE header 41 |  | TE header 41 |
| Trailer header 42 |  | Trailer header 42 |
| Transfer-Encoding header 43 |  | Transfer-Encoding header 43 |
| tunnel 8 |  | tunnel 8 |
| U |  | U |
| Upgrade header 43 |  | Upgrade header 43 |
| upstream 9 |  | upstream 9 |
| skipping to change at page 63, line 5 |  | skipping to change at page 66, line 31 |
| World Wide Web Consortium |  | World Wide Web Consortium |
| MIT Computer Science and Artificial Intelligence Laboratory |  | MIT Computer Science and Artificial Intelligence Laboratory |
| The Stata Center, Building 32 |  | The Stata Center, Building 32 |
| 32 Vassar Street |  | 32 Vassar Street |
| Cambridge, MA 02139 |  | Cambridge, MA 02139 |
| USA |  | USA |
| Email: timbl@w3.org |  | Email: timbl@w3.org |
| URI: http://www.w3.org/People/Berners-Lee/ |  | URI: http://www.w3.org/People/Berners-Lee/ |
|  |  | Yves Lafon (editor) |
|  |  | World Wide Web Consortium |
|  |  | W3C / ERCIM |
|  |  | 2004, rte des Lucioles |
|  |  | Sophia-Antipolis, AM 06902 |
|  |  | France |
|  |  | Email: ylafon@w3.org |
|  |  | URI: http://www.raubacapeu.net/people/yves/ |
|  |  | Julian F. Reschke (editor) |
|  |  | greenbytes GmbH |
|  |  | Hafenweg 16 |
|  |  | Muenster, NW 48155 |
|  |  | Germany |
|  |  | Phone: +49 251 2807760 |
|  |  | Fax: +49 251 2807761 |
|  |  | Email: julian.reschke@greenbytes.de |
|  |  | URI: http://greenbytes.de/tech/webdav/ |
| Full Copyright Statement |  | Full Copyright Statement |
| Copyright (C) The IETF Trust (2007). |  | Copyright (C) The IETF Trust (2008). |
| This document is subject to the rights, licenses and restrictions |  | This document is subject to the rights, licenses and restrictions |
| contained in BCP 78, and except as set forth therein, the authors |  | contained in BCP 78, and except as set forth therein, the authors |
| retain all their rights. |  | retain all their rights. |
| This document and the information contained herein are provided on an |  | This document and the information contained herein are provided on an |
| "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS |  | "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS |
| OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND |  | OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND |
| THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS |  | THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS |
| OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF |  | OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF |
End of changes. 147 change blocks.
| 365 lines changed or deleted |  | 552 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/