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

Re: Some general thought on CRIME and Compression and Headers

From: Poul-Henning Kamp <phk@phk.freebsd.dk>
Date: Sat, 12 Jan 2013 12:20:09 +0000
To: Frédéric Kayser <f.kayser@free.fr>
cc: ietf-http-wg@w3.org
Message-ID: <33883.1357993209@critter.freebsd.dk>
--------
In message <6D66A12F-6B70-4CD5-9CB1-D24ED597B1C6@free.fr>, =?iso-8859-1?Q?Fr=E9d=E9ric_Kayser?= writes:

>gzip/deflate streams are made of different types of blocks cf. RFC 1951 
>http://www.ietf.org/rfc/rfc1951.txt (btype 0 is non compressed - fixed 
>length-, btype 1 uses predefined Huffman tables, and btype 2 embeds 
>Huffman tables specially tailored for the current data). The stream 
>could switch to btype 0 when sensitive data has to be compressed, and 
>afterwards this region could be excluded from LZ matches to avoid reuse, 
>the resulting stream would be perfectly compatible with current Deflate 
>decoders implementations.

I spent quite some time hacking code to do interesting things
with gzip blocks (ESI support on gzip'ed objects if you must know).

While technically feasible, I would not recommend requiring
mainstream implementations to deal with "naked" GZIP blocks, in
particular since debugging compressed streams is not even close to
fun for anybody.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.
Received on Saturday, 12 January 2013 12:20:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 12 January 2013 12:20:39 GMT