2

私は現在、クライアントがオリジンサーバーの HTTP 1.1 リクエストを行うシステムに取り組んでいます。私はクライアント ソフトウェアとサーバー ソフトウェアの両方を制御しているので、HTTP ヘッダー セットを自由に制御できます。クライアントの間には、Web プロキシ/キャッシュ デバイス (Squid などと考えてください) の複数の階層レイヤーがあります。

通常、オリジンによって提供されるデータは高度にキャッシュ可能であり、これを示すために HTTP 応答ヘッダーを設定する予定です。具体的には を使用する予定Cache-Control: public, max-age=<value>です。max-ageこれは、中間プロキシが指定されたまでの応答をキャッシュすることを意味することを理解していLast-Modifiedます304。

私が抱えている問題は、キャッシュに保持されているデータが無効になっている可能性があることにクライアントが気付く可能性があることです。この場合、クライアントは、オリジンで応答を取得または再検証するようにキャッシュに指示する要求を作成する必要があります。元のレスポンスが異なる場合、キャッシュはこの新しいレスポンスを保存する必要があります。私の考えでは、これにはクライアントがリクエストを行う必要があり、チェーン内の各キャッシュは、オリジンまでさかのぼって、次の上流のデバイスでそのレスポンスを再検証する必要があります。新しい応答は、実際にそれを持っている最も近いキャッシュから提供できます。

これを実現するためにクライアント要求に設定する必要がある正しい HTTP ヘッダーは何ですか? Cache-control: no-cache最初は、HTTPリクエストで設定するとこれが起こると思っていましたが、RFC を読むと、中間キャッシュにオリジンに戻る (望ましい) だけでなく、新しい応答をキャッシュしない (望ましくない) ように指示するようです。 . その後、の HTTP リクエスト ヘッダーがおそらくこれを行うという記事を見ましたCache-control: max-age=0が、よくわかりません。

max-age=0ここで必要なことを行いますか、それとも HTTP ヘッダーの他の組み合わせが必要ですか?

4

1 に答える 1

1

ここで同様の質問をしました: How to make proxy revalidate resource from origin . 執筆時点で、プロキシの再検証がnginxでサポートされていないことを知りました。1.5 のリリースが予定されています。

クライアントから max-age=0 を送信すると、オリジンからの元の応答に正しいキャッシュ コントロール ヘッダーが含まれていた場合、プロキシでこの再検証メカニズムがトリガーされます。

しかし、アップストリーム サーバーがこれらのヘッダーを尊重し、オリジンで再検証するかどうかは、明らかに単純に想定できるものではありません。アップストリームサーバーを制御できる場合は、うまくいくと思います。

また、ヘッダーは afaik であるため、etag は変更されたものよりも優先されます。

これらは、この件に関する役立つ記事であることがわかりました。

キャッシュのチュートリアル

キャッシュ制御ディレクティブ

検証に関する http 仕様

この仕様のセクション 14.9.4

[更新] Nginx バージョン 1.5.8 がリリースされてから、このメカニズムが機能していることを確認できます!

于 2013-12-13T11:37:46.310 に答える