永久删除 HTML5 Appcache 清单
我在一个网站上设置了一个应用程序缓存，不久之后我就意识到它比我意识到的更加激进。我想删除它。永久地。
我读过，传递一个已更改的清单文件（完全为空）且具有正确的 MIMETYPE 将删除缓存。 编辑：见下文。莫里斯的答案是唯一一致的解决方案。
这是最快、最有效的解决方案吗？有更好的办法吗？
如果您可以在回答中指定您之前是否实际使用过此功能，我将非常感激 - 模糊的文档和测试期间未显示的古怪之处是让我陷入这种情况的原因。
I setup an Application Cache on a site and shortly thereafter realized its way more aggressive that I realized. I want to remove it. Permanently.
I've read that passing a changed manifest file, completely empty, with the correct MIMETYPE will remove the cache. Edit: See below. Maurice's answer is the only consistent fix.
Is this the fastest, most effective solution? Is there a better way?
And if you can specify whether or not you've actually used this functionality before with your answer I'd really appreciate it - ambiguous documentation and quirky that didn't show during testing are what got me into this situation.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
诀窍是首先将 HTML 页面中的清单 URL 更改为无效的内容，以便浏览器在加载它时会收到 404 错误。确保同时更改原始清单，否则永远不会下载新的 HTML 页面。浏览器无法下载新的清单 URL 后，您可以从 HTML 页面中完全删除清单设置。
有点古怪，但这似乎是删除现有清单引用的唯一可靠方法。
The trick is to first change the manifest URL in your HTML page to something invalid so the browser will receive a 404 when loading it. Make sure to also change the original manifest otherwise the new HTML page is never downloaded. After the browser has failed to download the new manifest URL you can completely remove the manifest setting from the HTML page.
Kind of wacky but that seems to be the only reliable way of removing an existing manifest reference.
截至 2015 年 6 月 25 日，我发现返回 404 不会清除 Firefox 的现有应用程序缓存，返回空白应用程序缓存也不会清除 Chrome 的现有应用程序缓存。返回以下 appcache 似乎可以在 IE、Chrome、Safari 和 Firefox 中工作，尽管尚不清楚通过什么机制来完成禁用 index.html 的“隐式”缓存。
As of 6/25/2015 I found returning a 404 will not clear the existing appcache for Firefox, and returning a blank appcache will not clear the existing appcache for Chrome. Returning the following appcache seemed to work in IE,Chrome,Safari, and Firefox, although it is unclear by what mechanism the disabling of 'implicit' caching of index.html is accomplished.
如果您只想将其从您身边删除，您可以从浏览器中执行此操作。我只记得如何在 Chrome 中执行此操作。转到 chrome://appcache-internals/ &删除所需的文件。您还可以清除缓存和饼干和那应该有效。不过，我只在 Chrome 中进行了测试。
如果您想为所有查看者删除它，我知道没有办法检测他们是否有旧的缓存版本，但我知道像莫里斯建议的那样保留带有错误链接的属性将是我知道的唯一方法;不过，我确信还有另一种方法，最有可能使用 jQuery。
If you just want it removed from your side you can do that from the Browser. I can only remember how to do it in Chrome. Go to chrome://appcache-internals/ & remove desired file(s). You can also clear cache & cookies & that should work. I've only testing that in Chrome, however.
If you want to remove it for all viewers, I know of no way to detect if they have an old cached version, but I know that keeping the attribute with a false link, like Maurice suggested, would be the only way that I would know; though, I'm sure there is another way, most likely with jQuery.
我遇到了类似的问题，我需要在更新失败后重置应用程序缓存（即强制完全删除应用程序缓存，以便可以从头开始重新构建）。
在莫里斯的回答的基础上，我向用户展示了一个通常隐藏的链接，该链接打开一个非缓存页面，该页面仅写入一个 cookie 并将用户返回到上一个视图。此 cookie 告诉服务器下次请求应用程序缓存时返回 404，然后用户将完成正常的登录过程。当应用程序下次成功运行时，它会清除 cookie 并恢复正常缓存。
以这种方式使用 cookie 可以解决视图的主版本卡在应用程序缓存中的问题，从而很难将破坏性 url 注入到 manifest="" 中，即清单 url 保持不变，但服务器以 404 响应除非另有说明。
I've been having a similar issue where I needed to reset the appcache after a failed update (i.e. force a complete removal of the appcache so that it can be re-built from scratch).
Building on Maurice's answer I present the user with a normally hidden link that opens a non-cached page, which just writes a cookie and returns the user to the previous view. This cookie tells the server to return a 404 the next time the appcache is requested, and the user is then taken through the normal login process. When the application next successfully runs it clears the cookie and caching resumes as normal.
Using a cookie in this way gets around issues where the master version of the view is stuck in the appcache, making it difficult to inject a breaking url into manifest="" i.e. the manifest url stays the same, but the server responds with a 404 until told otherwise.