HTTPのCache-Control Header
webHTTPでCache-Control Headerを付けてレスポンスすると、 クライアントにキャッシュさせてリクエストの回数やレスポンスの通信量を削減することができる。CDNによって挙動が異なるようなので注意が必要。
CDN切り替え作業における、Web版メルカリの個人情報流出の原因につきまして - Mercari Engineering Blog
また、Vary Headerで
クライアントが送るHeaderの値が前回と異なる場合にリクエストが送られるようにでき、
Access-Control-Allow-Origin でOriginの値を返す場合、Vary: Origin のようにしないと
他のOriginからのリクエスト時にキャッシュされたHeaderを読んでしまいCORSエラーになってしまう。
max-age
キャッシュが有効な秒数を表す。s-maxageというのもあってこれはプロキシやCDNといった共有キャッシュでのみ適用される時間。
Expires Headerがあったとしてもこれらが優先される。
Cache-Control: max-age=30
private
単一ユーザー向けのレスポンスであることを表し、共有キャッシュに保存させないようにする。
Cache-Control: private, max-age=30
no-cache
ETag付きのリクエストを毎回投げる。
ETagはリソースの識別子を表すHeaderで、
前回返ってきたETagをリクエストのIf-None-Match Headerで渡すと、変更されてない場合は代わりに304 Not Modifiedが返るのでキャッシュを使い、帯域を節約できる。
つまり文字通りキャッシュされないというわけではなく、304が返ってきたらキャッシュしたデータが使われる。
no-store
キャッシュさせない。毎回リクエストが飛びレスポンスが返る。
max-ageもExpires Headerもない場合でもLast-Modified Headerがあれば キャッシュされるのでキャッシュさせたくない場合は明示的に書いたほうがよい。