W3C home > Mailing lists > Public > public-webappsec@w3.org > March 2014

Re: [integrity] What should we hash?

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Thu, 13 Mar 2014 02:15:36 -0400
Message-ID: <53214D08.6030303@mit.edu>
To: Devdatta Akhawe <dev.akhawe@gmail.com>
CC: Mark Nottingham <mnot@mnot.net>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On 3/13/14 2:09 AM, Devdatta Akhawe wrote:
> The spec does talk about downloads. Seems to me that my browser does
> undo the encodings when I download something. Say I save a text file
> sent over HTTP. with Content Encoding set to gzip. It won't give me a
> txt.gz file, right?

It depends.

What Firefox implements is the following.  When saving a file, we 
compare the declared Content-Encoding to the extension of the filename 
we're planning to save the file with (this last typically comes from the 
URL or from a Content-Disposition header from the server).  If the 
Content-Encoding matches the filename extension, we leave the 
Content-Encoding in place.  Otherwise we undo it.

As a concrete example, if we're saving http://example.com/foo.txt.gz and 
it's sent as "Content-Type: text/plain" and "Content-Encoding: gzip", we 
will save the data as-is (after undoing any Transfer-Encodings) and name 
the file "foo.txt.gz".  But if we're saving http://example.com/foo.txt 
sent with the same headers, we'll run it through gunzip before sending 
it to disk, and name the file "foo.txt".

This is particularly important for the common case of .tar.gz or .tgz 
files that get sent as "Content-Type: application/x-tar" and 
"Content-Encoding: gzip" and which no one wants to be gunzipped when 

Received on Thursday, 13 March 2014 06:16:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:37 UTC