[jrockway]

I think browsers should respect HTTP's caching headers, even if the content is served over SSL. If the server says "hey, it's OK to cache this", I don't think the browser should second-guess that.

If you want to be ultra-secure, get an extension for your browser that doesn't cache anything.

[three14]

I agree. But extending HTML to use a hash for verification has additional benefits. One - proxies can see plain HTTP, but they can't cache HTTPS (I think). Two - you can share the same images for the HTTP and HTTPS pages on your site. And three - you can point to a resource (e.g. a Javascript library, a download link, whatever) that you don't control, but you can now trust that the other site won't change it to something malicious.

[three14]

Just thought of another benefit - if the referenced resource is cached, the browser can save an extra HTTP request that it would have sent to check if the referenced data has been modified. Now it knows, given the hash, that it must be unchanged.

[jrockway]

All good points. I like your idea.

I assume most people have frameworks that generate their <script src=...> tags for them, so this shouldn't even require developers to think about it.