いまさらXOOPSCube Legacyの吐くHTTP-headerを通してHeaderのキャッシュを勉強する

恥ずかしながら、XOOPSCube Legacyの吐いているHeaderについてよく知らなかったのでちゃんと調べる。
http://www.studyinghttp.net/header

modules/legacyRender/kernel/Legacy_RenderSystem.class.php の453行目あたり

<?php
	/**
	 * @deprecated
	 */
	function sendHeader()
	{
		header('Content-Type:text/html; charset='._CHARSET);
		header('Expires: Mon, 26 Jul 1997 05:00:00 GMT');
		header('Last-Modified: '.gmdate('D, d M Y H:i:s').' GMT');
		header('Cache-Control: no-store, no-cache, must-revalidate');
		header('Cache-Control: post-check=0, pre-check=0', false);
		header('Pragma: no-cache');
	}

Expires / Last-Modified / Cache-Control / Pragma については、キャッシュの取扱いについて。だからほとんどがキャッシュの取り扱いについてのHeaderを送ってるということになる。

ちなみに、その優先度はHTTP/1.1では

Cache-Control ＞ Pragma ＞ Expires ＞ Last-Modified

なんなんじゃないかなーって思うんだけど。そもそもLast-Modified はサーバに送ってるってことだし。

こんな感じかな

あと重要なのが「キャッシュを利用するのはブラウザとプロキシがある」ってこと。Headerがブラウザ向けに発せられているかプロキシ向けに発せられているかの認識を持たないと。

Content-Type

これから送信する文書(あるいはバイナリ)の意味。ブラウザはこれを手がかりにHTMLファイルとかGIFファイルだとかを認識して処理する。

Expires

コンテンツの有効期間。これを見て、ブラウザはキャッシュを使えるかどうかを判断する。しかし、面倒な文字列や・・・。

Last-Modified

コンテンツの最終更新時刻。今まで気にしてなかったけど、ブラウザって一度見たURLのものはHTTPサーバに

If-Modified-Since: Thu, 12 Jun 2008 01:40:32 GMT

ってのを送ってる。

Staticなコンテンツの場合、Apacheは

HTTP/1.1 304 Not Modified

ってHeaderだけ返して、Contents部分は送らない。

Cache-Control

キャッシュのコントロール方法について指定。最優先で利く。
HTTP/1.1で新しくつけられたHeader。HTTP/1.0しか理解しないブラウザには無効。

でも、Cache-Controlのとる値って、
http://www.studyinghttp.net/caching#Expiration_Model

Cache-Control = "Cache-Control" ":" 1#cache-directive
cache-directive = cache-request-directive
| cache-response-directive
cache-request-directive =
"no-cache" ; Section 14.9.1
| "no-store" ; Section 14.9.2
| "max-age" "=" delta-seconds ; Section 14.9.3, 14.9.4
| "max-stale" [ "=" delta-seconds ] ; Section 14.9.3
| "min-fresh" "=" delta-seconds ; Section 14.9.3
| "no-transform" ; Section 14.9.5
| "only-if-cached" ; Section 14.9.4
| cache-extension ; Section 14.9.6
cache-response-directive =
"public" ; Section 14.9.1
| "private" [ "=" <"> 1#field-name <"> ] ; Section 14.9.1
| "no-cache" [ "=" <"> 1#field-name <"> ]; Section 14.9.1
| "no-store" ; Section 14.9.2
| "no-transform" ; Section 14.9.5
| "must-revalidate" ; Section 14.9.4
| "proxy-revalidate" ; Section 14.9.4
| "max-age" "=" delta-seconds ; Section 14.9.3
| "s-maxage" "=" delta-seconds ; Section 14.9.3
| cache-extension ; Section 14.9.6
cache-extension = token [ "=" ( token | quoted-string ) ]

こんなにあるのかYo!　とりあえず、no-cacheとno-store 。

no-cache 一切キャッシュしない
no-store 機密情報がある場合、一時保存領域に保存したとしてもすぐに削除することが命じられる。これはRequest/Responseの両方共が使える。しかし、これはあまり意味無いんじゃないかなー。パケットキャプチャはともかく、普通にブラウザで保存しちゃえるし。性善説っぽい気がする。
post-check, pre-check I.E5以上用の拡張表現。この二つで

pre-chec=[n] n秒間、コンテンツキャッシュが有効である
post-check=[n] 上記のpre-checkと組み合わせて、このpre-checkの期間内でも取得からn秒以上経過した場合、キャッシュは使うがバックグラウンドで新しいコンテンツの検証を行い、必要に応じて新しいコンテンツを取得しなおす。・・・・使うってことか？よーわからんね。

XOOPSのキャッシュコントロールがキツイ件

たぶんだけど、昔のXOOPSって

んー、一回登録した後にブラウザの「戻る」で再度登録されたら困るなー。整合性取れない場合あるし
あと、ページを動的にしてるんだから絶対リロードさせるべきだよ！
「じゃあ、すべてのページで絶対読み込ませるようにしてしまえ！」

って感じでこの「ブラウザの戻るを押しても絶対再読み込みさせる」っていう仕様になったんじゃないかって思う。

しかし、これが普通の人には「なんかXOOPSって重い」っていうイメージの一助にもなっちゃったんじゃないかな。

私もXOOPSサイトを見るときは「戻るボタンでサクサク戻らせてくれよぉ・・・」って思う。

tohokuaikiのチラシの裏

技術的ネタとか。