Web屋のネタ帳

去年の今頃書いた 画像もDBに格納して管理する －扱いがめんどうなLOB(ラージオブジェクト)は使わない方法も含め(2008/8)と、こないだのCoolなURLを作るには(2008/7)の記事は、URLの処理をちょこっと工夫してシアワセになろうよ、という点で共通している。ついでなのでまとめて続編みたいなことをしてみようかと。

まず、画像もDBに格納して管理するで紹介したmod_rewrite設定が実はおかしいという、約1年後のいま明かされる真実(笑)。

と言っても本格的に間違ってるわけじゃなく結果的な動作に問題は無い。ただちょっと余計なものがある。

RewriteCond %{REQUEST_FILENAME} ^dbimage_\d+\.(jpg|gif|png)$
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^.*dbimage_(\d+)\.(jpg|gif|png)$ /getimgfromdb_and_makefile.php?id=$1&type=$2 [R]

一番最後の[R]はいらない（と思う。めんどいので未検証）。 RはつまりRedirectのことで、指定したURIにHTTPリクエストしなおせ！とブラウザに伝えてくれるのだが、よく考えるとそんなことをせんでもここまででリライト処理はできている。あとはほっといてもサーバはブラウザに /getimgfromdb_and_makefile.php?id=$1&type=$2 の結果を返してくれるので目的は達成される。

しいて言えば[R]の代わりに[L]と書くべき。これはlastの意味で、そこでリライト処理を終了してくれる（その後にrewrite設定が続いていても無視）。

次に、現場の状況によっては逆のパターンのほうがいいかもしれないという話。

RewriteCond %{REQUEST_FILENAME}    /getimgfromdb_and_makefile.jsp
RewriteCond %{QUERY_STRING}    id=([0-9a-z]+)&type=(jpg|gif|png)
RewriteCond /home/htdocs/imagecache/dbimage_%1.%2    -f
RewriteRule .*    /imagecache/dbimage_%1.%2 [L]

# 注：画像のキャッシュファイルはDocumentRoot配下ではなく /var/tmp/ 配下とか
# とにかく別なところに置いてAliasを張ったほうが管理しやすいと思う。
# そんな事情もあるので、本ブログで書いているapacheの設定は
# 本来はvirtualHostやAlias設定なども使ってもうちょっと本格的な設定に
# すべきだが、安価な共用型レンタルサーバでも使えるように 
# .htaccessファイル上で設定できる（そうな）書き方をしている。
# 要するにこれらはあくまで最低限の設定例に過ぎないです。

つまり、
http://example.com/getimgfromdb_and_makefile.jsp?id=abcd1234&type=jpg
を
http://example.com/imagecache/dbimage_abcd1234.jpg
にリライトする方法。ただしDB上の画像が既にキャッシュファイル化されいてdbimage_abcd1234.jpgとしてファイルが存在するときに、という条件つき。

Web層とAP層が明確に分かれている場合にはこっちのほうがいいんじゃないだろうか。典型的なのはWebサーバがApacheでAPサーバがTomcatというケース。

Tomcat上でjavaアプリを動かす場合、開発者は自分のPC上にTomcatサーバだけをを立てて開発をしていることがある。apacheを経由してないのでmod_rewriteが効かないため、<img src="dbimage_12345.jpg" /> と書いてあっても画像が出ない。上の方法だと<img src="getimgfromdb_and_makefile.jsp?id=12345&type=jpg" /> という一つの書き方で、本番環境のApache+Tomcatならばmod_rewriteによるキャッシュ機構が働くし、開発過程でのTomcatオンリーな環境であっても画像は（キャッシュ機構は動かないけど）表示される。 また、画像キャッシュ機構のオン／オフを切り替える機能の実装もやりやすくなるだろう。

話は変わって今度はCoolなURLの作り方の件。

geekデータベースアプリが http://example.com/x/geek/　、bookデータベースアプリが http://examle.com/x/book だとして、そのサイトのトップページを同じMVCフレームワークで動的にやりたいとすると、トップページのurlは http://example.com/x/ とか http://example.com/x/index とかになっちゃうの！？かっこ悪くね？ という意見をいただいた。

そのとおりだ。Webサイトのトップページは http://example.com/ だけのほうがCoolだ。そこで、こうする。

DirectoryIndex  x 
# DirectoryIndex  x  index.html  index.php 
# のようにしてもよい。詳しくは マニュアル。

これで、

トップページ	http://example.com/
geekアプリ	http://example.com/x/geek/foo/bar....
bookアプリ	http://example.com/x/book/foo/bar....

ということになる。このときのxの中は例えばこんな感じ↓

<?php
if ($_SERVER["SCRIPT_URL"] === "/") {
    include("DocumentRootじゃないどこか/toppage.php");
} else {
    $args = explode("/",$_SERVER["REQUEST_URI"]);
    switch ($args[2]) {
        case "geek":
            include("DocumentRootじゃないどこか/geek.php");
            break;
        case "book":
            include("DocumentRootじゃないどこか/book.php");
            break;
        default:
	    header("Not Found", TRUE, 404);
            echo "ねーよ";
            exit(0);
    }
}
?>

しかし、「やっぱりxは邪魔だ！Coolじゃない！」と感じる人もいるだろう。 それはそれで一つのポリシーであるので、

<FilesMatch "^(geek|book)$" >
    ForceType application/x-httpd-php
</FilesMatch>

のようにすることで、 http://example.com/geek/foo/bar , http://example.com/book/foo/bar のように余計な「x」を排除する方法を取ってもよいと思う。 ただしgeekとbookのほかにblogとsnsとbbsとrssreaderと、、、、を追加するたびに

<FilesMatch "^(geek|book|blog|sns|bbs|rssreader)$" >
    ForceType application/x-httpd-php
</FilesMatch>

というふうになってゆく。CoolなURLを追求しすぎて設定ファイルがCoolじゃなくなっている。 が、この程度は人それぞれの感じ方の問題だろう。結局はapacheの設定ファイルに書くか「x」の中に書くかの違いでしかないのだから。

ところで、mod_rewriteによる画像キャッシュ機構と、CoolなURL作りと、コントローラースクリプト「x」によるMVCフレームワーク（っぽいもの）の話とを、全部まとめてやってやろうとすると、こうなる。

DirectoryIndex  x index.html index.php
<FilesMatch "^x$" >
    ForceType application/x-httpd-php
</FilesMatch>
RewriteCond %{REQUEST_URI}    /x/getimgfromdb_and_makefile
RewriteCond %{QUERY_STRING}    id=([0-9a-z]+)&type=(jpg|gif|png)
RewriteCond /home/htdocs/imagecache/dbimage_%1.%2    -f
RewriteRule .*    /imagecache/dbimage_%1.%2 [L]

たった8行だが、これでもはじめての人にとってはチンプンカンプンだろう。 プログラミング言語の使い方を覚えるだけでも大変なのにね。

筆者は、ソフトウェアの設定ファイルを書くのもプログラミング言語でソースコードを書くのも同じ「開発」と捉えている。だったら少しでも単一の言語体系に寄せて、かつ、メインじゃない言語体系のもの＝設定ファイル＝を書き増す可能性を少しでも小さくするほうがcoolだと思う。だから「x」で妥協するプランのほうを示した。いろんな言語や出来合いのソフトウェアを使って遊ぼう|学ぼうというのなら話はまたちょっと違うけど。

また、mod_rewriteは麻薬だ。などと言うわりに実は1年も前にmod_rewriteを使った話を書いていて、それがこのブログでのソーシャルブックマーク数の一番多い記事（こことかこことか参照）だったりする。うん。ハサミと麻薬は使いよう。（笑）

see also:

• CoolなURLを作るときのHotな落とし穴 (2008/8)