Question "ATTENTION: les en-têtes provisoires sont affichés" dans le débogueur Chrome


J'ai remarqué un message de prudence étrange lorsque vous consultez les ressources téléchargées à l'aide de Google Chrome Inspector (F12):

Les en-têtes provisoires de prudence sont montrés

enter image description here

J'ai trouvé quelque chose de peut-être pertinent, Panneau réseau: ajouter des précautions sur les en-têtes de demande provisoires, mais je ne pouvais pas le comprendre complètement. Des questions connexes peuvent être trouvées Demandes de blocage de Chrome aussi bien que XMLHttpRequest ne peut pas être chargé. Les ressources déchargées montrent la prudence: les en-têtes provisoires sont affichés.

Semblable à la première question, ma ressource était bloquée, mais plus tard, elle chargeait automatiquement la même ressource. Contrairement à la deuxième question, Je ne veux rien réparer; Je veux savoir ce que signifie ce message et pourquoi je l'ai reçu.


269
2018-01-17 03:38


origine


Réponses:


La ressource pourrait être bloquée par une extension (AdBlock dans mon cas).

Le message est là car la demande de récupération de cette ressource n'a jamais été faite, de sorte que les en-têtes affichés ne sont pas réels. Comme expliqué dans le problème que vous avez référencé, les en-têtes réels sont mis à jour lorsque le serveur répond, mais il n'y a pas de réponse si la demande a été bloquée.


La façon dont j'ai découvert l’extension qui bloquait ma ressource était via l’outil net-internals de Chrome:

  • Type chrome://net-internals dans la barre d'adresse et appuyez sur Entrée.
  • Ouvrez la page qui montre des problèmes.
  • Retournez sur net-internals, cliquez sur événements (###) et utilisez le champ de texte pour rechercher l’événement lié à votre ressource (utilisez des parties de l’URL).
  • Enfin, cliquez sur l'événement et voyez si les informations affichées vous indiquent quelque chose.

245
2018-01-17 06:14



Je crois que cela se produit lorsque la demande réelle n'est pas envoyée. Se produit généralement lorsque vous chargez une ressource en cache.


82
2018-01-22 00:44



J'ai rencontré ce problème et j'ai réussi à identifier une cause spécifique, qui n'est mentionnée ni dans les réponses ni dans la question.

J'exécute une pile js complète, un front-end angulaire et un nœud d'arrière-plan sur SSL, et l'API se trouve sur un autre domaine s'exécutant sur le port 8081, alors je fais des requêtes CORS et withCredentials

Donc, spécifiquement, mon scénario était le suivant: La requête POST, avecCredentials sur le port 8081, provoquait le message "ATTENTION: les en-têtes provisoires sont affichés" dans l'inspecteur et bloquait bien entendu la requête tous ensemble.

Ma solution a été de configurer apache sur proxy pour passer la requête du port SSL habituel de 443 au port SSL 8081 du noeud (le noeud doit être sur un port supérieur car il ne peut pas être exécuté en tant que root in prod). Donc, je suppose que Chrome n'aime pas les requêtes SSL aux ports SSL non conventionnels, mais peut-être que leur message d'erreur pourrait être plus précis.


17
2018-02-11 12:27



Ressources HTTP / 2 poussées produira Provisional headers are shown dans l'inspecteur pour la même théorie que @wvega publié dans sa réponse ci-dessus.

par exemple: Puisque le serveur a poussé la ou les ressources vers le client (avant que le client ne les demande), le navigateur a les ressources mises en cache et par conséquent le client ne fait jamais / nécessite de requêtes; Alors parce que...

... les vrais en-têtes sont mis à jour lorsque le serveur répond, mais il n'y a pas de réponse si la requête a été bloquée.


8
2017-12-16 18:00



Je doute que ma réponse soit à temps pour vous aider, mais d'autres pourraient la trouver utile. J'ai rencontré un problème similaire avec un script jQuery Ajax Post que j'ai créé.

Il s'est avéré que j'avais une faute de frappe dans l'attribut href de l'étiquette A que j'utilisais pour déclencher le poste. J'avais tapé href = "javacsript:; "(inversant le 's' et le 'c') .. le script essayait de rafraîchir la page pendant que le poste tentait de tirer. corrigeait la faute de frappe et cela fonctionnait parfaitement bien pour moi.


6
2018-03-02 14:01



Ce message peut apparaître lorsque le site Web est protégé en utilisant HSTS. Ensuite, lorsque quelqu'un établit un lien vers la version HTTP de l'URL, le navigateur, comme indiqué par HSTS, n'émet pas de requête HTTP, mais redirige en interne la ressource HTTPS de façon sécurisée. Ceci afin d’éviter les attaques de mise à niveau HTTPS telles que sslstrip.


3
2017-10-18 14:52



J'ai rencontré ce problème avec un appel AJAX qui ne serait jamais terminé. J'ai suivi les conseils et les astuces de wvega sur le débogage avec chrome://net-internals pour finalement déterminer un autre click Le gestionnaire d'événements de la page, écoutant sur un nœud parent, faisait en sorte que le navigateur naviguait vers la même URL (il n'était donc pas facilement visible).

La solution était d'ajouter event.stopPropagation() dans un click gestionnaire sur le bouton de soumission du formulaire pour empêcher le clic de bouillir sur le DOM et d'annuler la requête AJAX en cours (lancée via un submit gestionnaire sur le form).


2
2018-03-11 22:42