Subject: Addressing gzip focus

From: Daniel Sommermann <[email-masked]>
Date: Wed, 14 May 2014 15:22:36 -0700

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

---

From: Matthew Kerwin <[email-masked]>
Date: Thu, 15 May 2014 08:51:13 +1000

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

---

From: Matthew Kerwin <[email-masked]>
Date: Thu, 15 May 2014 10:45:27 +1000

> that lead to the current compromise. I might even be able to dredge up some

​Here's the original proposal: <
http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0059.html>

Later versions [1] reduced field sizes to 8 bits, and cleaned up some
wording, but the main gist remained the same. I also wavered back and forth
on whether/how to include an identity encoding (0x0).

This is the point where we decided to go with a single bit gzip-or-nothing
flag: <http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0301.html

Cheers

[1] http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0149.html​
Note that the github link is dead.

-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/

---

From: Martin Thomson <[email-masked]>
Date: Wed, 14 May 2014 19:04:36 -0700

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.