- From: Devdatta Akhawe <dev.akhawe@gmail.com>
- Date: Thu, 10 Apr 2014 10:56:44 -0700
- To: Mark Nottingham <mnot@mnot.net>
- Cc: Boris Zbarsky <bzbarsky@mit.edu>, "public-webappsec@w3.org" <public-webappsec@w3.org>
Hi Mark and William William said: > I have a question on what an implementor needs to do WRT to file downloads. > My understanding is implementors are not required to buffer a file in memory > until the integrity check, right? Presumably we can still stream the > download to a temporary file or something somewhere. Sorry if this has > already been discussed somewhere else previously. Absolutely. BTW, what does Chrome do today to check against the malware blacklists for downloads? I believe that should be a comparable implementation. William said: > recompress. Can't you just keep the compressed bytestream and not have to > spend CPU cycles on recompressing? Decompression is only for integrity > verification, right? Yes, you are right. But, if I understand you right, you are still in support of Boris's idea (spec text like below)? Mark said: > --8<-- > The hash is calculated against the representation <http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-26#section-3.1.1.5> without any content-codings applied, except when there is an explicit flag that the content is to be consumed with content-encodings (e.g., saving a gzip'd file to disk). > -->8--- Oops! Yeah, you are right and you had already clarified this. That was a mistake in my email. Sorry about that. Although, I don't know what you mean by "explicit flag" above. Whats the explicit flag when gzip'ed files are downloaded? thanks Dev
Received on Thursday, 10 April 2014 17:57:31 UTC