@shqld RFC 9209: The Proxy-Status HTTP Response Header Field RFC 9211: The Cache-Status HTTP Response Header Field

RFC 9209 The Proxy-Status HTTP Response Header Field

HTTP/1.1 500 Internal Server Error Proxy-Status: r34.example.net; error=connection_timeout, ExampleCDN-A; received-status=504, ExampleCDN-B RFC 9209 Proxy-Status

- レスポンスがどう扱われたかを表現するフィールド - 誰に （e.g. intermidiary, proxy, CDN） - どのように（e.g. エラー状況、受信ステータス） - オリジンからクライアントまでの中間レイヤで何が起こったのかを理解するため のフィールド - e.g. オリジン→A→B→Cの順にハンドルされた - e.g. プロキシAでコネクションタイムアウトが発生した - e.g. Bの時点でステータスは 504だった - (基本的には) 一つのフィールドにそれぞれが書き加えていく形 RFC 9209 Proxy-Status: 概要

- 2.1.1. error - 発生したエラーの種類 - 2.1.2. next-hop - レスポンスを得るために選択・利用したプロキシ・オリジンの {hostname, IP, alias} - この場合の next は upstream (オリジンに近い側) - 2.1.3. next-protocol - next-hop との通信で使う protocol - 2.1.4. received-status - next-hop から受け取った時点の HTTP Status - 2.1.5. details - 追加情報・詳細を表す文字列（特に指定や制約はない） RFC 9209 Proxy-Status: パラメータの種類

- オリジンは生成してはならない (MUST NOT) - 仕様名で Header Field といいつつ、Trailer として送っても良い - むしろ Trailer で送る必要のあるケースが存在する - e.g. オリジンのレスポンスをそのままストリーミングしていたがコネクションが abruptly close し た時 - Header は既に送られてしまっている ので、書き換えようがない - Upstream から順に書き加えていく形なのに next-hop が存在するのは - 全ての中間レイヤが Proxy-Status を加える保証がない - next は「隣接 (adjacent)」 RFC 9209 Proxy-Status: ポイント

- 各 vendor のサポート状況に依存する - 今すぐ自分達で何か利用できる、というものではない - 誰も実装しなかったら、当然利用できない - 比較的 新しい仕様なのでサポートは先になるかもしれない RFC 9209 Proxy-Status: ポイント

RFC 9211 The Cache-Status HTTP Response Header Field

Cache-Status: ExampleCache; fwd=stale; fwd-status=304 RFC 9211: The Cache-Status HTTP Response Header Field

- それぞれのレイヤでそのレスポンスがどうキャッシュされていたかを表現する フィールド - 基本的には確認・デバッグが目的？ - e.g. 「プロキシAでは miss したがその裏のBでは hit した」 - ベンダー各社やソフトウェアによって様々なフィールド・内容で表現されていたも のが標準化された形 - e.g. (Fastly) Fastly-Debug, X-Cache (Cloudflare) CF-Cache-Status - 一つのフィールドにそれぞれが書き加えていく形 RFC 9211 Cache-Status: 概要

RFC 9211: The Cache-Status HTTP Response Header Field Cache-Status: ExampleCache; fwd=stale; fwd-status=304 Cache-Status: ReverseProxyCache; hit Cache-Status: ForwardProxyCache; fwd=uri-miss; collapsed; stored Cache-Status: BrowserCache; fwd=uri-miss Cache-Status: OriginCache; hit; ttl=1100, "CDN Company Here"; fwd=uri-miss;

- 2.1. hit: ヒットしたかどうか - ヒットの定義は forward されずキャッシュだけでレスポンスを生成できるかどうか - 200 → 304 に変更しても、stale-if-errorでstaleを返したとしても hit になる - 2.2. fwd: forward されたときの理由 - bypass: キャッシュを使わないように設定されている (e.g. Varnish の vcl_pass) - method: リクエストのメソッド起因 (e.g. DELETE, CONNECT, OPTIONS) - uri-miss: その URI に対応するキャッシュが store されていない場合 - vary-miss: Vary 起因 - miss: uri-miss, vary-miss 以外の miss - request: リクエスト起因 (e.g., Cache-Control request header) - stale: stale な場合 (fresshness validation の結果など) - partial: Range Request の範囲が異なるなど RFC 9211 Cache-Status: パラメータの種類

RFC 9211 Cache-Status: パラメータの種類 - 2.3. fwd-status - forward 先 (upstream) から受け取ったレスポンスの HTTP Status (fwd限定) - 2.4. ttl - Time To Live (freshness) - stale の場合は負の値になる (= stale になってからの経過時間 ) - 2.5. stored - 将来のリクエストのために store (キャッシュオブジェクトの生成 ) をしたかどうか (fwd限定) - 2.6. collapsed - Request collapsing （複数のリクエストを一つにまとめてオリジンの負荷を低減する）されたかどうか (fwd限定) - 2.7. key - Cache Key の文字列（実装依存） - Vary で cache の出しわけに使われたりする (e.g. Fastly `Surrogate-Key`) - 2.8. detail - 追加情報・詳細

- UA (browser) も使ってよい？ - 明確な記述はないが例にある e.g. `Cache-Status: BrowserCache; fwd=uri-miss` - browser や ServiceWorker で付与された fwd の値を DevTools で確認できると嬉しそう - RFC 9213 Targeted HTTP Cache Control との親和性 - Cache-Control の指定をレイヤごとにターゲティングできるようになるため、より精細なデバッグ ができると捗りそう RFC 9211 Cache-Status: ポイント

- 各 vendor のサポート状況に依存する - 今すぐ自分達で何か利用できる、というものではない - 誰も実装しなかったら、当然利用できない - 比較的 新しい仕様なのでサポートは先になるかもしれない RFC 9211 Cache-Status: ポイント