> I have no idea what it was like for SPDY, but given that the "innovative" header compression feature somehow survived, I'm guessing not good.
Considering the overwhelming majority of HTTP requests are nearly all headers, and request headers see 88% compression with SPDY [0], you seem to have an awfully negative view of header compression.
The complaint is about how the compression is implemented-
Header compression is a good feature with real world applications,
and deflate with persistent context is a good approach to achieve
it. A fixed dictionary is probably not very effective as it
complicates the implementation while only providing initial value to
the compression. As an example, this is how the average requests
sizes compares between HTTP and SPDY in different modes, using the
set of captured headers used to train the current SPDY 3 dictionary.
HTTP 821.1
HTTP zlib compressed 543.5
HTTP compressed with dictionary 497.0
SPDY 913.7
SPDY zlib compressed 606.5
SPDY compressed with dictionary 517.0
I.e. Just putting the HTTP request in a SPDY stream (after removing
disallowed headers) only differs by 20 bytes to SPDY binary header
format with dictionary based zlib compression. The benefit of using
a dictionary basically goes away entirely on the subsequent request.
Considering the overwhelming majority of HTTP requests are nearly all headers, and request headers see 88% compression with SPDY [0], you seem to have an awfully negative view of header compression.
[0] http://dev.chromium.org/spdy/spdy-whitepaper