『高速なメディアを実現させるための戦略と戦術』
@arayaryoma
へのフィードバック
『高速なメディアを実現させるための戦略と戦術』
@arayaryoma
へのフィードバック
- Takuma HANATANI@potato4d2020/12/15 13:25発表資料内で Fastly を使っている部分でクライアント側は no-cache をしている部分がありましたが、 no-store ではない理由はありますか？
Fastly 特有の Surrogate Control について詳しくないので自明な質問だったら申し訳ないのですが、オフィシャルだと差分があるやつを no-store で記述していて、おそらくそれでも Fastly 側のキャッシュは適切に行われそうで気になっています。
https://docs.fastly.com/ja/guides/configuring-caching#fastly-と-ブラウザに異なるキャッシュルールを適用する方法
- Takuma HANATANI2021/01/02 18:03👀@potato4d
- araya2021/01/13 14:11今更の回答で本当に申し訳ないです... (今日#3でこれ開いて思い出しました)
ここではクライアントは終端のUAであるブラウザとして説明します。
no-cache と no-store は明確に意図が違っていて、 ブラウザに no-store を送ったときはキャッシュそのものが保存されませんが、no-cacheはキャッシュが保存されます。ただし、ブラウザはサーバーへのキャッシュの検証(Conditional Request)なしにそのキャッシュを使い回すことができません。
サーバーに対しConditional Requestを送った結果、サーバーが304 Not Modifiedを返したときに、ブラウザにはキャッシュを使ってほしいため、no-cacheを指定しています。@arayaryoma - Takuma HANATANI2021/01/14 03:03返信ありがとうございます。
サーバーに対しConditional Requestを送った結果、サーバーが304 Not Modifiedを返したときに、ブラウザにはキャッシュを使ってほしいため、no-cacheを指定しています。
Fastly のデータを尊重するために no-cache の部分はユーザー側でキャッシュさせたくないのかなと認識していたのですが、アクセス自体は疎通させた上で、 304 が帰ってきたときにより高速に表示するために保持しておきたいモチベーションだったのですね。
勉強になりました。ありがとうございます！@potato4d
このスレッドへとコメントする
© 2020 ElevenBack LLC.