3. stale-while-revalidate Cache-Control 拡張

HTTP レスポンスに stale-while-revalidate Cache-Control 拡張が存在する場合、キャッシュは、レスポンスが古くなった後、指定された秒数までそのレスポンスを提供してもよい（MAY）ことを示します。

stale-while-revalidate = "stale-while-revalidate" "=" delta-seconds

この拡張が存在するためにキャッシュされたレスポンスが古いままで提供される場合、キャッシュは古いレスポンスを提供しながら（つまり、ブロックせずに）再検証を試みるべきです（SHOULD）。

「古い」とは、HTTP の要件に従って、レスポンスにゼロ以外の Age ヘッダーと警告ヘッダーが含まれることを意味することに注意してください。

キャッシュされたエンティティが再検証されずに delta-seconds が経過した場合、他の情報がない限り、古いままで提供し続けるべきではありません（SHOULD NOT）。

3.1. 例

以下を含むレスポンス：

Cache-Control: max-age=600, stale-while-revalidate=30

これは、600 秒間は新鮮であり、非同期検証が試みられている間、さらに最大 30 秒間は古いままで提供され続ける可能性があることを示します。検証が結論に達しない場合、またはそれをトリガーするトラフィックがない場合、30 秒後に stale-while-revalidate 機能は動作を停止し、キャッシュされたレスポンスは「本当に」古くなります（つまり、次のリクエストはブロックされ、通常どおり処理されます）。

一般に、サーバーは max-age と stale-while-revalidate の組み合わせを、許容できる最長の合計潜在的新鮮度寿命に設定することを望みます。たとえば、両方を 600 に設定した場合、サーバーはキャッシュからレスポンスが最大 20 分間提供されることを許容できなければなりません。

非同期検証は、レスポンスが古くなった後、stale-while-revalidate ウィンドウが終了する前にリクエストが発生した場合にのみ行われるため、そのウィンドウのサイズとその間のリクエストの可能性によって、すべてのリクエストが遅延なく提供される可能性が決まります。ウィンドウが小さすぎる場合、またはトラフィックが少なすぎる場合、一部のリクエストはその範囲外になり、サーバーがキャッシュされたレスポンスを検証できるようになるまでブロックされます。