Re: Adoption of Prefer-Push as an experimental submission

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 <me@evertpot.com> 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 <me@evertpot.com> wrote:
>
>> 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
>>
>>
> 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
>


-- 

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