Server Push, Alt-Svc and connection switching

Lucas Pardue <> Wed, 16 October 2019 00:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E3862120830 for <>; Tue, 15 Oct 2019 17:53:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.75
X-Spam-Status: No, score=-2.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cdqy1Fp9Xc9R for <>; Tue, 15 Oct 2019 17:53:54 -0700 (PDT)
Received: from ( [IPv6:2603:400a:ffff:804:801e:34:0:38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F36EE120825 for <>; Tue, 15 Oct 2019 17:53:53 -0700 (PDT)
Received: from lists by with local (Exim 4.89) (envelope-from <>) id 1iKXXN-0004de-FG for; Wed, 16 Oct 2019 00:51:37 +0000
Resent-Date: Wed, 16 Oct 2019 00:51:37 +0000
Resent-Message-Id: <>
Received: from ([2603:400a:ffff:804:801e:34:0:4c]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <>) id 1iKXXM-0004cQ-1J for; Wed, 16 Oct 2019 00:51:36 +0000
Received: from ([2607:f8b0:4864:20::a31]) by with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <>) id 1iKXXK-0005xU-O2 for; Wed, 16 Oct 2019 00:51:35 +0000
Received: by with SMTP id d126so4792338vkb.1 for <>; Tue, 15 Oct 2019 17:51:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=HlI6Qu/KL94Co33Ih+TiuXP1bGMkSGO6Soe1DOcboEI=; b=GwZtkuXL1BKJV+yQqqehm4E6lBi0PMABRYt9UIDM6DSrC5WO176ejQBXzK9NQNB8DV Bx7iT0gq/Fm+3t6yD2tkCmsKEDE6Z7xwIm3quKro+O9Mf+SQR2sYrHup9TwjU7nkKez+ yRZOVKxkkAb+mijS8n3t/u1ic6cSIRe8Vqy/i8hi04PP4M7bznvbcFBamEFIY1BUf6I3 CfCtAdwp8rPrhr2EgIodrJm7CPUXqEXhdpaFPgp8iMgM1Tcio4c09p3hTDv7yu3RRRvx Ql6xJbVisOr3UZhArR3ZZrKyBn/EPERm1YB2jNZ+DfIaUvFjNNBSi/ZtABL6MDvSOQ3t 8hyQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=HlI6Qu/KL94Co33Ih+TiuXP1bGMkSGO6Soe1DOcboEI=; b=abJ4EOXfcZ/v5Jb2BsHpnSrzyJwVqyiP/RKz3VWH5T87SdFWzKVdvnChWzOuAdniFP 8m8n3CYUb8D2R0ubf7/rLzQTSSRxnAxK73AWDCils96VRierH8OXln4uS4PfrjQKdaft i7K0I65FcM0g0jwPtag1OzsdUCQ6bwK67bY2vaTU4uWggfwVPWLzq8dEJl5iPSKtUmCr Udht0ioCENhhEpBO1TM73zHOh5qiCyxYzxFjnHDZb425Qmhfi+C0nvx1D5oXIUxYzEpK pbYPTlycuA3PtKgOntKOIxnC3ngly2Gf9AbKeO7qgMgW8Fvp5sTUz4Bf6ZtCcgrEGOVf fhLg==
X-Gm-Message-State: APjAAAXmC62VK2U2fHklygxl2Yfx0Yr9AOI4wzRUaVMEcTRmvv50/kM1 /jRGLkWIeP/98S2Mqu2Ovm6thj71zHr0TJ743csG/p77
X-Google-Smtp-Source: APXvYqzAj0YF0qxnqXQZYgeFvXCUcYugNI/He6WmqTnAFUg8F6Bep4Kh29is0LxcGa+AmnRxNcRsauai2oj2a7OuRik=
X-Received: by 2002:a1f:fec8:: with SMTP id l191mr20712951vki.15.1571187093237; Tue, 15 Oct 2019 17:51:33 -0700 (PDT)
MIME-Version: 1.0
From: Lucas Pardue <>
Date: Wed, 16 Oct 2019 01:51:22 +0100
Message-ID: <>
To: HTTP Working Group <>
Content-Type: multipart/alternative; boundary="0000000000009174ac0594fc80fa"
Received-SPF: pass client-ip=2607:f8b0:4864:20::a31;;
X-W3C-Hub-Spam-Status: No, score=-3.8
X-W3C-Scan-Sig: 1iKXXK-0005xU-O2 b6d31732e40a063cc539214fcf081611
Subject: Server Push, Alt-Svc and connection switching
Archived-At: <>
X-Mailing-List: <> archive/latest/37057
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Based on some observations of how Chrome Canary discovers HTTP/3 and
switches, I've begun wondering how the connection switching behaviour plays
with the way user agents implement server push - particularly around the
concept of "push caches" that may or may not be tied to a connection.

To use an example consider a document (index.html) that contains some tags
for script1.js, script2.js and script3.js. On first visit, the request
might happen as so

index.html - requested over TCP+TLS using HTTP/2. Contains Alt-Svc: h3-23
   * script1.js - requested over QUIC and H3
   * script2.js - requested over QUIC and H3
   * script3.js - requested over QUIC and H3

Now consider Server Push in this scenario; where requests for index.html
trigger server push for script(1-3).js unconditionally.

What do people think n the above case when the server sends PUSH_PROMISE,
HEADERS and DATA for scripts on HTTP/2 before sending the HEADERS for
index.html that contains the Alt-Svc.

If pushed responses are held in a "push cache" tied to the H2 connection,
is there a chance that this is blown away when you change to H3? Or do the
requests for scripts resolve to the push cache and promote to the client
cache proper? Or something totally different unique to each implementation.

This seems like an undesirable side-effect of our current capabilities and
deployment plans if it indeed an issue.

Any thoughts from the group?