rfc9205.original.xml   rfc9205.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.5.6 --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
<?rfc sortrefs="yes"?> -ietf-httpbis-bcp56bis-15" number="9205" obsoletes="3205" updates="" submissionT
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft ype="IETF" category="bcp" consensus="true" xml:lang="en" symRefs="true" sortRefs
-ietf-httpbis-bcp56bis-15" category="bcp" obsoletes="3205" updates="" submission ="true" tocInclude="true" version="3">
Type="IETF" xml:lang="en" sortRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.9.1 -->
<front> <front>
<title>Building Protocols with HTTP</title> <title>Building Protocols with HTTP</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-bcp56bis-15"/> <seriesInfo name="RFC" value="9205"/>
<seriesInfo name="BCP" value="56"/>
<author initials="M." surname="Nottingham" fullname="Mark Nottingham"> <author initials="M." surname="Nottingham" fullname="Mark Nottingham">
<organization/> <organization/>
<address> <address>
<postal> <postal>
<postalLine>Prahran</postalLine> <postalLine>Prahran</postalLine>
<postalLine>Australia</postalLine> <postalLine>Australia</postalLine>
</postal> </postal>
<email>mnot@mnot.net</email> <email>mnot@mnot.net</email>
<uri>https://www.mnot.net/</uri> <uri>https://www.mnot.net/</uri>
</address> </address>
</author> </author>
<date/> <date year="2022" month="June" />
<area>Applications and Real-Time</area> <area>Applications and Real-Time</area>
<workgroup>HTTP</workgroup> <workgroup>HTTP</workgroup>
<keyword>HTTP API</keyword> <keyword>HTTP API</keyword>
<abstract> <abstract>
<t>Applications often use HTTP as a substrate to create HTTP-based APIs. T <t>Applications often use HTTP as a substrate to create HTTP-based APIs. T
his document specifies best practices for writing specifications that use HTTP t his document specifies best practices for writing specifications that use HTTP t
o define new application protocols. It is written primarily to guide IETF effort o define new application protocols. It is written primarily to guide IETF effort
s to define application protocols using HTTP for deployment on the Internet, but s to define application protocols using HTTP for deployment on the Internet but
might be applicable in other situations.</t> might be applicable in other situations.</t>
<t>This document obsoletes <xref target="RFC3205" format="default"/>.</t> <t>This document obsoletes RFC 3205.</t>
</abstract> </abstract>
<note>
<name>Note to Readers</name>
<t><em>RFC EDITOR: please remove this section before publication</em></t>
<t>Discussion of this draft takes place on the HTTP working group mailing
list (ietf-http-wg@w3.org), which is archived at <eref target="https://lists.w3.
org/Archives/Public/ietf-http-wg/">https://lists.w3.org/Archives/Public/ietf-htt
p-wg/</eref>.</t>
<t>Working Group information can be found at <eref target="http://httpwg.g
ithub.io/">http://httpwg.github.io/</eref>; source code and issues list for this
draft can be found at <eref target="https://github.com/httpwg/http-extensions/l
abels/bcp56bis">https://github.com/httpwg/http-extensions/labels/bcp56bis</eref>
.</t>
</note>
</front> </front>
<middle> <middle>
<section anchor="introduction" numbered="true" toc="default"> <section anchor="introduction" numbered="true" toc="default">
<name>Introduction</name> <name>Introduction</name>
<t>Applications other than Web browsing often use HTTP <xref target="HTTP" format="default"/> as a substrate, a practice sometimes referred to as creating "HTTP-based APIs", "REST APIs" or just "HTTP APIs". This is done for a variety of reasons, including:</t> <t>Applications other than Web browsing often use HTTP <xref target="HTTP" format="default"/> as a substrate, a practice sometimes referred to as creating "HTTP-based APIs", "REST APIs", or just "HTTP APIs". This is done for a variety of reasons, including:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>familiarity by implementers, specifiers, administrators, developers <li>familiarity by implementers, specifiers, administrators, developers,
and users,</li> and users;</li>
<li>availability of a variety of client, server and proxy implementation <li>availability of a variety of client, server, and proxy implementatio
s,</li> ns;</li>
<li>ease of use,</li> <li>ease of use;</li>
<li>availability of Web browsers,</li> <li>availability of Web browsers;</li>
<li>reuse of existing mechanisms like authentication and encryption,</li <li>reuse of existing mechanisms like authentication and encryption;</li
> >
<li>presence of HTTP servers and clients in target deployments, and</li> <li>presence of HTTP servers and clients in target deployments; and</li>
<li>its ability to traverse firewalls.</li> <li>its ability to traverse firewalls.</li>
</ul> </ul>
<t>These protocols are often ad hoc, intended for only deployment by one o <t>These protocols are often ad hoc, intended for only deployment by one o
r a few servers and consumption by a limited set of clients. As a result, a body r a few servers and consumption by a limited set of clients. As a result, a body
of practices and tools has arisen around defining HTTP-based APIs that favours of practices and tools has arisen around defining HTTP-based APIs that favour t
these conditions.</t> hese conditions.</t>
<t>However, when such an application has multiple, separate implementation <t>However, when such an application has multiple, separate implementation
s, is deployed on multiple uncoordinated servers, and is consumed by diverse cli s, is deployed on multiple uncoordinated servers, and is consumed by diverse cli
ents -- as is often the case for HTTP APIs defined by standards efforts -- tools ents (as is often the case for HTTP APIs defined by standards efforts), tools an
and practices intended for limited deployment can become unsuitable.</t> d practices intended for limited deployment can become unsuitable.</t>
<t>This mismatch is largely because the API's clients and servers will imp <t>This mismatch is largely because the API's clients and servers will imp
lement and evolve at different paces, leading to a need for deployments with dif lement and evolve at different paces, leading to a need for deployments with dif
ferent features and versions to co-exist. As a result, the designers of HTTP-bas ferent features and versions to coexist. As a result, the designers of HTTP-base
ed APIs intended for such deployments need to more carefully consider how extens d APIs intended for such deployments need to more carefully consider how extensi
ibility of the service will be handled and how different deployment requirements bility of the service will be handled and how different deployment requirements
will be accommodated.</t> will be accommodated.</t>
<t>More generally, an application protocol using HTTP faces a number of de sign decisions, including:</t> <t>More generally, an application protocol using HTTP faces a number of de sign decisions, including:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Should it define a new URI scheme? Use new ports?</li> <li>Should it define a new URI scheme? Use new ports?</li>
<li>Should it use standard HTTP methods and status codes, or define new ones?</li> <li>Should it use standard HTTP methods and status codes or define new o nes?</li>
<li>How can the maximum value be extracted from the use of HTTP?</li> <li>How can the maximum value be extracted from the use of HTTP?</li>
<li>How does it coexist with other uses of HTTP -- especially Web browsi ng?</li> <li>How does it coexist with other uses of HTTP -- especially Web browsi ng?</li>
<li>How can interoperability problems and "protocol dead ends" be avoide d?</li> <li>How can interoperability problems and "protocol dead ends" be avoide d?</li>
</ul> </ul>
<t>This document contains best current practices for the specification of <t><xref target="used" format="default"/> defines when this document appli
such applications. <xref target="used" format="default"/> defines when it applie es, <xref target="overview" format="default"/> surveys the properties of HTTP th
s; <xref target="overview" format="default"/> surveys the properties of HTTP tha at are important to preserve, and <xref target="bp" format="default"/> contains
t are important to preserve, and <xref target="bp" format="default"/> conveys be best practices for the specification of applications that use HTTP.</t>
st practices for specifying them.</t> <t>It is written primarily to guide IETF efforts to define application pro
<t>It is written primarily to guide IETF efforts to define application pro tocols using HTTP for deployment on the Internet but might be applicable in othe
tocols using HTTP for deployment on the Internet, but might be applicable in oth r situations. Note that the requirements herein do not necessarily apply to the
er situations. Note that the requirements herein do not necessarily apply to the development of generic HTTP extensions.</t>
development of generic HTTP extensions.</t> <t>This document obsoletes <xref target="RFC3205" format="default"/> to re
<t>This document obsoletes <xref target="RFC3205" format="default"/>, to r flect the experience and developments regarding HTTP in the intervening time.</t
eflect experience and developments regarding HTTP in the intervening time.</t> >
<section anchor="notational-conventions" numbered="true" toc="default"> <section anchor="notational-conventions" numbered="true" toc="default">
<name>Notational Conventions</name> <name>Notational Conventions</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", " <t>
SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" i The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
n this document are to be interpreted as described in BCP 14 <xref target="RFC21 IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
19" format="default"/> <xref target="RFC8174" format="default"/> when, and only NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
when, they appear in all capitals, as shown here.</t> RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
</section> </section>
<section anchor="used" numbered="true" toc="default"> <section anchor="used" numbered="true" toc="default">
<name>Is HTTP Being Used?</name> <name>Is HTTP Being Used?</name>
<t>Different applications have different goals when using HTTP. The recomm endations in this document apply when a specification defines an application tha t:</t> <t>Different applications have different goals when using HTTP. The recomm endations in this document apply when a specification defines an application tha t:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>uses the transport port 80 or 443, or</li> <li>uses the transport port 80 or 443, or</li>
<li>uses the URI scheme "http" or "https", or</li> <li>uses the URI scheme "http" or "https", or</li>
<li>uses an ALPN protocol ID <xref target="RFC7301" format="default"/> t hat generically identifies HTTP (e.g., "http/1.1", "h2", "h3"), or</li> <li>uses an ALPN protocol ID <xref target="RFC7301" format="default"/> t hat generically identifies HTTP (e.g., "http/1.1", "h2", "h3"), or</li>
<li>makes registrations in or overall modifications to the IANA registri es defined for HTTP.</li> <li>makes registrations in or overall modifications to the IANA registri es defined for HTTP.</li>
</ul> </ul>
<t>Additionally, when a specification is using HTTP, all of the requiremen ts of the HTTP protocol suite are in force (in particular, <xref target="HTTP" f ormat="default"/>, but also other specifications such as the specific version of HTTP in use, and any extensions in use).</t> <t>Additionally, when a specification is using HTTP, all of the requiremen ts of the HTTP protocol suite are in force (<xref target="HTTP" format="default" /> in particular but also other specifications such as the specific version of H TTP in use and any extensions in use).</t>
<t>Note that this document is intended to apply to applications, not gener ic extensions to HTTP. Furthermore, while it is intended for IETF-specified appl ications, other standards organisations are encouraged to adhere to its requirem ents.</t> <t>Note that this document is intended to apply to applications, not gener ic extensions to HTTP. Furthermore, while it is intended for IETF-specified appl ications, other standards organisations are encouraged to adhere to its requirem ents.</t>
<section anchor="non-http-protocols" numbered="true" toc="default"> <section anchor="non-http-protocols" numbered="true" toc="default">
<name>Non-HTTP Protocols</name> <name>Non-HTTP Protocols</name>
<t>An application can rely upon HTTP without meeting the criteria for us <t>An application can rely upon HTTP without meeting the criteria for us
ing it defined above. ing it as defined above.
For example, an application might wish to avoid re-specifying parts of the messa For example, an application might wish to avoid re-specifying parts of th
ge format, but change other aspects of the protocol's operation; or, it might wa e message format but might change other aspects of the protocol's operation, or
nt to use application-specific methods.</t> it might want to use application-specific methods.</t>
<t>Doing so brings more freedom to modify protocol operations, but loses <t>Doing so permits more freedom to modify protocol operations, but at l
at least a portion of the benefits outlined in <xref target="overview" format=" east a portion of the benefits outlined in <xref target="overview" format="defau
default"/>, as most HTTP implementations won't be easily adaptable to these chan lt"/> are lost as most HTTP implementations won't be easily adaptable to these c
ges, and the benefit of mindshare will be lost.</t> hanges. The benefit of mindshare will also be lost.</t>
<t>Such specifications MUST NOT use HTTP's URI schemes, transport ports, <t>Such specifications <bcp14>MUST NOT</bcp14> use HTTP's URI schemes, t
ALPN protocol IDs or IANA registries; rather, they are encouraged to establish ransport ports, ALPN protocol IDs, or IANA registries; rather, they are encourag
their own.</t> ed to establish their own.</t>
</section> </section>
</section> </section>
<section anchor="overview" numbered="true" toc="default"> <section anchor="overview" numbered="true" toc="default">
<name>What's Important About HTTP</name> <name>What's Important About HTTP</name>
<t>This section examines the characteristics of HTTP that are important to consider when using HTTP to define an application protocol.</t> <t>This section examines the characteristics of HTTP that are important to consider when using HTTP to define an application protocol.</t>
<section anchor="generic-semantics" numbered="true" toc="default"> <section anchor="generic-semantics" numbered="true" toc="default">
<name>Generic Semantics</name> <name>Generic Semantics</name>
<t>Much of the value of HTTP is in its generic semantics -- that is, the <t>Much of the value of HTTP is in its generic semantics -- that is, the protoco
protocol elements defined by HTTP are potentially applicable to every resource, l elements defined by HTTP are potentially applicable to every resource and are
not specific to a particular context. Application-specific semantics are best e not specific to a particular context. Application-specific semantics are best ex
xpressed in message content and in header fields, not status codes or methods (a pressed in message content and header fields, not status codes or methods (altho
lthough the latter do have generic semantics that relate to application state).< ugh status codes and methods do have generic semantics that relate to applicatio
/t> n state).</t>
<t>This generic/application-specific split allows a HTTP message to be h <t>This split between generic and application-specific semantics allows
andled by common software (e.g., HTTP servers, intermediaries, client implementa an HTTP message to be handled by common software (e.g., HTTP servers, intermedia
tions, and caches) without understanding the specific application. It also allow ries, client implementations, and caches) without requiring those implementation
s people to leverage their knowledge of HTTP semantics without specialising them s to understand the application in use. It also allows people to leverage their
for a particular application.</t> knowledge of HTTP semantics without needing specialised knowledge of a particula
<t>Therefore, applications that use HTTP MUST NOT re-define, refine or o r application.</t>
verlay the semantics of generic protocol elements such as methods, status codes <t>Therefore, applications that use HTTP <bcp14>MUST NOT</bcp14> redefin
or existing header fields. Instead, they should focus their specifications on pr e, refine, or overlay the semantics of generic protocol elements such as methods
otocol elements that are specific to that application; namely their HTTP resourc , status codes, or existing header fields. Instead, they should focus their spec
es.</t> ifications on protocol elements that are specific to that application -- namely,
<t>When writing a specification, it's often tempting to specify exactly their HTTP resources.</t>
how HTTP is to be implemented, supported and used. However, this can easily lead <t>When writing a specification, it's often tempting to specify exactly
to an unintended profile of HTTP's behaviour. For example, it's common to see s how HTTP is to be implemented, supported, and used. However, this can easily lea
pecifications with language like this:</t> d to an unintended profile of HTTP behaviour. For example, it's common to see sp
<artwork name="" type="" align="left" alt=""><![CDATA[ ecifications with language like this:</t>
A `POST` request MUST result in a `201 Created` response. <blockquote>
]]></artwork> <t>A POST request MUST result in a 201 (Created) response.</t>
<t>This forms an expectation in the client that the response will always </blockquote>
be <tt>201 Created</tt>, when in fact there are a number of reasons why the sta <t>This forms an expectation in the client that the response will always
tus code might differ in a real deployment; for example, there might be a proxy be 201 (Created) when in fact there are a number of reasons why the status code
that requires authentication, or a server-side error, or a redirection. If the c might differ in a real deployment; for example, there might be a proxy that req
lient does not anticipate this, the application's deployment is brittle.</t> uires authentication, or a server-side error, or a redirection. If the client do
es not anticipate this, the application's deployment is brittle.</t>
<t>See <xref target="resource" format="default"/> for more details.</t> <t>See <xref target="resource" format="default"/> for more details.</t>
</section> </section>
<section anchor="links" numbered="true" toc="default"> <section anchor="links" numbered="true" toc="default">
<name>Links</name> <name>Links</name>
<t>Another common practice is assuming that the HTTP server's name space <t>Another common practice is assuming that the HTTP server's namespace
(or a portion thereof) is exclusively for the use of a single application. This (or a portion thereof) is exclusively for the use of a single application. This
effectively overlays special, application-specific semantics onto that space, p effectively overlays special, application-specific semantics onto that space and
recludes other applications from using it.</t> precludes other applications from using it.</t>
<t>As explained in <xref target="RFC8820" format="default"/>, such "squa <t>As explained in <xref target="BCP190" format="default"/>, such "squat
tting" on a part of the URL space by a standard usurps the server's authority ov ting" on a part of the URL space by a standard usurps the server's authority ove
er its own resources, can cause deployment issues, and is therefore bad practice r its own resources, can cause deployment issues, and is therefore bad practice
in standards.</t> in standards.</t>
<t>Instead of statically defining URI components like paths, it is RECOM <t>Instead of statically defining URI components like paths, it is <bcp1
MENDED that applications using HTTP define and use links <xref target="WEB-LINKI 4>RECOMMENDED</bcp14> that applications using HTTP define and use links <xref ta
NG" format="default"/> to allow flexibility in deployment.</t> rget="WEB-LINKING" format="default"/> to allow flexibility in deployment.</t>
<t>Using runtime links in this fashion has a number of other benefits -- especially when an application is to have multiple implementations and/or deplo yments (as is often the case for those that are standardised).</t> <t>Using runtime links in this fashion has a number of other benefits -- especially when an application is to have multiple implementations and/or deplo yments (as is often the case for those that are standardised).</t>
<t>For example, navigating with a link allows a request to be routed to a different server without the overhead of a redirection, thereby supporting dep loyment across machines well.</t> <t>For example, navigating with a link allows a request to be routed to a different server without the overhead of a redirection, thereby supporting dep loyment across machines well.</t>
<t>It also becomes possible to "mix and match" different applications on <t>By using links, it also becomes possible to "mix and match" different
the same server, and offers a natural mechanism for extensibility, versioning a applications on the same server. The use of links also offers a natural mechani
nd capability management, since the document containing the links can also conta sm for extensibility, versioning, and capability management because the document
in information about their targets.</t> containing the links can also contain information about their targets.</t>
<t>Using links also offers a form of cache invalidation that's seen on t <t>Using links also offers a form of cache invalidation that's seen on t
he Web; when a resource's state changes, the application can change its link to he Web; when a resource's state changes, the application can change the affected
it so that a fresh copy is always fetched.</t> links so that a fresh copy is always fetched.</t>
<t>See <xref target="specifying-urls" format="default"/> for more detail
s.</t>
</section> </section>
<section anchor="rich-functionality" numbered="true" toc="default"> <section anchor="rich-functionality" numbered="true" toc="default">
<name>Rich Functionality</name> <name>Rich Functionality</name>
<t>HTTP offers a number of features to applications, such as:</t> <t>HTTP offers a number of features to applications, such as:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Message framing</li> <li>Message framing</li>
<li>Multiplexing (in HTTP/2 <xref target="HTTP2" format="default"/> an d HTTP/3 <xref target="HTTP3" format="default"/>)</li> <li>Multiplexing (in HTTP/2 <xref target="HTTP2" format="default"/> an d HTTP/3 <xref target="HTTP3" format="default"/>)</li>
<li>Integration with TLS</li> <li>Integration with TLS</li>
<li>Support for intermediaries (proxies, gateways, Content Delivery Ne tworks)</li> <li>Support for intermediaries (proxies, gateways, content delivery ne tworks (CDNs))</li>
<li>Client authentication</li> <li>Client authentication</li>
<li>Content negotiation for format, language, and other features</li> <li>Content negotiation for format, language, and other features</li>
<li>Caching for server scalability, latency and bandwidth reduction, a nd reliability</li> <li>Caching for server scalability, latency and bandwidth reduction, a nd reliability</li>
<li>Granularity of access control (through use of a rich space of URLs )</li> <li>Granularity of access control (through use of a rich space of URLs )</li>
<li>Partial content to selectively request part of a response</li> <li>Partial content to selectively request part of a response</li>
<li>The ability to interact with the application easily using a Web br owser</li> <li>The ability to interact with the application easily using a Web br owser</li>
</ul> </ul>
<t>Applications that use HTTP are encouraged to utilise the various feat ures that the protocol offers, so that their users receive the maximum benefit f rom it, and to allow it to be deployed in a variety of situations. This document does not require specific features to be used, since the appropriate design tra deoffs are highly specific to a given situation. However, following the practice s in <xref target="bp" format="default"/> is a good starting point.</t> <t>An application that uses HTTP is encouraged to utilise the various fe atures that the protocol offers so that its users receive the maximum benefit fr om those features and so that the application can be deployed in a variety of si tuations. This document does not require specific features to be used since the appropriate design trade-offs are highly specific to a given situation. However, following the practices in <xref target="bp" format="default"/> is a good start ing point.</t>
</section> </section>
</section> </section>
<section anchor="bp" numbered="true" toc="default"> <section anchor="bp" numbered="true" toc="default">
<name>Best Practices for Specifying the Use of HTTP</name> <name>Best Practices for Specifying the Use of HTTP</name>
<t>This section contains best practices for specifying the use of HTTP by applications, including practices for specific HTTP protocol elements.</t> <t>This section contains best practices for specifying the use of HTTP by applications, including practices for specific HTTP protocol elements.</t>
<section anchor="specifying-the-use-of-http" numbered="true" toc="default" > <section anchor="specifying-the-use-of-http" numbered="true" toc="default" >
<name>Specifying the Use of HTTP</name> <name>Specifying the Use of HTTP</name>
<t>Specifications should use <xref target="HTTP" format="default"/> as t he primary reference for HTTP; it is not necessary to reference all of the speci fications in the HTTP suite unless there are specific reasons to do so (e.g., a particular feature is called out).</t> <t>Specifications should use <xref target="HTTP" format="default"/> as t he primary reference for HTTP; it is not necessary to reference all of the speci fications in the HTTP suite unless there are specific reasons to do so (e.g., a particular feature is called out).</t>
<t>Because HTTP is a hop-by-hop protocol, a connection can be handled by <t>Because HTTP is a hop-by-hop protocol, a connection can be handled by
implementations that are not controlled by the application; for example, proxie implementations that are not controlled by the application; for example, proxie
s, CDNs, firewalls and so on. Requiring a particular version of HTTP makes it di s, CDNs, firewalls, and so on. Requiring a particular version of HTTP makes it d
fficult to use in these situations, and harms interoperability. Therefore, it is ifficult to use in these situations and harms interoperability. Therefore, it is
NOT RECOMMENDED that applications using HTTP specify a minimum version of HTTP <bcp14>NOT RECOMMENDED</bcp14> that applications using HTTP specify a minimum v
to be used.</t> ersion of HTTP to be used.</t>
<t>However, if an application's deployment would benefit from the use of <t>However, if an application's deployment benefits from the use of a pa
a particular version of HTTP (for example, HTTP/2's multiplexing), this ought b rticular version of HTTP (for example, HTTP/2's multiplexing), this ought be not
e noted.</t> ed.</t>
<t>Applications using HTTP MUST NOT specify a maximum version, to preser <t>Applications using HTTP <bcp14>MUST NOT</bcp14> specify a maximum ver
ve the protocol's ability to evolve.</t> sion, to preserve the protocol's ability to evolve.</t>
<t>When specifying examples of protocol interactions, applications shoul <t>When specifying examples of protocol interactions, applications shoul
d document both the request and response messages, with complete header sections d document both the request and response messages with complete header sections,
, preferably in HTTP/1.1 format <xref target="HTTP11" format="default"/>. For ex preferably in HTTP/1.1 format <xref target="HTTP11" format="default"/>. For exa
ample:</t> mple:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
GET /thing HTTP/1.1 GET /thing HTTP/1.1
Host: example.com Host: example.com
Accept: application/things+json Accept: application/things+json
User-Agent: Foo/1.0 User-Agent: Foo/1.0
]]></sourcecode> ]]></sourcecode>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
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]
]]></sourcecode> ]]></sourcecode>
</section> </section>
<section anchor="resource" numbered="true" toc="default"> <section anchor="resource" numbered="true" toc="default">
<name>Specifying Server Behaviour</name> <name>Specifying Server Behaviour</name>
<t>The server-side behaviours of an application are most effectively spe cified by defining the following protocol elements:</t> <t>The server-side behaviours of an application are most effectively spe cified by defining the following protocol elements:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Media types <xref target="RFC6838" format="default"/>, often based <li>Media types <xref target="RFC6838" format="default"/>, often based
upon a format convention such as JSON <xref target="JSON" format="default"/>,</ upon a format convention such as JSON <xref target="JSON" format="default"/>;</
li> li>
<li>HTTP header fields, as per <xref target="headers" format="default" <li>HTTP header fields, per <xref target="headers" format="default"/>;
/>, and</li> and</li>
<li>The behaviour of resources, as identified by link relations <xref target="WEB-LINKING" format="default"/>.</li> <li>The behaviour of resources, as identified by link relations <xref target="WEB-LINKING" format="default"/>.</li>
</ul> </ul>
<t>An application can define its operation by composing these protocol e lements to define a set of resources that are identified by link relations and t hat implement specified behaviours, including:</t> <t>An application can define its operation by composing these protocol e lements to define a set of resources that are identified by link relations and t hat implement specified behaviours, including:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>retrieval of their state using GET, in one or more formats identif ied by media type;</li> <li>retrieval of resource state using GET in one or more formats ident ified by media type;</li>
<li>resource creation or update using POST or PUT, with an appropriate ly identified request content format;</li> <li>resource creation or update using POST or PUT, with an appropriate ly identified request content format;</li>
<li>data processing using POST and identified request and response con tent format(s); and</li> <li>data processing using POST and identified request and response con tent format(s); and</li>
<li>Resource deletion using DELETE.</li> <li>Resource deletion using DELETE.</li>
</ul> </ul>
<t>For example, an application might specify:</t> <t>For example, an application might specify:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <blockquote>
Resources linked to with the "example-widget" link relation type are <t>Resources linked to with the "example-widget" link relation type are
Widgets. The state of a Widget can be fetched in the Widgets. The state of a Widget can be fetched in the
"application/example-widget+json" format, and can be updated by PUT "application/example-widget+json" format, and can be updated by PUT
to the same link. Widget resources can be deleted. to the same link. Widget resources can be deleted.</t>
The "Example-Count" response header field on Widget representations <t>The Example-Count response header field on Widget representations
indicates how many Widgets are held by the sender. indicates how many Widgets are held by the sender.</t>
The "application/example-widget+json" format is a JSON [RFC8259] <t>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.</t>
]]></artwork> </blockquote>
<t>Applications can also specify the use of URI Templates <xref target=" URI-TEMPLATE" format="default"/> to allow clients to generate URLs based upon ru ntime data.</t> <t>Applications can also specify the use of URI Templates <xref target=" URI-TEMPLATE" format="default"/> to allow clients to generate URLs based upon ru ntime data.</t>
</section> </section>
<section anchor="clients" numbered="true" toc="default"> <section anchor="clients" numbered="true" toc="default">
<name>Specifying Client Behaviour</name> <name>Specifying Client Behaviour</name>
<t>An application's expectations for client behaviour ought to be closel <t>An application's expectations for client behaviour ought to be closel
y aligned with those of Web browsers, to avoid interoperability issues when they y aligned with those of Web browsers to avoid interoperability issues when they
are used.</t> are used.</t>
<t>One way to do this is to define it in terms of <xref target="FETCH" f <t>One way to do this is to define it in terms of <xref target="FETCH" f
ormat="default"/>, since that is the abstraction that browsers use for HTTP.</t> ormat="default"/> since that is the abstraction that browsers use for HTTP.</t>
<t>Some client behaviours (e.g., automatic redirect handling) and extens <t>Some client behaviours (e.g., automatic redirect handling) and extens
ions (e.g., Cookies) are not required by HTTP, but nevertheless have become very ions (e.g., cookies) are not required by HTTP but nevertheless have become very
common. If their use is not explicitly specified by applications using HTTP, th common. If their use is not explicitly specified by applications using HTTP, the
ere may be confusion and interoperability problems. In particular:</t> re may be confusion and interoperability problems. In particular:</t>
<ul spacing="normal"> <dl spacing="normal">
<li>Redirect handling - Applications need to specify how redirects are <dt>Redirect handling:</dt><dd>Applications need to specify how redire
expected to be handled; see <xref target="redirects" format="default"/>.</li> cts are expected to be handled; see <xref target="redirects" format="default"/>.
<li>Cookies - Applications using HTTP should explicitly reference the </dd>
Cookie specification <xref target="COOKIES" format="default"/> if they are requi <dt>Cookies:</dt><dd>Applications using HTTP should explicitly referen
red.</li> ce the Cookie specification <xref target="COOKIES" format="default"/> if they ar
<li>Certificates - Applications using HTTP should specify that TLS cer e required.</dd>
tificates are to be checked according to <xref section="4.3.4" sectionFormat="of <dt>Certificates:</dt><dd>Applications using HTTP should specify that
" target="HTTP" format="default"/> when HTTPS is used.</li> TLS certificates are to be checked according to <xref section="4.3.4" sectionFor
</ul> mat="of" target="HTTP" format="default"/> when HTTPS is used.</dd>
<t>Applications using HTTP should not statically require HTTP features t </dl>
hat are usually negotiated to be supported by clients. For example, requiring th <t>Applications using HTTP should not require that clients statically su
at clients support responses with a certain content-coding (<xref section="8.4.1 pport HTTP features that are usually negotiated. For example, requiring that cli
" sectionFormat="comma" target="HTTP" format="default"/>) instead of negotiating ents support responses with a certain content coding (<xref section="8.4.1" sect
for it (<xref section="12.5.3" sectionFormat="comma" target="HTTP" format="defa ionFormat="comma" target="HTTP" format="default"/>) instead of negotiating for i
ult"/>) means that otherwise conformant clients cannot interoperate with the app t (<xref section="12.5.3" sectionFormat="comma" target="HTTP" format="default"/>
lication. Applications can encourage the implementation of such features, though ) means that otherwise conformant clients cannot interoperate with the applicati
.</t> on. Applications can encourage the implementation of such features, though.</t>
</section> </section>
<section anchor="specifying-urls" numbered="true" toc="default"> <section anchor="specifying-urls" numbered="true" toc="default">
<name>Specifying URLs</name> <name>Specifying URLs</name>
<t>In HTTP, the resources that clients interact with are identified with URLs <xref target="URL" format="default"/>. As <xref target="RFC8820" format="d efault"/> explains, parts of the URL are designed to be under the control of the owner (also known as the "authority") of that server, to give them the flexibil ity in deployment.</t> <t>In HTTP, the resources that clients interact with are identified with URLs <xref target="URL" format="default"/>. As <xref target="BCP190" format="de fault"/> explains, parts of the URL are designed to be under the control of the owner (also known as the "authority") of that server to give them the flexibilit y in deployment.</t>
<t>This means that in most cases, specifications for applications that u se HTTP won't contain fixed application URLs or paths; while it is common practi ce for a specification of a single-deployment API to specify the path prefix "/a pp/v1" (for example), doing so in an IETF specification is inappropriate.</t> <t>This means that in most cases, specifications for applications that u se HTTP won't contain fixed application URLs or paths; while it is common practi ce for a specification of a single-deployment API to specify the path prefix "/a pp/v1" (for example), doing so in an IETF specification is inappropriate.</t>
<t>Therefore, the specification writer needs some mechanism to allow cli ents to discovery an application's URLs. Additionally, they need to specify what URL scheme(s) the application should be used with, and whether to use a dedicat ed port, or reuse HTTP's port(s).</t> <t>Therefore, the specification writer needs some mechanism to allow cli ents to discover an application's URLs. Additionally, they need to specify which URL scheme(s) the application should be used with and whether to use a dedicate d port or to reuse HTTP's port(s).</t>
<section anchor="discovering-an-applications-urls" numbered="true" toc=" default"> <section anchor="discovering-an-applications-urls" numbered="true" toc=" default">
<name>Discovering an Application's URLs</name> <name>Discovering an Application's URLs</name>
<t>Generally, a client will begin interacting with a given application server by requesting an initial document that contains information about that p articular deployment, potentially including links to other relevant resources. D oing so assures that the deployment is as flexible as possible (potentially span ning multiple servers), allows evolution, and also gives the application the opp ortunity to tailor the 'discovery document' to the client.</t> <t>Generally, a client will begin interacting with a given application server by requesting an initial document that contains information about that p articular deployment, potentially including links to other relevant resources. D oing so ensures that the deployment is as flexible as possible (potentially span ning multiple servers), allows evolution, and also gives the application the opp ortunity to tailor the "discovery document" to the client.</t>
<t>There are a few common patterns for discovering that initial URL.</ t> <t>There are a few common patterns for discovering that initial URL.</ t>
<t>The most straightforward mechanism for URL discovery is to configur e the client with (or otherwise convey to it) a full URL. This might be done in a configuration document, or through another discovery mechanism.</t> <t>The most straightforward mechanism for URL discovery is to configur e the client with (or otherwise convey to it) a full URL. This might be done in a configuration document or through another discovery mechanism.</t>
<t>However, if the client only knows the server's hostname and the ide ntity of the application, there needs to be some way to derive the initial URL f rom that information.</t> <t>However, if the client only knows the server's hostname and the ide ntity of the application, there needs to be some way to derive the initial URL f rom that information.</t>
<t>An application cannot define a fixed prefix for its URL paths; see <xref target="RFC8820" format="default"/>. Instead, a specification for such an application can use one of the following strategies:</t> <t>An application cannot define a fixed prefix for its URL paths; see <xref target="BCP190" format="default"/>. Instead, a specification for such an a pplication can use one of the following strategies:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Register a Well-Known URI <xref target="WELL-KNOWN-URI" format=" default"/> as an entry point for that application. This provides a fixed path on every potential server that will not collide with other applications.</li> <li>Register a well-known URI <xref target="WELL-KNOWN-URI" format=" default"/> as an entry point for that application. This provides a fixed path on every potential server that will not collide with other applications.</li>
<li>Enable the server authority to convey a URI Template <xref targe t="URI-TEMPLATE" format="default"/> or similar mechanism for generating a URL fo r an entry point. For example, this might be done in a configuration document or other artefact.</li> <li>Enable the server authority to convey a URI Template <xref targe t="URI-TEMPLATE" format="default"/> or similar mechanism for generating a URL fo r an entry point. For example, this might be done in a configuration document or other artefact.</li>
</ul> </ul>
<t>Once the discovery document is located, it can be fetched, cached f <t>Once the discovery document is located, it can be fetched, cached f
or later reuse (if allowed by its metadata), and used to locate other resources or later reuse (if allowed by its metadata), and used to locate other resources
that are relevant to the application, using full URIs or URL Templates.</t> that are relevant to the application using full URIs or URL Templates.</t>
<t>In some cases, an application may not wish to use such a discovery <t>In some cases, an application may not wish to use such a discovery
document; for example, when communication is very brief, or when the latency con document -- for example, when communication is very brief or when the latency co
cerns of doing so precludes the use of a discovery document. These situations ca ncerns of doing so preclude the use of a discovery document. These situations ca
n be addressed by placing all of the application's resources under a well-known n be addressed by placing all of the application's resources under a well-known
location.</t> location.</t>
</section> </section>
<section anchor="scheme" numbered="true" toc="default"> <section anchor="scheme" numbered="true" toc="default">
<name>Considering URI Schemes</name> <name>Considering URI Schemes</name>
<t>Applications that use HTTP will typically employ the "http" and/or <t>Applications that use HTTP will typically employ the "http" and/or
"https" URI schemes. "https" is RECOMMENDED to provide authentication, integrity "https" URI schemes. "https" is <bcp14>RECOMMENDED</bcp14> to provide authentica
and confidentiality, as well as mitigate pervasive monitoring attacks <xref tar tion, integrity, and confidentiality, as well as to mitigate pervasive monitorin
get="RFC7258" format="default"/>.</t> g attacks <xref target="RFC7258" format="default"/>.</t>
<t>However, application-specific schemes can also be defined. When def <t>However, application-specific schemes can also be defined. When def
ining an URI scheme for an application using HTTP, there are a number of tradeof ining a URI scheme for an application using HTTP, there are a number of trade-of
fs and caveats to keep in mind:</t> fs and caveats to keep in mind:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Unmodified Web browsers will not support the new scheme. While i <li>Unmodified Web browsers will not support the new scheme. While i
t is possible to register new URI schemes with Web browsers (e.g. registerProtoc t is possible to register new URI schemes with Web browsers (e.g., registerProto
olHandler() in <xref target="HTML" format="default"/>, as well as several propri colHandler() in <xref target="HTML" format="default"/>, as well as several propr
etary approaches), support for these mechanisms is not shared by all browsers, a ietary approaches), support for these mechanisms is not shared by all browsers,
nd their capabilities vary.</li> and their capabilities vary.</li>
<li>Existing non-browser clients, intermediaries, servers and associ <li>Existing non-browser clients, intermediaries, servers, and associated so
ated software will not recognise the new scheme. For example, a client library m ftware will not recognise the new scheme. For example, a client library might f
ight fail to dispatch the request; a cache might refuse to store the response, a ail to dispatch the request, a cache might refuse to store the response, and a p
nd a proxy might fail to forward the request.</li> roxy might fail to forward the request.</li>
<li>Because URLs occur in HTTP artefacts commonly, often being gener <li>Because URLs commonly occur in HTTP artefacts and are often gene
ated automatically (e.g., in the <tt>Location</tt> response header field), it ca rated automatically (e.g., in the Location response header field), it can be dif
n be difficult to assure that the new scheme is used consistently.</li> ficult to ensure that the new scheme is used consistently.</li>
<li>The resources identified by the new scheme will still be availab <li>The resources identified by the new scheme will still be availab
le using "http" and/or "https" URLs. Those URLs can "leak" into use, which can p le using "http" and/or "https" URLs. Those URLs can "leak" into use, which can p
resent security and operability issues. For example, using a new scheme to assur resent security and operability issues. For example, using a new scheme to ensur
e that requests don't get sent to a "normal" Web site is likely to fail.</li> e that requests don't get sent to a "normal" Web site is likely to fail.</li>
<li>Features that rely upon the URL's origin <xref target="RFC6454" format="default"/>, such as the Web's same-origin policy, will be impacted by a change of scheme.</li> <li>Features that rely upon the URL's origin <xref target="RFC6454" format="default"/>, such as the Web's same-origin policy, will be impacted by a change of scheme.</li>
<li>HTTP-specific features such as cookies <xref target="COOKIES" fo rmat="default"/>, authentication <xref target="HTTP" format="default"/>, caching <xref target="HTTP-CACHING" format="default"/>, HSTS <xref target="RFC6797" for mat="default"/>, and CORS <xref target="FETCH" format="default"/> might or might not work correctly, depending on how they are defined and implemented. Generall y, they are designed and implemented with an assumption that the URL will always be "http" or "https".</li> <li>HTTP-specific features such as cookies <xref target="COOKIES" fo rmat="default"/>, authentication <xref target="HTTP" format="default"/>, caching <xref target="HTTP-CACHING" format="default"/>, HTTP Strict Transport Security (HSTS) <xref target="RFC6797" format="default"/>, and Cross-Origin Resource Shar ing (CORS) <xref target="FETCH" format="default"/> might or might not work corre ctly, depending on how they are defined and implemented. Generally, they are des igned and implemented with an assumption that the URL will always be "http" or " https".</li>
<li>Web features that require a secure context <xref target="SECCTXT " format="default"/> will likely treat a new scheme as insecure.</li> <li>Web features that require a secure context <xref target="SECCTXT " format="default"/> will likely treat a new scheme as insecure.</li>
</ul> </ul>
<t>See <xref target="RFC7595" format="default"/> for more information about minting new URI schemes.</t> <t>See <xref target="RFC7595" format="default"/> for more information about minting new URI schemes.</t>
</section> </section>
<section anchor="transport-ports" numbered="true" toc="default"> <section anchor="choosing-transport-ports" numbered="true" toc="default"
<name>Transport Ports</name> >
<t>Applications can use the applicable default port (80 for HTTP, 443 <name>Choosing Transport Ports</name>
for HTTPS), or they can be deployed upon other ports. This decision can be made <t>Applications can use the applicable default port (80 for HTTP, 443
at deployment time, or might be encouraged by the application's specification (e for HTTPS), or they can be deployed upon other ports. This decision can be made
.g., by registering a port for that application).</t> at deployment time or might be encouraged by the application's specification (e.
g., by registering a port for that application).</t>
<t>If a non-default port is used, it needs to be reflected in the auth ority of all URLs for that resource; the only mechanism for changing a default p ort is changing the URI scheme (see <xref target="scheme" format="default"/>).</ t> <t>If a non-default port is used, it needs to be reflected in the auth ority of all URLs for that resource; the only mechanism for changing a default p ort is changing the URI scheme (see <xref target="scheme" format="default"/>).</ t>
<t>Using a port other than the default has privacy implications (i.e., the protocol can now be distinguished from other traffic), as well as operabili ty concerns (as some networks might block or otherwise interfere with it). Priva cy implications (including those stemming from this distinguishability) should b e documented in Security Considerations.</t> <t>Using a port other than the default has privacy implications (i.e., the protocol can now be distinguished from other traffic), as well as operabili ty concerns (as some networks might block or otherwise interfere with it). Priva cy implications (including those stemming from this distinguishability) should b e documented in Security Considerations.</t>
<t>See <xref target="RFC7605" format="default"/> for further guidance. </t> <t>See <xref target="RFC7605" format="default"/> for further guidance. </t>
</section> </section>
</section> </section>
<section anchor="using-http-methods" numbered="true" toc="default"> <section anchor="using-http-methods" numbered="true" toc="default">
<name>Using HTTP Methods</name> <name>Using HTTP Methods</name>
<t>Applications that use HTTP MUST confine themselves to using registere <t>Applications that use HTTP <bcp14>MUST</bcp14> confine themselves to
d HTTP methods such as GET, POST, PUT, DELETE, and PATCH.</t> using registered HTTP methods such as GET, POST, PUT, DELETE, and PATCH.</t>
<t>New HTTP methods are rare; they are required to be registered in the <t>New HTTP methods are rare; they are required to be registered in the
HTTP Method Registry with IETF Review (see <xref target="HTTP" format="default"/ "HTTP Method Registry" with IETF Review (see <xref target="HTTP" format="default
>), and are also required to be generic. That means that they need to be potenti "/>) and are also required to be generic. That means that they need to be potent
ally applicable to all resources, not just those of one application.</t> ially applicable to all resources, not just those of one application.</t>
<t>While historically some applications (e.g., <xref target="RFC4791" fo <t>While historically some applications (e.g., <xref target="RFC4791" fo
rmat="default"/>) have defined non-generic methods, <xref target="HTTP" format=" rmat="default"/>) have defined application-specific methods, <xref target="HTTP"
default"/> now forbids this.</t> format="default"/> now forbids this.</t>
<t>When authors believe that a new method is required, they are encourag <t>When authors believe that a new method is required, they are encourag
ed to engage with the HTTP community early (e.g., on the ietf-http-wg@w3.org mai ed to engage with the HTTP community early (e.g., on the <eref target="mailto:ie
ling list), and document their proposal as a separate HTTP extension, rather tha tf-http-wg@w3.org" brackets="angle"/> mailing list) and document their proposal
n as part of an application's specification.</t> as a separate HTTP extension rather than as part of an application's specificati
on.</t>
<section anchor="get" numbered="true" toc="default"> <section anchor="get" numbered="true" toc="default">
<name>GET</name> <name>GET</name>
<t>GET is the most common and useful HTTP method; its retrieval semant <t>GET is the most common and useful HTTP method; its retrieval semant
ics allow caching, side-effect free linking and underlies many of the benefits o ics allow caching and side-effect free linking and underlie many of the benefits
f using HTTP.</t> of using HTTP.</t>
<t>Queries can be performed with GET, often using the query component <t>Queries can be performed with GET, often using the query component
of the URL; this is a familiar pattern from Web browsing, and the results can be of the URL; this is a familiar pattern from Web browsing, and the results can be
cached, improving efficiency of an often expensive process. In some cases, howe cached, improving the efficiency of an often expensive process. In some cases,
ver, GET might be unwieldy for expressing queries, because of the limited syntax however, GET might be unwieldy for expressing queries because of the limited syn
of the URI; in particular, if binary data forms part of the query terms, it nee tax of the URI; in particular, if binary data forms part of the query terms, it
ds to be encoded to conform to URI syntax.</t> needs to be encoded to conform to the URI syntax.</t>
<t>While this is not an issue for short queries, it can become one for <t>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 requests. Addi larger query terms or those that need to sustain a high rate of requests. Addit
tionally, some HTTP implementations limit the size of URLs they support -- altho ionally, some HTTP implementations limit the size of URLs they support, although
ugh modern HTTP software has much more generous limits than previously (typicall modern HTTP software has much more generous limits than previously (typically,
y, considerably more than 8000 octets, as required by <xref target="HTTP" format considerably more than 8000 octets, as required by <xref target="HTTP" format="d
="default"/>).</t> efault"/>).</t>
<t>In these cases, an application using HTTP might consider using POST <t>In these cases, an application using HTTP might consider using POST
to express queries in the request's content; doing so avoids encoding overhead to express queries in the request's content; doing so avoids encoding overhead a
and URL length limits in implementations. However, in doing so it should be note nd URL length limits in implementations. However, in doing so, it should be note
d that the benefits of GET such as caching and linking to query results are lost d that the benefits of GET such as caching and linking to query results are lost
. Therefore, applications using HTTP that feel a need to allow POST queries ough . Therefore, applications using HTTP that require support for POST queries ough
t to consider allowing both methods.</t> t to consider allowing both methods.</t>
<t>Processing of GET requests should not change application state or h <t>Processing of GET requests should not change the application's stat
ave other side effects that might be significant to the client, since implementa e or have other side effects that might be significant to the client since imple
tions can and do retry HTTP GET requests that fail, and some GET requests protec mentations can and do retry HTTP GET requests that fail. Furthermore, some GET r
ted by TLS Early Data might be vulnerable to replay attacks (see <xref target="R equests protected by TLS early data might be vulnerable to replay attacks (see <
FC8470" format="default"/>). Note that this does not include logging and similar xref target="RFC8470" format="default"/>). Note that this does not include loggi
functions; see <xref section="9.2.1" sectionFormat="comma" target="HTTP" format ng and similar functions; see <xref section="9.2.1" sectionFormat="comma" target
="default"/>.</t> ="HTTP" format="default"/>.</t>
<t>Finally, note that while the generic HTTP syntax allows a GET reque <t>Finally, note that while the generic HTTP syntax allows a GET reque
st message to contain content, the purpose is to allow message parsers to be gen st message to contain content, the purpose is to allow message parsers to be gen
eric; as per <xref section="9.3.1" sectionFormat="comma" target="HTTP" format="d eric; per <xref section="9.3.1" sectionFormat="comma" target="HTTP" format="defa
efault"/>, content on a GET is not recommended, has no meaning, and will be eith ult"/>, content in a GET is not recommended, has no meaning, and will be either
er ignored or rejected by generic HTTP software (such as intermediaries, caches, ignored or rejected by generic HTTP software (such as intermediaries, caches, se
servers, and client libraries).</t> rvers, and client libraries).</t>
</section> </section>
<section anchor="options" numbered="true" toc="default"> <section anchor="options" numbered="true" toc="default">
<name>OPTIONS</name> <name>OPTIONS</name>
<t>The OPTIONS method was defined for metadata retrieval, and is used both by WebDAV <xref target="RFC4918" format="default"/> and CORS <xref target=" FETCH" format="default"/>. Because HTTP-based APIs often need to retrieve metada ta about resources, it is often considered for their use.</t> <t>The OPTIONS method was defined for metadata retrieval and is used b oth by Web Distributed Authoring and Versioning (WebDAV) <xref target="RFC4918" format="default"/> and CORS <xref target="FETCH" format="default"/>. Because HTT P-based APIs often need to retrieve metadata about resources, it is often consid ered for their use.</t>
<t>However, OPTIONS does have significant limitations:</t> <t>However, OPTIONS does have significant limitations:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>It isn't possible to link to the metadata with a simple URL, bec <li>It isn't possible to link to the metadata with a simple URL beca
ause OPTIONS is not the default method.</li> use OPTIONS is not the default method.</li>
<li>OPTIONS responses are not cacheable, because HTTP caches operate <li>OPTIONS responses are not cacheable because HTTP caches operate
on representations of the resource (i.e., GET and HEAD). If OPTIONS responses a on representations of the resource (i.e., GET and HEAD). If OPTIONS responses ar
re cached separately, their interaction with HTTP cache expiry, secondary keys a e cached separately, their interactions with the HTTP cache expiry, secondary ke
nd other mechanisms needs to be considered.</li> ys, and other mechanisms need to be considered.</li>
<li>OPTIONS is "chatty" - always separating metadata out into a sepa <li>OPTIONS is "chatty" -- requesting metadata separately increases
rate request increases the number of requests needed to interact with the applic the number of requests needed to interact with the application.</li>
ation.</li>
<li>Implementation support for OPTIONS is not universal; some server s do not expose the ability to respond to OPTIONS requests without significant e ffort.</li> <li>Implementation support for OPTIONS is not universal; some server s do not expose the ability to respond to OPTIONS requests without significant e ffort.</li>
</ul> </ul>
<t>Instead of OPTIONS, one of these alternative approaches might be mo re appropriate:</t> <t>Instead of OPTIONS, one of these alternative approaches might be mo re appropriate:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>For server-wide metadata, create a well-known URI <xref target=" WELL-KNOWN-URI" format="default"/>, or use an already existing one if appropriat e (e.g., HostMeta <xref target="RFC6415" format="default"/>).</li> <li>For server-wide metadata, create a well-known URI <xref target=" WELL-KNOWN-URI" format="default"/> or use an already existing one if appropriate (e.g., host-meta <xref target="RFC6415" format="default"/>).</li>
<li>For metadata about a specific resource, create a separate resour ce and link to it using a Link response header field or a link serialised into t he response's content. See <xref target="WEB-LINKING" format="default"/>. Note t hat the Link header field is available on HEAD responses, which is useful if the client wants to discover a resource's capabilities before they interact with it .</li> <li>For metadata about a specific resource, create a separate resour ce and link to it using a Link response header field or a link serialised into t he response's content. See <xref target="WEB-LINKING" format="default"/>. Note t hat the Link header field is available on HEAD responses, which is useful if the client wants to discover a resource's capabilities before they interact with it .</li>
</ul> </ul>
</section> </section>
</section> </section>
<section anchor="using-http-status-codes" numbered="true" toc="default"> <section anchor="using-http-status-codes" numbered="true" toc="default">
<name>Using HTTP Status Codes</name> <name>Using HTTP Status Codes</name>
<t>HTTP status codes convey semantics both for the benefit of generic HT TP components -- such as caches, intermediaries, and clients -- and applications themselves. However, applications can encounter a number of pitfalls in their u se.</t> <t>HTTP status codes convey semantics both for the benefit of generic HT TP components -- such as caches, intermediaries, and clients -- and applications themselves. However, applications can encounter a number of pitfalls in their u se.</t>
<t>First, status codes are often generated by components other than the <t>First, status codes are often generated by components other than the
application itself. This can happen, for example, when network errors are encoun application itself. This can happen, for example, when network errors are encoun
tered, a captive portal, proxy or Content Delivery Network is present, when a se tered; when a captive portal, proxy, or content delivery network is present; or
rver is overloaded, or it thinks it is under attack. They can even be generated when a server is overloaded or thinks it is under attack. They can even be gener
by generic client software when certain error conditions are encountered. As a r ated by generic client software when certain error conditions are encountered. A
esult, if an application assigns specific semantics to one of these status codes s a result, if an application assigns specific semantics to one of these status
, a client can be misled about its state, because the status code was generated codes, a client can be misled about its state because the status code was genera
by a generic component, not the application itself.</t> ted by a generic component, not the application itself.</t>
<t>Furthermore, mapping application errors to individual HTTP status cod <t>Furthermore, mapping application errors to individual HTTP status cod
es one-to-one often leads to a situation where the finite space of applicable HT es one-to-one often leads to a situation where the finite space of applicable HT
TP status codes is exhausted. This, in turn, leads to a number of bad practices TP status codes is exhausted. This, in turn, leads to a number of bad practices
-- including minting new, application-specific status codes, or using existing s -- including minting new, application-specific status codes or using existing st
tatus codes even though the link between their semantics and the application's i atus codes even though the link between their semantics and the application's is
s tenuous at best.</t> tenuous at best.</t>
<t>Instead, applications using HTTP should define their errors to use th <t>Instead, applications using HTTP should define their errors to use th
e most applicable status code, making generous use of the general status codes ( e most applicable status code, making generous use of the general status codes (
200, 400 and 500) when in doubt. Importantly, they should not specify a one-to-o 200, 400, and 500) when in doubt. Importantly, they should not specify a one-to-
ne relationship between status codes and application errors, thereby avoiding th one relationship between status codes and application errors, thereby avoiding t
e exhaustion issue outlined above.</t> he exhaustion issue outlined above.</t>
<t>To distinguish between multiple error conditions that are mapped to t <t>To distinguish between multiple error conditions that are mapped to t
he same status code, and to avoid the misattribution issue outlined above, appli he same status code and to avoid the misattribution issue outlined above, applic
cations using HTTP should convey finer-grained error information in the response ations using HTTP should convey finer-grained error information in the response'
's message content and/or header fields. <xref target="PROBLEM-DETAILS" format=" s message content and/or header fields. <xref target="PROBLEM-DETAILS" format="d
default"/> provides one way to do so.</t> efault"/> provides one way to do so.</t>
<t>Because the set of registered HTTP status codes can expand, applicati <t>Because the set of registered HTTP status codes can expand, applicati
ons using HTTP should explicitly point out that clients ought to be able to hand ons using HTTP should explicitly point out that clients ought to be able to hand
le all applicable status codes gracefully (i.e., falling back to the generic <tt le all applicable status codes gracefully (i.e., falling back to the generic n00
>n00</tt> semantics of a given status code; e.g., <tt>499</tt> can be safely han semantics of a given status code; e.g., 499 can be safely handled as 400 (Bad R
dled as <tt>400</tt> by clients that don't recognise it). This is preferable to equest) by clients that don't recognise it). This is preferable to creating a "l
creating a "laundry list" of potential status codes, since such a list won't be aundry list" of potential status codes since such a list won't be complete in th
complete in the foreseeable future.</t> e foreseeable future.</t>
<t>Applications using HTTP MUST NOT re-specify the semantics of HTTP sta <t>Applications using HTTP <bcp14>MUST NOT</bcp14> re-specify the semant
tus codes, even if it is only by copying their definition. It is NOT RECOMMENDED ics of HTTP status codes, even if it is only by copying their definition. It is
they require specific reason phrases to be used; the reason phrase has no funct <bcp14>NOT RECOMMENDED</bcp14> they require specific reason phrases to be used;
ion in HTTP, is not guaranteed to be preserved by implementations, and is not ca the reason phrase has no function in HTTP, is not guaranteed to be preserved by
rried at all in the HTTP/2 <contact fullname="HTTP2"/> message format.</t> implementations, and is not carried at all in the HTTP/2 <xref target="HTTP2" fo
<t>Applications MUST only use registered HTTP status codes. As with meth rmat="default"/> message format.</t>
ods, new HTTP status codes are rare, and required (by <xref target="HTTP" format <t>Applications <bcp14>MUST</bcp14> only use registered HTTP status code
="default"/>) to be registered with IETF Review. Similarly, HTTP status codes ar s. As with methods, new HTTP status codes are rare and required (by <xref target
e generic; they are required (by <xref target="HTTP" format="default"/>) to be p ="HTTP" format="default"/>) to be registered with IETF Review. Similarly, HTTP s
otentially applicable to all resources, not just to those of one application.</t tatus codes are generic; they are required (by <xref target="HTTP" format="defau
> lt"/>) to be potentially applicable to all resources, not just to those of one a
<t>When authors believe that a new status code is required, they are enc pplication.</t>
ouraged to engage with the HTTP community early (e.g., on the ietf-http-wg@w3.or <t>When authors believe that a new status code is required, they are enc
g mailing list), and document their proposal as a separate HTTP extension, rathe ouraged to engage with the HTTP community early (e.g., on the <eref target="mail
r than as part of an application's specification.</t> to:ietf-http-wg@w3.org" brackets="angle"/> mailing list) and document their prop
osal as a separate HTTP extension, rather than as part of an application's speci
fication.</t>
<section anchor="redirects" numbered="true" toc="default"> <section anchor="redirects" numbered="true" toc="default">
<name>Redirection</name> <name>Redirection</name>
<t>The 3xx series of status codes specified in <xref section="15.4" se ctionFormat="of" target="HTTP" format="default"/> direct the user agent to anoth er resource to satisfy the request. The most common of these are 301, 302, 307 a nd 308, all of which use the Location response header field to indicate where th e client should resend the request.</t> <t>The 3xx series of status codes specified in <xref section="15.4" se ctionFormat="of" target="HTTP" format="default"/> directs the user agent to anot her resource to satisfy the request. The most common of these are 301, 302, 307, and 308, all of which use the Location response header field to indicate where the client should resend the request.</t>
<t>There are two ways that the members of this group of status codes d iffer:</t> <t>There are two ways that the members of this group of status codes d iffer:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Whether they are permanent or temporary. Permanent redirects can be used to update links stored in the client (e.g., bookmarks), whereas tempora ry ones cannot. Note that this has no effect on HTTP caching; it is completely s eparate.</li> <li>Whether they are permanent or temporary. Permanent redirects can be used to update links stored in the client (e.g., bookmarks), whereas tempora ry ones cannot. Note that this has no effect on HTTP caching; it is completely s eparate.</li>
<li>Whether they allow the redirected request to change the request method from POST to GET. Web browsers generally do change POST to GET for 301 an d 302; therefore, 308 and 307 were created to allow redirection without changing the method.</li> <li>Whether they allow the redirected request to change the request method from POST to GET. Web browsers generally do change POST to GET for 301 an d 302; therefore, 308 and 307 were created to allow redirection without changing the method.</li>
</ul> </ul>
<t>This table summarises their relationships:</t> <t>This table summarises their relationships:</t>
<table align="center"> <table align="center">
<thead> <thead>
<tr> <tr>
<th align="left">&nbsp;</th> <th align="left">&nbsp;</th>
<th align="left">Permanent</th> <th align="left">Permanent</th>
<th align="left">Temporary</th> <th align="left">Temporary</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">Allows changing the request method from POST to GET</td> <td align="left">Allows change of the request method from POST t o GET</td>
<td align="left">301</td> <td align="left">301</td>
<td align="left">302</td> <td align="left">302</td>
</tr> </tr>
<tr> <tr>
<td align="left">Does not allow changing the request method</td> <td align="left">Does not allow change of the request method</td >
<td align="left">308</td> <td align="left">308</td>
<td align="left">307</td> <td align="left">307</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>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.</t> <t>The 303 (See Other) status code can be used to inform the client th at the result of an operation is available at a different location using GET.</t >
<t>As noted in <xref target="HTTP" format="default"/>, a user agent is allowed to automatically follow a 3xx redirect that has a Location response hea der field, even if they don't understand the semantics of the specific status co de. However, they aren't required to do so; therefore, if an application using H TTP desires redirects to be automatically followed, it needs to explicitly speci fy the circumstances when this is required.</t> <t>As noted in <xref target="HTTP" format="default"/>, a user agent is allowed to automatically follow a 3xx redirect that has a Location response hea der field, even if they don't understand the semantics of the specific status co de. However, they aren't required to do so; therefore, if an application using H TTP desires redirects to be automatically followed, it needs to explicitly speci fy the circumstances when this is required.</t>
<t>Redirects can be cached (when appropriate cache directives are pres <t>Redirects can be cached (when appropriate cache directives are pres
ent), but beyond that they are not 'sticky' -- i.e., redirection of a URI will n ent), but beyond that, they are not "sticky" -- i.e., redirection of a URI will
ot result in the client assuming that similar URIs (e.g., with different query p not result in the client assuming that similar URIs (e.g., with different query
arameters) will also be redirected.</t> parameters) will also be redirected.</t>
<t>Applications using HTTP are encouraged to specify that 301 and 302 <t>Applications using HTTP are encouraged to specify that 301 and 302
responses change the subsequent request method from POST (but no other method) t responses change the subsequent request method from POST (but no other method) t
o GET, to be compatible with browsers. o GET to be compatible with browsers.
Generally, when a redirected request is made, its header fields are copied from Generally, when a redirected request is made, its header fields are copied from
the original request's. However, they can be modified by various mechanisms; e.g the original request. However, they can be modified by various mechanisms; e.g.,
., sent Authorization (<xref section="11" sectionFormat="comma" target="HTTP" fo sent Authorization (<xref section="11" sectionFormat="comma" target="HTTP" form
rmat="default"/>) and Cookie (<xref target="COOKIES" format="default"/>) header at="default"/>) and Cookie (<xref target="COOKIES" format="default"/>) header fi
fields will change if the origin (and sometimes path) of the request changes. An elds will change if the origin (and sometimes path) of the request changes. An a
application using HTTP should specify if any request header fields that it defi pplication using HTTP should specify if any request header fields that it define
nes need to be modified or removed upon a redirect; however, this behaviour cann s need to be modified or removed upon a redirect; however, this behaviour cannot
ot be relied upon, since a generic client (like a browser) will be unaware of su be relied upon since a generic client (like a browser) will be unaware of such
ch requirements.</t> requirements.</t>
</section> </section>
</section> </section>
<section anchor="headers" numbered="true" toc="default"> <section anchor="headers" numbered="true" toc="default">
<name>Specifying HTTP Header Fields</name> <name>Specifying HTTP Header Fields</name>
<t>Applications often define new HTTP header fields. Typically, using HT TP header fields is appropriate in a few different situations:</t> <t>Applications often define new HTTP header fields. Typically, using HT TP header fields is appropriate in a few different situations:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>The field is useful to intermediaries (who often wish to avoid par sing message content), and/or</li> <li>The field is useful to intermediaries (who often wish to avoid par sing message content), and/or</li>
<li>The field is useful to generic HTTP software (e.g., clients, serve rs), and/or</li> <li>The field is useful to generic HTTP software (e.g., clients, serve rs), and/or</li>
<li>It is not possible to include their values in the message content (usually because a format does not allow it).</li> <li>It is not possible to include their values in the message content (usually because a format does not allow it).</li>
</ul> </ul>
<t>When the conditions above are not met, it is usually better to convey <t>When the conditions above are not met, it is usually better to convey
application-specific information in other places; e.g., the message content or application-specific information in other places -- e.g., the message content o
the URL query string.</t> r the URL query string.</t>
<t>New header fields MUST be registered, as per <xref section="16.3" sec <t>New header fields <bcp14>MUST</bcp14> be registered, per <xref sectio
tionFormat="of" target="HTTP" format="default"/>.</t> n="16.3" sectionFormat="of" target="HTTP" format="default"/>.</t>
<t>See <xref section="16.3.2" sectionFormat="of" target="HTTP" format="d <t>See <xref section="16.3.2" sectionFormat="of" target="HTTP" format="d
efault"/> for guidelines to consider when minting new header fields. <xref targe efault"/> for guidelines to consider when minting new header fields. <xref targe
t="STRUCTURED-FIELDS" format="default"/> provides a common structure for new hea t="STRUCTURED-FIELDS" format="default"/> provides a common structure for new hea
der fields, and avoids many issues in their parsing and handling; it is RECOMMEN der fields and avoids many issues in their parsing and handling; it is <bcp14>RE
DED that new header fields use it.</t> COMMENDED</bcp14> that new header fields use it.</t>
<t>It is RECOMMENDED that header field names be short (even when field c <t>It is <bcp14>RECOMMENDED</bcp14> that header field names be short (ev
ompression is used, there is an overhead) but appropriately specific. In particu en when field compression is used, there is an overhead) but appropriately speci
lar, if a header field is specific to an application, an identifier for that app fic. In particular, if a header field is specific to an application, an identifi
lication can form a prefix to the header field name, separated by a "-".</t> er for that application can form a prefix to the header field name, separated by
<t>For example, if the "example" application needs to create three heade a hyphen.</t>
r fields, they might be called "example-foo", "example-bar" and "example-baz". N <t>For example, if the "example" application needs to create three heade
ote that the primary motivation here is to avoid consuming more generic field na r fields, they might be called "example-foo", "example-bar", and "example-baz".
mes, not to reserve a portion of the namespace for the application; see <xref ta Note that the primary motivation here is to avoid consuming more generic field n
rget="RFC6648" format="default"/> for related considerations.</t> ames, not to reserve a portion of the namespace for the application; see <xref t
<t>The semantics of existing HTTP header fields MUST NOT be re-defined w arget="RFC6648" format="default"/> for related considerations.</t>
ithout updating their registration or defining an extension to them (if allowed) <t>The semantics of existing HTTP header fields <bcp14>MUST NOT</bcp14>
. For example, an application using HTTP cannot specify that the <tt>Location</t be redefined without updating their registration or defining an extension to the
t> header field has a special meaning in a certain context.</t> m (if allowed). For example, an application using HTTP cannot specify that the L
<t>See <xref target="caching" format="default"/> for the interaction bet ocation header field has a special meaning in a certain context.</t>
ween header fields and HTTP caching; in particular, request header fields that a <t>See <xref target="caching" format="default"/> for the interaction bet
re used to "select" a response have impact there, and need to be carefully consi ween header fields and HTTP caching; in particular, request header fields that a
dered.</t> re used to choose (per <xref section="4.1" sectionFormat="of" target="HTTP-CACHI
NG" format="default"/>) a response have impact there and need to be carefully co
nsidered.</t>
<t>See <xref target="state" format="default"/> for considerations regard ing header fields that carry application state (e.g., Cookie).</t> <t>See <xref target="state" format="default"/> for considerations regard ing header fields that carry application state (e.g., Cookie).</t>
</section> </section>
<section anchor="content" numbered="true" toc="default"> <section anchor="content" numbered="true" toc="default">
<name>Defining Message Content</name> <name>Defining Message Content</name>
<t>Common syntactic conventions for message contents include JSON <xref target="JSON" format="default"/>, XML <xref target="XML" format="default"/>, and CBOR <xref target="RFC8949" format="default"/>. Best practices for their use ar e out of scope for this document.</t> <t>Common syntactic conventions for message contents include JSON <xref target="JSON" format="default"/>, XML <xref target="XML" format="default"/>, and Concise Binary Object Representation (CBOR) <xref target="RFC8949" format="defa ult"/>. Best practices for their use are out of scope for this document.</t>
<t>Applications should register distinct media types for each format the y define; this makes it possible to identify them unambiguously and negotiate fo r their use. See <xref target="RFC6838" format="default"/> for more information. </t> <t>Applications should register distinct media types for each format the y define; this makes it possible to identify them unambiguously and negotiate fo r their use. See <xref target="RFC6838" format="default"/> for more information. </t>
</section> </section>
<section anchor="caching" numbered="true" toc="default"> <section anchor="caching" numbered="true" toc="default">
<name>Leveraging HTTP Caching</name> <name>Leveraging HTTP Caching</name>
<t>HTTP caching <xref target="HTTP-CACHING" format="default"/> is one of <t>HTTP caching <xref target="HTTP-CACHING" format="default"/> is one of
the primary benefits of using HTTP for applications; it provides scalability, r the primary benefits of using HTTP for applications; it provides scalability, r
educes latency and improves reliability. Furthermore, HTTP caches are readily av educes latency, and improves reliability. Furthermore, HTTP caches are readily a
ailable in browsers and other clients, networks as forward and reverse proxies, vailable in browsers and other clients, networks as forward and reverse proxies,
Content Delivery Networks and as part of server software.</t> content delivery networks, and as part of server software.</t>
<t>Even when an application using HTTP isn't designed to take advantage <t>Even when an application using HTTP isn't designed to take advantage
of caching, it needs to consider how caches will handle its responses, to preser of caching, it needs to consider how caches will handle its responses to preserv
ve correct behaviour when one is interposed (whether in the network, server, cli e correct behaviour when one is interposed (whether in the network, server, clie
ent, or intervening infrastructure).</t> nt, or intervening infrastructure).</t>
<section anchor="freshness" numbered="true" toc="default"> <section anchor="freshness" numbered="true" toc="default">
<name>Freshness</name> <name>Freshness</name>
<t>Assigning even a short freshness lifetime (<xref section="4.2" sect <t>Assigning even a short freshness lifetime (<xref section="4.2" sect
ionFormat="comma" target="HTTP-CACHING" format="default"/>) -- e.g., 5 seconds - ionFormat="comma" target="HTTP-CACHING" format="default"/>) -- e.g., 5 seconds -
- allows a response to be reused to satisfy multiple clients, and/or a single cl - allows a response to be reused to satisfy multiple clients and/or a single cli
ient making the same request repeatedly. In general, if it is safe to reuse some ent making the same request repeatedly. In general, if it is safe to reuse somet
thing, consider assigning a freshness lifetime.</t> hing, consider assigning a freshness lifetime.</t>
<t>The most common method for specifying freshness is the max-age resp <t>The most common method for specifying freshness is the max-age resp
onse directive (<xref section="5.2.2.1" sectionFormat="comma" target="HTTP-CACHI onse directive (<xref section="5.2.2.1" sectionFormat="comma" target="HTTP-CACHI
NG" format="default"/>). The Expires header field (<xref section="5.3" sectionFo NG" format="default"/>). The Expires header field (<xref section="5.3" sectionFo
rmat="comma" target="HTTP-CACHING" format="default"/>) can also be used, but it rmat="comma" target="HTTP-CACHING" format="default"/>) can also be used, but it
is not necessary; all modern cache implementations support Cache-Control, and sp is not necessary; all modern cache implementations support the Cache-Control hea
ecifying freshness as a delta is usually more convenient and less error-prone.</ der field, and specifying freshness as a delta is usually more convenient and le
t> ss error-prone.</t>
<t>It is not necessary to add the "public" response directive (<xref s <t>It is not necessary to add the public response directive (<xref sec
ection="5.2.2.9" sectionFormat="comma" target="HTTP-CACHING" format="default"/>) tion="5.2.2.9" sectionFormat="comma" target="HTTP-CACHING" format="default"/>) t
to cache most responses; it is only necessary when it's desirable to store an a o cache most responses; it is only necessary when it's desirable to store an aut
uthenticated response, or when the status code isn't understood by the cache and henticated response, or when the status code isn't understood by the cache and t
there isn't explicit freshness information available.</t> here isn't explicit freshness information available.</t>
<t>In some situations, responses without explicit cache freshness dire <t>In some situations, responses without explicit cache freshness dire
ctives will be stored and served using a heuristic freshness lifetime; see <xref ctives will be stored and served using a heuristic freshness lifetime; see <xref
section="4.2.2" sectionFormat="comma" target="HTTP-CACHING" format="default"/>. section="4.2.2" sectionFormat="comma" target="HTTP-CACHING" format="default"/>.
As the heuristic is not under control of the application, it is generally prefe As the heuristic is not under the control of the application, it is generally p
rable to set an explicit freshness lifetime, or make the response explicitly unc referable to set an explicit freshness lifetime or make the response explicitly
acheable.</t> uncacheable.</t>
<t>If caching of a response is not desired, the appropriate response d <t>If caching of a response is not desired, the appropriate cache resp
irective is "Cache-Control: no-store". Other directives are not necessary, and n onse directive is no-store. Other directives are not necessary, and no-store onl
o-store only need be sent in situations where the response might be cached; see y needs to be sent in situations where the response might be cached; see <xref s
<xref section="3" sectionFormat="comma" target="HTTP-CACHING" format="default"/> ection="3" sectionFormat="comma" target="HTTP-CACHING" format="default"/>. Note
. Note that "Cache-Control: no-cache" allows a response to be stored, just not r that the no-cache directive allows a response to be stored, just not reused by a
eused by a cache without validation; it does not prevent caching (despite its na cache without validation; it does not prevent caching (despite its name).</t>
me).</t>
<t>For example, this response cannot be stored or reused by a cache:</ t> <t>For example, this response cannot be stored or reused by a cache:</ t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: application/example+xml Content-Type: application/example+xml
Cache-Control: no-store Cache-Control: no-store
[content] [content]
]]></sourcecode> ]]></sourcecode>
</section> </section>
<section anchor="stale-responses" numbered="true" toc="default"> <section anchor="stale-responses" numbered="true" toc="default">
<name>Stale Responses</name> <name>Stale Responses</name>
<t>Authors should understand that stale responses (e.g., with "Cache-C <t>Authors should understand that stale responses (e.g., with Cache-Co
ontrol: max-age=0") can be reused by caches when disconnected from the origin se ntrol: max-age=0) can be reused by caches when disconnected from the origin serv
rver; this can be useful for handling network issues.</t> er; this can be useful for handling network issues.</t>
<t>If doing so is not suitable for a given response, the origin should <t>If doing so is not suitable for a given response, the origin should
use "Cache-Control: must-revalidate". See <xref section="4.2.4" sectionFormat=" send the must-revalidate cache directive. See <xref section="4.2.4" sectionForm
of" target="HTTP-CACHING" format="default"/>, and also <xref target="RFC5861" fo at="of" target="HTTP-CACHING" format="default"/> and also <xref target="RFC5861"
rmat="default"/> for additional controls over stale content.</t> format="default"/> for additional controls over stale content.</t>
<t>Stale responses can be refreshed by assigning a validator, saving b oth transfer bandwidth and latency for large responses; see <xref section="13" s ectionFormat="of" target="HTTP" format="default"/>.</t> <t>Stale responses can be refreshed by assigning a validator, saving b oth transfer bandwidth and latency for large responses; see <xref section="13" s ectionFormat="of" target="HTTP" format="default"/>.</t>
</section> </section>
<section anchor="caching-app-semantics" numbered="true" toc="default"> <section anchor="caching-app-semantics" numbered="true" toc="default">
<name>Caching and Application Semantics</name> <name>Caching and Application Semantics</name>
<t>When an application has a need to express a lifetime that's separat e from the freshness lifetime, this should be conveyed separately, either in the response's content or in a separate header field. When this happens, the relati onship between HTTP caching and that lifetime needs to be carefully considered, since the response will be used as long as it is considered fresh.</t> <t>When an application has a need to express a lifetime that's separat e from the freshness lifetime, this should be conveyed separately, either in the response's content or in a separate header field. When this happens, the relati onship between HTTP caching and that lifetime needs to be carefully considered s ince the response will be used as long as it is considered fresh.</t>
<t>In particular, application authors need to consider how responses t hat are not freshly obtained from the origin server should be handled; if they h ave a concept like a validity period, this will need to be calculated considerin g the age of the response (see <xref section="4.2.3" sectionFormat="comma" targe t="HTTP-CACHING" format="default"/>).</t> <t>In particular, application authors need to consider how responses t hat are not freshly obtained from the origin server should be handled; if they h ave a concept like a validity period, this will need to be calculated considerin g the age of the response (see <xref section="4.2.3" sectionFormat="comma" targe t="HTTP-CACHING" format="default"/>).</t>
<t>One way to address this is to explicitly specify that responses nee d to be fresh upon use.</t> <t>One way to address this is to explicitly specify that responses nee d to be fresh upon use.</t>
</section> </section>
<section anchor="varying-content-based-upon-the-request" numbered="true" toc="default"> <section anchor="varying-content-based-upon-the-request" numbered="true" toc="default">
<name>Varying Content Based Upon the Request</name> <name>Varying Content Based Upon the Request</name>
<t>If an application uses a request header field to change the respons e's header fields or content, authors should point out that this has implication s for caching; in general, such resources need to either make their responses un cacheable (e.g., with the "no-store" cache-control directive defined in <xref se ction="5.2.2.5" sectionFormat="comma" target="HTTP-CACHING" format="default"/>) or send the Vary response header field (<xref section="12.5.5" sectionFormat="co mma" target="HTTP" format="default"/>) on all responses from that resource (incl uding the "default" response).</t> <t>If an application uses a request header field to change the respons e's header fields or content, authors should point out that this has implication s for caching; in general, such resources need to either make their responses un cacheable (e.g., with the no-store cache directive defined in <xref section="5.2 .2.5" sectionFormat="comma" target="HTTP-CACHING" format="default"/>) or send th e Vary response header field (<xref section="12.5.5" sectionFormat="comma" targe t="HTTP" format="default"/>) on all responses from that resource (including the "default" response).</t>
<t>For example, this response:</t> <t>For example, this response:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
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]
]]></sourcecode> ]]></sourcecode>
<t>can be stored for 60 seconds by both private and shared caches, can be revalidated with If-None-Match, and varies on the Accept-Encoding request he ader field.</t> <t>can be stored for 60 seconds by both private and shared caches, can be revalidated with If-None-Match, and varies on the Accept-Encoding request he ader field.</t>
</section> </section>
</section> </section>
<section anchor="state" numbered="true" toc="default"> <section anchor="state" numbered="true" toc="default">
<name>Handling Application State</name> <name>Handling Application State</name>
<t>Applications can use stateful cookies <xref target="COOKIES" format=" default"/> to identify a client and/or store client-specific data to contextuali se requests.</t> <t>Applications can use stateful cookies <xref target="COOKIES" format=" default"/> to identify a client and/or store client-specific data to contextuali se requests.</t>
<t>When used, it is important to carefully specify the scoping and use o f cookies; if the application exposes sensitive data or capabilities (e.g., by a cting as an ambient authority), exploits are possible. Mitigations include using a request-specific token to assure the intent of the client.</t> <t>When used, it is important to carefully specify the scoping and use o f cookies; if the application exposes sensitive data or capabilities (e.g., by a cting as an ambient authority), exploits are possible. Mitigations include using a request-specific token to ensure the intent of the client.</t>
</section> </section>
<section anchor="multiplex" numbered="true" toc="default"> <section anchor="multiplex" numbered="true" toc="default">
<name>Making Multiple Requests</name> <name>Making Multiple Requests</name>
<t>Clients often need to send multiple requests to perform a task.</t> <t>Clients often need to send multiple requests to perform a task.</t>
<t>In HTTP/1 <xref target="HTTP11" format="default"/>, parallel requests <t>In HTTP/1 <xref target="HTTP11" format="default"/>, parallel requests
are most often supported by opening multiple connections. Application performan are most often supported by opening multiple connections. Application performan
ce can be impacted when too many simultaneous connections are used, because conn ce can be impacted when too many simultaneous connections are used because conne
ections' congestion control will not be coordinated. Furthermore, it can be diff ctions' congestion control will not be coordinated. Furthermore, it can be diffi
icult for applications to decide when to issue and which connection to use for a cult for applications to decide when to issue and which connection to use for a
given request, further impacting performance.</t> given request, further impacting performance.</t>
<t>HTTP/2 <xref target="HTTP2" format="default"/> and HTTP/3 <xref targe <t>HTTP/2 <xref target="HTTP2" format="default"/> and HTTP/3 <xref targe
t="HTTP3" format="default"/> offer multiplexing to applications, removing the ne t="HTTP3" format="default"/> offer multiplexing to applications, removing the ne
ed to use multiple connections. However, application performance can still be si ed to use multiple connections. However, application performance can still be si
gnificantly affected by how the server chooses to prioritize responses. Dependin gnificantly affected by how the server chooses to prioritize responses. Dependin
g on the application, it might be best for the server to determine the priority g on the application, it might be best for the server to determine the priority
of responses, or for the client to hint its priorities to the server (see, e.g., of responses or for the client to hint its priorities to the server (see, e.g.,
<xref target="HTTP-PRIORITY" format="default"/>).</t> <xref target="HTTP-PRIORITY" format="default"/>).</t>
<t>In all versions of HTTP, requests are made independently -- you can't <t>In all versions of HTTP, requests are made independently -- you can't
rely on the relative order of two requests to guarantee processing order. This rely on the relative order of two requests to guarantee their processing order.
is because they might be sent over a multiplexed protocol by an intermediary, se This is because they might be sent over a multiplexed protocol by an intermedia
nt to different origin servers, or the server might even perform processing in a ry or sent to different origin servers, or the server might even perform process
different order. If two requests need strict ordering, the only reliable way to ing in a different order. If two requests need strict ordering, the only reliabl
assure the outcome is to issue the second request when the final response to th e way to ensure the outcome is to issue the second request when the final respon
e first has begun.</t> se to the first has begun.</t>
<t>Applications MUST NOT make assumptions about the relationship between <t>Applications <bcp14>MUST NOT</bcp14> make assumptions about the relat
separate requests on a single transport connection; doing so breaks many of the ionship between separate requests on a single transport connection; doing so bre
assumptions of HTTP as a stateless protocol, and will cause problems in interop aks many of the assumptions of HTTP as a stateless protocol and will cause probl
erability, security, operability and evolution.</t> ems in interoperability, security, operability, and evolution.</t>
</section> </section>
<section anchor="client-auth" numbered="true" toc="default"> <section anchor="client-auth" numbered="true" toc="default">
<name>Client Authentication</name> <name>Client Authentication</name>
<t>Applications can use HTTP authentication <xref section="11" sectionFo <t>Applications can use HTTP authentication (<xref section="11" sectionF
rmat="of" target="HTTP" format="default"/> to identify clients. As per <xref tar ormat="of" target="HTTP" format="default"/>) to identify clients. Per <xref targ
get="RFC7617" format="default"/>, the Basic authentication scheme is not suitabl et="RFC7617" format="default"/>, the Basic authentication scheme is not suitable
e for protecting sensitive or valuable information unless the channel is secure for protecting sensitive or valuable information unless the channel is secure (
(e.g., using the "HTTPS" URI scheme). Likewise, <xref target="RFC7616" format="d e.g., using the "https" URI scheme). Likewise, <xref target="RFC7616" format="de
efault"/> requires the Digest authentication scheme to be used over a secure cha fault"/> requires the Digest authentication scheme to be used over a secure chan
nnel.</t> nel.</t>
<t>With HTTPS, clients might also be authenticated using certificates <x <t>With HTTPS, clients might also be authenticated using certificates <x
ref target="RFC8446" format="default"/>, but note that such authentication is in ref target="RFC8446" format="default"/>, but note that such authentication is in
trinsically scoped to the underlying transport connection. As a result, a client trinsically scoped to the underlying transport connection. As a result, a client
has no way of knowing whether the authenticated status was used in preparing th has no way of knowing whether the authenticated status was used in preparing th
e response (though "Vary: *" and/or "Cache-Control: private" can provide a parti e response (though Vary: * and/or the private cache directive can provide a part
al indication), and the only way to obtain a specifically unauthenticated respon ial indication), and the only way to obtain a specifically unauthenticated respo
se is to open a new connection.</t> nse is to open a new connection.</t>
<t>When used, it is important to carefully specify the scoping and use o <t>When used, it is important to carefully specify the scoping and use o
f authentication; if the application exposes sensitive data or capabilities (e.g f authentication; if the application exposes sensitive data or capabilities (e.g
., by acting as an ambient authority; see <xref section="8.3" sectionFormat="of" ., by acting as an ambient authority; see <xref section="8.3" sectionFormat="of"
target="RFC6454" format="default"/>), exploits are possible. Mitigations includ target="RFC6454" format="default"/>), exploits are possible. Mitigations includ
e using a request-specific token to assure the intent of the client.</t> e using a request-specific token to ensure the intent of the client.</t>
</section> </section>
<section anchor="browser" numbered="true" toc="default"> <section anchor="browser" numbered="true" toc="default">
<name>Co-Existing with Web Browsing</name> <name>Coexisting with Web Browsing</name>
<t>Even if there is not an intent for an application to be used with a W eb browser, its resources will remain available to browsers and other HTTP clien ts. This means that all such applications that use HTTP need to consider how bro wsers will interact with them, particularly regarding security.</t> <t>Even if there is not an intent for an application to be used with a W eb browser, its resources will remain available to browsers and other HTTP clien ts. This means that all such applications that use HTTP need to consider how bro wsers will interact with them, particularly regarding security.</t>
<t>For example, if an application's state can be changed using a POST re quest, a Web browser can easily be coaxed into cross-site request forgery (CSRF) from arbitrary Web sites.</t> <t>For example, if an application's state can be changed using a POST re quest, a Web browser can easily be coaxed into cross-site request forgery (CSRF) from arbitrary Web sites.</t>
<t>Or, if an attacker gains control of content returned from the applica tion's resources (for example, part of the request is reflected in the response, or the response contains external information that the attacker can change), th ey can inject code into the browser and access data and capabilities as if they were the origin -- a technique known as a cross-site scripting (XSS) attack.</t> <t>Or, if an attacker gains control of content returned from the applica tion's resources (for example, part of the request is reflected in the response, or the response contains external information that the attacker can change), th ey can inject code into the browser and access data and capabilities as if they were the origin -- a technique known as a cross-site scripting (XSS) attack.</t>
<t>This is only a small sample of the kinds of issues that applications using HTTP must consider. Generally, the best approach is to actually consider t he application as a Web application, and to follow best practices for their secu re development.</t> <t>This is only a small sample of the kinds of issues that applications using HTTP must consider. Generally, the best approach is to actually consider t he application as a Web application, and to follow best practices for their secu re development.</t>
<t>A complete enumeration of such practices is out of scope for this doc ument, but some considerations include:</t> <t>A complete enumeration of such practices is out of scope for this doc ument, but some considerations include:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Using an application-specific media type in the Content-Type heade r field, and requiring clients to fail if it is not used.</li> <li>Using an application-specific media type in the Content-Type heade r field, and requiring clients to fail if it is not used.</li>
<li>Using X-Content-Type-Options: nosniff <xref target="FETCH" format= <li>Using X-Content-Type-Options: nosniff <xref target="FETCH" format=
"default"/> to assure that content under attacker control can't be coaxed into a "default"/> to ensure that content under attacker control can't be coaxed into a
form that is interpreted as active content by a Web browser.</li> form that is interpreted as active content by a Web browser.</li>
<li>Using Content-Security-Policy <xref target="CSP" format="default"/ <li>Using Content-Security-Policy <xref target="CSP" format="default"/
> to constrain the capabilities of active content (i.e., that which can execute > to constrain the capabilities of active content (i.e., that which can execute
scripts, such as HTML <xref target="HTML" format="default"/> and PDF), thereby m scripts, such as HTML <xref target="HTML" format="default"/> and PDF), thereby m
itigating Cross-Site Scripting attacks.</li> itigating XSS attacks.</li>
<li>Using Referrer-Policy <xref target="REFERRER-POLICY" format="defau lt"/> to prevent sensitive data in URLs from being leaked in the Referer request header field.</li> <li>Using Referrer-Policy <xref target="REFERRER-POLICY" format="defau lt"/> to prevent sensitive data in URLs from being leaked in the Referer request header field.</li>
<li>Using the 'HttpOnly' flag on Cookies to assure that cookies are no <li>Using the 'HttpOnly' flag on Cookies to ensure that cookies are no
t exposed to browser scripting languages <xref target="COOKIES" format="default" t exposed to browser scripting languages <xref target="COOKIES" format="default"
/>.</li> />.</li>
<li>Avoiding use of compression on any sensitive information (e.g., au <li>Avoiding use of compression on any sensitive information (e.g., au
thentication tokens, passwords), as the scripting environment offered by Web bro thentication tokens, passwords), as the scripting environment offered by Web bro
wsers allows an attacker to repeatedly probe the compression space; if the attac wsers allows an attacker to repeatedly probe the compression space; if the attac
ker has access to the path of the communication, they can use this capability to ker has access to the network path of the communication, they can use this capab
recover that information.</li> ility to recover that information.</li>
</ul> </ul>
<t>Depending on how they are intended to be deployed, specifications for <t>Depending on how they are intended to be deployed, specifications for
applications using HTTP might require the use of these mechanisms in specific w applications using HTTP might require the use of these mechanisms in specific w
ays, or might merely point them out in Security Considerations.</t> ays or might merely point them out in Security Considerations.</t>
<t>An example of a HTTP response from an application that does not inten <t>An example of an HTTP response from an application that does not inte
d for its content to be treated as active by browsers might look like this:</t> nd for its content to be treated as active by browsers might look like this:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: application/example+json Content-Type: application/example+json
X-Content-Type-Options: nosniff X-Content-Type-Options: nosniff
Content-Security-Policy: default-src 'none' Content-Security-Policy: default-src 'none'
Cache-Control: max-age=3600 Cache-Control: max-age=3600
Referrer-Policy: no-referrer Referrer-Policy: no-referrer
[content] [content]
]]></sourcecode> ]]></sourcecode>
<t>If an application has browser compatibility as a goal, client interac tion ought to be defined in terms of <xref target="FETCH" format="default"/>, si nce that is the abstraction that browsers use for HTTP; it enforces many of thes e best practices.</t> <t>If an application has browser compatibility as a goal, client interac tion ought to be defined in terms of <xref target="FETCH" format="default"/> sin ce that is the abstraction that browsers use for HTTP; it enforces many of these best practices.</t>
</section> </section>
<section anchor="other-apps" numbered="true" toc="default"> <section anchor="other-apps" numbered="true" toc="default">
<name>Maintaining Application Boundaries</name> <name>Maintaining Application Boundaries</name>
<t>Because many HTTP capabilities are scoped to the origin <xref target= <t>Because many HTTP capabilities are scoped to the origin <xref target=
"RFC6454" format="default"/>, applications also need to consider how deployments "RFC6454" format="default"/>, applications also need to consider how deployments
might interact with other applications (including Web browsing) on the same ori might interact with other applications (including Web browsing) that use the sa
gin.</t> me origin server.</t>
<t>For example, if Cookies <xref target="COOKIES" format="default"/> are <t>For example, if cookies <xref target="COOKIES" format="default"/> are
used to carry application state, they will be sent with all requests to the ori used to carry application state, they will be sent with all requests to the ori
gin by default (unless scoped by path), and the application might receive cookie gin by default (unless scoped by path), and the application might receive cookie
s from other applications on the origin. This can lead to security issues, as we s from other applications on the origin server. This can lead to security issues
ll as collision in cookie names.</t> as well as collision in cookie names.</t>
<t>One solution to these issues is to require a dedicated hostname for t <t>One solution to these issues is to require a dedicated hostname for t
he application, so that it has a unique origin. However, it is often desirable t he application so that it has a unique origin. However, it is often desirable to
o allow multiple applications to be deployed on a single hostname; doing so prov allow multiple applications to be deployed on a single hostname; doing so provi
ides the most deployment flexibility and enables them to be "mixed" together (Se des the most deployment flexibility and enables them to be "mixed" together (see
e <xref target="RFC8820" format="default"/> for details). Therefore, application <xref target="BCP190" format="default"/> for details).</t>
s using HTTP should strive to allow multiple applications on an origin.</t> <t>Therefore, applications using HTTP should strive to allow multiple ap
<t>To enable this, when specifying the use of Cookies, HTTP authenticati plications on an origin. Specifically, when specifying the use of cookies, HTTP
on realms <xref target="HTTP" format="default"/>, or other origin-wide HTTP mech authentication realms <xref target="HTTP" format="default"/>, or other origin-wi
anisms, applications using HTTP should not mandate the use of a particular name, de HTTP mechanisms, applications using HTTP should not mandate the use of a part
but instead let deployments configure them. Consideration should be given to sc icular name but instead let deployments configure them. Consideration should be
oping them to part of the origin, using their specified mechanisms for doing so. given to scoping them to part of the origin, using their specified mechanisms fo
</t> r doing so.</t>
<t>Modern Web browsers constrain the ability of content from one origin <t>Modern Web browsers constrain the ability of content from one origin
to access resources from another, to avoid leaking private information. As a res to access resources from another to avoid leaking private information. As a resu
ult, applications that wish to expose cross-origin data to browsers will need to lt, applications that wish to expose cross-origin data to browsers will need to
implement the CORS protocol; see <xref target="FETCH" format="default"/>.</t> implement the CORS protocol; see <xref target="FETCH" format="default"/>.</t>
</section> </section>
<section anchor="server-push" numbered="true" toc="default"> <section anchor="server-push" numbered="true" toc="default">
<name>Using Server Push</name> <name>Using Server Push</name>
<t>HTTP/2 added the ability for servers to "push" request/response pairs to clients in <xref section="8.4" sectionFormat="comma" target="HTTP2" format=" default"/>. While server push seems like a natural fit for many common applicati on semantics (e.g., "fanout" and publish/subscribe), a few caveats should be not ed:</t> <t>HTTP/2 added the ability for servers to "push" request/response pairs to clients in <xref section="8.4" sectionFormat="comma" target="HTTP2" format=" default"/>. While server push seems like a natural fit for many common applicati on semantics (e.g., "fanout" and publish/subscribe), a few caveats should be not ed:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Server push is hop-by-hop; that is, it is not automatically forwar <li>Server push is hop by hop; that is, it is not automatically forwar
ded by intermediaries. As a result, it might not work easily (or at all) with pr ded by intermediaries. As a result, it might not work easily (or at all) with pr
oxies, reverse proxies, and Content Delivery Networks.</li> oxies, reverse proxies, and content delivery networks.</li>
<li>Server push can have negative performance impact on HTTP when used <li>Server push can have a negative performance impact on HTTP when us
incorrectly; in particular, if there is contention with resources that have act ed incorrectly, particularly if there is contention with resources that have act
ually been requested by the client.</li> ually been requested by the client.</li>
<li>Server push is implemented differently in different clients, espec ially regarding interaction with HTTP caching, and capabilities might vary.</li> <li>Server push is implemented differently in different clients, espec ially regarding interaction with HTTP caching, and capabilities might vary.</li>
<li>APIs for server push are currently unavailable in some implementat ions, and vary widely in others. In particular, there is no current browser API for it.</li> <li>APIs for server push are currently unavailable in some implementat ions and vary widely in others. In particular, there is no current browser API f or it.</li>
<li>Server push is not supported in HTTP/1.1 or HTTP/1.0.</li> <li>Server push is not supported in HTTP/1.1 or HTTP/1.0.</li>
<li>Server push does not form part of the "core" semantics of HTTP, an d therefore might not be supported by future versions of the protocol.</li> <li>Server push does not form part of the "core" semantics of HTTP and therefore might not be supported by future versions of the protocol.</li>
</ul> </ul>
<t>Applications wishing to optimise cases where the client can perform w ork related to requests before the full response is available (e.g., fetching li nks for things likely to be contained within) might benefit from using the 103 ( Early Hints) status code; see <xref target="RFC8297" format="default"/>.</t> <t>Applications wishing to optimise cases where the client can perform w ork related to requests before the full response is available (e.g., fetching li nks for things likely to be contained within) might benefit from using the 103 ( Early Hints) status code; see <xref target="RFC8297" format="default"/>.</t>
<t>Applications using server push directly need to enforce the requireme nts regarding authority in <xref section="8.4" sectionFormat="comma" target="HTT P2" format="default"/>, to avoid cross-origin push attacks.</t> <t>Applications using server push directly need to enforce the requireme nts regarding authority in <xref section="8.4" sectionFormat="comma" target="HTT P2" format="default"/> to avoid cross-origin push attacks.</t>
</section> </section>
<section anchor="versioning" numbered="true" toc="default"> <section anchor="versioning" numbered="true" toc="default">
<name>Allowing Versioning and Evolution</name> <name>Allowing Versioning and Evolution</name>
<t>It's often necessary to introduce new features into application proto cols, and change existing ones.</t> <t>It's often necessary to introduce new features into application proto cols and change existing ones.</t>
<t>In HTTP, backwards-incompatible changes can be made using mechanisms such as:</t> <t>In HTTP, backwards-incompatible changes can be made using mechanisms such as:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Using a distinct link relation type <xref target="WEB-LINKING" for mat="default"/> to identify a URL for a resource that implements the new functio nality.</li> <li>Using a distinct link relation type <xref target="WEB-LINKING" for mat="default"/> to identify a URL for a resource that implements the new functio nality.</li>
<li>Using a distinct media type <xref target="RFC6838" format="default "/> to identify formats that enable the new functionality.</li> <li>Using a distinct media type <xref target="RFC6838" format="default "/> to identify formats that enable the new functionality.</li>
<li>Using a distinct HTTP header field to implement new functionality outside the message content.</li> <li>Using a distinct HTTP header field to implement new functionality outside the message content.</li>
</ul> </ul>
</section> </section>
</section> </section>
<section anchor="iana-considerations" numbered="true" toc="default"> <section anchor="iana-considerations" numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This document has no requirements for IANA.</t> <t>This document has no IANA actions.</t>
</section> </section>
<section anchor="security-considerations" numbered="true" toc="default"> <section anchor="security-considerations" numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>Applications using HTTP are subject to the security considerations of H TTP itself and any extensions used; <xref target="HTTP" format="default"/>, <xre f target="HTTP-CACHING" format="default"/>, and <xref target="WEB-LINKING" forma t="default"/> are often relevant, amongst others.</t> <t>Applications using HTTP are subject to the security considerations of H TTP itself and any extensions used; <xref target="HTTP" format="default"/>, <xre f target="HTTP-CACHING" format="default"/>, and <xref target="WEB-LINKING" forma t="default"/> are often relevant, amongst others.</t>
<t><xref target="scheme" format="default"/> recommends support for 'https' URLs, and discourages the use of 'http' URLs, to provide authentication, integr ity and confidentiality, as well as mitigate pervasive monitoring attacks. Many applications using HTTP perform authentication and authorization with bearer tok ens (e.g., in session cookies). If the transport is unencrypted, an attacker tha t can eavesdrop upon or modify HTTP communications can often escalate their priv ilege to perform operations on resources.</t> <t><xref target="scheme" format="default"/> recommends support for "https" URLs and discourages the use of "http" URLs to provide authentication, integrit y, and confidentiality, as well as to mitigate pervasive monitoring attacks. Man y applications using HTTP perform authentication and authorization with bearer t okens (e.g., in session cookies). If the transport is unencrypted, an attacker t hat can eavesdrop upon or modify HTTP communications can often escalate their pr ivilege to perform operations on resources.</t>
<t><xref target="caching-app-semantics" format="default"/> highlights the potential for mismatch between HTTP caching and application-specific storage of responses or information therein.</t> <t><xref target="caching-app-semantics" format="default"/> highlights the potential for mismatch between HTTP caching and application-specific storage of responses or information therein.</t>
<t><xref target="state" format="default"/> discusses the impact of using s tateful mechanisms in the protocol as ambient authority, and suggests a mitigati on.</t> <t><xref target="state" format="default"/> discusses the impact of using s tateful mechanisms in the protocol as ambient authority and suggests a mitigatio n.</t>
<t><xref target="browser" format="default"/> highlights the implications o f Web browsers' capabilities on applications that use HTTP.</t> <t><xref target="browser" format="default"/> highlights the implications o f Web browsers' capabilities on applications that use HTTP.</t>
<t><xref target="other-apps" format="default"/> discusses the issues that <t><xref target="other-apps" format="default"/> discusses the issues that
arise when applications are deployed on the same origin as Web sites (and other arise when applications are deployed on the same origin as websites (and other a
applications).</t> pplications).</t>
<t><xref target="server-push" format="default"/> highlights risks of using <t><xref target="server-push" format="default"/> highlights risks of using
HTTP/2 server push in a manner other than specified.</t> HTTP/2 server push in a manner other than that specified.</t>
<t>Applications that use HTTP in a manner that involves modification of im <t>Applications that use HTTP in a manner that involves modification of im
plementations -- for example, requiring support for a new URI scheme, or a non-s plementations -- for example, requiring support for a new URI scheme or a non-st
tandard method -- risk having those implementations "fork" from their parent HTT andard method -- risk having those implementations "fork" from their parent HTTP
P implementations, with the possible result that they do not benefit from patche implementations, with the possible result that they do not benefit from patches
s and other security improvements incorporated upstream.</t> and other security improvements incorporated upstream.</t>
<section anchor="privacy-considerations" numbered="true" toc="default"> <section anchor="privacy-considerations" numbered="true" toc="default">
<name>Privacy Considerations</name> <name>Privacy Considerations</name>
<t>HTTP clients can expose a variety of information to servers. Besides information that's explicitly sent as part of an application's operation (for ex ample, names and other user-entered data), and "on the wire" (which is one of th e reasons https is recommended in <xref target="scheme" format="default"/>), oth er information can be gathered through less obvious means -- often by connecting activities of a user over time.</t> <t>HTTP clients can expose a variety of information to servers. Besides information that's explicitly sent as part of an application's operation (for ex ample, names and other user-entered data) and "on the wire" (which is one of the reasons "https" is recommended in <xref target="scheme" format="default"/>), ot her information can be gathered through less obvious means -- often by connectin g activities of a user over time.</t>
<t>This includes session information, tracking the client through finger printing, and code execution.</t> <t>This includes session information, tracking the client through finger printing, and code execution.</t>
<t>Session information includes things like the IP address of the client , TLS session tickets, Cookies, ETags stored in the client's cache, and other st ateful mechanisms. Applications are advised to avoid using session mechanisms un less they are unavoidable or necessary for operation, in which case these risks needs to be documented. When they are used, implementations should be encouraged to allow clearing such state.</t> <t>Session information includes things like the IP address of the client , TLS session tickets, Cookies, ETags stored in the client's cache, and other st ateful mechanisms. Applications are advised to avoid using session mechanisms un less they are unavoidable or necessary for operation, in which case these risks need to be documented. When they are used, implementations should be encouraged to allow clearing such state.</t>
<t>Fingerprinting uses unique aspects of a client's messages and behavio urs to connect disparate requests and connections. For example, the User-Agent r equest header field conveys specific information about the implementation; the A ccept-Language request header field conveys the users' preferred language. In co mbination, a number of these markers can be used to uniquely identify a client, impacting its control over its data. As a result, applications are advised to sp ecify that clients should only emit the information they need to function in req uests.</t> <t>Fingerprinting uses unique aspects of a client's messages and behavio urs to connect disparate requests and connections. For example, the User-Agent r equest header field conveys specific information about the implementation; the A ccept-Language request header field conveys the users' preferred language. In co mbination, a number of these markers can be used to uniquely identify a client, impacting its control over its data. As a result, applications are advised to sp ecify that clients should only emit the information they need to function in req uests.</t>
<t>Finally, if an application exposes the ability to execute code, great care needs to be taken, since any ability to observe its environment can be use d as an opportunity to both fingerprint the client and to obtain and manipulate private data (including session information). For example, access to high-resolu tion timers (even indirectly) can be used to profile the underlying hardware, cr eating a unique identifier for the system. Applications are advised to avoid all owing the use of mobile code where possible; when it cannot be avoided, the resu lting system's security properties need be carefully scrutinised.</t> <t>Finally, if an application exposes the ability to execute code, great care needs to be taken since any ability to observe its environment can be used as an opportunity to both fingerprint the client and to obtain and manipulate p rivate data (including session information). For example, access to high-resolut ion timers (even indirectly) can be used to profile the underlying hardware, cre ating a unique identifier for the system. Applications are advised to avoid allo wing the use of mobile code where possible; when it cannot be avoided, the resul ting system's security properties need be carefully scrutinised.</t>
</section> </section>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="HTTP11" to="HTTP/1.1"/>
<displayreference target="HTTP2" to="HTTP/2"/>
<displayreference target="HTTP3" to="HTTP/3"/>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="HTTP"> <reference anchor="HTTP" target="https://www.rfc-editor.org/info/rfc9110 ">
<front> <front>
<title>HTTP Semantics</title> <title>HTTP Semantics</title>
<author fullname="Roy T. Fielding"> <author initials="R" surname="Fielding" fullname="Roy Fielding" role
<organization>Adobe</organization> ="editor">
</author> <organization />
<author fullname="Mark Nottingham">
<organization>Fastly</organization>
</author>
<author fullname="Julian Reschke">
<organization>greenbytes GmbH</organization>
</author> </author>
<date day="18" month="August" year="2021"/> <author initials="M" surname="Nottingham" fullname="Mark Nottingham"
<abstract> role="editor">
<t> The Hypertext Transfer Protocol (HTTP) is a stateless applic <organization />
ation- </author>
level protocol for distributed, collaborative, hypertext information <author initials="J" surname="Reschke" fullname="Julian Reschke" role
systems. This document describes the overall architecture of HTTP, ="editor">
establishes common terminology, and defines aspects of the protocol <organization />
that are shared by all versions. In this definition are core </author>
protocol elements, extensibility mechanisms, and the "http" and <date year="2022" month="June" />
"https" Uniform Resource Identifier (URI) schemes.
This document updates RFC 3864 and obsoletes RFC 2818, RFC 7231, RFC
7232, RFC 7233, RFC 7235, RFC 7538, RFC 7615, RFC 7694, and portions
of RFC 7230.
</t>
</abstract>
</front> </front>
<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-semantics- <seriesInfo name="STD" value="97"/>
18"/> <seriesInfo name="RFC" value="9110"/>
<seriesInfo name="DOI" value="10.17487/RFC9110"/>
</reference> </reference>
<reference anchor="HTTP-CACHING"> <reference anchor="HTTP-CACHING" target="https://www.rfc-editor.org/info /rfc9111">
<front> <front>
<title>HTTP Caching</title> <title>HTTP Caching</title>
<author fullname="Roy T. Fielding"> <author initials="R" surname="Fielding" fullname="Roy Fielding" role
<organization>Adobe</organization> ="editor">
</author> <organization />
<author fullname="Mark Nottingham">
<organization>Fastly</organization>
</author>
<author fullname="Julian Reschke">
<organization>greenbytes GmbH</organization>
</author> </author>
<date day="18" month="August" year="2021"/> <author initials="M" surname="Nottingham" fullname="Mark Nottingham"
<abstract> role="editor">
<t> The Hypertext Transfer Protocol (HTTP) is a stateless applic <organization />
ation- </author>
level protocol for distributed, collaborative, hypertext information <author initials="J" surname="Reschke" fullname="Julian Reschke" role
systems. This document defines HTTP caches and the associated header ="editor">
fields that control cache behavior or indicate cacheable response <organization />
messages. </author>
<date year="2022" month="June"/>
This document obsoletes RFC 7234.
</t>
</abstract>
</front> </front>
<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-cache-18"/ <seriesInfo name="STD" value="98"/>
> <seriesInfo name="RFC" value="9111"/>
<seriesInfo name="DOI" value="10.17487/RFC9111"/>
</reference> </reference>
<reference anchor="WEB-LINKING"> <reference anchor="WEB-LINKING" target="https://www.rfc-editor.org/info/ rfc8288">
<front> <front>
<title>Web Linking</title> <title>Web Linking</title>
<author fullname="M. Nottingham" initials="M." surname="Nottingham"> <author fullname="M. Nottingham" initials="M." surname="Nottingham">
<organization/> <organization/>
</author> </author>
<date month="October" year="2017"/> <date month="October" year="2017"/>
<abstract>
<t>This specification defines a model for the relationships betwee
n resources on the Web ("links") and the type of those relationships ("link rela
tion types").</t>
<t>It also defines the serialisation of such links in HTTP headers
with the Link header field.</t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="8288"/> <seriesInfo name="RFC" value="8288"/>
<seriesInfo name="DOI" value="10.17487/RFC8288"/> <seriesInfo name="DOI" value="10.17487/RFC8288"/>
</reference> </reference>
<reference anchor="URL"> <reference anchor="URL" target="https://www.rfc-editor.org/info/rfc3986" >
<front> <front>
<title>Uniform Resource Identifier (URI): Generic Syntax</title> <title>Uniform Resource Identifier (URI): Generic Syntax</title>
<author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee "> <author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee ">
<organization/> <organization/>
</author> </author>
<author fullname="R. Fielding" initials="R." surname="Fielding"> <author fullname="R. Fielding" initials="R." surname="Fielding">
<organization/> <organization/>
</author> </author>
<author fullname="L. Masinter" initials="L." surname="Masinter"> <author fullname="L. Masinter" initials="L." surname="Masinter">
<organization/> <organization/>
</author> </author>
<date month="January" year="2005"/> <date month="January" year="2005"/>
<abstract>
<t>A Uniform Resource Identifier (URI) is a compact sequence of ch
aracters that identifies an abstract or physical resource. This specification d
efines the generic URI syntax and a process for resolving URI references that mi
ght be in relative form, along with guidelines and security considerations for t
he use of URIs on the Internet. The URI syntax defines a grammar that is a supe
rset of all valid URIs, allowing an implementation to parse the common component
s of a URI reference without knowing the scheme-specific requirements of every p
ossible identifier. This specification does not define a generative grammar for
URIs; that task is performed by the individual specifications of each URI schem
e. [STANDARDS-TRACK]</t>
</abstract>
</front> </front>
<seriesInfo name="STD" value="66"/> <seriesInfo name="STD" value="66"/>
<seriesInfo name="RFC" value="3986"/> <seriesInfo name="RFC" value="3986"/>
<seriesInfo name="DOI" value="10.17487/RFC3986"/> <seriesInfo name="DOI" value="10.17487/RFC3986"/>
</reference> </reference>
<reference anchor="WELL-KNOWN-URI"> <reference anchor="WELL-KNOWN-URI" target="https://www.rfc-editor.org/in fo/rfc8615">
<front> <front>
<title>Well-Known Uniform Resource Identifiers (URIs)</title> <title>Well-Known Uniform Resource Identifiers (URIs)</title>
<author fullname="M. Nottingham" initials="M." surname="Nottingham"> <author fullname="M. Nottingham" initials="M." surname="Nottingham">
<organization/> <organization/>
</author> </author>
<date month="May" year="2019"/> <date month="May" year="2019"/>
<abstract>
<t>This memo defines a path prefix for "well-known locations", "/.
well-known/", in selected Uniform Resource Identifier (URI) schemes.</t>
<t>In doing so, it obsoletes RFC 5785 and updates the URI schemes
defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track UR
I schemes that support well-known URIs in their registry.</t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="8615"/> <seriesInfo name="RFC" value="8615"/>
<seriesInfo name="DOI" value="10.17487/RFC8615"/> <seriesInfo name="DOI" value="10.17487/RFC8615"/>
</reference> </reference>
<reference anchor="RFC2119"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<front> FC.2119.xml"/>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
le> FC.8174.xml"/>
<author fullname="S. Bradner" initials="S." surname="Bradner"> <reference anchor="BCP190">
<organization/>
</author>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to sig
nify the requirements in the specification. These words are often capitalized.
This document defines these words as they should be interpreted in IETF document
s. This document specifies an Internet Best Current Practices for the Internet
Community, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba">
<organization/>
</author>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l specifications. This document aims to reduce the ambiguity by clarifying tha
t only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC8820">
<front> <front>
<title>URI Design and Ownership</title> <title>URI Design and Ownership</title>
<author fullname="M. Nottingham" initials="M." surname="Nottingham"> <author fullname="M. Nottingham" initials="M." surname="Nottingham">
<organization/> <organization/>
</author> </author>
<date month="June" year="2020"/> <date month="June" year="2020"/>
<abstract>
<t>Section 1.1.1 of RFC 3986 defines URI syntax as "a federated an
d extensible naming system wherein each scheme's specification may further restr
ict the syntax and semantics of identifiers using that scheme." In other words,
the structure of a URI is defined by its scheme. While it is common for schemes
to further delegate their substructure to the URI's owner, publishing independe
nt standards that mandate particular forms of substructure in URIs is often prob
lematic.</t>
<t>This document provides guidance on the specification of URI sub
structure in standards.</t>
<t>This document obsoletes RFC 7320 and updates RFC 3986.</t>
</abstract>
</front> </front>
<seriesInfo name="BCP" value="190"/> <seriesInfo name="BCP" value="190"/>
<seriesInfo name="RFC" value="8820"/> <seriesInfo name="RFC" value="8820"/>
<seriesInfo name="DOI" value="10.17487/RFC8820"/> <seriesInfo name="DOI" value="10.17487/RFC8820"/>
</reference> </reference>
<reference anchor="RFC6838"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<front> FC.6838.xml"/>
<title>Media Type Specifications and Registration Procedures</title> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<author fullname="N. Freed" initials="N." surname="Freed"> FC.6454.xml"/>
<organization/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</author> FC.6648.xml"/>
<author fullname="J. Klensin" initials="J." surname="Klensin"> <reference anchor="STRUCTURED-FIELDS" target="https://www.rfc-editor.org
<organization/> /info/rfc8941">
</author>
<author fullname="T. Hansen" initials="T." surname="Hansen">
<organization/>
</author>
<date month="January" year="2013"/>
<abstract>
<t>This document defines procedures for the specification and regi
stration of media types for use in HTTP, MIME, and other Internet protocols. Th
is memo documents an Internet Best Current Practice.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="13"/>
<seriesInfo name="RFC" value="6838"/>
<seriesInfo name="DOI" value="10.17487/RFC6838"/>
</reference>
<reference anchor="RFC6454">
<front>
<title>The Web Origin Concept</title>
<author fullname="A. Barth" initials="A." surname="Barth">
<organization/>
</author>
<date month="December" year="2011"/>
<abstract>
<t>This document defines the concept of an "origin", which is ofte
n used as the scope of authority or privilege by user agents. Typically, user a
gents isolate content retrieved from different origins to prevent malicious web
site operators from interfering with the operation of benign web sites. In addi
tion to outlining the principles that underlie the concept of origin, this docum
ent details how to determine the origin of a URI and how to serialize an origin
into a string. It also defines an HTTP header field, named "Origin", that indic
ates which origins are associated with an HTTP request. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6454"/>
<seriesInfo name="DOI" value="10.17487/RFC6454"/>
</reference>
<reference anchor="RFC6648">
<front> <front>
<title>Deprecating the "X-" Prefix and Similar Constructs in Applica <title>Structured Field Values for HTTP</title>
tion Protocols</title> <author fullname="M. Nottingham" initials="M." surname="Nottingham">
<author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre
">
<organization/>
</author>
<author fullname="D. Crocker" initials="D." surname="Crocker">
<organization/> <organization/>
</author> </author>
<author fullname="M. Nottingham" initials="M." surname="Nottingham"> <author fullname="P-H. Kamp" initials="P-H." surname="Kamp">
<organization/> <organization/>
</author> </author>
<date month="June" year="2012"/> <date month="February" year="2021"/>
<abstract>
<t>Historically, designers and implementers of application protoco
ls have often distinguished between standardized and unstandardized parameters b
y prefixing the names of unstandardized parameters with the string "X-" or simil
ar constructs. In practice, that convention causes more problems than it solves
. Therefore, this document deprecates the convention for newly defined paramete
rs with textual (as opposed to numerical) names in application protocols. This m
emo documents an Internet Best Current Practice.</t>
</abstract>
</front> </front>
<seriesInfo name="BCP" value="178"/> <seriesInfo name="RFC" value="8941"/>
<seriesInfo name="RFC" value="6648"/> <seriesInfo name="DOI" value="10.17487/RFC8941"/>
<seriesInfo name="DOI" value="10.17487/RFC6648"/>
</reference> </reference>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="HTTP11"> <reference anchor="HTTP11" target="https://www.rfc-editor.org/info/rfc91 12">
<front> <front>
<title>HTTP/1.1</title> <title>HTTP/1.1</title>
<author fullname="Roy T. Fielding"> <author initials="R" surname="Fielding" fullname="Roy Fielding" role
<organization>Adobe</organization> ="editor">
</author> <organization />
<author fullname="Mark Nottingham">
<organization>Fastly</organization>
</author>
<author fullname="Julian Reschke">
<organization>greenbytes GmbH</organization>
</author> </author>
<date day="18" month="August" year="2021"/> <author initials="M" surname="Nottingham" fullname="Mark Nottingham"
<abstract> role="editor">
<t> The Hypertext Transfer Protocol (HTTP) is a stateless applic <organization />
ation- </author>
level protocol for distributed, collaborative, hypertext information <author initials="J" surname="Reschke" fullname="Julian Reschke" role
systems. This document specifies the HTTP/1.1 message syntax, ="editor">
message parsing, connection management, and related security <organization />
concerns. </author>
<date year="2022" month="June" />
This document obsoletes portions of RFC 7230.
</t>
</abstract>
</front> </front>
<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-messaging- <seriesInfo name="STD" value="99"/>
18"/> <seriesInfo name="RFC" value="9112"/>
<seriesInfo name="DOI" value="10.17487/RFC9112"/>
</reference> </reference>
<reference anchor="HTTP2"> <reference anchor="HTTP2" target="https://www.rfc-editor.org/info/rfc911 3">
<front> <front>
<title>Hypertext Transfer Protocol Version 2 (HTTP/2)</title> <title>HTTP/2</title>
<author fullname="Martin Thomson"> <author initials="M" surname="Thomson" fullname="Martin Thomson" rol
<organization>Mozilla</organization> e="editor">
<organization/>
</author> </author>
<author fullname="Cory Benfield"> <author initials="C" surname="Benfield" fullname="Cory Benfield" rol
<organization>Apple Inc.</organization> e="editor">
<organization/>
</author> </author>
<date day="12" month="July" year="2021"/> <date month="June" year="2022"/>
<abstract>
<t> This specification describes an optimized expression of the
semantics
of the Hypertext Transfer Protocol (HTTP), referred to as HTTP
version 2 (HTTP/2). HTTP/2 enables a more efficient use of network
resources and a reduced perception of latency by introducing header
field compression and allowing multiple concurrent exchanges on the
same connection.
This specification is an alternative to, but does not obsolete, the
HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged.
This document obsoletes RFC 7540 and RFC 8740.
</t>
</abstract>
</front> </front>
<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-http2bis-0 <seriesInfo name="RFC" value="9113"/>
3"/> <seriesInfo name="DOI" value="10.17487/RFC9113"/>
</reference> </reference>
<reference anchor="HTTP3"> <reference anchor="HTTP3" target="https://www.rfc-editor.org/info/rfc911 4">
<front> <front>
<title>Hypertext Transfer Protocol Version 3 (HTTP/3)</title> <title>HTTP/3</title>
<author fullname="Mike Bishop"> <author initials="M" surname="Bishop" fullname="Mike Bishop" role="e
<organization>Akamai</organization> ditor">
<organization />
</author> </author>
<date day="2" month="February" year="2021"/> <date year="2022" month="June" />
<abstract>
<t> The QUIC transport protocol has several features that are de
sirable
in a transport for HTTP, such as stream multiplexing, per-stream flow
control, and low-latency connection establishment. This document
describes a mapping of HTTP semantics over QUIC. This document also
identifies HTTP/2 features that are subsumed by QUIC, and describes
how HTTP/2 extensions can be ported to HTTP/3.
DO NOT DEPLOY THIS VERSION OF HTTP
DO NOT DEPLOY THIS VERSION OF HTTP/3 UNTIL IT IS IN AN RFC. This
version is still a work in progress. For trial deployments, please
use earlier versions.
Note to Readers
Discussion of this draft takes place on the QUIC working group
mailing list (quic@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/search/?email_list=quic.
Working Group information can be found at https://github.com/quicwg;
source code and issues list for this draft can be found at
https://github.com/quicwg/base-drafts/labels/-http.
</t>
</abstract>
</front> </front>
<seriesInfo name="Internet-Draft" value="draft-ietf-quic-http-34"/> <seriesInfo name="RFC" value="9114"/>
<seriesInfo name="DOI" value="10.17487/RFC9114"/>
</reference> </reference>
<reference anchor="JSON"> <reference anchor="JSON" target="https://www.rfc-editor.org/info/rfc8259 ">
<front> <front>
<title>The JavaScript Object Notation (JSON) Data Interchange Format </title> <title>The JavaScript Object Notation (JSON) Data Interchange Format </title>
<author fullname="T. Bray" initials="T." role="editor" surname="Bray "> <author fullname="T. Bray" initials="T." role="editor" surname="Bray ">
<organization/> <organization/>
</author> </author>
<date month="December" year="2017"/> <date month="December" year="2017"/>
<abstract>
<t>JavaScript Object Notation (JSON) is a lightweight, text-based,
language-independent data interchange format. It was derived from the ECMAScri
pt Programming Language Standard. JSON defines a small set of formatting rules
for the portable representation of structured data.</t>
<t>This document removes inconsistencies with other specifications
of JSON, repairs specification errors, and offers experience-based interoperabi
lity guidance.</t>
</abstract>
</front> </front>
<seriesInfo name="STD" value="90"/> <seriesInfo name="STD" value="90"/>
<seriesInfo name="RFC" value="8259"/> <seriesInfo name="RFC" value="8259"/>
<seriesInfo name="DOI" value="10.17487/RFC8259"/> <seriesInfo name="DOI" value="10.17487/RFC8259"/>
</reference> </reference>
<reference anchor="URI-TEMPLATE"> <reference anchor="URI-TEMPLATE" target="https://www.rfc-editor.org/info /rfc6570">
<front> <front>
<title>URI Template</title> <title>URI Template</title>
<author fullname="J. Gregorio" initials="J." surname="Gregorio"> <author fullname="J. Gregorio" initials="J." surname="Gregorio">
<organization/> <organization/>
</author> </author>
<author fullname="R. Fielding" initials="R." surname="Fielding"> <author fullname="R. Fielding" initials="R." surname="Fielding">
<organization/> <organization/>
</author> </author>
<author fullname="M. Hadley" initials="M." surname="Hadley"> <author fullname="M. Hadley" initials="M." surname="Hadley">
<organization/> <organization/>
</author> </author>
<author fullname="M. Nottingham" initials="M." surname="Nottingham"> <author fullname="M. Nottingham" initials="M." surname="Nottingham">
<organization/> <organization/>
</author> </author>
<author fullname="D. Orchard" initials="D." surname="Orchard"> <author fullname="D. Orchard" initials="D." surname="Orchard">
<organization/> <organization/>
</author> </author>
<date month="March" year="2012"/> <date month="March" year="2012"/>
<abstract>
<t>A URI Template is a compact sequence of characters for describi
ng a range of Uniform Resource Identifiers through variable expansion. This spec
ification defines the URI Template syntax and the process for expanding a URI Te
mplate into a URI reference, along with guidelines for the use of URI Templates
on the Internet. [STANDARDS-TRACK]</t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="6570"/> <seriesInfo name="RFC" value="6570"/>
<seriesInfo name="DOI" value="10.17487/RFC6570"/> <seriesInfo name="DOI" value="10.17487/RFC6570"/>
</reference> </reference>
<reference anchor="COOKIES"> <reference anchor="COOKIES" target="https://www.rfc-editor.org/info/rfc6 265">
<front> <front>
<title>HTTP State Management Mechanism</title> <title>HTTP State Management Mechanism</title>
<author fullname="A. Barth" initials="A." surname="Barth"> <author fullname="A. Barth" initials="A." surname="Barth">
<organization/> <organization/>
</author> </author>
<date month="April" year="2011"/> <date month="April" year="2011"/>
<abstract>
<t>This document defines the HTTP Cookie and Set-Cookie header fie
lds. These header fields can be used by HTTP servers to store state (called cook
ies) at HTTP user agents, letting the servers maintain a stateful session over t
he mostly stateless HTTP protocol. Although cookies have many historical infeli
cities that degrade their security and privacy, the Cookie and Set-Cookie header
fields are widely used on the Internet. This document obsoletes RFC 2965. [ST
ANDARDS-TRACK]</t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="6265"/> <seriesInfo name="RFC" value="6265"/>
<seriesInfo name="DOI" value="10.17487/RFC6265"/> <seriesInfo name="DOI" value="10.17487/RFC6265"/>
</reference> </reference>
<reference anchor="PROBLEM-DETAILS"> <reference anchor="PROBLEM-DETAILS" target="https://www.rfc-editor.org/i nfo/rfc7807">
<front> <front>
<title>Problem Details for HTTP APIs</title> <title>Problem Details for HTTP APIs</title>
<author fullname="M. Nottingham" initials="M." surname="Nottingham"> <author fullname="M. Nottingham" initials="M." surname="Nottingham">
<organization/> <organization/>
</author> </author>
<author fullname="E. Wilde" initials="E." surname="Wilde"> <author fullname="E. Wilde" initials="E." surname="Wilde">
<organization/> <organization/>
</author> </author>
<date month="March" year="2016"/> <date month="March" year="2016"/>
<abstract>
<t>This document defines a "problem detail" as a way to carry mach
ine- readable details of errors in a HTTP response to avoid the need to define n
ew error response formats for HTTP APIs.</t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="7807"/> <seriesInfo name="RFC" value="7807"/>
<seriesInfo name="DOI" value="10.17487/RFC7807"/> <seriesInfo name="DOI" value="10.17487/RFC7807"/>
</reference> </reference>
<reference anchor="STRUCTURED-FIELDS"> <reference anchor="HTTP-PRIORITY" target="https://www.rfc-editor.org/inf o/rfc9218">
<front> <front>
<title>Structured Field Values for HTTP</title> <title>Extensible Prioritization Scheme for HTTP</title>
<author fullname="M. Nottingham" initials="M." surname="Nottingham"> <author asciiFullname="Kazuho Oku" fullname="奥 一穂">
<organization/> <organization/>
</author> </author>
<author fullname="P-H. Kamp" initials="P-H." surname="Kamp"> <author initials="L" surname="Pardue" fullname="Lucas Pardue">
<organization/> <organization/>
</author> </author>
<date month="February" year="2021"/> <date month="June" year="2022"/>
<abstract>
<t>This document describes a set of data types and associated algo
rithms that are intended to make it easier and safer to define and handle HTTP h
eader and trailer fields, known as "Structured Fields", "Structured Headers", or
"Structured Trailers". It is intended for use by specifications of new HTTP fie
lds that wish to use a common syntax that is more restrictive than traditional H
TTP field values.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8941"/>
<seriesInfo name="DOI" value="10.17487/RFC8941"/>
</reference>
<reference anchor="HTTP-PRIORITY">
<front>
<title>Extensible Prioritization Scheme for HTTP</title>
<author fullname="Kazuho Oku">
<organization>Fastly</organization>
</author>
<author fullname="Lucas Pardue">
<organization>Cloudflare</organization>
</author>
<date day="11" month="July" year="2021"/>
<abstract>
<t> This document describes a scheme for prioritizing HTTP respo
nses.
This scheme expresses the priority of each HTTP response using
absolute values, rather than as a relative relationship between a
group of HTTP responses.
This document defines the Priority header field for communicating the
initial priority in an HTTP version-independent manner, as well as
HTTP/2 and HTTP/3 frames for reprioritizing the responses. These
share a common format structure that is designed to provide future
extensibility.
</t>
</abstract>
</front> </front>
<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-priority-0 <seriesInfo name="RFC" value="9218"/>
4"/> <seriesInfo name="DOI" value="10.17487/RFC9218"/>
</reference> </reference>
<reference anchor="HTML" target="https://html.spec.whatwg.org"> <reference anchor="HTML" target="https://html.spec.whatwg.org">
<front> <front>
<title>HTML - Living Standard</title> <title>HTML - Living Standard</title>
<author> <author>
<organization>WHATWG</organization> <organization>WHATWG</organization>
</author> </author>
<date>n.d.</date> <date/>
</front> </front>
</reference> </reference>
<reference anchor="FETCH" target="https://fetch.spec.whatwg.org"> <reference anchor="FETCH" target="https://fetch.spec.whatwg.org">
<front> <front>
<title>Fetch - Living Standard</title> <title>Fetch - Living Standard</title>
<author> <author>
<organization>WHATWG</organization> <organization>WHATWG</organization>
</author> </author>
<date>n.d.</date> <date/>
</front>
</reference>
<reference anchor="RFC3205">
<front>
<title>On the use of HTTP as a Substrate</title>
<author fullname="K. Moore" initials="K." surname="Moore">
<organization/>
</author>
<date month="February" year="2002"/>
<abstract>
<t>Recently there has been widespread interest in using Hypertext
Transfer Protocol (HTTP) as a substrate for other applications-level protocols.
This document recommends technical particulars of such use, including use of def
ault ports, URL schemes, and HTTP security mechanisms. This document specifies
an Internet Best Current Practices for the Internet Community, and requests disc
ussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="56"/>
<seriesInfo name="RFC" value="3205"/>
<seriesInfo name="DOI" value="10.17487/RFC3205"/>
</reference>
<reference anchor="RFC7301">
<front>
<title>Transport Layer Security (TLS) Application-Layer Protocol Neg
otiation Extension</title>
<author fullname="S. Friedl" initials="S." surname="Friedl">
<organization/>
</author>
<author fullname="A. Popov" initials="A." surname="Popov">
<organization/>
</author>
<author fullname="A. Langley" initials="A." surname="Langley">
<organization/>
</author>
<author fullname="E. Stephan" initials="E." surname="Stephan">
<organization/>
</author>
<date month="July" year="2014"/>
<abstract>
<t>This document describes a Transport Layer Security (TLS) extens
ion for application-layer protocol negotiation within the TLS handshake. For ins
tances in which multiple application protocols are supported on the same TCP or
UDP port, this extension allows the application layer to negotiate which protoco
l will be used within the TLS connection.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7301"/>
<seriesInfo name="DOI" value="10.17487/RFC7301"/>
</reference>
<reference anchor="RFC7258">
<front>
<title>Pervasive Monitoring Is an Attack</title>
<author fullname="S. Farrell" initials="S." surname="Farrell">
<organization/>
</author>
<author fullname="H. Tschofenig" initials="H." surname="Tschofenig">
<organization/>
</author>
<date month="May" year="2014"/>
<abstract>
<t>Pervasive monitoring is a technical attack that should be mitig
ated in the design of IETF protocols, where possible.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="188"/>
<seriesInfo name="RFC" value="7258"/>
<seriesInfo name="DOI" value="10.17487/RFC7258"/>
</reference>
<reference anchor="RFC6797">
<front>
<title>HTTP Strict Transport Security (HSTS)</title>
<author fullname="J. Hodges" initials="J." surname="Hodges">
<organization/>
</author>
<author fullname="C. Jackson" initials="C." surname="Jackson">
<organization/>
</author>
<author fullname="A. Barth" initials="A." surname="Barth">
<organization/>
</author>
<date month="November" year="2012"/>
<abstract>
<t>This specification defines a mechanism enabling web sites to de
clare themselves accessible only via secure connections and/or for users to be a
ble to direct their user agent(s) to interact with given sites only over secure
connections. This overall policy is referred to as HTTP Strict Transport Securi
ty (HSTS). The policy is declared by web sites via the Strict-Transport-Securit
y HTTP response header field and/or by other means, such as user agent configura
tion, for example. [STANDARDS-TRACK]</t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="6797"/>
<seriesInfo name="DOI" value="10.17487/RFC6797"/>
</reference> </reference>
<reference anchor="SECCTXT" target="https://www.w3.org/TR/2016/CR-secure <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
-contexts-20160915"> FC.3205.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7301.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7258.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6797.xml"/>
<reference anchor="SECCTXT" target="https://www.w3.org/TR/2021/CRD-secur
e-contexts-20210918">
<front> <front>
<title>Secure Contexts</title> <title>Secure Contexts</title>
<author fullname="Mike West" initials="M." surname="West"> <author fullname="Mike West" initials="M." surname="West">
<organization/> <organization/>
</author> </author>
<date day="15" month="September" year="2016"/> <date month="September" year="2021"/>
</front>
<seriesInfo name="World Wide Web Consortium CR" value="CR-secure-conte
xts-20160915"/>
</reference>
<reference anchor="RFC7595">
<front>
<title>Guidelines and Registration Procedures for URI Schemes</title
>
<author fullname="D. Thaler" initials="D." role="editor" surname="Th
aler">
<organization/>
</author>
<author fullname="T. Hansen" initials="T." surname="Hansen">
<organization/>
</author>
<author fullname="T. Hardie" initials="T." surname="Hardie">
<organization/>
</author>
<date month="June" year="2015"/>
<abstract>
<t>This document updates the guidelines and recommendations, as we
ll as the IANA registration processes, for the definition of Uniform Resource Id
entifier (URI) schemes. It obsoletes RFC 4395.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="35"/>
<seriesInfo name="RFC" value="7595"/>
<seriesInfo name="DOI" value="10.17487/RFC7595"/>
</reference>
<reference anchor="RFC7605">
<front>
<title>Recommendations on Using Assigned Transport Port Numbers</tit
le>
<author fullname="J. Touch" initials="J." surname="Touch">
<organization/>
</author>
<date month="August" year="2015"/>
<abstract>
<t>This document provides recommendations to designers of applicat
ion and service protocols on how to use the transport protocol port number space
and when to request a port assignment from IANA. It provides designer guidance
to requesters or users of port numbers on how to interact with IANA using the p
rocesses defined in RFC 6335; thus, this document complements (but does not upda
te) that document.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="165"/>
<seriesInfo name="RFC" value="7605"/>
<seriesInfo name="DOI" value="10.17487/RFC7605"/>
</reference>
<reference anchor="RFC4791">
<front>
<title>Calendaring Extensions to WebDAV (CalDAV)</title>
<author fullname="C. Daboo" initials="C." surname="Daboo">
<organization/>
</author>
<author fullname="B. Desruisseaux" initials="B." surname="Desruissea
ux">
<organization/>
</author>
<author fullname="L. Dusseault" initials="L." surname="Dusseault">
<organization/>
</author>
<date month="March" year="2007"/>
<abstract>
<t>This document defines extensions to the Web Distributed Authori
ng and Versioning (WebDAV) protocol to specify a standard way of accessing, mana
ging, and sharing calendaring and scheduling information based on the iCalendar
format. This document defines the "calendar-access" feature of CalDAV. [STANDA
RDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4791"/>
<seriesInfo name="DOI" value="10.17487/RFC4791"/>
</reference>
<reference anchor="RFC8470">
<front>
<title>Using Early Data in HTTP</title>
<author fullname="M. Thomson" initials="M." surname="Thomson">
<organization/>
</author>
<author fullname="M. Nottingham" initials="M." surname="Nottingham">
<organization/>
</author>
<author fullname="W. Tarreau" initials="W." surname="Tarreau">
<organization/>
</author>
<date month="September" year="2018"/>
<abstract>
<t>Using TLS early data creates an exposure to the possibility of
a replay attack. This document defines mechanisms that allow clients to communi
cate with servers about HTTP requests that are sent in early data. Techniques a
re described that use these mechanisms to mitigate the risk of replay.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8470"/>
<seriesInfo name="DOI" value="10.17487/RFC8470"/>
</reference>
<reference anchor="RFC4918">
<front>
<title>HTTP Extensions for Web Distributed Authoring and Versioning
(WebDAV)</title>
<author fullname="L. Dusseault" initials="L." role="editor" surname=
"Dusseault">
<organization/>
</author>
<date month="June" year="2007"/>
<abstract>
<t>Web Distributed Authoring and Versioning (WebDAV) consists of a
set of methods, headers, and content-types ancillary to HTTP/1.1 for the manage
ment of resource properties, creation and management of resource collections, UR
L namespace manipulation, and resource locking (collision avoidance).</t>
<t>RFC 2518 was published in February 1999, and this specification
obsoletes RFC 2518 with minor revisions mostly due to interoperability experien
ce. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4918"/>
<seriesInfo name="DOI" value="10.17487/RFC4918"/>
</reference>
<reference anchor="RFC6415">
<front>
<title>Web Host Metadata</title>
<author fullname="E. Hammer-Lahav" initials="E." role="editor" surna
me="Hammer-Lahav">
<organization/>
</author>
<author fullname="B. Cook" initials="B." surname="Cook">
<organization/>
</author>
<date month="October" year="2011"/>
<abstract>
<t>This specification describes a method for locating host metadat
a as well as information about individual resources controlled by the host. [ST
ANDARDS-TRACK]</t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="6415"/> <refcontent>W3C Candidate Recommendation</refcontent>
<seriesInfo name="DOI" value="10.17487/RFC6415"/>
</reference> </reference>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7595.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7605.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4791.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8470.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4918.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6415.xml"/>
<reference anchor="XML" target="https://www.w3.org/TR/2008/REC-xml-20081 126"> <reference anchor="XML" target="https://www.w3.org/TR/2008/REC-xml-20081 126">
<front> <front>
<title>Extensible Markup Language (XML) 1.0 (Fifth Edition)</title> <title>Extensible Markup Language (XML) 1.0 (Fifth Edition)</title>
<author fullname="Tim Bray" initials="T." surname="Bray"> <author fullname="Tim Bray" initials="T." surname="Bray">
<organization/> <organization/>
</author> </author>
<author fullname="Jean Paoli" initials="J." surname="Paoli"> <author fullname="Jean Paoli" initials="J." surname="Paoli">
<organization/> <organization/>
</author> </author>
<author fullname="Michael Sperberg-McQueen" initials="M." surname="S perberg-McQueen"> <author fullname="Michael Sperberg-McQueen" initials="M." surname="S perberg-McQueen">
<organization/> <organization/>
</author> </author>
<author fullname="Eve Maler" initials="E." surname="Maler"> <author fullname="Eve Maler" initials="E." surname="Maler">
<organization/> <organization/>
</author> </author>
<author fullname="François Yergeau" initials="F." surname="Yergeau" <author fullname="François Yergeau" initials="F." surname="Yergeau">
>
<organization/>
</author>
<date day="26" month="November" year="2008"/>
</front>
<seriesInfo name="World Wide Web Consortium Recommendation" value="REC
-xml-20081126"/>
</reference>
<reference anchor="RFC8949">
<front>
<title>Concise Binary Object Representation (CBOR)</title>
<author fullname="C. Bormann" initials="C." surname="Bormann">
<organization/>
</author>
<author fullname="P. Hoffman" initials="P." surname="Hoffman">
<organization/>
</author>
<date month="December" year="2020"/>
<abstract>
<t>The Concise Binary Object Representation (CBOR) is a data forma
t whose design goals include the possibility of extremely small code size, fairl
y small message size, and extensibility without the need for version negotiation
. These design goals make it different from earlier binary serializations such a
s ASN.1 and MessagePack.</t>
<t>This document obsoletes RFC 7049, providing editorial improveme
nts, new details, and errata fixes while keeping full compatibility with the int
erchange format of RFC 7049. It does not create a new version of the format.</t
>
</abstract>
</front>
<seriesInfo name="STD" value="94"/>
<seriesInfo name="RFC" value="8949"/>
<seriesInfo name="DOI" value="10.17487/RFC8949"/>
</reference>
<reference anchor="RFC5861">
<front>
<title>HTTP Cache-Control Extensions for Stale Content</title>
<author fullname="M. Nottingham" initials="M." surname="Nottingham">
<organization/>
</author>
<date month="May" year="2010"/>
<abstract>
<t>This document defines two independent HTTP Cache-Control extens
ions that allow control over the use of stale responses by caches. This docume
nt is not an Internet Standards Track specification; it is published for informa
tional purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5861"/>
<seriesInfo name="DOI" value="10.17487/RFC5861"/>
</reference>
<reference anchor="RFC7617">
<front>
<title>The 'Basic' HTTP Authentication Scheme</title>
<author fullname="J. Reschke" initials="J." surname="Reschke">
<organization/>
</author>
<date month="September" year="2015"/>
<abstract>
<t>This document defines the "Basic" Hypertext Transfer Protocol (
HTTP) authentication scheme, which transmits credentials as user-id/ password pa
irs, encoded using Base64.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7617"/>
<seriesInfo name="DOI" value="10.17487/RFC7617"/>
</reference>
<reference anchor="RFC7616">
<front>
<title>HTTP Digest Access Authentication</title>
<author fullname="R. Shekh-Yusef" initials="R." role="editor" surnam
e="Shekh-Yusef">
<organization/>
</author>
<author fullname="D. Ahrens" initials="D." surname="Ahrens">
<organization/>
</author>
<author fullname="S. Bremer" initials="S." surname="Bremer">
<organization/>
</author>
<date month="September" year="2015"/>
<abstract>
<t>The Hypertext Transfer Protocol (HTTP) provides a simple challe
nge- response authentication mechanism that may be used by a server to challenge
a client request and by a client to provide authentication information. This d
ocument defines the HTTP Digest Authentication scheme that can be used with the
HTTP authentication mechanism.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7616"/>
<seriesInfo name="DOI" value="10.17487/RFC7616"/>
</reference>
<reference anchor="RFC8446">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl
e>
<author fullname="E. Rescorla" initials="E." surname="Rescorla">
<organization/> <organization/>
</author> </author>
<date month="August" year="2018"/> <date month="November" year="2008"/>
<abstract>
<t>This document specifies version 1.3 of the Transport Layer Secu
rity (TLS) protocol. TLS allows client/server applications to communicate over
the Internet in a way that is designed to prevent eavesdropping, tampering, and
message forgery.</t>
<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 50
77, 5246, and 6961. This document also specifies new requirements for TLS 1.2 i
mplementations.</t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="8446"/> <seriesInfo name="W3C Recommendation" value="REC-xml-20081126"/>
<seriesInfo name="DOI" value="10.17487/RFC8446"/>
</reference> </reference>
<reference anchor="CSP" target="https://www.w3.org/TR/2016/WD-CSP3-20160 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
913"> FC.8949.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5861.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7617.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7616.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8446.xml"/>
<reference anchor="CSP" target="https://www.w3.org/TR/2021/WD-CSP3-20210
629">
<front> <front>
<title>Content Security Policy Level 3</title> <title>Content Security Policy Level 3</title>
<author fullname="Mike West" initials="M." surname="West"> <author fullname="Mike West" initials="M." surname="West">
<organization/> <organization/>
</author> </author>
<date day="13" month="September" year="2016"/> <date month="June" year="2021"/>
</front> </front>
<seriesInfo name="World Wide Web Consortium WD" value="WD-CSP3-2016091 3"/> <refcontent>W3C Working Draft</refcontent>
</reference> </reference>
<reference anchor="REFERRER-POLICY" target="https://www.w3.org/TR/2017/C R-referrer-policy-20170126"> <reference anchor="REFERRER-POLICY" target="https://www.w3.org/TR/2017/C R-referrer-policy-20170126">
<front> <front>
<title>Referrer Policy</title> <title>Referrer Policy</title>
<author fullname="Jochen Eisinger" initials="J." surname="Eisinger"> <author fullname="Jochen Eisinger" initials="J." surname="Eisinger">
<organization/> <organization/>
</author> </author>
<author fullname="Emily Stark" initials="E." surname="Stark"> <author fullname="Emily Stark" initials="E." surname="Stark">
<organization/> <organization/>
</author> </author>
<date day="26" month="January" year="2017"/> <date month="January" year="2017"/>
</front>
<seriesInfo name="World Wide Web Consortium CR" value="CR-referrer-pol
icy-20170126"/>
</reference>
<reference anchor="RFC8297">
<front>
<title>An HTTP Status Code for Indicating Hints</title>
<author fullname="K. Oku" initials="K." surname="Oku">
<organization/>
</author>
<date month="December" year="2017"/>
<abstract>
<t>This memo introduces an informational HTTP status code that can
be used to convey hints that help a client make preparations for processing the
final response.</t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="8297"/> <refcontent>W3C Candidate Recommendation CR-referrer-policy-20170126</
<seriesInfo name="DOI" value="10.17487/RFC8297"/> refcontent>
</reference> </reference>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8297.xml"/>
</references> </references>
</references> </references>
<section anchor="changes-from-rfc-3205" numbered="true" toc="default"> <section anchor="changes-from-rfc-3205" numbered="true" toc="default">
<name>Changes from RFC 3205</name> <name>Changes from RFC 3205</name>
<t><xref target="RFC3205" format="default"/> captured the Best Current Pra ctice in the early 2000's, based on the concerns facing protocol designers at th e time. Use of HTTP has changed considerably since then, and as a result this do cument is substantially different. As a result, the changes are too numerous to list individually.</t> <t><xref target="RFC3205" format="default"/> captured the Best Current Pra ctice in the early 2000s based on the concerns facing protocol designers at the time. Use of HTTP has changed considerably since then; as a result, this documen t is substantially different. Consequently, the changes are too numerous to list individually.</t>
</section> </section>
</back> </back>
<!-- ##markdown-source:
H4sIAPV0KWEAA+V9W1fjWJbmu3+F2vEAVNsOIO7BdFeTQGQyRVwaiMqq1atX
pWzLRh2y5JJkCCoq+rfPvp99JEPW1OrpWbMmHzLAyEfnss++fPs2Ho8Hbd4W
2dvkh01ezPNymXyqq7aaVUWT3OXtTfLT9fWnwbyalekKnprX6aId51m7GN+0
7XqaN+PpbP3iJf5w8GIwT1t46Nvp8fXZ98EMfllW9f3bBB4ZVNOmKrI2a94m
zw73XwwG+bp+m7T1pmkP9/ff7B8O0jpL3ybH63WRw1fzqmyStJwnl1lajK/z
VTa4q+ovy7rarN/yrL5k9/DRvPvbz9k0/NJspk1bw0zCR2tZYPz95PjT+WDQ
tPDKP6VFVcI67rNm0KzSuv3TnzcVzbysBuv8bfJvTVW3dbZo/n0wWMImbabj
vGk22bhIp1lB66UtGQzSTXtT1W8HyXiQwH95CYO8nyQfqraFvb5JV/Qx7+37
tP7S/UtVL9My/wttx1v6ZF3BHAv+OUnGcFzpTZ2W9Pus2pQtbvjxBhdd5Cl9
nK3SHGa1Kqv2X/B/kzJr6Q+bGhaD59i8ffr07u5uon99OhiUVb2C195m+Crc
oLfJ+fh0Eh19AyOXbT5r5JHxyfHJT+cfftzy6Cyd3WTw2M9nP4wvzj/8jp66
fHfy+vD1a/j48+UF/frszeuX9NTFxfh3Hz7+/GH8+fKcH3x5gERTLrrzOjjY
8rpV1jTpEjZSHjrc8gz+e4inxI88c4/8eZPP6O/wt/959fGDTPXFG5rq+fj6
7P2nCyBy+vzli1f78PnJx4+/Oz+74o8OX76Ajz5dfvzh4uz9+PTs+vj8gv/0
6vX+K/jT1fXl55Prz5dnp+N352cXp/zH12+eH+hefro8/3h5fv3HLTNf13lV
5+09Pfr+gomhTetl1obzvGlXxaRZZ7PJ3U3a3i0nQEv8IF94/CbQz0V+i7f+
Cgk/ref0hFEtkZiQGhEj3K6fjq9//hE+e3d2ffLT9lcvsnZ289i73+EDf//L
B4PxeJykdLNn7WAQ8Yxq0WZlsmkyvtYpcJHABZK2SmbAZ1r+63iaNtkcr34z
Sa5v8iYBTrdZZWWb4OzzRZ41yTRrWmAa8KZ8Br8CASZ3sPs4cXlIX93CYsOb
4VXzbJGXWVJmd0ka5mgcCF563ibwVhwPZw0HC/wmL+7xy8tNPs+S87Prd0m2
gLe2jRty63DwbpwVvR2nOc/WRXVPy4HH2hsYrWyzGi74KJlu2mSVL29aWJ+O
Ni0yYFFJBU/WSZO3G17XZDCI98Z4efLt22/x1gJD//59IucCPCT70wf8X1v9
Cbj3PKubPw0Gv4EHk7PT8+uPl8CDiwx2PqmzVXULh4KjN9mMVjPNYOpZst5M
dYG/GQxO82a2aRr8e7Xg50kUAel9gWmsi3SW6Rpp+SgrcC9IXiTIAPG3Ioej
3LW7NL5b/svdMyTOvVFyd5MDTcLAaT27Af4yT+Aw/4eSNH6zmfDDT4/5iebp
J5rkUz/g03+GffhZ3v4jvd2YFkxwluIK4XQ2ZXgB3dZ2DfeEpckkr57+81HS
VJsaljWrgAxQEpKMaXgReLxuG7YOi/OWAWfVSl5B/4yzr0BuuJ3NU5JZzVOV
WTh9PMVVPp8X2WDwBGmmruYbOp3uXSNKAbIvUeom07q6Iwrs3MFv3/Cf7987
l3EEv+i9gsWushakfANEscjqGvYfqB2+QNcVBx12buxwlAwvz66u+RdgEMl/
gNjjx/gzudNEumVGe5Ymt3DBsvYe6QhGbmAZIzihWbFB7ect0GmySFdALily
2GR6n+QroFake6DjkfEF/Dmdr/Iyp8VU+Ps8u82Kag1/o/OC9cOnMGB6C/SX
TmFQfm80iVmRw9gwcFbfwmbiF+FCf3Xv5c3GgejSwHdg5G3j2hnIe+tsw89n
X2GWuIerbAaHlTcrJKMvGTHbDEU4Uye+PCtn9f0af8Uh1nXWwCc0Cm0sT5MX
yFNvkGewCHAcB7ennMMIOTygc4QThc3C78Np5HV2lxYFsxd4i+NjoAoKDaXz
5Kaa4QnBb3M4eTzEqgQO6ZgbHBKeLx3vAnhtNEfYus1qzazlHh4o8lXewkAN
TNe2HzjxMdImrHZTtEiY02pOexoYP47WVji9G6TjOm9wfjVdOeLKynsdjbJI
WKS3cJXxF1wmzGieK2P9qboDoqmR/cBozQZYEFwmz93xZSuYVA7UgFSyTkmQ
damDqJy2BF4NX9OvJJtyVoGWm5cpr5q2ZiQMRbYH/gB7M8/5ZPRYUcbS7eGj
QN46QwLEI7BLJgKJBmhEjjcmsGAI3jIma93K6DT1QNyBMjsDpoXTbzZ5i6JJ
xdAKyDdtmVcXSHZADPBwirSOc4RZ7TS2CHyx0sNdXhRh45jab6sCJBAc0jxf
AN/Bz9cgTGCHQESRQYRsCES4zNZROBtI4XsLYFSbWigFX8hKAWgc1ZhuYIfI
cLLzrMmXJU5OLpgnnmibiDb822lKMPoKxeUMrsxiU8BW4ImC4lDDvblLhM8H
FoHvxO1AlkvbAVIDOAKw+jlNG78UVuSOpM5AKa4zXTh/M53BGa0qNPvmcDzv
cSbLDJYD9/p+1KVkvd+RmpLS1UrKzWoKc4YZ8o7AP7O8ybdw56ubalMA7bam
CpF+BWp50oCNscp+m3xuWOdaIw3+NvoOEomSKc8AxM5NNRdCgdu0aUjiwnvp
tE2BAw5DY8GNJfrEnVylX/PVZgXsvNhkuCGw30jkeGR1taJnhAXju/Tr8wrv
AJB5RWTBdMSyFJ42UsDbk5G8we2MJKyfCFJJjVJHuSzsM1yXFS9paLs+B3oG
7j4HWYlHd1sBlcx/29XtgHzaFOxUVntnm5qvRKT+EhF51RdnzLzLaQcTkPuw
nDnIfd7GhpkcLJwey5ojeAL0P6DG7A6eajZwTe+JTeIaYEVt7naDWClKBrjB
cLBgeSL1k4CC7zFH+/ZtuoaRYBE00hbVned9TxcbqAWo9v8JFRyBgYy3AAeJ
biM8msF35hWq3kCrMzR+aQk4KEtdYjWknfBcFnxP8xlPNeiDf6OyP8JRgeUU
oLXDt+GsclITUhKG9iLU5pZpPbc9yXkTiGZvMxKZqPWh7fDkCS6S1psWyQke
YUmLJ/0g+ZLdo1YPN3X4/vPVNWp/+G/y4eM1a4L/+vkczGn8+eqn44sL+0Gf
uPrp4+eL0/BT+ObJx/fvzz6c8pfh06Tz0fvjPw6ZvoYfP12ff/xwfDHklfiN
QtKETZnK6oAwkQ+kKCGbWZ1P4Rf4zg8nn5KD57CX/wB7eXhw8AbIlX95ffDq
OfyCd4RfRmoO/wp7RqeZpTUOAvwArv4a5GKBohyMJ+DbJREC7WQCwoO2+4cM
dxj44fy3ybcndBvRmFL+7q8riAEQhIH3L6u0kBsbaBo1aqQ+ZPvASuSb/a0g
uqPvph1OoaygIxuQsom9EwNEEgFGWjZ40YmNJ6/3kR8/f/4M+bJ/LjD+ZIi2
DVkC9BNaCOFZeOHxxacPQQqdnwpFv3q2fwAbT5dLbgUxXLj7QICEAdBm7maT
5WTEYz89mBwgadwc0v+fDffkXSsySIHq2S7Q/UGt9ZbkIsjruccM+HKeH384
1m/hC1WrUl0LjvV4zmojy9atm5t7/jMiMhGZHzEM+YwWZduBalbG/LXE18Jl
3oWfQN0E5rkBRWtkdhyzLiCPShlVjIOwKGgiOaEKkbHznAxEpvS0vHcsSP60
B2v2XM8TWO6UI9TPlM95gh4RO1Q254aH55iW321qnD4qUGT/I++Nx8btR/Y/
VrNv3nmFrN8UXwZsG8WvYTeBLYLyny5lpnO8pPhTTswxnIqxwHJM+2M4PJx8
fFdQ6Neo9W7W8BvDHaBBVChOsqwV0QaGMxxonae0CCYLU5pgGVOgx8ngHfwt
+5quyLjo3EmWTXd5c0MzR4UB3jt2EhSJw8iJMVcyD0A/ZxpBaxM+4l1K8Zvh
eaU8UNZJe8F3HsEGjnCa8m4R8qhDuZmNjahEeYO9O60IkAP+W8MPDWvFixp0
ZNTDKr5194Hc7ZUNz7SoiEm0qPaD0pAS1zG8CZW7EnYOZ79pC9pBoFKvvhAf
XlXwXSbv2D4D0VXukKCH4Uk0z9M1mTXCAdDuos0S28y9E6ewykFxu0F6Ut0b
JtzCuq/wrnXun8pFQ2BgiwObhBfEvBU+6HJGJOQuTzpKYMNu0FZladSjbVC2
YEFELjdZDgzvrmRp9DNcYJjCueltx1MkVsaGntgWiuahQCCSJYkKImZYOyrW
NQIZs19TCs0G6ogvr71tt03kFv4oXOPKPByD97jRQgys7xsnI46FtKHMxhwj
ZADjFPNmFBF9khXCjJ39zIA1gp/A9uD7JIWcYoh7DJt1jxYkYYPM4uw2kKUa
GDbp8sD3Jt6pFu5OmCS+klRlUORg6IaJW+8zjSLmco5KBiK6CfDCYi481ptN
SDhqUu2mBbKlJREE2OqgYNeoppKm0d8r2ihgbILT++PBN5BAIAqRrz7dyhIa
+AyFUwGWEmyH2Hi8FFbP1N6dorEM5isMXy3aO9wFEfEe6WLsqV5lc4QE8fYw
tNBHYAhuQj9Xs2cMeVMi/I3iQdmyTdTNnvwAJE9l3uusWvOBF3jiNHe6U1/K
6g7mvvSAnO6fvlNMxrxRI0eQT0cZ/t2kXteEuo9ijTD2ZxhXARnARDtCCyBn
5A1vcZHeC8CgU3J2Rp/yVU0Qchn16Mhgy4jmYLPKpoVPhBE1bNwvQDdoZJc6
/NBjD/Z24xz++vCHYQ+OyDdb3Mu4tA96+VDq/Iz8Rb1BHW0M5diOgWcZYpCM
JokARQY3a2FsxFyUkYgBYZAzLLLZrJG1CUCDOvwkMdiQ1CJUCESsIGhFlwfY
XmlqDKx+gdqN0MwOWsZwCXNYB2hBXgWgKcutwKlmWXczCawoQFJtkCoJRcZJ
gPKObrrj5JdPH6+ufyHVBlkKUQ0jXmS5JL8c7h8kJ+SDm+NjIIfKxsA9VB5I
V0ebctaKWivgI987ZwTzd1kkpsVdSiZ//AbRlFGnhd3G79Ws5XrMSRwB8KgQ
cCBE0UTYLuIVwNOFM+yP6HrZDvIbgl0vaL4wN9L3mg7uPmLomhnOGCVXktU1
akL0eQ2sp2ahCLS/8HtBSBKyYLpv+ZpY540KG0fIO42HImCjp4h3EKh6BWf8
7ZtSNRhCuBxSn+ZZm+aFaqYXefmFlFHW5oRIzIGDnrOm2ayY6cgROUYKM8C7
BOSEvrpd5kiiY9GeVYs9HCT7OitAYt/irVOwSTA02CIYvchi1kl0k8HxzFr+
lrCiRhnhaLvu6LhUqVefJjdCUAkhx0w9XBFXJGRP9Wm0y3DO6yINSiFZ868P
91EpJCY3bP68SSmwY4jMiFmxKhOfLy9kU8g/YejkptnU68YQW9pBdo4TlovO
ItJH78rAkkbECxgLj84bPYcG+rfK75NpOncnWAZDBnEx5rKE7eFFZKPYPB2o
UAINwA0kdkqMAOjvphmJEeVAlB5fjXAy08iIu8FIQGewiy5UBK1zkY3JogCx
IEgnol62SpjyZxq03pSIKclACk4s0uZG/Sn+7vMJm3ofY65sZceqInNp0mHM
ydLV9mEtTzvOgt0HfSlwpE3m5JGcQQ6cHlWeiD+XwLWX7A8lRpzSKoO6o2yX
5UgN6oDYnQ7ZEU+jqgs4F6SmGznsiOEIP0PnDoshfLOjrHRWVw2IcFB7GOHN
ioIxVVJn2InTYNRSk4sKO1zlX+mwyYszdBOLCETg0oZ4Bs1YUDF8mo4QvS3A
ic2nKXzYeTxGijqQeCb1bK0oOVx+EGAr9r3miF0SSNrBwVVrY1rCy0Xrkr9G
rv10KrsJigK7QxsjSf46IyY6f/wmeSBRZYSRwKjI5wEN20FLCEhF9uHnbHqk
oI9ed3wEFeNgOXa4PnMDtsFzuqRAK4Q9oKXMFIdGMphss2p9TzycxSiF8JBT
B1n/JYZGvNuUM8afMPRoQFc3HIbdJ/OC9eAY0fcI5nuvYEGNRt4SP5G79BX3
C5EnfMHTQwGdDjF6oGSXzdNn8uGz79/34JuIqC/ZmOdLcX1xhU4fJliiiliF
T3ZRJpMuD3cpwwWPEHAmM+c0K3Iysj5kLUaRNPiKExa3sdjGz+VLZbaswF6j
KeD7FANRPUlIl1iNbhB+na7Nkh0TfCsbYLOpUi+aQuXsnr48hf/d5XNYHlzP
jVxO/ANYTLl8A4b8EUx7VPE11GCG3gCi1xq03932piaDzCRqnRN+kLKLH2QR
rfcTmgpwt9T2I1WwMAmrXEbFWGq6GHwXEWLn8KetR9WLjqZLoKK2sjRIfQRD
J9QktkX64MOmhTeKBxijK6pN40hR9ZEA/xDhjuwa8LWliA2Et7P8Nos8fArF
kPDPW8FoVCblynDNA0+Koovy8K6c2L9iKpwoh8Ee8TdpSkrQ3LMq2Ma6Wtc5
MgBxmrY12EmwNDbpb0AHhb2N4YElrKwM03GmxKLCtSjD8856dashe0iWVUWO
UhYF6yonyTt4kvyAFPEpcrZdRc428suq2frtCQzZQXxi3+NjfjvvVSW1KWI0
5jDeOob6vHomoTC7hycNunIH6GbTEyfjY5x4/9CPeM/RTOQaUyj/SPQj76y7
F3eaPOqA+471lbsYN0bsN2WBNzwYNrZKtWoQ9KqQ0gXdiJAAITKKBYHXYvDI
pkW14wcJqVDLNAU7dT2e3o/hH9s7HAxOrdQD5DA0B7B0FSPTcnD1wpXk0Q5r
6JhVxrFPTj/A/y16iP32IFaBlC/pBjEncUvseh7YRZOzUYfPGMbMu4shAnZd
+abfpGiWdj3t5A1T5IQPteM9fFzxVSAgRXiXAwk6Uw0338cK5YuOThpbd3dE
lBHHioyoR7ZmN9pzlsA7If4IZfOegA4oRsjCxXhPnN7xA6s03MgtV+Mm+PUj
78jv+gacKOFgHYVdHEeQGTccsCXXWgWPnKKfndxb48HTSkSTCjaWqwIvCHoI
g5AIQ6MHHeKKSgn3ashsXCBxFGSZ0O4dTA5EGRAOcXDw/XuEuYA69J//+Z8U
Oy1h69ngx7Pr5Gl7o1uIo8DpN+1b/RIGdA6OQbav4TO3NP5S84//ARcfVM+s
Hh8vYYFv4YUVjLJP7+q/z6Z6uL+ffPzdQNSa8fX9Ont4fH3qIiuX7c3b5MX+
/uCKtJi3yQ9p/fRwcjgY/JuqEHhT/p1e3+Wy/B2QHwJJgWwwNIJ9/x4ZMeSK
TrtjmyFnIR+MxwOC727q7Fc87iDyesJAtFTQGJMWdqERs/7l62ev0axnM45j
tcgNl+oxzyxwwQBOTCGA7+M/8F0M3cF70QHSU0R9Ye3f+POGPEoUQXl941bN
cJWZ+2hUqpua1kcqPoHoROkdM3qy1ZkoBjihCeoWE3QcDDfZrGab88L5UzSg
0ibnfDOPzZCdXanD0/2B2WF3w8DqDJ1SYDOJoMxrsYWY88ANGpHfndFp9gbS
AXU3bGVnfETDatQ1hR1X5LnfrOdhZIQ38cNPn6+FITANqi7mAwfmxlD0FvAc
8E0wJGGDqADguG50gmn6Y0RMKR5wt9k7Emq51BXM4ZRoBTzy6dnF2fVZF0/Y
6vIVziqQ7qUdKJ4ca9umyw9lpDGYJmDxDuPTpW1FEqCBfqZHGo4h4cMiecSf
Www7W54ii+mLQ8+B4hcSJxqavcU2Po3Dh0ZHDEfF2SdVgBRwnhN9daBZ+TLt
HUk1/B7Od3gm7z3BJKthOAh/jdFYtyE5dFoUH0n/muMq4DUI+a8w6kH2hPV1
HGGqLhR0HPn3/417wKoacZx/k6Slf6dB5M82L/NHdQ+CnFGmijNy0VY0Bjvn
5hHsIRopnbsu0JaBmHG0QzQMu0/7NET28RgH30ZHXRXDwBjVK5ySg+DkdQaD
phy45pO2PJioUcIY60dxqy3hsY3n7Aon4oXtmwiCDHjhJYN+7/LancZ7Ndgk
ERzfsXdSq1jvm2FQArqAC4wRnuuOVbzGKNo/RGj0wkElbYSwI/Pci0r5Edjj
XXovJkIr2RKBq+fktEHshKTtt2+U9UW4ttihTHGku0s+lgJYNjk6FBfIdIVx
3d2FN2adbNoKSWtmMCTbE6h6csh2iOSRr5xU1Zccva5qWIgpbU51DvEoUXuG
mZK9RPitxJgT3MP+DHWwMBigZhri+/ksb7vKxAOKvTmB0ns6xqpcbBrNr3gw
XBf9mk43Jyl32d2CZBxnyGoQuN4BZCy6bxJ/RCTHTwXb7Ihce+j2kWdRN/iN
7mT3Ld5mYdXZ7UgwW5EKeIROXNq3b5IdiSDCIlChnhO9GsN9F8Iff/X94c4D
oV1fXCUz//UQigmiZIYyCyPVaw3n//btSgzW55Nnk+dq/UjwJf18xbF0jxo2
MhWNgBAHicI4HAIcIVB88Tb0mCKGdjDBzYual2alRMK6NvuWhlPmJd80kdSo
awD3BFFq0RXGs4p2YJctkVGiu/B68nwCZske5iery8cQTYEngRP0vndwOHkx
QRAWlKhUjXti4nc5qygkJsowVeDZuF3hDrTZVlxwkvRYvcF9HEAc4QoWf677
jTcQOWmfXyN3R99WuKhdjTVkNXngsqPH0mckKVC4XKBNd9xErj91CqJd6MPk
0N2X1pb5ocdPgSLsFxKsVp6v7kAuYSgNSDqM/igVYRqaM3C4xw+nrXlKUKAJ
hsnW/2NuM06rCUeIwT9oRKGHKqS8zZzYeiRMhAPd1EGyyL/GMZO8aTAE+QqP
orDLrkuZw1Z6mQbqBh47zOP407lng4QhwAvIJM+/JkOMFXp6ezCMEI69EUg9
CRvMyc9Hof69mNq8dPp9HC/TT4W4o7BLYswNZTU6B9U2vWOeN7OKJFAP08Gt
ArqK4n6Jd3a5PmZZsx+ZIvzAGugB7cKsBE0i+mV1GVgeuSU0zBJIQ5U45CoU
g8CJhBI6gp/CG/hqPUlOZf7sYvP3VlYwGPzoUoJU8EsY4zIvA1ATnJqMUkfz
Z5Bgas4HeR8Y8+SpMCyH77Cqr9scdGnrIbBARKMo7i6AyKoCi/8GlFKwO0tn
NUwSiz7FEIjI4xBHXcDV5YuIQQzOLbrr39ysgUtStqa6lyUUbW+kjl5EwjbB
BUTMAfes6Z07sRCSD5tSUzDTvJDAip1AfbqBO2om8UEpuUvMDKZX6jWleD5h
CHNHBcJD+FyAAngIZimoIqKNCd+5wyCH2HmLJBxmlEvyXLnIlwhRu7gXIhOM
IYmkzW3GHqd2D2e6KfjtiWQNClxJqcDkntGRJTFB1k8Er26yVIJdwqRswh1A
1k2O8jaQVXeCN0BxbykERuN7WZ6ExDx3bqpCMhsRDQGZiWrrsNWClbqdVrCX
9t8Ifyvog2LYoBvm0sIrWdrT3VUmzbpikG0uBK/Lny1VMe3jTGSclZkuN6Bv
nA++BM1TtF6MOca4GzByimL8OxJ7aNMhnOVLg0hOOWoHLRwOeaMkpiLG3YUK
gIvf5nPKOJQ1o5BAPyQdrt1CZTc0DLEq9lcUBUKQLl8vSnjDuZ+VHKprB+9i
dpiakUrTyELtG6i4ifkqR/4U3xCxUtnHQSeOMjJaf0dpbP+3qD/ROwX3vc0w
ZI6sRI2O6HELSsKtSFyQCyQGcUYc3CB5vmmbqSjZRRcGnr54iVqKAk3RxN4b
WZwjxb/S4MZ6e9iicWPhWtEdYmVdOME5qR24Z4YMUJQT3yvRdbp4GNw2PHlN
gqD0UaLuLXvR8ViRLYG8Ehhv0CXoG9M6zxbEaNQqN1c/HMuMuCqmwqpUCfFo
kSOnPwXC1iL/lZ5IOp9LaDfsN9bLIBIKfsZY8wgbzXppSoE9Y9Y/6UiYr5AG
cCLR9hoVdsVpBsm3J6yOfH/UlU+3q71fi/mER1OxAifpXBJLJSldPpFhYh92
w80qvem9SMucgkXwNkp1gAVz4ZQjLlIOYaKwZGCrGB6CsPxtihGJIMKA11as
6rRtOvuiSZGvDl+8JnTdRML2kEPZGYOuCGqk+P9JQk4tc0+kpc9sk1vuSbMP
N3SjWl00AMGit1nKKueXLFuTkp+Xc2K4n0tOSgPq8KhS4HxqYuKxYDI0Twvn
HLR3H+NVKwePU7PFMo3eQRiOfUGznn4imKLe3ePwAyxWJCk2ejwNBcYXCSvm
wDzqe4bhOQLf4qY1iLTJfPULAXYopYahHFRHDU0TCZ3XIWIMYZFbeAlzeY1M
L+F45Wuq1PcTBnw9ClAQqxnb/ZZ1YNuMiZXLUsNY/EbHoL1qGkU+rXHdzN4X
oNeJRbGmAgnOo3mEX6JAM34WqwU0dFRNW4lupfiB6JQSuByPrXqbG5o2RKMF
2LqbzTa1ukBNkKh9h2aAuM8oO1WB13mA/ogTCLgn+PIvF8J1ftkOve958RM5
9lklDxp52FbFeDhfqEHZX/D5XkewQOww6oxBhwfEIBURuCRLod6ih3jYBblB
Kt0xnPewyNIvmFfMckYrEuGfBLJHV/PGeFcf4+2QiQZVucl2tkNOkOrj7GCu
JL6CZWmaDKkEXDGk69pgqEnOYb6caokUQXv1LsK4QmKigB2YAlHnS7rGyCpf
Pn/x3AKjBcqAN2AsI+jGY3l2XQGjwzRX2dd8tea6ChQjrWmFC70fA3GqjvvB
U/qemUCbDoscdevfhATXmUTm8Sda2A7/8tPV9ZUu5dWbV+KmTU4+Xl4FfFxu
DXoe6QfSIar6C8yiRrgV7wBYhhmnBWFUcnUXYFHL0US4OKSCTBJnSLuHBUfq
PB18k40VwLE7gFpQJ2uilzxNm4pnv+gcMOObKVNjpllmuCdXZycn13+4/qef
n51MTi7H/MBYHmjGh/sHL/ffHLxAoBVfrsSErtaYTtGtXfLXLUOB5OyLNy98
hkLfvAeZxow5Fjyqq1xb5uMnzHzc4lLSMjIu7w7OI0VmQt/bfb1vzowRJqTb
b1d7YjvCyZgfUeIB6UawEksplxoFKFVO9PlVOudiNAE1QN/TKFDSNAp87IdN
7TQdg0zYKAEnLGMlQCrIxthUQmTnHNVLlG3R0oVdEqf1hqnUgTCnrU9TID2f
mZy9TDnrEaMTaC7HVg7db55mdwL2pzbO/d9lG1U0zu97FnotK3WlyhiW4WEx
GwDUh9t0xrFqRgq7+SSbdHI28ZBAA2YJQ/J/A3aBFnuRN9Qpyp69SFfxrNoU
fEwIINOjlEBjPWHQr78kEbZBCgV6WfhS5+3eJPm0fdaGWrGfEM57RSk5ggwg
zYWpy5z2HDqolgQf5pUKHNXxzdJ1d/Llvt7JBSfUU92UFJYp8PtnFwzGuX6P
WgQUMEaaeckAdpMVtxwGyyJNCTnrlPBRVk/BHxhJMeIoDQ59YD796RgYNFYW
yO469X/QmIT/HfXdU0bm9lofhslLEtAClDE6IgKSLzPMa1bSZNEi5i3p6mgB
dN4h2ZLIHtLWY/IR7jt9LEUY75uLEELRQ4XxzHFcxcVrKJ4O1XggDjRuWPsi
yoxgfmEkfOjPX70hjxEXDRF5hQxD0z0tqdMCY/HmAJFMc+Qb8C6N42NmgTII
lNpbTYQhBs6D4LXXbXo4+bxcom/InEl0NGJ9A/1maR1USlFOttSBjCpFylE5
ZBkNArQ3qiYtpJih1mOLy+iMJFeeGQ7yGI2U72L8EbNWKQUEPKAgQHGtszeG
YVcBRxabwtPvkdST0KAol9zNDgfWZ9BvP8/GHB1H5REI3db0GDL2sTITB6f0
Sh8sfCmYweBfNxmlU4jwAiaH0lhVD7qFWglSOTbom/V9yBtzTrEjCz9IrQKj
YszMvXwBrFAkgXNLbRIMOI2QLSICgMGhyI9zAlf4AHhO6BcvyaqXICzyv3ss
6EZteTwJk76b8g7tjXsBeyhhHl/zZ96MkdWik6VZvcH7sk2/hgWfHyWd8ir5
IpnmJdpzFBvGqbA+U5A3j6IxejIYb4NUQxG/K/5IApJebLdcd5mzRtlyYNT2
BuWkLSOPyvBp/UwquFfHM6GKjBRhgvaK+aaA56SENGIeQlJLlJGaHF2/Fm38
1soZtIEMqOZ/sSwV5gNq42OpQq01sIJ9qMX2NBObqyjOblhtJCaFGSI0dsO3
FE4SI1Ea5BOGR42slgSF9a7YVoanX+/v74Oh22YtR2H6kBPj9YwvMviwHWB0
4QRMYVa6wsUDIntjQtPjUQEku7nTqI//KICGFA7UMGGQlaE5fnhz0AAoKG5X
9wAdcfHOu9wQKi+mntLWqQsU/B3sCs8q8NaY8SXmFL5aGQ6sislIbzCeE1U1
8WH1D8XOc2HNLCu0OKP5VmnLdJ8snMr2NVWnAwV9hwIyn0IopkzerGMX6CGW
Z682BV4CkoVauQ1zuInLivw2/oHWGjH8gFlbCViKqerSP4GFJIeIv0uZkGiC
UmU0L0aSDgF3KXoAVdhM7WcMlzkjeXiKfMZmdrspSqJzgfDWWM9BcU5RYlD2
v37+ah+JO+lVZ5JMJlZC8TCXSz11dWcsJIvQvEpxSMmbySGGomCYai6cobS3
3AkDy+LidcJZLQfWrdxX/tCQBLkpottv6nXFgV5GQPodYL2EUEaa2VEI1O7O
/BnOfGSRuRQULkJcwT2qmobiCflRWZGCZ9JMsY4sJxoCOqmQoZD//T/s9OKl
W+ESvWm9YiUEhxoGOXKFewU+xMg5VTy4vN0VO2zlF9XC7tK4LJk6bILWYQnm
BKrR/ZpS3crT49+r3vjm4LWkcsaIySTxCUe+CiqLa73j8rIsvJ7tfqfxMhzN
X9NrL3O2yD4P1es6iX7pEvs7SuyRryJh5VQuEtEyj3drYi0pazoxiWVo6EIj
xw26gb5SSMNbpLzbGBGnD4W4LkucwkPFixpGZH2XDjvRyCoMXo3DkEM5OAkS
FzMXyZTSa8+OT/coBnL7y8Wdp1qvAFF57ZNtQt8QQZxBduU1ivgMSx+jfvMF
i3OGjFiHy3uVJpyd3w3YsiE83rb3w2Ss+JVMiIImdPuRKghMdVq6sgXgUJgd
Jw41XwhEGCbOgwnu0fxVnNh5HIrm3Q6dYwZTBO9gWhwxi1a/gFTuhH2qFHwK
SU98ADSVcCYyS6v44+iVC5XG9RvkiyPnfcdQnwJ16xSzZJznJMgDUnZc5BOR
/ztLVcbo80DtI+2rELkKt/vsSWWkYCN0g8HX5veh1g85qBdRdqtWZQLdAIzt
1IBkRBL3JjKpDj9IfR6kVsuyKTqCkIugmomkxyt2fsFh6Ftj/WutvtBgmT3M
Pp4zwXlnSlDNJgljJnFCTqeway9gngwicypgvT+4ouFWur4FYhTGsShYQS8K
M4vLB0TeLem8QIp1TPV520dyrrhGzgkWa5JqAFH9Jol0CIYoyQOt6OJK20UC
zVUUAZ3eq4/ZFseaL0KPJkA570YmKnjkdNm0i/gSkFByvElgBeu8XVCCKava
Jjbe5XXTdmpVhXr1wZk1vfeL6cCPUT2RFqa4EEAY53ODhV7L0ZZoAkEKuTqQ
Ky9ZEipFjsF0TfeZiuEVI/HhwUAPlTcgzy2LiFBUlANXUIhiKZ0qJZWFg4Ax
AfBLIzJWggNIRSStnYHv7Jace/Fm6DELYQbnJ4VJSKQyLcxVyO8usVNBvZcI
i84O4IUBVvHl5aqY/cXFvs2nqkh83hRcJhPFSCuVNoK8bW/iMlGoHUXrTcOK
lQxGJuy3nD9Qli9HuoJHiAX5Ygl87CSU5vltPt+kAgLFldPKbNxWY14sEiUW
BWP9NgSG4L6L3xcjDtosFIFwcGJ/cKrQdANbQA6pa6o1hTdkU5cj/6JwkXyN
IbqmAaN2zpqHIia6FdmZMZu0iOZGdOcrDiIznQKdZ5neYYeLCX4Uw3FoB2Tl
BrEBzGBh93YIdns8E0Di6fhN4bCUXAjFc5vr5o7n/cWc4fh2hyBJRf14rbuH
+/uj5Pn+Pi3kxf7+nhU6m1ebKWZxaUVMcxf6hAXLxXbUYkmZN/na9i1mdDGH
lUWGIkGEOSjWJ3TCgU+IMlnpVCk+O7iuvDfCXmlxrz12YGFfeD1YP2utSJDf
Ti3PQSlRtPlYlBdMh+nmwQn96vmKSMNDrsfLmit+8Ry3ZMQ5DWBLKU0MB+iU
Nfz2rdMwDAwlC1isokytpnIVGjjWUJJvY89ILJG5rB68/FdX6tJ7OKbSIqdV
3Po8NYUMOLeIHBDbyRxYJDACaVQhpgcKWYJjQIboeSrn/KXc3/8lLidpFUzC
qEcJ64e/PH/z5hfl3026QN+y9bZo4M84WEiu4fVw5EMIvCHfmrYNsoT+0DiM
1cJhkYLsq+/JTzAkdSGEjkYsizEdiRmk1k1WCdgKCQjBoPbVZGTXJYtNy77v
X62qECoyCyG4zerRwIh5JMhNMZLR90qayloLnuTS9SLnsNnzB8paZCHTqVNw
JFnf1GxaWfGKI7kQ7s+KgCgepOFCIzWWlhvQ0OG6BI+XFIjYVlfEkAe2jus6
5/5dSIrOV0flpLSe1PdOxeruZtMO0wZtmuzRm0VaCSnK5vUq1b3Y0xPRx6iF
mwQy3vWYcd/Z2HUogiHBYBoy9u0vMbCq78vc9rK/w5lYPe5PfNyv5xWn/++c
e5ehuh5VutAETAbdnn39SvYkFzOJDjaknlIwlWXhvYhSGCVhVAKFQTtfakRX
GQdRk5MGZtYI59BwPgp+8x7HABjAwTzbPxjB/w7xf69oC5/tv7ZWA2yMqlDS
kL0HDGjRYym+O2ijah+wICLLpBtueG3hrmDCJAQAmQG9ylDvbKxNIDcA7G4l
1xwkQONnzX9S0ltnmLMosfBYt7fCGMtJ8sk+Dwm2WmtAgtWlUAQnDFFgpYUK
yLI0GqeqvqxSLC434qVjIJy+ir1pnKPRA9mFbYoHV+v/i3/lKCTSkWRBP77Q
8KS/VgK7eWd5Pa7WBIo7dnW4rVckmLyx6pn68ex6Ekf0Wgco1FRkFPc02bVA
RkI8h0esPbK7B4hJPn+V3OEpM2Tj3DuuOKXhX1FQkAKonNbINfabzWpFHdu0
QrRXdRHX/Wvy9/z3V0cUf6W0Aj7Av8J4x+yOiKb2K/sIY+C+6NiwN/ozjHdq
pX7Zof/IuG5+uJ/h51c2HvOa/WeESX1spYmFMeUOXefiUL7ZWoQZUWvxrFv1
mAi1Ir4fynxq/kAo1cJVdNmXmPswzNTzsLyxnBGkhihYmHOJ4Hnkn1Y4gGbJ
BV8f50VBL6KrwUphqN3e16xal/fpdy4qzc0MhfXLEOVD6ntE9H0YI6qO21DJ
6MB0ROnesv5ubF6vbgFz+lleg9TDlc1CYQjWeENG/uCyy+UE/N9llMjhswzz
y7W8FRVEQKU9rr0wze6rMjiK782VsYP9HL7c7xAwQAaBv+Ck8COI7ELktZS4
o8a48LS6GinlRxhup1UfO56RM8KVwcxKjYZtRPlShviIBt5XU6KiBI7DOSeK
Y6rYBxXvbdk+zBd2qW5FZX4S/POecIuRuUlWa5gdXjRapfLhic+7tcqxPU6P
2WHpnArYNbFFyh6fap37dnYcn50WIfSgS/IKoGlGCeibWpAzOHrUZqNw82MO
F/2LBKz2ygxQpBm5DLm4xK6L4d7rzJnOUUveLtyUk111jXObWcz82/PtkahM
ExfSBYX+wfvYKUBBdzdURI0nw5mYmmjZ+Pg92x5y72IbZCskpod0FCKQ6HqG
IjGSv0mUWuTyTbU10y7UusutXpUw9szRvCnTO4au2UDttCOKCyfQ4n/i5b3j
5X17orXKtvbgds0T+wXPQM0MMTZue+MNRJbvGA2FE2EKsitmbZlubzVxw/wm
4hFRJ56r/3t3U8kk4/ZG6PJnJ2IE2LCx8JQafD3whgfc8kzllhnkErl1vHMr
BuodyhpCwdoKFUyyoJ8umrSrNUUUm7ZadPNYZ8ipsOfPmnLoYXbEv4wnr7A7
oSD8NjQ1b3EZrNvQ2g4KJvHu2JzbLvy2BYhPCGOSmDFjw6FyKVG6MUWQVR7Z
x650nnGMl5NnwSSyaGX/58mhs5kosxZ7PRbccKjbQcgnFfRAu6vry88n158v
z07H787PLk4j2C61FjNtvZlRpVV8WW8giQrmkC0KvpSyTeZ9UtLkcqRcDUj1
/V7F0d74XM2otXaXvW9ElhlmqVNSCMcE7pJyRDvBf0eRQ3GP2nNObHeuI4uK
oMSa7XGnuKg6nlJLp94Rq0E932dUvThiyhRLZ6lZ9dZcBhJGpLummt4uEGNv
vaG3srhvhuNht1qeCBQtWDaMXmVal3iZ2xsMr+2cMklI87BLxV0rgLaoKmwn
qL9O03rIbSfDJ38Zdl3GWml4VYHyxVPRkzC+xm2eibNVAR7ypy2+KYo3oDKs
vQ5o9Bj5iNSJG1XrDTUCXr58/loulRaMsyBKTR+47irU5tHZIgUM66R7P9Yg
JOuxhFZ3QC9970Xr4SsptYbhCBmsfCb6XjfN8kEdQORvpO+1cZJiRF9sgkhb
CQ36kjR8X6Ppa2u8Six62UdCtFyIjXpKOvqaFMh3cEB8wx7RUrQoHG7MkGu9
D11dd46L4iw8vunMsZxG029BTeozL4e8p7KYmBiS0CF2y7QQy42EjYRbRpXf
JHwtOdWT1u4C6vT+9kREDSgqJ8KPMWgQfZKuYGsjcW2RdGpMFsdlXJM/vL/A
SBT4h/LdgKOOv66K8eH+/uuDg8OXlhj4w8dLDZx88/wNR7r1yptbhAHHEmxa
Tm4Eg1r+7ErGd20Sg8ok55pdarPWlTbll2Tp7EZVA7Zz6SZJ5L2VxY70EOav
93xZQGFcTfPlhqOk+fyljFknvE5iXULJ3K05e9pZiHuc2fXStghwbHILJMDk
oaxMdmWYw1Q54vbEhV4BK5KiJrGjBgzUagErn7pGDJxZQBa5NV7o9BL1wXgM
vqdzavpokAhcTMPLQiCc6YmWEpY2lnLNLgNUHzNXDf2hrhWSbG7YtLaXEM0U
dv7MhPrDjI4jHX2psjZFW2KOJTdSTsG11BKPPERd6GUnyOwQHyFnq1gQU+vq
f0uKrDN3aJIUFybxrRgnx0AER8qyPiubplr2yOKqtQGINJwGAqxT08f2JgzL
v8M2KKD9YW4aBZFQnMEtB8SQGrTQJ5IiX5AVqbaqUmKwWZ9PDtE2xW5CxKhe
SPQjxymFbj3CXdXnoxxYcXnzhBtliOvYWmGJjSfhA+YMV05fZ2vCT4t7UrcE
mh0FDyD6SVnsU20TNI/5NEPAvO1GumULfHEnUXUVxYi7NoSvalJT+nWMJGSb
YADSw9v6YnLIAeJ77KY4w9DSLMYtHvs2FSv01TdYdZ1SjE+vKcNRIv2aMZ9E
2vR0gvM12hNZFtYGptJ9EoW/be2kCICd0abeuiK+yHIol/iAhKqUUnDBGG57
mZnq3usbkc4ZoByuN1O4xMO/Y0ffiC9QSkRUjasmeeR9xeHFHG3SUuuBJjcn
OZeTSEufWp+FutVx0ZvYD+gwV+wxIrnNPCUBYWt9TpFNT1Y+F1wZravw43s6
xKUyUdzagPy+MKyDNRU3Ec8OHTJ7pDVc9CbbcIfaLTfFJzxsZRjIMsiVzPaJ
jmTBw/Os7haHjMwhPqbgfYmjFzBChANAuhunE+Qs8/RLXA3Eg8ib0iLPOUlc
BXLUA0hnzMj13LpSGYyzhT4xqju6Q29hiDFtNBg87KDoAMzRPRBtVL6itEoV
5BljzEtfFCm4G0OXh2CUIcz9+Gk9iyN3t0ydRhk+yOqZhEbsTGdce9NYeQsi
QaXM0BeMbqJhOpivxgGLfAa7sN9rKtPRcqvFXvM4UvNCBXkDEYWetdCjn8W2
7hR/e7cIefM/gl48eOB0Q4cIaQ6BsviqTYFoL/WSgkSWWAJtuOM9MymV3y0y
d6k96N89GxE7/7Q/3FOoOqxaNRUqxYQR09Tapo9/i4ohmnPwliEYuKBUMCnX
XFqULRVooUsTMumkCNEmZy8l1zvl+KbAMP1bQ7+h3rKAkMZ1JsSClybGvJC/
WJiAr2di9SPZRnnx+uWBaOupJWgq2+GAYNluDWsHE6+z/batxGOEnpwWIZPE
BqdNemu5eNSVHLushlZnJAhF97b0Uy+amhjYi1E/rk7mUg+d2RRaewczYwy0
OzZU4rvGscTasfSPFLtX8zLToBNa8z4JHjHS2cZxiX5COiWDq50MG80H64UV
Ovw0L328ileHpLCYBA9gZHmjZY+3RHtGZpbdL1tblJ6zxd73/cni9rzqTU6x
XiCO3VisQsjQwg1iie1Riyi+WxiB7n9kZwQKjNpM0bDYF3bacsjm9svsjsGK
pKtDmNCPlGt3rNtEHCpEx1TCPavzai6nya5Kj4sUuBAPg6mqLhZUtFu7v6Yl
POPEYle6X2r7Ja5+/1bPb+prhLsZcgdI8j5xjgNdnN+DWMWJqon5A6XkfdbS
TpdsYXCtmK4BmflepN2gnyiwxIg5Bn+qOuRppjHz7wSkWlRMVAiFcCaHgpnh
I44uLe1l95jvmGo/BCPqTjmtJ5IspHOblsKyY6wKWlBtFK60wIaHlHDMZqLK
nxrx9HtuILctdmp7LXYeodSoPZl/KArr0v5cnRhYhSQfBtPhcd3h/5hWoML5
5f7g7Dpdvk2GTbq/eH23ONxfNPuL4QC35G3Cna/GZ5La3tMhNAaY9RqkhZf7
ZoCDMCJxQ2V/WjYtpA6g5hmZAFNxqkGYi/EHjJd/j+X1WHTeskdRLkVnYluv
gIBeP6mKEAklAje/PWG49IHqVPRH1DS2lDSLMDvLaRHQgHVj/iw47ShpTvKj
s6+gIlMfTavTIFLQCj/ldNM4s4BNRhUDURgyxg1oVREOE5XZKlON8wgo9RGF
JjBIvjWUwtmpvxhqWUm5cC7+i6BkJu1ZqezU3ogYYJVLVQFFNCfJey7qSfup
uK4ab7LksXM5fcnKqGYeo/ChbonVyMYTfc8YjDayVQ6JCoY10EMAWiPoo7xm
uvQG94TM/krLqsAE27T5MrHmBU8PXEs5ajKA3qQifNeaofGbogYT1TqLS4yH
Lo5N1HxBX4+xQnovrBgfG/JVxR7LJsfR0jKryKa38cy3ELKn3F938Jdlxnki
yj0t3Id0IurckVLCUQSzbiv42O9OUFGVtXmms5XcD659TxUWQwNLydaJFXHa
zpEVt+LV4+a5rZkwQv2r/Yq58WzUUJEILOpfSvEgypuVQHBe209rW2Zj79is
QqXLFUZEmuJImSakBqGqQ7ObqpIwfmCVeK+w/IqJlUly6gsYbkMjzKSmfq7q
x9LS2nguGJUhKVP6kntpIqfQcFXbNzX2sEpuUAXIqbAFz4zn6YZHNWqUaMkq
ErufLs8/Xp5f/9EKs6CYlBaUli4x6twfLMiXl1yrkeqDIoB7X21wU3ek3GWl
mnnBydRAr1KB966KrrLlNPjGb/R0yDlxCYbOU0wYhuTvGvFQzXapTTe9524I
FudyP7JaniFaJlJ4Gy1XqHvGbyPMW5mOmyeZGH4omvZ5Z5VErhi/MZNHCEwm
Zbuk7jjoMymC6ho4K2h0VGqIFVi+pDw5lNsmSg08XEgYWsBV+NO64ZjPabbc
lFuTOtCVTJpeKI3ZhPbtD6TBdUoINFzfQ1D41spKhpvpSvFM6yz9EhfV8q/W
TB32EqN0J/DXNdnV6iBMGtoxKtHmGa6+4MiKxI6isoPUOUu7RojAkt5lx50i
qNLAbIzi9CEdhOfbrZ4aIvZccI3XSKyv0bGG7HAFwQOqo4r7AlYGSN7OyKFc
bw8vkco2tNGmPFQcMiWetgALh17JZISUIC25/fQmxGqFWmVDKurpK47vTZIL
MP2wJuMozP0lLFJC53js03xJ/Rq3LiJkRel91jqqPCNUuLSAxpWFjsndVLdF
DK7zlKMOWFqp5zn5oTmKVNFKTkaLJ8eeNbisjdb/Q9+zJVhyYThOEdtC6p20
bNM7JVkB7zrQA5aEwBHuQhZCZyHiD8Bc6g1XU0CUEy5eCHRXK1nSfIdsEPwm
lFjuWBSi5Q+ljrIUhWd8IS00AQXWsBdKyhGnEgbFoIFvc1EQEL7dvSHMC7Ur
SXVym/RfpknHZ/ffoVB3gbbXHF9n5Zz/7yjcJ9XYCrFbYfkfpEIgdphnD/t3
8XXzNtXGR0ReSseQDobhrqnU8XE5LiP1XwuKQLwZtDaiFPPx4xB9Hz8jbMoH
u623UCXh+/lwfdSt2Fdcs79XtGY1cpAayWENulFxsSXWrZ/P1nK4P6cDEIwT
fF8UsG7acrRfnHoMnL2QhojpV62VMquBVMZUXlwlPJzGEkMZdk+uLt/tMXyR
1tO8pdwarUaOlunH0AydalBg6Vlq++TcZAqS1hnWKPDo30MtL+Im6L4Ao4uZ
79U8jjycEa+yZlQYfVaXxHWCTLLgMVsCbhZv7p4Lqc9LrAEmvlKtMqP7SyD+
bEb+SqqBQw0f3EVHfEywzDt1fYkyiAEJCcjQmzKH1YUec6k/m2ZW52u6aLt/
uLra05ofkmSl3mHgkiuiYNo73TWwiuek5EhIazdIM8qqQD+GUXa34jkbElqr
SCMcZy170e0+dJkhLQbpphM9SrdIMoemD8VkiXSeg1pcVGuNvwrJ21m5WWnW
kwbSh3FwZx4N5mLhzGVH47g44ZbcoENCf7eHXYc4LyVGD751Ep1C5jEpDaER
HbV4sLgQcjk3XHqL3/6HsR91/JGVV/TkNWBQuuawEQNPQ+9rXy3GubLZkOqw
BQ5hT7S/LEf91FnLHoSUkVUdmNyVjt2EOeuMtY71+BP1FUD16OTqE8Xt/Xw6
hh+faXH6Zzx/PAtsVSaR8v4qoQCO32+1wrlGoTRtAPtstrGr04SOB9jMxHqa
cFHq03d7oYiGNJ6h+dMNvMIbeGU3UEoyhlVeop+/zmq3usuzd2eXl2eX408f
L85P/qgV+Wt9kvsr4KJf7VOwooRg3XKbiUhpyKVpIzFO7tmBrSoC66P3U2bx
NrRTZ4lP7vzUtuuPwCp2kkWREnCgLWd7RMMfqxOHFZq5E6qOJxXALDfpMoZC
8c3HWo/EMMgQuE61lO/dYj1XDs2IvZZM+gk19GyaO7BuGy7zzmqaTiYrb/O6
KrmbFlnLcymD6NQBCQtwgotisDRYi0w8yYd2U6bw66Dv6VfJJcncX+QCtzVb
6AChBZUTKAwy5K4ImNSb4zphW7rInT7YsYL0qLk5lLTtwa/3Du3Vv9WiEu2N
Nbpqe817ypAWgNnfrj0CsOLMipZQzCqXAXykkv1xqcKew1hoMia8Wfvo6IY3
PreG125t85Qp8E60kr4cmBa6H5QMeM4FkDq7FPE4/mt8K9gSfvArHHvwAHd8
q7Uox009S3bKqsx2HnLUPHu5vz/o8B8K7lBO0/PN9N2FBNaooijJjAJaoOBe
Vui3E4vSB8H7EjTOyfZf2a2cIm4yvASzuCh6k3U0BvMB5KTsdR07P1QbLH1J
3pon3OcetgBjDLSKDw0u7nevuNVZxxa3bjr/4LrpRJeKUIKtVkLoK6LEF1sK
/aaG3lXoC7DvKepJ4aY8py0mxMkWF5VPNXggvl/YlAXcZdrzkz2bAVF1GzK9
txqquwL0yMZhxzvM9gwWftTjT/jOLGOZzhN2LT2i7ZBVy4JD0T4sfcZ+HOEz
rOxGbUCof2QjyXH8Is6qEXd+I/CcLIzgBE4Ca5gza+ed0KLXeopuycnBouqJ
pqBy2MqGdXydfajv7UrmRuGcUhFZ/Q5dz4pvcePxUJ3Wke9hKAH2rUaYuiY3
vjs1IZXURZMLOMp7hits2DmE35YMH+2GFiTScZsa0WbY3rbZ+5uKiGsub8vN
VB9fLukLgdKvK5klcW3JsHYxv06AySUYbUVNQUAUq8bVPLAOnPwqLrMqrR5U
BP7qkiiNE3aSE9Fcz0jX+Ziz3ij2WUrFgkETsYio9+5qEstOFy/DnjKkfgGr
9Ny88czLcQBrXruSNk680zEK2cBGv+f460h/itVz1V6ctc/XtzTmQHYiaUjB
zhfRTps9CrlyqNuSd0/iA7wO1ME5exiNZhNLKV82oGUK6mfvdFcUNm2B5Wy/
YW1sxf8VfNNK2b4U6xV7bj5t4L3fnkhh3jX89t0ckumcFDO3Twur4UuXeIjP
D5WtPjXVZ53m/IAaiRbBchjiTl5PnmMsLPeWED8SjodzXjUaKVViB7G0SLDk
KyUCobDThiZRl28NyhMFfLiAA9q0nAZJ8e3NzVOsnADq9hTxEWlJLc0tO40J
yHa+cpPCUKFqPZ7ej+GfI1UIRs7m7ZbVoNwbqTkWJZF3S5G23VZvgndhl2oG
9vZYhFnuTi+Zh0scPJDQM+muhUvF3qKHeMl+R+/zlVQ9LRB0p8gzwgrag25b
BxJDSOUm5VrQu9N7lyPiFHqZZsFTnoXQfQVre4fg+9SZS5GarjsPo+W8ZJI5
GeGWD1ccz7WgfqRI8elYB08qLR8uAs+MCl5sapnMpozytQij2Vp37pbyITB9
/N7S3pteerPDnvUlpvbCbMSA2LZbrgMrq7hmD4iaCj/v975oBgo7ch0nHs4o
YK1XKtD0I5abjqBRB/PhI1yeMHKeswufOVbX64psUSIdKjBCVrn2Q+nX/SI3
jTif6RppCnHrnMyhUjU3d/bul3BmwkKoFzWXfcOyXILAlUvfzHJqKK3g/Xm5
Z853rlRN0iI4Bw/2nyW73EXjJyDFZi+uSOm6ZRxik8jtdWQ87XHAYBGafInZ
YcCzVuZwdyD02XuQNTvBFkkjpndFkkiiHGtnlN/zsarX6UzdxiBhbu1P3zEf
aSeEMbmEJPQkVpg4SR4wax/JwJ6PURFy0UreHBfqK8E3IdxpRBVCkRs3Y+Rh
VvRGarZELRQ3UsXDdArB3jyYGvJkCy7yXoh1j5hpp0x7J6zOGq+HiEoWJcod
pK8Arl7qW1J/6cm2tzv0NkqY9a9kDURYbxZazP9tb+il1McKR28QxEyog03b
L9ZBtJKcH3847iAp4gqwgori+40oF/cMv8qDPADJPF5xCWQ/+UEs2kfG6IDn
GlLBxbXZP1Leh/z/RuqSBrW73+kVv9Slg1DpXRvPw3OgxSybVvn+YBDaUCbW
9KWJGkPsUIvVHcJVpRAlZptQKamoyTs9qM+1/21tzSfJe9yuh4wMC0mMTRna
5aiWExekytKaAE4ET11b50ZQTTG5ue8Irj2EGFCN+ayc1ffrliq9eMCU6wOg
Y/E2a+Z1tZYuqzUXV1I0xcOfzCWkARxlerca743qPuiw3CtIF2gF7RpupiIq
EJ3x9qSR79TurEDRwQcZCgOT4gvciHpzP5hw8UAZ9KqWZIEQ190pO01ym0zT
UG4BqWrTaJ8T1Qk1G94CiWNs1UtyguC60QCS37pZLjlOzjwWFb9d/e69vYhC
9GEa3qbb6XhZykdc4PQWh6L1FuodjVj2MdGadQ4kq2PsooNl4cLN1cy1w/po
0B5vtrO6oiXDm790ig+APeaFPkWWrDDup/YtIsws7qoNcSCA/7bA9SCqMT+S
q4vNzCvZTVsej+PuEsEh6LlU2umiPOKeJ9jmk5LvsCqBJHvDgLhaNAtYQ6Km
Wp23DmHQL0NzwHNRI6SsbX3/XJKFFaSQ4n+hiqB0zol0tDXer8yHXARMjks3
rLSsR1VjwU4KoVo3CNWvuOyZ9tbtCiYfu6Hl1KuGU4HAJmQIIrqTlRraVPWD
8K+u83+nibJ1uJ7hwzWFQ43NOE6BazaFRWPhzHHGbTMIexD4cyi0fpejDbBr
7WNc/Qwu1N2QD0KqQlrrMtY0rc3ySN7mFyWK2JKKJBP0UFOsFkGy1fRWSgGm
TIfMjKkGOUdKIR9EV0nwtnIRUPZKacmB3BzkjQkSN4kRCpGZ1USwqqU8kwV8
jv5kLusl2icGVrDPlvnYVX/U8EpnQdALzj9ZFlYUqTSibns6QSx1SQ0jDRHE
LJftpYJ3pO3NyBNyn2FHwfrM1dL5bS7wOiv+amzwJByzD/GQ7MZDixe+wK2G
aqfUI6UZ4ZHwVj83RypjwggxO58gGFpJWw6ivqeRFq1xLQUDb+KymlLwtshS
4VDwYtoJ7hLoTpIzzwTkTpGLtkJBtqeizvJNsRIjWrMECRBlSTfWV5SqEHPf
yY3KQOmG63a8zFw1z0jj5sxOV8+s37peJWTYE66bL0lFF+Lkfnx80R1Rnq7F
Bzc3/zhhEnCVsc2sBMG4Ri3iZ03rLwSxdkpb06YiwNHNLhq5jAh1gFLsFfUQ
ajki6THktEOzUb6iMluhDYoyyrQfbEf7CaazbyrgEpmspWS/4K7GS3qYlHBc
juHgpiJLdOZSmGZE51gSJ1TfRLU5DFBNuagN7oMPDPC7yzGXFcldLmiP41K3
rEDdno1J5JKGpmLiEFzoNSWZGmxNcLNz3m1hkr2CZxZDgErMGNVddUgB260b
KQSIMbOMVex1qQTE60J7dLqY4RvQFO6o74HroSHXtFfBD9Swe2xb/7dwNmvm
6kymVTXNi0y6MhG8pPrDkRYtcbUPaBwtUsHkSbtFU9hpgu6wpih7kklaWMIF
7M5q2ChsIELpfWOQa4hWoJV7IvAE6SZg3SfPDvdfoNqI4BD+DDojdu3a1ILS
U3WwEwEIP4l/WWUDtzo43N/f38FW05SSW1k5z1lWY5BFOmP/hajwUr6pppZG
ZF+hEEWOZWYyGusazxk1PLZ0bgmYS8MtjuPYKJB+M0W9UBpJGJDbufvtTcBs
qIZ/VSUUQ4dqQVtxk5TQ4Kq4nwz+FwnVIZao1gAA
</rfc> </rfc>
 End of changes. 145 change blocks. 
1689 lines changed or deleted 701 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/