Subject: Using PUSH to refresh a previously requested resource?

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 3 Jul 2013 08:42:39 +0100

Colleagues,

I've been pondering the use of server push in non-browser environments. As currently designed server push is meant for pushing resources associated with the originally requested resource. Unless I've missed something it doesn't allow for the server to push an updated version of a previously requested resource.

What I'm thinking of is something like a webservice where the client is regularly polling the server for a resource (e.g. completion status of a running 'job') where the server may decide it is advantageous to push a refreshed/updated version of the resource to provide a more timely update to the client (e.g. as soon as the 'job' completes) rather than waiting for the client to next poll for itself.

I read the semantics of PUSH_PROMISE as roughly "based on the request you made here are some different resources associated with the one you requested that might be useful" but the semantics I think I need are "based on the request you made here is an updated version of that resource" or possibly (I need to think about it more) "based on a previous request you made here is an updated version of that resource 'piggybacked' on a response to a request for a different resource".

Am I being overly restrictive in my interpretation of associated and an updated resource is in fact 'associated' with the older version of the same resource?

The piggybacking of a PUSH for an unrelated resource (i.e. not referenced in the requested resource) doesn't appear to be accommodated by the (spirit of the) current spec but it's not clear to me if it's actively prohibited or just that the current spec wording implies (to me) it is not intended/allowed without saying so explicitly.

Thanks
Ben

---

From: Roberto Peon <[email-masked]>
Date: Wed, 3 Jul 2013 00:47:50 -0700

I may not be understanding properly, but isn't what you're talking about
solved with a request whose response doesn't return until the server wants
it to (a.k.a. hanging get)?

-=R

On Wed, Jul 3, 2013 at 12:42 AM, Ben Niven-Jenkins
<[email-masked]>wrote:

> Colleagues,
>
> I've been pondering the use of server push in non-browser environments. As
> currently designed server push is meant for pushing resources associated
> with the originally requested resource. Unless I've missed something it
> doesn't allow for the server to push an updated version of a previously
> requested resource.
>
> What I'm thinking of is something like a webservice where the client is
> regularly polling the server for a resource (e.g. completion status of a
> running 'job') where the server may decide it is advantageous to push a
> refreshed/updated version of the resource to provide a more timely update
> to the client (e.g. as soon as the 'job' completes) rather than waiting for
> the client to next poll for itself.
>
> I read the semantics of PUSH_PROMISE as roughly "based on the request you
> made here are some different resources associated with the one you
> requested that might be useful" but the semantics I think I need are "based
> on the request you made here is an updated version of that resource" or
> possibly (I need to think about it more) "based on a previous request you
> made here is an updated version of that resource 'piggybacked' on a
> response to a request for a different resource".
>
> Am I being overly restrictive in my interpretation of associated and an
> updated resource is in fact 'associated' with the older version of the same
> resource?
>
> The piggybacking of a PUSH for an unrelated resource (i.e. not referenced
> in the requested resource) doesn't appear to be accommodated by the (spirit
> of the) current spec but it's not clear to me if it's actively prohibited
> or just that the current spec wording implies (to me) it is not
> intended/allowed without saying so explicitly.
>
> Thanks
> Ben
>
>
>
>

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 3 Jul 2013 17:51:03 +1000

I personally see PUSH purely as an optimistic cache update (and we seemed to get agreement on this view in SF), so I think your use case is in-bounds. As I said there, if the model for PUSH isn't expressed in terms of HTTP caching, I think we're far into the weeds.

Cheers,

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

---

From: James M Snell <[email-masked]>
Date: Wed, 3 Jul 2013 00:56:02 -0700

The push promise is an implicit get the server proactively assumes the
client will want to make so it goes ahead and starts sending a response
without waiting for the client.  There really is nothing that says that
pushed resource can't be used for the purpose you describe but it's not
clear what kind of API the user agent may provide,  if any,  for accessing
the pushed stream.  You likely would just treat it like you would any
hanging get and the fact that it's a pushed stream would be completely
transparent.

That said,  there are likely better solutions that would work better, such
as a websocket over http/2 variation.
On Jul 3, 2013 12:45 AM, "Ben Niven-Jenkins" <[email-masked]>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 3 Jul 2013 08:57:39 +0100

On 3 Jul 2013, at 08:47, Roberto Peon wrote:

> I may not be understanding properly, but isn't what you're talking about solved with a request whose response doesn't return until the server wants it to (a.k.a. hanging get)?

Yes it could be, I was pondering whether PUSH could be used to make it server driven instead.

Ben

> 
> -=R
> 
> 
> On Wed, Jul 3, 2013 at 12:42 AM, Ben Niven-Jenkins <[email-masked]> wrote:
> Colleagues,
>

---

From: Roberto Peon <[email-masked]>
Date: Wed, 3 Jul 2013 01:33:52 -0700

A hanging-get, assuming the resource isn't marked cacheable, would be
end-to-end.
A PUSH, however, is currently intended to be point-to-point right now, as
opposed to end-to-end.

Perhaps that shouldn't be (but I think it should) and you can convince
everyone about it :)
Or if it should be, perhaps there needs to be another version to support
your use-case through a proxy.

-=R

On Wed, Jul 3, 2013 at 12:57 AM, Ben Niven-Jenkins
<[email-masked]>wrote:

> > I've been pondering the use of server push in non-browser environments.
> As currently designed server push is meant for pushing resources associated
> > I read the semantics of PUSH_PROMISE as roughly "based on the request
> you made here are some different resources associated with the one you
> > The piggybacking of a PUSH for an unrelated resource (i.e. not
> referenced in the requested resource) doesn't appear to be accommodated by
> the (spirit of the) current spec but it's not clear to me if it's actively
> prohibited or just that the current spec wording implies (to me) it is not

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 3 Jul 2013 09:37:30 +0100

On 3 Jul 2013, at 09:33, Roberto Peon wrote:

> A hanging-get, assuming the resource isn't marked cacheable, would be end-to-end.
> A PUSH, however, is currently intended to be point-to-point right now, as opposed to end-to-end.

Ah! I'd overlooked that aspect of PUSH, thanks. Ben

> 
> Perhaps that shouldn't be (but I think it should) and you can convince everyone about it :)
> Or if it should be, perhaps there needs to be another version to support your use-case through a proxy.
> 
> -=R
> 
> 
> On Wed, Jul 3, 2013 at 12:57 AM, Ben Niven-Jenkins <[email-masked]> wrote:
>

---

From: Roberto Peon <[email-masked]>
Date: Wed, 3 Jul 2013 01:39:28 -0700

Don't be afraid to push us if we're getting this wrong :)
-=R

On Wed, Jul 3, 2013 at 1:37 AM, Ben Niven-Jenkins
<[email-masked]>wrote:

> > > I may not be understanding properly, but isn't what you're talking
> about solved with a request whose response doesn't return until the server
> wants it to (a.k.a. hanging get)?
> >
> > > I've been pondering the use of server push in non-browser
> environments. As currently designed server push is meant for pushing
> resources associated with the originally requested resource. Unless I've
> missed something it doesn't allow for the server to push an updated version
> of a previously requested resource.
> > >
> > > What I'm thinking of is something like a webservice where the client
> is regularly polling the server for a resource (e.g. completion status of a
> > > Am I being overly restrictive in my interpretation of associated and
> an updated resource is in fact 'associated' with the older version of the
> same resource?
> > >

---

From: James M Snell <[email-masked]>
Date: Wed, 3 Jul 2013 01:44:46 -0700

I certainly do like the use case and would love to have that capability,
however I think it falls more into the domain of websockets or some other
subprotocol layered on top of the framing layer alongside the http
semantics. Keeping a narrower focus for push resources is best.
On Jul 3, 2013 1:41 AM, "Roberto Peon" <[email-masked]> wrote:

> On Wed, Jul 3, 2013 at 1:37 AM, Ben Niven-Jenkins <[email-masked]
> > wrote:
>
>>

---

From: Michael Sweet <[email-masked]>
Date: Wed, 03 Jul 2013 07:50:34 -0400

Ben,

> Yes it could be, I was pondering whether PUSH could be used to make it server driven instead.

Conceptually this could also be done as a "hanging PUSH" - rather than the server sending multiple PUSH's it might have a single long-lived PUSH that feeds (chunked) event messages (or whatever) back to the client.  Chat rooms, live blogs, hardware monitoring, etc. could use this as an alternative to the traditional hanging GET or POST.

I think such a server PUSH is still in the spirit of caching - the client requests a resource and is periodically sent updates via one or more server PUSH's.  Whether such an implementation offers any benefits over a hanging GET or POST would likely depend on the situation.

>> The piggybacking of a PUSH for an unrelated resource (i.e. not referenced in the requested resource) doesn't appear to be accommodated by the (spirit of the) current spec but it's not clear to me…

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair