This is explicitly disallowed by the the spec but the rationale doesn't hold up under scrutiny. Prohibiting cross-origin HTTPS from appcaching really doesn't defend against the attack that it tried to defend against because HTTPS resources can just as easily end up in the usual browser cache. The point of excluding them is to prevent an attacker with physical access to the system from stealing those resources. But unless there's a cache-control "no-store" header, they'll be in the browser cache anyway. So the feature request is allow cross-origin HTTPS resources but respect the "no-store" header, if that header is present the resource won't be cached and the appcache update will fail. This has already been done in the chromium project and has been brought up on the whatwg list and public-webapps list. http://code.google.com/p/chromium/issues/detail?id=69594
> But unless there's a cache-control "no-store" header, they'll be in the browser cache anyway. I'm surprised to hear that, and I don't think that it's accurate in general. It's definitely not the case for Safari.
(In reply to comment #1) > > But unless there's a cache-control "no-store" header, they'll be in the browser cache anyway. > > I'm surprised to hear that, and I don't think that it's accurate in general. It's definitely not the case for Safari. Chrome and Firefox will cache https resources on disk. Viewing about:cache in each of those browsers easily confirms it. (Hey... Firefox's about:cache page looks really nice. I wonder if the WebInspector team would consider pages like these are part of their charter too.)
After this commit (Disable `AppCache` everywhere): https://github.com/WebKit/WebKit/commit/6f399c42909b07a4da0c6c0d6baab1b578dd610e Is this applicable?
I plan to remove the appcache code, hopefully this week.