XMLHttpRequest (XHR)は、ブラウザのセキュリティ制限のため、本来は表示中の HTMLと同じドメイン上にあるXMLやテキストファイルにしかアクセスできません。 JavaScript だけでは、他のドメイン上にあるファイルや、はてな・ライブドア等が 提供するウェブサービスにアクセスできませんでした。 しかし、JavaScriptライブラリDojoの新機能を使うと、ドメインを越えた通信が できるようになるそうです。 従来、クロスドメイン制限については以下のような回避策も考えられてきましたが、 どれも短所があって、イマイチ使いにくいところがありました。 ・HTMLを設置しているドメインのサーバ上にプロキシCGI等を設置する 　　　→オープンプロキシ（誰でも利用できてしまう。掲示板の匿名投稿にも悪用可能） ・FLASHのクロスドメイン通信の機能を経由させる 　　　→JavaScriptからFLASHを呼び出す必要がある ・接続先ウェブサービス側の出力フォーマットに JavaScript を追加する 　　　→データでなくJavaScriptプログラムを返す。グローバル変数を書き換える。 Dojoの新しい手法はIFrameを複数使うことで、JavaScriptのみでクロスドメインの 通信に対応するものです。 ＜サーバA上の親ページから、サーバB上のウェブサービスにアクセスする手順＞ １）　親ページ内に、1つ目のIFrame（クライアントIFrame）を作成する。 ２）　クライアントIFrameから2つめのIFrame（サーバIFrame）を作成する ３）　親ページからクライアントIFrameにXHRリクエスト用のデータを送信する ４）　クライアントIFrameは、サーバIFrameに同データを転送する ５）　サーバIFrameは、サーバB上のウェブサービスにXHRで接続する ６）　サーバIFrameは、受け取ったXHRレスポンスをクライアントIFrameを経由して、 　　　親ページに返す まとめると、↓のようなデータの流れになります。 親ページ　←→　クライアントIFrame　←→　サーバIFrame　←XHR→　ウェブサービス クライアントIFrame用のHTMLファイルはサーバA上に、 サーバIFrame用のHTMLファイルはサーバB上に予め用意しておきます。 項番５でサーバBのウェブサービスにアクセスしているのは、サーバB上にある HTMLファイルとなるので、XHRのクロスドメイン制限に抵触しないのです。 間にIFrameをカマすことで、親ページから見ればドメインを越えた通信ができます。 この仕組みのポイントは、IFrame間のデータの受け渡しに fragmentIdentifier を 利用している点です。fragmentIdentifier とは、ブラウザの管理しているURLのうち、 http://www.a.com/path/to/file.html#fragmentIdentifier の「#」以降の部分です。<a name="">で定義する部分ですね。 XHRのリクエスト（URL＆POSTのボディを含むXHRのすべてのオプション）や レスポンスのデータ長はブラウザによる fragmentIdentifier の長さ制限を 越えてしまう場合があるため、長い場合は複数回に分けてデータの受け渡しを 行うそうです。fragmentIdentifier を通信路としたプロトコルと読べると思います。 ＜欠点＞ １）複数のIFrameを利用するため、ネイティブの XHR よりもブラウザのメモリを消費する ２）fragmentIdentifierを監視するためにタイマを使うため、その分遅くなる ３）IEに限っては、fragmentIdentifier 通信の度に、マウスクリック音がしてしまう ４）アクセス先のウェブサービス側に、サーバIFrameのコードが必要となる メモリを多く使っても、多少遅くなっても、ネイティブXHRで通信できるのは メリットがありますから、大きな問題にはならないでしょう。 しかし、３のIEでクリック音がするのは、残念です。リンク移動した扱いになるようです。 これが回避できれば、現実的になってくるのですが。 ４については、FLASHでもcrossdomain.xmlの設置が必要ですから、同等か。 逆にウェブサービス側のサーバ上に設置できることで、クライアントIFrame〜 サーバIFrame間の通信もデータだけ・特定目的だけに限定できて安心です。 とてもよく考えられたテクニックだと思います。 fragmentIdentifier 以外にも、他に IFrame間で双方向通信を行える手順があれば クリック音を回避できるのですが。IEで使いにくいのでは、まだ実用化は難しいか。。。

<< 前記事（2006/07/25）

トップへ

後記事（2006/08/06）>>

<< 前記事（2006/07/25）

トップへ

後記事（2006/08/06）>>