p1-messaging.unpg.txt   rfc7230-to-be.unpg.txt 
HTTPbis Working Group R. Fielding, Ed. Internet Engineering Task Force (IETF) R. Fielding, Ed.
Internet-Draft Adobe Request for Comments: 7230 Adobe
Obsoletes: 2145, 2616 J. Reschke, Ed. Obsoletes: 2145, 2616 J. Reschke, Ed.
(if approved) greenbytes Updates: 2817, 2818 greenbytes
Updates: 2817, 2818 (if approved) May 6, 2014 Category: Standards Track May 2014
Intended status: Standards Track ISSN: 2070-1721
Expires: November 7, 2014
Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
draft-ietf-httpbis-p1-messaging-latest
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is a stateless application- The Hypertext Transfer Protocol (HTTP) is a stateless application-
level protocol for distributed, collaborative, hypertext information level protocol for distributed, collaborative, hypertext information
systems. This document provides an overview of HTTP architecture and systems. This document provides an overview of HTTP architecture and
its associated terminology, defines the "http" and "https" Uniform its associated terminology, defines the "http" and "https" Uniform
Resource Identifier (URI) schemes, defines the HTTP/1.1 message Resource Identifier (URI) schemes, defines the HTTP/1.1 message
syntax and parsing requirements, and describes related security syntax and parsing requirements, and describes related security
concerns for implementations. concerns for implementations.
Editorial Note (To be removed by RFC Editor)
Discussion of this draft takes place on the HTTPBIS working group
mailing list (ietf-http-wg@w3.org), which is archived at
<http://lists.w3.org/Archives/Public/ietf-http-wg/>.
The current issues list is at
<http://tools.ietf.org/wg/httpbis/trac/report/3> and related
documents (including fancy diffs) can be found at
<http://tools.ietf.org/wg/httpbis/>.
_This is a temporary document for the purpose of tracking the
editorial changes made during the AUTH48 (RFC publication) phase._
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on November 7, 2014. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7230.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 4 skipping to change at page 3, line 32
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 . . . . . . . . . . . . . . . . . . . . . . . . . 47 5.7.1. Via . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.7.2. Transformations . . . . . . . . . . . . . . . . . . . 48 5.7.2. Transformations . . . . . . . . . . . . . . . . . . . 48
6. Connection Management . . . . . . . . . . . . . . . . . . . . 49 6. Connection Management . . . . . . . . . . . . . . . . . . . . 49
6.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 50 6.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 50
6.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 51 6.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 51
6.3. Persistence . . . . . . . . . . . . . . . . . . . . . . . 52 6.3. Persistence . . . . . . . . . . . . . . . . . . . . . . . 52
6.3.1. Retrying Requests . . . . . . . . . . . . . . . . . . 53 6.3.1. Retrying Requests . . . . . . . . . . . . . . . . . . 53
6.3.2. Pipelining . . . . . . . . . . . . . . . . . . . . . . 53 6.3.2. Pipelining . . . . . . . . . . . . . . . . . . . . . . 53
6.4. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 54 6.4. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 54
6.5. Failures and Timeouts . . . . . . . . . . . . . . . . . . 54 6.5. Failures and Timeouts . . . . . . . . . . . . . . . . . . 54
6.6. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 55 6.6. Teardown . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.7. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 56 6.7. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 56
7. ABNF List Extension: #rule . . . . . . . . . . . . . . . . . . 58 7. ABNF List Extension: #rule . . . . . . . . . . . . . . . . . . 58
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 60 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 60
8.1. Header Field Registration . . . . . . . . . . . . . . . . 60 8.1. Header Field Registration . . . . . . . . . . . . . . . . 60
8.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 60 8.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 60
8.3. Internet Media Type Registration . . . . . . . . . . . . . 61 8.3. Internet Media Type Registration . . . . . . . . . . . . . 61
8.3.1. Internet Media Type message/http . . . . . . . . . . . 61 8.3.1. Internet Media Type message/http . . . . . . . . . . . 61
8.3.2. Internet Media Type application/http . . . . . . . . . 62 8.3.2. Internet Media Type application/http . . . . . . . . . 62
8.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 63 8.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 63
8.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 63 8.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 63
skipping to change at page 4, line 37 skipping to change at page 4, line 16
9.4. Response Splitting . . . . . . . . . . . . . . . . . . . . 68 9.4. Response Splitting . . . . . . . . . . . . . . . . . . . . 68
9.5. Request Smuggling . . . . . . . . . . . . . . . . . . . . 69 9.5. Request Smuggling . . . . . . . . . . . . . . . . . . . . 69
9.6. Message Integrity . . . . . . . . . . . . . . . . . . . . 69 9.6. Message Integrity . . . . . . . . . . . . . . . . . . . . 69
9.7. Message Confidentiality . . . . . . . . . . . . . . . . . 70 9.7. Message Confidentiality . . . . . . . . . . . . . . . . . 70
9.8. Privacy of Server Log Information . . . . . . . . . . . . 70 9.8. Privacy of Server Log Information . . . . . . . . . . . . 70
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 71 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 71
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 72 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 72
11.1. Normative References . . . . . . . . . . . . . . . . . . . 72 11.1. Normative References . . . . . . . . . . . . . . . . . . . 72
11.2. Informative References . . . . . . . . . . . . . . . . . . 74 11.2. Informative References . . . . . . . . . . . . . . . . . . 74
Appendix A. HTTP Version History . . . . . . . . . . . . . . . . 76 Appendix A. HTTP Version History . . . . . . . . . . . . . . . . 76
A.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 77 A.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 76
A.1.1. Multi-homed Web Servers . . . . . . . . . . . . . . . 77 A.1.1. Multihomed Web Servers . . . . . . . . . . . . . . . . 77
A.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 77 A.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 77
A.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 78 A.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 78
A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 78 A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 78
Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 80 Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 80
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
1. Introduction 1. Introduction
The Hypertext Transfer Protocol (HTTP) is a stateless application- The Hypertext Transfer Protocol (HTTP) is a stateless application-
level request/response protocol that uses extensible semantics and level request/response protocol that uses extensible semantics and
skipping to change at page 5, line 26 skipping to change at page 5, line 26
RFC 7231: Semantics and Content RFC 7231: Semantics and Content
RFC 7232: Conditional Requests RFC 7232: Conditional Requests
RFC 7233: Range Requests RFC 7233: Range Requests
RFC 7234: Caching RFC 7234: Caching
RFC 7235: Authentication RFC 7235: Authentication
This HTTP/1.1 specification obsoletes RFC 2616 and RFC 2145 (on HTTP This HTTP/1.1 specification obsoletes [RFC2616] and [RFC2145] (on
versioning). This specification also updates the use of CONNECT to HTTP versioning). This specification also updates the use of
establish a tunnel, previously defined in RFC 2817, and defines the CONNECT, previously defined in RFC 2817, to establish a tunnel, and
"https" URI scheme that was described informally in RFC 2818. defines the "https" URI scheme that was described informally in RFC
2818.
HTTP is a generic interface protocol for information systems. It is HTTP is a generic interface protocol for information systems. It is
designed to hide the details of how a service is implemented by designed to hide the details of how a service is implemented by
presenting a uniform interface to clients that is independent of the presenting a uniform interface to clients that is independent of the
types of resources provided. Likewise, servers do not need to be types of resources provided. Likewise, servers do not need to be
aware of each client's purpose: an HTTP request can be considered in aware of each client's purpose: an HTTP request can be considered in
isolation rather than being associated with a specific type of client isolation rather than being associated with a specific type of client
or a predetermined sequence of application steps. The result is a or a predetermined sequence of application steps. The result is a
protocol that can be used effectively in many different contexts and protocol that can be used effectively in many different contexts and
for which implementations can evolve independently over time. for which implementations can evolve independently over time.
skipping to change at page 7, line 8 skipping to change at page 7, line 9
2. Architecture 2. Architecture
HTTP was created for the World Wide Web (WWW) architecture and has HTTP was created for the World Wide Web (WWW) architecture and has
evolved over time to support the scalability needs of a worldwide evolved over time to support the scalability needs of a worldwide
hypertext system. Much of that architecture is reflected in the hypertext system. Much of that architecture is reflected in the
terminology and syntax productions used to define HTTP. terminology and syntax productions used to define HTTP.
2.1. Client/Server Messaging 2.1. Client/Server Messaging
HTTP is a stateless request/response protocol that operates by HTTP is a stateless request/response protocol that operates by
exchanging messages (Section 3) across a reliable transport or exchanging messages (Section 3) across a reliable transport- or
session-layer "connection" (Section 6). An HTTP "client" is a session-layer "connection" (Section 6). An HTTP "client" is a
program that establishes a connection to a server for the purpose of program that establishes a connection to a server for the purpose of
sending one or more HTTP requests. An HTTP "server" is a program sending one or more HTTP requests. An HTTP "server" is a program
that accepts connections in order to service HTTP requests by sending that accepts connections in order to service HTTP requests by sending
HTTP responses. HTTP responses.
The terms "client" and "server" refer only to the roles that these The terms "client" and "server" refer only to the roles that these
programs perform for a particular connection. The same program might programs perform for a particular connection. The same program might
act as a client on some connections and a server on others. The term act as a client on some connections and a server on others. The term
"user agent" refers to any of the various client programs that "user agent" refers to any of the various client programs that
skipping to change at page 10, line 36 skipping to change at page 10, line 39
Gateways are often used to encapsulate legacy or untrusted Gateways are often used to encapsulate legacy or untrusted
information services, to improve server performance through information services, to improve server performance through
"accelerator" caching, and to enable partitioning or load balancing "accelerator" caching, and to enable partitioning or load balancing
of HTTP services across multiple machines. of HTTP services across multiple machines.
All HTTP requirements applicable to an origin server also apply to All HTTP requirements applicable to an origin server also apply to
the outbound communication of a gateway. A gateway communicates with the outbound communication of a gateway. A gateway communicates with
inbound servers using any protocol that it desires, including private inbound servers using any protocol that it desires, including private
extensions to HTTP that are outside the scope of this specification. extensions to HTTP that are outside the scope of this specification.
However, an HTTP-to-HTTP gateway that wishes to interoperate with However, an HTTP-to-HTTP gateway that wishes to interoperate with
third-party HTTP servers ought to conform to user agent requirements third-party HTTP servers ought to conform to user-agent requirements
on the gateway's inbound connection. on the gateway's inbound connection.
A "tunnel" acts as a blind relay between two connections without A "tunnel" acts as a blind relay between two connections without
changing the messages. Once active, a tunnel is not considered a changing the messages. Once active, a tunnel is not considered a
party to the HTTP communication, though the tunnel might have been party to the HTTP communication, though the tunnel might have been
initiated by an HTTP request. A tunnel ceases to exist when both initiated by an HTTP request. A tunnel ceases to exist when both
ends of the relayed connection are closed. Tunnels are used to ends of the relayed connection are closed. Tunnels are used to
extend a virtual connection through an intermediary, such as when extend a virtual connection through an intermediary, such as when
Transport Layer Security (TLS, [RFC5246]) is used to establish Transport Layer Security (TLS, [RFC5246]) is used to establish
confidential communication through a shared firewall proxy. confidential communication through a shared firewall proxy.
skipping to change at page 11, line 22 skipping to change at page 11, line 25
interception proxy filters or redirects outgoing TCP port 80 packets interception proxy filters or redirects outgoing TCP port 80 packets
(and occasionally other common port traffic). Interception proxies (and occasionally other common port traffic). Interception proxies
are commonly found on public network access points, as a means of are commonly found on public network access points, as a means of
enforcing account subscription prior to allowing use of non-local enforcing account subscription prior to allowing use of non-local
Internet services, and within corporate firewalls to enforce network Internet services, and within corporate firewalls to enforce network
usage policies. usage policies.
HTTP is defined as a stateless protocol, meaning that each request HTTP is defined as a stateless protocol, meaning that each request
message can be understood in isolation. Many implementations depend message can be understood in isolation. Many implementations depend
on HTTP's stateless design in order to reuse proxied connections or on HTTP's stateless design in order to reuse proxied connections or
dynamically load-balance requests across multiple servers. Hence, a dynamically load balance requests across multiple servers. Hence, a
server MUST NOT assume that two requests on the same connection are server MUST NOT assume that two requests on the same connection are
from the same user agent unless the connection is secured and from the same user agent unless the connection is secured and
specific to that agent. Some non-standard HTTP extensions (e.g., specific to that agent. Some non-standard HTTP extensions (e.g.,
[RFC4559]) have been known to violate this requirement, resulting in [RFC4559]) have been known to violate this requirement, resulting in
security and interoperability problems. security and interoperability problems.
2.4. Caches 2.4. Caches
A "cache" is a local store of previous response messages and the A "cache" is a local store of previous response messages and the
subsystem that controls its message storage, retrieval, and deletion. subsystem that controls its message storage, retrieval, and deletion.
skipping to change at page 13, line 49 skipping to change at page 14, line 4
2.6. Protocol Versioning 2.6. Protocol Versioning
HTTP uses a "<major>.<minor>" numbering scheme to indicate versions HTTP uses a "<major>.<minor>" numbering scheme to indicate versions
of the protocol. This specification defines version "1.1". The of the protocol. This specification defines version "1.1". The
protocol version as a whole indicates the sender's conformance with protocol version as a whole indicates the sender's conformance with
the set of requirements laid out in that version's corresponding the set of requirements laid out in that version's corresponding
specification of HTTP. specification of HTTP.
The version of an HTTP message is indicated by an HTTP-version field The version of an HTTP message is indicated by an HTTP-version field
in the first line of the message. HTTP-version is case-sensitive. in the first line of the message. HTTP-version is case sensitive.
HTTP-version = HTTP-name "/" DIGIT "." DIGIT HTTP-version = HTTP-name "/" DIGIT "." DIGIT
HTTP-name = %x48.54.54.50 ; "HTTP", case-sensitive HTTP-name = %x48.54.54.50 ; "HTTP", case sensitive
The HTTP version number consists of two decimal digits separated by a The HTTP version number consists of two decimal digits separated by a
"." (period or decimal point). The first digit ("major version") "." (period or decimal point). The first digit ("major version")
indicates the HTTP messaging syntax, whereas the second digit ("minor indicates the HTTP messaging syntax, whereas the second digit ("minor
version") indicates the highest minor version within that major version") indicates the highest minor version within that major
version to which the sender is conformant and able to understand for version to which the sender is conformant and able to understand for
future communication. The minor version advertises the sender's future communication. The minor version advertises the sender's
communication capabilities even when the sender is only using a communication capabilities even when the sender is only using a
backwards-compatible subset of the protocol, thereby letting the backwards-compatible subset of the protocol, thereby letting the
recipient know that more advanced features can be used in response recipient know that more advanced features can be used in response
skipping to change at page 14, line 36 skipping to change at page 14, line 39
The interpretation of a header field does not change between minor The interpretation of a header field does not change between minor
versions of the same major HTTP version, though the default behavior versions of the same major HTTP version, though the default behavior
of a recipient in the absence of such a field can change. Unless of a recipient in the absence of such a field can change. Unless
specified otherwise, header fields defined in HTTP/1.1 are defined specified otherwise, header fields defined in HTTP/1.1 are defined
for all versions of HTTP/1.x. In particular, the Host and Connection for all versions of HTTP/1.x. In particular, the Host and Connection
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 are not allowed to in forwarded messages. In other words, they are not allowed to
blindly forward the first line of an HTTP message without ensuring blindly forward the first line of an HTTP message without ensuring
that the protocol version in that message matches a version to which that the protocol version in that message matches a version to which
that intermediary is conformant for both the receiving and sending of that intermediary is conformant for both the receiving and sending of
messages. Forwarding an HTTP message without rewriting the HTTP- messages. Forwarding an HTTP message without rewriting the HTTP-
version might result in communication errors when downstream version might result in communication errors when downstream
skipping to change at page 15, line 48 skipping to change at page 15, line 51
introduced between [RFC2068] and [RFC2616], and this revision has introduced between [RFC2068] and [RFC2616], and this revision has
specifically avoided any such changes to the protocol. specifically avoided any such changes to the protocol.
When an HTTP message is received with a major version number that the When an HTTP message is received with a major version number that the
recipient implements, but a higher minor version number than what the recipient implements, but a higher minor version number than what the
recipient implements, the recipient SHOULD process the message as if recipient implements, the recipient SHOULD process the message as if
it were in the highest minor version within that major version to it were in the highest minor version within that major version to
which the recipient is conformant. A recipient can assume that a which the recipient is conformant. A recipient can assume that a
message with a higher minor version, when sent to a recipient that message with a higher minor version, when sent to a recipient that
has not yet indicated support for that higher version, is has not yet indicated support for that higher version, is
sufficiently backwards-compatible to be safely processed by any sufficiently backwards compatible to be safely processed by any
implementation of the same major version. implementation of the same major version.
2.7. Uniform Resource Identifiers 2.7. Uniform Resource Identifiers
Uniform Resource Identifiers (URIs) [RFC3986] are used throughout Uniform Resource Identifiers (URIs) [RFC3986] are used throughout
HTTP as the means for identifying resources (Section 2 of [RFC7231]). HTTP as the means for identifying resources (Section 2 of [RFC7231]).
URI references are used to target requests, indicate redirects, and URI references are used to target requests, indicate redirects, and
define relationships. define relationships.
The definitions of "URI-reference", "absolute-URI", "relative-part", The definitions of "URI-reference", "absolute-URI", "relative-part",
"scheme", "authority", "port", "host", "path-abempty", "segment", "scheme", "authority", "port", "host", "path-abempty", "segment",
"query", and "fragment" are adopted from the URI generic syntax. An "query", and "fragment" are adopted from the URI generic syntax. An
"absolute-path" rule is defined for protocol elements that can "absolute-path" rule is defined for protocol elements that can
contain a non-empty path component. (This rule differs slightly from contain a non-empty path component. (This rule differs slightly from
RFC 3986's path-abempty rule, which allows for an empty path to be the path-abempty rule of RFC 3986, which allows for an empty path to
used in references, and path-absolute rule, which does not allow be used in references, and path-absolute rule, which does not allow
paths that begin with "//".) A "partial-URI" rule is defined for paths that begin with "//".) A "partial-URI" rule is defined for
protocol elements that can contain a relative URI but not a fragment protocol elements that can contain a relative URI but not a fragment
component. component.
URI-reference = <URI-reference, defined in [RFC3986], Section 4.1> URI-reference = <URI-reference, defined in [RFC3986], Section 4.1>
absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3> absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3>
relative-part = <relative-part, defined in [RFC3986], Section 4.2> relative-part = <relative-part, defined in [RFC3986], Section 4.2>
scheme = <scheme, defined in [RFC3986], Section 3.1> scheme = <scheme, defined in [RFC3986], Section 3.1>
authority = <authority, defined in [RFC3986], Section 3.2> authority = <authority, defined in [RFC3986], Section 3.2>
uri-host = <host, defined in [RFC3986], Section 3.2.2> uri-host = <host, defined in [RFC3986], Section 3.2.2>
skipping to change at page 16, line 50 skipping to change at page 16, line 50
of reference (URI-reference), only a URI in absolute form (absolute- of reference (URI-reference), only a URI in absolute form (absolute-
URI), only the path and optional query components, or some URI), only the path and optional query components, or some
combination of the above. Unless otherwise indicated, URI references combination of the above. Unless otherwise indicated, URI references
are parsed relative to the effective request URI (Section 5.5). are parsed relative to the effective request URI (Section 5.5).
2.7.1. http URI Scheme 2.7.1. http URI Scheme
The "http" URI scheme is hereby defined for the purpose of minting The "http" URI scheme is hereby defined for the purpose of minting
identifiers according to their association with the hierarchical identifiers according to their association with the hierarchical
namespace governed by a potential HTTP origin server listening for namespace governed by a potential HTTP origin server listening for
TCP ([RFC0793]) connections on a given port. TCP ([RFC793]) connections on a given port.
http-URI = "http:" "//" authority path-abempty [ "?" query ] http-URI = "http:" "//" authority path-abempty [ "?" query ]
[ "#" fragment ] [ "#" fragment ]
The origin server for an "http" URI is identified by the authority The origin server for an "http" URI is identified by the authority
component, which includes a host identifier and optional TCP port component, which includes a host identifier and optional TCP port
([RFC3986], Section 3.2.2). The hierarchical path component and ([RFC3986], Section 3.2.2). The hierarchical path component and
optional query component serve as an identifier for a potential optional query component serve as an identifier for a potential
target resource within that origin server's name space. The optional target resource within that origin server's name space. The optional
skipping to change at page 18, line 44 skipping to change at page 18, line 44
through the use of strong encryption, end-to-end, prior to sending through the use of strong encryption, end-to-end, prior to sending
the first HTTP request. the first HTTP request.
https-URI = "https:" "//" authority path-abempty [ "?" query ] https-URI = "https:" "//" authority path-abempty [ "?" query ]
[ "#" fragment ] [ "#" fragment ]
Note that the "https" URI scheme depends on both TLS and TCP for Note that the "https" URI scheme depends on both TLS and TCP for
establishing authority. Resources made available via the "https" establishing authority. Resources made available via the "https"
scheme have no shared identity with the "http" scheme even if their scheme have no shared identity with the "http" scheme even if their
resource identifiers indicate the same authority (the same host resource identifiers indicate the same authority (the same host
listening to the same TCP port). They are distinct name spaces and listening to the same TCP port). They are distinct namespaces and
are considered to be distinct origin servers. However, an extension are considered to be distinct origin servers. However, an extension
to HTTP that is defined to apply to entire host domains, such as the to HTTP that is defined to apply to entire host domains, such as the
Cookie protocol [RFC6265], can allow information set by one service Cookie protocol [RFC6265], can allow information set by one service
to impact communication with other services within a matching group to impact communication with other services within a matching group
of host domains. of host domains.
The process for authoritative access to an "https" identified The process for authoritative access to an "https" identified
resource is defined in [RFC2818]. resource is defined in [RFC2818].
2.7.3. http and https URI Normalization and Comparison 2.7.3. http and https URI Normalization and Comparison
skipping to change at page 19, line 18 skipping to change at page 19, line 18
Since the "http" and "https" schemes conform to the URI generic Since the "http" and "https" schemes conform to the URI generic
syntax, such URIs are normalized and compared according to the syntax, such URIs are normalized and compared according to the
algorithm defined in Section 6 of [RFC3986], using the defaults algorithm defined in Section 6 of [RFC3986], using the defaults
described above for each scheme. described above for each scheme.
If the port is equal to the default port for a scheme, the normal If the port is equal to the default port for a scheme, the normal
form is to omit the port subcomponent. When not being used in form is to omit the port subcomponent. When not being used in
absolute form as the request target of an OPTIONS request, an empty absolute form as the request target of an OPTIONS request, an empty
path component is equivalent to an absolute path of "/", so the path component is equivalent to an absolute path of "/", so the
normal form is to provide a path of "/" instead. The scheme and host normal form is to provide a path of "/" instead. The scheme and host
are case-insensitive and normally provided in lowercase; all other are case insensitive and normally provided in lowercase; all other
components are compared in a case-sensitive manner. Characters other components are compared in a case-sensitive manner. Characters other
than those in the "reserved" set are equivalent to their percent- than those in the "reserved" set are equivalent to their percent-
encoded octets: the normal form is to not encode them (see Sections encoded octets: the normal form is to not encode them (see Sections
2.1 and 2.2 of [RFC3986]). 2.1 and 2.2 of [RFC3986]).
For example, the following three URIs are equivalent: For example, the following three URIs are equivalent:
http://example.com:80/~smith/home.html http://example.com:80/~smith/home.html
http://EXAMPLE.com/%7Esmith/home.html http://EXAMPLE.com/%7Esmith/home.html
http://EXAMPLE.com:/%7esmith/home.html http://EXAMPLE.com:/%7esmith/home.html
skipping to change at page 20, line 45 skipping to change at page 20, line 45
3.1. Start Line 3.1. Start Line
An HTTP message can be either a request from client to server or a An HTTP message can be either a request from client to server or a
response from server to client. Syntactically, the two types of response from server to client. Syntactically, the two types of
message differ only in the start-line, which is either a request-line message differ only in the start-line, which is either a request-line
(for requests) or a status-line (for responses), and in the algorithm (for requests) or a status-line (for responses), and in the algorithm
for determining the length of the message body (Section 3.3). for determining the length of the message body (Section 3.3).
In theory, a client could receive requests and a server could receive In theory, a client could receive requests and a server could receive
responses, distinguishing them by their different start-line formats, responses, distinguishing them by their different start-line formats,
but, in practice, servers are implemented to only expect a request (a but, in practice, servers are implemented only to expect a request (a
response is interpreted as an unknown or invalid request method) and response is interpreted as an unknown or invalid request method) and
clients are implemented to only expect a response. clients are implemented to only expect a response.
start-line = request-line / status-line start-line = request-line / status-line
3.1.1. Request Line 3.1.1. Request Line
A request-line begins with a method token, followed by a single space A request-line begins with a method token and is followed by a single
(SP), the request-target, another single space (SP), the protocol space (SP), the request-target, another single space (SP), the
version, and ending with CRLF. protocol version, and ends with CRLF.
request-line = method SP request-target SP HTTP-version CRLF request-line = method SP request-target SP HTTP-version CRLF
The method token indicates the request method to be performed on the The method token indicates the request method to be performed on the
target resource. The request method is case-sensitive. target resource. The request method is case sensitive.
method = token method = token
The request methods defined by this specification can be found in The request methods defined by this specification can be found in
Section 4 of [RFC7231], along with information regarding the HTTP Section 4 of [RFC7231], along with information regarding the HTTP
method registry and considerations for defining new methods. method registry and considerations for defining new methods.
The request-target identifies the target resource upon which to apply The request-target identifies the target resource upon which to apply
the request, as defined in Section 5.3. the request, as defined in Section 5.3.
skipping to change at page 22, line 8 skipping to change at page 22, line 8
longer than any URI it wishes to parse MUST respond with a 414 (URI longer than any URI it wishes to parse MUST respond with a 414 (URI
Too Long) status code (see Section 6.5.12 of [RFC7231]). Too Long) status code (see Section 6.5.12 of [RFC7231]).
Various ad hoc limitations on request-line length are found in Various ad hoc limitations on request-line length are found in
practice. It is RECOMMENDED that all HTTP senders and recipients practice. It is RECOMMENDED that all HTTP senders and recipients
support, at a minimum, request-line lengths of 8000 octets. support, at a minimum, request-line lengths of 8000 octets.
3.1.2. Status Line 3.1.2. Status Line
The first line of a response message is the status-line, consisting The first line of a response message is the status-line, consisting
of the protocol version, a space (SP), the status code, another of the protocol version, a space (SP), the status code, another space
space, a possibly empty textual phrase describing the status code, (SP), a possibly empty textual phrase describing the status code,
and ending with CRLF. and, finally, CRLF.
status-line = HTTP-version SP status-code SP reason-phrase CRLF status-line = HTTP-version SP status-code SP reason-phrase CRLF
The status-code element is a 3-digit integer code describing the The status-code element is a 3-digit integer code describing the
result of the server's attempt to understand and satisfy the client's result of the server's attempt to understand and satisfy the client's
corresponding request. The rest of the response message is to be corresponding request. The rest of the response message is to be
interpreted in light of the semantics defined for that status code. interpreted in light of the semantics defined for that status code.
See Section 6 of [RFC7231] for information about the semantics of See Section 6 of [RFC7231] for information about the semantics of
status codes, including the classes of status code (indicated by the status codes, including the classes of status code (indicated by the
first digit), the status codes defined by this specification, first digit), the status codes defined by this specification,
skipping to change at page 23, line 29 skipping to change at page 23, line 29
evaluation, or refine the meaning of responses. evaluation, or refine the meaning of responses.
A proxy MUST forward unrecognized header fields unless the field-name A proxy MUST forward unrecognized header fields unless the field-name
is listed in the Connection header field (Section 6.1) or the proxy is listed in the Connection header field (Section 6.1) or the proxy
is specifically configured to block, or otherwise transform, such is specifically configured to block, or otherwise transform, such
fields. Other recipients SHOULD ignore unrecognized header fields. fields. Other recipients SHOULD ignore unrecognized header fields.
These requirements allow HTTP's functionality to be enhanced without These requirements allow HTTP's functionality to be enhanced without
requiring prior update of deployed intermediaries. requiring prior update of deployed intermediaries.
All defined header fields ought to be registered with IANA in the All defined header fields ought to be registered with IANA in the
Message Header Field Registry, as described in Section 8.3 of "Message Headers" field registry, as described in Section 8.3 of
[RFC7231]. [RFC7231].
3.2.2. Field Order 3.2.2. Field Order
The order in which header fields with differing field names are The order in which header fields with differing field names are
received is not significant. However, it is good practice to send received is not significant. However, it is good practice to send
header fields that contain control data first, such as Host on header fields that contain control data first, such as Host on
requests and Date on responses, so that implementations can decide requests and Date on responses, so that implementations can decide
when not to handle a message as early as possible. A server MUST NOT when not to handle a message as early as possible. A server MUST NOT
apply a request to the target resource until the entire request apply a request to the target resource until the entire request
skipping to change at page 24, line 14 skipping to change at page 24, line 14
the combined field value in order, separated by a comma. The order the combined field value in order, separated by a comma. The order
in which header fields with the same field name are received is in which header fields with the same field name are received is
therefore significant to the interpretation of the combined field therefore significant to the interpretation of the combined field
value; a proxy MUST NOT change the order of these field values when value; a proxy MUST NOT change the order of these field values when
forwarding a message. forwarding a message.
Note: In practice, the "Set-Cookie" header field ([RFC6265]) often Note: In practice, the "Set-Cookie" header field ([RFC6265]) often
appears multiple times in a response message and does not use the appears multiple times in a response message and does not use the
list syntax, violating the above requirements on multiple header list syntax, violating the above requirements on multiple header
fields with the same name. Since it cannot be combined into a fields with the same name. Since it cannot be combined into a
single field-value, recipients ought to handle "Set-Cookie" as a single field-value, recipients ought to handle Set-Cookie as a
special case while processing header fields. (See Appendix A.2.3 special case while processing header fields. (See Appendix A.2.3
of [Kri2001] for details.) of [Kri2001] for details.)
3.2.3. Whitespace 3.2.3. Whitespace
This specification uses three rules to denote the use of linear This specification uses three rules to denote the use of linear
whitespace: OWS (optional whitespace), RWS (required whitespace), and whitespace: OWS (optional whitespace), RWS (required whitespace), and
BWS ("bad" whitespace). BWS ("bad" whitespace).
The OWS rule is used where zero or more linear whitespace octets The OWS rule is used where zero or more linear whitespace octets
might appear. For protocol elements where optional whitespace is might appear. For protocol elements where optional whitespace is
preferred to improve readability, a sender SHOULD generate the preferred to improve readability, a sender SHOULD generate the
optional whitespace as a single SP; otherwise, a sender SHOULD NOT optional whitespace as a single SP; otherwise, a sender SHOULD NOT
generate optional whitespace except as needed to white-out invalid or generate optional whitespace except as needed to white out invalid or
unwanted protocol elements during in-place message filtering. unwanted protocol elements during in-place message filtering.
The RWS rule is used when at least one linear whitespace octet is The RWS rule is used when at least one linear whitespace octet is
required to separate field tokens. A sender SHOULD generate RWS as a required to separate field tokens. A sender SHOULD generate RWS as a
single SP. single SP.
The BWS rule is used where the grammar allows optional whitespace The BWS rule is used where the grammar allows optional whitespace
only for historical reasons. A sender MUST NOT generate BWS in only for historical reasons. A sender MUST NOT generate BWS in
messages. A recipient MUST parse for such bad whitespace and remove messages. A recipient MUST parse for such bad whitespace and remove
it before interpreting the protocol element. it before interpreting the protocol element.
skipping to change at page 25, line 12 skipping to change at page 25, line 12
BWS = OWS BWS = OWS
; "bad" whitespace ; "bad" whitespace
3.2.4. Field Parsing 3.2.4. Field Parsing
Messages are parsed using a generic algorithm, independent of the Messages are parsed using a generic algorithm, independent of the
individual header field names. The contents within a given field individual header field names. The contents within a given field
value are not parsed until a later stage of message interpretation value are not parsed until a later stage of message interpretation
(usually after the message's entire header section has been (usually after the message's entire header section has been
processed). Consequently, this specification does not use ABNF rules processed). Consequently, this specification does not use ABNF rules
to define each "Field-Name: Field Value" pair, as was done in to define each "field-name: field-value" pair, as was done in
previous editions. Instead, this specification uses ABNF rules that previous editions. Instead, this specification uses ABNF rules that
are named according to each registered field name, wherein the rule are named according to each registered field name, wherein the rule
defines the valid grammar for that field's corresponding field values defines the valid grammar for that field's corresponding field values
(i.e., after the field-value has been extracted from the header (i.e., after the field-value has been extracted from the header
section by a generic field parser). section by a generic field parser).
No whitespace is allowed between the header field-name and colon. In No whitespace is allowed between the header field-name and colon. In
the past, differences in the handling of such whitespace have led to the past, differences in the handling of such whitespace have led to
security vulnerabilities in request routing and response handling. A security vulnerabilities in request routing and response handling. A
server MUST reject any received request message that contains server MUST reject any received request message that contains
skipping to change at page 26, line 15 skipping to change at page 26, line 15
with a representation explaining that unacceptable line folding was with a representation explaining that unacceptable line folding was
received, or replace each received obs-fold with one or more SP received, or replace each received obs-fold with one or more SP
octets prior to interpreting the field value or forwarding the octets prior to interpreting the field value or forwarding the
message downstream. message downstream.
A user agent that receives an obs-fold in a response message that is A user agent that receives an obs-fold in a response message that is
not within a message/http container MUST replace each received obs- not within a message/http container MUST replace each received obs-
fold with one or more SP octets prior to interpreting the field fold with one or more SP octets prior to interpreting the field
value. value.
Historically, HTTP has allowed field content with text in the ISO- Historically, HTTP has allowed field content with text in the
8859-1 [ISO-8859-1] charset, supporting other charsets only through ISO-8859-1 [ISO-8859-1] charset, supporting other charsets only
use of [RFC2047] encoding. In practice, most HTTP header field through use of [RFC2047] encoding. In practice, most HTTP header
values use only a subset of the US-ASCII charset [USASCII]. Newly field values use only a subset of the US-ASCII charset [USASCII].
defined header fields SHOULD limit their field values to US-ASCII Newly defined header fields SHOULD limit their field values to
octets. A recipient SHOULD treat other octets in field content (obs- US-ASCII octets. A recipient SHOULD treat other octets in field
text) as opaque data. content (obs-text) as opaque data.
3.2.5. Field Limits 3.2.5. Field Limits
HTTP does not place a predefined limit on the length of each header HTTP does not place a predefined limit on the length of each header
field or on the length of the header section as a whole, as described field or on the length of the header section as a whole, as described
in Section 2.5. Various ad hoc limitations on individual header in Section 2.5. Various ad hoc limitations on individual header
field length are found in practice, often depending on the specific field length are found in practice, often depending on the specific
field semantics. field semantics.
A server that receives a request header field, or set of fields, A server that receives a request header field, or set of fields,
skipping to change at page 33, line 6 skipping to change at page 33, line 6
6. If this is a request message and none of the above are true, then 6. If this is a request message and none of the above are true, then
the message body length is zero (no message body is present). the message body length is zero (no message body is present).
7. Otherwise, this is a response message without a declared message 7. Otherwise, this is a response message without a declared message
body length, so the message body length is determined by the body length, so the message body length is determined by the
number of octets received prior to the server closing the number of octets received prior to the server closing the
connection. connection.
Since there is no way to distinguish a successfully completed, close- Since there is no way to distinguish a successfully completed, close-
delimited message from a partially-received message interrupted by delimited message from a partially received message interrupted by
network failure, a server SHOULD generate encoding or length- network failure, a server SHOULD generate encoding or length-
delimited messages whenever possible. The close-delimiting feature delimited messages whenever possible. The close-delimiting feature
exists primarily for backwards compatibility with HTTP/1.0. exists primarily for backwards compatibility with HTTP/1.0.
A server MAY reject a request that contains a message body but not a A server MAY reject a request that contains a message body but not a
Content-Length by responding with 411 (Length Required). Content-Length by responding with 411 (Length Required).
Unless a transfer coding other than chunked has been applied, a Unless a transfer coding other than chunked has been applied, a
client that sends a request containing a message body SHOULD use a client that sends a request containing a message body SHOULD use a
valid Content-Length header field if the message body length is known valid Content-Length header field if the message body length is known
skipping to change at page 35, line 26 skipping to change at page 35, line 26
/ "compress" ; Section 4.2.1 / "compress" ; Section 4.2.1
/ "deflate" ; Section 4.2.2 / "deflate" ; Section 4.2.2
/ "gzip" ; Section 4.2.3 / "gzip" ; Section 4.2.3
/ transfer-extension / transfer-extension
transfer-extension = token *( OWS ";" OWS transfer-parameter ) transfer-extension = token *( OWS ";" OWS transfer-parameter )
Parameters are in the form of a name or name=value pair. Parameters are in the form of a name or name=value pair.
transfer-parameter = token BWS "=" BWS ( token / quoted-string ) transfer-parameter = token BWS "=" BWS ( token / quoted-string )
All transfer-coding names are case-insensitive and ought to be All transfer-coding names are case insensitive and ought to be
registered within the HTTP Transfer Coding registry, as defined in registered within the "HTTP Transfer Coding" registry, as defined in
Section 8.4. They are used in the TE (Section 4.3) and Transfer- Section 8.4. They are used in the TE (Section 4.3) and Transfer-
Encoding (Section 3.3.1) header fields. Encoding (Section 3.3.1) header fields.
4.1. Chunked Transfer Coding 4.1. Chunked Transfer Coding
The chunked transfer coding wraps the payload body in order to The chunked transfer coding wraps the payload body in order to
transfer it as a series of chunks, each with its own size indicator, transfer it as a series of chunks, each with its own size indicator,
followed by an OPTIONAL trailer containing header fields. Chunked followed by an OPTIONAL trailer containing header fields. Chunked
enables content streams of unknown size to be transferred as a enables content streams of unknown size to be transferred as a
sequence of length-delimited buffers, which enables the sender to sequence of length-delimited buffers, which enables the sender to
skipping to change at page 38, line 28 skipping to change at page 38, line 28
The "deflate" coding is a "zlib" data format [RFC1950] containing a The "deflate" coding is a "zlib" data format [RFC1950] containing a
"deflate" compressed data stream [RFC1951] that uses a combination of "deflate" compressed data stream [RFC1951] that uses a combination of
the Lempel-Ziv (LZ77) compression algorithm and Huffman coding. the Lempel-Ziv (LZ77) compression algorithm and Huffman coding.
Note: Some non-conformant implementations send the "deflate" Note: Some non-conformant implementations send the "deflate"
compressed data without the zlib wrapper. compressed data without the zlib wrapper.
4.2.3. Gzip Coding 4.2.3. Gzip Coding
The "gzip" coding is an LZ77 coding with a 32 bit CRC that is The "gzip" coding is an LZ77 coding with a 32-bit Cyclic Redundancy
commonly produced by the gzip file compression program [RFC1952]. A Check (CRC) that is commonly produced by the gzip file compression
recipient SHOULD consider "x-gzip" to be equivalent to "gzip". program [RFC1952]. A recipient SHOULD consider "x-gzip" to be
equivalent to "gzip".
4.3. TE 4.3. TE
The "TE" header field in a request indicates what transfer codings, The "TE" header field in a request indicates what transfer codings,
besides chunked, the client is willing to accept in response, and besides chunked, the client is willing to accept in response, and
whether or not the client is willing to accept trailer fields in a whether or not the client is willing to accept trailer fields in a
chunked transfer coding. chunked transfer coding.
The TE field-value consists of a comma-separated list of transfer The TE field-value consists of a comma-separated list of transfer
coding names, each allowing for optional parameters (as described in coding names, each allowing for optional parameters (as described in
skipping to change at page 49, line 29 skipping to change at page 49, line 29
A proxy MUST NOT modify the "absolute-path" and "query" parts of the A proxy MUST NOT modify the "absolute-path" and "query" parts of the
received request-target when forwarding it to the next inbound received request-target when forwarding it to the next inbound
server, except as noted above to replace an empty path with "/" or server, except as noted above to replace an empty path with "/" or
"*". "*".
A proxy MAY modify the message body through application or removal of A proxy MAY modify the message body through application or removal of
a transfer coding (Section 4). a transfer coding (Section 4).
A proxy MUST NOT transform the payload (Section 3.3 of [RFC7231]) of A proxy MUST NOT transform the payload (Section 3.3 of [RFC7231]) of
a message that contains a no-transform cache-control directive a message that contains a no-transform Cache-Control directive
(Section 5.2 of [RFC7234]). (Section 5.2 of [RFC7234]).
A proxy MAY transform the payload of a message that does not contain A proxy MAY transform the payload of a message that does not contain
a no-transform cache-control directive. A proxy that transforms a a no-transform Cache-Control directive. A proxy that transforms a
payload MUST add a Warning header field with the warn-code of 214 payload MUST add a Warning header field with the warn-code of 214
("Transformation Applied") if one is not already in the message (see ("Transformation Applied") if one is not already in the message (see
Section 5.5 of [RFC7234]). A proxy that transforms the payload of a Section 5.5 of [RFC7234]). A proxy that transforms the payload of a
200 (OK) response can further inform downstream recipients that a 200 (OK) response can further inform downstream recipients that a
transformation has been applied by changing the response status code transformation has been applied by changing the response status code
to 203 (Non-Authoritative Information) (Section 6.3.4 of [RFC7231]). to 203 (Non-Authoritative Information) (Section 6.3.4 of [RFC7231]).
A proxy SHOULD NOT modify header fields that provide information A proxy SHOULD NOT modify header fields that provide information
about the end points of the communication chain, the resource state, about the endpoints of the communication chain, the resource state,
or the selected representation (other than the payload) unless the or the selected representation (other than the payload) unless the
field's definition specifically allows such modification or the field's definition specifically allows such modification or the
modification is deemed necessary for privacy or security. modification is deemed necessary for privacy or security.
6. Connection Management 6. Connection Management
HTTP messaging is independent of the underlying transport or session- HTTP messaging is independent of the underlying transport- or
layer connection protocol(s). HTTP only presumes a reliable session-layer connection protocol(s). HTTP only presumes a reliable
transport with in-order delivery of requests and the corresponding transport with in-order delivery of requests and the corresponding
in-order delivery of responses. The mapping of HTTP request and in-order delivery of responses. The mapping of HTTP request and
response structures onto the data units of an underlying transport response structures onto the data units of an underlying transport
protocol is outside the scope of this specification. protocol is outside the scope of this specification.
As described in Section 5.2, the specific connection protocols to be As described in Section 5.2, the specific connection protocols to be
used for an HTTP interaction are determined by client configuration used for an HTTP interaction are determined by client configuration
and the target URI. For example, the "http" URI scheme and the target URI. For example, the "http" URI scheme
(Section 2.7.1) indicates a default connection of TCP over IP, with a (Section 2.7.1) indicates a default connection of TCP over IP, with a
default TCP port of 80, but the client might be configured to use a default TCP port of 80, but the client might be configured to use a
skipping to change at page 51, line 8 skipping to change at page 51, line 8
recipients on the chain ("end-to-end"), enabling the message to be recipients on the chain ("end-to-end"), enabling the message to be
self-descriptive and allowing future connection-specific extensions self-descriptive and allowing future connection-specific extensions
to be deployed without fear that they will be blindly forwarded by to be deployed without fear that they will be blindly forwarded by
older intermediaries. older intermediaries.
The Connection header field's value has the following grammar: The Connection header field's value has the following grammar:
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 [RFC7234]). (Section 5.2 of [RFC7234]).
The connection options do not always 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 a might not be needed if there are no parameters associated with a
connection option. In contrast, a connection-specific header field connection option. In contrast, a connection-specific header field
skipping to change at page 51, line 51 skipping to change at page 51, line 51
A client that does not support persistent connections MUST send the A client that does not support persistent connections MUST send the
"close" connection option in every request message. "close" connection option in every request message.
A server that does not support persistent connections MUST send the A server that does not support persistent connections MUST send the
"close" connection option in every response message that does not "close" connection option in every response message that does not
have a 1xx (Informational) status code. have a 1xx (Informational) status code.
6.2. Establishment 6.2. Establishment
It is beyond the scope of this specification to describe how It is beyond the scope of this specification to describe how
connections are established via various transport or session-layer connections are established via various transport- or session-layer
protocols. Each connection applies to only one transport link. protocols. Each connection applies to only one transport link.
6.3. Persistence 6.3. Persistence
HTTP/1.1 defaults to the use of "persistent connections", allowing HTTP/1.1 defaults to the use of "persistent connections", allowing
multiple requests and responses to be carried over a single multiple requests and responses to be carried over a single
connection. The "close" connection-option is used to signal that a connection. The "close" connection option is used to signal that a
connection will not persist after the current request/response. HTTP connection will not persist after the current request/response. HTTP
implementations SHOULD support persistent connections. implementations SHOULD support persistent connections.
A recipient determines whether a connection is persistent or not A recipient determines whether a connection is persistent or not
based on the most recently received message's protocol version and based on the most recently received message's protocol version and
Connection header field (if any): Connection header field (if any):
o If the close connection option is present, the connection will not o If the "close" connection option is present, the connection will
persist after the current response; else, not persist after the current response; else,
o If the received protocol is HTTP/1.1 (or later), the connection o If the received protocol is HTTP/1.1 (or later), the connection
will persist after the current response; else, will persist after the current response; else,
o If the received protocol is HTTP/1.0, the "keep-alive" connection o If the received protocol is HTTP/1.0, the "keep-alive" connection
option is present, the recipient is not a proxy, and the recipient option is present, the recipient is not a proxy, and the recipient
wishes to honor the HTTP/1.0 "keep-alive" mechanism, the wishes to honor the HTTP/1.0 "keep-alive" mechanism, the
connection will persist after the current response; otherwise, connection will persist after the current response; otherwise,
o The connection will close after the current response. o The connection will close after the current response.
A client MAY send additional requests on a persistent connection A client MAY send additional requests on a persistent connection
until it sends or receives a close connection option or receives an until it sends or receives a "close" connection option or receives an
HTTP/1.0 response without a "keep-alive" connection option. HTTP/1.0 response without a "keep-alive" connection option.
In order to remain persistent, all messages on a connection need to In order to remain persistent, all messages on a connection need to
have a self-defined message length (i.e., one not defined by closure have a self-defined message length (i.e., one not defined by closure
of the connection), as described in Section 3.3. A server MUST read of the connection), as described in Section 3.3. A server MUST read
the entire request message body or close the connection after sending the entire request message body or close the connection after sending
its response, since otherwise the remaining data on a persistent its response, since otherwise the remaining data on a persistent
connection would be misinterpreted as the next request. Likewise, a connection would be misinterpreted as the next request. Likewise, a
client MUST read the entire response message body if it intends to client MUST read the entire response message body if it intends to
reuse the same connection for a subsequent request. reuse the same connection for a subsequent request.
skipping to change at page 55, line 19 skipping to change at page 55, line 19
enables allocated system resources to be reclaimed. enables allocated system resources to be reclaimed.
A client, server, or proxy MAY close the transport connection at any A client, server, or proxy MAY close the transport connection at any
time. For example, a client might have started to send a new request time. For example, a client might have started to send a new request
at the same time that the server has decided to close the "idle" at the same time that the server has decided to close the "idle"
connection. From the server's point of view, the connection is being connection. From the server's point of view, the connection is being
closed while it was idle, but from the client's point of view, a closed while it was idle, but from the client's point of view, a
request is in progress. request is in progress.
A server SHOULD sustain persistent connections, when possible, and A server SHOULD sustain persistent connections, when possible, and
allow the underlying transport's flow control mechanisms to resolve allow the underlying transport's flow-control mechanisms to resolve
temporary overloads, rather than terminate connections with the temporary overloads, rather than terminate connections with the
expectation that clients will retry. The latter technique can expectation that clients will retry. The latter technique can
exacerbate network congestion. exacerbate network congestion.
A client sending a message body SHOULD monitor the network connection A client sending a message body SHOULD monitor the network connection
for an error response while it is transmitting the request. If the for an error response while it is transmitting the request. If the
client sees a response that indicates the server does not wish to client sees a response that indicates the server does not wish to
receive the message body and is closing the connection, the client receive the message body and is closing the connection, the client
SHOULD immediately cease transmitting the body and close its side of SHOULD immediately cease transmitting the body and close its side of
the connection. the connection.
6.6. Tear-down 6.6. Teardown
The Connection header field (Section 6.1) provides a "close" The Connection header field (Section 6.1) provides a "close"
connection option that a sender SHOULD send when it wishes to close connection option that a sender SHOULD send when it wishes to close
the connection after the current request/response pair. the connection after the current request/response pair.
A client that sends a close connection option MUST NOT send further A client that sends a "close" connection option MUST NOT send further
requests on that connection (after the one containing close) and MUST requests on that connection (after the one containing close) and MUST
close the connection after reading the final response message close the connection after reading the final response message
corresponding to this request. corresponding to this request.
A server that receives a close connection option MUST initiate a A server that receives a "close" connection option MUST initiate a
close of the connection (see below) after it sends the final response close of the connection (see below) after it sends the final response
to the request that contained close. The server SHOULD send a close to the request that contained close. The server SHOULD send a close
connection option in its final response on that connection. The connection option in its final response on that connection. The
server MUST NOT process any further requests received on that server MUST NOT process any further requests received on that
connection. connection.
A server that sends a close connection option MUST initiate a close A server that sends a "close" connection option MUST initiate a close
of the connection (see below) after it sends the response containing of the connection (see below) after it sends the response containing
close. The server MUST NOT process any further requests received on close. The server MUST NOT process any further requests received on
that connection. that connection.
A client that receives a close connection option MUST cease sending A client that receives a "close" connection option MUST cease sending
requests on that connection and close the connection after reading requests on that connection and close the connection after reading
the response message containing the close; if additional pipelined the response message containing the close; if additional pipelined
requests had been sent on the connection, the client SHOULD NOT requests had been sent on the connection, the client SHOULD NOT
assume that they will be processed by the server. assume that they will be processed by the server.
If a server performs an immediate close of a TCP connection, there is If a server performs an immediate close of a TCP connection, there is
a significant risk that the client will not be able to read the last a significant risk that the client will not be able to read the last
HTTP response. If the server receives additional data from the HTTP response. If the server receives additional data from the
client on a fully-closed connection, such as another request that was client on a fully closed connection, such as another request that was
sent by the client before receiving the server's response, the sent by the client before receiving the server's response, the
server's TCP stack will send a reset packet to the client; server's TCP stack will send a reset packet to the client;
unfortunately, the reset packet might erase the client's unfortunately, the reset packet might erase the client's
unacknowledged input buffers before they can be read and interpreted unacknowledged input buffers before they can be read and interpreted
by the client's HTTP parser. by the client's HTTP parser.
To avoid the TCP reset problem, servers typically close a connection To avoid the TCP reset problem, servers typically close a connection
in stages. First, the server performs a half-close by closing only in stages. First, the server performs a half-close by closing only
the write side of the read/write connection. The server then the write side of the read/write connection. The server then
continues to read from the connection until it receives a continues to read from the connection until it receives a
skipping to change at page 57, line 31 skipping to change at page 57, line 31
The following is a hypothetical example sent by a client: The following is a hypothetical example sent by a client:
GET /hello.txt HTTP/1.1 GET /hello.txt HTTP/1.1
Host: www.example.com Host: www.example.com
Connection: upgrade Connection: upgrade
Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
The capabilities and nature of the application-level communication The capabilities and nature of the application-level communication
after the protocol change is entirely dependent upon the new after the protocol change is entirely dependent upon the new
protocol(s) chosen. However, immediately after sending the 101 protocol(s) chosen. However, immediately after sending the 101
response, the server is expected to continue responding to the (Switching Protocols) response, the server is expected to continue
original request as if it had received its equivalent within the new responding to the original request as if it had received its
protocol (i.e., the server still has an outstanding request to equivalent within the new protocol (i.e., the server still has an
satisfy after the protocol has been changed, and is expected to do so outstanding request to satisfy after the protocol has been changed,
without requiring the request to be repeated). and is expected to do so without requiring the request to be
repeated).
For example, if the Upgrade header field is received in a GET request For example, if the Upgrade header field is received in a GET request
and the server decides to switch protocols, it first responds with a and the server decides to switch protocols, it first responds with a
101 (Switching Protocols) message in HTTP/1.1 and then immediately 101 (Switching Protocols) message in HTTP/1.1 and then immediately
follows that with the new protocol's equivalent of a response to a follows that with the new protocol's equivalent of a response to a
GET on the target resource. This allows a connection to be upgraded GET on the target resource. This allows a connection to be upgraded
to protocols with the same semantics as HTTP without the latency cost to protocols with the same semantics as HTTP without the latency cost
of an additional round trip. A server MUST NOT switch protocols of an additional round trip. A server MUST NOT switch protocols
unless the received message semantics can be honored by the new unless the received message semantics can be honored by the new
protocol; an OPTIONS request can be honored by any protocol. protocol; an OPTIONS request can be honored by any protocol.
skipping to change at page 59, line 35 skipping to change at page 59, line 35
#element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ] #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ]
1#element => *( "," OWS ) element *( OWS "," [ OWS element ] ) 1#element => *( "," OWS ) element *( OWS "," [ OWS element ] )
Empty elements do not contribute to the count of elements present. Empty elements do not contribute to the count of elements present.
For example, given these ABNF productions: For example, given these ABNF productions:
example-list = 1#example-list-elmt example-list = 1#example-list-elmt
example-list-elmt = token ; see Section 3.2.6 example-list-elmt = token ; see Section 3.2.6
Then the following are valid values for example-list (not including Then, the following are valid values for example-list (not including
the double quotes, which are present for delimitation only): the double quotes, which are present for delimitation only):
"foo,bar" "foo,bar"
"foo ,bar," "foo ,bar,"
"foo , ,bar,charlie " "foo , ,bar,charlie "
In contrast, the following values would be invalid, since at least In contrast, the following values would be invalid, since at least
one non-empty element is required by the example-list production: one non-empty element is required by the example-list production:
"" ""
"," ","
", ," ", ,"
Appendix B shows the collected ABNF for recipients after the list Appendix B shows the collected ABNF for recipients after the list
constructs have been expanded. constructs have been expanded.
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 registry maintained at
<http://www.iana.org/assignments/message-headers/>. <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 the
associated registry entries shall be updated according to the "Permanent Message Header Field Names" registry has been updated
permanent registrations below (see [BCP90]): accordingly (see [BCP90]).
+-------------------+----------+----------+---------------+ +-------------------+----------+----------+---------------+
| Header Field Name | Protocol | Status | Reference | | Header Field Name | Protocol | Status | Reference |
+-------------------+----------+----------+---------------+ +-------------------+----------+----------+---------------+
| Connection | http | standard | Section 6.1 | | Connection | http | standard | Section 6.1 |
| Content-Length | http | standard | Section 3.3.2 | | Content-Length | http | standard | Section 3.3.2 |
| Host | http | standard | Section 5.4 | | Host | http | standard | Section 5.4 |
| TE | http | standard | Section 4.3 | | TE | http | standard | Section 4.3 |
| Trailer | http | standard | Section 4.4 | | Trailer | http | standard | Section 4.4 |
| Transfer-Encoding | http | standard | Section 3.3.1 | | Transfer-Encoding | http | standard | Section 3.3.1 |
| Upgrade | http | standard | Section 6.7 | | Upgrade | http | standard | Section 6.7 |
| Via | http | standard | Section 5.7.1 | | Via | http | standard | Section 5.7.1 |
+-------------------+----------+----------+---------------+ +-------------------+----------+----------+---------------+
Furthermore, the header field-name "Close" shall be registered as Furthermore, the header field-name "Close" has been registered as
"reserved", since using that name as an HTTP header field might "reserved", since using that name as an HTTP header field might
conflict with the "close" connection option of the "Connection" conflict with the "close" connection option of the "Connection"
header field (Section 6.1). header field (Section 6.1).
+-------------------+----------+----------+-------------+ +-------------------+----------+----------+-------------+
| Header Field Name | Protocol | Status | Reference | | Header Field Name | Protocol | Status | Reference |
+-------------------+----------+----------+-------------+ +-------------------+----------+----------+-------------+
| 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/>. <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 the "Permanent
registry entries shall be updated according to the permanent URI Schemes" registry has been updated accordingly.
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 IANA maintains the registry of Internet media types [BCP13] at
<http://www.iana.org/assignments/media-types>. <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 has been
registered with IANA. 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
skipping to change at page 62, line 20 skipping to change at page 62, line 20
Additional information: Additional information:
Magic number(s): N/A Magic number(s): N/A
Deprecated alias names for this type: N/A Deprecated alias names for this type: N/A
File extension(s): N/A File extension(s): N/A
Macintosh file type code(s): N/A Macintosh file type code(s): N/A
Person and email address to contact for further information: See Person and email address to contact for further information:
Authors' Addresses Section. See Authors' Addresses Section.
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: N/A Restrictions on usage: N/A
Author: See Authors' Addresses Section. Author: See Authors' Addresses Section.
Change controller: IESG Change controller: IESG
8.3.2. Internet Media Type application/http 8.3.2. Internet Media Type application/http
skipping to change at page 63, line 7 skipping to change at page 63, line 7
version: The HTTP-version number of the enclosed messages (e.g., version: The HTTP-version number of the enclosed messages (e.g.,
"1.1"). If not present, the version can be determined from the "1.1"). If not present, the version can be determined from the
first line of the body. first line of the body.
msgtype: The message type -- "request" or "response". If not msgtype: The message type -- "request" or "response". If not
present, the type can be determined from the first line of the present, the type can be determined from the first line of the
body. body.
Encoding considerations: HTTP messages enclosed by this type are in Encoding considerations: HTTP messages enclosed by this type are in
"binary" format; use of an appropriate Content-Transfer-Encoding "binary" format; use of an appropriate Content-Transfer-Encoding
is required when transmitted via E-mail. is required when transmitted via email.
Security considerations: see Section 9 Security considerations: see Section 9
Interoperability considerations: N/A Interoperability considerations: N/A
Published specification: This specification (see Section 8.3.2). Published specification: This specification (see Section 8.3.2).
Applications that use this media type: N/A Applications that use this media type: N/A
Fragment identifier considerations: N/A Fragment identifier considerations: N/A
skipping to change at page 63, line 29 skipping to change at page 63, line 29
Additional information: Additional information:
Deprecated alias names for this type: N/A Deprecated alias names for this type: N/A
Magic number(s): N/A Magic number(s): N/A
File extension(s): N/A File extension(s): N/A
Macintosh file type code(s): N/A Macintosh file type code(s): N/A
Person and email address to contact for further information: See Person and email address to contact for further information:
Authors' Addresses Section. See Authors' Addresses Section.
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: N/A Restrictions on usage: N/A
Author: See Authors' Addresses Section. Author: See Authors' Addresses Section.
Change controller: IESG Change controller: IESG
8.4. Transfer Coding Registry 8.4. Transfer Coding Registry
The HTTP Transfer Coding Registry defines the name space for transfer The "HTTP Transfer Coding" registry defines the namespace for
coding names. It is maintained at transfer coding names. It is maintained at
<http://www.iana.org/assignments/http-parameters>. <http://www.iana.org/assignments/http-parameters>.
8.4.1. Procedure 8.4.1. Procedure
Registrations MUST include the following fields: Registrations MUST include the following fields:
o Name o Name
o Description o Description
o Pointer to specification text o Pointer to specification text
Names of transfer codings MUST NOT overlap with names of content Names of transfer codings MUST NOT overlap with names of content
codings (Section 3.1.2.1 of [RFC7231]) unless the encoding codings (Section 3.1.2.1 of [RFC7231]) unless the encoding
transformation is identical, as is the case for the compression transformation is identical, as is the case for the compression
codings defined in Section 4.2. codings defined in Section 4.2.
Values to be added to this name space require IETF Review (see Values to be added to this namespace require IETF Review (see Section
Section 4.1 of [RFC5226]), and MUST conform to the purpose of 4.1 of [RFC5226]), and MUST conform to the purpose of transfer coding
transfer coding defined in this specification. defined in this specification.
Use of program names for the identification of encoding formats is Use of program names for the identification of encoding formats is
not desirable and is discouraged for future encodings. not desirable and is discouraged for future encodings.
8.4.2. Registration 8.4.2. Registration
The HTTP Transfer Coding Registry shall be updated with the The "HTTP Transfer Coding Registry" has been updated with the
registrations below: registrations below:
+------------+--------------------------------------+---------------+ +------------+--------------------------------------+---------------+
| Name | Description | Reference | | Name | Description | Reference |
+------------+--------------------------------------+---------------+ +------------+--------------------------------------+---------------+
| chunked | Transfer in a series of chunks | Section 4.1 | | chunked | Transfer in a series of chunks | Section 4.1 |
| compress | UNIX "compress" 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. Content Coding Registration 8.5. Content Coding Registration
IANA maintains the registry of HTTP Content Codings at IANA maintains the "HTTP Content Coding Registry" at
<http://www.iana.org/assignments/http-parameters>. <http://www.iana.org/assignments/http-parameters>.
The HTTP Content Codings Registry shall be updated with the The "HTTP Content Codings Registry" has been updated with the
registrations below: registrations below:
+------------+--------------------------------------+---------------+ +------------+--------------------------------------+---------------+
| Name | Description | Reference | | Name | Description | Reference |
+------------+--------------------------------------+---------------+ +------------+--------------------------------------+---------------+
| 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.6. Upgrade Token Registry 8.6. Upgrade Token Registry
The HTTP Upgrade Token Registry defines the name space for protocol- The "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry"
name tokens used to identify protocols in the Upgrade header field. defines the namespace for protocol-name tokens used to identify
The registry is maintained at protocols in the Upgrade header field. The registry is maintained at
<http://www.iana.org/assignments/http-upgrade-tokens>. <http://www.iana.org/assignments/http-upgrade-tokens>.
8.6.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:
skipping to change at page 66, line 10 skipping to change at page 66, line 10
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.6.2. Upgrade Token Registration 8.6.2. Upgrade Token Registration
The "HTTP" entry in the HTTP Upgrade Token Registry shall be updated The "HTTP" entry in the "HTTP Upgrade Token" registry shall be
with the registration below: updated 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 67, line 13 skipping to change at page 67, line 13
unknown or untrusted source. unknown or untrusted source.
When a registered name is used in the authority component, the "http" When a registered name is used in the authority component, the "http"
URI scheme (Section 2.7.1) relies on the user's local name resolution URI scheme (Section 2.7.1) relies on the user's local name resolution
service to determine where it can find authoritative responses. This service to determine where it can find authoritative responses. This
means that any attack on a user's network host table, cached names, means that any attack on a user's network host table, cached names,
or name resolution libraries becomes an avenue for attack on or name resolution libraries becomes an avenue for attack on
establishing authority. Likewise, the user's choice of server for establishing authority. Likewise, the user's choice of server for
Domain Name Service (DNS), and the hierarchy of servers from which it Domain Name Service (DNS), and the hierarchy of servers from which it
obtains resolution results, could impact the authenticity of address obtains resolution results, could impact the authenticity of address
mappings; DNSSEC ([RFC4033]) is one way to improve authenticity. mappings; DNS Security Extensions (DNSSEC) ([RFC4033]) is one way to
improve authenticity.
Furthermore, after an IP address is obtained, establishing authority Furthermore, after an IP address is obtained, establishing authority
for an "http" URI is vulnerable to attacks on Internet Protocol for an "http" URI is vulnerable to attacks on Internet Protocol
routing. routing.
The "https" scheme (Section 2.7.2) is intended to prevent (or at The "https" scheme (Section 2.7.2) is intended to prevent (or at
least reveal) many of these potential attacks on establishing least reveal) many of these potential attacks on establishing
authority, provided that the negotiated TLS connection is secured and authority, provided that the negotiated TLS connection is secured and
the client properly verifies that the communicating server's identity the client properly verifies that the communicating server's identity
matches the target URI's authority component (see [RFC2818]). matches the target URI's authority component (see [RFC2818]).
Correctly implementing such verification can be difficult (see Correctly implementing such verification can be difficult (see
[Georgiev]). [Georgiev]).
9.2. Risks of Intermediaries 9.2. Risks of Intermediaries
By their very nature, HTTP intermediaries are men-in-the-middle, and By their very nature, HTTP intermediaries are men in the middle and,
thus represent an opportunity for man-in-the-middle attacks. thus, represent an opportunity for man-in-the-middle attacks.
Compromise of the systems on which the intermediaries run can result Compromise of the systems on which the intermediaries run can result
in serious security and privacy problems. Intermediaries might have in serious security and privacy problems. Intermediaries might have
access to security-related information, personal information about access to security-related information, personal information about
individual users and organizations, and proprietary information individual users and organizations, and proprietary information
belonging to users and content providers. A compromised belonging to users and content providers. A compromised
intermediary, or an intermediary implemented or configured without intermediary, or an intermediary implemented or configured without
regard to security and privacy considerations, might be used in the regard to security and privacy considerations, might be used in the
commission of a wide range of potential attacks. commission of a wide range of potential attacks.
Intermediaries that contain a shared cache are especially vulnerable Intermediaries that contain a shared cache are especially vulnerable
skipping to change at page 70, line 9 skipping to change at page 70, line 9
access mechanism has resulted in its increasing use within access mechanism has resulted in its increasing use within
environments where verification of message integrity is crucial. environments where verification of message integrity is crucial.
User agents are encouraged to implement configurable means for User agents are encouraged to implement configurable means for
detecting and reporting failures of message integrity such that those detecting and reporting failures of message integrity such that those
means can be enabled within environments for which integrity is means can be enabled within environments for which integrity is
necessary. For example, a browser being used to view medical history necessary. For example, a browser being used to view medical history
or drug interaction information needs to indicate to the user when or drug interaction information needs to indicate to the user when
such information is detected by the protocol to be incomplete, such information is detected by the protocol to be incomplete,
expired, or corrupted during transfer. Such mechanisms might be expired, or corrupted during transfer. Such mechanisms might be
selectively enabled via user agent extensions or the presence of selectively enabled via user-agent extensions or the presence of
message integrity metadata in a response. At a minimum, user agents message integrity metadata in a response. At a minimum, user agents
ought to provide some indication that allows a user to distinguish ought to provide some indication that allows a user to distinguish
between a complete and incomplete response message (Section 3.4) when between a complete and incomplete response message (Section 3.4) when
such verification is desired. such verification is desired.
9.7. Message Confidentiality 9.7. Message Confidentiality
HTTP relies on underlying transport protocols to provide message HTTP relies on underlying transport protocols to provide message
confidentiality when that is desired. HTTP has been specifically confidentiality when that is desired. HTTP has been specifically
designed to be independent of the transport protocol, such that it designed to be independent of the transport protocol, such that it
skipping to change at page 72, line 50 skipping to change at page 72, line 50
Yuchung Cheng, Yutaka Oiwa, Yves Lafon (long-time member of the Yuchung Cheng, Yutaka Oiwa, Yves Lafon (long-time member of the
editor team), Zed A. Shaw, and Zhong Yu. editor team), Zed A. Shaw, and Zhong Yu.
See Section 16 of [RFC2616] for additional acknowledgements from See Section 16 of [RFC2616] for additional acknowledgements from
prior revisions. prior revisions.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data
Format Specification version 3.3", RFC 1950, May 1996. Format Specification version 3.3", RFC 1950, May 1996.
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format
Specification version 1.3", RFC 1951, May 1996. Specification version 1.3", RFC 1951, May 1996.
[RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and
G. Randers-Pehrson, "GZIP file format specification G. Randers-Pehrson, "GZIP file format specification
version 4.3", RFC 1952, May 1996. version 4.3", RFC 1952, May 1996.
skipping to change at page 73, line 28 skipping to change at page 73, line 25
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
"Uniform Resource Identifier (URI): Generic Syntax", "Uniform Resource Identifier (URI): Generic Syntax",
STD 66, RFC 3986, January 2005. STD 66, RFC 3986, January 2005.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", STD 68, RFC 5234, Syntax Specifications: ABNF", STD 68, RFC 5234,
January 2008. January 2008.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Semantics and Content", Transfer Protocol (HTTP/1.1): Semantics and Content",
draft-ietf-httpbis-p2-semantics-latest (work in RFC 7231, May 2014.
progress), May 2014.
[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Conditional Requests", Transfer Protocol (HTTP/1.1): Conditional Requests",
draft-ietf-httpbis-p4-conditional-latest (work in RFC 7232, May 2014.
progress), May 2014.
[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
"Hypertext Transfer Protocol (HTTP/1.1): Range "Hypertext Transfer Protocol (HTTP/1.1): Range
Requests", draft-ietf-httpbis-p5-range-latest (work in Requests", RFC 7233, May 2014.
progress), May 2014.
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
draft-ietf-httpbis-p6-cache-latest (work in progress), RFC 7234, May 2014.
May 2014.
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Authentication", Transfer Protocol (HTTP/1.1): Authentication",
draft-ietf-httpbis-p7-auth-latest (work in progress), RFC 7235, May 2014.
May 2014.
[RFC793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[USASCII] American National Standards Institute, "Coded Character [USASCII] American National Standards Institute, "Coded Character
Set -- 7-bit American Standard Code for Information Set -- 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986. Interchange", ANSI X3.4, 1986.
[Welch] Welch, T., "A Technique for High Performance Data [Welch] Welch, T., "A Technique for High-Performance Data
Compression", IEEE Computer 17(6), June 1984. Compression", IEEE Computer 17(6), June 1984.
11.2. Informative References 11.2. Informative References
[BCP115] Hansen, T., Hardie, T., and L. Masinter, "Guidelines [BCP115] Hansen, T., Hardie, T., and L. Masinter, "Guidelines
and Registration Procedures for New URI Schemes", and Registration Procedures for New URI Schemes",
BCP 115, RFC 4395, February 2006. BCP 115, RFC 4395, February 2006.
[BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type [BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13, Specifications and Registration Procedures", BCP 13,
skipping to change at page 76, line 25 skipping to change at page 76, line 22
HTTP has been in use since 1990. The first version, later referred HTTP has been in use since 1990. The first version, later referred
to as HTTP/0.9, was a simple protocol for hypertext data transfer to as HTTP/0.9, was a simple protocol for hypertext data transfer
across the Internet, using only a single request method (GET) and no across the Internet, using only a single request method (GET) and no
metadata. HTTP/1.0, as defined by [RFC1945], added a range of metadata. HTTP/1.0, as defined by [RFC1945], added a range of
request methods and MIME-like messaging, allowing for metadata to be request methods and MIME-like messaging, allowing for metadata to be
transferred and modifiers placed on the request/response semantics. transferred and modifiers placed on the request/response semantics.
However, HTTP/1.0 did not sufficiently take into consideration the However, HTTP/1.0 did not sufficiently take into consideration the
effects of hierarchical proxies, caching, the need for persistent effects of hierarchical proxies, caching, the need for persistent
connections, or name-based virtual hosts. The proliferation of connections, or name-based virtual hosts. The proliferation of
incompletely-implemented applications calling themselves "HTTP/1.0" incompletely implemented applications calling themselves "HTTP/1.0"
further necessitated a protocol version change in order for two further necessitated a protocol version change in order for two
communicating applications to determine each other's true communicating applications to determine each other's true
capabilities. capabilities.
HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent
requirements that enable reliable implementations, adding only those requirements that enable reliable implementations, adding only those
features that can either be safely ignored by an HTTP/1.0 recipient features that can either be safely ignored by an HTTP/1.0 recipient
or only be sent when communicating with a party advertising or only be sent when communicating with a party advertising
conformance with HTTP/1.1. conformance with HTTP/1.1.
skipping to change at page 77, line 10 skipping to change at page 77, line 5
implements name-based virtual hosts ought to disable support for implements name-based virtual hosts ought to disable support for
HTTP/0.9. Most requests that appear to be HTTP/0.9 are, in fact, HTTP/0.9. Most requests that appear to be HTTP/0.9 are, in fact,
badly constructed HTTP/1.x requests caused by a client failing to badly constructed HTTP/1.x requests caused by a client failing to
properly encode the request-target. properly encode the request-target.
A.1. Changes from HTTP/1.0 A.1. Changes from HTTP/1.0
This section summarizes major differences between versions HTTP/1.0 This section summarizes major differences between versions HTTP/1.0
and HTTP/1.1. and HTTP/1.1.
A.1.1. Multi-homed Web Servers A.1.1. Multihomed Web Servers
The requirements that clients and servers support the Host header The requirements that clients and servers support the Host header
field (Section 5.4), report an error if it is missing from an field (Section 5.4), report an error if it is missing from an
HTTP/1.1 request, and accept absolute URIs (Section 5.3) are among HTTP/1.1 request, and accept absolute URIs (Section 5.3) are among
the most important changes defined by HTTP/1.1. the most important changes defined by HTTP/1.1.
Older HTTP/1.0 clients assumed a one-to-one relationship of IP Older HTTP/1.0 clients assumed a one-to-one relationship of IP
addresses and servers; there was no other established mechanism for addresses and servers; there was no other established mechanism for
distinguishing the intended server of a request than the IP address distinguishing the intended server of a request than the IP address
to which that request was directed. The Host header field was to which that request was directed. The Host header field was
skipping to change at page 78, line 20 skipping to change at page 78, line 14
not be used by clients at all when a proxy is being used. not be used by clients at all when a proxy is being used.
A.1.3. Introduction of Transfer-Encoding A.1.3. Introduction of Transfer-Encoding
HTTP/1.1 introduces the Transfer-Encoding header field HTTP/1.1 introduces the Transfer-Encoding header field
(Section 3.3.1). Transfer codings need to be decoded prior to (Section 3.3.1). Transfer codings need to be decoded prior to
forwarding an HTTP message over a MIME-compliant protocol. forwarding an HTTP message over a MIME-compliant protocol.
A.2. Changes from RFC 2616 A.2. Changes from RFC 2616
HTTP's approach to error handling has been explained. (Section 2.5) HTTP's approach to error handling has been explained (Section 2.5).
The HTTP-version ABNF production has been clarified to be case- The HTTP-version ABNF production has been clarified to be case
sensitive. Additionally, version numbers have been restricted to sensitive. Additionally, version numbers have been restricted to
single digits, due to the fact that implementations are known to single digits, due to the fact that implementations are known to
handle multi-digit version numbers incorrectly. (Section 2.6) handle multi-digit version numbers incorrectly (Section 2.6).
Userinfo (i.e., username and password) are now disallowed in HTTP and Userinfo (i.e., username and password) are now disallowed in HTTP and
HTTPS URIs, because of security issues related to their transmission HTTPS URIs, because of security issues related to their transmission
on the wire. (Section 2.7.1) on the wire (Section 2.7.1).
The HTTPS URI scheme is now defined by this specification; The HTTPS URI scheme is now defined by this specification;
previously, it was done in Section 2.4 of [RFC2818]. Furthermore, it previously, it was defined in Section 2.4 of [RFC2818]. Furthermore,
implies end-to-end security. (Section 2.7.2) it implies end-to-end security (Section 2.7.2).
HTTP messages can be (and often are) buffered by implementations; HTTP messages can be (and often are) buffered by implementations;
despite it sometimes being available as a stream, HTTP is despite it sometimes being available as a stream, HTTP is
fundamentally a message-oriented protocol. Minimum supported sizes fundamentally a message-oriented protocol. Minimum supported sizes
for various protocol elements have been suggested, to improve for various protocol elements have been suggested, to improve
interoperability. (Section 3) interoperability (Section 3).
Invalid whitespace around field-names is now required to be rejected, Invalid whitespace around field-names is now required to be rejected,
because accepting it represents a security vulnerability. The ABNF because accepting it represents a security vulnerability. The ABNF
productions defining header fields now only list the field value. productions defining header fields now only list the field value
(Section 3.2) (Section 3.2).
Rules about implicit linear whitespace between certain grammar Rules about implicit linear whitespace between certain grammar
productions have been removed; now whitespace is only allowed where productions have been removed; now whitespace is only allowed where
specifically defined in the ABNF. (Section 3.2.3) specifically defined in the ABNF (Section 3.2.3).
Header fields that span multiple lines ("line folding") are Header fields that span multiple lines ("line folding") are
deprecated. (Section 3.2.4) deprecated (Section 3.2.4).
The NUL octet is no longer allowed in comment and quoted-string text, The NUL octet is no longer allowed in comment and quoted-string text,
and handling of backslash-escaping in them has been clarified. The and handling of backslash-escaping in them has been clarified. The
quoted-pair rule no longer allows escaping control characters other quoted-pair rule no longer allows escaping control characters other
than HTAB. Non-ASCII content in header fields and the reason phrase than HTAB. Non-US-ASCII content in header fields and the reason
has been obsoleted and made opaque (the TEXT rule was removed). phrase has been obsoleted and made opaque (the TEXT rule was removed)
(Section 3.2.6) (Section 3.2.6).
Bogus "Content-Length" header fields are now required to be handled Bogus "Content-Length" header fields are now required to be handled
as errors by recipients. (Section 3.3.2) as errors by recipients (Section 3.3.2).
The algorithm for determining the message body length has been The algorithm for determining the message body length has been
clarified to indicate all of the special cases (e.g., driven by clarified to indicate all of the special cases (e.g., driven by
methods or status codes) that affect it, and that new protocol methods or status codes) that affect it, and that new protocol
elements cannot define such special cases. CONNECT is a new, special elements cannot define such special cases. CONNECT is a new, special
case in determining message body length. "multipart/byteranges" is no case in determining message body length. "multipart/byteranges" is no
longer a way of determining message body length detection. longer a way of determining message body length detection
(Section 3.3.3) (Section 3.3.3).
The "identity" transfer coding token has been removed. (Sections 3.3 The "identity" transfer coding token has been removed (Sections 3.3
and 4) and 4).
Chunk length does not include the count of the octets in the chunk Chunk length does not include the count of the octets in the chunk
header and trailer. Line folding in chunk extensions is disallowed. header and trailer. Line folding in chunk extensions is disallowed
(Section 4.1) (Section 4.1).
The meaning of the "deflate" content coding has been clarified. The meaning of the "deflate" content coding has been clarified
(Section 4.2.2) (Section 4.2.2).
The segment + query components of RFC 3986 have been used to define The segment + query components of RFC 3986 have been used to define
the request-target, instead of abs_path from RFC 1808. The asterisk- the request-target, instead of abs_path from RFC 1808. The asterisk-
form of the request-target is only allowed with the OPTIONS method. form of the request-target is only allowed with the OPTIONS method
(Section 5.3) (Section 5.3).
The term "Effective Request URI" has been introduced. (Section 5.5) The term "Effective Request URI" has been introduced (Section 5.5).
Gateways do not need to generate Via header fields anymore. Gateways do not need to generate Via header fields anymore
(Section 5.7.1) (Section 5.7.1).
Exactly when "close" connection options have to be sent has been Exactly when "close" connection options have to be sent has been
clarified. Also, "hop-by-hop" header fields are required to appear clarified. Also, "hop-by-hop" header fields are required to appear
in the Connection header field; just because they're defined as hop- in the Connection header field; just because they're defined as hop-
by-hop in this specification doesn't exempt them. (Section 6.1) by-hop in this specification doesn't exempt them (Section 6.1).
The limit of two connections per server has been removed. An The limit of two connections per server has been removed. An
idempotent sequence of requests is no longer required to be retried. idempotent sequence of requests is no longer required to be retried.
The requirement to retry requests under certain circumstances when The requirement to retry requests under certain circumstances when
the server prematurely closes the connection has been removed. Also, the server prematurely closes the connection has been removed. Also,
some extraneous requirements about when servers are allowed to close some extraneous requirements about when servers are allowed to close
connections prematurely have been removed. (Section 6.3) connections prematurely have been removed (Section 6.3).
The semantics of the Upgrade header field is now defined in responses The semantics of the Upgrade header field is now defined in responses
other than 101 (this was incorporated from [RFC2817]). 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 "HTTP Upgrade Tokens" registry,
defined in Section 7.2 of [RFC2817]. (Section 8.6) previously 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 ] )
Content-Length = 1*DIGIT Content-Length = 1*DIGIT
HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body
skipping to change at page 83, line 25 skipping to change at page 83, line 20
client 7 client 7
close 50, 55 close 50, 55
compress (Coding Format) 38 compress (Coding Format) 38
connection 7 connection 7
Connection header field 50, 55 Connection header field 50, 55
Content-Length header field 30 Content-Length header field 30
D D
deflate (Coding Format) 38 deflate (Coding Format) 38
Delimiters 26 Delimiters 26
downstream 9 downstream 10
E E
effective request URI 44 effective request URI 44
G G
gateway 10 gateway 10
Grammar Grammar
absolute-form 41-42 absolute-form 41-42
absolute-path 16 absolute-path 16
absolute-URI 16 absolute-URI 16
skipping to change at page 84, line 20 skipping to change at page 84, line 14
field-content 22 field-content 22
field-name 22, 39 field-name 22, 39
field-value 22 field-value 22
field-vchar 22 field-vchar 22
fragment 16 fragment 16
header-field 22, 36 header-field 22, 36
HEXDIG 6 HEXDIG 6
Host 43 Host 43
HTAB 6 HTAB 6
HTTP-message 19 HTTP-message 19
HTTP-name 13 HTTP-name 14
http-URI 16 http-URI 16
HTTP-version 13 HTTP-version 14
https-URI 18 https-URI 18
last-chunk 35 last-chunk 35
LF 6 LF 6
message-body 27 message-body 27
method 21 method 21
obs-fold 22 obs-fold 22
obs-text 27 obs-text 27
OCTET 6 OCTET 6
origin-form 41 origin-form 41
OWS 24 OWS 24
skipping to change at page 85, line 34 skipping to change at page 85, line 28
H H
header field 19 header field 19
header section 19 header section 19
headers 19 headers 19
Host header field 43 Host header field 43
http URI scheme 16 http URI scheme 16
https URI scheme 18 https URI scheme 18
I I
inbound 9 inbound 10
interception proxy 11 interception proxy 11
intermediary 9 intermediary 9
M M
Media Type Media Type
application/http 62 application/http 62
message/http 61 message/http 61
message 7 message 7
message/http Media Type 61 message/http Media Type 61
method 21 method 21
N N
non-transforming proxy 48 non-transforming proxy 48
O O
origin server 7 origin server 7
origin-form (of request-target) 41 origin-form (of request-target) 41
outbound 9 outbound 10
P P
phishing 66 phishing 66
proxy 10 proxy 10
R R
recipient 7 recipient 7
request 7 request 7
request-target 21 request-target 21
resource 16 resource 16
skipping to change at page 86, line 35 skipping to change at page 86, line 30
target URI 40 target URI 40
TE header field 38 TE header field 38
Trailer header field 39 Trailer header field 39
Transfer-Encoding header field 28 Transfer-Encoding header field 28
transforming proxy 48 transforming proxy 48
transparent proxy 11 transparent proxy 11
tunnel 10 tunnel 10
U U
Upgrade header field 56 Upgrade header field 56
upstream 9 upstream 10
URI scheme URI scheme
http 16 http 16
https 18 https 18
user agent 7 user agent 7
V V
Via header field 47 Via header field 47
Authors' Addresses Authors' Addresses
 End of changes. 111 change blocks. 
194 lines changed or deleted 173 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/