- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Thu, 13 Mar 2014 02:15:36 -0400
- 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 saving.... -Boris
Received on Thursday, 13 March 2014 06:16:06 UTC