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

Re: SPDY Header Frames

From: James M Snell <jasnell@gmail.com>
Date: Tue, 17 Jul 2012 07:36:02 -0700
Message-ID: <CABP7Rbc9QqfmVCGvmMCYDNHC5WSoC+A9HRqSLfJq1ayNdnd3qA@mail.gmail.com>
To: Phillip Hallam-Baker <hallam@gmail.com>
Cc: Roberto Peon <grmocg@gmail.com>, Poul-Henning Kamp <phk@phk.freebsd.dk>, Willy Tarreau <w@1wt.eu>, HTTP Working Group <ietf-http-wg@w3.org>
On Tue, Jul 17, 2012 at 6:48 AM, Phillip Hallam-Baker <hallam@gmail.com>wrote:

> [snip]
> There are design issues in SPDY that I find a little troubling. I much
> prefer using a compact encoding for headers over compression. A
> compact encoding is easier to implement and much easier to debug. It
> is also more robust as single bit errors are less likely to lead to
> catastrophe.

I definitely have to agree with preferring the compact encoding over
compression. At the moment, I'm just not seeing the benefit of applying the

FWIW, I made a few additional tweaks to my test.. namely, reducing the
header value size to max(int16), and eliminating the charset header with
the assumption everything would be UTF-8 and the header block becomes a
simple 116 bytes in length. The compressed size (done properly this time,
albeit using the existing SPDY dictionary that obviously would need to be
tweaked to account for the new structure) comes out to only 114 bytes...

Just for fun, I added in my chrome browser's user-agent string, swelling
the encoded size to 237 bytes... compressed at 220. Again, Not enough of a
savings to justify the additional cost.... and yeah, let's definitely see
what we can do about fixing the whole user-agent crap-fest.

- James
Received on Tuesday, 17 July 2012 14:36:56 UTC

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