Re: Addressing gzip focus

Hi Daniel,

I don't think that your assumption is correct in two ways :)

We will still offer negotiation for Content-Encoding, allowing for new and
better schemes to be negotiated (and worse ones too).

The point is that we want to raise the minimum above identity, or at least
give servers that option.

For frame compression, yes, you are right. We don't have flexibility. The
cost of flexibility is complexity. That was a late addition on a trial
basis only. If we fall in love with the notion, perhaps we can invest more
heavily in it by enabling negotiation. That would be fairly disruptive.
Matthew's proposal being just one of many such options we could consider.
On May 14, 2014 4:25 PM, "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
>
>