Internet-Draft A Preconnect Hint for SVCB/HTTPS RR October 2022
Pardue Expires 27 April 2023 [Page]
Intended Status:
L. Pardue

A Preconnect Hint for SVCB/HTTPS RR


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

This note is to be removed before publishing as an RFC.

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

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 27 April 2023.

Table of Contents

1. 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 [RFC9113] and HTTP/3 [RFC9114] allow clients to coalesce different origins onto the same connection when certain conditions are met. The ORIGIN frame ([RFC8336] and [I-D.ietf-httpbis-origin-h3]) 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 [RFC8297] 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 [I-D.ietf-dnsop-svcb-https], 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.

2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. 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> (Section 5.1 of [RFC1035]).

For example, consider the resource at that has the dependencies, and As an HTTPS RR, the relationship between and other origins could be represented as: IN HTTPS 1 . alpn=h2,h3,

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 were intended to be redirected to, this could be represented in an additional RR as: IN HTTPS 1 . alpn=h2,h2

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 ([RFC9113] and [RFC9114]) 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.

4. 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 Section 3.

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 Section 3.

5. IANA Considerations


6. References

6.1. Normative References

Schwartz, B. M., Bishop, M., and E. Nygren, "Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)", Work in Progress, Internet-Draft, draft-ietf-dnsop-svcb-https-11, , <>.
Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, , <>.
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <>.

6.2. Informative References

Bishop, M., "The ORIGIN Extension in HTTP/3", Work in Progress, Internet-Draft, draft-ietf-httpbis-origin-h3-01, , <>.
Oku, K., "An HTTP Status Code for Indicating Hints", RFC 8297, DOI 10.17487/RFC8297, , <>.
Nottingham, M. and E. Nygren, "The ORIGIN HTTP/2 Frame", RFC 8336, DOI 10.17487/RFC8336, , <>.
Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113, DOI 10.17487/RFC9113, , <>.
Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114, , <>.


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.

Author's Address

Lucas Pardue