it-swarm.com.de

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

Beim Betrachten heruntergeladener Ressourcen mit dem Google Chrome Inspector (F12) ist eine merkwürdige Warnmeldung aufgetreten:

Es werden nur vorläufige Header angezeigt

enter image description here

Ich habe etwas gefunden, das möglicherweise relevant ist, Netzwerk-Panel: Vorsicht bei vorläufigen Anforderungsheadern , aber ich konnte es nicht vollständig verstehen. Verwandte Fragen finden Sie sowohl in Chrome-Blockanforderungen als auch in XMLHttpRequest kann nicht geladen werden. Entladene Ressourcen zeigen Vorsicht: Vorläufige Header werden angezeigt

Ähnlich wie bei erste Frage wurde meine Ressource blockiert, später jedoch automatisch dieselbe Ressource geladen. Im Gegensatz zu zweite Frage möchte ich nichts reparieren; Ich möchte wissen, was diese Nachricht bedeutet und warum ich sie erhalten habe.

309
Salvador Dali

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

Die Nachricht ist da, weil die Anforderung zum Abrufen dieser Ressource nie gestellt wurde, so dass die angezeigten Header nicht die eigentliche Sache sind. Wie in dem Problem erläutert, auf das Sie sich bezogen haben, werden die realen Header aktualisiert, wenn der Server antwortet. Wenn die Anforderung jedoch blockiert wurde, erfolgt keine Antwort.


Ich fand die Erweiterung, die meine Ressource blockierte, über das Tool "Interne Interna" in Chrome:

  • Geben Sie chrome://net-internals in die Adressleiste ein und drücken Sie die Eingabetaste.
  • Öffnen Sie die Seite mit Problemen.
  • Gehen Sie zurück zu Internetinterns, klicken Sie auf events (###) 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 die Veranstaltung und sehen Sie, ob die angezeigten Informationen Ihnen etwas mitteilen.
285
Willington Vega

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

92
Shazz

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 erwähnt wird.

Ich verwende einen vollständigen js-Stack, ein eckiges Front-End und ein Node-Back-End auf SSL. Die API befindet sich in einer anderen Domäne, die auf Port 8081 ausgeführt wird. Daher mache ich CORS-Anforderungen und withCredentials, da ich ein Session-Cookie von der API lösche

Konkret war mein Szenario: POST - Anforderung, withCredentials an Port 8081 verursachte im Inspektor die Meldung "VORSICHT: Es werden vorläufige Header angezeigt" und natürlich wurde die Anforderung auch insgesamt blockiert.

Meine Lösung bestand darin, Apache so einzurichten, dass er die Anforderung vom normalen SSL-Port von 443 an den SSL-Port des Knotens 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 vermute, Chrome mag keine SSL-Anfragen an unkonventionelle SSL-Ports, aber möglicherweise könnte die Fehlermeldung genauer sein.

21
Mister P

HTTP/2 Pushed resources erzeugt Provisional headers are shown im Inspektor für dieselbe Theorie wie @wvega in seine Antwort oben .

z.B.: Da der Server die Ressource (n) an den Client weitergeleitet hat (bevor der Client sie angefordert hat), werden die Ressourcen des Browsers zwischengespeichert und der Client stellt daher niemals Anforderungen; Weil...

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

9
user742030

Für Chrome V72 + war das, was es für mich löste, nur das:

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

  • Deaktivieren Sie die Standortisolierung
  • Netzwerkdienst aktivieren
  • Führt den Netzwerkdienst in Bearbeitung aus

 enter image description here

oder Sie können es von der Kommandozeile aus 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, bei der verschiedene Dienste in eigenständige Module und Prozesse aufgeteilt werden. Sie nennen diesen Prozess Servicifizierung. Der Netzwerkdienst ist der erste Schritt. Der UI-Dienst, der Identitätsdienst und der Gerätedienst stehen an. Google liefert die offiziellen Informationen auf der Chromium-Projektseite .

Ist es gefährlich, das zu ändern?

Ein Beispiel ist die Vernetzung: Sobald wir einen Netzwerkdienst haben, können wir ihn zur Verbesserung der Stabilität/Sicherheit außer Betrieb setzen, oder bei eingeschränkten Ressourcen in Betrieb . Quelle

7
Badr Elmers

Meine Situation ist cross-Origin verwandt.
Situation: Der Browser sendet eine OPTIONS-Anforderung vor dem Senden der echten Anfrage wie GET oder POST. Backend-Entwickler vergisst, die OPTIONS-Anfrage zu bearbeiten, lässt den Service-Code durchlaufen und macht die Verarbeitungszeit zu lang. Länger als die Timeout-Einstellung, die ich in der axios-Initialisierung geschrieben habe, die 5000 Millisekunden beträgt. Daher konnte die echte Anfrage nicht gesendet werden, und dann trat das provisional headers are shown-Problem auf.
Lösung: Wenn es sich um OPTIONS-Anfrage handelt, gibt das Backend-API einfach das Ergebnis zurück, die Anfrage wird schneller und die echte Anfrage kann vor dem Timeout gesendet werden.

6
Alexee

Ich bezweifle, dass meine Antwort rechtzeitig ist, um Ihnen zu helfen, aber andere finden es vielleicht hilfreich. Bei einem von mir erstellten jQuery Ajax Post-Skript ist ein ähnliches Problem aufgetreten.

Es stellte sich heraus, dass ich einen Tippfehler im href-Attribut des A-Tags hatte, mit dem ich den Beitrag abfeuerte. Ich hatte href = " javacsript :;" (Umkehrung des 's' und des 'c') .. Dies veranlasste das Skript, die Seite zu aktualisieren, während der Beitrag versuchte, zu feuern. der Tippfehler korrigiert und es funktionierte perfekt für mich.

6
Savage

Diese Meldung kann auftreten, wenn die Website mit HSTS geschützt wird. Wenn sich dann jemand mit der HTTP-Version der URL verbindet, gibt der Browser, wie von HSTS angewiesen, keine HTTP-Anforderung aus, sondern leitet intern sicher zur HTTPS-Ressource um. Dies dient dazu, HTTPS-Downgrade-Angriffe wie sslstrip zu vermeiden.

4
dionyziz

Dies kann auch aufgrund einer neuen Funktion mit dem Namen Standortisolation passieren.

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

Es ist ein bekanntes Problem . Diese Seite besagt jedoch, dass sie in Chrome 68 behoben ist, aber ich habe Chrome 68 ausgeführt und habe immer noch das Problem.

4
onlynone

Ich habe dies kürzlich erfahren (heute tatsächlich), wo ein AJAX - Aufruf an den Server ausgeführt wurde und Chrome die "Achtung: Vorläufige Header werden angezeigt" auslöst Im serverseitigen PHP -Skripting gibt es MySQL-Abfragen, die je nach Szenario ziemlich schnell sein können oder einige Sekunden dauern können. Meine Serverantwort wird erst dann an den Browser zurückgesendet, wenn die Abfragen abgeschlossen sind. Ich habe festgestellt, dass diese Fehlermeldung nur angezeigt wird, wenn zeitaufwändige Abfragen (insgesamt bis zu ein paar Sekunden) ausgeführt werden und die Antwort nicht zurückgesendet wird.

In meinem Szenario besteht die sehr seltene Möglichkeit, dass Sie eine Tabelle ändern müssen, indem Sie Hunderte von Spalten für die Ausgabe des Wettermodells hinzufügen/entfernen.

2
Gwi7d31

Dies geschieht häufig, wenn 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.

2
bigtex777

Dieses Problem trat auf, als ich einen ungültigen HTTP-Autorisierungsheader sendete. Ich habe vergessen, Base64 zu kodieren.

2

Das kann daran liegen, dass Sie eine Ajax-Anfrage gesendet haben, aber jetzt springen Sie Ihre Seite mithilfe von location.href oder ähnlichem zu einer anderen. Die vorherige Anfrage war also fehlgeschlagen.

2
Frankjs

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

2
typocoder

Ich bin auf dieses Problem mit einem Aufruf von AJAX gestoßen, der niemals abgeschlossen werden würde. Ich folgte wvegas Rat und Tipp zum Debuggen mit chrome://net-internals, um schließlich einen anderen click-Ereignishandler auf der Seite zu ermitteln, der einen übergeordneten Knoten abhörte, der Browser dazu veranlasste, zur gleichen URL zu navigieren (sodass er nicht leicht zu erkennen war).

Die Lösung bestand darin, event.stopPropagation() in einem click-Handler auf der Formularsendeschaltfläche hinzuzufügen, um zu verhindern, dass der Klick das DOM aufbläht und die laufende Anforderung AJAX abbricht (initiiert über einen submit-Handler für die form).

2
jimp

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 für mich.

1
Nabi K.A.Z.

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 erstellte Entwicklerzertifikate.

Die gleichen Anrufe funktionieren in Chrome Canary und Firefox problemlos. Diese Browser scheinen beim SSL-Zertifikat nicht so streng zu sein wie Chrome. Die Aufrufe würden in Chrome mit der Meldung "ACHTUNG: Vorläufige Header ..." fehlschlagen.

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

1
CodeWarrior

Ich habe festgestellt, dass dies der Fall ist, wenn die Anzahl der Verbindungen zu meinem Server die maximale Anzahl von Verbindungen pro Server von Chrome von 6 überschritten hat. 

1
mab

Ein anderes mögliches Szenario, das ich gesehen habe - die gleiche Anforderung wird gerade 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 dass die Latenz nur einige Millisekunden beträgt.

1
Erez Cohen

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

In meinem Fall wurde die Anforderung korrekt an den Server gesendet, der serverseitige Code hat dann einen Fehler ausgegeben und meine benutzerdefinierte Fehlerbehandlung hat die Fehlermeldung im Feld HTTP-Statusmeldung zurückgegeben. Dieser Fehler wurde auf der Clientseite jedoch nicht empfangen, da in der Fehlermeldung (hier beschrieben http://aspnetwebstack.codeplex.com/workitem/1386 ) ungültige Zeichen enthalten waren, die zu fehlerhaften Antwortheadern führten.

1
Florian Haider

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

1
Ohad Sadan

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 bestand darin, dass Sie die Seite verlassen, wenn Sie auf den Download-Link klicken, auch wenn es nicht so aussieht. Wenn keine Datei übertragen würde, wird die angeforderte Seite angezeigt. Daher habe ich ein Ziel = "_ blank" gesetzt, um dieses Problem zu verhindern.

1
Hayk Aghabekyan

Ich habe diese Fehlermeldung erhalten, als ich versuchte, eine Seite in einem Popup zu drucken. Der Druckdialog wurde angezeigt und es wurde immer noch darauf gewartet, dass ich den Druck im Popup akzeptierte oder stornierte, während auf der Masterseite auch im Hintergrund die Nachricht angezeigt wurde VORSICHT werden vorläufige Header angezeigt als ich versuchte, auf einen anderen Link zu klicken.

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

1
Arnau Galofré

Dieses Problem tritt auch auf, wenn einige Pakete wie webpack-hot-middleware verwendet werden und mehrere Seiten gleichzeitig geöffnet werden. webpack-hot-middleware erstellt für jede Seite eine Verbindung zum Abhören der Codeänderungen und anschließend zum Aktualisieren der Seite. Jeder Browser hat eine max-connections-per-server-Einschränkung von 6 für Chrome. Wenn Sie also bereits mehr als 6 Seiten in Chrome geöffnet haben, wird die neue Anforderung dort aufgehängt, bis Sie einige Seiten schließen.

0
LCB

Ich habe nur meine zwei Cents eingeworfen. Ich schreibe eine Webanwendung mit CORS-Anforderungen und einem vollständigen RESTful-Webdienst. Ich habe festgestellt, dass Chrome diesen Fehler auslöst, wenn ich eine nicht behandelte Ausnahme oder einen Fehler PHP habe. Nur wenn jemand anderes auf das Problem stößt. Ich habe festgestellt, dass ich in diesem Fall die Chrome-App "Postman - Rest Client" starten und die gleiche Anforderung ausführen kann. In der Chrome-App werde ich jedoch tatsächlich den PHP -Fehler erhalten, der statt dieses nicht beschreibenden Fehlers ausgegeben wird Error.

0
JDubDev

In meinem Fall waren die Body-Parameter, die ich in der Post-Anfrage gesendet habe, und die Logik, die ich je nach Body-Parametern geschrieben habe, falsch, sodass die Antwort nicht gesendet werden konnte. also bekam ich diesen fehler.

 example: post request body (a: alsldfjfj) which I was sending

aber ich hatte den Code geschrieben, um "b" anstelle von "a" zu bestätigen 

0
vikas etagi

Die Meldung "Vorsicht: provisorische Header werden angezeigt" kann angezeigt werden, wenn eine auf HTTPS gehostete Website einen Aufruf an den auf HTTP gehosteten WebApi aufruft. Sie können alle prüfen, ob alle Ihre Apis HTTPS sind. Der Browser verhindert den Aufruf einer unsicheren Ressource. Sie können eine ähnliche Meldung in Ihrem Code sehen, wenn Sie die FETCH-API für die Domäne 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.

0
Rafal Cypcer

Ich hatte ein ähnliches Problem mit meiner MEAN-App. In meinem Fall trat das Problem nur in einer Get-Anfrage auf. Ich habe versucht, den Adblock zu entfernen, den Cache zu löschen und mit verschiedenen Browsern auszuprobieren. Nichts hat geholfen.

schließlich habe ich herausgefunden, dass die API versucht hat, ein großes JSON-Objekt zurückzugeben. Wenn ich versucht habe, ein kleines Objekt zu senden, funktionierte es einwandfrei. 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 ausgibt.

0
Chandru

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 Site verschwand die Warnung und die Entwickler-Tools zeigten die Cookies wieder an.

Damit die Änderung wirksam wird, mussten auch die Entwicklungstools geschlossen und die Seite aktualisiert werden

0
Tarmo

Gelöschte zwischengespeicherte Daten aus der Historie des Browsers funktionieren für mich.

0

Hier ist eine andere Lösung.

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

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

Wenn Sie eine Asp.Net Mvc-Anwendung entwickeln und versuchen, eine JsonResult in Ihrem Controller zurückzugeben, müssen Sie unbedingt JsonRequestBehavior.AllowGet zur Json-Methode 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
}
0
codingbiz