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


402

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

Anulowano zasób

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?


13
Możesz być w stanie uzyskać więcej szczegółów ze śladu wewnętrznej sieci . Miałem podobny problem i stwierdziłem w moim przypadku, że anulowano net::ERR_ABORTEDpod przykryciem. W takim przypadku ten post wyjaśnia, że ​​„net :: ERR_ABORTED ma być generowany tylko wtedy, gdy akcja użytkownika spowoduje przerwanie ładowania. Może się to zdarzyć, gdy nowa nawigacja przerwie istniejącą lub gdy użytkownik kliknie STOP przycisk."
John McCarthy

Dzięki. W moim przypadku nie jest to użytkownik, ponieważ jestem użytkownikiem. Strona ma (zbyt) wiele ramek. Może rama src zostanie zmieniona? Dziwne, że nigdy nie widziałem, żeby to się wydarzyło w IE. Zajrzę do wewnętrznych elementów sieci.
styfle

@ nondescript1 Wykonałem przechwytywanie podczas odtwarzania błędu i zrzuciłem do pliku. Teraz mam plik json o wielkości 18 000 wierszy. Czego szukam
styfle

3
Naprawdę nie wiem. Właściwie natknąłem się na twoje pytanie, kiedy szukałem więcej informacji o statusie = sam się anulowałem, dlatego dodam tylko komentarze, a nie odpowiedź;). Nie mam powodu sądzić, że ma to związek z buforowaniem. Jestem bardziej podejrzliwy wobec innej osoby zainicjowanej przez nawigację na stronie. Kiedy to zobaczyłem, próbowałem zainicjować pobieranie za pomocą window.open (), co spowodowało anulowanie kolejnego żądania serwera. W moim przypadku Firefox nie miał tego problemu, ale Chrome tak.
John McCarthy

1
Aby nie było oczywiste, jedną z możliwych przyczyn „(anulowane)” w kolumnie statusu - choć zdecydowanie nie jedyną możliwą przyczyną - jest to, że podany adres URL zwrócił błąd 404 lub inny. Wymuś kilkakrotnie odśwież adres URL na innej karcie, aby upewnić się, że ładuje się on konsekwentnie.
rakslice,

Odpowiedzi:


592

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.


2
Bardzo pouczające, dziękuję. Trudno jest mi odtworzyć ten błąd, ponieważ gdy rzeczy zostaną zbuforowane, to się nie dzieje. Jeśli ustawię punkt przerwania w moim javascript, tak się nie stanie. Twój pierwszy punkt nie jest prawdopodobnie problemem, ponieważ nie widzę elementu usuwanego. Wiem na pewno, że nie jest to punkt 3. Co rozumiesz przez „Po dotknięciu zawartości elementu iframe nie można już załadować do niego zasobu”? Czy możesz podać przykład?
styfle

1
Ciekawy. Muszę więc znaleźć wszystkie document.writes do tej ramki i upewnić się, że piszą tylko, gdy ramka jest załadowana. Oznaczę to jako prawidłową odpowiedź, ponieważ odpowiedziałeś na znaczenie tego statusu.
styfle,

3
@styfle Tak, ale może to być także coś innego niż document.write. Prawdopodobnie spowodowałoby to wszystko, co próbuje pisać do ramki, takie jak appendChild lub podobne. Możesz utworzyć moduł obsługi onLoad w każdej ramce, która zapisuje truedo jakiejś zmiennej, a następnie inne ramki najpierw szukają tej zmiennej, zanim cokolwiek dotkniesz.
whamma,

14
Miałem też z tym okropne problemy. Znalazłem jedną rzecz, która konsekwentnie powoduje to, jeśli odpowiedź AJAX ma kod stanu 301/302, a URL przekierowania znajduje się w innej domenie. Jest to dla mnie spójne odtworzenie problemu.
eb80 11.10.13

1
Dla mnie był to iframe dołączany do ciała, a następnie natychmiast usuwany z ciała. Położyłem linię podziału i problemu nie było. Więc ustaw trochę czasu (15 ms) i go pokonaj. @whamma to naprawdę motywuje sposób, w jaki rozwiązałeś ten problem. Dzięki za tak wspaniałe, szczegółowe szczegóły. :-)
bazylia

53

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>

3
To mnie uratowało, był problem w moim przypadku, w którym użyłem kątownika ng-clickna przycisku z, type="submit"a następnie zrobiłem trochę sieci w wywołanej funkcji. Chrome ciągle anulował tę prośbę ...
Robin

1
Niestety to nie działa dla mnie. Wszelkie inne wskazówki?
Krzysztof Madej

Vaov też mnie uratował! W przypadku zdarzenia kątowego kliknięcia zagnieżdżono żądania $ http, a drugie zostało anulowane. Po ustawieniu domyślnej linii zapobiegania znów zaczęła działać, dzięki.
Bahadir Tasdemir

Dzięki za to. Wiedziałem, że to nie jest problem CORS ani DOM. Być może @whamma mogłaby zaktualizować swoją odpowiedź, aby uwzględnić to jako możliwą przyczynę kompletności :)
glidester

Witajcie Pana !! Sir, jesteś absolutnym geniuszem !! Zostałem uratowany !!
Dilnoor Singh

25

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ć :)


To była dla mnie główna przyczyna - przycisk dwukrotnie wywołał POST. Nie chciałem przenosić przycisku poza element formularza z powodu CSS, więc takie było rozwiązanie: stackoverflow.com/questions/932653/...
Nikolai Koudelia

Ten sam problem. Aby to wyjaśnić, miałem przycisk zawarty w formularzu z typem przesyłania, ale miałem kliknięcie, które wykonywało przesłanie formularza zapytania, przedłożenie ajax. Działało to w FF, ale zawiodło w chome i IE i doprowadzało mnie do szału, dopóki go nie znalazłem.
ChrisThompson,

Rozwiązuje to problem, który mi się przydarzył w aplikacji Vue.js, w której @clickzdarzenie było powiązane z <button>elementem wewnątrz opakowania formularza. Unikaj tego, chyba że używasz @submit.preventmodyfikatora zdarzeń Vue .
Paul Wenzel

Tak było w moim przypadku. Dodając type="button"do mojego tagu przycisku, formularz nie został przesłany, a anulowane zdarzenie zostało uniknięte.
Brandon Medenwald

12

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ć.


Dokładnie co się stało. Włączyłem wtyczkę noscript i nagle iFrame już się nie ładował.
Margus Pala

Dla mnie była to wtyczka Hola. Po wyłączeniu żądania nie są już anulowane.
Lenin Raj Rajasekaran

1
W moim przypadku było to chromowane rozszerzenie „JavaScript Errors Notifier”
Alex

Próbowałem zaglądać we wszystko i nadal nie miałem szczęścia z Angular 8, wyłączyłem wszystkie rozszerzenia i nadal w wolnej sieci 3G poprzednie połączenia są anulowane. :(
born2net

10

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ć.


To był dokładnie mój problem. Wątek ma dobre odpowiedzi, jak to naprawić: stackoverflow.com/questions/6666423/…
ToniTornado

8

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.


Występuje ten sam problem. W moim przypadku jest to lokalny rozwój WordPress / WooCommerce z serwerem gościa VirtualBox, a niektóre żądania AJAX WooCommerce mają wstępnie zdefiniowany limit czasu AJAX wynoszący 5000 ms. Jeśli ktoś napotkał ten sam problem, ten limit czasu zdefiniowano w includes/class-wc-frontend-scripts.phppliku.
Ivan Shatsky

7

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 :)


Chociaż jest to bardzo oczywiste co do przyczyny, ale wciąż jest to bardzo przydatna odpowiedź. Edytowałem stary kod kawy i całkowicie zapomniałem, że pojedyncze cudzysłowy nie #{}interpolują, więc powstały adres URL był zniekształcony. Ale Chrome nic mi o tym nie powiedział.
kumarharsh

4

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/


czy w zasadzie możesz po prostu przekierować z domeny innej niż certyfikat do domeny certyfikowanej? od nagiego do www? czy zawsze widzisz błąd anulowania lub certyfikatu?
Konstantin Vahrushev

3

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.


Widzę prawie identyczne zachowanie w Chrome 30 podczas korzystania z usług płatniczych hostowanych przez Datacash, ale w moim przypadku test POST z witryny 3dsecure do witryny Datacash został anulowany, mimo że oba są https. To okazuje się być tajemnicą.
Jason

2

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


2

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.


2

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ął!


2

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ął.


2

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.


1

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


1

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.


1

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({

     ...
    });

})

0

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.


0

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.


0

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.


0

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.


0

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


0

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


0

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.


0

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


0

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



0

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.


0

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.


Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.