Oct - 6th

HEADリクエストとLocationの小ネタ

Posted at 8:16 pm | Filed Under PHP, mobile

PHPでLocationヘッダを出力してリダイレクト処理をするとき、

<?php

header("Location: http://www.example.com/");
exit;

?>

こんな感じでリクエストを普通にリダイレクトで飛ばすのが大半なわけだが、このリクエストがHEADで来た場合、リダイレクト先へのリクエストも当然ながらHEADになってしまう。

携帯サイトでOBJECTタグを使った場合、auなどはダウンロードページのOBJECTタグのURLに記述された先へHEADリクエストが飛ばされる（ことがある）。そこでOKが返らないとちゃんと動作しない。いつも飛ぶわけではなさそうなので、キャッシュの問題もあるのかもしれないが再現性があんまりなくて深追いしていない。

で、たとえばセッションで認証していたりする場合、$_SERVERのREQUEST_METHODを参照してHEADリクエストの場合は別処理にしてやるなどしないと、OBJECTタグでアクセスする先のファイルで認証エラーが発生したらログインページにリダイレクトで飛ばそうなんて処理を入れたら、HEADリクエストのままリダイレクトされてしまうので正常に動作しない。

しかし、それはそれでHEADリクエストを使って認証をかいくぐる方法なんかが考案されたらまずい。とはいえ、


$_SERVER['REQUEST_METHOD'] = 'GET';

とかやってももちろんLocationヘッダでリダイレクトしたらHEADリクエストのまま飛んでいってしまう。

というわけで、OBJECTタグでアクセスする先のファイルで認証を入れたい場合は、失敗したらいっそ404を返してファイルが存在しない、とかしてやった方がいい。少なくともHEADリクエストのままどこかに飛んでいってページが正常に表示されなくなるよりはまし。

Jul - 16th

iPhoneのSIMカードはSoftBank 3G端末では認識しない、けど…

Posted at 9:58 pm | Filed Under Apple, Fun, mobile

SoftBankのサポートページのPDFファイルにはこんな記述がある。

・専用USIMカードはSoftBank3Gに挿しても使用することはできません。
・SoftBank３Gへ戻す場合には、USIMカード交換（有償）が必要となります。

確かに実機で検証するとこんなエラー画面になる。

ここまではSoftBankの説明どおりである。

実にけしからん。iPhoneなんかやめた、と思い切って他の端末を友達から安く買ったという人はいったいどうすればいいのか。消費者の見地からこれは実に見過ごせない由々しき問題である。

ところで、SoftBankといえばその前身はVodafoneである。

SoftBank3Gではだめだというなら、ではVodafoneならどうなのだろう。誰もがそんなことを思うことには疑いの余地はない。

というわけでさっそく実験。iPhone 3GのUSIMカードを取り出して適当なVodafone 3Gの端末に入れて起動してみる。

起動した。となりの黒い箱は犠牲となったiPhone。

起動しただけかもしれないのでさっそく電話する。

通話できた。

ちなみにSIMロックが解除されたヤクザな携帯端末もちゃんと起動する。

もちろん、iPhone 3GのSIMロックを解除したわけではないので、念のため。第一、iPhone 3G専用をうたっているあのSIMカードは、そもそもiPhone 3Gを買った人じゃないと手に入らないので、何かの犯罪を教唆しているわけでもない。

あ、パケット通信はできないよ。

あと、番外編としての豆知識。

１　iPhone3Gは電源が入ったままSIMカードを抜いても大丈夫だった。
２　SIMカードをドックの口に挿す人間は必ずいる。
３　iPhone 3GとかSIMロック解除とかいうキーワードはすさまじくSEO効果が高い。

何かを勘違いしてアクセスしてきた人たちにはサービス画像。

Imaginary iPhone

iPhone実機が買えなかったので想像して描いたiPhone。

Jul - 9th

SoftBankのメールサーバ移設でミスが起きてないか？

Posted at 7:47 pm | Filed Under mobile

近頃どうも奇妙な現象が続いていたのだが、どうやらSoftBankがメールサーバの集約に失敗し続けているようだ。

いつからかはまだはっきりしないのだが、この2ヶ月ほど、何度か突然vodafone.ne.jp宛のメールが送信エラーになることがあり、どうしたのかといぶかっていたのだが、昨日その瞬間を捉えることに成功した。手元にスクリーンショットなどはないのだが、まとめるとこんな感じ。

突然@t.vodafone.ne.jp宛のメールが送信エラーで戻ってくる。
ログをみると途中でリレーを拒否されたといっている。
telnetで25番に接続してみる
某レジストラのサーバに挨拶される（びっくり！）

というわけで、digでいろいろ調べていたが、1時間くらいでIPアドレスが変わって復旧していた。最初は自分のところのネットワークがSoftBankから蹴られているのかと焦り、次はDNSポイズニングかと思ってさらに焦ったが、telnetしたらさらにびっくりした。きっとその某レジストラは、大量のリレー要求がきてびっくりしていたはずだ。

ちなみにいまdigしてみると

$ dig MX t.vodafone.ne.jp

; <<>> DiG 9.2.4 <<>> MX t.vodafone.ne.jp
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35439
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;t.vodafone.ne.jp.              IN      MX

;; ANSWER SECTION:
t.vodafone.ne.jp.       783     IN      MX      10 mx.k.vodafone.ne.jp.

;; ADDITIONAL SECTION:
mx.k.vodafone.ne.jp.    300     IN      A       202.179.204.119

;; Query time: 7 msec
;; SERVER: 202.224.32.1#53(202.224.32.1)
;; WHEN: Wed Jul  9 19:35:24 2008
;; MSG SIZE  rcvd: 71

こんな感じになっている。

Vodafoneのメールアドレスは東京なら「t」みたいに分かれていたのだが、現在は「k」を向いているらしい。おそらくもともとの母数が少ない上にみんなsoftbank.ne.jpにメールアドレスを変更しているところなので、メールサーバを集約しているのだろう。

まあ、それはいいとして、ttlが短いのがすごく気になる。普通、クライアントの数も相当なものだから、キャリアのMXレコードなんてそれなりの長さに設定しているはずだ。大丈夫なんだろうか。

今回の件は、おそらく旧メールサーバを廃止してどこかに統合する際に、IPアドレスが変更になる場合は普通は旧サーバを残して単純に新サーバにリレーするようにしてくれればいいだけなのを、一気に切り替えてしまって、DNS情報の更新が浸透する前に旧サーバが消えてなくなってしまった状態になったのだろう。で、宛先不明のIPアドレスについては一定期間までレジストラがキープしてくれているだろうから、そっちを向いてしまっていたといったところか。

いずれにせよ間抜けな話だし、おまけに少なくともこの１、2ヶ月くらいは同じミスをちょこちょこやっていそうなので、なおさらひどいものである。

May - 24th

携帯端末の404 Not found対策

Posted at 10:24 pm | Filed Under Apache, mobile

携帯端末の場合、サーバからステータスコード404が返ると、サーバ側のエラー画面を表示するのではなく処理を中断してしまうことがある（少なくともauではそうなった）ので、.htaccessでの制御で工夫しなければいけない。

普通、ステータスコード別に表示するHTMLドキュメントを指定する場合は

ErrorDocument 404 /error.html

のようにErrorDocumentディレクティブを利用する。しかし、ここで指定するのがローカルファイルへのパスの場合、ステータスコードはそのまま404を返してしまうため、携帯端末だとページを表示する前に処理が中断され、指定したドキュメントを表示させることができない。

解決方法は簡単で、

ErrorDocument 404 http://selfkleptomaniac.org/error.html

のようにリモートのURLを指定すると、この場合は404ではなくリダイレクトの302が返るため、携帯でも問題なく表示することができる。Apacheのマニュアルでは

リモート URL (例えば、頭に http と付与した方法) を ErrorDocument に指定するとき、たとえ文書が同じサーバにあろうとも、ドキュメントがどこにあるかを通知するために、 Apache はリダイレクトをクライアントに送出するということに、注意してください。これにはいろいろと関連して起こる問題があります。中でも最も重要なのは、クライアントは元々のエラーステータスコードを受け取らず、代わりにリダイレクトのステータスコードを受け取るということです。これにより、ステータスコードを使って URL が有効であるかどうかを決定しようとするウェブロボットやその他クライアントを、混乱させるかもしれません。さらに、ErrorDocument 401 にリモートの URL を指定すると、クライアントは 401 というステータスコードを受け取らないため、パスワードをユーザーに入力要求しなければならないことがわかりません。従って、ErrorDocument 401 というディレクティブを使う場合は、必ずローカルな文書を参照しなければなりません。

とのこと。