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

RE: In Defense of Header Compresson

From: Robert Brewer <fumanchu@aminus.org>
Date: Thu, 16 Aug 2012 07:36:53 -0700
Message-ID: <F1962646D3B64642B7C9A06068EE1E64164A0AB3@ex10.hostedexchange.local>
To: "Ilya Grigorik" <ilya@igvita.com>, "Henrik Frystyk Nielsen" <henrikn@microsoft.com>
Cc: "Patrick McManus" <pmcmanus@mozilla.com>, <ietf-http-wg@w3.org>
Ilya Grigorik wrote:
> > On Wed, Aug 15, 2012 at 4:36 AM, Henrik Frystyk Nielsen <henrikn@microsoft.com> wrote:
> > I completely agree that if you have very small entity bodies
> > then maturally the header size will matter getting more
> > requests into the pipe faster. However, in the tests that we
> > have done with actual data the size of the entity bodies was
> > large enough that the impact was minimal. This is especially
> > the case if you also do bundling/minification as it naturally
> > leads you to large entities.
> It's worth keeping in mind that we're seeing more and more web
> "applications", as opposed to pages. Frameworks like backbone,
> angular, etc, all frequently make very small (usually JSON
> encoded) requests to indicates record updates, or to pull
> specific objects on demand, from an HTTP endpoint.. All of that
> to say: many of these requests are just a few hundred bytes.
> Your typical CRUD operations are all great examples: a lotta
> headers for a tiny payload and a 204 response. The overhead
> there is huge, which is why we're seeing people starting to
> invent their own protocols. e.g. SwaggerRocket:
> http://blog.wordnik.com/introducing-swaggersocket-a-rest-over-websocket-protocol

> They shouldn't have to do this...

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.

Robert Brewer
Received on Thursday, 16 August 2012 14:37:20 UTC

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