adiary開発日誌

can メソッドの罠

Perlのマニュアルによれば、オブジェクトのメソッドを調べるには、すべてのクラスで継承される UNIVERSAL クラスの can メソッドを用いて

if ($obj->can("function_name")) { $obj->function_name(); }
if (MYCLASS->can("function_name")) { MYCLASS->function_name(); }

としろと書いてあります。実際この判定はうまく動き、スケルトンシステム（Satsukiシステム）が今ほど本格的になる前のテンプレートに少し毛が生えた程度のころは、この can メソッドを使って関数呼び出しと変数の判別をしていました*1。

この can メソッドには罠があって、オートローダー（AUTOLOAD 関数／メソッド）が定義されているときcanメソッドは常に true を返します。AUTOLOAD というのは、もともとはPerlの関数を必要なときに動的ロードする仕組みであって、Satsukiシステムでは独自のオートローダーを定義しています*2。さらに、呼び出された関数が未定義のときに呼び出されるという仕組みを用いて、あたかも関数のような動作を動的生成ということも可能です。AUTOLOADは、未定義関数をロードして代理で呼び出すなり、あたかもその関数が存在するように振る舞うなりすればいいということになります。

# オブジェクト内のハッシュを返すメソッド
# 呼び出した未定義関数はグローバル変数「our $AUTOLOAD」に入っている。
sub AUTOLOAD {
	# $AUTOLOAD='MYCLASS::FUNCTION' → $func='FUNCTION'
	my $func = substr($AUTOLOAD, rindex($AUTOLOAD, '::')+2);
	my $self = shift;
	return $self->{$func};
}

canメソッドが正常に働くとき、働かないとき

Satsukiシステムのオートローダーは、

Auth.pm
Auth_auto.pm
Auth_auto2.pm

という具合に、目的の関数が見つかるまで次々と連番のモジュールをロードしていくという方式で*3、AUTOLOAD内で次々とモジュールをロードしながら、canメソッドを使用して目的の関数が見つかったか調べる方法を取っていました。そして見つからなかったら失敗(die)するように作ってありました。

実際この方式はうまく動作していまして、このことからAUTOLOAD関数が存在するクラス内のcanはそのAUTOLOAD関数内では正常に判別できることがわかります。たぶんperl自身がcanの中でこの辺をこまめに判別しているようです。

AUTOLOADの暴走（無限ループ）

しかし更にややこしい問題が発生しました。SatsukiシステムのDBモジュール*4は、そのAPIが規定されていることが利点となり、どのような下位モジュールに対してもキャッシュを行うDB_cache.pmというものが存在します。この中では、select のみオーバーライドしキャッシュを行い、その他の関数はcanで調べてその関数が存在するときは下位のモジュールの関数を呼び出すという仕組みにしていました。この下位モジュールを呼び出す仕組みでAUTOLOADを使用していたのです。

分かりずらいので図式すると、今このサーバではPostgreSQLおよびこのキャッシュモジュールを使用しています。このときデータベースへのアクセスは、

（キャッシュなり）Diary.pm → DB_pg.pm
（キャッシュあり）Diary.pm → DB_cache.pm → DB_pg.pm

となっています。Diary.pm からは、キャッシュがあろうがなかろうが、DBモジュールAPIを満たすものに対するアクセスしか行っていないため何ら違いはありません。

ここで、プログラム中にたまたま Diary.pm から DB_pg.pm に存在しない関数xyz()を読んでしまったのが問題の始まりでした*5。

結果として「DB_cache.pm → DB_pg.pm → DB_cache.pm → …」という無限ループに陥ってしまいました。DB_cache はその仕組み上、DB_pg.pm を動的に継承してしまうため、DB_pg への関数呼び出しは、例えDB_pg自身からであってもすべて DB_cache を経由します。それでこういうことが起こったわけです。

しかし、どちらのモジュールでも、こういうことを避けるために「canメソッドによって関数が実在するか調べていた」ハズです。調べてみると、どちらのcanも、どんなメソッドに対しても成功していました。ありもしないでたらめな関数でもなんでもif ($obj->can("xxx"))が成立していたわけです。

これが最初に言った、AUTOLOAD関数が定義されているときcanメソッドは常に true を返すという罠です。オブジェクトを動的に継承したために（実際に継承するのではなく、あたかも継承したようにみせかけた*7ために）、自分のクラス外のcanが常に成功したわけです。

解決策

はじめからcanなんて必要なかったんじゃないかというくらい、実に簡単な解決策でした。DB_pg.pm、DB_cache.pmをそれぞれ次のようにしました。

sub AUTOLOAD {
	（略）
	if (defined &$AUTOLOAD) { $can=1; last; }

sub can {
	my ($self, $func) = @_;
	my $func = $self->{_super_class} . '::' . $func;
	return (defined &$func);
}

そしてたぶん、この方法の方が速く動作します。

注意

ここでは便宜上DB_pg.pm内に AUTOLOAD が存在するとして説明しましたが、実際には、Autoloader.pmからAUTOLOAD関数をインポートしています。

Content-Type技、色々

データをブラウザで開くのではなく、直接ファイルに保存させたい場合は、

Content-Type: application/xxx-data

という風にしておけば、大抵は未登録のコンテントタイプなので保存指示ウィンドウが出るようになります。

しかし、POST時にこの方法を用いてファイルを保存させようとすると、ファイル名選択ダイアログが出てきません（Firefoxにて確認）。各種blogツールにおいて、エクスポート時のメソッドがなぜGETなのか今まで疑問だったのですが、ようやく謎が解けました。

教訓：POSTメソッド発行時にファイルに保存させようとしてはいけない

おまけ

cgiのファイルなどを実行させずに、そのままのファイル名でブラウザで表示させたい場合は

AddType text/plain .cgi
RemoveHandler .cgi

というふうにします（Apache2用）。http://adiary.abk.nu/tools/tdiary2adiary.cgiで使ってる技です。

追記。mod_perlの影響か、RemoveHandler がうまく働かなくなってましたので、次のようにしました。

AddType text/plain .cgi
AddHandler default-handler .cgi

Content-Typeを変更せずにファイルとして保存させる

cgiの場合、もっとスマートにファイルとして保存させる方法を発見しました。

Content-Disposition: attachment; filename=export_file_name.txt
Content-Type: text/plain; charset=（文字コード）;

とすれば良いようです。

一昔前の掲示板などで利用出来るタグを制限できるものがありますが、それと同等のモジュール（自作）をadiaryでは使用しています。属性値を認めると途端にタグの解析が難しくなります。

#!/usr/local/bin/perl
use strict;

my $inp = join('', <>);
while($inp =~ /(<\w([^>"']|[=\s\n]".*?"|[=\s\n]'.*?')*?>)/s) {
	$inp = $';
	print "$1\n";
}

だいたいこれでタグを認識できますが、IE/Firefox/Operaなどで色々確認した結果、壊れた（不正な形式の）htmlタグの解釈は統一されておらず、結局、その辺の仕様まで完全にサポートすることは非常に難しく、そこをつつけば、この手のタグ制限ルーチンの解析を避けて、ブラウザに対し不正なタグを認識させる（XSSする）ことが可能なようです。

日記への画像添付に向けて、multipart/form-data の解析ルーチンでも作ろうかと思って調べ始めてみると……

1. とりあえずネットで仕様書を検索。RFC1876, RFC2388だということは分かるが……見ても分かりにくいぞ、これは。
2. 仕方ないので perl で書かれたサンプル（アップローダ）でも探してみると、CGI.pm を使用したものばかり見つかる。
3. しょうがないので、ENCTYPE="multipart/form-data" なフォームで POST してデータを全部ファイルにはき出してみる。実に分かりやすい。
4. 結局 boundary を認識しつつ読み出す必要があるので、perl 的にデリミタを書き換えてと思ったものの、例えば 100MB とか大きなファイルを受け取るとき、それだけメモリを食うこととなる。 → 常識的にはNG
5. なんかいい方法ないかなぁーと再びネット内のcgiスクリプトを検索。…………見るんじゃなかった（笑）

どうしてネットに転がってる cgi (with perl) スクリプトってのは、有名どころ含め、汚いのばかりかなぁ（苦笑）*1

multipart/form-dataの例

というわけで例をアップしておきます。参考にどうぞ。アップロードしたファイルは、C++のソースです。

続きを読む

mod_perl2 (on Apache 2.x)で無理矢理MT（Movable Type）を動かそうとしたり、古いスクリプトをmod_perl2で動かそうとする人たちがいまして。そういうページの中で、mod_perl2はカレントディレクトリをスクリプトのdirに変更しないというのが日本ではなぜか迷信のごとく広まっています。……いやある意味では正しいのですけど。例えばこちらのページでは

PerlFixupHandler "sub { \
	chdir('/project/sfo/www/www.sfo.jp/lib/mt'); \
	return OK; \
}"
PerlResponseHandler ModPerl::Registry

とやって明示的に chdir しています（別にやり玉に挙げているわけではなくて、どこのサイトを見てもおよそこんな感じです）。そもそもなぜ、ModPerl::Registry がスクリプトの場所にカレントディレクトリを変更しないかといえば、worker モデルの場合（Apacheがスレッド動作モデル）の場合、chdir しても途中でカレントディレクトリが変わる可能性がある＝あまり意味がないからです。だから chdir を明示的に発行するときは、Apache が prefork（従来のプロセスをforkして並列動作する方式）で動いてることを期待しています。

ここからが本題。mod_perl2のマニュアルによるとmod_perl2にはPrefork専用のハンドラーがあり、

PerlResponseHandler ModPerl::RegistryPrefork
PerlResponseHandler ModPerl::PerlRunPrefork

と（どちらか一つを）書けば chdir してくれるそうです。まあ英語のマニュアルだから自分もcgi開発でもなければ読まなかったのですが、日本での普及率をGoogle先生に聞いてみるとこんな結果になります（汗）

というわけで、以降普及することを期待して終わり（笑）