La requête Chrome indique « Les en-têtes provisoires sont affichées » :
La première fois que le navigateur envoie cette demande, celle-ci est bloquée et aucune réponse n’est reçue. Lorsque le navigateur est invité à envoyer à nouveau cette requête, il signalera cet avertissement si la même demande précédente n’a pas été répondue, alors où sera le problème ?
Je l’ai rencontré plusieurs fois dans le projet, et je vais présenter différents scénarios respectivement :
1. Les en-têtes provisoires s’affichent lors de l’accès au navigateur de tous les clients :
Comment gérer cela : Vérifiez la page où la requête a été déclenchée pour voir si la soumission du formulaire et la demande ajax sont déclenchées en même temps.
Par exemple, définir un bouton, taper est submit, et définir un événement ajax pour le bouton ;
Ce scénario est l’un de ceux qui sont apparus lors de notre précédent processus de développement
2. Certains navigateurs clients apparaissent
Comment gérer cela : Appelez le chrome://net-internals/#events de Chrome, puis relancez la requête, puis vérifiez le journal des requêtes où les en-têtes provisoires sont affichés ;
Voyez si delegate_blocked_by mots-clés existent ; Cela est généralement dû au plug-in du navigateur ou au logiciel du client qui intercepte la requête ; La situation que nous avons est interceptée par WebSense Endpoint ;
Si c’est le cas, cela peut essentiellement être ignoré, c’est le problème du client lui-même ; Vous pouvez envisager de désinstaller le plugin ou le logiciel et réessayer pour voir s’il apparaît toujours ; Si cela se produit encore, veuillez vérifier si cela relève des conditions suivantes
3. Tous les clients ont eu cette erreur de manière aléatoire et occasionnelle, et si c’est le cas, il s’agit souvent d’un problème côté serveur
Méthode de gestion : Dépanner en fonction de l’architecture de déploiement. Par exemple, quelques processus clés dans notre architecture de déploiement sont nginx----> application passerelle----> équilibreur de charge F5----> serveur d’applications (docker)
Vous pouvez dépanner couche par couche, la façon simple est d’écrire directement une requête de curl for loop avec la commande shell du serveur, et d’appeler d’abord le serveur d’application le plus bas (si vous craignez que la pression ne soit pas suffisante, vous pouvez l’appuyer avec plusieurs threads) ; Poussez vers le haut à tour de rôle ; Lors des tests de résistance, vous pouvez voir en temps réel si la requête sera bloquée ; Si cela est découvert, il est très probable que ce soit le problème :
À ce jour, nous avons rencontré deux situations : l’une concerne le niveau F5, certaines requêtes sont mal équilibrées vers le serveur d’applications ; Il y a aussi une situation où il reste bloqué au niveau nginx ;
Solution : La stratégie d’équilibrage de charge au niveau F5 a été modifiée, passant de performance L4 à standard.
Plan de gestion de situation bloquée au niveau de nginx : je n’ai en fait pas participé à cette situation, et je comprends que modifier de nombreuses configurations de nginx n’a aucun effet, et finalement je les tue et réinstalles, donc je n’ai pas trouvé le point clé
Ma propre solution, comme le Fiddler 4 que j’utilise n’est pas fermé normalement, alors j’ai rouvert Fiddler 4, essayé de demander le site et il est revenu à la normale, à ce moment-là, j’ai fermé Fiddler 4 à nouveau.
|
Publié sur 22/05/2018 22:57:55
|
|
|
|
