[11] Cache-Control: ヘッダーの
private キャッシュ指令は、
共有キャッシュが蓄積してはならないことを表します。
仕様書
- [2] RFC 7234 - Hypertext Transfer Protocol (HTTP/1.1): Caching ( 版) https://tools.ietf.org/html/rfc7234#section-5.2
- [1] RFC 7234 - Hypertext Transfer Protocol (HTTP/1.1): Caching ( 版) https://tools.ietf.org/html/rfc7234#section-5.2.2.6
意味
[3] 応答の Cache-Control: ヘッダーの
private キャッシュ指令は、
応答メッセージが単一利用者に向けたものであり、
共有キャッシュが蓄積してはならないことを表します >>1。
[14] 一方私的キャッシュは (本来キャッシュ可能ではないとしても)
キャッシュ可能となります。
構文
[6] 引数を指定してもしなくても構いません >>1。
指定する場合は引用文字列を生成するべきです >>1。
受信者は字句でも引用文字列でも対応するべきです >>2。
[7] 引数の値はヘッダー名のリスト (#) です >>1。
大文字・小文字不区別です >>1。
- ?
- ヘッダー名
- *
- OWS
,- OWS
- ヘッダー名
処理モデル
[4] 共有キャッシュはヘッダー名が指定されていない場合、
応答を蓄積してはなりません >>1。
[8] 共有キャッシュはヘッダー名が指定されている場合、
応答のうち指定されたヘッダー以外を蓄積して構いません >>1。
[9] 引数が空文字列の場合にどちらと解釈されるのかは不明です。[5] 私的キャッシュは通常キャッシュ可能でないとしても、
応答を蓄積して再利用して構いません >>1。
[13] キャッシュ可能性を参照。実装
[10] 実装によってはヘッダー名が指定されていても無視して、
ヘッダー名なしの指定と同じように扱います >>1。
[12] 利用者ごとに異なる文書を返す Webアプリケーションでは、
逆串や串にそのような文書をキャッシュさせず、
利用者エージェントにはキャッシュさせるためにこのキャッシュ指令を使うことがよくあります。
メモ
[15] ログインが必要なページが串にキャッシュされないように指定しておくと良さそうです。
(no-store や no-cache だとWebブラウザーもキャッシュできなくなってしまいます。)
[16] なお、通常なら蓄積されないような状態符号のエラー応答まで蓄積されてしまう可能性があるので、注意が必要です。