“LET OP: voorlopige headers worden weergegeven” in Chrome-foutopsporing

Ik zag een vreemd waarschuwingsbericht bij het bekijken van gedownloade bronnen met Google Chrome Inspector (F12):

Let op, voorlopige koppen worden weergegeven

Ik heb iets gevonden dat mogelijk relevant is, Netwerkvenster: voeg voorzichtigheid toe bij een voorlopig verzoek headers, maar ik kon het niet helemaal begrijpen. Gerelateerde vragen zijn te vinden op Chrome-blokverzoekenevenals XMLHttpRequest kan niet worden geladen. Niet-geladen bronnen zijn voorzichtig: voorlopige kopteksten worden weergegeven.

Net als bij de eerste vraag, werd mijn bron geblokkeerd, maar later automatisch dezelfde bron geladen. In tegenstelling tot de tweede vraag, wil ik niet om iets te repareren; Ik wil weten wat dit bericht betekent en waarom ik het heb ontvangen.


Antwoord 1, autoriteit 100%

De bron kan worden geblokkeerd door een extensie (AdBlock in mijn geval).

Het bericht is er omdat het verzoek om die bron op te halen nooit is gedaan, dus de headers die worden weergegeven, zijn niet echt. Zoals uitgelegd in het probleem waarnaar u verwees, worden de echte headers bijgewerkt wanneer de server reageert, maar er is geen reactie als het verzoek is geblokkeerd.


De manier waarop ik de extensie vond die mijn bron blokkeerde, was via de tool net-internals in Chrome:

Voor de nieuwste versies van chrome

  • Typ chrome://net-export/in de adresbalk en druk op enter.
  • Start opnemen. En sla het opnamebestand op lokaal op.
  • Open de pagina die problemen vertoont.
  • Ga terug naar net-internals
  • U kunt het opgenomen logbestand hier bekijken https://netlog-viewer.appspot.com/#import
  • klik op evenementen (###)en gebruik het tekstveld om het evenement te vinden dat gerelateerd is aan je bron (gebruik delen van de URL).
  • Klik ten slotte op het evenement en kijk of de getoonde informatie je iets vertelt.

Voor oudere versies van chrome

  • Typ chrome://net-internalsin de adresbalk en druk op enter.
  • Open de pagina die problemen vertoont.
  • Ga terug naar net-internals, klik op events (###)en gebruik het tekstveld om de gebeurtenis te vinden die betrekking heeft op uw bron (gebruik delen van de URL).
  • Klik ten slotte op het evenement en kijk of de getoonde informatie je iets vertelt.

Antwoord 2, autoriteit 31%

Ik geloof dat het gebeurt wanneer het daadwerkelijke verzoek niet wordt verzonden. Gebeurt meestal wanneer u een bron in de cache laadt.


Antwoord 3, autoriteit 11%

Voor chrome v72+ loste het voor mij alleen dit op:

ga naar chrome://flags/en schakel deze 3 vlaggen uit

  • Site-isolatie uitschakelen
  • Netwerkservice inschakelen
  • Laat de netwerkservice uitvoeren

of je kunt het doen vanaf de opdrachtregel :

chrome --disable-site-isolation-trials --disable-features=NetworkService,NetworkServiceInProcess

waarom gebeurt dit?

Het lijkt erop dat Google hun Chromium-engine ombouwt naar een modulaire structuur, waarbij verschillende services worden opgesplitst in zelfstandige modules en processen. Ze noemen dit processervice. Netwerkservice is de eerste stap, Ui-service, Identity-service en Device-service komen eraan. Google biedt de officiële informatie op de Chromium-projectsite.

is het gevaarlijk om dat te veranderen?

Een voorbeeld is netwerken: zodra we een netwerkservice hebben, kunnen we ervoor kiezen om deze uit het proces te halen voor betere stabiliteit/beveiliging, of in-proces als we beperkte middelen hebben. bron


Antwoord 4, autoriteit 7%

Ik ben dit probleem tegengekomen en ik heb een specifieke oorzaak kunnen identificeren, die hierboven noch in de antwoorden noch in de vraag wordt vermeld.

Ik gebruik een volledige js-stack, hoekige front-end en node-back-end op SSL, en de API bevindt zich op een ander domein dat wordt uitgevoerd op poort 8081, dus ik doe CORS-verzoeken en met referenties terwijl ik een sessiecookie van de API

Dus specifiek was mijn scenario: POST-verzoek, met referenties naar poort 8081 veroorzaakte het bericht “LET OP: voorlopige headers worden getoond” in de inspecteur en blokkeerde natuurlijk ook het verzoek allemaal samen.

Mijn oplossing was om Apache op te stellen op Proxy Pass het verzoek van de gebruikelijke SSL-poort van 443 naar de Node SSL-poort van 8081 (NODE moet op een hogere poort zijn omdat het niet als root in prod kan worden uitgevoerd). Dus ik denk dat Chrome niet van SSL-aanvragen aan onconventionele SSL-poorten houdt, maar misschien kan hun foutmelding specifieker zijn.


5, Autoriteit 4%

Dit kan ook (alleen voor cross-origin-aanvragen) gebeuren) vanwege een nieuwe functie genaamd Site isolatie

Deze pagina geeft de kwestie en een Werk – rondom . Dat is om naar chrome://flags/#site-isolation-trial-opt-outin chrome en verander die instelling om te “opt-out” en herlaad chroom.

Het is een bekende probleem . Maar die pagina zegt dat het in Chrome 68 is bevestigd, maar ik gebruik Chrome 68 en ik heb nog steeds het probleem.


Antwoord 6, autoriteit 3%

HTTP/2 gepushte bronnenproduceren Provisional headers are shownin de inspecteur voor dezelfde theorie als @wvega gepost in zijn antwoord hierboven.

bijv:aangezien de server de bron(nen) naar de client heeft gepusht (voordat de client ze heeft aangevraagd), heeft de browser de bronnen in de cache opgeslagen en daarom heeft de client nooit doet/heeft een verzoek nodig; Dus omdat…

…de echte headers worden bijgewerkt wanneer de server reageert, maar er is geen reactie als het verzoek is geblokkeerd.


Antwoord 7, autoriteit 2%

Ik betwijfel of mijn antwoord op tijd is om je te helpen, maar anderen kunnen het misschien nuttig vinden. Ik heb een soortgelijk probleem ondervonden met een jQuery Ajax Post-script dat ik heb gemaakt.

Het bleek dat ik een typefout had gemaakt in het href-attribuut van de A-tag die ik gebruikte om de post te activeren. Ik had href=”javacscript:;” getypt (het omkeren van de ‘s’ en de ‘c’ ).. dit zorgde ervoor dat het script probeerde de pagina te vernieuwen terwijl de post probeerde te vuren. de typefout gecorrigeerd en het werkte prima voor mij.


Antwoord 8

Dit bericht kan verschijnen wanneer de website is beveiligd met HSTS. Wanneer iemand vervolgens naar de HTTP-versie van de URL linkt, geeft de browser, zoals geïnstrueerd door HSTS, geen HTTP-verzoek uit, maar wordt intern veilig doorverwezen naar de HTTPS-bron. Dit is om HTTPS-downgrade-aanvallen zoals sslstripte voorkomen.


Antwoord 9

Dat kan omdat u een AJAX-verzoek hebt verzonden, tegelijkertijd springt u uw pagina naar een andere met behulp van locatie.href of zoiets als dat. Dus het vorige verzoek is mislukt.


10

Dit voorzichtigheidsboodschap treedt ook voor als het antwoord ongeldig is en daarom door de browser is gevallen.

In mijn geval is het verzoek correct verzonden naar de server, de server-zijcode produceerde vervolgens een fout en mijn aangepaste foutafhandeling heeft het foutbericht geretourneerd in het veld HTTP-statusbericht. Maar deze fout is niet ontvangen op de clientzijde, vanwege ongeldige tekens in het foutbericht (hier beschreven http: / /aspnetwebstack.codeplex.com/workitem/1386 ) wat resulteerde in corrupte responskoppen.


11

Ik liep dit probleem in met een AJAX-oproep die nooit zou voltooien. Ik volgde WVEGA’s advies en fooi over het debuggen met chrome://net-internalsom uiteindelijk een andere clickEvenement Handler op de pagina, het luisteren naar een ouderknooppunt, het Browser om naar dezelfde URL te navigeren (dus het was niet gemakkelijk merkbaar).

De oplossing was om event.stopPropagation()in een clickHandler op de knop Dient u op om het klik te houden van het opborrelen van de DOM en het annuleren van het AJAX-verzoek aan de gang (geïnitieerd via een submithandler op de form).


12

Ik heb dit heel recentelijk (in feite vandaag) gehad, waarbij een AJAX-oproep naar de server ging en Chrome de melding ‘Let op: voorlopige headers worden weergegeven’ activeert. In de PHP-scripting aan de serverzijde zijn er MySQL-query’s die vrijwel direct kunnen zijn of een paar seconden kunnen duren, afhankelijk van het gegeven scenario. Mijn serverreactie wordt pas teruggestuurd naar de browser als de query’s zijn voltooid. Ik heb gemerkt dat ik deze foutmelding alleen krijg wanneer tijdrovende vragen (tot een paar seconden in totaal) worden gedaan en voorkomen dat het antwoord wordt teruggestuurd.

Mijn scenario omvat de zeer zeldzame mogelijkheid dat een tabel moet worden gewijzigd door honderden kolommen toe te voegen/te verwijderen voor de uitvoer van het weermodel… vandaar de vertraging in de respons van het doorlopen van een lus van ALTER TABLE-query’s.


Antwoord 13

Een veelvoorkomende reden waarom dit gebeurt, is als u een gebeurtenis bijhoudt en u de standaardactie niet verhindert. Als u bijvoorbeeld een klikgebeurtenis heeft, wilt u het volgende opnemen:

e.preventDefault();

of

return false;

Als u dat niet doet, ziet u de voorlopige koptekstwaarschuwing en de status ‘geannuleerd’ op het tabblad Netwerk van uw webconsole.


Antwoord 14

In mijn geval was het gewoon een verkeerd ingesteld pad naar een bron (svg / img)


Antwoord 15

Dit probleem deed zich voor toen ik een ongeldige HTTP-autorisatieheader verzond. Ik ben vergeten het met base64 te coderen.


Antwoord 16

Ik kwam dit tegen en het verdween toen ik overschakelde van https naar http. De SSL-certificaten die we gebruiken in dev zijn niet geverifieerd door een derde partij. Het zijn gewoon lokaal gegenereerde ontwikkelaarscertificaten.

Dezelfde oproepen werken prima in Chrome Canary en Firefox. Deze browsers lijken niet zo streng te zijn over het SSL-certificaat als Chrome. De aanroepen zouden mislukken in Chrome met het bericht “LET OP: voorlopige kopteksten…”.

Ik denk/hoop dat wanneer we een legitiem SSL-certificaat gebruiken in stage en prod, we dit gedrag niet meer zullen zien in Chrome.


Antwoord 17

Gewoon even mijn twee cent erin gooien. Ik schrijf een webtoepassing met behulp van CORS-verzoeken en een volledige RESTful-webservice. Ik heb ontdekt dat Chrome deze foutmelding geeft als ik een niet-overhandigde uitzondering of een PHP-fout krijg. Voor het geval iemand anders tegen het probleem aanloopt. Ik ontdekte dat wanneer dit gebeurt, ik de Chrome-app “Postman – Rest Client” kan starten en exact hetzelfde verzoek kan uitvoeren, maar in de Chrome-app krijg ik de PHP-fout die wordt gegenereerd in plaats van deze niet-beschrijvende fout.


Antwoord 18

Ik heb dit probleem uitgevoerd toen ik main.js voor de tweede keer probeerde te laden omdat ik js nodig had nadat ik wijzigingen had aangebracht als gevolg van een fout .
Ik heb zojuist in Developer Tools Settings “Cache uitschakelen (wanneer DevTools is geopend)” ingeschakeld.
en dat deed de charme.


Antwoord 19

Een ander mogelijk scenario dat ik heb gezien: exact hetzelfde verzoek wordt na een paar milliseconden opnieuw verzonden (waarschijnlijk als gevolg van een bug aan de clientzijde).
In dat geval zie je ook dat de status van het eerste verzoek “geannuleerd” is en dat de latentie slechts enkele milliseconden is.


Antwoord 20

Dit gebeurde bij mij, toen ik een downloadlink had en nadat ik erop had geklikt, probeerde ik ook de klik op te vangen met jQuery en een ajax-verzoek te verzenden. Het probleem was dat wanneer je op de downloadlink klikt, je de pagina verlaat, zelfs als het er niet zo uitziet. Als er geen bestandsoverdracht zou zijn, zou je de gevraagde pagina zien. Dus ik heb een target=”_blank” ingesteld om dit probleem te voorkomen.


Antwoord 21

Ik heb deze foutmelding toen ik probeerde een pagina in een pop-up af te drukken. Het dialoogvenster Afdrukken was tonen en het wacht nog steeds mijn acceptatie of annulering van het afdrukken in de pop-up terwijl in de hoofdpagina op de achtergrond wachtte op de achtergrond met het bericht Let op Voorzichtige kopers worden weergegeven Toen ik probeerde te klikken een andere link.

In mijn geval was de oplossing om de window.print ();script dat het op de <body>van het pop-upvenster uitvoerde om te voorkomen Dialoogvenster afdrukken.


22

Ik zag dit optreden wanneer het aantal verbindingen met mijn server de MAX-connections-per-serverlimiet van 6.

heeft overtroffen


23

Gebruik deze code fist van uw code:

header('Cache-Control: no-cache, no-store, must-revalidate');
header('Pragma: no-cache');
header('Expires: 0');

Dit werkt voor mij.


24

In mijn geval was de oorzaak Adblock-extensie.

Het verzoek aan de server ging door en ik kreeg het antwoord, maar ik kon de aanvraagkoekjes niet zien als gevolg van “voorlopige headers ..” wordt getoond in Dev-gereedschappen. Na het uitschakelen van adblock voor de site, ging de waarschuwing weg en begonnen Dev-tools de cookies opnieuw te tonen.

Voor de wijziging van het gevolg is, was het ook noodzakelijk om de Dev-gereedschappen te sluiten en de pagina

te vernieuwen


25

De reden waarom deze header wordt weergegeven, is dat: uw verzoek niet verzonden naar afgelegen.

Het wordt meestal veroorzaakt door

  1. Extension heeft uw verzoek blokkeert
  2. Chrome Gebruik eigen cache om uw bron te halen

Chrome kan uw aanvraagopdrachten niet krijgen van een verzoek dat niet heeft gemaakt.

Een recente versie van Chrome heeft dit aangeven:

Alleen voorlopige kopers zijn beschikbaar omdat dit verzoek niet via het netwerk is verzonden en in plaats daarvan werd geserveerd vanaf een lokale cache,
die de oorspronkelijke verzoekheaders niet opslaat.

Cache uitschakelen om volledige verzoekheaders te zien


Antwoord 26

Hier is een andere oplossing.

Als je dit probleem tegenkomt met $ajax() aanroep, voeg dan http://toe voordat je serverhost je probleem oplost.

var requestURL = "http://" + serverHost;
$.ajax({
    dataType: "json",
    url: requestURL,
    data: data,
    success: success    
});

Antwoord 27

Als u een Asp.Net Mvc-toepassing ontwikkelt en u probeert een JsonResultin uw controller te retourneren, zorg er dan voor dat u JsonRequestBehavior.AllowGettoevoegt aan de Jsonmethode. Dat loste het voor mij op.

public JsonResult GetTaskSubCategories(int id)
{
    var subcategs = FindSubCategories(id);
    return Json(subcategs, JsonRequestBehavior.AllowGet);  //<-- Notice it has two parameters
}

Antwoord 28

Het bericht “Let op: voorlopige headers worden weergegeven” kan worden weergegeven wanneer een website die wordt gehost op HTTPS een oproep oproept naar WebApi die wordt gehost op HTTP. U kunt alles controleren of al uw Api’s HTTPS zijn. Browser voorkomt een oproep naar een onveilige bron. U kunt een soortgelijk bericht in uw code zien wanneer u FETCH API gebruikt voor domein met HTTP.

Gemengde inhoud: de pagina op ‘https://website.com‘ is geladen via HTTPS, maar verzocht om een onveilige bron ‘http://webapi.com‘. Dit verzoek is geblokkeerd; de inhoud moet worden aangeboden via HTTPS.


Antwoord 29

Ik had een soortgelijk probleem met mijn MEAN-app. In mijn geval deed het probleem zich voor in slechts één get-verzoek. Ik probeerde met het verwijderen van adblock, probeerde het cachegeheugen te wissen en probeerde het met verschillende browsers. Niets hielp.

Ten slotte ben ik erachter gekomen dat de api probeerde een enorm JSON-object te retourneren. Toen ik probeerde een klein object te verzenden, werkte het prima. Ten slotte heb ik mijn implementatie gewijzigd om een buffer terug te geven in plaats van een JSON.

Ik wil dat expressJS in dit geval een foutmelding geeft.

Other episodes