20

マニフェスト エントリを取得すると、次のようになります。

<html manifest="cache.manifest">

その後、そのページ (キャッシュ内のマスター エントリ) は、後で html タグからマニフェスト属性を削除してマニフェストを (その中の何か)、他のすべてと一緒にマスターエントリを強制的にリロードします。

つまり、次の場合:

  • index.html (マニフェストが定義されている)
  • file1.js (マニフェストで参照)
  • file2.js (マニフェストで参照)
  • cache.manifest (2 つの js ファイルを一覧表示)

-- index.html からマニフェスト エントリを削除し、マニフェストを変更しても (ブラウザによって期限切れになり、すべてのコンテンツがリロードされます)、このページがまだ完全にキャッシュされているかのように動作しなくなります。index.html でソースを表示すると、マニフェストが一覧表示されなくなりますが、ブラウザーは引き続き cache.manifest ファイルのみを要求し、そのファイルの内容が変更されない限り、ファイルに対するその他の変更は表示されません。ユーザー。

これはかなり明白なバグのようで、iOS だけでなく Mac バージョンの Safari にも存在します。ユーザーの介入を必要とせずにページをリセットしてキャッシュを削除する方法を見つけた人はいますか?

4

7 に答える 7

17

私は同じ質問を調査してきましたが、次の API ではないようです。

  1. ページがキャッシュされることを動的にトリガーする
  2. ページのキャッシュを動的に停止します。

私が見つけた最高のリソースは次のとおりです。

http://www.html5rocks.com/tutorials/appcache/beginner/

http://www.thecssninja.com/javascript/how-to-create-offline-webapps-on-the-iphone

特に、最初のリンクからのこの引用：

マニフェスト ファイルまたはその中で指定されたリソースのダウンロードに失敗すると、更新全体が失敗します。このような障害が発生した場合、ブラウザは引き続き古いアプリケーション キャッシュを使用します。

それ以外の場合、キャッシュのアンロードについてはどこにも言及されていません。

エラーを強制してキャッシュを解除することはできないことを示唆しているようです。ただし、以下に示すように、仕様では、マニフェスト ファイルのダウンロード中にエラーが発生した場合、キャッシュ全体が削除されることが示唆されています。

Google Chrome では、ユーザーは次の URL にアクセスできます。

chrome://appcache-internals/

そして手動でキャッシュを無効にします。もちろん、次にページにアクセスしたときに、ページにマニフェスト プロパティが設定されていれば再キャッシュされます。

仕様を見ると: 5.6 Offline Web applications

キャッシュが削除されている状況を示唆しているようです。具体的には、セクション 5.6.4.5:

404 または 410 応答または同等の応答が原因でマニフェストのフェッチが失敗した場合は、次のサブステップを実行します。キャッシュ グループを古い​​ものとしてマークします。このキャッシュ グループは、キャッシュ グループ内のアプリケーション キャッシュに既に関連付けられている Document オブジェクトの処理以外の目的では存在しません。完全性フラグが不完全なアプリケーション・キャッシュがキャッシュ・グループにある場合、そのアプリケーション・キャッシュを破棄します。

次に、次のように述べています。

これがキャッシュの試みであった場合は、キャッシュ グループを完全に破棄します。

基本的に、キャッシュ マニフェスト ファイルの要求で 404 が返された場合は、キャッシュ全体を破棄する必要があります。では、キャッシュ マニフェスト ファイルが要求されたときに、サーバーに 404 または 410 を返させようとしましたか? それはうまくいくはずです。秘訣は、マニフェストを削除したいページの 404 / 410 のみを返すことです (おそらく URL パラメーターを使用しますか?)。

于 2010-12-28T18:36:49.583 に答える
4

考えられる解決策の 1 つ:

  • マニフェストを変更する (リロードする)
  • 存在しないマニフェストを参照するようにマスター ファイル (index.html) を変更して、404 を取得します。

エレガントではありませんが、機能しているようです。その場合の主な問題は、サイトにアクセスしたことのある人が全員戻ってきてキャッシュがクリアされるまで、この 404 を生成する誤ったマニフェスト エントリに固執することです。

もっと良い方法があるに違いない...

于 2010-12-27T22:51:40.873 に答える
2

マニフェスト ファイルを単純に削除してみてください。mozzila docs から：

アプリケーション キャッシュも時代遅れになる可能性があります。マニフェストがサーバーから削除されると、ブラウザーはそのマニフェストを使用するすべてのアプリケーション キャッシュを削除し、「廃止された」イベントをアプリケーション キャッシュ オブジェクトに送信します。次に、アプリケーション キャッシュのステータスが OBSOLETE に設定されます。

これは、クロムでも機能しました。

于 2012-02-22T08:46:13.447 に答える
1

マニフェスト内のファイルのリストを削除することで、ファイルがキャッシュされないことがわかります。

それは私たちのために働きます。

于 2014-04-07T15:31:34.977 に答える
0

開発目的（一定の変更）のために、私たちが行ったことは次のとおりです。

  1. SERVER-SIDE 言語の下にキャッシュ マニフェスト ファイルを設定します。たとえば、PHP を使用しているため、開発キャッシュは「cache.manifest.php」と呼ばれ、次のように html タグで同じように指定されます。

    <html manifest="cache.manifest.php">

  2. ファイルが時々異なるように、マニフェストのどこかにコメント（#---）としていくつかの-timedependent-文字列（またはあなたに合ったもの）を入れてください（ブラウザは日付ではなくマニフェストの内容を比較するようです） ）、たとえば、この文字列はマニフェストを毎分変更します。このようにして、訪問が前回とは異なる分にある場合、すべてのファイルが再キャッシュされます。

    <?php if($dev) echo date("Y-m-d H:m"); ?>

Chrome を使用してこの手順をテストしたところです。他の環境でも機能することを願っていますが、そうでない場合は、コメントやアドバイスをいただければ幸いです。

于 2016-11-19T21:33:49.327 に答える
0

これは古いかもしれませんが、誰かに役立つことを願っています。

IIS プロパティの HTTP ヘッダーを見てください。コンテンツの有効期限の有効化または無効化をご覧ください。IIS がまだキャッシュを実行している可能性があります。

于 2011-10-14T21:00:40.730 に答える