Apa arti status = dibatalkan untuk sumber daya di Alat Pengembang Chrome?

Apa yang menyebabkan halaman dibatalkan? Saya memiliki tangkapan layar Alat Pengembang Chrome.

Ini sering terjadi tetapi tidak setiap waktu. Sepertinya begitu beberapa sumber daya lainnya di-cache, refresh halaman akan memuat LeftPane.aspx. Dan apa yang benar-benar aneh adalah ini hanya terjadi di Google Chrome, bukan Internet Explorer 8. Ada ide mengapa Chrome akan membatalkan permintaan?

Kami menghadapi masalah serupa di mana Chrome membatalkan permintaan untuk memuat hal-hal dalam bingkai atau iframe, tetapi hanya sebentar-sebentar dan itu tampaknya tergantung pada komputer dan / atau kecepatan koneksi internet.

Informasi ini beberapa bulan kedaluwarsa, tetapi saya membuat Chromium dari awal, menggali sumbernya untuk menemukan semua tempat di mana permintaan dapat dibatalkan, dan menampar breakpoint pada semuanya untuk di-debug. Dari memori, satu-satunya tempat di mana Chrome akan membatalkan permintaan:

• Elemen DOM yang menyebabkan permintaan dibuat dihapus (mis. IMG sedang dimuat, tetapi sebelum pemuatan terjadi, Anda menghapus simpul IMG)
• Anda melakukan sesuatu yang membuat pemuatan data tidak perlu. (yaitu Anda mulai memuat iframe, kemudian mengubah src atau menimpa isinya)
• Ada banyak permintaan ke server yang sama, dan masalah jaringan pada permintaan sebelumnya menunjukkan bahwa permintaan berikutnya tidak akan berfungsi (Galat pencarian DNS, permintaan sebelumnya (yang sama) dihasilkan misalnya kode kesalahan HTTP 400, dll.)

Dalam kasus kami, kami akhirnya melacaknya ke satu frame mencoba menambahkan HTML ke frame lain, yang kadang-kadang terjadi sebelum frame tujuan bahkan dimuat. Setelah Anda menyentuh konten iframe, ia tidak dapat lagi memuat sumber daya ke dalamnya (bagaimana ia tahu di mana harus meletakkannya?) Sehingga membatalkan permintaan.

status = dibatalkan dapat terjadi juga pada permintaan ajax pada acara JavaScript:

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

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

Acara berhasil mengirim permintaan, tetapi kemudian dibatalkan (tetapi diproses oleh server). Alasannya adalah, elemen mengirimkan formulir pada acara klik, tidak masalah jika Anda membuat permintaan ajax pada acara klik yang sama.

Untuk mencegah permintaan dibatalkan, JavaScript event.preventDefault (); harus dipanggil:

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

NB: Pastikan Anda tidak memiliki elemen bentuk pembungkus .

Saya memiliki masalah serupa di mana tombol saya dengan onclick = {} dibungkus dalam elemen formulir. Saat mengklik tombol, formulir juga dikirimkan, dan itu mengacaukan semuanya ...

Jawaban ini mungkin tidak akan pernah dibaca oleh siapa pun, tetapi saya pikir mengapa tidak menulisnya :)

Hal lain yang harus diperhatikan adalah ekstensi AdBlock, atau ekstensi secara umum.

Tapi "banyak" orang memiliki AdBlock ....

Untuk mengesampingkan ekstensi, buka tab baru dalam penyamaran dengan memastikan bahwa "izinkan dalam penyamaran dimatikan" untuk ekstensi yang ingin Anda uji.

Anda mungkin ingin memeriksa tag header "X-Frame-Options". Jika disetel ke SAMAORIGIN atau DENY, maka penyisipan iFrame akan dibatalkan oleh Chrome (dan peramban lain) sesuai spesifikasi .

Perhatikan juga bahwa beberapa browser mendukung pengaturan ALLOW-FROM tetapi Chrome tidak.

Untuk mengatasi ini, Anda harus menghapus tag header "X-Frame-Options". Ini bisa membuat Anda terbuka untuk serangan klik sehingga Anda perlu memutuskan apa risikonya dan bagaimana cara mengatasinya.

Dalam kasus saya, saya menemukan bahwa itu adalah pengaturan jquery global timeout, sebuah plugin jquery yang mengatur global timeout hingga 500ms, sehingga ketika permintaan melebihi 500ms, chrome akan membatalkan permintaan.

Inilah yang terjadi pada saya: server mengembalikan header "Lokasi" salah bentuk untuk 302 redirect. Chrome gagal memberi tahu saya hal ini, tentu saja. Saya membuka halaman di firefox, dan segera menemukan masalahnya. Senang memiliki banyak alat :)

Tempat lain yang pernah kami temui (canceled)statusnya adalah kesalahan konfigurasi sertifikat TLS tertentu. Jika situs seperti https://www.example.comsalah konfigurasi sehingga sertifikat tidak termasuk www.tetapi valid untuk https://example.com, chrome akan membatalkan permintaan ini dan secara otomatis mengarahkan ulang ke situs yang terakhir. Ini bukan kasus untuk Firefox.

Contoh saat ini valid: https://www.pthree.org/

Permintaan yang dibatalkan terjadi pada saya ketika mengalihkan antara halaman aman dan tidak aman di domain terpisah dalam iframe. Permintaan yang dialihkan ditampilkan di alat dev sebagai permintaan "dibatalkan".

Saya memiliki halaman dengan iframe yang berisi formulir yang diinangi oleh gateway pembayaran saya. Ketika formulir di iframe dikirimkan, gateway pembayaran akan mengarahkan kembali ke URL di server saya. Pengalihan baru-baru ini berhenti berfungsi dan berakhir sebagai permintaan "dibatalkan".

Tampaknya Chrome (saya menggunakan Windows 7 Chrome 30.0.1599.101) tidak lagi mengizinkan pengalihan dalam iframe untuk pergi ke halaman yang tidak aman pada domain yang terpisah. Untuk memperbaikinya, saya hanya memastikan bahwa permintaan yang dialihkan di iframe selalu dikirim ke URL yang aman.

Ketika saya membuat halaman pengujian yang lebih sederhana dengan hanya iframe, ada peringatan di konsol (yang sebelumnya saya lewatkan atau mungkin tidak muncul):

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

Redirect berubah menjadi permintaan yang dibatalkan di Chrome di PC, Mac dan Android. Saya tidak tahu apakah ini khusus untuk penyiapan situs web saya (Profil Rendah SagePay) atau apakah ada sesuatu yang berubah di Chrome.

Versi Chrome 33.0.1750.154 m secara konsisten membatalkan pemuatan gambar jika saya menggunakan Emulasi Seluler yang diarahkan ke hosting lokal saya; khusus dengan Agen Pengguna yang spoofing aktif (vs. pengaturan Layar saja).

Saat saya mematikan Agen Pengguna spoofing; permintaan gambar tidak dibatalkan, saya melihat gambar.

Saya masih tidak mengerti mengapa; dalam kasus sebelumnya, di mana permintaan dibatalkan, Header Permintaan (PERHATIAN: Header sementara ditampilkan) hanya memiliki

• Menerima
• Kontrol Cache
• Pragma
• Referer
• Agen pengguna

Dalam kasus terakhir, semua yang ditambah lainnya seperti:

• Kue kering
• Koneksi
• Tuan rumah
• Terima-Pengkodean
• Bahasa Terima

Mengangkat bahu

Saya mendapatkan kesalahan ini di Chrome ketika saya dialihkan melalui JavaScript:

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

Seperti yang Anda lihat saya lupa 'http: //' . Setelah saya menambahkannya, itu berhasil.

Untuk kasus saya, saya memiliki jangkar dengan acara klik seperti

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

Di dalam acara klik saya mendapat panggilan jaringan, Chrome membatalkan permintaan. Jangkar memiliki hrefdengan ""berarti, itu memuat ulang halaman dan saat yang sama memiliki klik acara dengan panggilan jaringan yang dibatalkan. Setiap kali saya mengganti hrefdengan void like

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

Masalahnya hilang!

Berikut adalah kasus lain permintaan dibatalkan oleh chrome, yang baru saja saya temui, yang tidak tercakup oleh jawaban apa pun di sana.

Singkatnya,
sertifikat yang ditandatangani sendiri tidak dipercaya di ponsel android saya.

Detail
Kami sedang dalam tahap pengembangan / debug. URL mengarah ke host yang ditandatangani sendiri. Kodenya seperti:

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

Chrome hanya membatalkan permintaan secara diam-diam, tanpa meninggalkan petunjuk bagi pemula untuk pengembangan web seperti saya untuk memperbaiki masalah ini. Setelah saya mengunduh dan menginstal sertifikat menggunakan ponsel android, masalahnya hilang.

Jika Anda menggunakan beberapa permintaan HTTP berbasis Observable seperti built-in di Angular (2+), maka permintaan HTTP dapat dibatalkan ketika diamati dapat dibatalkan (hal yang umum ketika Anda menggunakan switchMapoperator RxJS 6 untuk menggabungkan aliran) . Dalam kebanyakan kasus, cukup menggunakan mergeMapoperator saja, jika Anda ingin menyelesaikan permintaan.

Saya memiliki hal yang sama persis dengan dua file CSS yang disimpan di folder lain di luar folder css utama saya. Saya menggunakan Mesin Ekspresi dan menemukan bahwa masalahnya ada pada aturan di file htaccess saya. Saya baru saja menambahkan folder ke salah satu kondisi saya dan memperbaikinya. Ini sebuah contoh:

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

Jadi mungkin ada baiknya Anda memeriksa file htaccess Anda untuk setiap potensi konflik

Saya telah menyematkan semua jenis font serta woff , woff2 , ttf ketika saya menyematkan font web dalam style sheet. Baru-baru ini saya perhatikan bahwa Chrome membatalkan permintaan ke ttf dan woff ketika woff2 hadir. Saya menggunakan Chrome versi 66.0.3359.181 sekarang tetapi saya tidak yakin kapan Chrome mulai membatalkan jenis font tambahan.

Kami memiliki masalah ini memiliki tag <button>dalam formulir, yang seharusnya mengirim permintaan ajax dari js. Tetapi permintaan ini dibatalkan, karena browser, yang mengirimkan formulir secara otomatis pada setiap klikbutton dalam formulir.

Jadi jika Anda benar-benar ingin menggunakan button daripada biasa divatau spanpada halaman, dan Anda ingin mengirim js melempar formulir - Anda harus menyiapkan pendengar denganpreventDefault fungsi.

misalnya

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

    e.preventDefault();

    //do ajax
    $.ajax({

     ...
    });

})

terjadi pada saya sama ketika memanggil a. file js dengan $. ajax, dan membuat permintaan ajax, apa yang saya lakukan adalah menelepon secara normal.

Dalam kasus saya, kode untuk menampilkan jendela klien email menyebabkan Chrome berhenti memuat gambar:

document.location.href = mailToLink;

memindahkannya ke $ (window) .load (function () {...}) alih-alih $ (function () {...}) membantu.

Dalam kaleng ini membantu siapa pun saya menemukan status yang dibatalkan ketika saya meninggalkan pengembalian palsu; dalam formulir kirim. Ini menyebabkan pengiriman ajax segera diikuti oleh tindakan kirim, yang menimpa halaman saat ini. Kode ditunjukkan di bawah ini, dengan return penting salah di akhir.

$('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
});

Semoga itu bisa membantu seseorang.

Bagi siapa pun yang datang dari LoopbackJS dan berusaha menggunakan metode aliran khusus seperti yang disediakan dalam contoh grafik mereka. Saya mendapatkan kesalahan ini menggunakan PersistedModel, beralih ke dasar Modelmemperbaiki masalah sayaeventsource pembatalan status.

Sekali lagi, ini khusus untuk api loopback. Dan karena ini adalah jawaban teratas dan teratas di google saya pikir saya akan melemparkan ini ke dalam campuran jawaban.

Saya telah menghadapi masalah yang sama, di suatu tempat jauh di dalam kode kami, kami memiliki pseudocode ini:

• buat iframe

• onload iframe mengirimkan formulir

• Setelah 2 detik, hapus iframe

dengan demikian, ketika server membutuhkan waktu lebih dari 2 detik untuk merespons iframe yang menjadi respons server tersebut, dihapus, tetapi responsnya masih harus ditulis, tetapi tidak ada iframe untuk ditulis, sehingga chrome membatalkan permintaan, jadi untuk menghindari ini, saya memastikan bahwa iframe dihapus hanya setelah responsnya selesai, atau Anda dapat mengubah target menjadi "_blank". Jadi salah satu alasannya adalah: ketika sumber daya (iframe dalam kasus saya) tempat Anda menulis sesuatu, dihapus atau dihapus sebelum Anda berhenti menulis padanya, permintaan akan dibatalkan

Bagi saya status 'dibatalkan' adalah karena file tidak ada. Aneh mengapa chrome tidak muncul 404.

Itu sesederhana jalan yang salah bagi saya. Saya menyarankan langkah pertama dalam debugging adalah untuk melihat apakah Anda dapat memuat file secara independen dari ajax dll.

Permintaan mungkin telah diblokir oleh plugin perlindungan pelacakan.

Itu terjadi pada saya ketika memuat 300 gambar sebagai gambar latar. Saya menduga sekali pertama kali habis, itu membatalkan sisanya, atau mencapai permintaan bersamaan. perlu menerapkan 5-pada-waktu

Salah satu alasannya adalah XMLHttpRequest.abort () dipanggil di suatu tempat dalam kode, dalam hal ini, permintaan akan memiliki cancelledstatus di tab Jaringan alat Pengembang Chrome.

Dalam kasus saya, mulai muncul setelah pembaruan chrome 76.

Karena beberapa masalah dalam kode JS saya, window.location semakin diperbarui beberapa kali yang mengakibatkan membatalkan permintaan sebelumnya. Meskipun masalah muncul dari sebelumnya, chrome mulai membatalkan permintaan setelah memperbarui ke versi 76.

Saya memiliki masalah yang sama ketika memperbarui catatan. Di dalam save () saya sedang menyiapkan data mentah yang diambil dari formulir untuk mencocokkan format database (melakukan banyak pemetaan nilai enums, dll), dan ini sebentar-sebentar membatalkan permintaan put. saya mengatasinya dengan mengambil data prepping dari save () dan membuat metode dataPrep () khusus dari itu. Saya mengubah dataPrep ini menjadi async dan menunggu semua konversi data intensif memori. Saya kemudian mengembalikan data yang sudah disiapkan ke metode save () yang bisa saya gunakan di http put client. Saya memastikan saya menunggu dataPrep () sebelum memanggil metode put:

await dataToUpdate = await dataPrep (); http.put (apiUrl, dataToUpdate);

Ini menyelesaikan pembatalan permintaan yang terputus-putus.

Jika Anda menggunakan aksioma, ini dapat membantu Anda

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

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