W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2014

Re: h2#404 requiring gzip and/or deflate

From: Michael Sweet <msweet@apple.com>
Date: Fri, 21 Feb 2014 15:17:59 -0500
Cc: Bjoern Hoehrmann <derhoermi@gmx.net>, Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-id: <61A63060-5F20-402C-9E6B-FF7045AAB0FE@apple.com>
To: Willy Tarreau <w@1wt.eu>
Willy,

On Feb 20, 2014, at 3:08 PM, Willy Tarreau <w@1wt.eu> wrote:
> On Thu, Feb 20, 2014 at 08:38:36PM +0100, Bjoern Hoehrmann wrote:
>>> I want to clarify the text above... Do we want to mandate (i.e., use
>>> MUST) 1. gzip or 2. gzip+deflate ?
>> 
>> The gzip format is a container format and the container includes data
>> like filename, operating system, checksums, timestamps, comments, and
>> a DEFLATE stream with the compressed data.
> 
> The other difference is the use of the faster adler32 checksum in deflate
> instead of crc32 in gzip, so *if* we want to mandate something, deflate
> is cheaper for both ends. That said, I'm still very concerned that we
> want to mandate such antique bit-oriented algorithms which are extremely
> slow and memory invasive while we have many much better ones such as
> snappy, lz4, quicklz and I-don't-know-what which are much more friendly
> for both ends and better suited for the 21th century's machines and
> networks.

Other than lz4, it looks like the others need at least an order of magnitude more memory than gzip/deflate, which is particularly important for servers and embedded clients since they tend to be memory constrained...

Regardless, there is an IANA registry for this, so nothing prevents future clients and servers from supporting better compression algorithms as they become available/accepted.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


Received on Friday, 21 February 2014 20:18:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:24 UTC