---
# System prepended metadata

title: ⑧12/3(木) 9.9 キャッシュ ~ If-Modified-Since まで
tags: [Webを支える技術]

---

# ⑧12/3(木) 9.9 キャッシュ ~ If-Modified-Since まで
###### tags:`Webを支える技術`
### ✅ キャッシュ用ヘッダ

@Saki
#### 学習メモ
- キャッシュが使えるかどうか/有効期限の判断方法
> あるリソースがキャッシュ可能かどうかは、そのリソースを取得したときのヘッダで判断します。リソースがキャッシュ可能かどうか、その有効期限がいつまでなのかは、Pragma、Expires、CacheControlヘッダを用いてサーバが指定します。

- キャッシュの抑制 = 禁止ではないので注意
  
#### ❓疑問点
- ローカルストレージとは？
  - [わわわIT用語辞典](https://wa3.i-3-i.info/word13183.html)によると2つの意味がある。
  - 本では`ローカルストレージ（ハードディスクなど）`と言ってるので、おそらく前者の説明を指している。
  - ストレージ：ストレージは「データを入れておく箱」。物としては、ハードディスクとかCD-RとかUSBメモリとか。
  - ローカル:「自分のところだよー」の意味
  - ローカルストレージ：自コンピュータにくっついているデータを入れておく箱のこと
  - もう一つの意味は、ウェブストレージ(Webブラウザにデータを保存する仕組み) 
 
- ヘッダの使い分けの指針で、同時に指定とあるが、**2個ともを**同時に使うべきということ？
> 使い分けの指針:キャッシュをさせない場合は、PragmaとCacheControlのnocacheを同時に指定する

→ [PragmaヘッダーとCache-Controlヘッダーの違いは何ですか？](https://qastack.jp/programming/10314174/difference-between-pragma-and-cache-control-headers)によると、
> PragmaはHTTP / 1.0実装であり、cache-controlはそれと同じ概念のHTTP / 1.1実装です。どちらも、クライアントが応答をキャッシュしないようにするためのものです。古いクライアントはHTTP / 1.1をサポートしていない可能性があるため、そのヘッダーはまだ使用されています。

とあるので、クライアントがHTTPバージョン1.0までにしか対応していない場合を考慮し、1.0と1.1の両方に対応できるようにするために、PragmaとCacheControlの療法を同時に使うべき、ということと解釈した。
(HTTPバージョンは今は3まであるので、現状はどうなんだろう🤔)


- cash_controlの存在意義。。有効期限を相対時間(○時間後とか)で指定できるだけならあんまり要らなそう。

- キャッシュってブラウザバックでしか使った実感が湧かない。リクエストした時に接続したかキャッシュを取得したかブラウザで調べる方法ないかな。。

[cache（キャッシュ）とは？](https://academy.gmocloud.com/keywords/20170414/4163#:~:text=%E3%82%AD%E3%83%A3%E3%83%83%E3%82%B7%E3%83%A5%E3%81%AF%E3%81%A9%E3%82%93%E3%81%AA%E5%A0%B4%E9%9D%A2%E3%81%A7,%E4%B8%8A%E3%81%92%E3%82%8B%E3%81%93%E3%81%A8%E3%81%8C%E3%81%A7%E3%81%8D%E3%81%BE%E3%81%99%E3%80%82)

@皐月
- Cache-controlヘッダで、Pragma,Expiresの機能を一部代用できる。


### ✅ 条件付きGET
@Saki
### 疑問点
> クライアントがExpiresやCacheControlヘッダを検証した結果、ローカルキャッシュをそのまま再利用できないと判断した場合でも、条件付きGETを送信すればキャッシュを再利用できる可能性があります。条件付きGETは、サーバ側にあるリソースが、クライアントローカルのキャッシュから変更されているかどうかを調べるヒントをリクエストヘッダに含めることで、キャッシュがそのまま使えるかどうかを検証するしくみです。

↑の説明がややこしく感じたので自分なりにまとめた。
- クライアントが自分のローカルストレージに保存しているキャッシュを再利用したいので、ExpiresやCacheControlヘッダを検証したら、`no-cashe`だったので、サーバーがリソースのキャッシュを禁止=再度サーバーにアクセスしなきゃいけないことが分かる
- `no-cashe`と返されていても、「条件付きGET」を送信することで、自分のキャッシュが使えるかどうか調べることができる
- 調べ方=サーバ側にあるリソースが、クライアントローカルのキャッシュから変更されているかどうかを調べるヒントをリクエストヘッダに含める。
  - ❓この方法がなぜキャッシュを再利用できるか調べるために有効か分からない  
- 調べ方には2つある。`If-Modified-Since （要求）`ヘッダと`If-None-Match （要求）`ヘッダ。

 
- 疑問：キャッシュを使えないことがヘッダでわかったのに、なぜまた検証する？というかそもそもキャッシュってそんなに再利用したいもの？


- 条件付きGETを行ったときの流れを具体例・図がほしい→Rails書いたり実務に入ったらしっくり来るのかも。


### 次回読み始めるところ
`none_match`ヘッダからスタート