5

私の質問に対するほとんどのグーグル回答が構成されているため、これはクロスサイトリクエストの問題ではありません。

jquery 関数 .get および .load で ajax リクエストを作成しようとすると、xhr.status 0 och xhr.statusText "error" が発生します。ただし、Firebug では、要求されたページが html ステータス コード 200 で読み込まれます。応答のテキストを読み取ることができ、応答ヘッダーは正常に見えます。

私のコード:

  function GetProjectTask(e) {
    var loader = $('#' + e + 'tasks div.loader');
    var content = $('#' + e + 'tasks div.content');
    var img = $('#' + e + 'tasks img.collapseimg');
    if (loader.html() == null || loader.html().trim() == '') {
        if (content.html() == null || content.html() == '') {
            img.attr('src', 'images/expanded.gif');
            loader.html('<img src="images/loading.gif" alt="Wait..."> Loading support tasks');
            content.load('includes/my' + e + 'tasks.php',
                function (response, status, xhr) {
                    if (status == "error") {
                        var msg = "Sorry but there was an error: ";
                        alert(msg + xhr.status + " - " + xhr.statusText);
                    }
                }
            );
            return;
        }
    }
    content.empty();
    loader.empty();
    img.attr('src', 'images/collapsed.gif');
  }

サーバー: IIS v.7.5 Jquery: v1.6.2

何か案は？

4

2 に答える 2

10

ステータスコードがゼロの場合、多くの意味があると思います。私の場合、要求と応答のサイクルが完了する前にユーザーがページを離れたため、ステータスコード0を受け取っていました。サーバーとの通信に失敗した場合も、ステータスコードがゼロになる可能性があります。私は基本的にこれを送信者からのアウトバウンド通信の失敗として要約しました。そのため、クロスサイトリクエストやクライアント側を扱うその他の理由も考えられます。

W3 XMLHttpRequest仕様のセクション4.8.1には、次のように記載されています。

status属性は、これらのステップを実行した結果を返す必要があります。
状態がUNSENTまたはOPENEDの場合は、0を返し、これらのステップを終了します。
エラーフラグが設定されている場合は、0を返し、これらの手順を終了します。
HTTPステータスコードを返します。

仕様を正しく読んだ場合、UNSENTとOPENEDは、リクエストが送信される前に存在できる状態です。また、次の場合にエラーフラグが設定されます。

エラーフラグは、ある種のネットワークエラーまたは要求の中止を示します...

このステータスコードで私が抱えている問題は、リクエストがユーザーによってナビゲートされて中止された場合、これはユーザーによる意図的なアクションであるため、エラー状態とは見なさないことです。ネットワークの問題私はエラーと見なします。たとえば、ユーザーがアクションを呼び出した場合、エラーハンドラーを持つajaxリクエストが発生し、エラーページにリダイレクトされます。ユーザーが現在のページを離れてリクエストを中止した場合、使いやすさの観点から、ユーザーをエラーページにリダイレクトすることは意味がありません。仕様の実装は問題ありませんが、ステータスコード0が中止された要求またはその他の理由によるものであることを知る方法をまだ決定していません。違いがわかれば、適切な対応ができると思います。

編集：2014年3月18日

2013年8月9日の@arieraのコメントに応えて、回避策の大まかな説明を提供します。しかし、問題は私がこれを解決してからしばらく経ち、私の記憶が曖昧であるということです。

私の記憶が正しければ、ステータスコード0がユーザーによるリクエストの間接的な中止によるものかどうかを判断するためのアイデアは、エラーコールバックとは別の独自のコールバックにエラー処理コードを配置することでした。次に、エラーコールバックで、ステータスコードがゼロかどうかを確認します。そうである場合は、タイムアウト遅延でエラーコールバックを呼び出します。そうでない場合は、エラーコールバックを呼び出します。ここでの考え方は、エラーコードがゼロの場合、そのエラーの処理を遅らせることで、ブラウザが実際にナビゲーションを実行できるようにすることです。ブラウザにナビゲーションの実行を許可すると、実行中のJavaScriptがすべてクリアされるため、エラーハンドラは起動しません。

さて、これは応急修理であり、再び機能しないかもしれません。問題の複雑さを本当に覚えていませんが、うまくいけば、他の誰かを正しい道に導くことができます。

于 2012-01-27T19:18:35.400 に答える
3
于 2012-01-12T11:19:22.683 に答える