【眼から鱗】ブラウザのキャッシュは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表記ではキャッシュを無効にすることができなかったから。
上記ブログ内にも
これらの設定によってキャッシュを完全に抑止できる訳ではありません。
ブラウザの種類やバージョンやバグによって、上記の指定が無効だったり、ネットワーク上のプロキシサーバーがキャッシュしてしまったりする場合があります。
とあるように、環境に結構、左右されてしまうものらしい。
やはり、「更新されてないよ」から「リロード(再読み込み)してください」 の流れは逃れられないようだ。
ただ、夏休み中とかにこれが原因でクライアントから電話があったりするとやっぱりちょっと萎える。
アドセンス広告メイン
関連記事
-
当社の今後
1年以上前の記事です。内容が古い可能性があります。どうも、次期社長さんがWebに …
-
「position:absolute」の親要素に「relative」は世代を超えて設定可能【Webデザイン・CSS】
1年以上前の記事です。内容が古い可能性があります。CSSを使ったWebデザインで …
-
インターネットは強者のツール? #2
1年以上前の記事です。内容が古い可能性があります。弱者が強者に勝つためには強者と …
-
ブラウザでオンラインゲーム。HTML5+JavaScriptで書かれたRPG
1年以上前の記事です。内容が古い可能性があります。ついにブラウザでRPG(ロール …
-
自分のサイトの外部リンクがどのくらいクリックされているか調べる方法
1年以上前の記事です。内容が古い可能性があります。Google Analytic …
-
Google+ページとWordPressを連携させた時、記事を一般公開設定にする方法
1年以上前の記事です。内容が古い可能性があります。今まで使っていたブログサービス …
-
ブックマークレットをカスタマイズした
1年以上前の記事です。内容が古い可能性があります。ライブドアブログ(livedo …
-
今、ネットではやっているもの。
1年以上前の記事です。内容が古い可能性があります。ねこ鍋、FX、twitter、 …
-
Photoshop(フォトショップ)を使ったWebデザインで注意する点
1年以上前の記事です。内容が古い可能性があります。学校で生徒さん用にまとめたので …
-
twitterfeedが調子悪いかも
1年以上前の記事です。内容が古い可能性があります。英語の読めない僕の設定が悪いの …
Comment
数年前の記事ではありますが。。。
本当の意味でキャッシュさせないのであれば、CGIを使うと可能性は上がります。
PerlやPHPで作成した動的コンテンツであれば、同じURLでもコンテンツ内容が変化するので、プロクシサーバでも基本的にはキャッシュされません。
ただ、動的コンテンツもキャッシュすることを試みるプロクシサーバもありますので、そのあたりがネックですね。
POSTする値(プログラムの引数)で表示する画像が違うPHPのプログラムがあったら、キャッシュさせることなくできると思いますよ。
もしくは、ダウンロードさせる的な感じの。
URLも
http://hogehoge.jp/hogeimage.php
って感じになるので、IDとパスワードで振り分けたら、お客様にもURLを毎回伝える必要がなくなるので、いいかもしれませんね。