Re: Caching of web content based on hashes?

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