"ATTENTION: les en-têtes provisoires sont affichés" dans le débogueur Chrome
J'ai remarqué un étrange message de prudence lorsque vous consultez des ressources téléchargées à l'aide de Google Chrome Inspector (F12):
Attention les en-têtes provisoires sont affichés
J'ai trouvé quelque chose qui pourrait être pertinent, Panneau de réseau: faites attention aux en-têtes de requête provisoires , mais je ne pouvais pas bien le comprendre. Des questions connexes peuvent être trouvées Les requêtes de blocage de Chrome ainsi que XMLHttpRequest ne peuvent pas être chargées. Attention, les ressources déchargées sont prudentes: les en-têtes provisoires sont affichés .
Semblable à la première question , ma ressource a été bloquée, mais elle a ensuite été chargée automatiquement par la suite. Contrairement à la seconde question , je ne veux rien arranger; Je veux savoir ce que signifie ce message et pourquoi je l’ai reçu.
La ressource pourrait être bloquée par une extension (AdBlock dans mon cas).
Le message est là parce que la demande de récupération de cette ressource n'a jamais été faite, les en-têtes affichés ne sont donc pas réels. Comme expliqué dans le problème que vous avez mentionné, 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 manière dont j'ai découvert l'extension qui bloquait ma ressource était via l'outil net-internals de Chrome:
- Tapez
chrome://net-internalsdans la barre d'adresse et appuyez sur Entrée. - Ouvrez la page qui présente des problèmes.
- Retournez dans net-internals, cliquez sur events (###) et utilisez le champ de texte pour trouver 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 disent quelque chose.
Je crois que cela se produit lorsque la demande réelle n'est pas envoyée. Cela se produit généralement lorsque vous chargez une ressource mise en cache.
J'ai rencontré ce problème et j'ai réussi à identifier une cause spécifique, qui n'est mentionnée ci-dessus 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 dorsal sur SSL, et l'API est sur un domaine différent qui s'exécute sur le port 8081. Je fais donc les demandes CORS et withCredentials lorsque je dépose un cookie de session de l'API
Ainsi, mon scénario était précisément le suivant: POST demande, withCredentials au port 8081 a provoqué le message "ATTENTION: les en-têtes provisoires sont affichés" dans l'inspecteur et, bien sûr, également bloqué la demande dans son ensemble.
Ma solution consistait à configurer Apache pour que le proxy transfère la demande du port SSL habituel de 443 au port SSL du nœud 8081 (le nœud doit se trouver sur un port supérieur, car il ne peut pas être exécuté en tant que root dans prod). Je suppose donc que Chrome n'aime pas les requêtes SSL adressées à des ports SSL non conventionnels, mais peut-être que leur message d'erreur pourrait être plus spécifique.
HTTP/2 Les ressources poussées produiront Provisional headers are shown dans l'inspecteur pour la même théorie que @wvega publiée dans sa réponse ci-dessus .
e.g: Étant donné que le serveur a envoyé la (les) ressource (s) au client (avant que le client ne le demande), le navigateur a les ressources mises en cache et par conséquent, le client ne fait jamais une demande; Alors parce que...
... 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.
Pour chrome v72 +, ce qui me l'a résolu n'était que ceci:
allez à chrome://flags/ et désactivez ces 3 drapeaux
- Désactiver l'isolation de site
- Activer le service réseau
- Exécution du service réseau en cours de traitement
ou vous pouvez le faire en ligne de commande:
chrome --disable-site-isolation-trials --disable-features=NetworkService,NetworkServiceInProcess
pourquoi cela se produit-il?
Il semble que Google restructure son moteur Chromium en une structure modulaire, dans laquelle différents services seront séparés en modules et processus autonomes. Ils appellent ce processus de maintenance. Le service réseau est la première étape, le service UI, le service d'identité et le service de périphérique sont à venir. Google fournit les informations officielles sur le site du projet Chromium .
est-ce dangereux de changer cela?
Un exemple est le réseautage: une fois que nous avons un service réseau, nous pouvons choisir de l'exécuter en dehors du processus pour une meilleure stabilité/sécurité, ou en cours de processus si les ressources sont limitées . la source
Ma situation est origine croisée liée.
Situation: Le navigateur envoie une demande OPTIONS avant d'envoyer la demande réelle telle que GET ou POST. Le développeur backend oublie de traiter la requête OPTIONS en le laissant passer par le code de service, ce qui allonge le temps de traitement. Plus long que le paramètre de délai d'attente que j'ai écrit dans l'initialisation axios, qui correspond à 5 000 millisecondes. Par conséquent, la demande réelle n'a pas pu être envoyée, puis j'ai rencontré le problème provisional headers are shown.
Solution: Lorsqu'il s'agit d'une requête OPTIONS, l'API backend renvoie simplement le résultat, la requête est plus rapide et la requête réelle peut être envoyée avant l'expiration du délai.
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 la balise A que j'utilisais pour envoyer le message. J'avais tapé href = " javacsript :;" (inverser le 's' et le 'c') .. cela a amené le script à essayer de rafraîchir la page alors que le message essayait de se déclencher corrigé la faute de frappe et cela a parfaitement fonctionné pour moi.
Ce message peut apparaître lorsque le site Web est protégé avec HSTS . Ensuite, lorsque quelqu'un se connecte à la version HTTP de l'URL, le navigateur, comme indiqué par HSTS, n'émet pas de requête HTTP, mais redirige en interne vers la ressource HTTPS en toute sécurité. Cela évite les attaques par rétrogradation HTTPS telles que sslstrip .
Cela peut également arriver à cause d'une nouvelle fonctionnalité appelée isolement de site } _
_ { Cette page détaille le problème et une solution de contournement } _. Ce qui doit aller à chrome://flags/#site-isolation-trial-opt-out en chrome et changer ce paramètre en "Opt-out" et recharger chrome.
C'est un problème connu . Cependant, cette page indique que le problème a été corrigé dans chrome 68, mais je suis sous chrome 68 et le problème persiste.
J'ai eu ce problème très récemment (aujourd'hui même) où un appel de AJAX a été envoyé au serveur et où Chrome a déclenché l'option "Attention: les en-têtes provisoires sont affichés." Dans les scripts côté serveur PHP, il existe des requêtes MySQL qui peuvent être assez instantanées ou prendre quelques secondes en fonction du scénario donné. La réponse de mon serveur n'est pas renvoyée au navigateur tant que les requêtes ne sont pas terminées. J'ai constaté que cette erreur se produisait uniquement lorsque des requêtes fastidieuses (quelques secondes au total) étaient effectuées et empêchaient le renvoi de la réponse.
Mon scénario implique la très rare possibilité de modifier une table en ajoutant/supprimant des centaines de colonnes pour la sortie du modèle météorologique ... d'où le délai de réponse lié à l'itération d'une boucle de requêtes ALTER TABLE.
Cela se produit fréquemment si vous suivez un événement et que vous n'empêchez pas l'action par défaut. Par exemple, si vous avez un événement click, vous souhaiterez inclure:
e.preventDefault();
ou
return false;
Sinon, vous verrez l'avertissement provisoire des en-têtes ainsi que l'état "annulé" dans l'onglet Réseau de votre console Web.
Ce problème s'est produit lorsque j'ai envoyé un en-tête d'autorisation HTTP non valide. J'ai oublié de l'encoder en base64.
C'est peut-être parce que vous avez envoyé une demande Ajax, mais vous passez maintenant d'une page à une autre à l'aide de location.href ou de quelque chose du genre. La requête précédente a donc échoué.
Dans mon cas, il s'agissait simplement d'un faux chemin d'accès à une ressource (svg/img)
J'ai rencontré ce problème avec un appel AJAX qui ne serait jamais complet. J'ai suivi les conseils et astuces de wvega concernant le débogage avec chrome://net-internals afin de déterminer éventuellement un autre gestionnaire d'événements click dans la page, à l'écoute sur un nœud parent, obligeant le navigateur à accéder à la même URL (ce qui n'était pas facilement visible).
La solution consistait à ajouter event.stopPropagation() dans un gestionnaire click sur le bouton d'envoi de formulaire afin d'éviter que le clic ne déborde du DOM et annule la demande AJAX en cours (initiée via un gestionnaire submit sur form).
Utilisez ce code de poing de votre code:
header('Cache-Control: no-cache, no-store, must-revalidate');
header('Pragma: no-cache');
header('Expires: 0');
Cela fonctionne pour moi.
Je suis tombé dessus et ça a disparu quand je suis passé de https à http. Les certificats SSL que nous utilisons dans dev ne sont pas vérifiés par une tierce partie. Ils sont juste générés localement.
Les mêmes appels fonctionnent parfaitement dans Chrome Canary et Firefox. Ces navigateurs ne semblent pas être aussi stricts à propos du certificat SSL que Chrome. Les appels échouaient dans Chrome avec le message "ATTENTION: en-têtes provisoires ...".
Je pense/espère que lorsque nous utiliserons un certificat SSL légitime en scène, nous ne verrons plus ce comportement dans Chrome.
J'ai constaté ce problème lorsque le nombre de connexions à mon serveur dépassait la limite maximale de 6 connexions par serveur de Chrome.
Un autre scénario possible que j'ai déjà vu - la même demande exacte est renvoyée juste après quelques millisecondes (probablement à cause d'un bogue du côté client).
Dans ce cas, vous verrez également que le statut de la première requête est "annulé" et que le temps de latence n'est que de plusieurs millisecondes.
Ce message d'avertissement apparaît également si la réponse est invalide et donc abandonnée par le navigateur.
Dans mon cas, la demande a été correctement envoyée au serveur, le code côté serveur a alors généré une erreur et ma gestion d'erreur personnalisée a renvoyé le message d'erreur dans le champ du message d'état HTTP. Mais cette erreur n’a pas été reçue côté client, en raison de caractères non valides dans le message d’erreur (décrit ici http://aspnetwebstack.codeplex.com/workitem/1386 ), ce qui a entraîné des en-têtes de réponse corrompus.
J'ai exécuté ce problème lorsque j'ai essayé de charger main.js pour require js pour la deuxième fois après avoir apporté des modifications suite à une erreur. Je viens d’activer les paramètres des outils de développement "Désactiver le cache (lorsque DevTools est ouvert)" ... ... Et cela a fait le charme.
Cela se produisait pour moi, quand j'avais un lien de téléchargement et après avoir cliqué dessus, j'essayais aussi d'attraper le clic avec jQuery et d'envoyer une requête en ajax. Le problème tient au fait que lorsque vous cliquez sur le lien de téléchargement, vous quittez la page, même si cela n’a pas l’air si. S'il n'y avait pas de transfert de fichier, vous verriez la page demandée. J'ai donc défini un target = "_ blank" pour éviter ce problème.
J'ai eu cette erreur quand j'ai essayé d'imprimer une page dans un popup. La boîte de dialogue d'impression était affichée et attend toujours mon acceptation ou l'annulation de l'impression dans la fenêtre contextuelle, tandis que dans la page maquette attendait également en arrière-plan affichant le message. ATTENTION les en-têtes provisoires sont affichés quand j'ai essayé de cliquer sur un autre lien.
Dans mon cas, la solution consistait à supprimer le script window.print (); qu'il était en train d'exécuter sur le <body> de la fenêtre contextuelle afin d'empêcher la boîte de dialogue d'impression.
Ce problème se produira également lors de l’utilisation de packages tels que webpack-hot-middleware et lors de l’ouverture simultanée de plusieurs pages. webpack-hot-middleware créera une connexion pour chaque page pour écouter les modifications de code puis pour actualiser la page. Chaque navigateur a une limite de max-connections-per-server qui est 6 pour Chrome. Par conséquent, si vous avez déjà ouvert plus de 6 pages dans Chrome, la nouvelle demande sera suspendue jusqu'à la fermeture de certaines pages.
Je viens de jeter mes deux sous. J'écris une application Web à l'aide de demandes CORS et d'un service Web complet RESTful. J'ai trouvé que chrome lève cette erreur quand j'ai une exception non gérée ou une erreur PHP. Juste au cas où quelqu'un d’autre se heurterait au problème. J'ai découvert que lorsque cela se produisait, je pouvais lancer l'application Chrome "Postman - Rest Client" et exécuter exactement la même demande, mais dans l'application Chrome, j'obtiendrai l'erreur PHP renvoyée à la place de cette description Erreur.
Dans mon cas, les paramètres de corps que j’envoyais dans la demande de publication et la logique que j’écrivais en fonction des paramètres de corps étaient erronés; la réponse n’a donc pas été envoyée. alors j'ai eu cette erreur.
example: post request body (a: alsldfjfj) which I was sending
mais j'avais écrit le code pour valider "b" au lieu de "a"
Le message "Attention: les en-têtes provisoires sont affichés" peut s'afficher lorsqu'un site Web hébergé sur HTTPS appelle un appel à WebApi hébergé sur HTTP. Vous pouvez vérifier si toutes vos Api sont HTTPS. Le navigateur empêche de faire un appel à une ressource non sécurisée. Vous pouvez voir un message similaire dans votre code lorsque vous utilisez FETCH API sur un domaine avec HTTP.
Contenu mixte: La page ' https://website.com ' a été chargée via HTTPS, mais une ressource non sécurisée a été demandée ' http://webapi.com '. Cette demande a été bloquée. le contenu doit être servi sur HTTPS.
J'ai eu un problème similaire avec mon application MEAN. Dans mon cas, le problème se produisait dans une seule demande de get. J'ai essayé de supprimer adblock, de nettoyer le cache et de naviguer avec différents navigateurs. Rien n'a aidé.
enfin, j'ai compris que l'API essayait de renvoyer un énorme objet JSON. Quand j'ai essayé d'envoyer un petit objet, cela fonctionnait bien. Enfin, j'ai modifié mon implémentation pour renvoyer un tampon au lieu d'un JSON.
Je souhaite que expressJS jette une erreur dans ce cas.
Dans mon cas, la cause était l'extension AdBlock.
La demande au serveur a été traitée et j'ai reçu la réponse, mais je ne pouvais pas voir les cookies de la demande car "En-têtes provisoires .." était affiché dans les outils de développement. Après avoir désactivé AdBlock pour le site, l'avertissement a disparu et les outils de développement ont recommencé à afficher les cookies.
Pour que la modification soit prise en compte, il était également nécessaire de fermer les outils de développement et de rafraîchir la page.
Les données en cache supprimées de l'historique du navigateur fonctionnent pour moi.
Voici une autre solution.
Si vous rencontrez ce problème avec l'appel de $ ajax (), ajoutez http:// avant que votre hôte serveur ne résolve votre problème.
var requestURL = "http://" + serverHost;
$.ajax({
dataType: "json",
url: requestURL,
data: data,
success: success
});
Si vous développez une application Asp.Net Mvc et tentez de renvoyer une variable JsonResult dans votre contrôleur, veillez à ajouter JsonRequestBehavior.AllowGet à la méthode Json. Cela a réglé le problème pour moi.
public JsonResult GetTaskSubCategories(int id)
{
var subcategs = FindSubCategories(id);
return Json(subcategs, JsonRequestBehavior.AllowGet); //<-- Notice it has two parameters
}