1

私は新しい API に取り組んでいます。ETag を有効にすると、Chrome は常にキャッシュの有効期間が長いリソースを条件付きで取得します。つまり、Chrome は最初に ETag を確認せずにキャッシュされたバージョンを使用しなくなります。

これは、ETag が GET で動作することになっている方法ですか?

もしそうなら、更新の競合チェックにそれらが必要ないことを考慮して、ETag を削除し、サーバーが行っている余分な作業を軽減します。

編集

私は、Chrome が有効期限が切れるまで max-age に従ってキャッシュされたアイテムを使用し、条件付き GET を使用してキャッシュされたアイテムを更新することを期待していました。

私がこれを書いているとき、304には有効期限を延長するために使用する最大年齢が含まれていないため、「キャッシュされたアイテムを更新する」ことができないことに気づきました。

したがって、ETag が有効になっていると、ネットワークがないなど、キャッシュされたバージョンを使用する正当な理由がない限り、クライアントは常に条件付きで GET すると思います。

したがって、同時実行制御が必要ない場合、ETag はサーバーのパフォーマンスに悪影響を与えるようです。

編集

私はすでに答え（上記）を推測していると思いますが、簡単に言えば、ここに質問があります：

ETag が有効になっており、Max-Age がはるか先の未来の場合、ユーザー エージェントは、以前にキャッシュされた新しい応答を使用する代わりに、常に条件付き GET を使用する必要がありますか?

4

2 に答える 2

1

ブラウザーでページを読み込む方法は、ここで関連する場合があります。

  • Ctrl キーを押して更新ボタンを使用してページをリロードすると、リソースが無条件にリロードされ、200 が返されます。
  • 更新ボタン (または F5 などの同等のキー) を使用して再読み込みすると、条件付き要求が送信され、静的リソースに対して 304 が返されます。
  • アドレス ボックスで Enter キーを押すか、ページをブックマークに追加してそこから読み込むか、ハイパーリンクからページにアクセスすると、キャッシュの max-age が期待どおりに機能するはずです。
于 2014-10-04T20:57:37.027 に答える
0

ETag を有効にすると、Chrome は常に条件付きでキャッシュの有効期間が長いリソースを取得します。

答えは RFC にあります。

10.3.5 304 未修正

クライアントが条件付き GET リクエストを実行し、アクセスが許可されているが、ドキュメントが変更されていない場合、サーバーはこのステータス コードで応答する必要があります。

あ、はい。

これが期待する答えでない場合は、質問に実際のトラフィックを含めて、期待する要求と応答のペアの順序と実際に取得することをお勧めします。

更新のレースチェックには必要ないことを考慮して

条件付きリクエスト (If-Matchなど) を使用しない場合は、実際に ETag の計算と処理を省略できます。

于 2013-07-08T11:10:19.250 に答える