prototype.jsを使ったAjaxの落とし穴

ちょっとカテゴリを変えてWebプログラムということで今回はAjaxのライブラリであるprototype.jsを使った時に起こったことについてです。

prototype.jsでWebのアクセスを行うとメソッドが「GET」でも「POST」でもない「OPTIONS」になることがある

簡単にデバッグができるFirefox側での検証で起こった出来事です。

prototype.jsを使って通信を行った時に、取得方法になぜか「OPTIONS」という方法が使われていました。

これによってはまることがあるのが、GoogleMapsAPIのようにGETしか受け付けない(GET以外なら拒否する)もので

prototype.jsを直接使おうとした時に問題が発生します。

これの原因がsetRequestHeadersという関数の処理にあります。これは必要なオプションを通信前に設定するという処理なのですが、

デフォルトで設定されるオプションが設定されることでブラウザ側の通信がGETからOPTIONSに切り替わるようなのです。

(送信ヘッダの中に一応通信方法はGETである、という文がありますが、これはhttpとしてみた時に無視してもよい設定なので意味ないです)

解除するにはこの部分の送信を解除する(コメントアウトで無効にする)位しかないと思います。

ブラウザによってクロスドメインのアクセス禁止の動作が違うらしい

Ajaxを使おうとしてよく忘れるのが、「クロスドメインで通信を行うとブラウザによってエラーとなる」ことですが・・・

これらの動作がブラウザによって異なるようです。今のところIE8とFirefoxでしか確認していませんが・・・。

IE8でのクロスドメイン

クロスドメインでのXMLHttpRequestを発行しようとすると、URLを設定した時点でエラーとなりJavaScript処理例外が発行されます。

デバッグではXMLHttpRequest.openを呼び出した段階で即座に停止してエラーコードがOSに通知される(アクセス禁止のエラーコード)のでわかりやすいかもしれません。

Firefoxでのクロスドメイン

なんかクロスドメインによるアクセスの禁止が発行されていない・・・というよりはレスポンスを確認して・・・という処理になっているようです。

GoogleMapsAPIで試していたのでちょっとよくわからないのですが、今回はresponseTextが戻ってきていないという形で現れた可能性があるかな~と思っています。

クロスドメインが原因なのか、gzipで戻ってきているから展開できていないだけなのかがよくわかっていません。

しかし、本当にJavaScriptのエラーってよくわからないですね。

ブラウザ依存でもあり、サーバー依存でもあるようなバグが出てくる上にデバッグが恐ろしくしづらいですからね。

IE8とかFirefox3とかになると、すでに組み込まれていたり使いやすいプラグインがあったりとましなのですが・・・。

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

この記事のトラックバック用URL