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 18:28:34 -0800
Message-ID: <CAP+FsNesBJ_s15StYJLJoSOSJyB+Yx3C8p7kMiK_qH_9Q1F-Nw@mail.gmail.com>
To: Frédéric Kayser <f.kayser@free.fr>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
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).
>
>
>
Received on Tuesday, 22 January 2013 02:29:03 GMT

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