HTTP / 1.1 ETagおよびIf-None-Matchヘッダーをサポートするリバースプロキシはどれですか？
キャッシュにリバースプロキシを使用するeコマースプラットフォーム用のキャッシュシステムを開発しています。適切なHTTP/1.1ヘッダーを使用して無効化を処理する予定です。つまり、コンテンツの第1世代にETagを設定し、そのETag値をアプリケーションにキャッシュします。 Cache-Controlヘッダーは「must-revalidate」を指定するため、プロキシはETagを使用した後続のリクエストでIf-None-Matchヘッダーを設定する必要があります。アプリケーションはキャッシュされたETag値を検索し、一致する場合は304応答を送信し、それ以外の場合は完全な200応答を生成します。
Nginxを使用したかったのですが、ETagがサポートされているかどうかはわかりません（ドキュメントにはサポートされていないことが示されていますが、おそらく古くなっていますか？）。ニスは別のオプションですが、私もここでは前向きではありません。
ETagを完全にサポートしているリバースプロキシサーバーはどれですか？実際に複数のバージョンをキャッシュして、キャッシュを無効にせずにスプリットテストなどを実行できるようにしたいと考えています。つまり、HTTP/1.1は、クライアントが複数のETag値を使用してIf-None-Matchを送信でき、サーバーはETagが一致したもの（存在する場合）に応答する必要があることを指定します。リバースプロキシが最後に表示された値だけでなく複数のコピーを保持し、サーバーが使用するリクエストごとに指定できるようにする場合、それは理想的です。
今日まで、このHTTP仕様を完全にサポートするプロキシはまだないと思います。そこで、約1年前、Node.jsとMongoDbを使用して自分で作成することにしました。
nginxでは、ETagをサポートするためにサードパーティのモジュールが必要です。そしてそれらの2つがあります。
- 静的ETag 静的コンテンツのキャッシュ用
- Dynamic ETags 動的コンテンツのキャッシュ用
Varnishソースコードをチェックインしたところ、If-Modified-SinceヘッダーとIf-None-Matchヘッダーはサポートされていますが、must-revalidateのCache-Controlはサポートされていません。 Cache-Controlでサポートされている属性は、max-ageとs-max-ageのみです。
参照：
bin/varnishd/cache/cache_rfc2616.cin RFC2616_Do_Cond（）bin/varnishd/cache/cache_rfc2616.cin RFC2616_Ttl （）include/tbl/http_headers.h
私が間違っていて、これが古い投稿であることを知っている場合は、私を訂正してください-しかし、新しい通行人のためにコメントしたいと思います。私はリバースプロキシキャッシュはETagを使用するときにあなたが望むほど役に立たないと信じています。
検証キャッシュメカニズムは、Originサーバーを使用して、リクエスト内のETag（または最終変更日）がまだ有効であるかどうかを検証します（使用されているヘッダーに応じて、リソースのetagと一致するか、一致しないか、または変更されているかどうかによって異なります）リクエストで指定された日付以降）。
つまり、Varnishなどのリバースプロキシキャッシュは、その要求を引き続きOriginサーバーに渡します。サーバーに処理させるのではなく、リクエストで応答する場合がありますが、Originサーバーへのラウンドトリップを保存していません。
ブラウザーは応答をキャッシュして304応答を処理できるため、リバースプロキシを使用するよりもユーザーのプライベートキャッシュの方が適している場合があります（YMMVは、特に大規模で、ユースケースによっては当然です。私はそうではありません。アプリについて想定したい場合）。
仕様から 13. ：
キャッシュにクライアントの要求への応答として使用したい古いエントリがある場合、最初にOriginサーバー（または場合によっては新しい応答のある中間キャッシュ）に、キャッシュされたエントリがまだ使用可能かどうかを確認する必要があります。 。これをキャッシュエントリの「検証」と呼びます。キャッシュされたエントリが適切な場合は完全な応答を再送信するオーバーヘッドを支払う必要がなく、キャッシュされたエントリが無効な場合は余分なラウンドトリップのオーバーヘッドを支払う必要がないため、HTTP /1.1プロトコルはサポートします。条件付きメソッドの使用。
次にメモ 13.3.4 ：
HTTP/1.1キャッシングプロキシは、最終変更日とキャッシュバリデーターとして1つ以上のエンティティタグの両方を含む条件付きリクエストを受信すると、キャッシュされた応答がすべてのキャッシュされた応答と一致しない限り、ローカルにキャッシュされた応答をクライアントに返さないでください。リクエストの条件付きヘッダーフィールド。
したがって、Varnishは応答を返すことができますが、サーバーへの往復はまだあります。 APCやmemcacheなどのアプリキャッシュを使用できる場合でも、それだけの価値があるかもしれません。ただし、検証キャッシングは、サーバーリソースの節約よりも帯域幅の節約に一般的に優れています。
検証キャッシュは、クライアント（ブラウザーまたはAPIコード）に任せるのが最善の場合があります。
キャッシュに有効期限モデルを使用することは、リバースプロキシキャッシュが本当に優れているところです。これにより、Originサーバーへのアクセスを完全にスキップできます。 Expires、Cache-Control、Dateなどを使用することは、キャッシュが古くないことを前提として、キャッシュが応答を返すことができるため、リバースプロキシキャッシュに最適な（ここでもIMO）メカニズムです。 Originサーバーにアクセスすることはありません。