Re: How to stop receiving a pushed resource? (I-D Action: draft-ietf-httpbis-http2-01.txt)

I'd be interesting to hear what people running robots, etc. have to think about this.

Also, it'd be REALLY nice to think about about what this means for responsive design; e.g., if I'm a mobile, I don't need the desktop stylesheet, and maybe not some of those images too. So, how does that work in a push world?

Personally -- the most immediate problem I have with this is figuring out how to show push in REDbot :-/

Cheers,



On 22/01/2013, at 1:28 PM, Roberto Peon <grmocg@gmail.com> wrote:

> Push is simply better inlining, with prioritization and cancellation.
> 
> So, if you don't want a push, you'd cancel the stream, wasting at worst one BDP worth of bandwidth, and at best near zero (since the push is announced while the main resource is loading).
> 
> Note that if server push is disabled, then servers will inline resources which is strictly worse as it is impossible to prioritize or cancel (or cache) such, leading to *increased * bandwidth usage and latency.
> 
> -=R
> 
> On Jan 21, 2013 5:38 PM, "Frédéric Kayser" <f.kayser@free.fr> wrote:
> Hello,
> is this the mechanism clients should use to stop receiving pushed resources they already have in their local cache?
> How are servers supposed to guess what to push or not? Is it be based on modification date, could the clients send some hints?
> 
> Frédéric
> 
> > 4.3.2.  Client implementation
> >
> >    When fetching a resource the client has 3 possibilities:
> >
> >       the resource is not being pushed
> >
> >       the resource is being pushed, but the data has not yet arrived
> >
> >       the resource is being pushed, and the data has started to arrive
> >
> >    When a SYN_STREAM and HEADERS frame which contains an Associated-To-
> >    Stream-ID is received, the client must not issue GET requests for the
> >    resource in the pushed stream, and instead wait for the pushed stream
> >    to arrive.
> >
> > [...]
> >
> >    To cancel individual server push streams, the client can issue a
> >    stream error (Section 3.4.2) with error code CANCEL.  Upon receipt,
> >    the server MUST stop sending on this stream immediately (this is an
> >    Abrupt termination).
> 
> 

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

Received on Tuesday, 22 January 2013 03:35:42 UTC