< draft-ietf-httpbis-bcp56bis-11.txt   draft-ietf-httpbis-bcp56bis-12.txt >
HTTP M. Nottingham HTTP M. Nottingham
Internet-Draft 17 March 2021 Internet-Draft 27 April 2021
Obsoletes: 3205 (if approved) Obsoletes: 3205 (if approved)
Intended status: Best Current Practice Intended status: Best Current Practice
Expires: 18 September 2021 Expires: 29 October 2021
Building Protocols with HTTP Building Protocols with HTTP
draft-ietf-httpbis-bcp56bis-11 draft-ietf-httpbis-bcp56bis-12
Abstract Abstract
HTTP is often used as a substrate for other application protocols to Applications often use HTTP as a substrate to create HTTP-based APIs.
create HTTP-based APIs. This document specifies best practices for This document specifies best practices for writing specifications
writing specifications that use HTTP to define new application that use HTTP to define new application protocols. It is written
protocols, especially when they are defined for diverse primarily to guide IETF efforts to define application protocols using
implementation and broad deployment (e.g., in standards efforts). HTTP for deployment on the Internet, but might be applicable in other
situations.
Note to Readers Note to Readers
_RFC EDITOR: please remove this section before publication_ _RFC EDITOR: please remove this section before publication_
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/ https://lists.w3.org/Archives/Public/ietf-http-wg/
(https://lists.w3.org/Archives/Public/ietf-http-wg/). (https://lists.w3.org/Archives/Public/ietf-http-wg/).
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 18 September 2021. This Internet-Draft will expire on 29 October 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 20 skipping to change at page 3, line 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 27 6. Security Considerations . . . . . . . . . . . . . . . . . . . 27
6.1. Privacy Considerations . . . . . . . . . . . . . . . . . 28 6.1. Privacy Considerations . . . . . . . . . . . . . . . . . 28
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
7.1. Normative References . . . . . . . . . . . . . . . . . . 29 7.1. Normative References . . . . . . . . . . . . . . . . . . 29
7.2. Informative References . . . . . . . . . . . . . . . . . 30 7.2. Informative References . . . . . . . . . . . . . . . . . 30
Appendix A. Changes from RFC 3205 . . . . . . . . . . . . . . . 33 Appendix A. Changes from RFC 3205 . . . . . . . . . . . . . . . 33
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 33 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
HTTP [I-D.ietf-httpbis-semantics] is often used as a substrate for Applications other than Web browsing often use HTTP
applications other than Web browsing; this is sometimes referred to [I-D.ietf-httpbis-semantics] as a substrate, a practice sometimes
as creating "HTTP-based APIs", "REST APIs" or just "HTTP APIs". This referred to as creating "HTTP-based APIs", "REST APIs" or just "HTTP
is done for a variety of reasons, including: APIs". This is done for a variety of reasons, including:
* familiarity by implementers, specifiers, administrators, * familiarity by implementers, specifiers, administrators,
developers and users, developers and users,
* availability of a variety of client, server and proxy * availability of a variety of client, server and proxy
implementations, implementations,
* ease of use, * ease of use,
* availability of Web browsers, * availability of Web browsers,
skipping to change at page 4, line 5 skipping to change at page 4, line 5
deployment by one or a few servers, and consumption by a limited set deployment by one or a few servers, and consumption by a limited set
of clients. As a result, a body of practices and tools has arisen of clients. As a result, a body of practices and tools has arisen
around defining HTTP-based APIs that favours these conditions. around defining HTTP-based APIs that favours these conditions.
However, when such an application has multiple, separate However, when such an application has multiple, separate
implementations, is deployed on multiple uncoordinated servers, and implementations, is deployed on multiple uncoordinated servers, and
is consumed by diverse clients -- as is often the case for HTTP APIs is consumed by diverse clients -- as is often the case for HTTP APIs
defined by standards efforts -- tools and practices intended for defined by standards efforts -- tools and practices intended for
limited deployment can become unsuitable. limited deployment can become unsuitable.
This is largely because implementations (both client and server) will This mismatch is largely because the API's clients and servers will
implement and evolve at different paces, and because deployments will implement and evolve at different paces, leading to a need for
often have different features and versions available. As a result, deployments with different features and versions to co-exist. As a
the designers of such an HTTP-based API will need to more carefully result, the designers of HTTP-based APIs intended for such
consider how extensibility of the service will be handled and how deployments need to more carefully consider how extensibility of the
different deployment requirements will be accommodated. service will be handled and how different deployment requirements
will be accommodated.
More generally, an application protocol using HTTP faces a number of More generally, an application protocol using HTTP faces a number of
design decisions, including: design decisions, including:
* Should it define a new URI scheme? Use new ports? * Should it define a new URI scheme? Use new ports?
* Should it use standard HTTP methods and status codes, or define * Should it use standard HTTP methods and status codes, or define
new ones? new ones?
* How can the maximum value be extracted from the use of HTTP? * How can the maximum value be extracted from the use of HTTP?
* How does it coexist with other uses of HTTP -- especially Web * How does it coexist with other uses of HTTP -- especially Web
browsing? browsing?
* How can interoperability problems and "protocol dead ends" be * How can interoperability problems and "protocol dead ends" be
avoided? avoided?
This document contains best current practices for the specification This document contains best current practices for the specification
of such applications. Section 2 defines when it applies; Section 3 of such applications. Section 2 defines when it applies; Section 3
surveys the properties of HTTP that are important to preserve, and surveys the properties of HTTP that are important to preserve, and
Section 4 conveys best practices for the specifying them. Section 4 conveys best practices for specifying them.
It is written primarily to guide IETF efforts to define application It is written primarily to guide IETF efforts to define application
protocols using HTTP for deployment on the Internet, but might be protocols using HTTP for deployment on the Internet, but might be
applicable in other situations. Note that the requirements herein do applicable in other situations. Note that the requirements herein do
not necessarily apply to the development of generic HTTP extensions. not necessarily apply to the development of generic HTTP extensions.
1.1. Notational Conventions 1.1. Notational Conventions
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
skipping to change at page 5, line 4 skipping to change at page 5, line 6
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. The Different applications have different goals when using HTTP. The
requirements in this document apply when a specification defines an requirements in this document apply when a specification defines an
application that: application that:
* uses the transport port 80 or 443, or * uses the transport port 80 or 443, or
* uses the URI scheme "http" or "https", or * uses the URI scheme "http" or "https", or
* uses an ALPN protocol ID [RFC7301] that generically identifies * uses an ALPN protocol ID [RFC7301] that generically identifies
HTTP (e.g., "http/1.1", "h2", "h2c"), or HTTP (e.g., "http/1.1", "h2", "h2c"), or
* updates or modifies the IANA registries defined for HTTP. * updates or modifies the IANA registries defined for HTTP.
Additionally, when a specification is using HTTP, all of the Additionally, when a specification is using HTTP, all of the
requirements of the HTTP protocol suite are in force (in particular, requirements of the HTTP protocol suite are in force (in particular,
[I-D.ietf-httpbis-semantics], but also other specifications as [I-D.ietf-httpbis-semantics], but also other specifications as
appropriate). appropriate).
Note that this document is intended to apply to applications, not Note that this document is intended to apply to applications, not
generic extensions to HTTP, which follow the requirements in the generic extensions to HTTP. Furthermore, while it is intended for
relevant specification. Furthermore, it is intended for applications IETF-specified applications, other standards organisations are
defined by IETF specifications, although other standards encouraged to adhere to its requirements.
organisations are encouraged to adhere to its requirements.
2.1. Non-HTTP Protocols 2.1. Non-HTTP Protocols
A specification might not use HTTP according to the criteria above An application can rely upon HTTP without meeting the criteria for
and still define an application that relies upon HTTP in some manner. using it defined above. For example, an application might wish to
For example, an application might wish to avoid re-specifying parts avoid re-specifying parts of the message format, but change other
of the message format, but change other aspects of the protocol's aspects of the protocol's operation; or, it might want to use a
operation; or, it might want to use a different set of methods. different set of methods.
Doing so brings more freedom to modify protocol operations, but loses Doing so brings more freedom to modify protocol operations, but loses
at least a portion of the benefits outlined above, as most HTTP at least a portion of the benefits outlined above, as most HTTP
implementations won't be easily adaptable to these changes, and as implementations won't be easily adaptable to these changes, and the
the protocol diverges from HTTP, the benefit of mindshare will be benefit of mindshare will be lost.
lost.
Such specifications MUST NOT use HTTP's URI schemes, transport ports, Such specifications MUST NOT use HTTP's URI schemes, transport ports,
ALPN protocol IDs or IANA registries; rather, they are encouraged to ALPN protocol IDs or IANA registries; rather, they are encouraged to
establish their own. establish their own.
3. What's Important About HTTP 3. What's Important About HTTP
This section examines the characteristics of the HTTP protocol that This section examines the characteristics of HTTP that are important
are important to consider when using HTTP to define an application to consider when using HTTP to define an application protocol.
protocol.
3.1. Generic Semantics 3.1. Generic Semantics
Much of the value of HTTP is in its generic semantics -- that is, the Much of the value of HTTP is in its generic semantics -- that is, the
protocol elements defined by HTTP are potentially applicable to every protocol elements defined by HTTP are potentially applicable to every
resource, not specific to a particular context. Application-specific resource, not specific to a particular context. Application-specific
semantics are best expressed in message content and in header fields, semantics are best expressed in message content and in header fields,
not status codes or methods -- although the latter do have generic not status codes or methods (although the latter do have generic
semantics that relate to application state. semantics that relate to application state).
This generic/application-specific split allows a HTTP message to be This generic/application-specific split allows a HTTP message to be
handled by software (e.g., HTTP servers, intermediaries, client handled by common software (e.g., HTTP servers, intermediaries,
implementations, and caches) without understanding the specific client implementations, and caches) without understanding the
application. It also allows people to leverage their knowledge of specific application. It also allows people to leverage their
HTTP semantics without special-casing them for a particular knowledge of HTTP semantics without special-casing them for a
application. 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 generic protocol elements such as methods, overlay the semantics of generic protocol elements such as methods,
status codes or existing header fields. Instead, they should focus status codes or existing header fields. Instead, they should focus
their specifications on protocol elements that are specific to that their specifications on protocol elements that are specific to that
application; namely their HTTP resources. application; namely their HTTP resources.
When writing a specification, it's often tempting to specify exactly When writing a specification, it's often tempting to specify exactly
how HTTP is to be implemented, supported and used. However, this can how HTTP is to be implemented, supported and used. However, this can
easily lead to an unintended profile of HTTP's behaviour. For easily lead to an unintended profile of HTTP's behaviour. For
skipping to change at page 8, line 29 skipping to change at page 8, line 29
is a good starting point. is a good starting point.
4. Best Practices for Specifying the Use of HTTP 4. Best Practices for Specifying the Use of HTTP
This section contains best practices for specifying the use of HTTP This section contains best practices for specifying the use of HTTP
by applications, including practices for specific HTTP protocol by applications, including practices for specific HTTP protocol
elements. elements.
4.1. Specifying the Use of HTTP 4.1. Specifying the Use of HTTP
When specifying the use of HTTP, an application should use Specifications should use [I-D.ietf-httpbis-semantics] as the primary
[I-D.ietf-httpbis-semantics] as the primary reference; it is not reference for HTTP; it is not necessary to reference all of the
necessary to reference all of the specifications in the HTTP suite specifications in the HTTP suite unless there are specific reasons to
unless there are specific reasons to do so (e.g., a particular do so (e.g., a particular feature is called out).
feature is called out).
Because it is a hop-by-hop protocol, a HTTP connection can be handled Because HTTP is a hop-by-hop protocol, a connection can be handled by
by implementations that are not controlled by the application; for implementations that are not controlled by the application; for
example, proxies, CDNs, firewalls and so on. Requiring a particular example, proxies, CDNs, firewalls and so on. Requiring a particular
version of HTTP makes it difficult to use in these situations, and version of HTTP makes it difficult to use in these situations, and
harms interoperability. Therefore, it is RECOMMENDED that harms interoperability. Therefore, it is NOT RECOMMENDED that
applications using HTTP not specify a minimum version of HTTP to be applications using HTTP specify a minimum version of HTTP to be used.
used.
However, if an application's deployment would benefit from the use of However, if an application's deployment would benefit from the use of
a particular version of HTTP (for example, HTTP/2's multiplexing), a particular version of HTTP (for example, HTTP/2's multiplexing),
this ought be noted. this ought be noted.
Applications using HTTP MUST NOT specify a maximum version, to Applications using HTTP MUST NOT specify a maximum version, to
preserve the protocol's ability to evolve. preserve the protocol's ability to evolve.
When specifying examples of protocol interactions, applications When specifying examples of protocol interactions, applications
should document both the request and response messages, with complete should document both the request and response messages, with complete
skipping to change at page 9, line 19 skipping to change at page 9, line 19
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: application/things+json Content-Type: application/things+json
Content-Length: 500 Content-Length: 500
Server: Bar/2.2 Server: Bar/2.2
[content here] [content here]
4.2. Specifying Server Behaviour 4.2. Specifying Server Behaviour
The most effective way to specify an application's server-side HTTP The server-side behaviours of an application are most effectively
behaviours is in terms of the following protocol elements: specified by defining the following protocol elements:
* Media types [RFC6838], often based upon a format convention such * Media types [RFC6838], often based upon a format convention such
as JSON [RFC8259], as JSON [RFC8259],
* HTTP header fields, as per Section 4.7, and * HTTP header fields, as per Section 4.7, and
* The behaviour of resources, as identified by link relations * The behaviour of resources, as identified by link relations
[RFC8288]. [RFC8288].
By composing these protocol elements, an application can define a set An application can define its operation by composing these protocol
of resources, identified by link relations, that implement specified elements to define a set of resources that are identified by link
behaviours, including: relations and that implement specified behaviours, including:
* retrieval of their state using GET, in one or more formats * retrieval of their state using GET, in one or more formats
identified by media type; identified by media type;
* resource creation or update using POST or PUT, with an * resource creation or update using POST or PUT, with an
appropriately identified request content format; appropriately identified request content format;
* data processing using POST and identified request and response * data processing using POST and identified request and response
content format(s); and content format(s); and
skipping to change at page 10, line 23 skipping to change at page 10, line 23
The "application/example-widget+json" format is a JSON [RFC8259] The "application/example-widget+json" format is a JSON [RFC8259]
format representing the state of a Widget. It contains links to format representing the state of a Widget. It contains links to
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.
Applications can also specify the use of URI Templates [RFC6570] to Applications can also specify the use of URI Templates [RFC6570] to
allow clients to generate URLs based upon runtime data. allow clients to generate URLs based upon runtime data.
4.3. Specifying Client Behaviour 4.3. Specifying Client Behaviour
In general, applications using HTTP ought to align their expectations An application's expectations for client behaviour ought to be
for client behaviour as closely as possible with that of Web closely aligned with those of Web browsers, to avoid interoperability
browsers, to avoid interoperability issues when they are used. issues when they are used.
One way to do this is to define it in terms of [FETCH], since that is One way to do this is to define it in terms of [FETCH], since that is
the abstraction that browsers use for HTTP. the abstraction that browsers use for HTTP.
Some client behaviours (e.g., automatic redirect handling) and Some client behaviours (e.g., automatic redirect handling) and
extensions (e.g., Cookies) are not required by HTTP, but nevertheless extensions (e.g., Cookies) are not required by HTTP, but nevertheless
have become very common. If their use is not explicitly specified by have become very common. If their use is not explicitly specified by
applications using HTTP, there may be confusion and interoperability applications using HTTP, there may be confusion and interoperability
problems. In particular: problems. In particular:
* Redirect handling - Applications need to specify how redirects are * Redirect handling - Applications need to specify how redirects are
expected to be handled; see Section 4.6.1. expected to be handled; see Section 4.6.1.
* Cookies - Applications using HTTP should explicitly reference the * Cookies - Applications using HTTP should explicitly reference the
Cookie specification [I-D.ietf-httpbis-rfc6265bis] if they are Cookie specification [RFC6265] if they are required.
required.
* Certificates - Applications using HTTP should specify that TLS * Certificates - Applications using HTTP should specify that TLS
certificates are to be checked according to certificates are to be checked according to Section 4.3.4 of
[I-D.ietf-httpbis-semantics], Section 4.3.4 when HTTPS is used. [I-D.ietf-httpbis-semantics] when HTTPS is used.
Applications using HTTP should not statically require HTTP features Applications using HTTP should not statically require HTTP features
that are usually negotiated to be supported by clients. For example, that are usually negotiated to be supported by clients. For example,
requiring that clients support responses with a certain content- requiring that clients support responses with a certain content-
coding ([I-D.ietf-httpbis-semantics], Section 8.4.1) instead of coding ([I-D.ietf-httpbis-semantics], Section 8.4.1) instead of
negotiating for it ([I-D.ietf-httpbis-semantics], Section 12.5.3) negotiating for it ([I-D.ietf-httpbis-semantics], Section 12.5.3)
means that otherwise conformant clients cannot interoperate with the means that otherwise conformant clients cannot interoperate with the
application. Applications can encourage the implementation of such application. Applications can encourage the implementation of such
features, though. features, though.
4.4. Specifying URLs 4.4. Specifying URLs
In HTTP, the server resources that clients interact with are In HTTP, the resources that clients interact with are identified with
identified with URLs [RFC3986]. As [RFC8820] explains, parts of the URLs [RFC3986]. As [RFC8820] explains, parts of the URL are designed
URL are designed to be under the control of the owner (also known as to be under the control of the owner (also known as the "authority")
the "authority") of that server, to give them the flexibility in of that server, to give them the flexibility in deployment.
deployment.
This means that in most cases, specifications for applications that This means that in most cases, specifications for applications that
use HTTP won't contain its URLs; while it is common practice for a use HTTP won't contain its URLs; while it is common practice for a
specification of a single-deployment API to specify the path prefix specification of a single-deployment API to specify the path prefix
"/app/v1" (for example), doing so in an IETF specification is "/app/v1" (for example), doing so in an IETF specification is
inappropriate. inappropriate.
Therefore, the specification writer needs some mechanism to allow Therefore, the specification writer needs some mechanism to allow
clients to discovery an application's URLs. Additionally, they need clients to discovery an application's URLs. Additionally, they need
to specify what URL scheme(s) the application should be used with, to specify what URL scheme(s) the application should be used with,
skipping to change at page 13, line 19 skipping to change at page 13, line 19
* The resources identified by the new scheme will still be available * The resources identified by the new scheme will still be available
using "http" and/or "https" URLs. Those URLs can "leak" into use, using "http" and/or "https" URLs. Those URLs can "leak" into use,
which can present security and operability issues. For example, which can present security and operability issues. For example,
using a new scheme to assure that requests don't get sent to a using a new scheme to assure that requests don't get sent to a
"normal" Web site is likely to fail. "normal" Web site is likely to fail.
* Features that rely upon the URL's origin [RFC6454], such as the * Features that rely upon the URL's origin [RFC6454], such as the
Web's same-origin policy, will be impacted by a change of scheme. Web's same-origin policy, will be impacted by a change of scheme.
* HTTP-specific features such as cookies * HTTP-specific features such as cookies [RFC6265], authentication
[I-D.ietf-httpbis-rfc6265bis], authentication
[I-D.ietf-httpbis-semantics], caching [I-D.ietf-httpbis-cache], [I-D.ietf-httpbis-semantics], caching [I-D.ietf-httpbis-cache],
HSTS [RFC6797], and CORS [FETCH] might or might not work HSTS [RFC6797], and CORS [FETCH] might or might not work
correctly, depending on how they are defined and implemented. correctly, depending on how they are defined and implemented.
Generally, they are designed and implemented with an assumption Generally, they are designed and implemented with an assumption
that the URL will always be "http" or "https". that the URL will always be "http" or "https".
* Web features that require a secure context [SECCTXT] will likely * Web features that require a secure context [SECCTXT] will likely
treat a new scheme as insecure. treat a new scheme as insecure.
See [RFC7595] for more information about minting new URI schemes. See [RFC7595] for more information about minting new URI schemes.
skipping to change at page 14, line 30 skipping to change at page 14, line 30
encouraged to engage with the HTTP community early, and document encouraged to engage with the HTTP community early, and document
their proposal as a separate HTTP extension, rather than as part of their proposal as a separate HTTP extension, rather than as part of
an application's specification. an application's specification.
4.5.1. GET 4.5.1. GET
GET is the most common and useful HTTP method; its retrieval GET is the most common and useful HTTP method; its retrieval
semantics allow caching, side-effect free linking and underlies many semantics allow caching, side-effect free linking and underlies many
of the benefits of using HTTP. of the benefits of using HTTP.
A common use of GET is to perform queries, often using the query Queries can be performed with GET, often using the query component of
component of the URL; this is a familiar pattern from Web browsing, the URL; this is a familiar pattern from Web browsing, and the
and the results can be cached, improving efficiency of an often results can be cached, improving efficiency of an often expensive
expensive process. process. In some cases, however, GET might be unwieldy for
expressing queries, because of the limited syntax of the URI; in
In some cases, however, GET might be unwieldy for expressing queries, particular, if binary data forms part of the query terms, it needs to
because of the limited syntax of the URI; in particular, if binary be encoded to conform to URI syntax.
data forms part of the query terms, it needs to be encoded to conform
to URI 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 [I-D.ietf-httpbis-semantics]. 8000 octets, as required by [I-D.ietf-httpbis-semantics]).
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's content; doing so avoids encoding to express queries in the request's content; 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 should not change their state or have other side effects Applications should not change their state or have other side effects
skipping to change at page 17, line 16 skipping to change at page 17, line 16
applications using HTTP should explicitly point out that clients applications using HTTP should explicitly point out that clients
ought to be able to handle all applicable status codes gracefully ought to be able to handle all applicable status codes gracefully
(i.e., falling back to the generic "n00" semantics of a given status (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 code; e.g., "499" can be safely handled as "400" by clients that
don't recognise it). This is preferable to creating a "laundry list" don't recognise it). This is preferable to creating a "laundry list"
of potential status codes, since such a list won't be complete in the of potential status codes, since such a list won't be complete in the
foreseeable future. foreseeable future.
Applications using HTTP MUST NOT re-specify the semantics of HTTP Applications using HTTP MUST NOT re-specify the semantics of HTTP
status codes, even if it is only by copying their definition. It is status codes, even if it is only by copying their definition. It is
RECOMMENDED they require specific reason phrases to be used; the NOT RECOMMENDED they require specific reason phrases to be used; the
reason phrase has no function in HTTP, is not guaranteed to be reason phrase has no function in HTTP, is not guaranteed to be
preserved by implementations, and is not carried at all in the HTTP/2 preserved by implementations, and is not carried at all in the HTTP/2
[RFC7540] message format. [RFC7540] message format.
Applications MUST only use registered HTTP status codes. As with Applications MUST only use registered HTTP status codes. As with
methods, new HTTP status codes are rare, and required (by methods, new HTTP status codes are rare, and required (by
[I-D.ietf-httpbis-semantics]) to be registered with IETF Review. [I-D.ietf-httpbis-semantics]) to be registered with IETF Review.
Similarly, HTTP status codes are generic; they are required (by Similarly, HTTP status codes are generic; they are required (by
[I-D.ietf-httpbis-semantics]) to be potentially applicable to all [I-D.ietf-httpbis-semantics]) to be potentially applicable to all
resources, not just to those of one application. resources, not just to those of one application.
When authors believe that a new status code is required, they are When authors believe that a new status code is required, they are
encouraged to engage with the HTTP community early, and document encouraged to engage with the HTTP community early, and document
their proposal as a separate HTTP extension, rather than as part of their proposal as a separate HTTP extension, rather than as part of
an application's specification. an application's specification.
4.6.1. Redirection 4.6.1. Redirection
The 3xx series of status codes specified in The 3xx series of status codes specified in Section 15.4 of
[I-D.ietf-httpbis-semantics], Section 15.4 direct the user agent to [I-D.ietf-httpbis-semantics] direct the user agent to another
another resource to satisfy the request. The most common of these resource to satisfy the request. The most common of these are 301,
are 301, 302, 307 and 308, all of which use the Location response 302, 307 and 308, all of which use the Location response header field
header field to indicate where the client should send the request to. to indicate where the client should resend the request.
There are two ways that this group of status codes differ: There are two ways that the members of this group of status codes
differ:
* Whether they are permanent or temporary. Permanent redirects can * Whether they are permanent or temporary. Permanent redirects can
be used to update links stored in the client (e.g., bookmarks), be used to update links stored in the client (e.g., bookmarks),
whereas temporary ones can not. Note that this has no effect on whereas temporary ones can not. Note that this has no effect on
HTTP caching; it is completely separate. HTTP caching; it is completely separate.
* Whether they allow the redirected request to change the request * Whether they allow the redirected request to change the request
method from POST to GET. Web browsers generally do change POST to method from POST to GET. Web browsers generally do change POST to
GET for 301 and 302; therefore, 308 and 307 were created to allow GET for 301 and 302; therefore, 308 and 307 were created to allow
redirection without changing the method. redirection without changing the method.
skipping to change at page 18, line 19 skipping to change at page 18, line 19
+=============================+===========+===========+ +=============================+===========+===========+
| Allows changing the request | 301 | 302 | | Allows changing the request | 301 | 302 |
| method from POST to GET | | | | method from POST to GET | | |
+-----------------------------+-----------+-----------+ +-----------------------------+-----------+-----------+
| Does not allow changing the | 308 | 307 | | Does not allow changing the | 308 | 307 |
| request method | | | | request method | | |
+-----------------------------+-----------+-----------+ +-----------------------------+-----------+-----------+
Table 1 Table 1
The 303 See Other status code can be used to inform the client that
the result of an operation is available at a different location using
GET.
As noted in [I-D.ietf-httpbis-semantics], a user agent is allowed to As noted in [I-D.ietf-httpbis-semantics], a user agent is allowed to
automatically follow a 3xx redirect that has a Location response automatically follow a 3xx redirect that has a Location response
header field, even if they don't understand the semantics of the header field, even if they don't understand the semantics of the
specific status code. However, they aren't required to do so; specific status code. However, they aren't required to do so;
therefore, if an application using HTTP desires redirects to be therefore, if an application using HTTP desires redirects to be
automatically followed, it needs to explicitly specify the automatically followed, it needs to explicitly specify the
circumstances when this is required. circumstances when this is required.
Redirects can be cached (when appropriate cache directives are Redirects can be cached (when appropriate cache directives are
present), but beyond that they are not 'sticky' -- i.e., redirection present), but beyond that they are not 'sticky' -- i.e., redirection
of a URI will not result in the client assuming that similar URIs of a URI will not result in the client assuming that similar URIs
(e.g., with different query parameters) will also be redirected. (e.g., with different query parameters) will also be redirected.
Applications using HTTP are encouraged to specify that 301 and 302 Applications using HTTP are encouraged to specify that 301 and 302
responses change the subsequent request method from POST (but no responses change the subsequent request method from POST (but no
other method) to GET, to be compatible with browsers. Generally, other method) to GET, to be compatible with browsers. Generally,
when a redirected request is made, its header fields are copied from when a redirected request is made, its header fields are copied from
the original request's. However, they can be modified by various the original request's. However, they can be modified by various
mechanisms; e.g., sent Authorization ([I-D.ietf-httpbis-semantics]) mechanisms; e.g., sent Authorization ([I-D.ietf-httpbis-semantics],
and Cookie ([I-D.ietf-httpbis-rfc6265bis]) header fields will change Section 11) and Cookie ([RFC6265]) header fields will change if the
if the origin (and sometimes path) of the request changes. An origin (and sometimes path) of the request changes. An application
application using HTTP should specify if any request header fields using HTTP should specify if any request header fields that it
that it defines need to be modified or removed upon a redirect; defines need to be modified or removed upon a redirect; however, this
however, this behaviour cannot be relied upon, since a generic client behaviour cannot be relied upon, since a generic client (like a
(like a browser) will be unaware of such requirements. browser) will be unaware of such requirements.
4.7. Specifying HTTP Header Fields 4.7. Specifying HTTP Header Fields
Applications often define new HTTP header fields. Typically, using Applications often define new HTTP header fields. Typically, using
HTTP header fields is appropriate in a few different situations: HTTP header fields is appropriate in a few different situations:
* The field is useful to intermediaries (who often wish to avoid * The field is useful to intermediaries (who often wish to avoid
parsing message content), and/or parsing message content), and/or
* The field is useful to generic HTTP software (e.g., clients, * The field is useful to generic HTTP software (e.g., clients,
servers), and/or servers), and/or
* It is not possible to include their values in the message content * It is not possible to include their values in the message content
(usually because a format does not allow it). (usually because a format does not allow it).
When the conditions above are not met, it is usually better to convey When the conditions above are not met, it is usually better to convey
application-specific information in other places; e.g., the message application-specific information in other places; e.g., the message
content or the URL query string. content or the URL query string.
New header fields MUST be registered, as per New header fields MUST be registered, as per Section 16.3 of
[I-D.ietf-httpbis-semantics]. [I-D.ietf-httpbis-semantics].
See [I-D.ietf-httpbis-semantics], Section 16.3.2 for guidelines to See Section 16.3.2 of [I-D.ietf-httpbis-semantics] for guidelines to
consider when minting new header fields. [RFC8941] provides a common consider when minting new header fields. [RFC8941] provides a common
structure for new header fields, and avoids many issues in their structure for new header fields, and avoids many issues in their
parsing and handling; it is RECOMMENDED that new header fields use parsing and handling; it is RECOMMENDED that new header fields use
it. it.
It is RECOMMENDED that header field names be short (even when field It is RECOMMENDED that header field names be short (even when field
compression is used, there is an overhead) but appropriately compression is used, there is an overhead) but appropriately
specific. In particular, if a header field is specific to an specific. In particular, if a header field is specific to an
application, an identifier for that application can form a prefix to application, an identifier for that application can form a prefix to
the header field name, separated by a "-". the header field name, separated by a "-".
skipping to change at page 21, line 31 skipping to change at page 21, line 31
[content] [content]
4.9.2. Stale Responses 4.9.2. Stale Responses
Authors should understand that stale responses (e.g., with "Cache- Authors should understand that stale responses (e.g., with "Cache-
Control: max-age=0") can be reused by caches when disconnected from Control: max-age=0") can be reused by caches when disconnected from
the origin server; this can be useful for handling network issues. the origin server; this can be useful for handling network issues.
If doing so is not suitable for a given response, the origin should If doing so is not suitable for a given response, the origin should
use "Cache-Control: must-revalidate". See [I-D.ietf-httpbis-cache], use "Cache-Control: must-revalidate". See Section 4.2.4 of
Section 4.2.4, and also [RFC5861] for additional controls over stale [I-D.ietf-httpbis-cache], and also [RFC5861] for additional controls
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
[I-D.ietf-httpbis-semantics]. Section 13 of [I-D.ietf-httpbis-semantics].
4.9.3. Caching and Application Semantics 4.9.3. Caching and Application Semantics
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 conveyed separately, from the freshness lifetime, this should be conveyed separately,
either in the response's content or in a separate header field. When either in the response's content 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.
skipping to change at page 22, line 21 skipping to change at page 22, line 21
One way to address this is to explicitly specify that all responses One way to address this is to explicitly specify that all responses
be fresh upon use. be fresh upon use.
4.9.4. Varying Content Based Upon the Request 4.9.4. Varying Content Based Upon the Request
If an application uses a request header field to change the If an application uses a request header field to change the
response's header fields or content, authors should point out that response's header fields or content, authors should point out that
this has implications for caching; in general, such resources need to this has implications for caching; in general, such resources need to
either make their responses uncacheable (e.g., with the "no-store" either make their responses uncacheable (e.g., with the "no-store"
cache-control directive defined in [I-D.ietf-httpbis-cache], cache-control directive defined in [I-D.ietf-httpbis-cache],
Section 5.2.2.3) or send the Vary response header field Section 5.2.2.5) or send the Vary response header field
([I-D.ietf-httpbis-semantics], Section 12.5.5) on all responses from ([I-D.ietf-httpbis-semantics], Section 12.5.5) on all responses from
that resource (including the "default" response). that resource (including the "default" response).
For example, this response: For example, this response:
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: application/example+xml Content-Type: application/example+xml
Cache-Control: max-age=60 Cache-Control: max-age=60
ETag: "sa0f8wf20fs0f" ETag: "sa0f8wf20fs0f"
Vary: Accept-Encoding Vary: Accept-Encoding
[content] [content]
can be stored for 60 seconds by both private and shared caches, can 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 be revalidated with If-None-Match, and varies on the Accept-Encoding
request header field. request header field.
4.10. Handling Application State 4.10. Handling Application State
Applications can use stateful cookies [I-D.ietf-httpbis-rfc6265bis] Applications can use stateful cookies [RFC6265] to identify a client
to identify a client and/or store client-specific data to and/or store client-specific data to contextualise requests.
contextualise requests.
When used, it is important to carefully specify the scoping and use When used, it is important to carefully specify the scoping and use
of cookies; if the application exposes sensitive data or capabilities of cookies; if the application exposes sensitive data or capabilities
(e.g., by acting as an ambient authority), exploits are possible. (e.g., by acting as an ambient authority), exploits are possible.
Mitigations include using a request-specific token to assure the Mitigations include using a request-specific token to assure the
intent of the client. intent of the client.
4.11. Making Multiple Requests 4.11. Making Multiple Requests
Clients often need to send multiple requests to perform a task. Clients often need to send multiple requests to perform a task.
skipping to change at page 23, line 42 skipping to change at page 23, line 42
first has begun. first has begun.
Applications MUST NOT make assumptions about the relationship between Applications MUST NOT make assumptions about the relationship between
separate requests on a single transport connection; doing so breaks separate requests on a single transport connection; doing so breaks
many of the assumptions of HTTP as a stateless protocol, and will many of the assumptions of HTTP as a stateless protocol, and will
cause problems in interoperability, security, operability and cause problems in interoperability, security, operability and
evolution. evolution.
4.12. Client Authentication 4.12. Client Authentication
Applications can use HTTP authentication [I-D.ietf-httpbis-semantics] Applications can use HTTP authentication Section 11 of
to identify clients. The Basic authentication scheme [RFC7617] MUST [I-D.ietf-httpbis-semantics] to identify clients. The Basic
NOT be used unless the underlying transport is authenticated, authentication scheme [RFC7617] MUST NOT be used unless the
integrity-protected and confidential (e.g., as provided the "HTTPS" underlying transport is authenticated, integrity-protected and
URI scheme, or another using TLS). The Digest scheme [RFC7616] MUST confidential (e.g., as provided the "HTTPS" URI scheme, or another
NOT be used unless the underlying transport is similarly secure, or using TLS). The Digest scheme [RFC7616] MUST NOT be used unless the
the chosen hash algorithm is not "MD5". underlying transport is similarly secure, or the chosen hash
algorithm is not "MD5".
With HTTPS, clients might also be authenticated using certificates With HTTPS, clients might also be authenticated using certificates
[RFC5246]. [RFC5246].
When used, it is important to carefully specify the scoping and use When used, it is important to carefully specify the scoping and use
of authentication; if the application exposes sensitive data or of authentication; if the application exposes sensitive data or
capabilities (e.g., by acting as an ambient authority), exploits are capabilities (e.g., by acting as an ambient authority), exploits are
possible. Mitigations include using a request-specific token to possible. Mitigations include using a request-specific token to
assure the intent of the client. assure the intent of the client.
4.13. Co-Existing with Web Browsing 4.13. Co-Existing with Web Browsing
Even if there is not an intent for an application to be used with a Even if there is not an intent for an application to be used with a
Web browser, its resources will remain available to browsers and Web browser, its resources will remain available to browsers and
other HTTP clients. other HTTP clients. This means that all such applications that use
HTTP need to consider how browsers will interact with them,
This means that all such applications that use HTTP need to consider particularly regarding security.
how browsers 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 cross-site request request, a Web browser can easily be coaxed into cross-site request
forgery (CSRF) from arbitrary Web sites. forgery (CSRF) from arbitrary Web sites.
Or, if content returned from the application's resources is under Or, if an attacker gains control of content returned from the
control of an attacker (for example, part of the request is reflected application's resources (for example, part of the request is
in the response, or the response contains external information that reflected in the response, or the response contains external
might be under the control of the attacker), a cross-site scripting information that the attacker can change), they can inject code into
(XSS) attack is possible, whereby an attacker can inject code into the browser and access data and capabilities as if they were the
the browser and access data and capabilities on that origin. origin -- a technique known as a cross-site scripting (XSS) attack.
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 actually as a Web application, and to follow consider the application actually as a Web application, and to follow
best practices for their secure development. best 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:
* Using an application-specific media type in the Content-Type * Using an application-specific media type in the Content-Type
header field, and requiring clients to fail if it is not used. header field, and requiring clients to fail if it is not used.
* Using X-Content-Type-Options: nosniff [FETCH] to assure that * Using X-Content-Type-Options: nosniff [FETCH] to assure that
content under attacker control can't be coaxed into a form that is content under attacker control can't be coaxed into a form that is
interpreted as active content by a Web browser. interpreted as active content by a Web browser.
* Using Content-Security-Policy [CSP] to constrain the capabilities * Using Content-Security-Policy [CSP] to constrain the capabilities
of active content (such as HTML [HTML]), thereby mitigating Cross- of active content (i.e., that which can execute script, such as
Site Scripting attacks. HTML [HTML] and PDF), thereby mitigating Cross-Site Scripting
attacks.
* Using Referrer-Policy [REFERRER-POLICY] to prevent sensitive data * Using Referrer-Policy [REFERRER-POLICY] to prevent sensitive data
in URLs from being leaked in the Referer request header field. in URLs from being leaked in the Referer request header field.
* Using the 'HttpOnly' flag on Cookies to assure that cookies are * Using the 'HttpOnly' flag on Cookies to assure that cookies are
not exposed to browser scripting languages not exposed to browser scripting languages [RFC6265].
[I-D.ietf-httpbis-rfc6265bis].
* Avoiding use of compression on any sensitive information (e.g., * Avoiding use of compression on any sensitive information (e.g.,
authentication tokens, passwords), as the scripting environment authentication tokens, passwords), as the scripting environment
offered by Web browsers allows an attacker to repeatedly probe the offered by Web browsers allows an attacker to repeatedly probe the
compression space; if the attacker has access to the path of the compression space; if the attacker has access to the path of the
communication, they can use this capability to recover that communication, they can use this capability to recover that
information. 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
skipping to change at page 25, line 41 skipping to change at page 25, line 40
[content] [content]
If an application has browser compatibility as a goal, client If an application has browser compatibility as a goal, client
interaction ought to be defined in terms of [FETCH], since that is interaction ought to be defined in terms of [FETCH], since that is
the abstraction that browsers use for HTTP; it enforces many of these the abstraction that browsers use for HTTP; it enforces many of these
best practices. best practices.
4.14. Maintaining Application Boundaries 4.14. Maintaining Application Boundaries
Because the origin [RFC6454] is how many HTTP capabilities are Because many HTTP capabilities are scoped to the origin [RFC6454],
scoped, applications also need to consider how deployments might applications also need to consider how deployments might interact
interact with other applications (including Web browsing) on the same with other applications (including Web browsing) on the same origin.
origin.
For example, if Cookies [I-D.ietf-httpbis-rfc6265bis] are used to For example, if Cookies [RFC6265] are used to carry application
carry application state, they will be sent with all requests to the state, they will be sent with all requests to the origin by default
origin by default, unless scoped by path, and the application might (unless scoped by path), and the application might receive cookies
receive cookies from other applications on the origin. This can lead from other applications on the origin. This can lead to security
to security issues, as well as collision in cookie names. issues, as well as collision in cookie names.
One solution to these issues is to require a dedicated hostname for One solution to these issues is to require a dedicated hostname for
the application, so that it has a unique origin. However, it is the application, so that it has a unique origin. However, it is
often desirable to allow multiple applications to be deployed on a often desirable to allow multiple applications to be deployed on a
single hostname; doing so provides the most deployment flexibility single hostname; doing so provides the most deployment flexibility
and enables them to be "mixed" together (See [RFC8820] for details). and enables them to be "mixed" together (See [RFC8820] for details).
Therefore, applications using HTTP should strive to allow multiple Therefore, applications using HTTP should strive to allow multiple
applications on an origin. applications on an origin.
To enable this, when specifying the use of Cookies, HTTP To enable this, when specifying the use of Cookies, HTTP
skipping to change at page 29, line 23 skipping to change at page 29, line 12
be avoided, the resulting system's security properties need be be avoided, the resulting system's security properties need be
carefully scrutinised. carefully scrutinised.
7. References 7. References
7.1. Normative References 7.1. Normative References
[I-D.ietf-httpbis-semantics] [I-D.ietf-httpbis-semantics]
Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP
Semantics", Work in Progress, Internet-Draft, draft-ietf- Semantics", Work in Progress, Internet-Draft, draft-ietf-
httpbis-semantics-14, 12 January 2021, httpbis-semantics-15, 30 March 2021,
<https://tools.ietf.org/html/draft-ietf-httpbis-semantics- <https://tools.ietf.org/html/draft-ietf-httpbis-semantics-
14>. 15>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>. <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, Resource Identifier (URI): Generic Syntax", STD 66,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/rfc/rfc3986>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
"Transport Layer Security (TLS) Application-Layer Protocol DOI 10.17487/RFC6454, December 2011,
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, <https://www.rfc-editor.org/rfc/rfc6454>.
July 2014, <https://www.rfc-editor.org/rfc/rfc7301>.
[RFC8820] Nottingham, M., "URI Design and Ownership", BCP 190, [RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham,
RFC 8820, DOI 10.17487/RFC8820, June 2020, "Deprecating the "X-" Prefix and Similar Constructs in
<https://www.rfc-editor.org/rfc/rfc8820>. Application Protocols", BCP 178, RFC 6648,
DOI 10.17487/RFC6648, June 2012,
<https://www.rfc-editor.org/rfc/rfc6648>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13, Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013, RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/rfc/rfc6838>. <https://www.rfc-editor.org/rfc/rfc6838>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <https://www.rfc-editor.org/rfc/rfc7301>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/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/rfc/rfc8288>. <https://www.rfc-editor.org/rfc/rfc8288>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/rfc/rfc3986>.
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
(URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
<https://www.rfc-editor.org/rfc/rfc8615>. <https://www.rfc-editor.org/rfc/rfc8615>.
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, [RFC8820] Nottingham, M., "URI Design and Ownership", BCP 190,
DOI 10.17487/RFC6454, December 2011, RFC 8820, DOI 10.17487/RFC8820, June 2020,
<https://www.rfc-editor.org/rfc/rfc6454>. <https://www.rfc-editor.org/rfc/rfc8820>.
[RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham,
"Deprecating the "X-" Prefix and Similar Constructs in
Application Protocols", BCP 178, RFC 6648,
DOI 10.17487/RFC6648, June 2012,
<https://www.rfc-editor.org/rfc/rfc6648>.
7.2. Informative References 7.2. Informative References
[HTML] WHATWG, "HTML - Living Standard", n.d., [CSP] West, M., "Content Security Policy Level 3", World Wide
<https://html.spec.whatwg.org>. Web Consortium WD WD-CSP3-20160913, 13 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>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data [HTML] WHATWG, "HTML - Living Standard", n.d.,
Interchange Format", STD 90, RFC 8259, <https://html.spec.whatwg.org>.
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/rfc/rfc8259>.
[RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M.,
and D. Orchard, "URI Template", RFC 6570,
DOI 10.17487/RFC6570, March 2012,
<https://www.rfc-editor.org/rfc/rfc6570>.
[I-D.ietf-httpbis-rfc6265bis]
West, M. and J. Wilander, "Cookies: HTTP State Management
Mechanism", Work in Progress, Internet-Draft, draft-ietf-
httpbis-rfc6265bis-07, 7 December 2020,
<https://tools.ietf.org/html/draft-ietf-httpbis-
rfc6265bis-07>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <https://www.rfc-editor.org/rfc/rfc7258>.
[I-D.ietf-httpbis-cache] [I-D.ietf-httpbis-cache]
Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP
Caching", Work in Progress, Internet-Draft, draft-ietf- Caching", Work in Progress, Internet-Draft, draft-ietf-
httpbis-cache-14, 12 January 2021, httpbis-cache-15, 30 March 2021,
<https://tools.ietf.org/html/draft-ietf-httpbis-cache-14>. <https://tools.ietf.org/html/draft-ietf-httpbis-cache-15>.
[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/rfc/rfc6797>.
[SECCTXT] West, M., "Secure Contexts", World Wide Web Consortium CR [I-D.ietf-httpbis-priority]
CR-secure-contexts-20160915, 15 September 2016, Oku, K. and L. Pardue, "Extensible Prioritization Scheme
<https://www.w3.org/TR/2016/CR-secure-contexts-20160915>. for HTTP", Work in Progress, Internet-Draft, draft-ietf-
httpbis-priority-03, 11 January 2021,
<https://tools.ietf.org/html/draft-ietf-httpbis-priority-
03>.
[RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines [REFERRER-POLICY]
and Registration Procedures for URI Schemes", BCP 35, Eisinger, J. and E. Stark, "Referrer Policy", World Wide
RFC 7595, DOI 10.17487/RFC7595, June 2015, Web Consortium CR CR-referrer-policy-20170126, 26 January
<https://www.rfc-editor.org/rfc/rfc7595>. 2017,
<https://www.w3.org/TR/2017/CR-referrer-policy-20170126>.
[RFC7605] Touch, J., "Recommendations on Using Assigned Transport [RFC3205] Moore, K., "On the use of HTTP as a Substrate", BCP 56,
Port Numbers", BCP 165, RFC 7605, DOI 10.17487/RFC7605, RFC 3205, DOI 10.17487/RFC3205, February 2002,
August 2015, <https://www.rfc-editor.org/rfc/rfc7605>. <https://www.rfc-editor.org/rfc/rfc3205>.
[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/rfc/rfc4791>. <https://www.rfc-editor.org/rfc/rfc4791>.
[RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed [RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed
Authoring and Versioning (WebDAV)", RFC 4918, Authoring and Versioning (WebDAV)", RFC 4918,
DOI 10.17487/RFC4918, June 2007, DOI 10.17487/RFC4918, June 2007,
<https://www.rfc-editor.org/rfc/rfc4918>. <https://www.rfc-editor.org/rfc/rfc4918>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/rfc/rfc5246>.
[RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale
Content", RFC 5861, DOI 10.17487/RFC5861, May 2010,
<https://www.rfc-editor.org/rfc/rfc5861>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011,
<https://www.rfc-editor.org/rfc/rfc6265>.
[RFC6415] Hammer-Lahav, E., Ed. and B. Cook, "Web Host Metadata", [RFC6415] Hammer-Lahav, E., Ed. and B. Cook, "Web Host Metadata",
RFC 6415, DOI 10.17487/RFC6415, October 2011, RFC 6415, DOI 10.17487/RFC6415, October 2011,
<https://www.rfc-editor.org/rfc/rfc6415>. <https://www.rfc-editor.org/rfc/rfc6415>.
[RFC7807] Nottingham, M. and E. Wilde, "Problem Details for HTTP [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M.,
APIs", RFC 7807, DOI 10.17487/RFC7807, March 2016, and D. Orchard, "URI Template", RFC 6570,
<https://www.rfc-editor.org/rfc/rfc7807>. DOI 10.17487/RFC6570, March 2012,
<https://www.rfc-editor.org/rfc/rfc6570>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/rfc/rfc7540>.
[RFC8941] Nottingham, M. and P-H. Kamp, "Structured Field Values for
HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021,
<https://www.rfc-editor.org/rfc/rfc8941>.
[XML] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict
F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth Transport Security (HSTS)", RFC 6797,
Edition)", World Wide Web Consortium Recommendation REC- DOI 10.17487/RFC6797, November 2012,
xml-20081126, 26 November 2008, <https://www.rfc-editor.org/rfc/rfc6797>.
<https://www.w3.org/TR/2008/REC-xml-20081126>.
[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/rfc/rfc7049>. October 2013, <https://www.rfc-editor.org/rfc/rfc7049>.
[RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Content", RFC 5861, DOI 10.17487/RFC5861, May 2010, Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
<https://www.rfc-editor.org/rfc/rfc5861>. 2014, <https://www.rfc-editor.org/rfc/rfc7258>.
[I-D.ietf-httpbis-priority] [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Oku, K. and L. Pardue, "Extensible Prioritization Scheme Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
for HTTP", Work in Progress, Internet-Draft, draft-ietf- DOI 10.17487/RFC7540, May 2015,
httpbis-priority-03, 11 January 2021, <https://www.rfc-editor.org/rfc/rfc7540>.
<https://tools.ietf.org/html/draft-ietf-httpbis-priority-
03>.
[RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", [RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines
RFC 7617, DOI 10.17487/RFC7617, September 2015, and Registration Procedures for URI Schemes", BCP 35,
<https://www.rfc-editor.org/rfc/rfc7617>. RFC 7595, DOI 10.17487/RFC7595, June 2015,
<https://www.rfc-editor.org/rfc/rfc7595>.
[RFC7605] Touch, J., "Recommendations on Using Assigned Transport
Port Numbers", BCP 165, RFC 7605, DOI 10.17487/RFC7605,
August 2015, <https://www.rfc-editor.org/rfc/rfc7605>.
[RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP [RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP
Digest Access Authentication", RFC 7616, Digest Access Authentication", RFC 7616,
DOI 10.17487/RFC7616, September 2015, DOI 10.17487/RFC7616, September 2015,
<https://www.rfc-editor.org/rfc/rfc7616>. <https://www.rfc-editor.org/rfc/rfc7616>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme",
(TLS) Protocol Version 1.2", RFC 5246, RFC 7617, DOI 10.17487/RFC7617, September 2015,
DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/rfc/rfc7617>.
<https://www.rfc-editor.org/rfc/rfc5246>.
[CSP] West, M., "Content Security Policy Level 3", World Wide [RFC7807] Nottingham, M. and E. Wilde, "Problem Details for HTTP
Web Consortium WD WD-CSP3-20160913, 13 September 2016, APIs", RFC 7807, DOI 10.17487/RFC7807, March 2016,
<https://www.w3.org/TR/2016/WD-CSP3-20160913>. <https://www.rfc-editor.org/rfc/rfc7807>.
[REFERRER-POLICY] [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Eisinger, J. and E. Stark, "Referrer Policy", World Wide Interchange Format", STD 90, RFC 8259,
Web Consortium CR CR-referrer-policy-20170126, 26 January DOI 10.17487/RFC8259, December 2017,
2017, <https://www.rfc-editor.org/rfc/rfc8259>.
<https://www.w3.org/TR/2017/CR-referrer-policy-20170126>.
[RFC8297] Oku, K., "An HTTP Status Code for Indicating Hints", [RFC8297] Oku, K., "An HTTP Status Code for Indicating Hints",
RFC 8297, DOI 10.17487/RFC8297, December 2017, RFC 8297, DOI 10.17487/RFC8297, December 2017,
<https://www.rfc-editor.org/rfc/rfc8297>. <https://www.rfc-editor.org/rfc/rfc8297>.
[RFC3205] Moore, K., "On the use of HTTP as a Substrate", BCP 56, [RFC8941] Nottingham, M. and P-H. Kamp, "Structured Field Values for
RFC 3205, DOI 10.17487/RFC3205, February 2002, HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021,
<https://www.rfc-editor.org/rfc/rfc3205>. <https://www.rfc-editor.org/rfc/rfc8941>.
[SECCTXT] West, M., "Secure Contexts", World Wide Web Consortium CR
CR-secure-contexts-20160915, 15 September 2016,
<https://www.w3.org/TR/2016/CR-secure-contexts-20160915>.
[XML] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and
F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
Edition)", World Wide Web Consortium Recommendation REC-
xml-20081126, 26 November 2008,
<https://www.w3.org/TR/2008/REC-xml-20081126>.
Appendix A. Changes from RFC 3205 Appendix A. Changes from RFC 3205
[RFC3205] captured the Best Current Practice in the early 2000's, [RFC3205] captured the Best Current Practice in the early 2000's,
based on the concerns facing protocol designers at the time. Use of based on the concerns facing protocol designers at the time. Use of
HTTP has changed considerably since then, and as a result this HTTP has changed considerably since then, and as a result this
document is substantially different. As a result, the changes are document is substantially different. As a result, the changes are
too numerous to list individually. too numerous to list individually.
Author's Address Author's Address
 End of changes. 69 change blocks. 
245 lines changed or deleted 237 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/