W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2013

Re: Using PUSH to refresh a previously requested resource?

From: Michael Sweet <msweet@apple.com>
Date: Wed, 03 Jul 2013 07:50:34 -0400
Cc: Roberto Peon <grmocg@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-id: <0179F949-C621-4A5D-93C8-1015A9553BF9@apple.com>
To: Ben Niven-Jenkins <ben@niven-jenkins.co.uk>
Ben,

On Jul 3, 2013, at 3: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.

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.

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

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
Received on Wednesday, 3 July 2013 11:52:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:14 UTC