同一のURLに対しては、必ず同一のvaryを指定する
そうしないとcacheが機能しない
だけでなく、事故る
以下のような2つのrequestが、この順番に来るケースを見る
♥Accept-Encoding: gzip
♠Accept-Encodingなし
補足
これらは別々のclientから来ている
当たり前だが、同じURLとMethodに来ている
ここでは、URL1とGETとする
client → CDN → Originという構成の話をしている
responseにvaryを含めるか否かでの挙動の差異を見る
♥♠のどちらに対してもVary: Accept-Encodingを付けた時
①♥Accept-Encoding: gzipのrequestが飛んでくる
②CDNにはcacheがないので、Originまで飛んでくる
③OriginはVary: Accept-Encodingを付けて返す
code:response
HTTP/1.1 200 OK
Content-Length: 3458
Cache-Control: max-age=86400
Content-Encoding: gzip
Vary: Accept-Encoding
④CDNはこのresponseをcacheする
例えばURL1 + GET + gzipというkeyで保存する
⑤別のclientから♠Accept-Encodingなしのrequestが飛んでくる
⑥CDNはcacheを参照する
URL1 + GET + nullというものは存在しない
なので、Originにrequestを飛ばす
⑦OriginはVary: Accept-Encodingを付けて返す
code:response
HTTP/1.1 200 OK
Content-Length: 8365
Cache-Control: max-age=86400
Vary: Accept-Encoding
正常に動作するmrsekut.icon
各clientは、解釈できる圧縮形式のものを受け取る
♥♠のどちらに対してもVary: Accept-Encodingを付けなかった時
①♥Accept-Encoding: gzipのrequestが飛んでくる
②CDNにはcacheがないので、Originまで飛んでくる
③OriginはVary: Accept-Encodingを付けずに返す
code:response
HTTP/1.1 200 OK
Content-Length: 3458
Cache-Control: max-age=86400
Content-Encoding: gzip
④CDNはこのresponseをcacheする
例えばURL1 + GET + nullというkeyで保存する
gzipで圧縮したことがkeyに含まれていないmrsekut.icon
⑤別のclientから♠Accept-Encodingなしのrequestが飛んでくる
⑥CDNはcacheを参照する
URL1 + GET + nullというものが存在する
なので、これをそのままclientに返す
これの中身はgzipで圧縮されたものである
しかし、clientはgzipを解釈できないのでrenderingに失敗するmrsekut.icon
この①②を逆にすれば、例えば、
gzipを解釈できたはずなのに、生データを返した、のようなことが起きる
これは上記の例よりはマシ
失敗はしないので
ただ、データ通信量の無駄が生じている
参考