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に挿しても使用することはできません。
・SoftBank3Gへ戻す場合には、USIMカード交換(有償)が必要となります。
確かに実機で検証するとこんなエラー画面になる。
ここまではSoftBankの説明どおりである。
実にけしからん。iPhoneなんかやめた、と思い切って他の端末を友達から安く買ったという人はいったいどうすればいいのか。消費者の見地からこれは実に見過ごせない由々しき問題である。
ところで、SoftBankといえばその前身はVodafoneである。
SoftBank3Gではだめだというなら、ではVodafoneならどうなのだろう。誰もがそんなことを思うことには疑いの余地はない。
というわけでさっそく実験。iPhone 3GのUSIMカードを取り出して適当なVodafone 3Gの端末に入れて起動してみる。
起動した。となりの黒い箱は犠牲となったiPhone。
起動しただけかもしれないのでさっそく電話する。
通話できた。
ちなみにSIMロックが解除されたヤクザな携帯端末もちゃんと起動する。
もちろん、iPhone 3GのSIMロックを解除したわけではないので、念のため。第一、iPhone 3G専用をうたっているあのSIMカードは、そもそもiPhone 3Gを買った人じゃないと手に入らないので、何かの犯罪を教唆しているわけでもない。
あ、パケット通信はできないよ。
あと、番外編としての豆知識。
1 iPhone3Gは電源が入ったままSIMカードを抜いても大丈夫だった。
2 SIMカードをドックの口に挿す人間は必ずいる。
3 iPhone 3GとかSIMロック解除とかいうキーワードはすさまじくSEO効果が高い。
何かを勘違いしてアクセスしてきた人たちにはサービス画像。
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アドレスについては一定期間までレジストラがキープしてくれているだろうから、そっちを向いてしまっていたといったところか。
いずれにせよ間抜けな話だし、おまけに少なくともこの1、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 というディレクティブを使う場合は、 必ずローカルな文書を参照しなければなりません。
とのこと。
Feb - 19th
NDA
Posted at 11:08 pm | Filed Under mobile
携帯電話向けのウェブアプリケーション開発は、PC向けと違って対応するブラウザの挙動の違いからものすごい数のバッドノウハウがある。
世の中の開発者たちとその情報を共有して、もっと面白いサービスが登場するのを期待したいのだけれども、そういったバッドノウハウはみんなNDAで保護されているため、うかつに公開することが出来ない。
今日も、喉から(指先から)出掛かっている情報があるのだが、やっぱり書けない。
ケータイの世界がどんどん収縮して、端末の性能がPCと遜色なくなって、サービスも同等のものが提供される世の中はもうすぐそこまで来ているのに、ケータイの世界はこうして自滅を待つばかりだ。
Oct - 22nd
R.I.P. HDML
Posted at 6:26 pm | Filed Under mobile
これで正式にHDMLを利用したサービスが消滅する。
Sep - 10th
SoftBank殺し
Posted at 6:56 pm | Filed Under mobile
SoftBankから通達があり、パケット通信中に端末に何らかのパケットが送信された場合、そのパケットも通信量として加算されるとのこと。
「パケットし放題」は上限9,800円だが、IPアドレス指定でpingを打ちまくられると「PCサイトダイレクト」の対象になるので上限がちょっと上がって10,290円になる。
Jun - 25th
D01HWのパフォーマンス
Posted at 2:31 pm | Filed Under mobile
D01HWのパフォーマンスをgooスピードテストで計測。
六本木近辺での計測結果は1.47Mbps〜1.37Mbps。結構な数値だった。
Apr - 10th
em oneをMac BookのBluetoothモデムに
Posted at 11:42 am | Filed Under Apple, Tuit, mobile
同じような記事があったけど、手元のログをまとめておく。
em one側の設定は特になさそうなので、Mac Book側の設定を。
(1)「システム環境設定」から「Bluetooth」を選択
このスクリーンショットではもうem oneは設定済み
(2)「新規デバイスを設定」を選択
「続ける」を選択して2番目の画面では、とりあえず「任意のデバイス」を選んだ。
(3)em oneが検出されるので、「続ける」を選択して、Mac Bookとem oneの間でのパスフレーズを設定する。ここで設定したパスフレーズは忘れないこと。
(4)「システム環境設定」から「ネットワーク」を選択、表示は「Bluetooth」を選択
サービスプロバイダは適当に、アカウント名は「em」、パスワードは先程(3)で設定したパスフレーズを入力する。電話番号はなぜか「*99***1#」で。
モデムの機種を選択する。I-O DATA USB-CFADPで問題なく動作するので、こちらを選択。
以上で設定が完了する。「PPP」タブから「今すぐダイヤル」ボタンを選択すれば接続アシスタントが立ち上がる。








