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での議論
39- 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...
- jiehong
Varyは本当にそんなに醜いのか?
むしろ、Varyヘッダーが指定するヘッダーを解析して理解することを強制するだけだと思う。
Accept-LanguageはRFC4647に従って3つの方法のいずれかで解析・マッチングされることになっている。その部分はかなり複雑だが、Varyのせいではない。
- jrochkind1
Varyがどれほど厄介なものか、実はよく分かっていなかった。
わあ、ウェブがそもそも動いていること自体が時々驚きだ!