| draft-ietf-httpbis-p1-messaging-09.txt |  | draft-ietf-httpbis-p1-messaging-10.txt |
--- | --- | --- | --- | ---
| HTTPbis Working Group R. Fielding, Ed. |  | HTTPbis Working Group R. Fielding, Ed. |
| Internet-Draft Day Software |  | Internet-Draft Day Software |
| Obsoletes: 2616 (if approved) J. Gettys |  | Obsoletes: 2616 (if approved) J. Gettys |
| Updates: 2817 (if approved) One Laptop per Child |  | Updates: 2817 (if approved) Alcatel-Lucent |
| Intended status: Standards Track J. Mogul |  | Intended status: Standards Track J. Mogul |
| Expires: September 9, 2010 HP |  | Expires: January 13, 2011 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 |
| March 8, 2010 |  | July 12, 2010 |
| 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-09 |  | draft-ietf-httpbis-p1-messaging-10 |
| Abstract |  | Abstract |
| The Hypertext Transfer Protocol (HTTP) is an application-level |  | The Hypertext Transfer Protocol (HTTP) is an application-level |
| protocol for distributed, collaborative, hypertext information |  | protocol for distributed, collaborative, hypertext information |
| systems. HTTP has been in use by the World Wide Web global |  | systems. HTTP has been in use by the World Wide Web global |
| information initiative since 1990. This document is Part 1 of the |  | information initiative since 1990. This document is Part 1 of the |
| seven-part specification that defines the protocol referred to as |  | seven-part specification that defines the protocol referred to as |
| "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides |  | "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides |
| an overview of HTTP and its associated terminology, defines the |  | an overview of HTTP and its associated terminology, defines the |
| "http" and "https" Uniform Resource Identifier (URI) schemes, defines |  | "http" and "https" Uniform Resource Identifier (URI) schemes, defines |
| the generic message syntax and parsing requirements for HTTP message |  | the generic message syntax and parsing requirements for HTTP message |
| frames, and describes general security concerns for implementations. |  | frames, and describes general security concerns for implementations. |
| Editorial Note (To be removed by RFC Editor) |  | Editorial Note (To be removed by RFC Editor) |
| Discussion of this draft should take place on the HTTPBIS working |  | Discussion of this draft should take place on the HTTPBIS working |
| group mailing list (ietf-http-wg@w3.org). The current issues list is |  | group mailing list (ietf-http-wg@w3.org). The current issues list is |
| at <http://tools.ietf.org/wg/httpbis/trac/report/11> and related |  | at <http://tools.ietf.org/wg/httpbis/trac/report/3> and related |
| documents (including fancy diffs) can be found at |  | documents (including fancy diffs) can be found at |
| <http://tools.ietf.org/wg/httpbis/>. |  | <http://tools.ietf.org/wg/httpbis/>. |
| The changes in this draft are summarized in Appendix D.10. |  | The changes in this draft are summarized in Appendix D.11. |
| Status of this Memo |  | Status of This Memo |
| This Internet-Draft is submitted to IETF in full conformance with the |  | This Internet-Draft is submitted in full conformance with the |
| provisions of BCP 78 and BCP 79. |  | provisions of BCP 78 and BCP 79. |
| Internet-Drafts are working documents of the Internet Engineering |  | Internet-Drafts are working documents of the Internet Engineering |
| Task Force (IETF), its areas, and its working groups. Note that |  | Task Force (IETF). Note that other groups may also distribute |
| other groups may also distribute working documents as Internet- |  | working documents as Internet-Drafts. The list of current Internet- |
| Drafts. |  | Drafts is at http://datatracker.ietf.org/drafts/current/. |
| Internet-Drafts are draft documents valid for a maximum of six months |  | Internet-Drafts are draft documents valid for a maximum of six months |
| and may be updated, replaced, or obsoleted by other documents at any |  | and may be updated, replaced, or obsoleted by other documents at any |
| time. It is inappropriate to use Internet-Drafts as reference |  | time. It is inappropriate to use Internet-Drafts as reference |
| material or to cite them other than as "work in progress." |  | material or to cite them other than as "work in progress." |
| The list of current Internet-Drafts can be accessed at |  | This Internet-Draft will expire on January 13, 2011. |
| http://www.ietf.org/ietf/1id-abstracts.txt. |  |  |
| The list of Internet-Draft Shadow Directories can be accessed at |  |  |
| http://www.ietf.org/shadow.html. |  |  |
| This Internet-Draft will expire on September 9, 2010. |  |  |
| Copyright Notice |  | Copyright Notice |
| Copyright (c) 2010 IETF Trust and the persons identified as the |  | Copyright (c) 2010 IETF Trust and the persons identified as the |
| document authors. All rights reserved. |  | document authors. All rights reserved. |
| This document is subject to BCP 78 and the IETF Trust's Legal |  | This document is subject to BCP 78 and the IETF Trust's Legal |
| Provisions Relating to IETF Documents |  | Provisions Relating to IETF Documents |
| (http://trustee.ietf.org/license-info) in effect on the date of |  | (http://trustee.ietf.org/license-info) in effect on the date of |
| publication of this document. Please review these documents |  | publication of this document. Please review these documents |
| carefully, as they describe your rights and restrictions with respect |  | carefully, as they describe your rights and restrictions with respect |
| to this document. Code Components extracted from this document must |  | to this document. Code Components extracted from this document must |
| include Simplified BSD License text as described in Section 4.e of |  | include Simplified BSD License text as described in Section 4.e of |
| the Trust Legal Provisions and are provided without warranty as |  | the Trust Legal Provisions and are provided without warranty as |
| described in the BSD License. |  | described in the Simplified BSD License. |
| This document may contain material from IETF Documents or IETF |  | This document may contain material from IETF Documents or IETF |
| Contributions published or made publicly available before November |  | Contributions published or made publicly available before November |
| 10, 2008. The person(s) controlling the copyright in some of this |  | 10, 2008. The person(s) controlling the copyright in some of this |
| material may not have granted the IETF Trust the right to allow |  | material may not have granted the IETF Trust the right to allow |
| modifications of such material outside the IETF Standards Process. |  | modifications of such material outside the IETF Standards Process. |
| Without obtaining an adequate license from the person(s) controlling |  | Without obtaining an adequate license from the person(s) controlling |
| the copyright in such materials, this document may not be modified |  | the copyright in such materials, this document may not be modified |
| outside the IETF Standards Process, and derivative works of it may |  | outside the IETF Standards Process, and derivative works of it may |
| not be created outside the IETF Standards Process, except to format |  | not be created outside the IETF Standards Process, except to format |
| skipping to change at page 3, line 14 |  | skipping to change at page 3, line 7 |
| Table of Contents |  | Table of Contents |
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 |  | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 |
| 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7 |  | 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7 |
| 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7 |  | 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7 |
| 1.2.1. ABNF Extension: #rule . . . . . . . . . . . . . . . . 7 |  | 1.2.1. ABNF Extension: #rule . . . . . . . . . . . . . . . . 7 |
| 1.2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . 8 |  | 1.2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . 8 |
| 1.2.3. ABNF Rules defined in other Parts of the |  | 1.2.3. ABNF Rules defined in other Parts of the |
| Specification . . . . . . . . . . . . . . . . . . . . 10 |  | Specification . . . . . . . . . . . . . . . . . . . . 10 |
| 2. HTTP architecture . . . . . . . . . . . . . . . . . . . . . . 10 |  | 2. HTTP architecture . . . . . . . . . . . . . . . . . . . . . . 11 |
| 2.1. Client/Server Operation . . . . . . . . . . . . . . . . . 10 |  | 2.1. Client/Server Operation . . . . . . . . . . . . . . . . . 11 |
| 2.2. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 12 |  | 2.2. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 12 |
| 2.3. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 13 |  | 2.3. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 13 |
| 2.4. Transport Independence . . . . . . . . . . . . . . . . . . 14 |  | 2.4. Transport Independence . . . . . . . . . . . . . . . . . . 14 |
| 2.5. HTTP Version . . . . . . . . . . . . . . . . . . . . . . . 14 |  | 2.5. HTTP Version . . . . . . . . . . . . . . . . . . . . . . . 15 |
| 2.6. Uniform Resource Identifiers . . . . . . . . . . . . . . . 16 |  | 2.6. Uniform Resource Identifiers . . . . . . . . . . . . . . . 16 |
| 2.6.1. http URI scheme . . . . . . . . . . . . . . . . . . . 16 |  | 2.6.1. http URI scheme . . . . . . . . . . . . . . . . . . . 17 |
| 2.6.2. https URI scheme . . . . . . . . . . . . . . . . . . . 17 |  | 2.6.2. https URI scheme . . . . . . . . . . . . . . . . . . . 18 |
| 2.6.3. http and https URI Normalization and Comparison . . . 18 |  | 2.6.3. http and https URI Normalization and Comparison . . . 18 |
| 3. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . . 19 |  | 3. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . . 19 |
| 3.1. Message Parsing Robustness . . . . . . . . . . . . . . . . 19 |  | 3.1. Message Parsing Robustness . . . . . . . . . . . . . . . . 20 |
| 3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 20 |  | 3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 20 |
| 3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 22 |  | 3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 22 |
| 3.4. Message Length . . . . . . . . . . . . . . . . . . . . . . 23 |  | 3.4. Message Length . . . . . . . . . . . . . . . . . . . . . . 23 |
| 3.5. General Header Fields . . . . . . . . . . . . . . . . . . 24 |  | 3.5. General Header Fields . . . . . . . . . . . . . . . . . . 24 |
| 4. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 |  | 4. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 |
| 4.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 25 |  | 4.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 25 |
| 4.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 25 |  | 4.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 25 |
| 4.1.2. request-target . . . . . . . . . . . . . . . . . . . . 25 |  | 4.1.2. request-target . . . . . . . . . . . . . . . . . . . . 26 |
| 4.2. The Resource Identified by a Request . . . . . . . . . . . 27 |  | 4.2. The Resource Identified by a Request . . . . . . . . . . . 28 |
| 5. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 |  | 4.3. Effective Request URI . . . . . . . . . . . . . . . . . . 28 |
| 5.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 28 |  | 5. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 |
| 5.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 28 |  | 5.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 30 |
| 6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 29 |  | 5.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 30 |
| 6.1. Date/Time Formats: Full Date . . . . . . . . . . . . . . . 29 |  | 6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 31 |
| 6.2. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 31 |  | 6.1. Date/Time Formats: Full Date . . . . . . . . . . . . . . . 31 |
| 6.2.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 32 |  | 6.2. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 33 |
| 6.2.2. Compression Codings . . . . . . . . . . . . . . . . . 34 |  | 6.2.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 34 |
| 6.2.3. Transfer Coding Registry . . . . . . . . . . . . . . . 35 |  | 6.2.2. Compression Codings . . . . . . . . . . . . . . . . . 36 |
| 6.3. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 35 |  | 6.2.3. Transfer Coding Registry . . . . . . . . . . . . . . . 37 |
| 6.4. Quality Values . . . . . . . . . . . . . . . . . . . . . . 36 |  | 6.3. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 37 |
| 7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 36 |  | 6.4. Quality Values . . . . . . . . . . . . . . . . . . . . . . 38 |
| 7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 36 |  | 7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 38 |
| 7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 36 |  | 7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 38 |
| 7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 37 |  | 7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 38 |
| 7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 38 |  | 7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 39 |
| 7.1.4. Practical Considerations . . . . . . . . . . . . . . . 41 |  | 7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 41 |
| 7.2. Message Transmission Requirements . . . . . . . . . . . . 42 |  | 7.1.4. Practical Considerations . . . . . . . . . . . . . . . 43 |
| 7.2.1. Persistent Connections and Flow Control . . . . . . . 42 |  | 7.2. Message Transmission Requirements . . . . . . . . . . . . 44 |
| 7.2.2. Monitoring Connections for Error Status Messages . . . 42 |  | 7.2.1. Persistent Connections and Flow Control . . . . . . . 44 |
| 7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 42 |  | 7.2.2. Monitoring Connections for Error Status Messages . . . 44 |
|  |  | 7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 45 |
| 7.2.4. Client Behavior if Server Prematurely Closes |  | 7.2.4. Client Behavior if Server Prematurely Closes |
| Connection . . . . . . . . . . . . . . . . . . . . . . 44 |  | Connection . . . . . . . . . . . . . . . . . . . . . . 47 |
| 8. Miscellaneous notes that may disappear . . . . . . . . . . . . 45 |  |  |
| 8.1. Scheme aliases considered harmful . . . . . . . . . . . . 45 |  | 8. Miscellaneous notes that may disappear . . . . . . . . . . . . 47 |
| 8.2. Use of HTTP for proxy communication . . . . . . . . . . . 45 |  | 8.1. Scheme aliases considered harmful . . . . . . . . . . . . 47 |
| 8.3. Interception of HTTP for access control . . . . . . . . . 46 |  | 8.2. Use of HTTP for proxy communication . . . . . . . . . . . 48 |
| 8.4. Use of HTTP by other protocols . . . . . . . . . . . . . . 46 |  | 8.3. Interception of HTTP for access control . . . . . . . . . 48 |
| 8.5. Use of HTTP by media type specification . . . . . . . . . 46 |  | 8.4. Use of HTTP by other protocols . . . . . . . . . . . . . . 48 |
| 9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 46 |  | 8.5. Use of HTTP by media type specification . . . . . . . . . 48 |
| 9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 46 |  | 9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 48 |
| 9.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 47 |  | 9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 48 |
| 9.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 |  | 9.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 49 |
| 9.3.1. Clockless Origin Server Operation . . . . . . . . . . 49 |  | 9.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 |
| 9.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 |  | 9.3.1. Clockless Origin Server Operation . . . . . . . . . . 51 |
| 9.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 |  | 9.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 |
| 9.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 51 |  | 9.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 |
| 9.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 52 |  | 9.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 53 |
| 9.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 52 |  | 9.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 54 |
| 9.8.1. Upgrade Token Registry . . . . . . . . . . . . . . . . 53 |  | 9.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 54 |
| 9.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 |  | 9.8.1. Upgrade Token Registry . . . . . . . . . . . . . . . . 55 |
| 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56 |  | 9.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 |
| 10.1. Message Header Registration . . . . . . . . . . . . . . . 56 |  | 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58 |
| 10.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 56 |  | 10.1. Message Header Registration . . . . . . . . . . . . . . . 58 |
| 10.3. Internet Media Type Registrations . . . . . . . . . . . . 56 |  | 10.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 58 |
| 10.3.1. Internet Media Type message/http . . . . . . . . . . . 56 |  | 10.3. Internet Media Type Registrations . . . . . . . . . . . . 58 |
| 10.3.2. Internet Media Type application/http . . . . . . . . . 58 |  | 10.3.1. Internet Media Type message/http . . . . . . . . . . . 58 |
| 10.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 59 |  | 10.3.2. Internet Media Type application/http . . . . . . . . . 60 |
| 10.5. Upgrade Token Registration . . . . . . . . . . . . . . . . 59 |  | 10.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 61 |
| 11. Security Considerations . . . . . . . . . . . . . . . . . . . 59 |  | 10.5. Upgrade Token Registration . . . . . . . . . . . . . . . . 61 |
| 11.1. Personal Information . . . . . . . . . . . . . . . . . . . 60 |  | 11. Security Considerations . . . . . . . . . . . . . . . . . . . 61 |
| 11.2. Abuse of Server Log Information . . . . . . . . . . . . . 60 |  | 11.1. Personal Information . . . . . . . . . . . . . . . . . . . 62 |
| 11.3. Attacks Based On File and Path Names . . . . . . . . . . . 60 |  | 11.2. Abuse of Server Log Information . . . . . . . . . . . . . 62 |
| 11.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 60 |  | 11.3. Attacks Based On File and Path Names . . . . . . . . . . . 62 |
| 11.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 61 |  | 11.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 62 |
| 11.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 62 |  | 11.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 63 |
| 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 62 |  | 11.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 64 |
| 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 63 |  | 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 64 |
| 13.1. Normative References . . . . . . . . . . . . . . . . . . . 63 |  | 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 65 |
| 13.2. Informative References . . . . . . . . . . . . . . . . . . 65 |  | 13.1. Normative References . . . . . . . . . . . . . . . . . . . 65 |
| Appendix A. Tolerant Applications . . . . . . . . . . . . . . . . 67 |  | 13.2. Informative References . . . . . . . . . . . . . . . . . . 67 |
| Appendix B. Compatibility with Previous Versions . . . . . . . . 67 |  | Appendix A. Tolerant Applications . . . . . . . . . . . . . . . . 69 |
| B.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 68 |  | Appendix B. Compatibility with Previous Versions . . . . . . . . 70 |
|  |  | B.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 71 |
| B.1.1. Changes to Simplify Multi-homed Web Servers and |  | B.1.1. Changes to Simplify Multi-homed Web Servers and |
| Conserve IP Addresses . . . . . . . . . . . . . . . . 68 |  | Conserve IP Addresses . . . . . . . . . . . . . . . . 71 |
| B.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 69 |  | B.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 71 |
| B.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 70 |  | B.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 72 |
| B.4. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 70 |  | B.4. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 73 |
| Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 71 |  | Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 73 |
| Appendix D. Change Log (to be removed by RFC Editor before |  | Appendix D. Change Log (to be removed by RFC Editor before |
| publication) . . . . . . . . . . . . . . . . . . . . 76 |  | publication) . . . . . . . . . . . . . . . . . . . . 78 |
| D.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 76 |  |  |
| D.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 76 |  | D.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 78 |
| D.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 77 |  | D.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 78 |
| D.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 78 |  | D.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 80 |
| D.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 79 |  | D.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 81 |
| D.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 79 |  | D.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 81 |
| D.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 80 |  | D.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 82 |
| D.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 81 |  | D.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 82 |
| D.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 81 |  | D.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 83 |
| D.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 82 |  | D.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 84 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 |  | D.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 84 |
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 86 |  | D.11. Since draft-ietf-httpbis-p1-messaging-09 . . . . . . . . . 85 |
|  |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 |
| 1. Introduction |  | 1. Introduction |
| The Hypertext Transfer Protocol (HTTP) is an application-level |  | The Hypertext Transfer Protocol (HTTP) is an application-level |
| request/response protocol that uses extensible semantics and MIME- |  | request/response protocol that uses extensible semantics and MIME- |
| like message payloads for flexible interaction with network-based |  | like message payloads for flexible interaction with network-based |
| hypertext information systems. HTTP relies upon the Uniform Resource |  | hypertext information systems. HTTP relies upon the Uniform Resource |
| Identifier (URI) standard [RFC3986] to indicate request targets and |  | Identifier (URI) standard [RFC3986] to indicate request targets and |
| relationships between resources. Messages are passed in a format |  | relationships between resources. Messages are passed in a format |
| similar to that used by Internet mail [RFC5322] and the Multipurpose |  | similar to that used by Internet mail [RFC5322] and the Multipurpose |
| skipping to change at page 7, line 13 |  | skipping to change at page 7, line 13 |
| the complete set of requirements for message parsers and message- |  | the complete set of requirements for message parsers and message- |
| forwarding intermediaries. |  | forwarding intermediaries. |
| 1.1. Requirements |  | 1.1. Requirements |
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |  | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |  | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |
| document are to be interpreted as described in [RFC2119]. |  | document are to be interpreted as described in [RFC2119]. |
| An implementation is not compliant if it fails to satisfy one or more |  | An implementation is not compliant if it fails to satisfy one or more |
| of the MUST or REQUIRED level requirements for the protocols it |  | of the "MUST" or "REQUIRED" level requirements for the protocols it |
| implements. An implementation that satisfies all the MUST or |  | implements. An implementation that satisfies all the "MUST" or |
| REQUIRED level and all the SHOULD level requirements for its |  | "REQUIRED" level and all the "SHOULD" level requirements for its |
| protocols is said to be "unconditionally compliant"; one that |  | protocols is said to be "unconditionally compliant"; one that |
| satisfies all the MUST level requirements but not all the SHOULD |  | satisfies all the "MUST" level requirements but not all the "SHOULD" |
| level requirements for its protocols is said to be "conditionally |  | level requirements for its protocols is said to be "conditionally |
| compliant." |  | compliant". |
| 1.2. Syntax Notation |  | 1.2. Syntax Notation |
| This specification uses the Augmented Backus-Naur Form (ABNF) |  | This specification uses the Augmented Backus-Naur Form (ABNF) |
| notation of [RFC5234]. |  | notation of [RFC5234]. |
| The following core rules are included by reference, as defined in |  | The following core rules are included by reference, as defined in |
| [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF |  | [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF |
| (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), |  | (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), |
| HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit |  | HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit |
| skipping to change at page 9, line 43 |  | skipping to change at page 10, line 5 |
| BWS = OWS |  | BWS = OWS |
| ; "bad" whitespace |  | ; "bad" whitespace |
| obs-fold = CRLF |  | obs-fold = CRLF |
| ; see Section 3.2 |  | ; see Section 3.2 |
| Many HTTP/1.1 header field values consist of words (token or quoted- |  | Many HTTP/1.1 header field values consist of words (token or quoted- |
| string) separated by whitespace or special characters. These special |  | string) separated by whitespace or special characters. These special |
| characters MUST be in a quoted string to be used within a parameter |  | characters MUST be in a quoted string to be used within a parameter |
| value (as defined in Section 6.2). |  | value (as defined in Section 6.2). |
|  |  | word = token / quoted-string |
| token = 1*tchar |  | token = 1*tchar |
| tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" |  | tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" |
| / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" |  | / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" |
| / DIGIT / ALPHA |  | / DIGIT / ALPHA |
| ; any VCHAR, except special |  | ; any VCHAR, except special |
| special = "(" / ")" / "<" / ">" / "@" / "," |  | special = "(" / ")" / "<" / ">" / "@" / "," |
| / ";" / ":" / "\" / DQUOTE / "/" / "[" |  | / ";" / ":" / "\" / DQUOTE / "/" / "[" |
| / "]" / "?" / "=" / "{" / "}" |  | / "]" / "?" / "=" / "{" / "}" |
| skipping to change at page 16, line 21 |  | skipping to change at page 16, line 30 |
| interface that can be used to interact with a resource via HTTP. |  | interface that can be used to interact with a resource via HTTP. |
| More information on the scope of URIs and resources can be found in |  | More information on the scope of URIs and resources can be found in |
| [RFC3986]. |  | [RFC3986]. |
| This specification adopts the definitions of "URI-reference", |  | This specification adopts the definitions of "URI-reference", |
| "absolute-URI", "relative-part", "port", "host", "path-abempty", |  | "absolute-URI", "relative-part", "port", "host", "path-abempty", |
| "path-absolute", "query", and "authority" from [RFC3986]. In |  | "path-absolute", "query", and "authority" from [RFC3986]. In |
| addition, we define a partial-URI rule for protocol elements that |  | addition, we define a partial-URI rule for protocol elements that |
| allow a relative URI without a fragment. |  | allow a relative URI without a fragment. |
| URI = <URI, defined in [RFC3986], Section 3> |  |  |
| URI-reference = <URI-reference, defined in [RFC3986], Section 4.1> |  | URI-reference = <URI-reference, defined in [RFC3986], Section 4.1> |
| absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3> |  | absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3> |
| relative-part = <relative-part, defined in [RFC3986], Section 4.2> |  | relative-part = <relative-part, defined in [RFC3986], Section 4.2> |
| authority = <authority, defined in [RFC3986], Section 3.2> |  | authority = <authority, defined in [RFC3986], Section 3.2> |
| path-abempty = <path-abempty, defined in [RFC3986], Section 3.3> |  | path-abempty = <path-abempty, defined in [RFC3986], Section 3.3> |
| path-absolute = <path-absolute, defined in [RFC3986], Section 3.3> |  | path-absolute = <path-absolute, defined in [RFC3986], Section 3.3> |
| port = <port, defined in [RFC3986], Section 3.2.3> |  | port = <port, defined in [RFC3986], Section 3.2.3> |
| query = <query, defined in [RFC3986], Section 3.4> |  | query = <query, defined in [RFC3986], Section 3.4> |
| uri-host = <host, defined in [RFC3986], Section 3.2.2> |  | uri-host = <host, defined in [RFC3986], Section 3.2.2> |
| skipping to change at page 25, line 45 |  | skipping to change at page 26, line 16 |
| The request-target identifies the resource upon which to apply the |  | The request-target identifies the resource upon which to apply the |
| request. |  | request. |
| request-target = "*" |  | request-target = "*" |
| / absolute-URI |  | / absolute-URI |
| / ( path-absolute [ "?" query ] ) |  | / ( path-absolute [ "?" query ] ) |
| / authority |  | / authority |
| The four options for request-target are dependent on the nature of |  | The four options for request-target are dependent on the nature of |
| the request. The asterisk "*" means that the request does not apply |  | the request. |
| to a particular resource, but to the server itself, and is only |  |  |
| allowed when the method used does not necessarily apply to a |  | The asterisk "*" means that the request does not apply to a |
| resource. One example would be |  | particular resource, but to the server itself, and is only allowed |
|  |  | when the method used does not necessarily apply to a resource. One |
|  |  | example would be |
| OPTIONS * HTTP/1.1 |  | OPTIONS * HTTP/1.1 |
| The absolute-URI form is REQUIRED when the request is being made to a |  | The absolute-URI form is REQUIRED when the request is being made to a |
| proxy. The proxy is requested to forward the request or service it |  | proxy. The proxy is requested to forward the request or service it |
| from a valid cache, and return the response. Note that the proxy MAY |  | from a valid cache, and return the response. Note that the proxy MAY |
| forward the request on to another proxy or directly to the server |  | forward the request on to another proxy or directly to the server |
| specified by the absolute-URI. In order to avoid request loops, a |  | specified by the absolute-URI. In order to avoid request loops, a |
| proxy MUST be able to recognize all of its server names, including |  | proxy MUST be able to recognize all of its server names, including |
| any aliases, local variations, and the numeric IP address. An |  | any aliases, local variations, and the numeric IP address. An |
| skipping to change at page 27, line 21 |  | skipping to change at page 27, line 37 |
| The request-target is transmitted in the format specified in |  | The request-target is transmitted in the format specified in |
| Section 2.6.1. If the request-target is percent-encoded ([RFC3986], |  | Section 2.6.1. If the request-target is percent-encoded ([RFC3986], |
| Section 2.1), the origin server MUST decode the request-target in |  | Section 2.1), the origin server MUST decode the request-target in |
| order to properly interpret the request. Servers SHOULD respond to |  | order to properly interpret the request. Servers SHOULD respond to |
| invalid request-targets with an appropriate status code. |  | invalid request-targets with an appropriate status code. |
| A transparent proxy MUST NOT rewrite the "path-absolute" part of the |  | A transparent proxy MUST NOT rewrite the "path-absolute" part of the |
| received request-target when forwarding it to the next inbound |  | received request-target when forwarding it to the next inbound |
| server, except as noted above to replace a null path-absolute with |  | server, except as noted above to replace a null path-absolute with |
| "/". |  | "/" or "*". |
| Note: The "no rewrite" rule prevents the proxy from changing the |  | Note: The "no rewrite" rule prevents the proxy from changing the |
| meaning of the request when the origin server is improperly using |  | meaning of the request when the origin server is improperly using |
| a non-reserved URI character for a reserved purpose. Implementors |  | a non-reserved URI character for a reserved purpose. Implementors |
| 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-target. |  | rewrite the request-target. |
| HTTP does not place a pre-defined limit on the length of a request- |  | HTTP does not place a pre-defined limit on the length of a request- |
| target. A server MUST be prepared to receive URIs of unbounded |  | target. A server MUST be prepared to receive URIs of unbounded |
| length and respond with the 414 (URI Too Long) status if the received |  | length and respond with the 414 (URI Too Long) status if the received |
| request-target would be longer than the server wishes to handle (see |  | request-target would be longer than the server wishes to handle (see |
| Section 8.4.15 of [Part2]). |  | Section 8.4.15 of [Part2]). |
| Various ad-hoc limitations on request-target length are found in |  | Various ad-hoc limitations on request-target length are found in |
| practice. It is RECOMMENDED that all HTTP senders and recipients |  | practice. It is RECOMMENDED that all HTTP senders and recipients |
| support request-target lengths of 8000 or more OCTETs. |  | support request-target lengths of 8000 or more OCTETs. |
|  |  | Note: Fragments ([RFC3986], Section 3.5) are not part of the |
|  |  | request-target and thus will not be transmitted in an HTTP |
|  |  | request. |
| 4.2. The Resource Identified by a Request |  | 4.2. The Resource Identified by a Request |
| The exact resource identified by an Internet request is determined by |  | The exact resource identified by an Internet request is determined by |
| examining both the request-target and the Host header field. |  | examining both the request-target and the Host header field. |
| An origin server that does not allow resources to differ by the |  | An origin server that does not allow resources to differ by the |
| requested host MAY ignore the Host header field value when |  | requested host MAY ignore the Host header field value when |
| determining the resource identified by an HTTP/1.1 request. (But see |  | determining the resource identified by an HTTP/1.1 request. (But see |
| Appendix B.1.1 for other requirements on Host support in HTTP/1.1.) |  | Appendix B.1.1 for other requirements on Host support in HTTP/1.1.) |
| skipping to change at page 28, line 22 |  | skipping to change at page 28, line 42 |
| 3. If the host as determined by rule 1 or 2 is not a valid host on |  | 3. If the host as determined by rule 1 or 2 is not a valid host on |
| the server, the response MUST be a 400 (Bad Request) error |  | the server, the response MUST be a 400 (Bad Request) error |
| message. |  | message. |
| Recipients of an HTTP/1.0 request that lacks a Host header field MAY |  | Recipients of an HTTP/1.0 request that lacks a Host header field MAY |
| attempt to use heuristics (e.g., examination of the URI path for |  | attempt to use heuristics (e.g., examination of the URI path for |
| something unique to a particular host) in order to determine what |  | something unique to a particular host) in order to determine what |
| exact resource is being requested. |  | exact resource is being requested. |
|  |  | 4.3. Effective Request URI |
|  |  | HTTP requests often do not carry the absolute URI ([RFC3986], Section |
|  |  | 4.3) for the resource they are intended for; instead, the value needs |
|  |  | to be inferred from the request-target, Host header and other |
|  |  | context. The result of this process is the "Effective Request URI". |
|  |  | If the request-target is an absolute-URI, then the Effective Request |
|  |  | URI is the request-target. |
|  |  | If the request-target uses the path-absolute (plus optional query) |
|  |  | syntax or if it is just the asterisk "*", then the Effective Request |
|  |  | URI is constructed by concatenating |
|  |  | o the scheme name: "http" if the request was received over an |
|  |  | insecure TCP connection, or "https" when received over SSL/ |
|  |  | TLS-secured TCP connection, |
|  |  | o the character sequence "://", |
|  |  | o the authority component, as specified in the Host header |
|  |  | (Section 9.4) and determined by the rules in Section 4.2, |
|  |  | [[effrequri-nohost: Do we need to include the handling of missing |
|  |  | hosts in HTTP/1.0 messages, as described in Section 4.2? --jre]] |
|  |  | and |
|  |  | o the request-target obtained from the Request-Line, unless the |
|  |  | request-target is just the asterisk "*". |
|  |  | Otherwise, when request-target uses the authority form, the Effective |
|  |  | Request URI is undefined. |
|  |  | Example 1: the Effective Request URI for the message |
|  |  | GET /pub/WWW/TheProject.html HTTP/1.1 |
|  |  | Host: www.example.org:8080 |
|  |  | (received over an insecure TCP connection) is "http", plus "://", |
|  |  | plus the authority component "www.example.org:8080", plus the |
|  |  | request-target "/pub/WWW/TheProject.html", thus |
|  |  | "http://www.example.org:8080/pub/WWW/TheProject.html". |
|  |  | Example 2: the Effective Request URI for the message |
|  |  | GET * HTTP/1.1 |
|  |  | Host: www.example.org |
|  |  | (received over an SSL/TLS secured TCP connection) is "https", plus |
|  |  | "://", plus the authority component "www.example.org", thus |
|  |  | "https://www.example.org". |
|  |  | Effective Request URIs are compared using the rules described in |
|  |  | Section 2.6.3, except that empty path components MUST NOT be treated |
|  |  | as equivalent to an absolute path of "/". |
| 5. Response |  | 5. Response |
| After receiving and interpreting a request message, a server responds |  | After receiving and interpreting a request message, a server responds |
| with an HTTP response message. |  | with an HTTP response message. |
| Response = Status-Line ; Section 5.1 |  | Response = Status-Line ; Section 5.1 |
| *(( general-header ; Section 3.5 |  | *(( general-header ; Section 3.5 |
| / response-header ; [Part2], Section 5 |  | / response-header ; [Part2], Section 5 |
| / entity-header ) CRLF ) ; [Part3], Section 3.1 |  | / entity-header ) CRLF ) ; [Part3], Section 3.1 |
| CRLF |  | CRLF |
| skipping to change at page 29, line 32 |  | skipping to change at page 31, line 16 |
| valid request |  | valid request |
| Status-Code = 3DIGIT |  | Status-Code = 3DIGIT |
| Reason-Phrase = *( WSP / VCHAR / obs-text ) |  | Reason-Phrase = *( WSP / VCHAR / obs-text ) |
| 6. Protocol Parameters |  | 6. Protocol Parameters |
| 6.1. Date/Time Formats: Full Date |  | 6.1. Date/Time Formats: Full Date |
| HTTP applications have historically allowed three different formats |  | HTTP applications have historically allowed three different formats |
| for the representation of date/time stamps: |  | for the representation of date/time stamps. |
|  |  | The first format is preferred as an Internet standard and represents |
|  |  | a fixed-length subset of that defined by [RFC1123]: |
| Sun, 06 Nov 1994 08:49:37 GMT ; RFC 1123 |  | Sun, 06 Nov 1994 08:49:37 GMT ; RFC 1123 |
|  |  | The other formats are described here only for compatibility with |
|  |  | obsolete implementations. |
| 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 |  | HTTP/1.1 clients and servers that parse the date value MUST accept |
| a fixed-length subset of that defined by [RFC1123]. The other |  | all three formats (for compatibility with HTTP/1.0), though they MUST |
| formats are described here only for compatibility with obsolete |  | only generate the RFC 1123 format for representing HTTP-date values |
| implementations. HTTP/1.1 clients and servers that parse the date |  | in header fields. See Appendix A for further information. |
| value MUST accept all three formats (for compatibility with |  |  |
| HTTP/1.0), though they MUST only generate the RFC 1123 format for |  |  |
| representing HTTP-date values in header fields. See Appendix A for |  |  |
| further information. |  |  |
| All HTTP date/time stamps MUST be represented in Greenwich Mean Time |  | 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 whitespace beyond that specifically included as SP in the |  | additional whitespace beyond that specifically included as SP in the |
| grammar. |  | grammar. |
| skipping to change at page 32, line 4 |  | skipping to change at page 33, line 43 |
| 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 |
| entity-body in order to ensure "safe transport" through the network. |  | entity-body in order to ensure "safe transport" through the network. |
| This differs from a content coding in that the transfer-coding is a |  | This differs from a content coding in that the transfer-coding is a |
| property of the message, not of the original entity. |  | property of the message, not of the original entity. |
| transfer-coding = "chunked" ; Section 6.2.1 |  | transfer-coding = "chunked" ; Section 6.2.1 |
| / "compress" ; Section 6.2.2.1 |  | / "compress" ; Section 6.2.2.1 |
| / "deflate" ; Section 6.2.2.2 |  | / "deflate" ; Section 6.2.2.2 |
| / "gzip" ; Section 6.2.2.3 |  | / "gzip" ; Section 6.2.2.3 |
| / transfer-extension |  | / transfer-extension |
| transfer-extension = token *( OWS ";" OWS transfer-parameter ) |  | transfer-extension = token *( OWS ";" OWS transfer-parameter ) |
| Parameters are in the form of attribute/value pairs. |  | Parameters are in the form of attribute/value pairs. |
| transfer-parameter = attribute BWS "=" BWS value |  | transfer-parameter = attribute BWS "=" BWS value |
| attribute = token |  | attribute = token |
| value = token / quoted-string |  | value = word |
| 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 9.5) and in |  | transfer-coding values in the TE header field (Section 9.5) and in |
| the Transfer-Encoding header field (Section 9.7). |  | the Transfer-Encoding header field (Section 9.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 indicates |  | transfer-codings MUST include "chunked", unless the message indicates |
| it is terminated by closing the connection. When the "chunked" |  | it is terminated by closing the connection. When the "chunked" |
| transfer-coding is used, it MUST be the last transfer-coding applied |  | transfer-coding is used, it MUST be the last transfer-coding applied |
| to the message-body. The "chunked" transfer-coding MUST NOT be |  | to the message-body. The "chunked" transfer-coding MUST NOT be |
| skipping to change at page 35, line 7 |  | skipping to change at page 37, line 7 |
| equivalent to "gzip" and "compress" respectively. |  | equivalent to "gzip" and "compress" respectively. |
| 6.2.2.1. Compress Coding |  | 6.2.2.1. Compress Coding |
| The "compress" format is produced by the common UNIX file compression |  | The "compress" format is produced by the common UNIX file compression |
| program "compress". This format is an adaptive Lempel-Ziv-Welch |  | program "compress". This format is an adaptive Lempel-Ziv-Welch |
| coding (LZW). |  | coding (LZW). |
| 6.2.2.2. Deflate Coding |  | 6.2.2.2. Deflate Coding |
| The "zlib" format is defined in [RFC1950] in combination with the |  | The "deflate" format is defined as the "deflate" compression |
| "deflate" compression mechanism described in [RFC1951]. |  | mechanism (described in [RFC1951]) used inside the "zlib" data format |
|  |  | ([RFC1950]). |
|  |  | Note: Some incorrect implementations send the "deflate" compressed |
|  |  | data without the zlib wrapper. |
| 6.2.2.3. Gzip Coding |  | 6.2.2.3. Gzip Coding |
| The "gzip" format is produced by the file compression program "gzip" |  | The "gzip" format is produced by the file compression program "gzip" |
| (GNU zip), as described in [RFC1952]. This format is a Lempel-Ziv |  | (GNU zip), as described in [RFC1952]. This format is a Lempel-Ziv |
| coding (LZ77) with a 32 bit CRC. |  | coding (LZ77) with a 32 bit CRC. |
| 6.2.3. Transfer Coding Registry |  | 6.2.3. Transfer Coding Registry |
| The HTTP Transfer Coding Registry defines the name space for the |  | The HTTP Transfer Coding Registry defines the name space for the |
| transfer coding names. |  | transfer coding names. |
| Registrations MUST include the following fields: |  | Registrations MUST include the following fields: |
| o Name |  | o Name |
| o Description |  | o Description |
| o Pointer to specification text |  | o Pointer to specification text |
|  |  | Names of transfer codings MUST NOT overlap with names of content |
|  |  | codings (Section 2.2 of [Part3]), unless the encoding transformation |
|  |  | is identical (as it is the case for the compression codings defined |
|  |  | in Section 6.2.2). |
| Values to be added to this name space require expert review and a |  | Values to be added to this name space require expert review and a |
| specification (see "Expert Review" and "Specification Required" in |  | specification (see "Expert Review" and "Specification Required" in |
| Section 4.1 of [RFC5226]), and MUST conform to the purpose of |  | Section 4.1 of [RFC5226]), and MUST conform to the purpose of |
| transfer coding defined in this section. |  | transfer coding defined in this section. |
| The registry itself is maintained at |  | The registry itself is maintained at |
| <http://www.iana.org/assignments/http-parameters>. |  | <http://www.iana.org/assignments/http-parameters>. |
| 6.3. Product Tokens |  | 6.3. Product Tokens |
| skipping to change at page 39, line 13 |  | skipping to change at page 41, line 25 |
| connects to. Each persistent connection applies to only one |  | connects to. Each persistent connection applies to only one |
| transport link. |  | transport link. |
| A proxy server MUST NOT establish a HTTP/1.1 persistent connection |  | A proxy server MUST NOT establish a HTTP/1.1 persistent connection |
| with an HTTP/1.0 client (but see Section 19.7.1 of [RFC2068] for |  | with an HTTP/1.0 client (but see Section 19.7.1 of [RFC2068] for |
| information and discussion of the problems with the Keep-Alive header |  | information and discussion of the problems with the Keep-Alive header |
| implemented by many HTTP/1.0 clients). |  | implemented by many HTTP/1.0 clients). |
| 7.1.3.1. End-to-end and Hop-by-hop Headers |  | 7.1.3.1. End-to-end and Hop-by-hop Headers |
| [[TODO-end-to-end: Restored from <http://tools.ietf.org/html/ |  |  |
| draft-ietf-httpbis-p6-cache-05#section-7.1>. See also |  |  |
| <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/60>. --jre]] |  |  |
| For the purpose of defining the behavior of caches and non-caching |  | For the purpose of defining the behavior of caches and non-caching |
| proxies, we divide HTTP headers into two categories: |  | proxies, we divide HTTP headers into two categories: |
| o End-to-end headers, which are transmitted to the ultimate |  | o End-to-end headers, which are transmitted to the ultimate |
| recipient of a request or response. End-to-end headers in |  | recipient of a request or response. End-to-end headers in |
| responses MUST be stored as part of a cache entry and MUST be |  | responses MUST be stored as part of a cache entry and MUST be |
| transmitted in any response formed from a cache entry. |  | transmitted in any response formed from a cache entry. |
| o Hop-by-hop headers, which are meaningful only for a single |  | o Hop-by-hop headers, which are meaningful only for a single |
| transport-level connection, and are not stored by caches or |  | transport-level connection, and are not stored by caches or |
| skipping to change at page 40, line 7 |  | skipping to change at page 42, line 15 |
| o Upgrade |  | o Upgrade |
| All other headers defined by HTTP/1.1 are end-to-end headers. |  | All other headers defined by HTTP/1.1 are end-to-end headers. |
| Other hop-by-hop headers MUST be listed in a Connection header |  | Other hop-by-hop headers MUST be listed in a Connection header |
| (Section 9.1). |  | (Section 9.1). |
| 7.1.3.2. Non-modifiable Headers |  | 7.1.3.2. Non-modifiable Headers |
| [[TODO-non-mod-headers: Restored from <http://tools.ietf.org/html/ |  |  |
| draft-ietf-httpbis-p6-cache-05#section-7.2>. See also |  |  |
| <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/60>. --jre]] |  |  |
| Some features of HTTP/1.1, such as Digest Authentication, depend on |  | Some features of HTTP/1.1, such as Digest Authentication, depend on |
| the value of certain end-to-end headers. A transparent proxy SHOULD |  | the value of certain end-to-end headers. A transparent proxy SHOULD |
| NOT modify an end-to-end header unless the definition of that header |  | NOT modify an end-to-end header unless the definition of that header |
| requires or specifically allows that. |  | requires or specifically allows that. |
| A transparent proxy MUST NOT modify any of the following fields in a |  | A transparent proxy MUST NOT modify any of the following fields in a |
| request or response, and it MUST NOT add any of these fields if not |  | request or response, and it MUST NOT add any of these fields if not |
| already present: |  | already present: |
| o Content-Location |  | o Content-Location |
| skipping to change at page 50, line 26 |  | skipping to change at page 52, line 31 |
| it is willing to accept trailer fields in a chunked transfer-coding. |  | it is willing to accept trailer fields in a chunked transfer-coding. |
| Its value may consist of the keyword "trailers" and/or a comma- |  | Its value may consist of the keyword "trailers" and/or a comma- |
| separated list of extension transfer-coding names with optional |  | separated list of extension transfer-coding names with optional |
| accept parameters (as described in Section 6.2). |  | accept parameters (as described in Section 6.2). |
| TE = "TE" ":" OWS TE-v |  | TE = "TE" ":" OWS TE-v |
| TE-v = #t-codings |  | TE-v = #t-codings |
| t-codings = "trailers" / ( transfer-extension [ te-params ] ) |  | t-codings = "trailers" / ( transfer-extension [ te-params ] ) |
| te-params = OWS ";" OWS "q=" qvalue *( te-ext ) |  | te-params = OWS ";" OWS "q=" qvalue *( te-ext ) |
| te-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ] |  | te-ext = OWS ";" OWS token [ "=" word ] |
| The presence of the keyword "trailers" indicates that the client is |  | The presence of the keyword "trailers" indicates that the client is |
| willing to accept trailer fields in a chunked transfer-coding, as |  | willing to accept trailer fields in a chunked transfer-coding, as |
| defined in Section 6.2.1. This keyword is reserved for use with |  | defined in Section 6.2.1. This keyword is reserved for use with |
| transfer-coding values even though it does not itself represent a |  | transfer-coding values even though it does not itself represent a |
| transfer-coding. |  | transfer-coding. |
| Examples of its use are: |  | Examples of its use are: |
| TE: deflate |  | TE: deflate |
| skipping to change at page 59, line 22 |  | skipping to change at page 61, line 22 |
| The HTTP Transfer Codings Registry located at |  | The HTTP Transfer Codings Registry located at |
| <http://www.iana.org/assignments/http-parameters> should be updated |  | <http://www.iana.org/assignments/http-parameters> should be updated |
| with the registrations below: |  | with the registrations below: |
| +----------+--------------------------------------+-----------------+ |  | +----------+--------------------------------------+-----------------+ |
| | Name | Description | Reference | |  | | Name | Description | Reference | |
| +----------+--------------------------------------+-----------------+ |  | +----------+--------------------------------------+-----------------+ |
| | chunked | Transfer in a series of chunks | Section 6.2.1 | |  | | chunked | Transfer in a series of chunks | Section 6.2.1 | |
| | compress | UNIX "compress" program method | Section 6.2.2.1 | |  | | compress | UNIX "compress" program method | Section 6.2.2.1 | |
| | deflate | "zlib" format [RFC1950] with | Section 6.2.2.2 | |  | | deflate | "deflate" compression mechanism | Section 6.2.2.2 | |
| | | "deflate" compression | | |  | | | ([RFC1951]) used inside the "zlib" | | |
|  |  | | | data format ([RFC1950]) | | |
| | gzip | Same as GNU zip [RFC1952] | Section 6.2.2.3 | |  | | gzip | Same as GNU zip [RFC1952] | Section 6.2.2.3 | |
| +----------+--------------------------------------+-----------------+ |  | +----------+--------------------------------------+-----------------+ |
| 10.5. Upgrade Token Registration |  | 10.5. Upgrade Token Registration |
| The registration procedure for HTTP Upgrade Tokens -- previously |  | The registration procedure for HTTP Upgrade Tokens -- previously |
| defined in Section 7.2 of [RFC2817] -- is now defined by |  | defined in Section 7.2 of [RFC2817] -- is now defined by |
| Section 9.8.1 of this document. |  | Section 9.8.1 of this document. |
| The HTTP Status Code Registry located at |  | The HTTP Status Code Registry located at |
| skipping to change at page 62, line 38 |  | skipping to change at page 64, line 38 |
| Dave Raggett, Tony Sanders, and Marc VanHeyningen deserve special |  | Dave Raggett, Tony Sanders, and Marc VanHeyningen deserve special |
| recognition for their efforts in defining early aspects of the |  | recognition for their efforts in defining early aspects of the |
| protocol. |  | protocol. |
| This document has benefited greatly from the comments of all those |  | This document has benefited greatly from the comments of all those |
| participating in the HTTP-WG. In addition to those already |  | participating in the HTTP-WG. In addition to those already |
| mentioned, the following individuals have contributed to this |  | mentioned, the following individuals have contributed to this |
| specification: |  | specification: |
| Gary Adams, Harald Tveit Alvestrand, Keith Ball, Brian Behlendorf, |  | Gary Adams, Harald Tveit Alvestrand, Keith Ball, Brian Behlendorf, |
| Paul Burchard, Maurizio Codogno, Mike Cowlishaw, Roman Czyborra, |  | Paul Burchard, Maurizio Codogno, Josh Cohen, Mike Cowlishaw, Roman |
| Michael A. Dolan, Daniel DuBois, David J. Fiander, Alan Freier, Marc |  | Czyborra, Michael A. Dolan, Daniel DuBois, David J. Fiander, Alan |
| Hedlund, Greg Herlihy, Koen Holtman, Alex Hopmann, Bob Jernigan, Shel |  | Freier, Marc Hedlund, Greg Herlihy, Koen Holtman, Alex Hopmann, Bob |
| Kaphan, Rohit Khare, John Klensin, Martijn Koster, Alexei Kosut, |  | Jernigan, Shel Kaphan, Rohit Khare, John Klensin, Martijn Koster, |
| David M. Kristol, Daniel LaLiberte, Ben Laurie, Paul J. Leach, Albert |  | Alexei Kosut, David M. Kristol, Daniel LaLiberte, Ben Laurie, Paul J. |
| Lunde, John C. Mallery, Jean-Philippe Martin-Flatin, Mitra, David |  | Leach, Albert Lunde, John C. Mallery, Jean-Philippe Martin-Flatin, |
| Morris, Gavin Nicol, Ross Patterson, Bill Perry, Jeffrey Perry, Scott |  | Mitra, David Morris, Gavin Nicol, Ross Patterson, Bill Perry, Jeffrey |
| Powers, Owen Rees, Luigi Rizzo, David Robinson, Marc Salomon, Rich |  | Perry, Scott Powers, Owen Rees, Luigi Rizzo, David Robinson, Marc |
| Salz, Allan M. Schiffman, Jim Seidman, Chuck Shotton, Eric W. Sink, |  | Salomon, Rich Salz, Allan M. Schiffman, Jim Seidman, Chuck Shotton, |
| Simon E. Spero, Richard N. Taylor, Robert S. Thau, Bill (BearHeart) |  | Eric W. Sink, Simon E. Spero, Richard N. Taylor, Robert S. Thau, Bill |
| Weinman, Francois Yergeau, Mary Ellen Zurko, Josh Cohen. |  | (BearHeart) Weinman, Francois Yergeau, Mary Ellen Zurko. |
| Thanks to the "cave men" of Palo Alto. You know who you are. |  | Thanks to the "cave men" of Palo Alto. You know who you are. |
| Jim Gettys (the editor of [RFC2616]) wishes particularly to thank Roy |  | Jim Gettys (the editor of [RFC2616]) wishes particularly to thank Roy |
| Fielding, the editor of [RFC2068], along with John Klensin, Jeff |  | Fielding, the editor of [RFC2068], along with John Klensin, Jeff |
| Mogul, Paul Leach, Dave Kristol, Koen Holtman, John Franks, Josh |  | Mogul, Paul Leach, Dave Kristol, Koen Holtman, John Franks, Josh |
| Cohen, Alex Hopmann, Scott Lawrence, and Larry Masinter for their |  | Cohen, Alex Hopmann, Scott Lawrence, and Larry Masinter for their |
| help. And thanks go particularly to Jeff Mogul and Scott Lawrence |  | help. And thanks go particularly to Jeff Mogul and Scott Lawrence |
| for performing the "MUST/MAY/SHOULD" audit. |  | for performing the "MUST/MAY/SHOULD" audit. |
| skipping to change at page 63, line 28 |  | skipping to change at page 65, line 28 |
| constructs defined by David H. Crocker for [RFC5234]. Similarly, it |  | constructs defined by David H. Crocker for [RFC5234]. Similarly, it |
| reuses many of the definitions provided by Nathaniel Borenstein and |  | reuses many of the definitions provided by Nathaniel Borenstein and |
| Ned Freed for MIME [RFC2045]. We hope that their inclusion in this |  | Ned Freed for MIME [RFC2045]. We hope that their inclusion in this |
| specification will help reduce past confusion over the relationship |  | specification will help reduce past confusion over the relationship |
| between HTTP and Internet mail message formats. |  | between HTTP and Internet mail message formats. |
| 13. References |  | 13. References |
| 13.1. Normative References |  | 13.1. Normative References |
| [ISO-8859-1] |  | [ISO-8859-1] International Organization for Standardization, |
| International Organization for Standardization, |  | "Information technology -- 8-bit single-byte coded |
| "Information technology -- 8-bit single-byte coded graphic |  | graphic character sets -- Part 1: Latin alphabet No. |
| character sets -- Part 1: Latin alphabet No. 1", ISO/ |  | 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., |
| and J. Reschke, Ed., "HTTP/1.1, part 2: Message |  | Ed., and J. Reschke, Ed., "HTTP/1.1, part 2: Message |
| Semantics", draft-ietf-httpbis-p2-semantics-09 (work in |  | Semantics", draft-ietf-httpbis-p2-semantics-10 (work in |
| progress), March 2010. |  | progress), July 2010. |
| [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., |
| and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload |  | Ed., and J. Reschke, Ed., "HTTP/1.1, part 3: Message |
| and Content Negotiation", draft-ietf-httpbis-p3-payload-09 |  | Payload and Content Negotiation", |
| (work in progress), March 2010. |  | draft-ietf-httpbis-p3-payload-10 (work in progress), |
|  |  | July 2010. |
| [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., |
| and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and |  | Ed., and J. Reschke, Ed., "HTTP/1.1, part 5: Range |
| Partial Responses", draft-ietf-httpbis-p5-range-09 (work |  | Requests and Partial Responses", |
| in progress), March 2010. |  | draft-ietf-httpbis-p5-range-10 (work in progress), |
|  |  | July 2010. |
| [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., |
| Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part |  | Ed., Nottingham, M., Ed., and J. Reschke, Ed., |
| 6: Caching", draft-ietf-httpbis-p6-cache-09 (work in |  | "HTTP/1.1, part 6: Caching", |
| progress), March 2010. |  | draft-ietf-httpbis-p6-cache-10 (work in progress), |
|  |  | July 2010. |
| [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format |  | [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data |
| Specification version 3.3", RFC 1950, May 1996. |  | Format Specification version 3.3", RFC 1950, May 1996. |
| RFC 1950 is an Informational RFC, thus it may be less |  | RFC 1950 is an Informational RFC, thus it may be less |
| stable than this specification. On the other hand, this |  | stable than this specification. On the other hand, |
| downward reference was present since the publication of |  | this downward reference was present since the |
| RFC 2068 in 1997 ([RFC2068]), therefore it is unlikely to |  | publication of RFC 2068 in 1997 ([RFC2068]), therefore |
| cause problems in practice. See also [BCP97]. |  | it is unlikely to cause problems in practice. See also |
|  |  | [BCP97]. |
| [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification |  | [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format |
| version 1.3", RFC 1951, May 1996. |  | Specification version 1.3", RFC 1951, May 1996. |
| RFC 1951 is an Informational RFC, thus it may be less |  | RFC 1951 is an Informational RFC, thus it may be less |
| stable than this specification. On the other hand, this |  | stable than this specification. On the other hand, |
| downward reference was present since the publication of |  | this downward reference was present since the |
| RFC 2068 in 1997 ([RFC2068]), therefore it is unlikely to |  | publication of RFC 2068 in 1997 ([RFC2068]), therefore |
| cause problems in practice. See also [BCP97]. |  | it is unlikely to cause problems in practice. See also |
|  |  | [BCP97]. |
| [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G. |  | [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and |
| Randers-Pehrson, "GZIP file format specification version |  | G. Randers-Pehrson, "GZIP file format specification |
| 4.3", RFC 1952, May 1996. |  | version 4.3", RFC 1952, May 1996. |
| RFC 1952 is an Informational RFC, thus it may be less |  | RFC 1952 is an Informational RFC, thus it may be less |
| stable than this specification. On the other hand, this |  | stable than this specification. On the other hand, |
| downward reference was present since the publication of |  | this downward reference was present since the |
| RFC 2068 in 1997 ([RFC2068]), therefore it is unlikely to |  | publication of RFC 2068 in 1997 ([RFC2068]), therefore |
| cause problems in practice. See also [BCP97]. |  | it is unlikely to cause problems in practice. See also |
|  |  | [BCP97]. |
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |  | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |
| Requirement Levels", BCP 14, RFC 2119, March 1997. |  | Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform |  | [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, |
| Resource Identifier (URI): Generic Syntax", RFC 3986, |  | "Uniform Resource Identifier (URI): Generic Syntax", |
| STD 66, January 2005. |  | RFC 3986, STD 66, January 2005. |
| [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax |  | [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for |
| Specifications: ABNF", STD 68, RFC 5234, January 2008. |  | Syntax Specifications: ABNF", STD 68, RFC 5234, |
|  |  | January 2008. |
| [USASCII] American National Standards Institute, "Coded Character |  | [USASCII] American National Standards Institute, "Coded Character |
| Set -- 7-bit American Standard Code for Information |  | Set -- 7-bit American Standard Code for Information |
| Interchange", ANSI X3.4, 1986. |  | Interchange", ANSI X3.4, 1986. |
| 13.2. Informative References |  | 13.2. Informative References |
| [BCP97] Klensin, J. and S. Hartman, "Handling Normative References |  | [BCP97] Klensin, J. and S. Hartman, "Handling Normative |
| to Standards-Track Documents", BCP 97, RFC 4897, |  | References to Standards-Track Documents", BCP 97, |
| June 2007. |  | RFC 4897, June 2007. |
| [Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and |  | [Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and |
| Politics", ACM Transactions on Internet Technology Vol. 1, |  | Politics", ACM Transactions on Internet Technology Vol. |
| #2, November 2001, <http://arxiv.org/abs/cs.SE/0105018>. |  | 1, #2, November 2001, |
|  |  | <http://arxiv.org/abs/cs.SE/0105018>. |
| [Nie1997] Nielsen, H., Gettys, J., Prud'hommeaux, E., Lie, H., and |  | [Nie1997] Frystyk, H., Gettys, J., Prud'hommeaux, E., Lie, H., |
| C. Lilley, "Network Performance Effects of HTTP/1.1, CSS1, |  | and C. Lilley, "Network Performance Effects of |
| and PNG", ACM Proceedings of the ACM SIGCOMM '97 |  | HTTP/1.1, CSS1, and PNG", ACM Proceedings of the ACM |
| conference on Applications, technologies, architectures, |  | SIGCOMM '97 conference on Applications, technologies, |
| and protocols for computer communication SIGCOMM '97, |  | architectures, and protocols for computer communication |
| September 1997, |  | SIGCOMM '97, 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>. |  | <http://portal.acm.org/citation.cfm?id=219094>. |
| [RFC1123] Braden, R., "Requirements for Internet Hosts - Application |  | [RFC1123] Braden, R., "Requirements for Internet Hosts - |
| and Support", STD 3, RFC 1123, October 1989. |  | Application 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. |
| [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, |
| Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. |  | "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, |
|  |  | May 1996. |
| [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail |  | [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet |
| Extensions (MIME) Part One: Format of Internet Message |  | Mail Extensions (MIME) Part One: Format of Internet |
| Bodies", RFC 2045, November 1996. |  | Message Bodies", RFC 2045, November 1996. |
| [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) |  | [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail |
| Part Three: Message Header Extensions for Non-ASCII Text", |  | Extensions) Part Three: Message Header Extensions for |
| RFC 2047, November 1996. |  | Non-ASCII Text", RFC 2047, November 1996. |
| [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. |  | [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and |
| Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", |  | T. Berners-Lee, "Hypertext Transfer Protocol -- |
| RFC 2068, January 1997. |  | HTTP/1.1", RFC 2068, January 1997. |
| [RFC2109] Kristol, D. and L. Montulli, "HTTP State Management |  | [RFC2109] Kristol, D. and L. Montulli, "HTTP State Management |
| Mechanism", RFC 2109, February 1997. |  | Mechanism", RFC 2109, February 1997. |
| [RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use |  | [RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, |
| and Interpretation of HTTP Version Numbers", RFC 2145, |  | "Use and Interpretation of HTTP Version Numbers", |
| May 1997. |  | RFC 2145, May 1997. |
| [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., |  | [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext |  | Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext |
| Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. |  | Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. |
| [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within |  | [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within |
| HTTP/1.1", RFC 2817, May 2000. |  | HTTP/1.1", RFC 2817, May 2000. |
| [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. |  | [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. |
| [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management |  | [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management |
| Mechanism", RFC 2965, October 2000. |  | Mechanism", RFC 2965, October 2000. |
| [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration |  | [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration |
| Procedures for Message Header Fields", BCP 90, RFC 3864, |  | Procedures for Message Header Fields", BCP 90, |
| September 2004. |  | RFC 3864, September 2004. |
| [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and |  | [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications |
| Registration Procedures", BCP 13, RFC 4288, December 2005. |  | and Registration Procedures", BCP 13, RFC 4288, |
|  |  | December 2005. |
| [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and |  | [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines |
| Registration Procedures for New URI Schemes", BCP 115, |  | and Registration Procedures for New URI Schemes", |
| RFC 4395, February 2006. |  | BCP 115, RFC 4395, February 2006. |
| [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an |  | [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing |
| IANA Considerations Section in RFCs", BCP 26, RFC 5226, |  | an IANA Considerations Section in RFCs", BCP 26, |
| May 2008. |  | RFC 5226, May 2008. |
| [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, |  | [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, |
| October 2008. |  | October 2008. |
| [Spe] Spero, S., "Analysis of HTTP Performance Problems", |  | [Spe] Spero, S., "Analysis of HTTP Performance Problems", |
| <http://sunsite.unc.edu/mdma-release/http-prob.html>. |  | <http://sunsite.unc.edu/mdma-release/http-prob.html>. |
| [Tou1998] Touch, J., Heidemann, J., and K. Obraczka, "Analysis of |  | [Tou1998] Touch, J., Heidemann, J., and K. Obraczka, "Analysis of |
| HTTP Performance", ISI Research Report ISI/RR-98-463, |  | HTTP Performance", ISI Research Report ISI/RR-98-463, |
| Aug 1998, <http://www.isi.edu/touch/pubs/http-perf96/>. |  | Aug 1998, <http://www.isi.edu/touch/pubs/http-perf96/>. |
| (original report dated Aug. 1996) |  | (original report dated Aug. 1996) |
| Appendix A. Tolerant Applications |  | Appendix A. Tolerant Applications |
| Although this document specifies the requirements for the generation |  | Although this document specifies the requirements for the generation |
| of HTTP/1.1 messages, not all applications will be correct in their |  | of HTTP/1.1 messages, not all applications will be correct in their |
| implementation. We therefore recommend that operational applications |  | implementation. We therefore recommend that operational applications |
| be tolerant of deviations whenever those deviations can be |  | be tolerant of deviations whenever those deviations can be |
| interpreted unambiguously. |  | interpreted unambiguously. |
| Clients SHOULD be tolerant in parsing the Status-Line and servers |  | Clients SHOULD be tolerant in parsing the Status-Line and servers |
| skipping to change at page 67, line 34 |  | skipping to change at page 69, line 38 |
| the exception that not labeling the entity is preferred over labeling |  | the exception that not labeling the entity is preferred over labeling |
| the entity with the labels US-ASCII or ISO-8859-1. See [Part3]. |  | the entity with the labels US-ASCII or ISO-8859-1. See [Part3]. |
| Additional rules for requirements on parsing and encoding of dates |  | Additional rules for requirements on parsing and encoding of dates |
| and other potential problems with date encodings include: |  | and other potential problems with date encodings include: |
| o HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date |  | o HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date |
| which appears to be more than 50 years in the future is in fact in |  | which appears to be more than 50 years in the future is in fact in |
| the past (this helps solve the "year 2000" problem). |  | the past (this helps solve the "year 2000" problem). |
|  |  | o Although all date formats are specified to be case-sensitive, |
|  |  | recipients SHOULD match day, week and timezone names case- |
|  |  | insensitively. |
| o An HTTP/1.1 implementation MAY internally represent a parsed |  | o An HTTP/1.1 implementation MAY internally represent a parsed |
| Expires date as earlier than the proper value, but MUST NOT |  | Expires date as earlier than the proper value, but MUST NOT |
| internally represent a parsed Expires date as later than the |  | internally represent a parsed Expires date as later than the |
| 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 |
| skipping to change at page 72, line 35 |  | skipping to change at page 74, line 44 |
| Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF |  | Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF |
| TE = "TE:" OWS TE-v |  | TE = "TE:" OWS TE-v |
| TE-v = [ ( "," / t-codings ) *( OWS "," [ OWS t-codings ] ) ] |  | TE-v = [ ( "," / t-codings ) *( OWS "," [ OWS t-codings ] ) ] |
| Trailer = "Trailer:" OWS Trailer-v |  | Trailer = "Trailer:" OWS Trailer-v |
| Trailer-v = *( "," OWS ) field-name *( OWS "," [ OWS field-name ] ) |  | Trailer-v = *( "," OWS ) field-name *( OWS "," [ OWS field-name ] ) |
| Transfer-Encoding = "Transfer-Encoding:" OWS Transfer-Encoding-v |  | Transfer-Encoding = "Transfer-Encoding:" OWS Transfer-Encoding-v |
| Transfer-Encoding-v = *( "," OWS ) transfer-coding *( OWS "," [ OWS |  | Transfer-Encoding-v = *( "," OWS ) transfer-coding *( OWS "," [ OWS |
| transfer-coding ] ) |  | transfer-coding ] ) |
| URI = <URI, defined in [RFC3986], Section 3> |  |  |
| URI-reference = <URI-reference, defined in [RFC3986], Section 4.1> |  | URI-reference = <URI-reference, defined in [RFC3986], Section 4.1> |
| Upgrade = "Upgrade:" OWS Upgrade-v |  | Upgrade = "Upgrade:" OWS Upgrade-v |
| Upgrade-v = *( "," OWS ) product *( OWS "," [ OWS product ] ) |  | Upgrade-v = *( "," OWS ) product *( OWS "," [ OWS product ] ) |
| Via = "Via:" OWS Via-v |  | Via = "Via:" OWS Via-v |
| Via-v = *( "," OWS ) received-protocol RWS received-by [ RWS comment |  | Via-v = *( "," OWS ) received-protocol RWS received-by [ RWS comment |
| ] *( OWS "," [ OWS received-protocol RWS received-by [ RWS comment ] |  | ] *( OWS "," [ OWS received-protocol RWS received-by [ RWS comment ] |
| ] ) |  | ] ) |
| Warning = <Warning, defined in [Part6], Section 3.6> |  | Warning = <Warning, defined in [Part6], Section 3.6> |
| skipping to change at page 75, line 18 |  | skipping to change at page 77, line 24 |
| rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT |  | rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT |
| second = 2DIGIT |  | second = 2DIGIT |
| special = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" / |  | special = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" / |
| DQUOTE / "/" / "[" / "]" / "?" / "=" / "{" / "}" |  | DQUOTE / "/" / "[" / "]" / "?" / "=" / "{" / "}" |
| start-line = Request-Line / Status-Line |  | start-line = Request-Line / Status-Line |
| t-codings = "trailers" / ( transfer-extension [ te-params ] ) |  | t-codings = "trailers" / ( transfer-extension [ te-params ] ) |
| tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." / |  | tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." / |
| "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA |  | "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA |
| te-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ] |  | te-ext = OWS ";" OWS token [ "=" word ] |
| te-params = OWS ";" OWS "q=" qvalue *te-ext |  | te-params = OWS ";" OWS "q=" qvalue *te-ext |
| time-of-day = hour ":" minute ":" second |  | time-of-day = hour ":" minute ":" second |
| token = 1*tchar |  | token = 1*tchar |
| trailer-part = *( entity-header CRLF ) |  | trailer-part = *( entity-header CRLF ) |
| transfer-coding = "chunked" / "compress" / "deflate" / "gzip" / |  | transfer-coding = "chunked" / "compress" / "deflate" / "gzip" / |
| transfer-extension |  | transfer-extension |
| transfer-extension = token *( OWS ";" OWS transfer-parameter ) |  | transfer-extension = token *( OWS ";" OWS transfer-parameter ) |
| transfer-parameter = attribute BWS "=" BWS value |  | transfer-parameter = attribute BWS "=" BWS value |
| uri-host = <host, defined in [RFC3986], Section 3.2.2> |  | uri-host = <host, defined in [RFC3986], Section 3.2.2> |
| value = token / quoted-string |  | value = word |
| year = 4DIGIT |  | word = token / quoted-string |
|  |  | year = 4DIGIT |
| ABNF diagnostics: |  | ABNF diagnostics: |
| ; Chunked-Body defined but not used |  | ; Chunked-Body defined but not used |
| ; Content-Length defined but not used |  | ; Content-Length defined but not used |
| ; HTTP-message defined but not used |  | ; HTTP-message defined but not used |
| ; Host defined but not used |  | ; Host defined but not used |
| ; Request defined but not used |  | ; Request defined but not used |
| ; Response defined but not used |  | ; Response defined but not used |
| ; TE defined but not used |  | ; TE defined but not used |
| ; URI defined but not used |  |  |
| ; URI-reference defined but not used |  | ; URI-reference defined but not used |
| ; http-URI defined but not used |  | ; http-URI defined but not used |
| ; https-URI defined but not used |  | ; https-URI defined but not used |
| ; partial-URI defined but not used |  | ; partial-URI defined but not used |
| ; special defined but not used |  | ; special defined but not used |
| Appendix D. Change Log (to be removed by RFC Editor before publication) |  | Appendix D. Change Log (to be removed by RFC Editor before publication) |
| D.1. Since RFC2616 |  | D.1. Since RFC2616 |
| skipping to change at page 82, line 32 |  | skipping to change at page 85, line 8 |
| parsing, treatment of leading and trailing OWS" |  | parsing, treatment of leading and trailing OWS" |
| Partly resolved issues: |  | Partly resolved issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/60>: "Placement of |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/60>: "Placement of |
| 13.5.1 and 13.5.2" |  | 13.5.1 and 13.5.2" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/200>: "use of term |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/200>: "use of term |
| "word" when talking about header structure" |  | "word" when talking about header structure" |
|  |  | D.11. Since draft-ietf-httpbis-p1-messaging-09 |
|  |  | Closed issues: |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/73>: "Clarification |
|  |  | of the term 'deflate'" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/83>: "OPTIONS * and |
|  |  | proxies" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/143>: "IANA registry |
|  |  | for content/transfer encodings" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/165>: "Case- |
|  |  | sensitivity of HTTP-date" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/200>: "use of term |
|  |  | "word" when talking about header structure" |
|  |  | Partly resolved issues: |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/196>: "Term for the |
|  |  | requested resource's URI" |
| Index |  | Index |
| A |  | A |
| application/http Media Type 58 |  | application/http Media Type 60 |
| C |  | C |
| cache 13 |  | cache 13 |
| cacheable 14 |  | cacheable 14 |
| chunked (Coding Format) 32 |  | chunked (Coding Format) 34 |
| client 10 |  | client 11 |
| Coding Format |  | Coding Format |
| chunked 32 |  | chunked 34 |
| compress 34 |  | compress 36 |
| deflate 35 |  | deflate 37 |
| gzip 35 |  | gzip 37 |
| compress (Coding Format) 34 |  | compress (Coding Format) 36 |
| connection 10 |  | connection 11 |
| Connection header 46 |  | Connection header 48 |
| Content-Length header 47 |  | Content-Length header 49 |
| D |  | D |
| Date header 48 |  | Date header 50 |
| deflate (Coding Format) 35 |  | deflate (Coding Format) 37 |
| downstream 12 |  | downstream 12 |
|  |  | E |
|  |  | Effective Request URI 28 |
| G |  | G |
| gateway 13 |  | gateway 13 |
| Grammar |  | Grammar |
| absolute-URI 16 |  | absolute-URI 16 |
| ALPHA 7 |  | ALPHA 7 |
| asctime-date 31 |  | asctime-date 33 |
| attribute 32 |  | attribute 33 |
| authority 16 |  | authority 16 |
| BWS 9 |  | BWS 9 |
| chunk 33 |  | chunk 35 |
| chunk-data 33 |  | chunk-data 35 |
| chunk-ext 33 |  | chunk-ext 35 |
| chunk-ext-name 33 |  | chunk-ext-name 35 |
| chunk-ext-val 33 |  | chunk-ext-val 35 |
| chunk-size 33 |  | chunk-size 35 |
| Chunked-Body 33 |  | Chunked-Body 35 |
| comment 21 |  | comment 22 |
| Connection 46 |  | Connection 48 |
| connection-token 46 |  | connection-token 48 |
| Connection-v 46 |  | Connection-v 48 |
| Content-Length 47 |  | Content-Length 49 |
| Content-Length-v 47 |  | Content-Length-v 49 |
| CR 7 |  | CR 7 |
| CRLF 7 |  | CRLF 7 |
| ctext 21 |  | ctext 22 |
| CTL 7 |  | CTL 7 |
| Date 48 |  | Date 50 |
| Date-v 48 |  | Date-v 50 |
| date1 30 |  | date1 32 |
| date2 32 |  | date2 33 |
| date3 32 |  | date3 33 |
| day 30 |  | day 32 |
| day-name 30 |  | day-name 32 |
| day-name-l 30 |  | day-name-l 32 |
| DIGIT 7 |  | DIGIT 7 |
| DQUOTE 7 |  | DQUOTE 7 |
| extension-code 29 |  | extension-code 31 |
| extension-method 25 |  | extension-method 25 |
| field-content 20 |  | field-content 20 |
| field-name 20 |  | field-name 20 |
| field-value 20 |  | field-value 20 |
| general-header 24 |  | general-header 25 |
| GMT 30 |  | GMT 32 |
| header-field 20 |  | header-field 20 |
| HEXDIG 7 |  | HEXDIG 7 |
| Host 49 |  | Host 51 |
| Host-v 49 |  | Host-v 51 |
| hour 30 |  | hour 32 |
| HTTP-date 30 |  | HTTP-date 31 |
| HTTP-message 19 |  | HTTP-message 19 |
| HTTP-Prot-Name 15 |  | HTTP-Prot-Name 15 |
| http-URI 16 |  | http-URI 17 |
| HTTP-Version 15 |  | HTTP-Version 15 |
| https-URI 18 |  | https-URI 18 |
| last-chunk 33 |  | last-chunk 35 |
| LF 7 |  | LF 7 |
| message-body 22 |  | message-body 22 |
| Method 25 |  | Method 25 |
| minute 30 |  | minute 32 |
| month 30 |  | month 32 |
| obs-date 31 |  | obs-date 32 |
| obs-text 10 |  | obs-text 10 |
| OCTET 7 |  | OCTET 7 |
| OWS 9 |  | OWS 9 |
| path-absolute 16 |  | path-absolute 16 |
| port 16 |  | port 16 |
| product 35 |  | product 38 |
| product-version 35 |  | product-version 38 |
| protocol-name 54 |  | protocol-name 56 |
| protocol-version 54 |  | protocol-version 56 |
| pseudonym 54 |  | pseudonym 56 |
| qdtext 10 |  | qdtext 10 |
| qdtext-nf 33 |  | qdtext-nf 35 |
| query 16 |  | query 16 |
| quoted-cpair 22 |  | quoted-cpair 22 |
| quoted-pair 10 |  | quoted-pair 10 |
| quoted-str-nf 33 |  | quoted-str-nf 35 |
| quoted-string 10 |  | quoted-string 10 |
| qvalue 36 |  | qvalue 38 |
| Reason-Phrase 29 |  | Reason-Phrase 31 |
| received-by 54 |  | received-by 56 |
| received-protocol 54 |  | received-protocol 56 |
| Request 25 |  | Request 25 |
| Request-Line 25 |  | Request-Line 25 |
| request-target 25 |  | request-target 26 |
| Response 28 |  | Response 30 |
| rfc850-date 31 |  | rfc850-date 33 |
| rfc1123-date 30 |  | rfc1123-date 32 |
| RWS 9 |  | RWS 9 |
| second 30 |  | second 32 |
| SP 7 |  | SP 7 |
| special 9 |  | special 10 |
| Status-Code 29 |  | Status-Code 31 |
| Status-Line 28 |  | Status-Line 30 |
| t-codings 50 |  | t-codings 52 |
| tchar 9 |  | tchar 10 |
| TE 50 |  | TE 52 |
| te-ext 50 |  | te-ext 52 |
| te-params 50 |  | te-params 52 |
| TE-v 50 |  | TE-v 52 |
| time-of-day 30 |  | time-of-day 32 |
| token 9 |  | token 10 |
| Trailer 51 |  | Trailer 53 |
| trailer-part 33 |  | trailer-part 35 |
| Trailer-v 51 |  | Trailer-v 53 |
| transfer-coding 31 |  | transfer-coding 33 |
| Transfer-Encoding 52 |  | Transfer-Encoding 54 |
| Transfer-Encoding-v 52 |  | Transfer-Encoding-v 54 |
| transfer-extension 31 |  | transfer-extension 33 |
| transfer-parameter 32 |  | transfer-parameter 33 |
| Upgrade 52 |  | Upgrade 54 |
| Upgrade-v 52 |  | Upgrade-v 54 |
| uri-host 16 |  | uri-host 16 |
| URI-reference 16 |  | URI-reference 16 |
| value 32 |  | value 33 |
| VCHAR 7 |  | VCHAR 7 |
| Via 54 |  | Via 56 |
| Via-v 54 |  | Via-v 56 |
|  |  | word 10 |
| WSP 7 |  | WSP 7 |
| year 30 |  | year 32 |
| gzip (Coding Format) 35 |  | gzip (Coding Format) 37 |
| H |  | H |
| header field 19 |  | header field 19 |
| header section 19 |  | header section 19 |
| Headers |  | Headers |
| Connection 46 |  | Connection 48 |
| Content-Length 47 |  | Content-Length 49 |
| Date 48 |  | Date 50 |
| Host 49 |  | Host 51 |
| TE 50 |  | TE 52 |
| Trailer 51 |  | Trailer 53 |
| Transfer-Encoding 52 |  | Transfer-Encoding 54 |
| Upgrade 52 |  | Upgrade 54 |
| Via 54 |  | Via 56 |
| headers 19 |  | headers 19 |
| Host header 49 |  | Host header 51 |
| http URI scheme 16 |  | http URI scheme 17 |
| https URI scheme 17 |  | https URI scheme 18 |
| I |  | I |
| inbound 12 |  | inbound 12 |
| M |  | M |
| Media Type |  | Media Type |
| application/http 58 |  | application/http 60 |
| message/http 56 |  | message/http 58 |
| message 11 |  | message 11 |
| message/http Media Type 56 |  | message/http Media Type 58 |
| O |  | O |
| origin server 11 |  | origin server 11 |
| outbound 12 |  | outbound 12 |
| P |  | P |
| proxy 12 |  | proxy 13 |
| R |  | R |
| request 11 |  | request 11 |
| resource 16 |  | resource 16 |
| response 11 |  | response 11 |
| reverse proxy 13 |  | reverse proxy 13 |
| S |  | S |
| server 10 |  | server 11 |
| T |  | T |
| TE header 50 |  | TE header 52 |
| Trailer header 51 |  | Trailer header 53 |
| Transfer-Encoding header 52 |  | Transfer-Encoding header 54 |
| tunnel 13 |  | tunnel 13 |
| U |  | U |
| Upgrade header 52 |  | Upgrade header 54 |
| upstream 12 |  | upstream 12 |
| URI scheme |  | URI scheme |
| http 16 |  | http 17 |
| https 17 |  | https 18 |
| user agent 11 |  | user agent 11 |
| V |  | V |
| Via header 54 |  | Via header 56 |
| 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 |
| Fax: +1-949-706-5305 |  | Fax: +1-949-706-5305 |
| Email: fielding@gbiv.com |  | EMail: fielding@gbiv.com |
| URI: http://roy.gbiv.com/ |  | URI: http://roy.gbiv.com/ |
| Jim Gettys |  | Jim Gettys |
| One Laptop per Child |  | Alcatel-Lucent Bell Labs |
| 21 Oak Knoll Road |  | 21 Oak Knoll Road |
| Carlisle, MA 01741 |  | Carlisle, MA 01741 |
| USA |  | USA |
| Email: jg@laptop.org |  | EMail: jg@freedesktop.org |
| URI: http://www.laptop.org/ |  | URI: http://gettys.wordpress.com/ |
| Jeffrey C. Mogul |  | Jeffrey C. Mogul |
| Hewlett-Packard Company |  | Hewlett-Packard Company |
| HP Labs, Large Scale Systems Group |  | HP Labs, Large Scale Systems Group |
| 1501 Page Mill Road, MS 1177 |  | 1501 Page Mill Road, MS 1177 |
| Palo Alto, CA 94304 |  | Palo Alto, CA 94304 |
| USA |  | USA |
| Email: JeffMogul@acm.org |  | EMail: JeffMogul@acm.org |
| Henrik Frystyk Nielsen |  | Henrik Frystyk Nielsen |
| Microsoft Corporation |  | Microsoft Corporation |
| 1 Microsoft Way |  | 1 Microsoft Way |
| Redmond, WA 98052 |  | Redmond, WA 98052 |
| USA |  | USA |
| Email: henrikn@microsoft.com |  | EMail: henrikn@microsoft.com |
| Larry Masinter |  | Larry Masinter |
| Adobe Systems, Incorporated |  | Adobe Systems, Incorporated |
| 345 Park Ave |  | 345 Park Ave |
| San Jose, CA 95110 |  | San Jose, CA 95110 |
| USA |  | USA |
| Email: LMM@acm.org |  | EMail: LMM@acm.org |
| URI: http://larry.masinter.net/ |  | URI: http://larry.masinter.net/ |
| Paul J. Leach |  | Paul J. Leach |
| Microsoft Corporation |  | Microsoft Corporation |
| 1 Microsoft Way |  | 1 Microsoft Way |
| Redmond, WA 98052 |  | Redmond, WA 98052 |
| Email: paulle@microsoft.com |  | EMail: paulle@microsoft.com |
| Tim Berners-Lee |  | Tim Berners-Lee |
| World Wide Web Consortium |  | World Wide Web Consortium |
| MIT Computer Science and Artificial Intelligence Laboratory |  | MIT Computer Science and Artificial Intelligence Laboratory |
| The Stata Center, Building 32 |  | The Stata Center, Building 32 |
| 32 Vassar Street |  | 32 Vassar Street |
| Cambridge, MA 02139 |  | Cambridge, MA 02139 |
| USA |  | USA |
| Email: timbl@w3.org |  | EMail: timbl@w3.org |
| URI: http://www.w3.org/People/Berners-Lee/ |  | URI: http://www.w3.org/People/Berners-Lee/ |
| Yves Lafon (editor) |  | Yves Lafon (editor) |
| World Wide Web Consortium |  | World Wide Web Consortium |
| W3C / ERCIM |  | W3C / ERCIM |
| 2004, rte des Lucioles |  | 2004, rte des Lucioles |
| Sophia-Antipolis, AM 06902 |  | Sophia-Antipolis, AM 06902 |
| France |  | France |
| Email: ylafon@w3.org |  | EMail: ylafon@w3.org |
| URI: http://www.raubacapeu.net/people/yves/ |  | URI: http://www.raubacapeu.net/people/yves/ |
| Julian F. Reschke (editor) |  | Julian F. Reschke (editor) |
| greenbytes GmbH |  | greenbytes GmbH |
| Hafenweg 16 |  | Hafenweg 16 |
| Muenster, NW 48155 |  | Muenster, NW 48155 |
| Germany |  | Germany |
| Phone: +49 251 2807760 |  | Phone: +49 251 2807760 |
| Fax: +49 251 2807761 |  | Fax: +49 251 2807761 |
| Email: julian.reschke@greenbytes.de |  | EMail: julian.reschke@greenbytes.de |
| URI: http://greenbytes.de/tech/webdav/ |  | URI: http://greenbytes.de/tech/webdav/ |
End of changes. 132 change blocks.
| 407 lines changed or deleted |  | 511 lines changed or added |
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/