Lorsque ce lien (http://a//%%30%30) est cliqué dans Google Chrome, Chrome se bloque et ferme tous les onglets et instances.
Mais, dans certains cas, il suffit de survoler le lien pour que l'onglet plante.
Que se passe-t-il lorsque je survole ce lien ? Je veux dire, que fait Chrome lorsqu'un lien est survolé ?
L'accident est dû à un bug récemment découvert dans Chrome - et d'autres navigateurs WebKit(!)* - spécifiquement lié à %%30%30, %0%30 ou %%300 dans l'URL, qui représentent tous internement le même symbole: null. Vous pouvez en savoir plus sur le bug ici.
Ce n'est pas un bug qui affecte la plupart des liens, donc en général, vous n'avez pas à vous inquiéter en survolant les liens.
Notes:
* D'autres navigateurs WebKit incluent Safari, Opera, navigateur Steam, Midori, S60 (Symbian), navigateur Blackberry et le navigateur Playstation 3 - mais pas Firefox, Internet Explorer ou Edge.
Édition: Ce bug a été corrigé dans Chrome 45.0.2454.101 comme l'a signalé Deltik.
Le problème est lié au canoniqueur d'URL, qui s'exécute dès que vous survolez un lien - peut-être pour afficher le lien dans la barre d'état du navigateur, et pour précharger la page Web afin qu'elle se charge plus rapidement une fois cliquée.
Quant au rôle du canoniqueur d'URL:
Lorsqu'une URL est écrite en HTML, elle peut être écrite sous une forme telle que /home ou ../../home, mais les navigateurs doivent traduire cette URL en quelque chose comportant un protocole et un domaine aussi, comme http://superuser.com/home. De plus, l'URL peut contenir des échappements d'URL qui doivent être traduits, et ces échappements sont encodés en pourcentage, comme %%30%30. (Une liste plus exhaustive des échappements d'URL ici).
La fonctionnalité gérant cette traduction d'URL est celle qui finit par provoquer le crash, car elle reçoit une entrée que les développeurs n'attendaient/prenaient pas en charge.
Voici un résumé du changement de code qui a corrigé le problème:
Gérer correctement les échappements imbriqués problématiques dans les chemins d'URL.
Plus précisément, si le décodage de l'entrée conduit à l'URL de sortie contenant une nouvelle séquence échappée, par exemple en convertissant l'entrée "%%30%30" en "%00", échapper le '%' initial en "%25" pour garantir 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 crashes et autres bugs en différents endroits dans des constructions de débogage et de version publiée.
Comme le dit Fabio Turati,
Lorsque vous survolez un lien, Chrome l'affiche dans le coin inférieur gauche. Cela nécessite un certain traitement, y compris la "traduction" des caractères spécialement encodés.
Cependant, d'après votre article et votre commentaire, je pense que vous vous préoccupez davantage de savoir si Chrome se connecte au lien en arrière-plan. Il le fait, tout comme d'autres navigateurs modernes(Firefox, Opera). Vous pouvez vouloir désactiver le prefetching dans les préférences de Chrome, ou installer uBlock Origin pour obtenir plus de paramètres de confidentialité.
Je voulais donner quelques éclaircissements sur ce qui se passe exactement ici.
En gros, %30 est un 0 encodé en URL, et %00 est un NULL encodé en URL (qui est affiché en binaire comme 0000 0000). Donc si vous avez une URL qui a un caractère encodé en cascade qui se décodera en NULL, le bug se produit.
Chrome fait ce qui suit lors de la canonisation d'une URL (source : https://code.google.com/p/chromium/issues/detail?id=533361#c13) :
- Une chaîne d'entrée "http://a.com/%%30%30" est décodée en "http://a.com/%00" et considérée comme une GURL valide.
- Cette GURL est finalement envoyée à GURLToDatabaseURL(), qui appelle ReplaceComponents() dessus pour supprimer le nom d'utilisateur et le mot de passe.
- ReplaceComponents() re-canonise l'URL.
- La canonisation du chemin tombe sur la séquence "%00", la décode, voit que c'est un caractère 0 qui est invalide dans les URL, le laisse encodé, mais marque l'URL résultante comme invalide.
- Une fois de retour à GURLToDatabaseURL(), il appelle .spec() sur la nouvelle URL, s'attendant à ce qu'elle soit valide, puisque l'URL d'entrée était garantie d'être valide et nous avons simplement supprimé le nom d'utilisateur et le mot de passe. Cela provoque une erreur (DCHECK).
Ainsi, l'URL est d'abord considérée comme valide, mais après avoir retiré certaines données privées, elle est invalidée. Cependant, une fois que ces données sont supprimées, la fonction qui a appelé ce code particulier s'attend à une URL valide.
Une des raisons pour lesquelles cette URL est considérée comme invalide est parce que NULL est utilisé dans un certain nombre de logiciels et langages plus anciens pour indiquer la fin d'une chaîne (parce que c'est essentiellement 8 zéros à la suite, ce qui est facile à détecter pour un ordinateur).
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
