Wat betekent status=canceled voor een bron in Chrome Developer Tools?

Waarom zou een pagina worden geannuleerd? Ik heb een screenshot van de Chrome Developer Tools.

Dit gebeurt vaak, maar niet elke keer. Het lijkt erop dat als een aantal andere bronnen eenmaal in de cache zijn opgeslagen, een paginavernieuwing de LeftPane.aspx zal laden. En wat echt vreemd is, is dat dit alleen gebeurt in Google Chrome, niet in Internet Explorer 8. Enig idee waarom Chrome een verzoek zou annuleren?

Antwoord 1, autoriteit 100%

We hebben een soortgelijk probleem bestreden waarbij Chrome verzoeken annuleerde om dingen binnen frames of iframes te laden, maar slechts af en toe en het leek afhankelijk van de computer en/of de snelheid van de internetverbinding.

Deze informatie is een paar maanden verouderd, maar ik heb Chromium helemaal opnieuw gebouwd, door de bron gegraven om alle plaatsen te vinden waar verzoeken konden worden geannuleerd, en ik heb op al deze breekpunten gezet om fouten op te sporen. Uit het geheugen, de enige plaatsen waar Chrome een verzoek annuleert:

• Het DOM-element dat ervoor zorgde dat het verzoek werd gedaan, is verwijderd (d.w.z. er wordt een IMG geladen, maar voordat het laden plaatsvond, hebt u het IMG-knooppunt verwijderd)
• Je hebt iets gedaan waardoor het laden van de gegevens niet nodig was. (d.w.z. je bent begonnen met het laden van een iframe en vervolgens de src gewijzigd of de inhoud overschreven)
• Er gaan veel verzoeken naar dezelfde server, en een netwerkprobleem bij eerdere verzoeken toonde aan dat volgende verzoeken niet zouden werken (DNS-opzoekfout, eerdere (dezelfde) aanvraag resulteerde bijv. HTTP 400-foutcode, enz.)

In ons geval hebben we het uiteindelijk getraceerd naar een frame dat probeerde HTML aan een ander frame toe te voegen, wat soms gebeurde voordat het doelframe zelfs maar was geladen. Zodra je de inhoud van een iframe aanraakt, kan het de bron er niet meer in laden (hoe zou het weten waar het het moet plaatsen?) Dus annuleert het het verzoek.

Antwoord 2, autoriteit 10%

status=cancelled kan ook gebeuren bij ajax-verzoeken op JavaScript-evenementen:

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

De gebeurtenis verzendt het verzoek met succes, maar wordt dan geannuleerd (maar verwerkt door de server). De reden is dat de elementen formulieren indienen voor klikgebeurtenissen, ongeacht of u ajax-verzoeken doet voor dezelfde klikgebeurtenis.

Om te voorkomen dat het verzoek wordt geannuleerd, moet JavaScript event.preventDefault();worden aangeroepen:

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

Antwoord 3, autoriteit 6%

NB: zorg ervoor dat u geen omloopformulierelementenheeft.

Ik had een soortgelijk probleem waarbij mijn knop met onclick={} was verpakt in een formulierelement. Als je op de knop klikt, wordt het formulier ook verzonden, en dat verpest het allemaal…

Antwoord 4, autoriteit 2%

Een ander ding om op te letten, kan de AdBlock-extensie zijn, of extensies in het algemeen.

Maar “veel” mensen hebben AdBlock….

Om extensie(s) uit te sluiten, opent u een nieuw tabblad in incognito en zorgt u ervoor dat ‘incognito toestaan ​​is uitgeschakeld’ voor de extensie(s) die u wilt testen.

Antwoord 5, autoriteit 2%

In mijn geval ontdekte ik dat het de globale time-outinstellingen voor jQuery zijn, een globale time-out voor het instellen van jQuery-plug-ins tot 500 ms, zodat wanneer het verzoek de 500 ms overschrijdt, Chrome het verzoek annuleert.

Antwoord 6, autoriteit 2%

Misschien wil je de header-tag “X-Frame-Options” controleren. Als het is ingesteld op SAMEORIGIN of DENY, wordt het invoegen van iFrame geannuleerd door Chrome (en andere browsers) volgens de spec.

Houd er rekening mee dat sommige browsers de ALLOW-FROM-instelling ondersteunen, maar Chrome niet.

Om dit op te lossen, moet u de header-tag “X-Frame-Options” verwijderen. Dit kan u blootstellen aan clickjacking-aanvallen, dus u zult moeten beslissen wat de risico’s zijn en hoe u deze kunt verkleinen.

Antwoord 7

Dit is wat er met mij is gebeurd: de server retourneerde een verkeerd opgemaakte “Locatie”-header voor een 302-omleiding.
Chrome heeft me dit natuurlijk niet verteld. Ik opende de pagina in Firefox en ontdekte meteen het probleem.
Leuk om meerdere tools te hebben 🙂

Antwoord 8

Een andere plaats waar we de status (canceled)zijn tegengekomen, is een verkeerde configuratie van een TLS-certificaat. Als een site zoals https://www.example.comverkeerd is geconfigureerd, zodat het certificaat niet de www.bevat, maar geldig is voor https://example.com, zal chrome dit verzoek annuleren en automatisch doorverwijzen naar de laatstgenoemde site. Dit is niethet geval voor Firefox.

Momenteel geldig voorbeeld: https://www.pthree.org/

Antwoord 9

Er is mij een geannuleerd verzoek overkomen bij het omleiden tussen beveiligde en niet-beveiligde pagina’s op afzonderlijke domeinen binnen een iframe. Het omgeleide verzoek werd in dev-tools weergegeven als een “geannuleerd” verzoek.

Ik heb een pagina met een iframe met een formulier dat wordt gehost door mijn betalingsgateway. Toen het formulier in het iframe werd ingediend, zou de betalingsgateway terugverwijzen naar een URL op mijn server. De omleiding werkte onlangs niet meer en eindigde in plaats daarvan als een “geannuleerd” verzoek.

Het lijkt erop dat Chrome (ik gebruikte Windows 7 Chrome 30.0.1599.101) niet langer toestond dat een omleiding binnen het iframe naar een niet-beveiligde pagina op een apart domein ging. Om het op te lossen, heb ik ervoor gezorgd dat alle omgeleide verzoeken in het iframe altijd naar beveiligde URL’s werden verzonden.

Toen ik een eenvoudigere testpagina maakte met alleen een iframe, stond er een waarschuwing in de console (die ik eerder had gemist of misschien niet kwam opdagen):

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

De omleiding veranderde in een geannuleerd verzoek in Chrome op pc, Mac en Android. Ik weet niet of het specifiek is voor mijn websiteconfiguratie (SagePay Low Profile) of dat er iets is veranderd in Chrome.

Antwoord 10

Chrome-versie 33.0.1750.154 m annuleert consequent het laden van afbeeldingen als ik de Mobile Emulationwees naar mijn localhost; specifiek met User Agent-spoofing aan(vs. alleen Scherminstellingen).

Als ik User Agent-spoofing uitzet; beeldverzoeken worden niet geannuleerd, ik zie de afbeeldingen.

Ik begrijp nog steeds niet waarom; in het eerste geval, waar het verzoek wordt geannuleerd, hebben de verzoekheaders (LET OP: voorlopige headers worden weergegeven) alleen

• Accepteren
• Cachebeheer
• Pragma
• Verwijzer
• Gebruikersagent

In het laatste geval houden al die plus anderen van:

• Koek
• Verbinding
• Gastheer
• Accepteren-codering
• Taal accepteren

Houd je schouders op

Antwoord 11

Ik kreeg deze foutmelding in Chrome toen ik omleidde via JavaScript:

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

Zoals je ziet Ik ben de ‘http://’vergeten. Nadat ik het had toegevoegd, werkte het.

Antwoord 12

Voor mijn geval had ik een anker met klikgebeurtenis zoals

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

Binnen klikgebeurtenis Ik heb een netwerkoproep gehad, Chrome annuleerde het verzoek. Het anker heeft hrefmet ""betekent dat het de pagina opnieuw laadt en tegelijkertijd een klikgebeurtenis heeft met een netwerkoproep die wordt geannuleerd. Telkens wanneer ik de hrefvervang door void zoals

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

Het probleem is verdwenen!

Antwoord 13

Hier is een ander geval van aanvraag geannuleerd door Chrome, die ik net ben tegengekomen, die niet onder een van de antwoorden wordt gedekt. ​​

in een notendop
Zelfondertekend certificaat dat niet wordt vertrouwd op mijn Android-telefoon.

Details
We zijn in ontwikkeling / debugfase. De URL wijst naar een zelfondertekende host. De code is als:

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

Chrome geannuleerd het verzoek zwijgend, waardoor geen aanwijzing voor newbie naar webontwikkeling zoals ik is om het probleem op te lossen. Zodra ik het certificaat heb gedownload en geïnstalleerd met behulp van de Android-telefoon is het probleem verdwenen.

14

Als u AXIOS gebruikt, kan het u helpen

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


https://github.com/axios/axios#config-order -van-precedentie

15

Ik had geconfronteerd met hetzelfde probleem, ergens diep in onze code hadden we deze pseudocode:

• Maak een iframe

• Onload van IFRAME Dien een formulier in

• Verwijder na 2 seconden de IFRAME

Dus wanneer de server meer dan 2 seconden duurt om de IFRAME te reageren waarnaar de server het antwoord was, werd verwijderd, maar het antwoord was nog te geschreven, maar er was geen IFRAME om te schrijven, dus Chrome geannuleerd Het verzoek, dus om dit te voorkomen, zorgde ik ervoor dat de IFRAME alleen wordt verwijderd nadat het antwoord voorbij is, of u kunt het doelwit wijzigen op “_blank”.
Dus een van de reden is:
Wanneer de bron (iframe in mijn geval) is waarop u iets in het schrijven bent, wordt verwijderd of verwijderd voordat u stopt met schrijven, wordt het verzoek geannuleerd

16

Ik heb alle soorten lettertypen ingesloten, evenals WOFF , Woff2 , TTF wanneer ik een weblettertype in stijlblad insluit. Onlangs heb ik gemerkt dat Chrome annuleert om TTF en Woff Toen Woff2 aanwezig is. Ik gebruik nu Chrome versie 66.0.3359.181, maar ik weet niet zeker wanneer Chrome begon met het annuleren van extra lettertypes.

17

We hadden dit probleem met tag <button>in het formulier, dat is verondersteld AJAX-verzoek van JS te verzenden. Maar dit verzoek is geannuleerd, vanwege browser, die automatisch formulier verzendt op een klik op buttonin het formulier.

Dus als u echt wilt gebruiken buttonin plaats van gewone divof spanop de pagina, en u wilt formulier gooien JS verzenden – U moet een luisteraar instellen met preventDefaultFunctie.

b.g

$('button').on('click', function(e){
    e.preventDefault();
    //do ajax
    $.ajax({
     ...
    });
})

18

Ik had precies hetzelfde met twee CSS-bestanden die werden opgeslagen in een andere map buiten mijn hoofd CSS-map. Ik gebruik expressiemotor en vond dat het probleem in de regels in mijn HTAccess-bestand was. Ik heb de map gewoon toegevoegd aan een van mijn voorwaarden en het heeft het opgelost. Hier is een voorbeeld:

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

Het is misschien de moeite waard om uw HTAccess-bestand te controleren op mogelijke conflicten

19

gebeurde mij hetzelfde bij het bellen. JS-bestand met $. Ajax, en maak een AJAX-verzoek, wat ik deed, was normaal gesproken.

20

In mijn geval de code om het e-mailclientvenster te tonen, veroorzaakt chroom om te stoppen met het laden van afbeeldingen:

document.location.href = mailToLink;

het verplaatsen naar $ (venster). last (functie () {…}) in plaats van $ (functie () {…}) geholpen.

21

In kan dit iedereen helpt die ik de geannuleerde status heb tegengekomen toen ik het rendement niet vals wegging; in het formulier indienen. Dit zorgde ervoor dat de AJAX verzenden onmiddellijk wordt gevolgd door de handelingsactie, die de huidige pagina overschrijdt. De code wordt hieronder weergegeven, met het belangrijke retourners aan het einde.

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

Ik hoop dat het iemand helpt.

22

voor iedereen die uit loopbackjs komt en probeert de aangepaste stroommethode te gebruiken zoals in hun grafiekvoorbeeld. Ik kreeg deze foutmelding met behulp van een PersistedModel, omschakelen naar een basis ModelVaste mijn nummer van de eventsourceStatus annuleren.

Nogmaals, dit is specifiek voor de Loopback-API. En aangezien dit een topantwoord en de top op Google is, dacht ik dat ik dit in de mix van antwoorden gooi.

23

Voor mij ‘geannuleerde’ status was omdat het bestand niet bestond. Vreemd is waarom Chrome niet wordt weergegeven 404.

24

Het was zo simpel als een onjuist pad voor mij. Ik zou voorstellen dat de eerste stap in debugging zou zijn om te zien of u het bestand onafhankelijk van Ajax enz. Kunt laden.

25

De verzoeken zijn mogelijk geblokkeerd door een trackingbeveiligingsplugin.

26

Het is me overkomen bij het laden van 300 afbeeldingen als achtergrondafbeeldingen. Ik vermoed dat het eenmaal eerst is verlopen, het heeft al de rest geannuleerd of bereikte Max Concurrent verzoek. moet een 5-at-a-time

implementeren

27

Een van de redenen kan dat zijn dat de xmlhttproquest.abort ( ) werd ergens in de code gebeld, in dit geval, het verzoek heeft de cancelled-status in het tabblad Tabblad Chrome Developer Tools.

28

In mijn geval begon het na Chrome 76-update te komen.

Vanwege een bepaald probleem in mijn JS-code, werd venster.locatie meerdere keren bijgewerkt, wat resulteerde in het annuleren van het vorige verzoek.
Hoewel het probleem van vóór eerder aanwezig was, begon Chrome het verzoek na update naar versie 76 te annuleren.

29

Ik had hetzelfde probleem bij het bijwerken van een record. Binnenin de Save () Ik heb de RawData voorbereid gemaakt uit het formulier dat overeenkomt met het database-formaat (dat veel in kaart brengen van ENUMS-waarden, enz.), En dit annuleert met tussenpozen het PUT-verzoek. Ik heb het opgelost door de gegevens van het preppen van de opslaan () uit te schakelen en een speciale dataprep () -methode uit te maken. Ik veranderde deze dataprep in Async en wacht op alle geheugenintensieve data-conversie. Vervolgens retourneer ik de voorafgaande gegevens naar de methode opslaan () die ik in de HTTP Put Client kan gebruiken. Ik zorgde ervoor dat ik wacht op Dataprep () voordat ik de Put-methode oproept:

wachten op datatoupdate = wachten op dataprep ();
http.put (apiurl, datatoupdate);

Dit lost de intermitterende annulering van het verzoek op.