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

Question

Ich habe eine seltsame Warnmeldung bemerkt, als ich mir heruntergeladene Ressourcen mit dem Google Chrome Inspector (F12) angesehen habe:

Vorsicht, provisorische Header werden angezeigt

Ich habe etwas möglicherweise Relevantes gefunden, Netzwerkpanel: Vorsicht bei provisorischen Anforderungsheadern hinzufügen, konnte es aber nicht vollständig verstehen. Verwandte Fragen finden sich unter Chrome block requests sowie XMLHttpRequest kann nicht geladen werden. Nicht geladene Ressourcen zeigen Warnung: Provisorische Header werden angezeigt.

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

Answer 1

Die Ressource könnte von einer Erweiterung blockiert werden (in meinem Fall AdBlock).

Die Meldung erscheint, weil die Anfrage zur Abrufung dieser Ressource nie gemacht wurde, daher sind die angezeigten Header nicht echt. Wie im von Ihnen genannten Problem erläutert, werden die echten Header aktualisiert, wenn der Server antwortet, aber es gibt keine Antwort, wenn die Anfrage blockiert wurde.

---

Ich habe herausgefunden, dass die Erweiterung, die meine Ressource blockiert hat, über das net-internals-Tool in Chrome:

Für aktuelle Versionen von Chrome

• Geben Sie chrome://net-export/ in die Adressleiste ein und drücken Sie die Eingabetaste.
• Beginnen Sie mit der Aufzeichnung. Und speichern Sie die Aufzeichnungsdatei lokal.
• Öffnen Sie die Seite, die Probleme zeigt.
• Gehen Sie zurück zu den net-internals
• Sie können die aufgezeichnete Log-Datei 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 schließlich auf das Ereignis und prüfen Sie, ob die angezeigten Informationen Ihnen etwas sagen.

Für ältere Versionen von Chrome

• Geben Sie chrome://net-internals in die Adressleiste ein und drücken Sie die Eingabetaste.
• Öffnen Sie die Seite, die Probleme zeigt.
• Gehen Sie zurück zu den 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 schließlich auf das Ereignis und prüfen Sie, ob die angezeigten Informationen Ihnen etwas sagen.

Answer 2

Ich glaube, dass dies passiert, wenn die tatsächliche Anfrage nicht gesendet wird. Normalerweise passiert dies, wenn eine zwischengespeicherte Ressource geladen wird.

Answer 3

Für Chrome v72+ war das einzige, was bei mir funktioniert hat, Folgendes:

Gehen Sie zu chrome://flags/ und deaktivieren Sie diese 3 Flags:

• Site-Isolierung deaktivieren
• Netzwerkdienst aktivieren
• Netzwerkdienst im Prozess ausführen

Sie können dies auch über die Befehlszeile tun:

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

---

Warum passiert das?

Es scheint, dass Google seinen Chromium-Motor in ein modulares Konstrukt umgestaltet, in dem verschiedene Dienste in eigenständige Module und Prozesse aufgeteilt werden. Sie nennen diesen Prozess Servifizierung. Der Netzwerkdienst ist der erste Schritt, der Ui-Dienst, Identitätsdienst und Gerätedienst folgen. Google bietet offizielle Informationen auf der Projektseite von Chromium.

Ist es gefährlich, das zu ändern?

Ein Beispiel ist das Networking: Sobald wir einen Netzwerkdienst haben, können wir wählen, ob wir ihn ausgelagert für eine bessere Stabilität/Sicherheit ausführen wollen, oder in-Prozess, wenn wir ressourcenbeschränkt sind. Quelle

Answer 4

Ich bin auf dieses Problem gestoßen und es ist mir gelungen, eine spezifische Ursache zu identifizieren, die weder in den Antworten noch in der Frage oben erwähnt wird.

Ich betreibe einen vollständigen JS-Stack, Angular Frontend und Node-Backend auf SSL, und die API läuft auf einer anderen Domain auf Port 8081, sodass ich CORS-Anfragen und withCredentials durchführe, da ich ein Session-Cookie von der API abwerfe.

Also war mein spezifisches Szenario: POST-Anfrage mit withCredentials auf Port 8081 verursachte die Meldung "VORSICHT: Vorläufige Header werden angezeigt" im Inspektor und blockierte natürlich auch die Anfrage komplett.

Meine Lösung bestand darin, Apache so einzurichten, dass die Anfrage vom üblichen SSL-Port 443 zum Node SSL-Port 8081 weitergeleitet wird (Node muss auf einem höheren Port sein, da es in der Produktion nicht als Root ausgeführt werden kann). Ich vermute, dass Chrome keine SSL-Anfragen an unkonventionelle SSL-Ports mag, aber vielleicht könnte ihre Fehlermeldung genauer sein.

Answer 5

Meine Situation ist cross-origin bezogen.
Situation: Der Browser sendet eine OPTIONS-Anfrage, bevor er die eigentliche Anfrage wie GET oder POST sendet. Der Backend-Entwickler vergisst, die OPTIONS-Anfrage zu behandeln, sodass sie durch den Service-Code gelangt und die Verarbeitungszeit zu lang wird. Länger als die Timeout-Einstellung, die ich in der axios-Initialisierung geschrieben habe, die 5000 Millisekunden beträgt. Daher konnte die eigentliche Anfrage nicht gesendet werden, und dann bin ich auf das Problem provisional headers are shown gestoßen.
Lösung: Wenn es um OPTIONS-Anfragen geht, gibt das Backend-API einfach das Ergebnis zurück, was die Anfrage schneller macht und die eigentliche Anfrage vor dem Timeout gesendet werden kann.