キャッシュがHitした情報を示すCacheヘッダの標準化提案

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)

  • node: ホスト名やIPアドレスといった、キャッシュノードの識別子
  • fresh: freshさの有効期限([https://tools.ietf.org/html/rfc7234#section-4.2.1:title=[RFC7234], Section 4.2.1])。秒で示され、負の値を取ることも出来る。
  • age: このキャッシュの age を示す([https://tools.ietf.org/html/rfc7234#section-4.2.1:title=[RFC7234], Section 4.2.3])
  • cacheable: このレスポンスをキャッシュとして保存できるかのboolean値
  • key: キャッシュがレスポンスと関連付けられるキー
  • latency: リクエストを受け取ってからレスポンスを返すまでの遅延ミリ秒
  • cl_nm: クライアントへの応答に304 Not Modifiedが含まれるかを示す