On Mon, Jul 16, 2012 at 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. > That's why you can't make it optional :-) > > 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. > Let me know if you have a specific security question to raise. > > 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 ?) > OK - we did consider this approach, but it has real problems as you now have multiple URLs which contain index.html, style.css and logo.png. It makes it very difficult to find items in your cache if you allow multiple URLs to address the same resource. But worse, it means that you lose the per-resource response headers that you had before. So now all 3 of those items have a single set of cache control headers, which is undesirable. You could define the zip in a 'smart' way, so that the URLs are preserved and the client pulls them all apart, but you quickly get into a new multi-part format which has a lot of subtle nuance (see mime!). BTW - what you've just described here is basically what 'spriting' does - combine items in a non-individually addressable way. Mike > > -- > 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:44:37 UTC