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

Re: In Defense of Header Compresson

From: Ilya Grigorik <ilya@igvita.com>
Date: Thu, 16 Aug 2012 15:59:27 -0700
Message-ID: <CAKRe7JF_PojT=fWNNptCcMWGzTVKBGM71SZjQJ_+y-CUWbOM8w@mail.gmail.com>
To: Robert Brewer <fumanchu@aminus.org>
Cc: Henrik Frystyk Nielsen <henrikn@microsoft.com>, Patrick McManus <pmcmanus@mozilla.com>, ietf-http-wg@w3.org
> They shouldn't have to invent their own protocols because there are
> already plenty of protocols optimized for small-grained messages. That
> doesn't mean HTTP, which is one of the few protocols which is optimized for
> large-grained messages (in order to trade efficiency for scalability), has
> to change to become one of them.

I believe that would be a shortsighted call to make. Besides, show me
another protocol available in the browser, which *is* the distribution
platform for all these apps? It's HTTP, plain and simple.. or build on your
own, on top of WebSockets.

Median size per GET: 2.36KB -

Add ~800 bytes of request/response headers on top, and we're spending
25-30% on headers (that is, if you're lucky and can avoid adding cookies to
that as well). Also, there is no sign that we're going to stop putting
*more* stuff into the headers. User-agent and Cookies are the best known
offenders, but what about even things like upcoming CSP suport?

X-Content-Security-Policy: allow 'self'; img-src *; \
                           object-src media1.com media2.com *.cdn.com; \
                           script-src trustedscripts.example.com

And that's just the beginning.

In any case, my meta-point is simple: I believe Patrick's numbers may
well underestimate the prevalence of short requests/responses. We should
factor in the long-lived apps that stay open in the browser and rely on
small periodic pings (aka, any "ajax" app like gmail, docs, and so forth,
not to mention the billions of beacons for analytics and the like).

Received on Thursday, 16 August 2012 23:00:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:06 UTC