| [ホーム] -> [SSI 実験室] |
SSI には、常にパフォーマンスと、セキュリティの問題がついて回ります。この二つには、どれが良いとか悪いとかの決まりが無く、大変難しい問題です。
SSI がサーバにとって負荷になっている場合と、全く負荷にならない場合があります。サーバの稼働状況、トラフィックスをよく調べて下さい。SSI を使う価値と、サーバの負荷を天秤に掛け、適切に使用してましょう。
あまりにも負荷がかかるようならば、代替方法を検討する必要があるかも知れません。ヘッダと、フッタを付けるために、include コマンドを使っているのならば、cpp（C言語用プリプロセッサ）や、m4（UNIX系のシステムで使用できるマクロプリプロセッサ）などを使用するのも良いかも知れません。また、それ以外でも flastmod コマンドなども、sed や awk 、あるいは Perl などのプログラムを用いて、事前に整形しておけるでしょう。アクセスヒットカウンターにも SSI がよく使われますが、リアルタイムで表示したいので無ければ、アクセスログよりカウントすることも出来ます。
自分が作ったプログラムが悪用されたくない場合は、ファイルのパーミッションをよく考える必要があります。SSI で呼ばれるプログラムなどは、無条件に chmod 777 にする方がいますが、これは必ずしも必要ではありません。大抵の WWW サーバは、nobody グループの nobody ユーザとして実行されます。そして、自分のアカウントは大抵 users グループに属しています。従って、chmod 705 でも大抵は問題ないはずです。もし、777 に設定しておくと、他のユーザが変更できてしまいます。また、通常の ftp でファイルを送信した場合、デフォルトのパーミッションは、664 の場合があります。これもまた、他のユーザがファイルを変更できてしまいます。プログラムのパーミッションを 755 ではなく 705 にする必要があるのは、「SSI で呼ばれるプログラムは、他人にソースを見せるべきでは無い」という考えからです。思いもよらない方法で、自分が気づかなかったバグを、他人に悪用されるかも知れません。
SSI を使ったページは、多くのクライアントや、プロキシサーバに搭載されているキャッシュ機能を無効にさせます。何故かというと、SSI を使ったページは常に何らかの変更があると WWW サーバが判断し、クライアントからのリクエストに対し、毎回ページを整形して送信してしまうのです。それによって、毎回同じ内容が送信されるとしても、サーバはクライアントに誠実に同じデータを送信します。これは、帯域幅を減らすことや、素早く表示させるという本来のキャッシュの機能を無効にしてしまいます。データをリクエストごとに変更する必要が無いのであれば、SSI ではなく他の方法を使用することを検討しましょう。