Re: Adoption of Prefer-Push as an experimental submission

Lucas Pardue <> Wed, 06 May 2020 01:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4B9553A0CD5 for <>; Tue, 5 May 2020 18:44:50 -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.249, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=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 lsfftIH_Zqvz for <>; Tue, 5 May 2020 18:44:48 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 333753A0CA1 for <>; Tue, 5 May 2020 18:44:48 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jW94H-0000zz-04 for; Wed, 06 May 2020 01:41:49 +0000
Resent-Date: Wed, 06 May 2020 01:41:49 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jW94F-0000z8-UB for; Wed, 06 May 2020 01:41:47 +0000
Received: from ([2a00:1450:4864:20::42a]) by with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <>) id 1jW94E-0000U7-9E for; Wed, 06 May 2020 01:41:47 +0000
Received: by with SMTP id h9so239100wrt.0 for <>; Tue, 05 May 2020 18:41:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hxx+pfVy2due6XTF+VzpBaGHW9pmXuaGRgzHpHGunCk=; b=VZ86xY3wNghDVCpHjhmv5WhqSLM/W0ctjhe+1gORpJJBSv495EhD9/PXEnSoHW5kX7 cOhzEGspvcoOcOIhqN7rEaff/KnJW0vfCC7oKJXG7iMvTDmYcqEC28MenDNoUDDvmM0p j7kdkCIeziiiIcaKEDlsIydz02pfMkdh073UJGBYO3UHuOx4VuvvuGy13l/Jg7QqfPd4 ATSbhJkrAOfudF4osp7DpL4T/LQDCUae/hPpWz6BIgO9JTIx04ulyykFWIjEQU045DD8 qlt9gRj/YgkbAWS54J/Fu92uCCSP5+0zzfKa74CqYRKUIH36rnqC0OKLQU5ewWAfieXO sPdQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hxx+pfVy2due6XTF+VzpBaGHW9pmXuaGRgzHpHGunCk=; b=oKHpRpccX4jqR3rDDRnLxgMFm3nYivMSWHL0+36DAVIFcxL6G5EH2wq6cL01fTkshb paV1r21fXlSQrI80e7Msyr/QpH/9wvyOPeJNwHuRwuGhSwe/9Rho/F7E3hdX2c/vSVeR Uj5U+hogPATjcRgIK/6hCtWHZnZP/YIwiWIrxKXTrhSp98uVOMqq3VBqsFdufwUZwUM0 qvpq84SQLKInQkCa0arubuPzMM6hKXnNBDUiFV4P3EO3L21grPq/OcW1GIIxmY0be+wH xrscvwxqnJhq/J4KUgb4rM+A1CUjfe4b5gFiGvrUpm8gzcEP3QGn26ITsS8hhMpzUSTA wywQ==
X-Gm-Message-State: AGi0PuYNTLLuK8YYBHdNaS6gWc6fYI3AHLs08CApYg0c+tWm88S9z25R 4GhzSGmygNptp5XYd7Xl/MsCKt7VNCz7bdiA83rcc/jA
X-Google-Smtp-Source: APiQypLr4Uglk1JMn6DyLfmVynO9+o7+WAmGLFj46xuQMFi/4EOCroVrV49v+KUkrTd1DM89cTKO31l1hJVZwzMf5MM=
X-Received: by 2002:a5d:6503:: with SMTP id x3mr7377222wru.153.1588729295003; Tue, 05 May 2020 18:41:35 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Lucas Pardue <>
Date: Wed, 6 May 2020 02:41:22 +0100
Message-ID: <>
To: Evert Pot <>
Cc: HTTP Working Group <>
Content-Type: multipart/alternative; boundary="00000000000045e25e05a4f0dd90"
Received-SPF: pass client-ip=2a00:1450:4864:20::42a;;
X-W3C-Hub-Spam-Status: No, score=-7.8
X-W3C-Scan-Sig: 1jW94E-0000U7-9E 335b6da91c908f9e6a94db3e5b9ef061
Subject: Re: Adoption of Prefer-Push as an experimental submission
Archived-At: <>
X-Mailing-List: <> archive/latest/37574
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Hey Evert,

On Wed, May 6, 2020 at 1:16 AM Evert Pot <> wrote:

> Dear working group,
> Some time ago, I submitted the following draft:
> The document describes a means for a HTTP client to indicate a list of
> linked resources they might want to receive via HTTP2 Push, through
> their relation type.
> I was curious if there is a chance that the HTTP working group might
> want to adopt this document as an experimental specification
> We have deployed systems with this feature and some success. A public
> client implementation can also be found here:
> Regards,
> Evert
Reading the draft again, for someone not super familiar with the problem
area it doesn't leap of the page to me how this really benefits the use
cases. However, you've reminded me of Asbjørn Ulsberg's presentation at the
HTTP Workshop 2019 [1] that gave a good overview of things. There was some
chatter in the room and Daniel's notes [2] indicate there some alternative
suggestions made but I can't recall what they were.

Any specification that uses a client signal to inform a server of what to
push has a resemblence to Cache Digests, which has a sad fate [3]. Note too
that it had an intended status of experimental. Therefore, IMO, it is due
diligence to compare prefer-push to cache digests and understand how it
differs both technically and in terms of implementation interest.