20191104 追記
draft 01でCache-Status に改称されるとともに、内容も変わりました
更新記事を書きました
asnokaze.hatenablog.com
CDNなどのサービスは、リクエストがキャッシュにヒットしたかどうかをx-cacheヘッダに格納してレスポンスしてくれます
このx-cacheヘッダは独自の形式であり、例えば以下のようになっています。
(CDNによっては、x-cache以外のヘッダを使うものもあります)
fastly (document)
X-Cache: MISS, HIT
Amazon CloudFront
X-Cache: Hit from cloudfront
先述のように、x-cacheヘッダは標準化されておらずCDN毎に独自に使用されています。
そこで、IETFのHTTbisにおいて
キャッシュのHit情報などを格納するcacheヘッダの標準化を行う「The Cache HTTP Response Header」という仕様がFastlyのMark Nottingham氏から出されています。
Cacheヘッダ
例
Cache: HIT_FRESH; node="reverse-proxy.example.com:80";
key="https://example.com/foo|Accept-Encoding:gzip",
HIT_STALE; node="FooCDN parent"; fresh=-45; age=200; latency=3,
MISS; node="FooCDN edge"; fresh=-45; age=200; latency=98
(シンタックスについては 以前書いた「Structured Headersの記事」を参考に)
リクエストが複数回forwardされた場合は、レスポンスを返す順にカンマ区切りで情報が追記されていく。頭のほうがオリジンに近いほうで、後ろのほうがユーザエージェントに近い。
cache-actions
cache-actionsと呼ばれる、リクエストに対してどういうアクションを取ったかは以下の種類がある
- HIT_FRESH: リクエストをforwardすることなく、キャッシュとして期限内(fresh)であるものを返した
- HIT_STALE: リクエストをforwardすることなく、キャッシュとして期限内(fresh)ではないものを返した
- HIT_REFRESH_MODIFIED: キャッシュが有効ではなかったので、リクエストをforwardして新しく得られたレスポンスを返した
- HIT_REFRESH_NOT_MODIFIED: キャッシュが有効ではなかったので、リクエストをforwardして有効性が確認できたキャッシュしていたレスポンスを返した
- HIT_REFRESH_STALE: キャッシュが有効ではなかったので、リクエストをforwardしたが問題が発生したため、保存してあったキャッシュを返した
- MISS: キャッシュが無かったためリクエストをforwardした
- MISS_CLIENT: リクエスにCache-Controlヘッダのような、キャッシュが使えないようなパラメータが含まれていたので、リクエストをforwardした
- BYPASS: レスポンスをキャッシュするように設定されていない
- ERROR: 保存してあったものか、forwardして得られたキャッシュが使用できなかった
パラメータ
各アクションは下記パラメータを付けることが出来る(OPTIONAL)