Notes :: 2005年05月 - Rhongomyniad.org

RDFのMIME type（2）

URI: http://rhongomyniad.org/notes/2005/05.html#d26t2346
カテゴリ: Web全般; ブラウザ全般
投稿日時: 2005-05-26 23:46

RDFのMIME typeでHTTPレスポンスヘッダとXHTML文書内のMIME typeを一致させられないことがもどかしい。などと述べたが、これは単純に「特定のUA（ブラウザ）に対する指定」を取り除けば解決する話であった。

HTTPレスポンスヘッダのMIME type

サーバから送り出されるデータで、リクエストされたファイルの処理方法が指定される。

HTTP/1.0 200 OK
（中略）
Content-Type: application/xml; charset=utf-8

XHTML文書内のMIME type

link要素のtype属性値のこと。今のところ、処理（開く/open）には影響しない。

<link rel="alternate" type="application/xml" href="/notes/rssfeed.rdf" title="Notes :: 更新情報" />

現在、RDFファイルに対して設定できるMIME typeは次の3種類である。

application/rss+xml: 比較的多く使われており、OperaやFirefoxはlink要素で指定されたRSSの存在を自動認識できる。OperaはアドレスバーにRSSの文字を表示し、Firefoxは右下にオレンジのマークを表示する。
application/rdf+xml: RDFのMIME typeとして RFC 3870で登録されている。
application/xml: XML文書として認識させる。HTTPレスポンスヘッダでこれ以外のMIME typeが指定されていると、GeckoはそのRDFファイルを開くことができない。

RSSの存在をブラウザに認識させるならapplication/rss+xmlだが、これをHTTPレスポンスヘッダに指定するとGeckoで開けなくなってしまう。現実的にはlink要素にapplication/rss+xmlを指定し、HTTPレスポンスヘッダにはapplication/xmlを指定することになる。しかし、いくらlink要素で指定したMIME typeが実際の処理とは無関係といえど、HTTPレスポンスヘッダと異なるMIME typeを指定するのは気が進まない。実際にはtext/htmlであるのに、Another-HTML lintの文法チェックで減点されないよう、meta要素でapplication/xhtml+xmlだと言い張る文書とさして違わないからだ。

結論としては、application/xmlで統一することにした。わざわざGeckoが開けないRDFファイルにする必要はないし、いくらRFCで登録されていようとも開けないのであれば本末転倒である。

MSIE: 要素内容が左ないし右にずれるバグ

URI: http://rhongomyniad.org/notes/2005/05.html#d26t2218
カテゴリ: CSS; MSIE
投稿日時: 2005-05-26 22:18

今や手の込んだCSSを用いず、専らテクストを読みやすくしているにすぎないが、MSIEにおいて何らかの原因で要素内容が左へずれてしまう現象を確認した。CSSバグリスト WinIE バグ009では、最後の子要素が非匿名ブロックレベル要素である要素の四方にパディングを設置し、さらに左または右にボーダーを設置すると、その要素に後続する要素の内容物がボーダーを設置した方向にずれてしまう。と解説されており、blockquote要素やins要素に指定した左ボーダーが原因だと分かった。

現在、blockquote要素とins要素には次のプロパティを指定している。

blockquote {
    border-left: #171 solid 2px;
    margin: 1.5em 4em;
    padding: 0.3em 1em;
}
ins {
    display: block;
    border-left: #177 solid 2px;
    margin: 1.5em 4em;
    padding: 0.3em 1em 0.1em 1em;
    text-decoration: none;
}

原因となるプロパティはborder-leftとpaddingで、これらを指定しているblockquote要素やins要素が出現する度に以降の文字列が少しずつ左にずれていた。該当する要素にleft以外のborderを指定することで解決したため、新たに次の指定を追加した。

blockquote, ins {
    _border-top: #fff solid 1px;
    _border-right: #fff solid 1px;
    _border-bottom: #fff solid 1px;
}

先頭のアンダースコアはMSIEにのみ認識させる手法であり、MSIE以外のブラウザはこの指定を無視する。元々PHPでUAを識別し、HTTPリクエストヘッダでMSIEと同じ文字列（Mozilla/4.0 (compatible; MSIE 6.0; Windowsを含むもの）を吐くUAに対して修正スタイルシートを出力しているため、このアンダースコアは一見不要に思える。しかし、UAの偽装はいくらでもできることを考慮し、MSIEエンジン（Trident）だけが認識するアンダースコアを使うに至った。

もっとも、これは姑息な手段（一時しのぎ）にすぎず、推奨できるものではないことを付け加えておく。

XHTML: Dublin Coreによるメタデータ

URI: http://rhongomyniad.org/notes/2005/05.html#d20t0314
カテゴリ: XHTML; Webサイト制作
投稿日時: 2005-05-20 03:14

XHTML/HTMLでは、文書のメタデータを記述するためのmeta要素が定義されており、例えば、文書の作者を示す情報を付加する場合に<meta name="author" content="桐沢辰" />などとして使う。しかし、作者を示すauthorはあれど、作成日を示すmeta要素のname属性値は存在しておらず、詳細なメタデータを記述するには不足があった。そこで、メタデータを記述するための語彙としてDublin Core Metadata Initiativeで策定されたDublin Coreを用いることにした。

Dublin Coreについては、Dublin Core: メタデータを記述するボキャブラリ（The Web KANZAKI）が詳しい。神崎氏の文書を読んだ後、DCMIによるExpressing Dublin Core in HTML/XHTML meta and link elementsを読むと理解が深まる。

Dublin Coreをmeta要素で扱うには、link要素で接頭辞DC.をDCの名前空間と結びつける必要がある。Dublin Coreをmeta要素で用いる場合、次の指定は省略できない。

<link rel="schema.DC" href="http://purl.org/dc/elements/1.1/" />

これで"DC.title"といったDublin Coreの語彙を用いた属性値が扱えるようになる。Rhongomyniad.orgでは、titleの他にcreatorとidentifier（識別子: WWWではURI）を記述している。

<meta name="DC.title" content="Notes :: 2005年5月" />
<meta name="DC.creator" content="桐沢 辰" />
<meta name="DC.identifier" content="http://rhongomyniad.org/notes/2005/05.html" />

また、精密化要素と呼ばれる語彙を用いることで、文書の公開日や更新日といった詳細なメタデータも扱えるようになる。精密化要素の接頭辞はDCTERMS.となり、DCTERMSの名前空間と結びつけた上で次のように用いる。

<link rel="schema.DCTERMS" href="http://purl.org/dc/terms/" />
<meta name="DCTERMS.created" content="2005-05-02" />
<meta name="DCTERMS.modified" content="2005-05-20" />

文書情報をあれやこれやとaddress要素に詰め込むのではなく、文書の作成日ならそれだけで一つのmeta要素として記述できるため、コンピュータにとって読みやすいメタデータを提供できるだろう。実に合理的だ。

Hyper-Threadingに脆弱性

URI: http://rhongomyniad.org/notes/2005/05.html#d15t1500
カテゴリ: 雑多
投稿日時: 2005-05-15 15:00

IntelのXeonやPentium 4系列（CPU）などに実装されているHyper-Threadingに脆弱性が見つかった。Intelのハイパースレッディングに深刻な脆弱性（ITmedia）では、マルチユーザーシステムの管理者は直ちに使用を停止した方がいいとの勧告が出されている。と報じられている。なお、シングルユーザシステム（個人利用のコンピュータ）はこの影響を受けないそうだ。

Hyper-Threading Considered Harmful

具体的には、この脆弱性が原因でローカル情報が流出する恐れがあり、権限を持たないユーザーがRSA非公開鍵を盗み出すことができてしまうという。と説明されている。

それにしても、CPUの技術に脆弱性が見つかるとは驚きだ。シングルユーザシステムに影響がないのは、（私にとって、ではなく）ある意味幸運であったかも知れない。

Opera 8.01 Preview 1公開

URI: http://rhongomyniad.org/notes/2005/05.html#d08t1745
カテゴリ: Opera
投稿日時: 2005-05-08 17:45

Opera 8.00 Finalのバグ（主にクラッシュ関係）を修正したOpera 8.01 Preview 1が公開された。

8.00 Finalは、リリース直前にWindows XPのSP2を入れたためか少し安定性が悪かった。SP2をアンインストールした後は、それまでクラッシュしていた状況を再現しても大丈夫だったため、私の環境でSP2と8.00 Finalの相性が悪かったのは間違いないようだ。SP2にはマウスカーソルが勝手に動くなどの変な挙動が多かったこともあり、アンインストールすることには何の躊躇もなかった。

8.01p1では今のところクラッシュしておらず、7.60p4並みの安定性があるように感じている。おかしな話ではあるが、私はFinal（正式版）やBetaよりPreview（Alpha）を気に入ることが多い。細かな挙動まで評価に含めると、本当に満足できるバージョンは限定されてしまう。その満足できるものにPreviewが多く、最近のバージョンでは7.60p4や8.01p1（今のところ）が該当する。

PHP: エラーメッセージ表示の是非

URI: http://rhongomyniad.org/notes/2005/05.html#d02t2212
カテゴリ: PHP
投稿日時: 2005-05-02 22:12
更新日時: 2005-05-22 23:47

PHPのエラーメッセージには、デバッグしやすいようにスクリプトの場所が含まれている。制作者にとっては役立つ情報だが、第三者が閲覧できる状態にするのは危険でもある。

Fatal error: Call to undefined function: あarray() in /home/sites/users/foo.php on line 10

これは第三者にスクリプトやシステムの構造を公開しているのと同義であり、安全面から見て好ましいことではない。このことから、rhongomyniad.orgではエラーメッセージを表示させずにログを取ることにした。設定は別段難しくなく、.htaccessで次のように指定するだけである。

# エラーを非表示
php_flag display_errors Off

# エラーのログを記録する
php_flag log_errors On

# ログファイルのパス（絶対パス）
php_value error_log /home/sites/users/foo/error.log

空の.logファイルをアップロードし、パーミッションを606に設定すれば作業は完了だ。加えて、.htaccessで外部から.logファイルを閲覧できないようにしておくとなお良い。

<Files ~ "\.(log)$">
deny from all
</Files>

エラーのログを記録しておけば、いちいちすべてのページをチェックしなくて済むというメリットが得られる。安全性を高めるだけではなく、制作者の負担も減らしてくれる有難い機能だ。

2005-05-05 01:21追記

語弊があった。「いちいちすべてのページをチェックしなくて済む」とは、すべてのページの最初から最後まで（つまりは上から下まで）見る必要がないという意味である。とにかくそのページを開きさえすれば、発生したエラーをすべてログファイルに記録してくれる。

2005-05-22 23:47追記

文書情報

桐沢辰