Re: Using PUSH to refresh a previously requested resource?

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
<ben@niven-jenkins.co.uk>wrote:

>
> 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 <
> ben@niven-jenkins.co.uk> 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
> >
> >
> >
> >
>
>