| draft-ietf-httpbis-p1-messaging-15.txt |  | draft-ietf-httpbis-p1-messaging-16.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: January 12, 2012 HP |  | Expires: February 25, 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 |
| July 11, 2011 |  | August 24, 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-15 |  | draft-ietf-httpbis-p1-messaging-16 |
| 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 and moves it to |
| an overview of HTTP and its associated terminology, defines the |  | historic status, along with its predecessor RFC 2068. |
| "http" and "https" Uniform Resource Identifier (URI) schemes, defines |  |  |
| the generic message syntax and parsing requirements for HTTP message |  | Part 1 provides an overview of HTTP and its associated terminology, |
| frames, and describes general security concerns for implementations. |  | defines the "http" and "https" Uniform Resource Identifier (URI) |
|  |  | schemes, defines the generic message syntax and parsing requirements |
|  |  | for HTTP message frames, and describes general security concerns for |
|  |  | implementations. |
|  |  | This part also obsoletes RFCs 2145 (on HTTP version numbers) and 2817 |
|  |  | (on using CONNECT for TLS upgrades) and moves them to historic |
|  |  | status. |
| Editorial Note (To be removed by RFC Editor) |  | Editorial Note (To be removed by RFC Editor) |
| Discussion of this draft should take place on the HTTPBIS working |  | Discussion of this draft should take place on the HTTPBIS working |
| group mailing list (ietf-http-wg@w3.org), 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.16. |  | The changes in this draft are summarized in Appendix C.17. |
| 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 January 12, 2012. |  | This Internet-Draft will expire on February 25, 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 4 |  | skipping to change at page 3, line 10 |
| material may not have granted the IETF Trust the right to allow |  | material may not have granted the IETF Trust the right to allow |
| modifications of such material outside the IETF Standards Process. |  | modifications of such material outside the IETF Standards Process. |
| Without obtaining an adequate license from the person(s) controlling |  | Without obtaining an adequate license from the person(s) controlling |
| the copyright in such materials, this document may not be modified |  | the copyright in such materials, this document may not be modified |
| outside the IETF Standards Process, and derivative works of it may |  | outside the IETF Standards Process, and derivative works of it may |
| not be created outside the IETF Standards Process, except to format |  | not be created outside the IETF Standards Process, except to format |
| it for publication as an RFC or to translate it into languages other |  | it for publication as an RFC or to translate it into languages other |
| 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 . . . . . . . . . . . . . . . . . . 9 |
| 2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 10 |  | 2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 9 |
| 2.2. Message Orientation and Buffering . . . . . . . . . . . . 12 |  | 2.2. Message Orientation and Buffering . . . . . . . . . . . . 11 |
| 2.3. Connections and Transport Independence . . . . . . . . . . 12 |  | 2.3. Connections and Transport Independence . . . . . . . . . . 11 |
| 2.4. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 13 |  | 2.4. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 12 |
| 2.5. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 15 |  | 2.5. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 14 |
| 2.6. Protocol Versioning . . . . . . . . . . . . . . . . . . . 15 |  | 2.6. Protocol Versioning . . . . . . . . . . . . . . . . . . . 15 |
| 2.7. Uniform Resource Identifiers . . . . . . . . . . . . . . . 18 |  | 2.7. Uniform Resource Identifiers . . . . . . . . . . . . . . . 17 |
| 2.7.1. http URI scheme . . . . . . . . . . . . . . . . . . . 18 |  | 2.7.1. http URI scheme . . . . . . . . . . . . . . . . . . . 18 |
| 2.7.2. https URI scheme . . . . . . . . . . . . . . . . . . . 20 |  | 2.7.2. https URI scheme . . . . . . . . . . . . . . . . . . . 19 |
| 2.7.3. http and https URI Normalization and Comparison . . . 20 |  | 2.7.3. http and https URI Normalization and Comparison . . . 20 |
| 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 21 |  | 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 20 |
| 3.1. Message Parsing Robustness . . . . . . . . . . . . . . . . 22 |  | 3.1. Message Parsing and Robustness . . . . . . . . . . . . . . 21 |
| 3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 22 |  | 3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 22 |
|  |  | 3.2.1. Field Parsing . . . . . . . . . . . . . . . . . . . . 23 |
|  |  | 3.2.2. Field Length . . . . . . . . . . . . . . . . . . . . . 24 |
|  |  | 3.2.3. Common Field ABNF Rules . . . . . . . . . . . . . . . 24 |
| 3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 25 |  | 3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 25 |
| 3.4. General Header Fields . . . . . . . . . . . . . . . . . . 28 |  | 3.4. Incomplete Messages . . . . . . . . . . . . . . . . . . . 28 |
| 4. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 |  | 3.5. General Header Fields . . . . . . . . . . . . . . . . . . 29 |
| 4.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 29 |  | 4. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 |
| 4.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 29 |  | 4.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 30 |
| 4.1.2. request-target . . . . . . . . . . . . . . . . . . . . 29 |  | 4.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 30 |
| 4.2. The Resource Identified by a Request . . . . . . . . . . . 31 |  | 4.1.2. request-target . . . . . . . . . . . . . . . . . . . . 30 |
| 4.3. Effective Request URI . . . . . . . . . . . . . . . . . . 32 |  | 4.2. The Resource Identified by a Request . . . . . . . . . . . 32 |
| 5. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 |  | 4.3. Effective Request URI . . . . . . . . . . . . . . . . . . 33 |
| 5.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 33 |  | 5. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 |
| 5.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 34 |  | 5.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 34 |
| 6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 34 |  | 5.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 35 |
| 6.1. Date/Time Formats: Full Date . . . . . . . . . . . . . . . 34 |  | 6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 35 |
| 6.2. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 37 |  | 6.1. Date/Time Formats: Full Date . . . . . . . . . . . . . . . 35 |
| 6.2.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 38 |  | 6.2. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 38 |
| 6.2.2. Compression Codings . . . . . . . . . . . . . . . . . 40 |  | 6.2.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 39 |
| 6.2.3. Transfer Coding Registry . . . . . . . . . . . . . . . 41 |  | 6.2.2. Compression Codings . . . . . . . . . . . . . . . . . 41 |
| 6.3. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 42 |  | 6.2.3. Transfer Coding Registry . . . . . . . . . . . . . . . 42 |
| 6.4. Quality Values . . . . . . . . . . . . . . . . . . . . . . 42 |  | 6.3. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 43 |
| 7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 42 |  | 6.4. Quality Values . . . . . . . . . . . . . . . . . . . . . . 43 |
| 7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 43 |  | 7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 43 |
| 7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 43 |  | 7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 44 |
| 7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 43 |  | 7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 44 |
| 7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 45 |  | 7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 44 |
| 7.1.4. Practical Considerations . . . . . . . . . . . . . . . 47 |  | 7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 46 |
| 7.2. Message Transmission Requirements . . . . . . . . . . . . 48 |  | 7.1.4. Practical Considerations . . . . . . . . . . . . . . . 48 |
| 7.2.1. Persistent Connections and Flow Control . . . . . . . 48 |  | 7.2. Message Transmission Requirements . . . . . . . . . . . . 49 |
| 7.2.2. Monitoring Connections for Error Status Messages . . . 49 |  | 7.2.1. Persistent Connections and Flow Control . . . . . . . 49 |
| 7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 49 |  | 7.2.2. Monitoring Connections for Error Status Messages . . . 50 |
|  |  | 7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 50 |
| 7.2.4. Client Behavior if Server Prematurely Closes |  | 7.2.4. Client Behavior if Server Prematurely Closes |
| Connection . . . . . . . . . . . . . . . . . . . . . . 51 |  | Connection . . . . . . . . . . . . . . . . . . . . . . 52 |
| 8. Miscellaneous notes that might disappear . . . . . . . . . . . 52 |  | 8. Miscellaneous notes that might disappear . . . . . . . . . . . 53 |
| 8.1. Scheme aliases considered harmful . . . . . . . . . . . . 52 |  | 8.1. Scheme aliases considered harmful . . . . . . . . . . . . 53 |
| 8.2. Use of HTTP for proxy communication . . . . . . . . . . . 52 |  | 8.2. Use of HTTP for proxy communication . . . . . . . . . . . 53 |
| 8.3. Interception of HTTP for access control . . . . . . . . . 52 |  | 8.3. Interception of HTTP for access control . . . . . . . . . 53 |
| 8.4. Use of HTTP by other protocols . . . . . . . . . . . . . . 52 |  | 8.4. Use of HTTP by other protocols . . . . . . . . . . . . . . 53 |
| 8.5. Use of HTTP by media type specification . . . . . . . . . 52 |  | 8.5. Use of HTTP by media type specification . . . . . . . . . 53 |
| 9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 52 |  | 9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 53 |
| 9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 52 |  | 9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 53 |
| 9.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 54 |  | 9.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 55 |
| 9.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 |  | 9.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 |
| 9.3.1. Clockless Origin Server Operation . . . . . . . . . . 55 |  | 9.3.1. Clockless Origin Server Operation . . . . . . . . . . 56 |
| 9.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 |  | 9.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 |
| 9.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 |  | 9.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 |
| 9.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 58 |  | 9.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 59 |
| 9.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 58 |  | 9.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 59 |
| 9.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 59 |  | 9.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 60 |
| 9.8.1. Upgrade Token Registry . . . . . . . . . . . . . . . . 60 |  | 9.8.1. Upgrade Token Registry . . . . . . . . . . . . . . . . 61 |
| 9.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 |  | 9.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 |
| 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 62 |  | 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 63 |
| 10.1. Header Field Registration . . . . . . . . . . . . . . . . 62 |  | 10.1. Header Field Registration . . . . . . . . . . . . . . . . 63 |
| 10.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 63 |  | 10.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 64 |
| 10.3. Internet Media Type Registrations . . . . . . . . . . . . 63 |  | 10.3. Internet Media Type Registrations . . . . . . . . . . . . 64 |
| 10.3.1. Internet Media Type message/http . . . . . . . . . . . 63 |  | 10.3.1. Internet Media Type message/http . . . . . . . . . . . 64 |
| 10.3.2. Internet Media Type application/http . . . . . . . . . 64 |  | 10.3.2. Internet Media Type application/http . . . . . . . . . 66 |
| 10.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 65 |  | 10.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 67 |
| 10.5. Upgrade Token Registration . . . . . . . . . . . . . . . . 66 |  | 10.5. Upgrade Token Registration . . . . . . . . . . . . . . . . 67 |
| 11. Security Considerations . . . . . . . . . . . . . . . . . . . 66 |  | 11. Security Considerations . . . . . . . . . . . . . . . . . . . 67 |
| 11.1. Personal Information . . . . . . . . . . . . . . . . . . . 66 |  | 11.1. Personal Information . . . . . . . . . . . . . . . . . . . 68 |
| 11.2. Abuse of Server Log Information . . . . . . . . . . . . . 67 |  | 11.2. Abuse of Server Log Information . . . . . . . . . . . . . 68 |
| 11.3. Attacks Based On File and Path Names . . . . . . . . . . . 67 |  | 11.3. Attacks Based On File and Path Names . . . . . . . . . . . 68 |
| 11.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 67 |  | 11.4. DNS-related Attacks . . . . . . . . . . . . . . . . . . . 68 |
| 11.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 68 |  | 11.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 69 |
| 11.6. Protocol Element Size Overflows . . . . . . . . . . . . . 69 |  | 11.6. Protocol Element Size Overflows . . . . . . . . . . . . . 69 |
| 11.7. Denial of Service Attacks on Proxies . . . . . . . . . . . 69 |  | 11.7. Denial of Service Attacks on Proxies . . . . . . . . . . . 70 |
| 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 69 |  | 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 70 |
| 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 70 |  | 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 70 |
| 13.1. Normative References . . . . . . . . . . . . . . . . . . . 70 |  | 13.1. Normative References . . . . . . . . . . . . . . . . . . . 70 |
| 13.2. Informative References . . . . . . . . . . . . . . . . . . 72 |  | 13.2. Informative References . . . . . . . . . . . . . . . . . . 72 |
| Appendix A. Tolerant Applications . . . . . . . . . . . . . . . . 74 |  | Appendix A. HTTP Version History . . . . . . . . . . . . . . . . 74 |
| Appendix B. HTTP Version History . . . . . . . . . . . . . . . . 75 |  | A.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 75 |
| B.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 76 |  | A.1.1. Multi-homed Web Servers . . . . . . . . . . . . . . . 75 |
| B.1.1. Multi-homed Web Servers . . . . . . . . . . . . . . . 76 |  | A.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 75 |
| B.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 76 |  | A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 76 |
| B.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 77 |  | Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 77 |
| Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 78 |  | Appendix C. Change Log (to be removed by RFC Editor before |
| Appendix D. Change Log (to be removed by RFC Editor before |  | publication) . . . . . . . . . . . . . . . . . . . . 81 |
| publication) . . . . . . . . . . . . . . . . . . . . 82 |  | C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 81 |
| D.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 82 |  | C.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 81 |
| D.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 82 |  | C.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 83 |
| D.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 84 |  | C.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 84 |
| D.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 85 |  | C.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 84 |
| D.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 85 |  | C.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 85 |
| D.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 86 |  | C.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 85 |
| D.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 86 |  | C.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 86 |
| D.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 87 |  | C.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 87 |
| D.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 88 |  | C.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 87 |
| D.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 88 |  | C.11. Since draft-ietf-httpbis-p1-messaging-09 . . . . . . . . . 88 |
| D.11. Since draft-ietf-httpbis-p1-messaging-09 . . . . . . . . . 89 |  | C.12. Since draft-ietf-httpbis-p1-messaging-10 . . . . . . . . . 88 |
| D.12. Since draft-ietf-httpbis-p1-messaging-10 . . . . . . . . . 89 |  | C.13. Since draft-ietf-httpbis-p1-messaging-11 . . . . . . . . . 89 |
| D.13. Since draft-ietf-httpbis-p1-messaging-11 . . . . . . . . . 90 |  | C.14. Since draft-ietf-httpbis-p1-messaging-12 . . . . . . . . . 89 |
| D.14. Since draft-ietf-httpbis-p1-messaging-12 . . . . . . . . . 90 |  | C.15. Since draft-ietf-httpbis-p1-messaging-13 . . . . . . . . . 90 |
| D.15. Since draft-ietf-httpbis-p1-messaging-13 . . . . . . . . . 91 |  | C.16. Since draft-ietf-httpbis-p1-messaging-14 . . . . . . . . . 90 |
| D.16. Since draft-ietf-httpbis-p1-messaging-14 . . . . . . . . . 91 |  | C.17. Since draft-ietf-httpbis-p1-messaging-15 . . . . . . . . . 90 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 |
| skipping to change at page 8, line 27 |  | skipping to change at page 8, line 27 |
| #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ] |  | #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ] |
| 1#element => *( "," OWS ) element *( OWS "," [ OWS element ] ) |  | 1#element => *( "," OWS ) element *( OWS "," [ OWS element ] ) |
| Note that empty elements do not contribute to the count of elements |  | Note that empty elements do not contribute to the count of elements |
| present, though. |  | present, though. |
| For example, given these ABNF productions: |  | For example, given these ABNF productions: |
| example-list = 1#example-list-elmt |  | example-list = 1#example-list-elmt |
| example-list-elmt = token ; see Section 1.2.2 |  | example-list-elmt = token ; see Section 3.2.3 |
| Then these are valid values for example-list (not including the |  | Then these are valid values for example-list (not including the |
| double quotes, which are present for delimitation only): |  | double quotes, which are present for delimitation only): |
| "foo,bar" |  | "foo,bar" |
| " foo ,bar," |  | " foo ,bar," |
| " foo , ,bar,charlie " |  | " foo , ,bar,charlie " |
| "foo ,bar, charlie " |  | "foo ,bar, charlie " |
| But these values would be invalid, as at least one non-empty element |  | But these values would be invalid, as at least one non-empty element |
| is required: |  | is required: |
| "" |  | "" |
| "," |  | "," |
| ", ," |  | ", ," |
| Appendix C shows the collected ABNF, with the list rules expanded as |  | Appendix B shows the collected ABNF, with the list rules expanded as |
| explained above. |  | explained above. |
| 1.2.2. Basic Rules |  | 1.2.2. Basic Rules |
| HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all |  |  |
| protocol elements other than the message-body (see Appendix A for |  |  |
| tolerant applications). |  |  |
| This specification uses three rules to denote the use of linear |  | This specification uses three rules to denote the use of linear |
| whitespace: OWS (optional whitespace), RWS (required whitespace), and |  | whitespace: OWS (optional whitespace), RWS (required whitespace), and |
| BWS ("bad" whitespace). |  | BWS ("bad" whitespace). |
| The OWS rule is used where zero or more linear whitespace octets |  | The OWS rule is used where zero or more linear whitespace octets |
| might appear. OWS SHOULD either not be produced or be produced as a |  | might appear. OWS SHOULD either not be produced or be produced as a |
| single SP. Multiple OWS octets that occur within field-content |  | single SP. Multiple OWS octets that occur within field-content |
| SHOULD be replaced with a single SP before interpreting the field |  | SHOULD either be replaced with a single SP or transformed to all SP |
| value or forwarding the message downstream. |  | octets (each WSP octet other than SP replaced with SP) before |
|  |  | interpreting the field value or forwarding the message downstream. |
| RWS is used when at least one linear whitespace octet is required to |  | RWS is used when at least one linear whitespace octet is required to |
| separate field tokens. RWS SHOULD be produced as a single SP. |  | separate field tokens. RWS SHOULD be produced as a single SP. |
| Multiple RWS octets that occur within field-content SHOULD be |  | Multiple RWS octets octets that occur within field-content SHOULD |
| replaced with a single SP before interpreting the field value or |  | either be replaced with a single SP or transformed to all SP octets |
| forwarding the message downstream. |  | (each WSP octet other than SP replaced with SP) before interpreting |
|  |  | the field value or forwarding the message downstream. |
| BWS is used where the grammar allows optional whitespace for |  | BWS is used where the grammar allows optional whitespace for |
| historical reasons but senders SHOULD NOT produce it in messages. |  | historical reasons but senders SHOULD NOT produce it in messages. |
| HTTP/1.1 recipients MUST accept such bad optional whitespace and |  | HTTP/1.1 recipients MUST accept such bad optional whitespace and |
| remove it before interpreting the field value or forwarding the |  | remove it before interpreting the field value or forwarding the |
| message downstream. |  | message downstream. |
| OWS = *( [ obs-fold ] WSP ) |  | OWS = *( [ obs-fold ] WSP ) |
| ; "optional" whitespace |  | ; "optional" whitespace |
| RWS = 1*( [ obs-fold ] WSP ) |  | RWS = 1*( [ obs-fold ] WSP ) |
| ; "required" whitespace |  | ; "required" whitespace |
| BWS = OWS |  | BWS = OWS |
| ; "bad" whitespace |  | ; "bad" whitespace |
| obs-fold = CRLF |  | obs-fold = CRLF |
| ; see Section 3.2 |  | ; see Section 3.2 |
| Many HTTP/1.1 header field values consist of words (token or quoted- |  |  |
| string) separated by whitespace or special characters. These special |  |  |
| characters MUST be in a quoted string to be used within a parameter |  |  |
| value (as defined in Section 6.2). |  |  |
| word = token / quoted-string |  |  |
| token = 1*tchar |  |  |
| tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" |  |  |
| / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" |  |  |
| / DIGIT / ALPHA |  |  |
| ; any VCHAR, except special |  |  |
| special = "(" / ")" / "<" / ">" / "@" / "," |  |  |
| / ";" / ":" / "\" / DQUOTE / "/" / "[" |  |  |
| / "]" / "?" / "=" / "{" / "}" |  |  |
| A string of text is parsed as a single word if it is quoted using |  |  |
| double-quote marks. |  |  |
| quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE |  |  |
| qdtext = OWS / %x21 / %x23-5B / %x5D-7E / obs-text |  |  |
| ; OWS / <VCHAR except DQUOTE and "\"> / obs-text |  |  |
| obs-text = %x80-FF |  |  |
| The backslash octet ("\") can be used as a single-octet quoting |  |  |
| mechanism within quoted-string constructs: |  |  |
| quoted-pair = "\" ( WSP / VCHAR / obs-text ) |  |  |
| Senders SHOULD NOT escape octets that do not require escaping (i.e., |  |  |
| other than DQUOTE and the backslash octet). |  |  |
| 2. HTTP-related architecture |  | 2. HTTP-related architecture |
| HTTP was created for the World Wide Web architecture and has evolved |  | HTTP was created for the World Wide Web architecture and has evolved |
| over time to support the scalability needs of a worldwide hypertext |  | over time to support the scalability needs of a worldwide hypertext |
| system. Much of that architecture is reflected in the terminology |  | system. Much of that architecture is reflected in the terminology |
| and syntax productions used to define HTTP. |  | and syntax productions used to define HTTP. |
| 2.1. Client/Server Messaging |  | 2.1. Client/Server Messaging |
| HTTP is a stateless request/response protocol that operates by |  | HTTP is a stateless request/response protocol that operates by |
| skipping to change at page 22, line 9 |  | skipping to change at page 21, line 20 |
| Implementations MUST NOT send whitespace between the start-line and |  | Implementations MUST NOT send whitespace between the start-line and |
| the first header field. The presence of such whitespace in a request |  | the first header field. The presence of such whitespace in a request |
| might be an attempt to trick a server into ignoring that field or |  | might be an attempt to trick a server into ignoring that field or |
| processing the line after it as a new request, either of which might |  | processing the line after it as a new request, either of which might |
| result in a security vulnerability if other implementations within |  | result in a security vulnerability if other implementations within |
| the request chain interpret the same message differently. Likewise, |  | the request chain interpret the same message differently. Likewise, |
| the presence of such whitespace in a response might be ignored by |  | the presence of such whitespace in a response might be ignored by |
| some clients or cause others to cease parsing. |  | some clients or cause others to cease parsing. |
| 3.1. Message Parsing Robustness |  | 3.1. Message Parsing and Robustness |
| In the interest of robustness, servers SHOULD ignore at least one |  |  |
| empty line received where a Request-Line is expected. In other |  |  |
| words, if the server is reading the protocol stream at the beginning |  |  |
| of a message and receives a CRLF first, it SHOULD ignore the CRLF. |  |  |
| Some old HTTP/1.0 client implementations send an extra CRLF after a |  |  |
| POST request as a lame workaround for some early server applications |  |  |
| that failed to read message-body content that was not terminated by a |  |  |
| line-ending. An HTTP/1.1 client MUST NOT preface or follow a request |  |  |
| with an extra CRLF. If terminating the request message-body with a |  |  |
| line-ending is desired, then the client MUST include the terminating |  |  |
| CRLF octets as part of the message-body length. |  |  |
| When a server listening only for HTTP request messages, or processing |  |  |
| what appears from the start-line to be an HTTP request message, |  |  |
| receives a sequence of octets that does not match the HTTP-message |  |  |
| grammar aside from the robustness exceptions listed above, the server |  |  |
| MUST respond with an HTTP/1.1 400 (Bad Request) response. |  |  |
| The normal procedure for parsing an HTTP message is to read the |  | The normal procedure for parsing an HTTP message is to read the |
| start-line into a structure, read each header field into a hash table |  | start-line into a structure, read each header field into a hash table |
| by field name until the empty line, and then use the parsed data to |  | by field name until the empty line, and then use the parsed data to |
| determine if a message-body is expected. If a message-body has been |  | determine if a message-body is expected. If a message-body has been |
| indicated, then it is read as a stream until an amount of octets |  | indicated, then it is read as a stream until an amount of octets |
| equal to the message-body length is read or the connection is closed. |  | equal to the message-body length is read or the connection is closed. |
| Care must be taken to parse an HTTP message as a sequence of octets |  | Care must be taken to parse an HTTP message as a sequence of octets |
| in an encoding that is a superset of US-ASCII. Attempting to parse |  | in an encoding that is a superset of US-ASCII. Attempting to parse |
| HTTP as a stream of Unicode characters in a character encoding like |  | HTTP as a stream of Unicode characters in a character encoding like |
| UTF-16 might introduce security flaws due to the differing ways that |  | UTF-16 might introduce security flaws due to the differing ways that |
| such parsers interpret invalid characters. |  | such parsers interpret invalid characters. |
| HTTP allows the set of defined header fields to be extended without |  | Older HTTP/1.0 client implementations might send an extra CRLF after |
| changing the protocol version (see Section 10.1). Unrecognized |  | a POST request as a lame workaround for some early server |
| header fields MUST be forwarded by a proxy unless the proxy is |  | applications that failed to read message-body content that was not |
| specifically configured to block or otherwise transform such fields. |  | terminated by a line-ending. An HTTP/1.1 client MUST NOT preface or |
| Unrecognized header fields SHOULD be ignored by other recipients. |  | follow a request with an extra CRLF. If terminating the request |
|  |  | message-body with a line-ending is desired, then the client MUST |
|  |  | include the terminating CRLF octets as part of the message-body |
|  |  | length. |
|  |  | In the interest of robustness, servers SHOULD ignore at least one |
|  |  | empty line received where a Request-Line is expected. In other |
|  |  | words, if the server is reading the protocol stream at the beginning |
|  |  | of a message and receives a CRLF first, it SHOULD ignore the CRLF. |
|  |  | Likewise, although the line terminator for the start-line and header |
|  |  | fields is the sequence CRLF, we recommend that recipients recognize a |
|  |  | single LF as a line terminator and ignore any CR. |
|  |  | When a server listening only for HTTP request messages, or processing |
|  |  | what appears from the start-line to be an HTTP request message, |
|  |  | receives a sequence of octets that does not match the HTTP-message |
|  |  | grammar aside from the robustness exceptions listed above, the server |
|  |  | MUST respond with an HTTP/1.1 400 (Bad Request) response. |
| 3.2. Header Fields |  | 3.2. Header Fields |
| Each HTTP header field consists of a case-insensitive field name |  | Each HTTP header field consists of a case-insensitive field name |
| followed by a colon (":"), optional whitespace, and the field value. |  | followed by a colon (":"), optional whitespace, and the field value. |
| header-field = field-name ":" OWS [ field-value ] OWS |  | header-field = field-name ":" OWS [ field-value ] OWS |
| field-name = token |  | field-name = token |
| field-value = *( field-content / OWS ) |  | field-value = *( field-content / OWS ) |
| field-content = *( WSP / VCHAR / obs-text ) |  | field-content = *( WSP / VCHAR / obs-text ) |
| No whitespace is allowed between the header field name and colon. |  | The field-name token labels the corresponding field-value as having |
| For security reasons, any request message received containing such |  | the semantics defined by that header field. For example, the Date |
| whitespace MUST be rejected with a response code of 400 (Bad |  | header field is defined in Section 9.3 as containing the origination |
| Request). A proxy MUST remove any such whitespace from a response |  | timestamp for the message in which it appears. |
| message before forwarding the message downstream. |  |  |
| A field value MAY be preceded by optional whitespace (OWS); a single |  | HTTP header fields are fully extensible: there is no limit on the |
| SP is preferred. The field value does not include any leading or |  | introduction of new field names, each presumably defining new |
| trailing white space: OWS occurring before the first non-whitespace |  | semantics, or on the number of header fields used in a given message. |
| octet of the field value or after the last non-whitespace octet of |  | Existing fields are defined in each part of this specification and in |
| the field value is ignored and SHOULD be removed before further |  | many other specifications outside the standards process. New header |
| processing (as this does not change the meaning of the header field). |  | fields can be introduced without changing the protocol version if |
|  |  | their defined semantics allow them to be safely ignored by recipients |
|  |  | that do not recognize them. |
|  |  | New HTTP header fields SHOULD be registered with IANA according to |
|  |  | the procedures in Section 10.1. Unrecognized header fields MUST be |
|  |  | forwarded by a proxy unless the field-name is listed in the |
|  |  | Connection header field (Section 9.1) or the proxy is specifically |
|  |  | configured to block or otherwise transform such fields. Unrecognized |
|  |  | header fields SHOULD be ignored by other recipients. |
| The order in which header fields with differing field names are |  | The order in which header fields with differing field names are |
| received is not significant. However, it is "good practice" to send |  | received is not significant. However, it is "good practice" to send |
| header fields that contain control data first, such as Host on |  | header fields that contain control data first, such as Host on |
| requests and Date on responses, so that implementations can decide |  | requests and Date on responses, so that implementations can decide |
| when not to handle a message as early as possible. A server MUST |  | when not to handle a message as early as possible. A server MUST |
| wait until the entire header section is received before interpreting |  | wait until the entire header section is received before interpreting |
| a request message, since later header fields might include |  | a request message, since later header fields might include |
| conditionals, authentication credentials, or deliberately misleading |  | conditionals, authentication credentials, or deliberately misleading |
| duplicate header fields that would impact request processing. |  | duplicate header fields that would impact request processing. |
| skipping to change at page 23, line 50 |  | skipping to change at page 23, line 19 |
| 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 ([RFC6265]). (See Appendix |  | cannot be combined into a single line ([RFC6265]). (See Appendix |
| A.2.3 of [Kri2001] for details.) Also note that the Set-Cookie2 |  | A.2.3 of [Kri2001] for details.) Also note that the Set-Cookie2 |
| header field specified in [RFC2965] does not share this problem. |  | header field specified in [RFC2965] does not share this problem. |
|  |  | 3.2.1. Field Parsing |
|  |  | No whitespace is allowed between the header field-name and colon. In |
|  |  | the past, differences in the handling of such whitespace have led to |
|  |  | security vulnerabilities in request routing and response handling. |
|  |  | Any received request message that contains whitespace between a |
|  |  | header field-name and colon MUST be rejected with a response code of |
|  |  | 400 (Bad Request). A proxy MUST remove any such whitespace from a |
|  |  | response message before forwarding the message downstream. |
|  |  | A field value MAY be preceded by optional whitespace (OWS); a single |
|  |  | SP is preferred. The field value does not include any leading or |
|  |  | trailing white space: OWS occurring before the first non-whitespace |
|  |  | octet of the field value or after the last non-whitespace octet of |
|  |  | the field value is ignored and SHOULD be removed before further |
|  |  | processing (as this does not change the meaning of the header field). |
| 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 senders MUST NOT produce messages that |
| that include line folding (i.e., that contain any field-content 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 recipients SHOULD |
| SHOULD accept line folding and replace any embedded obs-fold |  | accept line folding and replace any embedded obs-fold whitespace with |
| whitespace with a single SP prior to interpreting the field value or |  | either a single SP or a matching number of SP octets (to avoid buffer |
| forwarding the message downstream. |  | copying) prior to interpreting the field value or forwarding the |
|  |  | message downstream. |
| Historically, HTTP has allowed field content with text in the ISO- |  | Historically, HTTP has allowed field content with text in the ISO- |
| 8859-1 [ISO-8859-1] character encoding and supported other character |  | 8859-1 [ISO-8859-1] character encoding and supported other character |
| sets only through use of [RFC2047] encoding. In practice, most HTTP |  | sets only through use of [RFC2047] encoding. In practice, most HTTP |
| header field values use only a subset of the US-ASCII character |  | header field values use only a subset of the US-ASCII character |
| encoding [USASCII]. Newly defined header fields SHOULD limit their |  | encoding [USASCII]. Newly defined header fields SHOULD limit their |
| field values to US-ASCII octets. Recipients SHOULD treat other (obs- |  | field values to US-ASCII octets. Recipients SHOULD treat other (obs- |
| text) octets in field content as opaque data. |  | text) octets in field content as opaque data. |
| Comments can be included in some HTTP header fields by surrounding |  | 3.2.2. Field Length |
| the comment text with parentheses. Comments are only allowed in |  |  |
| fields containing "comment" as part of their field value definition. |  |  |
| comment = "(" *( ctext / quoted-cpair / comment ) ")" |  |  |
| ctext = OWS / %x21-27 / %x2A-5B / %x5D-7E / obs-text |  |  |
| ; OWS / <VCHAR except "(", ")", and "\"> / obs-text |  |  |
| The backslash octet ("\") can be used as a single-octet quoting |  |  |
| mechanism within comment constructs: |  |  |
| quoted-cpair = "\" ( WSP / VCHAR / obs-text ) |  |  |
| Senders SHOULD NOT escape octets that do not require escaping (i.e., |  |  |
| other than the backslash octet "\" and the parentheses "(" and ")"). |  |  |
| HTTP does not place a pre-defined limit on the length of header |  | 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 |  | fields, either in isolation or as a set. A server MUST be prepared |
| to receive request header fields of unbounded length and respond with |  | to receive request header fields of unbounded length and respond with |
| a 4xx status code if the received header field(s) would be longer |  | a 4xx status code if the received header field(s) would be longer |
| than the server wishes to handle. |  | than the server wishes to handle. |
| A client that receives response headers that are longer than it |  | A client that receives response headers that are longer than it |
| wishes to handle can only treat it as a server error. |  | wishes to handle can only treat it as a server error. |
| Various ad-hoc limitations on header length are found in practice. |  | Various ad-hoc limitations on header length are found in practice. |
| It is RECOMMENDED that all HTTP senders and recipients support |  | It is RECOMMENDED that all HTTP senders and recipients support |
| messages whose combined header fields have 4000 or more octets. |  | messages whose combined header fields have 4000 or more octets. |
|  |  | 3.2.3. Common Field ABNF Rules |
|  |  | Many HTTP/1.1 header field values consist of words (token or quoted- |
|  |  | string) separated by whitespace or special characters. These special |
|  |  | characters MUST be in a quoted string to be used within a parameter |
|  |  | value (as defined in Section 6.2). |
|  |  | word = token / quoted-string |
|  |  | token = 1*tchar |
|  |  | tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" |
|  |  | / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" |
|  |  | / DIGIT / ALPHA |
|  |  | ; any VCHAR, except special |
|  |  | special = "(" / ")" / "<" / ">" / "@" / "," |
|  |  | / ";" / ":" / "\" / DQUOTE / "/" / "[" |
|  |  | / "]" / "?" / "=" / "{" / "}" |
|  |  | A string of text is parsed as a single word if it is quoted using |
|  |  | double-quote marks. |
|  |  | quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE |
|  |  | qdtext = OWS / %x21 / %x23-5B / %x5D-7E / obs-text |
|  |  | obs-text = %x80-FF |
|  |  | The backslash octet ("\") can be used as a single-octet quoting |
|  |  | mechanism within quoted-string constructs: |
|  |  | quoted-pair = "\" ( WSP / VCHAR / obs-text ) |
|  |  | Recipients that process the value of the quoted-string MUST handle a |
|  |  | quoted-pair as if it were replaced by the octet following the |
|  |  | backslash. |
|  |  | Senders SHOULD NOT escape octets in quoted-strings that do not |
|  |  | require escaping (i.e., other than DQUOTE and the backslash octet). |
|  |  | Comments can be included in some HTTP header fields by surrounding |
|  |  | the comment text with parentheses. Comments are only allowed in |
|  |  | fields containing "comment" as part of their field value definition. |
|  |  | comment = "(" *( ctext / quoted-cpair / comment ) ")" |
|  |  | ctext = OWS / %x21-27 / %x2A-5B / %x5D-7E / obs-text |
|  |  | The backslash octet ("\") can be used as a single-octet quoting |
|  |  | mechanism within comment constructs: |
|  |  | quoted-cpair = "\" ( WSP / VCHAR / obs-text ) |
|  |  | Senders SHOULD NOT escape octets in comments that do not require |
|  |  | escaping (i.e., other than the backslash octet "\" and the |
|  |  | parentheses "(" and ")"). |
| 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 27, line 18 |  | skipping to change at page 27, line 45 |
| length in octets. If the actual number of octets sent in the |  | length in octets. If the actual number of octets sent in the |
| message is less than the indicated Content-Length, the recipient |  | message is less than the indicated Content-Length, the recipient |
| MUST consider the message to be incomplete and treat the |  | MUST consider the message to be incomplete and treat the |
| connection as no longer usable. If the actual number of octets |  | connection as no longer usable. If the actual number of octets |
| sent in the message is more than the indicated Content-Length, |  | sent in the message is more than the indicated Content-Length, |
| the recipient MUST only process the message-body up to the field |  | the recipient MUST only process the message-body up to the field |
| value's number of octets; the remainder of the message MUST |  | value's number of octets; the remainder of the message MUST |
| either be discarded or treated as the next message in a pipeline. |  | either be discarded or treated as the next message in a pipeline. |
| For the sake of robustness, a user-agent MAY attempt to detect |  | For the sake of robustness, a user-agent MAY attempt to detect |
| and correct such an error in message framing if it is parsing the |  | and correct such an error in message framing if it is parsing the |
| response to the last request on on a connection and the |  | response to the last request on a connection and the connection |
| connection has been closed by the server. |  | has been closed by the server. |
| 5. If this is a request message and none of the above are true, then |  | 5. If this is a request message and none of the above are true, then |
| the message-body length is zero (no message-body is present). |  | the message-body length is zero (no message-body is present). |
| 6. Otherwise, this is a response message without a declared message- |  | 6. Otherwise, this is a response message without a declared message- |
| body length, so the message-body length is determined by the |  | body length, so the message-body length is determined by the |
| number of octets received prior to the server closing the |  | number of octets received prior to the server closing the |
| connection. |  | connection. |
| Since there is no way to distinguish a successfully completed, close- |  | Since there is no way to distinguish a successfully completed, close- |
| skipping to change at page 28, line 7 |  | skipping to change at page 28, line 36 |
| requires a content-length in advance of being called and the server |  | requires a content-length in advance of being called and the server |
| is unable or unwilling to buffer the entire request before |  | is unable or unwilling to buffer the entire request before |
| processing. |  | processing. |
| A client that sends a request containing a message-body MUST include |  | A client that sends a request containing a message-body MUST include |
| a valid Content-Length header field if it does not know the server |  | a valid Content-Length header field if it does not know the server |
| will handle HTTP/1.1 (or later) requests; such knowledge can be in |  | will handle HTTP/1.1 (or later) requests; such knowledge can be in |
| the form of specific user configuration or by remembering the version |  | the form of specific user configuration or by remembering the version |
| of a prior received response. |  | of a prior received response. |
|  |  | 3.4. Incomplete Messages |
| Request messages that are prematurely terminated, possibly due to a |  | Request messages that are prematurely terminated, possibly due to a |
| cancelled connection or a server-imposed time-out exception, MUST |  | cancelled connection or a server-imposed time-out exception, MUST |
| result in closure of the connection; sending an HTTP/1.1 error |  | result in closure of the connection; sending an HTTP/1.1 error |
| response prior to closing the connection is OPTIONAL. Response |  | response prior to closing the connection is OPTIONAL. |
| messages that are prematurely terminated, usually by closure of the |  |  |
| connection prior to receiving the expected number of octets or by |  | Response messages that are prematurely terminated, usually by closure |
| failure to decode a transfer-encoded message-body, MUST be recorded |  | of the connection prior to receiving the expected number of octets or |
| as incomplete. A user agent MUST NOT render an incomplete response |  | by failure to decode a transfer-encoded message-body, MUST be |
| message-body as if it were complete (i.e., some indication must be |  | recorded as incomplete. A response that terminates in the middle of |
| given to the user that an error occurred). Cache requirements for |  | the header block (before the empty line is received) cannot be |
| incomplete responses are defined in Section 2.1.1 of [Part6]. |  | assumed to convey the full semantics of the response and MUST be |
|  |  | treated as an error. |
|  |  | A message-body that uses the chunked transfer encoding is incomplete |
|  |  | if the zero-sized chunk that terminates the encoding has not been |
|  |  | received. A message that uses a valid Content-Length is incomplete |
|  |  | if the size of the message-body received (in octets) is less than the |
|  |  | value given by Content-Length. A response that has neither chunked |
|  |  | transfer encoding nor Content-Length is terminated by closure of the |
|  |  | connection, and thus is considered complete regardless of the number |
|  |  | of message-body octets received, provided that the header block was |
|  |  | received intact. |
|  |  | A user agent MUST NOT render an incomplete response message-body as |
|  |  | if it were complete (i.e., some indication must be given to the user |
|  |  | that an error occurred). Cache requirements for incomplete responses |
|  |  | are defined in Section 2.1 of [Part6]. |
| A server MUST read the entire request message-body or close the |  | A server MUST read the entire request message-body or close the |
| connection after sending its response, since otherwise the remaining |  | connection after sending its response, since otherwise the remaining |
| data on a persistent connection would be misinterpreted as the next |  | data on a persistent connection would be misinterpreted as the next |
| request. Likewise, a client MUST read the entire response message- |  | request. Likewise, a client MUST read the entire response message- |
| body if it intends to reuse the same connection for a subsequent |  | body if it intends to reuse the same connection for a subsequent |
| request. Pipelining multiple requests on a connection is described |  | request. Pipelining multiple requests on a connection is described |
| in Section 7.1.2.2. |  | in Section 7.1.2.2. |
| 3.4. General Header Fields |  | 3.5. General Header Fields |
| There are a few header fields which have general applicability for |  | There are a few header fields which have general applicability for |
| both request and response messages, but which do not apply to the |  | both request and response messages, but which do not apply to the |
| payload being transferred. These header fields apply only to the |  | payload being transferred. These header fields apply only to the |
| message being transmitted. |  | message being transmitted. |
| +-------------------+---------------+ |  | +-------------------+---------------+ |
| | Header Field Name | Defined in... | |  | | Header Field Name | Defined in... | |
| +-------------------+---------------+ |  | +-------------------+---------------+ |
| | Connection | Section 9.1 | |  | | Connection | Section 9.1 | |
| skipping to change at page 31, line 51 |  | skipping to change at page 32, line 51 |
| request. |  | request. |
| 4.2. The Resource Identified by a Request |  | 4.2. The Resource Identified by a Request |
| The exact resource identified by an Internet request is determined by |  | The exact resource identified by an Internet request is determined by |
| examining both the request-target and the Host header field. |  | examining both the request-target and the Host header field. |
| An origin server that does not allow resources to differ by the |  | An origin server that does not allow resources to differ by the |
| requested host MAY ignore the Host header field value when |  | requested host MAY ignore the Host header field value when |
| determining the resource identified by an HTTP/1.1 request. (But see |  | determining the resource identified by an HTTP/1.1 request. (But see |
| Appendix B.1.1 for other requirements on Host support in HTTP/1.1.) |  | Appendix A.1.1 for other requirements on Host support in HTTP/1.1.) |
| An origin server that does differentiate resources based on the host |  | An origin server that does differentiate resources based on the host |
| requested (sometimes referred to as virtual hosts or vanity host |  | requested (sometimes referred to as virtual hosts or vanity host |
| names) MUST use the following rules for determining the requested |  | names) MUST use the following rules for determining the requested |
| resource on an HTTP/1.1 request: |  | resource on an HTTP/1.1 request: |
| 1. If request-target is an absolute-URI, the host is part of the |  | 1. If request-target is an absolute-URI, the host is part of the |
| request-target. Any Host header field value in the request MUST |  | request-target. Any Host header field value in the request MUST |
| be ignored. |  | be ignored. |
| 2. If the request-target is not an absolute-URI, and the request |  | 2. If the request-target is not an absolute-URI, and the request |
| skipping to change at page 33, line 27 |  | skipping to change at page 34, line 27 |
| GET /pub/WWW/TheProject.html HTTP/1.1 |  | GET /pub/WWW/TheProject.html HTTP/1.1 |
| Host: www.example.org:8080 |  | Host: www.example.org:8080 |
| (received over an insecure TCP connection) is "http", plus "://", |  | (received over an insecure TCP connection) is "http", plus "://", |
| plus the authority component "www.example.org:8080", plus the |  | plus the authority component "www.example.org:8080", plus the |
| request-target "/pub/WWW/TheProject.html", thus |  | request-target "/pub/WWW/TheProject.html", thus |
| "http://www.example.org:8080/pub/WWW/TheProject.html". |  | "http://www.example.org:8080/pub/WWW/TheProject.html". |
| Example 2: the effective request URI for the message |  | Example 2: the effective request URI for the message |
| GET * HTTP/1.1 |  | OPTIONS * 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.7.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 "/". |
| skipping to change at page 35, line 11 |  | skipping to change at page 36, line 11 |
| The other formats are described here only for compatibility with |  | The other formats are described here only for compatibility with |
| obsolete implementations. |  | obsolete implementations. |
| Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format |  | Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format |
| Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format |  | Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format |
| HTTP/1.1 clients and servers that parse a date value MUST accept all |  | HTTP/1.1 clients and servers that parse a date value MUST accept all |
| three formats (for compatibility with HTTP/1.0), though they MUST |  | three formats (for compatibility with HTTP/1.0), though they MUST |
| only generate the RFC 1123 format for representing HTTP-date values |  | only generate the RFC 1123 format for representing HTTP-date values |
| in header fields. See Appendix A for further information. |  | in header fields. |
| All HTTP date/time stamps MUST be represented in Greenwich Mean Time |  | All HTTP date/time stamps MUST be represented in Greenwich Mean Time |
| (GMT), without exception. For the purposes of HTTP, GMT is exactly |  | (GMT), without exception. For the purposes of HTTP, GMT is exactly |
| equal to UTC (Coordinated Universal Time). This is indicated in the |  | equal to UTC (Coordinated Universal Time). This is indicated in the |
| first two formats by the inclusion of "GMT" as the three-letter |  | first two formats by the inclusion of "GMT" as the three-letter |
| abbreviation for time zone, and MUST be assumed when reading the |  | abbreviation for time zone, and MUST be assumed when reading the |
| asctime format. HTTP-date is case sensitive and MUST NOT include |  | asctime format. HTTP-date is case sensitive and MUST NOT include |
| additional whitespace beyond that specifically included as SP in the |  | additional whitespace beyond that specifically included as SP in the |
| grammar. |  | grammar. |
| skipping to change at page 44, line 34 |  | skipping to change at page 45, line 34 |
| In case the client does not want to maintain a connection for more |  | In case the client does not want to maintain a connection for more |
| than that request, it SHOULD send a Connection header field including |  | than that request, it SHOULD send a Connection header field including |
| the connection-token close. |  | the connection-token close. |
| If either the client or the server sends the close token in the |  | If either the client or the server sends the close token in the |
| Connection header field, that request becomes the last one for the |  | Connection header field, that request becomes the last one for the |
| connection. |  | connection. |
| Clients and servers SHOULD NOT assume that a persistent connection is |  | Clients and servers SHOULD NOT assume that a persistent connection is |
| maintained for HTTP versions less than 1.1 unless it is explicitly |  | maintained for HTTP versions less than 1.1 unless it is explicitly |
| signaled. See Appendix B.1.2 for more information on backward |  | signaled. See Appendix A.1.2 for more information on backward |
| compatibility with HTTP/1.0 clients. |  | compatibility with HTTP/1.0 clients. |
| In order to remain persistent, all messages on the connection MUST |  | In order to remain persistent, all messages on the connection MUST |
| have a self-defined message length (i.e., one not defined by closure |  | have a self-defined message length (i.e., one not defined by closure |
| of the connection), as described in Section 3.3. |  | of the connection), as described in Section 3.3. |
| 7.1.2.2. Pipelining |  | 7.1.2.2. Pipelining |
| A client that supports persistent connections MAY "pipeline" its |  | A client that supports persistent connections MAY "pipeline" its |
| requests (i.e., send multiple requests without waiting for each |  | requests (i.e., send multiple requests without waiting for each |
| skipping to change at page 51, line 5 |  | skipping to change at page 52, line 5 |
| o If a proxy receives a request that includes an Expect header field |  | o If a proxy receives a request that includes an Expect header field |
| with the "100-continue" expectation, and the proxy either knows |  | with the "100-continue" expectation, and the proxy either knows |
| that the next-hop server complies with HTTP/1.1 or higher, or does |  | that the next-hop server complies with HTTP/1.1 or higher, or does |
| not know the HTTP version of the next-hop server, it MUST forward |  | not know the HTTP version of the next-hop server, it MUST forward |
| the request, including the Expect header field. |  | the request, including the Expect header field. |
| o If the proxy knows that the version of the next-hop server is |  | o If the proxy knows that the version of the next-hop server is |
| HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST |  | HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST |
| respond with a 417 (Expectation Failed) status code. |  | respond with a 417 (Expectation Failed) status code. |
| o Proxies SHOULD maintain a cache recording the HTTP version numbers |  | o Proxies SHOULD maintain a record of the HTTP version numbers |
| received from recently-referenced next-hop servers. |  | received from recently-referenced next-hop servers. |
| o A proxy MUST NOT forward a 100 (Continue) response if the request |  | o A proxy MUST NOT forward a 100 (Continue) response if the request |
| message was received from an HTTP/1.0 (or earlier) client and did |  | message was received from an HTTP/1.0 (or earlier) client and did |
| not include an Expect header field with the "100-continue" |  | not include an Expect header field with the "100-continue" |
| expectation. This requirement overrides the general rule for |  | expectation. This requirement overrides the general rule for |
| forwarding of 1xx responses (see Section 8.1 of [Part2]). |  | forwarding of 1xx responses (see Section 8.1 of [Part2]). |
| 7.2.4. Client Behavior if Server Prematurely Closes Connection |  | 7.2.4. Client Behavior if Server Prematurely Closes Connection |
| skipping to change at page 57, line 7 |  | skipping to change at page 58, line 7 |
| Host header field value for redirecting requests to internal servers, |  | Host header field value for redirecting requests to internal servers, |
| or for use as a cache key in a shared cache, without first verifying |  | or for use as a cache key in a shared cache, without first verifying |
| that the intercepted connection is targeting a valid IP address for |  | that the intercepted connection is targeting a valid IP address for |
| that host. |  | that host. |
| A server MUST respond with a 400 (Bad Request) status code to any |  | A server MUST respond with a 400 (Bad Request) status code to any |
| HTTP/1.1 request message that lacks a Host header field and to any |  | HTTP/1.1 request message that lacks a Host header field and to any |
| request message that contains more than one Host header field or a |  | request message that contains more than one Host header field or a |
| Host header field with an invalid field-value. |  | Host header field with an invalid field-value. |
| See Sections 4.2 and B.1.1 for other requirements relating to Host. |  | See Sections 4.2 and A.1.1 for other requirements relating to Host. |
| 9.5. TE |  | 9.5. TE |
| The "TE" header field indicates what extension transfer-codings it is |  | The "TE" header field indicates what extension transfer-codings it is |
| willing to accept in the response, and whether or not it is willing |  | willing to accept in the response, and whether or not it is willing |
| to accept trailer fields in a chunked transfer-coding. |  | to accept trailer fields in a chunked transfer-coding. |
| Its value consists of the keyword "trailers" and/or a comma-separated |  | Its value consists of the keyword "trailers" and/or a comma-separated |
| list of extension transfer-coding names with optional accept |  | list of extension transfer-coding names with optional accept |
| parameters (as described in Section 6.2). |  | parameters (as described in Section 6.2). |
| skipping to change at page 63, line 19 |  | skipping to change at page 64, line 19 |
| | Content-Length | http | standard | Section 9.2 | |  | | Content-Length | http | standard | Section 9.2 | |
| | Date | http | standard | Section 9.3 | |  | | Date | http | standard | Section 9.3 | |
| | Host | http | standard | Section 9.4 | |  | | Host | http | standard | Section 9.4 | |
| | TE | http | standard | Section 9.5 | |  | | TE | http | standard | Section 9.5 | |
| | Trailer | http | standard | Section 9.6 | |  | | Trailer | http | standard | Section 9.6 | |
| | Transfer-Encoding | http | standard | Section 9.7 | |  | | Transfer-Encoding | http | standard | Section 9.7 | |
| | Upgrade | http | standard | Section 9.8 | |  | | Upgrade | http | standard | Section 9.8 | |
| | Via | http | standard | Section 9.9 | |  | | Via | http | standard | Section 9.9 | |
| +-------------------+----------+----------+-------------+ |  | +-------------------+----------+----------+-------------+ |
|  |  | Furthermore, the header field name "Close" shall be registered as |
|  |  | "reserved", as its use as HTTP header field would be in conflict with |
|  |  | the use of the "close" connection option for the "Connection" header |
|  |  | field (Section 9.1). |
|  |  | +-------------------+----------+----------+--------------+ |
|  |  | | Header Field Name | Protocol | Status | Reference | |
|  |  | +-------------------+----------+----------+--------------+ |
|  |  | | Close | http | reserved | Section 10.1 | |
|  |  | +-------------------+----------+----------+--------------+ |
| 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.7.1 and 2.7.2 of this document (see |  | be updated to point to Sections 2.7.1 and 2.7.2 of this document (see |
| [RFC4395]). |  | [RFC4395]). |
| skipping to change at page 67, line 34 |  | skipping to change at page 68, line 47 |
| directory level above the current one. On such a system, an HTTP |  | directory level above the current one. On such a system, an HTTP |
| server MUST disallow any such construct in the request-target if it |  | server MUST disallow any such construct in the request-target if it |
| would otherwise allow access to a resource outside those intended to |  | would otherwise allow access to a resource outside those intended to |
| be accessible via the HTTP server. Similarly, files intended for |  | be accessible via the HTTP server. Similarly, files intended for |
| reference only internally to the server (such as access control |  | reference only internally to the server (such as access control |
| files, configuration files, and script code) MUST be protected from |  | files, configuration files, and script code) MUST be protected from |
| inappropriate retrieval, since they might contain sensitive |  | inappropriate retrieval, since they might contain sensitive |
| information. Experience has shown that minor bugs in such HTTP |  | information. Experience has shown that minor bugs in such HTTP |
| server implementations have turned into security risks. |  | server implementations have turned into security risks. |
| 11.4. DNS Spoofing |  | 11.4. DNS-related Attacks |
| Clients using HTTP rely heavily on the Domain Name Service, and are |  |  |
| thus generally prone to security attacks based on the deliberate mis- |  |  |
| association of IP addresses and DNS names. Clients need to be |  |  |
| cautious in assuming the continuing validity of an IP number/DNS name |  |  |
| association. |  |  |
| In particular, HTTP clients SHOULD rely on their name resolver for |  |  |
| confirmation of an IP number/DNS name association, rather than |  |  |
| caching the result of previous host name lookups. Many platforms |  |  |
| already can cache host name lookups locally when appropriate, and |  |  |
| they SHOULD be configured to do so. It is proper for these lookups |  |  |
| to be cached, however, only when the TTL (Time To Live) information |  |  |
| reported by the name server makes it likely that the cached |  |  |
| information will remain useful. |  |  |
| If HTTP clients cache the results of host name lookups in order to |  |  |
| achieve a performance improvement, they MUST observe the TTL |  |  |
| information reported by DNS. |  |  |
| If HTTP clients do not observe this rule, they could be spoofed when |  |  |
| a previously-accessed server's IP address changes. As network |  |  |
| renumbering is expected to become increasingly common [RFC1900], the |  |  |
| possibility of this form of attack will grow. Observing this |  |  |
| requirement thus reduces this potential security vulnerability. |  |  |
| This requirement also improves the load-balancing behavior of clients |  | HTTP clients rely heavily on the Domain Name Service (DNS), and are |
| for replicated servers using the same DNS name and reduces the |  | thus generally prone to security attacks based on the deliberate |
| likelihood of a user's experiencing failure in accessing sites which |  | misassociation of IP addresses and DNS names not protected by DNSSec. |
| use that strategy. |  | Clients need to be cautious in assuming the validity of an IP number/ |
|  |  | DNS name association unless the response is protected by DNSSec |
|  |  | ([RFC4033]). |
| 11.5. Proxies and Caching |  | 11.5. Proxies and Caching |
| By their very nature, HTTP proxies are men-in-the-middle, and |  | By their very nature, HTTP proxies are men-in-the-middle, and |
| represent an opportunity for man-in-the-middle attacks. Compromise |  | represent an opportunity for man-in-the-middle attacks. Compromise |
| of the systems on which the proxies run can result in serious |  | of the systems on which the proxies run can result in serious |
| security and privacy problems. Proxies have access to security- |  | security and privacy problems. Proxies have access to security- |
| related information, personal information about individual users and |  | related information, personal information about individual users and |
| organizations, and proprietary information belonging to users and |  | organizations, and proprietary information belonging to users and |
| content providers. A compromised proxy, or a proxy implemented or |  | content providers. A compromised proxy, or a proxy implemented or |
| skipping to change at page 69, line 36 |  | skipping to change at page 70, line 22 |
| limited by implementations carefully, so as to not impede |  | limited by implementations carefully, so as to not impede |
| interoperability. |  | interoperability. |
| 11.7. Denial of Service Attacks on Proxies |  | 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 |  | This document revision builds on the work that went into RFC 2616 and |
| a large and active developer community -- the many people who have |  | its predecessors. See Section 16 of [RFC2616] for detailed |
| participated on the www-talk mailing list -- and it is that community |  | acknowledgements. |
| which has been most responsible for the success of HTTP and of the |  |  |
| World-Wide Web in general. Marc Andreessen, Robert Cailliau, Daniel |  |  |
| W. Connolly, Bob Denny, John Franks, Jean-Francois Groff, Phillip M. |  |  |
| Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob McCool, Lou Montulli, |  |  |
| Dave Raggett, Tony Sanders, and Marc VanHeyningen deserve special |  |  |
| recognition for their efforts in defining early aspects of the |  |  |
| protocol. |  |  |
| This document has benefited greatly from the comments of all those |  |  |
| participating in the HTTP-WG. In addition to those already |  |  |
| mentioned, the following individuals have contributed to this |  |  |
| specification: |  |  |
| Gary Adams, Harald Tveit Alvestrand, Keith Ball, Brian Behlendorf, |  |  |
| Paul Burchard, Maurizio Codogno, Josh Cohen, Mike Cowlishaw, Roman |  |  |
| Czyborra, Michael A. Dolan, Daniel DuBois, David J. Fiander, Alan |  |  |
| Freier, Marc Hedlund, Greg Herlihy, Koen Holtman, Alex Hopmann, Bob |  |  |
| Jernigan, Shel Kaphan, Rohit Khare, John Klensin, Martijn Koster, |  |  |
| Alexei Kosut, David M. Kristol, Daniel LaLiberte, Ben Laurie, Paul J. |  |  |
| Leach, Albert Lunde, John C. Mallery, Jean-Philippe Martin-Flatin, |  |  |
| Mitra, David Morris, Gavin Nicol, Ross Patterson, Bill Perry, Jeffrey |  |  |
| Perry, Scott Powers, Owen Rees, Luigi Rizzo, David Robinson, Marc |  |  |
| Salomon, Rich Salz, Allan M. Schiffman, Jim Seidman, Chuck Shotton, |  |  |
| Eric W. Sink, Simon E. Spero, Richard N. Taylor, Robert S. Thau, Bill |  |  |
| (BearHeart) Weinman, Francois Yergeau, Mary Ellen Zurko. |  |  |
| Thanks to the "cave men" of Palo Alto. You know who you are. |  |  |
| Jim Gettys (the editor of [RFC2616]) wishes particularly to thank Roy |  |  |
| Fielding, the editor of [RFC2068], along with John Klensin, Jeff |  |  |
| Mogul, Paul Leach, Dave Kristol, Koen Holtman, John Franks, Josh |  |  |
| Cohen, Alex Hopmann, Scott Lawrence, and Larry Masinter for their |  |  |
| help. And thanks go particularly to Jeff Mogul and Scott Lawrence |  |  |
| for performing the "MUST/MAY/SHOULD" audit. |  |  |
| The Apache Group, Anselm Baird-Smith, author of Jigsaw, and Henrik |  |  |
| Frystyk implemented RFC 2068 early, and we wish to thank them for the |  |  |
| discovery of many of the problems that this document attempts to |  |  |
| rectify. |  |  |
| This specification makes heavy use of the augmented BNF and generic |  | [[todoacks: Insert HTTPbis-specific acknowledgements here.]] |
| constructs defined by David H. Crocker for [RFC5234]. Similarly, it |  |  |
| reuses many of the definitions provided by Nathaniel Borenstein and |  |  |
| Ned Freed for MIME [RFC2045]. We hope that their inclusion in this |  |  |
| specification will help reduce past confusion over the relationship |  |  |
| 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 Standardization, |  | [ISO-8859-1] International Organization for Standardization, |
| "Information technology -- 8-bit single-byte coded |  | "Information technology -- 8-bit single-byte coded |
| graphic character sets -- Part 1: Latin alphabet No. |  | graphic character sets -- Part 1: Latin alphabet No. |
| 1", ISO/IEC 8859-1:1998, 1998. |  | 1", ISO/IEC 8859-1:1998, 1998. |
| [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., |
| Ed., and J. Reschke, Ed., "HTTP/1.1, part 2: Message |  | Ed., and J. Reschke, Ed., "HTTP/1.1, part 2: Message |
| Semantics", draft-ietf-httpbis-p2-semantics-15 (work in |  | Semantics", draft-ietf-httpbis-p2-semantics-16 (work in |
| progress), July 2011. |  | progress), August 2011. |
| [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., |
| Ed., and J. Reschke, Ed., "HTTP/1.1, part 3: Message |  | Ed., and J. Reschke, Ed., "HTTP/1.1, part 3: Message |
| Payload and Content Negotiation", |  | Payload and Content Negotiation", |
| draft-ietf-httpbis-p3-payload-15 (work in progress), |  | draft-ietf-httpbis-p3-payload-16 (work in progress), |
| July 2011. |  | August 2011. |
| [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., |
| Ed., Nottingham, M., Ed., and J. Reschke, Ed., |  | Ed., Nottingham, M., Ed., and J. Reschke, Ed., |
| "HTTP/1.1, part 6: Caching", |  | "HTTP/1.1, part 6: Caching", |
| draft-ietf-httpbis-p6-cache-15 (work in progress), |  | draft-ietf-httpbis-p6-cache-16 (work in progress), |
| July 2011. |  | August 2011. |
| [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data |  | [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data |
| Format Specification version 3.3", RFC 1950, May 1996. |  | Format Specification version 3.3", RFC 1950, May 1996. |
| RFC 1950 is an Informational RFC, thus it might be less |  | RFC 1950 is an Informational RFC, thus it might be less |
| stable than this specification. On the other hand, |  | stable than this specification. On the other hand, |
| this downward reference was present since the |  | this downward reference was present since the |
| publication of RFC 2068 in 1997 ([RFC2068]), therefore |  | publication of RFC 2068 in 1997 ([RFC2068]), therefore |
| it is unlikely to cause problems in practice. See also |  | it is unlikely to cause problems in practice. See also |
| [BCP97]. |  | [BCP97]. |
| skipping to change at page 72, line 45 |  | skipping to change at page 72, line 34 |
| [Pad1995] Padmanabhan, V. and J. Mogul, "Improving HTTP Latency", |  | [Pad1995] Padmanabhan, V. and J. Mogul, "Improving HTTP Latency", |
| Computer Networks and ISDN Systems v. 28, pp. 25-35, |  | Computer Networks and ISDN Systems v. 28, pp. 25-35, |
| December 1995, |  | December 1995, |
| <http://portal.acm.org/citation.cfm?id=219094>. |  | <http://portal.acm.org/citation.cfm?id=219094>. |
| [RFC1123] Braden, R., "Requirements for Internet Hosts - |  | [RFC1123] Braden, R., "Requirements for Internet Hosts - |
| Application and Support", STD 3, RFC 1123, |  | Application and Support", STD 3, RFC 1123, |
| October 1989. |  | October 1989. |
| [RFC1900] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", |  |  |
| RFC 1900, February 1996. |  |  |
| [RFC1919] Chatel, M., "Classical versus Transparent IP Proxies", |  | [RFC1919] Chatel, M., "Classical versus Transparent IP Proxies", |
| RFC 1919, March 1996. |  | RFC 1919, March 1996. |
| [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, |  | [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, |
| "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, |  | "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, |
| May 1996. |  | May 1996. |
| [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet |  | [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet |
| Mail Extensions (MIME) Part One: Format of Internet |  | Mail Extensions (MIME) Part One: Format of Internet |
| Message Bodies", RFC 2045, November 1996. |  | Message Bodies", RFC 2045, November 1996. |
| skipping to change at page 73, line 42 |  | skipping to change at page 73, line 29 |
| Mechanism", RFC 2965, October 2000. |  | Mechanism", RFC 2965, October 2000. |
| [RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web |  | [RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web |
| Replication and Caching Taxonomy", RFC 3040, |  | Replication and Caching Taxonomy", RFC 3040, |
| January 2001. |  | January 2001. |
| [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration |  | [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration |
| Procedures for Message Header Fields", BCP 90, |  | Procedures for Message Header Fields", BCP 90, |
| RFC 3864, September 2004. |  | RFC 3864, September 2004. |
|  |  | [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. |
|  |  | Rose, "DNS Security Introduction and Requirements", |
|  |  | RFC 4033, March 2005. |
| [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications |  | [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications |
| and Registration Procedures", BCP 13, RFC 4288, |  | and Registration Procedures", BCP 13, RFC 4288, |
| December 2005. |  | December 2005. |
| [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines |  | [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines |
| and Registration Procedures for New URI Schemes", |  | and Registration Procedures for New URI Schemes", |
| BCP 115, RFC 4395, February 2006. |  | BCP 115, RFC 4395, February 2006. |
| [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based |  | [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based |
| Kerberos and NTLM HTTP Authentication in Microsoft |  | Kerberos and NTLM HTTP Authentication in Microsoft |
| skipping to change at page 74, line 25 |  | skipping to change at page 74, line 15 |
| [Spe] Spero, S., "Analysis of HTTP Performance Problems", |  | [Spe] Spero, S., "Analysis of HTTP Performance Problems", |
| <http://sunsite.unc.edu/mdma-release/http-prob.html>. |  | <http://sunsite.unc.edu/mdma-release/http-prob.html>. |
| [Tou1998] Touch, J., Heidemann, J., and K. Obraczka, "Analysis of |  | [Tou1998] Touch, J., Heidemann, J., and K. Obraczka, "Analysis of |
| HTTP Performance", ISI Research Report ISI/RR-98-463, |  | HTTP Performance", ISI Research Report ISI/RR-98-463, |
| Aug 1998, <http://www.isi.edu/touch/pubs/http-perf96/>. |  | Aug 1998, <http://www.isi.edu/touch/pubs/http-perf96/>. |
| (original report dated Aug. 1996) |  | (original report dated Aug. 1996) |
| Appendix A. Tolerant Applications |  | Appendix A. HTTP Version History |
| Although this document specifies the requirements for the generation |  |  |
| of HTTP/1.1 messages, not all applications will be correct in their |  |  |
| implementation. We therefore recommend that operational applications |  |  |
| be tolerant of deviations whenever those deviations can be |  |  |
| interpreted unambiguously. |  |  |
| The line terminator for header fields is the sequence CRLF. However, |  |  |
| we recommend that applications, when parsing such headers fields, |  |  |
| recognize a single LF as a line terminator and ignore the leading CR. |  |  |
| The character encoding of a representation SHOULD be labeled as the |  |  |
| lowest common denominator of the character codes used within that |  |  |
| representation, with the exception that not labeling the |  |  |
| representation is preferred over labeling the representation with the |  |  |
| labels US-ASCII or ISO-8859-1. See [Part3]. |  |  |
| Additional rules for requirements on parsing and encoding of dates |  |  |
| and other potential problems with date encodings include: |  |  |
| o HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date |  |  |
| which appears to be more than 50 years in the future is in fact in |  |  |
| the past (this helps solve the "year 2000" problem). |  |  |
| o Although all date formats are specified to be case-sensitive, |  |  |
| recipients SHOULD match day, week and timezone names case- |  |  |
| insensitively. |  |  |
| o An HTTP/1.1 implementation MAY internally represent a parsed |  |  |
| Expires date as earlier than the proper value, but MUST NOT |  |  |
| internally represent a parsed Expires date as later than the |  |  |
| proper value. |  |  |
| o All expiration-related calculations MUST be done in GMT. The |  |  |
| local time zone MUST NOT influence the calculation or comparison |  |  |
| of an age or expiration time. |  |  |
| o If an HTTP header field incorrectly carries a date value with a |  |  |
| time zone other than GMT, it MUST be converted into GMT using the |  |  |
| most conservative possible conversion. |  |  |
| Appendix B. HTTP Version History |  |  |
| HTTP has been in use by the World-Wide Web global information |  | HTTP has been in use by the World-Wide Web global information |
| initiative since 1990. The first version of HTTP, later referred to |  | initiative since 1990. The first version of HTTP, later referred to |
| as HTTP/0.9, was a simple protocol for hypertext data transfer across |  | as HTTP/0.9, was a simple protocol for hypertext data transfer across |
| the Internet with only a single request method (GET) and no metadata. |  | the Internet with only a single request method (GET) and no metadata. |
| HTTP/1.0, as defined by [RFC1945], added a range of request methods |  | HTTP/1.0, as defined by [RFC1945], added a range of request methods |
| and MIME-like messaging that could include metadata about the data |  | and MIME-like messaging that could include metadata about the data |
| transferred and modifiers on the request/response semantics. |  | transferred and modifiers on the request/response semantics. |
| However, HTTP/1.0 did not sufficiently take into consideration the |  | However, HTTP/1.0 did not sufficiently take into consideration the |
| effects of hierarchical proxies, caching, the need for persistent |  | effects of hierarchical proxies, caching, the need for persistent |
| skipping to change at page 76, line 12 |  | skipping to change at page 75, line 8 |
| Since HTTP/0.9 did not support header fields in a request, there is |  | Since HTTP/0.9 did not support header fields in a request, there is |
| no mechanism for it to support name-based virtual hosts (selection of |  | no mechanism for it to support name-based virtual hosts (selection of |
| resource by inspection of the Host header field). Any server that |  | resource by inspection of the Host header field). Any server that |
| implements name-based virtual hosts ought to disable support for |  | implements name-based virtual hosts ought to disable support for |
| HTTP/0.9. Most requests that appear to be HTTP/0.9 are, in fact, |  | HTTP/0.9. Most requests that appear to be HTTP/0.9 are, in fact, |
| badly constructed HTTP/1.x requests wherein a buggy client failed to |  | badly constructed HTTP/1.x requests wherein a buggy client failed to |
| properly encode linear whitespace found in a URI reference and placed |  | properly encode linear whitespace found in a URI reference and placed |
| in the request-target. |  | in the request-target. |
| B.1. Changes from HTTP/1.0 |  | A.1. Changes from HTTP/1.0 |
| This section summarizes major differences between versions HTTP/1.0 |  | This section summarizes major differences between versions HTTP/1.0 |
| and HTTP/1.1. |  | and HTTP/1.1. |
| B.1.1. Multi-homed Web Servers |  | A.1.1. Multi-homed Web Servers |
| The requirements that clients and servers support the Host header |  | The requirements that clients and servers support the Host header |
| field (Section 9.4), report an error if it is missing from an |  | field (Section 9.4), report an error if it is missing from an |
| HTTP/1.1 request, and accept absolute URIs (Section 4.1.2) are among |  | HTTP/1.1 request, and accept absolute URIs (Section 4.1.2) are among |
| the most important changes defined by HTTP/1.1. |  | the most important changes defined by HTTP/1.1. |
| Older HTTP/1.0 clients assumed a one-to-one relationship of IP |  | Older HTTP/1.0 clients assumed a one-to-one relationship of IP |
| addresses and servers; there was no other established mechanism for |  | addresses and servers; there was no other established mechanism for |
| distinguishing the intended server of a request than the IP address |  | distinguishing the intended server of a request than the IP address |
| to which that request was directed. The Host header field was |  | to which that request was directed. The Host header field was |
| introduced during the development of HTTP/1.1 and, though it was |  | introduced during the development of HTTP/1.1 and, though it was |
| quickly implemented by most HTTP/1.0 browsers, additional |  | quickly implemented by most HTTP/1.0 browsers, additional |
| requirements were placed on all HTTP/1.1 requests in order to ensure |  | requirements were placed on all HTTP/1.1 requests in order to ensure |
| complete adoption. At the time of this writing, most HTTP-based |  | complete adoption. At the time of this writing, most HTTP-based |
| services are dependent upon the Host header field for targeting |  | services are dependent upon the Host header field for targeting |
| requests. |  | requests. |
| B.1.2. Keep-Alive Connections |  | A.1.2. Keep-Alive Connections |
| For most implementations of HTTP/1.0, each connection is established |  | For most implementations of HTTP/1.0, each connection is established |
| by the client prior to the request and closed by the server after |  | by the client prior to the request and closed by the server after |
| sending the response. However, some implementations implement the |  | sending the response. However, some implementations implement the |
| Keep-Alive version of persistent connections described in Section |  | Keep-Alive version of persistent connections described in Section |
| 19.7.1 of [RFC2068]. |  | 19.7.1 of [RFC2068]. |
| Some clients and servers might wish to be compatible with some |  | Some clients and servers might wish to be compatible with some |
| previous implementations of persistent connections in HTTP/1.0 |  | previous implementations of persistent connections in HTTP/1.0 |
| clients and servers. Persistent connections in HTTP/1.0 are |  | clients and servers. Persistent connections in HTTP/1.0 are |
| skipping to change at page 77, line 17 |  | skipping to change at page 76, line 13 |
| talking to proxies. |  | talking to proxies. |
| However, talking to proxies is the most important use of persistent |  | However, talking to proxies is the most important use of persistent |
| connections, so that prohibition is clearly unacceptable. Therefore, |  | connections, so that prohibition is clearly unacceptable. Therefore, |
| we need some other mechanism for indicating a persistent connection |  | we need some other mechanism for indicating a persistent connection |
| is desired, which is safe to use even when talking to an old proxy |  | is desired, which is safe to use even when talking to an old proxy |
| that ignores Connection. Persistent connections are the default for |  | that ignores Connection. Persistent connections are the default for |
| HTTP/1.1 messages; we introduce a new keyword (Connection: close) for |  | HTTP/1.1 messages; we introduce a new keyword (Connection: close) for |
| declaring non-persistence. See Section 9.1. |  | declaring non-persistence. See Section 9.1. |
| B.2. Changes from RFC 2616 |  | A.2. Changes from RFC 2616 |
| Empty list elements in list productions have been deprecated. |  | Empty list elements in list productions have been deprecated. |
| (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. (Section 1.2.2) |
| allowed in comment and quoted-string text. The quoted-pair rule no |  |  |
| longer allows escaping control characters other than HTAB. Non-ASCII |  |  |
| content in header fields and reason phrase has been obsoleted and |  |  |
| made opaque (the TEXT rule was removed) (Section 1.2.2) |  |  |
| Clarify that the string "HTTP" in the HTTP-Version ABFN production is |  | Clarify that the string "HTTP" in the HTTP-Version ABFN production is |
| case sensitive. Restrict the version numbers to be single digits due |  | case sensitive. Restrict the version numbers to be single digits due |
| to the fact that implementations are known to handle multi-digit |  | to the fact that implementations are known to handle multi-digit |
| version numbers incorrectly. (Section 2.6) |  | 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) |
|  |  | The NUL octet is no longer allowed in comment and quoted-string text. |
|  |  | The quoted-pair rule no longer allows escaping control characters |
|  |  | other than HTAB. Non-ASCII content in header fields and reason |
|  |  | phrase has been obsoleted and made opaque (the TEXT rule was |
|  |  | removed). (Section 3.2.3) |
| 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 |
| allowed for the OPTIONS request method only. (Section 4.1.2) |  | allowed for the OPTIONS request method only. (Section 4.1.2) |
| skipping to change at page 78, line 15 |  | skipping to change at page 77, line 12 |
| Change ABNF productions for header fields to only define the field |  | Change ABNF productions for header fields to only define the field |
| value. (Section 9) |  | value. (Section 9) |
| Clarify exactly when close connection options must be sent. |  | Clarify exactly when close connection options must be sent. |
| (Section 9.1) |  | (Section 9.1) |
| Define the semantics of the "Upgrade" header field in responses other |  | Define the semantics of the "Upgrade" header field in responses other |
| than 101 (this was incorporated from [RFC2817]). (Section 9.8) |  | than 101 (this was incorporated from [RFC2817]). (Section 9.8) |
| Appendix C. Collected ABNF |  | Appendix B. Collected ABNF |
| BWS = OWS |  | BWS = OWS |
| 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 |
| skipping to change at page 82, line 25 |  | skipping to change at page 81, line 25 |
| ; Trailer defined but not used |  | ; Trailer defined but not used |
| ; Transfer-Encoding defined but not used |  | ; Transfer-Encoding defined but not used |
| ; URI-reference defined but not used |  | ; URI-reference defined but not used |
| ; Upgrade defined but not used |  | ; Upgrade defined but not used |
| ; Via defined but not used |  | ; Via defined but not used |
| ; http-URI defined but not used |  | ; http-URI defined but not used |
| ; https-URI defined but not used |  | ; https-URI defined but not used |
| ; partial-URI defined but not used |  | ; partial-URI defined but not used |
| ; special defined but not used |  | ; special defined but not used |
| Appendix D. Change Log (to be removed by RFC Editor before publication) |  | Appendix C. Change Log (to be removed by RFC Editor before publication) |
| D.1. Since RFC 2616 |  | C.1. Since RFC 2616 |
| Extracted relevant partitions from [RFC2616]. |  | Extracted relevant partitions from [RFC2616]. |
| D.2. Since draft-ietf-httpbis-p1-messaging-00 |  | C.2. Since draft-ietf-httpbis-p1-messaging-00 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/1>: "HTTP Version |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/1>: "HTTP Version |
| should be case sensitive" |  | should be case sensitive" |
| (<http://purl.org/NET/http-errata#verscase>) |  | (<http://purl.org/NET/http-errata#verscase>) |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/2>: "'unsafe' |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/2>: "'unsafe' |
| characters" (<http://purl.org/NET/http-errata#unsafe-uri>) |  | characters" (<http://purl.org/NET/http-errata#unsafe-uri>) |
| skipping to change at page 84, line 6 |  | skipping to change at page 83, line 6 |
| to-date references" |  | to-date references" |
| Other changes: |  | Other changes: |
| o Update media type registrations to use RFC4288 template. |  | o Update media type registrations to use RFC4288 template. |
| o Use names of RFC4234 core rules DQUOTE and WSP, fix broken ABNF |  | o Use names of RFC4234 core rules DQUOTE and WSP, fix broken ABNF |
| for chunk-data (work in progress on |  | for chunk-data (work in progress on |
| <http://tools.ietf.org/wg/httpbis/trac/ticket/36>) |  | <http://tools.ietf.org/wg/httpbis/trac/ticket/36>) |
| D.3. Since draft-ietf-httpbis-p1-messaging-01 |  | C.3. Since draft-ietf-httpbis-p1-messaging-01 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/19>: "Bodies on GET |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/19>: "Bodies on GET |
| (and other) requests" |  | (and other) requests" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/55>: "Updating to |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/55>: "Updating to |
| RFC4288" |  | RFC4288" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/57>: "Status Code |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/57>: "Status Code |
| skipping to change at page 85, line 5 |  | skipping to change at page 84, line 5 |
| o Move "Product Tokens" section (back) into Part 1, as "token" is |  | o Move "Product Tokens" section (back) into Part 1, as "token" is |
| used in the definition of the Upgrade header field. |  | used in the definition of the Upgrade header field. |
| o Add explicit references to BNF syntax and rules imported from |  | o Add explicit references to BNF syntax and rules imported from |
| other parts of the specification. |  | other parts of the specification. |
| o Rewrite prose rule "token" in terms of "tchar", rewrite prose rule |  | o Rewrite prose rule "token" in terms of "tchar", rewrite prose rule |
| "TEXT". |  | "TEXT". |
| D.4. Since draft-ietf-httpbis-p1-messaging-02 |  | C.4. Since draft-ietf-httpbis-p1-messaging-02 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/51>: "HTTP-date vs. |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/51>: "HTTP-date vs. |
| rfc1123-date" |  | rfc1123-date" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/64>: "WS in quoted- |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/64>: "WS in quoted- |
| pair" |  | pair" |
| Ongoing work on IANA Message Header Field Registration |  | Ongoing work on IANA Message Header Field Registration |
| skipping to change at page 85, line 27 |  | skipping to change at page 84, line 27 |
| o Reference RFC 3984, and update header field registrations for |  | o Reference RFC 3984, and update header field registrations for |
| headers defined in this document. |  | headers defined in this document. |
| Ongoing work on ABNF conversion |  | Ongoing work on ABNF conversion |
| (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |  | (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |
| o Replace string literals when the string really is case-sensitive |  | o Replace string literals when the string really is case-sensitive |
| (HTTP-Version). |  | (HTTP-Version). |
| D.5. Since draft-ietf-httpbis-p1-messaging-03 |  | C.5. Since draft-ietf-httpbis-p1-messaging-03 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/28>: "Connection |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/28>: "Connection |
| closing" |  | closing" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/97>: "Move |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/97>: "Move |
| registrations and registry information to IANA Considerations" |  | registrations and registry information to IANA Considerations" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/120>: "need new URL |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/120>: "need new URL |
| skipping to change at page 86, line 11 |  | skipping to change at page 85, line 11 |
| Ongoing work on ABNF conversion |  | Ongoing work on ABNF conversion |
| (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |  | (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |
| o Replace string literals when the string really is case-sensitive |  | o Replace string literals when the string really is case-sensitive |
| (HTTP-Date). |  | (HTTP-Date). |
| o Replace HEX by HEXDIG for future consistence with RFC 5234's core |  | o Replace HEX by HEXDIG for future consistence with RFC 5234's core |
| rules. |  | rules. |
| D.6. Since draft-ietf-httpbis-p1-messaging-04 |  | C.6. Since draft-ietf-httpbis-p1-messaging-04 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/34>: "Out-of-date |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/34>: "Out-of-date |
| reference for URIs" |  | reference for URIs" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/132>: "RFC 2822 is |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/132>: "RFC 2822 is |
| updated by RFC 5322" |  | updated by RFC 5322" |
| Ongoing work on ABNF conversion |  | Ongoing work on ABNF conversion |
| skipping to change at page 86, line 36 |  | skipping to change at page 85, line 36 |
| o Get rid of RFC822 dependency; use RFC5234 plus extensions instead. |  | o Get rid of RFC822 dependency; use RFC5234 plus extensions instead. |
| o Only reference RFC 5234's core rules. |  | o Only reference RFC 5234's core rules. |
| o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional |  | o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional |
| whitespace ("OWS") and required whitespace ("RWS"). |  | whitespace ("OWS") and required whitespace ("RWS"). |
| o Rewrite ABNFs to spell out whitespace rules, factor out header |  | o Rewrite ABNFs to spell out whitespace rules, factor out header |
| field value format definitions. |  | field value format definitions. |
| D.7. Since draft-ietf-httpbis-p1-messaging-05 |  | C.7. Since draft-ietf-httpbis-p1-messaging-05 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/30>: "Header LWS" |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/30>: "Header LWS" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/52>: "Sort 1.3 |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/52>: "Sort 1.3 |
| Terminology" |  | Terminology" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/63>: "RFC2047 |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/63>: "RFC2047 |
| encoded words" |  | encoded words" |
| skipping to change at page 87, line 33 |  | skipping to change at page 86, line 33 |
| o Add appendix containing collected and expanded ABNF. |  | o Add appendix containing collected and expanded ABNF. |
| Other changes: |  | Other changes: |
| o Rewrite introduction; add mostly new Architecture Section. |  | o Rewrite introduction; add mostly new Architecture Section. |
| o Move definition of quality values from Part 3 into Part 1; make TE |  | o Move definition of quality values from Part 3 into Part 1; make TE |
| request header field grammar independent of accept-params (defined |  | request header field grammar independent of accept-params (defined |
| in Part 3). |  | in Part 3). |
| D.8. Since draft-ietf-httpbis-p1-messaging-06 |  | C.8. Since draft-ietf-httpbis-p1-messaging-06 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/161>: "base for |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/161>: "base for |
| numeric protocol elements" |  | numeric protocol elements" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/162>: "comment ABNF" |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/162>: "comment ABNF" |
| Partly resolved issues: |  | Partly resolved issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/88>: "205 Bodies" |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/88>: "205 Bodies" |
| (took out language that implied that there might be methods for |  | (took out language that implied that there might be methods for |
| which a request body MUST NOT be included) |  | which a request body MUST NOT be included) |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/163>: "editorial |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/163>: "editorial |
| improvements around HTTP-date" |  | improvements around HTTP-date" |
| D.9. Since draft-ietf-httpbis-p1-messaging-07 |  | C.9. Since draft-ietf-httpbis-p1-messaging-07 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/93>: "Repeating |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/93>: "Repeating |
| single-value headers" |  | single-value headers" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/131>: "increase |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/131>: "increase |
| connection limit" |  | connection limit" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/157>: "IP addresses |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/157>: "IP addresses |
| skipping to change at page 88, line 42 |  | skipping to change at page 87, line 42 |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/194>: "disallow |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/194>: "disallow |
| control characters in quoted-pair" |  | control characters in quoted-pair" |
| Partly resolved issues: |  | Partly resolved issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/148>: "update IANA |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/148>: "update IANA |
| requirements wrt Transfer-Coding values" (add the IANA |  | requirements wrt Transfer-Coding values" (add the IANA |
| Considerations subsection) |  | Considerations subsection) |
| D.10. Since draft-ietf-httpbis-p1-messaging-08 |  | C.10. Since draft-ietf-httpbis-p1-messaging-08 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/201>: "header |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/201>: "header |
| parsing, treatment of leading and trailing OWS" |  | parsing, treatment of leading and trailing OWS" |
| Partly resolved issues: |  | Partly resolved issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/60>: "Placement of |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/60>: "Placement of |
| 13.5.1 and 13.5.2" |  | 13.5.1 and 13.5.2" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/200>: "use of term |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/200>: "use of term |
| "word" when talking about header structure" |  | "word" when talking about header structure" |
| D.11. Since draft-ietf-httpbis-p1-messaging-09 |  | C.11. Since draft-ietf-httpbis-p1-messaging-09 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/73>: "Clarification |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/73>: "Clarification |
| of the term 'deflate'" |  | of the term 'deflate'" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/83>: "OPTIONS * and |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/83>: "OPTIONS * and |
| proxies" |  | proxies" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/122>: "MIME-Version |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/122>: "MIME-Version |
| skipping to change at page 89, line 35 |  | skipping to change at page 88, line 35 |
| sensitivity of HTTP-date" |  | sensitivity of HTTP-date" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/200>: "use of term |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/200>: "use of term |
| "word" when talking about header structure" |  | "word" when talking about header structure" |
| Partly resolved issues: |  | Partly resolved issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/196>: "Term for the |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/196>: "Term for the |
| requested resource's URI" |  | requested resource's URI" |
| D.12. Since draft-ietf-httpbis-p1-messaging-10 |  | C.12. Since draft-ietf-httpbis-p1-messaging-10 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/28>: "Connection |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/28>: "Connection |
| Closing" |  | Closing" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/90>: "Delimiting |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/90>: "Delimiting |
| messages with multipart/byteranges" |  | messages with multipart/byteranges" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/95>: "Handling |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/95>: "Handling |
| skipping to change at page 90, line 10 |  | skipping to change at page 89, line 10 |
| entity / representation / variant terminology" |  | entity / representation / variant terminology" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider |
| removing the 'changes from 2068' sections" |  | removing the 'changes from 2068' sections" |
| Partly resolved issues: |  | Partly resolved issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/159>: "HTTP(s) URI |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/159>: "HTTP(s) URI |
| scheme definitions" |  | scheme definitions" |
| D.13. Since draft-ietf-httpbis-p1-messaging-11 |  | C.13. Since draft-ietf-httpbis-p1-messaging-11 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/193>: "Trailer |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/193>: "Trailer |
| requirements" |  | requirements" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/204>: "Text about |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/204>: "Text about |
| clock requirement for caches belongs in p6" |  | clock requirement for caches belongs in p6" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/221>: "effective |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/221>: "effective |
| request URI: handling of missing host in HTTP/1.0" |  | request URI: handling of missing host in HTTP/1.0" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/248>: "confusing |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/248>: "confusing |
| Date requirements for clients" |  | Date requirements for clients" |
| Partly resolved issues: |  | Partly resolved issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/95>: "Handling |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/95>: "Handling |
| multiple Content-Length headers" |  | multiple Content-Length headers" |
| D.14. Since draft-ietf-httpbis-p1-messaging-12 |  | C.14. Since draft-ietf-httpbis-p1-messaging-12 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/75>: "RFC2145 |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/75>: "RFC2145 |
| Normative" |  | Normative" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/159>: "HTTP(s) URI |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/159>: "HTTP(s) URI |
| scheme definitions" (tune the requirements on userinfo) |  | scheme definitions" (tune the requirements on userinfo) |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/210>: "define |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/210>: "define |
| skipping to change at page 91, line 11 |  | skipping to change at page 90, line 11 |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/240>: "Migrate |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/240>: "Migrate |
| Upgrade details from RFC2817" |  | Upgrade details from RFC2817" |
| 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/279>: "update RFC |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/279>: "update RFC |
| 2109 reference" |  | 2109 reference" |
| D.15. Since draft-ietf-httpbis-p1-messaging-13 |  | C.15. Since draft-ietf-httpbis-p1-messaging-13 |
| Closed issues: |  | Closed issues: |
| 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/95>: "Handling |
|  |  | multiple Content-Length headers" |
| 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 |  | C.16. Since draft-ietf-httpbis-p1-messaging-14 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/273>: "HTTP-Version |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/273>: "HTTP-Version |
| should be redefined as fixed length pair of DIGIT . DIGIT" |  | should be redefined as fixed length pair of DIGIT . DIGIT" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/282>: "Recommend |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/282>: "Recommend |
| minimum sizes for protocol elements" |  | minimum sizes for protocol elements" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/283>: "Set |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/283>: "Set |
| expectations around buffering" |  | expectations around buffering" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/288>: "Considering |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/288>: "Considering |
| messages in isolation" |  | messages in isolation" |
|  |  | C.17. Since draft-ietf-httpbis-p1-messaging-15 |
|  |  | Closed issues: |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/100>: "DNS Spoofing |
|  |  | / DNS Binding advice" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/254>: "move RFCs |
|  |  | 2145, 2616, 2817 to Historic status" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/270>: "\-escaping in |
|  |  | quoted strings" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/305>: "'Close' |
|  |  | should be reserved in the HTTP header field registry" |
| Index |  | Index |
| A |  | A |
| absolute-URI form (of request-target) 29 |  | absolute-URI form (of request-target) 30 |
| accelerator 14 |  | accelerator 13 |
| application/http Media Type 64 |  | application/http Media Type 66 |
| asterisk form (of request-target) 29 |  | asterisk form (of request-target) 30 |
| authority form (of request-target) 30 |  | authority form (of request-target) 31 |
| B |  | B |
| browser 10 |  | browser 9 |
| C |  | C |
| cache 15 |  | cache 14 |
| cacheable 15 |  | cacheable 14 |
| captive portal 14 |  | captive portal 14 |
| chunked (Coding Format) 38 |  | chunked (Coding Format) 39 |
| client 10 |  | client 9 |
| Coding Format |  | Coding Format |
| chunked 38 |  | chunked 39 |
| compress 41 |  | compress 42 |
| deflate 41 |  | deflate 42 |
| gzip 41 |  | gzip 42 |
| compress (Coding Format) 41 |  | compress (Coding Format) 42 |
| connection 10 |  | connection 9 |
| Connection header field 52 |  | Connection header field 53 |
| Content-Length header field 54 |  | Content-Length header field 55 |
| D |  | D |
| Date header field 54 |  | Date header field 55 |
| deflate (Coding Format) 41 |  | deflate (Coding Format) 42 |
| downstream 13 |  | downstream 12 |
| E |  | E |
| effective request URI 32 |  | effective request URI 33 |
| G |  | G |
| gateway 14 |  | gateway 13 |
| Grammar |  | Grammar |
| absolute-URI 18 |  | absolute-URI 17 |
| ALPHA 7 |  | ALPHA 7 |
| asctime-date 37 |  | asctime-date 38 |
| attribute 37 |  | attribute 38 |
| authority 18 |  | authority 17 |
| BWS 9 |  | BWS 9 |
| chunk 38 |  | chunk 39 |
| chunk-data 38 |  | chunk-data 39 |
| chunk-ext 38 |  | chunk-ext 39 |
| chunk-ext-name 38 |  | chunk-ext-name 39 |
| chunk-ext-val 38 |  | chunk-ext-val 39 |
| chunk-size 38 |  | chunk-size 39 |
| Chunked-Body 38 |  | Chunked-Body 39 |
| comment 24 |  | comment 25 |
| Connection 53 |  | Connection 54 |
| connection-token 53 |  | connection-token 54 |
| Content-Length 54 |  | Content-Length 55 |
| CR 7 |  | CR 7 |
| CRLF 7 |  | CRLF 7 |
| ctext 24 |  | ctext 25 |
| CTL 7 |  | CTL 7 |
| Date 54 |  | Date 55 |
| date1 36 |  | date1 37 |
| date2 37 |  | date2 38 |
| date3 37 |  | date3 38 |
| day 36 |  | day 37 |
| day-name 36 |  | day-name 37 |
| day-name-l 36 |  | day-name-l 37 |
| DIGIT 7 |  | DIGIT 7 |
| DQUOTE 7 |  | DQUOTE 7 |
| field-content 23 |  | field-content 22 |
| field-name 23 |  | field-name 22 |
| field-value 23 |  | field-value 22 |
| GMT 36 |  | GMT 37 |
| header-field 23 |  | header-field 22 |
| HEXDIG 7 |  | HEXDIG 7 |
| Host 56 |  | Host 57 |
| hour 36 |  | hour 37 |
| HTTP-date 35 |  | HTTP-date 36 |
| HTTP-message 21 |  | HTTP-message 21 |
| HTTP-Prot-Name 16 |  | HTTP-Prot-Name 15 |
| http-URI 18 |  | http-URI 18 |
| HTTP-Version 16 |  | HTTP-Version 15 |
| https-URI 20 |  | https-URI 19 |
| last-chunk 38 |  | last-chunk 39 |
| LF 7 |  | LF 7 |
| message-body 25 |  | message-body 25 |
| Method 29 |  | Method 30 |
| minute 36 |  | minute 37 |
| month 36 |  | month 37 |
| obs-date 36 |  | obs-date 37 |
| obs-text 10 |  | obs-text 24 |
| OCTET 7 |  | OCTET 7 |
| OWS 9 |  | OWS 9 |
| path-absolute 18 |  | path-absolute 17 |
| port 18 |  | port 17 |
| product 42 |  | product 43 |
| product-version 42 |  | product-version 43 |
| protocol-name 61 |  | protocol-name 62 |
| protocol-version 61 |  | protocol-version 62 |
| pseudonym 61 |  | pseudonym 62 |
| qdtext 10 |  | qdtext 24 |
| qdtext-nf 38 |  | qdtext-nf 39 |
| query 18 |  | query 17 |
| quoted-cpair 24 |  | quoted-cpair 25 |
| quoted-pair 10 |  | quoted-pair 25 |
| quoted-str-nf 38 |  | quoted-str-nf 39 |
| quoted-string 10 |  | quoted-string 24 |
| qvalue 42 |  | qvalue 43 |
| Reason-Phrase 34 |  | Reason-Phrase 35 |
| received-by 61 |  | received-by 62 |
| received-protocol 61 |  | received-protocol 62 |
| Request 29 |  | Request 29 |
| Request-Line 29 |  | Request-Line 30 |
| request-target 29 |  | request-target 30 |
| Response 33 |  | Response 34 |
| rfc850-date 37 |  | rfc850-date 38 |
| rfc1123-date 36 |  | rfc1123-date 37 |
| RWS 9 |  | RWS 9 |
| second 36 |  | second 37 |
| SP 7 |  | SP 7 |
| special 9 |  | special 24 |
| Status-Code 34 |  | Status-Code 35 |
| Status-Line 34 |  | Status-Line 35 |
| t-codings 57 |  | t-codings 58 |
| tchar 9 |  | tchar 24 |
| TE 57 |  | TE 58 |
| te-ext 57 |  | te-ext 58 |
| te-params 57 |  | te-params 58 |
| time-of-day 36 |  | time-of-day 37 |
| token 9 |  | token 24 |
| Trailer 58 |  | Trailer 59 |
| trailer-part 38 |  | trailer-part 39 |
| transfer-coding 37 |  | transfer-coding 38 |
| Transfer-Encoding 59 |  | Transfer-Encoding 60 |
| transfer-extension 37 |  | transfer-extension 38 |
| transfer-parameter 37 |  | transfer-parameter 38 |
| Upgrade 59 |  | Upgrade 60 |
| uri-host 18 |  | uri-host 17 |
| URI-reference 18 |  | URI-reference 17 |
| value 37 |  | value 38 |
| VCHAR 7 |  | VCHAR 7 |
| Via 61 |  | Via 62 |
| word 9 |  | word 24 |
| WSP 7 |  | WSP 7 |
| year 36 |  | year 37 |
| gzip (Coding Format) 41 |  | gzip (Coding Format) 42 |
| H |  | H |
| header field 21 |  | header field 20 |
| Header Fields |  | Header Fields |
| Connection 52 |  | Connection 53 |
| Content-Length 54 |  | Content-Length 55 |
| Date 54 |  | Date 55 |
| Host 56 |  | Host 57 |
| TE 57 |  | TE 58 |
| Trailer 58 |  | Trailer 59 |
| Transfer-Encoding 58 |  | Transfer-Encoding 59 |
| Upgrade 59 |  | Upgrade 60 |
| Via 61 |  | Via 62 |
| header section 21 |  | header section 20 |
| headers 21 |  | headers 20 |
| Host header field 56 |  | Host header field 57 |
| http URI scheme 18 |  | http URI scheme 18 |
| https URI scheme 20 |  | https URI scheme 19 |
| I |  | I |
| inbound 13 |  | inbound 12 |
| interception proxy 14 |  | interception proxy 14 |
| intermediary 13 |  | intermediary 12 |
| M |  | M |
| Media Type |  | Media Type |
| application/http 64 |  | application/http 66 |
| message/http 63 |  | message/http 64 |
| message 11 |  | message 10 |
| message/http Media Type 63 |  | message/http Media Type 64 |
| N |  | N |
| non-transforming proxy 13 |  | non-transforming proxy 13 |
| O |  | O |
| origin form (of request-target) 30 |  | origin form (of request-target) 31 |
| origin server 10 |  | origin server 9 |
| outbound 13 |  | outbound 12 |
| P |  | P |
| proxy 13 |  | proxy 12 |
| R |  | R |
| recipient 10 |  | recipient 9 |
| request 11 |  | request 10 |
| resource 18 |  | resource 17 |
| response 11 |  | response 10 |
| reverse proxy 14 |  | reverse proxy 13 |
| S |  | S |
| sender 10 |  | sender 9 |
| server 10 |  | server 9 |
| spider 10 |  | spider 9 |
| T |  | T |
| target resource 32 |  | target resource 33 |
| TE header field 57 |  | TE header field 58 |
| Trailer header field 58 |  | Trailer header field 59 |
| Transfer-Encoding header field 58 |  | Transfer-Encoding header field 59 |
| transforming proxy 13 |  | transforming proxy 13 |
| transparent proxy 14 |  | transparent proxy 14 |
| tunnel 14 |  | tunnel 13 |
| U |  | U |
| Upgrade header field 59 |  | Upgrade header field 60 |
| upstream 13 |  | upstream 12 |
| URI scheme |  | URI scheme |
| http 18 |  | http 18 |
| https 20 |  | https 19 |
| user agent 10 |  | user agent 9 |
| V |  | V |
| Via header field 61 |  | Via header field 62 |
| 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. 118 change blocks.
| 537 lines changed or deleted |  | 521 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/