> > > And require tarball downloads in browsers from a server that sent > content-encoding:gzip to do a streaming decompress+recompress, right? > > Or just not do a streaming decompress/recompress. If content-encoding:gzip is sent but the browser didn't plan on doing a decompress already, the browser can just fail. If I am not wrong, if I want to download exe, pdf etc and the server sends these with a content-encoding:gzip, browsers already do a decompress. The only place where a decompress isn't done is something like: file is foor.tar.gz, content-type is application/x-tar and content-encoding is gzip. Browsers can fail SRI check for such downloads to avoid a streaming decompress/recompress. If the server wants to use SRI for such files, it needs to use something similar to what dropbox does: send it as "application/octet-stream" without any content-encoding and specify a filename=foo.tar.gz in content-disposition. Since this would be easily noticeable during testing, I don't imagine it being a problem. Again, as a UA developer it seems like a pretty positive property if I hash > the bytes I'm already working with... > > Absolutely! I agree, but spec ugliness can also be a negative. I am just trying to find the least bad solution :) cheers Dev
Received on Wednesday, 9 April 2014 17:12:35 UTC