ある URL から自動的に別の URL に飛ばすときに使える方法はいくつかあります。よく「X 秒後に自動的に転送されます」などと書いてあるのは、<META HTTP-EQUIV="Refresh" ...> とかで飛ばすタイプですが、それ以外に HTTP Header レベルで飛ばすものもあります。それは HTTP のステータスコードに 30x のどれかを返すことで実現する (CGI レベルでは、HTTP Header に Status: 303 See Other などの行を入れる) のですが、どの番号を選ぶかがまた面倒で。
303 See Other が普通に転送したいときには一番便利なのですが、これは HTTP/1.1 から定義されたコードなので、ブラウザ界の最後の害悪 Netscape4.x では理解してくれないんですよね……。そんなわけで、$ENV{SERVER_PROTOCOL} を見て HTTP/1.0 なら 303 See Other を使うことはあきらめて、302 Found (HTTP/1.0 では Moved Temporarily) を使うとかするしかありません。
ちなみに、POST されてきた内容をそのまま転送先 URL に送り直してもらいたいときには、307 Temporary redirect を送らないといけません。しかし、これは HTTP/1.1 の仕様なので NN4.x では理解できません。本来、同様に POST を転送するはずの 301, 302 は実際のブラウザの実装では GET に変わってしまうため、NN4.x で POST された内容を転送するのはおそらく無理でしょう。
参考 URL:
いいページを教えてくれた T 氏、ありがとう。
一昔前までは Linux のファイルシステムといえば ext2 だった訳ですが、ここ最近、いろいろな新しいファイルシステムが安定して動き始めています。ただ、XFS だの ReiserFS だの ext3 だのと、選択肢だけは耳にはいるのですが、どう違うかがどうもよく分かっていませんでした。そんな中、セキュリティホール memo で紹介されていた IBM developerWorks のアドバンスト・ファイルシステム・インプリメンター・ガイド 第11回の解説がとてもわかりやすかったのでお勧めです。
簡単にまとめると、Reiser さんが作った ReiserFS は、個別のデータベース層を挟まずとも、ファイルシステムだけでストレージとして十分なパフォーマンスを出すことを目的として１から設計されたシステムです。従来の ext2 だと小さいデータを１ファイルとして保存すると効率が悪く、結果として小さいデータをまとめて保存する何らかのデータ管理層が挟まっていたんですよね。ReiserFS ではそこが改善されており、小さなファイルに関しては ext2 の 10 倍前後もの速度が出、ディスクの使用効率も落ちないとのことです。大きなファイルに関しても ext2 よりは性能はいいようですが、特定のアクセスパターンだとずいぶん性能が落ちてしまうのが玉に瑕だとか。どういうパターンなのかはよく分かりませんですが……。
SGI が開発している XFS は、全体的に堅牢で性能がよく、最近好まれている……と書いてありましたが、どこがよいのかよく分からず（汗）。IRIX から Linux への移植なのですが、IRIX での動作実績が評価されているのかもしれません。企業がメンテナンスしているという安定感もありますし……。ちょっと前のバージョンだと、書き込みキャッシュの掃き出しのタイミングが遅く、不意の電源断でデータが壊れやすかったそうなのですが、最近は良くなっているそうです。
ext3 は他の新世代ファイルシステムと違い、ext2 との完全な互換性を狙った、安定したファイルシステムです。ext2 にジャーナル用の追加ファイルを加えたような構成で、いつでも ext2 <-> ext3 を切り替えられることが強みのようです。i node の構造は変わっていないので劇的なパフォーマンスの変化は無いですが、安心して使えるというのはファイルシステムとしては大きいかもしれません。
で、この記事を読んで自分の不明を恥じたわけですが、ファイルシステムがジャーナリングを行うと言っても、必ずしもデータの完全性を保証するというわけではないんですね。どうやら、ReiserFS と XFS のジャーナリングというのはメタデータ（どのブロックになんというファイルが収められているかという情報）について完全性を保証するだけで、データ本体の書き込みタイミングによっては、平気でファイルの中身が壊れるようです。ReiserFS だから電源をぶちぶち切っても大丈夫、というのは大きな誤解だったようで……（汗）異常終了後の fsck が早いというのと、データが壊れていないというのは別物でした。今のところ、データもジャーナリングするのは ext3 の一部のモードのみのようです。
う〜ん。ReiserFS の小さいファイルへの高パフォーマンスは捨てがたいんですが、速度と安全性のトレードオフを考えると ext3 の "data=ordered" モードが一番なんでしょうか。ようするに、自分の目的にあったシステムを選ぼう、ということなんでしょうけどね（＾＾；
しかし、IBM の developerWorks を見るたびに、 IBM って偉いなぁ、と思ってしまいます。自社製品ではないオープンソースのソフトウェアに関するドキュメントもどんどん載せて、しかも和訳をコンスタントにしてくれるというのは、本当にありがたいことです。安定した翻訳作業などは、まさに「企業だからできること」なんですよね……。