nDiki : LWP::UserAgent

HTTP WWW::Mechanize WWW::Mechanize::Cached Perl キャッシュ Perl モジュール Web URI::Fetch Test::WWW::Mechanize CGI HTTP::Daemon Cache::Cache Test::Harness libwww-perl Perl でキャッシュ処理 WiKicker 開発 WWW::Mechanize::CGI mixi スーツ SpeedyCGI ExtUtils::FakeConfig JSON File::Spec PATH_INFO URI RSS Test::Unit Term::ProgressBar PAR

■ 自作 HTTP Proxy、パイプライン化

一昨日で書いた HTTP Proxy、使用しているライブラリ(LWP::UserAgent, HTTP::Daemon) それぞれパイプライン的な処理(レスポンス全体を受信/作成することなく、処理/送信)サポートを利用してパイプライン化。

どちらのライブラリもコールバックを指定する形でそのままでは、つなげないので、HTTP::Daemon でクライアントへのレスポンスの送信を一部づつ送る方は簡単に自作した。

これで、サイズの大きいページも Proxy がすぐに転送を開始できるため、ブラウザ側で待たされる事が少なくなった。 めでたし、めでたし。

• HTTP/1.0 Simple-Response (2004-06-01)
• 他の Web サイトの情報を URI::Fetch でキャッシュ付き取得 (2005-10-29)
• Perl CGI プログラムのテストには WWW::Mechanize::... (2006-02-18)
• HTTP::Daemonベースのプログラムのテスト (2004-11-26)
• XMLRPC::Lite + 自前の HTTP::Daemon サーバ (2004-09-14)

■ HTTP/1.0 Simple-Response

「ある無線基地局のWeb管理画面の制御をスクリプトでしようとリクエストを送ったら、Status-Line 無しでボディが返ってきたよ」という話。 でRubyのライブラリや wget だとエラーになるとのこと。

@ HTTP/0.9 Simple-Response

RFC1945 6. Response で、Status-Line をともなわない「Simple-Response」というのが定義されている(HTTP/1.1 RFC2616 にはない)。

HTTP/0.9 Simple-Request (RFC1945 5. Request) を受けた時のみ Simple-Response を送信すべきとあるが must ではないようだ。 HTTP/1.0 Full-Request を送信して Status-Line で始まらないレスポンスを受けたら、Simple-Response とみなすべきとある。

 GET Request-URI HTTP/1.1 CRLF

を受信した HTTP/1.0 サーバが Simple-Request を返しても違反とはいえないのかな。 まぁ行儀が悪いことには違いないが。

@ Perl libwww-perl の場合

Perl のライブラリをみてみた。

libwww-perl の Net::HTTP::Methods::read_response_headers では laxed => 1 が指定されると、Status-Line が無い場合 HTTP/0.9 な 200 と判断するようになっている。

LWP::UserAgent を使うと laxed => 1 が設定された状態で呼ばれるので、Simple-Response もうまく処理できるはず。

@ Server: GR-HTTPD Server/2.20

Server レスポンスヘッダフィールドにある GR-HTTPD っていうのは国産の組み込みWebサーバのようだ。

• Perl CGI プログラムのテストには WWW::Mechanize::... (2006-02-18)
• POE で HTTP プロキシサーバ (2005-10-15)
• 他の Web サイトの情報を URI::Fetch でキャッシュ付き取得 (2005-10-29)
• リャマ本を Perl トレーニングコース用ブックに選定 (2006-04-18)
• Plagger で Twitter のあれこれをメールで通知 (2008-12-25)

■ 他の Web サイトの情報を URI::Fetch でキャッシュ付き取得

WiKicker や DiKicker でうまく他のサイトの情報を取り込んで利用できるようにしたい。 相手サイト・自サイトともに負荷をかけないように処理するには、うまくキャッシングする必要がある。

キャッシュ機能のあるPerl用HTTPユーザエージェントには

• WWW::Mechanize::Cached
• LWP::UserAgent::WithCache
• URI::Fetch

などがある。

@ WWW::Mechanize::Cached 1.32

WWW::Mechanize::Cached は1度取得したレスポンスを無条件に1日間キャッシュする。 WWW::Mechanize のサブクラスで、便利な機能が利用できるが、キャッシュは適当。

キャッシュは Cache::FileCache決め打ち。

@ LWP::UserAgent::WithCache 0.03

LWP::UserAgentのサブクラス。 Expires、Last-Modified、Etag ヘッダを考慮して処理する。

キャッシュは Cache::FileCache決め打ち。

@ URI::Fetch 0.04

fetch サブルーチンのみを提供するシンプルなモジュール。

キャッシュは Cache 系APIのモジュールを指定する。実際には Cache::Cache 系でもOK。 Last-Modified、Etag を考慮して処理する。

前回のアクセスから一定時間はキャッシュを返すようにする機能があり、RSS や Atom フィードを取得して利用するのに便利。

@ 今回は

URI::Fetch をチョイス。 our を使っているのでそのままでは Perl 5.005_03 では動かないが、use vars に書き換えれば問題なく動く。

• Perl CGI プログラムのテストには WWW::Mechanize::... (2006-02-18)
• Cache::Memcached 1.13 の Perl 5.005_03 対応 (2004-06-05)
• [ Perl ] Memcached を使ってみる (2004-01-12)
• Twitter ステータスを nDiki サイドバーに表示 (2007-11-09)
• 私的10大ニュース2004 [ web ] (2004-12-31)

■ 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 というものもある。 これらを用いるとさらにテストを書くのが楽になるが、依存するモジュールも多いので無理に使わないほうがいいかもしれない。

• 一般ユーザで Apache 2.0 を起動する最小限の httpd.conf (2006-07-15)
• Test::WWW::Mechanize で Web アプリケーションをテ... (2006-09-13)
• [ WiKicker ] SpeedyCGI (2003-10-17)
• XAMPP で WiKicker を動かしてみた。PPM インストール OK。 (2007-02-09)
• 他の Web サイトの情報を URI::Fetch でキャッシュ付き取得 (2005-10-29)