この質問への回答は既にオンラインにあるかもしれませんが、無関係な結果を得ることなく質問する方法がわかりません。サーブレットを使用し、サーブレット以外web.xmlのデプロイメント記述子を持つ Java Web プロジェクトで、任意のURL リソースのカスタム マッピングを作成する方法はありますか? たとえば、html ファイル、Javascript ファイル、画像、スタイル シートなど。
私が尋ねる理由は、ブラウザのキャッシュに関係しています。Web プロジェクトのリリース間で、リソースがキャッシュされてから更新がロールアウトされた場合、ブラウザーは通常、最初にキャッシュされたバージョンを読み込もうとします。DOM 要素と Javascript 関数が変更または更新された場所では、同期されていないリソースが原因で、更新されたページが破損する可能性があります。
今、私はこの問題に対する多くの解決策を聞いています:
- すべてのリソースに URL パラメーター クエリ文字列を追加します。そのため、
index.html1index.html?v=1.2回のリリースで、その後index.html?v=1.3のリリースで、キャッシュの重複を防ぎます。これに関する私の懸念は、すべてのブラウザーがこれを尊重するキャッシュ ポリシーを実装しているわけではないということです。 問題:あるブラウザがファイルを としてキャッシュする場合、別のブラウザはキャッシュからファイルをロードした後に URL パラメータをindex.html?v=1.3キャッシュして追加するだけであり、別のブラウザはURL パラメータを含むファイルをまったくキャッシュしない場合があります。index.html touchリリース間のサーバー上のすべてのファイル。このように、リソースの HTTP 要求が送信され、取得されたファイルのタイムスタンプがキャッシュのタイムスタンプよりも新しいことが応答ヘッダーに示されると、リロードされます。問題:繰り返しになりますが、すべてのブラウザーがそのようなキャッシュ ポリシーを実装しているとは限りません。- すべてのバージョンが一致する必要がある Javascript ファイルにロジックを実装し、読み込まれる最初のJavascript ファイルを、マスター バージョン キーを提供する動的な (キャッシュ不可能な) ファイルにします。同期されていない (キャッシュされているためにバージョンがマスター バージョンと一致しない) JavaScript ファイルは、強制的に再読み込みされます。問題:これは実際には良いアプローチのように思えますが、過去にキャッシュが問題であったことを知っている場合、Javascript ファイルに追加されたロジックに依存するのは恐ろしいことです。のように、私の新しい「バージョンチェック」ロジックもロードされますか?
- バージョンをファイル名にマージします。したがって、
index.htmlとなりindex.1.2.htmlます。index.1.3.htmlキャッシュはファイル名レベルで行われ、リリース バージョン 1.3 に移行するときに、ブラウザーが既にキャッシュしている可能性はありません。問題点:開発側のソース管理は悪夢のようです...
...ただしindex.1.3.html、単に という名前のサーバー側リソースにマップする方法がありましたindex.html。これは元の質問に戻りますが、これは Web プロジェクトで実行できますか? これもお勧めですか？ではweb.xml、URL パターンをサーブレットにマップできますが、URL パターンを他のリソースにマップすることはできますか? リリース間で単一の記述子ファイルを維持するのはとても簡単なように思われるので、クライアント側ではすべてのファイルが新しいように見えるので、新しいリリースが最初にロードされるときにロード ヒットが発生することは間違いありませんが、同期されていないリソースのキャッシュは、この方法で排除されます。