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: Roberto Peon <grmocg@gmail.com>
Date: Mon, 21 Jan 2013 20:01:40 -0800
Message-ID: <CAP+FsNeCZG1b35JEpyNgVo+3BpAEFSiOCOnHb=iNPfkQcuB92Q@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: Frédéric Kayser <f.kayser@free.fr>, HTTP Working Group <ietf-http-wg@w3.org>
On Mon, Jan 21, 2013 at 7:35 PM, Mark Nottingham <mnot@mnot.net> wrote:

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

The same way one would in a non-push world-- determine if it is mobile and
serve the most appropriate content... :)
-=R

>
> 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 04:02:08 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 22 January 2013 04:02:13 GMT