< draft-ietf-httpbis-bcp56bis-12.txt   draft-ietf-httpbis-bcp56bis-13.txt >
HTTP M. Nottingham HTTP M. Nottingham
Internet-Draft 27 April 2021 Internet-Draft 3 August 2021
Obsoletes: 3205 (if approved) Obsoletes: 3205 (if approved)
Intended status: Best Current Practice Intended status: Best Current Practice
Expires: 29 October 2021 Expires: 4 February 2022
Building Protocols with HTTP Building Protocols with HTTP
draft-ietf-httpbis-bcp56bis-12 draft-ietf-httpbis-bcp56bis-13
Abstract Abstract
Applications often use HTTP as a substrate to create HTTP-based APIs. Applications often use HTTP as a substrate to create HTTP-based APIs.
This document specifies best practices for writing specifications This document specifies best practices for writing specifications
that use HTTP to define new application protocols. It is written that use HTTP to define new application protocols. It is written
primarily to guide IETF efforts to define application protocols using primarily to guide IETF efforts to define application protocols using
HTTP for deployment on the Internet, but might be applicable in other HTTP for deployment on the Internet, but might be applicable in other
situations. situations.
This document obsoletes [RFC3205].
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/).
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 2, line 4 skipping to change at page 2, line 9
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 29 October 2021.
This Internet-Draft will expire on 4 February 2022.
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
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 5
2. Is HTTP Being Used? . . . . . . . . . . . . . . . . . . . . . 4 2. Is HTTP Being Used? . . . . . . . . . . . . . . . . . . . . . 5
2.1. Non-HTTP Protocols . . . . . . . . . . . . . . . . . . . 5 2.1. Non-HTTP Protocols . . . . . . . . . . . . . . . . . . . 5
3. What's Important About HTTP . . . . . . . . . . . . . . . . . 5 3. What's Important About HTTP . . . . . . . . . . . . . . . . . 6
3.1. Generic Semantics . . . . . . . . . . . . . . . . . . . . 6 3.1. Generic Semantics . . . . . . . . . . . . . . . . . . . . 6
3.2. Links . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Links . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Rich Functionality . . . . . . . . . . . . . . . . . . . 7 3.3. Rich Functionality . . . . . . . . . . . . . . . . . . . 7
4. Best Practices for Specifying the Use of HTTP . . . . . . . . 8 4. Best Practices for Specifying the Use of HTTP . . . . . . . . 8
4.1. Specifying the Use of HTTP . . . . . . . . . . . . . . . 8 4.1. Specifying the Use of HTTP . . . . . . . . . . . . . . . 8
4.2. Specifying Server Behaviour . . . . . . . . . . . . . . . 9 4.2. Specifying Server Behaviour . . . . . . . . . . . . . . . 9
4.3. Specifying Client Behaviour . . . . . . . . . . . . . . . 10 4.3. Specifying Client Behaviour . . . . . . . . . . . . . . . 10
4.4. Specifying URLs . . . . . . . . . . . . . . . . . . . . . 11 4.4. Specifying URLs . . . . . . . . . . . . . . . . . . . . . 11
4.4.1. Discovering an Application's URLs . . . . . . . . . . 11 4.4.1. Discovering an Application's URLs . . . . . . . . . . 11
4.4.2. Considering URI Schemes . . . . . . . . . . . . . . . 12 4.4.2. Considering URI Schemes . . . . . . . . . . . . . . . 12
4.4.3. Transport Ports . . . . . . . . . . . . . . . . . . . 13 4.4.3. Transport Ports . . . . . . . . . . . . . . . . . . . 13
4.5. Using HTTP Methods . . . . . . . . . . . . . . . . . . . 14 4.5. Using HTTP Methods . . . . . . . . . . . . . . . . . . . 14
skipping to change at page 4, line 39 skipping to change at page 4, line 45
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 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.
This document obsoletes [RFC3205], to reflect experience and
developments regarding HTTP in the intervening time.
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
"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?
skipping to change at page 5, line 12 skipping to change at page 5, line 26
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. * makes registrations in or overall modifications to 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 such as
appropriate). the specific version of HTTP in use, and any extensions in use).
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. Furthermore, while it is intended for generic extensions to HTTP. Furthermore, while it is intended for
IETF-specified applications, other standards organisations are IETF-specified applications, other standards organisations are
encouraged to adhere to its requirements. encouraged to adhere to its requirements.
2.1. Non-HTTP Protocols 2.1. Non-HTTP Protocols
An application can rely upon HTTP without meeting the criteria for An application can rely upon HTTP without meeting the criteria for
using it defined above. For example, an application might wish to using it defined above. For example, an application might wish to
avoid re-specifying parts of the message format, but change other avoid re-specifying parts of the message format, but change other
aspects of the protocol's operation; or, it might want to use a aspects of the protocol's operation; or, it might want to use
different set of methods. application-specific 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 in Section 3, as most
implementations won't be easily adaptable to these changes, and the HTTP implementations won't be easily adaptable to these changes, and
benefit of mindshare will be lost. the benefit of mindshare will be 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 HTTP that are important This section examines the characteristics of HTTP that are important
to consider when using HTTP to define an application protocol. to consider when using HTTP to define an application protocol.
skipping to change at page 11, line 22 skipping to change at page 11, line 22
features, though. features, though.
4.4. Specifying URLs 4.4. Specifying URLs
In HTTP, the resources that clients interact with are identified with In HTTP, the resources that clients interact with are identified with
URLs [RFC3986]. As [RFC8820] explains, parts of the URL are designed URLs [RFC3986]. As [RFC8820] explains, parts of the URL are designed
to be under the control of the owner (also known as the "authority") to be under the control of the owner (also known as the "authority")
of that server, to give them the flexibility in deployment. of that server, to give them the flexibility in 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 fixed application URLs or paths; while it is
specification of a single-deployment API to specify the path prefix common practice for a specification of a single-deployment API to
"/app/v1" (for example), doing so in an IETF specification is specify the path prefix "/app/v1" (for example), doing so in an IETF
inappropriate. specification is 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,
and whether to use a dedicated port, or reuse HTTP's port(s). and whether to use a dedicated port, or reuse HTTP's port(s).
4.4.1. Discovering an Application's URLs 4.4.1. Discovering an Application's URLs
Generally, a client will begin interacting with a given application Generally, a client will begin interacting with a given application
server by requesting an initial document that contains information server by requesting an initial document that contains information
skipping to change at page 15, line 7 skipping to change at page 15, line 7
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
that might be significant to the client, since implementations can that might be significant to the client, since implementations can
and do retry HTTP GET requests that fail. Note that this does not and do retry HTTP GET requests that fail, and some GET requests
include logging and similar functions; see protected by TLS Early Data might be vulnerable to replay attacks
[I-D.ietf-httpbis-semantics], Section 9.2.1. (see [RFC8470]). Note that this does not include logging and similar
functions; see [I-D.ietf-httpbis-semantics], Section 9.2.1.
Finally, note that while HTTP allows GET requests to have content Finally, note that while HTTP allows GET requests to have content
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 [I-D.ietf-httpbis-semantics], Section 9.3.1, content on a GET has per [I-D.ietf-httpbis-semantics], Section 9.3.1, content on a GET has
no meaning, and will be either ignored or rejected by generic HTTP no meaning, and will be either ignored or rejected by generic HTTP
software. software.
4.5.2. OPTIONS 4.5.2. OPTIONS
The OPTIONS method was defined for metadata retrieval, and is used The OPTIONS method was defined for metadata retrieval, and is used
skipping to change at page 15, line 47 skipping to change at page 15, line 48
interact with the application. interact with the application.
* Implementation support for OPTIONS is not universal; some servers * Implementation support for OPTIONS is not universal; some servers
do not expose the ability to respond to OPTIONS requests without do not expose the ability to respond to OPTIONS requests without
significant effort. significant effort.
Instead of OPTIONS, one of these alternative approaches might be more Instead of OPTIONS, one of these alternative approaches might be more
appropriate: appropriate:
* For server-wide metadata, create a well-known URI [RFC8615], or * For server-wide metadata, create a well-known URI [RFC8615], or
using an already existing one if it's appropriate (e.g., HostMeta use an already existing one if appropriate (e.g., HostMeta
[RFC6415]). [RFC6415]).
* For metadata about a specific resource, create a separate resource * For metadata about a specific resource, create a separate resource
and link to it using a Link response header field or a link and link to it using a Link response header field or a link
serialised into the response's content. See [RFC8288]. Note that serialised into the response's content. See [RFC8288]. Note that
the Link header field is available on HEAD responses, which is the Link header field is available on HEAD responses, which is
useful if the client wants to discover a resource's capabilities useful if the client wants to discover a resource's capabilities
before they interact with it. before they interact with it.
4.6. Using HTTP Status Codes 4.6. Using HTTP Status Codes
HTTP status codes convey semantics both for the benefit of generic HTTP status codes convey semantics both for the benefit of generic
HTTP components -- such as caches, intermediaries, and clients -- and HTTP components -- such as caches, intermediaries, and clients -- and
applications themselves. However, applications can encounter a applications themselves. However, applications can encounter a
number of pitfalls in their use. number of pitfalls in their use.
First, status codes are often generated by components other the the First, status codes are often generated by components other than the
application itself. This can happen, for example, when network application itself. This can happen, for example, when network
errors are encountered, a captive portal, proxy or Content Delivery errors are encountered, a captive portal, proxy or Content Delivery
Network is present, when a server is overloaded, or it thinks it is Network is present, when a server is overloaded, or it thinks it is
under attack. They can even be generated by generic client software under attack. They can even be generated by generic client software
when certain error conditions are encountered. As a result, if an when certain error conditions are encountered. As a result, if an
application assigns specific semantics to one of these status codes, application assigns specific semantics to one of these status codes,
a client can be misled about its state, because the status code was a client can be misled about its state, because the status code was
generated by a generic component, not the application itself. generated by a generic component, not the application itself.
Furthermore, mapping application errors to individual HTTP status Furthermore, mapping application errors to individual HTTP status
skipping to change at page 20, line 8 skipping to change at page 20, line 8
caching; in particular, request header fields that are used to caching; in particular, request header fields that are used to
"select" a response have impact there, and need to be carefully "select" a response have impact there, and need to be carefully
considered. 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 Content 4.8. Defining Message Content
Common syntactic conventions for message contents include JSON Common syntactic conventions for message contents include JSON
[RFC8259], XML [XML], and CBOR [RFC7049]. Best practices for their [RFC8259], XML [XML], and CBOR [RFC8949]. 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.
4.9. Leveraging HTTP Caching 4.9. Leveraging HTTP Caching
HTTP caching [I-D.ietf-httpbis-cache] is one of the primary benefits HTTP caching [I-D.ietf-httpbis-cache] is one of the primary benefits
of using HTTP for applications; it provides scalability, reduces of using HTTP for applications; it provides scalability, reduces
skipping to change at page 21, line 45 skipping to change at page 21, line 45
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
Section 13 of [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 needs to be carefully considered, since the response will be used as
long as it is considered fresh. long as it is considered fresh.
In particular, application authors need to consider how responses In particular, application authors need to consider how responses
that are not freshly obtained from the origin server should be that are not freshly obtained from the origin server should be
handled; if they have a concept like a validity period, this will handled; if they have a concept like a validity period, this will
need to be calculated considering the age of the response (see need to be calculated considering the age of the response (see
[I-D.ietf-httpbis-cache], Section 4.2.3). [I-D.ietf-httpbis-cache], Section 4.2.3).
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.
skipping to change at page 23, line 43 skipping to change at page 23, line 43
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 Section 11 of Applications can use HTTP authentication Section 11 of
[I-D.ietf-httpbis-semantics] to identify clients. The Basic [I-D.ietf-httpbis-semantics] to identify clients. As per [RFC7617],
authentication scheme [RFC7617] MUST NOT be used unless the the Basic authentication scheme is not suitable for protecting
underlying transport is authenticated, integrity-protected and sensitive or valuable information unless the channel is secure (e.g.,
confidential (e.g., as provided the "HTTPS" URI scheme, or another using the "HTTPS" URI scheme). Likewise, [RFC7617] requires the
using TLS). The Digest scheme [RFC7616] MUST NOT be used unless the Digest authentication scheme to be used over a secure channel.
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.
skipping to change at page 27, line 40 skipping to change at page 27, line 40
5. IANA Considerations 5. IANA Considerations
This document has no requirements for IANA. This document has no requirements for IANA.
6. Security Considerations 6. Security Considerations
Section 4.10 discusses the impact of using stateful mechanisms in the Section 4.10 discusses the impact of using stateful mechanisms in the
protocol as ambient authority, and suggests a mitigation. protocol as ambient authority, and suggests a mitigation.
Section 4.4.2 requires support for 'https' URLs, and discourages the Section 4.4.2 recommends support for 'https' URLs, and discourages
use of 'http' URLs, to provide authentication, integrity and the use of 'http' URLs, to provide authentication, integrity and
confidentiality, as well as mitigate pervasive monitoring attacks. confidentiality, as well as mitigate pervasive monitoring attacks.
Many applications using HTTP perform authentication and authorization
with bearer tokens (e.g., in session cookies). If the transport is
unencrypted, an attacker that can eavesdrop on HTTP communications
can often escalate their privilege to perform operations on
resources.
Section 4.13 highlights the implications of Web browsers' Section 4.13 highlights the implications of Web browsers'
capabilities on applications that use HTTP. capabilities on applications that use HTTP.
Section 4.14 discusses the issues that arise when applications are Section 4.14 discusses the issues that arise when applications are
deployed on the same origin as Web sites (and other applications). deployed on the same origin as Web sites (and other applications).
Section 4.15 highlights risks of using HTTP/2 server push in a manner Section 4.15 highlights risks of using HTTP/2 server push in a manner
other than specified. other than specified.
skipping to change at page 29, line 12 skipping to change at page 29, line 17
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-15, 30 March 2021, httpbis-semantics-17, 25 July 2021,
<https://tools.ietf.org/html/draft-ietf-httpbis-semantics- <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
15>. semantics-17>.
[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>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/rfc/rfc3986>. <https://www.rfc-editor.org/rfc/rfc3986>.
skipping to change at page 30, line 28 skipping to change at page 30, line 36
[FETCH] WHATWG, "Fetch - Living Standard", n.d., [FETCH] WHATWG, "Fetch - Living Standard", n.d.,
<https://fetch.spec.whatwg.org>. <https://fetch.spec.whatwg.org>.
[HTML] WHATWG, "HTML - Living Standard", n.d., [HTML] WHATWG, "HTML - Living Standard", n.d.,
<https://html.spec.whatwg.org>. <https://html.spec.whatwg.org>.
[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-15, 30 March 2021, httpbis-cache-17, 25 July 2021,
<https://tools.ietf.org/html/draft-ietf-httpbis-cache-15>. <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
cache-17>.
[I-D.ietf-httpbis-priority] [I-D.ietf-httpbis-priority]
Oku, K. and L. Pardue, "Extensible Prioritization Scheme Oku, K. and L. Pardue, "Extensible Prioritization Scheme
for HTTP", Work in Progress, Internet-Draft, draft-ietf- for HTTP", Work in Progress, Internet-Draft, draft-ietf-
httpbis-priority-03, 11 January 2021, httpbis-priority-04, 11 July 2021,
<https://tools.ietf.org/html/draft-ietf-httpbis-priority- <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
03>. priority-04>.
[REFERRER-POLICY] [REFERRER-POLICY]
Eisinger, J. and E. Stark, "Referrer Policy", World Wide Eisinger, J. and E. Stark, "Referrer Policy", World Wide
Web Consortium CR CR-referrer-policy-20170126, 26 January Web Consortium CR CR-referrer-policy-20170126, 26 January
2017, 2017,
<https://www.w3.org/TR/2017/CR-referrer-policy-20170126>. <https://www.w3.org/TR/2017/CR-referrer-policy-20170126>.
[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/rfc/rfc3205>. <https://www.rfc-editor.org/rfc/rfc3205>.
skipping to change at page 31, line 37 skipping to change at page 31, line 46
[RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M.,
and D. Orchard, "URI Template", RFC 6570, and D. Orchard, "URI Template", RFC 6570,
DOI 10.17487/RFC6570, March 2012, DOI 10.17487/RFC6570, March 2012,
<https://www.rfc-editor.org/rfc/rfc6570>. <https://www.rfc-editor.org/rfc/rfc6570>.
[RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict
Transport Security (HSTS)", RFC 6797, Transport Security (HSTS)", RFC 6797,
DOI 10.17487/RFC6797, November 2012, DOI 10.17487/RFC6797, November 2012,
<https://www.rfc-editor.org/rfc/rfc6797>. <https://www.rfc-editor.org/rfc/rfc6797>.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <https://www.rfc-editor.org/rfc/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/rfc/rfc7258>. 2014, <https://www.rfc-editor.org/rfc/rfc7258>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540, Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015, DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/rfc/rfc7540>. <https://www.rfc-editor.org/rfc/rfc7540>.
[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,
RFC 7595, DOI 10.17487/RFC7595, June 2015, RFC 7595, DOI 10.17487/RFC7595, June 2015,
<https://www.rfc-editor.org/rfc/rfc7595>. <https://www.rfc-editor.org/rfc/rfc7595>.
[RFC7605] Touch, J., "Recommendations on Using Assigned Transport [RFC7605] Touch, J., "Recommendations on Using Assigned Transport
Port Numbers", BCP 165, RFC 7605, DOI 10.17487/RFC7605, Port Numbers", BCP 165, RFC 7605, DOI 10.17487/RFC7605,
August 2015, <https://www.rfc-editor.org/rfc/rfc7605>. August 2015, <https://www.rfc-editor.org/rfc/rfc7605>.
[RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP
Digest Access Authentication", RFC 7616,
DOI 10.17487/RFC7616, September 2015,
<https://www.rfc-editor.org/rfc/rfc7616>.
[RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", [RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme",
RFC 7617, DOI 10.17487/RFC7617, September 2015, RFC 7617, DOI 10.17487/RFC7617, September 2015,
<https://www.rfc-editor.org/rfc/rfc7617>. <https://www.rfc-editor.org/rfc/rfc7617>.
[RFC7807] Nottingham, M. and E. Wilde, "Problem Details for HTTP [RFC7807] Nottingham, M. and E. Wilde, "Problem Details for HTTP
APIs", RFC 7807, DOI 10.17487/RFC7807, March 2016, APIs", RFC 7807, DOI 10.17487/RFC7807, March 2016,
<https://www.rfc-editor.org/rfc/rfc7807>. <https://www.rfc-editor.org/rfc/rfc7807>.
[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/rfc/rfc8259>. <https://www.rfc-editor.org/rfc/rfc8259>.
[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>.
[RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early
Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September
2018, <https://www.rfc-editor.org/rfc/rfc8470>.
[RFC8941] Nottingham, M. and P-H. Kamp, "Structured Field Values for [RFC8941] Nottingham, M. and P-H. Kamp, "Structured Field Values for
HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021, HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021,
<https://www.rfc-editor.org/rfc/rfc8941>. <https://www.rfc-editor.org/rfc/rfc8941>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/rfc/rfc8949>.
[SECCTXT] West, M., "Secure Contexts", World Wide Web Consortium CR [SECCTXT] West, M., "Secure Contexts", World Wide Web Consortium CR
CR-secure-contexts-20160915, 15 September 2016, CR-secure-contexts-20160915, 15 September 2016,
<https://www.w3.org/TR/2016/CR-secure-contexts-20160915>. <https://www.w3.org/TR/2016/CR-secure-contexts-20160915>.
[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, 26 November 2008, xml-20081126, 26 November 2008,
<https://www.w3.org/TR/2008/REC-xml-20081126>. <https://www.w3.org/TR/2008/REC-xml-20081126>.
 End of changes. 29 change blocks. 
53 lines changed or deleted 65 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/