Re: SPDY Header Frames

Noted and certainly understood. I'm still not convinced... assuming we can
come up with optimized binary encodings for the overwhelming majority of
the most common headers, eliminate redundant headers across requests, and
deal properly with the Crap that is Cookies and User-Agent headers, the
header block can be made to be very compact without applying any
compression.

If anything, I think I'm leaning more towards limiting the headers included
in the SYN_STREAM and SYN_REPLY frames to only a core set of uncompressed,
optimized headers but allowing HEADERS frames to optionally apply
compression. Doing so provides a reasonable balance between the two
approaches while reducing the amount of work routing intermediaries have to
do.

- james

On Tue, Jul 17, 2012 at 9:23 AM, Patrick McManus <pmcmanus@mozilla.com>wrote:

> 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
>
>
>