とっぷぺーじ
ねこめしにっき
2005/12/後半
2006/01/中旬
アポーストアに行ったついでに Mighty Mouse も買ってみた。
んー悪く無いな。マウスを強く握りしめて使ってる人や、右クリック時に左ボタンへ指を置いたままにする傾向のある人は、たしかにコレは使いづらそう。でもぼくはそういう癖は無いんで大丈夫。でもスクイーズ操作（両サイドボタンの同時押し）は、こりゃさすがにムチャだろ。持ち替えないと出来ないぞ。ホイールのかわりのボール（命名：「クリ○リス」）は操作感が軽くて好印象。
これまではフツーの市販品の 2 ボタン＋ホイールマウスをつかっていた。 OSX 標準のマウスドライバはボタン操作のカスタマイズがまるでできないし、マウスポインタ移動速度を全開にしても遅いし、なにより加速度が調整できないのが死ねる。 OSX デフォルトのマウス移動加速度は、 Classic MacOS 以来のユザにとって、ちと勾配が大きすぎなフィールがあって、違和感ある。加速度の無い or あっても比較的緩やかな Windows をメインに使ってるユザあるいはスイッチしてきたユザにとっても、同様のフィールだと思う。そこで、マウスドライバ兼ユーティリティの USB Overdrive で、そのあたりを好みに調整したりボタンカスタマイズをしていた。
その USB Overdrive は、最新版 10.4 で Mighty Mouse 対応を謳っており、だいたい問題なく使えるのだけども、ホイールスクロールの挙動がよろしくない。これまでは上下ホイール回転ともに「加速スクロール」としていて問題なかったけど、 Mighty Mouse では「加速スクロール」がありえない速度に加速されちゃうわ、スクロール速度を調整不可だわで、細かいスクロールがまるで不能となって、よろしくなさすぎる。速度固定の単なる「スクロール」にしてしまうと、今度はまったく加速がかからないから、これまたウゼェ。つまり Mighty Mouse 対応といっても適正はイマイチすぎ。 OSX 標準ドライバと PrefPane であれば加速スクロールの速度を良い感じに調整できるのだけど、そのかわりボタン操作のカスタマイズとポインタ移動加速度の調整が以下略で、堂々巡り状態。
ちうわけで、 Mighty Mouse への対応も万全らしい SteerMouse を試してみた。設定 UI が USB Overdrive より幾分まどろっこしい感じだけど、悪く無い。ポインタ移動加速度も加速スクロールの速度も好みに調整できるし、アプリケーション毎にボタン操作の挙動を細かく設定することもできるし、願いは全て叶う。しばし試用して無問題ならレジストしよっと。
あと、「クリト○ス」の動きが悪くなったとき用の覚え書きをメモっとく。
「第五世代 iPod (60GB) なんか不安定ですね？」の続編。ようやく銀座のアポーストアに行って、症状を訴えた。そしたら現物と新品との即交換と相成りました。いまんとこ、交換前みたいな多発フリーズや強制リセットは起きてないです。ヤレヤレ。
ただ、交換前のヤツは、裏の鏡面仕上げのトコに文字刻印を入れてたんだけど、それも含めての交換となると、現物を取り上げられた上に新品が届くまで数週間かかるとか無体な事を言われたので、仕方なく刻印はあきらめた。
交換前に入れてた刻印は、 Slayer の有名すぎる曲の一節より Rancid Angel Of Death flying free.
この死の天使メンゲレの呪詛の言葉が不安定にさせてたんだろかー。
それなら hxxk.jp の訪問者に何を知りたいかを尋ねて、それについて答えていけば効果的なプロフィールの拡充を行えるじゃないか ! ということにしました。 結城浩のはてな日記 - ニュー速：結城浩だけど何か質問ある？の二番煎じじゃないかとか言わない。
[ hxxk.jp より ]
ほほ。面白い試みだなー。ぼくもやってみよう。
302とかつて何う遣つて見たら良いのか分らず。
[ 日記 (kahusi.org) より ]
HTTPリクエストヘッダとかレスポンスヘッダならView HTTP Request and Response Headerで見られる。結果が書かれているリソースにリンクを張る事も出来るので、結構便利。
[ 無為徒食日記 より ]
ターミナルエミュレータで HTTP を手動で喋ればいい。楽するなら w3m -dump_head http://example.com/ とか lynx -view -head http://example.com/ とか libwww-perl があるなら HEAD http://example.com/ とか……。あー、この手のツールは、リダイレクトした先のヘッダもって来るかも(わらい)
[ 回顧録？ より ]
クライアントが送ってくる HTTP 要求ヘッダによって挙動を敏感に変えるような、込み入ったことをしている相手でなければ、View HTTP Request and Response Header でも Firefox 拡張の LiveHTTPHeaders でも w3m でも何でも良いので、らくちんな奴を。
漏れのオススメは 横取り丸＋ InetSpy かな。このにっきにしては珍しく Windows のソフト。ローカルプロクシなんで、 LAN 内のいろんなクライアントから串刺しして使えてナイス。ただし HTTPS には使えない（はず）。
しかし、挙動が敏感に変わるような込み入った相手かもしれない時、あるいは、たとえば「なつみかん」のようなある意味特殊なクライアントに対する応答を調べる時とかは、上記のようなツールだと正確なものを得られてない懸念を抱いたりする。 View HTTP Request and Response Header にしろ LiveHTTPHeaders にしろ InetSpy にしろ、それらを呼び出したブラウザ（等）の HTTP 要求ヘッダに対する応答しか見れないとか、一段特殊なモノを通過している事により何かが変わる可能性を否定できないとか。 w3m もデフォの Accept フィールド値は微妙な設定なので、そのへん気をつけないと、微妙。
よって、ターミナルエミュレータで HTTP を手動で喋ればいい
というのも、正確を期すという点ではあながちムチャクチャな話でもなく。「Location フィールド抽出処理あたりの、なつみかんのバグ」にて、 HTTP 応答ヘッダを採取した
とかサラリと書いてますが、実際には、手元の OSX 上で「さとみかん」の実物を動作させつつ tcpdump でパケットキャプチャ、とゆー力技を用いていたり。結果はフツーのブラウザでアクセスしたのと同じような応答だったけども、それは結果論なのであって事前にはわかんないし。
- ScrapBook
- Opera のメモ機能の進化版……かな。 (以下略)
いやぁ先日惜しまれつつ逝った MacIE の、後世に語り継がれるべき数々のイカす機能うちのひとつ、そのものズバリ「ScrapBook」の進化版……かな。とかいつもウザいクソマカーの漏れ。
なんにせよあの ScrapBook 同等以上のモノが Firefox で使えるというのはメデタイ。…はずだけど、相変わらず OSX で Firefox をメインブラウザとして快適に使うのは冗談キツイ状態なので、以下略。
Mac OS X 版 Firefox 1.5.0.1 は Firefox 1.5 が備えるはずだったものをすべて備えるんだそうです。（略）
- Mozilla 製品の Intel Mac OS X への移植。Intel Mac 発売後すぐに公開される予定。
- Aplle の Cocoa API を利用するよう Mac OS X 基盤の多くを書き直し中。成果は Firefox 3 で。
- Firefox 1.5.0.1 と Firefox 2.0。これらは Max OS X サポートという意味ではほとんど同じ。
[ えむもじら より ]
Firefox 3
を待てと…。イツデマスカソレ…。
ずいぶん前からブクマってたけど、当にっきで紹介するのが今頃。
（なつみかんって）いつの間にやら開発が凍結してたんですね… 後継のいよかんも凍結ですか… ググって見つけたパッチを適用＆クイックハックしたのですが、せっかくだから置いておきましょう。
そしてすごく遅い反応。
- LENGTH 取得したときも hina.di や hina.txt に更新情報を出力するようにした。また、3 時間で Expire される仕様を廃止。（by ありみかさとみ さん）
リンクの href 属性が
になっててリンクになり切れてないのと併せてこう書かれてると、誤解を招くというか、そのパッチの作成者は 牧野 尚彦さん です。もともとパッチを配布してた旧サイトがまるごと無くなるってんで、無断のままパッチファイルを保護してウチに置き、そのまま今に至るわけです。あーでも今みたら、パッチファイルも Internet Archive に保存されてたヨ…。（← 4 年越しの徒労の人）
hrerf
(X)HTML の仕様 (あるいは W3C 勧告) 含め、「 Web 標準」なるものに従う重要性やらご利益やら何やらを語る事の多い「ストリクター」気質のサイトの中の人は、それゆえこの Web や Internet を利用可能たらしめている HTTP 他のプロトコルとか (の RFC とか) に対しても、同様の厳格性でもって事にあたるべしであると常々。
さて、最近「さとみかん」で新規捕捉したサイトのうちいくつかは、 HTTP リダイレクトによる「最新記事のページへ常に飛ぶ URI 」を提供してます。このにっきがそうしているのと同様あるいは類似のアレ（どれ）ですね。
この「リダイレクト方式」は、非ブログツール系の某方面（死語）サイトによく見られるものでして、ウチを含め、これまで同方式のサイトは多数捕捉してきてます。「さとみかん（の中の人である「なつみかん」）」は問題なくそれらの更新日時を取得できる所以なのだけど。ところが今回捕捉した同方式のサイトは、たまたまだけど、ことごとく更新日時の取得がうまくいかない（いかなかった）。
以下、リダイレクトまわりが原因で更新日時の取得がうまくいかないパターンを、いくつか挙げてみまっす。
今回の事例では、「ねっとねっとねっとねっとねっとねっと日記」が該当（現在は問題解消されてます） 。
「リダイレクト時の HTTP ヘッダーを勉強中」でご自身が述べていますが、HTTP 応答ヘッダの Location フィールドの値は、必ず「絶対 URI (absolute URI) をひとつだけ」でないとダメです。
(RFC2068 は RFC2616 により破棄・更新されてます。)
であるから「なつみかん」は、 Location フィールドに常に絶対 URI が与えられているものとして処理してます。というか絶対 URI じゃないモノが与えられたら無視して終了ぽ。$nm::cf::base/lib/detect.pm の site_access() のあたり参照。
多くの Web ブラウザや HTTP クライアントは、ここに相対 URI が与えられた場合も「弾力運用」的になんとかしてしまう物が多いです。「仕様に忠実で厳格である」として一部の強まった「ストリクター」たちに好評の Opera でさえも同様（←余計な一言）。HTML/CSS/JS を書くとき同様、特定のクライアントでうまく行くからといって過信は禁物、の例。
もちろん「なつみかん」の detect.pm の該当処理部分に数行を付け足せば、相対 URI でも問題なくリダイレクト追尾するようにはできますよ。しかし、「ストリクター」気質なサイトを多く捕捉している「さとみかん」の立ち位置を鑑みるに、そういう対処はすべきでないと踏んだ次第っ。
これまた、「ねっとねっとねっとねっとねっとねっと日記」が該当（現在は「なつみかん」を修正して解決済み）。
http://net.netnetnetnet.net/diary/latest へのアクセスは、コンテントネゴシエーションにより http://net.netnetnetnet.net/diary/latest.php へのアクセスとなります。この latest.php が実際に最新記事ページへのリダイレクトを司っている実体です。この latest.php が Location フィールドを絶対 URI で送出するように修正された事はこちらでも確認できてたのですが、あいかわらず「さとみかん（の中の人である「なつみかん」）」はリダイレクトの追尾に失敗していた。 Location が示した絶対 URI へではなく、なぜか相対 URI の latest.php へ飛ぼうとする。
以下は「さとみかん（の中の人である「なつみかん」）」が http://net.netnetnetnet.net/diary/latest へアクセスした際の HTTP 応答ヘッダを採取したもの。
HTTP/1.1 302 Found Date: Sat, 07 Jan 2006 13:46:56 GMT Server: Apache/2.0.54 (Debian GNU/Linux) mod_python/3.1.3 Python/2.3.5 PHP/4.3.10-16 mod_perl/1.999.21 Perl/v5.8.4 Content-Location: latest.php Vary: negotiate TCN: choice X-Powered-By: PHP/4.3.10-16 Location: http://net.netnetnetnet.net/diary/2006/01 Connection: close Content-Type: text/html; charset=utf-8
ハイ、この時点で何となく想像がつきましたが。「なつみかん」は Location フィールドより前に出現する Content-Locationフィールドの値 (相対 URI の "latest.php" ) を、リダイレクト先 URI として認識しちゃってるワケです。「Location フィールドが絶対 URI で示されてない」で書いたように、リダイレクト先 URI は必ず絶対 URI で与えられるものとして処理してるので、結果、それ以上何もおきない。
該当の処理をしてるのはやはり $nm::cf::base/lib/detect.pm の site_access() のあたりですが、ここの正規表現がショボいことになってた。「なつみかん」の作者は Content-Location フィールドの存在を知らなかったのかな。ってぼくだって今回初めて知りましたけどね！
注: Content-Location ヘッダフィールド (section 14.14) は、リクエストと共に送られるエンティティのオリジナルの場所を指すという点で、Location ヘッダとは異なる。それ故に、レスポンスは Location と Content-Location の両ヘッダフィールドを含む事は可能である。
[ [RFC2616] ハイパーテキスト転送プロトコル -- HTTP/1.1 の Location の章 より ]
ちうわけで Content-Location はコンテントネゴシエーションとかの時に選択されたリソース実体の出元 URI の明示に使うためのモノっぽく（で合ってマスカ？＞識者（誰））、リダイレクトとはちっとも関係ない。「なつみかん」の挙動は明確にバグなんで修正したです。修正とかエラソーに言ってますが、一文字追加しただけ。
それはそうと「なつみかん」の公式配布サイトも作者様のサイトも消滅の今、この件をどうフィードバックすべきですか。
今回の事例では、「怠惰な日々」と「日記 (kahusi.org)」が該当。
件の「最新記事ページへ常に飛ぶ URI 」というのは、そのリダイレクト先の URI が、時の流れあるいはログの蓄積に従って次々変わってゆきます。逆にいうと、時の流れあるいはログの蓄積に従って最新記事ページ（実体）の URI が次々変わってゆくなかでも、「最新記事ページの URI 」を擬似的に固定するためにリダイレクトを使っているわけです。こういう用途の場合、リダイレクト時のステータスコードは 302 が相応しい。
では 301 と 302 はどう違うのかというと。
リクエストされたリソースは新しい恒久的な URI に割り当てられたので、以降そのリソースへの参照は返された URI の一つを使用すべきである。リンク編集機能を持つクライアントは、可能であればサーバにより返された新しい参照の一つ以上の Request-URI を参照するように自動的に再リンクすべきである。
リクエストされたリソースは、一時的に別の URI に属している。このリダイレクションは場合によって変更されるかもしれないので、クライアントは将来のリクエストではその Request-URI を使い続けるべきである。
つまり 301 でリダイレクトを指図されたクライアントは、それ以降、リダイレクト元の URI へ行くのが憚られ気味になると言って過言でなく。意味論的には「これまで『最新記事』を示していた latest.html は無くなりました！替わりに今後は 200601.html が永久に『最新記事』ですヨ！」となる。これじゃ「リダイレクト方式」の意図するトコロから相当外れてますやね。
リンク編集機能を持つクライアントは、可能であればサーバにより返された新しい参照の一つ以上の Request-URI を参照するように自動的に再リンクすべきである
というのを Web ブラウザに当てはめたら「 301 に出会ったらブックマークを自動修正すべきだ」となるよね…というのがよく語られる。
さて「なつみかん」の実装はというと、リダイレクト処理はステータスコード 302 の時しかしないようになってます。これまた $nm::cf::base/lib/detect.pm の site_access() のあたり参照。もちろん、該当処理部分に数行を付け足せば、301 の場合も細かい事なんか気にせず 302 同様リダイレクトするよう修正する事はできます。しかし、「Location フィールドが絶対 URI で示されてない」の件と同様で、そういう対処はすべきでないと思うので、しない。
はてなアンテナ、リダイレクトする類は碌に拾はないみたいで都合が惡い。
[ 日記 (kahusi.org) より ]
はてなアンテナがどう内部で処理してるかなんて知りませんが、やっぱり 301 でリダイレクトしてるのがダメなんじゃないのかな。
alib.jp の Perl CGI まわりに障害が発生中のモヨリ。サーバ内部的には Perl は正常動作するものの、HTTP 越しに CGI として動作させると全てサバエラー。 Perl を動作させる SSI もダメ。復旧時期不明。館長〜〜〜〜〜。
ねこめしにっきヘッドラインbase target のブラウザ別の出し分けが出来なくなっていて、現在静的に "_content" 固定。 Gecko 系ブラウザ専用状態。 Opera やその他はサヨウナラ。残念なことに、土曜日にあたっている日が４日もある。2月の建国記念日、4月の旧天皇誕生日、9月の秋分の日、そして12月の天皇誕生日である。土曜日が休日の勤労者にとっては４日も休日を損することになる。
[ 革電同 より ]
うげぇ…。
このにっきは 2001 年 2 月から始まっているのですが、その全項目がようやくコメント・トラバ可能となったのです。そりゃまぁ、今更な気がしないでもないですが。
これまでは 2001 年 12 月以降の分のみが可能となってた。それ以前の分は、各項目のフラグメント ID がそれ以降の形式とは違ってて（しかも二種類）、フラグメント ID から作り出している TrackBack ID の扱いがそれゆえメンドく、放置してた。単に実装上の都合だったという。今回、その過去のフラグメント ID を現在の形式で揃えてしまったので、問題なくなった。
ただ、変えてしまった過去のフラグメント ID に対して、ヨソ様のサイトから張られているリンクが依然としてそこそこあるので、どうしたものやらと悩むのだけれど、まぁ古い記事ってこともあるし、スクリプトで動的にフラグメント ID (つか location.hash) のツジツマをあわせておけばいいっしょーっと
（でもまだやってない）
（実装した）
。スクリプト OFF の人の事は考慮しません。人力でガンバレ。（えー
Blog ブーム以降のブログサイトあるいは日記サイトには、プロフィールやアバウトページのようなものを用意しないトコがやたら多い、…という定説がありますやね。匿名というか名無しのママ何かを好き勝手にノベたい、というスタンスならばそれはそれでいいと思う。でもそうでなく。どういうわけか「さすがに漏れの名前くらい誰だって知ってるんダロ？」と考えてる気配のサイトもチラホラ。しかし、他人からしたら当然のことながら、名乗られずして名前なんぞ分かるはずが無いとゆーか。
さとみかんにて新規に捕捉先を増やす際は、そのサイトを右往左往して書き手の名前を探します。これがなかなか見つからないんですよ。普通に探して分からなければ、そのサイトのコメント欄や掲示板はもちろん、論争先（何処）のブログや掲示板でその人がどう名乗り、どう呼ばれているのかまで探ったりしてます。気分はちょっとしたストーカー。
前にもこういう毒を吐いたことがありますが、その捕捉先がいわゆる信者系サイトの場合、「当サイトは XHTML1.1+CSS がウンタラでださいブラウザでは表示が崩れてカンタラですが意味構造は明確なのでホンダラ」とかのよくある信者な戯れ言を書いている暇はあっても、書いてる人の名前とかそういう大事な事を書く暇は無かったのかいな、と思うケースがやっぱりある。信者的能書きも良いですが、その前にプロフィールを「これみよがし」に提示して欲しいのココロですよ、まったくもう。
ちうわけで当人からしたら「完全なハズレ」や「イマイチハズレ」な名称を拾って来てしまう事も多く、遺憾ながら、以下のような申し出をいろいろな方法で受けることも時々あって。
kemuri_hsさんとなっていますが、一応私のハンドルネームは羞恥心若しくはa sense of shameだったりします。
そうならそうと「著作者について」のトコに、バッチリこれみよがしに書いておいてほしいのです。いや、たしかに HTML ソースをみれば、
と書いてあるのは見つけてました。が、サイト名と書き手の名前が同一というのはにわかに信じがたいというか、それが書き手の名前であるとの確信が持てない最たるケースでして。<meta name="author" content="羞恥心" />
蛇足にアンテナとは関係ない話をついでに。同人お絵描き系サイトへのリンクを貼るときに最も煩わしい作業が、上記の名前探索に加えて、バナー画像の所在を探す作業。お絵描き系サイトはバナー画像を使ったリンクを貼られてナンボなんだから、リンクページの奥底とか俺ルール宣言ページの末尾とかじゃなく、トップページにこれみよがしに置いておけっつーの！
飲み会で盛り上がるみなさんを後目にコソコソ集計してて発覚した釣銭詐欺が一件。500円玉だと思ってたらサンリオピューロランドのメダルでした……
[ Latest topics より ]
やっちまいました。ええ、サンピューメダル、新500円玉と似たような色で割と近い大きさしております。ええ、ええ、間違えました。財布に入れておいたのが運の尽きでした。
[ 雑記 より ]
そして iMa たそからそのサンリオまじりのお金を受け取っておいて、何の疑問も抱かなかったのが臨時売り子の漏れ。殺セ！
正月休みは実家にも帰らず、まるごと「 V ガンダム」全 51 話の鑑賞に費やしたヨ。シャクティたんの恐るべき疫病神っぷりは終盤の全裸水浴びシーンにより不問とす。しかし、宇宙世紀稀代の悪女・豹変のカテ公ことカテジナさんはやっぱ良すぎだ！最終話のボロキレのようなカテジナさんに加虐心がメラメラしまくりますよー。（危険
Mail to Alimika Satomi
Site search
About copyrights