続キャッシュ †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 コンテンツは…
これでは使いものにならない. で,ソースと相談してみる. 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 は,はっくするつもりでインストールしたんじゃないのだがなぁ __| ̄|○ |