Proxy-Status & Cache-Status

HTTP RFC Publication Study
https://web-study.connpass.com/event/250730/

編集が間に合っていない部分があったので後日更新したものに差し替える予定です！

Transcript

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

   View Slide

2. RFC 9209
   The Proxy-Status HTTP Response
   Header Field
   

   View Slide

3. 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
   

   View Slide

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

   View Slide

5. - 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: パラメータの種類
   

   View Slide

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

   View Slide

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

   View Slide

8. RFC 9211
   The Cache-Status HTTP Response
   Header Field
   

   View Slide

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

   View Slide

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

    View Slide

11. 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;
    

    View Slide

12. - 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: パラメータの種類
    

    View Slide

13. 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
    - 追加情報・詳細
    

    View Slide

14. - 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: ポイント
    

    View Slide

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

    View Slide