Re: Using PUSH to refresh a previously requested resource?

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

Received on Wednesday, 3 July 2013 08:37:54 UTC