メッセージ。 - 商品がなくても200を返そう。そのかわりに……
# 商品がなくても200を返そう。そのかわりに……
ステータス200なのに「その商品はありません」
「商品がないときは404を返そう」という指摘。それは違うんじゃないの?とコメントを書きこんだつもりが(すぐには?)反映されなくて、手元にテキストも残ってなくて不安なのでここにメモ。
「商品がない」のと「ページがない」のは違う。たとえばWikiで、存在しないページにアクセスすると、200と編集画面が返ってくる。ここで404と編集画面を返すとおかしくなる。404と「Not Found」もだめ(まぁ議論の余地がありそうだけど)。HTTPのレイヤーでページがないのと、Wikiのレイヤーでページがないのは違うからだ。
これと同様に、Webアプリケーションのレイヤーで「商品がない」のとHTTPレイヤーで「ページがない」のは違う。たしかにこれは、システムの仕組みが分からない人には混乱のもとだ。だけど、エンジニアリング的には正しいはず。また、検索エンジンにしてみても、「商品がない」のと「ページがない」のは違うものと認識した設計をするのが本筋のはずだ。
Web設計者が本来やるべきことは、存在しない商品にできるだけリンクが貼られないようにするURL設計や、もし在庫切れ商品にアクセスされた場合には「その商品は売り切れです。次の入荷は……」、「在庫切れ、または絶版商品です。同様の商品をお探しの場合は……」といった表示を返すことじゃなかろうか。
「商品がないときは404を返そう」という指摘。それは違うんじゃないの?とコメントを書きこんだつもりが(すぐには?)反映されなくて、手元にテキストも残ってなくて不安なのでここにメモ。
「商品がない」のと「ページがない」のは違う。たとえばWikiで、存在しないページにアクセスすると、200と編集画面が返ってくる。ここで404と編集画面を返すとおかしくなる。404と「Not Found」もだめ(まぁ議論の余地がありそうだけど)。HTTPのレイヤーでページがないのと、Wikiのレイヤーでページがないのは違うからだ。
これと同様に、Webアプリケーションのレイヤーで「商品がない」のとHTTPレイヤーで「ページがない」のは違う。たしかにこれは、システムの仕組みが分からない人には混乱のもとだ。だけど、エンジニアリング的には正しいはず。また、検索エンジンにしてみても、「商品がない」のと「ページがない」のは違うものと認識した設計をするのが本筋のはずだ。
Web設計者が本来やるべきことは、存在しない商品にできるだけリンクが貼られないようにするURL設計や、もし在庫切れ商品にアクセスされた場合には「その商品は売り切れです。次の入荷は……」、「在庫切れ、または絶版商品です。同様の商品をお探しの場合は……」といった表示を返すことじゃなかろうか。
Comment
#
また、YukiWikiだと同様にアクセスするとURLはそのままでFrontPageが表示されます。(YukiWikiの場合 editコマンド付きじゃないと編集にならない) FrontPageを表示するなら30X系リダイレクトを使うなりした方がいいかもしれないです。
と、いう事でWikiもWikiで、ちょっと何でも200しすぎではあります。
あんまり主旨とは関係なくてスイマセン。
#
# なんでこの子は、そんなページ名にアクセスするのっ!
そういう例を見ると、「なんでこの子は、そんなページ名にアクセスするのっ! メッ!」と思ってしまいますです。どこかからそういうページにリンクされているのだとすれば、リンク元が変だと思うんですよね……。
でもWikiって実装が軽いのが売りなので、「どんなページ名であれ、ユーザーからの入力(ページ名)は意図どおりのものだと信用する」ってポリシーなのかなぁと納得できる気がするんです。「ページ名として何が正しいか」はやり始めるとキリがないですから。
これは同意です。そのほうが好ましく感じます。
#
リソースが無いと言わないCGIですから。
ECサイトの場合、欠番化したID(URL)についてはGoogleに忘れてもらいたいんじゃないですかね。元のエントリはその為のノウハウを書いただけだと思い込めばやり過ごせるかと思ったりします。
で、そういうことならGoogleクローラには404を返すけど、一般的なUAのアクセスには類似商品への案内に飛ばすという手はどうでしょうね。
#
彼らに見えるものがぼくに見えず、ぼくに見えるものが彼らに見えないのが面白いなぁと。なにが違うか、ちょいと探りを入れてみたくてね。そのために、こう、自分に揺さぶりをかけてる部分があって。
それにしてもHTTPのステータスコードです。RFCをよく読んでみると、厳密には5つぐらいしか定義されていないんですよ(ここあまりにもアレなので後で調べて書く>自分)。2xx(正常)と3xx(別URLを見ろ)と4xx(クライアント側のエラー)、5xx(サーバー側、つまりCGIなどのエラー)です。1桁目しか定義されていないんですね。しかもステータスコードは拡張してもよいらしいです。HTTPとはなんなんだろうと考えてしまいますよ。
そういう意味では、ステータスコードの空きも多いし、アプリケーションサーバーの終了コードをそこにアサインしようという考え方は分からなくなかったです。でもでも。でもねー。どうなんでしょ。どうなんだろうねーとね。こういうの考えるのは楽しいです。楽しいから首をつっこんでいる。だから大丈夫です。リカちゃんはこいちじかんといつめますけれども。
#
# 実験してみた
例えば、自Wikiに対して yukiwiki.cgi?mycmd=hoge と未定義コマンドをURLとしてアクセスさせた時に、FrontPageを表示するのですが、その時CGIから Status: 404 Not Found を渡すとApacheがよきに計らってくれました。
FirefoxでもIE6でも404を受信しながらFrontPageを表示出来てますね。
てことは、Googleには404を渡しつつ類似商品の案内をブラウザに表示させる事も可能なんでしょう。
後、全然関係無いけど 検索用フォームの action= は従来CGIのアドレスのみ記述していたんですが、ここに action="yukiwiki.cgi?mycmd=search" と書いておくと、ブラウザのアドレスバーにaction内のアドレスを表示させられるのでブックマークに多少便利かもしれないですね。
# そこにアドレスバーがあるからだ。
っていうのが HTTPStatus:404 だったりするんだろうなぁと思った。
ちなみに、Status:404 とCGIが返すと Apacheは 「404 OK」って言うのね。
#
FrontPage 404実験は面白いですね。さすがAsOさん、いつも手が早い。この実験を見て思ったんですが、WebブラウザというHTTPクライアントは、たとえステータスコードは404でも、コンテンツはユーザーに見せるべきものとして扱うんですよね。なら、GoogleというHTTPクライアントだってそうするのが自然な動きだろうと。
「現状Googleはこうしてるから」と仕様を作るのは、おかしい気がするんですよね。404でFrontPageみたいなのが普通になってしまったら、Googleはそのデータを保存するようになるでしょう。そうしたらまたWebアプリケーションの仕様を変えないといけない。
どっちが正しいかは分からない気がする。だからぼくも、ぼくが正しいとは言えないというのが結論ですかね。なんとなく、ぼくは200を返したい派だけど。
#
私の場合、
http://www.amazon.co.jp/exec/obidos/ASIN/1565928628/
これを見てます。でも日本語の解説サイトはありがたいですね。
ま、Googleは好ましくないアドレスに対しては404くれれば破棄しますよと示しているわけで、間違ってるアドレスが流通しないでくれるという意味ではありがたい事かもしれないです。うまく利用出来るならそれはそれで悪いことじゃないと思うです。
今回は、その能力の「紹介の仕方」に引っかかっただけでしょう。
「404でFrontPageみたいなのが普通に」なるのは確かにまずい事で、危うくそっちの道に進みそうになりました(笑)
今はちゃんと [[Status.404]]と言うページに飛ぶようにしました。
#
そういう意味では、うちの実験の場合異常クエリのを試したのだから 400 Bad requestを返したほうがいいんですよね。
いつか修正しよう。
Trackback