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

Re: SPDY Header Frames

From: Patrick McManus <pmcmanus@mozilla.com>
Date: Tue, 17 Jul 2012 12:23:02 -0400
Message-ID: <1342542182.30417.9.camel@ds9>
To: James M Snell <jasnell@gmail.com>
Cc: Phillip Hallam-Baker <hallam@gmail.com>, 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>
when comparing against deflate you need to consider all the transactions
after the first one too. They compress much more effectively than the
first. (generally > 90% ratios). In a stream of ~80 requests, the first
one is only part of the story[*].

-P

[*] I didn't say it was an unimportant part :)

On Tue, 2012-07-17 at 07:36 -0700, James M Snell wrote:
> 
> 
> 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 compression.
> 
> 
> 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 16:23:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 17 July 2012 16:23:46 GMT