Re: [integrity] What should we hash?

Actually, giving a bit more thought, I wonder if all this work
(sometimes hashing with content-encoding sometimes without) makes the
spec too complicated to implement and understand.

We are adding a new opt-in feature so we can be a bit more strict. How
about this: Spec mandates that for links with integrity attribute, the
browser will always remove content encodings: both for calculating
hash and for saving to disk.

If you want to provide gzip'ed downloads and also want to use
integrity, you have to then provide gzip'ed downloads without sending
the "Content-Encoding: gzip" header.

I just tested on dropbox and it sends a foo.tar.gz files as
application/octet-stream without any content-encoding and specifies a
filename=foo.tar.gz in content-disposition. This should work fine with
the scheme I outlined above.

--dev

On 14 March 2014 21:14, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 3/15/14 12:11 AM, Devdatta Akhawe wrote:
>>
>> The hash can be computed in a streaming fashion. The final "this is
>> ok" can only be done after the hash has been computed on the whole
>> file.
>
>
> OK.  That makes sense.  ;)
>
>
>>> This seems reasonable, with one caveat: I would prefer there be no
>>> optional
>>> behavior here.  What the non-optional behavior should be depends on the
>>> above question about streaming vs not.
>>
>>
>> Given my clarification above, can you explain what should not be
>> non-optional? Are you saying that the spec should require a
>> "encoding=gzip" for files that will be saved to disk in a gzip'ed
>> format?
>
>
> Yes.
>
> -Boris

Received on Saturday, 15 March 2014 04:43:28 UTC