この文書の諸情報
- この文書の永続的URI
- http://kuruman.org/diary/2007/01/29/content-location-sbm
- 公開日時
- 2007年1月29日 午後1時25分19秒
- 最終更新日時
- 2007年4月2日 午後7時37分03秒
- ヘルプ
- フィードバックについて
-
更新情報 - http://kuruman.org/note/index.xml
.
Content-Locationヘッダの参照先をブックマークする件Livedoor clipはContent-Locationヘッダの参照先をブックマークする仕様のようだ。はじめに言っておくが、仕様上問題はない。しかしこれには一長一短あり、個人的には好ましくないように思う。理由として2点挙げる。Liverdoor clipには是非仕様変更を検討していただきたい。
例えばこんな例を考えてみる。全く同じ内容である最新版(latest)と毎月の文書(YYYYMM)を提供しているサイトがあるとしよう。latestにリクエストを投げると、そのレスポンスにはYYYYMMを指し示すContent-Locationヘッダを含めることができる。このサイトではそれを提供していたとしよう。Content-Locationヘッダの参照先がブックマークされる場合、間違って最新版をブックマークしてしまった人が救われる。しかしながら、個別の記事を参照したい人のみがソーシャルブックマークサービスを利用しているわけではない。少なくとも常に最新版を指し示すページはブックマークできない。Content-Locationの指し示すページをブックマークする仕様の場合、ブックマーク可能なページ数は減る。
また、Content-Locationはコンテンツネゴシエーションを行っているウェブサイトでも使われる。このサイトがまさにそうなのだが、Livedoor clipでは必ずHTML版を拾っていき、拡張子htmlを持ったクリップが増産されている。勘弁して欲しい。本来XHTML版を返したいUAもHTML版を要求してくるようになってしまう。確かにもしその特定のエンティティの源を明らかにしたければ、将来のリクエストでは Request-URI として Content-Location の URI を指定する事ができる
とされており問題はないが、エンティティの源を明らかにする必要があるかといえば甚だ疑問だ。従ってソーシャルブックマークサービスはContent-Location 値は、本来の Request-URI の代わりとはならない
ことに基づいた実装を行う方が好ましいのではないだろうか。
まぁLivedoor clipがapplication/xml+xhtmlを要求してきていたらさらに残念な結果になっていたわけで、喜ぶべきと言えばそうなのかもしれない。
……こういう事はこんな辺境に書かずメールを出せ、と言われそうだ。しばらくたっても覚えていたらメールも出そうと思う。正直、ソーシャルブックマークサービスに集まるURLが分散して気持ち悪いもので。別に元々少ないブックマーク数が分散するのはどうでも良い。何のためにコンテンツネゴシエーションしているのかと考えさせられるのがいやなのだ。折角複数バージョン用意しているにもかかわらずそれが生かされないというのは実に切ない。
malaさんからlivedoor Readerからブックマークした場合、RSS内のリンクがリダイレクタの場合があるのでリダイレクト先を見るようになってる。Content-locationはリダイレクタではないので別扱いにしても良いかもだけどレアケース
との回答。なるほど確かにlivedoor Readerと連携させたときにのみ発生している。レアケースと言われてしまっただけに仕様変更は期待薄かもしれませんが、淡い期待をもちつつ強引な手(謎)は使わない方向でゆこうかと思います。素早い回答ありがとうございました。
蛇足1。最速の中の人は本当に最速だった。
蛇足2。Livedoorでなくlivedoorであることを今知った。頭も小文字だったのか。
2007年03月29日にkyannyさんがこのエントリーをしゅうせいしますた
とのコメント付きでブックマークされました。動作の確認はしておりませんが、この問題は修正されたものと思われます。ご対応ありがとうございました。
更新情報.