W3C home > Mailing lists > Public > public-webappsec@w3.org > September 2015

Re: Caching of web content based on hashes?

From: Martin Thomson <martin.thomson@gmail.com>
Date: Thu, 3 Sep 2015 09:18:07 -0700
Message-ID: <CABkgnnWCQDmOVW11B9Y6DQmZB1H+yHUs3zywa4cS0Rd1PExqkg@mail.gmail.com>
To: Richard Barnes <rbarnes@mozilla.com>
Cc: Christian Nygaard <christiannygaard@gmail.com>, WebAppSec WG <public-webappsec@w3.org>
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 16:18:36 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:15 UTC