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 source
chrome://flags/#site-isolation-trial-opt-out
Réponses:
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
chrome://net-export/
dans la barre d'adresse et appuyez sur Entrée.Pour les anciennes versions de chrome
chrome://net-internals
dans la barre d'adresse et appuyez sur Entrée.la source
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.
la source
Pour le chrome v72 +, ce que j'ai résolu n'était que ceci:
aller
chrome://flags/
et désactiver ces 3 drapeauxou vous pouvez le faire à partir de la ligne de commande:
pourquoi cela arrive?
est-il dangereux de changer cela?
la source
localhost:8080
etgoogle.com
(!?). La désactivation de l'isolement du site a corrigé google.com, mais pas l'hôte local. Désactiver uniquement les deux autres options l'a corrigé pour tous les cas.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.
la source
'/graphql': { target: 'http://10.10.1.38:4000', changeOrigin: true }
"proxy": "http://192.168.98.110:1234"
à monpackage.json
dans un projet create-react-app. Contrairement à la réponse, je n'utilise HTTPS nulle part dans le développement, mais cela était nécessaire car mon application et mon API sont sur des adresses IP différentes.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 aller
chrome://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.
la source
HTTP / 2 Les ressources
Provisional 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...
la source
Ma situation est liée à l' origine croisée .
Situation: le navigateur envoie une
OPTIONS
demande avant d'envoyer la demande réelle commeGET
ouPOST
. Le développeur principal oublie de traiter laOPTIONS
demande, 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'axios
initialisation, qui est de 5000 millisecondes. Par conséquent, la vraie demande n'a pas pu être envoyée, puis j'ai rencontré leprovisional headers are shown
problème.Solution: en ce qui concerne la
OPTIONS
demande, 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.la source
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.
la source
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 .
la source
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é.
la source
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.
la source
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-internals
pour éventuellement déterminer un autreclick
gestionnaire 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()
unclick
gestionnaire 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 unsubmit
gestionnaire sur leform
).la source
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.
la source
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:
ou
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.
la source
Dans mon cas, c'était juste un faux chemin d'accès à une ressource (svg / img)
la source
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.
la source
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.
la source
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.
la source
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.
la source
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.
la source
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.
la source
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.la source
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.
la source
Utilisez le premier code de votre code:
Cela fonctionne pour moi.
la source
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.la source
Si vous développez une application Asp.Net Mvc et que vous essayez de renvoyer un
JsonResult
dans votre contrôleur, assurez-vous d'ajouterJsonRequestBehavior.AllowGet
à laJson
méthode. Cela m'a arrangé.la source
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.
la source
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.
la source
Ce problème se produit également lors de l'utilisation de certains packages comme
webpack-hot-middleware
et de l'ouverture de plusieurs pages en même temps.webpack-hot-middleware
va créer une connexion pour chaque page pour écouter les changements de code puis pour rafraîchir la page. Chaque navigateur a unemax-connections-per-server
limitation 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.la source
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
la source