| draft-ietf-httpbis-p1-messaging-22.txt |  | draft-ietf-httpbis-p1-messaging-23.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. Reschke, Ed. |  | Obsoletes: 2145,2616 (if approved) J. Reschke, Ed. |
| Updates: 2817,2818 (if approved) greenbytes |  | Updates: 2817,2818 (if approved) greenbytes |
| Intended status: Standards Track February 23, 2013 |  | Intended status: Standards Track July 15, 2013 |
| Expires: August 27, 2013 |  | Expires: January 16, 2014 |
| Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing |  | Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing |
| draft-ietf-httpbis-p1-messaging-22 |  | draft-ietf-httpbis-p1-messaging-23 |
| 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 provides an |  | information initiative since 1990. This document provides an |
| overview of HTTP architecture and its associated terminology, defines |  | overview of HTTP architecture and its associated terminology, defines |
| the "http" and "https" Uniform Resource Identifier (URI) schemes, |  | the "http" and "https" Uniform Resource Identifier (URI) schemes, |
| defines the HTTP/1.1 message syntax and parsing requirements, and |  | defines the HTTP/1.1 message syntax and parsing requirements, and |
| skipping to change at page 1, line 35 |  | skipping to change at page 1, line 35 |
| Discussion of this draft takes place on the HTTPBIS working group |  | Discussion of this draft takes place on the HTTPBIS working group |
| mailing list (ietf-http-wg@w3.org), which is archived at |  | mailing list (ietf-http-wg@w3.org), which is archived at |
| <http://lists.w3.org/Archives/Public/ietf-http-wg/>. |  | <http://lists.w3.org/Archives/Public/ietf-http-wg/>. |
| The current issues list is at |  | The current issues list is at |
| <http://tools.ietf.org/wg/httpbis/trac/report/3> and related |  | <http://tools.ietf.org/wg/httpbis/trac/report/3> and related |
| documents (including fancy diffs) can be found at |  | documents (including fancy diffs) can be found at |
| <http://tools.ietf.org/wg/httpbis/>. |  | <http://tools.ietf.org/wg/httpbis/>. |
| The changes in this draft are summarized in Appendix D.2. |  | The changes in this draft are summarized in Appendix D.3. |
| 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 August 27, 2013. |  | This Internet-Draft will expire on January 16, 2014. |
| Copyright Notice |  | Copyright Notice |
| Copyright (c) 2013 IETF Trust and the persons identified as the |  | Copyright (c) 2013 IETF Trust and the persons identified as the |
| document authors. All rights reserved. |  | document authors. All rights reserved. |
| This document is subject to BCP 78 and the IETF Trust's Legal |  | This document is subject to BCP 78 and the IETF Trust's Legal |
| Provisions Relating to IETF Documents |  | Provisions Relating to IETF Documents |
| (http://trustee.ietf.org/license-info) in effect on the date of |  | (http://trustee.ietf.org/license-info) in effect on the date of |
| publication of this document. Please review these documents |  | publication of this document. Please review these documents |
| skipping to change at page 3, line 4 |  | skipping to change at page 3, line 4 |
| 2.2. Implementation Diversity . . . . . . . . . . . . . . . . . 8 |  | 2.2. Implementation Diversity . . . . . . . . . . . . . . . . . 8 |
| 2.3. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 9 |  | 2.3. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 9 |
| 2.4. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 11 |  | 2.4. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 11 |
| 2.5. Conformance and Error Handling . . . . . . . . . . . . . . 12 |  | 2.5. Conformance and Error Handling . . . . . . . . . . . . . . 12 |
| 2.6. Protocol Versioning . . . . . . . . . . . . . . . . . . . 13 |  | 2.6. Protocol Versioning . . . . . . . . . . . . . . . . . . . 13 |
| 2.7. Uniform Resource Identifiers . . . . . . . . . . . . . . . 15 |  | 2.7. Uniform Resource Identifiers . . . . . . . . . . . . . . . 15 |
| 2.7.1. http URI scheme . . . . . . . . . . . . . . . . . . . 16 |  | 2.7.1. http URI scheme . . . . . . . . . . . . . . . . . . . 16 |
| 2.7.2. https URI scheme . . . . . . . . . . . . . . . . . . . 17 |  | 2.7.2. https URI scheme . . . . . . . . . . . . . . . . . . . 17 |
| 2.7.3. http and https URI Normalization and Comparison . . . 18 |  | 2.7.3. http and https URI Normalization and Comparison . . . 18 |
| 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 19 |  | 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 19 |
| 3.1. Start Line . . . . . . . . . . . . . . . . . . . . . . . . 19 |  | 3.1. Start Line . . . . . . . . . . . . . . . . . . . . . . . . 20 |
| 3.1.1. Request Line . . . . . . . . . . . . . . . . . . . . . 20 |  | 3.1.1. Request Line . . . . . . . . . . . . . . . . . . . . . 20 |
| 3.1.2. Status Line . . . . . . . . . . . . . . . . . . . . . 21 |  | 3.1.2. Status Line . . . . . . . . . . . . . . . . . . . . . 21 |
| 3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 22 |  | 3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 22 |
| 3.2.1. Field Extensibility . . . . . . . . . . . . . . . . . 22 |  | 3.2.1. Field Extensibility . . . . . . . . . . . . . . . . . 22 |
| 3.2.2. Field Order . . . . . . . . . . . . . . . . . . . . . 22 |  | 3.2.2. Field Order . . . . . . . . . . . . . . . . . . . . . 22 |
| 3.2.3. Whitespace . . . . . . . . . . . . . . . . . . . . . . 23 |  | 3.2.3. Whitespace . . . . . . . . . . . . . . . . . . . . . . 23 |
| 3.2.4. Field Parsing . . . . . . . . . . . . . . . . . . . . 24 |  | 3.2.4. Field Parsing . . . . . . . . . . . . . . . . . . . . 24 |
| 3.2.5. Field Limits . . . . . . . . . . . . . . . . . . . . . 25 |  | 3.2.5. Field Limits . . . . . . . . . . . . . . . . . . . . . 25 |
| 3.2.6. Field value components . . . . . . . . . . . . . . . . 25 |  | 3.2.6. Field value components . . . . . . . . . . . . . . . . 25 |
| 3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 26 |  | 3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 27 |
| 3.3.1. Transfer-Encoding . . . . . . . . . . . . . . . . . . 27 |  | 3.3.1. Transfer-Encoding . . . . . . . . . . . . . . . . . . 27 |
| 3.3.2. Content-Length . . . . . . . . . . . . . . . . . . . . 28 |  | 3.3.2. Content-Length . . . . . . . . . . . . . . . . . . . . 29 |
| 3.3.3. Message Body Length . . . . . . . . . . . . . . . . . 30 |  | 3.3.3. Message Body Length . . . . . . . . . . . . . . . . . 30 |
| 3.4. Handling Incomplete Messages . . . . . . . . . . . . . . . 32 |  | 3.4. Handling Incomplete Messages . . . . . . . . . . . . . . . 32 |
| 3.5. Message Parsing Robustness . . . . . . . . . . . . . . . . 33 |  | 3.5. Message Parsing Robustness . . . . . . . . . . . . . . . . 33 |
| 4. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . . 33 |  | 4. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . . 34 |
| 4.1. Chunked Transfer Coding . . . . . . . . . . . . . . . . . 34 |  | 4.1. Chunked Transfer Coding . . . . . . . . . . . . . . . . . 34 |
| 4.1.1. Trailer . . . . . . . . . . . . . . . . . . . . . . . 35 |  | 4.1.1. Trailer . . . . . . . . . . . . . . . . . . . . . . . 35 |
| 4.1.2. Decoding chunked . . . . . . . . . . . . . . . . . . . 36 |  | 4.1.2. Decoding chunked . . . . . . . . . . . . . . . . . . . 36 |
| 4.2. Compression Codings . . . . . . . . . . . . . . . . . . . 37 |  | 4.2. Compression Codings . . . . . . . . . . . . . . . . . . . 37 |
| 4.2.1. Compress Coding . . . . . . . . . . . . . . . . . . . 37 |  | 4.2.1. Compress Coding . . . . . . . . . . . . . . . . . . . 37 |
| 4.2.2. Deflate Coding . . . . . . . . . . . . . . . . . . . . 37 |  | 4.2.2. Deflate Coding . . . . . . . . . . . . . . . . . . . . 37 |
| 4.2.3. Gzip Coding . . . . . . . . . . . . . . . . . . . . . 37 |  | 4.2.3. Gzip Coding . . . . . . . . . . . . . . . . . . . . . 37 |
| 4.3. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 |  | 4.3. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 |
| 5. Message Routing . . . . . . . . . . . . . . . . . . . . . . . 38 |  | 5. Message Routing . . . . . . . . . . . . . . . . . . . . . . . 38 |
| 5.1. Identifying a Target Resource . . . . . . . . . . . . . . 38 |  | 5.1. Identifying a Target Resource . . . . . . . . . . . . . . 38 |
| skipping to change at page 3, line 43 |  | skipping to change at page 3, line 43 |
| 5.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 |  | 5.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 |
| 5.5. Effective Request URI . . . . . . . . . . . . . . . . . . 43 |  | 5.5. Effective Request URI . . . . . . . . . . . . . . . . . . 43 |
| 5.6. Associating a Response to a Request . . . . . . . . . . . 44 |  | 5.6. Associating a Response to a Request . . . . . . . . . . . 44 |
| 5.7. Message Forwarding . . . . . . . . . . . . . . . . . . . . 44 |  | 5.7. Message Forwarding . . . . . . . . . . . . . . . . . . . . 44 |
| 5.7.1. Via . . . . . . . . . . . . . . . . . . . . . . . . . 45 |  | 5.7.1. Via . . . . . . . . . . . . . . . . . . . . . . . . . 45 |
| 5.7.2. Transformations . . . . . . . . . . . . . . . . . . . 46 |  | 5.7.2. Transformations . . . . . . . . . . . . . . . . . . . 46 |
| 6. Connection Management . . . . . . . . . . . . . . . . . . . . 47 |  | 6. Connection Management . . . . . . . . . . . . . . . . . . . . 47 |
| 6.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 48 |  | 6.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 48 |
| 6.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 49 |  | 6.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 49 |
| 6.3. Persistence . . . . . . . . . . . . . . . . . . . . . . . 49 |  | 6.3. Persistence . . . . . . . . . . . . . . . . . . . . . . . 49 |
| 6.3.1. Retrying Requests . . . . . . . . . . . . . . . . . . 50 |  | 6.3.1. Retrying Requests . . . . . . . . . . . . . . . . . . 51 |
| 6.3.2. Pipelining . . . . . . . . . . . . . . . . . . . . . . 51 |  | 6.3.2. Pipelining . . . . . . . . . . . . . . . . . . . . . . 51 |
| 6.4. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 52 |  | 6.4. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 52 |
| 6.5. Failures and Time-outs . . . . . . . . . . . . . . . . . . 52 |  | 6.5. Failures and Time-outs . . . . . . . . . . . . . . . . . . 52 |
| 6.6. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 53 |  | 6.6. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 53 |
| 6.7. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 54 |  | 6.7. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 54 |
| 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55 |  | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56 |
| 7.1. Header Field Registration . . . . . . . . . . . . . . . . 55 |  | 7.1. Header Field Registration . . . . . . . . . . . . . . . . 56 |
| 7.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 56 |  | 7.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 57 |
| 7.3. Internet Media Type Registration . . . . . . . . . . . . . 56 |  | 7.3. Internet Media Type Registration . . . . . . . . . . . . . 57 |
| 7.3.1. Internet Media Type message/http . . . . . . . . . . . 57 |  | 7.3.1. Internet Media Type message/http . . . . . . . . . . . 57 |
| 7.3.2. Internet Media Type application/http . . . . . . . . . 58 |  | 7.3.2. Internet Media Type application/http . . . . . . . . . 58 |
| 7.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 59 |  | 7.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 60 |
| 7.5. Transfer Coding Registration . . . . . . . . . . . . . . . 59 |  | 7.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 60 |
| 7.6. Upgrade Token Registry . . . . . . . . . . . . . . . . . . 60 |  | 7.4.2. Registration . . . . . . . . . . . . . . . . . . . . . 60 |
| 7.7. Upgrade Token Registration . . . . . . . . . . . . . . . . 61 |  | 7.5. Upgrade Token Registry . . . . . . . . . . . . . . . . . . 61 |
| 8. Security Considerations . . . . . . . . . . . . . . . . . . . 61 |  | 7.5.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 61 |
| 8.1. DNS-related Attacks . . . . . . . . . . . . . . . . . . . 61 |  | 7.5.2. Upgrade Token Registration . . . . . . . . . . . . . . 61 |
| 8.2. Intermediaries and Caching . . . . . . . . . . . . . . . . 61 |  | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 62 |
| 8.3. Buffer Overflows . . . . . . . . . . . . . . . . . . . . . 62 |  | 8.1. DNS-related Attacks . . . . . . . . . . . . . . . . . . . 62 |
| 8.4. Message Integrity . . . . . . . . . . . . . . . . . . . . 62 |  | 8.2. Intermediaries and Caching . . . . . . . . . . . . . . . . 62 |
| 8.5. Server Log Information . . . . . . . . . . . . . . . . . . 63 |  | 8.3. Buffer Overflows . . . . . . . . . . . . . . . . . . . . . 63 |
| 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 63 |  | 8.4. Message Integrity . . . . . . . . . . . . . . . . . . . . 63 |
| 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 65 |  | 8.5. Server Log Information . . . . . . . . . . . . . . . . . . 64 |
| 10.1. Normative References . . . . . . . . . . . . . . . . . . . 65 |  | 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 64 |
| 10.2. Informative References . . . . . . . . . . . . . . . . . . 66 |  | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 66 |
| Appendix A. HTTP Version History . . . . . . . . . . . . . . . . 68 |  | 10.1. Normative References . . . . . . . . . . . . . . . . . . . 66 |
| A.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 69 |  | 10.2. Informative References . . . . . . . . . . . . . . . . . . 67 |
| A.1.1. Multi-homed Web Servers . . . . . . . . . . . . . . . 69 |  | Appendix A. HTTP Version History . . . . . . . . . . . . . . . . 69 |
| A.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 69 |  | A.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 70 |
| A.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 70 |  | A.1.1. Multi-homed Web Servers . . . . . . . . . . . . . . . 70 |
| A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 70 |  | A.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 70 |
| Appendix B. ABNF list extension: #rule . . . . . . . . . . . . . 72 |  | A.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 71 |
| Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 73 |  | A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 71 |
|  |  | Appendix B. ABNF list extension: #rule . . . . . . . . . . . . . 74 |
|  |  | Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 75 |
| Appendix D. Change Log (to be removed by RFC Editor before |  | Appendix D. Change Log (to be removed by RFC Editor before |
| publication) . . . . . . . . . . . . . . . . . . . . 76 |  | publication) . . . . . . . . . . . . . . . . . . . . 77 |
| D.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 76 |  | D.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 77 |
| D.2. Since draft-ietf-httpbis-p1-messaging-21 . . . . . . . . . 76 |  | D.2. Since draft-ietf-httpbis-p1-messaging-21 . . . . . . . . . 77 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 |  | D.3. Since draft-ietf-httpbis-p1-messaging-22 . . . . . . . . . 79 |
|  |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 |
| 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 self- |  | request/response protocol that uses extensible semantics and self- |
| descriptive message payloads for flexible interaction with network- |  | descriptive message payloads for flexible interaction with network- |
| based hypertext information systems. This document is the first in a |  | based hypertext information systems. This document is the first in a |
| series of documents that collectively form the HTTP/1.1 |  | series of documents that collectively form the HTTP/1.1 |
| specification: |  | specification: |
| skipping to change at page 8, line 33 |  | skipping to change at page 8, line 33 |
| Accept-Language: en, mi |  | Accept-Language: en, mi |
| server response: |  | server response: |
| HTTP/1.1 200 OK |  | HTTP/1.1 200 OK |
| Date: Mon, 27 Jul 2009 12:28:53 GMT |  | Date: Mon, 27 Jul 2009 12:28:53 GMT |
| Server: Apache |  | Server: Apache |
| Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT |  | Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT |
| ETag: "34aa387-d-1568eb00" |  | ETag: "34aa387-d-1568eb00" |
| Accept-Ranges: bytes |  | Accept-Ranges: bytes |
| Content-Length: 14 |  | Content-Length: 51 |
| Vary: Accept-Encoding |  | Vary: Accept-Encoding |
| Content-Type: text/plain |  | Content-Type: text/plain |
| Hello World! |  | Hello World! My payload includes a trailing CRLF. |
| (Note that the content length includes the trailing CR/LF sequence of |  |  |
| the body text) |  |  |
| 2.2. Implementation Diversity |  | 2.2. Implementation Diversity |
| When considering the design of HTTP, it is easy to fall into a trap |  | When considering the design of HTTP, it is easy to fall into a trap |
| of thinking that all user agents are general-purpose browsers and all |  | of thinking that all user agents are general-purpose browsers and all |
| origin servers are large public websites. That is not the case in |  | origin servers are large public websites. That is not the case in |
| practice. Common HTTP user agents include household appliances, |  | practice. Common HTTP user agents include household appliances, |
| stereos, scales, firmware update scripts, command-line programs, |  | stereos, scales, firmware update scripts, command-line programs, |
| mobile apps, and communication devices in a multitude of shapes and |  | mobile apps, and communication devices in a multitude of shapes and |
| sizes. Likewise, common HTTP origin servers include home automation |  | sizes. Likewise, common HTTP origin servers include home automation |
| skipping to change at page 9, line 23 |  | skipping to change at page 9, line 20 |
| erroneous). Spiders, for example, are typically given a start URI |  | erroneous). Spiders, for example, are typically given a start URI |
| and configured to follow certain behavior while crawling the Web as a |  | and configured to follow certain behavior while crawling the Web as a |
| hypertext graph. |  | hypertext graph. |
| The implementation diversity of HTTP means that we cannot assume the |  | The implementation diversity of HTTP means that we cannot assume the |
| user agent can make interactive suggestions to a user or provide |  | user agent can make interactive suggestions to a user or provide |
| adequate warning for security or privacy options. In the few cases |  | adequate warning for security or privacy options. In the few cases |
| where this specification requires reporting of errors to the user, it |  | where this specification requires reporting of errors to the user, it |
| is acceptable for such reporting to only be observable in an error |  | is acceptable for such reporting to only be observable in an error |
| console or log file. Likewise, requirements that an automated action |  | console or log file. Likewise, requirements that an automated action |
| be confirmed by the user before proceeding can be met via advance |  | be confirmed by the user before proceeding might be met via advance |
| configuration choices, run-time options, or simply not proceeding |  | configuration choices, run-time options, or simple avoidance of the |
| with the unsafe action. |  | unsafe action; confirmation does not imply any specific user |
|  |  | interface or interruption of normal processing if the user has |
|  |  | already made that choice. |
| 2.3. Intermediaries |  | 2.3. Intermediaries |
| HTTP enables the use of intermediaries to satisfy requests through a |  | HTTP enables the use of intermediaries to satisfy requests through a |
| chain of connections. There are three common forms of HTTP |  | chain of connections. There are three common forms of HTTP |
| intermediary: proxy, gateway, and tunnel. In some cases, a single |  | intermediary: proxy, gateway, and tunnel. In some cases, a single |
| intermediary might act as an origin server, proxy, gateway, or |  | intermediary might act as an origin server, proxy, gateway, or |
| tunnel, switching behavior based on the nature of each request. |  | tunnel, switching behavior based on the nature of each request. |
| > > > > |  | > > > > |
| skipping to change at page 9, line 49 |  | skipping to change at page 9, line 48 |
| The figure above shows three intermediaries (A, B, and C) between the |  | The figure above shows three intermediaries (A, B, and C) between the |
| user agent and origin server. A request or response message that |  | user agent and origin server. A request or response message that |
| travels the whole chain will pass through four separate connections. |  | travels the whole chain will pass through four separate connections. |
| Some HTTP communication options might apply only to the connection |  | Some HTTP communication options might apply only to the connection |
| with the nearest, non-tunnel neighbor, only to the end-points of the |  | with the nearest, non-tunnel neighbor, only to the end-points of the |
| 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. Likewise, later requests might be sent through a different |
|  |  | path of connections, often based on dynamic configuration for load |
|  |  | balancing. |
| 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 the |  | terms inbound and outbound to refer to directions in relation to the |
| request path: "inbound" means toward the origin server and "outbound" |  | request path: "inbound" means toward the origin server and "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 |
| skipping to change at page 10, line 37 |  | skipping to change at page 10, line 37 |
| responses to include references to a local annotation database), a |  | responses to include references to a local annotation database), a |
| malware filter, a format transcoder, or an intranet-to-Internet |  | malware filter, a format transcoder, or an intranet-to-Internet |
| privacy filter. Such transformations are presumed to be desired by |  | privacy filter. Such transformations are presumed to be desired by |
| the client (or client organization) that selected the proxy and are |  | the client (or client organization) that selected the proxy and are |
| beyond the scope of this specification. However, when a proxy is not |  | beyond the scope of this specification. However, when a proxy is not |
| intended to transform a given message, we use the term "non- |  | intended to transform a given message, we use the term "non- |
| transforming proxy" to target requirements that preserve HTTP message |  | transforming proxy" to target requirements that preserve HTTP message |
| semantics. See Section 6.3.4 of [Part2] and Section 7.5 of [Part6] |  | semantics. See Section 6.3.4 of [Part2] and Section 7.5 of [Part6] |
| for status and warning codes related to transformations. |  | for status and warning codes related to transformations. |
| A "gateway" (a.k.a., "reverse proxy") is a receiving agent that acts |  | A "gateway" (a.k.a., "reverse proxy") is an intermediary that acts as |
| as a layer above some other server(s) and translates the received |  | an origin server for the outbound connection, but translates received |
| requests to the underlying server's protocol. Gateways are often |  | requests and forwards them inbound to another server or servers. |
| used to encapsulate legacy or untrusted information services, to |  | Gateways are often used to encapsulate legacy or untrusted |
| improve server performance through "accelerator" caching, and to |  | information services, to improve server performance through |
| enable partitioning or load-balancing of HTTP services across |  | "accelerator" caching, and to enable partitioning or load balancing |
| multiple machines. |  | of HTTP services across multiple machines. |
| A gateway behaves as an origin server on its outbound connection and |  | All HTTP requirements applicable to an origin server also apply to |
| as a user agent on its inbound connection. All HTTP requirements |  | the outbound communication of a gateway. A gateway communicates with |
| applicable to an origin server also apply to the outbound |  | inbound servers using any protocol that it desires, including private |
| communication of a gateway. A gateway communicates with inbound |  |  |
| servers using any protocol that it desires, including private |  |  |
| extensions to HTTP that are outside the scope of this specification. |  | extensions to HTTP that are outside the scope of this specification. |
| However, an HTTP-to-HTTP gateway that wishes to interoperate with |  | However, an HTTP-to-HTTP gateway that wishes to interoperate with |
| third-party HTTP servers MUST conform to HTTP user agent requirements |  | third-party HTTP servers ought to conform to user agent requirements |
| on the gateway's inbound connection and MUST implement the Connection |  | on the gateway's inbound connection. |
| (Section 6.1) and Via (Section 5.7.1) header fields for both |  |  |
| connections. |  |  |
| A "tunnel" acts as a blind relay between two connections without |  | A "tunnel" acts as a blind relay between two connections without |
| changing the messages. Once active, a tunnel is not considered a |  | changing the messages. Once active, a tunnel is not considered a |
| party to the HTTP communication, though the tunnel might have been |  | party to the HTTP communication, though the tunnel might have been |
| initiated by an HTTP request. A tunnel ceases to exist when both |  | initiated by an HTTP request. A tunnel ceases to exist when both |
| ends of the relayed connection are closed. Tunnels are used to |  | ends of the relayed connection are closed. Tunnels are used to |
| extend a virtual connection through an intermediary, such as when |  | extend a virtual connection through an intermediary, such as when |
| Transport Layer Security (TLS, [RFC5246]) is used to establish |  | Transport Layer Security (TLS, [RFC5246]) is used to establish |
| confidential communication through a shared firewall proxy. |  | confidential communication through a shared firewall proxy. |
| skipping to change at page 12, line 47 |  | skipping to change at page 12, line 42 |
| depending on what behavior is being constrained by the requirement. |  | depending on what behavior is being constrained by the requirement. |
| Additional (social) requirements are placed on implementations, |  | Additional (social) requirements are placed on implementations, |
| resource owners, and protocol element registrations when they apply |  | resource owners, and protocol element registrations when they apply |
| beyond the scope of a single communication. |  | beyond the scope of a single communication. |
| The verb "generate" is used instead of "send" where a requirement |  | The verb "generate" is used instead of "send" where a requirement |
| differentiates between creating a protocol element and merely |  | differentiates between creating a protocol element and merely |
| forwarding a received element downstream. |  | forwarding a received element downstream. |
| An implementation is considered conformant if it complies with all of |  | An implementation is considered conformant if it complies with all of |
| the requirements associated with the roles it partakes in HTTP. Note |  | the requirements associated with the roles it partakes in HTTP. |
| that SHOULD-level requirements are relevant here, unless one of the |  |  |
| documented exceptions is applicable. |  |  |
| Conformance applies to both the syntax and semantics of HTTP protocol |  | Conformance applies to both the syntax and semantics of HTTP protocol |
| elements. A sender MUST NOT generate protocol elements that convey a |  | elements. A sender MUST NOT generate protocol elements that convey a |
| meaning that is known by that sender to be false. A sender MUST NOT |  | meaning that is known by that sender to be false. A sender MUST NOT |
| generate protocol elements that do not match the grammar defined by |  | generate protocol elements that do not match the grammar defined by |
| the ABNF rules for those protocol elements that are applicable to the |  | the ABNF rules for those protocol elements that are applicable to the |
| sender's role. If a received protocol element is processed, the |  | sender's role. If a received protocol element is processed, the |
| recipient MUST be able to parse any value that would match the ABNF |  | recipient MUST be able to parse any value that would match the ABNF |
| rules for that protocol element, excluding only those rules not |  | rules for that protocol element, excluding only those rules not |
| applicable to the recipient's role. |  | applicable to the recipient's role. |
| skipping to change at page 13, line 40 |  | skipping to change at page 13, line 33 |
| The version of an HTTP message is indicated by an HTTP-version field |  | The version of an HTTP message is indicated by an HTTP-version field |
| in the first line of the message. HTTP-version is case-sensitive. |  | in the first line of the message. HTTP-version is case-sensitive. |
| HTTP-version = HTTP-name "/" DIGIT "." DIGIT |  | HTTP-version = HTTP-name "/" DIGIT "." DIGIT |
| HTTP-name = %x48.54.54.50 ; "HTTP", case-sensitive |  | HTTP-name = %x48.54.54.50 ; "HTTP", case-sensitive |
| The HTTP version number consists of two decimal digits separated by a |  | The HTTP version number consists of two decimal digits separated by a |
| "." (period or decimal point). The first digit ("major version") |  | "." (period or decimal point). The first digit ("major version") |
| indicates the HTTP messaging syntax, whereas the second digit ("minor |  | indicates the HTTP messaging syntax, whereas the second digit ("minor |
| version") indicates the highest minor version to which the sender is |  | version") indicates the highest minor version within that major |
| conformant and able to understand for future communication. The |  | version to which the sender is conformant and able to understand for |
| minor version advertises the sender's communication capabilities even |  | future communication. The minor version advertises the sender's |
| when the sender is only using a backwards-compatible subset of the |  | communication capabilities even when the sender is only using a |
| protocol, thereby letting the recipient know that more advanced |  | backwards-compatible subset of the protocol, thereby letting the |
| features can be used in response (by servers) or in future requests |  | recipient know that more advanced features can be used in response |
| (by clients). |  | (by servers) or in future requests (by clients). |
| When an HTTP/1.1 message is sent to an HTTP/1.0 recipient [RFC1945] |  | When an HTTP/1.1 message is sent to an HTTP/1.0 recipient [RFC1945] |
| or a recipient whose version is unknown, the HTTP/1.1 message is |  | or a recipient whose version is unknown, the HTTP/1.1 message is |
| constructed such that it can be interpreted as a valid HTTP/1.0 |  | constructed such that it can be interpreted as a valid HTTP/1.0 |
| message if all of the newer features are ignored. This specification |  | message if all of the newer features are ignored. This specification |
| places recipient-version requirements on some new features so that a |  | places recipient-version requirements on some new features so that a |
| conformant sender will only use compatible features until it has |  | conformant sender will only use compatible features until it has |
| determined, through configuration or the receipt of a message, that |  | determined, through configuration or the receipt of a message, that |
| the recipient supports HTTP/1.1. |  | the recipient supports HTTP/1.1. |
| skipping to change at page 14, line 39 |  | skipping to change at page 14, line 32 |
| other than those acting as tunnels) MUST send their own HTTP-version |  | other than those acting as tunnels) MUST send their own HTTP-version |
| in forwarded messages. In other words, they MUST NOT blindly forward |  | in forwarded messages. In other words, they MUST NOT blindly forward |
| the first line of an HTTP message without ensuring that the protocol |  | the first line of an HTTP message without ensuring that the protocol |
| version in that message matches a version to which that intermediary |  | version in that message matches a version to which that intermediary |
| is conformant for both the receiving and sending of messages. |  | is conformant for both the receiving and sending of messages. |
| Forwarding an HTTP message without rewriting the HTTP-version might |  | Forwarding an HTTP message without rewriting the HTTP-version might |
| result in communication errors when downstream recipients use the |  | result in communication errors when downstream recipients use the |
| message sender's version to determine what features are safe to use |  | message sender's version to determine what features are safe to use |
| for later communication with that sender. |  | for later communication with that sender. |
| An HTTP client SHOULD send a request version equal to the highest |  | A client SHOULD send a request version equal to the highest version |
| version to which the client is conformant and whose major version is |  | to which the client is conformant and whose major version is no |
| no higher than the highest version supported by the server, if this |  | higher than the highest version supported by the server, if this is |
| is known. An HTTP client MUST NOT send a version to which it is not |  | known. A client MUST NOT send a version to which it is not |
| conformant. |  | conformant. |
| An HTTP client MAY send a lower request version if it is known that |  | A client MAY send a lower request version if it is known that the |
| the server incorrectly implements the HTTP specification, but only |  | server incorrectly implements the HTTP specification, but only after |
| after the client has attempted at least one normal request and |  | the client has attempted at least one normal request and determined |
| determined from the response status or header fields (e.g., Server) |  | from the response status or header fields (e.g., Server) that the |
| that the server improperly handles higher request versions. |  | server improperly handles higher request versions. |
| An HTTP server SHOULD send a response version equal to the highest |  | A server SHOULD send a response version equal to the highest version |
| version to which the server is conformant and whose major version is |  | to which the server is conformant and whose major version is less |
| less than or equal to the one received in the request. An HTTP |  | than or equal to the one received in the request. A server MUST NOT |
| server MUST NOT send a version to which it is not conformant. A |  | send a version to which it is not conformant. A server MAY send a |
| server MAY send a 505 (HTTP Version Not Supported) response if it |  | 505 (HTTP Version Not Supported) response if it cannot send a |
| cannot send a response using the major version used in the client's |  | response using the major version used in the client's request. |
| request. |  |  |
| An HTTP server MAY send an HTTP/1.0 response to an HTTP/1.0 request |  | A server MAY send an HTTP/1.0 response to a request if it is known or |
| if it is known or suspected that the client incorrectly implements |  | suspected that the client incorrectly implements the HTTP |
| the HTTP specification and is incapable of correctly processing later |  | specification and is incapable of correctly processing later version |
| version responses, such as when a client fails to parse the version |  | responses, such as when a client fails to parse the version number |
| number correctly or when an intermediary is known to blindly forward |  | correctly or when an intermediary is known to blindly forward the |
| the HTTP-version even when it doesn't conform to the given minor |  | HTTP-version even when it doesn't conform to the given minor version |
| version of the protocol. Such protocol downgrades SHOULD NOT be |  | of the protocol. Such protocol downgrades SHOULD NOT be performed |
| performed unless triggered by specific client attributes, such as |  | unless triggered by specific client attributes, such as when one or |
| when one or more of the request header fields (e.g., User-Agent) |  | more of the request header fields (e.g., User-Agent) uniquely match |
| uniquely match the values sent by a client known to be in error. |  | the values sent by a client known to be in error. |
| The intention of HTTP's versioning design is that the major number |  | The intention of HTTP's versioning design is that the major number |
| will only be incremented if an incompatible message syntax is |  | will only be incremented if an incompatible message syntax is |
| introduced, and that the minor number will only be incremented when |  | introduced, and that the minor number will only be incremented when |
| changes made to the protocol have the effect of adding to the message |  | changes made to the protocol have the effect of adding to the message |
| semantics or implying additional capabilities of the sender. |  | semantics or implying additional capabilities of the sender. |
| However, the minor version was not incremented for the changes |  | However, the minor version was not incremented for the changes |
| introduced between [RFC2068] and [RFC2616], and this revision has |  | introduced between [RFC2068] and [RFC2616], and this revision has |
| specifically avoiding any such changes to the protocol. |  | specifically avoided any such changes to the protocol. |
|  |  | When an HTTP message is received with a major version number that the |
|  |  | recipient implements, but a higher minor version number than what the |
|  |  | recipient implements, the recipient SHOULD process the message as if |
|  |  | it were in the highest minor version within that major version to |
|  |  | which the recipient is conformant. A recipient can assume that a |
|  |  | message with a higher minor version, when sent to a recipient that |
|  |  | has not yet indicated support for that higher version, is |
|  |  | sufficiently backwards-compatible to be safely processed by any |
|  |  | implementation of the same major version. |
| 2.7. Uniform Resource Identifiers |  | 2.7. Uniform Resource Identifiers |
| Uniform Resource Identifiers (URIs) [RFC3986] are used throughout |  | Uniform Resource Identifiers (URIs) [RFC3986] are used throughout |
| HTTP as the means for identifying resources (Section 2 of [Part2]). |  | HTTP as the means for identifying resources (Section 2 of [Part2]). |
| URI references are used to target requests, indicate redirects, and |  | URI references are used to target requests, indicate redirects, and |
| define relationships. |  | define relationships. |
| This specification adopts the definitions of "URI-reference", |  | This specification adopts the definitions of "URI-reference", |
| "absolute-URI", "relative-part", "port", "host", "path-abempty", |  | "absolute-URI", "relative-part", "authority", "port", "host", "path- |
| "query", "segment", and "authority" from the URI generic syntax. In |  | abempty", "segment", "query", and "fragment" from the URI generic |
| addition, we define an "absolute-path" rule (that differs from RFC |  | syntax. In addition, we define an "absolute-path" rule (that differs |
| 3986's "path-absolute" in that it allows a leading "//") and a |  | from RFC 3986's "path-absolute" in that it allows a leading "//") and |
| "partial-URI" rule for protocol elements that allow a relative URI |  | a "partial-URI" rule for protocol elements that allow a relative URI |
| but not a fragment. |  | but not a fragment. |
| URI-reference = <URI-reference, defined in [RFC3986], Section 4.1> |  | URI-reference = <URI-reference, defined in [RFC3986], Section 4.1> |
| absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3> |  | absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3> |
| relative-part = <relative-part, defined in [RFC3986], Section 4.2> |  | relative-part = <relative-part, defined in [RFC3986], Section 4.2> |
| authority = <authority, defined in [RFC3986], Section 3.2> |  | authority = <authority, defined in [RFC3986], Section 3.2> |
| path-abempty = <path-abempty, defined in [RFC3986], Section 3.3> |  | uri-host = <host, defined in [RFC3986], Section 3.2.2> |
| port = <port, defined in [RFC3986], Section 3.2.3> |  | port = <port, defined in [RFC3986], Section 3.2.3> |
| query = <query, defined in [RFC3986], Section 3.4> |  | path-abempty = <path-abempty, defined in [RFC3986], Section 3.3> |
| segment = <segment, defined in [RFC3986], Section 3.3> |  | segment = <segment, defined in [RFC3986], Section 3.3> |
| uri-host = <host, defined in [RFC3986], Section 3.2.2> |  | query = <query, defined in [RFC3986], Section 3.4> |
|  |  | fragment = <fragment, defined in [RFC3986], Section 3.5> |
| absolute-path = 1*( "/" segment ) |  | absolute-path = 1*( "/" segment ) |
| partial-URI = relative-part [ "?" query ] |  | partial-URI = relative-part [ "?" query ] |
| Each protocol element in HTTP that allows a URI reference will |  | Each protocol element in HTTP that allows a URI reference will |
| indicate in its ABNF production whether the element allows any form |  | indicate in its ABNF production whether the element allows any form |
| of reference (URI-reference), only a URI in absolute form (absolute- |  | of reference (URI-reference), only a URI in absolute form (absolute- |
| URI), only the path and optional query components, or some |  | URI), only the path and optional query components, or some |
| combination of the above. Unless otherwise indicated, URI references |  | combination of the above. Unless otherwise indicated, URI references |
| are parsed relative to the effective request URI (Section 5.5). |  | are parsed relative to the effective request URI (Section 5.5). |
| 2.7.1. http URI scheme |  | 2.7.1. http URI scheme |
| The "http" URI scheme is hereby defined for the purpose of minting |  | The "http" URI scheme is hereby defined for the purpose of minting |
| identifiers according to their association with the hierarchical |  | identifiers according to their association with the hierarchical |
| namespace governed by a potential HTTP origin server listening for |  | namespace governed by a potential HTTP origin server listening for |
| TCP connections on a given port. |  | TCP ([RFC0793]) connections on a given port. |
| http-URI = "http:" "//" authority path-abempty [ "?" query ] |  | http-URI = "http:" "//" authority path-abempty [ "?" query ] |
|  |  | [ "#" fragment ] |
| The HTTP origin server is identified by the generic syntax's |  | The HTTP origin server is identified by the generic syntax's |
| authority component, which includes a host identifier and optional |  | authority component, which includes a host identifier and optional |
| TCP port ([RFC3986], Section 3.2.2). The remainder of the URI, |  | TCP port ([RFC3986], Section 3.2.2). The remainder of the URI, |
| consisting of both the hierarchical path component and optional query |  | consisting of both the hierarchical path component and optional query |
| component, serves as an identifier for a potential resource within |  | component, serves as an identifier for a potential resource within |
| that origin server's name space. |  | that origin server's name space. |
| If the host identifier is provided as an IP address, then the origin |  | If the host identifier is provided as an IP address, then the origin |
| server is any listener on the indicated TCP port at that IP address. |  | server is any listener on the indicated TCP port at that IP address. |
| skipping to change at page 17, line 30 |  | skipping to change at page 17, line 33 |
| request. |  | request. |
| Although HTTP is independent of the transport protocol, the "http" |  | Although HTTP is independent of the transport protocol, the "http" |
| scheme is specific to TCP-based services because the name delegation |  | scheme is specific to TCP-based services because the name delegation |
| process depends on TCP for establishing authority. An HTTP service |  | process depends on TCP for establishing authority. An HTTP service |
| based on some other underlying connection protocol would presumably |  | based on some other underlying connection protocol would presumably |
| be identified using a different URI scheme, just as the "https" |  | be identified using a different URI scheme, just as the "https" |
| scheme (below) is used for resources that require an end-to-end |  | scheme (below) is used for resources that require an end-to-end |
| secured connection. Other protocols might also be used to provide |  | secured connection. Other protocols might also be used to provide |
| access to "http" identified resources -- it is only the authoritative |  | access to "http" identified resources -- it is only the authoritative |
| interface used for mapping the namespace that is specific to TCP. |  | interface that is specific to TCP. |
| The URI generic syntax for authority also includes a deprecated |  | The URI generic syntax for authority also includes a deprecated |
| userinfo subcomponent ([RFC3986], Section 3.2.1) for including user |  | userinfo subcomponent ([RFC3986], Section 3.2.1) for including user |
| authentication information in the URI. Some implementations make use |  | authentication information in the URI. Some implementations make use |
| of the userinfo component for internal configuration of |  | of the userinfo component for internal configuration of |
| authentication information, such as within command invocation |  | authentication information, such as within command invocation |
| options, configuration files, or bookmark lists, even though such |  | options, configuration files, or bookmark lists, even though such |
| usage might expose a user identifier or password. Senders MUST |  | usage might expose a user identifier or password. Senders MUST |
| exclude the userinfo subcomponent (and its "@" delimiter) when an |  | exclude the userinfo subcomponent (and its "@" delimiter) when an |
| "http" URI is transmitted within a message as a request target or |  | "http" URI is transmitted within a message as a request target or |
| header field value. Recipients of an "http" URI reference SHOULD |  | header field value. Recipients of an "http" URI reference SHOULD |
| parse for userinfo and treat its presence as an error, since it is |  | parse for userinfo and treat its presence as an error, since it is |
| likely being used to obscure the authority for the sake of phishing |  | likely being used to obscure the authority for the sake of phishing |
| attacks. |  | attacks. |
| 2.7.2. https URI scheme |  | 2.7.2. https URI scheme |
| The "https" URI scheme is hereby defined for the purpose of minting |  | The "https" URI scheme is hereby defined for the purpose of minting |
| identifiers according to their association with the hierarchical |  | identifiers according to their association with the hierarchical |
| namespace governed by a potential HTTP origin server listening to a |  | namespace governed by a potential HTTP origin server listening to a |
| given TCP port for TLS-secured connections [RFC5246]. |  | given TCP port for TLS-secured connections ([RFC0793], [RFC5246]). |
| All of the requirements listed above for the "http" scheme are also |  | All of the requirements listed above for the "http" scheme are also |
| requirements for the "https" scheme, except that a default TCP port |  | requirements for the "https" scheme, except that a default TCP port |
| of 443 is assumed if the port subcomponent is empty or not given, and |  | of 443 is assumed if the port subcomponent is empty or not given, and |
| the TCP connection MUST be secured, end-to-end, through the use of |  | the TCP connection MUST be secured, end-to-end, through the use of |
| strong encryption prior to sending the first HTTP request. |  | strong encryption prior to sending the first HTTP request. |
| https-URI = "https:" "//" authority path-abempty [ "?" query ] |  | https-URI = "https:" "//" authority path-abempty [ "?" query ] |
|  |  | [ "#" fragment ] |
| Resources made available via the "https" scheme have no shared |  | Note that the "https" URI scheme depends on both TLS and TCP for |
| identity with the "http" scheme even if their resource identifiers |  | establishing authority. Resources made available via the "https" |
| indicate the same authority (the same host listening to the same TCP |  | scheme have no shared identity with the "http" scheme even if their |
| port). They are distinct name spaces and are considered to be |  | resource identifiers indicate the same authority (the same host |
| distinct origin servers. However, an extension to HTTP that is |  | listening to the same TCP port). They are distinct name spaces and |
| defined to apply to entire host domains, such as the Cookie protocol |  | are considered to be distinct origin servers. However, an extension |
| [RFC6265], can allow information set by one service to impact |  | to HTTP that is defined to apply to entire host domains, such as the |
| communication with other services within a matching group of host |  | Cookie protocol [RFC6265], can allow information set by one service |
| domains. |  | to impact communication with other services within a matching group |
|  |  | of host domains. |
| The process for authoritative access to an "https" identified |  | The process for authoritative access to an "https" identified |
| resource is defined in [RFC2818]. |  | resource is defined in [RFC2818]. |
| 2.7.3. http and https URI Normalization and Comparison |  | 2.7.3. http and https URI Normalization and Comparison |
| Since the "http" and "https" schemes conform to the URI generic |  | Since the "http" and "https" schemes conform to the URI generic |
| syntax, such URIs are normalized and compared according to the |  | syntax, such URIs are normalized and compared according to the |
| algorithm defined in [RFC3986], Section 6, using the defaults |  | algorithm defined in [RFC3986], Section 6, using the defaults |
| described above for each scheme. |  | described above for each scheme. |
| If the port is equal to the default port for a scheme, the normal |  | If the port is equal to the default port for a scheme, the normal |
| form is to elide the port subcomponent. When not being used in |  | form is to omit the port subcomponent. When not being used in |
| absolute form as the request target of an OPTIONS request, an empty |  | absolute form as the request target of an OPTIONS request, an empty |
| path component is equivalent to an absolute path of "/", so the |  | path component is equivalent to an absolute path of "/", so the |
| normal form is to provide a path of "/" instead. The scheme and host |  | normal form is to provide a path of "/" instead. The scheme and host |
| are case-insensitive and normally provided in lowercase; all other |  | are case-insensitive and normally provided in lowercase; all other |
| components are compared in a case-sensitive manner. Characters other |  | components are compared in a case-sensitive manner. Characters other |
| than those in the "reserved" set are equivalent to their percent- |  | than those in the "reserved" set are equivalent to their percent- |
| encoded octets (see [RFC3986], Section 2.1): the normal form is to |  | encoded octets (see [RFC3986], Section 2.1): the normal form is to |
| not encode them. |  | not encode them. |
| For example, the following three URIs are equivalent: |  | For example, the following three URIs are equivalent: |
| skipping to change at page 19, line 42 |  | skipping to change at page 19, line 43 |
| after the element has been extracted from the message, such as within |  | after the element has been extracted from the message, such as within |
| a header field-value after message parsing has delineated the |  | a header field-value after message parsing has delineated the |
| individual fields. |  | individual fields. |
| An HTTP message can be parsed as a stream for incremental processing |  | An HTTP message can be parsed as a stream for incremental processing |
| or forwarding downstream. However, recipients cannot rely on |  | or forwarding downstream. However, recipients cannot rely on |
| incremental delivery of partial messages, since some implementations |  | incremental delivery of partial messages, since some implementations |
| will buffer or delay message forwarding for the sake of network |  | will buffer or delay message forwarding for the sake of network |
| efficiency, security checks, or payload transformations. |  | efficiency, security checks, or payload transformations. |
|  |  | A sender MUST NOT send whitespace between the start-line and the |
|  |  | first header field. A recipient that receives whitespace between the |
|  |  | start-line and the first header field MUST either reject the message |
|  |  | as invalid or consume each whitespace-preceded line without further |
|  |  | processing of it (i.e., ignore the entire line, along with any |
|  |  | subsequent lines preceded by whitespace, until a properly formed |
|  |  | header field is received or the header block is terminated). |
|  |  | The presence of such whitespace in a request might be an attempt to |
|  |  | trick a server into ignoring that field or processing the line after |
|  |  | it as a new request, either of which might result in a security |
|  |  | vulnerability if other implementations within the request chain |
|  |  | interpret the same message differently. Likewise, the presence of |
|  |  | such whitespace in a response might be ignored by some clients or |
|  |  | cause others to cease parsing. |
| 3.1. Start Line |  | 3.1. Start Line |
| An HTTP message can either be a request from client to server or a |  | An HTTP message can either be a request from client to server or a |
| response from server to client. Syntactically, the two types of |  | response from server to client. Syntactically, the two types of |
| message differ only in the start-line, which is either a request-line |  | message differ only in the start-line, which is either a request-line |
| (for requests) or a status-line (for responses), and in the algorithm |  | (for requests) or a status-line (for responses), and in the algorithm |
| for determining the length of the message body (Section 3.3). |  | for determining the length of the message body (Section 3.3). |
| In theory, a client could receive requests and a server could receive |  | In theory, a client could receive requests and a server could receive |
| responses, distinguishing them by their different start-line formats, |  | responses, distinguishing them by their different start-line formats, |
| but in practice servers are implemented to only expect a request (a |  | but in practice servers are implemented to only expect a request (a |
| response is interpreted as an unknown or invalid request method) and |  | response is interpreted as an unknown or invalid request method) and |
| clients are implemented to only expect a response. |  | clients are implemented to only expect a response. |
| start-line = request-line / status-line |  | start-line = request-line / status-line |
| A sender MUST NOT send whitespace between the start-line and the |  |  |
| first header field. The presence of such whitespace in a request |  |  |
| might be an attempt to trick a server into ignoring that field or |  |  |
| processing the line after it as a new request, either of which might |  |  |
| result in a security vulnerability if other implementations within |  |  |
| the request chain interpret the same message differently. Likewise, |  |  |
| the presence of such whitespace in a response might be ignored by |  |  |
| some clients or cause others to cease parsing. |  |  |
| A recipient that receives whitespace between the start-line and the |  |  |
| first header field MUST either reject the message as invalid or |  |  |
| consume each whitespace-preceded line without further processing of |  |  |
| it (i.e., ignore the entire line, along with any subsequent lines |  |  |
| preceded by whitespace, until a properly formed header field is |  |  |
| received or the header block is terminated). |  |  |
| 3.1.1. Request Line |  | 3.1.1. Request Line |
| A request-line begins with a method token, followed by a single space |  | A request-line begins with a method token, followed by a single space |
| (SP), the request-target, another single space (SP), the protocol |  | (SP), the request-target, another single space (SP), the protocol |
| version, and ending with CRLF. |  | version, and ending with CRLF. |
| request-line = method SP request-target SP HTTP-version CRLF |  | request-line = method SP request-target SP HTTP-version CRLF |
| The method token indicates the request method to be performed on the |  | The method token indicates the request method to be performed on the |
| target resource. The request method is case-sensitive. |  | target resource. The request method is case-sensitive. |
| method = token |  | method = token |
| The methods defined by this specification can be found in Section 4 |  | The methods defined by this specification can be found in Section 4 |
| of [Part2], along with information regarding the HTTP method registry |  | of [Part2], along with information regarding the HTTP method registry |
| and considerations for defining new methods. |  | and considerations for defining new methods. |
| The request-target identifies the target resource upon which to apply |  | The request-target identifies the target resource upon which to apply |
| the request, as defined in Section 5.3. |  | the request, as defined in Section 5.3. |
| No whitespace is allowed inside the method, request-target, and |  | Recipients typically parse the request-line into its component parts |
| protocol version. Hence, recipients typically parse the request-line |  | by splitting on whitespace (see Section 3.5), since no whitespace is |
| into its component parts by splitting on whitespace (see |  | allowed in the three components. Unfortunately, some user agents |
| Section 3.5). |  | fail to properly encode or exclude whitespace found in hypertext |
|  |  | references, resulting in those disallowed characters being sent in a |
|  |  | request-target. |
| Unfortunately, some user agents fail to properly encode hypertext |  | Recipients of an invalid request-line SHOULD respond with either a |
| references that have embedded whitespace, sending the characters |  | 400 (Bad Request) error or a 301 (Moved Permanently) redirect with |
| directly instead of properly encoding or excluding the disallowed |  | the request-target properly encoded. Recipients SHOULD NOT attempt |
| characters. Recipients of an invalid request-line SHOULD respond |  | to autocorrect and then process the request without a redirect, since |
| with either a 400 (Bad Request) error or a 301 (Moved Permanently) |  | the invalid request-line might be deliberately crafted to bypass |
| redirect with the request-target properly encoded. Recipients SHOULD |  | security filters along the request chain. |
| NOT attempt to autocorrect and then process the request without a |  |  |
| redirect, since the invalid request-line might be deliberately |  |  |
| crafted to bypass security filters along the request chain. |  |  |
| HTTP does not place a pre-defined limit on the length of a request- |  | HTTP does not place a pre-defined limit on the length of a request- |
| line. A server that receives a method longer than any that it |  | line. A server that receives a method longer than any that it |
| implements SHOULD respond with a 501 (Not Implemented) status code. |  | implements SHOULD respond with a 501 (Not Implemented) status code. |
| A server MUST be prepared to receive URIs of unbounded length and |  | A server MUST be prepared to receive URIs of unbounded length and |
| respond with the 414 (URI Too Long) status code if the received |  | respond with the 414 (URI Too Long) status code if the received |
| request-target would be longer than the server wishes to handle (see |  | request-target would be longer than the server wishes to handle (see |
| Section 6.5.12 of [Part2]). |  | Section 6.5.12 of [Part2]). |
| Various ad-hoc limitations on request-line length are found in |  | Various ad-hoc limitations on request-line length are found in |
| skipping to change at page 22, line 8 |  | skipping to change at page 22, line 10 |
| textual description associated with the numeric status code, mostly |  | textual description associated with the numeric status code, mostly |
| out of deference to earlier Internet application protocols that were |  | out of deference to earlier Internet application protocols that were |
| more frequently used with interactive text clients. A client SHOULD |  | more frequently used with interactive text clients. A client SHOULD |
| ignore the reason-phrase content. |  | ignore the reason-phrase content. |
| reason-phrase = *( HTAB / SP / VCHAR / obs-text ) |  | reason-phrase = *( HTAB / SP / VCHAR / obs-text ) |
| 3.2. Header Fields |  | 3.2. Header Fields |
| Each HTTP header field consists of a case-insensitive field name |  | Each HTTP header field consists of a case-insensitive field name |
| followed by a colon (":"), optional whitespace, and the field value. |  | followed by a colon (":"), optional leading whitespace, the field |
|  |  | value, and optional trailing whitespace. |
| header-field = field-name ":" OWS field-value BWS |  | header-field = field-name ":" OWS field-value OWS |
| field-name = token |  | field-name = token |
| field-value = *( field-content / obs-fold ) |  | field-value = *( field-content / obs-fold ) |
| field-content = *( HTAB / SP / VCHAR / obs-text ) |  | field-content = *( HTAB / SP / VCHAR / obs-text ) |
| obs-fold = CRLF ( SP / HTAB ) |  | obs-fold = CRLF ( SP / HTAB ) |
| ; obsolete line folding |  | ; obsolete line folding |
| ; see Section 3.2.4 |  | ; see Section 3.2.4 |
| The field-name token labels the corresponding field-value as having |  | The field-name token labels the corresponding field-value as having |
| the semantics defined by that header field. For example, the Date |  | the semantics defined by that header field. For example, the Date |
| header field is defined in Section 7.1.1.2 of [Part2] as containing |  | header field is defined in Section 7.1.1.2 of [Part2] as containing |
| skipping to change at page 22, line 34 |  | skipping to change at page 22, line 37 |
| HTTP header fields are fully extensible: there is no limit on the |  | HTTP header fields are fully extensible: there is no limit on the |
| introduction of new field names, each presumably defining new |  | introduction of new field names, each presumably defining new |
| semantics, nor on the number of header fields used in a given |  | semantics, nor on the number of header fields used in a given |
| message. Existing fields are defined in each part of this |  | message. Existing fields are defined in each part of this |
| specification and in many other specifications outside the core |  | specification and in many other specifications outside the core |
| standard. New header fields can be introduced without changing the |  | standard. New header fields can be introduced without changing the |
| protocol version if their defined semantics allow them to be safely |  | protocol version if their defined semantics allow them to be safely |
| ignored by recipients that do not recognize them. |  | ignored by recipients that do not recognize them. |
| New HTTP header fields ought to be be registered with IANA in the |  | New HTTP header fields ought to be registered with IANA in the |
| Message Header Field Registry, as described in Section 8.3 of |  | Message Header Field Registry, as described in Section 8.3 of |
| [Part2]. A proxy MUST forward unrecognized header fields unless the |  | [Part2]. A proxy MUST forward unrecognized header fields unless the |
| field-name is listed in the Connection header field (Section 6.1) or |  | field-name is listed in the Connection header field (Section 6.1) or |
| the proxy is specifically configured to block, or otherwise |  | the proxy is specifically configured to block, or otherwise |
| transform, such fields. Other recipients SHOULD ignore unrecognized |  | transform, such fields. Other recipients SHOULD ignore unrecognized |
| header fields. |  | header fields. |
| 3.2.2. Field Order |  | 3.2.2. Field Order |
| The order in which header fields with differing field names are |  | The order in which header fields with differing field names are |
| skipping to change at page 23, line 34 |  | skipping to change at page 23, line 37 |
| special case while processing header fields. (See Appendix A.2.3 |  | special case while processing header fields. (See Appendix A.2.3 |
| of [Kri2001] for details.) |  | of [Kri2001] for details.) |
| 3.2.3. Whitespace |  | 3.2.3. Whitespace |
| This specification uses three rules to denote the use of linear |  | This specification uses three rules to denote the use of linear |
| whitespace: OWS (optional whitespace), RWS (required whitespace), and |  | whitespace: OWS (optional whitespace), RWS (required whitespace), and |
| BWS ("bad" whitespace). |  | BWS ("bad" whitespace). |
| The OWS rule is used where zero or more linear whitespace octets |  | The OWS rule is used where zero or more linear whitespace octets |
| might appear. OWS SHOULD either not be generated or be generated as |  | might appear. For protocol elements where optional whitespace is |
| a single SP. Multiple OWS octets that occur within field-content |  | preferred to improve readability, a sender SHOULD generate the |
| SHOULD either be replaced with a single SP or transformed to all SP |  | optional whitespace as a single SP; otherwise, a sender SHOULD NOT |
| octets (each octet other than SP replaced with SP) before |  | generate optional whitespace except as needed to white-out invalid or |
| interpreting the field value or forwarding the message downstream. |  | unwanted protocol elements during in-place message filtering. |
| RWS is used when at least one linear whitespace octet is required to |  | The RWS rule is used when at least one linear whitespace octet is |
| separate field tokens. RWS SHOULD be generated as a single SP. |  | required to separate field tokens. A sender SHOULD generate RWS as a |
| Multiple RWS octets that occur within field-content SHOULD either be |  | single SP. |
| replaced with a single SP or transformed to all SP octets before |  |  |
| interpreting the field value or forwarding the message downstream. |  |  |
| BWS is used where the grammar allows optional whitespace, for |  | The BWS rule is used where the grammar allows optional whitespace |
| historical reasons, but senders SHOULD NOT generate it in messages; |  | only for historical reasons. A sender MUST NOT generate BWS in |
| recipients MUST accept such bad optional whitespace and remove it |  | messages. A recipient MUST parse for such bad whitespace and remove |
| before interpreting the field value or forwarding the message |  | it before interpreting the protocol element. |
| downstream. |  |  |
| OWS = *( SP / HTAB ) |  | OWS = *( SP / HTAB ) |
| ; optional whitespace |  | ; optional whitespace |
| RWS = 1*( SP / HTAB ) |  | RWS = 1*( SP / HTAB ) |
| ; required whitespace |  | ; required whitespace |
| BWS = OWS |  | BWS = OWS |
| ; "bad" whitespace |  | ; "bad" whitespace |
| 3.2.4. Field Parsing |  | 3.2.4. Field Parsing |
| skipping to change at page 24, line 26 |  | skipping to change at page 24, line 26 |
| security vulnerabilities in request routing and response handling. A |  | security vulnerabilities in request routing and response handling. A |
| server MUST reject any received request message that contains |  | server MUST reject any received request message that contains |
| whitespace between a header field-name and colon with a response code |  | whitespace between a header field-name and colon with a response code |
| of 400 (Bad Request). A proxy MUST remove any such whitespace from a |  | of 400 (Bad Request). A proxy MUST remove any such whitespace from a |
| response message before forwarding the message downstream. |  | response message before forwarding the message downstream. |
| A field value is preceded by optional whitespace (OWS); a single SP |  | A field value is preceded by optional whitespace (OWS); a single SP |
| is preferred. The field value does not include any leading or |  | is preferred. The field value does not include any leading or |
| trailing white space: OWS occurring before the first non-whitespace |  | trailing white space: OWS occurring before the first non-whitespace |
| octet of the field value or after the last non-whitespace octet of |  | octet of the field value or after the last non-whitespace octet of |
| the field value is ignored and SHOULD be removed before further |  | the field value ought to be excluded by parsers when extracting the |
| processing (as this does not change the meaning of the header field). |  | field value from a header field. |
|  |  | A recipient of field-content containing multiple sequential octets of |
|  |  | optional (OWS) or required (RWS) whitespace SHOULD either replace the |
|  |  | sequence with a single SP or transform any non-SP octets in the |
|  |  | sequence to SP octets before interpreting the field value or |
|  |  | forwarding the message downstream. |
| Historically, HTTP header field values could be extended over |  | Historically, HTTP header field values could be extended over |
| multiple lines by preceding each extra line with at least one space |  | multiple lines by preceding each extra line with at least one space |
| or horizontal tab (obs-fold). This specification deprecates such |  | or horizontal tab (obs-fold). This specification deprecates such |
| line folding except within the message/http media type |  | line folding except within the message/http media type |
| (Section 7.3.1). Senders MUST NOT generate messages that include |  | (Section 7.3.1). Senders MUST NOT generate messages that include |
| line folding (i.e., that contain any field-value that contains a |  | line folding (i.e., that contain any field-value that contains a |
| match to the obs-fold rule) unless the message is intended for |  | match to the obs-fold rule) unless the message is intended for |
| packaging within the message/http media type. When an obs-fold is |  | packaging within the message/http media type. |
| received in a message, recipients MUST do one of: |  |  |
| o accept the message and replace any embedded obs-fold whitespace |  |  |
| with either a single SP or a matching number of SP octets (to |  |  |
| avoid buffer copying) prior to interpreting the field value or |  |  |
| forwarding the message downstream; |  |  |
| o if it is a request, reject the message by sending a 400 (Bad |  | A server that receives an obs-fold in a request message that is not |
| Request) response with a representation explaining that obsolete |  | within a message/http container MUST either reject the message by |
| line folding is unacceptable; or, |  | sending a 400 (Bad Request), preferably with a representation |
|  |  | explaining that obsolete line folding is unacceptable, or replace |
|  |  | each received obs-fold with one or more SP octets prior to |
|  |  | interpreting the field value or forwarding the message downstream. |
| o if it is a response, discard the message and generate a 502 (Bad |  | A proxy or gateway that receives an obs-fold in a response message |
| Gateway) response with a representation explaining that |  | that is not within a message/http container MUST either discard the |
| unacceptable line folding was received. |  | message and replace it with a 502 (Bad Gateway) response, preferably |
|  |  | with a representation explaining that unacceptable line folding was |
|  |  | received, or replace each received obs-fold with one or more SP |
|  |  | octets prior to interpreting the field value or forwarding the |
|  |  | message downstream. |
| Recipients that choose not to implement obs-fold processing (as |  | A user agent that receives an obs-fold in a response message that is |
| described above) MUST NOT accept messages containing header fields |  | not within a message/http container MUST replace each received obs- |
| with leading whitespace, as this can expose them to attacks that |  | fold with one or more SP octets prior to interpreting the field |
| exploit this difference in processing. |  | value. |
| Historically, HTTP has allowed field content with text in the ISO- |  | Historically, HTTP has allowed field content with text in the ISO- |
| 8859-1 [ISO-8859-1] charset, supporting other charsets only through |  | 8859-1 [ISO-8859-1] charset, supporting other charsets only through |
| use of [RFC2047] encoding. In practice, most HTTP header field |  | use of [RFC2047] encoding. In practice, most HTTP header field |
| values use only a subset of the US-ASCII charset [USASCII]. Newly |  | values use only a subset of the US-ASCII charset [USASCII]. Newly |
| defined header fields SHOULD limit their field values to US-ASCII |  | defined header fields SHOULD limit their field values to US-ASCII |
| octets. Recipients SHOULD treat other octets in field content (obs- |  | octets. Recipients SHOULD treat other octets in field content (obs- |
| text) as opaque data. |  | text) as opaque data. |
| 3.2.5. Field Limits |  | 3.2.5. Field Limits |
| skipping to change at page 31, line 24 |  | skipping to change at page 31, line 34 |
| handled as an error. A sender MUST remove the received Content- |  | handled as an error. A sender MUST remove the received Content- |
| Length field prior to forwarding such a message downstream. |  | Length field prior to forwarding such a message downstream. |
| 4. If a message is received without Transfer-Encoding and with |  | 4. If a message is received without Transfer-Encoding and with |
| either multiple Content-Length header fields having differing |  | either multiple Content-Length header fields having differing |
| field-values or a single Content-Length header field having an |  | field-values or a single Content-Length header field having an |
| invalid value, then the message framing is invalid and MUST be |  | invalid value, then the message framing is invalid and MUST be |
| treated as an error to prevent request or response smuggling. If |  | treated as an error to prevent request or response smuggling. If |
| this is a request message, the server MUST respond with a 400 |  | this is a request message, the server MUST respond with a 400 |
| (Bad Request) status code and then close the connection. If this |  | (Bad Request) status code and then close the connection. If this |
| is a response message received by a proxy, the proxy MUST discard |  | is a response message received by a proxy, the proxy MUST close |
| the received response, send a 502 (Bad Gateway) status code as |  | the connection to the server, discard the received response, and |
| its downstream response, and then close the connection. If this |  | send a 502 (Bad Gateway) response to the client. If this is a |
| is a response message received by a user agent, it MUST be |  | response message received by a user agent, it MUST be treated as |
| treated as an error by discarding the message and closing the |  | an error by discarding the message and closing the connection. |
| connection. |  |  |
| 5. If a valid Content-Length header field is present without |  | 5. If a valid Content-Length header field is present without |
| Transfer-Encoding, its decimal value defines the expected message |  | Transfer-Encoding, its decimal value defines the expected message |
| body length in octets. If the sender closes the connection or |  | body length in octets. If the sender closes the connection or |
| the recipient times out before the indicated number of octets are |  | the recipient times out before the indicated number of octets are |
| received, the recipient MUST consider the message to be |  | received, the recipient MUST consider the message to be |
| incomplete and close the connection. |  | incomplete and close the connection. |
| 6. If this is a request message and none of the above are true, then |  | 6. If this is a request message and none of the above are true, then |
| the message body length is zero (no message body is present). |  | the message body length is zero (no message body is present). |
| skipping to change at page 33, line 16 |  | skipping to change at page 33, line 24 |
| if the size of the message body received (in octets) is less than the |  | if the size of the message body received (in octets) is less than the |
| value given by Content-Length. A response that has neither chunked |  | value given by Content-Length. A response that has neither chunked |
| transfer coding nor Content-Length is terminated by closure of the |  | transfer coding nor Content-Length is terminated by closure of the |
| connection, and thus is considered complete regardless of the number |  | connection, and thus is considered complete regardless of the number |
| of message body octets received, provided that the header block was |  | of message body octets received, provided that the header block was |
| received intact. |  | received intact. |
| 3.5. Message Parsing Robustness |  | 3.5. Message Parsing Robustness |
| Older HTTP/1.0 user agent implementations might send an extra CRLF |  | Older HTTP/1.0 user agent implementations might send an extra CRLF |
| after a POST request as a lame workaround for some early server |  | after a POST request as a workaround for some early server |
| applications that failed to read message body content that was not |  | applications that failed to read message body content that was not |
| terminated by a line-ending. An HTTP/1.1 user agent MUST NOT preface |  | terminated by a line-ending. An HTTP/1.1 user agent MUST NOT preface |
| or follow a request with an extra CRLF. If terminating the request |  | or follow a request with an extra CRLF. If terminating the request |
| message body with a line-ending is desired, then the user agent MUST |  | message body with a line-ending is desired, then the user agent MUST |
| count the terminating CRLF octets as part of the message body length. |  | count the terminating CRLF octets as part of the message body length. |
| In the interest of robustness, servers SHOULD ignore at least one |  | In the interest of robustness, servers SHOULD ignore at least one |
| empty line received where a request-line is expected. In other |  | empty line received where a request-line is expected. In other |
| words, if a server is reading the protocol stream at the beginning of |  | words, if a server is reading the protocol stream at the beginning of |
| a message and receives a CRLF first, the server SHOULD ignore the |  | a message and receives a CRLF first, the server SHOULD ignore the |
| skipping to change at page 36, line 34 |  | skipping to change at page 36, line 34 |
| The above requirement prevents the need for an infinite buffer when a |  | The above requirement prevents the need for an infinite buffer when a |
| message is being received by an HTTP/1.1 (or later) proxy and |  | message is being received by an HTTP/1.1 (or later) proxy and |
| forwarded to an HTTP/1.0 recipient. |  | forwarded to an HTTP/1.0 recipient. |
| 4.1.2. Decoding chunked |  | 4.1.2. Decoding chunked |
| A process for decoding the chunked transfer coding can be represented |  | A process for decoding the chunked transfer coding can be represented |
| in pseudo-code as: |  | in pseudo-code as: |
| length := 0 |  | length := 0 |
| read chunk-size, chunk-ext (if any) and CRLF |  | read chunk-size, chunk-ext (if any), and CRLF |
| while (chunk-size > 0) { |  | while (chunk-size > 0) { |
| read chunk-data and CRLF |  | read chunk-data and CRLF |
| append chunk-data to decoded-body |  | append chunk-data to decoded-body |
| length := length + chunk-size |  | length := length + chunk-size |
| read chunk-size and CRLF |  | read chunk-size, chunk-ext (if any), and CRLF |
| } |  | } |
| read header-field |  | read header-field |
| while (header-field not empty) { |  | while (header-field not empty) { |
| append header-field to existing header fields |  | append header-field to existing header fields |
| read header-field |  | read header-field |
| } |  | } |
| Content-Length := length |  | Content-Length := length |
| Remove "chunked" from Transfer-Encoding |  | Remove "chunked" from Transfer-Encoding |
| Remove Trailer from existing header fields |  | Remove Trailer from existing header fields |
| skipping to change at page 37, line 12 |  | skipping to change at page 37, line 12 |
| transfer coding and MUST ignore chunk-ext extensions they do not |  | transfer coding and MUST ignore chunk-ext extensions they do not |
| understand. |  | understand. |
| 4.2. Compression Codings |  | 4.2. Compression Codings |
| The codings defined below can be used to compress the payload of a |  | The codings defined below can be used to compress the payload of a |
| message. |  | message. |
| 4.2.1. Compress Coding |  | 4.2.1. Compress Coding |
| The "compress" format is produced by the common UNIX file compression |  | The "compress" coding is an adaptive Lempel-Ziv-Welch (LZW) coding |
| program "compress". This format is an adaptive Lempel-Ziv-Welch |  | [Welch] that is commonly produced by the UNIX file compression |
| coding (LZW). Recipients SHOULD consider "x-compress" to be |  | program "compress". Recipients SHOULD consider "x-compress" to be |
| equivalent to "compress". |  | equivalent to "compress". |
| 4.2.2. Deflate Coding |  | 4.2.2. Deflate Coding |
| The "deflate" format is defined as the "deflate" compression |  | The "deflate" coding is a "zlib" data format [RFC1950] containing a |
| mechanism (described in [RFC1951]) used inside the "zlib" data format |  | "deflate" compressed data stream [RFC1951] that uses a combination of |
| ([RFC1950]). |  | the Lempel-Ziv (LZ77) compression algorithm and Huffman coding. |
| Note: Some incorrect implementations send the "deflate" compressed |  | Note: Some incorrect implementations send the "deflate" compressed |
| data without the zlib wrapper. |  | data without the zlib wrapper. |
| 4.2.3. Gzip Coding |  | 4.2.3. Gzip Coding |
| The "gzip" format is produced by the file compression program "gzip" |  | The "gzip" coding is an LZ77 coding with a 32 bit CRC that is |
| (GNU zip), as described in [RFC1952]. This format is a Lempel-Ziv |  | commonly produced by the gzip file compression program [RFC1952]. |
| coding (LZ77) with a 32 bit CRC. Recipients SHOULD consider "x-gzip" |  | Recipients SHOULD consider "x-gzip" to be equivalent to "gzip". |
| to be equivalent to "gzip". |  |  |
| 4.3. TE |  | 4.3. TE |
| The "TE" header field in a request indicates what transfer codings, |  | The "TE" header field in a request indicates what transfer codings, |
| besides chunked, the client is willing to accept in response, and |  | besides chunked, the client is willing to accept in response, and |
| whether or not the client is willing to accept trailer fields in a |  | whether or not the client is willing to accept trailer fields in a |
| chunked transfer coding. |  | chunked transfer coding. |
| The TE field-value consists of a comma-separated list of transfer |  | The TE field-value consists of a comma-separated list of transfer |
| coding names, each allowing for optional parameters (as described in |  | coding names, each allowing for optional parameters (as described in |
| skipping to change at page 38, line 12 |  | skipping to change at page 38, line 12 |
| Three examples of TE use are below. |  | Three examples of TE use are below. |
| TE: deflate |  | TE: deflate |
| TE: |  | TE: |
| TE: trailers, deflate;q=0.5 |  | TE: trailers, deflate;q=0.5 |
| 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 4.1, on behalf of itself and any downstream |  | defined in Section 4.1, on behalf of itself and any downstream |
| clients. For chained requests, this implies that either: (a) all |  | clients. For requests from an intermediary, this implies that |
| downstream clients are willing to accept trailer fields in the |  | either: (a) all downstream clients are willing to accept trailer |
| forwarded response; or, (b) the client will attempt to buffer the |  | fields in the forwarded response; or, (b) the intermediary will |
| response on behalf of downstream recipients. Note that HTTP/1.1 does |  | attempt to buffer the response on behalf of downstream recipients. |
| not define any means to limit the size of a chunked response such |  | Note that HTTP/1.1 does not define any means to limit the size of a |
| that a client can be assured of buffering the entire response. |  | chunked response such that an intermediary can be assured of |
|  |  | buffering the entire response. |
| When multiple transfer codings are acceptable, the client MAY rank |  | When multiple transfer codings are acceptable, the client MAY rank |
| the codings by preference using a case-insensitive "q" parameter |  | the codings by preference using a case-insensitive "q" parameter |
| (similar to the qvalues used in content negotiation fields, Section |  | (similar to the qvalues used in content negotiation fields, Section |
| 5.3.1 of [Part2]). The rank value is a real number in the range 0 |  | 5.3.1 of [Part2]). The rank value is a real number in the range 0 |
| through 1, where 0.001 is the least preferred and 1 is the most |  | through 1, where 0.001 is the least preferred and 1 is the most |
| preferred; a value of 0 means "not acceptable". |  | preferred; a value of 0 means "not acceptable". |
| 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 |
| acceptable transfer coding is chunked. A message with no transfer |  | acceptable transfer coding is chunked. A message with no transfer |
| skipping to change at page 39, line 4 |  | skipping to change at page 39, line 6 |
| 5.1. Identifying a Target Resource |  | 5.1. Identifying a Target Resource |
| HTTP is used in a wide variety of applications, ranging from general- |  | HTTP is used in a wide variety of applications, ranging from general- |
| purpose computers to home appliances. In some cases, communication |  | purpose computers to home appliances. In some cases, communication |
| options are hard-coded in a client's configuration. However, most |  | options are hard-coded in a client's configuration. However, most |
| HTTP clients rely on the same resource identification mechanism and |  | HTTP clients rely on the same resource identification mechanism and |
| configuration techniques as general-purpose Web browsers. |  | configuration techniques as general-purpose Web browsers. |
| HTTP communication is initiated by a user agent for some purpose. |  | HTTP communication is initiated by a user agent for some purpose. |
| The purpose is a combination of request semantics, which are defined |  | The purpose is a combination of request semantics, which are defined |
| in [Part2], and a target resource upon which to apply those |  | in [Part2], and a target resource upon which to apply those |
| semantics. A URI reference (Section 2.7) is typically used as an |  | semantics. A URI reference (Section 2.7) is typically used as an |
| identifier for the "target resource", which a user agent would |  | identifier for the "target resource", which a user agent would |
| resolve to its absolute form in order to obtain the "target URI". |  | resolve to its absolute form in order to obtain the "target URI". |
| The target URI excludes the reference's fragment identifier |  | The target URI excludes the reference's fragment component, if any, |
| component, if any, since fragment identifiers are reserved for |  | since fragment identifiers are reserved for client-side processing |
| client-side processing ([RFC3986], Section 3.5). |  | ([RFC3986], Section 3.5). |
| 5.2. Connecting Inbound |  | 5.2. Connecting Inbound |
| Once the target URI is determined, a client needs to decide whether a |  | Once the target URI is determined, a client needs to decide whether a |
| network request is necessary to accomplish the desired semantics and, |  | network request is necessary to accomplish the desired semantics and, |
| if so, where that request is to be directed. |  | if so, where that request is to be directed. |
| If the client has a response cache and the request semantics can be |  | If the client has a cache [Part6] and the request can be satisfied by |
| satisfied by a cache ([Part6]), then the request is usually directed |  | it, then the request is usually directed there first. |
| to the cache first. |  |  |
| If the request is not satisfied by a cache, then a typical client |  | If the request is not satisfied by a cache, then a typical client |
| will check its configuration to determine whether a proxy is to be |  | will check its configuration to determine whether a proxy is to be |
| used to satisfy the request. Proxy configuration is implementation- |  | used to satisfy the request. Proxy configuration is implementation- |
| dependent, but is often based on URI prefix matching, selective |  | dependent, but is often based on URI prefix matching, selective |
| authority matching, or both, and the proxy itself is usually |  | authority matching, or both, and the proxy itself is usually |
| identified by an "http" or "https" URI. If a proxy is applicable, |  | identified by an "http" or "https" URI. If a proxy is applicable, |
| the client connects inbound by establishing (or reusing) a connection |  | the client connects inbound by establishing (or reusing) a connection |
| to that proxy. |  | to that proxy. |
| skipping to change at page 45, line 13 |  | skipping to change at page 45, line 13 |
| header field, as specified in Section 6.1, to exclude fields that are |  | header field, as specified in Section 6.1, to exclude fields that are |
| only intended for the incoming connection. |  | only intended for the incoming connection. |
| In order to avoid request loops, a proxy that forwards requests to |  | In order to avoid request loops, a proxy that forwards requests to |
| other proxies MUST be able to recognize and exclude all of its own |  | other proxies MUST be able to recognize and exclude all of its own |
| server names, including any aliases, local variations, or literal IP |  | server names, including any aliases, local variations, or literal IP |
| addresses. |  | addresses. |
| 5.7.1. Via |  | 5.7.1. Via |
| The "Via" header field MUST be sent by a proxy or gateway in |  | The "Via" header field indicates the presence of intermediate |
| forwarded messages to indicate the intermediate protocols and |  | protocols and recipients between the user agent and the server (on |
| recipients between the user agent and the server on requests, and |  | requests) or between the origin server and the client (on responses), |
| between the origin server and the client on responses. It is |  | similar to the "Received" header field in email (Section 3.6.7 of |
| analogous to the "Received" field used by email systems (Section |  | [RFC5322]). Via can be used for tracking message forwards, avoiding |
| 3.6.7 of [RFC5322]). Via is used in HTTP for tracking message |  | request loops, and identifying the protocol capabilities of senders |
| forwards, avoiding request loops, and identifying the protocol |  | along the request/response chain. |
| capabilities of all senders along the request/response chain. |  |  |
|  |  | Via = 1#( received-protocol RWS received-by [ RWS comment ] ) |
| Via = 1#( received-protocol RWS received-by |  |  |
| [ RWS comment ] ) |  |  |
| received-protocol = [ protocol-name "/" ] protocol-version |  | received-protocol = [ protocol-name "/" ] protocol-version |
| ; see Section 6.7 |  | ; see Section 6.7 |
| 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 |  | Multiple Via field values represent each proxy or gateway that has |
| received by the server or client along each segment of the request/ |  | forwarded the message. Each intermediary appends its own information |
| response chain. The received-protocol version is appended to the Via |  | about how the message was received, such that the end result is |
| field value when the message is forwarded so that information about |  | ordered according to the sequence of forwarding recipients. |
| the protocol capabilities of upstream applications remains visible to |  |  |
| all recipients. |  |  |
| The protocol-name is excluded if and only if it would be "HTTP". The |  | A proxy MUST send an appropriate Via header field, as described |
| received-by field is normally the host and optional port number of a |  | below, in each message that it forwards. An HTTP-to-HTTP gateway |
| recipient server or client that subsequently forwarded the message. |  | MUST send an appropriate Via header field in each inbound request |
| However, if the real host is considered to be sensitive information, |  | message and MAY send a Via header field in forwarded response |
| it MAY be replaced by a pseudonym. If the port is not given, it MAY |  | messages. |
| be assumed to be the default port of the received-protocol. |  |  |
| Multiple Via field values represent each proxy or gateway that has |  | For each intermediary, the received-protocol indicates the protocol |
| forwarded the message. Each recipient MUST append its information |  | and protocol version used by the upstream sender of the message. |
| such that the end result is ordered according to the sequence of |  | Hence, the Via field value records the advertised protocol |
| forwarding applications. |  | capabilities of the request/response chain such that they remain |
|  |  | visible to downstream recipients; this can be useful for determining |
|  |  | what backwards-incompatible features might be safe to use in |
|  |  | response, or within a later request, as described in Section 2.6. |
|  |  | For brevity, the protocol-name is omitted when the received protocol |
|  |  | is HTTP. |
|  |  | The received-by field is normally the host and optional port number |
|  |  | of a recipient server or client that subsequently forwarded the |
|  |  | message. However, if the real host is considered to be sensitive |
|  |  | information, it MAY be replaced by a pseudonym. If the port is not |
|  |  | given, it MAY be assumed to be the default port of the received- |
|  |  | protocol. |
| Comments MAY be used in the Via header field to identify the software |  | Comments MAY be used in the Via header field to identify the software |
| of each recipient, analogous to the User-Agent and Server header |  | of each recipient, analogous to the User-Agent and Server header |
| fields. However, all comments in the Via field are optional and MAY |  | fields. However, all comments in the Via field are optional and MAY |
| be removed by any recipient prior to forwarding the message. |  | be removed by any recipient prior to forwarding the message. |
| For example, a request message could be sent from an HTTP/1.0 user |  | For example, a request message could be sent from an HTTP/1.0 user |
| agent to an internal proxy code-named "fred", which uses HTTP/1.1 to |  | agent to an internal proxy code-named "fred", which uses HTTP/1.1 to |
| forward the request to a public proxy at p.example.net, which |  | forward the request to a public proxy at p.example.net, which |
| completes the request by forwarding it to the origin server at |  | completes the request by forwarding it to the origin server at |
| www.example.com. The request received by www.example.com would then |  | www.example.com. The request received by www.example.com would then |
| have the following Via header field: |  | have the following Via header field: |
| Via: 1.0 fred, 1.1 p.example.net (Apache/1.1) |  | Via: 1.0 fred, 1.1 p.example.net |
| A proxy or gateway used as a portal through a network firewall SHOULD |  | A proxy or gateway used as a portal through a network firewall SHOULD |
| NOT forward the names and ports of hosts within the firewall region |  | NOT forward the names and ports of hosts within the firewall region |
| unless it is explicitly enabled to do so. If not enabled, the |  | unless it is explicitly enabled to do so. If not enabled, the |
| received-by host of any host behind the firewall SHOULD be replaced |  | received-by host of any host behind the firewall SHOULD be replaced |
| by an appropriate pseudonym for that host. |  | by an appropriate pseudonym for that host. |
| A proxy or gateway MAY combine an ordered subsequence of Via header |  | A proxy or gateway MAY combine an ordered subsequence of Via header |
| field entries into a single such entry if the entries have identical |  | field entries into a single such entry if the entries have identical |
| received-protocol values. For example, |  | received-protocol values. For example, |
| skipping to change at page 47, line 13 |  | skipping to change at page 47, line 22 |
| A proxy MUST NOT modify the "absolute-path" and "query" parts of the |  | A proxy MUST NOT modify the "absolute-path" and "query" parts of the |
| received request-target when forwarding it to the next inbound |  | received request-target when forwarding it to the next inbound |
| server, except as noted above to replace an empty path with "/" or |  | server, except as noted above to replace an empty path with "/" or |
| "*". |  | "*". |
| A proxy MUST NOT modify header fields that provide information about |  | A proxy MUST NOT modify header fields that provide information about |
| the end points of the communication chain, the resource state, or the |  | the end points of the communication chain, the resource state, or the |
| selected representation. A proxy MAY change the message body through |  | selected representation. A proxy MAY change the message body through |
| application or removal of a transfer coding (Section 4). |  | application or removal of a transfer coding (Section 4). |
| A non-transforming proxy MUST preserve the message payload (Section |  | A non-transforming proxy MUST NOT modify the message payload (Section |
| 3.3 of [Part2]). A transforming proxy MUST preserve the payload of a |  | 3.3 of [Part2]). A transforming proxy MUST NOT modify the payload of |
| message that contains the no-transform cache-control directive. |  | a message that contains the no-transform cache-control directive. |
| A transforming proxy MAY transform the payload of a message that does |  | A transforming proxy MAY transform the payload of a message that does |
| not contain the no-transform cache-control directive; if the payload |  | not contain the no-transform cache-control directive; if the payload |
| is transformed, the transforming proxy MUST add a Warning 214 |  | is transformed, the transforming proxy MUST add a Warning header |
| (Transformation applied) header field if one does not already appear |  | field with the warn-code of 214 ("Transformation Applied") if one |
| in the message (see Section 7.5 of [Part6]). |  | does not already appear in the message (see Section 7.5 of [Part6]). |
|  |  | If the payload of a 200 (OK) response is transformed, the |
|  |  | transforming proxy can also inform downstream recipients that a |
|  |  | transformation has been applied by changing the response status code |
|  |  | to 203 (Non-Authoritative Information) (Section 6.3.4 of [Part2]). |
| 6. Connection Management |  | 6. Connection Management |
| HTTP messaging is independent of the underlying transport or session- |  | HTTP messaging is independent of the underlying transport or session- |
| layer connection protocol(s). HTTP only presumes a reliable |  | layer connection protocol(s). HTTP only presumes a reliable |
| transport with in-order delivery of requests and the corresponding |  | transport with in-order delivery of requests and the corresponding |
| in-order delivery of responses. The mapping of HTTP request and |  | in-order delivery of responses. The mapping of HTTP request and |
| response structures onto the data units of an underlying transport |  | response structures onto the data units of an underlying transport |
| protocol is outside the scope of this specification. |  | protocol is outside the scope of this specification. |
| skipping to change at page 53, line 9 |  | skipping to change at page 53, line 21 |
| closed while it was idle, but from the client's point of view, a |  | closed while it was idle, but from the client's point of view, a |
| request is in progress. |  | request is in progress. |
| Servers SHOULD maintain persistent connections and allow the |  | Servers SHOULD maintain persistent connections and allow the |
| underlying transport's flow control mechanisms to resolve temporary |  | underlying transport's flow control mechanisms to resolve temporary |
| overloads, rather than terminate connections with the expectation |  | overloads, rather than terminate connections with the expectation |
| that clients will retry. The latter technique can exacerbate network |  | that clients will retry. The latter technique can exacerbate network |
| congestion. |  | congestion. |
| A client sending a message body SHOULD monitor the network connection |  | A client sending a message body SHOULD monitor the network connection |
| for an error status code while it is transmitting the request. If |  | for an error response while it is transmitting the request. If the |
| the client sees an error status code, it SHOULD immediately cease |  | client sees an error response, it SHOULD immediately cease |
| transmitting the body and close the connection. |  | transmitting the body and close the connection. |
| 6.6. Tear-down |  | 6.6. Tear-down |
| The Connection header field (Section 6.1) provides a "close" |  | The Connection header field (Section 6.1) provides a "close" |
| connection option that a sender SHOULD send when it wishes to close |  | connection option that a sender SHOULD send when it wishes to close |
| the connection after the current request/response pair. |  | the connection after the current request/response pair. |
| A client that sends a close connection option MUST NOT send further |  | A client that sends a close connection option MUST NOT send further |
| requests on that connection (after the one containing close) and MUST |  | requests on that connection (after the one containing close) and MUST |
| close the connection after reading the final response message |  | close the connection after reading the final response message |
| corresponding to this request. |  | corresponding to this request. |
| A server that receives a close connection option MUST initiate a |  | A server that receives a close connection option MUST initiate a |
| lingering close (see below) of the connection after it sends the |  | close of the connection (see below) after it sends the final response |
| final response to the request that contained close. The server |  | to the request that contained close. The server SHOULD send a close |
| SHOULD send a close connection option in its final response on that |  | connection option in its final response on that connection. The |
| connection. The server MUST NOT process any further requests |  | server MUST NOT process any further requests received on that |
| received on that connection. |  | connection. |
| A server that sends a close connection option MUST initiate a |  | A server that sends a close connection option MUST initiate a close |
| lingering close of the connection after it sends the response |  | of the connection (see below) after it sends the response containing |
| containing close. The server MUST NOT process any further requests |  | close. The server MUST NOT process any further requests received on |
| received on that connection. |  | that connection. |
| A client that receives a close connection option MUST cease sending |  | A client that receives a close connection option MUST cease sending |
| requests on that connection and close the connection after reading |  | requests on that connection and close the connection after reading |
| the response message containing the close; if additional pipelined |  | the response message containing the close; if additional pipelined |
| requests had been sent on the connection, the client SHOULD assume |  | requests had been sent on the connection, the client SHOULD NOT |
| that they will not be processed by the server. |  | assume that they will be processed by the server. |
| If a server performs an immediate close of a TCP connection, there is |  | If a server performs an immediate close of a TCP connection, there is |
| a significant risk that the client will not be able to read the last |  | a significant risk that the client will not be able to read the last |
| HTTP response. If the server receives additional data from the |  | HTTP response. If the server receives additional data from the |
| client on a fully-closed connection, such as another request that was |  | client on a fully-closed connection, such as another request that was |
| sent by the client before receiving the server's response, the |  | sent by the client before receiving the server's response, the |
| server's TCP stack will send a reset packet to the client; |  | server's TCP stack will send a reset packet to the client; |
| unfortunately, the reset packet might erase the client's |  | unfortunately, the reset packet might erase the client's |
| unacknowledged input buffers before they can be read and interpreted |  | unacknowledged input buffers before they can be read and interpreted |
| by the client's HTTP parser. |  | by the client's HTTP parser. |
| To avoid the TCP reset problem, a server can perform a lingering |  | To avoid the TCP reset problem, servers typically close a connection |
| close on a connection by closing only the write side of the read/ |  | in stages. First, the server performs a half-close by closing only |
| write connection (a half-close) and continuing to read from the |  | the write side of the read/write connection. The server then |
| connection until the connection is closed by the client or the server |  | continues to read from the connection until it receives a |
| is reasonably certain that its own TCP stack has received the |  | corresponding close by the client, or until the server is reasonably |
| client's acknowledgement of the packet(s) containing the server's |  | certain that its own TCP stack has received the client's |
| last response. It is then safe for the server to fully close the |  | acknowledgement of the packet(s) containing the server's last |
| connection. |  | response. Finally, the server fully closes the connection. |
| It is unknown whether the reset problem is exclusive to TCP or might |  | It is unknown whether the reset problem is exclusive to TCP or might |
| also be found in other transport connection protocols. |  | also be found in other transport connection protocols. |
| 6.7. Upgrade |  | 6.7. Upgrade |
| The "Upgrade" header field is intended to provide a simple mechanism |  | The "Upgrade" header field is intended to provide a simple mechanism |
| for transitioning from HTTP/1.1 to some other protocol on the same |  | for transitioning from HTTP/1.1 to some other protocol on the same |
| connection. A client MAY send a list of protocols in the Upgrade |  | connection. A client MAY send a list of protocols in the Upgrade |
| header field of a request to invite the server to switch to one or |  | header field of a request to invite the server to switch to one or |
| more of those protocols before sending the final response. A server |  | more of those protocols, in order of descending preference, before |
| MUST send an Upgrade header field in 101 (Switching Protocols) |  | sending the final response. A server MAY ignore a received Upgrade |
| responses to indicate which protocol(s) are being switched to, and |  | header field if it wishes to continue using the current protocol on |
| MUST send it in 426 (Upgrade Required) responses to indicate |  | that connection. |
| acceptable protocols. A server MAY send an Upgrade header field in |  |  |
| any other response to indicate that they might be willing to upgrade |  |  |
| to one of the specified protocols for a future request. |  |  |
| Upgrade = 1#protocol |  | Upgrade = 1#protocol |
| protocol = protocol-name ["/" protocol-version] |  | protocol = protocol-name ["/" protocol-version] |
| protocol-name = token |  | protocol-name = token |
| protocol-version = token |  | protocol-version = token |
| For example, |  | A server that sends a 101 (Switching Protocols) response MUST send an |
|  |  | Upgrade header field to indicate the new protocol(s) to which the |
|  |  | connection is being switched; if multiple protocol layers are being |
|  |  | switched, the new protocols MUST be listed in layer-ascending order. |
|  |  | A server MUST NOT switch to a protocol that was not indicated by the |
|  |  | client in the corresponding request's Upgrade header field. A server |
|  |  | MAY choose to ignore the order of preference indicated by the client |
|  |  | and select the new protocol(s) based on other factors, such as the |
|  |  | nature of the request or the current load on the server. |
| Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 |  | A server that sends a 426 (Upgrade Required) response MUST send an |
|  |  | Upgrade header field to indicate the acceptable protocols, in order |
|  |  | of descending preference. |
| Upgrade eases the difficult transition between incompatible protocols |  | A server MAY send an Upgrade header field in any other response to |
| by allowing the client to initiate a request in the more commonly |  | advertise that it implements support for upgrading to the listed |
| supported protocol while indicating to the server that it would like |  | protocols, in order of descending preference, when appropriate for a |
| to use a "better" protocol if available (where "better" is determined |  | future request. |
| by the server, possibly according to the nature of the request method |  |  |
| or target resource). |  | The following is a hypothetical example sent by a client: |
|  |  | GET /hello.txt HTTP/1.1 |
|  |  | Host: www.example.com |
|  |  | Connection: upgrade |
|  |  | Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 |
| Upgrade cannot be used to insist on a protocol change; its acceptance |  | Upgrade cannot be used to insist on a protocol change; its acceptance |
| and use by the server is optional. The capabilities and nature of |  | and use by the server is optional. The capabilities and nature of |
| the application-level communication after the protocol change is |  | the application-level communication after the protocol change is |
| entirely dependent upon the new protocol chosen, although the first |  | entirely dependent upon the new protocol(s) chosen, although the |
| action after changing the protocol MUST be a response to the initial |  | first action after changing the protocol MUST be a response to the |
| HTTP request that contained the Upgrade header field. |  | initial HTTP request that contained the Upgrade header field. |
| For example, if the Upgrade header field is received in a GET request |  | For example, if the Upgrade header field is received in a GET request |
| and the server decides to switch protocols, then it first responds |  | and the server decides to switch protocols, it first responds with a |
| with a 101 (Switching Protocols) message in HTTP/1.1 and then |  | 101 (Switching Protocols) message in HTTP/1.1 and then immediately |
| immediately follows that with the new protocol's equivalent of a |  | follows that with the new protocol's equivalent of a response to a |
| response to a GET on the target resource. This allows a connection |  | GET on the target resource. This allows a connection to be upgraded |
| to be upgraded to protocols with the same semantics as HTTP without |  | to protocols with the same semantics as HTTP without the latency cost |
| the latency cost of an additional round-trip. A server MUST NOT |  | of an additional round-trip. A server MUST NOT switch protocols |
| switch protocols unless the received message semantics can be honored |  | unless the received message semantics can be honored by the new |
| by the new protocol; an OPTIONS request can be honored by any |  | protocol; an OPTIONS request can be honored by any protocol. |
| protocol. |  |  |
| When Upgrade is sent, a sender MUST also send a Connection header |  | The following is an example response to the above hypothetical |
| field (Section 6.1) that contains the "upgrade" connection option, in |  | request: |
|  |  | HTTP/1.1 101 Switching Protocols |
|  |  | Connection: upgrade |
|  |  | Upgrade: HTTP/2.0 |
|  |  | [... data stream switches to HTTP/2.0 with an appropriate response |
|  |  | (as defined by new protocol) to the "GET /hello.txt" request ...] |
|  |  | When Upgrade is sent, the sender MUST also send a Connection header |
|  |  | field (Section 6.1) that contains an "upgrade" connection option, in |
| order to prevent Upgrade from being accidentally forwarded by |  | order to prevent Upgrade from being accidentally forwarded by |
| intermediaries that might not implement the listed protocols. A |  | intermediaries that might not implement the listed protocols. A |
| server MUST ignore an Upgrade header field that is received in an |  | server MUST ignore an Upgrade header field that is received in an |
| HTTP/1.0 request. |  | HTTP/1.0 request. |
| The Upgrade header field only applies to switching application-level |  | The Upgrade header field only applies to switching protocols on top |
| protocols on the existing connection; it cannot be used to switch to |  | of the existing connection; it cannot be used to switch the |
| a protocol on a different connection. For that purpose, it is more |  | underlying connection (transport) protocol, nor to switch the |
| appropriate to use a 3xx (Redirection) response (Section 6.4 of |  | existing communication to a different connection. For those |
| [Part2]). |  | purposes, it is more appropriate to use a 3xx (Redirection) response |
|  |  | (Section 6.4 of [Part2]). |
| This specification only defines the protocol name "HTTP" for use by |  | This specification only defines the protocol name "HTTP" for use by |
| the family of Hypertext Transfer Protocols, as defined by the HTTP |  | the family of Hypertext Transfer Protocols, as defined by the HTTP |
| version rules of Section 2.6 and future updates to this |  | version rules of Section 2.6 and future updates to this |
| specification. Additional tokens ought to be registered with IANA |  | specification. Additional tokens ought to be registered with IANA |
| using the registration procedure defined in Section 7.6. |  | using the registration procedure defined in Section 7.5. |
| 7. IANA Considerations |  | 7. IANA Considerations |
| 7.1. Header Field Registration |  | 7.1. Header Field Registration |
| HTTP header fields are registered within the Message Header Field |  | HTTP header fields are registered within the Message Header Field |
| Registry [BCP90] maintained by IANA at <http://www.iana.org/ |  | Registry maintained at <http://www.iana.org/assignments/ |
| assignments/message-headers/message-header-index.html>. |  | message-headers/message-header-index.html>. |
| This document defines the following HTTP header fields, so their |  | This document defines the following HTTP header fields, so their |
| associated registry entries shall be updated according to the |  | associated registry entries shall be updated according to the |
| permanent registrations below: |  | permanent registrations below (see [BCP90]): |
| +-------------------+----------+----------+---------------+ |  | +-------------------+----------+----------+---------------+ |
| | Header Field Name | Protocol | Status | Reference | |  | | Header Field Name | Protocol | Status | Reference | |
| +-------------------+----------+----------+---------------+ |  | +-------------------+----------+----------+---------------+ |
| | Connection | http | standard | Section 6.1 | |  | | Connection | http | standard | Section 6.1 | |
| | Content-Length | http | standard | Section 3.3.2 | |  | | Content-Length | http | standard | Section 3.3.2 | |
| | Host | http | standard | Section 5.4 | |  | | Host | http | standard | Section 5.4 | |
| | TE | http | standard | Section 4.3 | |  | | TE | http | standard | Section 4.3 | |
| | Trailer | http | standard | Section 4.1.1 | |  | | Trailer | http | standard | Section 4.1.1 | |
| | Transfer-Encoding | http | standard | Section 3.3.1 | |  | | Transfer-Encoding | http | standard | Section 3.3.1 | |
| skipping to change at page 58, line 4 |  | skipping to change at page 58, line 35 |
| Magic number(s): none |  | Magic number(s): none |
| File extension(s): none |  | File extension(s): none |
| Macintosh file type code(s): none |  | Macintosh file type code(s): none |
| Person and email address to contact for further information: See |  | Person and email address to contact for further information: See |
| Authors Section. |  | Authors Section. |
| Intended usage: COMMON |  | Intended usage: COMMON |
| Restrictions on usage: none |  | Restrictions on usage: none |
| Author/Change controller: IESG |  | Author: See Authors Section. |
|  |  | Change controller: IESG |
| 7.3.2. Internet Media Type application/http |  | 7.3.2. Internet Media Type application/http |
| The application/http type can be used to enclose a pipeline of one or |  | The application/http type can be used to enclose a pipeline of one or |
| more HTTP request or response messages (not intermixed). |  | more HTTP request or response messages (not intermixed). |
| Type name: application |  | Type name: application |
| Subtype name: http |  | Subtype name: http |
| Required parameters: none |  | Required parameters: none |
| Optional parameters: version, msgtype |  | Optional parameters: version, msgtype |
| version: The HTTP-version number of the enclosed messages (e.g., |  | version: The HTTP-version number of the enclosed messages (e.g., |
| "1.1"). If not present, the version can be determined from the |  | "1.1"). If not present, the version can be determined from the |
| first line of the body. |  | first line of the body. |
| skipping to change at page 59, line 12 |  | skipping to change at page 59, line 45 |
| Macintosh file type code(s): none |  | Macintosh file type code(s): none |
| Person and email address to contact for further information: See |  | Person and email address to contact for further information: See |
| Authors Section. |  | Authors Section. |
| Intended usage: COMMON |  | Intended usage: COMMON |
| Restrictions on usage: none |  | Restrictions on usage: none |
| Author/Change controller: IESG |  | Author: See Authors Section. |
|  |  | Change controller: IESG |
| 7.4. Transfer Coding Registry |  | 7.4. Transfer Coding Registry |
| The HTTP Transfer Coding Registry defines the name space for transfer |  | The HTTP Transfer Coding Registry defines the name space for transfer |
| coding names. |  | coding names. It is maintained at |
|  |  | <http://www.iana.org/assignments/http-parameters>. |
|  |  | 7.4.1. Procedure |
| Registrations MUST include the following fields: |  | Registrations MUST include the following fields: |
| o Name |  | o Name |
| o Description |  | o Description |
| o Pointer to specification text |  | o Pointer to specification text |
| Names of transfer codings MUST NOT overlap with names of content |  | Names of transfer codings MUST NOT overlap with names of content |
| codings (Section 3.1.2.1 of [Part2]) unless the encoding |  | codings (Section 3.1.2.1 of [Part2]) unless the encoding |
| transformation is identical, as is the case for the compression |  | transformation is identical, as is the case for the compression |
| codings defined in Section 4.2. |  | codings defined in Section 4.2. |
| Values to be added to this name space require IETF Review (see |  | Values to be added to this name space require IETF Review (see |
| Section 4.1 of [RFC5226]), and MUST conform to the purpose of |  | Section 4.1 of [RFC5226]), and MUST conform to the purpose of |
| transfer coding defined in this section. Use of program names for |  | transfer coding defined in this specification. |
| the identification of encoding formats is not desirable and is |  |  |
| discouraged for future encodings. |  |  |
| The registry itself is maintained at |  | Use of program names for the identification of encoding formats is |
| <http://www.iana.org/assignments/http-parameters>. |  | not desirable and is discouraged for future encodings. |
| 7.5. Transfer Coding Registration |  | 7.4.2. Registration |
| The HTTP Transfer Coding Registry shall be updated with the |  | The HTTP Transfer Coding Registry shall be updated with the |
| registrations below: |  | registrations below: |
| +----------+----------------------------------------+---------------+ |  | +------------+--------------------------------------+---------------+ |
| | Name | Description | Reference | |  | | Name | Description | Reference | |
| +----------+----------------------------------------+---------------+ |  | +------------+--------------------------------------+---------------+ |
| | chunked | Transfer in a series of chunks | Section 4.1 | |  | | chunked | Transfer in a series of chunks | Section 4.1 | |
| | compress | UNIX "compress" program method | Section 4.2.1 | |  | | compress | UNIX "compress" data format [Welch] | Section 4.2.1 | |
| | deflate | "deflate" compression mechanism | Section 4.2.2 | |  | | deflate | "deflate" compressed data | Section 4.2.2 | |
| | | ([RFC1951]) used inside the "zlib" | | |  | | | ([RFC1951]) inside the "zlib" data | | |
| | | data format ([RFC1950]) | | |  | | | format ([RFC1950]) | | |
| | gzip | Same as GNU zip [RFC1952] | Section 4.2.3 | |  | | gzip | GZIP file format [RFC1952] | Section 4.2.3 | |
| +----------+----------------------------------------+---------------+ |  | | x-compress | Deprecated (alias for compress) | Section 4.2.1 | |
|  |  | | x-gzip | Deprecated (alias for gzip) | Section 4.2.3 | |
|  |  | +------------+--------------------------------------+---------------+ |
| 7.6. Upgrade Token Registry |  | 7.5. Upgrade Token Registry |
| The HTTP Upgrade Token Registry defines the name space for protocol- |  | The HTTP Upgrade Token Registry defines the name space for protocol- |
| name tokens used to identify protocols in the Upgrade header field. |  | name tokens used to identify protocols in the Upgrade header field. |
|  |  | The registry is maintained at |
|  |  | <http://www.iana.org/assignments/http-upgrade-tokens>. |
|  |  | 7.5.1. Procedure |
| Each registered protocol name is associated with contact information |  | Each registered protocol name is associated with contact information |
| and an optional set of specifications that details how the connection |  | and an optional set of specifications that details how the connection |
| will be processed after it has been upgraded. |  | will be processed after it has been upgraded. |
| Registrations happen on a "First Come First Served" basis (see |  | Registrations happen on a "First Come First Served" basis (see |
| Section 4.1 of [RFC5226]) and are subject to the following rules: |  | Section 4.1 of [RFC5226]) and are subject to the following rules: |
| 1. A protocol-name token, once registered, stays registered forever. |  | 1. A protocol-name token, once registered, stays registered forever. |
| 2. The registration MUST name a responsible party for the |  | 2. The registration MUST name a responsible party for the |
| skipping to change at page 61, line 5 |  | skipping to change at page 61, line 45 |
| The IANA will keep a record of all such changes, and make them |  | The IANA will keep a record of all such changes, and make them |
| available upon request. |  | available upon request. |
| 7. The IESG MAY reassign responsibility for a protocol token. This |  | 7. The IESG MAY reassign responsibility for a protocol token. This |
| will normally only be used in the case when a responsible party |  | will normally only be used in the case when a responsible party |
| cannot be contacted. |  | cannot be contacted. |
| This registration procedure for HTTP Upgrade Tokens replaces that |  | This registration procedure for HTTP Upgrade Tokens replaces that |
| previously defined in Section 7.2 of [RFC2817]. |  | previously defined in Section 7.2 of [RFC2817]. |
| 7.7. Upgrade Token Registration |  | 7.5.2. Upgrade Token Registration |
| The HTTP Upgrade Token Registry shall be updated with the |  | The HTTP Upgrade Token Registry shall be updated with the |
| registration below: |  | registration below: |
| +-------+----------------------+----------------------+-------------+ |  | +-------+----------------------+----------------------+-------------+ |
| | Value | Description | Expected Version | Reference | |  | | Value | Description | Expected Version | Reference | |
| | | | Tokens | | |  | | | | Tokens | | |
| +-------+----------------------+----------------------+-------------+ |  | +-------+----------------------+----------------------+-------------+ |
| | HTTP | Hypertext Transfer | any DIGIT.DIGIT | Section 2.6 | |  | | HTTP | Hypertext Transfer | any DIGIT.DIGIT | Section 2.6 | |
| | | Protocol | (e.g, "2.0") | | |  | | | Protocol | (e.g, "2.0") | | |
| skipping to change at page 62, line 28 |  | skipping to change at page 63, line 23 |
| To promote interoperability, this specification makes specific |  | To promote interoperability, this specification makes specific |
| recommendations for minimum size limits on request-line |  | recommendations for minimum size limits on request-line |
| (Section 3.1.1) and blocks of header fields (Section 3.2). These are |  | (Section 3.1.1) and blocks of header fields (Section 3.2). These are |
| minimum recommendations, chosen to be supportable even by |  | minimum recommendations, chosen to be supportable even by |
| implementations with limited resources; it is expected that most |  | implementations with limited resources; it is expected that most |
| implementations will choose substantially higher limits. |  | implementations will choose substantially higher limits. |
| This specification also provides a way for servers to reject messages |  | This specification also provides a way for servers to reject messages |
| that have request-targets that are too long (Section 6.5.12 of |  | that have request-targets that are too long (Section 6.5.12 of |
| [Part2]) or request entities that are too large (Section 6.5 of |  | [Part2]) or request entities that are too large (Section 6.5 of |
| [Part2]). |  | [Part2]). Additional status codes related to capacity limits have |
|  |  | been defined by extensions to HTTP [RFC6585]. |
| Recipients SHOULD carefully limit the extent to which they read other |  | Recipients SHOULD carefully limit the extent to which they read other |
| fields, including (but not limited to) request methods, response |  | fields, including (but not limited to) request methods, response |
| status phrases, header field-names, and body chunks, so as to avoid |  | status phrases, header field-names, and body chunks, so as to avoid |
| denial of service attacks without impeding interoperability. |  | denial of service attacks without impeding interoperability. |
| 8.4. Message Integrity |  | 8.4. Message Integrity |
| HTTP does not define a specific mechanism for ensuring message |  | HTTP does not define a specific mechanism for ensuring message |
| integrity, instead relying on the error-detection ability of |  | integrity, instead relying on the error-detection ability of |
| skipping to change at page 64, line 9 |  | skipping to change at page 65, line 5 |
| Since 1999, the following contributors have helped improve the HTTP |  | Since 1999, the following contributors have helped improve the HTTP |
| specification by reporting bugs, asking smart questions, drafting or |  | specification by reporting bugs, asking smart questions, drafting or |
| reviewing text, and evaluating open issues: |  | reviewing text, and evaluating open issues: |
| Adam Barth, Adam Roach, Addison Phillips, Adrian Chadd, Adrien W. de |  | Adam Barth, Adam Roach, Addison Phillips, Adrian Chadd, Adrien W. de |
| Croy, Alan Ford, Alan Ruttenberg, Albert Lunde, Alek Storm, Alex |  | Croy, Alan Ford, Alan Ruttenberg, Albert Lunde, Alek Storm, Alex |
| Rousskov, Alexandre Morgaut, Alexey Melnikov, Alisha Smith, Amichai |  | Rousskov, Alexandre Morgaut, Alexey Melnikov, Alisha Smith, Amichai |
| Rothman, Amit Klein, Amos Jeffries, Andreas Maier, Andreas Petersson, |  | Rothman, Amit Klein, Amos Jeffries, Andreas Maier, Andreas Petersson, |
| Anil Sharma, Anne van Kesteren, Anthony Bryan, Asbjorn Ulsberg, Ashok |  | Anil Sharma, Anne van Kesteren, Anthony Bryan, Asbjorn Ulsberg, Ashok |
| Kumar, Balachander Krishnamurthy, Barry Leiba, Ben Laurie, Benjamin |  | Kumar, Balachander Krishnamurthy, Barry Leiba, Ben Laurie, Benjamin |
| Niven-Jenkins, Bil Corry, Bill Burke, Bjoern Hoehrmann, Bob |  | Carlyle, Benjamin Niven-Jenkins, Bil Corry, Bill Burke, Bjoern |
| Scheifler, Boris Zbarsky, Brett Slatkin, Brian Kell, Brian McBarron, |  | Hoehrmann, Bob Scheifler, Boris Zbarsky, Brett Slatkin, Brian Kell, |
| Brian Pane, Brian Smith, Bryce Nesbitt, Cameron Heavon-Jones, Carl |  | Brian McBarron, Brian Pane, Brian Raymor, Brian Smith, Bryce Nesbitt, |
| Kugler, Carsten Bormann, Charles Fry, Chris Newman, Chris Weber, |  | Cameron Heavon-Jones, Carl Kugler, Carsten Bormann, Charles Fry, |
| Cyrus Daboo, Dale Robert Anderson, Dan Wing, Dan Winship, Daniel |  | Chris Newman, Cyrus Daboo, Dale Robert Anderson, Dan Wing, Dan |
| Stenberg, Darrel Miller, Dave Cridland, Dave Crocker, Dave Kristol, |  | Winship, Daniel Stenberg, Darrel Miller, Dave Cridland, Dave Crocker, |
| David Booth, David Singer, David W. Morris, Diwakar Shetty, Dmitry |  | Dave Kristol, Dave Thaler, David Booth, David Singer, David W. |
| Kurochkin, Drummond Reed, Duane Wessels, Duncan Cragg, Edward Lee, |  | Morris, Diwakar Shetty, Dmitry Kurochkin, Drummond Reed, Duane |
| Eliot Lear, Eran Hammer-Lahav, Eric D. Williams, Eric J. Bowman, Eric |  | Wessels, Edward Lee, Eitan Adler, Eliot Lear, Eran Hammer-Lahav, Eric |
| Lawrence, Eric Rescorla, Erik Aronesty, Evan Prodromou, Florian |  | D. Williams, Eric J. Bowman, Eric Lawrence, Eric Rescorla, Erik |
| Weimer, Frank Ellermann, Fred Bohle, Gabriel Montenegro, Geoffrey |  | Aronesty, Evan Prodromou, Felix Geisendoerfer, Florian Weimer, Frank |
| Sneddon, Gervase Markham, Grahame Grieve, Greg Wilkins, Harald Tveit |  | Ellermann, Fred Akalin, Fred Bohle, Frederic Kayser, Gabor Molnar, |
|  |  | Gabriel Montenegro, Geoffrey Sneddon, Gervase Markham, Gili Tzabari, |
|  |  | Grahame Grieve, Greg Wilkins, Grzegorz Calkowski, Harald Tveit |
| Alvestrand, Harry Halpin, Helge Hess, Henrik Nordstrom, Henry S. |  | Alvestrand, Harry Halpin, Helge Hess, Henrik Nordstrom, Henry S. |
| Thompson, Henry Story, Herbert van de Sompel, Howard Melman, Hugo |  | Thompson, Henry Story, Herbert van de Sompel, Herve Ruellan, Howard |
| Haas, Ian Fette, Ian Hickson, Ido Safruti, Ilya Grigorik, Ingo |  | Melman, Hugo Haas, Ian Fette, Ian Hickson, Ido Safruti, Ilari |
| Struck, J. Ross Nicoll, James H. Manger, James Lacey, James M. Snell, |  | Liusvaara, Ilya Grigorik, Ingo Struck, J. Ross Nicoll, James Cloos, |
| Jamie Lokier, Jan Algermissen, Jeff Hodges (who came up with the term |  | James H. Manger, James Lacey, James M. Snell, Jamie Lokier, Jan |
| 'effective Request-URI'), Jeff Walden, Jeroen de Borst, Jim Luther, |  | Algermissen, Jeff Hodges (who came up with the term 'effective |
| Joe D. Williams, Joe Gregorio, Joe Orton, John C. Klensin, John C. |  | Request-URI'), Jeff Pinner, Jeff Walden, Jim Luther, Jitu Padhye, Joe |
|  |  | D. Williams, Joe Gregorio, Joe Orton, John C. Klensin, John C. |
| Mallery, John Cowan, John Kemp, John Panzer, John Schneider, John |  | Mallery, John Cowan, John Kemp, John Panzer, John Schneider, John |
| Stracke, John Sullivan, Jonas Sicking, Jonathan A. Rees, Jonathan |  | Stracke, John Sullivan, Jonas Sicking, Jonathan A. Rees, Jonathan |
| Billington, Jonathan Moore, Jonathan Rees, Jonathan Silvera, Jordi |  | Billington, Jonathan Moore, Jonathan Silvera, Jordi Ros, Joris |
| Ros, Joris Dobbelsteen, Josh Cohen, Julien Pierre, Jungshik Shin, |  | Dobbelsteen, Josh Cohen, Julien Pierre, Jungshik Shin, Justin |
| Justin Chapweske, Justin Erenkrantz, Justin James, Kalvinder Singh, |  | Chapweske, Justin Erenkrantz, Justin James, Kalvinder Singh, Karl |
| Karl Dubost, Keith Hoffman, Keith Moore, Ken Murchison, Koen Holtman, |  | Dubost, Keith Hoffman, Keith Moore, Ken Murchison, Koen Holtman, |
| Konstantin Voronkov, Kris Zyp, Lisa Dusseault, Maciej Stachowiak, |  | Konstantin Voronkov, Kris Zyp, Lisa Dusseault, Maciej Stachowiak, |
| Marc Schneider, Marc Slemko, Mark Baker, Mark Pauley, Mark Watson, |  | Manu Sporny, Marc Schneider, Marc Slemko, Mark Baker, Mark Pauley, |
| Markus Isomaki, Markus Lanthaler, Martin J. Duerst, Martin Musatov, |  | Mark Watson, Markus Isomaki, Markus Lanthaler, Martin J. Duerst, |
| Martin Nilsson, Martin Thomson, Matt Lynch, Matthew Cox, Max Clark, |  | Martin Musatov, Martin Nilsson, Martin Thomson, Matt Lynch, Matthew |
| Michael Burrows, Michael Hausenblas, Mike Amundsen, Mike Belshe, Mike |  | Cox, Max Clark, Michael Burrows, Michael Hausenblas, Michael Sweet, |
| Kelly, Mike Schinkel, Miles Sabin, Murray S. Kucherawy, Mykyta |  | Mike Amundsen, Mike Belshe, Mike Bishop, Mike Kelly, Mike Schinkel, |
| Yevstifeyev, Nathan Rixham, Nicholas Shanks, Nico Williams, Nicolas |  | Miles Sabin, Murray S. Kucherawy, Mykyta Yevstifeyev, Nathan Rixham, |
| Alvarez, Nicolas Mailhot, Noah Slater, Pablo Castro, Pat Hayes, |  | Nicholas Shanks, Nico Williams, Nicolas Alvarez, Nicolas Mailhot, |
| Patrick R. McManus, Patrik Faltstrom, Paul E. Jones, Paul Hoffman, |  | Noah Slater, Osama Mazahir, Pablo Castro, Pat Hayes, Patrick R. |
| Paul Marquess, Peter Lepeska, Peter Saint-Andre, Peter Watkins, Phil |  | McManus, Paul E. Jones, Paul Hoffman, Paul Marquess, Peter Lepeska, |
| Archer, Philippe Mougin, Phillip Hallam-Baker, Poul-Henning Kamp, |  | Peter Occil, Peter Saint-Andre, Peter Watkins, Phil Archer, Philippe |
|  |  | Mougin, Phillip Hallam-Baker, Piotr Dobrogost, Poul-Henning Kamp, |
| Preethi Natarajan, Rajeev Bector, Ray Polk, Reto Bachmann-Gmuer, |  | Preethi Natarajan, Rajeev Bector, Ray Polk, Reto Bachmann-Gmuer, |
| Richard Cyganiak, Robert Brewer, Robert Collins, Robert O'Callahan, |  | Richard Cyganiak, Robby Simpson, Robert Brewer, Robert Collins, |
| Robert Olofsson, Robert Sayre, Robert Siemer, Robert de Wilde, |  | Robert Mattson, Robert O'Callahan, Robert Olofsson, Robert Sayre, |
| Roberto Javier Godoy, Roberto Peon, Roland Zink, Ronny Widjaja, S. |  | Robert Siemer, Robert de Wilde, Roberto Javier Godoy, Roberto Peon, |
| Mike Dierken, Salvatore Loreto, Sam Johnston, Sam Ruby, Scott |  | Roland Zink, Ronny Widjaja, S. Mike Dierken, Salvatore Loreto, Sam |
| Lawrence (who maintained the original issues list), Sean B. Palmer, |  | Johnston, Sam Pullara, Sam Ruby, Scott Lawrence (who maintained the |
| Shane McCarron, Stefan Eissing, Stefan Tilkov, Stefanos Harhalakis, |  | original issues list), Sean B. Palmer, Shane McCarron, Shigeki Ohtsu, |
| Stephane Bortzmeyer, Stephen Farrell, Stephen Ludin, Stuart Williams, |  | Stefan Eissing, Stefan Tilkov, Stefanos Harhalakis, Stephane |
| Subbu Allamaraju, Subramanian Moonesamy, Sylvain Hellegouarch, Tapan |  | Bortzmeyer, Stephen Farrell, Stephen Ludin, Stuart Williams, Subbu |
| Divekar, Tatsuya Hayashi, Ted Hardie, Thomas Broyer, Thomas Fossati, |  | Allamaraju, Sylvain Hellegouarch, Tapan Divekar, Tatsuya Hayashi, Ted |
| Thomas Nordin, Thomas Roessler, Tim Bray, Tim Morgan, Tim Olsen, |  | Hardie, Thomas Broyer, Thomas Fossati, Thomas Maslen, Thomas Nordin, |
| Tobias Oberstein, Tom Zhou, Travis Snoozy, Tyler Close, Vincent |  | Thomas Roessler, Tim Bray, Tim Morgan, Tim Olsen, Tom Zhou, Travis |
| Murphy, Wenbo Zhu, Werner Baumann, Wilbur Streett, Wilfredo Sanchez |  | Snoozy, Tyler Close, Vincent Murphy, Wenbo Zhu, Werner Baumann, |
| Vega, William A. Rowe Jr., William Chan, Willy Tarreau, Xiaoshu Wang, |  | Wilbur Streett, Wilfredo Sanchez Vega, William A. Rowe Jr., William |
| Yaron Goland, Yngve Nysaeter Pettersen, Yoav Nir, Yogesh Bang, Yutaka |  | Chan, Willy Tarreau, Xiaoshu Wang, Yaron Goland, Yngve Nysaeter |
| Oiwa, Yves Lafon (long-time member of the editor team), Zed A. Shaw, |  | Pettersen, Yoav Nir, Yogesh Bang, Yutaka Oiwa, Yves Lafon (long-time |
| and Zhong Yu. |  | member of the editor team), Zed A. Shaw, and Zhong Yu. |
| See Section 16 of [RFC2616] for additional acknowledgements from |  | See Section 16 of [RFC2616] for additional acknowledgements from |
| prior revisions. |  | prior revisions. |
| 10. References |  | 10. References |
| 10.1. Normative References |  | 10.1. Normative References |
| [Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext |  | [Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext |
| Transfer Protocol (HTTP/1.1): Semantics and Content", |  | Transfer Protocol (HTTP/1.1): Semantics and Content", |
| draft-ietf-httpbis-p2-semantics-22 (work in progress), |  | draft-ietf-httpbis-p2-semantics-23 (work in progress), |
| February 2013. |  | July 2013. |
| [Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext |  | [Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext |
| Transfer Protocol (HTTP/1.1): Conditional Requests", |  | Transfer Protocol (HTTP/1.1): Conditional Requests", |
| draft-ietf-httpbis-p4-conditional-22 (work in |  | draft-ietf-httpbis-p4-conditional-23 (work in |
| progress), February 2013. |  | progress), July 2013. |
| [Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |  | [Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |
| "Hypertext Transfer Protocol (HTTP/1.1): Range |  | "Hypertext Transfer Protocol (HTTP/1.1): Range |
| Requests", draft-ietf-httpbis-p5-range-22 (work in |  | Requests", draft-ietf-httpbis-p5-range-23 (work in |
| progress), February 2013. |  | progress), July 2013. |
| [Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, |  | [Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, |
| Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", |  | Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", |
| draft-ietf-httpbis-p6-cache-22 (work in progress), |  | draft-ietf-httpbis-p6-cache-23 (work in progress), |
| February 2013. |  | July 2013. |
| [Part7] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext |  | [Part7] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext |
| Transfer Protocol (HTTP/1.1): Authentication", |  | Transfer Protocol (HTTP/1.1): Authentication", |
| draft-ietf-httpbis-p7-auth-22 (work in progress), |  | draft-ietf-httpbis-p7-auth-23 (work in progress), |
| February 2013. |  | July 2013. |
|  |  | [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, |
|  |  | RFC 793, September 1981. |
| [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. |
| [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. |
| [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. |
| skipping to change at page 66, line 24 |  | skipping to change at page 67, line 27 |
| 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. |
|  |  | [Welch] Welch, T., "A Technique for High Performance Data |
|  |  | Compression", IEEE Computer 17(6), June 1984. |
| 10.2. Informative References |  | 10.2. Informative References |
| [BCP115] Hansen, T., Hardie, T., and L. Masinter, "Guidelines |  | [BCP115] Hansen, T., Hardie, T., and L. Masinter, "Guidelines |
| and Registration Procedures for New URI Schemes", |  | and Registration Procedures for New URI Schemes", |
| BCP 115, RFC 4395, February 2006. |  | BCP 115, RFC 4395, February 2006. |
| [BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type |  | [BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type |
| Specifications and Registration Procedures", BCP 13, |  | Specifications and Registration Procedures", BCP 13, |
| RFC 6838, January 2013. |  | RFC 6838, January 2013. |
| [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration |  | [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration |
| Procedures for Message Header Fields", BCP 90, |  | Procedures for Message Header Fields", BCP 90, |
| RFC 3864, September 2004. |  | RFC 3864, September 2004. |
| [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. |
| [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 |
| 1, #2, November 2001, |  | Technology 1(2), November 2001, |
| <http://arxiv.org/abs/cs.SE/0105018>. |  | <http://arxiv.org/abs/cs.SE/0105018>. |
| [RFC1919] Chatel, M., "Classical versus Transparent IP Proxies", |  | [RFC1919] Chatel, M., "Classical versus Transparent IP Proxies", |
| RFC 1919, March 1996. |  | RFC 1919, March 1996. |
| [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, |  | [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, |
| "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, |  | "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, |
| May 1996. |  | May 1996. |
| [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet |  | [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet |
| skipping to change at page 68, line 9 |  | skipping to change at page 69, line 15 |
| [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer |  | [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer |
| Security (TLS) Protocol Version 1.2", RFC 5246, |  | Security (TLS) Protocol Version 1.2", RFC 5246, |
| August 2008. |  | August 2008. |
| [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, |  | [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, |
| October 2008. |  | October 2008. |
| [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, |  | [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, |
| April 2011. |  | April 2011. |
|  |  | [RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status |
|  |  | Codes", RFC 6585, April 2012. |
| Appendix A. HTTP Version History |  | Appendix A. HTTP Version History |
| HTTP has been in use by the World-Wide Web global information |  | HTTP has been in use by the World-Wide Web global information |
| initiative since 1990. The first version of HTTP, later referred to |  | initiative since 1990. The first version of HTTP, later referred to |
| as HTTP/0.9, was a simple protocol for hypertext data transfer across |  | as HTTP/0.9, was a simple protocol for hypertext data transfer across |
| the Internet with only a single request method (GET) and no metadata. |  | the Internet with only a single request method (GET) and no metadata. |
| HTTP/1.0, as defined by [RFC1945], added a range of request methods |  | HTTP/1.0, as defined by [RFC1945], added a range of request methods |
| and MIME-like messaging that could include metadata about the data |  | and MIME-like messaging that could include metadata about the data |
| transferred and modifiers on the request/response semantics. |  | transferred and modifiers on the request/response semantics. |
| However, HTTP/1.0 did not sufficiently take into consideration the |  | However, HTTP/1.0 did not sufficiently take into consideration the |
| skipping to change at page 70, line 7 |  | skipping to change at page 71, line 12 |
| One attempted solution was the introduction of a Proxy-Connection |  | One attempted solution was the introduction of a Proxy-Connection |
| header field, targeted specifically at proxies. In practice, this |  | header field, targeted specifically at proxies. In practice, this |
| was also unworkable, because proxies are often deployed in multiple |  | was also unworkable, because proxies are often deployed in multiple |
| layers, bringing about the same problem discussed above. |  | layers, bringing about the same problem discussed above. |
| As a result, clients are encouraged not to send the Proxy-Connection |  | As a result, clients are encouraged not to send the Proxy-Connection |
| header field in any requests. |  | header field in any requests. |
| Clients are also encouraged to consider the use of Connection: keep- |  | Clients are also encouraged to consider the use of Connection: keep- |
| alive in requests carefully; while they can enable persistent |  | alive in requests carefully; while they can enable persistent |
| connections with HTTP/1.0 servers, clients using them need will need |  | connections with HTTP/1.0 servers, clients using them will need to |
| to monitor the connection for "hung" requests (which indicate that |  | monitor the connection for "hung" requests (which indicate that the |
| the client ought stop sending the header field), and this mechanism |  | client ought stop sending the header field), and this mechanism ought |
| ought not be used by clients at all when a proxy is being used. |  | not be used by clients at all when a proxy is being used. |
| A.1.3. Introduction of Transfer-Encoding |  | A.1.3. Introduction of Transfer-Encoding |
| HTTP/1.1 introduces the Transfer-Encoding header field |  | HTTP/1.1 introduces the Transfer-Encoding header field |
| (Section 3.3.1). Transfer codings need to be decoded prior to |  | (Section 3.3.1). Transfer codings need to be decoded prior to |
| forwarding an HTTP message over a MIME-compliant protocol. |  | forwarding an HTTP message over a MIME-compliant protocol. |
| A.2. Changes from RFC 2616 |  | A.2. Changes from RFC 2616 |
| HTTP's approach to error handling has been explained. (Section 2.5) |  | HTTP's approach to error handling has been explained. (Section 2.5) |
| skipping to change at page 72, line 33 |  | skipping to change at page 73, line 40 |
| The semantics of the Upgrade header field is now defined in responses |  | The semantics of the Upgrade header field is now defined in responses |
| other than 101 (this was incorporated from [RFC2817]). (Section 6.7) |  | other than 101 (this was incorporated from [RFC2817]). (Section 6.7) |
| Registration of Transfer Codings now requires IETF Review |  | Registration of Transfer Codings now requires IETF Review |
| (Section 7.4) |  | (Section 7.4) |
| The meaning of the "deflate" content coding has been clarified. |  | The meaning of the "deflate" content coding has been clarified. |
| (Section 4.2.2) |  | (Section 4.2.2) |
| This specification now defines the Upgrade Token Registry, previously |  | This specification now defines the Upgrade Token Registry, previously |
| defined in Section 7.2 of [RFC2817]. (Section 7.6) |  | defined in Section 7.2 of [RFC2817]. (Section 7.5) |
| Empty list elements in list productions (e.g., a list header |  | Issues with the Keep-Alive and Proxy-Connection header fields in |
| containing ", ,") have been deprecated. (Appendix B) |  | requests are pointed out, with use of the latter being discouraged |
|  |  | altogether. (Appendix A.1.2) |
| Issues with the Keep-Alive and Proxy-Connection headers in requests |  | Empty list elements in list productions (e.g., a list header field |
| are pointed out, with use of the latter being discouraged altogether. |  | containing ", ,") have been deprecated. (Appendix B) |
| (Appendix A.1.2) |  |  |
| Appendix B. ABNF list extension: #rule |  | Appendix B. ABNF list extension: #rule |
| A #rule extension to the ABNF rules of [RFC5234] is used to improve |  | A #rule extension to the ABNF rules of [RFC5234] is used to improve |
| readability in the definitions of some header field values. |  | readability in the definitions of some header field values. |
| A construct "#" is defined, similar to "*", for defining comma- |  | A construct "#" is defined, similar to "*", for defining comma- |
| delimited lists of elements. The full form is "<n>#<m>element" |  | delimited lists of elements. The full form is "<n>#<m>element" |
| indicating at least <n> and at most <m> elements, each separated by a |  | indicating at least <n> and at most <m> elements, each separated by a |
| single comma (",") and optional whitespace (OWS). |  | single comma (",") and optional whitespace (OWS). |
| skipping to change at page 75, line 8 |  | skipping to change at page 76, line 18 |
| comment = "(" *( ctext / quoted-cpair / comment ) ")" |  | comment = "(" *( ctext / quoted-cpair / comment ) ")" |
| connection-option = token |  | connection-option = token |
| ctext = HTAB / SP / %x21-27 ; '!'-''' |  | ctext = HTAB / SP / %x21-27 ; '!'-''' |
| / %x2A-5B ; '*'-'[' |  | / %x2A-5B ; '*'-'[' |
| / %x5D-7E ; ']'-'~' |  | / %x5D-7E ; ']'-'~' |
| / obs-text |  | / obs-text |
| field-content = *( HTAB / SP / VCHAR / obs-text ) |  | field-content = *( HTAB / SP / VCHAR / obs-text ) |
| field-name = token |  | field-name = token |
| field-value = *( field-content / obs-fold ) |  | field-value = *( field-content / obs-fold ) |
|  |  | fragment = <fragment, defined in [RFC3986], Section 3.5> |
| header-field = field-name ":" OWS field-value BWS |  | header-field = field-name ":" OWS field-value OWS |
| http-URI = "http://" authority path-abempty [ "?" query ] |  | http-URI = "http://" authority path-abempty [ "?" query ] [ "#" |
| https-URI = "https://" authority path-abempty [ "?" query ] |  | fragment ] |
|  |  | https-URI = "https://" authority path-abempty [ "?" query ] [ "#" |
|  |  | fragment ] |
| last-chunk = 1*"0" [ chunk-ext ] CRLF |  | last-chunk = 1*"0" [ chunk-ext ] CRLF |
| message-body = *OCTET |  | message-body = *OCTET |
| method = token |  | method = token |
| obs-fold = CRLF ( SP / HTAB ) |  | obs-fold = CRLF ( SP / HTAB ) |
| obs-text = %x80-FF |  | obs-text = %x80-FF |
| origin-form = absolute-path [ "?" query ] |  | origin-form = absolute-path [ "?" query ] |
| skipping to change at page 76, line 49 |  | skipping to change at page 78, line 15 |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/128>: "Cite HTTPS |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/128>: "Cite HTTPS |
| URI scheme definition" (the spec now includes the HTTPs scheme |  | URI scheme definition" (the spec now includes the HTTPs scheme |
| definition and thus updates RFC 2818) |  | definition and thus updates RFC 2818) |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/389>: "mention of |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/389>: "mention of |
| 'proxies' in section about caches" |  | 'proxies' in section about caches" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/390>: "use of ABNF |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/390>: "use of ABNF |
| terms from RFC 3986" |  | terms from RFC 3986" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/391>: "transferring |
|  |  | URIs with userinfo in payload" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/392>: "editorial |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/392>: "editorial |
| improvements to message length definition" |  | improvements to message length definition" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/395>: "Connection |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/395>: "Connection |
| header field MUST vs SHOULD" |  | header field MUST vs SHOULD" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/396>: "editorial |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/396>: "editorial |
| improvements to persistent connections section" |  | improvements to persistent connections section" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/397>: "URI |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/397>: "URI |
| skipping to change at page 77, line 47 |  | skipping to change at page 79, line 14 |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/420>: "Content- |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/420>: "Content- |
| Length SHOULD be sent" |  | Length SHOULD be sent" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/431>: "origin-form |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/431>: "origin-form |
| does not allow path starting with "//"" |  | does not allow path starting with "//"" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/433>: "ambiguity in |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/433>: "ambiguity in |
| part 1 example" |  | part 1 example" |
|  |  | D.3. Since draft-ietf-httpbis-p1-messaging-22 |
|  |  | Closed issues: |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/435>: "Part1 should |
|  |  | have a reference to TCP (RFC 793)" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/438>: "media type |
|  |  | registration template issues" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/442>: "BWS" (vs |
|  |  | conformance) |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/444>: "obs-fold |
|  |  | language" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/445>: "Ordering in |
|  |  | Upgrade" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/446>: "p1 editorial |
|  |  | feedback" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/447>: "HTTP and TCP |
|  |  | name delegation" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/449>: "Receiving a |
|  |  | higher minor HTTP version number" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/451>: "HTTP(S) URIs |
|  |  | and fragids" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/457>: "Registering |
|  |  | x-gzip and x-deflate" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/460>: "Via and |
|  |  | gateways" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/465>: "Mention 203 |
|  |  | Non-Authoritative Information in p1" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/476>: "SHOULD and |
|  |  | conformance" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/477>: "Pipelining |
|  |  | language" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/482>: "proxy |
|  |  | handling of a really bad Content-Length" |
| Index |  | Index |
| A |  | A |
| absolute-form (of request-target) 40 |  | absolute-form (of request-target) 40 |
| accelerator 10 |  | accelerator 10 |
| application/http Media Type 58 |  | application/http Media Type 58 |
| asterisk-form (of request-target) 41 |  | asterisk-form (of request-target) 41 |
| authority-form (of request-target) 41 |  | authority-form (of request-target) 41 |
| B |  | B |
| skipping to change at page 78, line 20 |  | skipping to change at page 80, line 36 |
| C |  | C |
| cache 11 |  | cache 11 |
| cacheable 12 |  | cacheable 12 |
| captive portal 11 |  | captive portal 11 |
| chunked (Coding Format) 27, 30, 34 |  | chunked (Coding Format) 27, 30, 34 |
| client 7 |  | client 7 |
| close 48, 53 |  | close 48, 53 |
| compress (Coding Format) 37 |  | compress (Coding Format) 37 |
| connection 7 |  | connection 7 |
| Connection header field 48, 53 |  | Connection header field 48, 53 |
| Content-Length header field 28 |  | Content-Length header field 29 |
| D |  | D |
| deflate (Coding Format) 37 |  | deflate (Coding Format) 37 |
| downstream 9 |  | downstream 9 |
| E |  | E |
| effective request URI 43 |  | effective request URI 43 |
| G |  | G |
| gateway 10 |  | gateway 10 |
| skipping to change at page 79, line 15 |  | skipping to change at page 81, line 30 |
| CRLF 6 |  | CRLF 6 |
| ctext 26 |  | ctext 26 |
| CTL 6 |  | CTL 6 |
| date2 34 |  | date2 34 |
| date3 34 |  | date3 34 |
| DIGIT 6 |  | DIGIT 6 |
| DQUOTE 6 |  | DQUOTE 6 |
| field-content 22 |  | field-content 22 |
| field-name 22 |  | field-name 22 |
| field-value 22 |  | field-value 22 |
|  |  | fragment 16 |
| header-field 22 |  | header-field 22 |
| HEXDIG 6 |  | HEXDIG 6 |
| Host 42 |  | Host 42 |
| HTAB 6 |  | HTAB 6 |
| HTTP-message 19 |  | HTTP-message 19 |
| HTTP-name 13 |  | HTTP-name 13 |
| http-URI 16 |  | http-URI 16 |
| HTTP-version 13 |  | HTTP-version 13 |
| https-URI 18 |  | https-URI 18 |
| last-chunk 35 |  | last-chunk 35 |
| LF 6 |  | LF 6 |
| message-body 26 |  | message-body 27 |
| method 20 |  | method 20 |
| obs-fold 22 |  | obs-fold 22 |
| obs-text 26 |  | obs-text 26 |
| OCTET 6 |  | OCTET 6 |
| origin-form 40 |  | origin-form 40 |
| OWS 24 |  | OWS 24 |
| partial-URI 16 |  | partial-URI 16 |
| port 16 |  | port 16 |
| protocol-name 45 |  | protocol-name 45 |
| protocol-version 45 |  | protocol-version 45 |
| skipping to change at page 80, line 6 |  | skipping to change at page 82, line 22 |
| quoted-string 26 |  | quoted-string 26 |
| rank 37 |  | rank 37 |
| reason-phrase 21 |  | reason-phrase 21 |
| received-by 45 |  | received-by 45 |
| received-protocol 45 |  | received-protocol 45 |
| request-line 20 |  | request-line 20 |
| request-target 40 |  | request-target 40 |
| RWS 24 |  | RWS 24 |
| segment 16 |  | segment 16 |
| SP 6 |  | SP 6 |
| special 25 |  | special 26 |
| start-line 20 |  | start-line 20 |
| status-code 21 |  | status-code 21 |
| status-line 21 |  | status-line 21 |
| t-codings 37 |  | t-codings 37 |
| t-ranking 37 |  | t-ranking 37 |
| tchar 25 |  | tchar 26 |
| TE 37 |  | TE 37 |
| token 25 |  | token 26 |
| Trailer 35 |  | Trailer 35 |
| trailer-part 35 |  | trailer-part 35 |
| transfer-coding 34 |  | transfer-coding 34 |
| Transfer-Encoding 27 |  | Transfer-Encoding 27 |
| transfer-extension 34 |  | transfer-extension 34 |
| transfer-parameter 34 |  | transfer-parameter 34 |
| Upgrade 54 |  | Upgrade 54 |
| uri-host 16 |  | uri-host 16 |
| URI-reference 16 |  | URI-reference 16 |
| value 34 |  | value 34 |
| VCHAR 6 |  | VCHAR 6 |
| Via 45 |  | Via 45 |
| word 25 |  | word 26 |
| gzip (Coding Format) 37 |  | gzip (Coding Format) 37 |
| H |  | H |
| header field 19 |  | header field 19 |
| header section 19 |  | header section 19 |
| headers 19 |  | headers 19 |
| Host header field 41 |  | Host header field 41 |
| http URI scheme 16 |  | http URI scheme 16 |
| https URI scheme 17 |  | https URI scheme 17 |
End of changes. 128 change blocks.
| 415 lines changed or deleted |  | 543 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/