| draft-ietf-httpbis-p1-messaging-03.txt |  | draft-ietf-httpbis-p1-messaging-04.txt |
--- | --- | --- | --- | ---
| Network Working Group R. Fielding, Ed. |  | Network Working Group R. Fielding, Ed. |
| Internet-Draft Day Software |  | Internet-Draft Day Software |
| Obsoletes: 2616 (if approved) J. Gettys |  | Obsoletes: 2616 (if approved) J. Gettys |
| Intended status: Standards Track One Laptop per Child |  | Intended status: Standards Track One Laptop per Child |
| Expires: December 19, 2008 J. Mogul |  | Expires: March 2, 2009 J. Mogul |
| HP |  | HP |
| H. Frystyk |  | H. Frystyk |
| Microsoft |  | Microsoft |
| L. Masinter |  | L. Masinter |
| Adobe Systems |  | Adobe Systems |
| P. Leach |  | P. Leach |
| Microsoft |  | Microsoft |
| T. Berners-Lee |  | T. Berners-Lee |
| W3C/MIT |  | W3C/MIT |
| Y. Lafon, Ed. |  | Y. Lafon, Ed. |
| W3C |  | W3C |
| J. Reschke, Ed. |  | J. Reschke, Ed. |
| greenbytes |  | greenbytes |
| June 17, 2008 |  | August 29, 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-03 |  | draft-ietf-httpbis-p1-messaging-04 |
| Status of this Memo |  | Status of this Memo |
| By submitting this Internet-Draft, each author represents that any |  | By submitting this Internet-Draft, each author represents that any |
| applicable patent or other IPR claims of which he or she is aware |  | applicable patent or other IPR claims of which he or she is aware |
| have been or will be disclosed, and any of which he or she becomes |  | have been or will be disclosed, and any of which he or she becomes |
| aware will be disclosed, in accordance with Section 6 of BCP 79. |  | aware will be disclosed, in accordance with Section 6 of BCP 79. |
| Internet-Drafts are working documents of the Internet Engineering |  | Internet-Drafts are working documents of the Internet Engineering |
| Task Force (IETF), its areas, and its working groups. Note that |  | Task Force (IETF), its areas, and its working groups. Note that |
| skipping to change at page 1, line 49 |  | skipping to change at page 1, line 49 |
| and may be updated, replaced, or obsoleted by other documents at any |  | and may be updated, replaced, or obsoleted by other documents at any |
| time. It is inappropriate to use Internet-Drafts as reference |  | time. It is inappropriate to use Internet-Drafts as reference |
| material or to cite them other than as "work in progress." |  | material or to cite them other than as "work in progress." |
| The list of current Internet-Drafts can be accessed at |  | The list of current Internet-Drafts can be accessed at |
| http://www.ietf.org/ietf/1id-abstracts.txt. |  | http://www.ietf.org/ietf/1id-abstracts.txt. |
| The list of Internet-Draft Shadow Directories can be accessed at |  | The list of Internet-Draft Shadow Directories can be accessed at |
| http://www.ietf.org/shadow.html. |  | http://www.ietf.org/shadow.html. |
| This Internet-Draft will expire on December 19, 2008. |  | This Internet-Draft will expire on March 2, 2009. |
| 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 |
| skipping to change at page 2, line 26 |  | skipping to change at page 2, line 26 |
| frames, and describes general security concerns for implementations. |  | frames, and describes general security concerns for implementations. |
| Editorial Note (To be removed by RFC Editor) |  | Editorial Note (To be removed by RFC Editor) |
| Discussion of this draft should take place on the HTTPBIS working |  | Discussion of this draft should take place on the HTTPBIS working |
| group mailing list (ietf-http-wg@w3.org). The current issues list is |  | group mailing list (ietf-http-wg@w3.org). The current issues list is |
| at <http://www.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://www.tools.ietf.org/wg/httpbis/>. |  | <http://www.tools.ietf.org/wg/httpbis/>. |
| The changes in this draft are summarized in Appendix E.4. |  | The changes in this draft are summarized in Appendix D.4. |
| 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 |
| 2.3. ABNF Rules defined in other Parts of the Specification . . 16 |  | 2.3. ABNF Rules defined in other Parts of the Specification . . 16 |
| 3. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 16 |  | 3. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 16 |
| 3.1. HTTP Version . . . . . . . . . . . . . . . . . . . . . . . 16 |  | 3.1. HTTP Version . . . . . . . . . . . . . . . . . . . . . . . 16 |
| 3.2. Uniform Resource Identifiers . . . . . . . . . . . . . . . 17 |  | 3.2. Uniform Resource Identifiers . . . . . . . . . . . . . . . 17 |
| 3.2.1. General Syntax . . . . . . . . . . . . . . . . . . . . 17 |  | 3.2.1. General Syntax . . . . . . . . . . . . . . . . . . . . 17 |
| 3.2.2. http URL . . . . . . . . . . . . . . . . . . . . . . . 18 |  | 3.2.2. http URL . . . . . . . . . . . . . . . . . . . . . . . 18 |
| 3.2.3. URI Comparison . . . . . . . . . . . . . . . . . . . . 18 |  | 3.2.3. URI Comparison . . . . . . . . . . . . . . . . . . . . 19 |
| 3.3. Date/Time Formats . . . . . . . . . . . . . . . . . . . . 19 |  | 3.3. Date/Time Formats . . . . . . . . . . . . . . . . . . . . 19 |
| 3.3.1. Full Date . . . . . . . . . . . . . . . . . . . . . . 19 |  | 3.3.1. Full Date . . . . . . . . . . . . . . . . . . . . . . 19 |
| 3.4. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 20 |  | 3.4. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 21 |
| 3.4.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 21 |  | 3.4.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 22 |
| 3.5. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 23 |  | 3.5. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 24 |
| 4. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . . 24 |  | 4. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . . 24 |
| 4.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 24 |  | 4.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 24 |
| 4.2. Message Headers . . . . . . . . . . . . . . . . . . . . . 24 |  | 4.2. Message Headers . . . . . . . . . . . . . . . . . . . . . 25 |
| 4.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 25 |  | 4.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 26 |
| 4.4. Message Length . . . . . . . . . . . . . . . . . . . . . . 26 |  | 4.4. Message Length . . . . . . . . . . . . . . . . . . . . . . 27 |
| 4.5. General Header Fields . . . . . . . . . . . . . . . . . . 28 |  | 4.5. General Header Fields . . . . . . . . . . . . . . . . . . 28 |
| 5. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 |  | 5. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 |
| 5.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 28 |  | 5.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 29 |
| 5.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 29 |  | 5.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 29 |
| 5.1.2. Request-URI . . . . . . . . . . . . . . . . . . . . . 29 |  | 5.1.2. Request-URI . . . . . . . . . . . . . . . . . . . . . 30 |
| 5.2. The Resource Identified by a Request . . . . . . . . . . . 30 |  | 5.2. The Resource Identified by a Request . . . . . . . . . . . 31 |
| 6. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 |  | 6. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 |
| 6.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 31 |  | 6.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 32 |
| 6.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 31 |  | 6.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 32 |
| 7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 32 |  | 7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 33 |
| 7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 32 |  | 7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 33 |
| 7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 32 |  | 7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 33 |
| 7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 33 |  | 7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 34 |
| 7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 34 |  | 7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 35 |
| 7.1.4. Practical Considerations . . . . . . . . . . . . . . . 35 |  | 7.1.4. Practical Considerations . . . . . . . . . . . . . . . 35 |
| 7.2. Message Transmission Requirements . . . . . . . . . . . . 36 |  | 7.2. Message Transmission Requirements . . . . . . . . . . . . 36 |
| 7.2.1. Persistent Connections and Flow Control . . . . . . . 36 |  | 7.2.1. Persistent Connections and Flow Control . . . . . . . 37 |
| 7.2.2. Monitoring Connections for Error Status Messages . . . 36 |  | 7.2.2. Monitoring Connections for Error Status Messages . . . 37 |
| 7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 36 |  | 7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 37 |
| 7.2.4. Client Behavior if Server Prematurely Closes |  | 7.2.4. Client Behavior if Server Prematurely Closes |
| Connection . . . . . . . . . . . . . . . . . . . . . . 38 |  | Connection . . . . . . . . . . . . . . . . . . . . . . 39 |
| 8. Header Field Definitions . . . . . . . . . . . . . . . . . . . 39 |  | 8. Header Field Definitions . . . . . . . . . . . . . . . . . . . 40 |
| 8.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 39 |  | 8.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 40 |
| 8.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 40 |  | 8.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 41 |
| 8.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 |  | 8.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 |
| 8.3.1. Clockless Origin Server Operation . . . . . . . . . . 42 |  | 8.3.1. Clockless Origin Server Operation . . . . . . . . . . 43 |
| 8.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 |  | 8.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 |
| 8.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 |  | 8.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 |
| 8.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 44 |  | 8.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 45 |
| 8.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 44 |  | 8.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 45 |
| 8.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 45 |  | 8.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 46 |
| 8.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 |  | 8.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 |
| 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 |  | 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 |
| 9.1. Message Header Registration . . . . . . . . . . . . . . . 47 |  | 9.1. Message Header Registration . . . . . . . . . . . . . . . 48 |
| 10. Security Considerations . . . . . . . . . . . . . . . . . . . 48 |  | 9.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 49 |
| 10.1. Personal Information . . . . . . . . . . . . . . . . . . . 48 |  | 9.3. Internet Media Type Registrations . . . . . . . . . . . . 49 |
| 10.2. Abuse of Server Log Information . . . . . . . . . . . . . 48 |  | 9.3.1. Internet Media Type message/http . . . . . . . . . . . 49 |
| 10.3. Attacks Based On File and Path Names . . . . . . . . . . . 49 |  | 9.3.2. Internet Media Type application/http . . . . . . . . . 50 |
| 10.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 49 |  | 10. Security Considerations . . . . . . . . . . . . . . . . . . . 51 |
| 10.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 50 |  | 10.1. Personal Information . . . . . . . . . . . . . . . . . . . 52 |
| 10.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 50 |  | 10.2. Abuse of Server Log Information . . . . . . . . . . . . . 52 |
| 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50 |  | 10.3. Attacks Based On File and Path Names . . . . . . . . . . . 52 |
| 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52 |  | 10.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 52 |
| 12.1. Normative References . . . . . . . . . . . . . . . . . . . 52 |  | 10.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 53 |
| 12.2. Informative References . . . . . . . . . . . . . . . . . . 53 |  | 10.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 54 |
| Appendix A. Internet Media Types . . . . . . . . . . . . . . . . 55 |  | 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 54 |
| A.1. Internet Media Type message/http . . . . . . . . . . . . . 55 |  | 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55 |
| A.2. Internet Media Type application/http . . . . . . . . . . . 56 |  | 12.1. Normative References . . . . . . . . . . . . . . . . . . . 55 |
| Appendix B. Tolerant Applications . . . . . . . . . . . . . . . . 57 |  | 12.2. Informative References . . . . . . . . . . . . . . . . . . 56 |
| Appendix C. Conversion of Date Formats . . . . . . . . . . . . . 58 |  | Appendix A. Tolerant Applications . . . . . . . . . . . . . . . . 59 |
| Appendix D. Compatibility with Previous Versions . . . . . . . . 58 |  | Appendix B. Conversion of Date Formats . . . . . . . . . . . . . 59 |
| D.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 59 |  | Appendix C. Compatibility with Previous Versions . . . . . . . . 60 |
| D.1.1. Changes to Simplify Multi-homed Web Servers and |  | C.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 60 |
| Conserve IP Addresses . . . . . . . . . . . . . . . . 59 |  | C.1.1. Changes to Simplify Multi-homed Web Servers and |
| D.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 60 |  | Conserve IP Addresses . . . . . . . . . . . . . . . . 60 |
| D.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 60 |  | C.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 61 |
| D.4. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 61 |  | C.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 62 |
| Appendix E. Change Log (to be removed by RFC Editor before |  | C.4. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 62 |
| publication) . . . . . . . . . . . . . . . . . . . . 61 |  | Appendix D. Change Log (to be removed by RFC Editor before |
| E.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 61 |  | publication) . . . . . . . . . . . . . . . . . . . . 63 |
| E.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 61 |  | D.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 63 |
| E.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 63 |  | D.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 63 |
| E.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 64 |  | D.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 64 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 |  | D.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 65 |
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 68 |  | D.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 66 |
| Intellectual Property and Copyright Statements . . . . . . . . . . 71 |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 |
|  |  | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 70 |
|  |  | Intellectual Property and Copyright Statements . . . . . . . . . . 73 |
| 1. Introduction |  | 1. Introduction |
| The Hypertext Transfer Protocol (HTTP) is an application-level |  | The Hypertext Transfer Protocol (HTTP) is an application-level |
| protocol for distributed, collaborative, hypermedia information |  | protocol for distributed, collaborative, hypermedia information |
| systems. HTTP has been in use by the World-Wide Web global |  | systems. HTTP has been in use by the World-Wide Web global |
| information initiative since 1990. The first version of HTTP, |  | information initiative since 1990. The first version of HTTP, |
| commonly referred to as HTTP/0.9, was a simple protocol for raw data |  | commonly referred to as HTTP/0.9, was a simple protocol for raw data |
| transfer across the Internet with only a single method and no |  | transfer across the Internet with only a single method and no |
| metadata. HTTP/1.0, as defined by [RFC1945], improved the protocol |  | metadata. HTTP/1.0, as defined by [RFC1945], improved the protocol |
| skipping to change at page 14, line 27 |  | skipping to change at page 14, line 27 |
| LF = %x0A |  | LF = %x0A |
| ; US-ASCII LF, linefeed (10) |  | ; US-ASCII LF, linefeed (10) |
| SP = %x20 |  | SP = %x20 |
| ; US-ASCII SP, space (32) |  | ; US-ASCII SP, space (32) |
| HTAB = %x09 |  | HTAB = %x09 |
| ; US-ASCII HT, horizontal-tab (9) |  | ; US-ASCII HT, horizontal-tab (9) |
| DQUOTE = %x22 |  | DQUOTE = %x22 |
| ; US-ASCII double-quote mark (34) |  | ; 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 A for tolerant |
| applications). The end-of-line marker within an entity-body is |  | applications). The end-of-line marker within an entity-body is |
| defined by its associated media type, as described in Section 3.3 of |  | defined by its associated media type, as described in Section 3.3 of |
| [Part3]. |  | [Part3]. |
| CRLF = CR LF |  | CRLF = CR LF |
| HTTP/1.1 header field values can be folded onto multiple lines if the |  | HTTP/1.1 header field values can be folded onto multiple lines if the |
| continuation line begins with a space or horizontal tab. All linear |  | continuation line begins with a space or horizontal tab. All linear |
| white space, including folding, has the same semantics as SP. A |  | white space, including folding, has the same semantics as SP. A |
| recipient MAY replace any linear white space with a single SP before |  | recipient MAY replace any linear white space with a single SP before |
| skipping to change at page 15, line 8 |  | skipping to change at page 15, line 8 |
| TEXT = %x20-7E | %x80-FF | LWS |  | TEXT = %x20-7E | %x80-FF | LWS |
| ; any OCTET except CTLs, but including LWS |  | ; any OCTET except CTLs, but including LWS |
| A CRLF is allowed in the definition of TEXT only as part of a header |  | A CRLF is allowed in the definition of TEXT only as part of a header |
| field continuation. It is expected that the folding LWS will be |  | field continuation. It is expected that the folding LWS will be |
| replaced with a single SP before interpretation of the TEXT value. |  | replaced with a single SP before interpretation of the TEXT value. |
| Hexadecimal numeric characters are used in several protocol elements. |  | Hexadecimal numeric characters are used in several protocol elements. |
| HEX = "A" | "B" | "C" | "D" | "E" | "F" |  | HEXDIG = "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). |
| separators = "(" | ")" | "<" | ">" | "@" |  | separators = "(" | ")" | "<" | ">" | "@" |
| | "," | ";" | ":" | "\" | DQUOTE |  | | "," | ";" | ":" | "\" | DQUOTE |
| | "/" | "[" | "]" | "?" | "=" |  | | "/" | "[" | "]" | "?" | "=" |
| skipping to change at page 18, line 48 |  | skipping to change at page 18, line 48 |
| 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 path-absolute (Section 5.1.2). The use of IP |  | for the resource is path-absolute (Section 5.1.2). The use of IP |
| addresses in URLs SHOULD be avoided whenever possible (see |  | addresses in URLs SHOULD be avoided whenever possible (see |
| [RFC1900]). If the path-absolute is not present in the URL, it MUST |  | [RFC1900]). If the path-absolute is not present in the URL, it MUST |
| be given as "/" when used as a Request-URI for a resource |  | be given as "/" when used as a Request-URI for a resource |
| (Section 5.1.2). If a proxy receives a host name which is not a |  | (Section 5.1.2). If a proxy receives a host name which is not a |
| fully qualified domain name, it MAY add its domain to the host name |  | fully qualified domain name, it MAY add its domain to the host name |
| it received. If a proxy receives a fully qualified domain name, the |  | it received. If a proxy receives a fully qualified domain name, the |
| proxy MUST NOT change the host name. |  | proxy MUST NOT change the host name. |
|  |  | Note: the "https" scheme is defined in [RFC2818]. |
| 3.2.3. URI Comparison |  | 3.2.3. URI Comparison |
| When comparing two URIs to decide if they match or not, a client |  | When comparing two URIs to decide if they match or not, a client |
| SHOULD use a case-sensitive octet-by-octet comparison of the entire |  | SHOULD use a case-sensitive octet-by-octet comparison of the entire |
| URIs, with these exceptions: |  | URIs, with these exceptions: |
| o A port that is empty or not given is equivalent to the default |  | o A port that is empty or not given is equivalent to the default |
| port for that URI-reference; |  | port for that URI-reference; |
| o Comparisons of host names MUST be case-insensitive; |  | o Comparisons of host names MUST be case-insensitive; |
| o Comparisons of scheme names MUST be case-insensitive; |  | o Comparisons of scheme names MUST be case-insensitive; |
| o An empty path-absolute is equivalent to an path-absolute of "/". |  | o An empty path-absolute is equivalent to an path-absolute of "/". |
| Characters other than those in the "reserved" set (see [RFC2396]) are |  | Characters other than those in the "reserved" set (see [RFC2396], |
| equivalent to their ""%" HEX HEX" encoding. |  | Section 2.2) are equivalent to their ""%" HEXDIG HEXDIG" encoding. |
| For example, the following three URIs are equivalent: |  | For example, the following three URIs are equivalent: |
| http://example.com:80/~smith/home.html |  | http://example.com:80/~smith/home.html |
| http://EXAMPLE.com/%7Esmith/home.html |  | http://EXAMPLE.com/%7Esmith/home.html |
| http://EXAMPLE.com:/%7esmith/home.html |  | http://EXAMPLE.com:/%7esmith/home.html |
| 3.3. Date/Time Formats |  | 3.3. Date/Time Formats |
| 3.3.1. Full Date |  | 3.3.1. Full Date |
| skipping to change at page 19, line 42 |  | skipping to change at page 19, line 47 |
| Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format |  | 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 [RFC1123] (an update to |  | a fixed-length subset of that defined by [RFC1123] (an update to |
| [RFC822]). The other formats are described here only for |  | [RFC822]). The other formats are described here only for |
| compatibility with obsolete implementations. HTTP/1.1 clients and |  | compatibility with obsolete implementations. HTTP/1.1 clients and |
| servers that parse the date value MUST accept all three formats (for |  | servers that parse the date value MUST accept all three formats (for |
| compatibility with HTTP/1.0), though they MUST only generate the RFC |  | compatibility with HTTP/1.0), though they MUST only generate the RFC |
| 1123 format for representing HTTP-date values in header fields. See |  | 1123 format for representing HTTP-date values in header fields. See |
| Appendix B for further information. |  | Appendix A for 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 |
| abbreviation for time zone, and MUST be assumed when reading the |  | abbreviation for time zone, and MUST be assumed when reading the |
| asctime format. HTTP-date is case sensitive and MUST NOT include |  | asctime format. HTTP-date is case sensitive and MUST NOT include |
| additional LWS beyond that specifically included as SP in the |  | additional LWS beyond that specifically included as SP in the |
| grammar. |  | grammar. |
| HTTP-date = rfc1123-date | obsolete-date |  | HTTP-date = rfc1123-date | obsolete-date |
| obsolete-date = rfc850-date | asctime-date |  | obsolete-date = rfc850-date | asctime-date |
| rfc1123-date = wkday "," SP date1 SP time SP "GMT" |  | rfc1123-date = wkday "," SP date1 SP time SP GMT |
| rfc850-date = weekday "," SP date2 SP time SP "GMT" |  | rfc850-date = weekday "," SP date2 SP time SP GMT |
| asctime-date = wkday SP date3 SP time SP 4DIGIT |  | asctime-date = wkday SP date3 SP time SP 4DIGIT |
| date1 = 2DIGIT SP month SP 4DIGIT |  | date1 = 2DIGIT SP month SP 4DIGIT |
| ; day month year (e.g., 02 Jun 1982) |  | ; day month year (e.g., 02 Jun 1982) |
| date2 = 2DIGIT "-" month "-" 2DIGIT |  | date2 = 2DIGIT "-" month "-" 2DIGIT |
| ; day-month-year (e.g., 02-Jun-82) |  | ; day-month-year (e.g., 02-Jun-82) |
| date3 = month SP ( 2DIGIT | ( SP 1DIGIT )) |  | date3 = month SP ( 2DIGIT | ( SP 1DIGIT )) |
| ; month day (e.g., Jun 2) |  | ; month day (e.g., Jun 2) |
| time = 2DIGIT ":" 2DIGIT ":" 2DIGIT |  | time = 2DIGIT ":" 2DIGIT ":" 2DIGIT |
| ; 00:00:00 - 23:59:59 |  | ; 00:00:00 - 23:59:59 |
| wkday = "Mon" | "Tue" | "Wed" |  | wkday = s-Mon | s-Tue | s-Wed |
| | "Thu" | "Fri" | "Sat" | "Sun" |  | | s-Thu | s-Fri | s-Sat | s-Sun |
| weekday = "Monday" | "Tuesday" | "Wednesday" |  | weekday = l-Mon | l-Tue | l-Wed |
| | "Thursday" | "Friday" | "Saturday" | "Sunday" |  | | l-Thu | l-Fri | l-Sat | l-Sun |
| month = "Jan" | "Feb" | "Mar" | "Apr" |  | month = s-Jan | s-Feb | s-Mar | s-Apr |
| | "May" | "Jun" | "Jul" | "Aug" |  | | s-May | s-Jun | s-Jul | s-Aug |
| | "Sep" | "Oct" | "Nov" | "Dec" |  | | s-Sep | s-Oct | s-Nov | s-Dec |
|  |  | GMT = %x47.4D.54 ; "GMT", case-sensitive |
|  |  | s-Mon = %x4D.6F.6E ; "Mon", case-sensitive |
|  |  | s-Tue = %x54.75.65 ; "Tue", case-sensitive |
|  |  | s-Wed = %x57.65.64 ; "Wed", case-sensitive |
|  |  | s-Thu = %x54.68.75 ; "Thu", case-sensitive |
|  |  | s-Fri = %x46.72.69 ; "Fri", case-sensitive |
|  |  | s-Sat = %x53.61.74 ; "Sat", case-sensitive |
|  |  | s-Sun = %x53.75.6E ; "Sun", case-sensitive |
|  |  | l-Mon = %x4D.6F.6E.64.61.79 ; "Monday", case-sensitive |
|  |  | l-Tue = %x54.75.65.73.64.61.79 ; "Tuesday", case-sensitive |
|  |  | l-Wed = %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive |
|  |  | l-Thu = %x54.68.75.72.73.64.61.79 ; "Thursday", case-sensitive |
|  |  | l-Fri = %x46.72.69.64.61.79 ; "Friday", case-sensitive |
|  |  | l-Sat = %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive |
|  |  | l-Sun = %x53.75.6E.64.61.79 ; "Sunday", case-sensitive |
|  |  | s-Jan = %x4A.61.6E ; "Jan", case-sensitive |
|  |  | s-Feb = %x46.65.62 ; "Feb", case-sensitive |
|  |  | s-Mar = %x4D.61.72 ; "Mar", case-sensitive |
|  |  | s-Apr = %x41.70.72 ; "Apr", case-sensitive |
|  |  | s-May = %x4D.61.79 ; "May", case-sensitive |
|  |  | s-Jun = %x4A.75.6E ; "Jun", case-sensitive |
|  |  | s-Jul = %x4A.75.6C ; "Jul", case-sensitive |
|  |  | s-Aug = %x41.75.67 ; "Aug", case-sensitive |
|  |  | s-Sep = %x53.65.70 ; "Sep", case-sensitive |
|  |  | s-Oct = %x4F.63.74 ; "Oct", case-sensitive |
|  |  | s-Nov = %x4E.6F.76 ; "Nov", case-sensitive |
|  |  | s-Dec = %x44.65.63 ; "Dec", case-sensitive |
| Note: HTTP requirements for the date/time stamp format apply only to |  | Note: HTTP requirements for the date/time stamp format apply only to |
| their usage within the protocol stream. Clients and servers are not |  | their usage within the protocol stream. Clients and servers are not |
| required to use these formats for user presentation, request logging, |  | required to use these formats for user presentation, request logging, |
| etc. |  | etc. |
| 3.4. Transfer Codings |  | 3.4. Transfer Codings |
| Transfer-coding values are used to indicate an encoding |  | Transfer-coding values are used to indicate an encoding |
| transformation that has been, can be, or may need to be applied to an |  | transformation that has been, can be, or may need to be applied to an |
| skipping to change at page 21, line 4 |  | skipping to change at page 21, line 38 |
| property of the message, not of the original entity. |  | property of the message, not of the original entity. |
| transfer-coding = "chunked" | transfer-extension |  | transfer-coding = "chunked" | transfer-extension |
| transfer-extension = token *( ";" parameter ) |  | transfer-extension = token *( ";" parameter ) |
| Parameters are in the form of attribute/value pairs. |  | Parameters are in the form of attribute/value pairs. |
| parameter = attribute "=" value |  | parameter = attribute "=" value |
| attribute = token |  | attribute = token |
| value = token | quoted-string |  | value = token | quoted-string |
| All transfer-coding values are case-insensitive. HTTP/1.1 uses |  | All transfer-coding values are case-insensitive. HTTP/1.1 uses |
| transfer-coding values in the TE header field (Section 8.5) and in |  | transfer-coding values in the TE header field (Section 8.5) and in |
| the Transfer-Encoding header field (Section 8.7). |  | the Transfer-Encoding header field (Section 8.7). |
| Whenever a transfer-coding is applied to a message-body, the set of |  | Whenever a transfer-coding is applied to a message-body, the set of |
| transfer-codings MUST include "chunked", unless the message is |  | transfer-codings MUST include "chunked", unless the message indicates |
| terminated by closing the connection. When the "chunked" transfer- |  | it is terminated by closing the connection. When the "chunked" |
| coding is used, it MUST be the last transfer-coding applied to the |  | transfer-coding is used, it MUST be the last transfer-coding applied |
| message-body. The "chunked" transfer-coding MUST NOT be applied more |  | to the message-body. The "chunked" transfer-coding MUST NOT be |
| than once to a message-body. These rules allow the recipient to |  | applied more than once to a message-body. These rules allow the |
| determine the transfer-length of the message (Section 4.4). |  | recipient to determine the transfer-length of the message |
|  |  | (Section 4.4). |
| 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 |
| skipping to change at page 22, line 12 |  | skipping to change at page 22, line 42 |
| the information necessary for the recipient to verify that it has |  | the information necessary for the recipient to verify that it has |
| received the full message. |  | received the full message. |
| Chunked-Body = *chunk |  | Chunked-Body = *chunk |
| last-chunk |  | last-chunk |
| trailer-part |  | trailer-part |
| CRLF |  | CRLF |
| chunk = chunk-size [ chunk-extension ] CRLF |  | chunk = chunk-size [ chunk-extension ] CRLF |
| chunk-data CRLF |  | chunk-data CRLF |
| chunk-size = 1*HEX |  | chunk-size = 1*HEXDIG |
| last-chunk = 1*("0") [ chunk-extension ] CRLF |  | last-chunk = 1*("0") [ chunk-extension ] CRLF |
| chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] ) |  | chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] ) |
| chunk-ext-name = token |  | chunk-ext-name = token |
| chunk-ext-val = token | quoted-string |  | chunk-ext-val = token | quoted-string |
| chunk-data = 1*OCTET ; a sequence of chunk-size octets |  | chunk-data = 1*OCTET ; a sequence of chunk-size octets |
| trailer-part = *(entity-header CRLF) |  | trailer-part = *(entity-header CRLF) |
| The chunk-size field is a string of hex digits indicating the size of |  | The chunk-size field is a string of hex digits indicating the size of |
| the chunk-data in octets. The chunked encoding is ended by any chunk |  | the chunk-data in octets. The chunked encoding is ended by any chunk |
| skipping to change at page 25, line 38 |  | skipping to change at page 26, line 21 |
| present in a message if and only if the entire field-value for that |  | present in a message if and only if the entire field-value for that |
| header field is defined as a comma-separated list [i.e., #(values)]. |  | header field is defined as a comma-separated list [i.e., #(values)]. |
| It MUST be possible to combine the multiple header fields into one |  | It MUST be possible to combine the multiple header fields into one |
| "field-name: field-value" pair, without changing the semantics of the |  | "field-name: field-value" pair, without changing the semantics of the |
| message, by appending each subsequent field-value to the first, each |  | message, by appending each subsequent field-value to the first, each |
| separated by a comma. The order in which header fields with the same |  | separated by a comma. The order in which header fields with the same |
| field-name are received is therefore significant to the |  | field-name are received is therefore significant to the |
| interpretation of the combined field value, and thus a proxy MUST NOT |  | interpretation of the combined field value, and thus a proxy MUST NOT |
| change the order of these field values when a message is forwarded. |  | change the order of these field values when a message is forwarded. |
|  |  | Note: the "Set-Cookie" header as implemented in practice (as |
|  |  | opposed to how it is specified in [RFC2109]) can occur multiple |
|  |  | times, but does not use the list syntax, and thus cannot be |
|  |  | combined into a single line. (See Appendix A.2.3 of [Kri2001] for |
|  |  | details.) Also note that the Set-Cookie2 header specified in |
|  |  | [RFC2965] does not share this problem. |
| 4.3. Message Body |  | 4.3. Message Body |
| The message-body (if any) of an HTTP message is used to carry the |  | The message-body (if any) of an HTTP message is used to carry the |
| entity-body associated with the request or response. The message- |  | entity-body associated with the request or response. The message- |
| body differs from the entity-body only when a transfer-coding has |  | body differs from the entity-body only when a transfer-coding has |
| been applied, as indicated by the Transfer-Encoding header field |  | been applied, as indicated by the Transfer-Encoding header field |
| (Section 8.7). |  | (Section 8.7). |
| message-body = entity-body |  | message-body = entity-body |
| | <entity-body encoded as per Transfer-Encoding> |  | | <entity-body encoded as per Transfer-Encoding> |
| skipping to change at page 26, line 46 |  | skipping to change at page 27, line 36 |
| 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, |  | 2. If a Transfer-Encoding header field (Section 8.7) is present and |
| then the transfer-length is defined by use of the "chunked" |  | the "chunked" transfer-coding (Section 3.4) is used, the |
| transfer-coding (Section 3.4), unless the message is terminated |  | transfer-length is defined by the use of this transfer-coding. |
| by closing the connection. |  | If a Transfer-Encoding header field is present and the "chunked" |
|  |  | transfer-coding is not present, the transfer-length is defined by |
|  |  | the sender closing the connection. |
| 3. If a Content-Length header field (Section 8.2) is present, its |  | 3. If a Content-Length header field (Section 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 |
| skipping to change at page 30, line 11 |  | skipping to change at page 31, line 4 |
| 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, path- |  | path of the URI MUST be transmitted (see Section 3.2.1, path- |
| absolute) as the Request-URI, and the network location of the URI |  | absolute) as the Request-URI, and the network location of the URI |
| (authority) MUST be transmitted in a Host header field. For example, |  | (authority) MUST be transmitted in a Host header field. For example, |
| a client wishing to retrieve the resource above directly from the |  | a client wishing to retrieve the resource above directly from the |
| origin server would create a TCP connection to port 80 of the host |  | origin server would create a TCP connection to port 80 of the host |
| "www.example.org" and send the lines: |  | "www.example.org" and send the lines: |
| GET /pub/WWW/TheProject.html HTTP/1.1 |  | GET /pub/WWW/TheProject.html HTTP/1.1 |
| Host: www.example.org |  | Host: www.example.org |
| followed by the remainder of the Request. Note that the absolute |  | followed by the remainder of the Request. Note that the absolute |
| 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 "% HEXDIG |
| encoding [RFC2396], the origin server MUST decode the Request-URI in |  | HEXDIG" encoding ([RFC2396], Section 2.4.1), the origin server MUST |
| order to properly interpret the request. Servers SHOULD respond to |  | decode the Request-URI in order to properly interpret the request. |
| invalid Request-URIs with an appropriate status code. |  | Servers SHOULD respond to invalid Request-URIs with an appropriate |
|  |  | status code. |
| A transparent proxy MUST NOT rewrite the "path-absolute" part of the |  | A transparent proxy MUST NOT rewrite the "path-absolute" part of the |
| received Request-URI when forwarding it to the next inbound server, |  | received Request-URI when forwarding it to the next inbound server, |
| except as noted above to replace a null path-absolute with "/". |  | except as noted above to replace a null path-absolute with "/". |
| Note: The "no rewrite" rule prevents the proxy from changing the |  | Note: The "no rewrite" rule prevents the proxy from changing the |
| meaning of the request when the origin server is improperly using |  | meaning of the request when the origin server is improperly using |
| a non-reserved URI character for a reserved purpose. Implementors |  | a non-reserved URI character for a reserved purpose. Implementors |
| should be aware that some pre-HTTP/1.1 proxies have been known to |  | should be aware that some pre-HTTP/1.1 proxies have been known to |
| rewrite the Request-URI. |  | rewrite the Request-URI. |
| 5.2. The Resource Identified by a Request |  | 5.2. The Resource Identified by a Request |
| The exact resource identified by an Internet request is determined by |  | The exact resource identified by an Internet request is determined by |
| examining both the Request-URI and the Host header field. |  | examining both the Request-URI and the Host header field. |
| An origin server that does not allow resources to differ by the |  | An origin server that does not allow resources to differ by the |
| requested host MAY ignore the Host header field value when |  | requested host MAY ignore the Host header field value when |
| determining the resource identified by an HTTP/1.1 request. (But see |  | determining the resource identified by an HTTP/1.1 request. (But see |
| Appendix D.1.1 for other requirements on Host support in HTTP/1.1.) |  | Appendix C.1.1 for other requirements on Host support in HTTP/1.1.) |
| An origin server that does differentiate resources based on the host |  | An origin server that does differentiate resources based on the host |
| requested (sometimes referred to as virtual hosts or vanity host |  | requested (sometimes referred to as virtual hosts or vanity host |
| names) MUST use the following rules for determining the requested |  | names) MUST use the following rules for determining the requested |
| resource on an HTTP/1.1 request: |  | resource on an HTTP/1.1 request: |
| 1. If Request-URI is an absoluteURI, the host is part of the |  | 1. If Request-URI is an absoluteURI, the host is part of the |
| Request-URI. Any Host header field value in the request MUST be |  | Request-URI. Any Host header field value in the request MUST be |
| ignored. |  | ignored. |
| skipping to change at page 34, line 9 |  | skipping to change at page 34, line 52 |
| case the client does not want to maintain a connection for more than |  | case the client does not want to maintain a connection for more than |
| that request, it SHOULD send a Connection header including the |  | that request, it SHOULD send a Connection header including the |
| connection-token close. |  | connection-token close. |
| If either the client or the server sends the close token in the |  | If either the client or the server sends the close token in the |
| Connection header, that request becomes the last one for the |  | Connection header, that request becomes the last one for the |
| connection. |  | connection. |
| Clients and servers SHOULD NOT assume that a persistent connection is |  | Clients and servers SHOULD NOT assume that a persistent connection is |
| maintained for HTTP versions less than 1.1 unless it is explicitly |  | maintained for HTTP versions less than 1.1 unless it is explicitly |
| signaled. See Appendix D.2 for more information on backward |  | signaled. See Appendix C.2 for more information on backward |
| compatibility with HTTP/1.0 clients. |  | compatibility with HTTP/1.0 clients. |
| In order to remain persistent, all messages on the connection MUST |  | In order to remain persistent, all messages on the connection MUST |
| have a self-defined message length (i.e., one not defined by closure |  | have a self-defined message length (i.e., one not defined by closure |
| of the connection), as described in Section 4.4. |  | of the connection), as described in Section 4.4. |
| 7.1.2.2. Pipelining |  | 7.1.2.2. Pipelining |
| A client that supports persistent connections MAY "pipeline" its |  | A client that supports persistent connections MAY "pipeline" its |
| requests (i.e., send multiple requests without waiting for each |  | requests (i.e., send multiple requests without waiting for each |
| skipping to change at page 40, line 27 |  | skipping to change at page 41, line 20 |
| An HTTP/1.1 server that does not support persistent connections MUST |  | An HTTP/1.1 server that does not support persistent connections MUST |
| include the "close" connection option in every response message that |  | include the "close" connection option in every response message that |
| does not have a 1xx (informational) status code. |  | does not have a 1xx (informational) status code. |
| A system receiving an HTTP/1.0 (or lower-version) message that |  | 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 C.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 43, line 5 |  | skipping to change at page 43, line 50 |
| 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 C.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 48, line 22 |  | skipping to change at page 49, line 22 |
| | TE | http | standard | Section 8.5 | |  | | TE | http | standard | Section 8.5 | |
| | Trailer | http | standard | Section 8.6 | |  | | Trailer | http | standard | Section 8.6 | |
| | Transfer-Encoding | http | standard | Section 8.7 | |  | | Transfer-Encoding | http | standard | Section 8.7 | |
| | Upgrade | http | standard | Section 8.8 | |  | | Upgrade | http | standard | Section 8.8 | |
| | Via | http | standard | Section 8.9 | |  | | Via | http | standard | Section 8.9 | |
| +-------------------+----------+----------+-------------+ |  | +-------------------+----------+----------+-------------+ |
| The change controller is: "IETF (iesg@ietf.org) - Internet |  | The change controller is: "IETF (iesg@ietf.org) - Internet |
| Engineering Task Force". |  | Engineering Task Force". |
|  |  | 9.2. URI Scheme Registration |
|  |  | The entry for the "http" URI Scheme in the registry located at |
|  |  | <http://www.iana.org/assignments/uri-schemes.html> should be updated |
|  |  | to point to Section 3.2.2 of this document (see [RFC4395]). |
|  |  | 9.3. Internet Media Type Registrations |
|  |  | This document serves as the specification for the Internet media |
|  |  | types "message/http" and "application/http". The following is to be |
|  |  | registered with IANA (see [RFC4288]). |
|  |  | 9.3.1. Internet Media Type message/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 |
|  |  | Optional parameters: version, msgtype |
|  |  | version: The HTTP-Version number of the enclosed message (e.g., |
|  |  | "1.1"). If not present, the version can be determined from the |
|  |  | first line of the body. |
|  |  | msgtype: The message type -- "request" or "response". If not |
|  |  | present, the type can be determined from the first line of the |
|  |  | body. |
|  |  | Encoding considerations: only "7bit", "8bit", or "binary" are |
|  |  | permitted |
|  |  | Security considerations: none |
|  |  | Interoperability considerations: none |
|  |  | Published specification: This specification (see Section 9.3.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 |
|  |  | 9.3.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 |
|  |  | Optional parameters: version, msgtype |
|  |  | version: The HTTP-Version number of the enclosed messages (e.g., |
|  |  | "1.1"). If not present, the version can be determined from the |
|  |  | first line of the body. |
|  |  | msgtype: The message type -- "request" or "response". If not |
|  |  | present, the type can be determined from the first line of the |
|  |  | body. |
|  |  | Encoding considerations: HTTP messages enclosed by this type are in |
|  |  | "binary" format; use of an appropriate Content-Transfer-Encoding |
|  |  | is required when transmitted via E-mail. |
|  |  | Security considerations: none |
|  |  | Interoperability considerations: none |
|  |  | Published specification: This specification (see Section 9.3.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 |
| 10. Security Considerations |  | 10. Security Considerations |
| This section is meant to inform application developers, information |  | This section is meant to inform application developers, information |
| providers, and users of the security limitations in HTTP/1.1 as |  | providers, and users of the security limitations in HTTP/1.1 as |
| described by this document. The discussion does not include |  | described by this document. The discussion does not include |
| definitive solutions to the problems revealed, though it does make |  | definitive solutions to the problems revealed, though it does make |
| some suggestions for reducing security risks. |  | some suggestions for reducing security risks. |
| 10.1. Personal Information |  | 10.1. Personal Information |
| skipping to change at page 52, line 16 |  | skipping to change at page 55, line 37 |
| [ISO-8859-1] |  | [ISO-8859-1] |
| International Organization for Standardization, |  | International Organization for Standardization, |
| "Information technology -- 8-bit single-byte coded graphic |  | "Information technology -- 8-bit single-byte coded graphic |
| character sets -- Part 1: Latin alphabet No. 1", ISO/ |  | character sets -- Part 1: Latin alphabet No. 1", ISO/ |
| IEC 8859-1:1998, 1998. |  | IEC 8859-1:1998, 1998. |
| [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| and J. Reschke, Ed., "HTTP/1.1, part 2: Message |  | and J. Reschke, Ed., "HTTP/1.1, part 2: Message |
| Semantics", draft-ietf-httpbis-p2-semantics-03 (work in |  | Semantics", draft-ietf-httpbis-p2-semantics-04 (work in |
| progress), June 2008. |  | progress), August 2008. |
| [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload |  | and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload |
| and Content Negotiation", draft-ietf-httpbis-p3-payload-03 |  | and Content Negotiation", draft-ietf-httpbis-p3-payload-04 |
| (work in progress), June 2008. |  | (work in progress), August 2008. |
| [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and |  | and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and |
| Partial Responses", draft-ietf-httpbis-p5-range-03 (work |  | Partial Responses", draft-ietf-httpbis-p5-range-04 (work |
| in progress), June 2008. |  | in progress), August 2008. |
| [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", |  | and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", |
| draft-ietf-httpbis-p6-cache-03 (work in progress), |  | draft-ietf-httpbis-p6-cache-04 (work in progress), |
| June 2008. |  | August 2008. |
| [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail |  | [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail |
| Extensions (MIME) Part One: Format of Internet Message |  | Extensions (MIME) Part One: Format of Internet Message |
| Bodies", RFC 2045, November 1996. |  | Bodies", RFC 2045, November 1996. |
| [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) |  | [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) |
| Part Three: Message Header Extensions for Non-ASCII Text", |  | Part Three: Message Header Extensions for Non-ASCII Text", |
| RFC 2047, November 1996. |  | RFC 2047, November 1996. |
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |  | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |
| skipping to change at page 53, line 13 |  | skipping to change at page 56, line 36 |
| [RFC822ABNF] |  | [RFC822ABNF] |
| Crocker, D., "Standard for the format of ARPA Internet |  | Crocker, D., "Standard for the format of ARPA Internet |
| text messages", STD 11, RFC 822, August 1982. |  | text messages", STD 11, RFC 822, August 1982. |
| [USASCII] American National Standards Institute, "Coded Character |  | [USASCII] American National Standards Institute, "Coded Character |
| Set -- 7-bit American Standard Code for Information |  | Set -- 7-bit American Standard Code for Information |
| Interchange", ANSI X3.4, 1986. |  | Interchange", ANSI X3.4, 1986. |
| 12.2. Informative References |  | 12.2. Informative References |
|  |  | [Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and |
|  |  | Politics", ACM Transactions on Internet Technology Vol. 1, |
|  |  | #2, November 2001, <http://arxiv.org/abs/cs.SE/0105018>. |
| [Nie1997] Nielsen, H., Gettys, J., Prud'hommeaux, E., Lie, H., and |  | [Nie1997] Nielsen, H., Gettys, J., Prud'hommeaux, E., Lie, H., and |
| C. Lilley, "Network Performance Effects of HTTP/1.1, CSS1, |  | C. Lilley, "Network Performance Effects of HTTP/1.1, CSS1, |
| and PNG", ACM Proceedings of the ACM SIGCOMM '97 |  | and PNG", ACM Proceedings of the ACM SIGCOMM '97 |
| conference on Applications, technologies, architectures, |  | conference on Applications, technologies, architectures, |
| and protocols for computer communication SIGCOMM '97, |  | and protocols for computer communication SIGCOMM '97, |
| September 1997, |  | September 1997, |
| <http://doi.acm.org/10.1145/263105.263157>. |  | <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, |
| December 1995. |  | December 1995, |
|  |  | <http://portal.acm.org/citation.cfm?id=219094>. |
| Slightly revised version of paper in Proc. 2nd |  |  |
| International WWW Conference '94: Mosaic and the Web, Oct. |  |  |
| 1994, which is available at <http://www.ncsa.uiuc.edu/SDG/ |  |  |
| IT94/Proceedings/DDay/mogul/HTTPLatency.html>. |  |  |
| [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)", |
| skipping to change at page 54, line 18 |  | skipping to change at page 57, line 40 |
| [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. |
| [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. |
|  |  | [RFC2109] Kristol, D. and L. Montulli, "HTTP State Management |
|  |  | Mechanism", RFC 2109, February 1997. |
| [RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use |  | [RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use |
| and Interpretation of HTTP Version Numbers", RFC 2145, |  | and Interpretation of HTTP Version Numbers", RFC 2145, |
| May 1997. |  | May 1997. |
| [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. |
| [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. |
|  |  | [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. |
| [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, |  | [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, |
| April 2001. |  | April 2001. |
| [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, |  | [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, |
| April 2001. |  | April 2001. |
|  |  | [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management |
|  |  | Mechanism", RFC 2965, October 2000. |
| [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration |  | [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration |
| Procedures for Message Header Fields", BCP 90, RFC 3864, |  | Procedures for Message Header Fields", BCP 90, RFC 3864, |
| September 2004. |  | September 2004. |
| [RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)", |  | [RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)", |
| RFC 3977, October 2006. |  | RFC 3977, October 2006. |
| [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and |  | [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and |
| Registration Procedures", BCP 13, RFC 4288, December 2005. |  | Registration Procedures", BCP 13, RFC 4288, December 2005. |
|  |  | [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and |
|  |  | Registration Procedures for New URI Schemes", BCP 115, |
|  |  | RFC 4395, February 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. |
| [Spe] Spero, S., "Analysis of HTTP Performance Problems", |  | [Spe] Spero, S., "Analysis of HTTP Performance Problems", |
| <http://sunsite.unc.edu/mdma-release/http-prob.html>. |  | <http://sunsite.unc.edu/mdma-release/http-prob.html>. |
| [Tou1998] Touch, J., Heidemann, J., and K. Obraczka, "Analysis of |  | [Tou1998] Touch, J., Heidemann, J., and K. Obraczka, "Analysis of |
| HTTP Performance", ISI Research Report ISI/RR-98-463, |  | HTTP Performance", ISI Research Report ISI/RR-98-463, |
| Aug 1998, <http://www.isi.edu/touch/pubs/http-perf96/>. |  | Aug 1998, <http://www.isi.edu/touch/pubs/http-perf96/>. |
| (original report dated Aug. 1996) |  | (original report dated Aug. 1996) |
| [WAIS] Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T., |  | [WAIS] Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T., |
| Wang, R., Sui, J., and M. Grinbaum, "WAIS Interface |  | Wang, R., Sui, J., and M. Grinbaum, "WAIS Interface |
| Protocol Prototype Functional Specification (v1.5)", |  | Protocol Prototype Functional Specification (v1.5)", |
| Thinking Machines Corporation , April 1990. |  | Thinking Machines Corporation , April 1990. |
| Appendix A. Internet Media Types |  | Appendix A. Tolerant Applications |
| In addition to defining HTTP/1.1, this document serves as the |  |  |
| specification for the Internet media type "message/http" and |  |  |
| "application/http". The following is to be registered with IANA |  |  |
| [RFC4288]. |  |  |
| A.1. Internet Media Type message/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 |  |  |
| Optional parameters: version, msgtype |  |  |
| version: The HTTP-Version number of the enclosed message (e.g., |  |  |
| "1.1"). If not present, the version can be determined from the |  |  |
| first line of the body. |  |  |
| msgtype: The message type -- "request" or "response". If not |  |  |
| present, the type can be determined from the first line of the |  |  |
| body. |  |  |
| Encoding considerations: only "7bit", "8bit", or "binary" are |  |  |
| permitted |  |  |
| Security considerations: none |  |  |
| Interoperability considerations: none |  |  |
| 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 |  |  |
| Optional parameters: version, msgtype |  |  |
| version: The HTTP-Version number of the enclosed messages (e.g., |  |  |
| "1.1"). If not present, the version can be determined from the |  |  |
| first line of the body. |  |  |
| msgtype: The message type -- "request" or "response". If not |  |  |
| present, the type can be determined from the first line of the |  |  |
| body. |  |  |
| Encoding considerations: HTTP messages enclosed by this type are in |  |  |
| "binary" format; use of an appropriate Content-Transfer-Encoding |  |  |
| is required when transmitted via E-mail. |  |  |
| 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 |  |  |
| 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 HTAB characters between fields, even |  | accept any amount of SP or HTAB characters between fields, even |
| skipping to change at page 58, line 28 |  | skipping to change at page 59, line 47 |
| proper value. |  | proper value. |
| o All expiration-related calculations MUST be done in GMT. The |  | o All expiration-related calculations MUST be done in GMT. The |
| local time zone MUST NOT influence the calculation or comparison |  | local time zone MUST NOT influence the calculation or comparison |
| of an age or expiration time. |  | of an age or expiration time. |
| o If an HTTP header incorrectly carries a date value with a time |  | o If an HTTP header incorrectly carries a date value with a time |
| zone other than GMT, it MUST be converted into GMT using the most |  | zone other than GMT, it MUST be converted into GMT using the most |
| conservative possible conversion. |  | conservative possible conversion. |
| Appendix C. Conversion of Date Formats |  | Appendix B. Conversion of Date Formats |
| HTTP/1.1 uses a restricted set of date formats (Section 3.3.1) to |  | HTTP/1.1 uses a restricted set of date formats (Section 3.3.1) to |
| simplify the process of date comparison. Proxies and gateways from |  | simplify the process of date comparison. Proxies and gateways from |
| other protocols SHOULD ensure that any Date header field present in a |  | other protocols SHOULD ensure that any Date header field present in a |
| message conforms to one of the HTTP/1.1 formats and rewrite the date |  | message conforms to one of the HTTP/1.1 formats and rewrite the date |
| if necessary. |  | if necessary. |
| Appendix D. Compatibility with Previous Versions |  | Appendix C. Compatibility with Previous Versions |
| It is beyond the scope of a protocol specification to mandate |  | It is beyond the scope of a protocol specification to mandate |
| compliance with previous versions. HTTP/1.1 was deliberately |  | compliance with previous versions. HTTP/1.1 was deliberately |
| designed, however, to make supporting previous versions easy. It is |  | designed, however, to make supporting previous versions easy. It is |
| worth noting that, at the time of composing this specification |  | worth noting that, at the time of composing this specification |
| (1996), we would expect commercial HTTP/1.1 servers to: |  | (1996), we would expect commercial HTTP/1.1 servers to: |
| o recognize the format of the Request-Line for HTTP/0.9, 1.0, and |  | o recognize the format of the Request-Line for HTTP/0.9, 1.0, and |
| 1.1 requests; |  | 1.1 requests; |
| skipping to change at page 59, line 21 |  | skipping to change at page 60, line 38 |
| 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 |  | version of persistent connections described in Section 19.7.1 of |
| [RFC2068]. |  | [RFC2068]. |
| D.1. Changes from HTTP/1.0 |  | C.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 |  | C.1.1. Changes to Simplify Multi-homed Web Servers and Conserve IP |
| Addresses |  | Addresses |
| The requirements that clients and servers support the Host request- |  | The requirements that clients and servers support the Host request- |
| header, report an error if the Host request-header (Section 8.4) is |  | header, report an error if the Host request-header (Section 8.4) is |
| missing from an HTTP/1.1 request, and accept absolute URIs |  | missing from an HTTP/1.1 request, and accept absolute URIs |
| (Section 5.1.2) are among the most important changes defined by this |  | (Section 5.1.2) are among the most important changes defined by this |
| specification. |  | specification. |
| Older HTTP/1.0 clients assumed a one-to-one relationship of IP |  | Older HTTP/1.0 clients assumed a one-to-one relationship of IP |
| addresses and servers; there was no other established mechanism for |  | addresses and servers; there was no other established mechanism for |
| skipping to change at page 60, line 14 |  | skipping to change at page 61, line 30 |
| o Both clients and servers MUST support the Host request-header. |  | o Both clients and servers MUST support the Host request-header. |
| o A client that sends an HTTP/1.1 request MUST send a Host header. |  | o A client that sends an HTTP/1.1 request MUST send a Host header. |
| o Servers MUST report a 400 (Bad Request) error if an HTTP/1.1 |  | o Servers MUST report a 400 (Bad Request) error if an HTTP/1.1 |
| request does not include a Host request-header. |  | request does not include a Host request-header. |
| o Servers MUST accept absolute URIs. |  | o Servers MUST accept absolute URIs. |
| D.2. Compatibility with HTTP/1.0 Persistent Connections |  | C.2. Compatibility with HTTP/1.0 Persistent Connections |
| Some clients and servers might wish to be compatible with some |  | Some clients and servers might wish to be compatible with some |
| previous implementations of persistent connections in HTTP/1.0 |  | previous implementations of persistent connections in HTTP/1.0 |
| clients and servers. Persistent connections in HTTP/1.0 are |  | clients and servers. Persistent connections in HTTP/1.0 are |
| explicitly negotiated as they are not the default behavior. HTTP/1.0 |  | explicitly negotiated as they are not the default behavior. HTTP/1.0 |
| experimental implementations of persistent connections are faulty, |  | experimental implementations of persistent connections are faulty, |
| and the new facilities in HTTP/1.1 are designed to rectify these |  | and the new facilities in HTTP/1.1 are designed to rectify these |
| problems. The problem was that some existing 1.0 clients may be |  | problems. The problem was that some existing 1.0 clients may be |
| sending Keep-Alive to a proxy server that doesn't understand |  | sending Keep-Alive to a proxy server that doesn't understand |
| Connection, which would then erroneously forward it to the next |  | Connection, which would then erroneously forward it to the next |
| skipping to change at page 60, line 41 |  | skipping to change at page 62, line 8 |
| 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 [RFC2068]. |  | Keep-Alive and Keep-Alive header) is documented in [RFC2068]. |
| D.3. Changes from RFC 2068 |  | C.3. Changes from RFC 2068 |
| This specification has been carefully audited to correct and |  | This specification has been carefully audited to correct and |
| disambiguate key word usage; RFC 2068 had many problems in respect to |  | disambiguate key word usage; RFC 2068 had many problems in respect to |
| the conventions laid out in [RFC2119]. |  | the conventions laid out in [RFC2119]. |
| Transfer-coding and message lengths all interact in ways that |  | Transfer-coding and message lengths all interact in ways that |
| required fixing exactly when chunked encoding is used (to allow for |  | required fixing exactly when chunked encoding is used (to allow for |
| transfer encoding that may not be self delimiting); it was important |  | transfer encoding that may not be self delimiting); it was important |
| to straighten out exactly how message lengths are computed. |  | to straighten out exactly how message lengths are computed. |
| (Sections 3.4, 4.4, 8.2, see also [Part3], [Part5] and [Part6]) |  | (Sections 3.4, 4.4, 8.2, see also [Part3], [Part5] and [Part6]) |
| skipping to change at page 61, line 20 |  | skipping to change at page 62, line 36 |
| 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 |  | C.4. Changes from RFC 2616 |
| The CHAR rule does not allow the NUL character anymore (this affects |  | The CHAR rule does not allow the NUL character anymore (this affects |
| the comment and quoted-string rules). Furthermore, the quoted-pair |  | the comment and quoted-string rules). Furthermore, the quoted-pair |
| rule does not allow escaping NUL, CR or LF anymore. (Section 2.2) |  | rule does not allow escaping NUL, CR or LF anymore. (Section 2.2) |
| Clarify that HTTP-Version is case sensitive. (Section 3.1) |  | Clarify that HTTP-Version is case sensitive. (Section 3.1) |
| Remove reference to non-existant identity transfer-coding value |  | Remove reference to non-existant identity transfer-coding value |
| tokens. (Sections 3.4 and 4.4) |  | tokens. (Sections 3.4 and 4.4) |
| skipping to change at page 61, line 36 |  | skipping to change at page 63, line 4 |
| Clarify that HTTP-Version is case sensitive. (Section 3.1) |  | Clarify that HTTP-Version is case sensitive. (Section 3.1) |
| Remove reference to non-existant identity transfer-coding value |  | Remove reference to non-existant identity transfer-coding value |
| tokens. (Sections 3.4 and 4.4) |  | tokens. (Sections 3.4 and 4.4) |
| Clarification that the chunk length does not include the count of the |  | Clarification that the chunk length does not include the count of the |
| octets in the chunk header and trailer. (Section 3.4.1) |  | octets in the chunk header and trailer. (Section 3.4.1) |
| Fix BNF to add query, as the abs_path production in Section 3 of |  | Fix BNF to add query, as the abs_path production in Section 3 of |
| [RFC2396] doesn't define it. (Section 5.1.2) |  | [RFC2396] doesn't define it. (Section 5.1.2) |
| Clarify exactly when close connection options must be sent. |  | Clarify exactly when close connection options must be sent. |
| (Section 8.1) |  | (Section 8.1) |
| Appendix E. Change Log (to be removed by RFC Editor before publication) |  | Appendix D. Change Log (to be removed by RFC Editor before publication) |
| E.1. Since RFC2616 |  | D.1. Since RFC2616 |
| Extracted relevant partitions from [RFC2616]. |  | Extracted relevant partitions from [RFC2616]. |
| E.2. Since draft-ietf-httpbis-p1-messaging-00 |  | D.2. Since draft-ietf-httpbis-p1-messaging-00 |
| Closed issues: |  | Closed issues: |
| o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/1>: "HTTP |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/1>: "HTTP |
| Version should be case sensitive" |  | Version should be case sensitive" |
| (<http://purl.org/NET/http-errata#verscase>) |  | (<http://purl.org/NET/http-errata#verscase>) |
| o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/2>: "'unsafe' |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/2>: "'unsafe' |
| characters" (<http://purl.org/NET/http-errata#unsafe-uri>) |  | characters" (<http://purl.org/NET/http-errata#unsafe-uri>) |
| skipping to change at page 63, line 24 |  | skipping to change at page 64, line 36 |
| up-to-date references" |  | up-to-date references" |
| Other changes: |  | Other changes: |
| o Update media type registrations to use RFC4288 template. |  | o Update media type registrations to use RFC4288 template. |
| o Use names of RFC4234 core rules DQUOTE and HTAB, fix broken ABNF |  | o Use names of RFC4234 core rules DQUOTE and HTAB, fix broken ABNF |
| for chunk-data (work in progress on |  | for chunk-data (work in progress on |
| <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36>) |  | <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36>) |
| E.3. Since draft-ietf-httpbis-p1-messaging-01 |  | D.3. Since draft-ietf-httpbis-p1-messaging-01 |
| Closed issues: |  | Closed issues: |
| o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/19>: "Bodies on |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/19>: "Bodies on |
| GET (and other) requests" |  | GET (and other) requests" |
| o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/55>: "Updating |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/55>: "Updating |
| to RFC4288" |  | to RFC4288" |
| o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/57>: "Status |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/57>: "Status |
| skipping to change at page 64, line 22 |  | skipping to change at page 65, line 34 |
| o Move "Product Tokens" section (back) into Part 1, as "token" is |  | o Move "Product Tokens" section (back) into Part 1, as "token" is |
| used in the definition of the Upgrade header. |  | used in the definition of the Upgrade header. |
| o Add explicit references to BNF syntax and rules imported from |  | o Add explicit references to BNF syntax and rules imported from |
| other parts of the specification. |  | other parts of the specification. |
| o Rewrite prose rule "token" in terms of "tchar", rewrite prose rule |  | o Rewrite prose rule "token" in terms of "tchar", rewrite prose rule |
| "TEXT". |  | "TEXT". |
| E.4. Since draft-ietf-httpbis-p1-messaging-02 |  | D.4. Since draft-ietf-httpbis-p1-messaging-02 |
| Closed issues: |  | Closed issues: |
| o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/51>: "HTTP-date |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/51>: "HTTP-date |
| vs. rfc1123-date" |  | vs. rfc1123-date" |
| o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/64>: "WS in |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/64>: "WS in |
| quoted-pair" |  | quoted-pair" |
| Ongoing work on IANA Message Header Registration |  | Ongoing work on IANA Message Header Registration |
| skipping to change at page 64, line 44 |  | skipping to change at page 66, line 8 |
| o Reference RFC 3984, and update header registrations for headers |  | o Reference RFC 3984, and update header registrations for headers |
| defined in this document. |  | defined in this document. |
| Ongoing work on ABNF conversion |  | Ongoing work on ABNF conversion |
| (<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36>): |  | (<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36>): |
| o Replace string literals when the string really is case-sensitive |  | o Replace string literals when the string really is case-sensitive |
| (HTTP-Version). |  | (HTTP-Version). |
|  |  | D.5. Since draft-ietf-httpbis-p1-messaging-03 |
|  |  | Closed issues: |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/28>: |
|  |  | "Connection closing" |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/97>: "Move |
|  |  | registrations and registry information to IANA Considerations" |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/120>: "need new |
|  |  | URL for PAD1995 reference" |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/127>: "IANA |
|  |  | Considerations: update HTTP URI scheme registration" |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/128>: "Cite |
|  |  | HTTPS URI scheme definition" |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/129>: "List- |
|  |  | type headers vs Set-Cookie" |
|  |  | Ongoing work on ABNF conversion |
|  |  | (<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36>): |
|  |  | o Replace string literals when the string really is case-sensitive |
|  |  | (HTTP-Date). |
|  |  | o Replace HEX by HEXDIG for future consistence with RFC 5234's core |
|  |  | rules. |
| Index |  | Index |
| A |  | A |
| application/http Media Type 56 |  | application/http Media Type 50 |
| C |  | C |
| cache 8 |  | cache 8 |
| cacheable 9 |  | cacheable 9 |
| client 7 |  | client 7 |
| connection 6 |  | connection 6 |
| Connection header 39 |  | Connection header 40 |
| content negotiation 7 |  | content negotiation 7 |
| Content-Length header 40 |  | Content-Length header 41 |
| D |  | D |
| Date header 41 |  | Date header 42 |
| downstream 9 |  | downstream 9 |
| E |  | E |
| entity 7 |  | entity 7 |
| G |  | G |
| gateway 8 |  | gateway 8 |
| Grammar |  | Grammar |
| absoluteURI 18 |  | absoluteURI 18 |
| ALPHA 14 |  | ALPHA 14 |
| asctime-date 20 |  | asctime-date 20 |
| attribute 20 |  | attribute 21 |
| authority 18 |  | authority 18 |
| CHAR 14 |  | CHAR 14 |
| chunk 22 |  | chunk 22 |
| chunk-data 22 |  | chunk-data 22 |
| chunk-ext-name 22 |  | chunk-ext-name 22 |
| chunk-ext-val 22 |  | chunk-ext-val 22 |
| chunk-extension 22 |  | chunk-extension 22 |
| chunk-size 22 |  | chunk-size 22 |
| Chunked-Body 22 |  | Chunked-Body 22 |
| comment 15 |  | comment 15 |
| Connection 39 |  | Connection 40 |
| connection-token 39 |  | connection-token 40 |
| Content-Length 40 |  | Content-Length 41 |
| CR 14 |  | CR 14 |
| CRLF 14 |  | CRLF 14 |
| ctext 15 |  | ctext 15 |
| CTL 14 |  | CTL 14 |
| Date 41 |  | Date 42 |
| date1 20 |  | date1 20 |
| date2 20 |  | date2 20 |
| date3 20 |  | date3 20 |
| DIGIT 14 |  | DIGIT 14 |
| DQUOTE 14 |  | DQUOTE 14 |
| extension-code 32 |  | extension-code 33 |
| extension-method 29 |  | extension-method 29 |
| field-content 25 |  | field-content 25 |
| field-name 25 |  | field-name 25 |
| field-value 25 |  | field-value 25 |
| general-header 28 |  | general-header 29 |
| generic-message 24 |  | generic-message 25 |
| HEX 15 |  | HEXDIG 15 |
| Host 42 |  | Host 43 |
| HTAB 14 |  | HTAB 14 |
| HTTP-date 20 |  | HTTP-date 20 |
| HTTP-message 24 |  | HTTP-message 24 |
| HTTP-Prot-Name 16 |  | HTTP-Prot-Name 16 |
| http-URL 18 |  | http-URL 18 |
| HTTP-Version 16 |  | HTTP-Version 16 |
| last-chunk 22 |  | last-chunk 22 |
| LF 14 |  | LF 14 |
| LWS 14 |  | LWS 14 |
| message-body 25 |  | message-body 26 |
| message-header 25 |  | message-header 25 |
| Method 29 |  | Method 29 |
| month 20 |  | month 20 |
| obsolete-date 20 |  | obsolete-date 20 |
| OCTET 14 |  | OCTET 14 |
| parameter 20 |  | parameter 21 |
| path-absolute 18 |  | path-absolute 18 |
| port 18 |  | port 18 |
| product 23 |  | product 24 |
| product-version 23 |  | product-version 24 |
| protocol-name 46 |  | protocol-name 47 |
| protocol-version 46 |  | protocol-version 47 |
| pseudonym 46 |  | pseudonym 47 |
| qdtext 15 |  | qdtext 15 |
| query 18 |  | query 18 |
| quoted-pair 15 |  | quoted-pair 15 |
| quoted-string 15 |  | quoted-string 15 |
| quoted-text 15 |  | quoted-text 15 |
| Reason-Phrase 32 |  | Reason-Phrase 33 |
| received-by 46 |  | received-by 47 |
| received-protocol 46 |  | received-protocol 47 |
| relativeURI 18 |  | relativeURI 18 |
| Request 28 |  | Request 29 |
| Request-Line 28 |  | Request-Line 29 |
| Request-URI 29 |  | Request-URI 30 |
| Response 31 |  | Response 32 |
| rfc850-date 20 |  | rfc850-date 20 |
| rfc1123-date 20 |  | rfc1123-date 20 |
| separators 15 |  | separators 15 |
| SP 14 |  | SP 14 |
| start-line 24 |  | start-line 25 |
| Status-Code 32 |  | Status-Code 33 |
| Status-Line 31 |  | Status-Line 32 |
| t-codings 43 |  | t-codings 44 |
| tchar 15 |  | tchar 15 |
| TE 43 |  | TE 44 |
| TEXT 14 |  | TEXT 14 |
| time 20 |  | time 20 |
| token 15 |  | token 15 |
| Trailer 44 |  | Trailer 45 |
| trailer-part 22 |  | trailer-part 22 |
| transfer-coding 20 |  | transfer-coding 21 |
| Transfer-Encoding 44 |  | Transfer-Encoding 45 |
| transfer-extension 20 |  | transfer-extension 21 |
| Upgrade 45 |  | Upgrade 46 |
| uri-host 18 |  | uri-host 18 |
| value 20 |  | value 21 |
| Via 46 |  | Via 47 |
| weekday 20 |  | weekday 20 |
| wkday 20 |  | wkday 20 |
| H |  | H |
| Headers |  | Headers |
| Connection 39 |  | Connection 40 |
| Content-Length 40 |  | Content-Length 41 |
| Date 41 |  | Date 42 |
| Host 42 |  | Host 43 |
| TE 43 |  | TE 44 |
| Trailer 44 |  | Trailer 45 |
| Transfer-Encoding 44 |  | Transfer-Encoding 45 |
| Upgrade 45 |  | Upgrade 46 |
| Via 46 |  | Via 47 |
| Host header 42 |  | Host header 43 |
|  |  | http URI scheme 18 |
|  |  | https URI scheme 18 |
| I |  | I |
| implied *LWS 13 |  | implied *LWS 13 |
| inbound 9 |  | inbound 9 |
| M |  | M |
| Media Type |  | Media Type |
| application/http 56 |  | application/http 50 |
| message/http 55 |  | message/http 49 |
| message 6 |  | message 6 |
| message/http Media Type 55 |  | message/http Media Type 49 |
| O |  | O |
| origin server 8 |  | origin server 8 |
| outbound 9 |  | outbound 9 |
| P |  | P |
| proxy 8 |  | proxy 8 |
| R |  | R |
| representation 7 |  | representation 7 |
| request 6 |  | request 6 |
| resource 7 |  | resource 7 |
| response 6 |  | response 6 |
| S |  | S |
| server 8 |  | server 8 |
| T |  | T |
| skipping to change at page 68, line 14 |  | skipping to change at page 70, line 10 |
| R |  | R |
| representation 7 |  | representation 7 |
| request 6 |  | request 6 |
| resource 7 |  | resource 7 |
| response 6 |  | response 6 |
| S |  | S |
| server 8 |  | server 8 |
| T |  | T |
| TE header 43 |  | TE header 44 |
| Trailer header 44 |  | Trailer header 45 |
| Transfer-Encoding header 44 |  | Transfer-Encoding header 45 |
| tunnel 8 |  | tunnel 8 |
| U |  | U |
| Upgrade header 45 |  | Upgrade header 46 |
| upstream 9 |  | upstream 9 |
|  |  | URI scheme |
|  |  | http 18 |
|  |  | https 18 |
| user agent 7 |  | user agent 7 |
| V |  | V |
| variant 7 |  | variant 7 |
| Via header 46 |  | Via header 47 |
| Authors' Addresses |  | Authors' Addresses |
| Roy T. Fielding (editor) |  | Roy T. Fielding (editor) |
| Day Software |  | Day Software |
| 23 Corporate Plaza DR, Suite 280 |  | 23 Corporate Plaza DR, Suite 280 |
| Newport Beach, CA 92660 |  | Newport Beach, CA 92660 |
| USA |  | USA |
| Phone: +1-949-706-5300 |  | Phone: +1-949-706-5300 |
End of changes. 83 change blocks.
| 300 lines changed or deleted |  | 397 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/