Co oznacza status = anulowano dla zasobu w Narzędziach dla programistów Chrome?

Co spowodowałoby anulowanie strony? Mam zrzut ekranu Narzędzi dla programistów Chrome.

Zdarza się to często, ale nie za każdym razem. Wygląda na to, że po buforowaniu niektórych innych zasobów odświeżenie strony załaduje plik LeftPane.aspx. Co naprawdę dziwne, dzieje się tak tylko w Google Chrome, a nie w Internet Explorerze 8. Czy masz jakieś pomysły, dlaczego Chrome anuluje żądanie?

Walczyliśmy z podobnym problemem, w którym Chrome anulował żądania załadowania elementów w ramkach lub ramkach iframe, ale tylko sporadycznie i wydawało się, że zależy to od komputera i / lub szybkości połączenia internetowego.

Ta informacja jest kilka miesięcy nieaktualna, ale zbudowałem Chromium od zera, przekopałem źródło, aby znaleźć wszystkie miejsca, w których można anulować żądania, i podałem wszystkim punkty przerwania, aby debugować. Z pamięci jedyne miejsca, w których Chrome anuluje żądanie:

• Element DOM, który spowodował wysłanie żądania, został usunięty (tzn. Ładowany jest IMG, ale przed załadowaniem usunięto węzeł IMG)
• Zrobiłeś coś, co sprawiło, że ładowanie danych stało się niepotrzebne. (tzn. zacząłeś ładować iframe, a następnie zmieniłeś plik src lub nadpisałeś zawartość)
• Istnieje wiele żądań kierowanych do tego samego serwera, a problem z siecią w przypadku wcześniejszych żądań pokazał, że kolejne żądania nie działały (błąd wyszukiwania DNS, wcześniejsze (takie same) żądanie spowodowało np. Kod błędu HTTP 400 itp.)

W naszym przypadku w końcu prześledziliśmy go do jednej ramki, próbując dołączyć HTML do innej ramki, co czasami zdarzało się, zanim jeszcze załadowano ramkę docelową. Po dotknięciu zawartości elementu iframe nie może on już załadować do niego zasobu (skąd miałby wiedzieć, gdzie go umieścić?), Więc anuluje żądanie.

status = anulowany może się zdarzyć również w przypadku żądań ajax dotyczących zdarzeń JavaScript:

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

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

Zdarzenie pomyślnie wysyła żądanie, ale jest następnie anulowane (ale przetwarzane przez serwer). Powodem jest to, że elementy przesyłają formularze dotyczące zdarzeń kliknięcia, bez względu na to, czy wykonujesz jakiekolwiek żądania ajax dla tego samego zdarzenia kliknięcia.

Aby zapobiec anulowaniu żądania, JavaScript event.preventDefault (); muszą być nazywane:

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

Uwaga: Upewnij się, że nie masz żadnych elementów formularza zawijania .

Miałem podobny problem, gdy mój przycisk onclick = {} był zawinięty w element formularza. Po kliknięciu przycisku formularz jest również przesyłany i wszystko to zawiodło ...

Ta odpowiedź prawdopodobnie nigdy nie zostanie przeczytana, ale doszedłem do wniosku, dlaczego nie napisać :)

Inną rzeczą, na którą należy zwrócić uwagę, może być rozszerzenie AdBlock lub ogólnie rozszerzenia.

Ale „wiele” osób ma AdBlock…

Aby wykluczyć rozszerzenie (rozszerzenia), otwórz nową kartę w trybie incognito, upewniając się, że opcja „zezwól w trybie incognito jest wyłączona” dla rozszerzenia, które chcesz przetestować.

Możesz sprawdzić tag nagłówka „X-Frame-Opcje”. Jeśli jest ustawiony na SAMEORIGIN lub DENY, wstawianie iFrame zostanie anulowane przez Chrome (i inne przeglądarki) zgodnie ze specyfikacją .

Pamiętaj też, że niektóre przeglądarki obsługują ustawienie ZEZWALAJ-OD, ale Chrome nie.

Aby rozwiązać ten problem, musisz usunąć tag nagłówka „X-Frame-Opcje”. To może pozostawić cię otwartym na ataki typu clickjacking, więc będziesz musiał zdecydować, jakie jest ryzyko i jak je ograniczyć.

W moim przypadku okazało się, że są to globalne ustawienia limitu czasu jquery, globalny limit czasu konfiguracji wtyczki jquery do 500 ms, więc gdy żądanie przekroczy 500 ms, chrome anuluje żądanie.

Oto, co mi się przydarzyło: serwer zwracał zniekształcony nagłówek „Lokalizacja” dla przekierowania 302. Oczywiście Chrome mi tego nie powiedział. Otworzyłem stronę w Firefoksie i natychmiast odkryłem problem. Miło mieć wiele narzędzi :)

Innym miejscem, w którym napotkaliśmy (canceled)status, jest błędna konfiguracja certyfikatu TLS. Jeśli witryna taka https://www.example.comjest źle skonfigurowana w taki sposób, że certyfikat nie zawiera, www.ale jest ważny https://example.com, Chrome anuluje to żądanie i automatycznie przekieruje do tej drugiej witryny. To nie sprawa dla Firefoksa.

Obecnie ważny przykład: https://www.pthree.org/

Anulowane żądanie przydarzyło mi się podczas przekierowywania między stronami bezpiecznymi i niezabezpieczonymi w oddzielnych domenach w ramce iframe. Przekierowane żądanie pokazało się w narzędziach programistycznych jako „anulowane” żądanie.

Mam stronę z ramką iframe zawierającą formularz obsługiwany przez moją bramkę płatności. Po przesłaniu formularza w elemencie iframe brama płatności przekieruje z powrotem na adres URL na moim serwerze. Przekierowanie ostatnio przestało działać i zakończyło się jako żądanie „anulowane”.

Wygląda na to, że Chrome (korzystałem z systemu Windows 7 Chrome 30.0.1599.101) nie zezwalał już na przekierowanie w ramce iframe na niezabezpieczoną stronę w oddzielnej domenie. Aby to naprawić, upewniłem się, że wszelkie przekierowane żądania w ramce iframe są zawsze wysyłane na bezpieczne adresy URL.

Kiedy utworzyłem prostszą stronę testową z tylko ramką iframe, w konsoli pojawiło się ostrzeżenie (którego wcześniej przegapiłem lub może się nie pokazałem):

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

Przekierowanie zmieniło się w anulowane żądanie w Chrome na PC, Mac i Androidzie. Nie wiem, czy jest to specyficzne dla konfiguracji mojej witryny (SagePay Low Profile), czy też coś się zmieniło w Chrome.

Wersja Chrome 33.0.1750.154 m konsekwentnie anuluje ładowanie obrazu, jeśli korzystam z emulacji mobilnej wskazanej na moim komputerze lokalnym; w szczególności z włączonym fałszowaniem agenta użytkownika (a nie tylko ustawienia ekranu).

Kiedy wyłączam fałszowanie User User; żądania obrazów nie są anulowane, widzę obrazy.

Nadal nie rozumiem dlaczego; w pierwszym przypadku, gdy żądanie zostanie anulowane, nagłówki żądania (UWAGA: pokazane są tymczasowe nagłówki) mają tylko

• Zaakceptować
• Kontrola pamięci podręcznej
• Pragma
• Referer
• Agent użytkownika

W tym drugim przypadku wszystkie te oraz inne, takie jak:

• Ciastko
• Połączenie
• Gospodarz
• Zaakceptuj kodowanie
• Zaakceptuj język

Wzruszać ramionami

Ten błąd pojawia się w Chrome, gdy przekierowuję przez JavaScript:

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

Jak widzisz , zapomniałem „http: //” . Po dodaniu działało.

W moim przypadku miałem kotwicę ze zdarzeniem kliknięcia jak

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

Wewnątrz zdarzenia kliknięcia miałem połączenie sieciowe, Chrome anulował żądanie. Kotwa ma hrefz ""pomocą, to ładuje stronę i jednocześnie posiada kliknij zdarzenie połączenia sieciowego, który zostanie anulowane. Ilekroć wymieniam na hrefvoid jak

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

Problem zniknął!

Oto kolejny przypadek anulowania żądania przez chrome, który właśnie spotkałem, który nie jest objęty żadną z odpowiedzi tam.

Krótko mówiąc,
samopodpisany certyfikat nie jest zaufany na moim telefonie z Androidem.

Szczegóły
Jesteśmy w fazie rozwoju / debugowania. Adres URL wskazuje hosta z podpisem własnym. Kod jest jak:

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

Chrome po prostu anulował prośbę w trybie cichym, nie pozostawiając nowicjuszowi wskazówek dotyczących tworzenia stron internetowych, takich jak ja, w celu rozwiązania problemu. Po pobraniu i zainstalowaniu certyfikatu za pomocą telefonu z systemem Android problem zniknął.

Jeśli korzystasz z niektórych żądań HTTP opartych na obserwowalnych, takich jak te wbudowane w Angular (2+), to żądanie HTTP może zostać anulowane, gdy obserwowalne zostanie anulowane (powszechne, gdy używasz switchMapoperatora RxJS 6 do łączenia strumieni) . W większości przypadków wystarczy użyć mergeMapoperatora, jeśli chcesz, aby żądanie zostało zrealizowane.

Miałem dokładnie to samo z dwoma plikami CSS, które były przechowywane w innym folderze poza moim głównym folderem css. Korzystam z Expression Engine i stwierdziłem, że problem dotyczył reguł w moim pliku htaccess. Właśnie dodałem folder do jednego z moich warunków i naprawiłem go. Oto przykład:

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

Dlatego warto sprawdzić plik htaccess pod kątem potencjalnych konfliktów

Po osadzeniu czcionki internetowej w arkuszu stylów osadziłem wszystkie typy czcionek oraz woff , woff2 , ttf . Ostatnio zauważyłem, że Chrome anuluje żądanie ttf i woff, gdy woff2 jest obecny. Używam teraz wersji Chrome 66.0.3359.181, ale nie jestem pewien, kiedy Chrome zaczął anulować dodatkowe typy czcionek.

Mieliśmy ten problem z tagiem <button>w formularzu, który miał wysyłać żądanie ajax z js. Ale to żądanie zostało anulowane z powodu przeglądarki, która automatycznie wysyła formularz po każdym kliknięciu w buttonformularzu.

Więc jeśli naprawdę chcesz używać button zamiast zwykłego divlub spanna stronie i chcesz wysłać rzut formularza js - powinieneś skonfigurować detektor z preventDefaultfunkcją.

na przykład

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

    e.preventDefault();

    //do ajax
    $.ajax({

     ...
    });

})

przydarzyło mi się to samo, dzwoniąc pod numer. plik js z $. ajax i złóż zapytanie ajax, to, co zrobiłem, było normalne.

W moim przypadku kod pokazujący okno klienta e-mail spowodował, że Chrome przestał ładować obrazy:

document.location.href = mailToLink;

przeniesienie go do $ (okno) .load (funkcja () {...}) zamiast $ (funkcja () {...}) pomogło.

Czy może to pomóc każdemu, kogo spotkałem anulowany status, gdy pominąłem zwrot fałszywy; w formularzu prześlij. Spowodowało to, że natychmiast po wysłaniu ajax nastąpiła akcja wysyłania, która zastąpiła bieżącą stronę. Kod pokazano poniżej, a ważny zwrot false na końcu.

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

Mam nadzieję, że komuś pomoże.

Dla każdego, kto pochodzi z LoopbackJS i próbuje użyć niestandardowej metody strumieniowej, jak podano w przykładzie z wykresu. Otrzymywałem ten błąd, używając PersistedModelprzełącznika na podstawowy Modelnaprawiłem mój problem zeventsource anulowaniem statusu.

Ponownie dotyczy to interfejsu API sprzężenia zwrotnego. A ponieważ jest to najlepsza odpowiedź i najlepsza w google, pomyślałem, że dodam to do mieszanki odpowiedzi.

Napotkałem ten sam problem, gdzieś głęboko w naszym kodzie mieliśmy ten pseudokod:

• utwórz iframe

• obciążenie iframe wyślij formularz

• Po 2 sekundach usuń ramkę iframe

dlatego gdy serwer potrzebuje więcej niż 2 sekundy, aby odpowiedzieć na element iframe, na który serwer zapisywał odpowiedź, został usunięty, ale odpowiedź wciąż musiała zostać napisana, ale nie było elementu iframe, więc chrome anulował żądanie, dlatego, aby tego uniknąć, upewniłem się, że iframe jest usuwany dopiero po zakończeniu odpowiedzi, lub możesz zmienić cel na „_blank”. Tak więc jednym z powodów jest to, że gdy zasób (w moim przypadku iframe), w którym coś piszesz, jest usuwany lub usuwany, zanim przestaniesz do niego pisać, żądanie zostanie anulowane

Dla mnie stanem „anulowano” było to, że plik nie istniał. Dziwne, dlaczego chrom się nie wyświetla 404.

To było dla mnie tak proste, jak niewłaściwa ścieżka. Sugerowałbym, aby pierwszym krokiem w debugowaniu było sprawdzenie, czy można załadować plik niezależnie od ajax itp.

Żądania mogły zostać zablokowane przez wtyczkę ochrony śledzenia.

Zdarzyło mi się, gdy ładowałem 300 obrazów jako obrazy tła. Zgaduję, że po przekroczeniu limitu czasu pierwszy anulował całą resztę lub osiągnął maksymalną równoczesną prośbę. trzeba wdrożyć 5 na raz

Jednym z powodów może być wywołanie XMLHttpRequest.abort () gdzieś w kodzie, w tym przypadku żądanie będzie miało cancelledstatus na karcie Sieć narzędzi dla programistów Chrome.

W moim przypadku zaczęło się to po aktualizacji Chrome 76.

Z powodu jakiegoś problemu w moim kodzie JS, window.location był aktualizowany wiele razy, co spowodowało anulowanie poprzedniego żądania. Chociaż problem występował wcześniej, Chrome zaczął anulować żądanie po aktualizacji do wersji 76.

Miałem ten sam problem podczas aktualizacji rekordu. Wewnątrz save () przygotowywałem dane surowe pobrane z formularza, aby pasowały do ​​formatu bazy danych (wykonując wiele mapowań wartości wyliczeniowych itp.), A to przerywa anulowanie żądania wprowadzenia. Rozwiązałem go, wyjmując przygotowanie danych z save () i tworząc z niego dedykowaną metodę dataPrep (). Przekształciłem tę funkcję DataPrep w asynchronię i czekam na konwersję danych wymagających dużej ilości pamięci. Następnie zwracam przygotowane dane do metody save (), której mógłbym użyć w kliencie HTTP. Przed wywołaniem metody put upewniłem się, że czekam na dataPrep ():

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

To rozwiązało sporadyczne anulowanie żądania.

Jeśli używasz axiosa, może ci to pomóc

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

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