"VORSICHT: Vorläufige Header werden angezeigt" im Chrome-Debugger

Beim Anzeigen heruntergeladener Ressourcen mit Google Chrome Inspector ( F12) ist mir eine seltsame Warnmeldung aufgefallen :

Achtung vorläufige Header werden angezeigt

Ich habe etwas möglicherweise Relevantes gefunden, Network Panel: Vorsicht bei vorläufigen Anforderungsheadern , aber ich konnte es nicht vollständig verstehen. Verwandte Fragen finden Sie unter Chrome-Blockanforderungen sowie XMLHttpRequest kann nicht geladen werden. Entladene Ressourcen sind vorsichtig: Vorläufige Header werden angezeigt .

Ähnlich wie bei der ersten Frage wurde meine Ressource blockiert, aber später automatisch dieselbe Ressource geladen. Im Gegensatz zur zweiten Frage möchte ich nichts reparieren. Ich möchte wissen, was diese Nachricht bedeutet und warum ich sie erhalten habe.

Die Ressource könnte durch eine Erweiterung blockiert werden (in meinem Fall AdBlock).

Die Nachricht ist da, weil die Anforderung zum Abrufen dieser Ressource nie gestellt wurde, sodass die angezeigten Header nicht der Realität entsprechen. Wie in dem von Ihnen genannten Problem erläutert, werden die tatsächlichen Header aktualisiert, wenn der Server antwortet. Es erfolgt jedoch keine Antwort, wenn die Anforderung blockiert wurde.

Die Art und Weise, wie ich über die Erweiterung, die meine Ressource blockierte, herausgefunden habe, war über das Net-Internals-Tool in Chrome:

Für die neuesten Chromversionen

• Geben Sie chrome://net-export/die Adressleiste ein und drücken Sie die Eingabetaste.
• Starte die Aufnahme. Und speichern Sie die Aufnahmedatei lokal.
• Öffnen Sie die Seite, auf der Probleme angezeigt werden.
• Gehen Sie zurück zu Net-Internals
• Sie können die aufgezeichnete Protokolldatei hier anzeigen: https://netlog-viewer.appspot.com/#import
• Klicken Sie auf Ereignisse (###) und verwenden Sie das Textfeld, um das Ereignis zu finden, das sich auf Ihre Ressource bezieht (verwenden Sie Teile der URL).
• Klicken Sie abschließend auf das Ereignis und prüfen Sie, ob die angezeigten Informationen etwas aussagen.

Für ältere Chromversionen

• Geben Sie chrome://net-internalsdie Adressleiste ein und drücken Sie die Eingabetaste.
• Öffnen Sie die Seite, auf der Probleme angezeigt werden.
• Gehen Sie zurück zu Net-Internals, klicken Sie auf Ereignisse (###) und verwenden Sie das Textfeld, um das Ereignis zu finden, das sich auf Ihre Ressource bezieht (verwenden Sie Teile der URL).
• Klicken Sie abschließend auf das Ereignis und prüfen Sie, ob die angezeigten Informationen etwas aussagen.

Ich glaube, es passiert, wenn die eigentliche Anfrage nicht gesendet wird. Tritt normalerweise auf, wenn Sie eine zwischengespeicherte Ressource laden.

Für Chrome V72 + löste es für mich nur Folgendes:

Gehe zu chrome://flags/und deaktiviere diese 3 Flags

• Deaktivieren Sie die Site-Isolation
• Aktivieren Sie den Netzwerkdienst
• Führt den Netzwerkdienst in Bearbeitung aus

oder Sie können es über die Befehlszeile tun:

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

Warum passiert das?

Es scheint, dass Google seine Chromium-Engine in eine modulare Struktur umgestaltet, in der verschiedene Dienste in eigenständige Module und Prozesse unterteilt werden. Sie nennen diesen Prozess Wartung. Der Netzwerkdienst ist der erste Schritt. Der UI-Dienst, der Identitätsdienst und der Gerätedienst stehen an. Google stellt die offiziellen Informationen auf der Chromium-Projektseite zur Verfügung .

Ist es gefährlich, das zu ändern?

Ein Beispiel ist das Netzwerk: Sobald wir einen Netzwerkdienst haben, können wir ihn für eine bessere Stabilität / Sicherheit aus dem Prozess ausführen oder in Bearbeitung, wenn wir über Ressourcenbeschränkungen verfügen . Quelle

Ich bin auf dieses Problem gestoßen und habe es geschafft, eine bestimmte Ursache zu identifizieren, die weder in den Antworten noch in der Frage oben erwähnt wurde.

Ich führe einen vollständigen js-Stapel, ein eckiges Front-End und ein Node-Back-End unter SSL aus, und die API befindet sich in einer anderen Domäne, die auf Port 8081 ausgeführt wird. Daher führe ich CORS-Anforderungen und mit Berechtigungen aus, während ich ein Sitzungscookie von der API lösche

Mein spezielles Szenario war also: POST-Anforderung mit Berechtigungen für Port 8081 verursachte die Meldung "VORSICHT: Vorläufige Header werden angezeigt" im Inspektor und blockierte natürlich auch die Anforderung insgesamt.

Meine Lösung bestand darin, Apache so einzurichten, dass der Proxy die Anforderung vom üblichen SSL-Port von 443 an den Knoten-SSL-Port von 8081 weiterleitet (der Knoten muss sich auf einem höheren Port befinden, da er nicht als Root in Prod ausgeführt werden kann). Ich denke, Chrome mag keine SSL-Anfragen an unkonventionelle SSL-Ports, aber möglicherweise könnte ihre Fehlermeldung spezifischer sein.

Dies kann auch passieren (nur für Cross-Origin-Anfragen), da eine neue Funktion namens Site-Isolation verwendet wird

Diese Seite beschreibt das Problem und eine Problemumgehung . Gehen Sie chrome://flags/#site-isolation-trial-opt-outin Chrome und ändern Sie diese Einstellung in "Opt-out" und laden Sie Chrome neu.

Es ist ein bekanntes Problem . Diese Seite sagt jedoch, dass es in Chrome 68 behoben ist, aber ich verwende Chrome 68 und habe immer noch das Problem.

HTTP / 2 Pushed-Ressourcen werden Provisional headers are shownim Inspektor für dieselbe Theorie wie @wvega in seiner obigen Antwort erstellt .

Beispiel: Da der Server die Ressource (n) an den Client gesendet hat ( bevor der Client sie angefordert hat ), hat der Browser die Ressourcen zwischengespeichert und daher stellt / benötigt der Client niemals Anforderungen. Weil...

... die realen Header werden aktualisiert, wenn der Server antwortet, aber es erfolgt keine Antwort, wenn die Anforderung blockiert wurde.

Meine Situation hängt mit dem Ursprung zusammen.
Situation: Der Browser sendet eine OPTIONSAnfrage, bevor die eigentliche Anfrage wie GEToder gesendet wird POST. Der Backend-Entwickler vergisst, die OPTIONSAnfrage zu bearbeiten, lässt sie den Service-Code durchlaufen und macht die Verarbeitungszeit zu lang. Länger als die Timeout-Einstellung, die ich in der axiosInitialisierung geschrieben habe, dh 5000 Millisekunden. Daher konnte die eigentliche Anfrage nicht gesendet werden, und dann trat das provisional headers are shownProblem auf.
Lösung: Wenn es um OPTIONSAnfragen geht, gibt die Backend-API nur das Ergebnis zurück, beschleunigt die Anfrage und die eigentliche Anfrage kann vor dem Timeout gesendet werden.

Ich bezweifle, dass meine Antwort rechtzeitig ist, um Ihnen zu helfen, aber andere finden sie möglicherweise hilfreich. Ich habe ein ähnliches Problem mit einem von mir erstellten jQuery Ajax Post-Skript festgestellt.

Es stellte sich heraus, dass ich einen Tippfehler im href-Attribut des A-Tags hatte, mit dem ich den Beitrag ausgelöst habe. Ich hatte href = " javacsript :;" (Umkehren des 's' und des 'c') .. Dies führte dazu, dass das Skript versuchte, die Seite zu aktualisieren, während der Beitrag versuchte zu feuern. Der Tippfehler wurde korrigiert und es hat für mich einwandfrei funktioniert.

Diese Meldung kann auftreten, wenn die Website mit HSTS geschützt ist . Wenn dann jemand eine Verbindung zur HTTP-Version der URL herstellt, gibt der Browser gemäß den Anweisungen von HSTS keine HTTP-Anforderung aus, sondern leitet intern sicher zur HTTPS-Ressource weiter. Dies dient dazu, HTTPS-Downgrade-Angriffe wie sslstrip zu vermeiden .

Dies kann daran liegen, dass Sie eine Ajax-Anfrage gesendet haben und gleichzeitig Ihre Seite mit location.href oder ähnlichem zu einer anderen Seite springen. Die vorherige Anfrage ist also fehlgeschlagen.

Diese Warnmeldung wird auch angezeigt, wenn die Antwort ungültig ist und daher vom Browser gelöscht wird.

In meinem Fall wurde die Anforderung korrekt an den Server gesendet, der serverseitige Code erzeugte dann einen Fehler und meine benutzerdefinierte Fehlerbehandlung gab die Fehlermeldung im Feld HTTP-Statusmeldung zurück. Dieser Fehler wurde jedoch auf der Clientseite aufgrund ungültiger Zeichen in der Fehlermeldung (hier beschrieben unter http://aspnetwebstack.codeplex.com/workitem/1386 ) nicht empfangen, was zu beschädigten Antwortheadern führte.

Ich bin auf dieses Problem mit einem AJAX-Aufruf gestoßen, der niemals abgeschlossen werden würde. Ich befolgte den Rat und den Tipp von wvega zum Debuggen mit, chrome://net-internalsum schließlich einen anderen clickEreignishandler auf der Seite zu ermitteln, der einen übergeordneten Knoten abhörte, was dazu führte, dass der Browser zu derselben URL navigierte (sodass dies nicht leicht zu erkennen war).

Die Lösung bestand darin, event.stopPropagation()einen clickHandler auf der Schaltfläche zum Senden von Formularen hinzuzufügen , um zu verhindern, dass der Klick das DOM in die Luft sprudelt und die laufende AJAX-Anforderung abbricht (initiiert über einen submitHandler auf dem form).

Ich habe dies vor kurzem (heute tatsächlich) erfahren, wo ein AJAX-Anruf an den Server gesendet wurde und Chrome die Meldung "Achtung: Vorläufige Header werden angezeigt" auslöst. In der serverseitigen PHP-Skripterstellung gibt es MySQL-Abfragen, die je nach Szenario ziemlich sofort oder einige Sekunden dauern können. Meine Serverantwort wird erst nach Abschluss der Abfragen an den Browser zurückgesendet. Ich habe festgestellt, dass ich diesen Fehler nur erhalte, wenn zeitaufwändige Abfragen (insgesamt bis zu einigen Sekunden) ausgeführt werden und verhindert wird, dass die Antwort zurückgesendet wird.

Mein Szenario beinhaltet die sehr seltene Möglichkeit, eine Tabelle durch Hinzufügen / Entfernen von Hunderten von Spalten für die Ausgabe des Wettermodells ändern zu müssen ... daher die Antwortverzögerung beim Durchlaufen einer Schleife von ALTER TABLE-Abfragen.

Ein häufiger Grund dafür ist, dass Sie ein Ereignis verfolgen und die Standardaktion nicht verhindern. Wenn Sie beispielsweise ein Klickereignis haben, möchten Sie Folgendes einschließen:

e.preventDefault();

oder

return false;

Wenn Sie dies nicht tun, werden auf der Registerkarte "Netzwerk" Ihrer Webkonsole die Warnung "Vorläufige Header" sowie der Status "Abgebrochen" angezeigt.

In meinem Fall war es nur ein falsch festgelegter Pfad zu einer Ressource (svg / img)

Dieses Problem trat bei mir auf, als ich einen ungültigen HTTP-Autorisierungsheader sendete. Ich habe vergessen, base64 zu codieren.

Ich bin darauf gestoßen und es ging weg, als ich von https zu http wechselte. Die SSL-Zertifikate, die wir in dev verwenden, werden nicht von Dritten überprüft. Sie sind nur lokal generierte Entwicklerzertifikate.

Dieselben Anrufe funktionieren in Chrome Canary und Firefox einwandfrei. Diese Browser scheinen hinsichtlich des SSL-Zertifikats nicht so streng zu sein wie Chrome. Die Aufrufe würden in Chrome mit der Meldung "VORSICHT: Vorläufige Header ..." fehlschlagen.

Ich denke / hoffe, dass wir dieses Verhalten in Chrome nicht mehr sehen, wenn wir ein legitimes SSL-Zertifikat in Stage and Prod verwenden.

Ich werfe nur meine zwei Cent hinein. Ich schreibe eine Webanwendung mit CORS-Anforderungen und einem vollständigen RESTful-Webdienst. Ich habe festgestellt, dass Chrome diesen Fehler auslöst, wenn eine unbehandelte Ausnahme oder ein PHP-Fehler ausgelöst wird. Nur für den Fall, dass jemand anderes auf das Problem stößt. Ich habe festgestellt, dass ich in diesem Fall die Chrome-App "Postman - Rest Client" starten und genau dieselbe Anforderung ausführen kann, aber in der Chrome-App wird tatsächlich der PHP-Fehler angezeigt, der anstelle dieses nicht beschreibenden Fehlers ausgelöst wird.

Ich habe dieses Problem ausgeführt, als ich zum zweiten Mal versuchte, main.js für require js zu laden, nachdem ich aufgrund eines Fehlers Änderungen vorgenommen hatte. Ich habe gerade in den Developer Tools-Einstellungen "Cache deaktivieren (wenn DevTools geöffnet ist)" aktiviert. und das hat den Reiz gemacht.

Ein weiteres mögliches Szenario, das ich gesehen habe - genau dieselbe Anfrage wird nach wenigen Millisekunden erneut gesendet (höchstwahrscheinlich aufgrund eines Fehlers auf der Clientseite).
In diesem Fall sehen Sie auch, dass der Status der ersten Anforderung "abgebrochen" ist und die Latenz nur einige Millisekunden beträgt.

Dies geschah für mich, als ich einen Download-Link hatte und nachdem ich darauf geklickt hatte, versuchte ich auch, den Klick mit jquery zu fangen und eine Ajax-Anfrage zu senden. Das Problem war, dass Sie beim Klicken auf den Download-Link die Seite verlassen, auch wenn sie nicht so aussieht. Wenn keine Dateiübertragung stattfinden würde, wird die angeforderte Seite angezeigt. Daher habe ich ein Ziel = "_ blank" festgelegt, um dieses Problem zu vermeiden.

Ich habe diesen Fehler erhalten, als ich versucht habe, eine Seite in einem Popup zu drucken. Der Druckdialog wurde angezeigt und wartete noch auf meine Annahme oder Stornierung des Druckvorgangs im Popup, während auf der Masterseite auch im Hintergrund die Meldung angezeigt wurde. VORSICHT Vorläufige Header werden angezeigt, wenn ich versuchte, auf einen anderen Link zu klicken.

In meinem Fall bestand die Lösung darin, das window.print ();Skript zu entfernen, das <body>im Popup-Fenster ausgeführt wurde, um den Druckdialog zu verhindern.

Ich habe dies gesehen, als die Anzahl der Verbindungen zu meinem Server die maximale Anzahl von Verbindungen pro Server von Chrome von 6 überschritten hat.

Verwenden Sie diese Code-Faust Ihres Codes:

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

Das funktioniert bei mir.

Hier ist eine andere Lösung.

Wenn dieses Problem beim Aufruf von $ ajax () auftritt, fügen http://Sie hinzu, bevor Ihr Serverhost Ihr Problem löst.

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

Wenn Sie eine Asp.Net Mvc-Anwendung entwickeln und versuchen, eine JsonResultin Ihrem Controller zurückzugeben, stellen Sie sicher, dass Sie JsonRequestBehavior.AllowGetder JsonMethode hinzufügen . Das hat es für mich behoben.

public JsonResult GetTaskSubCategories(int id)
{
    var subcategs = FindSubCategories(id);

    return Json(subcategs, JsonRequestBehavior.AllowGet);  //<-- Notice it has two parameters
}

Die Meldung "Achtung: Vorläufige Header werden angezeigt" kann angezeigt werden, wenn auf HTTPS gehostete Websites Aufrufe von auf HTTP gehosteten WebApi aufrufen. Sie können alle überprüfen, ob alle Ihre APIs HTTPS sind. Der Browser verhindert, dass eine unsichere Ressource aufgerufen wird. Sie können eine ähnliche Meldung in Ihrem Code sehen, wenn Sie die FETCH-API für Domänen mit HTTP verwenden.

Gemischter Inhalt: Die Seite unter " https://website.com " wurde über HTTPS geladen, forderte jedoch eine unsichere Ressource " http://webapi.com " an. Diese Anfrage wurde blockiert. Der Inhalt muss über HTTPS bereitgestellt werden.

Ich hatte ein ähnliches Problem mit meiner MEAN-App. In meinem Fall trat das Problem nur in einer Abrufanforderung auf. Ich habe versucht, Adblock zu entfernen, den Cache zu leeren und es mit verschiedenen Browsern zu versuchen. Nichts hat geholfen.

Schließlich habe ich herausgefunden, dass die API versucht hat, ein riesiges JSON-Objekt zurückzugeben. Als ich versucht habe, ein kleines Objekt zu senden, hat es gut funktioniert. Schließlich habe ich meine Implementierung geändert, um einen Puffer anstelle eines JSON zurückzugeben.

Ich möchte, dass expressJS in diesem Fall einen Fehler auslöst.

Dieses Problem tritt auch auf, wenn Sie einige Pakete verwenden webpack-hot-middlewareund mehrere Seiten gleichzeitig öffnen. webpack-hot-middlewareerstellt für jede Seite eine Verbindung, um die Codeänderungen abzuhören und die Seite dann zu aktualisieren. Jeder Browser hat eine max-connections-per-serverEinschränkung von 6 für Chrome. Wenn Sie also bereits mehr als 6 Seiten in Chrome geöffnet haben, bleibt die neue Anforderung dort hängen, bis Sie einige Seiten schließen.

In meinem Fall war die Ursache die AdBlock-Erweiterung.

Die Anfrage an den Server ging durch und ich erhielt die Antwort, aber ich konnte die Anfrage-Cookies nicht sehen, da "Provisional Headers .." in den Dev Tools angezeigt wurde. Nach dem Deaktivieren von AdBlock für die Website wurde die Warnung gelöscht und die Entwicklungstools zeigten die Cookies erneut an.

Damit die Änderung wirksam wurde, mussten auch die Entwicklungswerkzeuge geschlossen und die Seite aktualisiert werden