Re: Prefer-Push, a HTTP extension.

[Mark Nottingham <[e-mail]>]

Hi Evert,

Just some personal thoughts. 

Although folks are generally not as optimistic about Push as they used to be, I think there's still some appetite for considering it for non-browsing use cases; as such, this is potentially interesting.

However, it's not clear at all how it'd work to me. Push is effectively hop-by-hop; intermediaries need to make a decision to send it, and that decision needs to be informed. How will a generic intermediary (like a CDN) know what link relations like "item" and "author" are, and how to apply them to a particular connection? 

It's likely that a server (whether an intermediary or an origin) is going to have many, many potential representations of these types to send, so it'll need to have knowledge of the format to be able to get those links out and push the appropriate responses. That doesn't seem generic -- unless you require all of the potentially pushable links to appear in Link headers (which doesn't seem like it would scale very well).

Pushing *all* of the resources -- or even a significant subset -- is likely to cause performance problems of its own, as there will be contention with any other requests made for bandwidth. This is one of the big things we've learned about push in the browsing use case, and I suspect it applies here as well.

Cheers,


> On 19 Nov 2018, at 3:27 pm, Evert Pot <[e-mail]> wrote:
> 
> Hi everyone,
> 
> We're a group of people collaborating on a HTTP extension. We would like
> to introduce a new header that a HTTP client can use to indicate what
> resources they would like to have pushed, based on a link relationship.
> 
> This might look something like the following request header:
> 
> GET /articles
> Prefer-Push: item, author
> 
> or
> 
> GET /articles
> Prefer: push="item, author"
> 
> We see this feature being especially useful for hypermedia-style APIs.
> Many of these types of APIs have some feature to embed resources in
> other resources in a way that is ignored by HTTP caches.
> 
> The work-in-progress draft can be read here:
> 
> <https://github.com/evert/push-please/>
> 
> My questions:
> 
> 1. Would this group be interested in adopting this draft and bringing
>   through the standards process?
> 2. We're having some discussions around which HTTP Header is more
>   appropriate. I'm curious if anyone here has any thoughts on that. The
>   main drawback is using "Prefer" is that it requires parsing a nested
>   format, but it might be more semantically appropriate for HTTP.
> 3. Our group is mostly divided on one issue: whether this header should
>   allow a client to request pushes of arbitrary depth. The cost would
>   be increased complexity (thus a higher barrier to entry). I'm curious
>   if anyone here has any insights that would help us make this
>   decision.
> 
> Arbitrary-depth example with a custom format:
> 
>  Prefer-Push: item(author, "https://example.org/custom-rel"), icon
> 
> Example with S-expression syntax:
> 
>  Prefer: push="(item(author \"https://example.org/custom-rel\") icon)"
> 
> In each of the above cases the client request the server push:
> 
> 1. The resource(s) behind the item link-relationship
>   a. The resources(s) behind the author relationship (via the "item"
>      link-relationship).
>   b. The resource(s) behind the "https://example.org/custom-rel" (via
>      the "item" link)
> 2. The resource(s) behind the icon relationship
> 
> Unfortunately structured-headers doesn't support data-structures of
> arbitrary depth, so if we want arbitrary-depth pushes, we would need to
> pick a different format. Very open to suggestions here too.
> 
> We intend to have several working implementations of this. For those
> interested in discussing, most of our discussion  is happening on a
> slack instance (http://slack.httpapis.com channel: #push-please).
> 
> Evert et al.
> 

--
Mark Nottingham   https://www.mnot.net/