- From: Richard Barnes <rbarnes@mozilla.com>
- Date: Thu, 3 Sep 2015 14:05:09 -0400
- To: Brad Hill <hillbrad@gmail.com>
- Cc: Martin Thomson <martin.thomson@gmail.com>, Elie Bursztein <elieb@google.com>, Christian Nygaard <christiannygaard@gmail.com>, WebAppSec WG <public-webappsec@w3.org>
- Message-ID: <CAOAcki-a04MJPOaWJPsiHfcajWLqiQ8GBVVSnkotF9OuyFCDZA@mail.gmail.com>
Yes, you could update HTTP to get this right (your particular approach seems like an abuse of Content-Encoding, since it's not like you can decode the content). But that's not what SRI does :) And in any case, you would then only be getting a bandwidth advantage, not latency. On Thu, Sep 3, 2015 at 1:37 PM, Brad Hill <hillbrad@gmail.com> wrote: > + Elie Bursztein who has done a bunch of research on the topic. > > On Thu, Sep 3, 2015 at 9:19 AM Martin Thomson <martin.thomson@gmail.com> > wrote: > >> You know that this isn't strictly a bad idea as long as you get the >> rules right. This might be ok... >> >> GET /foo HTTP/1.1 >> Host: example.com >> Accept-Encoding: hash-sha256 >> >> Though Roy would have this defined as a new 3xx code, you might see a >> response like: >> >> HTTP/1.1 200 OK >> Content-Encoding: hash-sha256 >> >> abcdefghijklmnopqrstuvwxyz... >> >> That isn't caching, but at the point that you have a strong hash, it >> doesn't matter where the content actually comes from[*]. >> >> Of course, this is more appropriately a discussion for the HTTP working >> group. >> >> [*] Much. You still have to meet certain minimum standards of >> confidentiality etc... >> >> On 3 September 2015 at 08:04, Richard Barnes <rbarnes@mozilla.com> wrote: >> > This was discussed during the development of SRI. It was not added >> because >> > it would provide the ability for a calling site to "speak for" another >> > origin, in the sense that the browser would load the content even the >> origin >> > server would have sent something completely different. >> > >> > --Richard >> > >> > On Wed, Sep 2, 2015 at 5:33 PM, Christian Nygaard >> > <christiannygaard@gmail.com> wrote: >> >> >> >> Is it possible to extend the Subresource integrity specification to >> allow >> >> for caching of web content based on hashes instead of max-age? This >> would >> >> allow for longer caching of objects and may speed up the web due to >> making >> >> cache control easier for web developers and proxies. >> >> >> >> http://w3c.github.io/webappsec/specs/subresourceintegrity/ >> >> >> >> Best regards, >> >> Christian Nygaard >> > >> > >> >>
Received on Thursday, 3 September 2015 18:05:37 UTC