_ 民間の駐車場に「契約車専用」というアクリル板があるのは珍しくないよね。
_ でも、民間の駐車場の一角に駐車スペースとは別にデカデカと「会計検査院専用洗車場」と書かれたアクリル板があるのは世間一般の常識からはずれてるよね。冗談じゃなくてほんとに洗車してるんだよね。っていうか、何で黒塗りの高級車があんなにたくさん必要なんだろうね。
_ 会計検査院：宿泊先予約など、随意契約で天下り先に発注。もっと追及してやってくださいまし。新聞の切り抜きに必要な知識・能力って何だろ？
_ /.j の RSS にくだらん広告がいっぱい載るようになって、リンク先も行動調査用(たぶん)の URL をいったん経由してからでないとアクセスできないようになった。キモい。
_ ので、自分で RSS を生成するようにした。sh 以外のスクリプトを書いたのはずいぶん久しぶりだけど、骨格はだいぶ前に作ったものの使い回しなので、大した手間はかからず完了。っていうか、PHP スクリプトなんてもう1年以上書いてなかったんじゃ？ モノは ここに置いておくので欲しい人は勝手に持ってってください。使い方は中身を見て勝手に想像してください。エラーチェックとかかなりいいかげんなので使用は自己責任で。
_ できてしまってから、ふと思いついて google で検索してみたら、自分で作るまでもなくけっこうあちこちで配布されてた。まあ、いいやね。
_ なんとなく、自転車で出社してみた。23km の距離を80分。電車で通うのと比べて15分しか変わらなかったり。やっぱり都心に近付くと、スピードにのる前に信号にひっかかって止まる、ということが多くなっちゃうね。今のルートを使ってるかぎりはどんなにがんばってもあと5分の短縮がせいぜいじゃないかな。
_ で、朝から運動した日にかぎって、昼間も仕事で歩きまわったりなんかして。
_ 雷雨なので帰りはすなおに電車で。また別の日に自転車にのって帰るとしよう。
_ A というホストの /dir/ を B というホストに同期したいんだけど、それぞれお互いに直接ログインすることはできず、C というホストを経由する必要がある。
_ なので、C で
を実行してみた。結果。C のカレントディレクトリに B:/dir というディレクトリが掘られてそこにファイルが同期された。そうきたか……。rsync って remote to remote の同期はできないのね。% rsync -e ssh -a A:/dir/ B:/dir/_ さて、こういう状況で C に作業用ファイルを作らずに直接ファイルを転送するにはどうすればいいか。
_ 案1。
なぜかホスト鍵がおかしいとエラーになった。それぞれ単体に ssh するときにはこんな文句は言われないのに。ボツ。% scp -pr A:/dir/ B:/dir/ Host key verification failed. lost connection_ 案2。
B がパスワードなしでログインできる設定になっている場合はこれでうまくいった。パスワードを聞かれる場合はダメ。A の方はどっちでもいいみたい。いまいち汎用的じゃないけど、こうするしかないのかなぁ。% ssh A 'cd /dir && tar cf - .' | ssh B 'cd /dir && tar xf -'_ なんかうまい方法ない？
_ 新入社員がうろついております。といっても、わしも中途で1月に入ったばかりで、新人さんとは3ヶ月しか違わないのだが。新人さんはまだ研修中で正式配属されたわけじゃないけど、そのうちの何人かを引率して施設見学とか行ってみたり。といっても、説明はほかの人にまかせてわしは別のことをやってたわけだが。
_ みんなすごいなー。こっち方面の基礎知識は十分に持ってる人ばっかり。そういう人をちゃんと採用してるんだねぇ。わしが新入社員だったころは、「なにそれ聞いたことないあっぱらぱー」てな感じだったけど。まあ、新人さんに即戦力を求めるのは間違いだと思うので、現時点でそういう知識を持ってたって大したアドバンテージじゃないんだけどね。あっぱらぱーだったわしでもそれなりにできるようになったわけだし。わしみたいな中途は即戦力にならんとマズいんだろうけど。……戦力になってないな、わし。
_ おととい自転車で出社したので、今日は自転車で帰宅。定時までに到着しなきゃいけない朝と違って、帰りは何時になっても誰も困らないので、ぐるっと遠回り。
_ 前半 15km は信号ばっかりの市街地だけど、後半 15km はサイクリングロードで信号も車もない道を。とはいっても、街灯もないしジョギングしてる人はいっぱいいるしで、それほどスピードを出して走れるわけでもなし。結局 30km を2時間弱で。
_ あれ、404 やら 403 やらのエラーページのサイズが512バイト以下だと、IE はサーバからの応答ではなく内蔵の「簡易」エラーページを表示する( 294807)、ってのはある程度 Web 関係の開発をやってる人には常識だと思ってたんだけどなぁ。
_ ちなみに、すべてのエラーステータスについて512バイト制限があるわけではなく、たとえば 401 や 503 なんかのエラーだとこれより小さいサイズでもサーバからの応答がそのまま使われる。512バイト制限のあるステータスコードは 218155を参照。
_ IE のキモさはエラーページのサイズによってどちらを使うかが変わることにあるのであって、決して内蔵のエラーページを使うことにあるわけではないことに注意しておく必要がある。重要なのはエラーが起きたことを通知することであって、確実に通知できるのであれば手段は問わなくていい。たとえば POP サーバにメールを取りにいこうとしたけどパスワードを間違えたとき、「認証に失敗しました」と表示するのはダメで、「-ERR authorization failed」と表示するべきだ、なんて主張する人はあんまりいないと思う。それと同じことだ。携帯電話内蔵のブラウザではサーバからのエラーページをそのまま使うものの方が珍しいわけだし。
_ この前の件。今さらになって /.j 自体にそのことについて ストーリーが立ってることに気がついた。っていうか、 ふつー気がつかねーよ。
_ index.rssなんてのがあるってのも知らんかったぞ。でも、これも URL の末尾に &from=rss というよけいなものがついてるな。こういうことをやってるところは多いけどさ、同じものに異なる URL を与えるのはやめてほしい。同じものは同じものとして扱ってよ。
_ が、まあ、この程度は許容範囲だ。はじめから index.rss の方を知ってればわざわざあんなスクリプトなんか書かなかった。RSS で広告配信することについても文句を言うつもりはない。ただ、*広告でないものへのアクセス*についても、広告配信会社をいったん経由してリダイレクトされないと読めないというのが気に食わないんだ。 CNET の RSS 改造もこれが理由。リンク先の URL がもともと自分がアクセスしようとしていたサイトと明らかに異なるってのは、気持ち悪いを越えて十分に警戒の対象だよ。
_ ログにこんな UA があった。
Mozilla/6.0 (MSIE 6.0, <b>IF YOU SEE THIS STRINGS ARE BOLD, YOUR ACCESS ANALYZER HAS A <a href=\"http://www.google.com/search?q=XSS\">XSS</a></b>) Firefox/1.2.3_ ごめんな。アクセス解析の穴がどうのという以前に、うちはそういうアホは敷居をまたがせないようにしてるんだ。
になってるので 403 でさようなら。この人に悪意はなかったんじゃないかと思うけど直すつもりはございません。BrowserMatch "<.*>" robot deny from env=robot
_ うーん。
不正プログラムにパソコンを乗っ取られ、意図せず迷惑メールを大量送信する会員のメール利用をいったん強制的に停止。会員に連絡をしてパソコンの修復を指導する。はじめは、おお、すごい、と思った。_ でもさ、よく考えてみたら、これダメだよな。ISP の側で「迷惑メール」を大量送信してるってのはどうやって知るんだろ。通信の秘密にひっかからずにこれをやるのって無理なんじゃないかなー。Biglobe は OP25B ではなく流量制限をやってるから、大量送信してるユーザを見つけるのは難しくないだろうけど、その大量送信の実態がワームに乗っ取られたボットである、と断定できる根拠を通信内容の覗き見以外の方法でどうやって拾ってくるつもりなんだろうか。
_ 生 JIS の Subject が文字化け扱いされとる……。MIME 登場以前には常識だったことが「迷惑メールの手口」にされてしまっとる……。
実はOutlookExpressは、件名の文字コードが不明確なメールも、修正してキチンと読める文字コードに自動変換してしまう。いや、ちゃんとエスケープシーケンスで文字コードが判別できるでしょう……。立派な日本語文字列なんだから、日本語のメールを扱う以上は化けたように見える表示をしてしまったらそれはバグだと思うぞ。
_ すげー。ムチャクチャだ。
メールサーバー内にメールが何通あるかは確認でき、最初の何通かはダウンロードできるものの、その後のメールは一切受信ができなくなるというものだ。ということなので、中身も見ずにフィルタしているのではなく、通信内容を覗き見してるんだろうなぁ。生パスワードで POP なんて恐くてできねぇ。_ ただ、この記事をほんとに信じてしまっていいのか、ぶっちゃけライターの勘違いなんじゃ？という疑問もあるわけで。日本の POP サーバにアカウントをもってる中国人なんてそんなに多いはずがないので、影響を受けるのはそれこそ中国出張中の日本人がほとんど、中国国内の情報統制としては効果が薄いんじゃないかと思う。なんでそんなフィルタリングをするのか、中国当局にとってのメリットがよくわからない。たしか ITmedia にも中国在住のライターがいたはずなので、そちらでもレポートしてくれないかなぁ。
_ ドメイン名にアンダースコア(_)は使えない、とよく言われるが、それについて調べたメモ。アンダースコートについての話題はございませんので、検索でやってきたフェチの方はおひきとりくださいませ。
_ RFC2181 #11 によると、DNS のラベルに使える文字に制限はない。バイナリ値でもかまわない（「日本語.jp」を punycode で符号化せずに Shift JIS で登録したって、DNS の仕様上は違反ではない。JPRS が却下するけど）。ラベルの制限は長さだけ。しかし、DNS を利用するアプリケーションの方で、文字を制限するのはかまわない。MX レコードにバイナリデータを登録することは可能だが、だからといってバイナリの MX にメールを配送できるわけではない。
_ RFC1034 #3.5 や RFC1035 #3.1 にはアンスコがマズいと受けとれるような記述があるが、これは DNS でそういう文字を使うのが禁止という意味ではなく、アプリ側の都合でそういう文字を使うことができないかもしれないから注意しろ、という意味である。RFC2181 は定義が曖昧だったり誤解されがちだったものをピックアップして解説しただけの RFC であり、新たな仕様を追加するものではない。つまり、RFC1034/1035 の規定が RFC2181 によって拡張されたわけではなく、はじめからそうだったということ。よって、アンスコは使えない、という根拠を RFC1034/1035 に求めるのは間違いである。DNS 以外のところに理由がある。
_ この話題では RFC952 が参照されることも多いが、こちらでははっきりアンスコは使えないことになっている。しかし、これは DNS 登場以前の HOSTS.TXT（インターネット上の全ホストが記述されたテキストファイル）の書式を定めた RFC であり、現在もこの仕様を厳密に守らなければならないかというとちょっと違う。が、その後に出てきた RFC1123（インターネットホスト要件）が RFC952 を参照している。RFC952 における「先頭はアルファベットのみ」という規定を RFC1123 #2.1 で「アルファベットまたは数字」に拡張していて、これを扱えるよう実装するのが MUST とされている（重要）。
_ アプリケーションごとの規定を見ると、まず URI の定義では、RFC1738 (URL) は RFC1123#2.1 を参照しているので host にアンスコは使えないということになっている。RFC2396 (URI) も RFC1034 #3、RFC1123 #2.1 を参照しているのでアンスコ不可。どちらの RFC も、スキームにかかわらずインターネット上のホストにアンスコは使えない、となっているので、サービスの場所を URI で表現したいと思えばアンスコつきホスト名は不可……だった。
_ URI を定義する RFC の現時点の最新版である RFC3986 では、一転して「何でもアリ」になってしまった。記号類は言うに及ばず、% でエンコードしてやれば 8bit 文字を含むホストだって URI 表記が可能。ちなみに、RFC1630 (WWW URI) は「先頭はアルファベット必須で、2文字目以降は英数ハイフン以外にもいろんな記号文字（もちんアンスコ含む）を利用可」という謎の定義であり、こっちもユルユル派。もっとも URI で「表記できる」からといってそれを「使っていい」とはかぎらない、まったく別次元の問題なので念のため。
_ RFC1945 (HTTP/1.0) の HTTP URL の規定では RFC1630/1738/2396 を参照していないが、RFC1123 #2.1 のルールにしたがうとある。RFC2616 (HTTP/1.1) の HTTP URL の定義は RFC2396 を参照しているのでやっぱりアンスコは使えず、Host: ヘッダにあらわれるホスト名についても URL のホスト名と同じとなっているので（あたりまえだ）、結局のところ使えない。HTTP では使えない。
_ メールの場合、RFC821/2821 (SMTP) ではメールボックスのドメイン部に使える文字としてアンスコは含まれていない。一方、RFC822/2822 の addr-spec ではアンスコが許容されている（atext に "_" を含む）ので、From: や To: といったヘッダでアンスコつきドメインがあらわれても違反とはいえない。っていうか、!$&*.-=^.`|~ みたいな記号列でも RFC2822 的には有効だったりするようだ。知らんかったぞ。なお、これはあくまでメールアドレスに使われるドメイン名についてであり、たとえば DomainKeys/DKIM で使われる _domainkey というラベルはメールアドレスとして使われるわけではないから、RFC2821 の規定は適用されない。
_ アンスコを使うよ、と仕様にちゃんと明記されているものとしては、RFC2782 で定義されている SRV レコードや、現在 RFC 策定に向けて議論中の前述 DKIM などがある。どっちも、ドメインのラベルではあるけど、「ホスト」じゃねぇな。つーか、SRV レコードでアンスコを使うのは "to prevent collisions with DNS labels that occur in nature" というなんとも後ろ向きな理由なのがアレ。
_ ただのメモなので結論なんか出さないけど、とりあえず、DNS は仕様上アンスコを許可しているので、NS レコードにアンスコ入りホストを使うのはたぶん問題ないだろう。それ以外は RFC1123 #2.1 にしたがっておくのが無難、といったところか。
_ 中国の POP3 遮断の件。各方面の情報を収集してみたが、どうも POP3 が切断されてるのは事実のようだな。完全なフィルタリングではなく、接続してしばらくしてから切断。うーん。っていうか、 なんだこの法律は……。そういえば こんなことも言ってたなー。
_ ホスト名の件。そういえばホスト名が使われるもので重要なものに SSL の CommonName があったなー、ということで PKI 関連の規格を調べてみた。……契約したつもりがないのに悪魔に魂を奪われた。この睡魔め。まったくちんぷんかんぷんでどこに書いてあるのかさっぱりわからない。あれは地球上の言語ではない。お手上げ。
_ RFC3986 では URI に使える文字が従来の定義とは異なり、どんなバイト列を持つホスト名であろうと URI で表記することが可能になったのは 書いたとおり。だが、英数記号以外の文字を使う場合は % でエンコードしなければならないので、http://日本語.jp とか、http://生茶.jp といった URL は、制限の厳しい RFC2396 どころか何でもアリの RFC3986 の定義をもってしてもすっぱりはっきり違反である。