雑記帳 - JasminInfo

PukiWiki If-Modified-Since（条件付きリクエスト）対応

別の日記に少し書いてますが、ECO-Wiki (acronia)をIf-Modified-Since（条件付きリクエスト）に対応させたので、その方法をメモしておきます。

If-Modified-Since（条件付きリクエスト）とは

If-Modified-Sinceを使うと、ページが更新されている時だけデータを送って欲しい、という要求ができます。

• 初回アクセス
  1. [クライアント] ファイルください。
  2. [サーバー] はいどうぞ。ファイルの更新日時は「Wed, 25 Mar 2015 15:07:33 GMT」。(200 OK 応答)
• 2回目以降：更新されてない場合
  1. [クライアント] 更新日時「Wed, 25 Mar 2015 15:07:33 GMT」のキャッシュ持ってるけど最新版ある？（If-Modified-Sinceフィールド）
  2. [サーバー] 更新されてないから、内容は送らない。そのキャッシュ使って。（304 Not Modified 応答）
• 2回目以降：更新されている場合
  1. [クライアント] 更新日時「Wed, 25 Mar 2015 15:07:33 GMT」のキャッシュ持ってるけど最新版ある？（If-Modified-Sinceフィールド）
  2. [サーバー] 最新版あるので送る。(200 OK 応答)

PukiWikiでIf-Modified-Since対応する場合の問題

PukiWikiの場合、各ページの更新日時をどのような基準で決めるかが問題となります。

• ページを編集した日時にした場合：pcommentやinclude先、メニューバーが更新されても、そのページは更新されたと見なされない
• ページを構成しているファイル郡の中の最新更新日時にした場合：正しく動作するが、追加の処理が必要。負荷も増える。

対応方針

この問題は、bodycache適用時の問題と似ています。そこで、今回はbodycacheファイルの更新日時を対応するページの更新日時と見なすようにしました。

• bodycacheファイルはpcommentやinclude先が更新されたときもアップデートされるようにしているので、更新見落としが起こらない
  • bodycache patch適用範囲拡大を実施していることが前提
  • メニューバーの問題については、メニューバー更新のたびにbodycacheを全削除*1することで対応

改造内容

主にread.inc.phpを書き換えます。

• lib/bodycache.php
  • キャッシュファイルの更新日時を元にLast-Modifiedヘッダフィールドを返す関数
    • どこに書いても良いですが、bodycacheを前提にした記述なので、bodycache.phpに書きました。

      // Last-Modified header
      function header_lastmod_cache($page = NULL)
      {
          global $lastmod;
      
          if ( is_cache($page) && get_cachetime($page) != 0 ) { //get_cachetime==0の時は、そのキャッシュは破棄予定なので無視
              pkwk_headers_sent();
              header('Last-Modified: ' .
                  date('D, d M Y H:i:s', get_cachetime($page)) . ' GMT');
          } else if ( is_page($page) ) { //キャッシュが存在しない問いは現在時刻を使う
              header('Last-Modified: ' .
                  date('D, d M Y H:i:s', UTIME) . ' GMT');
          }
      }
      

• plugin/read.inc.php
  • If-Modified-Sinceフィールドヘッダの内容をunixtimeに変換して返す関数

    function get_if_modified_since()
    {
        static $unixtime = null ;
        if ($unixtime !== null ) {
            return $unixtime ;
        }
    
        if (!isset($_SERVER['HTTP_IF_MODIFIED_SINCE'])) {
            $unixtime = false ;
            return false ; // If-Modified-Since なし
        }
        
        $unixtime = strtotime( $_SERVER['HTTP_IF_MODIFIED_SINCE'] );
        return $unixtime ;
    }
    ?>
    

  • plugin_read_action関数内の改造
    • 変更前

      if (is_page($page)) {
          // ページを表示
          check_readable($page, true, true);
          header_lastmod($page);
          return array('msg'=>'', 'body'=>'');
      

    • 変更後: 更新の有無を確認して、更新されていなかったら304 Not Modifiedを送って処理を打ち切ります。また、header_lastmod_cacheでLast-Modifiedフィールドを送るようにします。

      if (is_page($page)) {
          // ページを表示
          check_readable($page, true, true);
          
          $ims = get_if_modified_since();
          if ( $ims ) {
              $ctm = get_cachetime($page);
              if ( $ctm && $ctm <= $ims) {
                  // 更新されていない
                  header('HTTP/1.1 304 Not Modified') ;
                  header_lastmod_cache($page);
                  exit;
              }
          }
      
          //header_lastmod($page);
          header_lastmod_cache($page);
          return array('msg'=>'', 'body'=>'');
      

pukiwiki bodycache patch 2重include対応

以前、#includeを含んだページで更新時にキャッシュが再生成されるような改良を行いましたが、この改良では上図のように#includeや#pcommentが2重に使われていると、キャッシュが正しく再生成されないことが分かりました。

このような場合、一番深いページを更新したときに、最上位のページのキャッシュが再生成されずに残ってしまいます。これは、キャッシュを再生成するページを探すときに、#includeや#pcommentを更新されたページから1段しかたどっていないために発生する現象です。

そこで、更新時に2段までページをたどってキャッシュを再生成するように変更しました。これで、2重include/pcommentまでなら正しくキャッシュが再生成されるようになります。

ただし、3重include/pcommentには未対応です。対応は難しくありませんが、たどる段数を増やすとその分負荷も増えるので、2重までの対応としています。

見出しタイトル化のバグ

タイトルプラグイン(PukiWiki)導入に合わせて、最初に出現したレベル1見出しをタイトル扱いにする改造を行いましたが、バグがあったようです。（季節イベントページをみていて気づきました。）

• 発生条件: includeプラグインが使われており、includeで参照しているページにレベル1見出しが含まれている
• 現象: レベル1見出しが含まれる最後のincludeがタイトルとして使われてしまう。
• 原因: includeを使うとconvert_htmlが複数回呼ばれることを考慮していなかった。その結果、後で呼び出されたconvert_htmlにより見出しから抽出したタイトルが上書きされていた。
• 修正前: Heading->Heading() 内の改造箇所

  if( $this->level === 1 && !isset( $root->title ) ){
      $root->title = preg_replace('|\s*\[.*|', '', $text);
      $root->title = preg_replace('|^\*\s*|', '', $root->title);
  }
  

• 修正後: Heading->Heading() 内の改造箇所

  //初回呼び出し時は $root->id は 1
  if( $this->level === 1 && !isset( $root->title ) && $root->id === 1 ){
      $root->title = preg_replace('|\s*\[.*|', '', $text);
      $root->title = preg_replace('|^\*\s*|', '', $root->title);
  }
  

また、includeプラグインの参照先ページにtitleプラグインが含まれている場合も、同様にincludeしたページのタイトルが優先されてしまうと思われます。ただ、このような使い方はたぶんしないと思うので、こちらの問題はそのままにしておこうかと思います。

続・PukiWiki bodycache patch副作用：id重複

PukiWiki bodycache patch副作用：id重複で適用した修正ですが、不十分だったようです＾＾；

原因は、やはりconvert_htmlが複数回呼ばれることを考慮していなかったことで、

function convert_html($lines)
{
	//省略
	static $contents_id = 0;
	global $bodycache_status;
	if ( $bodycache_status === 'cached' ) { //bodycacheから取得済み
		++$contents_id;
	}
	//省略
	$body = & new Body(++$contents_id);
	//省略
}

この修正では、includeによる2回目のconvert_html出力と、メニューバーの$contents_idが共に2になってid重複してしまいます。

ものすごく場当たり的ですが、以下のように再修正しました。

	if ( $bodycache_status === 'cached' ) { //bodycacheから取得済み
		$contents_id += 90 ; //これだけ足せばきっと重複しない・・・(^_^;)
	}

いっそ、メニューバーでは見出しの自動id生成をやめた方が良い気もしてきましたが、メニューバーだけ自動id生成をやめる方が修正は面倒そうです。（もしかしたら、本文も自動id要らないかも？）

PukiWiki UTF-8版とEUC-JP版

今の ECO-Wiki (acronia) はEUC-JP版

PukiWikiにはUTF-8版とEUC-JP版がありますが、現在はEUC-JP版を採用しています。理由としては、

• 元のECO-WikiがEUC-JPだった
• UTF-8版にすると転送量が増える
• UTF-8版にするとPukiWikiが内部的に使用するファイル名が長くなる
• UTF-8版にするとURLが長くなる（けど、そんなに大した問題ではないかな）
• UTF-8はあまりおすすめしないような記述があった*1

などです。

UTF-8版にするべきか

ただ、最近はUTF-8版にした方が良いかなと考え始めてます。

• 最近の文字コード事情はUTF-8が主流
• PukiWiki公式でもUTF-8推奨になった（PukiWiki開発日記、PukiWiki 1.5.0ダウンロード）
• 転送量は圧縮が効いていればそんなに問題ないかも

とはいえ、EUC-JPで困っているというわけでもないのでUTF-8版に置き換えるかどうかはちょっと悩ましいところです。

UTF-8版にするなら、PukiWiki 1.5.1のリリースに合わせることになるでしょうか。

UTF-8版にする場合の課題

• ファイルなどを全部UTF-8に変換する必要がある
  • 変換スクリプトが作られているようなので、これで変換を試みることになりそうです。
• （英数字以外をページ名に含む）各ページのURLが変わってしまう
  • 検索エンジンなどからのリンクが切れてしまうので、存在しないページにアクセスされたら、EUC-JP版URLへのアクセスと解釈して301 Moved Permanentlyで新URLに転送するような仕組みを入れたいところです。
    • と思って探してみたら、同じ事をやってた人がいました→PukiwikiをEUC→UTF-8移行した後もEUCのURLでアクセスできるようにする - あっきぃ日誌

PukiWiki bodycache patch副作用：id重複

たまたま気が付いたのですが、ECO-Wikiのメニューバーと本文それぞれの見出しのidが重複していました。

例えば、ECO-Wiki (acronia) トップページでは、メニューバーの「ECO攻略Wiki」と本文の「ECO-Wiki (acronia)：エミル・クロニクル・オンライン攻略情報wiki」に同じid="content_1_0"が振られています。

原因を追ってみたところ、どうやらbodycacheパッチの副作用のようです。

• 発生条件
  • PukiWiki bodycacheパッチを適用している。
  • MenuBarと本文の両方で見出しを使用している。
• 原因
  • bodyキャッシュを読み込んだときは、本文に対するconvert_htmlの実行はスキップされる。その結果、convert_html内の$contents_idがインクリメントされなくなるため、メニューバー生成時のconvert_htmlの実行結果に影響を与えてしまう。

    function convert_html($lines)
    {
    	//省略
    	static $contents_id = 0;
    	//省略
    	$body = & new Body(++$contents_id); //この$contents_idのインクリメントが必要
    	//省略
    }
    

• 対策
  • 場当たり的な対応ですが、$bodycache_statusが'cached'になっていたら、bodycacheによりconvert_htmlの実行がスキップされたと見なして、$contents_idをインクリメントするコードを追加しました。

    function convert_html($lines)
    {
    	//省略
    	static $contents_id = 0;
    	global $bodycache_status;
    	if ( $bodycache_status === 'cached' ) { //bodycacheから取得済み
    		++$contents_id;
    	}
    	//省略
    	$body = & new Body(++$contents_id);
    	//省略
    }
    

追記

改良したbodycache patchを公開しました。