Chrome Geliştirici Araçları'nda bir kaynak için status = iptal edildi ne anlama geliyor?

Bir sayfanın iptal edilmesine ne sebep olur? Chrome Geliştirici Araçları'nın bir ekran görüntüm var.

Bu sık sık olur, ancak her seferinde olmaz. Diğer kaynaklar önbelleğe alındıktan sonra, sayfa yenilemesi LeftPane.aspx dosyasını yükleyecek gibi görünüyor. Ve gerçekten garip olan şey, Internet Explorer 8'de değil, yalnızca Google Chrome'da gerçekleşiyor. Chrome'un bir isteği neden iptal edeceği hakkında herhangi bir fikir?

Chrome'un çerçeve veya iframe'lere bir şey yükleme isteklerini iptal ettiği benzer bir sorunla mücadele ettik, ancak sadece aralıklı olarak ve bilgisayara ve / veya internet bağlantısının hızına bağlı görünüyordu.

Bu bilgiler güncel olmayan birkaç aydır, ancak Chromium'u sıfırdan oluşturdum, isteklerin iptal edilebileceği tüm yerleri bulmak için kaynaktan kazdım ve hata ayıklamak için hepsinde kesme noktaları tokatladım. Bellekten, Chrome'un bir isteği iptal edeceği tek yer:

• İsteğin yapılmasına neden olan DOM öğesi silindi (yani bir IMG yükleniyor, ancak yükleme gerçekleşmeden önce IMG düğümünü sildiniz)
• Verileri yüklemeyi gereksiz kılan bir şey yaptınız. (yani bir iframe yüklemeye başladınız, sonra src'yi değiştirdiniz veya içeriğin üzerine yazdınız)
• Aynı sunucuya giden çok sayıda istek var ve önceki isteklerde bir ağ sorunu, sonraki isteklerin işe yaramayacağını gösterdi (DNS arama hatası, önceki (aynı) istek, örneğin HTTP 400 hata kodu, vb.)

Bizim durumumuzda nihayet HTML'yi başka bir kareye eklemeye çalışırken bir kareye kadar izledik, bu da bazen hedef karenin yüklenmesi öncesinde bile oldu. Bir iframe'in içeriğine dokunduğunuzda, artık kaynağa kaynağını yükleyemez (nereye koyacağını nasıl bilebilir?), Böylece isteği iptal eder.

status = iptal edildi, JavaScript etkinliklerindeki ajax isteklerinde de olabilir:

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

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

Olay isteği başarıyla gönderir, ancak iptal edilir (ancak sunucu tarafından işlenir). Bunun nedeni, aynı tıklama etkinliğinde herhangi bir ajax isteğinde bulunmanızdan bağımsız olarak, öğelerin tıklama etkinliklerinde form göndermesidir.

İsteğin iptal edilmesini önlemek için JavaScript event.preventDefault (); çağrılmalı:

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

Not: Herhangi bir sarma form öğeniz olmadığından emin olun .

Ben onclick = {} ile benim düğme bir form öğesi içinde sarılmış benzer bir sorun vardı. Düğmeyi tıkladığınızda form da gönderilir ve bu da hepsini berbat eder ...

Bu cevap muhtemelen hiç kimse tarafından okunmayacak, ama neden yazmadım :)

Dikkat edilmesi gereken başka bir şey, AdBlock uzantısı veya genel olarak uzantılar olabilir.

Ama "çok" insanın AdBlock var ....

Uzantıları dışlamak için gizli modda yeni bir sekme açın ve test etmek istediğiniz uzantılar için "gizli modda izin ver kapalı" seçeneğinden emin olun.

"X-Frame-Options" başlık etiketini kontrol etmek isteyebilirsiniz. SAMEORIGIN veya DENY olarak ayarlanmışsa, iFrame ekleme spesifikasyon başına Chrome (ve diğer tarayıcılar) tarafından iptal edilir .

Ayrıca, bazı tarayıcıların ALLOW-FROM ayarını desteklediğini, ancak Chrome'un desteklemediğini unutmayın.

Bu sorunu çözmek için, "X-Frame-Options" başlık etiketini kaldırmanız gerekir. Bu, sizi tıklama saldırılarına açık bırakabilir, böylece risklerin ne olduğuna ve bunları nasıl azaltacağınıza karar vermeniz gerekir.

Benim durumumda, jquery global zaman aşımı ayarları, 500 ms'ye kadar bir jquery eklentisi kurulum global zaman aşımı olduğunu buldum, böylece istek 500 ms'yi aştığında, krom isteği iptal edecektir.

İşte başıma gelenler: Sunucu, 302 yönlendirmesi için hatalı biçimlendirilmiş bir "Konum" başlığı döndürüyordu. Chrome bana bunu söyleyemedi elbette. Sayfayı firefox'ta açtım ve hemen sorunu keşfettim. Birden fazla araca sahip olmak güzel :)

Durumla karşılaştığımız başka bir yer de (canceled)belirli bir TLS sertifikası yanlış yapılandırmasında. Gibi bir site https://www.example.com, sertifikanın içermediği www.ancak geçerli olmadığı şekilde yanlış yapılandırılırsa https://example.com, krom bu isteği iptal eder ve otomatik olarak ikinci siteye yönlendirir. Bu değil Firefox için kılıf.

Şu anda geçerli örnek: https://www.pthree.org/

Bir iframe içindeki ayrı alan adlarında güvenli ve güvenli olmayan sayfalar arasında yeniden yönlendirilirken iptal edilen bir istek geldi. Yeniden yönlendirilen istek geliştirici araçlarında "iptal edildi" isteği olarak gösterildi.

Ödeme ağ geçidim tarafından barındırılan bir form içeren bir iframe içeren bir sayfam var. İframe'deki form gönderildiğinde, ödeme ağ geçidi sunucumdaki bir URL'ye yeniden yönlendirir. Yönlendirme yakın zamanda çalışmayı durdurdu ve bunun yerine "iptal edildi" isteği olarak sona erdi.

Görünüşe göre Chrome (Windows 7 Chrome 30.0.1599.101 kullanıyordum) artık iframe içindeki bir yönlendirmenin ayrı bir alandaki güvenli olmayan bir sayfaya gitmesine izin vermedi. Bunu düzeltmek için iframe'deki yeniden yönlendirilen isteklerin her zaman güvenli URL'lere gönderildiğinden emin oldum.

Yalnızca bir iframe ile daha basit bir test sayfası oluşturduğumda, konsolda bir uyarı vardı (daha önce kaçırmıştım ya da belki görünmüyordu):

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

Yönlendirme, PC, Mac ve Android'de Chrome'da iptal edilen bir isteğe dönüştü. Web sitemin kurulumuna (SagePay Düşük Profil) özgü olup olmadığını veya Chrome'da bir şey değişip değişmediğini bilmiyorum.

Yerel sürümümü işaret eden Mobil Öykünmeyi kullanıyorsanız, Chrome Sürüm 33.0.1750.154 m, resim yüklemelerini sürekli olarak iptal eder ; özellikle User Agent kimlik sahtekarlığı açıkken (yalnızca Ekran ayarlarına göre).

Kullanıcı Aracısı kimlik sahtekarlığını kapattığımda; resim istekleri iptal edilmedi, resimleri görüyorum.

Hala nedenini anlamıyorum; isteğin iptal edildiği önceki durumda, İstek Başlıkları (DİKKAT: Geçici başlıklar gösterilir)

• Kabul etmek
• Cache-Control
• Pragma
• yönlendiren
• User-Agent

İkinci durumda, bunların tümü ve diğerleri:

• Kurabiye
• Bağ
• evsahibi
• Accept-Encoding
• Accept-Language

omuz silkme

JavaScript ile yeniden yönlendirdiğimde Chrome'da bu hatayı aldım:

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

Gördüğünüz gibi 'http: //' i unuttum . Ekledikten sonra işe yaradı.

Benim durumum için, tıklama etkinliğine sahip bir çapa vardı

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

Tıklama etkinliğinin içinde, Chrome isteği iptal eden bir ağ çağrısı yaptım. Çapa sahip hrefolan ""bu sayfayı yeniden ve aynı zamanda iptal olur ağ çağrısıyla olay tıklayın vardır, araçlar. Ne zaman ben hrefgeçersiz gibi değiştirin

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

Sorun ortadan kalktı!

Burada daha önce karşılaştığım krom tarafından iptal edilen başka bir talep örneği var;

Özetle Kendim
imzalı sertifika android telefonumda güvenilmiyor.

Ayrıntılar
Geliştirme aşamasında / hata ayıklama aşamasındayız. URL, kendinden imzalı bir ana bilgisayarı işaret ediyor. Kod şöyle:

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

Chrome, isteği sessizce iptal etti ve yeni başlayanların benim gibi web geliştirme konusunda sorunu çözmesi için hiçbir ipucu bırakmadı. Android telefon kullanarak sertifikayı indirip yükledikten sonra sorun ortadan kalktı.

Açısal (2+) yerleşik olanlar gibi bazı Gözlenebilir tabanlı HTTP isteklerinden yararlanırsanız, gözlemlenebilir iptal edildiğinde HTTP isteği iptal edilebilir ( switchMapakışları birleştirmek için RxJS 6 operatörünü kullandığınızda sık karşılaşılan şey ) . mergeMapİsteğin tamamlanmasını istiyorsanız, çoğu durumda bunun yerine operatör kullanmak yeterlidir .

Benim ana css klasörü dışında başka bir klasörde saklanan iki CSS dosyaları ile aynı şey vardı. Expression Engine kullanıyorum ve sorunun htaccess dosyamdaki kurallarda olduğunu gördüm. Klasörü koşullardan birine ekledim ve düzeltti. İşte bir örnek:

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

Bu nedenle, htaccess dosyanızı olası çakışmalar açısından kontrol etmeye değer olabilir

Ben yazı yanı sıra her türlü gömülü olan woff , woff2 , ttf ben stil sayfasındaki bir web yazı katıştırdığınızda. Son zamanlarda , woff2 mevcut olduğunda Chrome'un ttf ve woff talebini iptal ettiğini fark ettim . Şu anda Chrome 66.0.3359.181 sürümünü kullanıyorum, ancak Chrome'un ekstra yazı tipi türlerini iptal etmeye ne zaman başladığını bilmiyorum.

<button>Js'den ajax isteği göndermek gerekiyordu formda etiket sahip bu sorun vardı . Ancak bu istek, formun buttoniçindeki herhangi bir tıklamayla otomatik olarak form gönderen tarayıcı nedeniyle iptal edildi .

button Normal divveya spansayfa yerine kullanmak istiyorsanız ve form atma js göndermek istiyorsanız - preventDefaultişlevli bir dinleyici kurmalısınız .

Örneğin

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

    e.preventDefault();

    //do ajax
    $.ajax({

     ...
    });

})

Aynı şeyi çağırırken bana da oldu. js dosyası $ ile. ajax ve ajax isteğinde bulunuyorum, yaptığım şey normal olarak adlandırmaktı.

Benim durumumda, e-posta istemcisi penceresini gösteren kod, Chrome'un resim yüklemeyi durdurmasına neden oldu:

document.location.href = mailToLink;

$ (function () {...}) yerine $ (window) .load (function () {...}) 'a taşımak yardımcı oldu.

In-dönüş yanlış dışarıda bıraktığımda iptal durumu rastladı herkese yardımcı olabilir; şeklinde gönderin. Bu, ajax gönderisinin hemen ardından geçerli sayfanın üzerine yazan gönderme eylemini izlemesine neden oldu. Kod, önemli dönüş yanlış sonunda olacak şekilde aşağıda gösterilmiştir.

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

Umarım birine yardım eder.

LoopbackJS'den gelen ve grafik örneklerinde belirtildiği gibi özel akış yöntemini kullanmaya çalışan herkes için. Bu hatayı PersistedModeltemel kullanarak geçiş yaparak alıyordumModeleventsource duruma geçerek durumun iptal edilmesiyle ilgili sorunum düzeltildi .

Yine, bu özellikle geri döngü api içindir. Ve bu bir üst cevap ve google üst i i bu cevaplar karışımı atmak düşündüm çünkü.

Ben aynı sorunla karşı karşıya, bizim kod derin bir yerde biz bu sözde kod vardı:

• iframe oluştur

• iframe'in yüklenmesi

• 2 saniye sonra iframe'i çıkarın

bu nedenle, sunucunun yanıt yazdığı iframe'e yanıt vermesi 2 saniyeden fazla sürdüğünde, yanıt kaldırıldı, ancak yanıt yine de yazılacaktı, ancak yazılacak bir iframe yoktu, bu nedenle krom isteği iptal etti, böylece bunu önlemek için iframe sadece yanıt bittikten sonra kaldırıldı emin olun, ya da hedefi "_blank" olarak değiştirebilirsiniz. Bu nedenle nedenlerden biri: bir şey yazdığınız kaynak (benim durumumda iframe), yazmayı durdurmadan önce kaldırılır veya silinirse, istek iptal edilir

Benim için 'iptal edildi' durumu dosyanın mevcut olmamasıydı. Chrome'un neden görünmediği garip 404.

Benim için yanlış bir yol kadar basitti. Hata ayıklamadaki ilk adımın dosyayı ajax vs.'den bağımsız olarak yükleyip yükleyemeyeceğinizi görmek olduğunu öneririm.

İstekler bir izleme koruma eklentisi tarafından engellenmiş olabilir.

300 görüntü arka plan görüntüsü olarak yüklenirken başıma geldi. İlk kez zaman aşımına uğradı, geri kalan her şeyi iptal etti veya maksimum eşzamanlı istek ulaştı tahmin ediyorum. her seferinde 5 tane uygulamak gerekir

Bunun nedenlerinden biri, XMLHttpRequest.abort () yönteminin kodun herhangi bir yerine çağrılmış olması olabilir; bu durumda, isteğin cancelleddurumu Chrome Geliştirici araçları Ağ sekmesinde olacaktır.

Benim durumumda, krom 76 güncellemesinden sonra gelmeye başladı.

JS kodumdaki bazı sorunlar nedeniyle, window.location birden çok kez güncelleniyordu ve bu da önceki isteğin iptal edilmesiyle sonuçlandı. Sorun daha önce mevcut olsa da, Chrome 76 sürümüne güncellendikten sonra isteği iptal etmeye başladı.

Bir kaydı güncellerken de aynı sorunu yaşadım. Save () içinde veritabanı biçimini (numaralandırma değerleri, vb bir çok eşleme yapıyor) eşleştirmek için formdan alınan ham veri hazırlanıyor ve bu zaman zaman put isteği iptal eder. save () 'den hazırlanıyor ve dışarı adanmış bir dataPrep () yöntemi oluşturarak veri alarak çözüldü. Bu dataPrep'i zaman uyumsuz hale getirdim ve tüm bellek yoğun veri dönüşümünü bekledim. Daha sonra http put istemcisinde kullanabileceğiniz save () yöntemine önceden hazırlanmış veri döndürür. Ben put yöntemi çağırmadan önce dataPrep () bekliyorum emin yaptı:

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

Bu, talebin aralıklı olarak iptal edilmesini çözdü.

Axios kullanıyorsanız size yardımcı olabilir

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

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