Какое поведение является правильным для http://anonymous.invalid?
Блок содержит фактические данные файла, поэтому обычно мы хотим, чтобы блок был как можно больше, но при этом имел приличную производительность. Оказывается, довольно хороший размер блока — это размер страницы. Процитировать вики ext4:
Block size is specified at mkfs time and typically is 4KiB. You may experience mounting problems if block size is greater than page size (i.e. 64KiB blocks on a i386 which only has 4KiB memory pages).
«Время mkfs» означает время создания файловой системы. Таким образом, размер блока фиксируется после того, как мы создали файловую систему, и, скорее всего, будет равен 4 КБ.
Иноды должны содержать только указатели на блоки данных (, а также некоторую метаинформацию о файле -, когда к нему последний раз обращались, какому пользователю он принадлежит и т. д. ). В другом разделе вики говорится, что
By default, ext4 inode records are 256 bytes, and (as of October 2013) the inode structure is 156 bytes [...]. The extra space between the end of the inode structure and the end of the inode record can be used to store extended attributes. Each inode record can be as large as the filesystem block size, though this is not terribly efficient.
Таким образом, мы могли бы действительно сделать иноды такими же большими, как и блоки, но в реальной системе это, вероятно, не так. Если вам интересно, структура inode говорит только об указателях на блоки данных. Таким образом, у нас есть 156 байтов указателей на фактическое содержимое файла, но весь inode занимает 256 байт -, по сути, у нас есть 100 байтов, которые мы можем использовать на досуге для любых метаданных, которые захотим.
Короче говоря, ext4 очень настраиваемый. Но очень высока вероятность того, что размер вашего блока составляет 4 КБ, а ваши записи inode — 256 байт.
Возможно, это ошибка в Chrome. В качестве ссылки это не приводит к поиску Google. Это поведение можно увидеть только при вставке в саму строку URL.
Я зарегистрировал это как ошибку
https://bugs.chromium.org/p/chromium/issues/detail?id=1008918
Это также может быть DNS-сервер. :DNS-сервер, предоставляемый многими интернет-провайдерами, будет перенаправлять -, если ему будет присвоено имя, которое он не может найти. Часто к какой-нибудь рекламе или бого -помощи.
Существует множество стандартов, определяющих, как интерпретировать URL. Но не существует стандартов, определяющих, как интерпретировать строку, введенную в комбинированной строке поиска URL -и -веб-браузера.
Существует негласное ожидание, что при вводе действительного URL-адреса в строке браузер посещает этот URL-адрес. Однако точное определение «действительного» зависит от интерпретации. В основных браузерах есть эвристика, позволяющая определить, выглядит ли строка как URL-адрес или что-то еще (, например, поиск или букмарклет ).
RFC 2606 определяет, что домен верхнего -уровня invalidникогда не будет назначаться в Интернете. Он не кодифицирует, что люди могут делать в частной сети (интрасети ). Обоснование в документе говорит против его использования в частной сети, но RFC регулируют только Интернет, а не частные сети.
Для Chromium разумно рассматривать invalidкак обычный домен верхнего уровня -и позволить системе DNS обрабатывать RFC 2606, никогда не возвращая никаких записей в .invalid. Для Chromium также разумно решить, что .invalidникогда не является действительным TLD, и рассматривать все, что выглядит как URL-адрес с этим TLD, как не URL-адрес.
Существует несколько ограничений, которым должны следовать веб-браузеры в отношении построения URL. Например, HSTS указывает, что доступ к определенным именам сайтов не должен осуществляться через HTTP, а только через HTTPS, поэтому для веб-браузера было бы неправильно рассматривать facebook.comкак ярлык для http://facebook.com, а не https://facebook.com¹. Но на .invalidтакое ограничение не распространяется, просто разрешено обращаться с ним иначе, чем с обычным ДВУ.
¹ Подробная информация о том, как работает HSTS, выходит за рамки этого ответа.
Правильным поведением в омнибоксе Chromium является поиск, потому что все, что вводится в строку адреса, не использует TLD из этого списка отправлено в качестве поискового запроса.
Список включен в исходный код хрома (, по крайней мере, в версии 73 для старого стабильного Debian, как я получил с помощьюapt-get source chromium)в net/base/registry_controlled_domains/effective_tld_names.dat. Вы можете попробовать перестроить Chromium, добавив в этот файл дополнительные TLD, которые вам нужны.
На самом деле это даже не вопрос DNS. Google Chrome будет искать термины, которые, по его мнению, не являются именами хостов, DNS-именами или IP-адресами. Это довольно конкретно об этом. Например,http://127.0.0.1не будет искать, аhttp://256.0.0.1будет, потому что это вне диапазона для IP. В то время как.invalid TLD определенно является доменным именем, даже если оно недействительно для его регистрации. Разрешение на 404 не имеет смысла, потому что это ошибка HTTP и нет способа разрешить DNS-имя. Правильное сообщение об ошибке будет Name not resolvable, record does not exist. Или Name not resolvable, invalid records will not be forwarded. Я согласен с ОП, что это неправильное поведение. Также обратите внимание, чтоhttp://site.exampleиhttp://site.testНЕ выполняют поиск.
Недопустимое имя зарезервировано Инженерной группой Интернета (IETF )в RFC 2606 (июнь 1999 г. )как доменное имя, которое не может быть установлено в качестве домена верхнего -уровня в Система доменных имен (DNS )Интернета. 1
Если вы хотите использовать, например, http://anonymous.evan, просто добавьте / в конце. Затем Google Chrome пытается решить эту проблему.
РЕДАКТИРОВАТЬ:https://bugs.chromium.org/p/chromium/issues/detail?id=30636Информация взята отсюда:https://stackoverflow.com/questions/36783705/force-chrome-to-follow-url-and-not-search/36783847#36783847