| draft-ietf-httpbis-p1-messaging-13.txt |  | draft-ietf-httpbis-p1-messaging-14.txt |
--- | --- | --- | --- | ---
| HTTPbis Working Group R. Fielding, Ed. |  | HTTPbis Working Group R. Fielding, Ed. |
| Internet-Draft Adobe |  | Internet-Draft Adobe |
| Obsoletes: 2145,2616 J. Gettys |  | Obsoletes: 2145,2616 (if approved) J. Gettys |
| (if approved) Alcatel-Lucent |  | Updates: 2817 (if approved) Alcatel-Lucent |
| Updates: 2817 (if approved) J. Mogul |  | Intended status: Standards Track J. Mogul |
| Intended status: Standards Track HP |  | Expires: October 20, 2011 HP |
| Expires: September 15, 2011 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 |
| March 14, 2011 |  | April 18, 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-13 |  | draft-ietf-httpbis-p1-messaging-14 |
| Abstract |  | Abstract |
| The Hypertext Transfer Protocol (HTTP) is an application-level |  | The Hypertext Transfer Protocol (HTTP) is an application-level |
| protocol for distributed, collaborative, hypertext information |  | protocol for distributed, collaborative, hypertext information |
| systems. HTTP has been in use by the World Wide Web global |  | systems. HTTP has been in use by the World Wide Web global |
| information initiative since 1990. This document is Part 1 of the |  | information initiative since 1990. This document is Part 1 of the |
| seven-part specification that defines the protocol referred to as |  | seven-part specification that defines the protocol referred to as |
| "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides |  | "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides |
| an overview of HTTP and its associated terminology, defines the |  | an overview of HTTP and its associated terminology, defines the |
| "http" and "https" Uniform Resource Identifier (URI) schemes, defines |  | "http" and "https" Uniform Resource Identifier (URI) schemes, defines |
| the generic message syntax and parsing requirements for HTTP message |  | the generic message syntax and parsing requirements for HTTP message |
| frames, and describes general security concerns for implementations. |  | frames, and describes general security concerns for implementations. |
| Editorial Note (To be removed by RFC Editor) |  | Editorial Note (To be removed by RFC Editor) |
| Discussion of this draft should take place on the HTTPBIS working |  | Discussion of this draft should take place on the HTTPBIS working |
| group mailing list (ietf-http-wg@w3.org). The current issues list is |  | group mailing list (ietf-http-wg@w3.org), which is archived at |
| at <http://tools.ietf.org/wg/httpbis/trac/report/3> and related |  | <http://lists.w3.org/Archives/Public/ietf-http-wg/>. |
|  |  | The current issues list is at |
|  |  | <http://tools.ietf.org/wg/httpbis/trac/report/3> and related |
| documents (including fancy diffs) can be found at |  | documents (including fancy diffs) can be found at |
| <http://tools.ietf.org/wg/httpbis/>. |  | <http://tools.ietf.org/wg/httpbis/>. |
| The changes in this draft are summarized in Appendix D.14. |  | The changes in this draft are summarized in Appendix D.15. |
| 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 |
| skipping to change at page 2, line 17 |  | skipping to change at page 2, line 22 |
| 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 September 15, 2011. |  | This Internet-Draft will expire on October 20, 2011. |
| 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 45 |  | skipping to change at page 3, line 49 |
| 6.3. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 41 |  | 6.3. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 41 |
| 6.4. Quality Values . . . . . . . . . . . . . . . . . . . . . . 41 |  | 6.4. Quality Values . . . . . . . . . . . . . . . . . . . . . . 41 |
| 7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 41 |  | 7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 41 |
| 7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 42 |  | 7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 42 |
| 7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 42 |  | 7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 42 |
| 7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 42 |  | 7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 42 |
| 7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 44 |  | 7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 44 |
| 7.1.4. Practical Considerations . . . . . . . . . . . . . . . 46 |  | 7.1.4. Practical Considerations . . . . . . . . . . . . . . . 46 |
| 7.2. Message Transmission Requirements . . . . . . . . . . . . 47 |  | 7.2. Message Transmission Requirements . . . . . . . . . . . . 47 |
| 7.2.1. Persistent Connections and Flow Control . . . . . . . 47 |  | 7.2.1. Persistent Connections and Flow Control . . . . . . . 47 |
| 7.2.2. Monitoring Connections for Error Status Messages . . . 47 |  | 7.2.2. Monitoring Connections for Error Status Messages . . . 48 |
| 7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 48 |  | 7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 48 |
| 7.2.4. Client Behavior if Server Prematurely Closes |  | 7.2.4. Client Behavior if Server Prematurely Closes |
| Connection . . . . . . . . . . . . . . . . . . . . . . 50 |  | Connection . . . . . . . . . . . . . . . . . . . . . . 50 |
| 8. Miscellaneous notes that might disappear . . . . . . . . . . . 51 |  | 8. Miscellaneous notes that might disappear . . . . . . . . . . . 51 |
| 8.1. Scheme aliases considered harmful . . . . . . . . . . . . 51 |  | 8.1. Scheme aliases considered harmful . . . . . . . . . . . . 51 |
| 8.2. Use of HTTP for proxy communication . . . . . . . . . . . 51 |  | 8.2. Use of HTTP for proxy communication . . . . . . . . . . . 51 |
| 8.3. Interception of HTTP for access control . . . . . . . . . 51 |  | 8.3. Interception of HTTP for access control . . . . . . . . . 51 |
| 8.4. Use of HTTP by other protocols . . . . . . . . . . . . . . 51 |  | 8.4. Use of HTTP by other protocols . . . . . . . . . . . . . . 51 |
| 8.5. Use of HTTP by media type specification . . . . . . . . . 51 |  | 8.5. Use of HTTP by media type specification . . . . . . . . . 51 |
| 9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 51 |  | 9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 51 |
| 9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 51 |  | 9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 51 |
| 9.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 53 |  | 9.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 53 |
| 9.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 |  | 9.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 |
| 9.3.1. Clockless Origin Server Operation . . . . . . . . . . 54 |  | 9.3.1. Clockless Origin Server Operation . . . . . . . . . . 54 |
| 9.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 |  | 9.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 |
| 9.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 |  | 9.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 |
| 9.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 57 |  | 9.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 57 |
| 9.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 58 |  | 9.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 57 |
| 9.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 58 |  | 9.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 58 |
| 9.8.1. Upgrade Token Registry . . . . . . . . . . . . . . . . 59 |  | 9.8.1. Upgrade Token Registry . . . . . . . . . . . . . . . . 59 |
| 9.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 |  | 9.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 |
| 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 62 |  | 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61 |
| 10.1. Header Field Registration . . . . . . . . . . . . . . . . 62 |  | 10.1. Header Field Registration . . . . . . . . . . . . . . . . 61 |
| 10.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 62 |  | 10.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 62 |
| 10.3. Internet Media Type Registrations . . . . . . . . . . . . 62 |  | 10.3. Internet Media Type Registrations . . . . . . . . . . . . 62 |
| 10.3.1. Internet Media Type message/http . . . . . . . . . . . 62 |  | 10.3.1. Internet Media Type message/http . . . . . . . . . . . 62 |
| 10.3.2. Internet Media Type application/http . . . . . . . . . 64 |  | 10.3.2. Internet Media Type application/http . . . . . . . . . 63 |
| 10.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 65 |  | 10.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 64 |
| 10.5. Upgrade Token Registration . . . . . . . . . . . . . . . . 65 |  | 10.5. Upgrade Token Registration . . . . . . . . . . . . . . . . 65 |
| 11. Security Considerations . . . . . . . . . . . . . . . . . . . 65 |  | 11. Security Considerations . . . . . . . . . . . . . . . . . . . 65 |
| 11.1. Personal Information . . . . . . . . . . . . . . . . . . . 66 |  | 11.1. Personal Information . . . . . . . . . . . . . . . . . . . 65 |
| 11.2. Abuse of Server Log Information . . . . . . . . . . . . . 66 |  | 11.2. Abuse of Server Log Information . . . . . . . . . . . . . 66 |
| 11.3. Attacks Based On File and Path Names . . . . . . . . . . . 66 |  | 11.3. Attacks Based On File and Path Names . . . . . . . . . . . 66 |
| 11.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 66 |  | 11.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 66 |
| 11.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 67 |  | 11.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 67 |
| 11.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 68 |  | 11.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 68 |
| 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 68 |  | 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 68 |
| 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 69 |  | 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 69 |
| 13.1. Normative References . . . . . . . . . . . . . . . . . . . 69 |  | 13.1. Normative References . . . . . . . . . . . . . . . . . . . 69 |
| 13.2. Informative References . . . . . . . . . . . . . . . . . . 71 |  | 13.2. Informative References . . . . . . . . . . . . . . . . . . 71 |
| Appendix A. Tolerant Applications . . . . . . . . . . . . . . . . 74 |  | Appendix A. Tolerant Applications . . . . . . . . . . . . . . . . 73 |
| Appendix B. HTTP Version History . . . . . . . . . . . . . . . . 75 |  | Appendix B. HTTP Version History . . . . . . . . . . . . . . . . 74 |
| B.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 75 |  | B.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 75 |
| B.1.1. Multi-homed Web Servers . . . . . . . . . . . . . . . 76 |  | B.1.1. Multi-homed Web Servers . . . . . . . . . . . . . . . 75 |
| B.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 76 |  | B.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 76 |
| B.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 77 |  | B.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 76 |
| Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 77 |  | Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 77 |
| Appendix D. Change Log (to be removed by RFC Editor before |  | Appendix D. Change Log (to be removed by RFC Editor before |
| publication) . . . . . . . . . . . . . . . . . . . . 82 |  | publication) . . . . . . . . . . . . . . . . . . . . 81 |
| D.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 82 |  | D.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 81 |
| D.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 82 |  | D.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 81 |
| D.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 83 |  | D.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 83 |
| D.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 84 |  | D.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 84 |
| D.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 85 |  | D.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 84 |
| D.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 85 |  | D.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 85 |
| D.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 86 |  | D.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 85 |
| D.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 87 |  | D.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 86 |
| D.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 87 |  | D.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 87 |
| D.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 88 |  | D.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 87 |
| D.11. Since draft-ietf-httpbis-p1-messaging-09 . . . . . . . . . 88 |  | D.11. Since draft-ietf-httpbis-p1-messaging-09 . . . . . . . . . 88 |
| D.12. Since draft-ietf-httpbis-p1-messaging-10 . . . . . . . . . 89 |  | D.12. Since draft-ietf-httpbis-p1-messaging-10 . . . . . . . . . 88 |
| D.13. Since draft-ietf-httpbis-p1-messaging-11 . . . . . . . . . 89 |  | D.13. Since draft-ietf-httpbis-p1-messaging-11 . . . . . . . . . 89 |
| D.14. Since draft-ietf-httpbis-p1-messaging-12 . . . . . . . . . 90 |  | D.14. Since draft-ietf-httpbis-p1-messaging-12 . . . . . . . . . 89 |
|  |  | D.15. Since draft-ietf-httpbis-p1-messaging-13 . . . . . . . . . 90 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 |
| 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 10, line 33 |  | skipping to change at page 10, line 33 |
| 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 |
| exchanging messages across a reliable transport or session-layer |  | exchanging messages across a reliable transport or session-layer |
| connection. An HTTP "client" is a program that establishes a |  | "connection". An HTTP "client" is a program that establishes a |
| connection to a server for the purpose of sending one or more HTTP |  | connection to a server for the purpose of sending one or more HTTP |
| requests. An HTTP "server" is a program that accepts connections in |  | requests. An HTTP "server" is a program that accepts connections in |
| order to service HTTP requests by sending HTTP responses. |  | order to service HTTP requests by sending HTTP responses. |
| Note that the terms client and server refer only to the roles that |  | Note that the terms client and server refer only to the roles that |
| these programs perform for a particular connection. The same program |  | these programs perform for a particular connection. The same program |
| might act as a client on some connections and a server on others. We |  | might act as a client on some connections and a server on others. We |
| use the term "user agent" to refer to the program that initiates a |  | use the term "user agent" to refer to the program that initiates a |
| request, such as a WWW browser, editor, or spider (web-traversing |  | request, such as a WWW browser, editor, or spider (web-traversing |
| robot), and the term "origin server" to refer to the program that can |  | robot), and the term "origin server" to refer to the program that can |
| skipping to change at page 12, line 51 |  | skipping to change at page 12, line 51 |
| chain, or to all connections along the chain. Although the diagram |  | chain, or to all connections along the chain. Although the diagram |
| is linear, each participant might be engaged in multiple, |  | is linear, each participant might be engaged in multiple, |
| simultaneous communications. For example, B might be receiving |  | simultaneous communications. For example, B might be receiving |
| requests from many clients other than A, and/or forwarding requests |  | requests from many clients other than A, and/or forwarding requests |
| to servers other than C, at the same time that it is handling A's |  | to servers other than C, at the same time that it is handling A's |
| request. |  | request. |
| We use the terms "upstream" and "downstream" to describe various |  | We use the terms "upstream" and "downstream" to describe various |
| requirements in relation to the directional flow of a message: all |  | requirements in relation to the directional flow of a message: all |
| messages flow from upstream to downstream. Likewise, we use the |  | messages flow from upstream to downstream. Likewise, we use the |
| terms "inbound" and "outbound" to refer to directions in relation to |  | terms inbound and outbound to refer to directions in relation to the |
| the request path: "inbound" means toward the origin server and |  | request path: "inbound" means toward the origin server and "outbound" |
| "outbound" means toward the user agent. |  | means toward the user agent. |
| A "proxy" is a message forwarding agent that is selected by the |  | A "proxy" is a message forwarding agent that is selected by the |
| client, usually via local configuration rules, to receive requests |  | client, usually via local configuration rules, to receive requests |
| for some type(s) of absolute URI and attempt to satisfy those |  | for some type(s) of absolute URI and attempt to satisfy those |
| requests via translation through the HTTP interface. Some |  | requests via translation through the HTTP interface. Some |
| translations are minimal, such as for proxy requests for "http" URIs, |  | translations are minimal, such as for proxy requests for "http" URIs, |
| whereas other requests might require translation to and from entirely |  | whereas other requests might require translation to and from entirely |
| different application-layer protocols. Proxies are often used to |  | different application-layer protocols. Proxies are often used to |
| group an organization's HTTP requests through a common intermediary |  | group an organization's HTTP requests through a common intermediary |
| for the sake of security, annotation services, or shared caching. |  | for the sake of security, annotation services, or shared caching. |
| skipping to change at page 24, line 40 |  | skipping to change at page 24, line 40 |
| property of the message, not of the payload, and thus MAY be added or |  | property of the message, not of the payload, and thus MAY be added or |
| removed by any implementation along the request/response chain under |  | removed by any implementation along the request/response chain under |
| the constraints found in Section 6.2. |  | the constraints found in Section 6.2. |
| If a message is received that has multiple Content-Length header |  | If a message is received that has multiple Content-Length header |
| fields (Section 9.2) with field-values consisting of the same decimal |  | fields (Section 9.2) with field-values consisting of the same decimal |
| value, or a single Content-Length header field with a field value |  | value, or a single Content-Length header field with a field value |
| containing a list of identical decimal values (e.g., "Content-Length: |  | containing a list of identical decimal values (e.g., "Content-Length: |
| 42, 42"), indicating that duplicate Content-Length header fields have |  | 42, 42"), indicating that duplicate Content-Length header fields have |
| been generated or combined by an upstream message processor, then the |  | been generated or combined by an upstream message processor, then the |
| recipient MUST replace the duplicated fields or field-values with a |  | recipient MUST either reject the message as invalid or replace the |
| single valid Content-Length field containing that decimal value prior |  | duplicated field-values with a single valid Content-Length field |
| to determining the message-body length. |  | containing that decimal value prior to determining the message-body |
|  |  | length. |
| The rules for when a message-body is allowed in a message differ for |  | The rules for when a message-body is allowed in a message differ for |
| requests and responses. |  | requests and responses. |
| The presence of a message-body in a request is signaled by the |  | The presence of a message-body in a request is signaled by the |
| inclusion of a Content-Length or Transfer-Encoding header field in |  | inclusion of a Content-Length or Transfer-Encoding header field in |
| the request's header fields, even if the request method does not |  | the request's header fields, even if the request method does not |
| define any use for a message-body. This allows the request message |  | define any use for a message-body. This allows the request message |
| framing algorithm to be independent of method semantics. |  | framing algorithm to be independent of method semantics. |
| skipping to change at page 45, line 33 |  | skipping to change at page 45, line 33 |
| Some features of HTTP/1.1, such as Digest Authentication, depend on |  | Some features of HTTP/1.1, such as Digest Authentication, depend on |
| the value of certain end-to-end header fields. A non-transforming |  | the value of certain end-to-end header fields. A non-transforming |
| proxy SHOULD NOT modify an end-to-end header field unless the |  | proxy SHOULD NOT modify an end-to-end header field unless the |
| definition of that header field requires or specifically allows that. |  | definition of that header field requires or specifically allows that. |
| A non-transforming proxy MUST NOT modify any of the following fields |  | A non-transforming proxy MUST NOT modify any of the following fields |
| in a request or response, and it MUST NOT add any of these fields if |  | in a request or response, and it MUST NOT add any of these fields if |
| not already present: |  | not already present: |
|  |  | o Allow |
| o Content-Location |  | o Content-Location |
| o Content-MD5 |  | o Content-MD5 |
| o ETag |  | o ETag |
| o Last-Modified |  | o Last-Modified |
|  |  | o Server |
| A non-transforming proxy MUST NOT modify any of the following fields |  | A non-transforming proxy MUST NOT modify any of the following fields |
| in a response: |  | in a response: |
| o Expires |  | o Expires |
| but it MAY add any of these fields if not already present. If an |  | but it MAY add any of these fields if not already present. If an |
| Expires header field is added, it MUST be given a field-value |  | Expires header field is added, it MUST be given a field-value |
| identical to that of the Date header field in that response. |  | identical to that of the Date header field in that response. |
| A proxy MUST NOT modify or add any of the following fields in a |  | A proxy MUST NOT modify or add any of the following fields in a |
| skipping to change at page 52, line 5 |  | skipping to change at page 52, line 7 |
| be forwarded downstream by a proxy or gateway. This mechanism also |  | be forwarded downstream by a proxy or gateway. This mechanism also |
| allows the sender to indicate which HTTP header fields used in the |  | allows the sender to indicate which HTTP header fields used in the |
| message are only intended for the immediate recipient ("hop-by-hop"), |  | message are only intended for the immediate recipient ("hop-by-hop"), |
| as opposed to all recipients on the chain ("end-to-end"), enabling |  | as opposed to all recipients on the chain ("end-to-end"), enabling |
| the message to be self-descriptive and allowing future connection- |  | the message to be self-descriptive and allowing future connection- |
| specific extensions to be deployed in HTTP without fear that they |  | specific extensions to be deployed in HTTP without fear that they |
| will be blindly forwarded by previously deployed intermediaries. |  | will be blindly forwarded by previously deployed intermediaries. |
| The Connection header field's value has the following grammar: |  | The Connection header field's value has the following grammar: |
| Connection = "Connection" ":" OWS Connection-v |  | Connection = 1#connection-token |
| Connection-v = 1#connection-token |  |  |
| connection-token = token |  | connection-token = token |
| A proxy or gateway MUST parse a received Connection header field |  | A proxy or gateway MUST parse a received Connection header field |
| before a message is forwarded and, for each connection-token in this |  | before a message is forwarded and, for each connection-token in this |
| field, remove any header field(s) from the message with the same name |  | field, remove any header field(s) from the message with the same name |
| as the connection-token, and then remove the Connection header field |  | as the connection-token, and then remove the Connection header field |
| itself or replace it with the sender's own connection options for the |  | itself or replace it with the sender's own connection options for the |
| forwarded message. |  | forwarded message. |
| A sender MUST NOT include field-names in the Connection header field- |  | A sender MUST NOT include field-names in the Connection header field- |
| skipping to change at page 53, line 23 |  | skipping to change at page 53, line 25 |
| body, in decimal number of octets, for any message other than a |  | body, in decimal number of octets, for any message other than a |
| response to a HEAD request or a response with a status code of 304. |  | response to a HEAD request or a response with a status code of 304. |
| In the case of a response to a HEAD request, Content-Length indicates |  | In the case of a response to a HEAD request, Content-Length indicates |
| the size of the payload body (not including any potential transfer- |  | the size of the payload body (not including any potential transfer- |
| coding) that would have been sent had the request been a GET. In the |  | coding) that would have been sent had the request been a GET. In the |
| case of a 304 (Not Modified) response to a GET request, Content- |  | case of a 304 (Not Modified) response to a GET request, Content- |
| Length indicates the size of the payload body (not including any |  | Length indicates the size of the payload body (not including any |
| potential transfer-coding) that would have been sent in a 200 (OK) |  | potential transfer-coding) that would have been sent in a 200 (OK) |
| response. |  | response. |
| Content-Length = "Content-Length" ":" OWS 1*Content-Length-v |  | Content-Length = 1*DIGIT |
| Content-Length-v = 1*DIGIT |  |  |
| An example is |  | An example is |
| Content-Length: 3495 |  | Content-Length: 3495 |
| Implementations SHOULD use this field to indicate the message-body |  | Implementations SHOULD use this field to indicate the message-body |
| length when no transfer-coding is being applied and the payload's |  | length when no transfer-coding is being applied and the payload's |
| body length can be determined prior to being transferred. |  | body length can be determined prior to being transferred. |
| Section 3.3 describes how recipients determine the length of a |  | Section 3.3 describes how recipients determine the length of a |
| message-body. |  | message-body. |
| skipping to change at page 53, line 50 |  | skipping to change at page 53, line 51 |
| field used within the "message/external-body" content-type. |  | field used within the "message/external-body" content-type. |
| 9.3. Date |  | 9.3. Date |
| The "Date" header field represents the date and time at which the |  | The "Date" header field represents the date and time at which the |
| message was originated, having the same semantics as the Origination |  | message was originated, having the same semantics as the Origination |
| Date Field (orig-date) defined in Section 3.6.1 of [RFC5322]. The |  | Date Field (orig-date) defined in Section 3.6.1 of [RFC5322]. The |
| field value is an HTTP-date, as described in Section 6.1; it MUST be |  | field value is an HTTP-date, as described in Section 6.1; it MUST be |
| sent in rfc1123-date format. |  | sent in rfc1123-date format. |
| Date = "Date" ":" OWS Date-v |  | Date = HTTP-date |
| Date-v = HTTP-date |  |  |
| An example is |  | An example is |
| Date: Tue, 15 Nov 1994 08:12:31 GMT |  | Date: Tue, 15 Nov 1994 08:12:31 GMT |
| Origin servers MUST include a Date header field in all responses, |  | Origin servers MUST include a Date header field in all responses, |
| except in these cases: |  | except in these cases: |
| 1. If the response status code is 100 (Continue) or 101 (Switching |  | 1. If the response status code is 100 (Continue) or 101 (Switching |
| Protocols), the response MAY include a Date header field, at the |  | Protocols), the response MAY include a Date header field, at the |
| skipping to change at page 55, line 14 |  | skipping to change at page 55, line 14 |
| 9.4. Host |  | 9.4. Host |
| The "Host" header field in a request provides the host and port |  | The "Host" header field in a request provides the host and port |
| information from the target resource's URI, enabling the origin |  | information from the target resource's URI, enabling the origin |
| server to distinguish between resources while servicing requests for |  | server to distinguish between resources while servicing requests for |
| multiple host names on a single IP address. Since the Host field- |  | multiple host names on a single IP address. Since the Host field- |
| value is critical information for handling a request, it SHOULD be |  | value is critical information for handling a request, it SHOULD be |
| sent as the first header field following the Request-Line. |  | sent as the first header field following the Request-Line. |
| Host = "Host" ":" OWS Host-v |  | Host = uri-host [ ":" port ] ; Section 2.6.1 |
| Host-v = uri-host [ ":" port ] ; Section 2.6.1 |  |  |
| A client MUST send a Host header field in all HTTP/1.1 request |  | A client MUST send a Host header field in all HTTP/1.1 request |
| messages. If the target resource's URI includes an authority |  | messages. If the target resource's URI includes an authority |
| component, then the Host field-value MUST be identical to that |  | component, then the Host field-value MUST be identical to that |
| authority component after excluding any userinfo (Section 2.6.1). If |  | authority component after excluding any userinfo (Section 2.6.1). If |
| the authority component is missing or undefined for the target |  | the authority component is missing or undefined for the target |
| resource's URI, then the Host header field MUST be sent with an empty |  | resource's URI, then the Host header field MUST be sent with an empty |
| field-value. |  | field-value. |
| For example, a GET request to the origin server for |  | For example, a GET request to the origin server for |
| skipping to change at page 56, line 20 |  | skipping to change at page 56, line 19 |
| 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). |
| TE = "TE" ":" OWS TE-v |  | TE = #t-codings |
| TE-v = #t-codings |  |  |
| t-codings = "trailers" / ( transfer-extension [ te-params ] ) |  | t-codings = "trailers" / ( transfer-extension [ te-params ] ) |
| te-params = OWS ";" OWS "q=" qvalue *( te-ext ) |  | te-params = OWS ";" OWS "q=" qvalue *( te-ext ) |
| te-ext = OWS ";" OWS token [ "=" word ] |  | te-ext = OWS ";" OWS token [ "=" word ] |
| The presence of the keyword "trailers" indicates that the client is |  | The presence of the keyword "trailers" indicates that the client is |
| willing to accept trailer fields in a chunked transfer-coding, as |  | willing to accept trailer fields in a chunked transfer-coding, as |
| defined in Section 6.2.1. This keyword is reserved for use with |  | defined in Section 6.2.1. This keyword is reserved for use with |
| transfer-coding values even though it does not itself represent a |  | transfer-coding values even though it does not itself represent a |
| transfer-coding. |  | transfer-coding. |
| skipping to change at page 57, line 29 |  | skipping to change at page 57, line 28 |
| If the TE field-value is empty or if no TE field is present, the only |  | If the TE field-value is empty or if no TE field is present, the only |
| transfer-coding is "chunked". A message with no transfer-coding is |  | transfer-coding is "chunked". A message with no transfer-coding is |
| always acceptable. |  | always acceptable. |
| 9.6. Trailer |  | 9.6. Trailer |
| The "Trailer" header field indicates that the given set of header |  | The "Trailer" header field indicates that the given set of header |
| fields is present in the trailer of a message encoded with chunked |  | fields is present in the trailer of a message encoded with chunked |
| transfer-coding. |  | transfer-coding. |
| Trailer = "Trailer" ":" OWS Trailer-v |  | Trailer = 1#field-name |
| Trailer-v = 1#field-name |  |  |
| An HTTP/1.1 message SHOULD include a Trailer header field in a |  | An HTTP/1.1 message SHOULD include a Trailer header field in a |
| message using chunked transfer-coding with a non-empty trailer. |  | message using chunked transfer-coding with a non-empty trailer. |
| Doing so allows the recipient to know which header fields to expect |  | Doing so allows the recipient to know which header fields to expect |
| in the trailer. |  | in the trailer. |
| If no Trailer header field is present, the trailer SHOULD NOT include |  | If no Trailer header field is present, the trailer SHOULD NOT include |
| any header fields. See Section 6.2.1 for restrictions on the use of |  | any header fields. See Section 6.2.1 for restrictions on the use of |
| trailer fields in a "chunked" transfer-coding. |  | trailer fields in a "chunked" transfer-coding. |
| skipping to change at page 58, line 13 |  | skipping to change at page 58, line 7 |
| o Trailer |  | o Trailer |
| 9.7. Transfer-Encoding |  | 9.7. Transfer-Encoding |
| The "Transfer-Encoding" header field indicates what transfer-codings |  | The "Transfer-Encoding" header field indicates what transfer-codings |
| (if any) have been applied to the message body. It differs from |  | (if any) have been applied to the message body. It differs from |
| Content-Encoding (Section 2.2 of [Part3]) in that transfer-codings |  | Content-Encoding (Section 2.2 of [Part3]) in that transfer-codings |
| are a property of the message (and therefore are removed by |  | are a property of the message (and therefore are removed by |
| intermediaries), whereas content-codings are not. |  | intermediaries), whereas content-codings are not. |
| Transfer-Encoding = "Transfer-Encoding" ":" OWS |  | Transfer-Encoding = 1#transfer-coding |
| Transfer-Encoding-v |  |  |
| Transfer-Encoding-v = 1#transfer-coding |  |  |
| Transfer-codings are defined in Section 6.2. An example is: |  | Transfer-codings are defined in Section 6.2. An example is: |
| Transfer-Encoding: chunked |  | Transfer-Encoding: chunked |
| If multiple encodings have been applied to a representation, the |  | If multiple encodings have been applied to a representation, the |
| transfer-codings MUST be listed in the order in which they were |  | transfer-codings MUST be listed in the order in which they were |
| applied. Additional information about the encoding parameters MAY be |  | applied. Additional information about the encoding parameters MAY be |
| provided by other header fields not defined by this specification. |  | provided by other header fields not defined by this specification. |
| Many older HTTP/1.0 applications do not understand the Transfer- |  | Many older HTTP/1.0 applications do not understand the Transfer- |
| Encoding header field. |  | Encoding header field. |
| 9.8. Upgrade |  | 9.8. Upgrade |
| The "Upgrade" header field allows the client to specify what |  | The "Upgrade" header field allows the client to specify what |
| additional communication protocols it would like to use, if the |  | additional communication protocols it would like to use, if the |
| server chooses to switch protocols. Servers can use it to indicate |  | server chooses to switch protocols. Servers can use it to indicate |
| what protocols they are willing to switch to. |  | what protocols they are willing to switch to. |
| Upgrade = "Upgrade" ":" OWS Upgrade-v |  | Upgrade = 1#product |
| Upgrade-v = 1#product |  |  |
| For example, |  | For example, |
| Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 |  | Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 |
| The Upgrade header field is intended to provide a simple mechanism |  | The Upgrade header field is intended to provide a simple mechanism |
| for transition from HTTP/1.1 to some other, incompatible protocol. |  | for transition from HTTP/1.1 to some other, incompatible protocol. |
| It does so by allowing the client to advertise its desire to use |  | It does so by allowing the client to advertise its desire to use |
| another protocol, such as a later version of HTTP with a higher major |  | another protocol, such as a later version of HTTP with a higher major |
| version number, even though the current request has been made using |  | version number, even though the current request has been made using |
| skipping to change at page 60, line 38 |  | skipping to change at page 60, line 28 |
| The "Via" header field MUST be sent by a proxy or gateway to indicate |  | The "Via" header field MUST be sent by a proxy or gateway to indicate |
| the intermediate protocols and recipients between the user agent and |  | the intermediate protocols and recipients between the user agent and |
| the server on requests, and between the origin server and the client |  | the server on requests, and between the origin server and the client |
| on responses. It is analogous to the "Received" field used by email |  | on responses. It is analogous to the "Received" field used by email |
| systems (Section 3.6.7 of [RFC5322]) and is intended to be used for |  | systems (Section 3.6.7 of [RFC5322]) and is intended to be used for |
| tracking message forwards, avoiding request loops, and identifying |  | tracking message forwards, avoiding request loops, and identifying |
| the protocol capabilities of all senders along the request/response |  | the protocol capabilities of all senders along the request/response |
| chain. |  | chain. |
| Via = "Via" ":" OWS Via-v |  | Via = 1#( received-protocol RWS received-by |
| Via-v = 1#( received-protocol RWS received-by |  |  |
| [ RWS comment ] ) |  | [ RWS comment ] ) |
| received-protocol = [ protocol-name "/" ] protocol-version |  | received-protocol = [ protocol-name "/" ] protocol-version |
| protocol-name = token |  | protocol-name = token |
| protocol-version = token |  | protocol-version = token |
| received-by = ( uri-host [ ":" port ] ) / pseudonym |  | received-by = ( uri-host [ ":" port ] ) / pseudonym |
| pseudonym = token |  | pseudonym = token |
| The received-protocol indicates the protocol version of the message |  | The received-protocol indicates the protocol version of the message |
| received by the server or client along each segment of the request/ |  | received by the server or client along each segment of the request/ |
| response chain. The received-protocol version is appended to the Via |  | response chain. The received-protocol version is appended to the Via |
| skipping to change at page 69, line 40 |  | skipping to change at page 69, line 29 |
| technology -- 8-bit single-byte coded |  | technology -- 8-bit single-byte coded |
| graphic character sets -- Part 1: |  | graphic character sets -- Part 1: |
| Latin alphabet No. 1", ISO/ |  | Latin alphabet No. 1", ISO/ |
| IEC 8859-1:1998, 1998. |  | IEC 8859-1:1998, 1998. |
| [Part2] Fielding, R., Ed., Gettys, J., Mogul, |  | [Part2] Fielding, R., Ed., Gettys, J., Mogul, |
| J., Frystyk, H., Masinter, L., Leach, |  | J., Frystyk, H., Masinter, L., Leach, |
| P., Berners-Lee, T., Lafon, Y., Ed., |  | P., Berners-Lee, T., Lafon, Y., Ed., |
| and J. Reschke, Ed., "HTTP/1.1, part |  | and J. Reschke, Ed., "HTTP/1.1, part |
| 2: Message Semantics", |  | 2: Message Semantics", |
| draft-ietf-httpbis-p2-semantics-13 |  | draft-ietf-httpbis-p2-semantics-14 |
| (work in progress), March 2011. |  | (work in progress), April 2011. |
| [Part3] Fielding, R., Ed., Gettys, J., Mogul, |  | [Part3] Fielding, R., Ed., Gettys, J., Mogul, |
| J., Frystyk, H., Masinter, L., Leach, |  | J., Frystyk, H., Masinter, L., Leach, |
| P., Berners-Lee, T., Lafon, Y., Ed., |  | P., Berners-Lee, T., Lafon, Y., Ed., |
| and J. Reschke, Ed., "HTTP/1.1, part |  | and J. Reschke, Ed., "HTTP/1.1, part |
| 3: Message Payload and Content |  | 3: Message Payload and Content |
| Negotiation", |  | Negotiation", |
| draft-ietf-httpbis-p3-payload-13 (work |  | draft-ietf-httpbis-p3-payload-14 (work |
| in progress), March 2011. |  | in progress), April 2011. |
| [Part6] Fielding, R., Ed., Gettys, J., Mogul, |  | [Part6] Fielding, R., Ed., Gettys, J., Mogul, |
| J., Frystyk, H., Masinter, L., Leach, |  | J., Frystyk, H., Masinter, L., Leach, |
| P., Berners-Lee, T., Lafon, Y., Ed., |  | P., Berners-Lee, T., Lafon, Y., Ed., |
| Nottingham, M., Ed., and J. Reschke, |  | Nottingham, M., Ed., and J. Reschke, |
| Ed., "HTTP/1.1, part 6: Caching", |  | Ed., "HTTP/1.1, part 6: Caching", |
| draft-ietf-httpbis-p6-cache-13 (work |  | draft-ietf-httpbis-p6-cache-14 (work |
| in progress), March 2011. |  | in progress), April 2011. |
| [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB |  | [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB |
| Compressed Data Format Specification |  | Compressed Data Format Specification |
| version 3.3", RFC 1950, May 1996. |  | version 3.3", RFC 1950, May 1996. |
| RFC 1950 is an Informational RFC, thus |  | RFC 1950 is an Informational RFC, thus |
| it might be less stable than this |  | it might be less stable than this |
| specification. On the other hand, |  | specification. On the other hand, |
| this downward reference was present |  | this downward reference was present |
| since the publication of RFC 2068 in |  | since the publication of RFC 2068 in |
| skipping to change at page 77, line 39 |  | skipping to change at page 77, line 23 |
| 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) |
| Clarification that the chunk length does not include the count of the |  | Clarification that the chunk length does not include the count of the |
| octets in the chunk header and trailer. Furthermore disallowed line |  | octets in the chunk header and trailer. Furthermore disallowed line |
| folding in chunk extensions. (Section 6.2.1) |  | folding in chunk extensions. (Section 6.2.1) |
| Remove hard limit of two connections per server. (Section 7.1.4) |  | Remove hard limit of two connections per server. (Section 7.1.4) |
|  |  | Change ABNF productions for header fields to only define the field |
|  |  | 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 C. Collected ABNF |
| BWS = OWS |  | BWS = OWS |
| Chunked-Body = *chunk last-chunk trailer-part CRLF |  | Chunked-Body = *chunk last-chunk trailer-part CRLF |
| Connection = "Connection:" OWS Connection-v |  | Connection = *( "," OWS ) connection-token *( OWS "," [ OWS |
| Connection-v = *( "," OWS ) connection-token *( OWS "," [ OWS |  |  |
| connection-token ] ) |  | connection-token ] ) |
|  |  | Content-Length = 1*DIGIT |
| Content-Length = "Content-Length:" OWS 1*Content-Length-v |  | Date = HTTP-date |
| Content-Length-v = 1*DIGIT |  |  |
| Date = "Date:" OWS Date-v |  |  |
| Date-v = HTTP-date |  |  |
| GMT = %x47.4D.54 ; GMT |  | GMT = %x47.4D.54 ; GMT |
| HTTP-Prot-Name = %x48.54.54.50 ; HTTP |  | HTTP-Prot-Name = %x48.54.54.50 ; HTTP |
| HTTP-Version = HTTP-Prot-Name "/" 1*DIGIT "." 1*DIGIT |  | HTTP-Version = HTTP-Prot-Name "/" 1*DIGIT "." 1*DIGIT |
| HTTP-date = rfc1123-date / obs-date |  | HTTP-date = rfc1123-date / obs-date |
| HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body |  | HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body |
| ] |  | ] |
| Host = "Host:" OWS Host-v |  | Host = uri-host [ ":" port ] |
| Host-v = uri-host [ ":" port ] |  |  |
| Method = token |  | Method = token |
| OWS = *( [ obs-fold ] WSP ) |  | OWS = *( [ obs-fold ] WSP ) |
| RWS = 1*( [ obs-fold ] WSP ) |  | RWS = 1*( [ obs-fold ] WSP ) |
| Reason-Phrase = *( WSP / VCHAR / obs-text ) |  | Reason-Phrase = *( WSP / VCHAR / obs-text ) |
| Request = Request-Line *( header-field CRLF ) CRLF [ message-body ] |  | Request = Request-Line *( header-field CRLF ) CRLF [ message-body ] |
| Request-Line = Method SP request-target SP HTTP-Version CRLF |  | Request-Line = Method SP request-target SP HTTP-Version CRLF |
| Response = Status-Line *( header-field CRLF ) CRLF [ message-body ] |  | Response = Status-Line *( header-field CRLF ) CRLF [ message-body ] |
| Status-Code = 3DIGIT |  | Status-Code = 3DIGIT |
| Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF |  | Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF |
| skipping to change at page 78, line 34 |  | skipping to change at page 78, line 15 |
| RWS = 1*( [ obs-fold ] WSP ) |  | RWS = 1*( [ obs-fold ] WSP ) |
| Reason-Phrase = *( WSP / VCHAR / obs-text ) |  | Reason-Phrase = *( WSP / VCHAR / obs-text ) |
| Request = Request-Line *( header-field CRLF ) CRLF [ message-body ] |  | Request = Request-Line *( header-field CRLF ) CRLF [ message-body ] |
| Request-Line = Method SP request-target SP HTTP-Version CRLF |  | Request-Line = Method SP request-target SP HTTP-Version CRLF |
| Response = Status-Line *( header-field CRLF ) CRLF [ message-body ] |  | Response = Status-Line *( header-field CRLF ) CRLF [ message-body ] |
| Status-Code = 3DIGIT |  | Status-Code = 3DIGIT |
| Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF |  | Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF |
| TE = "TE:" OWS TE-v |  | TE = [ ( "," / t-codings ) *( OWS "," [ OWS t-codings ] ) ] |
| TE-v = [ ( "," / t-codings ) *( OWS "," [ OWS t-codings ] ) ] |  | Trailer = *( "," OWS ) field-name *( OWS "," [ OWS field-name ] ) |
| Trailer = "Trailer:" OWS Trailer-v |  | Transfer-Encoding = *( "," OWS ) transfer-coding *( OWS "," [ OWS |
| Trailer-v = *( "," OWS ) field-name *( OWS "," [ OWS field-name ] ) |  |  |
| Transfer-Encoding = "Transfer-Encoding:" OWS Transfer-Encoding-v |  |  |
| Transfer-Encoding-v = *( "," OWS ) transfer-coding *( OWS "," [ OWS |  |  |
| transfer-coding ] ) |  | transfer-coding ] ) |
| URI-reference = <URI-reference, defined in [RFC3986], Section 4.1> |  | URI-reference = <URI-reference, defined in [RFC3986], Section 4.1> |
| Upgrade = "Upgrade:" OWS Upgrade-v |  | Upgrade = *( "," OWS ) product *( OWS "," [ OWS product ] ) |
| Upgrade-v = *( "," OWS ) product *( OWS "," [ OWS product ] ) |  |  |
| Via = "Via:" OWS Via-v |  | Via = *( "," OWS ) received-protocol RWS received-by [ RWS comment ] |
| Via-v = *( "," OWS ) received-protocol RWS received-by [ RWS comment |  | *( OWS "," [ OWS received-protocol RWS received-by [ RWS comment ] ] |
| ] *( OWS "," [ OWS received-protocol RWS received-by [ RWS comment ] |  | ) |
| ] ) |  |  |
| absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3> |  | absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3> |
| asctime-date = day-name SP date3 SP time-of-day SP year |  | asctime-date = day-name SP date3 SP time-of-day SP year |
| attribute = token |  | attribute = token |
| authority = <authority, defined in [RFC3986], Section 3.2> |  | authority = <authority, defined in [RFC3986], Section 3.2> |
| chunk = chunk-size *WSP [ chunk-ext ] CRLF chunk-data CRLF |  | chunk = chunk-size *WSP [ chunk-ext ] CRLF chunk-data CRLF |
| chunk-data = 1*OCTET |  | chunk-data = 1*OCTET |
| chunk-ext = *( ";" *WSP chunk-ext-name [ "=" chunk-ext-val ] *WSP ) |  | chunk-ext = *( ";" *WSP chunk-ext-name [ "=" chunk-ext-val ] *WSP ) |
| chunk-ext-name = token |  | chunk-ext-name = token |
| skipping to change at page 90, line 36 |  | skipping to change at page 90, line 14 |
| 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 |
|  |  | Closed issues: |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/53>: "Allow is not |
|  |  | in 13.5.2" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle |
|  |  | ABNFs for header fields" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/286>: "Content- |
|  |  | Length ABNF broken" |
| Index |  | Index |
| A |  | A |
| absolute-URI form (of request-target) 29 |  | absolute-URI form (of request-target) 29 |
| accelerator 13 |  | accelerator 13 |
| application/http Media Type 64 |  | application/http Media Type 63 |
| asterisk form (of request-target) 28 |  | asterisk form (of request-target) 28 |
| authority form (of request-target) 29 |  | authority form (of request-target) 29 |
| B |  | B |
| browser 10 |  | browser 10 |
| C |  | C |
| cache 14 |  | cache 14 |
| cacheable 14 |  | cacheable 14 |
| captive portal 14 |  | captive portal 14 |
| skipping to change at page 91, line 42 |  | skipping to change at page 91, line 33 |
| chunk 37 |  | chunk 37 |
| chunk-data 37 |  | chunk-data 37 |
| chunk-ext 37 |  | chunk-ext 37 |
| chunk-ext-name 37 |  | chunk-ext-name 37 |
| chunk-ext-val 37 |  | chunk-ext-val 37 |
| chunk-size 37 |  | chunk-size 37 |
| Chunked-Body 37 |  | Chunked-Body 37 |
| comment 23 |  | comment 23 |
| Connection 52 |  | Connection 52 |
| connection-token 52 |  | connection-token 52 |
| Connection-v 52 |  |  |
| Content-Length 53 |  | Content-Length 53 |
| Content-Length-v 53 |  |  |
| CR 7 |  | CR 7 |
| CRLF 7 |  | CRLF 7 |
| ctext 23 |  | ctext 23 |
| CTL 7 |  | CTL 7 |
| Date 53 |  | Date 53 |
| Date-v 53 |  |  |
| date1 35 |  | date1 35 |
| date2 36 |  | date2 36 |
| date3 36 |  | date3 36 |
| day 35 |  | day 35 |
| day-name 35 |  | day-name 35 |
| day-name-l 35 |  | day-name-l 35 |
| DIGIT 7 |  | DIGIT 7 |
| DQUOTE 7 |  | DQUOTE 7 |
| field-content 22 |  | field-content 22 |
| field-name 22 |  | field-name 22 |
| field-value 22 |  | field-value 22 |
| GMT 35 |  | GMT 35 |
| header-field 22 |  | header-field 22 |
| HEXDIG 7 |  | HEXDIG 7 |
| Host 55 |  | Host 55 |
| Host-v 55 |  |  |
| hour 35 |  | hour 35 |
| HTTP-date 34 |  | HTTP-date 34 |
| HTTP-message 21 |  | HTTP-message 21 |
| HTTP-Prot-Name 15 |  | HTTP-Prot-Name 15 |
| http-URI 18 |  | http-URI 18 |
| HTTP-Version 15 |  | HTTP-Version 15 |
| https-URI 19 |  | https-URI 19 |
| last-chunk 37 |  | last-chunk 37 |
| LF 7 |  | LF 7 |
| message-body 24 |  | message-body 24 |
| skipping to change at page 93, line 23 |  | skipping to change at page 93, line 10 |
| second 35 |  | second 35 |
| SP 7 |  | SP 7 |
| special 9 |  | special 9 |
| Status-Code 33 |  | Status-Code 33 |
| Status-Line 33 |  | Status-Line 33 |
| t-codings 56 |  | t-codings 56 |
| tchar 9 |  | tchar 9 |
| TE 56 |  | TE 56 |
| te-ext 56 |  | te-ext 56 |
| te-params 56 |  | te-params 56 |
| TE-v 56 |  |  |
| time-of-day 35 |  | time-of-day 35 |
| token 9 |  | token 9 |
| Trailer 57 |  | Trailer 57 |
| trailer-part 37 |  | trailer-part 37 |
| Trailer-v 57 |  |  |
| transfer-coding 36 |  | transfer-coding 36 |
| Transfer-Encoding 58 |  | Transfer-Encoding 58 |
| Transfer-Encoding-v 58 |  |  |
| transfer-extension 36 |  | transfer-extension 36 |
| transfer-parameter 36 |  | transfer-parameter 36 |
| Upgrade 58 |  | Upgrade 58 |
| Upgrade-v 58 |  |  |
| uri-host 17 |  | uri-host 17 |
| URI-reference 17 |  | URI-reference 17 |
| value 36 |  | value 36 |
| VCHAR 7 |  | VCHAR 7 |
| Via 60 |  | Via 60 |
| Via-v 60 |  |  |
| word 9 |  | word 9 |
| WSP 7 |  | WSP 7 |
| year 35 |  | year 35 |
| gzip (Coding Format) 40 |  | gzip (Coding Format) 40 |
| H |  | H |
| header field 20 |  | header field 20 |
| Header Fields |  | Header Fields |
| Connection 51 |  | Connection 51 |
| Content-Length 53 |  | Content-Length 53 |
| Date 53 |  | Date 53 |
| Host 55 |  | Host 55 |
| TE 56 |  | TE 56 |
| Trailer 57 |  | Trailer 57 |
| Transfer-Encoding 58 |  | Transfer-Encoding 57 |
| Upgrade 58 |  | Upgrade 58 |
| Via 60 |  | Via 60 |
| header section 20 |  | header section 20 |
| headers 20 |  | headers 20 |
| Host header field 55 |  | Host header field 55 |
| http URI scheme 18 |  | http URI scheme 18 |
| https URI scheme 19 |  | https URI scheme 19 |
| I |  | I |
| inbound 12 |  | inbound 12 |
| interception proxy 14 |  | interception proxy 14 |
| intermediary 12 |  | intermediary 12 |
| M |  | M |
| Media Type |  | Media Type |
| application/http 64 |  | application/http 63 |
| message/http 62 |  | message/http 62 |
| message 11 |  | message 11 |
| message/http Media Type 62 |  | message/http Media Type 62 |
| N |  | N |
| non-transforming proxy 13 |  | non-transforming proxy 13 |
| O |  | O |
| origin form (of request-target) 29 |  | origin form (of request-target) 29 |
| origin server 10 |  | origin server 10 |
| outbound 12 |  | outbound 12 |
| P |  | P |
| proxy 13 |  | proxy 13 |
| R |  | R |
|  |  | recipient 10 |
| request 11 |  | request 11 |
| resource 17 |  | resource 17 |
| response 11 |  | response 11 |
| reverse proxy 13 |  | reverse proxy 13 |
| S |  | S |
|  |  | sender 10 |
| server 10 |  | server 10 |
| spider 10 |  | spider 10 |
| T |  | T |
| target resource 31 |  | target resource 31 |
| TE header field 56 |  | TE header field 56 |
| Trailer header field 57 |  | Trailer header field 57 |
| Transfer-Encoding header field 58 |  | Transfer-Encoding header field 57 |
| transforming proxy 13 |  | transforming proxy 13 |
| transparent proxy 14 |  | transparent proxy 14 |
| tunnel 14 |  | tunnel 14 |
| U |  | U |
| Upgrade header field 58 |  | Upgrade header field 58 |
| upstream 12 |  | upstream 12 |
| URI scheme |  | URI scheme |
| http 18 |  | http 18 |
| https 19 |  | https 19 |
End of changes. 63 change blocks.
| 98 lines changed or deleted |  | 96 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/