日記/2004-04-17

続キャッシュ †

Pragma: no-cache とかのヘッダを殺して，キャッシュ可能にしてみる． が，やはり，思った通り，キャッシングと PukiWiki（というか CGI）は相性が悪い． 「最新のコンテンツを見るにはリロードボタンを押してね」というのも，めんどくさい．

まっとうな手段としては，PukiWiki のレイヤーでコンパイル済みのコンテンツを用意しておいて，PukiWiki のレイヤーでキャッシュしておくことなのだけど，これはこれで大改造が必要な気はする． へなちょこハックでは歯が立たないだろう．

squid によるキャッシュサーバと PukiWiki †

PukiWiki が重いので，設定してみる．

squid は，LAN 内からのアクセスを proxy サーバとして受け，外部の web サーバにアクセスする用途に用いられることが多い．

LAN 内 web client ---> 8080:squid ---> 80:web サーバ

が，

Internet の web client ---> 80:squid ---> 80:LAN 内の web サーバ

という設定も可能なのである．

この場合，squid が待ち受けている 80 番ポートでのやりとりは apache などの「web サーバ」のものと同様のものであり，proxy サーバのプロトコルとは微妙に異なる． squid は，このような設定にも対応している．

で，今回は同じサーバ内で動作している apache と同居させようとする．

           WAN          lo
web client --> 80:squid --> 8080:apache

という構成で同居させようと企む．

squid のアクセスコントロールの設定で悩むが，とりあえず，設定は成功． で，従来の HTML コンテンツのアクセスは問題なく行うことができる．

問題の PukiWiki コンテンツは…

ぐはっ…リンクが全て http://localhost:8080/… に化けてるじゃん

これでは使いものにならない．

で，ソースと相談してみる． find.php の get_script_uri() という関数で，環境変数の SERVER_PORT, SERVER_NAME から URL のサーバ名部分を生成していることがわかる． つまり，apache が localhost:8080 で上がっているために URL がこのように化けてしまうわけである．

となると，話は簡単． 問題の get_script_uri() 関数の最初の部分を

function get_script_uri()
{
       global $override_uri;  
       if ( $override_uri === '' ) {
               // scheme
               $script  = ($_SERVER['SERVER_PORT'] == 443 ? 'https://' : 'http://');
               // host
               $script .= $_SERVER['SERVER_NAME'];
		// port
               $script .= ($_SERVER['SERVER_PORT'] == 80 ? '' : ':'.$_SERVER['SERVER_PORT']);
       } else {
               $script .= $override_uri;
       }

このように書き換え，pukiwiki.ini.php に

/////////////////////////////////////////////////
// PukiWiki サーバの URI
// '' で自動検出
// キャッシュサーバによるサービスを行う場合など，自動検出が失敗する場合は
// 設定すること
//$override_uri = '';
$override_uri = 'http://jr0bak.homelinux.net';

このような変数を追加する．

これでようやく思った通りの動きをしてくれました． が，PukiWiki からは Last-modified: や Expires: ヘッダを出力してくれないので，キャッシュの効果がどの程度あるかは謎である．

# しかし，PukiWiki は，はっくするつもりでインストールしたんじゃないのだがなぁ __|￣|○