【眼から鱗】ブラウザのキャッシュはHTMLで制御できた
1年以上前の記事です。内容が古い可能性があります。
過去にはサイトデザインをプリントアウトしてお客様のところへもって行き、デザイン案をみてもらっていた時代もあったがさすがに今はそんなことはやらない。
仮サーバーを用意してそちらにデザインデータをアップ。直接、Web上で見てもらうのが主流。
まあ、どうしてもプリントアウトで見たいというお客様もいるにはいるのだが。。
で、Web上で見てもらうにしてもいろいろと問題点はあって、特に度々問合せが来るのが「更新されていないよ」という問合せ。
実はこれはキャッシュが悪さをしていることが殆ど。
キャッシュとは一度ダウンロードしたWebのデータ(画像、CSS等)を保管しておくスペース及びそのデータ。
同じサイトに再訪問した際、わざわざその度にインターネットからデータをダウンロードせず、一度ローカルに保存したデータを表示するというのが一般的なブラウザの仕様となっている。
そのために、たとえば画像の一部を修正したり、外部CSSの一部を修正したりした際に、更新されていないデータが表示されてしまうことがあるのだ。
で、そんなときはリロード(再読み込み)してくださいとお願いするのだがこれがちょくちょくあるのが悩みの種。
仮に、何とかしようと思っても、これはブラウザ側で設定する以外回避する方法はないのではないかと思っていた。
が、なんと、HTMLやCGI上でこれを回避するための記述があったらしい。
それを解説しているのが以下のサイト。
HTMLページの場合は <head>~</head> の間に以下の3行を書きます。
<meta http-equiv=”Pragma” content=”no-cache”>
<meta http-equiv=”Cache-Control” content=”no-cache”>
<meta http-equiv=”Expires” content=”Thu, 01 Dec 1994 16:00:00 GMT”>Perl/CGIの場合は HTTPヘッダで以下のような出力をします。
print “Content-type: text/html\n”;
print “Pragma: no-cache\n”;
print “Cache-Control: no-cache\n”;
print “Expires: Thu, 01 Dec 1994 16:00:00 GMT\n\n”;PHP/CGIの場合は Perlと同じくHTTPヘッダに以下のような出力をします。
header(“Content-Type: text/html; charset=文字コード”);
header(“Expires: Thu, 01 Dec 1994 16:00:00 GMT”);
header(“Last-Modified: “. gmdate(“D, d M Y H:i:s”). ” GMT”);
header(“Cache-Control: no-cache, must-revalidate”);
header(“Cache-Control: post-check=0, pre-check=0”, false);
header(“Pragma: no-cache”);ワードやエクセルファイルなどの場合は サーバの設定を変更して、HTTPヘッダを追加します。
サーバが Apache の場合は、httpd.conf で以下の設定を加えます。<Files ~ “\.(doc|xls)$”>
Header set Pragma no-cache
Header set Cache-Control no-cache
Header set Expires “Thu, 01 Dec 1994 16:00:00 GMT”
</Files>
上記の表記をそれぞれHTMLやPerlスクリプト等に書き加えればキャッシュを無効にできるとのこと。
HTMLだけじゃなく、PerlやPHPでもできるのだが、むしろそのほうが確実かもしれない。
というのは、「Google Corme」で動作確認してみたところ、上記HTML表記ではキャッシュを無効にすることができなかったから。
上記ブログ内にも
これらの設定によってキャッシュを完全に抑止できる訳ではありません。
ブラウザの種類やバージョンやバグによって、上記の指定が無効だったり、ネットワーク上のプロキシサーバーがキャッシュしてしまったりする場合があります。
とあるように、環境に結構、左右されてしまうものらしい。
やはり、「更新されてないよ」から「リロード(再読み込み)してください」 の流れは逃れられないようだ。
ただ、夏休み中とかにこれが原因でクライアントから電話があったりするとやっぱりちょっと萎える。
アドセンス広告メイン
関連記事
-
-
Web制作・管理でよく使うツール
1年以上前の記事です。内容が古い可能性があります。以前、紹介すると言っていたWe …
-
-
DMOZ(OPD)のエディタになってみる?
1年以上前の記事です。内容が古い可能性があります。DMOZの印刷カテゴリに会社の …
-
-
メモリが”read”になることはできませんでした。
1年以上前の記事です。内容が古い可能性があります。Windowsのアプリケーショ …
-
-
「BLOG of the year 2009」発表!【今週のトピック】
1年以上前の記事です。内容が古い可能性があります。ブログにもいろいろな賞があるん …
-
-
サイト利用状況のアンケート
1年以上前の記事です。内容が古い可能性があります。社内でサイト利用状況のアンケー …
-
-
知らぬ間に。。
1年以上前の記事です。内容が古い可能性があります。ホームページがどーんと増えてま …
-
-
ユビキタスの第一歩、スマホ(スマートフォン)やタブレットで家電が遠隔操作できる「heimcontrol.js」
1年以上前の記事です。内容が古い可能性があります。ユビキタスという言葉は最近あま …
-
-
クリックジャッキングとは何?
1年以上前の記事です。内容が古い可能性があります。今朝、通勤途中でJ-WAVEで …
-
-
WordPressの更新(アップデート)作業、ちゃんとやったら10万円
1年以上前の記事です。内容が古い可能性があります。自分も使っているWordPre …
-
-
CSS2.1まとめ書き-border編(HTML・CSSリファレンス)
1年以上前の記事です。内容が古い可能性があります。CSS2.1まとめ書きとしてい …
Comment
数年前の記事ではありますが。。。
本当の意味でキャッシュさせないのであれば、CGIを使うと可能性は上がります。
PerlやPHPで作成した動的コンテンツであれば、同じURLでもコンテンツ内容が変化するので、プロクシサーバでも基本的にはキャッシュされません。
ただ、動的コンテンツもキャッシュすることを試みるプロクシサーバもありますので、そのあたりがネックですね。
POSTする値(プログラムの引数)で表示する画像が違うPHPのプログラムがあったら、キャッシュさせることなくできると思いますよ。
もしくは、ダウンロードさせる的な感じの。
URLも
http://hogehoge.jp/hogeimage.php
って感じになるので、IDとパスワードで振り分けたら、お客様にもURLを毎回伝える必要がなくなるので、いいかもしれませんね。