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