Re: Addressing gzip focus

On May 15, 2014 8:24 AM, "Daniel Sommermann" <dcsommer@fb.com> wrote:
>
> Hi there,
>
> I've noticed a lot of the discussion on the list and parts of the spec
assume that gzip will be the compression algorithm everyone wants to use
for a long time (see "gzip at the server" discussion, COMPRESSED DATA flag,
HTTP/2 clients must support gzip).
>
> I'm concerned that this puts HTTP/2 in a fragile state where it will not
be able to make use of better, more secure, or faster compression
algorithms in the future. There is good reason to believe gzip is not the
best we can do. Gzip's 32 KiB window is relatively small. We've seen the
effectiveness of shared dictionaries for headers, but we also don't have a
way to easily change these dictionaries going forward. It's easy to imagine
other dictionaries or algorithms could be used for different response
content types to reap further savings.
>
> Is there a way we can factor out (some of) these references into
capabilities indicated by one side to the other via SETTINGS? E.g.
SETTINGS_SUPPORTS_COMPRESSION with the value indicating the supported
compression algorithm. The value -> compression protocol mapping could be
registered via IANA for instance. SETTINGS_COMPRESS_DATA would then use 0
for uncompressed, 1 for gzip, and 2+ for any future registered compression
algorithms+dictionaries advertised by the remote's
SETTINGS_SUPPORTS_COMPRESSION. I realize this delays SETTINGS_COMPRESS_DATA
at least 1 RTT to use "extended" compression algorithms, but for compressed
responses I don't think that is too much of an issue.
>
> Daniel
>

My original proposal for the compression setting/flag actually supported
this sort of extensibility, without extra rtts. When I get to a computer
and can search the list archive I'll be able to point to the discussion
that lead to the current compromise. I might even be able to dredge up some
of the proposed wording.