3

ajax を多用する Rails アプリケーションがあります。jQueryで。たとえば、モデルの 1 つが完全に jQuery で管理されています。レコードは ajaxly で作成、更新、削除されます。レコードの更新を除いて、すべてがうまく機能します。

いくつかのテストを行ったところ、Firefox の jQuery (Mac では 3.6、Windows では 3.5 をテストしたもの) には、同じ URL に 302 リダイレクトされたときにサーバーの応答を検出する際に問題があることがわかりました。私がFirebugで得たものは次のとおりです。

POST localhost:3000/resources/1 -> 302 が見つかりました

GET localhost:3000/resources/1 -> 200 OK

また、jQuery の ajax コールバックは呼び出されません。成功でも、完了でも、エラーでもありません。しかし、レコードを作成し、サーバーが別の URL にリダイレクトされると、「成功」コールバックが呼び出されます。

POST localhost:3000/resources -> 302 が見つかりました

GET localhost:3000/resources/1 -> 200 OK

$.ajax を自分で呼び出すか、jquery.form の ajaxForm() を使用するかは問題ではありません。

何か案は？

4

1 に答える 1

1

301/302/303 リダイレクトは、jQuery ではなく、ブラウザーの XmlHttpRequest ハンドラーによって行われます。これは、成功のコールバックがない理由を説明していません。しかし、リダイレクトが ajax 側で十分にテストされていない理由を説明できるかもしれません。

問題の 1 つは、一部のブラウザーが 302 に従っていることです。たとえば、301 または 303 リダイレクトではありません。古いアプリケーションでは、303 see-other 応答コードを使用し、エラー ハンドラで処理していました。これは、ブラウザの代わりに新しい GET リクエストを実行できたので良かったです (ブラウザにはバグがあり、実行する必要がありました)。

しかし、ブラウザによっては問題がありました（確かではないと思います）。

あなたが持っている 302 応答の動作を見たとき、私たちが行ったことを行うべきだと思います: ajax requests のポスト処理の後にリダイレクトを削除します。必要な最終 HTML (リダイレクト サーバー側) を応答で送信するか、JSON キーでプロトコル ステータスを送信する独自​​のプロトコル (JSON に基づく?) と、確認する新しい URL を送信します。別のキーなどの新しい応答用。

于 2011-01-07T23:57:10.263 に答える