jQueryAjaxリクエストは送信されずにキャンセルされます

スクリプトをMicrosoftのWorld-WideTelescopeアプリに接続しようとしています。後者はポート5050でコマンドをリッスンします。ブラウザと同じマシンで実行されています（現在Chromeですが、私が知る限り、動作はFirefox7とIE9で同じです）。

問題としてXSS制限を排除するために、元のhtmlファイルを含む「Access-Control-Allow-Origin：*」ヘッダーを送信しています。

WWTにアクセスするための私のコードは次のとおりです。

$.ajax({
    type: 'POST',
    url: url,
    data: data,
    crossDomain: true,
    success: success,
    dataType: dataType
});

この場合のURLは「http：//127.0.0.1：5050 / layerApi.aspx？cmd = new＆...」です（明らかに...ここではいくつかの追加パラメーターの省略形です）。

Chromeのネットワーク診断を見ると、次のことがわかります。

Request URL:http://127.0.0.1:5050/layerApi.aspx?cmd=new&...
Request Headersview source
Accept:application/xml, text/xml, */*; q=0.01
Content-Type:application/x-www-form-urlencoded
Origin:http://gwheeler4
Referer:http://gwheeler4/conceptconnect.html
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.835.186 Safari/535.1

リクエストは送信されます-WWTが新しいレイヤーを作成しているのがわかります。ただし、コールバックがありません。呼び出されるエラーコールバックを追加したが、jqXHRオブジェクトのerrorプロパティが「error」でステータスが0の場合。Chromeでネットワークリクエストを見ると、ステータスとして「（cancelled）」が表示され、応答がありません。 。

同じURLを取得して新しいブラウザタブに貼り付けると、応答が期待されるXMLであることがわかります。

もちろん、ここでの違いは、これがPOSTではなくGETであるということですが、スクリプトで試してみましたが、違いはありません。

私はこれにかなり困惑していて、どんな新鮮なアイデアでもありがたいです。

他の誰かがこれに遭遇した場合、私たちが抱えていた問題は、リンクからajaxリクエストを行っていて、リンクのフォローを妨げていないことでした。したがって、onclick属性でこれを行う場合は、必ずそうしreturn false;てください。

Chromeを使用している場合、(canceled)リクエストの根本原因を特定するのに十分な情報が標準のChromeネットワークパネルに表示されません。

chrome://net-internals/#events送信するリクエストの厄介な詳細を表示するを使用する必要があります-非表示のリダイレクト/送信されるCookieに関するセキュリティ情報などを含みます。

たとえば、以下は、ネットワークトレースに表示されなかったリダイレクトを示しています。これは、Cookieがサブドメイン間で送信されなかったことが原因です。

t=1374052796448 [st=  1]   +URL_REQUEST_START_JOB  [dt=261]
                            --> load_flags = 143540481 (DO_NOT_SAVE_COOKIES | DO_NOT_SEND_AUTH_DATA | DO_NOT_SEND_COOKIES | ENABLE_LOAD_TIMING | MAYBE_USER_GESTURE | REPORT_RAW_HEADERS | VALIDATE_CACHE | VERIFY_EV_CERT)
                            --> method = "GET"
                            --> priority = 2
                            --> url = "https://...."
...
t=1374052796708 [st=261]        HTTP_TRANSACTION_READ_RESPONSE_HEADERS
                                --> HTTP/1.1 302 Moved Temporarily
                                    Content-Type: text/html
                                    Date: Wed, 17 Jul 2013 09:19:56 GMT
...
t=1374052796709 [st=262]     +URL_REQUEST_BLOCKED_ON_DELEGATE  [dt=0]
t=1374052796709 [st=262]        CANCELLED
t=1374052796709 [st=262]   -URL_REQUEST_START_JOB
                            --> net_error = -3 (ERR_ABORTED)

私の場合type='submit'、フォームを送信するときに、ajaxヒットが発生する前にページが再読み込みされていたので、簡単な解決策がありましたtype="button"。タイプを指定しない場合はsubmitデフォルトであるため、指定する必要がありますtype="button"

type='submit' => type='button'

または

タイプなし=> type='button'

私も同様の問題を抱えていました。私の場合、Apacheサーバー+ djangoでWebサービスを使用しようとしています（サービスは自分で作成しました）。私はあなたと同じ出力を持っていました：FFがそれを大丈夫にしている間、Chromeはそれがキャンセルされたと言います。ajaxではなくブラウザで直接サービスにアクセスしようとすると、それも機能します。調べてみると、いくつかの新しいバージョンのapacheが応答ヘッダーで応答の長さを正しく設定していないことがわかったので、これを手動で行いました。djangoで、私がしなければならなかったのは：

response['Content-Length'] = len(content)

アクセスしようとしているサービスを制御できる場合は、使用しているプラ​​ットフォームの応答ヘッダーを変更する方法を確認してください。変更しない場合は、サービスプロバイダーに連絡してこの問題を修正する必要があります。どうやら、FFや他の多くのブラウザはこの状況を正しく処理できますが、Chromeの設計者は指定どおりに処理することにしました。

同様の問題がありました。chrome：// net-internals /＃eventsを使用すると、問題の原因がサイレントリダイレクトであることがわかりました。私のgetリクエストはonloadスクリプトで実行されていました。URLは「http://example.com/inner-path」の形式で、301は「/ inner-path」に永続的にリダイレクトされていました。この問題を修正するために、URLを「/ inner-path」に変更したところ、問題が修正されました。1週間前に機能したスクリプトが突然問題を引き起こした理由は、まだわかりません...これが誰かに役立つことを願っています

（WebフォームASP.NETを使用）

私の問題は、サーバー側のクリックイベントが設定されている送信ボタンのクリックイベントからAjaxを起動しようとしていたことでした。ボタンを単純なボタンにする必要がありました（つまり<input type="button">）

同じ問題が発生しました。一時的にiframeを作成し、ajaxが完了する前にiframeを削除していたため、ブラウザーがajaxリクエストをキャンセルしていました。

@Kazetsukaiの回答を拡張すると、ユーザーからリンクをクリックしてAJAXリクエストを行う場合に、この問題が発生する可能性があります。

次のようにリンクを設定した場合：

<a href="#" onclick="soAjax()">click me!</a>

そして、次のようなjavascriptハンドラー：

soAjax() {
    $.ajax({ ... all your lovely parameters ... });       
}

ブラウザがリンクをたどって進行中のリクエストをキャンセルしないようにするには、クリックイベントの伝播を追加return falseまたはe.preventDefault()停止する必要があります。

soAjax() {
   $.ajax({ ... etc ... });
   return false;
}

または：

soAjax(e) {
   $.ajax({ ... etc ... });
   e.preventDefault();
}

AJAXリクエストがドロップされた場合（クロスオリジンリクエストでない場合）、2つの可能性があります。

1. イベントに対する要素のデフォルトの動作を妨げているわけではありません。
2. AJAXのタイムアウトの設定が低すぎるか、ネットワーク/アプリケーションのバックエンドサーバーが低速です。

1）の解決策：追加return false;またはe.preventDefault();イベントハンドラーにます。

2）の解決策：AJAXリクエストの形成中にタイムアウトオプションを追加します。以下の例。

$.ajax({
    type: 'POST',
    url: url,
    timeout: 86400,
    data: data,
    success: success,
    dataType: dataType
});

クロスオリジンリクエストの場合は、クロスオリジンリソースシェアリング（CORS）HTTPヘッダーを確認してください。

httpsを必要とするURLにhttpを使用してリクエストを行うと、このエラーが発生しました。ajax呼び出しはリダイレクトを処理していないと思います。これは、crossDomain ajaxオプションがtrueに設定されている場合でも当てはまります（JQuery 1.5.2の場合）。

私の場合、Apacheのmod-rewriteはURLと一致し、リクエストをhttpsにリダイレクトしていました。

chrome：// net-internals /＃eventsでリクエストを確認してください。

リクエストの内部ログが表示されます。リダイレクトを確認します。

私も同じ問題を抱えていましたが、私の場合はCookieの問題であることが判明しました。バックエンドで作業している人たちは、アプリにログインしたときに設定されるJSESSIONID Cookieのパスを変更しました。私は、その名前の古いCookieをコンピューターに持っていましたが、古いパスを使用していました。そのため、ブラウザ（Chrome）にログインしようとすると、値の異なるJSESSIONIDという2つのCookieがサーバーに送信されたため（当然のことながら混乱しました）、リクエストがキャンセルされました。私のコンピュータからクッキーを削除すると、それが修正されました。

私はもっ​​と不気味な方法でこのエラーを抱えていました：jsが完了した後、ネットワークタブとchrome：// net-internals /＃eventsはリクエストを表示しませんでした。エラーcallcackでjsを一時停止すると、[ネットワーク]タブにリクエストが（キャンセル済み）として表示されました。は一貫して、Webページ内のいくつかの同様のリクエストのうちの1つ（常に同じ）を要求されていました。Chromeを再起動した後、エラーは再び発生しませんでした！

私がいたFirefoxでキャンセル。いくつかのajax-callは私にとっては完全にうまく機能しましたが、実際にそれを使用しなければならなかった同僚にとっては失敗しました。

上記のChromeのトリックでこれを確認したところ、疑わしいものは何も見つかりませんでした。Firebugでチェックすると、2回の悪意のある呼び出しの後に「読み込み中」のアニメーションが表示され、結果タブは表示されませんでした。

解決策は非常に簡単でした。履歴に移動し、Webサイトを見つけて、右クリック-> Webサイトを忘れます。
削除するのではなく、忘れてください。

その後、問題はなくなりました。私の推測では、それは.htaccessと関係があります。

私の場合、それはURLに欠落している末尾のスラッシュでした。末尾にスラッシュを追加すると、問題が解決しました。

Dropzone.jsの場合。私の場合、これはtimeoutオプション値がデフォルトで低すぎることが原因でした。だからあなたの必要に応じてそれを増やしてください。

{
// other dropzone options
timeout: 60000 * 10, // 10 minutes
...
}

特定の3Gネットワ​​ークでこの問題が発生しました。chrome：// net-internals /＃events
でのDELETEリクエストでは常に失敗しnet_error = -101ます。

他のネットワークは問題なく動作したので、プロキシサーバーなどに障害があったと思います。