| draft-ietf-httpbis-p1-messaging-24.txt |  | draft-ietf-httpbis-p1-messaging-25.txt |
--- | --- | --- | --- | ---
| HTTPbis Working Group R. Fielding, Ed. |  | HTTPbis Working Group R. Fielding, Ed. |
| Internet-Draft Adobe |  | Internet-Draft Adobe |
| Obsoletes: 2145,2616 (if approved) J. Reschke, Ed. |  | Obsoletes: 2145,2616 (if approved) J. Reschke, Ed. |
| Updates: 2817,2818 (if approved) greenbytes |  | Updates: 2817,2818 (if approved) greenbytes |
| Intended status: Standards Track September 25, 2013 |  | Intended status: Standards Track November 17, 2013 |
| Expires: March 29, 2014 |  | Expires: May 21, 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-24 |  | draft-ietf-httpbis-p1-messaging-25 |
| Abstract |  | Abstract |
| The Hypertext Transfer Protocol (HTTP) is an application-level |  | The Hypertext Transfer Protocol (HTTP) is an application-level |
| protocol for distributed, collaborative, hypertext information |  | protocol for distributed, collaborative, hypertext information |
| systems. HTTP has been in use by the World Wide Web global |  | systems. HTTP has been in use by the World Wide Web global |
| information initiative since 1990. This document provides an |  | information initiative since 1990. This document provides an |
| overview of HTTP architecture and its associated terminology, defines |  | overview of HTTP architecture and its associated terminology, defines |
| the "http" and "https" Uniform Resource Identifier (URI) schemes, |  | the "http" and "https" Uniform Resource Identifier (URI) schemes, |
| defines the HTTP/1.1 message syntax and parsing requirements, and |  | defines the HTTP/1.1 message syntax and parsing requirements, and |
| skipping to change at page 1, line 35 |  | skipping to change at page 1, line 35 |
| Discussion of this draft takes place on the HTTPBIS working group |  | Discussion of this draft takes place on the HTTPBIS working group |
| mailing list (ietf-http-wg@w3.org), which is archived at |  | mailing list (ietf-http-wg@w3.org), which is archived at |
| <http://lists.w3.org/Archives/Public/ietf-http-wg/>. |  | <http://lists.w3.org/Archives/Public/ietf-http-wg/>. |
| The current issues list is at |  | The current issues list is at |
| <http://tools.ietf.org/wg/httpbis/trac/report/3> and related |  | <http://tools.ietf.org/wg/httpbis/trac/report/3> and related |
| documents (including fancy diffs) can be found at |  | documents (including fancy diffs) can be found at |
| <http://tools.ietf.org/wg/httpbis/>. |  | <http://tools.ietf.org/wg/httpbis/>. |
| The changes in this draft are summarized in Appendix C.4. |  | The changes in this draft are summarized in Appendix C.2. |
| Status of This Memo |  | Status of This Memo |
| This Internet-Draft is submitted in full conformance with the |  | This Internet-Draft is submitted in full conformance with the |
| provisions of BCP 78 and BCP 79. |  | provisions of BCP 78 and BCP 79. |
| Internet-Drafts are working documents of the Internet Engineering |  | Internet-Drafts are working documents of the Internet Engineering |
| Task Force (IETF). Note that other groups may also distribute |  | Task Force (IETF). Note that other groups may also distribute |
| working documents as Internet-Drafts. The list of current Internet- |  | working documents as Internet-Drafts. The list of current Internet- |
| Drafts is at http://datatracker.ietf.org/drafts/current/. |  | Drafts is at http://datatracker.ietf.org/drafts/current/. |
| Internet-Drafts are draft documents valid for a maximum of six months |  | Internet-Drafts are draft documents valid for a maximum of six months |
| and may be updated, replaced, or obsoleted by other documents at any |  | and may be updated, replaced, or obsoleted by other documents at any |
| time. It is inappropriate to use Internet-Drafts as reference |  | time. It is inappropriate to use Internet-Drafts as reference |
| material or to cite them other than as "work in progress." |  | material or to cite them other than as "work in progress." |
| This Internet-Draft will expire on March 29, 2014. |  | This Internet-Draft will expire on May 21, 2014. |
| Copyright Notice |  | Copyright Notice |
| Copyright (c) 2013 IETF Trust and the persons identified as the |  | Copyright (c) 2013 IETF Trust and the persons identified as the |
| document authors. All rights reserved. |  | document authors. All rights reserved. |
| This document is subject to BCP 78 and the IETF Trust's Legal |  | This document is subject to BCP 78 and the IETF Trust's Legal |
| Provisions Relating to IETF Documents |  | Provisions Relating to IETF Documents |
| (http://trustee.ietf.org/license-info) in effect on the date of |  | (http://trustee.ietf.org/license-info) in effect on the date of |
| publication of this document. Please review these documents |  | publication of this document. Please review these documents |
| skipping to change at page 3, line 47 |  | skipping to change at page 3, line 47 |
| 5.6. Associating a Response to a Request . . . . . . . . . . . 46 |  | 5.6. Associating a Response to a Request . . . . . . . . . . . 46 |
| 5.7. Message Forwarding . . . . . . . . . . . . . . . . . . . . 46 |  | 5.7. Message Forwarding . . . . . . . . . . . . . . . . . . . . 46 |
| 5.7.1. Via . . . . . . . . . . . . . . . . . . . . . . . . . 46 |  | 5.7.1. Via . . . . . . . . . . . . . . . . . . . . . . . . . 46 |
| 5.7.2. Transformations . . . . . . . . . . . . . . . . . . . 48 |  | 5.7.2. Transformations . . . . . . . . . . . . . . . . . . . 48 |
| 6. Connection Management . . . . . . . . . . . . . . . . . . . . 49 |  | 6. Connection Management . . . . . . . . . . . . . . . . . . . . 49 |
| 6.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 49 |  | 6.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 49 |
| 6.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 51 |  | 6.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 51 |
| 6.3. Persistence . . . . . . . . . . . . . . . . . . . . . . . 51 |  | 6.3. Persistence . . . . . . . . . . . . . . . . . . . . . . . 51 |
| 6.3.1. Retrying Requests . . . . . . . . . . . . . . . . . . 52 |  | 6.3.1. Retrying Requests . . . . . . . . . . . . . . . . . . 52 |
| 6.3.2. Pipelining . . . . . . . . . . . . . . . . . . . . . . 53 |  | 6.3.2. Pipelining . . . . . . . . . . . . . . . . . . . . . . 53 |
| 6.4. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 54 |  | 6.4. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 53 |
| 6.5. Failures and Time-outs . . . . . . . . . . . . . . . . . . 54 |  | 6.5. Failures and Time-outs . . . . . . . . . . . . . . . . . . 54 |
| 6.6. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 55 |  | 6.6. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 55 |
| 6.7. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 56 |  | 6.7. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 56 |
| 7. ABNF list extension: #rule . . . . . . . . . . . . . . . . . . 58 |  | 7. ABNF list extension: #rule . . . . . . . . . . . . . . . . . . 58 |
| 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59 |  | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59 |
| 8.1. Header Field Registration . . . . . . . . . . . . . . . . 59 |  | 8.1. Header Field Registration . . . . . . . . . . . . . . . . 59 |
| 8.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 60 |  | 8.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 60 |
| 8.3. Internet Media Type Registration . . . . . . . . . . . . . 60 |  | 8.3. Internet Media Type Registration . . . . . . . . . . . . . 60 |
| 8.3.1. Internet Media Type message/http . . . . . . . . . . . 61 |  | 8.3.1. Internet Media Type message/http . . . . . . . . . . . 60 |
| 8.3.2. Internet Media Type application/http . . . . . . . . . 62 |  | 8.3.2. Internet Media Type application/http . . . . . . . . . 61 |
| 8.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 63 |  | 8.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 63 |
| 8.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 63 |  | 8.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 63 |
| 8.4.2. Registration . . . . . . . . . . . . . . . . . . . . . 63 |  | 8.4.2. Registration . . . . . . . . . . . . . . . . . . . . . 63 |
| 8.5. Upgrade Token Registry . . . . . . . . . . . . . . . . . . 64 |  | 8.5. Content Coding Registration . . . . . . . . . . . . . . . 64 |
| 8.5.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 64 |  | 8.6. Upgrade Token Registry . . . . . . . . . . . . . . . . . . 64 |
| 8.5.2. Upgrade Token Registration . . . . . . . . . . . . . . 65 |  | 8.6.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 64 |
|  |  | 8.6.2. Upgrade Token Registration . . . . . . . . . . . . . . 65 |
| 9. Security Considerations . . . . . . . . . . . . . . . . . . . 65 |  | 9. Security Considerations . . . . . . . . . . . . . . . . . . . 65 |
| 9.1. DNS-related Attacks . . . . . . . . . . . . . . . . . . . 65 |  | 9.1. DNS-related Attacks . . . . . . . . . . . . . . . . . . . 65 |
| 9.2. Intermediaries and Caching . . . . . . . . . . . . . . . . 65 |  | 9.2. Intermediaries and Caching . . . . . . . . . . . . . . . . 65 |
| 9.3. Buffer Overflows . . . . . . . . . . . . . . . . . . . . . 66 |  | 9.3. Buffer Overflows . . . . . . . . . . . . . . . . . . . . . 66 |
| 9.4. Message Integrity . . . . . . . . . . . . . . . . . . . . 66 |  | 9.4. Message Integrity . . . . . . . . . . . . . . . . . . . . 66 |
| 9.5. Server Log Information . . . . . . . . . . . . . . . . . . 67 |  | 9.5. Server Log Information . . . . . . . . . . . . . . . . . . 67 |
| 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 67 |  | 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 68 |
| 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 69 |  | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 69 |
| 11.1. Normative References . . . . . . . . . . . . . . . . . . . 69 |  | 11.1. Normative References . . . . . . . . . . . . . . . . . . . 69 |
| 11.2. Informative References . . . . . . . . . . . . . . . . . . 70 |  | 11.2. Informative References . . . . . . . . . . . . . . . . . . 71 |
| Appendix A. HTTP Version History . . . . . . . . . . . . . . . . 72 |  | Appendix A. HTTP Version History . . . . . . . . . . . . . . . . 72 |
| A.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 73 |  | A.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 73 |
| A.1.1. Multi-homed Web Servers . . . . . . . . . . . . . . . 73 |  | A.1.1. Multi-homed Web Servers . . . . . . . . . . . . . . . 73 |
| A.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 73 |  | A.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 74 |
| A.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 74 |  | A.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 74 |
| A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 74 |  | A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 74 |
| Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 76 |  | Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 77 |
| Appendix C. Change Log (to be removed by RFC Editor before |  | Appendix C. Change Log (to be removed by RFC Editor before |
| publication) . . . . . . . . . . . . . . . . . . . . 79 |  | publication) . . . . . . . . . . . . . . . . . . . . 79 |
| C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 79 |  | C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 79 |
| C.2. Since draft-ietf-httpbis-p1-messaging-21 . . . . . . . . . 79 |  | C.2. Since draft-ietf-httpbis-p1-messaging-24 . . . . . . . . . 79 |
| C.3. Since draft-ietf-httpbis-p1-messaging-22 . . . . . . . . . 80 |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 |
| C.4. Since draft-ietf-httpbis-p1-messaging-23 . . . . . . . . . 82 |  |  |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 |  |  |
| 1. Introduction |  | 1. Introduction |
| The Hypertext Transfer Protocol (HTTP) is an application-level |  | The Hypertext Transfer Protocol (HTTP) is an application-level |
| request/response protocol that uses extensible semantics and self- |  | request/response protocol that uses extensible semantics and self- |
| descriptive message payloads for flexible interaction with network- |  | descriptive message payloads for flexible interaction with network- |
| based hypertext information systems. This document is the first in a |  | based hypertext information systems. This document is the first in a |
| series of documents that collectively form the HTTP/1.1 |  | series of documents that collectively form the HTTP/1.1 |
| specification: |  | specification: |
| skipping to change at page 12, line 44 |  | skipping to change at page 12, line 44 |
| resource owners, and protocol element registrations when they apply |  | resource owners, and protocol element registrations when they apply |
| beyond the scope of a single communication. |  | beyond the scope of a single communication. |
| The verb "generate" is used instead of "send" where a requirement |  | The verb "generate" is used instead of "send" where a requirement |
| differentiates between creating a protocol element and merely |  | differentiates between creating a protocol element and merely |
| forwarding a received element downstream. |  | forwarding a received element downstream. |
| An implementation is considered conformant if it complies with all of |  | An implementation is considered conformant if it complies with all of |
| the requirements associated with the roles it partakes in HTTP. |  | the requirements associated with the roles it partakes in HTTP. |
| Conformance includes both the syntax and semantics of HTTP protocol |  | Conformance includes both the syntax and semantics of protocol |
| elements. A sender MUST NOT generate protocol elements that convey a |  | elements. A sender MUST NOT generate protocol elements that convey a |
| meaning that is known by that sender to be false. A sender MUST NOT |  | meaning that is known by that sender to be false. A sender MUST NOT |
| generate protocol elements that do not match the grammar defined by |  | generate protocol elements that do not match the grammar defined by |
| the 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 |
| skipping to change at page 15, line 5 |  | skipping to change at page 15, line 5 |
| header fields ought to be implemented by all HTTP/1.x implementations |  | header fields ought to be implemented by all HTTP/1.x implementations |
| whether or not they advertise conformance with HTTP/1.1. |  | whether or not they advertise conformance with HTTP/1.1. |
| New header fields can be introduced without changing the protocol |  | New header fields can be introduced without changing the protocol |
| 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 MUST NOT blindly forward |  | in forwarded messages. In other words, they are not allowed to |
| the first line of an HTTP message without ensuring that the protocol |  | blindly forward the first line of an HTTP message without ensuring |
| version in that message matches a version to which that intermediary |  | that the protocol version in that message matches a version to which |
| is conformant for both the receiving and sending of messages. |  | that intermediary is conformant for both the receiving and sending of |
| Forwarding an HTTP message without rewriting the HTTP-version might |  | messages. Forwarding an HTTP message without rewriting the HTTP- |
| result in communication errors when downstream recipients use the |  | version might result in communication errors when downstream |
| message sender's version to determine what features are safe to use |  | recipients use the message sender's version to determine what |
| 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 |
| server incorrectly implements the HTTP specification, but only after |  | server incorrectly implements the HTTP specification, but only after |
| the client has attempted at least one normal request and determined |  | the client has attempted at least one normal request and determined |
| from the response status code or header fields (e.g., Server) that |  | from the response status code or header fields (e.g., Server) that |
| the server improperly handles higher request versions. |  | the server improperly handles higher request versions. |
| A server SHOULD send a response version equal to the highest version |  | A server SHOULD send a response version equal to the highest version |
| to which the server is conformant and whose major version is less |  | to which the server is conformant that has a major version less than |
| than or equal to the one received in the request. A server MUST NOT |  | or equal to the one received in the request. A server MUST NOT send |
| send a version to which it is not conformant. A server MAY send a |  | a version to which it is not conformant. A server can send a 505 |
| 505 (HTTP Version Not Supported) response if it cannot send a |  | (HTTP Version Not Supported) response if it wishes, for any reason, |
| response using the major version used in the client's request. |  | to refuse service of the client's major protocol version. |
| A server MAY send an HTTP/1.0 response to a request if it is known or |  | A server MAY send an HTTP/1.0 response to a request if it is known or |
| suspected that the client incorrectly implements the HTTP |  | suspected that the client incorrectly implements the HTTP |
| specification and is incapable of correctly processing later version |  | specification and is incapable of correctly processing later version |
| responses, such as when a client fails to parse the version number |  | responses, such as when a client fails to parse the version number |
| correctly or when an intermediary is known to blindly forward the |  | correctly or when an intermediary is known to blindly forward the |
| HTTP-version even when it doesn't conform to the given minor version |  | HTTP-version even when it doesn't conform to the given minor version |
| of the protocol. Such protocol downgrades SHOULD NOT be performed |  | of the protocol. Such protocol downgrades SHOULD NOT be performed |
| unless triggered by specific client attributes, such as when one or |  | unless triggered by specific client attributes, such as when one or |
| more of the request header fields (e.g., User-Agent) uniquely match |  | more of the request header fields (e.g., User-Agent) uniquely match |
| skipping to change at page 31, line 14 |  | skipping to change at page 31, line 14 |
| Aside from the cases defined above, in the absence of Transfer- |  | Aside from the cases defined above, in the absence of Transfer- |
| Encoding, an origin server SHOULD send a Content-Length header field |  | Encoding, an origin server SHOULD send a Content-Length header field |
| when the payload body size is known prior to sending the complete |  | when the payload body size is known prior to sending the complete |
| header section. This will allow downstream recipients to measure |  | header section. This will allow downstream recipients to measure |
| transfer progress, know when a received message is complete, and |  | transfer progress, know when a received message is complete, and |
| potentially reuse the connection for additional requests. |  | 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 SHOULD 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 |
| skipping to change at page 50, line 36 |  | skipping to change at page 50, line 36 |
| Connection = 1#connection-option |  | Connection = 1#connection-option |
| connection-option = token |  | connection-option = token |
| Connection options are case-insensitive. |  | Connection options are case-insensitive. |
| A sender MUST NOT send a connection option corresponding to a header |  | A sender MUST NOT send a connection option corresponding to a header |
| field that is intended for all recipients of the payload. For |  | field that is intended for all recipients of the payload. For |
| example, Cache-Control is never appropriate as a connection option |  | example, Cache-Control is never appropriate as a connection option |
| (Section 5.2 of [Part6]). |  | (Section 5.2 of [Part6]). |
| The connection options do not have to correspond to a header field |  | The connection options do not always correspond to a header field |
| present in the message, since a connection-specific header field |  | present in the message, since a connection-specific header field |
| might not be needed if there are no parameters associated with that |  | might not be needed if there are no parameters associated with a |
| connection option. Recipients that trigger certain connection |  | connection option. In contrast, a connection-specific header field |
| behavior based on the presence of connection options MUST do so based |  | that is received without a corresponding connection option usually |
| on the presence of the connection-option rather than only the |  | indicates that the field has been improperly forwarded by an |
| presence of the optional header field. In other words, if the |  | intermediary and ought to be ignored by the recipient. |
| connection option is received as a header field but not indicated |  |  |
| within the Connection field-value, then the recipient MUST ignore the |  |  |
| connection-specific header field because it has likely been forwarded |  |  |
| by an intermediary that is only partially conformant. |  |  |
| When defining new connection options, specifications ought to |  | When defining new connection options, specification authors ought to |
| carefully consider existing deployed header fields and ensure that |  | survey existing header field names and ensure that the new connection |
| the new connection option does not share the same name as an |  | option does not share the same name as an already deployed header |
| unrelated header field that might already be deployed. Defining a |  | field. Defining a new connection option essentially reserves that |
| new connection option essentially reserves that potential field-name |  | potential field-name for carrying additional information related to |
| for carrying additional information related to the connection option, |  | the connection option, since it would be unwise for senders to use |
| since it would be unwise for senders to use that field-name for |  | that field-name for anything else. |
| anything else. |  |  |
| The "close" connection option is defined for a sender to signal that |  | The "close" connection option is defined for a sender to signal that |
| this connection will be closed after completion of the response. For |  | this connection will be closed after completion of the response. For |
| example, |  | example, |
| Connection: close |  | Connection: close |
| in either the request or the response header fields indicates that |  | in either the request or the response header fields indicates that |
| the sender is going to close the connection after the current |  | the sender is going to close the connection after the current |
| request/response is complete (Section 6.6). |  | request/response is complete (Section 6.6). |
| skipping to change at page 58, line 21 |  | skipping to change at page 58, line 13 |
| of the existing connection; it cannot be used to switch the |  | of the existing connection; it cannot be used to switch the |
| underlying connection (transport) protocol, nor to switch the |  | underlying connection (transport) protocol, nor to switch the |
| existing communication to a different connection. For those |  | existing communication to a different connection. For those |
| purposes, it is more appropriate to use a 3xx (Redirection) response |  | purposes, it is more appropriate to use a 3xx (Redirection) response |
| (Section 6.4 of [Part2]). |  | (Section 6.4 of [Part2]). |
| This specification only defines the protocol name "HTTP" for use by |  | This specification only defines the protocol name "HTTP" for use by |
| the family of Hypertext Transfer Protocols, as defined by the HTTP |  | the family of Hypertext Transfer Protocols, as defined by the HTTP |
| version rules of Section 2.6 and future updates to this |  | version rules of Section 2.6 and future updates to this |
| specification. Additional tokens ought to be registered with IANA |  | specification. Additional tokens ought to be registered with IANA |
| using the registration procedure defined in Section 8.5. |  | 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 comma- |
| delimited lists of elements. The full form is "<n>#<m>element" |  | delimited lists of elements. The full form is "<n>#<m>element" |
| indicating at least <n> and at most <m> elements, each separated by a |  | indicating at least <n> and at most <m> elements, each separated by a |
| single comma (",") and optional whitespace (OWS). |  | single comma (",") and optional whitespace (OWS). |
| skipping to change at page 59, line 37 |  | skipping to change at page 59, line 27 |
| ", ," |  | ", ," |
| Appendix B shows the collected ABNF after the list constructs have |  | Appendix B shows the collected ABNF after the list constructs have |
| been expanded, as described above, for recipients. |  | been expanded, as described above, for recipients. |
| 8. IANA Considerations |  | 8. IANA Considerations |
| 8.1. Header Field Registration |  | 8.1. Header Field Registration |
| HTTP header fields are registered within the Message Header Field |  | HTTP header fields are registered within the Message Header Field |
| Registry maintained at <http://www.iana.org/assignments/ |  | Registry maintained at |
| message-headers/message-header-index.html>. |  | <http://www.iana.org/assignments/message-headers/>. |
| This document defines the following HTTP header fields, so their |  | This document defines the following HTTP header fields, so their |
| associated registry entries shall be updated according to the |  | associated registry entries shall be updated according to the |
| permanent registrations below (see [BCP90]): |  | permanent registrations below (see [BCP90]): |
| +-------------------+----------+----------+---------------+ |  | +-------------------+----------+----------+---------------+ |
| | Header Field Name | Protocol | Status | Reference | |  | | Header Field Name | Protocol | Status | Reference | |
| +-------------------+----------+----------+---------------+ |  | +-------------------+----------+----------+---------------+ |
| | Connection | http | standard | Section 6.1 | |  | | Connection | http | standard | Section 6.1 | |
| | Content-Length | http | standard | Section 3.3.2 | |  | | Content-Length | http | standard | Section 3.3.2 | |
| skipping to change at page 60, line 35 |  | skipping to change at page 60, line 17 |
| +-------------------+----------+----------+-------------+ |  | +-------------------+----------+----------+-------------+ |
| | Close | http | reserved | Section 8.1 | |  | | Close | http | reserved | Section 8.1 | |
| +-------------------+----------+----------+-------------+ |  | +-------------------+----------+----------+-------------+ |
| The change controller is: "IETF (iesg@ietf.org) - Internet |  | The change controller is: "IETF (iesg@ietf.org) - Internet |
| Engineering Task Force". |  | Engineering Task Force". |
| 8.2. URI Scheme Registration |  | 8.2. URI Scheme Registration |
| IANA maintains the registry of URI Schemes [BCP115] at |  | IANA maintains the registry of URI Schemes [BCP115] at |
| <http://www.iana.org/assignments/uri-schemes.html>. |  | <http://www.iana.org/assignments/uri-schemes/>. |
| This document defines the following URI schemes, so their associated |  | This document defines the following URI schemes, so their associated |
| registry entries shall be updated according to the permanent |  | registry entries shall be updated according to the permanent |
| registrations below: |  | registrations below: |
| +------------+------------------------------------+---------------+ |  | +------------+------------------------------------+---------------+ |
| | URI Scheme | Description | Reference | |  | | URI Scheme | Description | Reference | |
| +------------+------------------------------------+---------------+ |  | +------------+------------------------------------+---------------+ |
| | http | Hypertext Transfer Protocol | Section 2.7.1 | |  | | http | Hypertext Transfer Protocol | Section 2.7.1 | |
| | https | Hypertext Transfer Protocol Secure | Section 2.7.2 | |  | | https | Hypertext Transfer Protocol Secure | Section 2.7.2 | |
| +------------+------------------------------------+---------------+ |  | +------------+------------------------------------+---------------+ |
| 8.3. Internet Media Type Registration |  | 8.3. Internet Media Type Registration |
|  |  | IANA maintains the registry of Internet media types [BCP13] at |
|  |  | <http://www.iana.org/assignments/media-types>. |
| This document serves as the specification for the Internet media |  | This document serves as the specification for the Internet media |
| types "message/http" and "application/http". The following is to be |  | types "message/http" and "application/http". The following is to be |
| registered with IANA (see [BCP13]). |  | registered with IANA. |
| 8.3.1. Internet Media Type message/http |  | 8.3.1. Internet Media Type message/http |
| The message/http type can be used to enclose a single HTTP request or |  | The message/http type can be used to enclose a single HTTP request or |
| response message, provided that it obeys the MIME restrictions for |  | response message, provided that it obeys the MIME restrictions for |
| all "message" types regarding line length and encodings. |  | all "message" types regarding line length and encodings. |
| Type name: message |  | Type name: message |
| Subtype name: http |  | Subtype name: http |
| skipping to change at page 64, line 18 |  | skipping to change at page 64, line 5 |
| | chunked | Transfer in a series of chunks | Section 4.1 | |  | | chunked | Transfer in a series of chunks | Section 4.1 | |
| | compress | UNIX "compress" data format [Welch] | Section 4.2.1 | |  | | compress | UNIX "compress" data format [Welch] | Section 4.2.1 | |
| | deflate | "deflate" compressed data | Section 4.2.2 | |  | | deflate | "deflate" compressed data | Section 4.2.2 | |
| | | ([RFC1951]) inside the "zlib" data | | |  | | | ([RFC1951]) inside the "zlib" data | | |
| | | format ([RFC1950]) | | |  | | | format ([RFC1950]) | | |
| | gzip | GZIP file format [RFC1952] | Section 4.2.3 | |  | | gzip | GZIP file format [RFC1952] | Section 4.2.3 | |
| | x-compress | Deprecated (alias for compress) | Section 4.2.1 | |  | | x-compress | Deprecated (alias for compress) | Section 4.2.1 | |
| | x-gzip | Deprecated (alias for gzip) | Section 4.2.3 | |  | | x-gzip | Deprecated (alias for gzip) | Section 4.2.3 | |
| +------------+--------------------------------------+---------------+ |  | +------------+--------------------------------------+---------------+ |
| 8.5. Upgrade Token Registry |  | 8.5. Content Coding Registration |
|  |  | IANA maintains the registry of HTTP Content Codings at |
|  |  | <http://www.iana.org/assignments/http-parameters>. |
|  |  | The HTTP Content Codings Registry shall be updated with the |
|  |  | registrations below: |
|  |  | +------------+--------------------------------------+---------------+ |
|  |  | | Name | Description | Reference | |
|  |  | +------------+--------------------------------------+---------------+ |
|  |  | | compress | UNIX "compress" data format [Welch] | Section 4.2.1 | |
|  |  | | deflate | "deflate" compressed data | Section 4.2.2 | |
|  |  | | | ([RFC1951]) inside the "zlib" data | | |
|  |  | | | format ([RFC1950]) | | |
|  |  | | gzip | GZIP file format [RFC1952] | Section 4.2.3 | |
|  |  | | x-compress | Deprecated (alias for compress) | Section 4.2.1 | |
|  |  | | x-gzip | Deprecated (alias for gzip) | Section 4.2.3 | |
|  |  | +------------+--------------------------------------+---------------+ |
|  |  | 8.6. Upgrade Token Registry |
| The HTTP Upgrade Token Registry defines the name space for protocol- |  | The HTTP Upgrade Token Registry defines the name space for protocol- |
| name tokens used to identify protocols in the Upgrade header field. |  | name tokens used to identify protocols in the Upgrade header field. |
| The registry is maintained at |  | The registry is maintained at |
| <http://www.iana.org/assignments/http-upgrade-tokens>. |  | <http://www.iana.org/assignments/http-upgrade-tokens>. |
| 8.5.1. Procedure |  | 8.6.1. Procedure |
| Each registered protocol name is associated with contact information |  | Each registered protocol name is associated with contact information |
| and an optional set of specifications that details how the connection |  | and an optional set of specifications that details how the connection |
| will be processed after it has been upgraded. |  | will be processed after it has been upgraded. |
| Registrations happen on a "First Come First Served" basis (see |  | Registrations happen on a "First Come First Served" basis (see |
| Section 4.1 of [RFC5226]) and are subject to the following rules: |  | Section 4.1 of [RFC5226]) and are subject to the following rules: |
| 1. A protocol-name token, once registered, stays registered forever. |  | 1. A protocol-name token, once registered, stays registered forever. |
| skipping to change at page 65, line 9 |  | skipping to change at page 65, line 16 |
| The IANA will keep a record of all such changes, and make them |  | The IANA will keep a record of all such changes, and make them |
| available upon request. |  | available upon request. |
| 7. The IESG MAY reassign responsibility for a protocol token. This |  | 7. The IESG MAY reassign responsibility for a protocol token. This |
| will normally only be used in the case when a responsible party |  | will normally only be used in the case when a responsible party |
| cannot be contacted. |  | cannot be contacted. |
| This registration procedure for HTTP Upgrade Tokens replaces that |  | This registration procedure for HTTP Upgrade Tokens replaces that |
| previously defined in Section 7.2 of [RFC2817]. |  | previously defined in Section 7.2 of [RFC2817]. |
| 8.5.2. Upgrade Token Registration |  | 8.6.2. Upgrade Token Registration |
| The HTTP Upgrade Token Registry shall be updated with the |  | The "HTTP" entry in the HTTP Upgrade Token Registry shall be updated |
| registration below: |  | with the registration below: |
| +-------+----------------------+----------------------+-------------+ |  | +-------+----------------------+----------------------+-------------+ |
| | Value | Description | Expected Version | Reference | |  | | Value | Description | Expected Version | Reference | |
| | | | Tokens | | |  | | | | Tokens | | |
| +-------+----------------------+----------------------+-------------+ |  | +-------+----------------------+----------------------+-------------+ |
| | HTTP | Hypertext Transfer | any DIGIT.DIGIT | Section 2.6 | |  | | HTTP | Hypertext Transfer | any DIGIT.DIGIT | Section 2.6 | |
| | | Protocol | (e.g, "2.0") | | |  | | | Protocol | (e.g, "2.0") | | |
| +-------+----------------------+----------------------+-------------+ |  | +-------+----------------------+----------------------+-------------+ |
| The responsible party is: "IETF (iesg@ietf.org) - Internet |  | The responsible party is: "IETF (iesg@ietf.org) - Internet |
| skipping to change at page 68, line 13 |  | skipping to change at page 68, line 23 |
| group chair. |  | group chair. |
| Since 1999, the following contributors have helped improve the HTTP |  | Since 1999, the following contributors have helped improve the HTTP |
| specification by reporting bugs, asking smart questions, drafting or |  | specification by reporting bugs, asking smart questions, drafting or |
| reviewing text, and evaluating open issues: |  | reviewing text, and evaluating open issues: |
| Adam Barth, Adam Roach, Addison Phillips, Adrian Chadd, Adrien W. de |  | Adam Barth, Adam Roach, Addison Phillips, Adrian Chadd, Adrien W. de |
| Croy, Alan Ford, Alan Ruttenberg, Albert Lunde, Alek Storm, Alex |  | Croy, Alan Ford, Alan Ruttenberg, Albert Lunde, Alek Storm, Alex |
| Rousskov, Alexandre Morgaut, Alexey Melnikov, Alisha Smith, Amichai |  | Rousskov, Alexandre Morgaut, Alexey Melnikov, Alisha Smith, Amichai |
| Rothman, Amit Klein, Amos Jeffries, Andreas Maier, Andreas Petersson, |  | Rothman, Amit Klein, Amos Jeffries, Andreas Maier, Andreas Petersson, |
| Anil Sharma, Anne van Kesteren, Anthony Bryan, Asbjorn Ulsberg, Ashok |  | Andrei Popov, Anil Sharma, Anne van Kesteren, Anthony Bryan, Asbjorn |
| Kumar, Balachander Krishnamurthy, Barry Leiba, Ben Laurie, Benjamin |  | Ulsberg, Ashok Kumar, Balachander Krishnamurthy, Barry Leiba, Ben |
| Carlyle, Benjamin Niven-Jenkins, Bil Corry, Bill Burke, Bjoern |  | Laurie, Benjamin Carlyle, Benjamin Niven-Jenkins, Bil Corry, Bill |
| Hoehrmann, Bob Scheifler, Boris Zbarsky, Brett Slatkin, Brian Kell, |  | Burke, Bjoern Hoehrmann, Bob Scheifler, Boris Zbarsky, Brett Slatkin, |
| Brian McBarron, Brian Pane, Brian Raymor, Brian Smith, Bryce Nesbitt, |  | Brian Kell, Brian McBarron, Brian Pane, Brian Raymor, Brian Smith, |
| Cameron Heavon-Jones, Carl Kugler, Carsten Bormann, Charles Fry, |  | Bryce Nesbitt, Cameron Heavon-Jones, Carl Kugler, Carsten Bormann, |
| Chris Newman, Cyrus Daboo, Dale Robert Anderson, Dan Wing, Dan |  | Charles Fry, Chris Newman, Cyrus Daboo, Dale Robert Anderson, Dan |
| Winship, Daniel Stenberg, Darrel Miller, Dave Cridland, Dave Crocker, |  | Wing, Dan Winship, Daniel Stenberg, Darrel Miller, Dave Cridland, |
| Dave Kristol, Dave Thaler, David Booth, David Singer, David W. |  | Dave Crocker, Dave Kristol, Dave Thaler, David Booth, David Singer, |
| Morris, Diwakar Shetty, Dmitry Kurochkin, Drummond Reed, Duane |  | David W. Morris, Diwakar Shetty, Dmitry Kurochkin, Drummond Reed, |
| Wessels, Edward Lee, Eitan Adler, Eliot Lear, Eran Hammer-Lahav, Eric |  | Duane Wessels, Edward Lee, Eitan Adler, Eliot Lear, Emile Stephan, |
| D. Williams, Eric J. Bowman, Eric Lawrence, Eric Rescorla, Erik |  | Eran Hammer-Lahav, Eric D. Williams, Eric J. Bowman, Eric Lawrence, |
| Aronesty, Evan Prodromou, Felix Geisendoerfer, Florian Weimer, Frank |  | Eric Rescorla, Erik Aronesty, EungJun Yi, Evan Prodromou, Felix |
| Ellermann, Fred Akalin, Fred Bohle, Frederic Kayser, Gabor Molnar, |  | Geisendoerfer, Florian Weimer, Frank Ellermann, Fred Akalin, Fred |
| Gabriel Montenegro, Geoffrey Sneddon, Gervase Markham, Gili Tzabari, |  | Bohle, Frederic Kayser, Gabor Molnar, Gabriel Montenegro, Geoffrey |
| Grahame Grieve, Greg Wilkins, Grzegorz Calkowski, Harald Tveit |  | Sneddon, Gervase Markham, Gili Tzabari, Grahame Grieve, Greg Wilkins, |
| Alvestrand, Harry Halpin, Helge Hess, Henrik Nordstrom, Henry S. |  | Grzegorz Calkowski, Harald Tveit Alvestrand, Harry Halpin, Helge |
| Thompson, Henry Story, Herbert van de Sompel, Herve Ruellan, Howard |  | Hess, Henrik Nordstrom, Henry S. Thompson, Henry Story, Herbert van |
| Melman, Hugo Haas, Ian Fette, Ian Hickson, Ido Safruti, Ilari |  | de Sompel, Herve Ruellan, Howard Melman, Hugo Haas, Ian Fette, Ian |
| Liusvaara, Ilya Grigorik, Ingo Struck, J. Ross Nicoll, James Cloos, |  | Hickson, Ido Safruti, Ilari Liusvaara, Ilya Grigorik, Ingo Struck, J. |
| James H. Manger, James Lacey, James M. Snell, Jamie Lokier, Jan |  | Ross Nicoll, James Cloos, James H. Manger, James Lacey, James M. |
| Algermissen, Jeff Hodges (who came up with the term 'effective |  | Snell, Jamie Lokier, Jan Algermissen, Jeff Hodges (who came up with |
| Request-URI'), Jeff Pinner, Jeff Walden, Jim Luther, Jitu Padhye, Joe |  | the term 'effective Request-URI'), Jeff Pinner, Jeff Walden, Jim |
| D. Williams, Joe Gregorio, Joe Orton, John C. Klensin, John C. |  | Luther, Jitu Padhye, Joe D. Williams, Joe Gregorio, Joe Orton, John |
| Mallery, John Cowan, John Kemp, John Panzer, John Schneider, John |  | C. Klensin, John C. Mallery, John Cowan, John Kemp, John Panzer, John |
| Stracke, John Sullivan, Jonas Sicking, Jonathan A. Rees, Jonathan |  | Schneider, John Stracke, John Sullivan, Jonas Sicking, Jonathan A. |
| Billington, Jonathan Moore, Jonathan Silvera, Jordi Ros, Joris |  | Rees, Jonathan Billington, Jonathan Moore, Jonathan Silvera, Jordi |
| Dobbelsteen, Josh Cohen, Julien Pierre, Jungshik Shin, Justin |  | Ros, Joris Dobbelsteen, Josh Cohen, Julien Pierre, Jungshik Shin, |
| Chapweske, Justin Erenkrantz, Justin James, Kalvinder Singh, Karl |  | Justin Chapweske, Justin Erenkrantz, Justin James, Kalvinder Singh, |
| Dubost, Keith Hoffman, Keith Moore, Ken Murchison, Koen Holtman, |  | Karl Dubost, Keith Hoffman, Keith Moore, Ken Murchison, Koen Holtman, |
| Konstantin Voronkov, Kris Zyp, Lisa Dusseault, Maciej Stachowiak, |  | Konstantin Voronkov, Kris Zyp, Leif Hedstrom, Lisa Dusseault, Maciej |
| Manu Sporny, Marc Schneider, Marc Slemko, Mark Baker, Mark Pauley, |  | Stachowiak, Manu Sporny, Marc Schneider, Marc Slemko, Mark Baker, |
| Mark Watson, Markus Isomaki, Markus Lanthaler, Martin J. Duerst, |  | Mark Pauley, Mark Watson, Markus Isomaki, Markus Lanthaler, Martin J. |
| Martin Musatov, Martin Nilsson, Martin Thomson, Matt Lynch, Matthew |  | Duerst, Martin Musatov, Martin Nilsson, Martin Thomson, Matt Lynch, |
| Cox, Max Clark, Michael Burrows, Michael Hausenblas, Michael Sweet, |  | Matthew Cox, Max Clark, Michael Burrows, Michael Hausenblas, Michael |
| Michael Tuexen, Michael Welzl, Mike Amundsen, Mike Belshe, Mike |  | Scharf, Michael Sweet, Michael Tuexen, Michael Welzl, Mike Amundsen, |
| Bishop, Mike Kelly, Mike Schinkel, Miles Sabin, Murray S. Kucherawy, |  | Mike Belshe, Mike Bishop, Mike Kelly, Mike Schinkel, Miles Sabin, |
| Mykyta Yevstifeyev, Nathan Rixham, Nicholas Shanks, Nico Williams, |  | Murray S. Kucherawy, Mykyta Yevstifeyev, Nathan Rixham, Nicholas |
| Nicolas Alvarez, Nicolas Mailhot, Noah Slater, Osama Mazahir, Pablo |  | Shanks, Nico Williams, Nicolas Alvarez, Nicolas Mailhot, Noah Slater, |
| Castro, Pat Hayes, Patrick R. McManus, Paul E. Jones, Paul Hoffman, |  | Osama Mazahir, Pablo Castro, Pat Hayes, Patrick R. McManus, Paul E. |
| Paul Marquess, Peter Lepeska, Peter Occil, Peter Saint-Andre, Peter |  | Jones, Paul Hoffman, Paul Marquess, Peter Lepeska, Peter Occil, Peter |
| Watkins, Phil Archer, Philippe Mougin, Phillip Hallam-Baker, Piotr |  | Saint-Andre, Peter Watkins, Phil Archer, Philippe Mougin, Phillip |
| Dobrogost, Poul-Henning Kamp, Preethi Natarajan, Rajeev Bector, Ray |  | Hallam-Baker, Piotr Dobrogost, Poul-Henning Kamp, Preethi Natarajan, |
| Polk, Reto Bachmann-Gmuer, Richard Cyganiak, Robby Simpson, Robert |  | Rajeev Bector, Ray Polk, Reto Bachmann-Gmuer, Richard Cyganiak, Robby |
| Brewer, Robert Collins, Robert Mattson, Robert O'Callahan, Robert |  | Simpson, Robert Brewer, Robert Collins, Robert Mattson, Robert |
| Olofsson, Robert Sayre, Robert Siemer, Robert de Wilde, Roberto |  | O'Callahan, Robert Olofsson, Robert Sayre, Robert Siemer, Robert de |
| Javier Godoy, Roberto Peon, Roland Zink, Ronny Widjaja, Ryan |  | Wilde, Roberto Javier Godoy, Roberto Peon, Roland Zink, Ronny |
| Hamilton, S. Mike Dierken, Salvatore Loreto, Sam Johnston, Sam |  | Widjaja, Ryan Hamilton, S. Mike Dierken, Salvatore Loreto, Sam |
| Pullara, Sam Ruby, Scott Lawrence (who maintained the original issues |  | Johnston, Sam Pullara, Sam Ruby, Saurabh Kulkarni, Scott Lawrence |
| list), Sean B. Palmer, Sebastien Barnoud, Shane McCarron, Shigeki |  | (who maintained the original issues list), Sean B. Palmer, Sebastien |
| Ohtsu, Stefan Eissing, Stefan Tilkov, Stefanos Harhalakis, Stephane |  | Barnoud, Shane McCarron, Shigeki Ohtsu, Stefan Eissing, Stefan |
| Bortzmeyer, Stephen Farrell, Stephen Ludin, Stuart Williams, Subbu |  | Tilkov, Stefanos Harhalakis, Stephane Bortzmeyer, Stephen Farrell, |
| Allamaraju, Sylvain Hellegouarch, Tapan Divekar, Tatsuhiro Tsujikawa, |  | Stephen Ludin, Stuart Williams, Subbu Allamaraju, Subramanian |
|  |  | Moonesamy, Sylvain Hellegouarch, Tapan Divekar, Tatsuhiro Tsujikawa, |
| Tatsuya Hayashi, Ted Hardie, Thomas Broyer, Thomas Fossati, Thomas |  | Tatsuya Hayashi, Ted Hardie, Thomas Broyer, Thomas Fossati, Thomas |
| Maslen, Thomas Nordin, Thomas Roessler, Tim Bray, Tim Morgan, Tim |  | Maslen, Thomas Nordin, Thomas Roessler, Tim Bray, Tim Morgan, Tim |
| Olsen, Tom Zhou, Travis Snoozy, Tyler Close, Vincent Murphy, Wenbo |  | Olsen, Tom Zhou, Travis Snoozy, Tyler Close, Vincent Murphy, Wenbo |
| Zhu, Werner Baumann, Wilbur Streett, Wilfredo Sanchez Vega, William |  | Zhu, Werner Baumann, Wilbur Streett, Wilfredo Sanchez Vega, William |
| A. Rowe Jr., William Chan, Willy Tarreau, Xiaoshu Wang, Yaron Goland, |  | A. Rowe Jr., William Chan, Willy Tarreau, Xiaoshu Wang, Yaron Goland, |
| Yngve Nysaeter Pettersen, Yoav Nir, Yogesh Bang, Yuchung Cheng, |  | Yngve Nysaeter Pettersen, Yoav Nir, Yogesh Bang, Yuchung Cheng, |
| Yutaka Oiwa, Yves Lafon (long-time member of the editor team), Zed A. |  | Yutaka Oiwa, Yves Lafon (long-time member of the editor team), Zed A. |
| Shaw, and Zhong Yu. |  | Shaw, and Zhong Yu. |
| See Section 16 of [RFC2616] for additional acknowledgements from |  | See Section 16 of [RFC2616] for additional acknowledgements from |
| prior revisions. |  | prior revisions. |
| 11. References |  | 11. References |
| 11.1. Normative References |  | 11.1. Normative References |
| [Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext |  | [Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext |
| Transfer Protocol (HTTP/1.1): Semantics and Content", |  | Transfer Protocol (HTTP/1.1): Semantics and Content", |
| draft-ietf-httpbis-p2-semantics-24 (work in progress), |  | draft-ietf-httpbis-p2-semantics-25 (work in progress), |
| September 2013. |  | November 2013. |
| [Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext |  | [Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext |
| Transfer Protocol (HTTP/1.1): Conditional Requests", |  | Transfer Protocol (HTTP/1.1): Conditional Requests", |
| draft-ietf-httpbis-p4-conditional-24 (work in |  | draft-ietf-httpbis-p4-conditional-25 (work in |
| progress), September 2013. |  | progress), November 2013. |
| [Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |  | [Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |
| "Hypertext Transfer Protocol (HTTP/1.1): Range |  | "Hypertext Transfer Protocol (HTTP/1.1): Range |
| Requests", draft-ietf-httpbis-p5-range-24 (work in |  | Requests", draft-ietf-httpbis-p5-range-25 (work in |
| progress), September 2013. |  | progress), November 2013. |
| [Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, |  | [Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, |
| Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", |  | Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", |
| draft-ietf-httpbis-p6-cache-24 (work in progress), |  | draft-ietf-httpbis-p6-cache-25 (work in progress), |
| September 2013. |  | November 2013. |
| [Part7] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext |  | [Part7] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext |
| Transfer Protocol (HTTP/1.1): Authentication", |  | Transfer Protocol (HTTP/1.1): Authentication", |
| draft-ietf-httpbis-p7-auth-24 (work in progress), |  | draft-ietf-httpbis-p7-auth-25 (work in progress), |
| September 2013. |  | November 2013. |
| [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, |  | [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, |
| RFC 793, September 1981. |  | RFC 793, September 1981. |
| [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data |  | [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data |
| Format Specification version 3.3", RFC 1950, May 1996. |  | Format Specification version 3.3", RFC 1950, May 1996. |
| [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format |  | [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format |
| Specification version 1.3", RFC 1951, May 1996. |  | Specification version 1.3", RFC 1951, May 1996. |
| skipping to change at page 76, line 35 |  | skipping to change at page 76, line 47 |
| other than 101 (this was incorporated from [RFC2817]). Furthermore, |  | other than 101 (this was incorporated from [RFC2817]). Furthermore, |
| the ordering in the field value is now significant. (Section 6.7) |  | the ordering in the field value is now significant. (Section 6.7) |
| Empty list elements in list productions (e.g., a list header field |  | Empty list elements in list productions (e.g., a list header field |
| containing ", ,") have been deprecated. (Section 7) |  | containing ", ,") have been deprecated. (Section 7) |
| Registration of Transfer Codings now requires IETF Review |  | Registration of Transfer Codings now requires IETF Review |
| (Section 8.4) |  | (Section 8.4) |
| This specification now defines the Upgrade Token Registry, previously |  | This specification now defines the Upgrade Token Registry, previously |
| defined in Section 7.2 of [RFC2817]. (Section 8.5) |  | defined in Section 7.2 of [RFC2817]. (Section 8.6) |
| The expectation to support HTTP/0.9 requests has been removed. |  | The expectation to support HTTP/0.9 requests has been removed. |
| (Appendix A) |  | (Appendix A) |
| Issues with the Keep-Alive and Proxy-Connection header fields in |  | Issues with the Keep-Alive and Proxy-Connection header fields in |
| requests are pointed out, with use of the latter being discouraged |  | requests are pointed out, with use of the latter being discouraged |
| altogether. (Appendix A.1.2) |  | altogether. (Appendix A.1.2) |
| Appendix B. Collected ABNF |  | Appendix B. Collected ABNF |
| BWS = OWS |  | BWS = OWS |
| Connection = *( "," OWS ) connection-option *( OWS "," [ OWS |  | Connection = *( "," OWS ) connection-option *( OWS "," [ OWS |
| connection-option ] ) |  | connection-option ] ) |
| skipping to change at page 79, line 28 |  | skipping to change at page 79, line 41 |
| uri-host = <host, defined in [RFC3986], Section 3.2.2> |  | uri-host = <host, defined in [RFC3986], Section 3.2.2> |
| value = word |  | value = word |
| word = token / quoted-string |  | word = token / quoted-string |
| Appendix C. Change Log (to be removed by RFC Editor before publication) |  | Appendix C. Change Log (to be removed by RFC Editor before publication) |
| C.1. Since RFC 2616 |  | C.1. Since RFC 2616 |
| Changes up to the first Working Group Last Call draft are summarized |  | Changes up to the IETF Last Call draft are summarized in <http:// |
| in <http://trac.tools.ietf.org/html/ |  | trac.tools.ietf.org/html/ |
| draft-ietf-httpbis-p1-messaging-21#appendix-D>. |  | draft-ietf-httpbis-p1-messaging-24#appendix-C>. |
| C.2. Since draft-ietf-httpbis-p1-messaging-21 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/128>: "Cite HTTPS |  |  |
| URI scheme definition" (the spec now includes the HTTPs scheme |  |  |
| definition and thus updates RFC 2818) |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/389>: "mention of |  |  |
| 'proxies' in section about caches" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/390>: "use of ABNF |  |  |
| terms from RFC 3986" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/391>: "transferring |  |  |
| URIs with userinfo in payload" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/392>: "editorial |  |  |
| improvements to message length definition" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/395>: "Connection |  |  |
| header field MUST vs SHOULD" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/396>: "editorial |  |  |
| improvements to persistent connections section" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/397>: "URI |  |  |
| normalization vs empty path" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/408>: "p1 feedback" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/409>: "is parsing |  |  |
| OBS-FOLD mandatory?" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/410>: "HTTPS and |  |  |
| Shared Caching" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/411>: "Requirements |  |  |
| for recipients of ws between start-line and first header field" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/412>: "SP and HT |  |  |
| when being tolerant" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/414>: "Message |  |  |
| Parsing Strictness" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/415>: "'Render'" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/418>: "No-Transform" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/419>: "p2 editorial |  |  |
| feedback" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/420>: "Content- |  |  |
| Length SHOULD be sent" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/431>: "origin-form |  |  |
| does not allow path starting with "//"" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/433>: "ambiguity in |  |  |
| part 1 example" |  |  |
| C.3. Since draft-ietf-httpbis-p1-messaging-22 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/435>: "Part1 should |  |  |
| have a reference to TCP (RFC 793)" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/438>: "media type |  |  |
| registration template issues" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/441>: P1 editorial |  |  |
| nits |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/442>: "BWS" (vs |  |  |
| conformance) |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/444>: "obs-fold |  |  |
| language" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/445>: "Ordering in |  |  |
| Upgrade" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/446>: "p1 editorial |  |  |
| feedback" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/447>: "HTTP and TCP |  |  |
| name delegation" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/449>: "Receiving a |  |  |
| higher minor HTTP version number" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/451>: "HTTP(S) URIs |  |  |
| and fragids" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/457>: "Registering |  |  |
| x-gzip and x-deflate" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/460>: "Via and |  |  |
| gateways" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/465>: "Mention 203 |  |  |
| Non-Authoritative Information in p1" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/476>: "SHOULD and |  |  |
| conformance" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/477>: "Pipelining |  |  |
| language" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/482>: "proxy |  |  |
| handling of a really bad Content-Length" |  |  |
| C.4. Since draft-ietf-httpbis-p1-messaging-23 |  | C.2. Since draft-ietf-httpbis-p1-messaging-24 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/343>: "chunk- |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/502>: "APPSDIR |
| extensions" (un-deprecated and explained) |  | review of draft-ietf-httpbis-p1-messaging-24" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/483>: "MUST fix |  |  |
| Content-Length?" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/492>: "list notation |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/507>: "integer value |
| defined in appendix" |  | parsing" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/497>: "Fine-Tuning |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/517>: "move IANA |
| when Upgrade takes effect" |  | registrations to correct draft" |
| Index |  | Index |
| A |  | A |
| absolute-form (of request-target) 42 |  | absolute-form (of request-target) 42 |
| accelerator 10 |  | accelerator 10 |
| application/http Media Type 62 |  | application/http Media Type 61 |
| asterisk-form (of request-target) 42 |  | asterisk-form (of request-target) 42 |
| authority-form (of request-target) 42 |  | authority-form (of request-target) 42 |
| B |  | B |
| browser 7 |  | browser 7 |
| C |  | C |
| cache 11 |  | cache 11 |
| cacheable 12 |  | cacheable 12 |
| captive portal 11 |  | captive portal 11 |
| skipping to change at page 85, line 20 |  | skipping to change at page 83, line 10 |
| http URI scheme 17 |  | http URI scheme 17 |
| https URI scheme 18 |  | https URI scheme 18 |
| 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 61 |
| message/http 61 |  | message/http 60 |
| message 7 |  | message 7 |
| message/http Media Type 61 |  | message/http Media Type 60 |
| method 21 |  | method 21 |
| N |  | N |
| non-transforming proxy 10 |  | non-transforming proxy 10 |
| O |  | O |
| origin server 7 |  | origin server 7 |
| origin-form (of request-target) 41 |  | origin-form (of request-target) 41 |
| outbound 9 |  | outbound 9 |
End of changes. 44 change blocks.
| 258 lines changed or deleted |  | 158 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/