W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2012

Re: Re[2]: HTTP2 Expression of Interest : Squid

From: Roberto Peon <grmocg@gmail.com>
Date: Mon, 16 Jul 2012 09:20:17 -0700
Message-ID: <CAP+FsNcoyx7=EfXLezzHGq-3_+BWTwhLQj8dGObvKpSsHMMarg@mail.gmail.com>
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
Cc: Amos Jeffries <squid3@treenet.co.nz>, Willy Tarreau <w@1wt.eu>, Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>, tom <zs68j2ee@gmail.com>, Adrien de Croy <adrien@qbik.com>, James M Snell <jasnell@gmail.com>, Mike Belshe <mike@belshe.com>
Bundling has combinatorial explosion problems. It is basically an alternate
server push mechanism.

If we say that we're supposed to look inside the envelope of the bundle,
you end up doing the same as the resource-defined server push that is
implemented in spdy, but you must know about all possible resources that
the dynamic page will generate at the time you create the bundle. This is
basically impossible. You must still advertise which resources will be sent
in the bundle before the user-agent interprets the section of the main
resource which refers to it, else suffer races where the user-agent has
requested an object which is being pushed but has not yet arrived at the

If we don't look in the envelope,  security becomes more difficult. It
becomes costly to do filtering or caching.

Because everything is in one resource, you may not be able to reject
resources as you can with individually identified pushed resources.

On Jul 16, 2012 7:53 AM, "Poul-Henning Kamp" <phk@phk.freebsd.dk> wrote:

> In message <CABaLYCusRpEs7bicEq+_jViW5k-X9ehip=
> RJe8wD51Z-B-UH2A@mail.gmail.com>
> , Mike Belshe writes:
> >But seriously, who are these clients which will reject the pushes?
> I think this may be asking the wrong question.
> Yes, there will be clients which reject server-push, either because
> they only implemented the easy part of the specs, or because the
> voices from the tinfoil hat tells them to, but they are not
> important.
> The people who will have a problem with server-push are the
> security people, and the people who have to deal with the
> complexity it introduces.
> As I understand the desire for server-push it basically is this:
>         Client:
>                 Give me "index.html"
>         Server:
>                 Here it comes, and here are "style.css" and
>                 "logo.png" which you'll also need.
> That makes a lot of sense, but I would solve it this way:
>         Client:
>                 Give me "index.html"
>         Server:
>                 Here is "index.zip" which contains "index.html"
>                 and some other objects you'll need.
> No protocol complexity, the objects are bound together and we
> get compression too.  (.zip is just an example though, there
> may be better designs, as I assume interleaving might be
> desired ?)
> --
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk@FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
Received on Monday, 16 July 2012 16:20:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:02 UTC