How to set HTTP headers (for cache-control)? という問いが意味をなさないそんな日は

諦める、以上。

タイトルはいつものごとく StackOverflow

なんか毎投稿繰り返してる気がするが「WEB アプリケーションに本気」てこと自体ワタシにはこれまでから考えれば奇跡的なわけで、色々知らんことだらけというよりは「知識がとにかく古くて困っている」わけなんだけれど、ただ、Cache-Control についてはちょっと別で、「古い知識でも」実際現状はそう変わってない。少しはあるみたいだけど

根本的「オレ的」問題は単に「色々失念しておる」てことなだけだった。記憶を辿ろうと WEB ブラウズするも、どうにも記憶が蘇ってこない。いや、これは「誰が指示出来て、どこのどいつが従い、無視し、そしてブラウザはどう振舞うのだ?」という、「誰がどこで」の情報が、なんだか見つけられない。うーん。

と、ふと「そういやぁ、随分古い本持ってたっけなぁ、確か海外の人が書いてるちゃんとした本だったよな、HTTP 1.1 も網羅してたよな」と:

HTTPプロトコル―セキュア&スケーラブルなWeb開発

中古価格
¥59から
(2018/2/7 04:57時点)


一瞬で解決した。うーん、久しぶりかもな、「本の方が安上がり」な体験。というか凄まじい値段だが、まぁ 2002 年の本だもん、今わざわざ誰がこれを買うか、てもんだわな。

何かつーとね、以前まさに max-age の話を書いて、まぁそれをしようと思ったんだけどさ、もう相手が違うからね、同じではないんだよね。

つまり、引用した記事を書いたときの相手はこれは httplib2、つまりこれは「ローカルプロキシ」であって、今ワタシがやってる「ajax で特定のサーバとお喋りする」のとは根本的なところで違うわけね。

max-age に限らずちょっと一般論的には、「クライアントが願う目的のもの、サーバが応答の性質を主張する目的のもの」両方あって、一方でしか使えないものと、両方で使われるものの両方ある。max-age は両方で使われる。no-cache も同様。

で、この「no-cache」なのよ、今ワタシがツラいなぁ思っていたのは。本読んでやっとわかったのはこれ。つまり、「サーバが no-cache を返してきたら」、これはクライアントが逆らう術がないのよね。「こちとら古くてもいいんじゃボゲぇ」とどんだけわめこうが、「毎度取りに来いやヲラァ」とサーバが主張してくる限り、ブラウザは絶対にこれに逆らわない。最低でも「新しいかどうかの確認」だけは必ず行う。

もちろんこういったことは「双方の合意に基いて」ということなので、クライアント側だけの願いが強いのも困るし、サーバ側の主張だけが強いのも両方本来は困るんだけれど、ただここからが問題で、「WEB アプリケーションが正確に振舞うためには」、サーバ側の主張の方が優位でないとこれは非常に困るんだよね。銀行の WEB バンクなんか考えてみればいい。こんなので「クライアントが望んだから」という理由でキャッシュなんか使われた日には、これは本当に目も当てられない災害になる。だからこれは正しいこと、なのだけれど。

ただねぇ、「うーん、お前、no-cache 主張しとるけど、そこまでのもんなのけ?」ての、あるでしょう。具体例がまさに今ワタシが相手してる MAL。こんなもんさぁ、別に 10分古かろうが誰が気にするかね、と思うんだけどなぁ。なんなら1週間前のだって大抵十分ぞ。(は言い過ぎか。常識的な範囲内なら、10分程度なら許容出来んじゃないのかね。)

まぁこういう「登録しているユーザが自由に編集・レビュー出来る」ものが no-cache してるのは「当然」という意見もあるでしょうがね、けどそれさぁ、「登録してるユーザが編集モード時は」てことなんじゃないの? なんで全員誰もが「1マイクロ秒さえも遅延は許さん」と思うかね。

というわけで、隅々までちゃんと意味が理解出来た上でなおも気分的には「なんだかなぁ」が抜けない。まぁこんなもんに抜け道作ったらまたダークサイドへまっしぐらなので、出来ちゃいけないことも理解の上で、だよ。

というわけで、結局「古くてもいいんじゃボケぇ」は、使えないときは使えない、のを受け容れるしかないわけなんだけれど、無論「自分でキャッシュする」ことは出来て、まぁどうしてもということなら、結局それしか手はない。indexDB ちゃう? これだけのために? まぁないではないか。