301 permanently movedへの対応
先日の記事でも書いたとおり、 Movable Typeのアップグレードに伴い、 RSSの出力先が index.rdf から index.xmlに変わった。それで、このサイトでは index.rdfへのアクセスを index.xmlにリダイレクトするようにした。ところが、 RSSリーダー (や類似のもの) の中には、 301 permanently moved にちゃんと対応していないものも少なくないことが分かった。
アクセスログを見ていると、 RSSリーダー (およびその類似品) は、以下のように分類できるようだ。
- 301 permanently movedを受け手、 index.xmlにアクセスし、それ以後、 index.rdfにはアクセスしないタイプ
- 301を受け手、 index.xmlにアクセスするものの、それ以後のアクセスも、まずは index.rdfに対して行うもの。
- index.rdfにアクセスして、 301は無視するもの。
もちろん仕様的には 1.があるべき姿だろう。 2.も許容できる範囲かもしれない。しかし、 3.は論外である。しかし、実際には 3.のタイプのシステムもいくつかあるようで、これらのシステムの利用者は、このサイトが消滅した、あるいはブログの更新が止まったと思いこむことだろう。
ちなみに、 1.の例としてはいくつかの検索エンジンや bloglinesなどの RSSチェッカーが、 2.の例としては僕が愛用している Headline Readerが、 3.の例としては、某所で動いているアンテナ的なサイト (たぶん個人作成) が挙げられる。また、 Google Desktopに関しては、バージョンによって動作が異なるようである。
そういう現状を考慮すると、 301でリダイレクトするよりも、 symbolic linkを張るようにした方がいいのか、と思わなくもない。しかし、僕は Web上のものに関しては、なるべく symbolic linkは使わないことにしている。これは、たとえばサイトを再構築する際には、いちいち手動でリンクを作り直さなければならなくなる可能性があり、それを忘れてしまう可能性がそれなりに高いと思う、とかそういう理由である。全てを .htaccessに書いておけば、仮に CVSや Subversionでファイル管理をしているサイトなどでも、全ての情報をリポジトリに入れることができる。
いずれにしても、 HTTPの仕様に従った実装をして欲しいものだと感じる。もうしばらくしたら、 index.rdf は 404になるようにすると思うので、そうすると上記 3.のクライアントの利用者からは、このサイトは完全に消滅したと思われることだろう。まあ、今まで更新頻度が低かったので、別に不思議に思われないだろうけど。