HTTP / 1.1 ETagおよびIf-None-Matchヘッダーをサポートするリバースプロキシはどれですか。

キャッシングにリバースプロキシを使用するeコマースプラットフォーム用のキャッシングシステムを開発しています。適切なHTTP / 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（存在する場合）で応答する必要があることを指定します。リバースプロキシが最後に表示された値だけでなく複数のコピーを保持し、使用するリクエストごとにサーバーに指定させる場合、それは理想的です。

VarnishのソースコードをチェックインしたところIf-Modified-Since、If-None-Matchヘッダーとヘッダーはサポートさmust-revalidateれていCache-Controlますが、ではサポートされていません。でサポートされてCache-Controlいる属性はmax-ageおよびのみs-max-ageです。

参照：

• bin/varnishd/cache/cache_rfc2616.c中RFC2616_Do_Cond（）
• bin/varnishd/cache/cache_rfc2616.c中RFC2616_Ttl（）
• include/tbl/http_headers.h

nginxがETagをサポートするには、サードパーティのモジュールが必要です。そして、それらの2つがあります。

• 静的コンテンツをキャッシュするための静的ETag
• 動的コンテンツをキャッシュするための動的ETag

私が間違っている場合は修正してください。これは古い投稿であることはわかっていますが、新しい通行人にコメントしたいと思います。私はリバースプロキシキャッシュはETagを使用するときにあなたが望むほど役に立たないと信じています。

検証キャッシングメカニズムは、元のサーバーを使用して、リクエスト内のETag（または最終変更日）がまだ有効であるか（どのヘッダーが使用されているか、または変更されていないかによって、リソースのetagと一致するか一致しないか）を検証しますリクエストで指定された日付以降）。

つまり、Varnishなどのリバースプロキシキャッシュは、引き続きその要求をオリジンサーバーに渡します。サーバーで処理するのではなく、リクエストで応答する場合がありますが、オリジンサーバーへの往復を保存していません。

ブラウザーは応答をキャッシュして304応答を処理できるため、リバースプロキシを使用するよりもユーザーのプライベートキャッシュの方が適している可能性があります（YMMV、特に大規模で、もちろんユースケースによっては異なります）。アプリについて想定したい場合）。

仕様13.3から：

キャッシュに、クライアントの要求への応答として使用したい古いエントリがある場合、最初にオリジンサーバー（またはおそらく新しい応答を持つ中間キャッシュ）をチェックして、キャッシュされたエントリがまだ使用可能かどうかを確認する必要があります。これをキャッシュエントリの「検証」と呼びます。キャッシュされたエントリが適切である場合、完全な応答を再送信するオーバーヘッドを支払う必要がないので、キャッシュされたエントリが無効な場合、余分なラウンドトリップのオーバーヘッドを支払う必要がないため、HTTP / 1.1プロトコルは、条件付きメソッドの使用。

そして13.3.4に注意してください：

HTTP / 1.1キャッシングプロキシは、Last-Modified日付と1つ以上のエンティティタグの両方を含む条件付きリクエストをキャッシュバリデータとして受信すると、ローカルにキャッシュされた応答をクライアントに返してはなりません。リクエストの条件付きヘッダーフィールド。

したがって、Varnishは応答を返すことができますが、サーバーへの往復はまだあります。APCやmemcacheなどのアプリキャッシュを使用できる場合は、それでも価値があるかもしれません。ただし、検証キャッシュは一般に、サーバーリソースの節約よりも帯域幅の節約に適しています。

検証キャッシングは、クライアント（ブラウザまたはAPIコード）に任せるのが最適です。

キャッシュに有効期限モデルを使用することは、リバースプロキシキャッシュが本当に優れているところです。これにより、元のサーバーへのヒットを完全にスキップできます。使用してExpires、Cache-Control、Date、など、これまでにオリジンサーバを押すことなく、その古くなっていないと仮定すると、応答を返すことができるキャッシュとしてリバースプロキシキャッシュのメカニズム（IMO、再び）が最適です。

必要なものがあるように見えるApache TrafficServerを見ることができます。

これまでのところ、このHTTP仕様を完全にサポートするプロキシはまだないと思います。したがって、約1年前に、Node.jsとMongoDbを使用して独自に作成することにしました。

https://github.com/colinmollenhour/node-caching-proxy