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

[Roberto Peon <[e-mail]>]

The idea that is in my mind is that people would innovate and the best
ideas would win out. :)

Personally, I suspect there are a few winning approaches, the first being
page static analysis and rewrite (which you mention) which is in use for
HTML for HTTP today, the second being the server learning based on what the
clients ask for (either by examination of the request stream, examination
of referrers, or reaping of timing stats about page loads), and the third
being the content developer specifies.

The latter two approaches are in use today, with mod_spdy pushing what the
content-owners tells it to (by including a 'x-associated-resource' from
cgi, "Headers" directive, or similar), and with Jetty doing some learning.
I don't know of anyone doing the first yet, but, I'd guess it was only a
matter of time and would likely be a selling feature in/for the various
acceleration services.

-=R


On Tue, Jan 22, 2013 at 12:19 AM, Frédéric Kayser <[e-mail]> wrote:

> Ok,
> I'm familiar with the data URI scheme used by front-end developers. Since
> "push" is way closer to the server it will probably require the creation of
> "pushing rules" (if this HTML page is requested push this CSS file and
> these background images along) or is it envisioned that the server could
> parse HTML/CSS files to automatically pick up other resources to push, or
> even train some kind of IA to learn which file request is usually followed
> by other requests and anticipate such patterns?
>
> Frédéric
>
> Le 22 janv. 2013 à 03:23, William Chan (陈智昌) a écrit :
>
> > Note that web developers are already pushing resources. It's called
> > resource inlining
> > (https://developers.google.com/speed/docs/pss/InlineSmallResources).
> > These resources do not have their own URLs, are usually inlined into
> > uncacheable documents, and thus are rarely cached at all. Using server
> > push will enable them to have their own URLs and be cached by the
> > client if that makes sense.
> >
> > Remember, once you issue a request to a server, the server can send
> > you anything in return. It's in our interest to provide them better
> > facilities for sending responses, or they will hack around it in less
> > optimal ways.
>
>
>