第93話：イトは、古い表示を直そうとしてログインまで消しかけた｜キャッシュ削除で何が起きる？

第92話のstatus panelは、三つのbrowserで二色に分かれていた。

ユイのbrowser        resolved / cyan
マコトのbrowser      resolved / cyan
イトのbrowser        incident / amber

hostnameもURLも同じ。

イトは自分のbrowserだけに残るamber panelを見て、大きなdelete trayを引き出した。

trayには三つの箱が載っている。

cached images and files
cookies and site state
history

イトは三箱をまとめて、赤いdelete leverへ寄せた。

「古いなら、全部消せば新しくなる」

uploadのhost-only session ringと、未送信draft二件もcookie boxの横で揺れた。

cacheは、使い直せるHTTP response

browserは、受け取ったHTTP responseをcacheへ保存できる。

次に同じrequestが来たとき、保存したresponseを使えれば、毎回すべてを遠いserverから取り直さずに済む。

ただし、保存したものをいつまで使えるかは同じではない。

Cache-Control: max-ageなどがfreshness lifetimeを示す場合がある。

ageがfreshness lifetimeを超えていなければ、cacheはoriginへ連絡せずfresh responseを再利用できる。

staleになったresponseは、通常はそのまま使わず、validatorを使ってまだ有効か確かめられる。

fresh stored response   reuse possible
stale stored response   validation needed
no stored response      fetch needed

cacheは古いもの置き場ではない。

再利用してよいresponseも、確かめ直すresponseも入る作業棚だ。

マコト

保存されているかだけでなく、freshか、validationが必要かを見る

ユイ

自分だけ古いなら、どの材料を再利用したか比べられます

イト

棚があることと、棚の全部が間違いは同じじゃないんだ

Picoはdelete leverを押さない。

HTML response、panel image、cookie ringを別のinspection lightで照らした。

304は、新しいbodyを受け取った印ではない

cached responseには、ETagやLast-Modifiedのようなvalidatorが付く場合がある。

clientがconditional requestを送り、selected representationが変わっていなければ、serverは304 Not Modifiedを返せる。

304は、同じbodyをもう一度送らなくてよいというanswerだ。

cacheは、保存済みbodyを使う。

representationが変わっていれば、fixtureではnew bodyを持つ200 OKを受け取り、cache entryを置き換える。

conditional request + unchanged   304 / stored body reused
request + changed representation  200 / response body received

Cache-Control: no-cacheも、保存禁止という意味ではない。

stored responseを使う前にvalidationを求めるdirectiveだ。

保存自体を避けるno-storeとは役割が違う。

よくある誤解：再読み込みもキャッシュ削除も、全部同じ

通常のreload、cacheを使わないreload、browser settingsからのcache clearは、同じ操作ではない。

具体的な名前と挙動はbrowserや環境で違う。

reloadを一度押しても、fresh resourceが再利用される場合がある。

cache clearはlocalに保存された対象responseを消す、または次のrequestで使えない状態にする操作だ。

次の表示では、必要なresourceを取得・validationする。

しかしcache clearは、次のものを自動では直さない。

origin server content
shared CDN response
application state
account data
network failure

Cookieを同時に選ばない限り、cacheだけのclearがCookie削除と同じになるわけでもない。

逆にbrowserのclear画面で複数項目を選べば、login stateやhistoryまで影響し得る。

clearという一語ではなく、選択中のdata categoryを読む。

amber panelは、serverへ取りに行っていなかった

三人のrequest traceを、同じ時刻で比べた。

document /status/
  Ito       conditional request -> 304
  Yui       request -> 200
  Makoto    request -> 200

asset /status-panel.avif
  Ito       fresh cache -> request 0
  Yui       no cache entry -> request 1
  Makoto    no cache entry -> request 1

HTML documentは、イトのbrowserでもvalidationされていた。

違ったのはpanel assetだ。

fixtureの古いamber assetには、max-age=3600が残っていた。

cache ageは千八百二十秒。

まだfreshと計算され、browserはserverへrequestを送らず再利用した。

server側では、同じURLのpanelがcyan版へ置き換わっている。

contentを変えたのにcache keyとなるURLとfreshness policyを整えなかったことが、今回のfixtureを作った。

一回の観測から、すべての古い表示をbrowser cache原因とは決めない。

残り31秒の三択

support caseへcyan panelの確認を返すまで、残り三十一秒。

upload sessionと未送信draft二件を保つ。

同じreloadを大量に繰り返さない。

cache bypassを一度試して変わらなければ、client cache以外へ進む。

追加downloadの時間とdata量も記録する。

イトはdelete trayの前に、三枚のroute cardを置いた。

イト

A。cache、Cookie、historyを全部消し、最初からloginし直す

イト

B。普通のreloadを、cyanに変わるまで何度も押す

イト

C。cookie boxを保ち、panel assetだけ一度cache bypassしてrequest結果を比べる

Aは、原因を確かめる前にunrelated stateまで消す。

Bは、同じfresh cache reuseを繰り返すだけになる場合がある。

Cなら、古い表示へ効いた一手と、残したstateを分けて観測できる。

イトがall-data deleteを閉じ、panel drawerだけを開いた

イトは左手で、all-data delete trayの赤いlidを閉じた。

reload storm wheelにもstop barを掛ける。

右手で、amber panel assetのcache drawerだけを開いた。

cookie box、upload session ring、draft shelfはclosed keep railへ戻した。

イトはfixtureのcache-bypass requestを一度だけ送った。

request target       /status-panel.avif
stored response use  bypassed once
network request      1
response             200 OK
ETag                 "panel-v4"
body received        cyan panel

Picoはold entryとnew responseの境界だけを照らす。

request、delete tray、cookie box、drawerへ触れない。

panelはcyanになり、loginは残った

イトのstatus windowがamberからcyanへ変わった。

display after test       resolved / cyan
cookie removed           0
upload session retained  1
upload drafts retained   2
additional download      184 KB
time before case close   12 seconds

イトはsupport caseへcyan panelの確認を返した。

caseは閉じる前に受け取った。

今回の結果は、Ito browserのfresh cached assetが表示差へ関与したことを示す。

cache clearがすべての表示障害を直す証明ではない。

download 184 KBと十二秒も、無損失ではなかった。

変わらなければ、clearを繰り返さない

まず同じURLをanother browser / deviceと比べる。

自分だけ違うなら、どのresourceがcacheから使われたかを見る。

一度のcache bypassまたは選択的clearで、request発生、status code、validator、body、表示変化を記録する。

304なら、stored bodyを使う流れを確かめる。

200でnew bodyを受け取っても表示が変わらないなら、別resourceやapplication stateを疑う。

他のbrowserでも同じ古さなら、origin / shared cache / deploy state / service statusへ進む。

同じ操作を繰り返しても観測が変わらなければ止める。

browser固有のclear項目が不明なら、公式helpや管理者へ戻る。

運営側は、長くcacheする変更可能assetでversioned URLや適切なvalidation policyを使い、同じ事故を減らせる。

cacheを空にしても、受付札は残った

status確認を終え、イトはupload tabへ戻った。

画面には、labの前回test sessionがまだsigned-inと出ている。

次の利用者へbrowserを渡すまで、二十秒。

イトはもう一度cache drawerを空にした。

signed-in表示は変わらない。

network requestには、upload session cookieが付いていた。

イトはcookie boxから、小さな受付札を一枚取り出した。

「これを消したら、loginだけが消える？　draftもaccountも消える？」

今度はcache drawerへ入れない。

受付札専用のdelete slotの前で止めた。

次回、ピコルート第94話。

イトは、共有browserのログイン札を消したら下書きまで消える？｜Cookie削除の境界