現在、CSS や js などのブラウザーにキャッシュされたリソースを SE と同様の方法で破棄する方法を使用しています: https://meta.stackexchange.com/questions/112182/how-does-se-determine-the-css- and-js-version-parameter
とにかく、HTTPヘッダーでいくつかのテストを行った後、これが実際にいつ必要になるのか疑問に思っています. これは 90 年代の遺物ですか、それとも Last-Modified または ETags HTTP ヘッダーを読み取れない最近のブラウザーはありますか?
キャッシングの問題
揮発性の JS または CSS をサーバー化しようとしていて、(たとえば CDN を使用して) したくない/できない場合は、HTTP キャッシュ ディレクティブ ヘッダーに依存して、ブラウザーに新しいファイルを要求させます。一部の古いブラウザーは、HTTP キャッシュ ディレクティブに応答しません。したがって、それらをターゲットにしている場合、選択肢は限られています。一部のプロキシ サーバーは、バグがあるか、積極的なキャッシュとして機能しているため、古いブラウザを削除するか、無効にするか、プロキシ情報を無視します。そのため、HTTP キャッシュ コントロール ヘッダーを使用しても機能しません。この場合、エンド ユーザーが F5 キーを押すまで奇妙な機能を利用できないようにするだけです。
揮発性 JS/CSS リソースは、管理/構成パネルで編集可能なファイル/リソースから取得できます。これには、国際化のためのテーマ、レイアウト編集、言語定義ファイルなどの理由があります。
HTTP1.0
それを使用するレガシーシステムがあります。Oracle の組み込み HTTP サーバー (EGP ゲートウェイ) が RDBMS ソリューションにまだ使用されていることを考慮してください。一部のプロキシは、1.1 要求を 1.0 に変換します。古いブラウザーはまだ 1.0 しかサポートしていませんが、最近では比較的問題にならないはずです。
いずれにせよ、HTTP 1.0 は、HTTP 1.1 が提供するものと比較して「原始的な」制御メカニズムの異なるセットを使用します。それらには、キャッシュが適切に機能するようにするために、RFC で指定されていない多くのヒューリスティック テストが含まれていました。どちらの場合でも、古いコンテンツが配信されたり、同じコンテンツが変更されずにリクエストされたりするため、キャッシングによって奇妙な動作が発生することがよくあります。
pragma:no-cache に関する注意事項
RESPONSES ではなく REQUESTS でのみ機能します。人々が知らない一般的なこと。中間システムが機密情報をキャッシュしないようにすることを目的としていました。HTTP 1.1 ではまだ下位サポートがありますが、非推奨であるため使用しないでください。
...Microsoft が IE ではそうしないと言っている場合を除きます: http://support.microsoft.com/kb/234067
生成されたコンテンツの入力
さらに別の理由は、入力パラメーターに基づいて生成される JS または CSS です。URL に含まれsomefile.jsているからといって、それがファイル システム上の実際のファイルである必要があるわけではありません。プロセスから出力されるのは JS だけかもしれません。そのプロセスがパラメーターに基づいて異なるコンテンツを出力する必要がある場合、GET パラメーターはそれを実現するための良い方法です。
ページのバージョン管理を検討してください。履歴またはビジネス要件のためにページが保持される可能性がある大規模なアプリケーションでは、同じ名前のリソースが存在することが許可されますが、特定のバージョンが必要な場合は、必要に応じて提供できます。各バージョンを別のファイルに保存するか、正しいバージョンの変更で正しいコンテンツを出力するプロセスを作成することができます。
古いブラウザの問題
IE6 では、AJAX リクエストはブラウザ キャッシュの対象となります。変更されていない URL で制御できないサービスを要求している場合、URL に簡単なランダム文字列を追加すると、その問題を回避できます。
ブラウザのキャッシュ オプション
ユーザー エージェントのキャッシュ設定に関する HTTP 1.1 の RFC を検討すると、次のこともわかります。
多くのユーザー エージェントは、ユーザーが基本的なキャッシュ メカニズムをオーバーライドできるようにします。たとえば、ユーザー エージェントは、ユーザーがキャッシュされたエンティティ (明示的に古いものであっても) を検証しないように指定できるようにする場合があります。または、ユーザー エージェントは、"Cache- Control: max-stale=3600" をすべての要求に習慣的に追加する場合があります。ユーザー エージェントは、非透過的な動作、または異常に効果のないキャッシュをもたらす動作のいずれかにデフォルト設定するべきではありませんが、ユーザーの明示的なアクションによってそうするように明示的に構成することができます。
リソースのバージョン管理のために URL を変更することは、このような問題への対策と見なすことができます。価値があると信じるかどうかは、読者に委ねます。
結論
ファイル リクエストに GET パラメーターを追加する理由はいくつかありますが、実際に現在 (2012 年現在) 追加する唯一の理由は、動的に生成されたスクリプトに入力パラメーターを提供し、キャッシュ ヘッダーを制御できない問題を克服することです。
個人的には、初期化スクリプトを動的に出力するスクリプトに入力パラメーターを提供するためにのみ使用しますが、開発中のすべてのものと同様に、理由を追加するエッジケースが常にあります。