Re: Prefer-Push, a HTTP extension.

On 11/24/18 12:23 AM, Willy Tarreau wrote:
> 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" ?

The idea of bundled resources is actually extremely common, and one of
the major reasons we want this draft is actually to try and come up with
ways to avoid this. In the draft I talk about 'embedding', but really
the mechanism you describe is similar.


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

I think using the early hints mechanism is a good idea, and potentially
a solution for a subset of cases.

The cases it doesn't address as well are:

* Situations where a server can optimize for a set of requests /
  responses. (example: give me all members of a collection)
* Situations where using Link headers are undesirable. Most hypermedia-
  style applications will already have a defined format for links.
  Moving the entire response body in headers might be a solution for
  some cases but not all.

Evert

Received on Sunday, 25 November 2018 21:28:43 UTC