Lighttpd

先日、CentOS 5.5 が出たため、yum upgrade をしたところ openssl のバージョンアップによって、lighttpd の起動時に network.c でエラーが出るようになってしまいました。 SSL: error:00000000:lib(0):func(0):reason(0). RPMForgeの最新の lighttpd 1.4.22 ではダメで、lighttpd 1.4.26-2 に上げるため別途 rpm を落としてきました。 Redhat 5 系の RPM パッケージでよさそうなのが下記にありました。 ftp://ftp.univie.ac.at/systems/linux/fedora/epel/5/i386/ 上記サイトから下記のパッケージを順にインストールします。 lua-5.1.2-1.el5.i386.rpm spawn-fcgi-1.6.2-1.el5.1.i386.rpm lighttpd-1.4.26-2.el5.i386.rpm lighttpd-fastcgi-1.4.26-2.el5.i386.rpm /etc/lighttpd/ を予め tar などしてバックアップしておきます。 yum remove で RPMForge から落として入れていた lighttpd, lighttpd-fastcgi を削除します。 上記のパッケージを rpm -ivh 〜 コマンドでインストール。 /etc/lighttpd/lighttpd.conf を lighttpd.conf.rpmsave から復帰させて無事起動するようになりました。

#!/usr/bin/ruby print “Content-Type:application/xhtml+xml\r\n” print “Content-Type:text/plain\r\n\r\n” print «EOF Test for How to deal Content-Type EOF たとえば上記のようにわざと Content-Type を二重に出力してしまうと、Apache はバリデートで後者のみがクライアントに返されるが、lighttpd はそのまま二重定義で返してしまう。 これを確認するために、Firefox の Live HTTP headers を使ってレスポンスヘッダを見ても、下記のように Content-Type はどちらも１つしかない。lighttpd の前記の動作を確認することはできない。 Firefox Live HTTP headers Apache HTTP/1.x 200 OK Date: Fri, 12 Dec 2008 15:23:14 GMT Server: Apache/2.2.3 (CentOS) Content-Length: 34 Connection: close Content-Type: text/plain; charset=UTF-8 lighttpd HTTP/1.x 200 OK Transfer-Encoding: chunked Content-Type: text/plain Date: Fri, 12 Dec 2008 15:23:55 GMT Server: lighttpd/1.4.20 wget -S 今度は wget -S オプションで server response を見るようにしてみると、lighttpd の方は Content-Type がそのまま二重に出力されていることが確認できた。 ...

index-file.names = ( “index.fcgi” ) fastcgi.server = ( “/index.fcgi” => ( “portal” => ( “socket” => “/var/lib/lighttpd/fastcgi/index.fcgi.socket”, “bin-path” => “/www/portal.cgi”, “check-local” => “disable”, “min-procs” => 1, “max-procs” => 1, “max-load-per-proc” => 50 ) ) ) 上記のように / を index.fcgi で受けようと設定したが、Not Found 404 になってしまった。ここでダミーのファイル index.fcgi を置くと動くようになる。 つまり、index-file が存在するかの確認は fastcgi.server のマッチングを判定しておらず、実際のファイルを見にいってしまう。bin-path とマッチが同じになっていれば気づかない。 Apache から lighttpd に乗り換え中だが結構いろいろ引っかかってくる。

require “cgi” require “cgi/session” require ‘cgi/session/pstore’ cgi = CGI.new user_id = cgi[’loginid’] session = CGI::Session.new(cgi, { ‘database_manager’ => CGI::Session::PStore, }) session[‘userid’] = user_id session.close headers.store(“status”, “REDIRECT”) headers.store(“Location”, $rooturi + “portal.cgi”) puts cgi.header(headers) exit 0 上記のような CGI を lighttpd で実行するとセッションのファイルは生成されるが、値が書き込まれずに終わる。コマンドラインで実行したり、Apache で実行しても問題はない。FastCGI対応してみたがそれでも変わらなかった。ちなみに database_manager が FileStore では問題は発生しない。 こんなコードを書いたのは、ログイン認証後にセッションへIDを保存してリダイレクトという流れの実現をしたかったのだが。。。いまいち原因が掴めない。

Apache の方が融通が効いていたということも言えるのだが、/xxxx/yyyy を rewrite で /xxxx?mode=yyy のように書きかえて、CGI を叩くことは多いと思う。これが GET であればもちろん問題ないのだが、POST でこれを行うと引数 (mode=yyy) が渡ってこない。