CloudflareがHTTPの「最も醜い」ヘッダーVaryをサポート、キャッシュの無駄を解消
We just shipped support for the ugliest part of HTTP: Vary – Cloudflare Blog
CloudflareがHTTPレスポンスヘッダーVaryのサポートをCache Rulesで開始した。Varyはキャッシュにどのリクエストヘッダーがレスポンスに影響するかを伝えるが、生の値の違いを区別しすぎるとキャッシュが断片化し効率が落ちる。新機能では、オリジンがVaryで宣言したヘッダーごとにnormalize、passthrough、bypassの3つのアクションを設定でき、正しさを保ちつつキャッシュヒット率を維持する。
Varyはキャッシュにどのリクエストフィールドがレスポンスに影響し得るかを伝えるが、どの違いが実際に重要かを伝えるわけではない。
HNでの議論
26- simonw
何年も前からCloudflareにこれを望んでいた。
ここでの典型的な問題は、「accept: text/html」を送るユーザーエージェントにはHTMLを返し、送らないユーザーエージェントにはJSONや他のフォーマットを返すというパターンを使った場合だ。
これはCloudflareのキャッシュの背後ではデプロイ不可能だった。なぜなら、彼らは画像以外の何に対してもVaryヘッダーを無視していたからだ。つまり、JSONバージョンをキャッシュして、HTMLを期待している誰かにそれを提供してしまうリスクがあった。
（Cloudflareの機能とは関係なく、私は結局このパターンは決して使わないことにした。URLが予測可能にHTMLかJSONを返す方が好みだからだ。私のアプリではJSONを提供するために.jsonサフィックスを付けている。）
- colmmacc
わあ、これは思い出がよみがえる。20年以上前、私はApache 2.0の様々なmod_cacheサブモジュールにVaryサポートを追加したが、苦労に見合わなすぎた。それはあまりにも多くのユーザーエージェントのバグや狂ったバックエンドを露呈させただけだった。非リテラルの仮想ヘッダー（例えば地理位置ヘッダー）に基づいてキャッシュを可変にできるようにする議論や、「Date:」に基づいてVaryするという狂ったリクエストも覚えている……全く意味が通らない。全体として、賢すぎて自分のためにならなかった。言語選択が「Vary: Accept-Lang」機能ではなくURL（/en-US/..）に行き着いたのも不思議ではない。
- tiffanyh
Cloudflareが1年前に約束したのにまだ実現していない、Enterprise機能を下位の（有料）ティアで有効にしてほしいだけだ。
https://blog.cloudflare.com/enterprise-grade-features-for-al...
例えばPrefetchのように：https://developers.cloudflare.com/speed/optimization/content...