Re: Prefer-Push, a HTTP extension.

Hello,

On Fri, Nov 23, 2018 at 07:23:10PM -0500, Evert Pot wrote:
> A client can only know which links are available and where they point
> to, after the initial response came back.

In fact, with Early Hints (RFC8297) the client can get these info *before*
the initial response, and can even start to preload from different origin
servers if needed. The waste of bandwidth will only be a few tens of bytes
to pass the links and if the client already cached the elements, there is
zero cost here. If the client only cached *some* elements (most likely
case), it will only request the missing ones.

> After that, I agree, a client
> can just do GET requests for every linked resource individually and get
> the same performance (not considering the fact that servers can optimize
> for groups of similar requests).
(...)

> The biggest use-case from my perspective is for hypermedia-style API's,
> such as HAL & Siren. In these cases clients generally do have knowledge
> of which links might potentially be available, but not where they will
> be pointing to.
> 
> Solving this for HTTP-services that don't follow this paradigm is out of
> scope for this (for me at least).

Then maybe it might be worth trying to think about a notion of "bundled"
resources for such use cases, without involving the semantics of a GET
and multiple PUSH in return. This could possibly even allow for better
caching of the whole bundle. I don't know how to do that but we've seen
stuff like "content-type: multipart", maybe this already matches your
use case well where the client asks "give me this and all dependent
resources" ?

> Yes, sorry, this is just to avoid having to wait for the first response
> (or subsequent responses in case a bigger part of the graph is
> requested), I don't expect it to optimize the case where a client
> already knows the target of the links.

Please take a look at RFC8297, as it may possibly be interesting for your
use case if your concern is the server's initial response time.

Thanks,
Willy

Received on Saturday, 24 November 2018 05:23:28 UTC