海外製携帯電話が日本のケータイサイトに対応しない、歴史的事情

Vodafone/SoftBank 3G の海外製携帯電話(SAMSUNG 製を除く)が日本のケータイサイトに対応しないことを、日本では見過ごされがちな歴史的事情を絡めて語ります。

まず歴史のおさらいから。海外の携帯電話向けウェブは、HDML が作られた後、標準化団体を作ってから端末メーカと携帯電話キャリアがサービスに反映させる方法で開発されてきました。WAP Forum が WAP サービスを定義して WML というマークアップ言語でサービスされましたが、PC 向けウェブと違いすぎたために CP が増えませんでした。そこで 2001 年の WAP 2.0 では XHTML Mobile Profile + Wireless CSS を定義して、PC 向けウェブに近いものにしました。後に WAP Forum は Open Mobile Alliance と改称しました。

日本のウェブ開発者から見過ごされがちなのは、HTML が携帯電話向けにサービスされたことがないという点です。WML から、いきなり XHTML + CSS に変更されたからです。

海外製携帯電話にとって、HTML の対応がどうのというより、HTML は PC 向けウェブの証なんです。携帯電話向けウェブは WML か XHTML + CSS のどちらかなのですから。

そのため、HTML で作成された日本のケータイサイトでは、font タグへの対応が悪かったり、PC サイト対応モードに入ってしまったりします。

では、海外製携帯電話は切り捨てるしかないかというと、ウェブサイト管理者から見れば意外なところでやりようはあります。SoftBank 3G 端末は XHTML Mobile Profile + Wireless CSS サポートを継続しています。海外製携帯電話向けウェブサイトをまだ表示できます。すると SoftBank 3G 専用に限れば XHTML + CSS でもサービスできます。

日本から見るか海外から見るかで見え方が違ってきて、苦しくて、面白い話です。

参考サイト

• Forum Nokia - Light Browsing
• SoftBank Developers Support Site からウェブ技術資料

HTTP : GET と POST の知られざる違い

HTTP の GET メソッドと POST メソッドについて、改めて書きたいことがあります。定義の中のある箇所が世間では軽視されているように思うのです。

Wikipedia に簡潔かつ正確に解説されている話ですが、ここで改めて解説を。
http://ja.wikipedia.org/wiki/%E5%86%AA%E7%AD%89#WWW

HTTP 1.1 の通信手順・動作を定義している RFC 2616 http://www.ietf.org/rfc/rfc2616.txt に「9.1.2 Idempotent Methods」という節があります。

"Idempotent" の形容詞 "Idempotence" とは「N(>0)回実行された際の副作用が、1回のみ実行された際の副作用と同じ」と定義されています。平たく言うと、1回目の実行で何か変化が起きる(かもしれない)のですが、2回目以降の実行では変化が起きないという意味です。日本語では「冪等」と訳されます。これは数学用語で、一般の英和辞典には見つかりません。

RFC 2616 では GET、HEAD、PUT、DELETE が Idempotent Methods であり、また OPTIONS、TRACE は副作用を持つべきではないと定義しています。裏を返すと POST は Idempotent Methods ではありません。

この定義はブラウザやプロキシサーバのキャッシュに影響します。2回目以降に変化が起きないリクエストは、キャッシュを使って回数を減らして構いません。リクエストの度に変化が起きるメソッドは、キャッシュを使って回数を減らすと結果が変わってしまいます。

つまり GET メソッドの結果はキャッシュしてもいいですが、POST メソッドの結果はキャッシュしてはいけません。

Web プログラミングに詳しい人なら、GET メソッドの度に状態を変化させるプログラムを CGI/PHP 等で作れることを知っているでしょう。アクセス回数を数えるアクセスカウンタはそうして作られています。文書で決めることに意味がないと考える方もいらっしゃるかもしれません。

しかし GET と POST の違いを決めておくことに意味があります。目的に応じて使い分ける基準になります。さらには、世に広まっているブラウザやプロキシサーバのキャッシュはこの定義に従って実装されているので、Web アプリを開発する際に定義に逆らうとキャッシュ制御でトラブルを起こしやすいんです。

キャッシュして欲しいデータを POST で取得するようにプログラミングするとキャッシュが効かなくて困るようになります -よくある「フォームの期限切れ」- し、キャッシュされては困るデータを GET で取得するようプログラミングするとキャッシュの無効化を考えなければなりません。アクセスカウンタは HTML に埋め込みたいので GET メソッドで取得しますが、キャッシュの動作から考えると例外的です。

キャッシュのコントロールを考えたときに、GET と POST を使い分けてキャッシュの動作を変える方法もあるのです。