2005-05-19 アーカイブ

http://hxxk.jp/2005/05/19/

コンテントネゴシエーションを行う必要があるものと、必要がないもの

記事データ

投稿者

望月真琴

投稿日時

2005-05-19T00:52+09:00

タグ
概要

mt.cgi に対するコンテントネゴシエーションに何故意味が無いのかという説明と、「できるからやった」という理由で、明確なメリットを説明しないままにその方法を発表することに疑問を投げかける記事です。

リプライ

リプライはまだありません。

記事本文

口うるさいと言われればそれまでなのですが

mt.cgiのリネーム。 ついでにスパム簡単なスパム対策も兼ねてmt-comment.cgiとmt-tb.cgiもリネーム。 lolipopはApacheサーバだからコンテントネゴシエーションを用いて表示されるファイル名の拡張子も無しに

mt.cgi や mt-comments.cgi や mt-tb.cgi をリネームすること自体には異論はありません。 私自身Movable Type における CSRF の可能性と各種対処法 - 防御法 - mt.cgi の名前を変更するMovable Type カスタマイズあれこれ - コメントスパム対策その 2 で述べていますし。

しかし、これらの CGI のファイル名の拡張子を無しにすることについては疑問を抱きました。 そこで、 2xUP:mt.cfgをかくさないと!もっかい!またはいろいろ具体的対策をやってみるに関連のある Movable Type における CSRF の可能性と各種対処法からトラックバックを送ってみたのですが、 ちなみにコンテントネゴシエーションはできるからやったわけで、これが問題の解決の歩みになるとは書いていませんのであしからず との追記がなされました。

「問題の解決には寄与しない」と言いたかったのも確かですが、それ以前に、「この問題を抜きにして考えてもコンテントネゴシエーションを行う意味が無い」と言いたかったのです。

コンテントネゴシエーションの必要性

コンテントネゴシエーションを行う必要のある状況を想定すると、

  • ( UA から見た ) 同一の URI から、異なる言語のリソースを適切に判断して提供する場合
  • ( UA から見た ) 同一の URI から、異なる文字コードのリソースを適切に判断して提供する場合
  • ( UA から見た ) 同一の URI から、異なるメディアタイプのリソースを適切に判断して提供する場合
  • ( UA から見た ) 同一の URI から、異なる種類のリソースを適切に判断して提供する場合

このような例が挙げられます。 要するに、サーバが提供する複数のリソースがある場合に、リクエストを行う UA から見た URI は同じであるように見せるケースです。

例えば、 2xUP が英語版と日本語版の両方のリソースを提供する weblog だったと仮定します。 それぞれのリソースの実態は http://2xup.org/log/yyyy/mm/dd-HHMM.html.enhttp://2xup.org/log/yyyy/mm/dd-HHMM.html.ja という風になります。 そこで Accept-Language フィールドを基にしたコンテントネゴシエーションを行うことにより、 http://2xup.org/log/yyyy/mm/dd-HHMM という URI へのリクエストに対して、 UA に応じて適切なリソースを提供することができます。

管理画面の CGI に対するコンテントネゴシエーションの必要性

Movable Type によって生成される HTML に対してコンテントネゴシエーションを行うことは、充分に有意義だと思います。 現在は .html という拡張子で使われている HTML も、いつまでもその拡張子が使われるかは分かりませんし、 PHP で運用している場合は、既にそう遠くない過去に .php3 から .php への変更を経験しました。 また、 weblog の内容によっては一つの言語に留まらない場合も充分に考えられます。 そういうことを見据え、あらかじめコンテントネゴシエーションを行っておくことは、未来に向けた有効な手段だと思います。

しかし、 Movable Type の管理画面の CGI についてはコンテントネゴシエーションが必要でしょうか。 複数言語のリソースを提供するわけでなく、また拡張子が変わるような事態になっても影響を受けるわけでもありません。 ( 拡張子が変わるような大きな変更がシステム側にあった場合、影響を受けないというより、コンテントネゴシエーションによる拡張子外し程度では対処できないと考えられます。 )

できるからやった という理由で、明確なメリットを説明しないままにその方法を発表することは、その記事を見て鵜呑みにしてしまう人が出るかもしれないという危険を孕んでしまうと思います。 ( この場合は鵜呑みにしてしまう人にも問題はありますが。 )

リプライ

リプライはまだ送られていないか、管理者の承認待ち状態です。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。

Re: 外部の RSS を PHP で取得

記事データ

投稿者

望月真琴

投稿日時

2005-05-19T00:17+09:00

タグ
概要

はてなブックマークなどのソーシャルブックマークサービスにブックマークされた記事というのは、第三者に何かしらの印象を与えた記事ということなので、それを羅列することで自分の weblog からの傑作選を作るようなことができるでしょう。

リプライ

1 件のリプライがあります。

記事本文

はてなブックマークにブックマークされている記事を表示

これは面白そう。 面白そうというより、便利そうです。

はてなブックマークなどのソーシャルブックマークサービスにブックマークされた記事というのは、第三者に何かしらの印象を与えた記事ということなので、それを羅列することで自分の weblog からの傑作選を作るようなことができるでしょう。

私も e-luck さん ( Lucky bag::blog ) の手順を参考に、そのうちhttp://hxxk.jp/ の エントリー一覧をリストアップするテンプレートを作ってみようかな。

PHP での XML 宣言

それと、xml 宣言部分の <? が php の省略タグだと認識されてエラーになっちゃうんで、同じく .htaccess に下記を追加して省略タグを無効にした。

php_flag short_open_tag Off

この方法でも間違いではありませんが、 .htaccess を使わない方法もあります。

<?xml version="1.0" encoding="<$MTPublishCharset$>"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
( 以下省略 )

通常、 XHTML ではこのような XML 宣言の書き方になります。 ( この例では XHTML 1.0 Strict の記述を示しています。 ) それを、 PHP を用いる場合では次のように書くと良いでしょう。

<?php echo '<?xml version="1.0" encoding="<$MTPublishCharset$>"?>'."\n";?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
( 以下省略 )

このように、 echo で書き出すことで処理命令と認識されることを防ぎ、エラーを回避できます。 <?xml-stylesheet href="hoge.css" type="text/css"?> のようなスタイルシートの指定をする場合も同様です。

トラックバック送信先

リプライ

1 件のリプライが送られています。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。

2007-10-12T17:29+09:00 - coolweb

参考になりました。 今後のご活躍に期待します。

補足情報

著作、講演、制作実績など