<?xml version='1.0' encoding='utf-8'?> version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.5.6 -->
<?rfc sortrefs="yes"?>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-httpbis-bcp56bis-15" category="bcp" number="9205" obsoletes="3205" updates="" submissionType="IETF" category="bcp" consensus="true" xml:lang="en" symRefs="true" sortRefs="true" tocInclude="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.9.1 -->

  <front>
    <title>Building Protocols with HTTP</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-bcp56bis-15"/> name="RFC" value="9205"/>
    <seriesInfo name="BCP" value="56"/>
    <author initials="M." surname="Nottingham" fullname="Mark Nottingham">
      <organization/>
      <address>
        <postal>
          <postalLine>Prahran</postalLine>
          <postalLine>Australia</postalLine>
        </postal>
        <email>mnot@mnot.net</email>
        <uri>https://www.mnot.net/</uri>
      </address>
    </author>
    <date/>
    <date year="2022" month="June" />
    <area>Applications and Real-Time</area>
    <workgroup>HTTP</workgroup>
    <keyword>HTTP API</keyword>
    <abstract>
      <t>Applications often use HTTP as a substrate to create HTTP-based APIs. This document specifies best practices for writing specifications that use HTTP to define new application protocols. It is written primarily to guide IETF efforts to define application protocols using HTTP for deployment on the Internet, Internet but might be applicable in other situations.</t>
      <t>This document obsoletes <xref target="RFC3205" format="default"/>.</t> RFC 3205.</t>
    </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-http-wg/</eref>.</t>
      <t>Working Group information can be found at <eref target="http://httpwg.github.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/labels/bcp56bis">https://github.com/httpwg/http-extensions/labels/bcp56bis</eref>.</t>
    </note>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="default">
      <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" APIs", or just "HTTP APIs". This is done for a variety of reasons, including:</t>
      <ul spacing="normal">
        <li>familiarity by implementers, specifiers, administrators, developers developers, and users,</li> users;</li>
        <li>availability of a variety of client, server server, and proxy implementations,</li> implementations;</li>
        <li>ease of use,</li> use;</li>
        <li>availability of Web browsers,</li> browsers;</li>
        <li>reuse of existing mechanisms like authentication and encryption,</li> encryption;</li>
        <li>presence of HTTP servers and clients in target deployments, deployments; and</li>
        <li>its ability to traverse firewalls.</li>
      </ul>
      <t>These protocols are often ad hoc, intended for only deployment by one or a few servers and consumption by a limited set of clients. As a result, a body of practices and tools has arisen around defining HTTP-based APIs that favours favour these conditions.</t>
      <t>However, when such an application has multiple, separate implementations, is deployed on multiple uncoordinated servers, and is consumed by diverse clients -- as (as is often the case for HTTP APIs defined by standards efforts -- efforts), tools and practices intended for limited deployment can become unsuitable.</t>
      <t>This mismatch is largely because the API's clients and servers will implement and evolve at different paces, leading to a need for deployments with different features and versions to co-exist. coexist. As a result, the designers of HTTP-based APIs intended for such deployments need to more carefully consider how extensibility of the service will be handled and how different deployment requirements will be accommodated.</t>
      <t>More generally, an application protocol using HTTP faces a number of design decisions, including:</t>
      <ul spacing="normal">
        <li>Should it define a new URI scheme? Use new ports?</li>
        <li>Should it use standard HTTP methods and status codes, codes or define new ones?</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 browsing?</li>
        <li>How can interoperability problems and "protocol dead ends" be avoided?</li>
      </ul>
      <t>This document contains best current practices for the specification of such applications. <xref
      <t><xref target="used" format="default"/> defines when it applies; this document applies, <xref target="overview" format="default"/> surveys the properties of HTTP that are important to preserve, and <xref target="bp" format="default"/> conveys contains best practices for specifying them.</t> the specification of applications that use HTTP.</t>
      <t>It is written primarily to guide IETF efforts to define application protocols using HTTP for deployment on the Internet, Internet but might be applicable in other situations. Note that the requirements herein do not necessarily apply to the development of generic HTTP extensions.</t>
      <t>This document obsoletes <xref target="RFC3205" format="default"/>, format="default"/> to reflect the experience and developments regarding HTTP in the intervening time.</t>
      <section anchor="notational-conventions" numbered="true" toc="default">
        <name>Notational Conventions</name>
        <t>The
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 BCP&nbsp;14 <xref target="RFC2119" format="default"/> target="RFC2119"/> <xref target="RFC8174" format="default"/> target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>
      </section>
    </section>
    <section anchor="used" numbered="true" toc="default">
      <name>Is HTTP Being Used?</name>
      <t>Different applications have different goals when using HTTP. The recommendations in this document apply when a specification defines an application that:</t>
      <ul spacing="normal">
        <li>uses the transport port 80 or 443, or</li>
        <li>uses the URI scheme "http" or "https", or</li>
        <li>uses an ALPN protocol ID <xref target="RFC7301" format="default"/> that generically identifies HTTP (e.g., "http/1.1", "h2", "h3"), or</li>
        <li>makes registrations in or overall modifications to the IANA registries defined for HTTP.</li>
      </ul>
      <t>Additionally, when a specification is using HTTP, all of the requirements of the HTTP protocol suite are in force (in particular, <xref (<xref target="HTTP" format="default"/>, format="default"/> in particular but also other specifications such as the specific version of HTTP in use, use and any extensions in use).</t>
      <t>Note that this document is intended to apply to applications, not generic extensions to HTTP. Furthermore, while it is intended for IETF-specified applications, other standards organisations are encouraged to adhere to its requirements.</t>
      <section anchor="non-http-protocols" numbered="true" toc="default">
        <name>Non-HTTP Protocols</name>
        <t>An application can rely upon HTTP without meeting the criteria for using it as defined above.
	For example, an application might wish to avoid re-specifying parts of the message format, format but might change other aspects of the protocol's operation; or, operation, or it might want to use application-specific methods.</t>
        <t>Doing so brings permits more freedom to modify protocol operations, but loses at least a portion of the benefits outlined in <xref target="overview" format="default"/>, format="default"/> are lost as most HTTP implementations won't be easily adaptable to these changes, and the changes. The benefit of mindshare will also be lost.</t>
        <t>Such specifications MUST NOT <bcp14>MUST NOT</bcp14> use HTTP's URI schemes, transport ports, ALPN protocol IDs IDs, or IANA registries; rather, they are encouraged to establish their own.</t>
      </section>
    </section>
    <section anchor="overview" numbered="true" toc="default">
      <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>
      <section anchor="generic-semantics" numbered="true" toc="default">
        <name>Generic Semantics</name>
<t>Much of the value of HTTP is in its generic semantics -- that is, the protocol elements defined by HTTP are potentially applicable to every resource, resource and are not specific to a particular context. Application-specific semantics are best expressed in message content and in header fields, not status codes or methods (although the latter status codes and methods do have generic semantics that relate to application state).</t>
        <t>This generic/application-specific split between generic and application-specific semantics allows a an HTTP message to be handled by common software (e.g., HTTP servers, intermediaries, client implementations, and caches) without understanding requiring those implementations to understand the specific application. application in use. It also allows people to leverage their knowledge of HTTP semantics without specialising them for needing specialised knowledge of a particular application.</t>
        <t>Therefore, applications that use HTTP MUST NOT re-define, refine <bcp14>MUST NOT</bcp14> redefine, refine, or overlay the semantics of generic protocol elements such as methods, status codes codes, or existing header fields. Instead, they should focus their specifications on protocol elements that are specific to that application; namely application -- namely, their HTTP resources.</t>
        <t>When writing a specification, it's often tempting to specify exactly how HTTP is to be implemented, supported supported, and used. However, this can easily lead to an unintended profile of HTTP's HTTP behaviour. For example, it's common to see specifications with language like this:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
A `POST`
        <blockquote>
        <t>A POST request MUST result in a `201 Created` response.
]]></artwork> 201 (Created) response.</t>
        </blockquote>
        <t>This forms an expectation in the client that the response will always be <tt>201 Created</tt>, 201 (Created) when in fact there are a number of reasons why the status code might differ in a real deployment; for example, there might be a proxy that requires authentication, or a server-side error, or a redirection. If the client does not anticipate this, the application's deployment is brittle.</t>
        <t>See <xref target="resource" format="default"/> for more details.</t>
      </section>
      <section anchor="links" numbered="true" toc="default">
        <name>Links</name>
        <t>Another common practice is assuming that the HTTP server's name space namespace (or a portion thereof) is exclusively for the use of a single application. This effectively overlays special, application-specific semantics onto that space, space and precludes other applications from using it.</t>
        <t>As explained in <xref target="RFC8820" target="BCP190" format="default"/>, such "squatting" on a part of the URL space by a standard usurps the server's authority over its own resources, can cause deployment issues, and is therefore bad practice in standards.</t>
        <t>Instead of statically defining URI components like paths, it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that applications using HTTP define and use links <xref target="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 deployments (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 deployment across machines well.</t>
        <t>It
        <t>By using links, it also becomes possible to "mix and match" different applications on the same server, and server. The use of links also offers a natural mechanism for extensibility, versioning versioning, and capability management, since management because the document 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 the Web; when a resource's state changes, the application can change its link to it the affected links so that a fresh copy is always fetched.</t>
        <t>See <xref target="specifying-urls" format="default"/> for more details.</t>
      </section>
      <section anchor="rich-functionality" numbered="true" toc="default">
        <name>Rich Functionality</name>
        <t>HTTP offers a number of features to applications, such as:</t>
        <ul spacing="normal">
          <li>Message framing</li>
          <li>Multiplexing (in HTTP/2 <xref target="HTTP2" format="default"/> and HTTP/3 <xref target="HTTP3" format="default"/>)</li>
          <li>Integration with TLS</li>
          <li>Support for intermediaries (proxies, gateways, Content Delivery Networks)</li> content delivery networks (CDNs))</li>
          <li>Client authentication</li>
          <li>Content negotiation for format, language, and other features</li>
          <li>Caching for server scalability, latency and bandwidth reduction, and reliability</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>The ability to interact with the application easily using a Web browser</li>
        </ul>
        <t>Applications
        <t>An application that use uses HTTP are is encouraged to utilise the various features that the protocol offers, offers so that their its users receive the maximum benefit from it, those features and to allow it to so that the application can be deployed in a variety of situations. This document does not require specific features to be used, used since the appropriate design tradeoffs trade-offs are highly specific to a given situation. However, following the practices in <xref target="bp" format="default"/> is a good starting point.</t>
      </section>
    </section>
    <section anchor="bp" numbered="true" toc="default">
      <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>
      <section anchor="specifying-the-use-of-http" numbered="true" toc="default">
        <name>Specifying the Use of HTTP</name>
        <t>Specifications should use <xref target="HTTP" format="default"/> as the primary reference for HTTP; it is not necessary to reference all of the specifications 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 implementations that are not controlled by the application; for example, proxies, CDNs, firewalls firewalls, and so on. Requiring a particular version of HTTP makes it difficult to use in these situations, situations and harms interoperability. Therefore, it is NOT RECOMMENDED <bcp14>NOT RECOMMENDED</bcp14> that applications using HTTP specify a minimum version of HTTP to be used.</t>
        <t>However, if an application's deployment would benefit benefits from the use of a particular version of HTTP (for example, HTTP/2's multiplexing), this ought be noted.</t>
        <t>Applications using HTTP MUST NOT <bcp14>MUST NOT</bcp14> specify a maximum version, to preserve the protocol's ability to evolve.</t>
        <t>When specifying examples of protocol interactions, applications should document both the request and response messages, messages with complete header sections, preferably in HTTP/1.1 format <xref target="HTTP11" format="default"/>. For example:</t>
        <sourcecode type="http-message"><![CDATA[
GET /thing HTTP/1.1
Host: example.com
Accept: application/things+json
User-Agent: Foo/1.0

]]></sourcecode>
        <sourcecode type="http-message"><![CDATA[
HTTP/1.1 200 OK
Content-Type: application/things+json
Content-Length: 500
Server: Bar/2.2

[content here]
]]></sourcecode>
      </section>
      <section anchor="resource" numbered="true" toc="default">
        <name>Specifying Server Behaviour</name>
        <t>The server-side behaviours of an application are most effectively specified by defining the following protocol elements:</t>
        <ul spacing="normal">
          <li>Media types <xref target="RFC6838" format="default"/>, often based upon a format convention such as JSON <xref target="JSON" format="default"/>,</li> format="default"/>;</li>
          <li>HTTP header fields, as per <xref target="headers" format="default"/>, format="default"/>; and</li>
          <li>The behaviour of resources, as identified by link relations <xref target="WEB-LINKING" format="default"/>.</li>
        </ul>
        <t>An application can define its operation by composing these protocol elements to define a set of resources that are identified by link relations and that implement specified behaviours, including:</t>
        <ul spacing="normal">
          <li>retrieval of their resource state using GET, GET in one or more formats identified by media type;</li>
          <li>resource creation or update using POST or PUT, with an appropriately identified request content format;</li>
          <li>data processing using POST and identified request and response content format(s); and</li>
          <li>Resource deletion using DELETE.</li>
        </ul>
        <t>For example, an application might specify:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
Resources
        <blockquote>
<t>Resources linked to with the "example-widget" link relation type are
Widgets. The state of a Widget can be fetched in the
"application/example-widget+json" format, and can be updated by PUT
to the same link. Widget resources can be deleted.

The "Example-Count" deleted.</t>

<t>The Example-Count response header field on Widget representations
indicates how many Widgets are held by the sender.

The sender.</t>

<t>The "application/example-widget+json" format is a JSON [RFC8259]
format representing the state of a Widget. It contains links to
related information in the link indicated by the Link header field
value with the "example-other-info" link relation type.
]]></artwork> type.</t>
        </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 runtime data.</t>
      </section>
      <section anchor="clients" numbered="true" toc="default">
        <name>Specifying Client Behaviour</name>
        <t>An application's expectations for client behaviour ought to be closely aligned with those of Web browsers, browsers to avoid interoperability issues when they are used.</t>
        <t>One way to do this is to define it in terms of <xref target="FETCH" format="default"/>, format="default"/> since that is the abstraction that browsers use for HTTP.</t>
        <t>Some client behaviours (e.g., automatic redirect handling) and extensions (e.g., Cookies) cookies) are not required by HTTP, HTTP but nevertheless have become very common. If their use is not explicitly specified by applications using HTTP, there may be confusion and interoperability problems. In particular:</t>
        <ul
        <dl spacing="normal">
          <li>Redirect handling - Applications
          <dt>Redirect handling:</dt><dd>Applications need to specify how redirects are expected to be handled; see <xref target="redirects" format="default"/>.</li>
          <li>Cookies - Applications format="default"/>.</dd>
          <dt>Cookies:</dt><dd>Applications using HTTP should explicitly reference the Cookie specification <xref target="COOKIES" format="default"/> if they are required.</li>
          <li>Certificates - Applications required.</dd>
          <dt>Certificates:</dt><dd>Applications using HTTP should specify that TLS certificates are to be checked according to <xref section="4.3.4" sectionFormat="of" target="HTTP" format="default"/> when HTTPS is used.</li>
        </ul> used.</dd>
        </dl>
        <t>Applications using HTTP should not statically require that clients statically support HTTP features that are usually negotiated to be supported by clients. negotiated. For example, requiring that clients support responses with a certain content-coding content coding (<xref section="8.4.1" sectionFormat="comma" target="HTTP" format="default"/>) instead of negotiating for it (<xref section="12.5.3" sectionFormat="comma" target="HTTP" format="default"/>) means that otherwise conformant clients cannot interoperate with the application. Applications can encourage the implementation of such features, though.</t>
      </section>
      <section anchor="specifying-urls" numbered="true" toc="default">
        <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" target="BCP190" format="default"/> explains, parts of the URL are designed to be under the control of the owner (also known as the "authority") of that server, server to give them the flexibility in deployment.</t>
        <t>This means that in most cases, specifications for applications that use HTTP won't contain fixed application URLs or paths; while it is common practice for a specification of a single-deployment API to specify the path prefix "/app/v1" (for example), doing so in an IETF specification is inappropriate.</t>
        <t>Therefore, the specification writer needs some mechanism to allow clients to discovery discover an application's URLs. Additionally, they need to specify what which URL scheme(s) the application should be used with, with and whether to use a dedicated port, port or to reuse HTTP's port(s).</t>
        <section anchor="discovering-an-applications-urls" numbered="true" toc="default">
          <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 particular deployment, potentially including links to other relevant resources. Doing so assures ensures that the deployment is as flexible as possible (potentially spanning multiple servers), allows evolution, and also gives the application the opportunity to tailor the 'discovery document' "discovery document" to the client.</t>
          <t>There are a few common patterns for discovering that initial URL.</t>
          <t>The most straightforward mechanism for URL discovery is to configure the client with (or otherwise convey to it) a full URL. This might be done in a configuration document, document or through another discovery mechanism.</t>
          <t>However, if the client only knows the server's hostname and the identity of the application, there needs to be some way to derive the initial URL from that information.</t>
          <t>An application cannot define a fixed prefix for its URL paths; see <xref target="RFC8820" target="BCP190" format="default"/>. Instead, a specification for such an application can use one of the following strategies:</t>
          <ul spacing="normal">
            <li>Register a Well-Known 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 target="URI-TEMPLATE" format="default"/> or similar mechanism for generating a URL for an entry point. For example, this might be done in a configuration document or other artefact.</li>
          </ul>
          <t>Once the discovery document is located, it can be fetched, cached for later reuse (if allowed by its metadata), and used to locate other resources that are relevant to the application, application using full URIs or URL Templates.</t>
          <t>In some cases, an application may not wish to use such a discovery document; document -- for example, when communication is very brief, brief or when the latency concerns of doing so precludes preclude the use of a discovery document. These situations can be addressed by placing all of the application's resources under a well-known location.</t>
        </section>
        <section anchor="scheme" numbered="true" toc="default">
          <name>Considering URI Schemes</name>
          <t>Applications that use HTTP will typically employ the "http" and/or "https" URI schemes. "https" is RECOMMENDED <bcp14>RECOMMENDED</bcp14> to provide authentication, integrity integrity, and confidentiality, as well as to mitigate pervasive monitoring attacks <xref target="RFC7258" format="default"/>.</t>
          <t>However, application-specific schemes can also be defined. When defining an a URI scheme for an application using HTTP, there are a number of tradeoffs trade-offs and caveats to keep in mind:</t>
          <ul spacing="normal">
            <li>Unmodified Web browsers will not support the new scheme. While it is possible to register new URI schemes with Web browsers (e.g. (e.g., registerProtocolHandler() in <xref target="HTML" format="default"/>, as well as several proprietary approaches), support for these mechanisms is not shared by all browsers, and their capabilities vary.</li>
    <li>Existing non-browser clients, intermediaries, servers servers, and associated software will not recognise the new scheme.  For example, a client library might fail to dispatch the request; request, a cache might refuse to store the response, and a proxy might fail to forward the request.</li>
            <li>Because URLs commonly occur in HTTP artefacts commonly, and are often being generated automatically (e.g., in the <tt>Location</tt> Location response header field), it can be difficult to assure ensure that the new scheme is used consistently.</li>
            <li>The resources identified by the new scheme will still be available using "http" and/or "https" URLs. Those URLs can "leak" into use, which can present security and operability issues. For example, using a new scheme to assure ensure 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>HTTP-specific features such as cookies <xref target="COOKIES" format="default"/>, authentication <xref target="HTTP" format="default"/>, caching <xref target="HTTP-CACHING" format="default"/>, HSTS HTTP Strict Transport Security (HSTS) <xref target="RFC6797" format="default"/>, and CORS Cross-Origin Resource Sharing (CORS) <xref target="FETCH" format="default"/> might or might not work correctly, depending on how they are defined and implemented. Generally, they are designed 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>
          </ul>
          <t>See <xref target="RFC7595" format="default"/> for more information about minting new URI schemes.</t>
        </section>
        <section anchor="transport-ports" anchor="choosing-transport-ports" numbered="true" toc="default">
          <name>Transport
          <name>Choosing Transport Ports</name>
          <t>Applications can use the applicable default port (80 for HTTP, 443 for HTTPS), or they can be deployed upon other ports. This decision can be made at deployment time, 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 authority of all URLs for that resource; the only mechanism for changing a default port 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 operability concerns (as some networks might block or otherwise interfere with it). Privacy implications (including those stemming from this distinguishability) should be documented in Security Considerations.</t>
          <t>See <xref target="RFC7605" format="default"/> for further guidance.</t>
        </section>
      </section>
      <section anchor="using-http-methods" numbered="true" toc="default">
        <name>Using HTTP Methods</name>
        <t>Applications that use HTTP MUST <bcp14>MUST</bcp14> confine themselves to 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 HTTP "HTTP Method Registry Registry" with IETF Review (see <xref target="HTTP" format="default"/>), format="default"/>) and are also required to be generic. That means that they need to be potentially applicable to all resources, not just those of one application.</t>
        <t>While historically some applications (e.g., <xref target="RFC4791" format="default"/>) have defined non-generic application-specific methods, <xref target="HTTP" format="default"/> now forbids this.</t>
        <t>When authors believe that a new method is required, they are encouraged to engage with the HTTP community early (e.g., on the ietf-http-wg@w3.org <eref target="mailto:ietf-http-wg@w3.org" brackets="angle"/> mailing list), list) and document their proposal as a separate HTTP extension, extension rather than as part of an application's specification.</t>
        <section anchor="get" numbered="true" toc="default">
          <name>GET</name>
          <t>GET is the most common and useful HTTP method; its retrieval semantics allow caching, caching and side-effect free linking and underlies underlie many of the benefits of using HTTP.</t>
          <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 cached, improving the efficiency of an often expensive process. In some cases, however, GET might be unwieldy for expressing queries, queries because of the limited syntax of the URI; in particular, if binary data forms part of the query terms, it 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 larger query terms, terms or ones which those that need to sustain a high rate of requests. Additionally, some HTTP implementations limit the size of URLs they support -- support, although modern HTTP software has much more generous limits than previously (typically, considerably more than 8000 octets, as required by <xref target="HTTP" format="default"/>).</t>
         <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 and URL length limits in implementations. However, in doing so so, it should be noted 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 require support for POST queries ought to consider allowing both methods.</t>
          <t>Processing of GET requests should not change application the application's state or have other side effects that might be significant to the client, client since implementations can and do retry HTTP GET requests that fail, and fail. Furthermore, some GET requests protected by TLS Early Data early data might be vulnerable to replay attacks (see <xref target="RFC8470" format="default"/>). Note that this does not include logging and similar functions; see <xref section="9.2.1" sectionFormat="comma" target="HTTP" format="default"/>.</t>
          <t>Finally, note that while the generic HTTP syntax allows a GET request message to contain content, the purpose is to allow message parsers to be generic; as per <xref section="9.3.1" sectionFormat="comma" target="HTTP" format="default"/>, content on in a GET is not recommended, has no meaning, and will be either ignored or rejected by generic HTTP software (such as intermediaries, caches, servers, and client libraries).</t>
        </section>
        <section anchor="options" numbered="true" toc="default">
          <name>OPTIONS</name>
          <t>The OPTIONS method was defined for metadata retrieval, retrieval and is used both by WebDAV Web Distributed Authoring and Versioning (WebDAV) <xref target="RFC4918" format="default"/> and CORS <xref target="FETCH" format="default"/>. Because HTTP-based APIs often need to retrieve metadata about resources, it is often considered for their use.</t>
          <t>However, OPTIONS does have significant limitations:</t>
          <ul spacing="normal">
            <li>It isn't possible to link to the metadata with a simple URL, URL because OPTIONS is not the default method.</li>
            <li>OPTIONS responses are not cacheable, cacheable because HTTP caches operate on representations of the resource (i.e., GET and HEAD). If OPTIONS responses are cached separately, their interaction interactions with the HTTP cache expiry, secondary keys keys, and other mechanisms needs need to be considered.</li>
            <li>OPTIONS is "chatty" - always separating -- requesting metadata out into a separate request separately increases the number of requests needed to interact with the application.</li>
            <li>Implementation support for OPTIONS is not universal; some servers do not expose the ability to respond to OPTIONS requests without significant effort.</li>
          </ul>
          <t>Instead of OPTIONS, one of these alternative approaches might be more appropriate:</t>
          <ul spacing="normal">
            <li>For server-wide metadata, create a well-known URI <xref target="WELL-KNOWN-URI" format="default"/>, format="default"/> or use an already existing one if appropriate (e.g., HostMeta host-meta <xref target="RFC6415" format="default"/>).</li>
            <li>For metadata about a specific resource, create a separate resource and link to it using a Link response header field or a link serialised into the response's content. See <xref target="WEB-LINKING" format="default"/>. Note that 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>
        </section>
      </section>
      <section anchor="using-http-status-codes" numbered="true" toc="default">
        <name>Using HTTP Status Codes</name>
        <t>HTTP status codes convey semantics both for the benefit of generic HTTP components -- such as caches, intermediaries, and clients -- and applications themselves. However, applications can encounter a number of pitfalls in their use.</t>
        <t>First, status codes are often generated by components other than the application itself. This can happen, for example, when network errors are encountered, encountered; when a captive portal, proxy proxy, or Content Delivery Network content delivery network is present, present; or when a server is overloaded, overloaded or it thinks it is under attack. They can even be generated by generic client software when certain error conditions are encountered. As a result, if an application assigns specific semantics to one of these status codes, a client can be misled about its state, state because the status code was generated by a generic component, not the application itself.</t>
        <t>Furthermore, mapping application errors to individual HTTP status codes one-to-one often leads to a situation where the finite space of applicable HTTP status codes is exhausted. This, in turn, leads to a number of bad practices -- including minting new, application-specific status codes, codes or using existing status codes even though the link between their semantics and the application's is tenuous at best.</t>
        <t>Instead, applications using HTTP should define their errors to use the most applicable status code, making generous use of the general status codes (200, 400 400, and 500) when in doubt. Importantly, they should not specify a one-to-one relationship between status codes and application errors, thereby avoiding the exhaustion issue outlined above.</t>
        <t>To distinguish between multiple error conditions that are mapped to the same status code, code and to avoid the misattribution issue outlined above, applications using HTTP should convey finer-grained error information in the response's message content and/or header fields. <xref target="PROBLEM-DETAILS" format="default"/> provides one way to do so.</t>
        <t>Because the set of registered HTTP status codes can expand, applications using HTTP should explicitly point out that clients ought to be able to handle all applicable status codes gracefully (i.e., falling back to the generic <tt>n00</tt> n00 semantics of a given status code; e.g., <tt>499</tt> 499 can be safely handled as <tt>400</tt> 400 (Bad Request) by clients that don't recognise it). This is preferable to creating a "laundry list" of potential status codes, codes since such a list won't be complete in the foreseeable future.</t>
        <t>Applications using HTTP MUST NOT <bcp14>MUST NOT</bcp14> re-specify the semantics of HTTP status codes, even if it is only by copying their definition. It is NOT RECOMMENDED <bcp14>NOT RECOMMENDED</bcp14> they require specific reason phrases to be used; the reason phrase has no function in HTTP, is not guaranteed to be preserved by implementations, and is not carried at all in the HTTP/2 <contact fullname="HTTP2"/> <xref target="HTTP2" format="default"/> message format.</t>
        <t>Applications MUST <bcp14>MUST</bcp14> only use registered HTTP status codes. As with methods, new HTTP status codes are rare, rare and required (by <xref target="HTTP" format="default"/>) to be registered with IETF Review. Similarly, HTTP status codes are generic; they are required (by <xref target="HTTP" format="default"/>) to be potentially applicable to all resources, not just to those of one application.</t>
        <t>When authors believe that a new status code is required, they are encouraged to engage with the HTTP community early (e.g., on the ietf-http-wg@w3.org <eref target="mailto:ietf-http-wg@w3.org" brackets="angle"/> mailing list), list) and document their proposal as a separate HTTP extension, rather than as part of an application's specification.</t>
        <section anchor="redirects" numbered="true" toc="default">
          <name>Redirection</name>
          <t>The 3xx series of status codes specified in <xref section="15.4" sectionFormat="of" target="HTTP" format="default"/> direct directs the user agent to another resource to satisfy the request. The most common of these are 301, 302, 307 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 differ:</t>
          <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 temporary ones cannot. Note that this has no effect on HTTP caching; it is completely separate.</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 and 302; therefore, 308 and 307 were created to allow redirection without changing the method.</li>
          </ul>
          <t>This table summarises their relationships:</t>
          <table align="center">
            <thead>
              <tr>
                <th align="left">&nbsp;</th>
                <th align="left">Permanent</th>
                <th align="left">Temporary</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left">Allows changing change of the request method from POST to GET</td>
                <td align="left">301</td>
                <td align="left">302</td>
              </tr>
              <tr>
                <td align="left">Does not allow changing change of the request method</td>
                <td align="left">308</td>
                <td align="left">307</td>
              </tr>
            </tbody>
          </table>
          <t>The 303 See Other (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>As noted in <xref target="HTTP" format="default"/>, a user agent is allowed to automatically follow a 3xx redirect that has a Location response header field, even if they don't understand the semantics of the specific status code. However, they aren't required to do so; therefore, if an application using HTTP desires redirects to be automatically followed, it needs to explicitly specify the circumstances when this is required.</t>
          <t>Redirects can be cached (when appropriate cache directives are present), but beyond that that, they are not 'sticky' "sticky" -- i.e., redirection of a URI will not result in the client assuming that similar URIs (e.g., with different query parameters) will also be redirected.</t>
          <t>Applications using HTTP are encouraged to specify that 301 and 302 responses change the subsequent request method from POST (but no other method) to GET, GET to be compatible with browsers.
Generally, when a redirected request is made, its header fields are copied from the original request's. request. However, they can be modified by various mechanisms; e.g., sent Authorization (<xref section="11" sectionFormat="comma" target="HTTP" format="default"/>) and Cookie (<xref target="COOKIES" format="default"/>) header fields will change if the origin (and sometimes path) of the request changes. An application using HTTP should specify if any request header fields that it defines need to be modified or removed upon a redirect; however, this behaviour cannot be relied upon, upon since a generic client (like a browser) will be unaware of such requirements.</t>
        </section>
      </section>
      <section anchor="headers" numbered="true" toc="default">
        <name>Specifying HTTP Header Fields</name>
        <t>Applications often define new HTTP header fields. Typically, using HTTP header fields is appropriate in a few different situations:</t>
        <ul spacing="normal">
          <li>The field is useful to intermediaries (who often wish to avoid parsing message content), and/or</li>
          <li>The field is useful to generic HTTP software (e.g., clients, servers), 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>
        </ul>
        <t>When the conditions above are not met, it is usually better to convey application-specific information in other places; places -- e.g., the message content or the URL query string.</t>
        <t>New header fields MUST <bcp14>MUST</bcp14> be registered, as per <xref section="16.3" sectionFormat="of" target="HTTP" format="default"/>.</t>
        <t>See <xref section="16.3.2" sectionFormat="of" target="HTTP" format="default"/> for guidelines to consider when minting new header fields. <xref target="STRUCTURED-FIELDS" format="default"/> provides a common structure for new header fields, fields and avoids many issues in their parsing and handling; it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that new header fields use it.</t>
        <t>It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that header field names be short (even when field compression is used, there is an overhead) but appropriately specific. In particular, if a header field is specific to an application, an identifier for that application can form a prefix to the header field name, separated by a "-".</t> hyphen.</t>
        <t>For example, if the "example" application needs to create three header fields, they might be called "example-foo", "example-bar" "example-bar", and "example-baz". Note that the primary motivation here is to avoid consuming more generic field names, not to reserve a portion of the namespace for the application; see <xref target="RFC6648" format="default"/> for related considerations.</t>
        <t>The semantics of existing HTTP header fields MUST NOT <bcp14>MUST NOT</bcp14> be re-defined redefined without updating their registration or defining an extension to them (if allowed). For example, an application using HTTP cannot specify that the <tt>Location</tt> Location header field has a special meaning in a certain context.</t>
        <t>See <xref target="caching" format="default"/> for the interaction between header fields and HTTP caching; in particular, request header fields that are used to "select" choose (per <xref section="4.1" sectionFormat="of" target="HTTP-CACHING" format="default"/>) a response have impact there, there and need to be carefully considered.</t>
        <t>See <xref target="state" format="default"/> for considerations regarding header fields that carry application state (e.g., Cookie).</t>
      </section>
      <section anchor="content" numbered="true" toc="default">
        <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 Concise Binary Object Representation (CBOR) <xref target="RFC8949" format="default"/>. Best practices for their use are out of scope for this document.</t>
        <t>Applications should register distinct media types for each format they define; this makes it possible to identify them unambiguously and negotiate for their use. See <xref target="RFC6838" format="default"/> for more information.</t>
      </section>
      <section anchor="caching" numbered="true" toc="default">
        <name>Leveraging HTTP Caching</name>
        <t>HTTP caching <xref target="HTTP-CACHING" format="default"/> is one of the primary benefits of using HTTP for applications; it provides scalability, reduces latency latency, and improves reliability. Furthermore, HTTP caches are readily available in browsers and other clients, networks as forward and reverse proxies, Content Delivery Networks content delivery networks, and as part of server software.</t>
        <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, responses to preserve correct behaviour when one is interposed (whether in the network, server, client, or intervening infrastructure).</t>
        <section anchor="freshness" numbered="true" toc="default">
          <name>Freshness</name>
          <t>Assigning even a short freshness lifetime (<xref section="4.2" sectionFormat="comma" target="HTTP-CACHING" format="default"/>) -- e.g., 5 seconds -- allows a response to be reused to satisfy multiple clients, clients and/or a single client making the same request repeatedly. In general, if it is safe to reuse something, consider assigning a freshness lifetime.</t>
          <t>The most common method for specifying freshness is the max-age response directive (<xref section="5.2.2.1" sectionFormat="comma" target="HTTP-CACHING" format="default"/>). The Expires header field (<xref section="5.3" sectionFormat="comma" target="HTTP-CACHING" format="default"/>) can also be used, but it is not necessary; all modern cache implementations support Cache-Control, the Cache-Control header field, and specifying freshness as a delta is usually more convenient and less error-prone.</t>
          <t>It is not necessary to add the "public" public response directive (<xref section="5.2.2.9" sectionFormat="comma" target="HTTP-CACHING" format="default"/>) to cache most responses; it is only necessary when it's desirable to store an authenticated response, or when the status code isn't understood by the cache and there isn't explicit freshness information available.</t>
          <t>In some situations, responses without explicit cache freshness directives will be stored and served using a heuristic freshness lifetime; see <xref section="4.2.2" sectionFormat="comma" target="HTTP-CACHING" format="default"/>. As the heuristic is not under the control of the application, it is generally preferable to set an explicit freshness lifetime, lifetime or make the response explicitly uncacheable.</t>
          <t>If caching of a response is not desired, the appropriate cache response directive is "Cache-Control: no-store". no-store. Other directives are not necessary, and no-store only need needs to be sent in situations where the response might be cached; see <xref section="3" sectionFormat="comma" target="HTTP-CACHING" format="default"/>. Note that "Cache-Control: no-cache" the no-cache directive allows a response to be stored, just not reused by a cache without validation; it does not prevent caching (despite its name).</t>
          <t>For example, this response cannot be stored or reused by a cache:</t>
          <sourcecode type="http-message"><![CDATA[
HTTP/1.1 200 OK
Content-Type: application/example+xml
Cache-Control: no-store

[content]
]]></sourcecode>
        </section>
        <section anchor="stale-responses" numbered="true" toc="default">
          <name>Stale Responses</name>
          <t>Authors should understand that stale responses (e.g., with "Cache-Control: max-age=0") Cache-Control: max-age=0) can be reused by caches when disconnected from the origin server; this can be useful for handling network issues.</t>
          <t>If doing so is not suitable for a given response, the origin should use "Cache-Control: must-revalidate". send the must-revalidate cache directive. See <xref section="4.2.4" sectionFormat="of" target="HTTP-CACHING" format="default"/>, format="default"/> and also <xref target="RFC5861" format="default"/> for additional controls over stale content.</t>
          <t>Stale responses can be refreshed by assigning a validator, saving both transfer bandwidth and latency for large responses; see <xref section="13" sectionFormat="of" target="HTTP" format="default"/>.</t>
        </section>
        <section anchor="caching-app-semantics" numbered="true" toc="default">
          <name>Caching and Application Semantics</name>
          <t>When an application has a need to express a lifetime that's separate 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 relationship between HTTP caching and that lifetime needs to be carefully considered, considered since the response will be used as long as it is considered fresh.</t>
          <t>In particular, application authors need to consider how responses that are not freshly obtained from the origin server should be handled; if they have a concept like a validity period, this will need to be calculated considering the age of the response (see <xref section="4.2.3" sectionFormat="comma" target="HTTP-CACHING" format="default"/>).</t>
          <t>One way to address this is to explicitly specify that responses need to be fresh upon use.</t>
        </section>
        <section anchor="varying-content-based-upon-the-request" numbered="true" toc="default">
          <name>Varying Content Based Upon the Request</name>
          <t>If an application uses a request header field to change the response's header fields or content, authors should point out that this has implications for caching; in general, such resources need to either make their responses uncacheable (e.g., with the "no-store" cache-control no-store cache directive defined in <xref section="5.2.2.5" sectionFormat="comma" target="HTTP-CACHING" format="default"/>) or send the Vary response header field (<xref section="12.5.5" sectionFormat="comma" target="HTTP" format="default"/>) on all responses from that resource (including the "default" response).</t>
          <t>For example, this response:</t>
          <sourcecode type="http-message"><![CDATA[
HTTP/1.1 200 OK
Content-Type: application/example+xml
Cache-Control: max-age=60
ETag: "sa0f8wf20fs0f"
Vary: Accept-Encoding

[content]
]]></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 header field.</t>
        </section>
      </section>
      <section anchor="state" numbered="true" toc="default">
        <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 contextualise requests.</t>
        <t>When used, it is important to carefully specify the scoping and use of cookies; if the application exposes sensitive data or capabilities (e.g., by acting as an ambient authority), exploits are possible. Mitigations include using a request-specific token to assure ensure the intent of the client.</t>
      </section>
      <section anchor="multiplex" numbered="true" toc="default">
        <name>Making Multiple Requests</name>
        <t>Clients often need to send multiple requests to perform a task.</t>
        <t>In HTTP/1 <xref target="HTTP11" format="default"/>, parallel requests are most often supported by opening multiple connections. Application performance can be impacted when too many simultaneous connections are used, used because connections' congestion control will not be coordinated. Furthermore, it can be difficult for applications to decide when to issue and which connection to use for a given request, further impacting performance.</t>
        <t>HTTP/2 <xref target="HTTP2" format="default"/> and HTTP/3 <xref target="HTTP3" format="default"/> offer multiplexing to applications, removing the need to use multiple connections. However, application performance can still be significantly affected by how the server chooses to prioritize responses. Depending on the application, it might be best for the server to determine the priority of responses, responses or for the client to hint its priorities to the server (see, e.g., <xref target="HTTP-PRIORITY" format="default"/>).</t>
        <t>In all versions of HTTP, requests are made independently -- you can't rely on the relative order of two requests to guarantee their processing order. This is because they might be sent over a multiplexed protocol by an intermediary, intermediary or sent to different origin servers, or the server might even perform processing in a different order. If two requests need strict ordering, the only reliable way to assure ensure the outcome is to issue the second request when the final response to the first has begun.</t>
        <t>Applications MUST NOT <bcp14>MUST NOT</bcp14> make assumptions about the relationship between separate requests on a single transport connection; doing so breaks many of the assumptions of HTTP as a stateless protocol, protocol and will cause problems in interoperability, security, operability operability, and evolution.</t>
      </section>
      <section anchor="client-auth" numbered="true" toc="default">
        <name>Client Authentication</name>
        <t>Applications can use HTTP authentication <xref (<xref section="11" sectionFormat="of" target="HTTP" format="default"/> format="default"/>) to identify clients. As per Per <xref target="RFC7617" format="default"/>, the Basic authentication scheme is not suitable for protecting sensitive or valuable information unless the channel is secure (e.g., using the "HTTPS" "https" URI scheme). Likewise, <xref target="RFC7616" format="default"/> requires the Digest authentication scheme to be used over a secure channel.</t>
        <t>With HTTPS, clients might also be authenticated using certificates <xref target="RFC8446" format="default"/>, but note that such authentication is intrinsically scoped to the underlying transport connection. As a result, a client has no way of knowing whether the authenticated status was used in preparing the response (though "Vary: *" Vary: * and/or "Cache-Control: private" the private cache directive can provide a partial indication), and the only way to obtain a specifically unauthenticated response is to open a new connection.</t>
        <t>When used, it is important to carefully specify the scoping and use of authentication; if the application exposes sensitive data or capabilities (e.g., by acting as an ambient authority; see <xref section="8.3" sectionFormat="of" target="RFC6454" format="default"/>), exploits are possible. Mitigations include using a request-specific token to assure ensure the intent of the client.</t>
      </section>
      <section anchor="browser" numbered="true" toc="default">
        <name>Co-Existing
        <name>Coexisting with Web Browsing</name>
        <t>Even if there is not an intent for an application to be used with a Web browser, its resources will remain available to browsers and other HTTP clients. This means that all such applications that use HTTP need to consider how browsers will interact with them, particularly regarding security.</t>
        <t>For example, if an application's state can be changed using a POST request, a Web browser can easily be coaxed into cross-site request forgery (CSRF) from arbitrary Web sites.</t>
        <t>Or, if an attacker gains control of content returned from the application's resources (for example, part of the request is reflected in the response, or the response contains external information that the attacker can change), they 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 the application as a Web application, and to follow best practices for their secure development.</t>
        <t>A complete enumeration of such practices is out of scope for this document, but some considerations include:</t>
        <ul spacing="normal">
          <li>Using an application-specific media type in the Content-Type header field, and requiring clients to fail if it is not used.</li>
          <li>Using X-Content-Type-Options: nosniff <xref target="FETCH" format="default"/> to assure ensure that content under attacker control can't be coaxed into a form that is interpreted as active content by a Web browser.</li>
          <li>Using Content-Security-Policy <xref target="CSP" format="default"/> 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 mitigating Cross-Site Scripting XSS attacks.</li>
          <li>Using Referrer-Policy <xref target="REFERRER-POLICY" format="default"/> 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 ensure that cookies are not exposed to browser scripting languages <xref target="COOKIES" format="default"/>.</li>
          <li>Avoiding use of compression on any sensitive information (e.g., authentication tokens, passwords), as the scripting environment offered by Web browsers allows an attacker to repeatedly probe the compression space; if the attacker has access to the network path of the communication, they can use this capability to recover that information.</li>
        </ul>
        <t>Depending on how they are intended to be deployed, specifications for applications using HTTP might require the use of these mechanisms in specific ways, ways or might merely point them out in Security Considerations.</t>
        <t>An example of a an HTTP response from an application that does not intend for its content to be treated as active by browsers might look like this:</t>
        <sourcecode type="http-message"><![CDATA[
HTTP/1.1 200 OK
Content-Type: application/example+json
X-Content-Type-Options: nosniff
Content-Security-Policy: default-src 'none'
Cache-Control: max-age=3600
Referrer-Policy: no-referrer

[content]
]]></sourcecode>
        <t>If an application has browser compatibility as a goal, client interaction ought to be defined in terms of <xref target="FETCH" format="default"/>, format="default"/> since that is the abstraction that browsers use for HTTP; it enforces many of these best practices.</t>
      </section>
      <section anchor="other-apps" numbered="true" toc="default">
        <name>Maintaining Application Boundaries</name>
        <t>Because many HTTP capabilities are scoped to the origin <xref target="RFC6454" format="default"/>, applications also need to consider how deployments might interact with other applications (including Web browsing) on that use the same origin.</t> origin server.</t>
        <t>For example, if Cookies cookies <xref target="COOKIES" format="default"/> are used to carry application state, they will be sent with all requests to the origin by default (unless scoped by path), and the application might receive cookies from other applications on the origin. origin server. This can lead to security issues, issues as well as collision in cookie names.</t>
        <t>One solution to these issues is to require a dedicated hostname for the application, application so that it has a unique origin. However, it is often desirable to allow multiple applications to be deployed on a single hostname; doing so provides the most deployment flexibility and enables them to be "mixed" together (See (see <xref target="RFC8820" target="BCP190" format="default"/> for details). Therefore, details).</t>
        <t>Therefore, applications using HTTP should strive to allow multiple applications on an origin.</t>
        <t>To enable this, origin. Specifically, when specifying the use of Cookies, cookies, HTTP authentication realms <xref target="HTTP" format="default"/>, or other origin-wide HTTP mechanisms, applications using HTTP should not mandate the use of a particular name, name but instead let deployments configure them. Consideration should be given to scoping them to part of the origin, using their specified mechanisms for doing so.</t>
        <t>Modern Web browsers constrain the ability of content from one origin to access resources from another, another to avoid leaking private information. As a result, applications that wish to expose cross-origin data to browsers will need to implement the CORS protocol; see <xref target="FETCH" format="default"/>.</t>
      </section>
      <section anchor="server-push" numbered="true" toc="default">
        <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 application semantics (e.g., "fanout" and publish/subscribe), a few caveats should be noted:</t>
        <ul spacing="normal">
          <li>Server push is hop-by-hop; hop by hop; that is, it is not automatically forwarded by intermediaries. As a result, it might not work easily (or at all) with proxies, reverse proxies, and Content Delivery Networks.</li> content delivery networks.</li>
          <li>Server push can have a negative performance impact on HTTP when used incorrectly; in particular, incorrectly, particularly if there is contention with resources that have actually been requested by the client.</li>
          <li>Server push is implemented differently in different clients, especially regarding interaction with HTTP caching, and capabilities might vary.</li>
          <li>APIs for server push are currently unavailable in some implementations, implementations and vary widely in others. In particular, there is no current browser API for it.</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, HTTP and therefore might not be supported by future versions of the protocol.</li>
        </ul>
        <t>Applications wishing to optimise cases where the client can perform work related to requests before the full response is available (e.g., fetching links 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 requirements regarding authority in <xref section="8.4" sectionFormat="comma" target="HTTP2" format="default"/>, format="default"/> to avoid cross-origin push attacks.</t>
      </section>
      <section anchor="versioning" numbered="true" toc="default">
        <name>Allowing Versioning and Evolution</name>
        <t>It's often necessary to introduce new features into application protocols, protocols and change existing ones.</t>
        <t>In HTTP, backwards-incompatible changes can be made using mechanisms such as:</t>
        <ul spacing="normal">
          <li>Using a distinct link relation type <xref target="WEB-LINKING" format="default"/> to identify a URL for a resource that implements 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>
        </ul>
      </section>
    </section>
    <section anchor="iana-considerations" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document has no requirements for IANA.</t> IANA actions.</t>
    </section>
    <section anchor="security-considerations" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>Applications using HTTP are subject to the security considerations of HTTP itself and any extensions used; <xref target="HTTP" format="default"/>, <xref target="HTTP-CACHING" format="default"/>, and <xref target="WEB-LINKING" format="default"/> are often relevant, amongst others.</t>
      <t><xref target="scheme" format="default"/> recommends support for 'https' URLs, "https" URLs and discourages the use of 'http' URLs, "http" URLs to provide authentication, integrity integrity, and confidentiality, as well as to mitigate pervasive monitoring attacks. Many applications using HTTP perform authentication and authorization with bearer tokens (e.g., in session cookies). If the transport is unencrypted, an attacker that can eavesdrop upon or modify HTTP communications can often escalate their privilege 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="state" format="default"/> discusses the impact of using stateful mechanisms in the protocol as ambient authority, authority and suggests a mitigation.</t>
      <t><xref target="browser" format="default"/> highlights the implications of Web browsers' capabilities on applications that use HTTP.</t>
      <t><xref target="other-apps" format="default"/> discusses the issues that arise when applications are deployed on the same origin as Web sites websites (and other applications).</t>
      <t><xref target="server-push" format="default"/> highlights risks of using HTTP/2 server push in a manner other than that specified.</t>
      <t>Applications that use HTTP in a manner that involves modification of implementations -- for example, requiring support for a new URI scheme, scheme or a non-standard method -- risk having those implementations "fork" from their parent HTTP implementations, with the possible result that they do not benefit from patches and other security improvements incorporated upstream.</t>
      <section anchor="privacy-considerations" numbered="true" toc="default">
        <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 example, names and other user-entered data), data) and "on the wire" (which is one of the reasons https "https" is recommended in <xref target="scheme" format="default"/>), other information can be gathered through less obvious means -- often by connecting activities of a user over time.</t>
        <t>This includes session information, tracking the client through fingerprinting, 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 stateful mechanisms. Applications are advised to avoid using session mechanisms unless they are unavoidable or necessary for operation, in which case these risks needs 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 behaviours to connect disparate requests and connections. For example, the User-Agent request header field conveys specific information about the implementation; the Accept-Language request header field conveys the users' preferred language. In combination, 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 specify that clients should only emit the information they need to function in requests.</t>
        <t>Finally, if an application exposes the ability to execute code, great care needs to be taken, taken since any ability to observe its environment can be used as an opportunity to both fingerprint the client and to obtain and manipulate private data (including session information). For example, access to high-resolution timers (even indirectly) can be used to profile the underlying hardware, creating a unique identifier for the system. Applications are advised to avoid allowing the use of mobile code where possible; when it cannot be avoided, the resulting system's security properties need be carefully scrutinised.</t>
      </section>
    </section>
  </middle>
  <back>
    <displayreference target="HTTP11" to="HTTP/1.1"/>
    <displayreference target="HTTP2" to="HTTP/2"/>
    <displayreference target="HTTP3" to="HTTP/3"/>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="HTTP"> anchor="HTTP" target="https://www.rfc-editor.org/info/rfc9110">
          <front>
            <title>HTTP Semantics</title>
            <author initials="R" surname="Fielding" fullname="Roy T. Fielding">
              <organization>Adobe</organization> Fielding" role="editor">
              <organization />
            </author>
            <author initials="M" surname="Nottingham" fullname="Mark Nottingham">
              <organization>Fastly</organization> Nottingham" role="editor">
             <organization />
           </author>
           <author initials="J" surname="Reschke" fullname="Julian Reschke">
              <organization>greenbytes GmbH</organization> Reschke" role="editor">
             <organization />
           </author>
           <date day="18" month="August" year="2021"/>
            <abstract>
              <t>   The Hypertext Transfer Protocol (HTTP) is a stateless application-
   level protocol for distributed, collaborative, hypertext information
   systems.  This document describes the overall architecture of HTTP,
   establishes common terminology, and defines aspects of the protocol
   that are shared by all versions.  In this definition are core
   protocol elements, extensibility mechanisms, and the "http" and
   "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> year="2022" month="June" />
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-semantics-18"/> name="STD" value="97"/>
          <seriesInfo name="RFC" value="9110"/>
          <seriesInfo name="DOI" value="10.17487/RFC9110"/>
        </reference>
        <reference anchor="HTTP-CACHING"> anchor="HTTP-CACHING" target="https://www.rfc-editor.org/info/rfc9111">
          <front>
            <title>HTTP Caching</title>
            <author initials="R" surname="Fielding" fullname="Roy T. Fielding">
              <organization>Adobe</organization> Fielding" role="editor">
              <organization />
            </author>
            <author initials="M" surname="Nottingham" fullname="Mark Nottingham">
              <organization>Fastly</organization> Nottingham" role="editor">
             <organization />
           </author>
           <author initials="J" surname="Reschke" fullname="Julian Reschke">
              <organization>greenbytes GmbH</organization> Reschke" role="editor">
             <organization />
           </author>
           <date day="18" month="August" year="2021"/>
            <abstract>
              <t>   The Hypertext Transfer Protocol (HTTP) is a stateless application-
   level protocol for distributed, collaborative, hypertext information
   systems.  This document defines HTTP caches and the associated header
   fields that control cache behavior or indicate cacheable response
   messages.

   This document obsoletes RFC 7234.

              </t>
            </abstract> year="2022" month="June"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-cache-18"/> name="STD" value="98"/>
          <seriesInfo name="RFC" value="9111"/>
          <seriesInfo name="DOI" value="10.17487/RFC9111"/>
        </reference>
        <reference anchor="WEB-LINKING"> anchor="WEB-LINKING" target="https://www.rfc-editor.org/info/rfc8288">
          <front>
            <title>Web Linking</title>
            <author fullname="M. Nottingham" initials="M." surname="Nottingham">
              <organization/>
            </author>
            <date month="October" year="2017"/>
            <abstract>
              <t>This specification defines a model for the relationships between resources on the Web ("links") and the type of those relationships ("link relation types").</t>
              <t>It also defines the serialisation of such links in HTTP headers with the Link header field.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8288"/>
          <seriesInfo name="DOI" value="10.17487/RFC8288"/>
        </reference>
        <reference anchor="URL"> anchor="URL" target="https://www.rfc-editor.org/info/rfc3986">
          <front>
            <title>Uniform Resource Identifier (URI): Generic Syntax</title>
            <author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee">
              <organization/>
            </author>
            <author fullname="R. Fielding" initials="R." surname="Fielding">
              <organization/>
            </author>
            <author fullname="L. Masinter" initials="L." surname="Masinter">
              <organization/>
            </author>
            <date month="January" year="2005"/>
            <abstract>
              <t>A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource.  This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet.  The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier.  This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="66"/>
          <seriesInfo name="RFC" value="3986"/>
          <seriesInfo name="DOI" value="10.17487/RFC3986"/>
        </reference>
        <reference anchor="WELL-KNOWN-URI"> anchor="WELL-KNOWN-URI" target="https://www.rfc-editor.org/info/rfc8615">
          <front>
            <title>Well-Known Uniform Resource Identifiers (URIs)</title>
            <author fullname="M. Nottingham" initials="M." surname="Nottingham">
              <organization/>
            </author>
            <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 URI schemes that support well-known URIs in their registry.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8615"/>
          <seriesInfo name="DOI" value="10.17487/RFC8615"/>
        </reference>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner">
              <organization/>
            </author>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  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</title>
            <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 protocol  specifications.  This document aims to reduce the ambiguity by clarifying that 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"> anchor="BCP190">
          <front>
            <title>URI Design and Ownership</title>
            <author fullname="M. Nottingham" initials="M." surname="Nottingham">
              <organization/>
            </author>
            <date month="June" year="2020"/>
            <abstract>
              <t>Section 1.1.1 of RFC 3986 defines URI syntax as "a federated and extensible naming system wherein each scheme's specification may further restrict 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 independent standards that mandate particular forms of substructure in URIs is often problematic.</t>
              <t>This document provides guidance on the specification of URI substructure in standards.</t>
              <t>This document obsoletes RFC 7320 and updates RFC 3986.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="190"/>
          <seriesInfo name="RFC" value="8820"/>
          <seriesInfo name="DOI" value="10.17487/RFC8820"/>
        </reference>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6838.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6454.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6648.xml"/>
        <reference anchor="RFC6838"> anchor="STRUCTURED-FIELDS" target="https://www.rfc-editor.org/info/rfc8941">
          <front>
            <title>Media Type Specifications and Registration Procedures</title>
            <author fullname="N. Freed" initials="N." surname="Freed">
              <organization/>
            </author>
            <author fullname="J. Klensin" initials="J." surname="Klensin">
              <organization/>
            </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 registration of media types
            <title>Structured Field Values for use in HTTP, MIME, and other Internet protocols.  This 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 often used as the scope of authority or privilege by user agents.  Typically, user agents isolate content retrieved from different origins to prevent malicious web site operators from interfering with the operation of benign web sites.  In addition to outlining the principles that underlie the concept of origin, this document 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 indicates 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>
            <title>Deprecating the "X-" Prefix and Similar Constructs in Application Protocols</title>
            <author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre">
              <organization/>
            </author>
            <author fullname="D. Crocker" initials="D." surname="Crocker">
              <organization/>
            </author> HTTP</title>
            <author fullname="M. Nottingham" initials="M." surname="Nottingham">
              <organization/>
            </author>
            <author fullname="P-H. Kamp" initials="P-H." surname="Kamp">
              <organization/>
            </author>
            <date month="June" year="2012"/>
            <abstract>
              <t>Historically, designers and implementers of application protocols have often distinguished between standardized and unstandardized parameters by prefixing the names of unstandardized parameters with the string "X-" or similar constructs.  In practice, that convention causes more problems than it solves.  Therefore, this document deprecates the convention for newly defined parameters with textual (as opposed to numerical) names in application protocols. This memo documents an Internet Best Current Practice.</t>
            </abstract> month="February" year="2021"/>
          </front>
          <seriesInfo name="BCP" value="178"/>
          <seriesInfo name="RFC" value="6648"/> value="8941"/>
          <seriesInfo name="DOI" value="10.17487/RFC6648"/> value="10.17487/RFC8941"/>
        </reference>
    </references>
    <references>
        <name>Informative References</name>
        <reference anchor="HTTP11"> anchor="HTTP11" target="https://www.rfc-editor.org/info/rfc9112">
          <front>
            <title>HTTP/1.1</title>
            <author initials="R" surname="Fielding" fullname="Roy T. Fielding">
              <organization>Adobe</organization> Fielding" role="editor">
              <organization />
            </author>
            <author initials="M" surname="Nottingham" fullname="Mark Nottingham">
              <organization>Fastly</organization> Nottingham" role="editor">
             <organization />
           </author>
           <author initials="J" surname="Reschke" fullname="Julian Reschke">
              <organization>greenbytes GmbH</organization> Reschke" role="editor">
             <organization />
           </author>
           <date day="18" month="August" year="2021"/>
            <abstract>
              <t>   The Hypertext Transfer Protocol (HTTP) is a stateless application-
   level protocol for distributed, collaborative, hypertext information
   systems.  This document specifies the HTTP/1.1 message syntax,
   message parsing, connection management, and related security
   concerns.

   This document obsoletes portions of RFC 7230.

              </t>
            </abstract> year="2022" month="June" />
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-messaging-18"/> name="STD" value="99"/>
          <seriesInfo name="RFC" value="9112"/>
          <seriesInfo name="DOI" value="10.17487/RFC9112"/>
        </reference>
        <reference anchor="HTTP2"> anchor="HTTP2" target="https://www.rfc-editor.org/info/rfc9113">
          <front>
            <title>Hypertext Transfer Protocol Version 2 (HTTP/2)</title>
            <title>HTTP/2</title>
            <author initials="M" surname="Thomson" fullname="Martin Thomson">
              <organization>Mozilla</organization> Thomson" role="editor">
              <organization/>
            </author>
            <author initials="C" surname="Benfield" fullname="Cory Benfield">
              <organization>Apple Inc.</organization> Benfield" role="editor">
              <organization/>
            </author>
            <date day="12" month="July" year="2021"/>
            <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>  month="June" year="2022"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-http2bis-03"/> name="RFC" value="9113"/>
          <seriesInfo name="DOI" value="10.17487/RFC9113"/>
        </reference>
        <reference anchor="HTTP3"> anchor="HTTP3" target="https://www.rfc-editor.org/info/rfc9114">
          <front>
            <title>Hypertext Transfer Protocol Version 3 (HTTP/3)</title>
            <title>HTTP/3</title>
            <author initials="M" surname="Bishop" fullname="Mike Bishop">
              <organization>Akamai</organization> Bishop" role="editor">
              <organization />
            </author>
            <date day="2" month="February" year="2021"/>
            <abstract>
              <t>   The QUIC transport protocol has several features that are desirable
   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> year="2022" month="June" />
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-quic-http-34"/> name="RFC" value="9114"/>
          <seriesInfo name="DOI" value="10.17487/RFC9114"/>
        </reference>
        <reference anchor="JSON"> anchor="JSON" target="https://www.rfc-editor.org/info/rfc8259">
          <front>
            <title>The JavaScript Object Notation (JSON) Data Interchange Format</title>
            <author fullname="T. Bray" initials="T." role="editor" surname="Bray">
              <organization/>
            </author>
            <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 ECMAScript 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 interoperability guidance.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="90"/>
          <seriesInfo name="RFC" value="8259"/>
          <seriesInfo name="DOI" value="10.17487/RFC8259"/>
        </reference>
        <reference anchor="URI-TEMPLATE"> anchor="URI-TEMPLATE" target="https://www.rfc-editor.org/info/rfc6570">
          <front>
            <title>URI Template</title>
            <author fullname="J. Gregorio" initials="J." surname="Gregorio">
              <organization/>
            </author>
            <author fullname="R. Fielding" initials="R." surname="Fielding">
              <organization/>
            </author>
            <author fullname="M. Hadley" initials="M." surname="Hadley">
              <organization/>
            </author>
            <author fullname="M. Nottingham" initials="M." surname="Nottingham">
              <organization/>
            </author>
            <author fullname="D. Orchard" initials="D." surname="Orchard">
              <organization/>
            </author>
            <date month="March" year="2012"/>
            <abstract>
              <t>A URI Template is a compact sequence of characters for describing a range of Uniform Resource Identifiers through variable expansion. This specification defines the URI Template syntax and the process for expanding a URI Template into a URI reference, along with guidelines for the use of URI Templates on the Internet.   [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6570"/>
          <seriesInfo name="DOI" value="10.17487/RFC6570"/>
        </reference>
        <reference anchor="COOKIES"> anchor="COOKIES" target="https://www.rfc-editor.org/info/rfc6265">
          <front>
            <title>HTTP State Management Mechanism</title>
            <author fullname="A. Barth" initials="A." surname="Barth">
              <organization/>
            </author>
            <date month="April" year="2011"/>
            <abstract>
              <t>This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol.  Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet.  This document obsoletes RFC 2965.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6265"/>
          <seriesInfo name="DOI" value="10.17487/RFC6265"/>
        </reference>
        <reference anchor="PROBLEM-DETAILS"> anchor="PROBLEM-DETAILS" target="https://www.rfc-editor.org/info/rfc7807">
          <front>
            <title>Problem Details for HTTP APIs</title>
            <author fullname="M. Nottingham" initials="M." surname="Nottingham">
              <organization/>
            </author>
            <author fullname="E. Wilde" initials="E." surname="Wilde">
              <organization/>
            </author>
            <date month="March" year="2016"/>
            <abstract>
              <t>This document defines a "problem detail" as a way to carry machine- readable details of errors in a HTTP response to avoid the need to define new error response formats for HTTP APIs.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7807"/>
          <seriesInfo name="DOI" value="10.17487/RFC7807"/>
        </reference>
        <reference anchor="STRUCTURED-FIELDS">
          <front>
            <title>Structured Field Values for HTTP</title>
            <author fullname="M. Nottingham" initials="M." surname="Nottingham">
              <organization/>
            </author>
            <author fullname="P-H. Kamp" initials="P-H." surname="Kamp">
              <organization/>
            </author>
            <date month="February" year="2021"/>
            <abstract>
              <t>This document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handle HTTP header and trailer fields, known as "Structured Fields", "Structured Headers", or "Structured Trailers". It is intended for use by specifications of new HTTP fields that wish to use a common syntax that is more restrictive than traditional HTTP field values.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8941"/>
          <seriesInfo name="DOI" value="10.17487/RFC8941"/>
        </reference>
        <reference anchor="HTTP-PRIORITY"> anchor="HTTP-PRIORITY" target="https://www.rfc-editor.org/info/rfc9218">
          <front>
            <title>Extensible Prioritization Scheme for HTTP</title>
            <author fullname="Kazuho Oku">
              <organization>Fastly</organization> asciiFullname="Kazuho Oku" fullname="奥 一穂">
              <organization/>
            </author>
            <author initials="L" surname="Pardue" fullname="Lucas Pardue">
              <organization>Cloudflare</organization>
              <organization/>
            </author>
            <date day="11" month="July" year="2021"/>
            <abstract>
              <t>   This document describes a scheme for prioritizing HTTP responses.
   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> month="June" year="2022"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-priority-04"/> name="RFC" value="9218"/>
          <seriesInfo name="DOI" value="10.17487/RFC9218"/>
        </reference>
        <reference anchor="HTML" target="https://html.spec.whatwg.org">
          <front>
            <title>HTML - Living Standard</title>
            <author>
              <organization>WHATWG</organization>
            </author>
            <date>n.d.</date>
            <date/>
          </front>
        </reference>
        <reference anchor="FETCH" target="https://fetch.spec.whatwg.org">
          <front>
            <title>Fetch - Living Standard</title>
            <author>
              <organization>WHATWG</organization>
            </author>
            <date>n.d.</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 default ports, URL schemes, and HTTP security mechanisms.  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="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 Negotiation 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) extension for application-layer protocol negotiation within the TLS handshake. For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol 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 mitigated 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 declare themselves accessible only via secure connections and/or for users to be able 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 Security (HSTS).  The policy is declared by web sites via the Strict-Transport-Security HTTP response header field and/or by other means, such as user agent configuration, for example. [STANDARDS-TRACK]</t>
            </abstract>
            <date/>
          </front>
          <seriesInfo name="RFC" value="6797"/>
          <seriesInfo name="DOI" value="10.17487/RFC6797"/>
        </reference>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3205.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7301.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7258.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6797.xml"/>
        <reference anchor="SECCTXT" target="https://www.w3.org/TR/2016/CR-secure-contexts-20160915"> target="https://www.w3.org/TR/2021/CRD-secure-contexts-20210918">
          <front>
            <title>Secure Contexts</title>
            <author fullname="Mike West" initials="M." surname="West">
              <organization/>
            </author>
            <date day="15"  month="September" year="2016"/>
          </front>
          <seriesInfo name="World Wide Web Consortium CR" value="CR-secure-contexts-20160915"/>
        </reference>
        <reference anchor="RFC7595">
          <front>
            <title>Guidelines and Registration Procedures for URI Schemes</title>
            <author fullname="D. Thaler" initials="D." role="editor" surname="Thaler">
              <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 well as the IANA registration processes, for the definition of Uniform Resource Identifier (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</title>
            <author fullname="J. Touch" initials="J." surname="Touch">
              <organization/>
            </author>
            <date month="August" year="2015"/>
            <abstract>
              <t>This document provides recommendations to designers of application 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 processes defined in RFC 6335; thus, this document complements (but does not update) 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="Desruisseaux">
              <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 Authoring and Versioning (WebDAV) protocol to specify a standard way of accessing, managing, and sharing calendaring and scheduling information based on the iCalendar format.  This document defines the "calendar-access" feature of CalDAV.  [STANDARDS-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 communicate with servers about HTTP requests that are sent in early data.  Techniques are 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 management of resource properties, creation and management of resource collections, URL 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 experience.  [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" surname="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 metadata as well as information about individual resources controlled by the host.  [STANDARDS-TRACK]</t>
            </abstract> year="2021"/>
          </front>
          <seriesInfo name="RFC" value="6415"/>
          <seriesInfo name="DOI" value="10.17487/RFC6415"/>
        </reference>
          <refcontent>W3C Candidate Recommendation</refcontent>
        </reference>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7595.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7605.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4791.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8470.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4918.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6415.xml"/>
        <reference anchor="XML" target="https://www.w3.org/TR/2008/REC-xml-20081126">
          <front>
            <title>Extensible Markup Language (XML) 1.0 (Fifth Edition)</title>
            <author fullname="Tim Bray" initials="T." surname="Bray">
              <organization/>
            </author>
            <author fullname="Jean Paoli" initials="J." surname="Paoli">
              <organization/>
            </author>
            <author fullname="Michael Sperberg-McQueen" initials="M." surname="Sperberg-McQueen">
              <organization/>
            </author>
            <author fullname="Eve Maler" initials="E." surname="Maler">
              <organization/>
            </author>
            <author fullname="François fullname="François Yergeau" initials="F." surname="Yergeau">
              <organization/>
            </author>
            <date day="26" month="November" year="2008"/>
          </front>
          <seriesInfo name="World Wide Web Consortium name="W3C 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 format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.</t>
              <t>This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange 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 extensions that allow control over the use of stale responses by caches.  This  document is not an Internet Standards Track specification; it is published for informational 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 pairs, 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" surname="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 challenge- response authentication mechanism that may be used by a server to challenge a client request and by a client to provide authentication information.  This document 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</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla">
              <organization/>
            </author>
            <date month="August" year="2018"/>
            <abstract>
              <t>This document specifies version 1.3 of the Transport Layer Security (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 5077, 5246, and 6961.  This document also specifies new requirements for TLS 1.2 implementations.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8446"/>
          <seriesInfo name="DOI" value="10.17487/RFC8446"/>
        </reference>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8949.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5861.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7617.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7616.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
        <reference anchor="CSP" target="https://www.w3.org/TR/2016/WD-CSP3-20160913"> target="https://www.w3.org/TR/2021/WD-CSP3-20210629">
          <front>
            <title>Content Security Policy Level 3</title>
            <author fullname="Mike West" initials="M." surname="West">
              <organization/>
            </author>
            <date day="13" month="September" year="2016"/> month="June" year="2021"/>
          </front>
          <seriesInfo name="World Wide Web Consortium WD" value="WD-CSP3-20160913"/>
          <refcontent>W3C Working Draft</refcontent>
        </reference>
        <reference anchor="REFERRER-POLICY" target="https://www.w3.org/TR/2017/CR-referrer-policy-20170126">
          <front>
            <title>Referrer Policy</title>
            <author fullname="Jochen Eisinger" initials="J." surname="Eisinger">
              <organization/>
            </author>
            <author fullname="Emily Stark" initials="E." surname="Stark">
              <organization/>
            </author>
            <date day="26" month="January" year="2017"/>
          </front>
          <seriesInfo name="World Wide Web Consortium CR" value="CR-referrer-policy-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>
          <seriesInfo name="RFC" value="8297"/>
          <seriesInfo name="DOI" value="10.17487/RFC8297"/>
          <refcontent>W3C Candidate Recommendation CR-referrer-policy-20170126</refcontent>
        </reference>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8297.xml"/>
      </references>
    </references>
    <section anchor="changes-from-rfc-3205" numbered="true" toc="default">
      <name>Changes from RFC 3205</name>
      <t><xref target="RFC3205" format="default"/> captured the Best Current Practice in the early 2000's, 2000s based on the concerns facing protocol designers at the time. Use of HTTP has changed considerably since then, and then; as a result result, this document is substantially different. As a result, Consequently, the changes are too numerous to list individually.</t>
    </section>
  </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>