- From: Devdatta Akhawe <dev.akhawe@gmail.com>
- Date: Wed, 2 Jul 2014 14:58:47 -0700
- To: "public-webappsec@w3.org" <public-webappsec@w3.org>
- Message-ID: <CAPfop_1Uoz6G8Wu31mNPEqTbS8ww6SR_BQQh34yO_qkMrTtZNg@mail.gmail.com>
Previously, on "what should we hash" http://lists.w3.org/Archives/Public/public-webappsec/2014Mar/0023.html Hi, Recently, for ServiceWorker, Anne and others have been dealing with "what content to surface to the ServiceWorker." This is similar to the question of "What should we hash" for SRI that we previously discussed extensively on this list. For the same reason that we don't want to hash the gzip'ed images, SWs don't want to surface the gzip'ed values. See https://github.com/slightlyoff/ServiceWorker/issues/339 Anne modified Fetch, based on the discussion above, to talk about the gzip quirks we dealt with previously in "What should we hash". In particular, see point 9 in http://fetch.spec.whatwg.org/#http-network-or-cache-fetch So, finally, I am wondering if "After Step 9" the body of the HTTP response is what SRI implementations should hash? That is, can we remove the weird wording in Step 2 of http://w3c.github.io/webappsec/specs/subresourceintegrity/#apply-algorithm-to-resource and instead just hook into fetch now. Basically, if I am not wrong, it would be "After Step 9, undo content and transfer encodings (if any) and then hash" What to others think? Is there any difference between the new Fetch spec and what SRI wants to hash? I couldn't see one, but maybe I am wrong. cheers Dev
Received on Wednesday, 2 July 2014 21:59:36 UTC