Re: [integrity] What should we hash?

I think the browser should undo the content-encoding for downloads
that include integrity metadata. It is unnecessary since the browser
will throw it away anyhow but useful for spec simplicity.  We should
mention this in the spec and warn developers relying on integrity
about this gotcha.

thanks
Dev

On 12 March 2014 23:15, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> 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:28:50 UTC