| draft-ietf-httpbis-p1-messaging-17.txt |  | draft-ietf-httpbis-p1-messaging-18.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: May 3, 2012 HP |  | Expires: July 7, 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 |
| October 31, 2011 |  | January 4, 2012 |
| 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-17 |  | draft-ietf-httpbis-p1-messaging-18 |
| 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 and moves it to |  | "HTTP/1.1" and, taken together, obsoletes RFC 2616 and moves it to |
| historic status, along with its predecessor RFC 2068. |  | historic status, along with its predecessor RFC 2068. |
| skipping to change at page 2, line 11 |  | skipping to change at page 2, line 11 |
| 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 C.18. |  | The changes in this draft are summarized in Appendix C.19. |
| 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 May 3, 2012. |  | This Internet-Draft will expire on July 7, 2012. |
| Copyright Notice |  | Copyright Notice |
| Copyright (c) 2011 IETF Trust and the persons identified as the |  | Copyright (c) 2012 IETF Trust and the persons identified as the |
| document authors. All rights reserved. |  | document authors. All rights reserved. |
| This document is subject to BCP 78 and the IETF Trust's Legal |  | This document is subject to BCP 78 and the IETF Trust's Legal |
| Provisions Relating to IETF Documents |  | Provisions Relating to IETF Documents |
| (http://trustee.ietf.org/license-info) in effect on the date of |  | (http://trustee.ietf.org/license-info) in effect on the date of |
| publication of this document. Please review these documents |  | publication of this document. Please review these documents |
| carefully, as they describe your rights and restrictions with respect |  | carefully, as they describe your rights and restrictions with respect |
| to this document. Code Components extracted from this document must |  | to this document. Code Components extracted from this document must |
| include Simplified BSD License text as described in Section 4.e of |  | include Simplified BSD License text as described in Section 4.e of |
| the Trust Legal Provisions and are provided without warranty as |  | the Trust Legal Provisions and are provided without warranty as |
| skipping to change at page 3, line 27 |  | skipping to change at page 3, line 27 |
| 2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 10 |  | 2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 10 |
| 2.2. Message Orientation and Buffering . . . . . . . . . . . . 11 |  | 2.2. Message Orientation and Buffering . . . . . . . . . . . . 11 |
| 2.3. Connections and Transport Independence . . . . . . . . . . 12 |  | 2.3. Connections and Transport Independence . . . . . . . . . . 12 |
| 2.4. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 12 |  | 2.4. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 12 |
| 2.5. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 14 |  | 2.5. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 14 |
| 2.6. Protocol Versioning . . . . . . . . . . . . . . . . . . . 15 |  | 2.6. Protocol Versioning . . . . . . . . . . . . . . . . . . . 15 |
| 2.7. Uniform Resource Identifiers . . . . . . . . . . . . . . . 17 |  | 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 . . . . . . . . . . . . . . . . . . . 19 |  | 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 . . . . . . . . . . . . . . . . . . . . . . . . 20 |  | 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 21 |
| 3.1. Start Line . . . . . . . . . . . . . . . . . . . . . . . . 21 |  | 3.1. Start Line . . . . . . . . . . . . . . . . . . . . . . . . 21 |
| 3.1.1. Request-Line . . . . . . . . . . . . . . . . . . . . . 22 |  | 3.1.1. Request-Line . . . . . . . . . . . . . . . . . . . . . 22 |
| 3.1.2. Response Status-Line . . . . . . . . . . . . . . . . . 23 |  | 3.1.2. Response Status-Line . . . . . . . . . . . . . . . . . 23 |
| 3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 23 |  | 3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 23 |
| 3.2.1. Field Parsing . . . . . . . . . . . . . . . . . . . . 24 |  | 3.2.1. Field Parsing . . . . . . . . . . . . . . . . . . . . 25 |
| 3.2.2. Field Length . . . . . . . . . . . . . . . . . . . . . 25 |  | 3.2.2. Field Length . . . . . . . . . . . . . . . . . . . . . 25 |
| 3.2.3. Common Field ABNF Rules . . . . . . . . . . . . . . . 25 |  | 3.2.3. Common Field ABNF Rules . . . . . . . . . . . . . . . 26 |
| 3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 27 |  | 3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 27 |
| 3.4. Handling Incomplete Messages . . . . . . . . . . . . . . . 30 |  | 3.4. Handling Incomplete Messages . . . . . . . . . . . . . . . 30 |
| 3.5. Message Parsing Robustness . . . . . . . . . . . . . . . . 30 |  | 3.5. Message Parsing Robustness . . . . . . . . . . . . . . . . 31 |
| 4. Message Routing . . . . . . . . . . . . . . . . . . . . . . . 31 |  | 4. Message Routing . . . . . . . . . . . . . . . . . . . . . . . 31 |
| 4.1. Types of Request Target . . . . . . . . . . . . . . . . . 31 |  | 4.1. Types of Request Target . . . . . . . . . . . . . . . . . 31 |
| 4.2. The Resource Identified by a Request . . . . . . . . . . . 33 |  | 4.2. The Resource Identified by a Request . . . . . . . . . . . 33 |
| 4.3. Effective Request URI . . . . . . . . . . . . . . . . . . 34 |  | 4.3. Effective Request URI . . . . . . . . . . . . . . . . . . 34 |
| 5. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 35 |  | 5. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 35 |
| 5.1. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 35 |  | 5.1. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 35 |
| 5.1.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 36 |  | 5.1.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 36 |
| 5.1.2. Compression Codings . . . . . . . . . . . . . . . . . 38 |  | 5.1.2. Compression Codings . . . . . . . . . . . . . . . . . 38 |
| 5.1.3. Transfer Coding Registry . . . . . . . . . . . . . . . 39 |  | 5.1.3. Transfer Coding Registry . . . . . . . . . . . . . . . 39 |
| 5.2. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 39 |  | 5.2. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 39 |
| skipping to change at page 4, line 47 |  | skipping to change at page 4, line 47 |
| 10.1. Personal Information . . . . . . . . . . . . . . . . . . . 63 |  | 10.1. Personal Information . . . . . . . . . . . . . . . . . . . 63 |
| 10.2. Abuse of Server Log Information . . . . . . . . . . . . . 63 |  | 10.2. Abuse of Server Log Information . . . . . . . . . . . . . 63 |
| 10.3. Attacks Based On File and Path Names . . . . . . . . . . . 63 |  | 10.3. Attacks Based On File and Path Names . . . . . . . . . . . 63 |
| 10.4. DNS-related Attacks . . . . . . . . . . . . . . . . . . . 63 |  | 10.4. DNS-related Attacks . . . . . . . . . . . . . . . . . . . 63 |
| 10.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 64 |  | 10.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 64 |
| 10.6. Protocol Element Size Overflows . . . . . . . . . . . . . 64 |  | 10.6. Protocol Element Size Overflows . . . . . . . . . . . . . 64 |
| 10.7. Denial of Service Attacks on Proxies . . . . . . . . . . . 65 |  | 10.7. Denial of Service Attacks on Proxies . . . . . . . . . . . 65 |
| 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 65 |  | 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 65 |
| 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 66 |  | 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 66 |
| 12.1. Normative References . . . . . . . . . . . . . . . . . . . 66 |  | 12.1. Normative References . . . . . . . . . . . . . . . . . . . 66 |
| 12.2. Informative References . . . . . . . . . . . . . . . . . . 68 |  | 12.2. Informative References . . . . . . . . . . . . . . . . . . 67 |
| Appendix A. HTTP Version History . . . . . . . . . . . . . . . . 70 |  | Appendix A. HTTP Version History . . . . . . . . . . . . . . . . 69 |
| A.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 71 |  | A.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 70 |
| A.1.1. Multi-homed Web Servers . . . . . . . . . . . . . . . 71 |  | A.1.1. Multi-homed Web Servers . . . . . . . . . . . . . . . 70 |
| A.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 71 |  | A.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 71 |
| A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 72 |  | A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 71 |
| Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 73 |  | Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 72 |
| Appendix C. Change Log (to be removed by RFC Editor before |  | Appendix C. Change Log (to be removed by RFC Editor before |
| publication) . . . . . . . . . . . . . . . . . . . . 76 |  | publication) . . . . . . . . . . . . . . . . . . . . 75 |
| C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 76 |  | C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 75 |
| C.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 76 |  | C.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 75 |
| C.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 78 |  | C.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 77 |
| C.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 79 |  | C.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 78 |
| C.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 79 |  | C.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 78 |
| C.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 80 |  | C.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 79 |
| C.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 80 |  | C.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 79 |
| C.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 81 |  | C.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 80 |
| C.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 82 |  | C.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 81 |
| C.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 82 |  | C.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 82 |
| C.11. Since draft-ietf-httpbis-p1-messaging-09 . . . . . . . . . 83 |  | C.11. Since draft-ietf-httpbis-p1-messaging-09 . . . . . . . . . 82 |
| C.12. Since draft-ietf-httpbis-p1-messaging-10 . . . . . . . . . 83 |  | C.12. Since draft-ietf-httpbis-p1-messaging-10 . . . . . . . . . 82 |
| C.13. Since draft-ietf-httpbis-p1-messaging-11 . . . . . . . . . 84 |  | C.13. Since draft-ietf-httpbis-p1-messaging-11 . . . . . . . . . 83 |
| C.14. Since draft-ietf-httpbis-p1-messaging-12 . . . . . . . . . 84 |  | C.14. Since draft-ietf-httpbis-p1-messaging-12 . . . . . . . . . 83 |
| C.15. Since draft-ietf-httpbis-p1-messaging-13 . . . . . . . . . 85 |  | C.15. Since draft-ietf-httpbis-p1-messaging-13 . . . . . . . . . 84 |
| C.16. Since draft-ietf-httpbis-p1-messaging-14 . . . . . . . . . 85 |  | C.16. Since draft-ietf-httpbis-p1-messaging-14 . . . . . . . . . 84 |
| C.17. Since draft-ietf-httpbis-p1-messaging-15 . . . . . . . . . 85 |  | C.17. Since draft-ietf-httpbis-p1-messaging-15 . . . . . . . . . 85 |
| C.18. Since draft-ietf-httpbis-p1-messaging-16 . . . . . . . . . 86 |  | C.18. Since draft-ietf-httpbis-p1-messaging-16 . . . . . . . . . 85 |
|  |  | C.19. Since draft-ietf-httpbis-p1-messaging-17 . . . . . . . . . 85 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 |
| 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 27 |  | skipping to change at page 10, line 27 |
| 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 |
| originate authoritative responses to a request. For general |  | originate authoritative responses to a request. For general |
| requirements, we use the term "sender" to refer to whichever |  | requirements, we use the term "sender" to refer to whichever |
| component sent a given message and the term "recipient" to refer to |  | component sent a given message and the term "recipient" to refer to |
| any component that receives the message. |  | any component that receives the message. |
|  |  | Note: The term 'user agent' covers both those situations where |
|  |  | there is a user (human) interacting with the software agent (and |
|  |  | for which user interface or interactive suggestions might be made, |
|  |  | e.g., warning the user or given the user an option in the case of |
|  |  | security or privacy options) and also those where the software |
|  |  | agent may act autonomously. |
| Most HTTP communication consists of a retrieval request (GET) for a |  | Most HTTP communication consists of a retrieval request (GET) for a |
| representation of some resource identified by a URI. In the simplest |  | representation of some resource identified by a URI. In the simplest |
| case, this might be accomplished via a single bidirectional |  | case, this might be accomplished via a single bidirectional |
| connection (===) between the user agent (UA) and the origin server |  | connection (===) between the user agent (UA) and the origin server |
| (O). |  | (O). |
| request > |  | request > |
| UA ======================================= O |  | UA ======================================= O |
| < response |  | < response |
| skipping to change at page 11, line 6 |  | skipping to change at page 11, line 14 |
| A server responds to the client's request by sending an HTTP response |  | A server responds to the client's request by sending an HTTP response |
| message, beginning with a status line that includes the protocol |  | message, beginning with a status line that includes the protocol |
| version, a success or error code, and textual reason phrase |  | version, a success or error code, and textual reason phrase |
| (Section 3.1.2), followed by MIME-like header fields containing |  | (Section 3.1.2), followed by MIME-like header fields containing |
| server information, resource metadata, and payload metadata |  | server information, resource metadata, and payload metadata |
| (Section 3.2), an empty line to indicate the end of the header |  | (Section 3.2), an empty line to indicate the end of the header |
| section, and finally a message body containing the payload body (if |  | section, and finally a message body containing the payload body (if |
| any, Section 3.3). |  | any, Section 3.3). |
|  |  | Note that 1xx responses (Section 7.1 of [Part2]) are not final; |
|  |  | therefore, a server can send zero or more 1xx responses, followed by |
|  |  | exactly one final response (with any other status code). |
| The following example illustrates a typical message exchange for a |  | The following example illustrates a typical message exchange for a |
| GET request on the URI "http://www.example.com/hello.txt": |  | GET request on the URI "http://www.example.com/hello.txt": |
| client request: |  | client request: |
| GET /hello.txt HTTP/1.1 |  | GET /hello.txt HTTP/1.1 |
| User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 |  | User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 |
| Host: www.example.com |  | Host: www.example.com |
| Accept: */* |  | Accept: */* |
| skipping to change at page 33, line 18 |  | skipping to change at page 33, line 22 |
| Host: www.example.org:8001 |  | Host: www.example.org:8001 |
| after connecting to port 8001 of host "www.example.org". |  | after connecting to port 8001 of host "www.example.org". |
| The request-target is transmitted in the format specified in |  | The request-target is transmitted in the format specified in |
| Section 2.7.1. If the request-target is percent-encoded ([RFC3986], |  | Section 2.7.1. If the request-target is percent-encoded ([RFC3986], |
| Section 2.1), the origin server MUST decode the request-target in |  | Section 2.1), the origin server MUST decode the request-target in |
| order to properly interpret the request. Servers SHOULD respond to |  | order to properly interpret the request. Servers SHOULD respond to |
| invalid request-targets with an appropriate status code. |  | invalid request-targets with an appropriate status code. |
| A non-transforming proxy MUST NOT rewrite the "path-absolute" part of |  | A non-transforming proxy MUST NOT rewrite the "path-absolute" and |
| the received request-target when forwarding it to the next inbound |  | "query" parts of the received request-target when forwarding it to |
| server, except as noted above to replace a null path-absolute with |  | the next inbound server, except as noted above to replace a null |
| "/" or "*". |  | path-absolute with "/" or "*". |
| Note: The "no rewrite" rule prevents the proxy from changing the |  | Note: The "no rewrite" rule prevents the proxy from changing the |
| meaning of the request when the origin server is improperly using |  | meaning of the request when the origin server is improperly using |
| a non-reserved URI character for a reserved purpose. Implementors |  | a non-reserved URI character for a reserved purpose. Implementors |
| need to be aware that some pre-HTTP/1.1 proxies have been known to |  | need to be aware that some pre-HTTP/1.1 proxies have been known to |
| rewrite the request-target. |  | rewrite the request-target. |
| 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 |
| skipping to change at page 34, line 26 |  | skipping to change at page 34, line 30 |
| HTTP requests often do not carry the absolute URI ([RFC3986], Section |  | HTTP requests often do not carry the absolute URI ([RFC3986], Section |
| 4.3) for the target resource; instead, the URI needs to be inferred |  | 4.3) for the target resource; instead, the URI needs to be inferred |
| from the request-target, Host header field, and connection context. |  | from the request-target, Host header field, and connection context. |
| The result of this process is called the "effective request URI". |  | The result of this process is called the "effective request URI". |
| The "target resource" is the resource identified by the effective |  | The "target resource" is the resource identified by the effective |
| request URI. |  | request URI. |
| If the request-target is an absolute-URI, then the effective request |  | If the request-target is an absolute-URI, then the effective request |
| URI is the request-target. |  | URI is the request-target. |
| If the request-target uses the path-absolute form or the asterisk |  | If the request-target uses the origin form or the asterisk form, and |
| form, and the Host header field is present, then the effective |  | the Host header field is present, then the effective request URI is |
| request URI is constructed by concatenating |  | constructed by concatenating |
| o the scheme name: "http" if the request was received over an |  | o the scheme name: "http" if the request was received over an |
| insecure TCP connection, or "https" when received over a SSL/ |  | insecure TCP connection, or "https" when received over a SSL/ |
| TLS-secured TCP connection, |  | TLS-secured TCP connection, |
| o the octet sequence "://", |  | o the octet sequence "://", |
| o the authority component, as specified in the Host header field |  | o the authority component, as specified in the Host header field |
| (Section 8.3), and |  | (Section 8.3), and |
| o the request-target obtained from the Request-Line, unless the |  | o the request-target obtained from the Request-Line, unless the |
| request-target is just the asterisk "*". |  | request-target is just the asterisk "*". |
| If the request-target uses the path-absolute form or the asterisk |  | If the request-target uses the origin form or the asterisk form, and |
| form, and the Host header field is not present, then the effective |  | the Host header field is not present, then the effective request URI |
| request URI is undefined. |  | is undefined. |
| Otherwise, when request-target uses the authority form, the effective |  | Otherwise, when request-target uses the authority form, the effective |
| request URI is undefined. |  | request URI is undefined. |
| Example 1: the effective request URI for the message |  | Example 1: the effective request URI for the message |
| 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 "://", |
| skipping to change at page 65, line 37 |  | skipping to change at page 65, line 37 |
| smart questions, drafting and reviewing text, and discussing open |  | smart questions, drafting and reviewing text, and discussing open |
| issues: |  | issues: |
| Adam Barth, Adam Roach, Addison Phillips, Adrian Chadd, Adrien de |  | Adam Barth, Adam Roach, Addison Phillips, Adrian Chadd, Adrien de |
| Croy, Alan Ford, Alan Ruttenberg, Albert Lunde, Alex Rousskov, Alexey |  | Croy, Alan Ford, Alan Ruttenberg, Albert Lunde, Alex Rousskov, Alexey |
| Melnikov, Alisha Smith, Amichai Rothman, Amit Klein, Amos Jeffries, |  | Melnikov, Alisha Smith, Amichai Rothman, Amit Klein, Amos Jeffries, |
| Andreas Maier, Andreas Petersson, Anne van Kesteren, Anthony Bryan, |  | Andreas Maier, Andreas Petersson, Anne van Kesteren, Anthony Bryan, |
| Asbjorn Ulsberg, Balachander Krishnamurthy, Barry Leiba, Ben Laurie, |  | Asbjorn Ulsberg, Balachander Krishnamurthy, Barry Leiba, Ben Laurie, |
| Benjamin Niven-Jenkins, Bil Corry, Bill Burke, Bjoern Hoehrmann, Bob |  | Benjamin Niven-Jenkins, Bil Corry, Bill Burke, Bjoern Hoehrmann, Bob |
| Scheifler, Boris Zbarsky, Brett Slatkin, Brian Kell, Brian McBarron, |  | Scheifler, Boris Zbarsky, Brett Slatkin, Brian Kell, Brian McBarron, |
| Brian Pane, Brian Smith, Bryce Nesbitt, Carl Kugler, Charles Fry, |  | Brian Pane, Brian Smith, Bryce Nesbitt, Cameron Heavon-Jones, Carl |
| Chris Newman, Cyrus Daboo, Dale Robert Anderson, Dan Winship, Daniel |  | Kugler, Charles Fry, Chris Newman, Cyrus Daboo, Dale Robert Anderson, |
| Stenberg, Dave Cridland, Dave Crocker, Dave Kristol, David Booth, |  | Dan Winship, Daniel Stenberg, Dave Cridland, Dave Crocker, Dave |
| David Singer, David W. Morris, Diwakar Shetty, Drummond Reed, Duane |  | Kristol, David Booth, David Singer, David W. Morris, Diwakar Shetty, |
| Wessels, Edward Lee, Eliot Lear, Eran Hammer-Lahav, Eric D. Williams, |  | Dmitry Kurochkin, Drummond Reed, Duane Wessels, Edward Lee, Eliot |
| Eric J. Bowman, Eric Lawrence, Erik Aronesty, Florian Weimer, Frank |  | Lear, Eran Hammer-Lahav, Eric D. Williams, Eric J. Bowman, Eric |
| Ellermann, Fred Bohle, Geoffrey Sneddon, Gervase Markham, Greg |  | Lawrence, Erik Aronesty, Florian Weimer, Frank Ellermann, Fred Bohle, |
| Wilkins, Harald Tveit Alvestrand, Harry Halpin, Helge Hess, Henrik |  | Geoffrey Sneddon, Gervase Markham, Greg Wilkins, Harald Tveit |
| Nordstrom, Henry S. Thompson, Henry Story, Howard Melman, Hugo Haas, |  | Alvestrand, Harry Halpin, Helge Hess, Henrik Nordstrom, Henry S. |
| Ian Hickson, Ingo Struck, J. Ross Nicoll, James H. Manger, James |  | Thompson, Henry Story, Herbert van de Sompel, Howard Melman, Hugo |
| Lacey, James M. Snell, Jamie Lokier, Jan Algermissen, Jeff Hodges |  | Haas, Ian Hickson, Ingo Struck, J. Ross Nicoll, James H. Manger, |
| (for coming up with the term 'effective Request-URI'), Jeff Walden, |  | James Lacey, James M. Snell, Jamie Lokier, Jan Algermissen, Jeff |
| Jim Luther, Joe D. Williams, Joe Gregorio, Joe Orton, John C. |  | Hodges (for coming up with the term 'effective Request-URI'), Jeff |
|  |  | Walden, Jim Luther, Joe D. Williams, Joe Gregorio, Joe Orton, John C. |
| Klensin, John C. Mallery, John Cowan, John Kemp, John Panzer, John |  | Klensin, John C. Mallery, John Cowan, John Kemp, John Panzer, John |
| Schneider, John Stracke, Jonas Sicking, Jonathan Moore, Jonathan |  | Schneider, John Stracke, Jonas Sicking, Jonathan Moore, Jonathan |
| Rees, Jordi Ros, Joris Dobbelsteen, Josh Cohen, Julien Pierre, |  | Rees, Jordi Ros, Joris Dobbelsteen, Josh Cohen, Julien Pierre, |
| Jungshik Shin, Justin Chapweske, Justin Erenkrantz, Justin James, |  | Jungshik Shin, Justin Chapweske, Justin Erenkrantz, Justin James, |
| Kalvinder Singh, Karl Dubost, Keith Hoffman, Keith Moore, Koen |  | Kalvinder Singh, Karl Dubost, Keith Hoffman, Keith Moore, Koen |
| Holtman, Konstantin Voronkov, Kris Zyp, Lisa Dusseault, Maciej |  | Holtman, Konstantin Voronkov, Kris Zyp, Lisa Dusseault, Maciej |
| Stachowiak, Marc Schneider, Marc Slemko, Mark Baker, Mark Nottingham |  | Stachowiak, Marc Schneider, Marc Slemko, Mark Baker, Mark Nottingham |
| (Working Group chair), Mark Pauley, Martin J. Duerst, Martin Thomson, |  | (Working Group chair), Mark Pauley, Martin J. Duerst, Martin Thomson, |
| Matt Lynch, Matthew Cox, Max Clark, Michael Burrows, Michael |  | Matt Lynch, Matthew Cox, Max Clark, Michael Burrows, Michael |
| Hausenblas, Mike Amundsen, Mike Kelly, Mike Schinkel, Miles Sabin, |  | Hausenblas, Mike Amundsen, Mike Kelly, Mike Schinkel, Miles Sabin, |
| skipping to change at page 66, line 41 |  | skipping to change at page 66, line 42 |
| 12.1. Normative References |  | 12.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-17 (work in |  | Semantics", draft-ietf-httpbis-p2-semantics-18 (work in |
| progress), October 2011. |  | progress), January 2012. |
| [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-17 (work in progress), |  | draft-ietf-httpbis-p3-payload-18 (work in progress), |
| October 2011. |  | January 2012. |
| [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-17 (work in progress), |  | draft-ietf-httpbis-p6-cache-18 (work in progress), |
| October 2011. |  | January 2012. |
| [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 |  |  |
| stable than this specification. On the other hand, |  |  |
| this downward reference was present since the |  |  |
| publication of RFC 2068 in 1997, therefore it is |  |  |
| unlikely to cause problems in practice. See also |  |  |
| [BCP97]. |  |  |
| [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format |  | [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format |
| Specification version 1.3", RFC 1951, May 1996. |  | Specification version 1.3", RFC 1951, May 1996. |
| RFC 1951 is an Informational RFC, thus it might be less |  |  |
| stable than this specification. On the other hand, |  |  |
| this downward reference was present since the |  |  |
| publication of RFC 2068 in 1997, therefore it is |  |  |
| unlikely to cause problems in practice. See also |  |  |
| [BCP97]. |  |  |
| [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and |  | [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and |
| G. Randers-Pehrson, "GZIP file format specification |  | G. Randers-Pehrson, "GZIP file format specification |
| version 4.3", RFC 1952, May 1996. |  | version 4.3", RFC 1952, May 1996. |
| RFC 1952 is an Informational RFC, thus it might be less |  |  |
| stable than this specification. On the other hand, |  |  |
| this downward reference was present since the |  |  |
| publication of RFC 2068 in 1997, therefore it is |  |  |
| unlikely to cause problems in practice. See also |  |  |
| [BCP97]. |  |  |
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |  | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |
| Requirement Levels", BCP 14, RFC 2119, March 1997. |  | Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, |  | [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, |
| "Uniform Resource Identifier (URI): Generic Syntax", |  | "Uniform Resource Identifier (URI): Generic Syntax", |
| STD 66, RFC 3986, January 2005. |  | STD 66, RFC 3986, January 2005. |
| [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for |  | [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for |
| Syntax Specifications: ABNF", STD 68, RFC 5234, |  | Syntax Specifications: ABNF", STD 68, RFC 5234, |
| January 2008. |  | January 2008. |
| [USASCII] American National Standards Institute, "Coded Character |  | [USASCII] American National Standards Institute, "Coded Character |
| Set -- 7-bit American Standard Code for Information |  | Set -- 7-bit American Standard Code for Information |
| Interchange", ANSI X3.4, 1986. |  | Interchange", ANSI X3.4, 1986. |
| 12.2. Informative References |  | 12.2. Informative References |
| [BCP97] Klensin, J. and S. Hartman, "Handling Normative |  |  |
| References to Standards-Track Documents", BCP 97, |  |  |
| RFC 4897, June 2007. |  |  |
| [Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and |  | [Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and |
| Politics", ACM Transactions on Internet Technology Vol. |  | Politics", ACM Transactions on Internet Technology Vol. |
| 1, #2, November 2001, |  | 1, #2, November 2001, |
| <http://arxiv.org/abs/cs.SE/0105018>. |  | <http://arxiv.org/abs/cs.SE/0105018>. |
| [Nie1997] Frystyk, H., Gettys, J., Prud'hommeaux, E., Lie, H., |  | [Nie1997] Frystyk, H., Gettys, J., Prud'hommeaux, E., Lie, H., |
| and C. Lilley, "Network Performance Effects of |  | and C. Lilley, "Network Performance Effects of |
| HTTP/1.1, CSS1, and PNG", ACM Proceedings of the ACM |  | HTTP/1.1, CSS1, and PNG", ACM Proceedings of the ACM |
| SIGCOMM '97 conference on Applications, technologies, |  | SIGCOMM '97 conference on Applications, technologies, |
| architectures, and protocols for computer communication |  | architectures, and protocols for computer communication |
| skipping to change at page 71, line 31 |  | skipping to change at page 71, line 8 |
| 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. |
| A.1.2. Keep-Alive Connections |  | A.1.2. Keep-Alive Connections |
| For most implementations of HTTP/1.0, each connection is established |  | In HTTP/1.0, each connection is established by the client prior to |
| by the client prior to the request and closed by the server after |  | the request and closed by the server after sending the response. |
| sending the response. However, some implementations implement the |  | However, some implementations implement the explicitly negotiated |
| 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 these |
| previous implementations of persistent connections in HTTP/1.0 |  | previous approaches to persistent connections, by explicitly |
| clients and servers. Persistent connections in HTTP/1.0 are |  | negotiating for them with a "Connection: keep-alive" request header |
| explicitly negotiated as they are not the default behavior. HTTP/1.0 |  | field. However, some experimental implementations of HTTP/1.0 |
| experimental implementations of persistent connections are faulty, |  | persistent connections are faulty; for example, if a HTTP/1.0 proxy |
| and the new facilities in HTTP/1.1 are designed to rectify these |  | server doesn't understand Connection, it will erroneously forward |
| problems. The problem was that some existing HTTP/1.0 clients might |  | that header to the next inbound server, which would result in a hung |
| send Keep-Alive to a proxy server that doesn't understand Connection, |  | connection. |
| which would then erroneously forward it to the next inbound server, |  |  |
| which would establish the Keep-Alive connection and result in a hung |  |  |
| HTTP/1.0 proxy waiting for the close on the response. The result is |  |  |
| that HTTP/1.0 clients must be prevented from using Keep-Alive when |  |  |
| talking to proxies. |  |  |
| However, talking to proxies is the most important use of persistent |  | One attempted solution was the introduction of a Proxy-Connection |
| connections, so that prohibition is clearly unacceptable. Therefore, |  | header, targeted specifically at proxies. In practice, this was also |
| we need some other mechanism for indicating a persistent connection |  | unworkable, because proxies are often deployed in multiple layers, |
| is desired, which is safe to use even when talking to an old proxy |  | bringing about the same problem discussed above. |
| that ignores Connection. Persistent connections are the default for |  |  |
| HTTP/1.1 messages; we introduce a new keyword (Connection: close) for |  | As a result, clients are encouraged not to send the Proxy-Connection |
| declaring non-persistence. See Section 8.1. |  | header in any requests. |
|  |  | Clients are also encouraged to consider the use of Connection: keep- |
|  |  | alive in requests carefully; while they can enable persistent |
|  |  | connections with HTTP/1.0 servers, clients using them need will need |
|  |  | to monitor the connection for "hung" requests (which indicate that |
|  |  | the client ought stop sending the header), and this mechanism ought |
|  |  | not be used by clients at all when a proxy is being used. |
| A.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. (Section 1.2.2) |  | specifically pointed out in the ABNF. (Section 1.2.2) |
| skipping to change at page 86, line 30 |  | skipping to change at page 85, line 43 |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/219>: "Revise |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/219>: "Revise |
| Acknowledgements Sections" |  | Acknowledgements Sections" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/297>: "Retrying |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/297>: "Retrying |
| Requests" |  | Requests" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/318>: "Closing the |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/318>: "Closing the |
| connection on server error" |  | connection on server error" |
|  |  | C.19. Since draft-ietf-httpbis-p1-messaging-17 |
|  |  | Closed issues: |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/166>: "Clarify 'User |
|  |  | Agent'" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/300>: "Define non- |
|  |  | final responses" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/323>: "intended |
|  |  | maturity level vs normative references" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/324>: "Intermediary |
|  |  | rewriting of queries" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/158>: "Proxy- |
|  |  | Connection and Keep-Alive" |
| Index |  | Index |
| A |  | A |
| absolute-URI form (of request-target) 31 |  | absolute-URI form (of request-target) 32 |
| accelerator 13 |  | accelerator 13 |
| application/http Media Type 61 |  | application/http Media Type 61 |
| asterisk form (of request-target) 31 |  | asterisk form (of request-target) 31 |
| authority form (of request-target) 32 |  | authority form (of request-target) 32 |
| B |  | B |
| browser 10 |  | browser 10 |
| C |  | C |
| cache 14 |  | cache 14 |
| skipping to change at page 87, line 20 |  | skipping to change at page 86, line 52 |
| D |  | D |
| deflate (Coding Format) 38 |  | deflate (Coding Format) 38 |
| downstream 13 |  | downstream 13 |
| E |  | E |
| effective request URI 34 |  | effective request URI 34 |
| G |  | G |
| gateway 13 |  | gateway 13 |
| Grammar |  | Grammar |
| absolute-URI 17 |  | absolute-URI 18 |
| ALPHA 7 |  | ALPHA 7 |
| attribute 35 |  | attribute 35 |
| authority 17 |  | authority 18 |
| BWS 9 |  | BWS 9 |
| chunk 36 |  | chunk 36 |
| chunk-data 36 |  | chunk-data 36 |
| chunk-ext 36 |  | chunk-ext 36 |
| chunk-ext-name 36 |  | chunk-ext-name 36 |
| chunk-ext-val 36 |  | chunk-ext-val 36 |
| chunk-size 36 |  | chunk-size 36 |
| Chunked-Body 36 |  | Chunked-Body 36 |
| comment 26 |  | comment 26 |
| Connection 50 |  | Connection 50 |
| skipping to change at page 88, line 6 |  | skipping to change at page 87, line 38 |
| field-name 23 |  | field-name 23 |
| field-value 23 |  | field-value 23 |
| header-field 23 |  | header-field 23 |
| HEXDIG 7 |  | HEXDIG 7 |
| Host 52 |  | Host 52 |
| HTAB 7 |  | HTAB 7 |
| 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 20 |
| last-chunk 36 |  | last-chunk 36 |
| LF 7 |  | LF 7 |
| message-body 27 |  | message-body 27 |
| Method 22 |  | Method 22 |
| obs-text 26 |  | obs-text 26 |
| OCTET 7 |  | OCTET 7 |
| OWS 9 |  | OWS 9 |
| path-absolute 17 |  | path-absolute 18 |
| port 17 |  | port 18 |
| product 39 |  | product 39 |
| product-version 39 |  | product-version 39 |
| protocol-name 57 |  | protocol-name 57 |
| protocol-version 57 |  | protocol-version 57 |
| pseudonym 57 |  | pseudonym 57 |
| qdtext 26 |  | qdtext 26 |
| qdtext-nf 36 |  | qdtext-nf 36 |
| query 17 |  | query 18 |
| quoted-cpair 26 |  | quoted-cpair 27 |
| quoted-pair 26 |  | quoted-pair 26 |
| quoted-str-nf 36 |  | quoted-str-nf 36 |
| quoted-string 26 |  | quoted-string 26 |
| qvalue 40 |  | qvalue 40 |
| Reason-Phrase 23 |  | Reason-Phrase 23 |
| received-by 57 |  | received-by 57 |
| received-protocol 57 |  | received-protocol 57 |
| Request-Line 22 |  | Request-Line 22 |
| request-target 22 |  | request-target 22 |
| RWS 9 |  | RWS 9 |
| skipping to change at page 89, line 5 |  | skipping to change at page 88, line 37 |
| te-ext 53 |  | te-ext 53 |
| te-params 53 |  | te-params 53 |
| token 26 |  | token 26 |
| Trailer 54 |  | Trailer 54 |
| trailer-part 36 |  | trailer-part 36 |
| transfer-coding 35 |  | transfer-coding 35 |
| Transfer-Encoding 54 |  | Transfer-Encoding 54 |
| transfer-extension 35 |  | transfer-extension 35 |
| transfer-parameter 35 |  | transfer-parameter 35 |
| Upgrade 55 |  | Upgrade 55 |
| uri-host 17 |  | uri-host 18 |
| URI-reference 17 |  | URI-reference 18 |
| value 35 |  | value 35 |
| VCHAR 7 |  | VCHAR 7 |
| Via 57 |  | Via 57 |
| word 26 |  | word 26 |
| gzip (Coding Format) 39 |  | gzip (Coding Format) 39 |
| H |  | H |
| header field 20 |  | header field 21 |
| Header Fields |  | Header Fields |
| Connection 49 |  | Connection 49 |
| Content-Length 51 |  | Content-Length 51 |
| Host 51 |  | Host 51 |
| TE 53 |  | TE 53 |
| Trailer 54 |  | Trailer 54 |
| Transfer-Encoding 54 |  | Transfer-Encoding 54 |
| Upgrade 55 |  | Upgrade 55 |
| Via 57 |  | Via 57 |
| header section 20 |  | header section 21 |
| headers 20 |  | headers 21 |
| Host header field 51 |  | Host header field 51 |
| http URI scheme 18 |  | http URI scheme 18 |
| https URI scheme 19 |  | https URI scheme 19 |
| I |  | I |
| inbound 13 |  | inbound 13 |
| interception proxy 14 |  | interception proxy 14 |
| intermediary 12 |  | intermediary 12 |
| M |  | M |
End of changes. 41 change blocks.
| 124 lines changed or deleted |  | 133 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/