Re: [httpapi] Server push - use cases

[Evert Pot <[e-mail]>]

On 2023-08-14 09:39, Willy Tarreau wrote:
> Hi Asbjørn,
>
> On Mon, Aug 14, 2023 at 12:46:42PM +0200, Asbjørn Ulsberg wrote:
>> HTTP Server Push has been debated much in the API community, although
>> widespread adoption has yet to materialise. I presented some of the use-cases
>> at the 2019 HTTP Workshop, which can be viewed here:
>>
>> https://asbjornu.github.io/prefer-push-presentation/
> Thanks for sharing. Sadly without the explanations, it's not obvious
> where you're seeing a gain in the example, because the provided example
> turns a moderately sized responses into 4 slightly smaller ones which
> together are twice as large.
>
>> Kévin Dunglas has been a pioneer in the space, with his implementation of Server Push called "Vulcain":
>>
>> https://github.com/dunglas/vulcain
>>
>> I would love to see more, not less, adoption of Server Push going forward.
>> The web isn't browser-only; if it was, the HTTP specification would have
>> dropped  support for other methods than GET + POST long ago (as an
>> example). Thankfully, it hasn't, and I think Server Push deserves a similar
>> treatment.
> For sure the web is not just browsers, but likewise it could be said
> that whenever a server decides to deliver multiple responses it could
> also coalesce them into a composite one that the client would get at
> once. And since push is useful in this case when the requester has a
> cache, populating a cache from multiple responses or from collected
> elements is not different.
>
> The real benefit of push *was* for browsers, on high-latency links,
> where the server could decide to push some objects the client had not
> yet requested. We all know the pros and cons (saving a round-trip vs
> sending objects already present there, who's responsible for that
> object's presence in the cache, etc). But here unless I'm not getting
> it from the presentation, the server did not really use push for what
> it provides, it used it as a way to split the response, just as if it
> had sent a multi-part response in some sort.
The main benefit of using push for sending representations vs compound 
responses is that with push there was a future possibility that they 
would work better with HTTP caches.

Since browsers are not aware of the identity of documents embedded in 
compound documents, they also don't know that that a compound response 
carrying a new representation should replace a cache entry for something 
it already received as an individual response.

This applies to both browsers and intermediaries of course.

The result is that many frontend frameworks and protocols like GraphQL 
end up building their own caching layers from scratch, often with fever 
features as HTTP implementations and turning off browser cach facilities 
because they're not easy to control.

Having Push itself (in the form it was released) would not have been the 
whole story for this working really well, with Push, along with Cache 
Digests[1] and Cache Groups[2] and HTTP/2 frames for cache invalidation, 
this could have gotten us closer to HTTP being used as a state 
synchronization engine.

So count me as one of the people that would have *liked* to see this 
explored more

[1]: 
https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-cache-digest-05
[2]: https://datatracker.ietf.org/doc/draft-nottingham-http-cache-groups/