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

J'ai remarqué un étrange message d'avertissement en regardant les 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 de peut-être pertinent, Network Panel: ajoutez des précautions concernant les en-têtes de demande provisoires , mais je ne pouvais pas le comprendre pleinement. Des questions connexes peuvent être trouvées. Les demandes de blocage de Chrome ainsi que XMLHttpRequest ne peuvent pas se charger. Les ressources déchargées montrent la prudence: les en-têtes provisoires sont affichés .

Semblable à la première question , ma ressource a été bloquée, mais a ensuite chargé automatiquement la même ressource. Contrairement à la deuxième question , je ne veux rien corriger; 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, donc les en-têtes affichés ne sont pas réels. Comme expliqué dans le problème que vous avez référencé, les vrais en-têtes 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 dans Chrome:

Pour les dernières versions de chrome

• Tapez chrome://net-export/dans la barre d'adresse et appuyez sur Entrée.
• Commencer l'enregistrement. Et enregistrez le fichier d'enregistrement au niveau local.
• Ouvrez la page qui présente des problèmes.
• Retour à net-internals
• Vous pouvez afficher le fichier journal enregistré ici https://netlog-viewer.appspot.com/#import
• cliquez sur les événements (###) 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.

Pour les anciennes versions de chrome

• Tapez chrome://net-internalsdans la barre d'adresse et appuyez sur Entrée.
• Ouvrez la page qui présente des problèmes.
• Revenez à net-internals, cliquez sur les événements (###) 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.

Pour le chrome v72 +, ce que j'ai résolu n'était que ceci:

aller chrome://flags/et désactiver ces 3 drapeaux

• Désactiver l'isolement du site
• Activer le service réseau
• Exécute le service réseau en cours

ou vous pouvez le faire à partir de la ligne de commande:

chrome --disable-site-isolation-trials --disable-features=NetworkService,NetworkServiceInProcess

pourquoi cela arrive?

Il semble que Google refactorise son moteur Chromium dans une structure modulaire, où différents services seront séparés en modules et processus autonomes. Ils appellent ce processus la servicification. Le service réseau est la première étape, le service d'interface utilisateur, le service d'identité et le service de périphérique arrivent. Google fournit les informations officielles sur le site du projet Chromium .

est-il dangereux de changer cela?

Un exemple est la mise en réseau: une fois que nous avons un service réseau, nous pouvons choisir de l'exécuter hors du processus pour une meilleure stabilité / sécurité, ou en cours si nous sommes limités en ressources . la source

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

J'exécute une pile js complète, un frontal angulaire et un nœud principal sur SSL, et l'API se trouve sur un domaine différent fonctionnant sur le port 8081, donc je fais des demandes CORS et withCredentials car je supprime un cookie de session de l'API

Donc, plus précisément, mon scénario était le suivant: la requête POST, avec les informations d'identification sur le port 8081 a provoqué le message "ATTENTION: les en-têtes provisoires sont affichés" dans l'inspecteur et a bien sûr également bloqué la demande tous ensemble.

Ma solution était de configurer apache pour passer par proxy la demande du port SSL habituel de 443 au port SSL de nœud de 8081 (le nœud doit être 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 demandes SSL vers des ports SSL non conventionnels, mais peut-être que leur message d'erreur pourrait être plus spécifique.

Cela peut également se produire (pour les demandes d'origine croisée uniquement) en raison d'une nouvelle fonctionnalité appelée isolation du site

Cette page détaille le problème et une solution de contournement . À qui allerchrome://flags/#site-isolation-trial-opt-out dans Chrome et de changer ce paramètre sur "Opt-out" et de recharger Chrome.

C'est un problème connu . Cependant, cette page indique qu'il est résolu dans Chrome 68, mais j'utilise Chrome 68 et j'ai toujours le problème.

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

Par exemple: depuis que le serveur a poussé les ressources vers le client ( avant que le client ne les demande ), le navigateur a les ressources mises en cache et donc le client ne fait / n'a jamais 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 demande a été bloquée.

Ma situation est liée à l' origine croisée .
Situation: le navigateur envoie une OPTIONSdemande avant d'envoyer la demande réelle comme GETou POST. Le développeur principal oublie de traiter la OPTIONSdemande, la laissant passer par le code de service, ce qui rend le temps de traitement trop long. Plus long que le paramètre de délai d'attente que j'ai écrit lors de l' axiosinitialisation, qui est de 5000 millisecondes. Par conséquent, la vraie demande n'a pas pu être envoyée, puis j'ai rencontré le provisional headers are shownproblème.
Solution: en ce qui concerne la OPTIONSdemande, le backend api renvoie simplement le résultat, cela rend la demande plus rapide et la vraie demande 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 déclencher le message. J'avais tapé href = " javacsript:; " (en inversant le 's' et le 'c') .. cela a amené le script à essayer de rafraîchir la page pendant que le post tentait de se déclencher. corrigé la faute de frappe et cela a parfaitement fonctionné 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 demande HTTP, mais redirige en interne vers la ressource HTTPS en toute sécurité. Cela permet d'éviter les attaques de rétrogradation HTTPS telles que sslstrip .

Cela peut être dû au fait que vous avez envoyé une demande Ajax, en même temps que vous passez votre page à une autre en utilisant location.href ou quelque chose comme ça. La demande précédente a donc échoué.

Ce message d'avertissement apparaît également si la réponse n'est pas valide et est donc supprimée par le navigateur.

Dans mon cas, la demande a été correctement envoyée au serveur, le code côté serveur a ensuite produit une erreur et ma gestion des erreurs 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 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 ont entraîné des en-têtes de réponse corrompus.

J'ai rencontré ce problème avec un appel AJAX qui ne se terminerait jamais. J'ai suivi les conseils et astuces de wvega sur le débogage avec chrome://net-internalspour éventuellement déterminer un autre clickgestionnaire d'événements dans la page, en écoutant sur un nœud parent, provoquait la navigation du navigateur vers la même URL (donc ce n'était pas facilement perceptible).

La solution consistait à ajouter event.stopPropagation()un clickgestionnaire sur le bouton d'envoi du formulaire pour empêcher le clic de se propager dans le DOM et d'annuler la demande AJAX en cours (initiée via un submitgestionnaire sur le form).

J'ai eu cela très récemment (aujourd'hui en fait) où j'ai eu un appel AJAX vers le serveur et Chrome déclenche la "Attention: les en-têtes provisoires sont affichés." Dans le script PHP côté serveur, il existe des requêtes MySQL qui peuvent être à peu près instantanées ou prendre quelques secondes selon le scénario donné. La réponse de mon serveur n'est renvoyée au navigateur qu'une fois les requêtes terminées. J'ai constaté que j'obtiens cette erreur uniquement lorsque des requêtes longues (jusqu'à quelques secondes au total) sont effectuées et empêchent la réponse d'être renvoyée.

Mon scénario implique la possibilité très rare 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.

Cela se produit généralement 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 de clic, vous souhaiterez inclure:

e.preventDefault();

ou

return false;

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

Dans mon cas, c'était juste un faux chemin d'accès à une ressource (svg / img)

Ce problème m'est apparu lorsque j'envoyais un en-tête d'autorisation HTTP non valide. J'ai oublié de l'encoder en base64.

Je suis tombé sur cela et cela a disparu lorsque je suis passé de https à http. Les certificats SSL que nous utilisons dans le développement ne sont pas vérifiés par un tiers. Ce ne sont que des certificats de développement générés localement.

Les mêmes appels fonctionnent très bien dans Chrome Canary et Firefox. Ces navigateurs ne semblent pas être aussi stricts sur le certificat SSL que Chrome. Les appels échouaient dans Chrome avec le message "ATTENTION: en-têtes provisoires ...".

Je pense / j'espère que lorsque nous utiliserons un certificat SSL légitime dans l'étape et la production, nous ne verrons plus ce comportement dans Chrome.

Je jette juste mes deux cents. J'écris une application Web à l'aide de demandes CORS et d'un service Web RESTful complet. J'ai trouvé que chrome lèvera cette erreur quand j'ai une exception non levée ou une erreur PHP levée. Au cas où quelqu'un d'autre rencontrerait le problème. J'ai trouvé que lorsque cela se produit, je peux lancer l'application Chrome "Postman - Rest Client" et exécuter la même demande, mais dans l'application Chrome, j'obtiendrai en fait l'erreur PHP qui est levée au lieu de cette erreur non descriptive.

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 dans les paramètres des outils de développement "Désactiver le cache (lorsque DevTools est ouvert)". et cela a fait le charme.

Un autre scénario possible que j'ai vu - la même demande exacte est envoyée à nouveau juste après quelques millisecondes (probablement en raison d'un bogue côté client).
Dans ce cas, vous verrez également que l'état de la première demande est "annulé" et que la latence n'est que de quelques millisecondes.

Cela se passait pour moi, quand j'avais un lien de téléchargement et après avoir cliqué dessus, j'essayais également d'attraper le clic avec jquery et d'envoyer une demande ajax. Le problème était dû au fait que lorsque vous cliquez sur le lien de téléchargement, vous quittez la page, même si elle ne l'est pas. 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 lorsque j'ai essayé d'imprimer une page dans une fenêtre contextuelle. La boîte de dialogue d'impression était affichée et attendait toujours mon acceptation ou annulation de l'impression dans la fenêtre contextuelle tandis que dans la page maître attendait également en arrière-plan montrant le message ATTENTION Les en-têtes provisoires sont affichés lorsque j'ai essayé de cliquer sur un autre lien.

Dans mon cas, la solution était de supprimer le window.print ();script qu'il exécutait sur la <body>fenêtre contextuelle pour empêcher la boîte de dialogue d'impression.

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

Utilisez le premier code de votre code:

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

Cela fonctionne pour moi.

Voici une autre solution.

Si vous rencontrez ce problème avec l'appel de $ ajax (), ajoutez http://avant que votre serveur ne résout 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 que vous essayez de renvoyer un JsonResultdans votre contrôleur, assurez-vous d'ajouter JsonRequestBehavior.AllowGetà la Jsonméthode. Cela m'a arrangé.

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

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

Le message "Attention: les en-têtes provisoires sont affichés" peut s'afficher lorsque le site Web hébergé sur HTTPS appelle un appel à WebApi hébergé sur HTTP. Vous pouvez tout vérifier si tous 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 l'API FETCH pour domaine avec HTTP.

Contenu mixte: la page sur « https://website.com » a été chargée via HTTPS, mais a demandé une ressource non sécurisée « http://webapi.com ». Cette demande a été bloquée; le contenu doit être diffusé via HTTPS.

J'ai eu un problème similaire avec mon application MEAN. Dans mon cas, le problème se produisait dans une seule demande d'obtention. J'ai essayé de supprimer adblock, j'ai effacé le cache et j'ai essayé 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 changé mon implémentation pour retourner un tampon au lieu d'un JSON.

Je souhaite qu'expressJS envoie une erreur dans ce cas.

Ce problème se produit également lors de l'utilisation de certains packages comme webpack-hot-middlewareet de l'ouverture de plusieurs pages en même temps. webpack-hot-middlewareva créer une connexion pour chaque page pour écouter les changements de code puis pour rafraîchir la page. Chaque navigateur a une max-connections-per-serverlimitation qui est de 6 pour Chrome, donc si vous avez déjà ouvert plus de 6 pages dans Chrome, la nouvelle demande y sera suspendue jusqu'à ce que vous fermiez certaines pages.

Dans mon cas, la cause était l'extension AdBlock.

La demande au serveur a été traitée et j'ai obtenu la réponse, mais je n'ai pas pu voir les cookies de demande en raison de l'affichage des "En-têtes provisoires .." 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 prenne effet, il fallait également fermer les outils de développement et actualiser la page