[Google-chrome] "ATTENTION: les en-têtes provisoires sont affichés" dans le débogueur Chrome


Answers

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

Question

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

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

J'ai trouvé quelque chose de peut-être pertinent, panneau de réseau: ajouter des précautions sur les en-têtes de demande provisoire , mais je ne pouvais pas le comprendre complètement. Des questions connexes peuvent être trouvées Les requêtes de bloc Chrome ainsi que XMLHttpRequest ne peuvent pas être chargées. Les ressources déchargées font preuve de prudence: les en-têtes provisoires sont affichés .

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




Je lance juste mes deux cents. J'écris une application Web en utilisant des requêtes CORS et un service web RESTful complet. J'ai trouvé le chrome lancera cette erreur quand j'ai une exception non levée ou une erreur PHP lancée. Juste au cas où quelqu'un d'autre se heurte au problème. J'ai trouvé que lorsque cela arrive, je peux lancer l'application Chrome "Postman - Rest Client" et exécuter exactement la même demande, mais dans l'application Chrome, je vais effectivement obtenir l'erreur PHP qui est lancée au lieu de cette erreur non descriptive.




Utilisez ce code poing de votre code:

header('Cache-Control: no-cache, no-store, must-revalidate');
header('Pragma: no-cache');
header('Expires: 0');

Cela fonctionne pour moi.




Ce message peut se produire lorsque le site Web est protégé à l'aide de 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. Cela permet d'éviter les attaques par rétrogradation HTTPS telles que sslstrip .




J'ai vu cela se produire lorsque le nombre de connexions à mon serveur dépassait la limite de 6 connexions maximum par serveur de Chrome.




Je l'ai fait venir très récemment (aujourd'hui en fait) où j'ai eu un appel AJAX sortir sur le serveur et Chrome déclenche le "Attention: les en-têtes provisoires sont affichés." Dans le script PHP côté serveur, il y a des requêtes MySQL qui peuvent être assez instantanées ou prendre quelques secondes selon le scénario donné. Ma réponse du serveur n'est pas renvoyée au navigateur tant que les requêtes ne sont pas terminées. J'ai trouvé que je reçois cette erreur uniquement lorsque des requêtes longues (jusqu'à quelques secondes au total) sont en cours et empêche la réponse d'être renvoyé.

Mon scénario implique la très rare possibilité d'avoir à modifier une table en ajoutant / supprimant des centaines de colonnes pour la sortie du modèle météo ... d'où le retard de réponse de l'itération à travers une boucle de requêtes ALTER TABLE.




J'ai exécuté ce problème quand j'ai essayé de charger main.js pour require js pour la deuxième fois après que j'ai fait des changements en raison d'erreur. Je viens d'activer les paramètres des outils de développement "Désactiver le cache (lorsque DevTools est ouvert)". et ça a fait le charme.




HTTP / 2 Les ressources poussées vont produire Les en- Provisional headers are shown dans l'inspecteur pour la même théorie que @wvega dans sa réponse ci-dessus .

Ex: Puisque le serveur a poussé la (les) ressource (s) au client ( avant que le client ne l'ait demandé ), le navigateur a les ressources cachées et donc le client ne fait jamais / a besoin de demandes; 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.




Si vous développez une application Asp.Net Mvc et que vous essayez de renvoyer un JsonResult dans votre contrôleur, assurez-vous d'ajouter JsonRequestBehavior.AllowGet à la méthode Json . Cela l'a arrangé pour moi.

public JsonResult GetTaskSubCategories(int id)
{
    var subcategs = FindSubCategories(id);

    return Json(subcategs, JsonRequestBehavior.AllowGet);  //<-- Notice it has two parameters
}



J'ai eu un problème similaire avec mon application MEAN. Dans mon cas, le problème se produisait dans une seule demande get. J'ai essayé de supprimer adblock, essayé de vider le cache et essayé avec différents navigateurs. Rien n'a aidé.

Finalement, j'ai compris que l'API essayait de retourner un énorme objet JSON. Quand j'ai essayé d'envoyer un petit objet, ça fonctionnait bien. Finalement, j'ai changé mon implémentation pour retourner un tampon au lieu d'un JSON.

Je souhaite exprimer une erreur dans ce cas.




Ce message d'avertissement se produit également si la réponse est invalide et donc abandonnée par le navigateur.

Dans mon cas, la requête a été correctement envoyée au serveur, le code côté serveur a alors généré une erreur et mon traitement d'erreur personnalisé a renvoyé le message d'erreur dans le champ du message d'état HTTP. Mais cette erreur n'a pas été reçue du côté client, en raison de caractères non valides dans le message d'erreur (décrit ici http://aspnetwebstack.codeplex.com/workitem/1386 ) qui a entraîné des en-têtes de réponse corrompus.




Une raison courante est que 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 voudrez inclure:

e.preventDefault();

ou

return false;

Si vous ne le faites pas, vous verrez l'avertissement des en-têtes provisoires ainsi qu'un statut "annulé" dans l'onglet Réseau de votre console Web.




Cela arrivait 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 ajax. Le problème était que lorsque vous cliquez sur le lien de téléchargement, vous quittez la page, même si cela ne semble pas le cas. S'il n'y aurait pas de transfert de fichier, vous verriez la page demandée. J'ai donc défini un target = "_ blank" pour éviter ce problème.