"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

Dies kann auch (nur für cross-origin Anfragen) passieren, aufgrund eines neuen Features namens Seitenisolierung

Diese Seite beschreibt das Problem und einen Workaround. Der Workaround besteht darin, zu chrome://flags/#site-isolation-trial-opt-out in Chrome zu gehen und diese Einstellung auf "Opt-out" zu ändern und Chrome neu zu laden.

Es handelt sich um ein bekanntes Problem. Allerdings sagt diese Seite, dass es in Chrome 68 behoben wurde, aber ich verwende Chrome 68 und habe immer noch das Problem.

Answer 2

HTTP/2 Pushed resources werden im Inspector die Meldung Vorläufige Header werden angezeigt anzeigen, basierend auf der gleichen Theorie wie @wvega in seiner Antwort oben gepostet hat.

z.B.: Da der Server die Ressourcen an den Client geschoben hat (bevor der Client sie angefordert hat), hat der Browser die Ressourcen im Cache und der Client macht/ benötigt daher keine Anfragen; Deshalb...

...werden die echten Header aktualisiert, wenn der Server antwortet, aber es gibt keine Antwort, wenn die Anfrage blockiert wurde.

(Note: The translation provided assumes that the tags are the same in both languages.)

Answer 3

Ich bezweifle, dass meine Antwort rechtzeitig ist, um Ihnen zu helfen, aber andere könnten sie nützlich finden. Ich hatte ein ähnliches Problem mit einem jQuery Ajax Post Skript, das ich erstellt habe.

Es stellte sich heraus, dass ich einen Tippfehler im href-Attribut des A-Tags hatte, den ich zum Auslösen des Posts verwendet habe. Ich hatte href="javacsript:;" (die 's' und das 'c' vertauscht) getippt... dadurch versuchte das Skript, die Seite neu zu laden, während der Post ausgeführt wurde. Den Tippfehler korrigiert und es hat perfekt für mich funktioniert.

Answer 4

Diese Meldung kann auftreten, wenn die Website mit HSTS geschützt ist. Wenn also jemand auf die HTTP-Version der URL verweist, gibt der Browser, wie von HSTS angewiesen, keine HTTP-Anforderung aus, sondern leitet intern sicher zum HTTPS-Ressource weiter. Dies soll HTTPS-Downgrade-Angriffe wie sslstrip verhindern.

Answer 5

Dieses Problem ist mir passiert, als ich einen ungültigen HTTP-Autorisierungsheader gesendet habe. Ich habe vergessen, ihn mit Base64 zu codieren.