Que se passe-t-il lorsque je survole un lien dans Chrome?
Lorsque vous cliquez sur ce lien (http://a//%%30%30) dans Google Chrome, celui-ci casse et ferme tous les onglets et toutes les instances.
Mais, dans certains cas, il suffit de survoler le lien et l’onglet se bloque.
Que se passe-t-il lorsque je survole ce lien? Je veux dire, que fait Chrome lorsqu'un lien est survolé?
La panne est due à un bogue récemment découvert dans Chrome - et autres navigateurs WebKit (!) * - spécifiquement liés à l'un ou l'autre %%30%30, %0%30 ou %%300 faisant partie de l'URL, qui finissent tous par représenter le même symbole: null . Vous pouvez en savoir plus sur le bogue ici .
Ce n'est pas un bug qui affecte la plupart des liens, vous n'avez donc généralement pas à vous soucier de survoler les liens.
Notes:
* Autres navigateurs WebKit comprennent Safari, Opera, Navigateur Steam, Midori, S60 (Symbian), Blackberry Browser et le navigateur de PlayStation 3 - mais non Firefox, Internet Explorer ou Edge.
Edit: Ce bogue a maintenant été corrigé dans Chrome 45.0.2454.101 comme Deltik indique.
Plus sur ce qui se passe
Le problème est lié au canoniseur d'URL , qui s'exécute dès que vous survolez un lien - éventuellement pour afficher le lien dans la barre d'état du navigateur. , et pour prélecture la page Web afin qu’elle se charge plus rapidement une fois cliqué.
En ce qui concerne le rôle du canoniseur d'URL:
Lorsqu'une URL est écrite dans HTML, elle peut être écrite sous une forme telle que /home ou ../../home, mais les navigateurs doivent la traduire en quelque chose avec un protocole et un domaine, tel que http://superuser.com/home. De plus, l’URL peut contenir RL Escapes qui doivent être traduits , et ces échappements sont pourcentage encodé , comme %%30%30. (Une liste plus exhaustive des échappements d'URL ici ).
La fonctionnalité qui gère cette traduction d'URL correspond à ce qui se bloque, car elle reçoit des entrées que les développeurs ne s'attendaient pas/ne pouvaient pas gérer.
Voici un résumé du changement de code qui a résolu le problème:
Traitez correctement les échappements imbriqués problématiques dans les chemins d’URL.
Spécifiquement, si une évacuation dans l’entrée entraîne une URL, l’URL de sortie contenant une nouvelle séquence échappée, par ex. convertissant l'entrée "%% 30% 30" en "% 00", échappez le '%' initial en tant que "% 25" pour vous assurer que la séquence de sortie n'est pas traitée comme une nouvelle séquence d'échappement valide.
Cela garantit que la canonisation de la même URL une deuxième fois ne la modifiera pas, ce qui est important pour éviter les plantages et autres bogues à divers endroits dans les versions de débogage et de publication.
Comme le dit Fabio Turati,
Lorsque vous survolez un lien, Chrome l'affiche dans le coin inférieur gauche. Cela nécessite certains traitements, y compris la "traduction" de caractères spécialement codés.
Cependant, d'après votre commentaire et votre commentaire, je pense que vous êtes davantage préoccupé par le fait que Chrome se connecte ou non au lien en arrière-plan. C'est le cas , il en va de même pour les autres navigateurs modernes ( Firefox , Opera ). Vous pouvez désactiver le prélecture dans les préférences de Chrome ou installer Block Origin pour obtenir davantage de paramètres de confidentialité.
Je voulais donner quelques précisions sur ce qui se passe exactement ici.
Fondamentalement,% 30 est un 0 codé en URL, et% 00 est un NULL codé en URL (affiché en binaire sous la forme 0000 0000). Donc, si vous avez une URL avec un caractère codé imbriqué qui décodera en NULL, le bogue se produit.
Chrome procède comme suit lors de la canonisation d'une URL (source: https://code.google.com/p/chromium/issues/detail?id=533361#c1 ):
- Une chaîne d'entrée "http: //a.com/%%30%30" n'est pas échappée à " http://a.com/% " et est considérée comme une GURL valide.
- Cette GURL est finalement envoyée à GURLToDatabaseURL (), qui appelle ReplaceComponents () dessus pour effacer le nom d'utilisateur et le mot de passe.
- ReplaceComponents () re-canonicalise l'URL.
- La canonisation du chemin frappe la séquence "% 00", unescapes, voit qu'il s'agit d'un caractère 0 invalide dans les URL, le laisse échappé, mais marque l'URL résultante comme non valide.
- Une fois que nous sommes revenus à GURLToDatabaseURL (), celui-ci appelle .spec () sur la nouvelle URL, en s’attendant à ce qu’elle soit valide, car l’URL d’entrée était garantie et nous avons simplement supprimé le nom d’utilisateur et le mot de passe. Cette DCHECKs.
Donc, l'URL est d'abord considéré comme valide, mais après la suppression de certaines données privées, il est invalidé. Toutefois, une fois ces données supprimées, la fonction qui a appelé ce code particulier attend une URL valide.
Une partie de la raison pour laquelle cette URL est considérée comme non valide tient au fait que NULL est utilisé dans un certain nombre de logiciels et de langages plus anciens pour indiquer la fin d'une chaîne (car il s'agit essentiellement de 8 zéros dans une ligne, ce qui est facile à détecter pour un ordinateur).