]>

lucaspardue.24.7@gmail.com

Applications and Real-Time HTTP HTTP resources from one origin often have relationships to resources on other origins. This document outlines how a "preconnectHint" SvcParamKey for SVCB, could be used to provide an early indication of origins that are related to the current origin. Clients could use this information to opportunistically prepare and open connections, with the expectation that they will be used to fetch related resources. This mechanism provides information from a source that is not the authenticated origin, which could cause the client to perform actions that no other party would ask them to do; privacy considerations due to this are visited. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the HTTP Working Group mailing list (), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction HTTP resources from one origin often have relationships to resources on other origins. For example, when a user agent loads the main HTML document of a webpage from one one origin, it can discover critical dependencies at additional first-party or third-party origins. In order to fetch these resources, additional connections might be required. The additional time required to establish new connections can inflate the perceived latency of rendering or using resources. In some cases, a server may be authoritative for several origins. HTTP/2 and HTTP/3 allow clients to coalesce different origins onto the same connection when certain conditions are met. The ORIGIN frame ( and ) enhances this further. These techniques can help minimize perceived latency by eliminating connection setup time entirely, but they apply only for the subset of origins that can safely be coalesced. The 103 (Early Hints) status code can convey hints about resource relationships. A server can emit interim responses to help the client start making preparations, such as creating new connections. This is especially useful when the origin might take time to generate the final response. Where related resources reside on third-party origins, this technique helps minimize perceived latency by providing the client with information as early as possible in the HTTP message exchange. Thus it fills a capability gap left by coalescing. However, the technique is dependent on the timing of message exchanges, which might might make it difficult to achieve performance gains in practice. It is common for a web page to fetch resources from a fairly stable set of additional origins, even if the specific resource paths are more volatile. For example, a page may be designed to load scripts from third-party resource CDNs, or images from content sub-domains under the same top-level origin. User agents can only learn of these relationships once a resource has been fetched. This "run-time learning" of stable relationships delays the time at which a client discovers it might need to create additional connections. Between fetching a resource and learning its dependencies, here is an opportunity to reduce performance delays caused by the delayed run-time learning of these relationships, even in light of the techniques described above. This document defines the "preconnectHint" SvcParamKey for SVCB , to indicate origins that are related to the current origin. Clients that query HTTPS RRs can use the information contained in this parameter to opportunistically prepare and open connections, with the expectation that they will be used to fetch related resources. This could include chaining DNS queries for the hinted origins. Preconnect origins might satisfy the conditions required for HTTP connection coalescing, in which case the optimization could still reduce the delay before clients perform coalescing-related checks; for example, certificate fetching or validation.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

The preconnectHint SvcParamKey SVCB and HTTPS Resource Records can include the preconnectHint SvcParamKey to indicate related origins. Its presentation format value is a comma-separated list of <domain-name> (). For example, consider the resource at https://example.org/index.html that has the dependencies https://www.example.com/style.css, and https://scripts.example.org/script.js. As an HTTPS RR, the relationship between example.org and other origins could be represented as: A common pattern in HTTP is to use 3xx redirect status codes to move from www subdomains to domain apexes. Building on the previous example, if www.example.com were intended to be redirected to example.com, this could be represented in an additional RR as: Clients that learn about preconnect origins MAY use this information to make whatever preparations they deem fit. For instance, they could use it to perform the same connection coalescing authority checks ( and ) that would otherwise happen later in a connection lifecycle. Similarly, they could use this information to help maintain a connection pool and, where needed, proactively create or keep open connections to those origins in anticipation of being used. There are new privacy considerations to make when using any preconnect origin information provided via the DNS. The records are presented by resolvers that act on behalf of, but are not authoritative for, the origin. As such, the resolvers could present unauthenticated information that could cause a client to take actions that the authenticated origin would not. This could be abused to leak information about the client. A malicious resolver could also abuse this mechanism unbeknownst to the origin. The preconnectHint SvcParamKey is a hint and could contain stale, incorrect or superfluous information. A client SHOULD implement checks and heuristics that limit state or resource commitment based on this information. For example, a client could track how often preconnect origins are matched to related resources. Notably, the scope of relationships is at the origin level, not any other component that might later comprise a URI that is to be fetched. As such, constraining the set of values in the preconnectHint parameter, to those that are most likely to be used by a client, can help avoid commitment of resources that might subsequently go unused. Knowledge of HTTP resource relationships might be restricted to authorized clients. Exposing those origins as a preconnectHint to unauthorised DNS clients could leak confidential or sensitive information. Therefore, the preconnectHint SvcParmKey SHOULD NOT contain origins that relate to information that would otherwise only be accessible to authorized clients.

Security and Privacy Considerations Information about origin relationships is typically presented by the authenticated origin itself. Delegating this information to an unauthenticated and untrusted DNS resolver provides opportunities to manipulate client behaviour, which could risk privacy problems; see . The preconnectHint parameter reveals information about the relationships of resources hosted on a server. While this information is typically already available to any client that visits the server, some resources may only be discoverable by authorized clients. Guidance for managing this is given in .

IANA Considerations TBD

References Normative References Google Akamai Technologies Akamai Technologies This document specifies the "SVCB" and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration and keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP [HTTP]. By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/MikeBishop/dns-alt-svc (https://github.com/MikeBishop/dns-alt-svc). The most recent working version of the document, open issues, etc. should all be available there. The authors (gratefully) accept pull requests. 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. 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. This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication. Informative References 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 latency by introducing field compression and allowing multiple concurrent exchanges on the same connection. This document obsoletes RFCs 7540 and 8740. 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. This document specifies the ORIGIN frame for HTTP/2, to indicate what origins are available on a given connection. Akamai The ORIGIN frame for HTTP/2 is equally applicable to HTTP/3, but needs to be separately registered. This document describes the ORIGIN frame for HTTP/3. 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.

Acknowledgments This document is based on one of the options described by Barry Pollard's "Even earlier connection hints" proposal presented to the Web Perf WG at TPAC 2022. Ben Schwartz suggested the name preconnectHint. Thanks to Chris Wood for a providing insight into the privacy implications of this design.