Subject: Adoption of Prefer-Push as an experimental submission

From: Evert Pot <[email-masked]>
Date: Tue, 5 May 2020 20:12:45 -0400

Dear working group,

Some time ago, I submitted the following draft:
https://tools.ietf.org/html/draft-pot-prefer-push

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:

https://github.com/badgateway/ketting

Regards,
Evert

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 6 May 2020 02:41:22 +0100

Hey Evert,

> https://github.com/badgateway/ketting
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.

Cheers
Lucas

[1] https://asbjornu.github.io/prefer-push-presentation/
[2] https://daniel.haxx.se/blog/2019/04/04/more-amsterdamned-workshop/
[3] https://lists.w3.org/Archives/Public/ietf-http-wg/2019JanMar/0033.html

---

From: Evert Pot <[email-masked]>
Date: Tue, 12 May 2020 15:40:09 -0400

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 <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Dear working group,
>
> 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:

https://evertpot.com/h2-parallelism/

Evert

---

From: Robin MARX <[email-masked]>
Date: Wed, 13 May 2020 17:10:35 +0200

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 "book.author.address" 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
complex...

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 (
https://docs.google.com/document/d/11t4Ix2bvF1_ZCV9HKfafGfWu82zbOD7aUhZ_FyDAgmA/edit#)
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,
Robin

On Tue, 12 May 2020 at 21:40, Evert Pot <[email-masked]> wrote:

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

-- 

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

www.uhasselt.be
Universiteit Hasselt - Campus Diepenbeek
Agoralaan Gebouw D - B-3590 Diepenbeek
Kantoor EDM-2.05