| draft-ietf-httpbis-p1-messaging-14.txt |  | draft-ietf-httpbis-p1-messaging-15.txt |
--- | --- | --- | --- | ---
| HTTPbis Working Group R. Fielding, Ed. |  | HTTPbis Working Group R. Fielding, Ed. |
| Internet-Draft Adobe |  | Internet-Draft Adobe |
| Obsoletes: 2145,2616 (if approved) J. Gettys |  | Obsoletes: 2145,2616 (if approved) J. Gettys |
| Updates: 2817 (if approved) Alcatel-Lucent |  | Updates: 2817 (if approved) Alcatel-Lucent |
| Intended status: Standards Track J. Mogul |  | Intended status: Standards Track J. Mogul |
| Expires: October 20, 2011 HP |  | Expires: January 12, 2012 HP |
| H. Frystyk |  | H. Frystyk |
| Microsoft |  | Microsoft |
| L. Masinter |  | L. Masinter |
| Adobe |  | Adobe |
| 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 |
| April 18, 2011 |  | July 11, 2011 |
| 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-14 |  | draft-ietf-httpbis-p1-messaging-15 |
| 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 |
| skipping to change at page 2, line 5 |  | skipping to change at page 2, line 5 |
| 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), which is archived at |  | group mailing list (ietf-http-wg@w3.org), which is archived at |
| <http://lists.w3.org/Archives/Public/ietf-http-wg/>. |  | <http://lists.w3.org/Archives/Public/ietf-http-wg/>. |
| The current issues list is at |  | The current issues list is at |
| <http://tools.ietf.org/wg/httpbis/trac/report/3> and related |  | <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.15. |  | The changes in this draft are summarized in Appendix D.16. |
| Status of This Memo |  | Status of This Memo |
| This Internet-Draft is submitted 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). Note that other groups may also distribute |  | Task Force (IETF). Note that other groups may also distribute |
| working documents as Internet-Drafts. The list of current Internet- |  | working documents as Internet-Drafts. The list of current Internet- |
| Drafts is at http://datatracker.ietf.org/drafts/current/. |  | 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." |
| This Internet-Draft will expire on October 20, 2011. |  | This Internet-Draft will expire on January 12, 2012. |
| Copyright Notice |  | Copyright Notice |
| Copyright (c) 2011 IETF Trust and the persons identified as the |  | Copyright (c) 2011 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 |
| skipping to change at page 3, line 11 |  | skipping to change at page 3, line 11 |
| than English. |  | than English. |
| 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 |
| 2. HTTP-related architecture . . . . . . . . . . . . . . . . . . 10 |  | 2. HTTP-related architecture . . . . . . . . . . . . . . . . . . 10 |
| 2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 10 |  | 2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 10 |
| 2.2. Connections and Transport Independence . . . . . . . . . . 12 |  | 2.2. Message Orientation and Buffering . . . . . . . . . . . . 12 |
| 2.3. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 12 |  | 2.3. Connections and Transport Independence . . . . . . . . . . 12 |
| 2.4. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 14 |  | 2.4. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 13 |
| 2.5. Protocol Versioning . . . . . . . . . . . . . . . . . . . 15 |  | 2.5. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 15 |
| 2.6. Uniform Resource Identifiers . . . . . . . . . . . . . . . 17 |  | 2.6. Protocol Versioning . . . . . . . . . . . . . . . . . . . 15 |
| 2.6.1. http URI scheme . . . . . . . . . . . . . . . . . . . 18 |  | 2.7. Uniform Resource Identifiers . . . . . . . . . . . . . . . 18 |
| 2.6.2. https URI scheme . . . . . . . . . . . . . . . . . . . 19 |  | 2.7.1. http URI scheme . . . . . . . . . . . . . . . . . . . 18 |
| 2.6.3. http and https URI Normalization and Comparison . . . 20 |  | 2.7.2. https URI scheme . . . . . . . . . . . . . . . . . . . 20 |
| 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 20 |  | 2.7.3. http and https URI Normalization and Comparison . . . 20 |
| 3.1. Message Parsing Robustness . . . . . . . . . . . . . . . . 21 |  | 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 21 |
|  |  | 3.1. Message Parsing Robustness . . . . . . . . . . . . . . . . 22 |
| 3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 22 |  | 3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 22 |
| 3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 24 |  | 3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 25 |
| 3.4. General Header Fields . . . . . . . . . . . . . . . . . . 27 |  | 3.4. General Header Fields . . . . . . . . . . . . . . . . . . 28 |
| 4. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 |  | 4. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 |
| 4.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 28 |  | 4.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 29 |
| 4.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 28 |  | 4.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 29 |
| 4.1.2. request-target . . . . . . . . . . . . . . . . . . . . 28 |  | 4.1.2. request-target . . . . . . . . . . . . . . . . . . . . 29 |
| 4.2. The Resource Identified by a Request . . . . . . . . . . . 30 |  | 4.2. The Resource Identified by a Request . . . . . . . . . . . 31 |
| 4.3. Effective Request URI . . . . . . . . . . . . . . . . . . 31 |  | 4.3. Effective Request URI . . . . . . . . . . . . . . . . . . 32 |
| 5. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 |  | 5. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 |
| 5.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 33 |  | 5.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 33 |
| 5.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 33 |  | 5.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 34 |
| 6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 33 |  | 6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 34 |
| 6.1. Date/Time Formats: Full Date . . . . . . . . . . . . . . . 33 |  | 6.1. Date/Time Formats: Full Date . . . . . . . . . . . . . . . 34 |
| 6.2. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 36 |  | 6.2. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 37 |
| 6.2.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 37 |  | 6.2.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 38 |
| 6.2.2. Compression Codings . . . . . . . . . . . . . . . . . 39 |  | 6.2.2. Compression Codings . . . . . . . . . . . . . . . . . 40 |
| 6.2.3. Transfer Coding Registry . . . . . . . . . . . . . . . 40 |  | 6.2.3. Transfer Coding Registry . . . . . . . . . . . . . . . 41 |
| 6.3. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 41 |  | 6.3. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 42 |
| 6.4. Quality Values . . . . . . . . . . . . . . . . . . . . . . 41 |  | 6.4. Quality Values . . . . . . . . . . . . . . . . . . . . . . 42 |
| 7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 41 |  | 7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 42 |
| 7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 42 |  | 7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 43 |
| 7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 42 |  | 7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 43 |
| 7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 42 |  | 7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 43 |
| 7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 44 |  | 7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 45 |
| 7.1.4. Practical Considerations . . . . . . . . . . . . . . . 46 |  | 7.1.4. Practical Considerations . . . . . . . . . . . . . . . 47 |
| 7.2. Message Transmission Requirements . . . . . . . . . . . . 47 |  | 7.2. Message Transmission Requirements . . . . . . . . . . . . 48 |
| 7.2.1. Persistent Connections and Flow Control . . . . . . . 47 |  | 7.2.1. Persistent Connections and Flow Control . . . . . . . 48 |
| 7.2.2. Monitoring Connections for Error Status Messages . . . 48 |  | 7.2.2. Monitoring Connections for Error Status Messages . . . 49 |
| 7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 48 |  | 7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 49 |
| 7.2.4. Client Behavior if Server Prematurely Closes |  | 7.2.4. Client Behavior if Server Prematurely Closes |
| Connection . . . . . . . . . . . . . . . . . . . . . . 50 |  | Connection . . . . . . . . . . . . . . . . . . . . . . 51 |
| 8. Miscellaneous notes that might disappear . . . . . . . . . . . 51 |  | 8. Miscellaneous notes that might disappear . . . . . . . . . . . 52 |
| 8.1. Scheme aliases considered harmful . . . . . . . . . . . . 51 |  | 8.1. Scheme aliases considered harmful . . . . . . . . . . . . 52 |
| 8.2. Use of HTTP for proxy communication . . . . . . . . . . . 51 |  | 8.2. Use of HTTP for proxy communication . . . . . . . . . . . 52 |
| 8.3. Interception of HTTP for access control . . . . . . . . . 51 |  | 8.3. Interception of HTTP for access control . . . . . . . . . 52 |
| 8.4. Use of HTTP by other protocols . . . . . . . . . . . . . . 51 |  | 8.4. Use of HTTP by other protocols . . . . . . . . . . . . . . 52 |
| 8.5. Use of HTTP by media type specification . . . . . . . . . 51 |  | 8.5. Use of HTTP by media type specification . . . . . . . . . 52 |
| 9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 51 |  | 9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 52 |
| 9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 51 |  | 9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 52 |
| 9.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 53 |  | 9.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 54 |
| 9.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 |  | 9.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 |
| 9.3.1. Clockless Origin Server Operation . . . . . . . . . . 54 |  | 9.3.1. Clockless Origin Server Operation . . . . . . . . . . 55 |
| 9.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 |  | 9.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 |
| 9.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 |  | 9.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 |
| 9.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 57 |  | 9.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 58 |
| 9.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 57 |  | 9.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 58 |
| 9.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 58 |  | 9.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 59 |
| 9.8.1. Upgrade Token Registry . . . . . . . . . . . . . . . . 59 |  | 9.8.1. Upgrade Token Registry . . . . . . . . . . . . . . . . 60 |
| 9.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 |  | 9.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 |
| 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61 |  | 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 62 |
| 10.1. Header Field Registration . . . . . . . . . . . . . . . . 61 |  | 10.1. Header Field Registration . . . . . . . . . . . . . . . . 62 |
| 10.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 62 |  | 10.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 63 |
| 10.3. Internet Media Type Registrations . . . . . . . . . . . . 62 |  | 10.3. Internet Media Type Registrations . . . . . . . . . . . . 63 |
| 10.3.1. Internet Media Type message/http . . . . . . . . . . . 62 |  | 10.3.1. Internet Media Type message/http . . . . . . . . . . . 63 |
| 10.3.2. Internet Media Type application/http . . . . . . . . . 63 |  | 10.3.2. Internet Media Type application/http . . . . . . . . . 64 |
| 10.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 64 |  | 10.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 65 |
| 10.5. Upgrade Token Registration . . . . . . . . . . . . . . . . 65 |  | 10.5. Upgrade Token Registration . . . . . . . . . . . . . . . . 66 |
| 11. Security Considerations . . . . . . . . . . . . . . . . . . . 65 |  | 11. Security Considerations . . . . . . . . . . . . . . . . . . . 66 |
| 11.1. Personal Information . . . . . . . . . . . . . . . . . . . 65 |  | 11.1. Personal Information . . . . . . . . . . . . . . . . . . . 66 |
| 11.2. Abuse of Server Log Information . . . . . . . . . . . . . 66 |  | 11.2. Abuse of Server Log Information . . . . . . . . . . . . . 67 |
| 11.3. Attacks Based On File and Path Names . . . . . . . . . . . 66 |  | 11.3. Attacks Based On File and Path Names . . . . . . . . . . . 67 |
| 11.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 66 |  | 11.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 67 |
| 11.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 67 |  | 11.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 68 |
| 11.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 68 |  | 11.6. Protocol Element Size Overflows . . . . . . . . . . . . . 69 |
| 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 68 |  | 11.7. Denial of Service Attacks on Proxies . . . . . . . . . . . 69 |
| 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 69 |  | 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 69 |
| 13.1. Normative References . . . . . . . . . . . . . . . . . . . 69 |  | 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 70 |
| 13.2. Informative References . . . . . . . . . . . . . . . . . . 71 |  | 13.1. Normative References . . . . . . . . . . . . . . . . . . . 70 |
| Appendix A. Tolerant Applications . . . . . . . . . . . . . . . . 73 |  | 13.2. Informative References . . . . . . . . . . . . . . . . . . 72 |
| Appendix B. HTTP Version History . . . . . . . . . . . . . . . . 74 |  | Appendix A. Tolerant Applications . . . . . . . . . . . . . . . . 74 |
| B.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 75 |  | Appendix B. HTTP Version History . . . . . . . . . . . . . . . . 75 |
| B.1.1. Multi-homed Web Servers . . . . . . . . . . . . . . . 75 |  | B.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 76 |
|  |  | B.1.1. Multi-homed Web Servers . . . . . . . . . . . . . . . 76 |
| B.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 76 |  | B.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 76 |
| B.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 76 |  | B.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 77 |
| Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 77 |  | Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 78 |
| Appendix D. Change Log (to be removed by RFC Editor before |  | Appendix D. Change Log (to be removed by RFC Editor before |
| publication) . . . . . . . . . . . . . . . . . . . . 81 |  | publication) . . . . . . . . . . . . . . . . . . . . 82 |
| D.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 81 |  | D.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 82 |
| D.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 81 |  | D.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 82 |
| D.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 83 |  | D.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 84 |
| D.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 84 |  | D.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 85 |
| D.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 84 |  | D.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 85 |
| D.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 85 |  | D.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 86 |
| D.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 85 |  | D.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 86 |
| D.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 86 |  | D.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 87 |
| D.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 87 |  | D.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 88 |
| D.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 87 |  | D.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 88 |
| D.11. Since draft-ietf-httpbis-p1-messaging-09 . . . . . . . . . 88 |  | D.11. Since draft-ietf-httpbis-p1-messaging-09 . . . . . . . . . 89 |
| D.12. Since draft-ietf-httpbis-p1-messaging-10 . . . . . . . . . 88 |  | D.12. Since draft-ietf-httpbis-p1-messaging-10 . . . . . . . . . 89 |
| D.13. Since draft-ietf-httpbis-p1-messaging-11 . . . . . . . . . 89 |  | D.13. Since draft-ietf-httpbis-p1-messaging-11 . . . . . . . . . 90 |
| D.14. Since draft-ietf-httpbis-p1-messaging-12 . . . . . . . . . 89 |  | D.14. Since draft-ietf-httpbis-p1-messaging-12 . . . . . . . . . 90 |
| D.15. Since draft-ietf-httpbis-p1-messaging-13 . . . . . . . . . 90 |  | D.15. Since draft-ietf-httpbis-p1-messaging-13 . . . . . . . . . 91 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 |  | D.16. Since draft-ietf-httpbis-p1-messaging-14 . . . . . . . . . 91 |
|  |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 |
| 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 the target resource |  | Identifier (URI) standard [RFC3986] to indicate the target resource |
| and relationships between resources. Messages are passed in a format |  | and 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 12, line 5 |  | skipping to change at page 12, line 5 |
| Server: Apache |  | Server: Apache |
| Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT |  | Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT |
| ETag: "34aa387-d-1568eb00" |  | ETag: "34aa387-d-1568eb00" |
| Accept-Ranges: bytes |  | Accept-Ranges: bytes |
| Content-Length: 14 |  | Content-Length: 14 |
| Vary: Accept-Encoding |  | Vary: Accept-Encoding |
| Content-Type: text/plain |  | Content-Type: text/plain |
| Hello World! |  | Hello World! |
| 2.2. Connections and Transport Independence |  | 2.2. Message Orientation and Buffering |
|  |  | Fundamentally, HTTP is a message-based protocol. Although message |
|  |  | bodies can be chunked (Section 6.2.1) and implementations often make |
|  |  | parts of a message available progressively, this is not required, and |
|  |  | some widely-used implementations only make a message available when |
|  |  | it is complete. Furthermore, while most proxies will progressively |
|  |  | stream messages, some amount of buffering will take place, and some |
|  |  | proxies might buffer messages to perform transformations, check |
|  |  | content or provide other services. |
|  |  | Therefore, extensions to and uses of HTTP cannot rely on the |
|  |  | availability of a partial message, or assume that messages will not |
|  |  | be buffered. There are strategies that can be used to test for |
|  |  | buffering in a given connection, but it should be understood that |
|  |  | behaviors can differ across connections, and between requests and |
|  |  | responses. |
|  |  | Recipients MUST consider every message in a connection in isolation; |
|  |  | because HTTP is a stateless protocol, it cannot be assumed that two |
|  |  | requests on the same connection are from the same client or share any |
|  |  | other common attributes. In particular, intermediaries might mix |
|  |  | requests from different clients into a single server connection. |
|  |  | Note that some existing HTTP extensions (e.g., [RFC4559]) violate |
|  |  | this requirement, thereby potentially causing interoperability and |
|  |  | security problems. |
|  |  | 2.3. Connections and Transport Independence |
| HTTP messaging is independent of the underlying transport or session- |  | HTTP messaging is independent of the underlying transport or session- |
| layer connection protocol(s). HTTP only presumes a reliable |  | layer connection protocol(s). HTTP only presumes a reliable |
| transport with in-order delivery of requests and the corresponding |  | transport with in-order delivery of requests and the corresponding |
| in-order delivery of responses. The mapping of HTTP request and |  | in-order delivery of responses. The mapping of HTTP request and |
| response structures onto the data units of the underlying transport |  | response structures onto the data units of the underlying transport |
| protocol is outside the scope of this specification. |  | protocol is outside the scope of this specification. |
| The specific connection protocols to be used for an interaction are |  | The specific connection protocols to be used for an interaction are |
| determined by client configuration and the target resource's URI. |  | determined by client configuration and the target resource's URI. |
| For example, the "http" URI scheme (Section 2.6.1) indicates a |  | For example, the "http" URI scheme (Section 2.7.1) indicates a |
| default connection of TCP over IP, with a default TCP port of 80, but |  | default connection of TCP over IP, with a default TCP port of 80, but |
| the client might be configured to use a proxy via some other |  | the client might be configured to use a proxy via some other |
| connection port or protocol instead of using the defaults. |  | connection port or protocol instead of using the defaults. |
| A connection might be used for multiple HTTP request/response |  | A connection might be used for multiple HTTP request/response |
| exchanges, as defined in Section 7.1. |  | exchanges, as defined in Section 7.1. |
| 2.3. Intermediaries |  | 2.4. Intermediaries |
| HTTP enables the use of intermediaries to satisfy requests through a |  | HTTP enables the use of intermediaries to satisfy requests through a |
| chain of connections. There are three common forms of HTTP |  | chain of connections. There are three common forms of HTTP |
| intermediary: proxy, gateway, and tunnel. In some cases, a single |  | intermediary: proxy, gateway, and tunnel. In some cases, a single |
| intermediary might act as an origin server, proxy, gateway, or |  | intermediary might act as an origin server, proxy, gateway, or |
| tunnel, switching behavior based on the nature of each request. |  | tunnel, switching behavior based on the nature of each request. |
| > > > > |  | > > > > |
| UA =========== A =========== B =========== C =========== O |  | UA =========== A =========== B =========== C =========== O |
| < < < < |  | < < < < |
| skipping to change at page 13, line 30 |  | skipping to change at page 14, line 11 |
| that would be significant to the original sender or potentially |  | that would be significant to the original sender or potentially |
| significant to downstream recipients). For example, a transforming |  | significant to downstream recipients). For example, a transforming |
| proxy might be acting as a shared annotation server (modifying |  | proxy might be acting as a shared annotation server (modifying |
| responses to include references to a local annotation database), a |  | responses to include references to a local annotation database), a |
| malware filter, a format transcoder, or an intranet-to-Internet |  | malware filter, a format transcoder, or an intranet-to-Internet |
| privacy filter. Such transformations are presumed to be desired by |  | privacy filter. Such transformations are presumed to be desired by |
| the client (or client organization) that selected the proxy and are |  | the client (or client organization) that selected the proxy and are |
| beyond the scope of this specification. However, when a proxy is not |  | beyond the scope of this specification. However, when a proxy is not |
| intended to transform a given message, we use the term "non- |  | intended to transform a given message, we use the term "non- |
| transforming proxy" to target requirements that preserve HTTP message |  | transforming proxy" to target requirements that preserve HTTP message |
| semantics. |  | semantics. See Section 8.2.4 of [Part2] and Section 3.6 of [Part6] |
|  |  | for status and warning codes related to transformations. |
| A "gateway" (a.k.a., "reverse proxy") is a receiving agent that acts |  | A "gateway" (a.k.a., "reverse proxy") is a receiving agent that acts |
| as a layer above some other server(s) and translates the received |  | as a layer above some other server(s) and translates the received |
| requests to the underlying server's protocol. Gateways are often |  | requests to the underlying server's protocol. Gateways are often |
| used to encapsulate legacy or untrusted information services, to |  | used to encapsulate legacy or untrusted information services, to |
| improve server performance through "accelerator" caching, and to |  | improve server performance through "accelerator" caching, and to |
| enable partitioning or load-balancing of HTTP services across |  | enable partitioning or load-balancing of HTTP services across |
| multiple machines. |  | multiple machines. |
| A gateway behaves as an origin server on its outbound connection and |  | A gateway behaves as an origin server on its outbound connection and |
| skipping to change at page 14, line 29 |  | skipping to change at page 15, line 10 |
| proxy" [RFC3040], "transparent proxy" [RFC1919], or "captive portal", |  | proxy" [RFC3040], "transparent proxy" [RFC1919], or "captive portal", |
| differs from an HTTP proxy because it has not been selected by the |  | differs from an HTTP proxy because it has not been selected by the |
| client. Instead, the network intermediary redirects outgoing TCP |  | client. Instead, the network intermediary redirects outgoing TCP |
| port 80 packets (and occasionally other common port traffic) to an |  | port 80 packets (and occasionally other common port traffic) to an |
| internal HTTP server. Interception proxies are commonly found on |  | internal HTTP server. Interception proxies are commonly found on |
| public network access points, as a means of enforcing account |  | public network access points, as a means of enforcing account |
| subscription prior to allowing use of non-local Internet services, |  | subscription prior to allowing use of non-local Internet services, |
| and within corporate firewalls to enforce network usage policies. |  | and within corporate firewalls to enforce network usage policies. |
| They are indistinguishable from a man-in-the-middle attack. |  | They are indistinguishable from a man-in-the-middle attack. |
| 2.4. Caches |  | 2.5. Caches |
| A "cache" is a local store of previous response messages and the |  | A "cache" is a local store of previous response messages and the |
| subsystem that controls its message storage, retrieval, and deletion. |  | subsystem that controls its message storage, retrieval, and deletion. |
| A cache stores cacheable responses in order to reduce the response |  | A cache stores cacheable responses in order to reduce the response |
| time and network bandwidth consumption on future, equivalent |  | time and network bandwidth consumption on future, equivalent |
| requests. Any client or server MAY employ a cache, though a cache |  | requests. Any client or server MAY employ a cache, though a cache |
| cannot be used by a server while it is acting as a tunnel. |  | cannot be used by a server while it is acting as a tunnel. |
| The effect of a cache is that the request/response chain is shortened |  | The effect of a cache is that the request/response chain is shortened |
| if one of the participants along the chain has a cached response |  | if one of the participants along the chain has a cached response |
| skipping to change at page 15, line 14 |  | skipping to change at page 15, line 44 |
| cache behavior and cacheable responses are defined in Section 2 of |  | cache behavior and cacheable responses are defined in Section 2 of |
| [Part6]. |  | [Part6]. |
| There are a wide variety of architectures and configurations of |  | There are a wide variety of architectures and configurations of |
| caches and proxies deployed across the World Wide Web and inside |  | caches and proxies deployed across the World Wide Web and inside |
| large organizations. These systems include national hierarchies of |  | large organizations. These systems include national hierarchies of |
| proxy caches to save transoceanic bandwidth, systems that broadcast |  | proxy caches to save transoceanic bandwidth, systems that broadcast |
| or multicast cache entries, organizations that distribute subsets of |  | or multicast cache entries, organizations that distribute subsets of |
| cached data via optical media, and so on. |  | cached data via optical media, and so on. |
| 2.5. Protocol Versioning |  | 2.6. Protocol Versioning |
| HTTP uses a "<major>.<minor>" numbering scheme to indicate versions |  | HTTP uses a "<major>.<minor>" numbering scheme to indicate versions |
| of the protocol. This specification defines version "1.1". The |  | of the protocol. This specification defines version "1.1". The |
| protocol version as a whole indicates the sender's compliance with |  | protocol version as a whole indicates the sender's compliance with |
| the set of requirements laid out in that version's corresponding |  | the set of requirements laid out in that version's corresponding |
| specification of HTTP. |  | specification of HTTP. |
| The version of an HTTP message is indicated by an HTTP-Version field |  | The version of an HTTP message is indicated by an HTTP-Version field |
| in the first line of the message. HTTP-Version is case-sensitive. |  | in the first line of the message. HTTP-Version is case-sensitive. |
| HTTP-Version = HTTP-Prot-Name "/" 1*DIGIT "." 1*DIGIT |  | HTTP-Version = HTTP-Prot-Name "/" DIGIT "." DIGIT |
| HTTP-Prot-Name = %x48.54.54.50 ; "HTTP", case-sensitive |  | HTTP-Prot-Name = %x48.54.54.50 ; "HTTP", case-sensitive |
| The HTTP version number consists of two non-negative decimal integers |  | The HTTP version number consists of two decimal digits separated by a |
| separated by a "." (period or decimal point). The first number |  | "." (period or decimal point). The first digit ("major version") |
| ("major version") indicates the HTTP messaging syntax, whereas the |  | indicates the HTTP messaging syntax, whereas the second digit ("minor |
| second number ("minor version") indicates the highest minor version |  | version") indicates the highest minor version to which the sender is |
| to which the sender is at least conditionally compliant and able to |  | at least conditionally compliant and able to understand for future |
| understand for future communication. The minor version advertises |  | communication. The minor version advertises the sender's |
| the sender's communication capabilities even when the sender is only |  | communication capabilities even when the sender is only using a |
| using a backwards-compatible subset of the protocol, thereby letting |  | backwards-compatible subset of the protocol, thereby letting the |
| the recipient know that more advanced features can be used in |  | recipient know that more advanced features can be used in response |
| response (by servers) or in future requests (by clients). |  | (by servers) or in future requests (by clients). |
| When comparing HTTP versions, the numbers MUST be compared |  |  |
| numerically rather than lexically. For example, HTTP/2.4 is a lower |  |  |
| version than HTTP/2.13, which in turn is lower than HTTP/12.3. |  |  |
| Leading zeros MUST be ignored by recipients and MUST NOT be sent. |  |  |
| When an HTTP/1.1 message is sent to an HTTP/1.0 recipient [RFC1945] |  | When an HTTP/1.1 message is sent to an HTTP/1.0 recipient [RFC1945] |
| or a recipient whose version is unknown, the HTTP/1.1 message is |  | or a recipient whose version is unknown, the HTTP/1.1 message is |
| constructed such that it can be interpreted as a valid HTTP/1.0 |  | constructed such that it can be interpreted as a valid HTTP/1.0 |
| message if all of the newer features are ignored. This specification |  | message if all of the newer features are ignored. This specification |
| places recipient-version requirements on some new features so that a |  | places recipient-version requirements on some new features so that a |
| compliant sender will only use compatible features until it has |  | compliant sender will only use compatible features until it has |
| determined, through configuration or the receipt of a message, that |  | determined, through configuration or the receipt of a message, that |
| the recipient supports HTTP/1.1. |  | the recipient supports HTTP/1.1. |
| skipping to change at page 17, line 26 |  | skipping to change at page 18, line 5 |
| The intention of HTTP's versioning design is that the major number |  | The intention of HTTP's versioning design is that the major number |
| will only be incremented if an incompatible message syntax is |  | will only be incremented if an incompatible message syntax is |
| introduced, and that the minor number will only be incremented when |  | introduced, and that the minor number will only be incremented when |
| changes made to the protocol have the effect of adding to the message |  | changes made to the protocol have the effect of adding to the message |
| semantics or implying additional capabilities of the sender. |  | semantics or implying additional capabilities of the sender. |
| However, the minor version was not incremented for the changes |  | However, the minor version was not incremented for the changes |
| introduced between [RFC2068] and [RFC2616], and this revision is |  | introduced between [RFC2068] and [RFC2616], and this revision is |
| specifically avoiding any such changes to the protocol. |  | specifically avoiding any such changes to the protocol. |
| 2.6. Uniform Resource Identifiers |  | 2.7. Uniform Resource Identifiers |
| Uniform Resource Identifiers (URIs) [RFC3986] are used throughout |  | Uniform Resource Identifiers (URIs) [RFC3986] are used throughout |
| HTTP as the means for identifying resources. URI references are used |  | HTTP as the means for identifying resources. URI references are used |
| to target requests, indicate redirects, and define relationships. |  | to target requests, indicate redirects, and define relationships. |
| HTTP does not limit what a resource might be; it merely defines an |  | HTTP does not limit what a resource might be; it merely defines an |
| 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", |
| skipping to change at page 18, line 15 |  | skipping to change at page 18, line 42 |
| Each protocol element in HTTP that allows a URI reference will |  | Each protocol element in HTTP that allows a URI reference will |
| indicate in its ABNF production whether the element allows any form |  | indicate in its ABNF production whether the element allows any form |
| of reference (URI-reference), only a URI in absolute form (absolute- |  | of reference (URI-reference), only a URI in absolute form (absolute- |
| URI), only the path and optional query components, or some |  | URI), only the path and optional query components, or some |
| combination of the above. Unless otherwise indicated, URI references |  | combination of the above. Unless otherwise indicated, URI references |
| are parsed relative to the effective request URI, which defines the |  | are parsed relative to the effective request URI, which defines the |
| default base URI for references in both the request and its |  | default base URI for references in both the request and its |
| corresponding response. |  | corresponding response. |
| 2.6.1. http URI scheme |  | 2.7.1. http URI scheme |
| The "http" URI scheme is hereby defined for the purpose of minting |  | The "http" URI scheme is hereby defined for the purpose of minting |
| identifiers according to their association with the hierarchical |  | identifiers according to their association with the hierarchical |
| namespace governed by a potential HTTP origin server listening for |  | namespace governed by a potential HTTP origin server listening for |
| TCP connections on a given port. |  | TCP connections on a given port. |
| http-URI = "http:" "//" authority path-abempty [ "?" query ] |  | http-URI = "http:" "//" authority path-abempty [ "?" query ] |
| The HTTP origin server is identified by the generic syntax's |  | The HTTP origin server is identified by the generic syntax's |
| authority component, which includes a host identifier and optional |  | authority component, which includes a host identifier and optional |
| skipping to change at page 19, line 36 |  | skipping to change at page 20, line 14 |
| authentication information, such as within command invocation |  | authentication information, such as within command invocation |
| options, configuration files, or bookmark lists, even though such |  | options, configuration files, or bookmark lists, even though such |
| usage might expose a user identifier or password. Senders MUST NOT |  | usage might expose a user identifier or password. Senders MUST NOT |
| include a userinfo subcomponent (and its "@" delimiter) when |  | include a userinfo subcomponent (and its "@" delimiter) when |
| transmitting an "http" URI in a message. Recipients of HTTP messages |  | transmitting an "http" URI in a message. Recipients of HTTP messages |
| that contain a URI reference SHOULD parse for the existence of |  | that contain a URI reference SHOULD parse for the existence of |
| userinfo and treat its presence as an error, likely indicating that |  | userinfo and treat its presence as an error, likely indicating that |
| the deprecated subcomponent is being used to obscure the authority |  | the deprecated subcomponent is being used to obscure the authority |
| for the sake of phishing attacks. |  | for the sake of phishing attacks. |
| 2.6.2. https URI scheme |  | 2.7.2. https URI scheme |
| The "https" URI scheme is hereby defined for the purpose of minting |  | The "https" URI scheme is hereby defined for the purpose of minting |
| identifiers according to their association with the hierarchical |  | identifiers according to their association with the hierarchical |
| namespace governed by a potential HTTP origin server listening for |  | namespace governed by a potential HTTP origin server listening for |
| SSL/TLS-secured connections on a given TCP port. |  | SSL/TLS-secured connections on a given TCP port. |
| All of the requirements listed above for the "http" scheme are also |  | All of the requirements listed above for the "http" scheme are also |
| requirements for the "https" scheme, except that a default TCP port |  | requirements for the "https" scheme, except that a default TCP port |
| of 443 is assumed if the port subcomponent is empty or not given, and |  | of 443 is assumed if the port subcomponent is empty or not given, and |
| the TCP connection MUST be secured for privacy through the use of |  | the TCP connection MUST be secured for privacy through the use of |
| skipping to change at page 20, line 15 |  | skipping to change at page 20, line 41 |
| They can, however, be reused in a private cache if the message is |  | They can, however, be reused in a private cache if the message is |
| cacheable by default in HTTP or specifically indicated as such by the |  | cacheable by default in HTTP or specifically indicated as such by the |
| Cache-Control header field (Section 3.2 of [Part6]). |  | Cache-Control header field (Section 3.2 of [Part6]). |
| Resources made available via the "https" scheme have no shared |  | Resources made available via the "https" scheme have no shared |
| identity with the "http" scheme even if their resource identifiers |  | identity with the "http" scheme even if their resource identifiers |
| indicate the same authority (the same host listening to the same TCP |  | indicate the same authority (the same host listening to the same TCP |
| port). They are distinct name spaces and are considered to be |  | port). They are distinct name spaces and are considered to be |
| distinct origin servers. However, an extension to HTTP that is |  | distinct origin servers. However, an extension to HTTP that is |
| defined to apply to entire host domains, such as the Cookie protocol |  | defined to apply to entire host domains, such as the Cookie protocol |
| [draft-ietf-httpstate-cookie], can allow information set by one |  | [RFC6265], can allow information set by one service to impact |
| service to impact communication with other services within a matching |  | communication with other services within a matching group of host |
| group of host domains. |  | domains. |
| The process for authoritative access to an "https" identified |  | The process for authoritative access to an "https" identified |
| resource is defined in [RFC2818]. |  | resource is defined in [RFC2818]. |
| 2.6.3. http and https URI Normalization and Comparison |  | 2.7.3. http and https URI Normalization and Comparison |
| Since the "http" and "https" schemes conform to the URI generic |  | Since the "http" and "https" schemes conform to the URI generic |
| syntax, such URIs are normalized and compared according to the |  | syntax, such URIs are normalized and compared according to the |
| algorithm defined in [RFC3986], Section 6, using the defaults |  | algorithm defined in [RFC3986], Section 6, using the defaults |
| described above for each scheme. |  | described above for each scheme. |
| If the port is equal to the default port for a scheme, the normal |  | If the port is equal to the default port for a scheme, the normal |
| form is to elide the port subcomponent. Likewise, an empty path |  | form is to elide the port subcomponent. Likewise, an empty path |
| component is equivalent to an absolute path of "/", so the normal |  | component is equivalent to an absolute path of "/", so the normal |
| form is to provide a path of "/" instead. The scheme and host are |  | form is to provide a path of "/" instead. The scheme and host are |
| skipping to change at page 23, line 19 |  | skipping to change at page 23, line 46 |
| fields with the same field name can be combined into one "field-name: |  | fields with the same field name can be combined into one "field-name: |
| field-value" pair, without changing the semantics of the message, by |  | field-value" pair, without changing the semantics of the message, by |
| appending each subsequent field value to the combined field value in |  | appending each subsequent field value to the combined field value in |
| order, separated by a comma. The order in which header fields with |  | order, separated by a comma. The order in which header fields with |
| the same field name are received is therefore significant to the |  | the same field name are received is therefore significant to the |
| interpretation of the combined field value; a proxy MUST NOT change |  | interpretation of the combined field value; a proxy MUST NOT change |
| the order of these field values when forwarding a message. |  | the order of these field values when forwarding a message. |
| Note: The "Set-Cookie" header field as implemented in practice can |  | Note: The "Set-Cookie" header field as implemented in practice can |
| occur multiple times, but does not use the list syntax, and thus |  | occur multiple times, but does not use the list syntax, and thus |
| cannot be combined into a single line |  | cannot be combined into a single line ([RFC6265]). (See Appendix |
| ([draft-ietf-httpstate-cookie]). (See Appendix A.2.3 of [Kri2001] |  | A.2.3 of [Kri2001] for details.) Also note that the Set-Cookie2 |
| for details.) Also note that the Set-Cookie2 header field |  | header field specified in [RFC2965] does not share this problem. |
| specified in [RFC2965] does not share this problem. |  |  |
| Historically, HTTP header field values could be extended over |  | Historically, HTTP header field values could be extended over |
| multiple lines by preceding each extra line with at least one space |  | multiple lines by preceding each extra line with at least one space |
| or horizontal tab octet (line folding). This specification |  | or horizontal tab octet (line folding). This specification |
| deprecates such line folding except within the message/http media |  | deprecates such line folding except within the message/http media |
| type (Section 10.3.1). HTTP/1.1 senders MUST NOT produce messages |  | type (Section 10.3.1). HTTP/1.1 senders MUST NOT produce messages |
| that include line folding (i.e., that contain any field-content that |  | that include line folding (i.e., that contain any field-content that |
| matches the obs-fold rule) unless the message is intended for |  | matches the obs-fold rule) unless the message is intended for |
| packaging within the message/http media type. HTTP/1.1 recipients |  | packaging within the message/http media type. HTTP/1.1 recipients |
| SHOULD accept line folding and replace any embedded obs-fold |  | SHOULD accept line folding and replace any embedded obs-fold |
| skipping to change at page 24, line 13 |  | skipping to change at page 24, line 37 |
| ; OWS / <VCHAR except "(", ")", and "\"> / obs-text |  | ; OWS / <VCHAR except "(", ")", and "\"> / obs-text |
| The backslash octet ("\") can be used as a single-octet quoting |  | The backslash octet ("\") can be used as a single-octet quoting |
| mechanism within comment constructs: |  | mechanism within comment constructs: |
| quoted-cpair = "\" ( WSP / VCHAR / obs-text ) |  | quoted-cpair = "\" ( WSP / VCHAR / obs-text ) |
| Senders SHOULD NOT escape octets that do not require escaping (i.e., |  | Senders SHOULD NOT escape octets that do not require escaping (i.e., |
| other than the backslash octet "\" and the parentheses "(" and ")"). |  | other than the backslash octet "\" and the parentheses "(" and ")"). |
|  |  | HTTP does not place a pre-defined limit on the length of header |
|  |  | fields, either in isolation or as a set. A server MUST be prepared |
|  |  | to receive request header fields of unbounded length and respond with |
|  |  | a 4xx status code if the received header field(s) would be longer |
|  |  | than the server wishes to handle. |
|  |  | A client that receives response headers that are longer than it |
|  |  | wishes to handle can only treat it as a server error. |
|  |  | Various ad-hoc limitations on header length are found in practice. |
|  |  | It is RECOMMENDED that all HTTP senders and recipients support |
|  |  | messages whose combined header fields have 4000 or more octets. |
| 3.3. Message Body |  | 3.3. Message Body |
| The message-body (if any) of an HTTP message is used to carry the |  | The message-body (if any) of an HTTP message is used to carry the |
| payload body associated with the request or response. |  | payload body associated with the request or response. |
| message-body = *OCTET |  | message-body = *OCTET |
| The message-body differs from the payload body only when a transfer- |  | The message-body differs from the payload body only when a transfer- |
| coding has been applied, as indicated by the Transfer-Encoding header |  | coding has been applied, as indicated by the Transfer-Encoding header |
| field (Section 9.7). If more than one Transfer-Encoding header field |  | field (Section 9.7). If more than one Transfer-Encoding header field |
| skipping to change at page 30, line 17 |  | skipping to change at page 31, line 13 |
| OPTIONS http://www.example.org:8001 HTTP/1.1 |  | OPTIONS http://www.example.org:8001 HTTP/1.1 |
| would be forwarded by the final proxy as |  | would be forwarded by the final proxy as |
| OPTIONS * HTTP/1.1 |  | OPTIONS * HTTP/1.1 |
| Host: www.example.org:8001 |  | Host: www.example.org:8001 |
| after connecting to port 8001 of host "www.example.org". |  | after connecting to port 8001 of host "www.example.org". |
| The request-target is transmitted in the format specified in |  | The request-target is transmitted in the format specified in |
| Section 2.6.1. If the request-target is percent-encoded ([RFC3986], |  | Section 2.7.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 non-transforming proxy MUST NOT rewrite the "path-absolute" part of |  | A non-transforming proxy MUST NOT rewrite the "path-absolute" part of |
| the received request-target when forwarding it to the next inbound |  | the 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 "*". |  | "/" or "*". |
| Note: The "no rewrite" rule prevents the proxy from changing the |  | Note: The "no rewrite" rule prevents the proxy from changing the |
| skipping to change at page 32, line 37 |  | skipping to change at page 33, line 35 |
| Example 2: the effective request URI for the message |  | Example 2: the effective request URI for the message |
| GET * HTTP/1.1 |  | GET * HTTP/1.1 |
| Host: www.example.org |  | Host: www.example.org |
| (received over an SSL/TLS secured TCP connection) is "https", plus |  | (received over an SSL/TLS secured TCP connection) is "https", plus |
| "://", plus the authority component "www.example.org", thus |  | "://", plus the authority component "www.example.org", thus |
| "https://www.example.org". |  | "https://www.example.org". |
| Effective request URIs are compared using the rules described in |  | Effective request URIs are compared using the rules described in |
| Section 2.6.3, except that empty path components MUST NOT be treated |  | Section 2.7.3, except that empty path components MUST NOT be treated |
| as equivalent to an absolute path of "/". |  | 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 |
| *( header-field CRLF ) ; Section 3.2 |  | *( header-field CRLF ) ; Section 3.2 |
| CRLF |  | CRLF |
| skipping to change at page 55, line 14 |  | skipping to change at page 56, line 14 |
| 9.4. Host |  | 9.4. Host |
| The "Host" header field in a request provides the host and port |  | The "Host" header field in a request provides the host and port |
| information from the target resource's URI, enabling the origin |  | information from the target resource's URI, enabling the origin |
| server to distinguish between resources while servicing requests for |  | server to distinguish between resources while servicing requests for |
| multiple host names on a single IP address. Since the Host field- |  | multiple host names on a single IP address. Since the Host field- |
| value is critical information for handling a request, it SHOULD be |  | value is critical information for handling a request, it SHOULD be |
| sent as the first header field following the Request-Line. |  | sent as the first header field following the Request-Line. |
| Host = uri-host [ ":" port ] ; Section 2.6.1 |  | Host = uri-host [ ":" port ] ; Section 2.7.1 |
| A client MUST send a Host header field in all HTTP/1.1 request |  | A client MUST send a Host header field in all HTTP/1.1 request |
| messages. If the target resource's URI includes an authority |  | messages. If the target resource's URI includes an authority |
| component, then the Host field-value MUST be identical to that |  | component, then the Host field-value MUST be identical to that |
| authority component after excluding any userinfo (Section 2.6.1). If |  | authority component after excluding any userinfo (Section 2.7.1). If |
| the authority component is missing or undefined for the target |  | the authority component is missing or undefined for the target |
| resource's URI, then the Host header field MUST be sent with an empty |  | resource's URI, then the Host header field MUST be sent with an empty |
| field-value. |  | field-value. |
| For example, a GET request to the origin server for |  | For example, a GET request to the origin server for |
| <http://www.example.org/pub/WWW/> would begin with: |  | <http://www.example.org/pub/WWW/> would begin with: |
| GET /pub/WWW/ HTTP/1.1 |  | GET /pub/WWW/ HTTP/1.1 |
| Host: www.example.org |  | Host: www.example.org |
| skipping to change at page 59, line 26 |  | skipping to change at page 60, line 26 |
| Servers MUST include the "Upgrade" header field in 101 (Switching |  | Servers MUST include the "Upgrade" header field in 101 (Switching |
| Protocols) responses to indicate which protocol(s) are being switched |  | Protocols) responses to indicate which protocol(s) are being switched |
| to, and MUST include it in 426 (Upgrade Required) responses to |  | to, and MUST include it in 426 (Upgrade Required) responses to |
| indicate acceptable protocols to upgrade to. Servers MAY include it |  | indicate acceptable protocols to upgrade to. Servers MAY include it |
| in any other response to indicate that they are willing to upgrade to |  | in any other response to indicate that they are willing to upgrade to |
| one of the specified protocols. |  | one of the specified protocols. |
| This specification only defines the protocol name "HTTP" for use by |  | This specification only defines the protocol name "HTTP" for use by |
| the family of Hypertext Transfer Protocols, as defined by the HTTP |  | the family of Hypertext Transfer Protocols, as defined by the HTTP |
| version rules of Section 2.5 and future updates to this |  | version rules of Section 2.6 and future updates to this |
| specification. Additional tokens can be registered with IANA using |  | specification. Additional tokens can be registered with IANA using |
| the registration procedure defined below. |  | the registration procedure defined below. |
| 9.8.1. Upgrade Token Registry |  | 9.8.1. Upgrade Token Registry |
| The HTTP Upgrade Token Registry defines the name space for product |  | The HTTP Upgrade Token Registry defines the name space for product |
| tokens used to identify protocols in the Upgrade header field. Each |  | tokens used to identify protocols in the Upgrade header field. Each |
| registered token is associated with contact information and an |  | registered token is associated with contact information and an |
| optional set of specifications that details how the connection will |  | optional set of specifications that details how the connection will |
| be processed after it has been upgraded. |  | be processed after it has been upgraded. |
| skipping to change at page 62, line 26 |  | skipping to change at page 63, line 26 |
| | Via | http | standard | Section 9.9 | |  | | Via | http | standard | Section 9.9 | |
| +-------------------+----------+----------+-------------+ |  | +-------------------+----------+----------+-------------+ |
| The change controller is: "IETF (iesg@ietf.org) - Internet |  | The change controller is: "IETF (iesg@ietf.org) - Internet |
| Engineering Task Force". |  | Engineering Task Force". |
| 10.2. URI Scheme Registration |  | 10.2. URI Scheme Registration |
| The entries for the "http" and "https" URI Schemes in the registry |  | The entries for the "http" and "https" URI Schemes in the registry |
| located at <http://www.iana.org/assignments/uri-schemes.html> shall |  | located at <http://www.iana.org/assignments/uri-schemes.html> shall |
| be updated to point to Sections 2.6.1 and 2.6.2 of this document (see |  | be updated to point to Sections 2.7.1 and 2.7.2 of this document (see |
| [RFC4395]). |  | [RFC4395]). |
| 10.3. Internet Media Type Registrations |  | 10.3. Internet Media Type Registrations |
| This document serves as the specification for the Internet media |  | This document serves as the specification for the Internet media |
| types "message/http" and "application/http". The following is to be |  | types "message/http" and "application/http". The following is to be |
| registered with IANA (see [RFC4288]). |  | registered with IANA (see [RFC4288]). |
| 10.3.1. Internet Media Type message/http |  | 10.3.1. Internet Media Type message/http |
| skipping to change at page 65, line 29 |  | skipping to change at page 66, line 29 |
| 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 |
| <http://www.iana.org/assignments/http-upgrade-tokens/> shall be |  | <http://www.iana.org/assignments/http-upgrade-tokens/> shall be |
| updated with the registration below: |  | updated with the registration below: |
| +-------+---------------------------+-------------------------------+ |  | +-------+---------------------------+-------------------------------+ |
| | Value | Description | Reference | |  | | Value | Description | Reference | |
| +-------+---------------------------+-------------------------------+ |  | +-------+---------------------------+-------------------------------+ |
| | HTTP | Hypertext Transfer | Section 2.5 of this | |  | | HTTP | Hypertext Transfer | Section 2.6 of this | |
| | | Protocol | specification | |  | | | Protocol | specification | |
| +-------+---------------------------+-------------------------------+ |  | +-------+---------------------------+-------------------------------+ |
| 11. Security Considerations |  | 11. Security Considerations |
| This section is meant to inform application developers, information |  | This section is meant to inform application developers, information |
| providers, and users of the security limitations in HTTP/1.1 as |  | providers, and users of the security limitations in HTTP/1.1 as |
| described by this document. The discussion does not include |  | described by this document. The discussion does not include |
| definitive solutions to the problems revealed, though it does make |  | definitive solutions to the problems revealed, though it does make |
| some suggestions for reducing security risks. |  | some suggestions for reducing security risks. |
| skipping to change at page 68, line 5 |  | skipping to change at page 69, line 5 |
| configuration options they provide to proxy operators (especially the |  | configuration options they provide to proxy operators (especially the |
| default configuration). |  | default configuration). |
| Users of a proxy need to be aware that proxies are no trustworthier |  | Users of a proxy need to be aware that proxies are no trustworthier |
| than the people who run them; HTTP itself cannot solve this problem. |  | than the people who run them; HTTP itself cannot solve this problem. |
| The judicious use of cryptography, when appropriate, might suffice to |  | The judicious use of cryptography, when appropriate, might suffice to |
| protect against a broad range of security and privacy attacks. Such |  | protect against a broad range of security and privacy attacks. Such |
| cryptography is beyond the scope of the HTTP/1.1 specification. |  | cryptography is beyond the scope of the HTTP/1.1 specification. |
| 11.6. Denial of Service Attacks on Proxies |  | 11.6. Protocol Element Size Overflows |
|  |  | Because HTTP uses mostly textual, character-delimited fields, |
|  |  | attackers can overflow buffers in implementations, and/or perform a |
|  |  | Denial of Service against implementations that accept fields with |
|  |  | unlimited lengths. |
|  |  | To promote interoperability, this specification makes specific |
|  |  | recommendations for size limits on request-targets (Section 4.1.2) |
|  |  | and blocks of header fields (Section 3.2). These are minimum |
|  |  | recommendations, chosen to be supportable even by implementations |
|  |  | with limited resources; it is expected that most implementations will |
|  |  | choose substantially higher limits. |
|  |  | This specification also provides a way for servers to reject messages |
|  |  | that have request-targets that are too long (Section 8.4.15 of |
|  |  | [Part2]) or request entities that are too large (Section 8.4 of |
|  |  | [Part2]). |
|  |  | Other fields (including but not limited to request methods, response |
|  |  | status phrases, header field-names, and body chunks) SHOULD be |
|  |  | limited by implementations carefully, so as to not impede |
|  |  | interoperability. |
|  |  | 11.7. Denial of Service Attacks on Proxies |
| They exist. They are hard to defend against. Research continues. |  | They exist. They are hard to defend against. Research continues. |
| Beware. |  | Beware. |
| 12. Acknowledgments |  | 12. Acknowledgments |
| HTTP has evolved considerably over the years. It has benefited from |  | HTTP has evolved considerably over the years. It has benefited from |
| a large and active developer community -- the many people who have |  | a large and active developer community -- the many people who have |
| participated on the www-talk mailing list -- and it is that community |  | participated on the www-talk mailing list -- and it is that community |
| which has been most responsible for the success of HTTP and of the |  | which has been most responsible for the success of HTTP and of the |
| skipping to change at page 69, line 17 |  | skipping to change at page 70, line 41 |
| 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] International Organization for |  | [ISO-8859-1] International Organization for Standardization, |
| Standardization, "Information |  | "Information technology -- 8-bit single-byte coded |
| technology -- 8-bit single-byte coded |  | graphic character sets -- Part 1: Latin alphabet No. |
| graphic character sets -- Part 1: |  | 1", ISO/IEC 8859-1:1998, 1998. |
| Latin alphabet No. 1", ISO/ |  |  |
| IEC 8859-1:1998, 1998. |  |  |
| [Part2] Fielding, R., Ed., Gettys, J., Mogul, |  | [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| J., Frystyk, H., Masinter, L., Leach, |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., |
| P., Berners-Lee, T., Lafon, Y., Ed., |  | Ed., and J. Reschke, Ed., "HTTP/1.1, part 2: Message |
| and J. Reschke, Ed., "HTTP/1.1, part |  | Semantics", draft-ietf-httpbis-p2-semantics-15 (work in |
| 2: Message Semantics", |  | progress), July 2011. |
| draft-ietf-httpbis-p2-semantics-14 |  |  |
| (work in progress), April 2011. |  |  |
| [Part3] Fielding, R., Ed., Gettys, J., Mogul, |  | [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| J., Frystyk, H., Masinter, L., Leach, |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., |
| P., Berners-Lee, T., Lafon, Y., Ed., |  | Ed., and J. Reschke, Ed., "HTTP/1.1, part 3: Message |
| and J. Reschke, Ed., "HTTP/1.1, part |  | Payload and Content Negotiation", |
| 3: Message Payload and Content |  | draft-ietf-httpbis-p3-payload-15 (work in progress), |
| Negotiation", |  | July 2011. |
| draft-ietf-httpbis-p3-payload-14 (work |  |  |
| in progress), April 2011. |  |  |
| [Part6] Fielding, R., Ed., Gettys, J., Mogul, |  | [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| J., Frystyk, H., Masinter, L., Leach, |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., |
| P., Berners-Lee, T., Lafon, Y., Ed., |  | Ed., Nottingham, M., Ed., and J. Reschke, Ed., |
| Nottingham, M., Ed., and J. Reschke, |  | "HTTP/1.1, part 6: Caching", |
| Ed., "HTTP/1.1, part 6: Caching", |  | draft-ietf-httpbis-p6-cache-15 (work in progress), |
| draft-ietf-httpbis-p6-cache-14 (work |  | July 2011. |
| in progress), April 2011. |  |  |
| [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB |  | [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data |
| Compressed Data Format Specification |  | Format Specification version 3.3", RFC 1950, May 1996. |
| version 3.3", RFC 1950, May 1996. |  |  |
| RFC 1950 is an Informational RFC, thus |  | RFC 1950 is an Informational RFC, thus it might be less |
| it might be less stable than this |  | stable than this specification. On the other hand, |
| specification. On the other hand, |  | this downward reference was present since the |
| this downward reference was present |  | publication of RFC 2068 in 1997 ([RFC2068]), therefore |
| since the publication of RFC 2068 in |  | it is unlikely to cause problems in practice. See also |
| 1997 ([RFC2068]), therefore it is |  | [BCP97]. |
| unlikely to cause problems in |  |  |
| practice. See also [BCP97]. |  |  |
| [RFC1951] Deutsch, P., "DEFLATE Compressed Data |  | [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format |
| Format Specification version 1.3", |  | Specification version 1.3", RFC 1951, May 1996. |
| RFC 1951, May 1996. |  |  |
| RFC 1951 is an Informational RFC, thus |  | RFC 1951 is an Informational RFC, thus it might be less |
| it might be less stable than this |  | stable than this specification. On the other hand, |
| specification. On the other hand, |  | this downward reference was present since the |
| this downward reference was present |  | publication of RFC 2068 in 1997 ([RFC2068]), therefore |
| since the publication of RFC 2068 in |  | it is unlikely to cause problems in practice. See also |
| 1997 ([RFC2068]), therefore it is |  | [BCP97]. |
| unlikely to cause problems in |  |  |
| practice. See also [BCP97]. |  |  |
| [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., |  | [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and |
| Deutsch, L., and G. Randers-Pehrson, |  | G. Randers-Pehrson, "GZIP file format specification |
| "GZIP file format specification |  | version 4.3", RFC 1952, May 1996. |
| version 4.3", RFC 1952, May 1996. |  |  |
| RFC 1952 is an Informational RFC, thus |  | RFC 1952 is an Informational RFC, thus it might be less |
| it might be less stable than this |  | stable than this specification. On the other hand, |
| specification. On the other hand, |  | this downward reference was present since the |
| this downward reference was present |  | publication of RFC 2068 in 1997 ([RFC2068]), therefore |
| since the publication of RFC 2068 in |  | it is unlikely to cause problems in practice. See also |
| 1997 ([RFC2068]), therefore it is |  | [BCP97]. |
| unlikely to cause problems in |  |  |
| practice. See also [BCP97]. |  |  |
| [RFC2119] Bradner, S., "Key words for use in |  | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |
| RFCs to Indicate Requirement Levels", |  | Requirement Levels", BCP 14, RFC 2119, March 1997. |
| BCP 14, RFC 2119, March 1997. |  |  |
| [RFC3986] Berners-Lee, T., Fielding, R., and L. |  | [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, |
| Masinter, "Uniform Resource Identifier |  | "Uniform Resource Identifier (URI): Generic Syntax", |
| (URI): Generic Syntax", STD 66, |  | STD 66, RFC 3986, January 2005. |
| RFC 3986, January 2005. |  |  |
| [RFC5234] Crocker, D., Ed. and P. Overell, |  | [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for |
| "Augmented BNF for Syntax |  | Syntax Specifications: ABNF", STD 68, RFC 5234, |
| Specifications: ABNF", STD 68, |  | January 2008. |
| RFC 5234, January 2008. |  |  |
| [USASCII] American National Standards Institute, |  | [USASCII] American National Standards Institute, "Coded Character |
| "Coded Character Set -- 7-bit American |  | Set -- 7-bit American Standard Code for Information |
| 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 |  | [BCP97] Klensin, J. and S. Hartman, "Handling Normative |
| Normative References to Standards- |  | References to Standards-Track Documents", BCP 97, |
| Track Documents", BCP 97, RFC 4897, |  | RFC 4897, June 2007. |
| June 2007. |  |  |
| [Kri2001] Kristol, D., "HTTP Cookies: Standards, |  | [Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and |
| Privacy, and Politics", ACM |  | Politics", ACM Transactions on Internet Technology Vol. |
| Transactions on Internet |  | 1, #2, November 2001, |
| Technology Vol. 1, #2, November 2001, |  | <http://arxiv.org/abs/cs.SE/0105018>. |
| <http://arxiv.org/abs/cs.SE/0105018>. |  |  |
| [Nie1997] Frystyk, H., Gettys, J., |  | [Nie1997] Frystyk, H., Gettys, J., Prud'hommeaux, E., Lie, H., |
| Prud'hommeaux, E., Lie, H., and C. |  | and C. Lilley, "Network Performance Effects of |
| Lilley, "Network Performance Effects |  | HTTP/1.1, CSS1, and PNG", ACM Proceedings of the ACM |
| of HTTP/1.1, CSS1, and PNG", |  | SIGCOMM '97 conference on Applications, technologies, |
| ACM Proceedings of the ACM SIGCOMM '97 |  | architectures, and protocols for computer communication |
| conference on Applications, |  | SIGCOMM '97, September 1997, |
| technologies, architectures, and |  | <http://doi.acm.org/10.1145/263105.263157>. |
| protocols for computer communication |  |  |
| SIGCOMM '97, September 1997, <http:// |  |  |
| doi.acm.org/10.1145/263105.263157>. |  |  |
| [Pad1995] Padmanabhan, V. and J. Mogul, |  | [Pad1995] Padmanabhan, V. and J. Mogul, "Improving HTTP Latency", |
| "Improving HTTP Latency", Computer |  | Computer Networks and ISDN Systems v. 28, pp. 25-35, |
| Networks and ISDN Systems v. 28, pp. |  | December 1995, |
| 25-35, December 1995, <http:// |  | <http://portal.acm.org/citation.cfm?id=219094>. |
| portal.acm.org/ |  |  |
| citation.cfm?id=219094>. |  |  |
| [RFC1123] Braden, R., "Requirements for Internet |  | [RFC1123] Braden, R., "Requirements for Internet Hosts - |
| Hosts - Application and Support", |  | Application and Support", STD 3, RFC 1123, |
| STD 3, RFC 1123, October 1989. |  | October 1989. |
| [RFC1900] Carpenter, B. and Y. Rekhter, |  | [RFC1900] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", |
| "Renumbering Needs Work", RFC 1900, |  | RFC 1900, February 1996. |
| February 1996. |  |  |
| [RFC1919] Chatel, M., "Classical versus |  | [RFC1919] Chatel, M., "Classical versus Transparent IP Proxies", |
| Transparent IP Proxies", RFC 1919, |  | RFC 1919, March 1996. |
| March 1996. |  |  |
| [RFC1945] Berners-Lee, T., Fielding, R., and H. |  | [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, |
| Nielsen, "Hypertext Transfer Protocol |  | "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, |
| -- HTTP/1.0", RFC 1945, May 1996. |  | May 1996. |
| [RFC2045] Freed, N. and N. Borenstein, |  | [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet |
| "Multipurpose Internet Mail Extensions |  | Mail Extensions (MIME) Part One: Format of Internet |
| (MIME) Part One: Format of Internet |  | Message Bodies", RFC 2045, November 1996. |
| Message Bodies", RFC 2045, |  |  |
| November 1996. |  |  |
| [RFC2047] Moore, K., "MIME (Multipurpose |  | [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail |
| Internet Mail Extensions) Part Three: |  | Extensions) Part Three: Message Header Extensions for |
| Message Header Extensions for Non- |  | Non-ASCII Text", RFC 2047, November 1996. |
| ASCII Text", RFC 2047, November 1996. |  |  |
| [RFC2068] Fielding, R., Gettys, J., Mogul, J., |  | [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and |
| Nielsen, H., and T. Berners-Lee, |  | T. Berners-Lee, "Hypertext Transfer Protocol -- |
| "Hypertext Transfer Protocol -- |  | HTTP/1.1", RFC 2068, January 1997. |
| HTTP/1.1", RFC 2068, January 1997. |  |  |
| [RFC2145] Mogul, J., Fielding, R., Gettys, J., |  | [RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, |
| and H. Nielsen, "Use and |  | "Use and Interpretation of HTTP Version Numbers", |
| Interpretation of HTTP Version |  | RFC 2145, May 1997. |
| Numbers", RFC 2145, May 1997. |  |  |
| [RFC2616] Fielding, R., Gettys, J., Mogul, J., |  | [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., |
| Frystyk, H., Masinter, L., Leach, P., |  | Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext |
| 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 |  | [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within |
| to TLS Within HTTP/1.1", RFC 2817, |  | HTTP/1.1", RFC 2817, May 2000. |
| May 2000. |  |  |
| [RFC2818] Rescorla, E., "HTTP Over TLS", |  | [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. |
| RFC 2818, May 2000. |  |  |
| [RFC2965] Kristol, D. and L. Montulli, "HTTP |  | [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management |
| State Management Mechanism", RFC 2965, |  | Mechanism", RFC 2965, October 2000. |
| October 2000. |  |  |
| [RFC3040] Cooper, I., Melve, I., and G. |  | [RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web |
| Tomlinson, "Internet Web Replication |  | Replication and Caching Taxonomy", RFC 3040, |
| and Caching Taxonomy", RFC 3040, |  | January 2001. |
| January 2001. |  |  |
| [RFC3864] Klyne, G., Nottingham, M., and J. |  | [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration |
| Mogul, "Registration Procedures for |  | Procedures for Message Header Fields", BCP 90, |
| Message Header Fields", BCP 90, |  | RFC 3864, September 2004. |
| RFC 3864, September 2004. |  |  |
| [RFC4288] Freed, N. and J. Klensin, "Media Type |  | [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications |
| Specifications and Registration |  | and Registration Procedures", BCP 13, RFC 4288, |
| Procedures", BCP 13, RFC 4288, |  | December 2005. |
| December 2005. |  |  |
| [RFC4395] Hansen, T., Hardie, T., and L. |  | [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines |
| Masinter, "Guidelines and Registration |  | and Registration Procedures for New URI Schemes", |
| Procedures for New URI Schemes", |  | BCP 115, RFC 4395, February 2006. |
| BCP 115, RFC 4395, February 2006. |  |  |
| [RFC5226] Narten, T. and H. Alvestrand, |  | [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based |
| "Guidelines for Writing an IANA |  | Kerberos and NTLM HTTP Authentication in Microsoft |
| Considerations Section in RFCs", |  | Windows", RFC 4559, June 2006. |
| BCP 26, RFC 5226, May 2008. |  |  |
| [RFC5322] Resnick, P., "Internet Message |  | [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing |
| Format", RFC 5322, October 2008. |  | an IANA Considerations Section in RFCs", BCP 26, |
|  |  | RFC 5226, May 2008. |
| [Spe] Spero, S., "Analysis of HTTP |  | [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, |
| Performance Problems", <http:// |  | October 2008. |
| sunsite.unc.edu/mdma-release/ |  |  |
| http-prob.html>. |  |  |
| [Tou1998] Touch, J., Heidemann, J., and K. |  | [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, |
| Obraczka, "Analysis of HTTP |  | April 2011. |
| Performance", ISI Research Report ISI/ |  |  |
| RR-98-463, Aug 1998, <http:// |  |  |
| www.isi.edu/touch/pubs/http-perf96/>. |  |  |
| (original report dated Aug. 1996) |  | [Spe] Spero, S., "Analysis of HTTP Performance Problems", |
|  |  | <http://sunsite.unc.edu/mdma-release/http-prob.html>. |
| [draft-ietf-httpstate-cookie] Barth, A., "HTTP State Management |  | [Tou1998] Touch, J., Heidemann, J., and K. Obraczka, "Analysis of |
| Mechanism", |  | HTTP Performance", ISI Research Report ISI/RR-98-463, |
| draft-ietf-httpstate-cookie-23 (work |  | Aug 1998, <http://www.isi.edu/touch/pubs/http-perf96/>. |
| in progress), March 2011. |  |  |
|  |  | (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. |
| The line terminator for header fields is the sequence CRLF. However, |  | The line terminator for header fields is the sequence CRLF. However, |
| skipping to change at page 76, line 49 |  | skipping to change at page 77, line 30 |
| (Section 1.2.1) |  | (Section 1.2.1) |
| Rules about implicit linear whitespace between certain grammar |  | Rules about implicit linear whitespace between certain grammar |
| productions have been removed; now it's only allowed when |  | productions have been removed; now it's only allowed when |
| specifically pointed out in the ABNF. The NUL octet is no longer |  | specifically pointed out in the ABNF. The NUL octet is no longer |
| allowed in comment and quoted-string text. The quoted-pair rule no |  | allowed in comment and quoted-string text. The quoted-pair rule no |
| longer allows escaping control characters other than HTAB. Non-ASCII |  | longer allows escaping control characters other than HTAB. Non-ASCII |
| content in header fields and reason phrase has been obsoleted and |  | content in header fields and reason phrase has been obsoleted and |
| made opaque (the TEXT rule was removed) (Section 1.2.2) |  | made opaque (the TEXT rule was removed) (Section 1.2.2) |
| Clarify that HTTP-Version is case sensitive. (Section 2.5) |  | Clarify that the string "HTTP" in the HTTP-Version ABFN production is |
|  |  | case sensitive. Restrict the version numbers to be single digits due |
|  |  | to the fact that implementations are known to handle multi-digit |
|  |  | version numbers incorrectly. (Section 2.6) |
| Require that invalid whitespace around field-names be rejected. |  | Require that invalid whitespace around field-names be rejected. |
| (Section 3.2) |  | (Section 3.2) |
| Require recipients to handle bogus Content-Length header fields as |  | Require recipients to handle bogus Content-Length header fields as |
| errors. (Section 3.3) |  | errors. (Section 3.3) |
| Remove reference to non-existent identity transfer-coding value |  | Remove reference to non-existent identity transfer-coding value |
| tokens. (Sections 3.3 and 6.2) |  | tokens. (Sections 3.3 and 6.2) |
| Update use of abs_path production from RFC 1808 to the path-absolute |  | Update use of abs_path production from RFC 1808 to the path-absolute |
| + query components of RFC 3986. State that the asterisk form is |  | + query components of RFC 3986. State that the asterisk form is |
| skipping to change at page 77, line 46 |  | skipping to change at page 78, line 29 |
| Chunked-Body = *chunk last-chunk trailer-part CRLF |  | Chunked-Body = *chunk last-chunk trailer-part CRLF |
| Connection = *( "," OWS ) connection-token *( OWS "," [ OWS |  | Connection = *( "," OWS ) connection-token *( OWS "," [ OWS |
| connection-token ] ) |  | connection-token ] ) |
| Content-Length = 1*DIGIT |  | Content-Length = 1*DIGIT |
| Date = HTTP-date |  | Date = HTTP-date |
| GMT = %x47.4D.54 ; GMT |  | GMT = %x47.4D.54 ; GMT |
| HTTP-Prot-Name = %x48.54.54.50 ; HTTP |  | HTTP-Prot-Name = %x48.54.54.50 ; HTTP |
| HTTP-Version = HTTP-Prot-Name "/" 1*DIGIT "." 1*DIGIT |  | HTTP-Version = HTTP-Prot-Name "/" DIGIT "." DIGIT |
| HTTP-date = rfc1123-date / obs-date |  | HTTP-date = rfc1123-date / obs-date |
| HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body |  | HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body |
| ] |  | ] |
| Host = uri-host [ ":" port ] |  | Host = uri-host [ ":" port ] |
| Method = token |  | Method = token |
| OWS = *( [ obs-fold ] WSP ) |  | OWS = *( [ obs-fold ] WSP ) |
| RWS = 1*( [ obs-fold ] WSP ) |  | RWS = 1*( [ obs-fold ] WSP ) |
| Reason-Phrase = *( WSP / VCHAR / obs-text ) |  | Reason-Phrase = *( WSP / VCHAR / obs-text ) |
| Request = Request-Line *( header-field CRLF ) CRLF [ message-body ] |  | Request = Request-Line *( header-field CRLF ) CRLF [ message-body ] |
| Request-Line = Method SP request-target SP HTTP-Version CRLF |  | Request-Line = Method SP request-target SP HTTP-Version CRLF |
| Response = Status-Line *( header-field CRLF ) CRLF [ message-body ] |  | Response = Status-Line *( header-field CRLF ) CRLF [ message-body ] |
| Status-Code = 3DIGIT |  | Status-Code = 3DIGIT |
| Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF |  | Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF |
| skipping to change at page 90, line 27 |  | skipping to change at page 91, line 24 |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/53>: "Allow is not |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/53>: "Allow is not |
| in 13.5.2" |  | in 13.5.2" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle |
| ABNFs for header fields" |  | ABNFs for header fields" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/286>: "Content- |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/286>: "Content- |
| Length ABNF broken" |  | Length ABNF broken" |
|  |  | D.16. Since draft-ietf-httpbis-p1-messaging-14 |
|  |  | Closed issues: |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/273>: "HTTP-Version |
|  |  | should be redefined as fixed length pair of DIGIT . DIGIT" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/282>: "Recommend |
|  |  | minimum sizes for protocol elements" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/283>: "Set |
|  |  | expectations around buffering" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/288>: "Considering |
|  |  | messages in isolation" |
| Index |  | Index |
| A |  | A |
| absolute-URI form (of request-target) 29 |  | absolute-URI form (of request-target) 29 |
| accelerator 13 |  | accelerator 14 |
| application/http Media Type 63 |  | application/http Media Type 64 |
| asterisk form (of request-target) 28 |  | asterisk form (of request-target) 29 |
| authority form (of request-target) 29 |  | authority form (of request-target) 30 |
| B |  | B |
| browser 10 |  | browser 10 |
| C |  | C |
| cache 14 |  | cache 15 |
| cacheable 14 |  | cacheable 15 |
| captive portal 14 |  | captive portal 14 |
| chunked (Coding Format) 37 |  | chunked (Coding Format) 38 |
| client 10 |  | client 10 |
| Coding Format |  | Coding Format |
| chunked 37 |  | chunked 38 |
| compress 40 |  | compress 41 |
| deflate 40 |  | deflate 41 |
| gzip 40 |  | gzip 41 |
| compress (Coding Format) 40 |  | compress (Coding Format) 41 |
| connection 10 |  | connection 10 |
| Connection header field 51 |  | Connection header field 52 |
| Content-Length header field 53 |  | Content-Length header field 54 |
| D |  | D |
| Date header field 53 |  | Date header field 54 |
| deflate (Coding Format) 40 |  | deflate (Coding Format) 41 |
| downstream 12 |  | downstream 13 |
| E |  | E |
| effective request URI 31 |  | effective request URI 32 |
| G |  | G |
| gateway 13 |  | gateway 14 |
| Grammar |  | Grammar |
| absolute-URI 17 |  | absolute-URI 18 |
| ALPHA 7 |  | ALPHA 7 |
| asctime-date 36 |  | asctime-date 37 |
| attribute 36 |  | attribute 37 |
| authority 17 |  | authority 18 |
| BWS 9 |  | BWS 9 |
| chunk 37 |  | chunk 38 |
| chunk-data 37 |  | chunk-data 38 |
| chunk-ext 37 |  | chunk-ext 38 |
| chunk-ext-name 37 |  | chunk-ext-name 38 |
| chunk-ext-val 37 |  | chunk-ext-val 38 |
| chunk-size 37 |  | chunk-size 38 |
| Chunked-Body 37 |  | Chunked-Body 38 |
| comment 23 |  | comment 24 |
| Connection 52 |  | Connection 53 |
| connection-token 52 |  | connection-token 53 |
| Content-Length 53 |  | Content-Length 54 |
| CR 7 |  | CR 7 |
| CRLF 7 |  | CRLF 7 |
| ctext 23 |  | ctext 24 |
| CTL 7 |  | CTL 7 |
| Date 53 |  | Date 54 |
| date1 35 |  | date1 36 |
| date2 36 |  | date2 37 |
| date3 36 |  | date3 37 |
| day 35 |  | day 36 |
| day-name 35 |  | day-name 36 |
| day-name-l 35 |  | day-name-l 36 |
| DIGIT 7 |  | DIGIT 7 |
| DQUOTE 7 |  | DQUOTE 7 |
| field-content 22 |  | field-content 23 |
| field-name 22 |  | field-name 23 |
| field-value 22 |  | field-value 23 |
| GMT 35 |  | GMT 36 |
| header-field 22 |  | header-field 23 |
| HEXDIG 7 |  | HEXDIG 7 |
| Host 55 |  | Host 56 |
| hour 35 |  | hour 36 |
| HTTP-date 34 |  | HTTP-date 35 |
| HTTP-message 21 |  | HTTP-message 21 |
| HTTP-Prot-Name 15 |  | HTTP-Prot-Name 16 |
| http-URI 18 |  | http-URI 18 |
| HTTP-Version 15 |  | HTTP-Version 16 |
| https-URI 19 |  | https-URI 20 |
| last-chunk 37 |  | last-chunk 38 |
| LF 7 |  | LF 7 |
| message-body 24 |  | message-body 25 |
| Method 28 |  | Method 29 |
| minute 35 |  | minute 36 |
| month 35 |  | month 36 |
| obs-date 35 |  | obs-date 36 |
| obs-text 10 |  | obs-text 10 |
| OCTET 7 |  | OCTET 7 |
| OWS 9 |  | OWS 9 |
| path-absolute 17 |  | path-absolute 18 |
| port 17 |  | port 18 |
| product 41 |  | product 42 |
| product-version 41 |  | product-version 42 |
| protocol-name 60 |  | protocol-name 61 |
| protocol-version 60 |  | protocol-version 61 |
| pseudonym 60 |  | pseudonym 61 |
| qdtext 10 |  | qdtext 10 |
| qdtext-nf 37 |  | qdtext-nf 38 |
| query 17 |  | query 18 |
| quoted-cpair 24 |  | quoted-cpair 24 |
| quoted-pair 10 |  | quoted-pair 10 |
| quoted-str-nf 37 |  | quoted-str-nf 38 |
| quoted-string 10 |  | quoted-string 10 |
| qvalue 41 |  | qvalue 42 |
| Reason-Phrase 33 |  | Reason-Phrase 34 |
| received-by 60 |  | received-by 61 |
| received-protocol 60 |  | received-protocol 61 |
| Request 28 |  | Request 29 |
| Request-Line 28 |  | Request-Line 29 |
| request-target 28 |  | request-target 29 |
| Response 32 |  | Response 33 |
| rfc850-date 36 |  | rfc850-date 37 |
| rfc1123-date 35 |  | rfc1123-date 36 |
| RWS 9 |  | RWS 9 |
| second 35 |  | second 36 |
| SP 7 |  | SP 7 |
| special 9 |  | special 9 |
| Status-Code 33 |  | Status-Code 34 |
| Status-Line 33 |  | Status-Line 34 |
| t-codings 56 |  | t-codings 57 |
| tchar 9 |  | tchar 9 |
| TE 56 |  | TE 57 |
| te-ext 56 |  | te-ext 57 |
| te-params 56 |  | te-params 57 |
| time-of-day 35 |  | time-of-day 36 |
| token 9 |  | token 9 |
| Trailer 57 |  | Trailer 58 |
| trailer-part 37 |  | trailer-part 38 |
| transfer-coding 36 |  | transfer-coding 37 |
| Transfer-Encoding 58 |  | Transfer-Encoding 59 |
| transfer-extension 36 |  | transfer-extension 37 |
| transfer-parameter 36 |  | transfer-parameter 37 |
| Upgrade 58 |  | Upgrade 59 |
| uri-host 17 |  | uri-host 18 |
| URI-reference 17 |  | URI-reference 18 |
| value 36 |  | value 37 |
| VCHAR 7 |  | VCHAR 7 |
| Via 60 |  | Via 61 |
| word 9 |  | word 9 |
| WSP 7 |  | WSP 7 |
| year 35 |  | year 36 |
| gzip (Coding Format) 40 |  | gzip (Coding Format) 41 |
| H |  | H |
| header field 20 |  | header field 21 |
| Header Fields |  | Header Fields |
| Connection 51 |  | Connection 52 |
| Content-Length 53 |  | Content-Length 54 |
| Date 53 |  | Date 54 |
| Host 55 |  | Host 56 |
| TE 56 |  | TE 57 |
| Trailer 57 |  | Trailer 58 |
| Transfer-Encoding 57 |  | Transfer-Encoding 58 |
| Upgrade 58 |  | Upgrade 59 |
| Via 60 |  | Via 61 |
| header section 20 |  | header section 21 |
| headers 20 |  | headers 21 |
| Host header field 55 |  | Host header field 56 |
| http URI scheme 18 |  | http URI scheme 18 |
| https URI scheme 19 |  | https URI scheme 20 |
| I |  | I |
| inbound 12 |  | inbound 13 |
| interception proxy 14 |  | interception proxy 14 |
| intermediary 12 |  | intermediary 13 |
| M |  | M |
| Media Type |  | Media Type |
| application/http 63 |  | application/http 64 |
| message/http 62 |  | message/http 63 |
| message 11 |  | message 11 |
| message/http Media Type 62 |  | message/http Media Type 63 |
| N |  | N |
| non-transforming proxy 13 |  | non-transforming proxy 13 |
| O |  | O |
| origin form (of request-target) 29 |  | origin form (of request-target) 30 |
| origin server 10 |  | origin server 10 |
| outbound 12 |  | outbound 13 |
| P |  | P |
| proxy 13 |  | proxy 13 |
| R |  | R |
| recipient 10 |  | recipient 10 |
| request 11 |  | request 11 |
| resource 17 |  | resource 18 |
| response 11 |  | response 11 |
| reverse proxy 13 |  | reverse proxy 14 |
| S |  | S |
| sender 10 |  | sender 10 |
| server 10 |  | server 10 |
| spider 10 |  | spider 10 |
| T |  | T |
| target resource 31 |  | target resource 32 |
| TE header field 56 |  | TE header field 57 |
| Trailer header field 57 |  | Trailer header field 58 |
| Transfer-Encoding header field 57 |  | Transfer-Encoding header field 58 |
| transforming proxy 13 |  | transforming proxy 13 |
| transparent proxy 14 |  | transparent proxy 14 |
| tunnel 14 |  | tunnel 14 |
| U |  | U |
| Upgrade header field 58 |  | Upgrade header field 59 |
| upstream 12 |  | upstream 13 |
| URI scheme |  | URI scheme |
| http 18 |  | http 18 |
| https 19 |  | https 20 |
| user agent 10 |  | user agent 10 |
| V |  | V |
| Via header field 60 |  | Via header field 61 |
| Authors' Addresses |  | Authors' Addresses |
| Roy T. Fielding (editor) |  | Roy T. Fielding (editor) |
| Adobe Systems Incorporated |  | Adobe Systems Incorporated |
| 345 Park Ave |  | 345 Park Ave |
| San Jose, CA 95110 |  | San Jose, CA 95110 |
| USA |  | USA |
| EMail: fielding@gbiv.com |  | EMail: fielding@gbiv.com |
End of changes. 123 change blocks.
| 458 lines changed or deleted |  | 493 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/