< draft-ietf-httpbis-bcp56bis-03.txt   draft-ietf-httpbis-bcp56bis-04.txt >
HTTP M. Nottingham HTTP M. Nottingham
Internet-Draft April 2, 2018 Internet-Draft April 11, 2018
Obsoletes: 3205 (if approved) Obsoletes: 3205 (if approved)
Intended status: Best Current Practice Intended status: Best Current Practice
Expires: October 4, 2018 Expires: October 13, 2018
On the use of HTTP as a Substrate On the use of HTTP as a Substrate
draft-ietf-httpbis-bcp56bis-03 draft-ietf-httpbis-bcp56bis-04
Abstract Abstract
HTTP is often used as a substrate for other application protocols. HTTP is often used as a substrate for other application protocols
This document specifies best practices for these protocols' use of (a.k.a. HTTP-based APIs). This document specifies best practices
HTTP. for these protocols' use of HTTP.
This document obsoletes RFC 3205. This document obsoletes RFC 3205.
Note to Readers Note to Readers
Discussion of this draft takes place on the HTTP working group Discussion of this draft takes place on the HTTP working group
mailing list (ietf-http-wg@w3.org), which is archived at mailing list (ietf-http-wg@w3.org), which is archived at
https://lists.w3.org/Archives/Public/ietf-http-wg/ [1]. https://lists.w3.org/Archives/Public/ietf-http-wg/ [1].
Working Group information can be found at http://httpwg.github.io/ Working Group information can be found at http://httpwg.github.io/
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 4, 2018. This Internet-Draft will expire on October 13, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 39 skipping to change at page 2, line 39
4. Best Practices for Using HTTP . . . . . . . . . . . . . . . . 7 4. Best Practices for Using HTTP . . . . . . . . . . . . . . . . 7
4.1. Specifying the Use of HTTP . . . . . . . . . . . . . . . 8 4.1. Specifying the Use of HTTP . . . . . . . . . . . . . . . 8
4.2. Defining HTTP Resources . . . . . . . . . . . . . . . . . 8 4.2. Defining HTTP Resources . . . . . . . . . . . . . . . . . 8
4.3. Specifying Client Behaviours . . . . . . . . . . . . . . 9 4.3. Specifying Client Behaviours . . . . . . . . . . . . . . 9
4.4. HTTP URLs . . . . . . . . . . . . . . . . . . . . . . . . 10 4.4. HTTP URLs . . . . . . . . . . . . . . . . . . . . . . . . 10
4.4.1. Initial URL Discovery . . . . . . . . . . . . . . . . 11 4.4.1. Initial URL Discovery . . . . . . . . . . . . . . . . 11
4.4.2. URL Schemes . . . . . . . . . . . . . . . . . . . . . 11 4.4.2. URL Schemes . . . . . . . . . . . . . . . . . . . . . 11
4.4.3. Transport Ports . . . . . . . . . . . . . . . . . . . 12 4.4.3. Transport Ports . . . . . . . . . . . . . . . . . . . 12
4.5. HTTP Methods . . . . . . . . . . . . . . . . . . . . . . 12 4.5. HTTP Methods . . . . . . . . . . . . . . . . . . . . . . 12
4.5.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.5.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.5.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 14
4.6. HTTP Status Codes . . . . . . . . . . . . . . . . . . . . 14 4.6. HTTP Status Codes . . . . . . . . . . . . . . . . . . . . 14
4.7. HTTP Header Fields . . . . . . . . . . . . . . . . . . . 15 4.7. HTTP Header Fields . . . . . . . . . . . . . . . . . . . 16
4.8. Defining Message Payloads . . . . . . . . . . . . . . . . 16 4.8. Defining Message Payloads . . . . . . . . . . . . . . . . 17
4.9. HTTP Caching . . . . . . . . . . . . . . . . . . . . . . 16 4.9. HTTP Caching . . . . . . . . . . . . . . . . . . . . . . 17
4.10. Application State . . . . . . . . . . . . . . . . . . . . 17 4.10. Application State . . . . . . . . . . . . . . . . . . . . 19
4.11. Client Authentication . . . . . . . . . . . . . . . . . . 17 4.11. Client Authentication . . . . . . . . . . . . . . . . . . 19
4.12. Co-Existing with Web Browsing . . . . . . . . . . . . . . 18 4.12. Co-Existing with Web Browsing . . . . . . . . . . . . . . 19
4.13. Application Boundaries . . . . . . . . . . . . . . . . . 19 4.13. Application Boundaries . . . . . . . . . . . . . . . . . 21
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
7.1. Normative References . . . . . . . . . . . . . . . . . . 20 7.1. Normative References . . . . . . . . . . . . . . . . . . 22
7.2. Informative References . . . . . . . . . . . . . . . . . 22 7.2. Informative References . . . . . . . . . . . . . . . . . 24
7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 25 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Appendix A. Changes from RFC 3205 . . . . . . . . . . . . . . . 27
Appendix A. Changes from RFC 3205 . . . . . . . . . . . . . . . 25 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 27
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
HTTP [RFC7230] is often used as a substrate for other application HTTP [RFC7230] is often used as a substrate for other application
protocols. This is done for a variety of reasons, including: protocols; this is sometimes referred to as creating "HTTP-based
APIs", or just "HTTP APIs", although the latter is ambiguous. This
is done for a variety of reasons, including:
o familiarity by implementers, specifiers, administrators, o familiarity by implementers, specifiers, administrators,
developers and users, developers and users,
o availability of a variety of client, server and proxy o availability of a variety of client, server and proxy
implementations, implementations,
o ease of use, o ease of use,
o ubiquity of Web browsers, o ubiquity of Web browsers,
o reuse of existing mechanisms like authentication and encryption, o reuse of existing mechanisms like authentication and encryption,
o presence of HTTP servers and clients in target deployments, and o presence of HTTP servers and clients in target deployments, and
o its ability to traverse firewalls. o its ability to traverse firewalls.
In many cases, these protocols are ad hoc; they are intended for only In many cases, these protocols are ad hoc; they are intended for only
deployment on the server side, and consumption by a limited set of deployment on the server side, and consumption by a limited set of
clients. A body of practices and tools has arisen around defining clients. A body of practices and tools has arisen around defining
such "HTTP APIs" that favours these conditions. HTTP-based APIs that favours these conditions.
However, when such a protocol is standarised, it is typically However, when such a protocol is standarised, it is typically
deployed on multiple servers, implemented a number of times, and deployed on multiple servers, implemented a number of times, and
might be consumed by a broader variety of clients. Such diversity might be consumed by a broader variety of clients. Such diversity
brings a different set of concerns, and tools and practices intended brings a different set of concerns, and tools and practices intended
for a single-server deployment might not be suitable. for a single-server deployment might not be suitable.
In particular, standards-defined HTTP APIs need to more carefully In particular, standards-defined HTTP-based APIs need to more
consider how extensibility and evolution will be handled, how carefully consider how extensibility and evolution will be handled,
different deployment requirements will be accommodated, and how how different deployment requirements will be accommodated, and how
clients will evolve with the API. clients will evolve with the API.
At the same time, the Internet community has a tradition of protocol At the same time, the IETF has a tradition of protocol reuse (e.g.,
reuse (e.g., Telnet [RFC0854] as a substrate for FTP [RFC0959] and [TELNET] as a substrate for [FTP] and [SMTP]; HTTP as a substrate for
SMTP [RFC2821]), but less experience using HTTP as a substrate. [IPP] and [RESTCONF]). Because HTTP is extensible in many ways, a
Because HTTP is extensible in many ways, a number of questions arise, number of questions arise, such as:
such as:
o Should an application using HTTP define a new URL scheme? Use new o Should an application using HTTP define a new URL scheme? Use new
ports? ports?
o Should it use standard HTTP methods and status codes, or define o Should it use standard HTTP methods and status codes, or define
new ones? new ones?
o How can the maximum value be extracted from the use of HTTP? o How can the maximum value be extracted from the use of HTTP?
o How does it coexist with other uses of HTTP - especially Web o How does it coexist with other uses of HTTP - especially Web
skipping to change at page 4, line 38 skipping to change at page 4, line 41
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Is HTTP Being Used? 2. Is HTTP Being Used?
Different applications have different goals when using HTTP. In this Different applications have different goals when using HTTP. In this
document, we say an application is _using HTTP_ when any of the document, we say an application is "using HTTP" when any of the
following conditions are true: following conditions are true:
o The transport port in use is 80 or 443, o The transport port in use is 80 or 443,
o The URL scheme "http" or "https" is used, o The URL scheme "http" or "https" is used,
o The ALPN protocol ID [RFC7301] generically identifies HTTP (e.g., o The ALPN protocol ID [RFC7301] generically identifies HTTP (e.g.,
"http/1.1", "h2", "h2c"), or "http/1.1", "h2", "h2c"), or
o The IANA registries defined for HTTP are updated or modified. o The IANA registries defined for HTTP are updated or modified.
When an application is using HTTP, all of the requirements of the When an application is using HTTP, all of the requirements of the
HTTP protocol suite (including but not limited to [RFC7230], HTTP protocol suite are in force (including but not limited to
[RFC7230], [RFC7231], [RFC7232], [RFC7233], [RFC7234], [RFC7235] and
[RFC7231], [RFC7232], [RFC7233], [RFC7234], [RFC7235] and [RFC7540]) [RFC7540]).
are in force.
An application might not be _using HTTP_ according to this An application might not be using HTTP according to this definition,
definition, but still relying upon the HTTP specifications in some but still relying upon the HTTP specifications in some manner. For
manner. For example, an application might wish to avoid re- example, an application might wish to avoid re-specifying parts of
specifying parts of the message format, but change others; or, it the message format, but change others; or, it might want to use a
might want to use a different set of methods. different set of methods.
Such applications are referred to as _protocols based upon HTTP_ in Such applications are referred to as "protocols based upon HTTP" in
this document. These have more freedom to modify protocol operation, this document. These have more freedom to modify protocol operation,
but are also likely to lose at least a portion of the benefits but are also likely to lose at least a portion of the benefits
outlined above, as most HTTP implementations won't be easily outlined above, as most HTTP implementations won't be easily
adaptable to these changes, and as the protocol diverges from HTTP, adaptable to these changes, and as the protocol diverges from HTTP,
the benefit of mindshare will be lost. the benefit of mindshare will be lost.
Protocols that are based upon HTTP MUST NOT reuse HTTP's URL schemes, Protocols that are based upon HTTP MUST NOT reuse HTTP's URL schemes,
transport ports, ALPN protocol IDs or IANA registries; rather, they transport ports, ALPN protocol IDs or IANA registries; rather, they
are encouraged to establish their own. are encouraged to establish their own.
skipping to change at page 5, line 45 skipping to change at page 5, line 47
3.1. Generic Semantics 3.1. Generic Semantics
When writing an application's specification, it's often tempting to When writing an application's specification, it's often tempting to
specify exactly how HTTP is to be implemented, supported and used. specify exactly how HTTP is to be implemented, supported and used.
However, this can easily lead to an unintended profile of HTTP's However, this can easily lead to an unintended profile of HTTP's
behaviour. For example, it's common to see specifications with behaviour. For example, it's common to see specifications with
language like this: language like this:
A `200 OK` response means that the widget has successfully been
updated.
This sort of specification is bad practice, because it is adding new
semantics to HTTP's status codes and methods, respectively; a
recipient - whether it's an origin server, client library,
intermediary or cache - now has to know these extra semantics to
understand the message.
Some applications even require specific behaviours, such as:
A `POST` request MUST result in a `201 Created` response. A `POST` request MUST result in a `201 Created` response.
This forms an expectation in the client that the response will always This forms an expectation in the client that the response will always
be "201 Created", when in fact there are a number of reasons why the be "201 Created", when in fact there are a number of reasons why the
status code might differ in a real deployment. If the client does status code might differ in a real deployment. If the client does
not anticipate this, the application's deployment is brittle. not anticipate this, the application's deployment is brittle.
Much of the value of HTTP is in its _generic semantics_ - that is, Much of the value of HTTP is in its generic semantics - that is, the
the protocol elements defined by HTTP are potentially applicable to protocol elements defined by HTTP are potentially applicable to every
every resource, not specific to a particular context. Application- resource, not specific to a particular context. Application-specific
specific semantics are expressed in the payload; mostly, in the body, semantics are expressed in the payload; mostly, in the body, but also
but also in header fields. in header fields.
This allows a HTTP message to be examined by generic HTTP software This allows a HTTP message to be examined by generic HTTP software
(e.g., HTTP servers, intermediaries, client implementations), and its (e.g., HTTP servers, intermediaries, client implementations), and its
handling to be correctly determined. It also allows people to handling to be correctly determined. It also allows people to
leverage their knowledge of HTTP semantics without special-casing leverage their knowledge of HTTP semantics without special-casing
them for a particular application. them for a particular application.
Therefore, applications that use HTTP MUST NOT re-define, refine or Therefore, applications that use HTTP MUST NOT re-define, refine or
overlay the semantics of defined protocol elements. Instead, they overlay the semantics of defined protocol elements. Instead, they
should focus their specifications on protocol elements that are should focus their specifications on protocol elements that are
skipping to change at page 7, line 4 skipping to change at page 6, line 44
resources, can cause deployment issues, and is therefore bad practice resources, can cause deployment issues, and is therefore bad practice
in standards. in standards.
Instead of statically defining URL components like paths, it is Instead of statically defining URL components like paths, it is
RECOMMENDED that applications using HTTP define links in payloads, to RECOMMENDED that applications using HTTP define links in payloads, to
allow flexibility in deployment. allow flexibility in deployment.
Using runtime links in this fashion has a number of other benefits. Using runtime links in this fashion has a number of other benefits.
For example, navigating with a link allows a request to be routed to For example, navigating with a link allows a request to be routed to
a different server without the overhead of a redirection, thereby a different server without the overhead of a redirection, thereby
supporting deployment across machines well. It becomes possible to supporting deployment across machines well.
"mix" different applications on the same server, and offers a natural
path for extensibility, versioning and capability management. It also becomes possible to "mix" different applications on the same
server, and offers a natural mechanism for extensibility, versioning
and capability management.
3.3. Rich Functionality 3.3. Rich Functionality
The simplest possible use of HTTP is to POST data to a single URL, The simplest possible use of HTTP is to POST data to a single URL,
thereby effectively tunnelling through the protocol. thereby effectively tunnelling through the protocol.
This "RPC" style of communication does get some benefit from using This "RPC" style of communication does get some benefit from using
HTTP - namely, message framing and the availability of HTTP - namely, message framing and the availability of
implementations - but fails to realise many others when used implementations - but fails to realise many others when used
exclusively: exclusively:
skipping to change at page 7, line 36 skipping to change at page 7, line 33
o Definition of an information space using URLs; and o Definition of an information space using URLs; and
o The ability to interact with the application easily using a Web o The ability to interact with the application easily using a Web
browser. browser.
Using such a high-level protocol to tunnel simple semantics has Using such a high-level protocol to tunnel simple semantics has
downsides too; because of its more advanced capabilities, breadth of downsides too; because of its more advanced capabilities, breadth of
deployment and age, HTTP's complexity can cause interoperability deployment and age, HTTP's complexity can cause interoperability
problems that could be avoided by using a simpler substrate (e.g., problems that could be avoided by using a simpler substrate (e.g.,
WebSockets [RFC6455], if browser support is necessary, or TCP WebSockets [RFC6455], if browser support is necessary, or TCP
[RFC0793] if not), or making the application be _based upon HTTP_, [RFC0793] if not), or making the application be based upon HTTP,
instead of using it (as defined in Section 2). instead of using it (as defined in Section 2).
Applications that use HTTP are encouraged to accommodate the various Applications that use HTTP are encouraged to accommodate the various
features that the protocol offers, so that their users receive the features that the protocol offers, so that their users receive the
maximum benefit from it. This document does not require specific maximum benefit from it. This document does not require specific
features to be used, since the appropriate design tradeoffs are features to be used, since the appropriate design tradeoffs are
highly specific to a given situation. However, following the highly specific to a given situation. However, following the
practices in Section 4 will help make them available. practices in Section 4 will help make them available.
4. Best Practices for Using HTTP 4. Best Practices for Using HTTP
skipping to change at page 9, line 42 skipping to change at page 9, line 42
related information in the link indicated by the Link header field related information in the link indicated by the Link header field
value with the "example-other-info" link relation type. value with the "example-other-info" link relation type.
4.3. Specifying Client Behaviours 4.3. Specifying Client Behaviours
HTTP does not mandate some behaviours that have nevertheless become HTTP does not mandate some behaviours that have nevertheless become
very common; if these are not explicitly specified by applications very common; if these are not explicitly specified by applications
using HTTP, there may be confusion and interoperability problems. using HTTP, there may be confusion and interoperability problems.
This section recommends default handling for these mechanisms. This section recommends default handling for these mechanisms.
o Redirect handling - applications using HTTP SHOULD specify that o Redirect handling - Applications using HTTP SHOULD specify that
3xx redirect status codes be followed automatically. See 3xx redirect status codes be followed automatically. See
[RFC7231], Section 6.4. [RFC7231], Section 6.4.
o Redirect methods - applications using HTTP SHOULD specify that 301 o Redirect methods - Applications using HTTP SHOULD specify that 301
and 302 redirect status codes rewrite the POST method to GET. See and 302 redirect status codes rewrite the POST method to GET, in
[RFC7231], Section 6.4. order to be compatible with browsers. See [RFC7231], Section 6.4.
o Cookies - Applications using HTTP MUST explicitly reference the o Cookies - Applications using HTTP MUST explicitly reference the
Cookie specification [RFC6265] if they are required. Cookie specification [RFC6265] if they are required.
o Certificates - Applications using HTTP MUST specify that TLS o Certificates - Applications using HTTP MUST specify that TLS
certificates are to be checked according to [RFC2818] when HTTPS certificates are to be checked according to [RFC2818] when HTTPS
is used. is used.
In general, applications using HTTP ought to align their usage as In general, applications using HTTP ought to align their usage as
closely as possible with Web browsers, to avoid interoperability closely as possible with Web browsers, to avoid interoperability
skipping to change at page 11, line 24 skipping to change at page 11, line 24
"the initial document is at "/foo/v1", they should allow a deployment "the initial document is at "/foo/v1", they should allow a deployment
to use any URL as the entry point for the application. to use any URL as the entry point for the application.
In cases where doing so is impractical (e.g., it is not possible to In cases where doing so is impractical (e.g., it is not possible to
convey a whole URL, but only a hostname) standard applications that convey a whole URL, but only a hostname) standard applications that
use HTTP can request a well-known URL [RFC5785] as an entry point. use HTTP can request a well-known URL [RFC5785] as an entry point.
4.4.2. URL Schemes 4.4.2. URL Schemes
Applications that use HTTP will typically employ the "http" and/or Applications that use HTTP will typically employ the "http" and/or
"https" URL schemes. "https" is preferred to provide authentication, "https" URL schemes. "https" is RECOMMENDED to provide
integrity and confidentiality, as well as mitigate pervasive authentication, integrity and confidentiality, as well as mitigate
monitoring attacks [RFC7258]. pervasive monitoring attacks [RFC7258].
However, application-specific schemes can be defined as well. However, application-specific schemes can be defined as well.
When defining an URL scheme for an application using HTTP, there are When defining an URL scheme for an application using HTTP, there are
a number of tradeoffs and caveats to keep in mind: a number of tradeoffs and caveats to keep in mind:
o Unmodified Web browsers will not support the new scheme. While it o Unmodified Web browsers will not support the new scheme. While it
is possible to register new URL schemes with Web browsers (e.g. is possible to register new URL schemes with Web browsers (e.g.
registerProtocolHandler() in [HTML5], as well as several registerProtocolHandler() in [HTML5], as well as several
proprietary approaches), support for these mechanisms is not proprietary approaches), support for these mechanisms is not
skipping to change at page 13, line 34 skipping to change at page 13, line 34
In some cases, however, GET might be unwieldy for expressing queries, In some cases, however, GET might be unwieldy for expressing queries,
because of the limited syntax of the URL; in particular, if binary because of the limited syntax of the URL; in particular, if binary
data forms part of the query terms, it needs to be encoded to conform data forms part of the query terms, it needs to be encoded to conform
to URL syntax. to URL syntax.
While this is not an issue for short queries, it can become one for While this is not an issue for short queries, it can become one for
larger query terms, or ones which need to sustain a high rate of larger query terms, or ones which need to sustain a high rate of
requests. Additionally, some HTTP implementations limit the size of requests. Additionally, some HTTP implementations limit the size of
URLs they support - although modern HTTP software has much more URLs they support - although modern HTTP software has much more
generous limits than previously (typically, considerably more than generous limits than previously (typically, considerably more than
8000 octets, as required by [RFC7230] Section 3.1.1). 8000 octets, as required by [RFC7230], Section 3.1.1).
In these cases, an application using HTTP might consider using POST In these cases, an application using HTTP might consider using POST
to express queries in the request body; doing so avoids encoding to express queries in the request body; doing so avoids encoding
overhead and URL length limits in implementations. However, in doing overhead and URL length limits in implementations. However, in doing
so it should be noted that the benefits of GET such as caching and so it should be noted that the benefits of GET such as caching and
linking to query results are lost. Therefore, applications using linking to query results are lost. Therefore, applications using
HTTP that feel a need to allow POST queries ought consider allowing HTTP that feel a need to allow POST queries ought consider allowing
both methods. both methods.
Applications that use HTTP SHOULD NOT define GET requests to have Applications that use HTTP SHOULD NOT define GET requests to have
side effects, since implementations can and do retry HTTP GET side effects, since implementations can and do retry HTTP GET
requests that fail. requests that fail.
Finally, note that while HTTP allows GET requests to have a body Finally, note that while HTTP allows GET requests to have a body
syntactically, this is done only to allow parsers to be generic; as syntactically, this is done only to allow parsers to be generic; as
per [RFC7231], Section 4.3.1, a body on a GET has no meaning, and per [RFC7231], Section 4.3.1, a body on a GET has no meaning, and
will be either ignored or rejected by generic HTTP software. As a will be either ignored or rejected by generic HTTP software.
result, applications that use HTTP SHOULD NOT define GET to have any
sde effects upon their resources. 4.5.2. OPTIONS
The OPTIONS method was defined for metadata retrieval, and is used
both by WebDAV [RFC4918] and CORS [FETCH]. Because HTTP-based APIs
often need to retrieve metadata about resources, it is often
considered for their use.
However, OPTIONS does have significant limitations:
o It isn't possible to link to the metadata with a simple URL,
because OPTIONS is not the default GET method.
o OPTIONS responses are not cacheable, because HTTP caches operate
on representations of the resource (i.e., GET and HEAD). If
OPTIONS responses are cached separately, their interaction with
HTTP cache expiry, secondary keys and other mechanisms needs to be
considered.
o OPTIONS is "chatty" - always separating metadata out into a
separate request increases the number of requests needed to
interact with the application.
o Implementation support for OPTIONS is not universal; some servers
do not expose the ability to respond to OPTIONS requests without
significant effort.
Instead of OPTIONS, one of these alternative approaches might be more
appropriate:
o For server-wide metadata, create a well-known URI [RFC5785], or
using an already existing one if it's appropriate (e.g., HostMeta
[RFC6415]).
o For metadata about a specific resource, use a Link response
header, or a link in the representation format for that resource.
See [RFC8288]. Note that the Link header is available on HEAD
responses, which is useful if the client wants to discover a
resource's capabilities before they interact with it.
4.6. HTTP Status Codes 4.6. HTTP Status Codes
Applications that use HTTP MUST only use registered HTTP status The primary function of a HTTP status code is to convey semantics for
codes. the benefit of generic HTTP software, not to convey application-
specific semantics.
As with methods, new HTTP status codes are rare, and required (by In particular, status codes are often generated or overwritten by
[RFC7231]) to be registered with IETF review. Similarly, HTTP status intermediaries, as well as server and client implementations; for
codes are generic; they are required (by [RFC7231]) to be potentially example, when network errors are encountered, a captive portal is
applicable to all resources, not just to those of one application. present, when an implementation is overloaded, or it thinks it is
under attack. As a result, the status code that a server-side
application generates and the one that the client software receives
often differ.
When authors believe that a new status code is required, they are This means that status codes are not a reliable way to carry
encouraged to engage with the HTTP community early, and document application-specific signals. Specifying that a particular status
their proposal as a separate HTTP extension, rather than as part of code has a specific meaning in the context of an application can have
an application's specification. unintended side effects; if that status code is generated by a
generic HTTP component can lead clients to believe that the
application is in a state that wasn't intended.
The primary function of status codes is to convey HTTP semantics for Instead, applications using HTTP should specify the implications of
the benefit of generic HTTP software, not application-specific general classes of responses (e.g., "successful response" for 2xx;
semantics. Therefore, applications MUST NOT specify additional "client error" for 4xx and "server error" for 5xx), conveying any
semantics or refine existing semantics for status codes. application-specific information in the message body and/or HTTP
header fields, not the status code. [RFC7807] provides one way for
applications using HTTP to do so for error conditions.
In particular, specifying that a particular status code has a There are limited exceptions to this; for example, applications might
specific meaning in the context of an application is harmful, as use 201 (Created) or 404 (Not Found) to convey application semantics
these are not generic semantics, since the consumer needs to be in that are compatible with the generic HTTP semantics of those status
the context of the application to understand them. codes. In general, though, applications should resist the temptation
to map their semantics into fine-grained status codes.
Furthermore, applications using HTTP MUST NOT re-specify the Because the set of registered HTTP status codes can expand,
semantics of HTTP status codes, even if it is only by copying their applications using HTTP should explicitly point out that clients
definition. They MUST NOT require specific reason phrases to be ought to be able to handle all applicable status codes gracefully
used; the reason phrase has no function in HTTP, and is not (i.e., falling back to the generic "n00" semantics of a given status
guaranteed to be preserved by implementations. The reason phrase is code; e.g., "499" can be safely handled as "400" by clients that
not carried in the [RFC7540] message format. don't recognise it). This is preferable to creating a "laundry list"
of potential status codes, since such a list is never complete.
Typically, applications using HTTP will convey application-specific Applications using HTTP MUST NOT re-specify the semantics of HTTP
information in the message body and/or HTTP header fields, not the status codes, even if it is only by copying their definition. They
status code. [RFC7807] provides one way for applications using HTTP MUST NOT require specific reason phrases to be used; the reason
to do this. phrase has no function in HTTP, and is not guaranteed to be preserved
by implementations, and the reason phrase is not carried at all in
the [RFC7540] message format.
Specifications sometimes also create a "laundry list" of potential Applications that use HTTP MUST only use registered HTTP status
status codes, in an effort to be helpful. The problem with doing so codes. As with methods, new HTTP status codes are rare, and required
is that such a list is never complete; for example, if a network (by [RFC7231]) to be registered with IETF review. Similarly, HTTP
proxy is interposed, the client might encounter a "407 Proxy status codes are generic; they are required (by [RFC7231]) to be
Authentication Required" response; or, if the server is rate limiting potentially applicable to all resources, not just to those of one
the client, it might receive a "429 Too Many Requests" response. application.
Since the list of HTTP status codes can be added to, it's safer to When authors believe that a new status code is required, they are
specify behaviours in terms of general response classes (e.g., encouraged to engage with the HTTP community early, and document
"successful response" for 2xx; "client error" for 4xx and "server their proposal as a separate HTTP extension, rather than as part of
error" for 5xx), pointing out that clients SHOULD be able to handle an application's specification.
all applicable protocol elements gracefully (i.e., falling back to
the generic "n00" semantics of a given status code; e.g., "499" can
be safely handled as "400" by clients that don't recognise it).
4.7. HTTP Header Fields 4.7. HTTP Header Fields
Applications that use HTTP MAY define new HTTP header fields, Applications that use HTTP MAY define new HTTP header fields.
following the advice in [RFC7231], Section 8.3.1.
Typically, using HTTP header fields is appropriate in a few different Typically, using HTTP header fields is appropriate in a few different
situations: situations:
o Their content is useful to intermediaries (who often wish to avoid o Their content is useful to intermediaries (who often wish to avoid
parsing the body), and/or parsing the body), and/or
o Their content is useful to generic HTTP software (e.g., clients, o Their content is useful to generic HTTP software (e.g., clients,
servers), and/or servers), and/or
o It is not possible to include their content in the message body o It is not possible to include their content in the message body
(usually because a format does not allow it). (usually because a format does not allow it).
New header fields MUST be registered, as per [RFC7231] and [RFC3864]. New header fields MUST be registered, as per [RFC7231] and [RFC3864].
See [RFC7231], Section 8.3.1 for guidelines to consider when minting
new header fields. [I-D.ietf-httpbis-header-structure] provides a
common structure for new header fields, and avoids many issues in
their parsing and handling; it is RECOMMENDED that new header fields
use it.
It is RECOMMENDED that header field names be short (even when HTTP/2 It is RECOMMENDED that header field names be short (even when HTTP/2
header compression is in effect, there is an overhead) but header compression is in effect, there is an overhead) but
appropriately specific. In particular, if a header field is specific appropriately specific. In particular, if a header field is specific
to an application, an identifier for that application SHOULD form a to an application, an identifier for that application SHOULD form a
prefix to the header field name, separated by a "-". prefix to the header field name, separated by a "-".
For example, if the "example" application needs to create three For example, if the "example" application needs to create three
headers, they might be called "example-foo", "example-bar" and headers, they might be called "example-foo", "example-bar" and
"example-baz". Note that the primary motivation here is to avoid "example-baz". Note that the primary motivation here is to avoid
consuming more generic header names, not to reserve a portion of the consuming more generic header names, not to reserve a portion of the
skipping to change at page 16, line 10 skipping to change at page 17, line 10
without updating their registration or defining an extension to them without updating their registration or defining an extension to them
(if allowed). For example, an application using HTTP cannot specify (if allowed). For example, an application using HTTP cannot specify
that the "Location" header has a special meaning in a certain that the "Location" header has a special meaning in a certain
context. context.
See Section 4.9 for the interaction between headers and HTTP caching; See Section 4.9 for the interaction between headers and HTTP caching;
in particular, request headers that are used to "select" a response in particular, request headers that are used to "select" a response
have impact there, and need to be carefully considered. have impact there, and need to be carefully considered.
See Section 4.10 for considerations regarding header fields that See Section 4.10 for considerations regarding header fields that
carry application state (e.g,. Cookie). carry application state (e.g., Cookie).
4.8. Defining Message Payloads 4.8. Defining Message Payloads
There are many potential formats for payloads; for example, JSON There are many potential formats for payloads; for example, JSON
[RFC8259], XML [XML], and CBOR [RFC7049]. Best practices for their [RFC8259], XML [XML], and CBOR [RFC7049]. Best practices for their
use are out of scope for this document. use are out of scope for this document.
Applications SHOULD register distinct media types for each format Applications SHOULD register distinct media types for each format
they define; this makes it possible to identify them unambiguously they define; this makes it possible to identify them unambiguously
and negotiate for their use. See [RFC6838] for more information. and negotiate for their use. See [RFC6838] for more information.
skipping to change at page 16, line 35 skipping to change at page 17, line 35
for applications; it provides scalability, reduces latency and for applications; it provides scalability, reduces latency and
improves reliability. Furthermore, HTTP caches are readily available improves reliability. Furthermore, HTTP caches are readily available
in browsers and other clients, networks as forward and reverse in browsers and other clients, networks as forward and reverse
proxies, Content Delivery Networks and as part of server software. proxies, Content Delivery Networks and as part of server software.
Assigning even a short freshness lifetime ([RFC7234], Section 4.2) - Assigning even a short freshness lifetime ([RFC7234], Section 4.2) -
e.g., 5 seconds - allows a response to be reused to satisfy multiple e.g., 5 seconds - allows a response to be reused to satisfy multiple
clients, and/or a single client making the same request repeatedly. clients, and/or a single client making the same request repeatedly.
In general, if it is safe to reuse something, consider assigning a In general, if it is safe to reuse something, consider assigning a
freshness lifetime; cache implementations take active measures to freshness lifetime; cache implementations take active measures to
expire content intelligently when they are out of space, so "it will remove content intelligently when they are out of space, so "it will
fill up the cache" is not a valid concern. fill up the cache" is not a valid concern.
Understand that stale responses (e.g., one with "Cache-Control: max- Understand that stale responses (e.g., one with "Cache-Control: max-
age=0") can be reused when the cache is disconnected from the origin age=0") can be reused when the cache is disconnected from the origin
server; this can be useful for handling network issues. See server; this can be useful for handling network issues. See
[RFC7234], Section 4.2.4, and also [RFC5861] for additional controls [RFC7234], Section 4.2.4, and also [RFC5861] for additional controls
over stale content. over stale content.
Stale responses can be refreshed by assigning a validator, saving Stale responses can be refreshed by assigning a validator, saving
both transfer bandwidth and latency for large responses; see both transfer bandwidth and latency for large responses; see
[RFC7232]. [RFC7232].
If an application defines a request header field that might be used
by a server to change the response's headers or body, authors should
point out that this has implications for caching; in general, such
resources need to either make their responses uncacheable (e.g., with
the "no-store" cache-control directive defined in [RFC7234],
Section 5.2.2.3) or consistently send the Vary response header
([RFC7231], Section 7.1.4).
For example, this response:
HTTP/1.1 200 OK
Content-Type: application/example+xml
Cache-Control: max-age=60
ETag: "sa0f8wf20fs0f"
Vary: Accept-Encoding
[content]
can be stored for 60 seconds by both private and shared caches, can
be revalidated with If-None-Match, and varies on the Accept-Encoding
request header field.
In some situations, responses without explicit cache directives In some situations, responses without explicit cache directives
(e.g., Cache-Control or Expires) will be stored and served using a (e.g., Cache-Control or Expires) will be stored and served using a
heuristic freshness lifetime; see [RFC7234], Section 4.2.2. As the heuristic freshness lifetime; see [RFC7234], Section 4.2.2. As the
heuristic is not under control of the application, it is generally heuristic is not under control of the application, it is generally
preferable to set an explicit freshness lifetime. preferable to set an explicit freshness lifetime.
If caching of a response is not desired, the appropriate response If caching of a response is not desired, the appropriate response
directive is "Cache-Control: no-store". This only need be sent in directive is "Cache-Control: no-store". This only need be sent in
situations where the response might be cached; see [RFC7234], situations where the response might be cached; see [RFC7234],
Section 3. Section 3. Note that "Cache-Control: no-cache" allows a response to
be stored, just not reused by a cache; it does not prevent caching
(despite its name).
If an application defines a request header field that might be used For example, this response cannot be stored or reused by a cache:
by a server to change the response's headers or body, authors should
point out that this has implications for caching; in general, such HTTP/1.1 200 OK
resources need to either make their responses uncacheable (e.g., with Content-Type: application/example+xml
the "no-store" cache-control directive defined in [RFC7234], Cache-Control: no-store
Section 5.2.2.3) or consistently send the Vary response header
([RFC7231], Section 7.1.4). [content]
When an application has a need to express a lifetime that's separate When an application has a need to express a lifetime that's separate
from the freshness lifetime, this should be expressed separately, from the freshness lifetime, this should be expressed separately,
either in the response's body or in a separate header field. When either in the response's body or in a separate header field. When
this happens, the relationship between HTTP caching and that lifetime this happens, the relationship between HTTP caching and that lifetime
need to be carefully considered, since the response will be used as need to be carefully considered, since the response will be used as
long as it is considered fresh. long as it is considered fresh.
Like other functions, HTTP caching is generic; it does not have Like other functions, HTTP caching is generic; it does not have
knowledge of the application in use. Therefore, caching extensions knowledge of the application in use. Therefore, caching extensions
skipping to change at page 18, line 27 skipping to change at page 20, line 5
be used with a Web browser, its resources will remain available to be used with a Web browser, its resources will remain available to
browsers and other HTTP clients. browsers and other HTTP clients.
This means that all such applications need to consider how browsers This means that all such applications need to consider how browsers
will interact with them, particularly regarding security. will interact with them, particularly regarding security.
For example, if an application's state can be changed using a POST For example, if an application's state can be changed using a POST
request, a Web browser can easily be coaxed into making that request request, a Web browser can easily be coaxed into making that request
by a HTML form on an arbitrary Web site. by a HTML form on an arbitrary Web site.
Or, if a resource reflects data from the request into a response, Or, If content returned from the application's resources is under
that can be used to perform a Cross-Site Scripting attack on Web control of an attacker (for example, part of the request is reflected
browsers directed to it. in the response, or the response contains external information that
might be under the control of the attacker), a cross-site scripting
attack is possible, whereby an attacker can inject code into the
browser and access data and capabilities on that origin.
This is only a small sample of the kinds of issues that applications This is only a small sample of the kinds of issues that applications
using HTTP must consider. Generally, the best approach is to using HTTP must consider. Generally, the best approach is to
consider the application _as_ a Web application, and to follow best consider the application _as_ a Web application, and to follow best
practices for their secure development. practices for their secure development.
A complete enumeration of such practices is out of scope for this A complete enumeration of such practices is out of scope for this
document, but some considerations include: document, but some considerations include:
o Using Strict Transport Security [RFC6797] to assure that HTTPS is o Using an application-specific media type in the Content-Type
used header, and requiring clients to fail if it is not used
o Using Content-Security-Policy [W3C.WD-CSP3-20160913] to constrain o Using X-Content-Type-Options: nosniff [FETCH]} to assure that
the capabilities of content, thereby mitigating Cross-Site content under attacker control can't be coaxed into a form that is
Scripting attacks (which are possible if client-provided data is interpreted as active content by a Web browser
exposed in any part of a response in the application)
o Using X-Frame-Options [RFC7034] to prevent content from being o Using Content-Security-Policy [CSP] to constrain the capabilities
included in a HTML frame from another origin, thereby enabling of active content (such as HTML [HTML5]), thereby mitigating
"clickjacking" Cross-Site Scripting attacks
o Using Referrer-Policy [W3C.CR-referrer-policy-20170126] to prevent o Using Referrer-Policy [REFERRER-POLICY] to prevent sensitive data
sensitive data in URLs from being leaked in the Referer request in URLs from being leaked in the Referer request header
header
o Using the 'HttpOnly' flag on Cookies to assure that cookies are o Using the 'HttpOnly' flag on Cookies to assure that cookies are
not exposed to browser scripting languages [RFC6265] not exposed to browser scripting languages [RFC6265]
o Avoiding use of compression on any sensitive information (e.g.,
authentication tokens, passwords), as the scripting environment
offered by Web browsers allows an attacker to repeatedly probe the
compression space; if the attacker has access to the path of the
communication, they can use this capability to recover that
information.
Depending on how they are intended to be deployed, specifications for Depending on how they are intended to be deployed, specifications for
applications using HTTP might require the use of these mechanisms in applications using HTTP might require the use of these mechanisms in
specific ways, or might merely point them out in Security specific ways, or might merely point them out in Security
Considerations. Considerations.
An example of a HTTP response from an application that does not
intend for its content to be treated as active by browsers might look
like this:
HTTP/1.1 200 OK
Content-Type: application/example+json
X-Content-Type-Options: nosniff
Content-Security-Policy: default-src 'none'
Cache-Control: max-age=3600
Referrer-Policy: no-referrer
[content]
If an application using HTTP has browser compatibility as a goal, If an application using HTTP has browser compatibility as a goal,
client interaction ought to be defined in terms of [FETCH], since client interaction ought to be defined in terms of [FETCH], since
that is the abstraction that browsers use for HTTP; it enforces many that is the abstraction that browsers use for HTTP; it enforces many
of these best practices. of these best practices.
4.13. Application Boundaries 4.13. Application Boundaries
Because the origin [RFC6454] is how many HTTP capabilities are Because the origin [RFC6454] is how many HTTP capabilities are
scoped, applications also need to consider how deployments might scoped, applications also need to consider how deployments might
interact with other applications (including Web browsing) on the same interact with other applications (including Web browsing) on the same
skipping to change at page 22, line 29 skipping to change at page 24, line 24
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8288] Nottingham, M., "Web Linking", RFC 8288, [RFC8288] Nottingham, M., "Web Linking", RFC 8288,
DOI 10.17487/RFC8288, October 2017, DOI 10.17487/RFC8288, October 2017,
<https://www.rfc-editor.org/info/rfc8288>. <https://www.rfc-editor.org/info/rfc8288>.
7.2. Informative References 7.2. Informative References
[CSP] West, M., "Content Security Policy Level 3", World Wide
Web Consortium WD WD-CSP3-20160913, September 2016,
<https://www.w3.org/TR/2016/WD-CSP3-20160913>.
[FETCH] WHATWG, "Fetch - Living Standard", n.d., [FETCH] WHATWG, "Fetch - Living Standard", n.d.,
<https://fetch.spec.whatwg.org>. <https://fetch.spec.whatwg.org>.
[FTP] Postel, J. and J. Reynolds, "File Transfer Protocol",
STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985,
<https://www.rfc-editor.org/info/rfc959>.
[HTML5] WHATWG, "HTML - Living Standard", n.d., [HTML5] WHATWG, "HTML - Living Standard", n.d.,
<https://html.spec.whatwg.org>. <https://html.spec.whatwg.org>.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [I-D.ietf-httpbis-header-structure]
RFC 793, DOI 10.17487/RFC0793, September 1981, Nottingham, M. and P. Kamp, "Structured Headers for HTTP",
<https://www.rfc-editor.org/info/rfc793>. draft-ietf-httpbis-header-structure-04 (work in progress),
March 2018.
[RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol [IPP] Sweet, M. and I. McDonald, "Internet Printing
Specification", STD 8, RFC 854, DOI 10.17487/RFC0854, May Protocol/1.1: Model and Semantics", RFC 8011,
1983, <https://www.rfc-editor.org/info/rfc854>. DOI 10.17487/RFC8011, January 2017,
<https://www.rfc-editor.org/info/rfc8011>.
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", [REFERRER-POLICY]
STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985, Eisinger, J. and E. Stark, "Referrer Policy", World Wide
<https://www.rfc-editor.org/info/rfc959>. Web Consortium CR CR-referrer-policy-20170126, January
2017,
<https://www.w3.org/TR/2017/CR-referrer-policy-20170126>.
[RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol", [RESTCONF]
RFC 2821, DOI 10.17487/RFC2821, April 2001, Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
<https://www.rfc-editor.org/info/rfc2821>. Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>.
[RFC3205] Moore, K., "On the use of HTTP as a Substrate", BCP 56, [RFC3205] Moore, K., "On the use of HTTP as a Substrate", BCP 56,
RFC 3205, DOI 10.17487/RFC3205, February 2002, RFC 3205, DOI 10.17487/RFC3205, February 2002,
<https://www.rfc-editor.org/info/rfc3205>. <https://www.rfc-editor.org/info/rfc3205>.
[RFC4367] Rosenberg, J., Ed. and IAB, "What's in a Name: False [RFC4367] Rosenberg, J., Ed. and IAB, "What's in a Name: False
Assumptions about DNS Names", RFC 4367, Assumptions about DNS Names", RFC 4367,
DOI 10.17487/RFC4367, February 2006, DOI 10.17487/RFC4367, February 2006,
<https://www.rfc-editor.org/info/rfc4367>. <https://www.rfc-editor.org/info/rfc4367>.
[RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault,
"Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791,
DOI 10.17487/RFC4791, March 2007, DOI 10.17487/RFC4791, March 2007,
<https://www.rfc-editor.org/info/rfc4791>. <https://www.rfc-editor.org/info/rfc4791>.
[RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed
Authoring and Versioning (WebDAV)", RFC 4918,
DOI 10.17487/RFC4918, June 2007,
<https://www.rfc-editor.org/info/rfc4918>.
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
Uniform Resource Identifiers (URIs)", RFC 5785, Uniform Resource Identifiers (URIs)", RFC 5785,
DOI 10.17487/RFC5785, April 2010, DOI 10.17487/RFC5785, April 2010,
<https://www.rfc-editor.org/info/rfc5785>. <https://www.rfc-editor.org/info/rfc5785>.
[RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale [RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale
Content", RFC 5861, DOI 10.17487/RFC5861, May 2010, Content", RFC 5861, DOI 10.17487/RFC5861, May 2010,
<https://www.rfc-editor.org/info/rfc5861>. <https://www.rfc-editor.org/info/rfc5861>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011, DOI 10.17487/RFC6265, April 2011,
<https://www.rfc-editor.org/info/rfc6265>. <https://www.rfc-editor.org/info/rfc6265>.
[RFC6415] Hammer-Lahav, E., Ed. and B. Cook, "Web Host Metadata",
RFC 6415, DOI 10.17487/RFC6415, October 2011,
<https://www.rfc-editor.org/info/rfc6415>.
[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol",
RFC 6455, DOI 10.17487/RFC6455, December 2011, RFC 6455, DOI 10.17487/RFC6455, December 2011,
<https://www.rfc-editor.org/info/rfc6455>. <https://www.rfc-editor.org/info/rfc6455>.
[RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict
Transport Security (HSTS)", RFC 6797,
DOI 10.17487/RFC6797, November 2012,
<https://www.rfc-editor.org/info/rfc6797>.
[RFC7034] Ross, D. and T. Gondrom, "HTTP Header Field X-Frame-
Options", RFC 7034, DOI 10.17487/RFC7034, October 2013,
<https://www.rfc-editor.org/info/rfc7034>.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <https://www.rfc-editor.org/info/rfc7049>. October 2013, <https://www.rfc-editor.org/info/rfc7049>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <https://www.rfc-editor.org/info/rfc7258>. 2014, <https://www.rfc-editor.org/info/rfc7258>.
[RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines [RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines
and Registration Procedures for URI Schemes", BCP 35, and Registration Procedures for URI Schemes", BCP 35,
skipping to change at page 24, line 36 skipping to change at page 26, line 44
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259, Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017, DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>. <https://www.rfc-editor.org/info/rfc8259>.
[SECCTXT] West, M., "Secure Contexts", World Wide Web Consortium CR [SECCTXT] West, M., "Secure Contexts", World Wide Web Consortium CR
CR-secure-contexts-20160915, September 2016, CR-secure-contexts-20160915, September 2016,
<https://www.w3.org/TR/2016/CR-secure-contexts-20160915>. <https://www.w3.org/TR/2016/CR-secure-contexts-20160915>.
[W3C.CR-referrer-policy-20170126] [SMTP] Klensin, J., Ed., "Simple Mail Transfer Protocol",
Eisinger, J. and E. Stark, "Referrer Policy", World Wide RFC 2821, DOI 10.17487/RFC2821, April 2001,
Web Consortium CR CR-referrer-policy-20170126, January <https://www.rfc-editor.org/info/rfc2821>.
2017,
<https://www.w3.org/TR/2017/CR-referrer-policy-20170126>.
[W3C.WD-CSP3-20160913] [TELNET] Postel, J. and J. Reynolds, "Telnet Protocol
West, M., "Content Security Policy Level 3", World Wide Specification", STD 8, RFC 854, DOI 10.17487/RFC0854, May
Web Consortium WD WD-CSP3-20160913, September 2016, 1983, <https://www.rfc-editor.org/info/rfc854>.
<https://www.w3.org/TR/2016/WD-CSP3-20160913>.
[XML] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and [XML] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and
F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
Edition)", World Wide Web Consortium Recommendation REC- Edition)", World Wide Web Consortium Recommendation REC-
xml-20081126, November 2008, xml-20081126, November 2008,
<http://www.w3.org/TR/2008/REC-xml-20081126>. <http://www.w3.org/TR/2008/REC-xml-20081126>.
7.3. URIs 7.3. URIs
[1] https://lists.w3.org/Archives/Public/ietf-http-wg/ [1] https://lists.w3.org/Archives/Public/ietf-http-wg/
 End of changes. 58 change blocks. 
174 lines changed or deleted 274 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/