| p1-messaging.unpg.txt |  | rfc7230.txt |
--- | --- | --- | --- | ---
| HTTPbis Working Group R. Fielding, Ed. |  | Internet Engineering Task Force (IETF) R. Fielding, Ed. |
| Internet-Draft Adobe |  | Request for Comments: 7230 Adobe |
| Obsoletes: 2145, 2616 J. Reschke, Ed. |  | Obsoletes: 2145, 2616 J. Reschke, Ed. |
| (if approved) greenbytes |  | Updates: 2817, 2818 greenbytes |
| Updates: 2817, 2818 (if approved) June 6, 2014 |  | Category: Standards Track June 2014 |
| Intended status: Standards Track |  | ISSN: 2070-1721 |
| Expires: December 8, 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-latest |  |  |
| Abstract |  | Abstract |
| The Hypertext Transfer Protocol (HTTP) is a stateless application- |  | The Hypertext Transfer Protocol (HTTP) is a stateless application- |
| level protocol for distributed, collaborative, hypertext information |  | level protocol for distributed, collaborative, hypertext information |
| systems. This document provides an overview of HTTP architecture and |  | systems. This document provides an overview of HTTP architecture and |
| its associated terminology, defines the "http" and "https" Uniform |  | its associated terminology, defines the "http" and "https" Uniform |
| Resource Identifier (URI) schemes, defines the HTTP/1.1 message |  | Resource Identifier (URI) schemes, defines the HTTP/1.1 message |
| syntax and parsing requirements, and describes related security |  | syntax and parsing requirements, and describes related security |
| concerns for implementations. |  | concerns for implementations. |
| Editorial Note (To be removed by RFC Editor) |  |  |
| Discussion of this draft takes place on the HTTPBIS working group |  |  |
| mailing list (ietf-http-wg@w3.org), which is archived at |  |  |
| <http://lists.w3.org/Archives/Public/ietf-http-wg/>. |  |  |
| The current issues list is at |  |  |
| <http://tools.ietf.org/wg/httpbis/trac/report/3> and related |  |  |
| documents (including fancy diffs) can be found at |  |  |
| <http://tools.ietf.org/wg/httpbis/>. |  |  |
| _This is a temporary document for the purpose of tracking the |  |  |
| editorial changes made during the AUTH48 (RFC publication) phase._ |  |  |
| Status of This Memo |  | Status of This Memo |
| This Internet-Draft is submitted in full conformance with the |  | This is an Internet Standards Track document. |
| provisions of BCP 78 and BCP 79. |  |  |
| Internet-Drafts are working documents of the Internet Engineering |  |  |
| Task Force (IETF). Note that other groups may also distribute |  |  |
| working documents as Internet-Drafts. The list of current Internet- |  |  |
| Drafts is at http://datatracker.ietf.org/drafts/current/. |  |  |
| Internet-Drafts are draft documents valid for a maximum of six months |  | This document is a product of the Internet Engineering Task Force |
| and may be updated, replaced, or obsoleted by other documents at any |  | (IETF). It represents the consensus of the IETF community. It has |
| time. It is inappropriate to use Internet-Drafts as reference |  | received public review and has been approved for publication by the |
| material or to cite them other than as "work in progress." |  | Internet Engineering Steering Group (IESG). Further information on |
|  |  | Internet Standards is available in Section 2 of RFC 5741. |
| This Internet-Draft will expire on December 8, 2014. |  | Information about the current status of this document, any errata, |
|  |  | and how to provide feedback on it may be obtained at |
|  |  | http://www.rfc-editor.org/info/rfc7230. |
| Copyright Notice |  | Copyright Notice |
| Copyright (c) 2014 IETF Trust and the persons identified as the |  | Copyright (c) 2014 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 2, line 38 |  | skipping to change at page 2, line 34 |
| modifications of such material outside the IETF Standards Process. |  | modifications of such material outside the IETF Standards Process. |
| Without obtaining an adequate license from the person(s) controlling |  | Without obtaining an adequate license from the person(s) controlling |
| the copyright in such materials, this document may not be modified |  | the copyright in such materials, this document may not be modified |
| outside the IETF Standards Process, and derivative works of it may |  | outside the IETF Standards Process, and derivative works of it may |
| not be created outside the IETF Standards Process, except to format |  | not be created outside the IETF Standards Process, except to format |
| it for publication as an RFC or to translate it into languages other |  | it for publication as an RFC or to translate it into languages other |
| than English. |  | than English. |
| Table of Contents |  | Table of Contents |
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 |  | 1. Introduction ....................................................5 |
| 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 6 |  | 1.1. Requirements Notation ......................................6 |
| 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 |  | 1.2. Syntax Notation ............................................6 |
| 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 6 |  | 2. Architecture ....................................................6 |
| 2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 7 |  | 2.1. Client/Server Messaging ....................................7 |
| 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 . . . . . . . . . . . . . . . 16 |  | 2.7. Uniform Resource Identifiers ..............................16 |
| 2.7.1. http URI Scheme . . . . . . . . . . . . . . . . . . . 16 |  | 2.7.1. http URI Scheme ....................................17 |
| 2.7.2. https URI Scheme . . . . . . . . . . . . . . . . . . . 18 |  | 2.7.2. https URI Scheme ...................................18 |
| 2.7.3. http and https URI Normalization and Comparison . . . 19 |  | 2.7.3. http and https URI Normalization and Comparison ....19 |
|  |  | 3. Message Format .................................................19 |
| 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 19 |  | 3.1. Start Line ................................................20 |
| 3.1. Start Line . . . . . . . . . . . . . . . . . . . . . . . . 20 |  | 3.1.1. Request Line .......................................21 |
| 3.1.1. Request Line . . . . . . . . . . . . . . . . . . . . . 21 |  | 3.1.2. Status Line ........................................22 |
| 3.1.2. Status Line . . . . . . . . . . . . . . . . . . . . . 22 |  | 3.2. Header Fields .............................................22 |
| 3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 22 |  | 3.2.1. Field Extensibility ................................23 |
| 3.2.1. Field Extensibility . . . . . . . . . . . . . . . . . 23 |  | 3.2.2. Field Order ........................................23 |
| 3.2.2. Field Order . . . . . . . . . . . . . . . . . . . . . 23 |  | 3.2.3. Whitespace .........................................24 |
| 3.2.3. Whitespace . . . . . . . . . . . . . . . . . . . . . . 24 |  | 3.2.4. Field Parsing ......................................25 |
| 3.2.4. Field Parsing . . . . . . . . . . . . . . . . . . . . 24 |  | 3.2.5. Field Limits .......................................26 |
| 3.2.5. Field Limits . . . . . . . . . . . . . . . . . . . . . 26 |  | 3.2.6. Field Value Components .............................27 |
| 3.2.6. Field Value Components . . . . . . . . . . . . . . . . 26 |  | 3.3. Message Body ..............................................28 |
| 3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 27 |  | 3.3.1. Transfer-Encoding ..................................28 |
| 3.3.1. Transfer-Encoding . . . . . . . . . . . . . . . . . . 28 |  | 3.3.2. Content-Length .....................................30 |
| 3.3.2. Content-Length . . . . . . . . . . . . . . . . . . . . 29 |  | 3.3.3. Message Body Length ................................32 |
| 3.3.3. Message Body Length . . . . . . . . . . . . . . . . . 31 |  | 3.4. Handling Incomplete Messages ..............................34 |
| 3.4. Handling Incomplete Messages . . . . . . . . . . . . . . . 33 |  | 3.5. Message Parsing Robustness ................................34 |
| 3.5. Message Parsing Robustness . . . . . . . . . . . . . . . . 34 |  | 4. Transfer Codings ...............................................35 |
| 4. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . . 34 |  | 4.1. Chunked Transfer Coding ...................................36 |
| 4.1. Chunked Transfer Coding . . . . . . . . . . . . . . . . . 35 |  | 4.1.1. Chunk Extensions ...................................36 |
| 4.1.1. Chunk Extensions . . . . . . . . . . . . . . . . . . . 36 |  | 4.1.2. Chunked Trailer Part ...............................37 |
| 4.1.2. Chunked Trailer Part . . . . . . . . . . . . . . . . . 36 |  | 4.1.3. Decoding Chunked ...................................38 |
| 4.1.3. Decoding Chunked . . . . . . . . . . . . . . . . . . . 37 |  | 4.2. Compression Codings .......................................38 |
| 4.2. Compression Codings . . . . . . . . . . . . . . . . . . . 37 |  | 4.2.1. Compress Coding ....................................38 |
| 4.2.1. Compress Coding . . . . . . . . . . . . . . . . . . . 38 |  | 4.2.2. Deflate Coding .....................................38 |
| 4.2.2. Deflate Coding . . . . . . . . . . . . . . . . . . . . 38 |  | 4.2.3. Gzip Coding ........................................39 |
| 4.2.3. Gzip Coding . . . . . . . . . . . . . . . . . . . . . 38 |  | 4.3. TE ........................................................39 |
| 4.3. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 |  | 4.4. Trailer ...................................................40 |
| 4.4. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 39 |  | 5. Message Routing ................................................40 |
| 5. Message Routing . . . . . . . . . . . . . . . . . . . . . . . 39 |  | 5.1. Identifying a Target Resource .............................40 |
| 5.1. Identifying a Target Resource . . . . . . . . . . . . . . 40 |  | 5.2. Connecting Inbound ........................................41 |
| 5.2. Connecting Inbound . . . . . . . . . . . . . . . . . . . . 40 |  | 5.3. Request Target ............................................41 |
| 5.3. Request Target . . . . . . . . . . . . . . . . . . . . . . 41 |  | 5.3.1. origin-form ........................................42 |
| 5.3.1. origin-form . . . . . . . . . . . . . . . . . . . . . 41 |  | 5.3.2. absolute-form ......................................42 |
| 5.3.2. absolute-form . . . . . . . . . . . . . . . . . . . . 41 |  | 5.3.3. authority-form .....................................43 |
| 5.3.3. authority-form . . . . . . . . . . . . . . . . . . . . 42 |  | 5.3.4. asterisk-form ......................................43 |
| 5.3.4. asterisk-form . . . . . . . . . . . . . . . . . . . . 42 |  | 5.4. Host ......................................................44 |
| 5.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 |  | 5.5. Effective Request URI .....................................45 |
| 5.5. Effective Request URI . . . . . . . . . . . . . . . . . . 44 |  | 5.6. Associating a Response to a Request .......................46 |
| 5.6. Associating a Response to a Request . . . . . . . . . . . 46 |  | 5.7. Message Forwarding ........................................47 |
| 5.7. Message Forwarding . . . . . . . . . . . . . . . . . . . . 46 |  | 5.7.1. Via ................................................47 |
| 5.7.1. Via . . . . . . . . . . . . . . . . . . . . . . . . . 46 |  | 5.7.2. Transformations ....................................49 |
| 5.7.2. Transformations . . . . . . . . . . . . . . . . . . . 48 |  | 6. Connection Management ..........................................50 |
| 6. Connection Management . . . . . . . . . . . . . . . . . . . . 49 |  | 6.1. Connection ................................................51 |
| 6.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 50 |  | 6.2. Establishment .............................................52 |
| 6.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 51 |  | 6.3. Persistence ...............................................52 |
| 6.3. Persistence . . . . . . . . . . . . . . . . . . . . . . . 51 |  | 6.3.1. Retrying Requests ..................................53 |
| 6.3.1. Retrying Requests . . . . . . . . . . . . . . . . . . 52 |  | 6.3.2. Pipelining .........................................54 |
| 6.3.2. Pipelining . . . . . . . . . . . . . . . . . . . . . . 53 |  | 6.4. Concurrency ...............................................55 |
|  |  | 6.5. Failures and Timeouts .....................................55 |
| 6.4. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 54 |  | 6.6. Tear-down .................................................56 |
| 6.5. Failures and Timeouts . . . . . . . . . . . . . . . . . . 54 |  | 6.7. Upgrade ...................................................57 |
| 6.6. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 55 |  | 7. ABNF List Extension: #rule .....................................59 |
| 6.7. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 56 |  | 8. IANA Considerations ............................................61 |
| 7. ABNF List Extension: #rule . . . . . . . . . . . . . . . . . . 58 |  | 8.1. Header Field Registration .................................61 |
| 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59 |  | 8.2. URI Scheme Registration ...................................62 |
| 8.1. Header Field Registration . . . . . . . . . . . . . . . . 59 |  | 8.3. Internet Media Type Registration ..........................62 |
| 8.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 60 |  | 8.3.1. Internet Media Type message/http ...................62 |
| 8.3. Internet Media Type Registration . . . . . . . . . . . . . 60 |  | 8.3.2. Internet Media Type application/http ...............63 |
| 8.3.1. Internet Media Type message/http . . . . . . . . . . . 61 |  | 8.4. Transfer Coding Registry ..................................64 |
| 8.3.2. Internet Media Type application/http . . . . . . . . . 62 |  | 8.4.1. Procedure ..........................................65 |
| 8.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 63 |  | 8.4.2. Registration .......................................65 |
| 8.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 63 |  | 8.5. Content Coding Registration ...............................66 |
| 8.4.2. Registration . . . . . . . . . . . . . . . . . . . . . 64 |  | 8.6. Upgrade Token Registry ....................................66 |
| 8.5. Content Coding Registration . . . . . . . . . . . . . . . 64 |  | 8.6.1. Procedure ..........................................66 |
| 8.6. Upgrade Token Registry . . . . . . . . . . . . . . . . . . 64 |  | 8.6.2. Upgrade Token Registration .........................67 |
| 8.6.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 65 |  | 9. Security Considerations ........................................67 |
| 8.6.2. Upgrade Token Registration . . . . . . . . . . . . . . 65 |  | 9.1. Establishing Authority ....................................67 |
| 9. Security Considerations . . . . . . . . . . . . . . . . . . . 66 |  | 9.2. Risks of Intermediaries ...................................68 |
| 9.1. Establishing Authority . . . . . . . . . . . . . . . . . . 66 |  | 9.3. Attacks via Protocol Element Length .......................69 |
| 9.2. Risks of Intermediaries . . . . . . . . . . . . . . . . . 67 |  | 9.4. Response Splitting ........................................69 |
| 9.3. Attacks via Protocol Element Length . . . . . . . . . . . 67 |  | 9.5. Request Smuggling .........................................70 |
| 9.4. Response Splitting . . . . . . . . . . . . . . . . . . . . 68 |  | 9.6. Message Integrity .........................................70 |
| 9.5. Request Smuggling . . . . . . . . . . . . . . . . . . . . 69 |  | 9.7. Message Confidentiality ...................................71 |
| 9.6. Message Integrity . . . . . . . . . . . . . . . . . . . . 69 |  | 9.8. Privacy of Server Log Information .........................71 |
| 9.7. Message Confidentiality . . . . . . . . . . . . . . . . . 69 |  | 10. Acknowledgments ...............................................72 |
| 9.8. Privacy of Server Log Information . . . . . . . . . . . . 70 |  | 11. References ....................................................74 |
| 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 70 |  | 11.1. Normative References .....................................74 |
| 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 72 |  | 11.2. Informative References ...................................75 |
| 11.1. Normative References . . . . . . . . . . . . . . . . . . . 72 |  | Appendix A. HTTP Version History ..................................78 |
| 11.2. Informative References . . . . . . . . . . . . . . . . . . 73 |  | A.1. Changes from HTTP/1.0 ....................................78 |
| Appendix A. HTTP Version History . . . . . . . . . . . . . . . . 75 |  | A.1.1. Multihomed Web Servers ............................78 |
| A.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 76 |  | A.1.2. Keep-Alive Connections ............................79 |
| A.1.1. Multihomed Web Servers . . . . . . . . . . . . . . . . 76 |  | A.1.3. Introduction of Transfer-Encoding .................79 |
| A.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 77 |  | A.2. Changes from RFC 2616 ....................................80 |
| A.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 77 |  | Appendix B. Collected ABNF ........................................82 |
| A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 77 |  | Index .............................................................85 |
| Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 80 |  |  |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 |  |  |
| 1. Introduction |  | 1. Introduction |
| The Hypertext Transfer Protocol (HTTP) is a stateless application- |  | The Hypertext Transfer Protocol (HTTP) is a stateless application- |
| level request/response protocol that uses extensible semantics and |  | level request/response protocol that uses extensible semantics and |
| self-descriptive message payloads for flexible interaction with |  | self-descriptive message payloads for flexible interaction with |
| network-based hypertext information systems. This document is the |  | network-based hypertext information systems. This document is the |
| first in a series of documents that collectively form the HTTP/1.1 |  | first in a series of documents that collectively form the HTTP/1.1 |
| specification: |  | specification: |
| skipping to change at page 7, line 36 |  | skipping to change at page 7, line 36 |
| HTTP relies upon the Uniform Resource Identifier (URI) standard |  | HTTP relies upon the Uniform Resource Identifier (URI) standard |
| [RFC3986] to indicate the target resource (Section 5.1) and |  | [RFC3986] to indicate the target resource (Section 5.1) and |
| relationships between resources. Messages are passed in a format |  | relationships between resources. Messages are passed in a format |
| similar to that used by Internet mail [RFC5322] and the Multipurpose |  | similar to that used by Internet mail [RFC5322] and the Multipurpose |
| Internet Mail Extensions (MIME) [RFC2045] (see Appendix A of |  | Internet Mail Extensions (MIME) [RFC2045] (see Appendix A of |
| [RFC7231] for the differences between HTTP and MIME messages). |  | [RFC7231] for the differences between HTTP and MIME messages). |
| Most HTTP communication consists of a retrieval request (GET) for a |  | Most HTTP communication consists of a retrieval request (GET) for a |
| representation of some resource identified by a URI. In the simplest |  | representation of some resource identified by a URI. In the simplest |
| case, this might be accomplished via a single bidirectional |  | case, this might be accomplished via a single bidirectional |
| connection (===) between the user agent (UA) and the origin server |  | connection (===) between the user agent (UA) and the origin |
| (O). |  | server (O). |
| request > |  | request > |
| UA ======================================= O |  | UA ======================================= O |
| < response |  | < response |
| A client sends an HTTP request to a server in the form of a request |  | A client sends an HTTP request to a server in the form of a request |
| message, beginning with a request-line that includes a method, URI, |  | message, beginning with a request-line that includes a method, URI, |
| and protocol version (Section 3.1.1), followed by header fields |  | and protocol version (Section 3.1.1), followed by header fields |
| containing request modifiers, client information, and representation |  | containing request modifiers, client information, and representation |
| metadata (Section 3.2), an empty line to indicate the end of the |  | metadata (Section 3.2), an empty line to indicate the end of the |
| skipping to change at page 12, line 47 |  | skipping to change at page 13, line 4 |
| the corresponding ABNF rules. Within a given message, a sender MUST |  | the corresponding ABNF rules. Within a given message, a sender MUST |
| NOT generate protocol elements or syntax alternatives that are only |  | NOT generate protocol elements or syntax alternatives that are only |
| allowed to be generated by participants in other roles (i.e., a role |  | allowed to be generated by participants in other roles (i.e., a role |
| that the sender does not have for that message). |  | that the sender does not have for that message). |
| When a received protocol element is parsed, the recipient MUST be |  | When a received protocol element is parsed, the recipient MUST be |
| able to parse any value of reasonable length that is applicable to |  | able to parse any value of reasonable length that is applicable to |
| the recipient's role and that matches the grammar defined by the |  | the recipient's role and that matches the grammar defined by the |
| corresponding ABNF rules. Note, however, that some received protocol |  | corresponding ABNF rules. Note, however, that some received protocol |
| elements might not be parsed. For example, an intermediary |  | elements might not be parsed. For example, an intermediary |
| forwarding a message might parse a header-field into generic field- |  | forwarding a message might parse a header-field into generic |
| name and field-value components, but then forward the header field |  | field-name and field-value components, but then forward the header |
| without further parsing inside the field-value. |  | field without further parsing inside the field-value. |
| HTTP does not have specific length limitations for many of its |  | HTTP does not have specific length limitations for many of its |
| protocol elements because the lengths that might be appropriate will |  | protocol elements because the lengths that might be appropriate will |
| vary widely, depending on the deployment context and purpose of the |  | vary widely, depending on the deployment context and purpose of the |
| implementation. Hence, interoperability between senders and |  | implementation. Hence, interoperability between senders and |
| recipients depends on shared expectations regarding what is a |  | recipients depends on shared expectations regarding what is a |
| reasonable length for each protocol element. Furthermore, what is |  | reasonable length for each protocol element. Furthermore, what is |
| commonly understood to be a reasonable length for some protocol |  | commonly understood to be a reasonable length for some protocol |
| elements has changed over the course of the past two decades of HTTP |  | elements has changed over the course of the past two decades of HTTP |
| use and is expected to continue changing in the future. |  | use and is expected to continue changing in the future. |
| skipping to change at page 13, line 25 |  | skipping to change at page 13, line 30 |
| generates for those same protocol elements in other messages. For |  | generates for those same protocol elements in other messages. For |
| example, an origin server that publishes very long URI references to |  | example, an origin server that publishes very long URI references to |
| its own resources needs to be able to parse and process those same |  | its own resources needs to be able to parse and process those same |
| references when received as a request target. |  | references when received as a request target. |
| A recipient MUST interpret a received protocol element according to |  | A recipient MUST interpret a received protocol element according to |
| the semantics defined for it by this specification, including |  | the semantics defined for it by this specification, including |
| extensions to this specification, unless the recipient has determined |  | extensions to this specification, unless the recipient has determined |
| (through experience or configuration) that the sender incorrectly |  | (through experience or configuration) that the sender incorrectly |
| implements what is implied by those semantics. For example, an |  | implements what is implied by those semantics. For example, an |
| origin server might disregard the contents of a received Accept- |  | origin server might disregard the contents of a received |
| Encoding header field if inspection of the User-Agent header field |  | Accept-Encoding header field if inspection of the User-Agent header |
| indicates a specific implementation version that is known to fail on |  | field indicates a specific implementation version that is known to |
| receipt of certain content codings. |  | fail on receipt of certain content codings. |
| Unless noted otherwise, a recipient MAY attempt to recover a usable |  | Unless noted otherwise, a recipient MAY attempt to recover a usable |
| protocol element from an invalid construct. HTTP does not define |  | protocol element from an invalid construct. HTTP does not define |
| specific error handling mechanisms except when they have a direct |  | specific error handling mechanisms except when they have a direct |
| impact on security, since different applications of the protocol |  | impact on security, since different applications of the protocol |
| require different error handling strategies. For example, a Web |  | require different error handling strategies. For example, a Web |
| browser might wish to transparently recover from a response where the |  | browser might wish to transparently recover from a response where the |
| Location header field doesn't parse according to the ABNF, whereas a |  | Location header field doesn't parse according to the ABNF, whereas a |
| systems control client might consider any form of error recovery to |  | systems control client might consider any form of error recovery to |
| be dangerous. |  | be dangerous. |
| skipping to change at page 14, line 45 |  | skipping to change at page 14, line 50 |
| version if their defined semantics allow them to be safely ignored by |  | version if their defined semantics allow them to be safely ignored by |
| recipients that do not recognize them. Header field extensibility is |  | recipients that do not recognize them. Header field extensibility is |
| discussed in Section 3.2.1. |  | discussed in Section 3.2.1. |
| Intermediaries that process HTTP messages (i.e., all intermediaries |  | Intermediaries that process HTTP messages (i.e., all intermediaries |
| 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 are not allowed to |  | in forwarded messages. In other words, they are not allowed to |
| blindly forward the first line of an HTTP message without ensuring |  | blindly forward the first line of an HTTP message without ensuring |
| that the protocol version in that message matches a version to which |  | that the protocol version in that message matches a version to which |
| that intermediary is conformant for both the receiving and sending of |  | that intermediary is conformant for both the receiving and sending of |
| messages. Forwarding an HTTP message without rewriting the HTTP- |  | messages. Forwarding an HTTP message without rewriting the |
| version might result in communication errors when downstream |  | HTTP-version might result in communication errors when downstream |
| recipients use the message sender's version to determine what |  | recipients use the message sender's version to determine what |
| features are safe to use for later communication with that sender. |  | features are safe to use for later communication with that sender. |
| A client SHOULD send a request version equal to the highest version |  | A client SHOULD send a request version equal to the highest version |
| to which the client is conformant and whose major version is no |  | to which the client is conformant and whose major version is no |
| higher than the highest version supported by the server, if this is |  | higher than the highest version supported by the server, if this is |
| known. A 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. |
| A client MAY send a lower request version if it is known that the |  | A client MAY send a lower request version if it is known that the |
| skipping to change at page 16, line 40 |  | skipping to change at page 16, line 44 |
| path-abempty = <path-abempty, see [RFC3986], Section 3.3> |  | path-abempty = <path-abempty, see [RFC3986], Section 3.3> |
| segment = <segment, see [RFC3986], Section 3.3> |  | segment = <segment, see [RFC3986], Section 3.3> |
| query = <query, see [RFC3986], Section 3.4> |  | query = <query, see [RFC3986], Section 3.4> |
| fragment = <fragment, see [RFC3986], Section 3.5> |  | fragment = <fragment, see [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 |
| URI), only the path and optional query components, or some |  | (absolute-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 ([RFC0793]) connections on a given port. |  | TCP ([RFC0793]) connections on a given port. |
| skipping to change at page 19, line 20 |  | skipping to change at page 19, line 29 |
| algorithm defined in Section 6 of [RFC3986], using the defaults |  | algorithm defined in Section 6 of [RFC3986], 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 omit 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 |
| encoded octets: the normal form is to not encode them (see Sections |  | percent-encoded octets: the normal form is to not encode them (see |
| 2.1 and 2.2 of [RFC3986]). |  | Sections 2.1 and 2.2 of [RFC3986]). |
| For example, the following three URIs are equivalent: |  | For example, the following three URIs are equivalent: |
| http://example.com:80/~smith/home.html |  | http://example.com:80/~smith/home.html |
| http://EXAMPLE.com/%7Esmith/home.html |  | http://EXAMPLE.com/%7Esmith/home.html |
| http://EXAMPLE.com:/%7esmith/home.html |  | http://EXAMPLE.com:/%7esmith/home.html |
| 3. Message Format |  | 3. Message Format |
| All HTTP/1.1 messages consist of a start-line followed by a sequence |  | All HTTP/1.1 messages consist of a start-line followed by a sequence |
| skipping to change at page 21, line 39 |  | skipping to change at page 21, line 47 |
| references, resulting in those disallowed characters being sent in a |  | references, resulting in those disallowed characters being sent in a |
| request-target. |  | request-target. |
| Recipients of an invalid request-line SHOULD respond with either a |  | Recipients of an invalid request-line SHOULD respond with either a |
| 400 (Bad Request) error or a 301 (Moved Permanently) redirect with |  | 400 (Bad Request) error or a 301 (Moved Permanently) redirect with |
| the request-target properly encoded. A recipient SHOULD NOT attempt |  | the request-target properly encoded. A recipient SHOULD NOT attempt |
| to autocorrect and then process the request without a redirect, since |  | to autocorrect and then process the request without a redirect, since |
| the invalid request-line might be deliberately crafted to bypass |  | the invalid request-line might be deliberately crafted to bypass |
| security filters along the request chain. |  | security filters along the request chain. |
| HTTP does not place a predefined limit on the length of a request- |  | HTTP does not place a predefined limit on the length of a |
| line, as described in Section 2.5. A server that receives a method |  | request-line, as described in Section 2.5. A server that receives a |
| longer than any that it implements SHOULD respond with a 501 (Not |  | method longer than any that it implements SHOULD respond with a 501 |
| Implemented) status code. A server that receives a request-target |  | (Not Implemented) status code. A server that receives a |
| longer than any URI it wishes to parse MUST respond with a 414 (URI |  | request-target longer than any URI it wishes to parse MUST respond |
| Too Long) status code (see Section 6.5.12 of [RFC7231]). |  | with a 414 (URI Too Long) status code (see Section 6.5.12 of |
|  |  | [RFC7231]). |
| Various ad hoc limitations on request-line length are found in |  | Various ad hoc limitations on request-line length are found in |
| practice. It is RECOMMENDED that all HTTP senders and recipients |  | practice. It is RECOMMENDED that all HTTP senders and recipients |
| support, at a minimum, request-line lengths of 8000 octets. |  | support, at a minimum, request-line lengths of 8000 octets. |
| 3.1.2. Status Line |  | 3.1.2. Status Line |
| The first line of a response message is the status-line, consisting |  | The first line of a response message is the status-line, consisting |
| of the protocol version, a space (SP), the status code, another |  | of the protocol version, a space (SP), the status code, another |
| space, a possibly empty textual phrase describing the status code, |  | space, a possibly empty textual phrase describing the status code, |
| skipping to change at page 25, line 25 |  | skipping to change at page 25, line 38 |
| 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 might be preceded and/or followed by optional |  | A field value might be preceded and/or followed by optional |
| whitespace (OWS); a single SP preceding the field-value is preferred |  | whitespace (OWS); a single SP preceding the field-value is preferred |
| for consistent readability by humans. The field value does not |  | for consistent readability by humans. The field value does not |
| include any leading or trailing whitespace: OWS occurring before the |  | include any leading or trailing whitespace: OWS occurring before the |
| first non-whitespace octet of the field value or after the last non- |  | first non-whitespace octet of the field value or after the last |
| whitespace octet of the field value ought to be excluded by parsers |  | non-whitespace octet of the field value ought to be excluded by |
| when extracting the field value from a header field. |  | parsers when extracting the field value from a header field. |
| Historically, HTTP header field values could be extended over |  | Historically, HTTP header field values could be extended over |
| multiple lines by preceding each extra line with at least one space |  | multiple lines by preceding each extra line with at least one space |
| or horizontal tab (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 8.3.1). A sender MUST NOT generate a message that includes |  | (Section 8.3.1). A sender MUST NOT generate a message that includes |
| line folding (i.e., that has any field-value that contains a match to |  | line folding (i.e., that has any field-value that contains a match to |
| the obs-fold rule) unless the message is intended for packaging |  | the obs-fold rule) unless the message is intended for packaging |
| within the message/http media type. |  | within the message/http media type. |
| skipping to change at page 26, line 6 |  | skipping to change at page 26, line 21 |
| A proxy or gateway that receives an obs-fold in a response message |  | A proxy or gateway that receives an obs-fold in a response message |
| that is not within a message/http container MUST either discard the |  | that is not within a message/http container MUST either discard the |
| message and replace it with a 502 (Bad Gateway) response, preferably |  | message and replace it with a 502 (Bad Gateway) response, preferably |
| with a representation explaining that unacceptable line folding was |  | with a representation explaining that unacceptable line folding was |
| received, or replace each received obs-fold with one or more SP |  | received, or replace each received obs-fold with one or more SP |
| octets prior to interpreting the field value or forwarding the |  | octets prior to interpreting the field value or forwarding the |
| message downstream. |  | message downstream. |
| A user agent that receives an obs-fold in a response message that is |  | A user agent that receives an obs-fold in a response message that is |
| not within a message/http container MUST replace each received obs- |  | not within a message/http container MUST replace each received |
| fold with one or more SP octets prior to interpreting the field |  | obs-fold with one or more SP octets prior to interpreting the field |
| value. |  | value. |
| Historically, HTTP has allowed field content with text in the |  | Historically, HTTP has allowed field content with text in the |
| ISO-8859-1 charset [ISO-8859-1], supporting other charsets only |  | ISO-8859-1 charset [ISO-8859-1], supporting other charsets only |
| through use of [RFC2047] encoding. In practice, most HTTP header |  | through use of [RFC2047] encoding. In practice, most HTTP header |
| field values use only a subset of the US-ASCII charset [USASCII]. |  | field values use only a subset of the US-ASCII charset [USASCII]. |
| Newly defined header fields SHOULD limit their field values to |  | Newly defined header fields SHOULD limit their field values to |
| US-ASCII octets. A recipient SHOULD treat other octets in field |  | US-ASCII octets. A recipient SHOULD treat other octets in field |
| content (obs-text) as opaque data. |  | content (obs-text) as opaque data. |
| skipping to change at page 27, line 42 |  | skipping to change at page 28, line 17 |
| The message body (if any) of an HTTP message is used to carry the |  | The message body (if any) of an HTTP message is used to carry the |
| payload body of that request or response. The message body is |  | payload body of that request or response. The message body is |
| identical to the payload body unless a transfer coding has been |  | identical to the payload body unless a transfer coding has been |
| applied, as described in Section 3.3.1. |  | applied, as described in Section 3.3.1. |
| message-body = *OCTET |  | message-body = *OCTET |
| The rules for when a message body is allowed in a message differ for |  | The rules for when a message body is allowed in a message differ for |
| requests and responses. |  | requests and responses. |
| The presence of a message body in a request is signaled by a Content- |  | The presence of a message body in a request is signaled by a |
| Length or Transfer-Encoding header field. Request message framing is |  | Content-Length or Transfer-Encoding header field. Request message |
| independent of method semantics, even if the method does not define |  | framing is independent of method semantics, even if the method does |
| any use for a message body. |  | not define any use for a message body. |
| The presence of a message body in a response depends on both the |  | The presence of a message body in a response depends on both the |
| request method to which it is responding and the response status code |  | request method to which it is responding and the response status code |
| (Section 3.1.2). Responses to the HEAD request method (Section 4.3.2 |  | (Section 3.1.2). Responses to the HEAD request method (Section 4.3.2 |
| of [RFC7231]) never include a message body because the associated |  | of [RFC7231]) never include a message body because the associated |
| response header fields (e.g., Transfer-Encoding, Content-Length, |  | response header fields (e.g., Transfer-Encoding, Content-Length, |
| etc.), if present, indicate only what their values would have been if |  | etc.), if present, indicate only what their values would have been if |
| the request method had been GET (Section 4.3.1 of [RFC7231]). 2xx |  | the request method had been GET (Section 4.3.1 of [RFC7231]). 2xx |
| (Successful) responses to a CONNECT request method (Section 4.3.6 of |  | (Successful) responses to a CONNECT request method (Section 4.3.6 of |
| [RFC7231]) switch to tunnel mode instead of having a message body. |  | [RFC7231]) switch to tunnel mode instead of having a message body. |
| skipping to change at page 28, line 50 |  | skipping to change at page 29, line 25 |
| by closing the connection. |  | by closing the connection. |
| For example, |  | For example, |
| Transfer-Encoding: gzip, chunked |  | Transfer-Encoding: gzip, chunked |
| indicates that the payload body has been compressed using the gzip |  | indicates that the payload body has been compressed using the gzip |
| coding and then chunked using the chunked coding while forming the |  | coding and then chunked using the chunked coding while forming the |
| message body. |  | message body. |
| Unlike Content-Encoding (Section 3.1.2.1 of [RFC7231]), Transfer- |  | Unlike Content-Encoding (Section 3.1.2.1 of [RFC7231]), |
| Encoding is a property of the message, not of the representation, and |  | Transfer-Encoding is a property of the message, not of the |
| any recipient along the request/response chain MAY decode the |  | representation, and any recipient along the request/response chain |
| received transfer coding(s) or apply additional transfer coding(s) to |  | MAY decode the received transfer coding(s) or apply additional |
| the message body, assuming that corresponding changes are made to the |  | transfer coding(s) to the message body, assuming that corresponding |
| Transfer-Encoding field-value. Additional information about the |  | changes are made to the Transfer-Encoding field-value. Additional |
| encoding parameters can be provided by other header fields not |  | information about the encoding parameters can be provided by other |
| defined by this specification. |  | header fields not defined by this specification. |
| Transfer-Encoding MAY be sent in a response to a HEAD request or in a |  | Transfer-Encoding MAY be sent in a response to a HEAD request or in a |
| 304 (Not Modified) response (Section 4.1 of [RFC7232]) to a GET |  | 304 (Not Modified) response (Section 4.1 of [RFC7232]) to a GET |
| request, neither of which includes a message body, to indicate that |  | request, neither of which includes a message body, to indicate that |
| the origin server would have applied a transfer coding to the message |  | the origin server would have applied a transfer coding to the message |
| body if the request had been an unconditional GET. This indication |  | body if the request had been an unconditional GET. This indication |
| is not required, however, because any recipient on the response chain |  | is not required, however, because any recipient on the response chain |
| (including the origin server) can remove transfer codings when they |  | (including the origin server) can remove transfer codings when they |
| are not needed. |  | are not needed. |
| skipping to change at page 30, line 40 |  | skipping to change at page 31, line 14 |
| unless its field-value equals the decimal number of octets that would |  | unless its field-value equals the decimal number of octets that would |
| have been sent in the payload body of a 200 (OK) response to the same |  | have been sent in the payload body of a 200 (OK) response to the same |
| request. |  | request. |
| A server MUST NOT send a Content-Length header field in any response |  | A server MUST NOT send a Content-Length header field in any response |
| with a status code of 1xx (Informational) or 204 (No Content). A |  | with a status code of 1xx (Informational) or 204 (No Content). A |
| server MUST NOT send a Content-Length header field in any 2xx |  | server MUST NOT send a Content-Length header field in any 2xx |
| (Successful) response to a CONNECT request (Section 4.3.6 of |  | (Successful) response to a CONNECT request (Section 4.3.6 of |
| [RFC7231]). |  | [RFC7231]). |
| Aside from the cases defined above, in the absence of Transfer- |  | Aside from the cases defined above, in the absence of |
| Encoding, an origin server SHOULD send a Content-Length header field |  | Transfer-Encoding, an origin server SHOULD send a Content-Length |
| when the payload body size is known prior to sending the complete |  | header field when the payload body size is known prior to sending the |
| header section. This will allow downstream recipients to measure |  | complete header section. This will allow downstream recipients to |
| transfer progress, know when a received message is complete, and |  | measure transfer progress, know when a received message is complete, |
| potentially reuse the connection for additional requests. |  | and potentially reuse the connection for additional requests. |
| Any Content-Length field value greater than or equal to zero is |  | Any Content-Length field value greater than or equal to zero is |
| valid. Since there is no predefined limit to the length of a |  | valid. Since there is no predefined limit to the length of a |
| payload, a recipient MUST anticipate potentially large decimal |  | payload, a recipient MUST anticipate potentially large decimal |
| numerals and prevent parsing errors due to integer conversion |  | numerals and prevent parsing errors due to integer conversion |
| overflows (Section 9.3). |  | overflows (Section 9.3). |
| If a message is received that has multiple Content-Length header |  | If a message is received that has multiple Content-Length header |
| fields with field-values consisting of the same decimal value, or a |  | fields with field-values consisting of the same decimal value, or a |
| single Content-Length header field with a field value containing a |  | single Content-Length header field with a field value containing a |
| list of identical decimal values (e.g., "Content-Length: 42, 42"), |  | list of identical decimal values (e.g., "Content-Length: 42, 42"), |
| indicating that duplicate Content-Length header fields have been |  | indicating that duplicate Content-Length header fields have been |
| generated or combined by an upstream message processor, then the |  | generated or combined by an upstream message processor, then the |
| recipient MUST either reject the message as invalid or replace the |  | recipient MUST either reject the message as invalid or replace the |
| duplicated field-values with a single valid Content-Length field |  | duplicated field-values with a single valid Content-Length field |
| containing that decimal value prior to determining the message body |  | containing that decimal value prior to determining the message body |
| length or forwarding the message. |  | length or forwarding the message. |
| Note: HTTP's use of Content-Length for message framing differs |  | Note: HTTP's use of Content-Length for message framing differs |
| significantly from the same field's use in MIME, where it is an |  | significantly from the same field's use in MIME, where it is an |
| optional field used only within the "message/external-body" media- |  | optional field used only within the "message/external-body" |
| type. |  | media-type. |
| 3.3.3. Message Body Length |  | 3.3.3. Message Body Length |
| The length of a message body is determined by one of the following |  | The length of a message body is determined by one of the following |
| (in order of precedence): |  | (in order of precedence): |
| 1. Any response to a HEAD request and any response with a 1xx |  | 1. Any response to a HEAD request and any response with a 1xx |
| (Informational), 204 (No Content), or 304 (Not Modified) status |  | (Informational), 204 (No Content), or 304 (Not Modified) status |
| code is always terminated by the first empty line after the |  | code is always terminated by the first empty line after the |
| header fields, regardless of the header fields present in the |  | header fields, regardless of the header fields present in the |
| skipping to change at page 32, line 39 |  | skipping to change at page 33, line 23 |
| 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). |
| 7. Otherwise, this is a response message without a declared message |  | 7. Otherwise, this is a response message without a declared message |
| body length, so the message body length is determined by the |  | body length, so the message body length is determined by the |
| number of octets received prior to the server closing the |  | number of octets received prior to the server closing the |
| connection. |  | connection. |
| Since there is no way to distinguish a successfully completed, close- |  | Since there is no way to distinguish a successfully completed, |
| delimited message from a partially received message interrupted by |  | close-delimited message from a partially received message interrupted |
| network failure, a server SHOULD generate encoding or length- |  | by network failure, a server SHOULD generate encoding or |
| delimited messages whenever possible. The close-delimiting feature |  | length-delimited messages whenever possible. The close-delimiting |
| exists primarily for backwards compatibility with HTTP/1.0. |  | feature exists primarily for backwards compatibility with HTTP/1.0. |
| A server MAY reject a request that contains a message body but not a |  | A server MAY reject a request that contains a message body but not a |
| Content-Length by responding with 411 (Length Required). |  | Content-Length by responding with 411 (Length Required). |
| Unless a transfer coding other than chunked has been applied, a |  | Unless a transfer coding other than chunked has been applied, a |
| client that sends a request containing a message body SHOULD use a |  | client that sends a request containing a message body SHOULD use a |
| valid Content-Length header field if the message body length is known |  | valid Content-Length header field if the message body length is known |
| in advance, rather than the chunked transfer coding, since some |  | in advance, rather than the chunked transfer coding, since some |
| existing services respond to chunked with a 411 (Length Required) |  | existing services respond to chunked with a 411 (Length Required) |
| status code even though they understand the chunked transfer coding. |  | status code even though they understand the chunked transfer coding. |
| skipping to change at page 35, line 18 |  | skipping to change at page 35, line 48 |
| / "gzip" ; Section 4.2.3 |  | / "gzip" ; Section 4.2.3 |
| / transfer-extension |  | / transfer-extension |
| transfer-extension = token *( OWS ";" OWS transfer-parameter ) |  | transfer-extension = token *( OWS ";" OWS transfer-parameter ) |
| Parameters are in the form of a name or name=value pair. |  | Parameters are in the form of a name or name=value pair. |
| transfer-parameter = token BWS "=" BWS ( token / quoted-string ) |  | transfer-parameter = token BWS "=" BWS ( token / quoted-string ) |
| All transfer-coding names are case-insensitive and ought to be |  | All transfer-coding names are case-insensitive and ought to be |
| registered within the HTTP Transfer Coding registry, as defined in |  | registered within the HTTP Transfer Coding registry, as defined in |
| Section 8.4. They are used in the TE (Section 4.3) and Transfer- |  | Section 8.4. They are used in the TE (Section 4.3) and |
| Encoding (Section 3.3.1) header fields. |  | Transfer-Encoding (Section 3.3.1) header fields. |
| 4.1. Chunked Transfer Coding |  | 4.1. Chunked Transfer Coding |
| The chunked transfer coding wraps the payload body in order to |  | The chunked transfer coding wraps the payload body in order to |
| transfer it as a series of chunks, each with its own size indicator, |  | transfer it as a series of chunks, each with its own size indicator, |
| followed by an OPTIONAL trailer containing header fields. Chunked |  | followed by an OPTIONAL trailer containing header fields. Chunked |
| enables content streams of unknown size to be transferred as a |  | enables content streams of unknown size to be transferred as a |
| sequence of length-delimited buffers, which enables the sender to |  | sequence of length-delimited buffers, which enables the sender to |
| retain connection persistence and the recipient to know when it has |  | retain connection persistence and the recipient to know when it has |
| received the entire message. |  | received the entire message. |
| skipping to change at page 36, line 9 |  | skipping to change at page 36, line 39 |
| when a chunk with a chunk-size of zero is received, possibly followed |  | when a chunk with a chunk-size of zero is received, possibly followed |
| by a trailer, and finally terminated by an empty line. |  | by a trailer, and finally terminated by an empty line. |
| A recipient MUST be able to parse and decode the chunked transfer |  | A recipient MUST be able to parse and decode the chunked transfer |
| coding. |  | coding. |
| 4.1.1. Chunk Extensions |  | 4.1.1. Chunk Extensions |
| The chunked encoding allows each chunk to include zero or more chunk |  | The chunked encoding allows each chunk to include zero or more chunk |
| extensions, immediately following the chunk-size, for the sake of |  | extensions, immediately following the chunk-size, for the sake of |
| supplying per-chunk metadata (such as a signature or hash), mid- |  | supplying per-chunk metadata (such as a signature or hash), |
| message control information, or randomization of message body size. |  | mid-message control information, or randomization of message body |
|  |  | size. |
| chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-val ] ) |  | chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-val ] ) |
| chunk-ext-name = token |  | chunk-ext-name = token |
| chunk-ext-val = token / quoted-string |  | chunk-ext-val = token / quoted-string |
| The chunked encoding is specific to each connection and is likely to |  | The chunked encoding is specific to each connection and is likely to |
| be removed or recoded by each recipient (including intermediaries) |  | be removed or recoded by each recipient (including intermediaries) |
| before any higher-level application would have a chance to inspect |  | before any higher-level application would have a chance to inspect |
| the extensions. Hence, use of chunk extensions is generally limited |  | the extensions. Hence, use of chunk extensions is generally limited |
| skipping to change at page 40, line 7 |  | skipping to change at page 40, line 41 |
| 5. Message Routing |  | 5. Message Routing |
| HTTP request message routing is determined by each client based on |  | HTTP request message routing is determined by each client based on |
| the target resource, the client's proxy configuration, and |  | the target resource, the client's proxy configuration, and |
| establishment or reuse of an inbound connection. The corresponding |  | establishment or reuse of an inbound connection. The corresponding |
| response routing follows the same connection chain back to the |  | response routing follows the same connection chain back to the |
| client. |  | client. |
| 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 |
| purpose computers to home appliances. In some cases, communication |  | general-purpose computers to home appliances. In some cases, |
| options are hard-coded in a client's configuration. However, most |  | communication options are hard-coded in a client's configuration. |
| HTTP clients rely on the same resource identification mechanism and |  | However, most HTTP clients rely on the same resource identification |
| configuration techniques as general-purpose Web browsers. |  | mechanism and 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 [RFC7231], and a target resource upon which to apply those |  | in [RFC7231], 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 component, if any, |  | The target URI excludes the reference's fragment component, if any, |
| since fragment identifiers are reserved for client-side processing |  | since fragment identifiers are reserved for client-side processing |
| ([RFC3986], Section 3.5). |  | ([RFC3986], Section 3.5). |
| skipping to change at page 43, line 48 |  | skipping to change at page 44, line 37 |
| <http://www.example.org/pub/WWW/> would begin with: |  | <http://www.example.org/pub/WWW/> would begin with: |
| GET /pub/WWW/ HTTP/1.1 |  | GET /pub/WWW/ HTTP/1.1 |
| Host: www.example.org |  | Host: www.example.org |
| A client MUST send a Host header field in an HTTP/1.1 request even if |  | A client MUST send a Host header field in an HTTP/1.1 request even if |
| the request-target is in the absolute-form, since this allows the |  | the request-target is in the absolute-form, since this allows the |
| Host information to be forwarded through ancient HTTP/1.0 proxies |  | Host information to be forwarded through ancient HTTP/1.0 proxies |
| that might not have implemented Host. |  | that might not have implemented Host. |
| When a proxy receives a request with an absolute-form of request- |  | When a proxy receives a request with an absolute-form of |
| target, the proxy MUST ignore the received Host header field (if any) |  | request-target, the proxy MUST ignore the received Host header field |
| and instead replace it with the host information of the request- |  | (if any) and instead replace it with the host information of the |
| target. A proxy that forwards such a request MUST generate a new |  | request-target. A proxy that forwards such a request MUST generate a |
| Host field-value based on the received request-target rather than |  | new Host field-value based on the received request-target rather than |
| forward the received Host field-value. |  | forward the received Host field-value. |
| Since the Host header field acts as an application-level routing |  | Since the Host header field acts as an application-level routing |
| mechanism, it is a frequent target for malware seeking to poison a |  | mechanism, it is a frequent target for malware seeking to poison a |
| shared cache or redirect a request to an unintended server. An |  | shared cache or redirect a request to an unintended server. An |
| interception proxy is particularly vulnerable if it relies on the |  | interception proxy is particularly vulnerable if it relies on the |
| Host field-value for redirecting requests to internal servers, or for |  | Host field-value for redirecting requests to internal servers, or for |
| use as a cache key in a shared cache, without first verifying that |  | use as a cache key in a shared cache, without first verifying that |
| the intercepted connection is targeting a valid IP address for that |  | the intercepted connection is targeting a valid IP address for that |
| host. |  | host. |
| skipping to change at page 46, line 18 |  | skipping to change at page 47, line 8 |
| request message with its corresponding one or more response messages. |  | request message with its corresponding one or more response messages. |
| Hence, it relies on the order of response arrival to correspond |  | Hence, it relies on the order of response arrival to correspond |
| exactly to the order in which requests are made on the same |  | exactly to the order in which requests are made on the same |
| connection. More than one response message per request only occurs |  | connection. More than one response message per request only occurs |
| when one or more informational responses (1xx, see Section 6.2 of |  | when one or more informational responses (1xx, see Section 6.2 of |
| [RFC7231]) precede a final response to the same request. |  | [RFC7231]) precede a final response to the same request. |
| A client that has more than one outstanding request on a connection |  | A client that has more than one outstanding request on a connection |
| MUST maintain a list of outstanding requests in the order sent and |  | MUST maintain a list of outstanding requests in the order sent and |
| MUST associate each received response message on that connection to |  | MUST associate each received response message on that connection to |
| the highest ordered request that has not yet received a final (non- |  | the highest ordered request that has not yet received a final |
| 1xx) response. |  | (non-1xx) response. |
| 5.7. Message Forwarding |  | 5.7. Message Forwarding |
| As described in Section 2.3, intermediaries can serve a variety of |  | As described in Section 2.3, intermediaries can serve a variety of |
| roles in the processing of HTTP requests and responses. Some |  | roles in the processing of HTTP requests and responses. Some |
| intermediaries are used to improve performance or availability. |  | intermediaries are used to improve performance or availability. |
| Others are used for access control or to filter content. Since an |  | Others are used for access control or to filter content. Since an |
| HTTP stream has characteristics similar to a pipe-and-filter |  | HTTP stream has characteristics similar to a pipe-and-filter |
| architecture, there are no inherent limits to the extent an |  | architecture, there are no inherent limits to the extent an |
| intermediary can enhance (or interfere) with either direction of the |  | intermediary can enhance (or interfere) with either direction of the |
| skipping to change at page 52, line 50 |  | skipping to change at page 54, line 8 |
| 6.3.1. Retrying Requests |  | 6.3.1. Retrying Requests |
| Connections can be closed at any time, with or without intention. |  | Connections can be closed at any time, with or without intention. |
| Implementations ought to anticipate the need to recover from |  | Implementations ought to anticipate the need to recover from |
| asynchronous close events. |  | asynchronous close events. |
| When an inbound connection is closed prematurely, a client MAY open a |  | When an inbound connection is closed prematurely, a client MAY open a |
| new connection and automatically retransmit an aborted sequence of |  | new connection and automatically retransmit an aborted sequence of |
| requests if all of those requests have idempotent methods (Section |  | requests if all of those requests have idempotent methods (Section |
| 4.2.2 of [RFC7231]). A proxy MUST NOT automatically retry non- |  | 4.2.2 of [RFC7231]). A proxy MUST NOT automatically retry |
| idempotent requests. |  | non-idempotent requests. |
| A user agent MUST NOT automatically retry a request with a non- |  | A user agent MUST NOT automatically retry a request with a non- |
| idempotent method unless it has some means to know that the request |  | idempotent method unless it has some means to know that the request |
| semantics are actually idempotent, regardless of the method, or some |  | semantics are actually idempotent, regardless of the method, or some |
| means to detect that the original request was never applied. For |  | means to detect that the original request was never applied. For |
| example, a user agent that knows (through design or configuration) |  | example, a user agent that knows (through design or configuration) |
| that a POST request to a given resource is safe can repeat that |  | that a POST request to a given resource is safe can repeat that |
| request automatically. Likewise, a user agent designed specifically |  | request automatically. Likewise, a user agent designed specifically |
| to operate on a version control repository might be able to recover |  | to operate on a version control repository might be able to recover |
| from partial failure conditions by checking the target resource |  | from partial failure conditions by checking the target resource |
| skipping to change at page 54, line 21 |  | skipping to change at page 55, line 28 |
| A client ought to limit the number of simultaneous open connections |  | A client ought to limit the number of simultaneous open connections |
| that it maintains to a given server. |  | that it maintains to a given server. |
| Previous revisions of HTTP gave a specific number of connections as a |  | Previous revisions of HTTP gave a specific number of connections as a |
| ceiling, but this was found to be impractical for many applications. |  | ceiling, but this was found to be impractical for many applications. |
| As a result, this specification does not mandate a particular maximum |  | As a result, this specification does not mandate a particular maximum |
| number of connections but, instead, encourages clients to be |  | number of connections but, instead, encourages clients to be |
| conservative when opening multiple connections. |  | conservative when opening multiple connections. |
| Multiple connections are typically used to avoid the "head-of-line |  | Multiple connections are typically used to avoid the "head-of-line |
| blocking" problem, wherein a request that takes significant server- |  | blocking" problem, wherein a request that takes significant |
| side processing and/or has a large payload blocks subsequent requests |  | server-side processing and/or has a large payload blocks subsequent |
| on the same connection. However, each connection consumes server |  | requests on the same connection. However, each connection consumes |
| resources. Furthermore, using multiple connections can cause |  | server resources. Furthermore, using multiple connections can cause |
| undesirable side effects in congested networks. |  | undesirable side effects in congested networks. |
| Note that a server might reject traffic that it deems abusive or |  | Note that a server might reject traffic that it deems abusive or |
| characteristic of a denial-of-service attack, such as an excessive |  | characteristic of a denial-of-service attack, such as an excessive |
| number of open connections from a single client. |  | number of open connections from a single client. |
| 6.5. Failures and Timeouts |  | 6.5. Failures and Timeouts |
| Servers will usually have some timeout value beyond which they will |  | Servers will usually have some timeout value beyond which they will |
| no longer maintain an inactive connection. Proxy servers might make |  | no longer maintain an inactive connection. Proxy servers might make |
| skipping to change at page 58, line 32 |  | skipping to change at page 59, line 48 |
| 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 8.6. |  | using the registration procedure defined in Section 8.6. |
| 7. ABNF List Extension: #rule |  | 7. 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 |
| delimited lists of elements. The full form is "<n>#<m>element" |  | comma-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). |
| In any production that uses the list construct, a sender MUST NOT |  | In any production that uses the list construct, a sender MUST NOT |
| generate empty list elements. In other words, a sender MUST generate |  | generate empty list elements. In other words, a sender MUST generate |
| lists that satisfy the following syntax: |  | lists that satisfy the following syntax: |
| 1#element => element *( OWS "," OWS element ) |  | 1#element => element *( OWS "," OWS element ) |
| and: |  | and: |
| skipping to change at page 66, line 18 |  | skipping to change at page 67, line 45 |
| and users of known security considerations relevant to HTTP message |  | and users of known security considerations relevant to HTTP message |
| syntax, parsing, and routing. Security considerations about HTTP |  | syntax, parsing, and routing. Security considerations about HTTP |
| semantics and payloads are addressed in [RFC7231]. |  | semantics and payloads are addressed in [RFC7231]. |
| 9.1. Establishing Authority |  | 9.1. Establishing Authority |
| HTTP relies on the notion of an authoritative response: a response |  | HTTP relies on the notion of an authoritative response: a response |
| that has been determined by (or at the direction of) the authority |  | that has been determined by (or at the direction of) the authority |
| identified within the target URI to be the most appropriate response |  | identified within the target URI to be the most appropriate response |
| for that request given the state of the target resource at the time |  | for that request given the state of the target resource at the time |
| of response message origination. Providing a response from a non- |  | of response message origination. Providing a response from a |
| authoritative source, such as a shared cache, is often useful to |  | non-authoritative source, such as a shared cache, is often useful to |
| improve performance and availability, but only to the extent that the |  | improve performance and availability, but only to the extent that the |
| source can be trusted or the distrusted response can be safely used. |  | source can be trusted or the distrusted response can be safely used. |
| Unfortunately, establishing authority can be difficult. For example, |  | Unfortunately, establishing authority can be difficult. For example, |
| phishing is an attack on the user's perception of authority, where |  | phishing is an attack on the user's perception of authority, where |
| that perception can be misled by presenting similar branding in |  | that perception can be misled by presenting similar branding in |
| hypertext, possibly aided by userinfo obfuscating the authority |  | hypertext, possibly aided by userinfo obfuscating the authority |
| component (see Section 2.7.1). User agents can reduce the impact of |  | component (see Section 2.7.1). User agents can reduce the impact of |
| phishing attacks by enabling users to easily inspect a target URI |  | phishing attacks by enabling users to easily inspect a target URI |
| prior to making an action, by prominently distinguishing (or |  | prior to making an action, by prominently distinguishing (or |
| skipping to change at page 69, line 22 |  | skipping to change at page 70, line 48 |
| usage. |  | usage. |
| This specification has introduced new requirements on request |  | This specification has introduced new requirements on request |
| parsing, particularly with regard to message framing in |  | parsing, particularly with regard to message framing in |
| Section 3.3.3, to reduce the effectiveness of request smuggling. |  | Section 3.3.3, to reduce the effectiveness of request smuggling. |
| 9.6. Message Integrity |  | 9.6. 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 |
| underlying transport protocols and the use of length or chunk- |  | underlying transport protocols and the use of length or |
| delimited framing to detect completeness. Additional integrity |  | chunk-delimited framing to detect completeness. Additional integrity |
| mechanisms, such as hash functions or digital signatures applied to |  | mechanisms, such as hash functions or digital signatures applied to |
| the content, can be selectively added to messages via extensible |  | the content, can be selectively added to messages via extensible |
| metadata header fields. Historically, the lack of a single integrity |  | metadata header fields. Historically, the lack of a single integrity |
| mechanism has been justified by the informal nature of most HTTP |  | mechanism has been justified by the informal nature of most HTTP |
| communication. However, the prevalence of HTTP as an information |  | communication. However, the prevalence of HTTP as an information |
| access mechanism has resulted in its increasing use within |  | access mechanism has resulted in its increasing use within |
| environments where verification of message integrity is crucial. |  | environments where verification of message integrity is crucial. |
| User agents are encouraged to implement configurable means for |  | User agents are encouraged to implement configurable means for |
| detecting and reporting failures of message integrity such that those |  | detecting and reporting failures of message integrity such that those |
| skipping to change at page 70, line 27 |  | skipping to change at page 72, line 7 |
| constrained by laws and regulations. Log information needs to be |  | constrained by laws and regulations. Log information needs to be |
| securely stored and appropriate guidelines followed for its analysis. |  | securely stored and appropriate guidelines followed for its analysis. |
| Anonymization of personal information within individual entries |  | Anonymization of personal information within individual entries |
| helps, but it is generally not sufficient to prevent real log traces |  | helps, but it is generally not sufficient to prevent real log traces |
| from being re-identified based on correlation with other access |  | from being re-identified based on correlation with other access |
| characteristics. As such, access traces that are keyed to a specific |  | characteristics. As such, access traces that are keyed to a specific |
| client are unsafe to publish even if the key is pseudonymous. |  | client are unsafe to publish even if the key is pseudonymous. |
| To minimize the risk of theft or accidental publication, log |  | To minimize the risk of theft or accidental publication, log |
| information ought to be purged of personally identifiable |  | information ought to be purged of personally identifiable |
| information, including user identifiers, IP addresses, and user- |  | information, including user identifiers, IP addresses, and |
| provided query parameters, as soon as that information is no longer |  | user-provided query parameters, as soon as that information is no |
| necessary to support operational needs for security, auditing, or |  | longer necessary to support operational needs for security, auditing, |
| fraud control. |  | or fraud control. |
| 10. Acknowledgments |  | 10. Acknowledgments |
| This edition of HTTP/1.1 builds on the many contributions that went |  | This edition of HTTP/1.1 builds on the many contributions that went |
| into RFC 1945, RFC 2068, RFC 2145, and RFC 2616, including |  | into RFC 1945, RFC 2068, RFC 2145, and RFC 2616, including |
| substantial contributions made by the previous authors, editors, and |  | substantial contributions made by the previous authors, editors, and |
| Working Group Chairs: Tim Berners-Lee, Ari Luotonen, Roy T. Fielding, |  | Working Group Chairs: Tim Berners-Lee, Ari Luotonen, Roy T. Fielding, |
| Henrik Frystyk Nielsen, Jim Gettys, Jeffrey C. Mogul, Larry Masinter, |  | Henrik Frystyk Nielsen, Jim Gettys, Jeffrey C. Mogul, Larry Masinter, |
| and Paul J. Leach. Mark Nottingham oversaw this effort as Working |  | and Paul J. Leach. Mark Nottingham oversaw this effort as Working |
| Group Chair. |  | Group Chair. |
| skipping to change at page 73, line 7 |  | skipping to change at page 74, line 35 |
| [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, |  | [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, |
| "Uniform Resource Identifier (URI): Generic Syntax", |  | "Uniform Resource Identifier (URI): Generic Syntax", |
| STD 66, RFC 3986, January 2005. |  | STD 66, RFC 3986, January 2005. |
| [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for |  | [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for |
| Syntax Specifications: ABNF", STD 68, RFC 5234, |  | Syntax Specifications: ABNF", STD 68, RFC 5234, |
| January 2008. |  | January 2008. |
| [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext |  | [RFC7231] 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-latest (work in |  | RFC 7231, June 2014. |
| progress), June 2014. |  |  |
| [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext |  | [RFC7232] 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-latest (work in |  | RFC 7232, June 2014. |
| progress), June 2014. |  |  |
| [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |  | [RFC7233] 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-latest (work in |  | Requests", RFC 7233, June 2014. |
| progress), June 2014. |  |  |
| [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, |  | [RFC7234] 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-latest (work in progress), |  | RFC 7234, June 2014. |
| June 2014. |  |  |
| [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext |  | [RFC7235] 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-latest (work in progress), |  | RFC 7235, June 2014. |
| June 2014. |  |  |
| [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 |  | [Welch] Welch, T., "A Technique for High-Performance Data |
| Compression", IEEE Computer 17(6), June 1984. |  | Compression", IEEE Computer 17(6), June 1984. |
| 11.2. Informative References |  | 11.2. Informative References |
| skipping to change at page 77, line 31 |  | skipping to change at page 79, line 41 |
| hung connection. |  | hung connection. |
| 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: |
| alive in requests carefully; while they can enable persistent |  | keep-alive in requests carefully; while they can enable persistent |
| connections with HTTP/1.0 servers, clients using them will need to |  | connections with HTTP/1.0 servers, clients using them will need to |
| monitor the connection for "hung" requests (which indicate that the |  | monitor the connection for "hung" requests (which indicate that the |
| client ought stop sending the header field), and this mechanism ought |  | client ought stop sending the header field), and this mechanism 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. |
| skipping to change at page 79, line 11 |  | skipping to change at page 81, line 20 |
| and 4) |  | and 4) |
| Chunk length does not include the count of the octets in the chunk |  | Chunk length does not include the count of the octets in the chunk |
| header and trailer. Line folding in chunk extensions is disallowed. |  | header and trailer. Line folding in chunk extensions is disallowed. |
| (Section 4.1) |  | (Section 4.1) |
| 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) |
| The segment + query components of RFC 3986 have been used to define |  | The segment + query components of RFC 3986 have been used to define |
| the request-target, instead of abs_path from RFC 1808. The asterisk- |  | the request-target, instead of abs_path from RFC 1808. The |
| form of the request-target is only allowed with the OPTIONS method. |  | asterisk-form of the request-target is only allowed with the OPTIONS |
| (Section 5.3) |  | method. (Section 5.3) |
| The term "Effective Request URI" has been introduced. (Section 5.5) |  | The term "Effective Request URI" has been introduced. (Section 5.5) |
| Gateways do not need to generate Via header fields anymore. |  | Gateways do not need to generate Via header fields anymore. |
| (Section 5.7.1) |  | (Section 5.7.1) |
| Exactly when "close" connection options have to be sent has been |  | Exactly when "close" connection options have to be sent has been |
| clarified. Also, "hop-by-hop" header fields are required to appear |  | clarified. Also, "hop-by-hop" header fields are required to appear |
| in the Connection header field; just because they're defined as hop- |  | in the Connection header field; just because they're defined as hop- |
| by-hop in this specification doesn't exempt them. (Section 6.1) |  | by-hop in this specification doesn't exempt them. (Section 6.1) |
| skipping to change at page 82, line 29 |  | skipping to change at page 85, line 8 |
| transfer-coding = "chunked" / "compress" / "deflate" / "gzip" / |  | transfer-coding = "chunked" / "compress" / "deflate" / "gzip" / |
| transfer-extension |  | transfer-extension |
| transfer-extension = token *( OWS ";" OWS transfer-parameter ) |  | transfer-extension = token *( OWS ";" OWS transfer-parameter ) |
| transfer-parameter = token BWS "=" BWS ( token / quoted-string ) |  | transfer-parameter = token BWS "=" BWS ( token / quoted-string ) |
| uri-host = <host, see [RFC3986], Section 3.2.2> |  | uri-host = <host, see [RFC3986], Section 3.2.2> |
| Index |  | Index |
| A |  | A |
| absolute-form (of request-target) 41 |  | absolute-form (of request-target) 42 |
| accelerator 10 |  | accelerator 10 |
| application/http Media Type 62 |  | application/http Media Type 63 |
| asterisk-form (of request-target) 42 |  | asterisk-form (of request-target) 43 |
| authoritative response 66 |  | authoritative response 67 |
| authority-form (of request-target) 42 |  | authority-form (of request-target) 42-43 |
| B |  | B |
| browser 7 |  | browser 7 |
| C |  | C |
| cache 11 |  | cache 11 |
| cacheable 11 |  | cacheable 12 |
| captive portal 11 |  | captive portal 11 |
| chunked (Coding Format) 28, 31, 35 |  | chunked (Coding Format) 28, 32, 36 |
| client 7 |  | client 7 |
| close 50, 55 |  | close 51, 56 |
| compress (Coding Format) 38 |  | compress (Coding Format) 38 |
| connection 7 |  | connection 7 |
| Connection header field 50, 55 |  | Connection header field 51, 56 |
| Content-Length header field 29 |  | Content-Length header field 30 |
| D |  | D |
| deflate (Coding Format) 38 |  | deflate (Coding Format) 38 |
| Delimiters 26 |  | Delimiters 27 |
| downstream 9 |  | downstream 10 |
| E |  | E |
| effective request URI 44 |  | effective request URI 45 |
| G |  | G |
| gateway 10 |  | gateway 10 |
| Grammar |  | Grammar |
| absolute-form 41 |  | absolute-form 42 |
| absolute-path 16 |  | absolute-path 16 |
| absolute-URI 16 |  | absolute-URI 16 |
| ALPHA 6 |  | ALPHA 6 |
| asterisk-form 41-42 |  | asterisk-form 41, 43 |
| authority 16 |  | authority 16 |
| authority-form 41-42 |  | authority-form 42-43 |
| BWS 24 |  | BWS 25 |
| chunk 35 |  | chunk 36 |
| chunk-data 35 |  | chunk-data 36 |
| chunk-ext 35-36 |  | chunk-ext 36 |
| chunk-ext-name 36 |  | chunk-ext-name 36 |
| chunk-ext-val 36 |  | chunk-ext-val 36 |
| chunk-size 35 |  | chunk-size 36 |
| chunked-body 35-36 |  | chunked-body 36 |
| comment 27 |  | comment 27 |
| Connection 50 |  | Connection 51 |
| connection-option 50 |  | connection-option 51 |
| Content-Length 29 |  | Content-Length 30 |
| CR 6 |  | CR 6 |
| CRLF 6 |  | CRLF 6 |
| ctext 27 |  | ctext 27 |
| CTL 6 |  | CTL 6 |
| DIGIT 6 |  | DIGIT 6 |
| DQUOTE 6 |  | DQUOTE 6 |
| field-content 22 |  | field-content 23 |
| field-name 22, 39 |  | field-name 23, 40 |
| field-value 22 |  | field-value 23 |
| field-vchar 22 |  | field-vchar 23 |
| fragment 16 |  | fragment 16 |
| header-field 22, 36 |  | header-field 23, 37 |
| HEXDIG 6 |  | HEXDIG 6 |
| Host 43 |  | Host 44 |
| HTAB 6 |  | HTAB 6 |
| HTTP-message 19 |  | HTTP-message 19 |
| HTTP-name 13 |  | HTTP-name 14 |
| http-URI 16 |  | http-URI 17 |
| HTTP-version 13 |  | HTTP-version 14 |
| https-URI 18 |  | https-URI 18 |
| last-chunk 35 |  | last-chunk 36 |
| LF 6 |  | LF 6 |
| message-body 27 |  | message-body 28 |
| method 21 |  | method 21 |
| obs-fold 22 |  | obs-fold 23 |
| obs-text 27 |  | obs-text 27 |
| OCTET 6 |  | OCTET 6 |
| origin-form 41 |  | origin-form 42 |
| OWS 24 |  | OWS 25 |
| partial-URI 16 |  | partial-URI 16 |
| port 16 |  | port 16 |
| protocol-name 47 |  | protocol-name 47 |
| protocol-version 47 |  | protocol-version 47 |
| pseudonym 47 |  | pseudonym 47 |
| qdtext 27 |  | qdtext 27 |
| query 16 |  | query 16 |
| quoted-pair 27 |  | quoted-pair 27 |
| quoted-string 27 |  | quoted-string 27 |
| rank 38 |  | rank 39 |
| reason-phrase 22 |  | reason-phrase 22 |
| received-by 47 |  | received-by 47 |
| received-protocol 47 |  | received-protocol 47 |
| request-line 21 |  | request-line 21 |
| request-target 41 |  | request-target 41 |
| RWS 24 |  | RWS 25 |
| scheme 16 |  | scheme 16 |
| segment 16 |  | segment 16 |
| SP 6 |  | SP 6 |
| start-line 20 |  | start-line 21 |
| status-code 22 |  | status-code 22 |
| status-line 22 |  | status-line 22 |
| t-codings 38 |  | t-codings 39 |
| t-ranking 38 |  | t-ranking 39 |
| tchar 26 |  | tchar 27 |
| TE 38 |  | TE 39 |
| token 26 |  | token 27 |
| Trailer 39 |  | Trailer 40 |
| trailer-part 35-36 |  | trailer-part 37 |
| transfer-coding 35 |  | transfer-coding 35 |
| Transfer-Encoding 28 |  | Transfer-Encoding 28 |
| transfer-extension 35 |  | transfer-extension 35 |
| transfer-parameter 35 |  | transfer-parameter 35 |
| Upgrade 56 |  | Upgrade 57 |
| uri-host 16 |  | uri-host 16 |
| URI-reference 16 |  | URI-reference 16 |
| VCHAR 6 |  | VCHAR 6 |
| Via 47 |  | Via 47 |
|  |  | gzip (Coding Format) 39 |
| gzip (Coding Format) 38 |  |  |
| H |  | H |
| header field 19 |  | header field 19 |
| header section 19 |  | header section 19 |
| headers 19 |  | headers 19 |
| Host header field 43 |  | Host header field 44 |
| http URI scheme 16 |  | http URI scheme 17 |
| https URI scheme 18 |  | https URI scheme 17 |
| I |  | I |
| inbound 9 |  | inbound 9 |
| interception proxy 11 |  | interception proxy 11 |
| intermediary 9 |  | intermediary 9 |
| M |  | M |
| Media Type |  | Media Type |
| application/http 62 |  | application/http 63 |
| message/http 61 |  | message/http 62 |
| message 7 |  | message 7 |
| message/http Media Type 61 |  | message/http Media Type 62 |
| method 21 |  | method 21 |
| N |  | N |
| non-transforming proxy 48 |  | non-transforming proxy 49 |
| O |  | O |
| origin server 7 |  | origin server 7 |
| origin-form (of request-target) 41 |  | origin-form (of request-target) 42 |
| outbound 9 |  | outbound 10 |
| P |  | P |
| phishing 66 |  | phishing 67 |
| proxy 10 |  | proxy 10 |
| R |  | R |
| recipient 7 |  | recipient 7 |
| request 7 |  | request 7 |
| request-target 21 |  | request-target 21 |
| resource 16 |  | resource 16 |
| response 7 |  | response 7 |
| reverse proxy 10 |  | reverse proxy 10 |
| S |  | S |
| sender 7 |  | sender 7 |
| server 7 |  | server 7 |
| spider 7 |  | spider 7 |
| T |  | T |
| target resource 40 |  | target resource 40 |
| target URI 40 |  | target URI 40 |
| TE header field 38 |  | TE header field 39 |
| Trailer header field 39 |  | Trailer header field 40 |
| Transfer-Encoding header field 28 |  | Transfer-Encoding header field 28 |
| transforming proxy 48 |  | transforming proxy 49 |
| transparent proxy 11 |  | transparent proxy 11 |
| tunnel 10 |  | tunnel 10 |
| U |  | U |
| Upgrade header field 56 |  | Upgrade header field 57 |
| upstream 9 |  | upstream 9 |
| URI scheme |  | URI scheme |
| http 16 |  | http 17 |
| https 18 |  | https 17 |
| user agent 7 |  | user agent 7 |
| V |  | V |
| Via header field 46 |  | Via header field 47 |
| Authors' Addresses |  | Authors' Addresses |
| Roy T. Fielding (editor) |  | Roy T. Fielding (editor) |
| Adobe Systems Incorporated |  | Adobe Systems Incorporated |
| 345 Park Ave |  | 345 Park Ave |
| San Jose, CA 95110 |  | San Jose, CA 95110 |
| USA |  | USA |
| EMail: fielding@gbiv.com |  | EMail: fielding@gbiv.com |
End of changes. 78 change blocks.
| 305 lines changed or deleted |  | 280 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/