現在、Rails アプリケーションの前に置くことが適切かどうかを確認するために、Varnish の実装をスパイクしています。
Varnish が API 呼び出しの結果をキャッシュし、クライアントの ETag が Varnish に保存されているものと一致しない場合、またはクライアントの変更日が Varnish の日付より前である場合にのみ、アプリケーションをヒットするようにします。
これまでのところ、Varnish がこれらの値を考慮に入れているのを見たことがありません。
二次リクエストが最大経過時間内にある場合にのみ、キャッシュ ヒットを取得します。
これは予想される動作ですか？
これは予想される動作であり、Varnish は現在、キャッシュされたコンテンツを再検証していません。
あなたが望むことをするための実験的な作業がいくつかあります.Varnish 4.0で終わるかもしれません.
それまでの間、人為的に短い TTL を設定graceし、目的の TTL に相当する時間を設定することができます。その構成では、リクエストが着信すると、Varnish は IMS リクエストをバックエンドに送信します (もちろん、キャッシュされたエントリに ETag がある限り、それ以外の場合はプレーンなリクエストになります)。
副作用として、バックエンドがダウンしている場合や 500 が返された場合、Varnish はキャッシュされたエントリも送信します。これは、必要な場合とそうでない場合があります。
私が行ったことは、提供された etag を使用するように hash() 関数を設定することです。
これは、オブジェクトに対する最初のリクエスト (クライアントから etag が提供されていない) がオブジェクト自体を取得することを意味します。
後続のリクエスト、または etag のヘッダーを提供するリクエストは、オブジェクトまたは 304 のいずれかを取得します。