Que faire avec chrome en envoyant des requêtes supplémentaires?
Google Chrome envoie plusieurs requêtes pour extraire une page. Il ne s'agit apparemment ni d'un bogue, mais d'une fonctionnalité. Et nous, les développeurs, devons simplement nous en occuper.
Dans la mesure où je pouvais creuser en cinq minutes, Chrome le fait simplement pour accélérer la navigation. Si une connexion est perdue, la seconde prend le relais.
Je suppose que si le site Web est bien développé, sa fonctionnalité ne sera pas interrompue, car les demandes multiples ne sont tout simplement pas nouvelles.
Mais je ne sais pas si j'ai expliqué toutes les situations que cette fonctionnalité peut générer.
Y aurait-il des situations spéciales? Des meilleures pratiques pour y faire face?
Mise à jour 1: Je vois maintenant pourquoi la page de ma banque génère une erreur lorsque j'ouvre la page avec chrome! Il dit: "Une seule fenêtre du navigateur devrait être ouverte." C'est leur solution aux menaces de sécurité? !!
Votre meilleur choix est de suivre les meilleures pratiques de développement Web standard: ne changez pas l'état de l'application à la suite d'un appel GET.
Si vous êtes inquiet, je vous recommande de mettre à jour vos tests unitaires de couche de données pour que les appels GET soient dupliqués et d’assurer qu'ils renvoient les mêmes données.
(Au fait, je ne vois pas ce comportement avec Chrome 8.0.552.224, c'est très récent?)
J'ai vu le comportement soumis lors de l'écriture de mon application serveur et j'ai constaté que les réponses précédentes ne sont probablement pas vraies.
Chrome distribue une requête unique à plusieurs utilisateurs http pour récupérer des ressources en parallèle. Dans ce cas, il s'agit d'une image qu'il récupère sous la forme d'un http get séparé.
J'ai joint une capture d'écran de la capture de paquets par l'intermédiaire de Wireshark.
Il s’agit d’une simple requête get sur le port 8080 pour laquelle mon serveur renvoie un message hello.
Chrome envoie la deuxième demande d'obtention pour obtention de l'icône de favori que vous voyez en haut de chaque onglet ouvert . Ce n'est PAS une seconde pour prendre du temps ou une telle chose.
Cela devrait être considéré comme un autre élément différent selon les navigateurs.
Voici une question de référence que j'ai trouvée plus tard
Chrome envoie deux demandes SO
Ce problème peut être provoqué par SRC = '' ou SRC = '#' dans IMG ou (comme dans mon cas), balise IFRAME. Remplacer "#" par "about: blank" a résolu le problème.
Ici http://forums.mozillazine.org/viewtopic.php?f=7&t=1816755 ils disent que les balises SCRIPT peuvent également poser problème.
Mon observation de cette caractéristique (bogue/fonctionnalité/quoi que ce soit) se produit lorsque je tape une URL et que la saisie semi-automatique atterrit sur une correspondance tout en tapant l'URL. Chrome prend cette correspondance et récupère la page, je suppose pour les avantages de la mise en cache qui se produiraient lors du chargement de la page vous-même ....
Cela peut également être causé par les balises link avec des attributs href vides, au moins dans Chromium (v41). Par exemple, chacune des lignes suivantes générera une requête supplémentaire sur la page:
<link rel="shortcut icon" href="" />
<link rel="icon" type="image/x-icon" href="" />
<link rel="icon" type="image/png" href="" />
Il est évident que la recherche d'attributs vides dans la page est un bon point de départ, soit href ou src.
Cela ne se produit que lorsque j'active l'extension "webug" (qui remplace FirePHP pour Chrome). Si je désactive l'extension, le serveur reçoit une seule demande.
J'avais ce problème, mais aucune des solutions ici n'était le problème. Pour moi, cela était dû à l'extension APNG de Chrome (prise en charge des PNG animés). Une fois que j'ai désactivé cette extension, je n'ai plus vu de double demande d'images dans le navigateur. Je devrais noter que, que la page produise ou non une image PNG, la désactivation de cette extension corrigeait le problème (c.-à-d. APNG semble provoquer le problème pour les images, quel que soit leur type, elles ne doivent pas obligatoirement être PNG).
J'avais aussi beaucoup d'autres extensions (comme "Web Developer", ce que beaucoup ont suggéré, est le problème), et ce n'était pas le problème. Les désactiver ne résout pas le problème. Je cours également en mode développeur et cela ne fait aucune différence pour moi.
Je viens de mettre en œuvre un jeton Guid à usage unique (asp.net/TSQL) qui est généré lorsque le premier formulaire d'une série de deux (+ page de confirmation) est généré. Le jeton est enregistré comme "en attente" dans la base de données lorsqu’il est généré. Le jeton Guid accompagne les publications en tant que champ caché et est finalement marqué comme fermé lorsque l'opération utilisateur est terminée (paiement). Ce mécanisme fonctionne et évite que les formulaires ne soient soumis à nouveau après le paiement. Cependant, je vois 2 ou 3 (!?) Jetons supplémentaires générés par des demandes supplémentaires rapidement les uns après les autres. La première demande est ce qui se termine devant l'utilisateur (localhost - c'est-à-dire, moi), où le contenu généré aboutit aux deux autres demandes, je n'en ai aucune idée. Au départ, je me demandais pourquoi les gestionnaires Page_Load renvoyaient plusieurs fois pour une impression de page. J'ai donc essayé d'utiliser un indicateur dans Http.Context.Current - mais à mon grand désarroi, les demandes suivantes parvenaient au même URL, mais sans données de publication, et Tableaux Http.Context.Current vides - c'est-à-dire, complètement (à des fins pratiques), séparer les requêtes http. Comment gérer ça? Une sorte de jeton et de logique pour refuser les demandes de contenu ultérieur du corps de page pendant que la première est en cours de traitement? Je suppose que cela pourrait se dérouler dans un contexte global?
J'ai le même bug. Et comme le réponse précédente ce problème est dû au fait que j'ai installé l’extension chrome Validator . Une fois l’extension désactivée, fonctionne normalement.
Dans mon cas, c’était Chrome (v65) qui créait un deuxième GET /favicon.ico, même si la réponse était text/plain, donc clairement pas <link dans la référence de l’icône. Il a cessé de le faire après avoir répondu avec un 404.
Firefox (v59) envoyait 2 demandes pour favicon; encore une fois, il a cessé de le faire après la 404.
Je veux juste mettre à jour sur celui-ci. J'ai rencontré le même problème mais sur le style css.
J'ai regardé tous mes src, href, balises de script et aucun d'entre eux n'avait de chaîne vide. L'entrée incriminée était la suivante:
<div class="Picture" style="background-image: url('');"> </div>
Assurez-vous également de vérifier vos styles pour la chaîne d'URL vide
Dans mon cas, j'ai des données enpoint (json) sur un serveur différent et le navigateur envoie d'abord une requête vide (Request Method: OPTIONS) pour vérifier si un point de terminaison accepte les demandes de mon serveur, règle Même origine. De plus, goot to know is a Angular 1 App. En conclusion, je soumets des demandes de localhost à des données en ligne factices.