nDiki : PATH_INFO

Windows 上での Apache 2.0.53 では PATH_INFO が シフト JIS に

WiKicker の Windows 上での動作確認の続き。 WiKicker のPPM パッケージを作成して ActivePerl 5.8.6.811 上にインストール。 依存するモジュールで、ActivePerl に入っていないものは以下の通り。

• Algorithm::Diff
• Jcode
• Log::Log4perl
• Time::Zone (TimeDate)

既に手元で PPM パッケージ化済みなので、これもインストールしておく。

後は RCS をパスの通っているディレクトリに入れてタイムゾーンを設定。

 TZ=JST-9

で CGI プログラムとして実行。 お、表示できた。 書き込みはと。

エラー。

予想していたけれど、sendmail に依存していたところ。 sendmail が見つからない場合はメールの送信をスキップするように修正。

これでうまく動くかなと思ったら、日本語名のページを作るとうまく表示できない問題を発見。

PATH_INFO がシフト JIS で渡される

WiKicker では UTF-8 文字列をURIエスケープして WikiPage のURLを生成している。 このURIにアクセスされると WiKicker は、PATH_INFO から WikiName を取り出す。 この文字列がシフト JIS になってしまっている。

Windows がファイル名に使用する charset にあわせて、Apache が変換してしまっているようだ。 調べてみると他の WikiEngine でも同様の問題にあっているという記事が見つかった。

将来の 2.0 系でパッチが取り込まれて修正されるとか、そうでないとか。

現状どうするかなぁ。 WiKicker 側でシフト JIS から UTF-8 に戻すというのもできない事はないけれど、あまりやりたくはないな。 いったんシフト JIS を介しているという時点で、シフト JIS に無い文字の扱いに関する問題をかかえてしまっているし(Apache が)。

対策案:

• Apache 1.x 系を使う (まだ未確認だが、こちらだと勝手に変換されないらしい)
• WiKicker に PATH_INFO を使わないオプションをつける(URI Query Component は勝手に変換されない)
• WiKicker 側でシフト JIS から UTF-8 に変換する

AN HTTPD 1.42n も PATH_INFO が シフト JIS に

Windows 用 Apache 2.0 では PATH_INFO がシフト JIS になるという仕様により WiKicker がうまく動かないのだが、AN HTTPD どうかと思い確認してみた。

結果は×。

AN HTTPD も PATH_INFO はシフト JIS になってしまう。

PATH_INFO のかわりに REQUEST_URI と SCRIPT_NAME を使う

結局 Apache 1.3.33 でもやはり PATH_INFO が UTF-8 では無くなってしまうようだ。

ということで WiKicker 側で対処。 SERVER_SOFTWARE 環境変数を見て Win32 な Apache だった場合、PATH_INFO を使わず REQUEST_URI と SCRIPT_NAME 環境変数を使って PATH_INFO にあたる文字列を取り出すようにした。

これで期待するページにアクセスできるようになった。

ただし別件で、ページ書き込み時に失敗する問題が発覚。 ページの補助情報を保存している部分の処理がこけるらしく、一度エラーになると以降のアクセスがエラーになってしまう。 要調査。

Perl CGI プログラムのテストには WWW::Mechanize::CGI を

CGI プログラムを書いていて、いつも困るのがリグレッションテスト。

パッケージのビルド時に実行するテストスーツ (make check / make test 用テストプログラム群) に含めておきたいが、さすがにその場で Web サーバの下へセットアップするわけにもいかない。 ミニ Web サーバを同梱してテストスーツ内で起動する方法はちょっとおおがかかりだし、ポート番号の選択やらサーバの停止の問題もあって、かなり面倒。

結局、テストスーツの中で環境変数や標準入力など CGI リクエスト環境をセットアップして、CGI プログラムを実行するという王道(?)かつ泥臭いテストを書くことになったりする。

何かいいものはないかと探していたところ、WWW::Mechanize::CGI というものをみつけた。

LWP::UserAgent を継承した WWW::Mechanize モジュールは Web ブラウジングを容易にする有名どころのモジュールである。

WWW::Mechanize::CGI モジュールはさらにこれを拡張したモジュールで、HTTP リクエストを、仮想的に CGI プログラムやサブルーチンへの呼出しにしてくれる。 これを用いるとあたかも Web サーバ上の CGI プログラムにリクエストしレスポンスを受けとっているかのように、テストプログラムを書くことができる。

素晴しい。

さっそく WiKicker のテストを書き換えてみた:

 use Test::More tests => 2;
 use WiKicker::WikICGI::Controller;
 use WWW::Mechanize::CGI;
 use File::Temp qw(tempdir);
 use File::Spec;
 my $www_dir = tempdir(CLEANUP => 1);
 my $mech = WWW::Mechanize::CGI->new;
 $mech->cgi(sub {
              $ENV{PATH_INFO} = '' if $ENV{PATH_INFO} eq '/';
              WiKicker::WikiCGI::Controller->new->run});
 $mech->env($mech->env,
            SCRIPT_FILENAME => File::Spec
                                 ->catfile($www_dir . '/wiki'),
            SCRIPT_NAME => '/wiki');
 my $response = $mech->get('http://localhost/wiki');
 ok($response->is_success);
 like($response->content,
      qr|<title>WikiForum\[WiKicker\]: FrontPage</title>|);

WWW::Mechanize::CGI オブジェクトを new した後、cgi メソッドで CGI サブルーチンを指定するか、cgi_application メソッドで外部 CGI プログラムを指定する。 ここでは直接、CGI サブルーチン (WiKicker::WikiCGI::Controller->new->run を実行)を指定した。

なおここで WWW::Mechanize::CGI が使っている HTTP::Request::AsCGI 0.5 における PATH_INFO の扱いが Apache などとは違って、空でも必ず '/' が入るようになっている。 これだと WiKicker では困るので、サブルーチンのところで修正している。

後は必要ならば WWW::Mechanize::CGI::env で、追加の環境変数設定を行っておく。

セットアップが済めば通常の WWW::Mechanize と同様に get 等でリクエストを行いレスポンスを受けとることができるようになる。

いい。しばらく試してみて不具合がなさそうなら、定番のテストスタイルにしたい。

ちなみに Test::Harness 用の Test::WWW::Mechanize にあわせて、Test::WWW::Mechanize::CGI というものもある。 これらを用いるとさらにテストを書くのが楽になるが、依存するモジュールも多いので無理に使わないほうがいいかもしれない。

Perl 5.8.8 の CGI.pm の PATH_INFO 処理の問題にぶつかる

手元の WiKicker (や DiKicker) で、「C++」という文字列を含む URI にアクセスしたらエラー。

 Nested quantifiers in regex; marked by <-- HERE in m//C++ <-- HERE .html$/ at (eval 27) line 7.

正規表現の一部として使う時には \Q...\E していたと思ったが抜けがあったか。 とコードをチェックしてみたが、それっぽいところなし。 そもそも、Perl 5.005_03 だと問題おきていないし。

確認したら CGI.pm の url() の中でのエラーだった。 quotemeta されていない。

Perl 5.8.8 に含まれている CGI.pm 3.15 で問題を確認。3.17 までは駄目で、3.19 以降だと \Q...\E するように修正されている (3.18 は CPAN にないので不明)。

標準 Perl ライブラリのバグを踏んだか……。 標準 Perl ライブラリのアップグレードはなにかと面倒なので、システム要件にはしたくはないんだよねぇ。