Re: Issue #73: definition of deflate encoding

While doing some recent packet capture / object extraction work as part of 
an effort to study the current degree of content-encoding by live web 
sites, I needed to remove gzip encoding ... naively thought I could just
save the data as a *.gz file (tried .zip also) and post process it. Found
about 800 gzip encoded responses of about 2400 and decoded them all 
assuming no gzip or zlib wrapper. I'm not 100% sure about my conclusions
(I probably could provide a couple example payloads still gzip-ed in file 
form if someone with more knowledge would care to look), but it appears to 
me that 'some incorrect' is likely 'most implementations are incorrect'.

Dave Morris

On Wed, 29 Jul 2009, Henrik Nordstrom wrote:

> http://trac.tools.ietf.org/wg/httpbis/trac/ticket/73
>
> As most of you know our definition of deflate is somewhat contradictory
> with the referenced RFCs definitions, as is already stated in our
> definition:
>
>   deflate
>        The "zlib" format defined in RFC 1950 [31] in combination with
>        the "deflate" compression mechanism described in RFC 1951 [29].
>
> As result of this inconsistent name selection there is several
> implementations that implement "deflate" to literally mean the deflate
> encoding without the zlib wrapper.
>
> Proposed solution is to add a note on this fact
>
>                Note that some incorrect implementations may send
>                deflate encoding without a zlib wrapper when using this
>                encoding.
>
>
> On a related note I should perhaps also remind you that gzip is actually
> also deflate but with a gzip wrapper instead of zlib. To be consistent
> or "deflate" term should really had been "zlib". And both are well
> defined file format which also happens to be the same name of the
> application/library creating the format in question.
>
> Regards
> Henrik
>

Received on Thursday, 30 July 2009 05:17:47 UTC