nDiki : LWP::UserAgent

HTTP Perl WWW::Mechanize::Cached WWW::Mechanize キャッシュ URI::Fetch Perl モジュール Web HTTP::Daemon libwww-perl WiKicker Perl でキャッシュ処理 Test::Harness 開発 CGI Cache::Cache Test::WWW::Mechanize WWW::Mechanize::CGI Term::ProgressBar Locale::Maketext Module::CoreList GR-HTTPD Net::HTTP Devel::Cover CGI プログラム CGI.pm PPM::Make Perl 5.005_03 Tie::File IPC::ShareLite

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

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

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

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

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

■ 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)
• 他の Web サイトの情報を URI::Fetch でキャッシュ付き取得 (2005-10-29)
• POE で HTTP プロキシサーバ (2005-10-15)
• Tor で hidden service (2005-02-13)
• Firefox 拡張機能の整理 (2005-02-05)

■ 他の 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 に書き換えれば問題なく動く。

• Cache::Memcached 1.13 の Perl 5.005_03 対応 (2004-06-05)
• Perl CGI プログラムのテストには WWW::Mechanize::... (2006-02-18)
• [ Perl ] Memcached を使ってみる (2004-01-12)
• Twitter ステータスを nDiki サイドバーに表示 (2007-11-09)
• さらにサーバ負荷状態悪化。対応に追われる。 (2006-03-04)

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

• Test::WWW::Mechanize で Web アプリケーションをテ... (2006-09-13)
• 一般ユーザで Apache 2.0 を起動する最小限の httpd.conf (2006-07-15)
• 他の Web サイトの情報を URI::Fetch でキャッシュ付き取得 (2005-10-29)
• CGI プログラム、Out of memory! に泣く (2001-01-04)
• [ WiKicker ] 「最近のアクセスログ」処理思案 (2004-01-17)