При щелчке по этой ссылке (http://a//%%30%30) в Google Chrome Chrome разрывает и закрывает все вкладки и экземпляры.
Но в некоторых случаях мне нужно только навести указатель мыши на ссылку, и вкладка вылетает.
Что произойдет, когда я наведусь на эту ссылку? Я имею в виду, что делает Chrome при наведении ссылки?
Сбой происходит из-за недавно обнаруженной ошибки в Chrome и других браузерах WebKit(!)* - определенно относится либо к %%30%30 , %0%30 либо к %%300 как части URL-адреса, которые внутренне все заканчиваются тем, что представляют один и тот же символ: null. Вы можете прочитать больше об ошибке здесь.
Это не ошибка, которая затрагивает большинство ссылок, поэтому вам не нужно беспокоиться о наведении курсора на ссылки.
Заметки:
* Другие браузеры WebKit включают Safari, Opera, Steam Browser, Midori, S60 (Symbian), Blackberry Browser и браузер Playstation 3, но не Firefox, Internet Explorer или Edge.
Редактировать: эта ошибка была исправлена в Chrome 45.0.2454.101, как указывает Дельтик .
Проблема связана с каноническим URL-адресом, который запускается, как только вы наводите указатель мыши на ссылку - возможно, для отображения ссылки в строке состояния браузера и для предварительной выборки веб-страницы, чтобы она быстрее загружалась при нажатии.
Что касается роли канонизатора URL:
Когда URL-адрес написан на HTML , он может быть записан в такой форме, как /home или ../../home , но браузеры должны преобразовать этот URL-адрес во что-то с протоколом и доменом, например, http://superuser.com/home . Кроме того, URL может содержать URL Escape, которые необходимо перевести , и эти экранированные символы кодируются в процентах , например %%30%30 . (Более исчерпывающий список URL избегает здесь).
Функциональность, обрабатывающая этот перевод URL, является тем, что в конечном итоге приводит к сбою, потому что он получает ввод, который разработчики не ожидали / не обрабатывали.
Вот краткое описание изменения кода, которое решило проблему:
Правильно обрабатывать проблемные вложенные переходы в URL-путях.
В частности, если удаление из входных данных приводит к выходному URL-адресу, содержащему новую экранированную последовательность, например, преобразование входных данных «%% 30% 30» в «% 00», экранируйте ведущий «%» как «% 25», чтобы обеспечить вывод последовательность не рассматривается как новая допустимая escape-последовательность.
Это гарантирует, что канонизация одного и того же URL-адреса во второй раз не изменит его, что важно для предотвращения сбоев и других ошибок в различных местах как в отладочной, так и в выпускной сборках.
Как говорит Фабио Турати,
Когда вы наводите курсор на ссылку, Chrome отображает ее в левом нижнем углу. Это требует некоторой обработки, включая "перевод" специально закодированных символов.
Однако из вашего поста и комментария я думаю, что вас больше беспокоит вопрос о том, подключается ли Chrome к ссылке в фоновом режиме. Это так, как и другие современные браузеры (Firefox, Opera). Вы можете отключить предварительную выборку в настройках Chrome или установить uBlock Origin, чтобы получить больше настроек конфиденциальности.
Я хотел дать некоторые дополнительные разъяснения о том, что именно здесь происходит.
По сути,% 30 - это URL-кодированный 0, а% 00 - это URL-кодированный NULL (который отображается в двоичном виде как 0000 0000). Таким образом, если у вас есть URL-адрес с вложенным закодированным символом, который будет декодироваться в NULL, возникает ошибка.
При канонизации URL-адреса Chrome выполняет следующие действия (источник: https://code.google.com/p/chromium/issues/detail?id=533361#c13):
- Входная строка "http: //a.com/%%30%30" не экранирована к " http://a.com/%00 " и считается допустимым GURL.
- Этот GURL в конечном итоге отправляется в GURLToDatabaseURL(), которая вызывает для него функцию ReplaceComponents() для удаления имени пользователя и пароля.
- ReplaceComponents() повторно канонизирует URL.
- Канонизация пути попадает в последовательность «% 00», отменяет, видит, что это 0 символ, который недопустим в URL, оставляет его экранированным, но помечает полученный URL как недействительный.
- Когда мы возвращаемся обратно к GURLToDatabaseURL(), он вызывает .spec() для нового URL, ожидая, что он будет действительным, поскольку входной URL гарантированно был действительным, и мы просто удалили имя пользователя и пароль. Это чеки.
Таким образом, URL сначала считается действительным, но после удаления определенных личных данных он становится недействительным. Однако после удаления этих данных функция, вызвавшая этот конкретный код, ожидает действительный URL-адрес.
Одна из причин, по которой этот URL-адрес считается недействительным, заключается в том, что NULL используется в ряде старых программ и языков для обозначения конца строки (потому что это в основном 8 нулей в строке, что легко обнаружить для компьютера).
