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

Re: #445: Transfer-codings

From: Frédéric Kayser <f.kayser@free.fr>
Date: Fri, 4 Apr 2014 23:25:20 +0200
Cc: <msweet@apple.com>, <martin.thomson@gmail.com>, <matthew@kerwin.net.au>, <mnot@mnot.net>, <squid3@treenet.co.nz>, <ilari.liusvaara@elisanet.fi>, <nilsson@opera.com>, <ietf-http-wg@w3.org>, <fielding@gbiv.com>, <derhoermi@gmx.net>, <roland@zinks.de>, <C.Brunhuber@iaea.org>, <jasnell@gmail.com>
Message-Id: <DE80A874-7DD5-4A93-8456-02ACE5AC0943@free.fr>
To: <K.Morgan@iaea.org> <K.Morgan@iaea.org>
My $0.02: why pick Gzip over Deflate?
A Deflate stream is shorter than Gzip, Gzip is a file format which eventually embeds a file name, holds a time stamp — 32 bits epoch than will not even survive past January 2038 — and defines a compression method which has always been Deflate (and will probably never change) followed by Deflate compressed data. Why bother including all this extra payload and not use a stripped down Deflate (RFC 1951) or more precisely a Zlib stream (RFC 1950)? 
I know that some server vendors had a bogus implementation of Deflate in the past and send a raw Deflate stream without the Zlib header and checksum, Billy Hoffman explained this blunder and why nowadays only Gzip is used: http://zoompf.com/blog/2012/02/lose-the-wait-http-compression .
Why not course correct now and pick the simpler Deflate over Gzip?

<K.Morgan@iaea.org> <K.Morgan@iaea.org> wrote:

> On Apr 4, 2014, at 21:17, "msweet@apple.com<mailto:msweet@apple.com>" <msweet@apple.com<mailto:msweet@apple.com>> wrote:
>> My $0.02: Since "Transfer-Encoding: gzip" would apply
>> to both HTTP/1.1 and HTTP/2, we should define gzip in
>> a separate document that applies to both. ...
> Gzip transfer coding is already explicitly defined in Section 4 of the update to RFC2616 (HTTP-p1) - which is referenced in our proposal below.
> Subsection 4.2.3 defines gzip:
> http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-26#section-4.2.3
> If there are specific security issues related to gzip then they apply equally to C-E gzip (which is implicitly required for clients to support already). As we mentioned below, one of the benefits of using TE/Transfer-Encoding over a framing layer transfer coding mechanism is that the decision to TE compress can be made at the same level as deciding to CE compress.

Received on Friday, 4 April 2014 21:25:56 UTC

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