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

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

From: Mark Nottingham <mnot@mnot.net>
Date: Tue, 22 Jan 2013 14:35:13 +1100
Cc: Frédéric Kayser <f.kayser@free.fr>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <FF21A5E5-0F41-45BE-8A08-7915E9632A86@mnot.net>
To: Roberto Peon <grmocg@gmail.com>
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 :-/


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

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:09 UTC