Re: Adoption of Prefer-Push as an experimental submission

Robin MARX <> Wed, 13 May 2020 15:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6FDC13A102E for <>; Wed, 13 May 2020 08:14:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.747
X-Spam-Status: No, score=-2.747 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id m6Wud5-dF0Vs for <>; Wed, 13 May 2020 08:14:35 -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 EF8243A119A for <>; Wed, 13 May 2020 08:13:44 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jYt2D-0003ib-O7 for; Wed, 13 May 2020 15:11:01 +0000
Resent-Date: Wed, 13 May 2020 15:11:01 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jYt2C-0003hc-A0 for; Wed, 13 May 2020 15:11:00 +0000
Received: from ([2a00:1450:4864:20::434]) by with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <>) id 1jYt2A-0001Xy-1j for; Wed, 13 May 2020 15:11:00 +0000
Received: by with SMTP id y16so14171293wrs.3 for <>; Wed, 13 May 2020 08:10:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=e0PYK+jkIntJxb+lPNNpUJBM0sjw4v8qeHZn9MgLw80=; b=tx/JZ9imNXkkSGyVWWOFX4wtn9xwh8dwHKn/V2yB4dtQwnPrRl+7ErkkLUDO3V5bJM sRl/MFfRdUezoXp4unfjFSdR8FeiORkmrkWqt6QLi+cn5XcKSzcSpwrXzPdoIVnJdU+K Dv6hB8HnSEuzovDRWLfDVttcgCTHHfwoBdgsU=
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=e0PYK+jkIntJxb+lPNNpUJBM0sjw4v8qeHZn9MgLw80=; b=VBQnS2app0jFLjk+4KKkhPkD72nHfU17isUKcltpaRuevtIipXlog4BLELeXC3E3Ma XEQEQCvF9aTTJPt/1oBuBUy/JE4axmJKIrIcCtL17tHmVtQljH4MwIkNzHqmRR4Lk6dk crZpbTuRyQ7dz/aszIB5X7o04F2kt7jrSV/R31JTVs78HAw7slr36ZZ/kgj5xAYvQjnz 0KtjOJMN7PjfFu1ngWd3+1oFXd+u1HU87xelUYCSYOWkdULiw5gWWh4qgJUFD1oly/T2 jrVHFKFzJQsEXkkjQnqRPGMxOLLGvbzU8QDLNgLHB7lkIZqxX4W2fPyWjZkbJpCtIy// 9ahA==
X-Gm-Message-State: AGi0PuZetB2E4O8Bso2Dvp/c2THGPQSgvPkZ5Ro89enzj2bXvO/bsNiz QCWsvZIR8aDKKnLcgVk0BY8GQgB0hcIW66Z4PGXufw==
X-Google-Smtp-Source: APiQypJ6mEdNpXJqV1DFYaSsuOuruUPFguK1fGtJkNg4+koDTVd5o7zSUbDUKApFOxGA6mM8ZwhDeXwd5AEX8/8rhSI=
X-Received: by 2002:adf:f702:: with SMTP id r2mr32467038wrp.191.1589382646065; Wed, 13 May 2020 08:10:46 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Robin MARX <>
Date: Wed, 13 May 2020 17:10:35 +0200
Message-ID: <>
To: Evert Pot <>
Cc: Lucas Pardue <>, HTTP Working Group <>
Content-Type: multipart/alternative; boundary="00000000000007fec305a588fc03"
Received-SPF: pass client-ip=2a00:1450:4864:20::434;;
X-W3C-Hub-Spam-Status: No, score=-4.1
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1jYt2A-0001Xy-1j 040d4f0968b413a7fb5063414306b5f8
Subject: Re: Adoption of Prefer-Push as an experimental submission
Archived-At: <>
X-Mailing-List: <> archive/latest/37616
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Hello Evert,

My four cents:
1) It seems this is highly REST-API coupled? In that case, the "querying"
language should be well-defined in the document as well (e.g., you use
"item, author", but what if I'd want to request a push of the author of
just the first 10 entries?)
In addition to that, IIUC, few endpoints use "pure REST": most will have
some form of embedding going on (up to full-fledged GraphQL), where you
might need to have something like "" etc.
If you don't support these cases, the header's usefulness becomes very
narrow imo. If you do support them, the "querying" language becomes

2) It seems like this is something that would always be
programmatically driven? (e.g., in the browser, a JavaScript fetch(), not
something a developer would trigger using an HTML tag).
In this case, it's pretty trivial to add this type of functionality on a
per-application basis (which, imo, does not by definition mean it shouldn't
be standardized, but does make it less "important" as there is a direct
workaround available).

3) Yoav Weiss (and his team) recently posted a "Web Bundles" design
document (
which seems to take a new stab at the "let the server know what the client
has cached"-problem.
I must admit I haven't processed this 100% yet and it's written from a
different perspective (improving JS delivery), but at high level it might
be an interesting avenue for reviving cache digests (or similar) for push
down the line.
It would be interesting to have that conversation here as well I feel.

4) I really like the blogpost and its visual example, thanks for sharing.
At the risk of going on a tangent here: you mention HTTP/3 a few times in
there but don't specify concretely how it would help with this use case and
I'm having trouble seeing how H3 is different from H2 in that respect.
If you do see better synergies, could you elaborate? This might be good
input for the QUIC wg as it finalizes H3.

With best regards,

On Tue, 12 May 2020 at 21:40, Evert Pot <> wrote:

> Hi Lucas,
> On 2020-05-05 9:41 p.m., Lucas Pardue wrote:
> 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.
> I was very sad to see Cache Digest go too. Prefer-Push is complimentary to
> Cache Digest, as that draft informed the server of the state of the cache,
> but not *which* resources they would like pushed. With Cache Digest
> alone, the server would still have to guess which resources the client
> needs.
> This makes more sense for traditional browser applications where you can
> reasonably assume that user will need all related images, scripts, styles
> and fonts.
> I'm hoping to see Cache Digest come back one day, a combo of Cache Digest
> and Prefer Push means that a client (such as an API consumer) can tell
> exactly what relationships are interesting, and a server can filter this
> further by not pushing anything that the client has an up-to-date copy of.
> I will update the draft to include a comparison to Cache Digests.
> If it helps, I also wrote a bit about Prefer Push in this article:
> Evert


Robin Marx
PhD researcher - web performance
Expertise centre for Digital Media

T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94
Universiteit Hasselt - Campus Diepenbeek
Agoralaan Gebouw D - B-3590 Diepenbeek
Kantoor EDM-2.05