雑記帳 - JasminInfo

初回アクセス
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'=>'');

コメント（8件）

2015/02/03(火)bodycache patch 2重include対応

ECO::ECO-WikiProgramming::PukiWiki

pukiwiki bodycache patch 2重include対応

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

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

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

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

コメント（0件）

2015/02/03(火)見出しタイトル化のバグと続・PukiWiki bodycache patch副作用：id重複

ECO::ECO-WikiProgramming::PukiWiki

見出しタイトル化のバグ

タイトルプラグイン(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要らないかも？）

コメント（3件）

元の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でアクセスできるようにする - あっきぃ日誌

コメント（0件）

		2024/12
日	月	火	水	木	金	土
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30	31

雑記帳 - JasminInfo

検索条件

2016/03/20(日)PukiWikiを1.5.1に更新

PukiWikiを1.5.1に更新

2015/03/26(木)PukiWiki If-Modified-Since（条件付きリクエスト）対応

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

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