scgiとfcgiって、fcgiの方が多機能だけど、リクエスト時の動きは一緒と思ってたのだが、結構違った。作成されるサンプルアプリケーションで、PATH_INFOを調べてみた結果です。マウントhttp://localhost/PATH_INFO'/'SCIPT_NAME''http://localhost/aPATH_INFO'/a'SCIPT_NAME''と、PATH_INFOとSCRIPT_NAMEの分け方が逆。fcgiは全部SCRIPT_NAME側に振られるけど、scgiはPATH_INFOに振ってくる。マウントした場合と同じ振るまいをする。マウントした場合は、pasteの設定でも/aをscriptNameにしないとだめ。マウントした場合の挙動が非常に気になる。すべて、SCRIPT_NAMEになってしまうのはいかがなものか。scgiの挙動の方が正しく思える。SCRIPT_NAMEは実体までのパスで、PATH_INFOはそれ以降の仮想的なパスという意味合いを持つ。すれば、同じWSGIアプリケーションに対するリクエストで、SCRIPT_NAMEが変わってしまうのは納得がいかない。いうか、WSGIで使われているディスパッチャはたいていPATH_INFOをみているわけで、うまく動かない。Djangoでも、lightyの/にfcgiでマウントするとうまく動かなくなるという話を聞いているが、おそらくこれ原因じゃないだろうか。/にマウントした場合、REQUEST_URIを使ってしのいでいるらしいが、おそらくSCRIPT_NAMEを使っても同様の動作となるだろう。動かすには、scgiでマウントさせるのが良さそうだ。実際、Pylonsでも試してみたが、fcgiで/にマウントすると、うまく動かず、scgiに変更したら正常に動作した。