Skip to main content

A Preconnect Hint for SVCB/HTTPS RR

Document Type Active Internet-Draft (individual)
Author Lucas Pardue
Last updated 2022-10-24
RFC stream (None)
Intended RFC status (None)
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
HTTP                                                           L. Pardue
Internet-Draft                                           24 October 2022
Intended status: Experimental                                           
Expires: 27 April 2023

                  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
   param/draft-pardue-httpbis-preconnect-hint-svc-param.html.  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.

Pardue                    Expires 27 April 2023                 [Page 1]
Internet-Draft     A Preconnect Hint for SVCB/HTTPS RR      October 2022

   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.

Copyright Notice

   Copyright (c) 2022 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   4
   3.  The preconnectHint SvcParamKey  . . . . . . . . . . . . . . .   4
   4.  Security and Privacy Considerations . . . . . . . . . . . . .   5
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

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.

Pardue                    Expires 27 April 2023                 [Page 2]
Internet-Draft     A Preconnect Hint for SVCB/HTTPS RR      October 2022

   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

Pardue                    Expires 27 April 2023                 [Page 3]
Internet-Draft     A Preconnect Hint for SVCB/HTTPS RR      October 2022

2.  Conventions and Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "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

   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.

Pardue                    Expires 27 April 2023                 [Page 4]
Internet-Draft     A Preconnect Hint for SVCB/HTTPS RR      October 2022

   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, 11 October 2022,

Pardue                    Expires 27 April 2023                 [Page 5]
Internet-Draft     A Preconnect Hint for SVCB/HTTPS RR      October 2022

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <>.

6.2.  Informative References

              Bishop, M., "The ORIGIN Extension in HTTP/3", Work in
              Progress, Internet-Draft, draft-ietf-httpbis-origin-h3-01,
              5 October 2022, <

   [RFC8297]  Oku, K., "An HTTP Status Code for Indicating Hints",
              RFC 8297, DOI 10.17487/RFC8297, December 2017,

   [RFC8336]  Nottingham, M. and E. Nygren, "The ORIGIN HTTP/2 Frame",
              RFC 8336, DOI 10.17487/RFC8336, March 2018,

   [RFC9113]  Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,
              DOI 10.17487/RFC9113, June 2022,

   [RFC9114]  Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114,
              June 2022, <>.


   This document is based on one of the options described by Barry
   Pollard's "Even earlier connection hints"
   edit#heading=h.fxvrme9c9xpm) proposal presented to the Web Perf WG at
   TPAC 2022.

   Ben Schwartz suggested the name preconnectHint.

Pardue                    Expires 27 April 2023                 [Page 6]
Internet-Draft     A Preconnect Hint for SVCB/HTTPS RR      October 2022

   Thanks to Chris Wood for a providing insight into the privacy
   implications of this design.

Author's Address

   Lucas Pardue

Pardue                    Expires 27 April 2023                 [Page 7]