« ATTENTION : en-têtes provisoires figurent » débogueur Chrome

Question

J'ai remarqué un étrange message d'avertissement lorsque l'on regarde les ressources téléchargées à l'aide de Google chrome inspecteur (F12):

Attention provisoire en-têtes sont affichés

J'ai trouvé quelque chose qui peuvent être pertinentes, Réseau du Panneau: ajouter de la prudence provisoire en-têtes de requête, mais je ne pouvais pas la comprendre pleinement. Questions connexes peuvent être trouvés Chrome bloquer les demandes ainsi que XMLHttpRequest ne peut pas charger. Déchargé de ressources preuve de prudence: Provisoire en-têtes sont affichés.

Similaire à la première question, ma ressource a été bloqué, mais plus tard automatiquement chargés de la même ressource. Contrairement à la deuxième question, je ne veux pas résoudre quoi que ce soit; je veux savoir ce que signifie ce message et pourquoi je l'ai reçu.

Answer 1

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

Le message est là parce que la demande pour récupérer cette ressource n’a jamais été fait, donc les en-têtes projetés ne sont pas la vraie chose. Comme expliqué dans le numéro que vous avez référencé, les en-têtes de real sont mises à jour lorsque le serveur répond, mais il n’y a aucune réponse si la demande a été bloquée.

Answer 2

Selon moi, qu'il arrive lorsque la demande n’est pas envoyée. Se produit généralement lorsque vous chargez une ressource mise en cache.

Answer 3

J'ai rencontré ce problème, et j'ai réussi à identifier une cause précise, ce qui n'est pas mentionné ci-dessus, soit dans les réponses ou la question.

Je suis en cours d'exécution pleine js pile, angulaire de la fin de devant et noeud fin de retour sur SSL, et de l'API est sur un autre domaine en cours d'exécution sur le port 8081, donc je fais de la SCRO demandes et withCredentials que je suis déposer un cookie de session à partir de l'API

Donc, précisément mon scénario était: requête POST, withCredentials de port 8081 origine de la "ATTENTION: provisoire en-têtes sont montrés" message de l'inspecteur et aussi, bien sûr, bloqué la demande tous ensemble.

Ma solution a été de configurer apache pour proxy transmettre la demande de l'habituel port SSL 443 vers le nœud SSL port 8081 (nœud doit être sur un port plus qu'il ne peut pas être exécuté en tant que root en prod). Donc je suppose que Chrome n'aime pas les demandes SSL non conventionnelles ports SSL, mais peut-être leur message d'erreur pouvait être plus précis.

Answer 4

Je doute que ma réponse est dans le temps pour vous aider, mais d’autres peuvent s’avérer utile. J’ai eu un problème semblable avec un jQuery script Ajax Post que j’ai créé.

Il s’est avéré que j’avais une faute de frappe dans l’attribut href de la balise A que j’utilisais pour le poste d’incendie. J’avais tapé href = »javacsript: ; » (inverser les » et le « c »)... Cela a provoqué le script essayer d’actualiser la page, alors que le poste tentait de feu. corrigé la faute de frappe et il a parfaitement bien fonctionné pour moi.

Answer 5

J'ai rencontré ce problème avec un appel AJAX qui ne serait jamais complète. J'ai suivi wvega conseils et astuce sur le débogage avec chrome://net-internals pour finalement déterminer un autre click gestionnaire d'événement dans la page, à l'écoute sur un nœud parent, était à l'origine du navigateur pour naviguer vers la même URL (il n'est donc pas facilement perceptible).

La solution était d'ajouter event.stopPropagation() en click gestionnaire sur le formulaire bouton soumettre pour garder le clic de remonter les DOM et l'annulation de la requête AJAX en cours (lancé par un submit gestionnaire sur l' form).