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/