アプリケーションキャッシュでキャッシュしてくれない時

2013/10/28 | html5

html5の機能の一つであるアプリケーションキャッシュ。htmlファイルやcss等を専用のストレージに格納してくれる機能だ。

仕事でアプリケーションキャッシュを使うことになった。最初のうちは問題なく動作確認できていた記憶があったが、つい最近使ってみたけど何故かキャッシュしてくれない事象が発生。「拡張子を昔みたいにmanifestに戻してみたり」「htaccessを配置してmimeタイプを設定してみたり」したけど全然ダメ。理由がわからない。

そこで初心に立ち返って、最小限のテストコードで試行錯誤してみたら原因がわかった。

どうやらアプリケーションキャッシュは、マニフェストファイルに書かれたキャッシュすべきファイルを取得できなかった時(not foundとか)にキャッシュをやめるんだか破棄してしまうんだか、そんな仕様になっているようだ。問題のあるファイルをスキップして残りはキャッシュしてくれる、ということではないらしい。ChromeとFirefoxで確認した。

もちろんキャッシュしたいのだから「正しく指定する」ということが大前提ではあるのだが。中途半端に動作すると原因の究明が大変だからそういう仕様なのかな、とも思ったりした。

アプリケーションキャッシュ

2012/03/06 | HTML・CSS関連

故あってアプリケーションキャッシュを使う必要がある。HTMLとかがキャッシュされるので便利だなぁ、と思っていたら、なんかいろいろ制約やら問題やらあるっぽい。

  • iOSのSafariで使用する場合、JavaScriptによるキャッシュ初期化処理を入れておかないとひどい目にあう。
    アプリケーションキャッシュの設定をして、iOSのSafariでアクセスすると、ブラウザの設定とかそういうのではキャッシュは削除できない。つまり一度キャッシュされたら最後、再インストールするまでキャッシュされ続ける(と@ITに書いてあった)。キャッシュの設定ファイルに更新日を記述しておくが、それも役に立たないらしい。で、 それを回避するにはあらかじめそういうチェックをするためのスクリプトを用意しておく必要があるとのこと。うっかり忘れたら偉いことになりそうな予感。

var cache = window.applicationCache;
cache.addEventListener(“updateready”, function() {
if (confirm(‘アプリケーションの新しいバージョンが利用可能です。更新しますか?’)) {
cache.swapCache();
location.reload();
}
});
if (navigator.onLine) {
cache.update();
}

  • 上記に関連することだけれど、キャッシュ設定ファイルを設置する際に、<html manifest=”…”>と記述するらしいのだが、このキャッシュ設定ファイル自体をキャッシュしてしまう、という問題があるとのこと。まぁ、そういう意味で日付とかシリアル番号とか入れるのかも知れない。

いずれにしてもうかつには手を出せない気がする。詳しく調べてからチャレンジすることにしょう。

恐るべし、アプリケーションキャッシュ。

縦書きのためのCSS

2011/07/27 | CSS

縦書きといっても国語の教科書のようにならなくてよくて、表組みして表示する際に、縦書きライクに表示させるためのCSSのメモ。

writing-mode:tb-rl;
-webkit-transform:rotate(90deg);
-moz-transform:rotate(90deg);

IE用、safari用、firefox用って感じ。一度に指定しておけば、とりあえず大抵のブラウザで通用するっぽい。見栄えが良くなるので、今後使うようにする。

cookieをおさらいしてみた

2010/11/11 | cookie

何を今更という感じだが、わかっているようでわかっていないクッキー(cookie)のおさらいをしてみた。まずPHPでセットしたクッキーについて調べてみた。

PHPでクッキーをセット(setcookie)すると、その情報はHTTPヘッダとしてブラウザに送出される。HTTPヘッダとして送出するための関数であるから、その関数よりも前に、ブラウザに対してはヘッダ以外の情報を出力しているとエラーになる。出力するHTTPヘッダーはこんな感じになっていた(この例はsetcookieではなくセッション開始の例)。

HTTP/1.1 200 OK
Date: Thu, 11 Nov 2010 01:26:46 GMT
Server: Apache
Set-Cookie: PHPSESSID=i7y59fnv2cphp1kf76bdodu4t8ii6elk; path=/; HttpOnly
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 2402
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=UTF-8

ブラウザに対してSet-Cookieヘッダを送っている。ちなみにsetcookie関数ではなく、header関数で直接上記の文字列を送出しても問題ないはずだ(試していないけれど)。送出された情報を見ると、値(この場合はセッションID)、パス、HttoOnly、期限(ブラウザを閉じるまで)の情報が送られている。またクッキーはデフォルトで、当該ホストとのみやりとり可能なので、アクセスしたホスト名に限定したクッキーとなっているはずだ。

サーバから上記のヘッダを送出されると、ブラウザを閉じない限り当該ホストに関して、ブラウザは今後永久に(クッキーの削除でもしない限り)、Cookieリクエストを送出するようになる。リクエストの例はこちら。

GET /dummy.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; ja; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12 GTB7.1 ( .NET CLR 3.5.30729; .NET4.0C)
Accept: text/css,*/*;q=0.1
Accept-Language: ja,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: Shift_JIS,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://www.example.com/
Cookie: PHPSESSID=i7y59fnv2cphp1kf76bdodu4t8ii6elk

/dummy.htmlをリクエストした例だ。リクエストの最後に、先程受信したクッキーを送出しているのが見て取れる。一旦クッキーをセットされると、ブラウザが閉じられるかそのクッキーが削除されるか有効期限が切れるまでは、ブラウザは当該ホストに対して必ずクッキー付きでリクエストを送るようになる。

以下は、/dummy.html内に含まれる/img/logo.pngに関するリクエストだ。

GET /img/logo.png HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; ja; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12 GTB7.1 ( .NET CLR 3.5.30729; .NET4.0C)
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: ja,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: Shift_JIS,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://www.example.com/
Cookie: PHPSESSID=i7y59fnv2cphp1kf76bdodu4t8ii6elk

クッキーの送出は対象が何であっても関係ない。拡張子も関係ない。プログラムであろうが、HTMLであろうが、画像であろうが、音楽であろうが、ブラウザが閉じられるかそのクッキーが削除されるか有効期限が切れるまでは、ブラウザは当該ホストに対して、ずっとクッキー付きでリクエストを送り続ける(そもそもブラウザがリクエストする時点でリクエスト対象に対して「これは画像」「これはHTML」とか淡い期待をいだいているだけで、本当にそういうものが返ってくるかどうか分からないから)。

自分で整理してみて、ちょっとだけ理解できた。あとはJavaScriptによるcookieの受け渡しを調べなきゃな。

session_set_cookie_params関数

PHPしかやっていなかったときは、極力クッキーを使って値を保存するようなことはしないようにしていた(セッションは使うけど)。クライアントサイドにデータを保存しても改ざんされる前提で使わないといけないからだ。しかし最近はいろいろ使うようにしている。そもそもGETやPOSTでの値引渡しと同じという前提でやれば問題ないわけで。ただ、GETやPOSTと違うのは値をセットする方法で、setcookie関数を使わないといけないところだ。GETやPOSTと同様にこんな感じでクッキーがセット出来ればいいのに。

$_COOKIE[‘_key’]=’_value';

まぁ、できないほうがいいという理由もわかるのだけれど。

で、最近使うようになったクッキーだが、便利な関数があることを知った。session_set_cookie_params関数だ。この関数一つでクッキー周りの設定がすべてできてしまう。

void session_set_cookie_params (
int $lifetime
[, string $path
[, string $domain
[, bool $secure = false
[, bool $httponly = false ]]]]
)

第1引数:セッション有効期限(秒)
第2引数:クッキーが動作するパス
第3引数:クッキーが有効なドメイン名
第4引数:https時のみ使用可能とするかどうか
第5引数:JavaScript等からのクッキーへのアクセスを許可するかどうか

デフォルトではPHPでセットしたクッキーを、JavaScriptから読み込むことはできないのかな。その逆はできるけど。


守谷市(まちの情報ポータル) 無料アンケートレンタルjpForm.net