質問概要
Last-Modified
や ETag
でブラウザ側キャッシュを利用するよう示されたとき、
ブラウザが利用するのは「キャッシュされたときのレスポンスヘッダまで含めて全部」でしょうか?
背景
JWT 認証をしています。アクセストークンの有効期限とリフレッシュも実装しており、リクエストを受けたサーバ側で判断してアクセストークンが有効期限外だったら、リフレッシュしたアクセストークンをレスポンスヘッダに載せて返し、クライアント側ではレスポンスを受けた毎に当該ヘッダがあれば保存しているアクセストークンを上書き保存しておく流れです。
且つ、リフレッシュ時に古いアクセストークンはサーバ側でブラックリストに入れておきます。
起こること
リクエストでの認証時に「アクセストークンがブラックリストに入っている(既に無効)」としてエラーが発生することがあります。
一旦発生すると、諸々初期化( Cookie や localStorage を手動削除するなど)して再ログインしても、同じ箇所で同じエラーが発生します。
リフレッシュ自体の失敗や、リフレッシュ済トークンの保存失敗を疑いましたが、
どうも「リフレッシュ処理そのものは問題ないけれど、レスポンスするときに、過去にリフレッシュして返した(現在は既にブラックリスト入りしている)トークンを再び返してきている」ような動作に思えました。
考察
すべてのレスポンスヘッダには ETag
も載せています。
ETag
値生成時のソースは iNode 、データサイズ、更新日時などですから、レスポンスヘッダに新しいアクセストークンを載せても ETag
値は変わらないと思います。
ブラウザにとってはキャッシュを使うべきとの指示ですが、キャッシュした時点のレスポンスヘッダにあった(もう古い)アクセストークンまで活かされて、クライアント側でそれを再保存しているから次回のリクエストでエラーになるのではと考えました。
質問
ブラウザが利用するキャッシュの範囲はレスポンスボディのみか、もしくはその時のレスポンスヘッダまで含めて全部でしょうか?
調べてみても、そこまでは具体的でない説明が多く判断できませんでした。
テストのためにトークン有効期限を短く設定しても限度があるので、高速に同じことを繰り返せず再現性が低い状況です。
但し一旦再現すると、諸々初期化しても同じ URL にアクセスする限り必ず発生します。
アクセスする URL で再現結果が変わることからも、やはりキャッシュが原因ではないかと感じていますが、状況判断以前にまず仕様詳細を知っておきたいと思います。
ただ、よく API リクエストのスロットル制限の残回数をレスポンスヘッダに載せるシステムも多くあると思いますが、レスポンスヘッダまでキャッシュ時のデータが有効ならリクエスト毎に変わるはずの残回数までキャッシュが使われてスロットル制限が成立しないかキャッシュが使えないのでは…とも思いました。
あるいは、「但しこのヘッダだけはキャッシュを使わせない」などの指定方法もあるのでしょうか?