460

ページがキャンセルされる原因は何ですか？Chromeデベロッパーツールのスクリーンショットがあります。

キャンセルされたリソース

これは頻繁に発生しますが、毎回発生するわけではありません。他のリソースがキャッシュされると、ページの更新によってLeftPane.aspxが読み込まれるようです。そして、本当に奇妙なのは、これがInternet Explorer8ではなくGoogleChromeでのみ発生することです。Chromeがリクエストをキャンセルする理由はありますか？

4

34 に答える 34

683

Chromeがフレームまたはiframe内に物をロードするリクエストをキャンセルするという同様の問題と戦いましたが、断続的にしか発生せず、コンピューターやインターネット接続の速度に依存しているように見えました。

この情報は数か月前のものですが、Chromiumを最初から作成し、ソースを調べてリクエストがキャンセルされる可能性のあるすべての場所を見つけ、すべての場所にブレークポイントを設定してデバッグしました。メモリから、Chromeがリクエストをキャンセルする唯一の場所：

  • 要求が行われる原因となったDOM要素が削除されました（つまり、IMGがロードされていますが、ロードが発生する前に、IMGノードを削除しました）
  • データの読み込みが不要になるようなことをしました。（つまり、iframeの読み込みを開始してから、srcを変更するか、内容を上書きします）
  • 同じサーバーに送信されるリクエストが多数あり、以前のリクエストのネットワークの問題により、後続のリクエストが機能しないことが示されました（DNSルックアップエラー、以前の（同じ）リクエストの結果、HTTP 400エラーコードなど）

私たちの場合、最終的に、HTMLを別のフレームに追加しようとしている1つのフレームまで追跡しました。これは、宛先フレームがロードされる前に発生することがありました。iframeのコンテンツに触れると、リソースをiframeにロードできなくなるため（どこに配置するかをどのように知ることができますか？）、リクエストがキャンセルされます。

于 2012-11-19T17:34:50.890 に答える
67

status = canceledは、JavaScriptイベントのajaxリクエストでも発生する可能性があります。

<script>
  $("#call_ajax").on("click", function(event){
     $.ajax({
        ...    
     });
  });
</script>

<button id="call_ajax">call</button>

イベントは正常にリクエストを送信しますが、その後キャンセルされます（ただし、サーバーによって処理されます）。その理由は、同じクリックイベントでajaxリクエストを行ったかどうかに関係なく、要素はクリックイベントでフォームを送信するためです。

リクエストがキャンセルされないようにするには、JavaScriptevent.preventDefault();を呼び出す必要があります。

<script>
  $("#call_ajax").on("click", function(event){
     event.preventDefault();
     $.ajax({
        ...    
     });
  });
</script>
于 2014-06-05T13:55:42.277 に答える
39

注意：ラッピングフォーム要素がないことを確認してください。

onclick={}のボタンがフォーム要素でラップされているという同様の問題がありました。ボタンをクリックすると、フォームも送信され、それがすべてを台無しにしました...

于 2016-09-22T13:00:15.933 に答える
15

注意すべきもう1つのことは、AdBlock拡張機能、または一般的な拡張機能です。

しかし、「多くの」人々がAdBlockを持っています。

拡張機能を除外するには、シークレットモードで新しいタブを開き、テストする拡張機能の「シークレットモードでの許可がオフになっている」ことを確認します。

于 2013-10-16T10:53:38.390 に答える
14

私の場合、それはjqueryグローバルタイムアウト設定であり、jqueryプラグインはグローバルタイムアウトを500msに設定しているため、リクエストが500msを超えると、chromeはリクエストをキャンセルします。

于 2013-07-04T04:32:22.637 に答える
12

「X-Frame-Options」ヘッダータグを確認することをお勧めします。SAMEORIGINまたはDENYに設定されている場合、iFrameの挿入は、仕様に従ってChrome（および他のブラウザー）によってキャンセルされます。

また、一部のブラウザはALLOW-FROM設定をサポートしていますが、Chromeはサポートしていないことに注意してください。

これを解決するには、「X-Frame-Options」ヘッダータグを削除する必要があります。これにより、クリックジャッキング攻撃を受けやすくなる可能性があるため、リスクとは何か、およびそれらを軽減する方法を決定する必要があります。

于 2013-06-12T21:19:12.370 に答える
9

これが私に起こったことです：サーバーは302リダイレクトのために不正な形式の「Location」ヘッダーを返していました。もちろん、Chromeはこれを教えてくれませんでした。Firefoxでページを開いたところ、すぐに問題が見つかりました。複数のツールがあるのはいいですね:)

于 2013-06-25T20:01:57.713 に答える
6

ステータスに遭遇したもう1つの場所は(canceled)、特定のTLS証明書の設定ミスです。のようなサイトhttps://www.example.comが誤って構成されていて、証明書にが含まれていないwww.が有効である場合https://example.com、chromeはこのリクエストをキャンセルし、自動的に後者のサイトにリダイレクトします。これはFirefoxには当てはまりません。

現在有効な例：https ：//www.pthree.org/

于 2017-06-20T18:39:12.980 に答える
5

iframe内の別々のドメインにあるセキュアページと非セキュアページの間でリダイレクトするときに、キャンセルされたリクエストが発生しました。リダイレクトされたリクエストは、開発ツールに「キャンセルされた」リクエストとして表示されました。

支払いゲートウェイによってホストされているフォームを含むiframeのページがあります。iframe内のフォームが送信されると、支払いゲートウェイはサーバー上のURLにリダイレクトします。リダイレクトは最近機能を停止し、代わりに「キャンセルされた」リクエストとして終了しました。

Chrome（私はWindows 7 Chrome 30.0.1599.101を使用していました）は、iframe内のリダイレクトが別のドメインの安全でないページに移動することを許可しなくなったようです。これを修正するために、iframe内のリダイレクトされたリクエストが常に安全なURLに送信されるようにしました。

iframeのみを使用してより単純なテストページを作成すると、コンソールに警告が表示されました（以前は見逃していたか、表示されなかった可能性があります）。

[Blocked] The page at https://mydomain.com/Payment/EnterDetails ran insecure content from http://mydomain.com/Payment/Success

リダイレクトは、PC、Mac、AndroidのChromeでキャンセルされたリクエストに変わりました。それが私のウェブサイトの設定（SagePay Low Profile）に固有のものなのか、それともChromeで何かが変更されたのかわかりません。

于 2013-10-21T13:12:12.877 に答える
4

Chromeバージョン33.0.1750.154mは、ローカルホストを指すモバイルエミュレーションを使用している場合、画像の読み込みを一貫してキャンセルします。特に、ユーザーエージェントのなりすましがオンになっている場合（画面設定のみ）。

ユーザーエージェントのなりすましをオフにすると、画像リクエストはキャンセルされません。画像が表示されます。

理由はまだわかりません。前者の場合、リクエストがキャンセルされると、リクエストヘッダー（注意：暫定ヘッダーが表示されます）には

  • 承認
  • キャッシュ制御
  • プラグマ
  • リファラー
  • ユーザーエージェント

後者の場合、これらすべてに加えて、次のようなものがあります。

  • クッキー
  • 繋がり
  • 亭主
  • Accept-Encoding
  • 受け入れる-言語

肩をすくめる

于 2014-03-26T21:30:16.850 に答える
4

JavaScriptを介してリダイレクトすると、Chromeで次のエラーが発生しました。

<script>
    window.location.href = "devhost:88/somepage";
</script>

ご覧のとおり、「http：//」を忘れました。追加した後、動作しました。

于 2017-04-08T21:40:02.997 に答える
3

私の場合、次のようなクリックイベント付きのアンカーがありました

<a href="" onclick="somemethod($index, hour, $event)">

クリックイベント内でネットワークコールがあり、Chromeがリクエストをキャンセルしました。アンカーにはhref手段""があり、ページをリロードすると同時に、ネットワーク呼び出しがキャンセルされるクリックイベントが発生します。hrefのようにボイドに置き換えるときはいつでも

<a href="javascript:void(0)" onclick="somemethod($index, hour, $event)">

問題は解決しました！

于 2017-04-24T12:16:46.680 に答える
3

これは、私が遭遇したばかりのchromeによってリクエストがキャンセルされた別のケースですが、これまでの回答ではカバーされていません。

一言で言えば
、私のAndroid携帯電話で信頼されていない自己署名証明書。

詳細
開発/デバッグ段階です。URLは自己署名ホストを指しています。コードは次のようなものです。

location.href = 'https://some.host.com/some/path'

Chromeはリクエストを黙ってキャンセルしただけで、私のようなWeb開発の初心者が問題を解決する手がかりを残していません。Androidフォンを使用して証明書をダウンロードしてインストールすると、問題は解消されます。

于 2018-12-26T06:17:54.333 に答える
3

あなたがaxiosを使うなら、それはあなたを助けることができます

// change timeout delay: instance.defaults.timeout = 2500;

https://github.com/axios/axios#config-order-of-precedence

于 2019-12-16T10:41:13.717 に答える
2

私は同じ問題に直面していました。コードのどこかで、次の擬似コードがありました。

  • iframeを作成する

  • iframeのonloadはフォームを送信します

  • 2秒後、iframeを削除します

したがって、サーバーが応答を書き込んでいるiframeに応答するのに2秒以上かかる場合、サーバーは削除されましたが、応答はまだ書き込まれていませんでしたが、書き込むiframeがなかったため、chromeは要求をキャンセルしました。したがって、これを回避するために、応答が終了した後にのみiframeが削除されるようにしました。または、ターゲットを「_blank」に変更できます。したがって、理由の1つは、 書き込みを停止する前に、書き込み中のリソース（私の場合はiframe）が削除または削除されると、リクエストがキャンセルされることです。

于 2017-03-28T07:28:40.577 に答える
2

Webフォントをスタイルシートに埋め込むときに、すべての種類のフォントとwoff、woff2、ttfを埋め込みました。最近、woff2が存在する場合、Chromeがttfとwoffへのリクエストをキャンセルすることに気付きました。現在Chromeバージョン66.0.3359.181を使用していますが、Chromeが追加のフォントタイプのキャンセルを開始した時期がわかりません。

于 2018-05-31T11:02:04.760 に答える
2

<button>jsからajaxリクエストを送信するはずのフォームにタグがあるという問題がありました。しかし、このリクエストはブラウザが原因でキャンセルされ、buttonフォーム内をクリックすると自動的にフォームが送信されます。

したがってbutton 、通常の代わりに、divまたはspanページ上で実際に使用したい場合で、form throw jsを送信したい場合は、preventDefault関数を使用してリスナーを設定する必要があります。

例えば

$('button').on('click', function(e){

    e.preventDefault();

    //do ajax
    $.ajax({

     ...
    });

})
于 2018-12-06T10:05:25.323 に答える
2

Angular（2+）に組み込まれているようなObservableベースのHTTPリクエストを利用する場合、ObservableがキャンセルされたときにHTTPリクエストをキャンセルできます（RxJS 6switchMapオペレーターを使用してストリームを結合する場合の一般的なこと） 。ほとんどの場合mergeMap、リクエストを完了させたい場合は、代わりに演算子を使用するだけで十分です。

于 2019-11-22T23:13:47.697 に答える
1

メインのcssフォルダーの外にある別のフォルダーに保存された2つのCSSファイルでもまったく同じことがわかりました。Expression Engineを使用していますが、htaccessファイルのルールに問題があることがわかりました。条件の1つにフォルダーを追加したところ、修正されました。次に例を示します。

RewriteCond %{REQUEST_URI} !(images|css|js|new_folder|favicon.ico)

したがって、潜在的な競合がないかhtaccessファイルを確認する価値があるかもしれません

于 2013-04-24T10:59:32.220 に答える
1

を呼び出すときに同じように私に起こった。$を含むjsファイル。ajax、およびajaxリクエストを行うと、私が行ったことは通常どおりに呼び出すことでした。

于 2013-08-13T18:48:38.310 に答える
1

私の場合、電子メールクライアントウィンドウを表示するコードにより、Chromeは画像の読み込みを停止しました。

document.location.href = mailToLink;

$（function（）{...}）ではなく$（window）.load（function（）{...}）に移動すると役に立ちました。

于 2014-05-19T05:32:13.867 に答える
1

これは、私がreturn falseを省略したときに、キャンセルされたステータスに遭遇した人を助けることができます。フォームで送信します。これにより、ajax送信の直後に送信アクションが発生し、現在のページが上書きされました。コードを以下に示します。最後に重要なreturnfalseがあります。

$('form').submit(function() {

    $.validator.unobtrusive.parse($('form'));
    var data = $('form').serialize();
    data.__RequestVerificationToken = $('input[name=__RequestVerificationToken]').val();

    if ($('form').valid()) {
        $.ajax({
            url: this.action,
            type: 'POST',
            data: data,
            success: submitSuccess,
            fail: submitFailed
        });
    }
    return false;       //needed to stop default form submit action
});

それが誰かを助けることを願っています。

于 2014-06-09T09:28:18.550 に答える
0

LoopbackJSから来て、チャートの例で提供されているようなカスタムストリームメソッドを使用しようとしている人のために。を使用してこのエラーが発生しPersistedModel、基本に切り替えると、ステータスがキャンセルされるModelという問題が修正されました。eventsource

繰り返しますが、これは特にループバックAPI用です。そして、これはトップの答えであり、グーグルのトップなので、私はこれを答えの組み合わせに投げ込むと思いました。

于 2016-04-05T22:49:13.273 に答える
0

私にとって「キャンセル」ステータスは、ファイルが存在しなかったためです。なぜクロムが表示されないのか不思議404です。

于 2018-02-10T17:56:08.777 に答える
0

それは私にとって間違った道と同じくらい単純でした。デバッグの最初のステップは、ajaxなどとは独立してファイルをロードできるかどうかを確認することです。

于 2018-10-03T07:11:40.497 に答える
0

リクエストはトラッキング保護プラグインによってブロックされた可能性があります。

于 2019-02-21T21:33:38.200 に答える
0

300枚の画像を背景画像として読み込んでいるときに起こりました。最初の1つがタイムアウトしたか、残りのすべてがキャンセルされたか、最大同時リクエストに達したと推測しています。一度に5つ実装する必要があります

于 2019-03-18T20:51:01.617 に答える
0

その理由の1つは、XMLHttpRequest.abort（）がコードのどこかで呼び出されたためである可能性があります。この場合、リクエストのcancelledステータスはChromeデベロッパーツールの[ネットワーク]タブに表示されます。

于 2019-06-26T05:47:11.860 に答える
0

私の場合、それはクローム76のアップデート後に来始めました。

JSコードの問題により、window.locationが複数回更新され、以前のリクエストがキャンセルされました。この問題は以前から存在していましたが、バージョン76に更新した後、Chromeはリクエストのキャンセルを開始しました。

于 2019-08-06T18:43:43.367 に答える
0

レコードを更新するときに同じ問題が発生しました。save（）内で、フォームから取得したrawdataをデータベース形式に一致するように準備していました（列挙値の多くのマッピングなどを実行しました）。これにより、putリクエストが断続的にキャンセルされます。save（）からデータ準備を取り出し、そこから専用のdataPrep（）メソッドを作成することで解決しました。このdataPrepを非同期に変換し、メモリを大量に消費するすべてのデータ変換を待ちます。次に、準備したデータをhttp putクライアントで使用できるsave（）メソッドに返します。putメソッドを呼び出す前に、dataPrep（）で待機していることを確認しました。

await dataToUpdate = await dataPrep（）; http.put（apiUrl、dataToUpdate）;

これにより、リクエストの断続的なキャンセルが解決されました。

于 2019-10-24T11:01:04.433 に答える
0

aタグの中にタグがありましたdiv。div持っていたonclick="location='http://mydestination.org/'"とaタグはで同じURLを持っていましたhref。これにより、ターゲットページが2回読み込まれ、最初の読み込みがChromeによってキャンセルされました。

于 2020-05-12T07:05:24.407 に答える
0

私の場合、問題の原因はさらに別のものでした。

私のアプリケーションはプロキシの背後にあり、ChromeリクエストはIf-Modified-SinceHTTPヘッダーで送信されていました。このヘッダーが存在する場合、実行される動作は次のとおりです。

サーバーは、指定された日付以降に最後に変更された場合にのみ、要求されたリソースを200ステータスで送り返します。それ以降、要求が変更されていない場合、応答は本文のない304になります。

プロキシはこの期待に応えられず、304ステータスコードで応答しましたが、本文が空ではなかったため、リクエストがキャンセルされました。

プロキシの動作を修正した後、リクエストは魅力のように機能しました。

于 2020-07-15T20:40:21.773 に答える
0

私のためのコンテンツセキュリティポリシーヘッダー！Chrome Dev Tools Consoleを確認することで、この可能性をすばやく除外できます。CSPの問題である場合は、コンソールにエラーが表示されます。.Netでは、web.configファイルまたはコードにヘッダーを追加することでこれを修正できます。

次のコンテンツセキュリティポリシーディレクティブに違反しているため、フォームデータを「https://www.mysite.mydomain/」に送信することを拒否しました：「form-action'self' *.otherdomainwww.thirdparty.co.uk」。

上記のエラーに対するweb.configの修正は次のとおりです。

<cspConfiguration>
        <directives>
            <directive name="form-action" allowedSources="'self' *.mydomain>
            </directive>
        </directives>
</cspConfiguration>

于 2021-02-05T09:21:35.707 に答える
0

Angularの厳密な観点から：

これは、コードレベルで適切に解読できない場合に発生します。

仮に、request1が出て、その応答も出て、その後、ネストされたrequest2も出て、その応答も出て、request1のサブスクリプションを適切に破棄せずに、直接ループから抜け出しているとします。

その時、それは起こります

于 2021-03-25T08:48:21.847 に答える