● キャッシュ対策・トラブルシューティング

▼ 対策前のページではきちんと表示されていたのに、対策後のページではファイルが正しく表示されなくなる場合

1.ファイルタイプの設定をそれぞれのHTMLタグの中で行っておられますか?

ex.
css →「<lik rel="stylesheet" type="text/css" href="top.css">」
js → 「<script type="text/javascript" src="hoge.js">」
swf → 「<embed src="opening.swf" type="application/x-shockwave-flash"・・・>」
midi→「<embed src="bgm.mid" type="audio/x-midi"・・・>」

本対策前のファイル名には固有の拡張子がそのまま残っていますので、ファイルタイプがHTMLソース内に書かれていない場合でも、その拡張子を通じてブラウザがファイルタイプを推測してくれていました。ところが、本対策後は、ファイルタイプがHTMLソース内に書かれていないと、拡張子ではファイルタイプが推測できないため、一部のブラウザではファイルが正しく表示されません。

対策前のページでは、拡張子によってたまたまうまく表示されていただけというふうに考えていただき、これを機に今後は、HTMLソースの中で、ファイルタイプの設定を必ず行うようにしてください。

2.CGI形式の場合、パーミッションは正しく設定されていますか?

CGIの場合、パーミッションが適切でないとInternal Server Errorになりますから、画像などが表示されません。通常、パーミッションは705に設定する必要があります。やり方がよくわからない方はサポートにご相談ください。

当メニューで変換したHTMLソースが、<img src="getimage.php?r=igD5yV1klcpx-_EwhneqmMd2PQUSCt.ZIOGz4J6HF3uW7KBL0(・・・中略・・・)ULRJvTjgDNrxV3oBunO/bQKH86.f2lEdkseGt7ZF-q&c=XfA8o9bvTLKW3HJzOZtSQ2Mqnw_xckV5gizw0CISa">のようになっているのであれば、「http://」から始まるその画像のURLに直接アクセスしてみてください。

http://(お客様サーバのドメイン名)/(ディレクトリー)/geimage.php?〜でアクセスして、Internal Server Errorと表示されるのであれば、パーミッションが間違っている可能性があります。

3.CGI形式の場合、perlのパスは正しいですか?

弊社提供のCGIは「/usr/local/bin/perl」と設定しています。「/usr/bin/perl」などそれ以外の場合は、CGIファイルの一行目を書き直していただく必要があります。上記「2.」の項目のように、画像などのパスに直接アクセスした場合に、「Internal Server Error」が表示される場合は、この点をご確認ください。

4.CGI形式の場合、CGIがCGI-BINなどの特殊ディレクトリーでのみ動作するようなサーバ設定になっていませんか?

この場合、カスタマイズ(プラス5千円)が必要です。サポートにご相談ください。

5.弊社提供のCGIやPHPファイルを、暗号化したHTMLファイルと同じディレクトリーにアップしていますか?

当然といえば当然ですが、CGIファイルやPHPファイルがアップロードされていない場合、動作しません。また、アップロードするディレクトリーは暗号化したHTMLファイルと同じディレクトリーです。キャッシュ対策をしたい画像と同じディレクトリーではありませんのでご注意ください。

 baseタグを使っている場合は、baseタグで指定したパスに、弊社提供のPHP(CGI)プログラムはアップロードしてください。

6.(ごく稀なケース).htaccessで画像の転送設定を行ったりしていませんか?

.htaccessを使って、abc.gifのアクセスを全て「http://(別のサーバ)/abc.gif」や「http://(同じサーバ)/(別のディレクトリー)/abc.gif」などを読み込むように転送設定(Redirect)をしていませんか? そのような場合は動作しません。

7.弊社への問いあわせの前に、以下の点をご確認ください

  • オリジナルのファイルでは本当に画像ファイルなどがちゃんと表示されていましたか? お手数ですが、もう一度ご確認ください。ローカルではしっかりと表示されていても、画像などをサーバにアップし忘れていることは結構あることです。

  • オリジナルのファイル(ファイルA)から一旦キャッシュ対策用のHTMLファイル(中間生成物のファイルB)に変換してから、暗号化してファイルCを生成するという2ステップを本対策では取っていますが、では、この中間生成物ともいうべきファイルBの段階では、画像ファイルなどはちゃんと表示されていますか? 問題を特定するために必要な情報ですので、お手数ですが、お調べください。

  • 弊社(shtml2@princesse.com)へお問い合わせの場合には、恐れ入りますが、「オリジナルのファイル」「中間生成物のファイル」「暗号化後のファイル」をお客様のサーバにアップしていただき、弊社で確認できるURLをお知らせください。

▼ キャッシュ対策をしているにもかかわらず、キャッシュに残ってしまう場合

8.該当のファイルは、暗号化前のHTMLソースの段階で拡張子が.phpもしくは.cgiにしっかりと書き換わっていますか?

本対策は、ソースを一旦、CGIもしくはPHP経由で読み込むように書き換えてから、暗号化します。そして、皆さんに確認してもらいやすいように、敢えて、2ステップに分けてあります。まずは、暗号化の前段階でのソースにて、該当ファイルの部分がCGIやPHPでのパスに書き換わっているのか確認してみてください。全体ではなく、そのファイルの部分だけ書き換わっていない場合、以下のような理由が考えられます。

  • この対策では仕様上、ファイル名に使用できる文字に制限があります。英数字(AからZ、aからz、0〜9)及び「-」(ハイフン)、「_」(アンダーバー)、「/」(スラッシュ)、「.」(ドット)のみです。日本語はもちろん、半角スペースなど対象外の文字列が含まれている場合、キャッシュ対策の対象になりません。なお、仕様上の制限などにより、変換対象にならなかったパスのリストは、変換結果の下に表示されるようになっています。変換時に、変換対象外のリストとして表示されていないかどうかご確認ください。

  • http://やhttps://で始まるURLは対策の対象外です。他のドメインにあるコンテンツはもちろんのこと、プログラム(PHPファイル/CGIファイル)と同じサーバに存在している場合でも、http://やhttps://で始まる形でパスを指定している場合、本対策の対象外になります。相対パスやドキュメントルートからの絶対パスに書き換えてください。

  • JavaScriptでdocument.writeしているソースの中のパスはうまく抽出できない場合があります。その場合は、JavaScriptの書き換えを一度試してみてください。もしくはサポートにお問い合わせください。また、JavaScript内で読み込んでいる画像であっても、こちらの方法でうまく対処できる場合もあります。ご参照ください。

  • キャッシュ対策できるファイルの拡張子には制限があります。、「.jpg」「.jpeg」「.gif」「.png」「.js」「.css」「.swf」「.midi」「.mid」「.mp3」「.wav」ファイルのみが対策の対象です。また、HTMLタグで言いますと、IMGタグのSRC属性、LINKタグのhref属性、SCRIPTタグのSRC属性、BGSOUNDタグのSRC属性、EMBEDタグのSRC属性、PARAMタグをチェックしています。ですから、同じ画像であってもbodyタグやtableタグの背景画像で指定された画像の場合、そのままではPHP形式(CGI形式)のパスに変換できません。対処法はこちらをご参照ください。


9.レスポンスヘッダーを無視するようなproxyを通したアクセスの場合、キャッシュが残ることがあります。

「キャッシュを残してはいけない」という命令を無視するように実装されているproxyでのアクセスに対しては対処のしようがありません。イントラネット内でのご利用で、このキャッシュ対策を希望されている場合には、サンプルページで挙動を一度ご確認ください。

10.HTML本体のキャッシュ対策は、本対策の対象外であることはご存知でしょうか?

HTMLファイル自体は暗号化されていますのでキャッシュに残ってもそれほど問題はないと思いますが、何らかの事情でキャッシュファイルとして残したくない場合には、サポートにご相談ください。


その他、よくある質問もご参照ください。


© 株式会社プランセス