Как веб-сайты должны обрабатывать имя хоста с конечной точкой?

Я прочитал этот вопрос Как URL могут иметь точку. в конце, например, www.bla.de.? и понимаем, что полное доменное имя должно содержать конечную .метку для корневой метки дерева DNS:

example.com. вместо того example.com

Тем не менее, есть проблемы, как указано в этой статье блога :

Если вы не учитываете тот факт, что пользователь может случайно ввести доменное имя с точкой в ​​конце или перейти по ссылке, полученной от какого-то «доброжелателя», и получить ваше доменное имя с точкой в ​​конце, как В результате это может привести к неожиданным последствиям:

1) Если веб-сайт использует HTTPS, при переходе к имени домена с точкой в ​​конце браузер отобразит предупреждение о ненадежном соединении.

2) Аутентификация может быть нарушена, поскольку куки-файлы обычно устанавливаются для доменного имени без точки в конце. Пользователь в этом случае будет весьма удивлен, почему он не может войти в систему. Примечательно, что если вы установите cookie для доменного имени с точкой в ​​конце, этот cookie не будет передан доменному имени без точки в конце и наоборот.

3) JavaScript на странице может быть поврежден.

4) Могут быть проблемы с кэшированием страниц сайта (например, https://www.cloudflare.com/не очищает кеш страниц, если доменное имя имеет точку в конце, считая его недействительным доменным именем).

5) Если в условиях конфигурации веб-сервера вы полагаетесь на конкретное доменное имя ($ http_host в Nginx,% {HTTP_HOST} в Apache) без точки в конце, вы можете столкнуться с множеством неожиданных ситуаций: неожиданные перенаправления, основные проблемы авторизации и др.

6) Если веб-сервер не настроен на прием запросов на доменное имя с конечной точкой, любой пользователь, который случайно набрал доменное имя с конечной точкой, увидит что-то вроде Bad Request - Invalid Hostname.

7) Возможно, что поисковые системы обнаружат, что на вашем ресурсе есть дублированный контент, если кто-то случайно или намеренно разместит ссылки на ваши веб-страницы с точкой в ​​конце имени домена.

Я также понимаю, что http://webmasters.stackexchange.com./делает 400 Bad Request. Но так как собственно доменное имя должно содержать .в конце, не должны ли мы выдавать 400ошибку или 301перенаправлять имена хостов без конечной точки? Как правильно решать эту проблему последовательным и последовательным образом?

Чтобы частично ответить на ваш вопрос, вы можете добавить его в правила канадского перенаправителя htaccess. В базовом смысле HTTP ищет период до URI и использует его в любом используемом вами механизме защиты от дублирования. Вот пример, включающий общий маршрут sub util «домен аддона»:

RewriteCond %{HTTP_HOST} ^domain\.hostdomain\.com(|\.)$ [OR]
RewriteCond %{HTTP_HOST} ^www\.domain\.hostdomain\.com(|\.)$ [OR]
RewriteCond %{HTTP_HOST} ^domain\.com(|\.)$ [OR]
RewriteCond %{HTTP_HOST} ^www.domain\.com\.$
RewriteRule ^(.*)$ "http\:\/\/www\.domain\.com\/$1" [R=301,L]

То, что это сделало бы, пересылает все следующее к каноническому HTTP www домену:

• domain.hostdomain.com
• domain.hostdomain.com.
• www.domain.hostdomain.com
• www.domain.hostdomain.com.
• domain.com
• domain.com.
• www.domain.com.

Всех жду:

• http://www.domain.com

Однако есть предостережение: как указано в исходной цитате блога, SSL не будет корректно пересылаться и выдает предупреждение браузера или ошибку 400 неверных запросов в большинстве экземпляров сервера (особенно с HSTS). Это потому, что он видит «хост» SSL в случае использования после периода TLD. Я не уверен в обходном пути, чтобы справиться с предупреждением SSL хоста, так как оно предшествует htaccess и прочим.

Мне нравится думать о конечной точке как о «реальном» корне Интернета и о том, что он живет в Вирджинии, США. Если вы пропустите точку, то всегда подразумевается какой-либо корень. Для обычных пользователей это тот же корень, и об этом я сегодня расскажу.

По моему извращенному пути, я на самом деле нахожу конечную точку довольно удобной. Если я проверяю чужой веб-сайт и хочу начать все заново, без кэширования, без файлов cookie и т. Д., И мне лень их удалять, я либо использую другой браузер, либо добавлю точку. Если сайт не перенаправляет меня, у меня есть совершенно новые некэшированные URL-адреса для всех страниц сайта и других ресурсов.

Как веб-мастер, я хочу, чтобы все люди и роботы, просматривающие страницу, просматривали ее с одинаковым URL и, следовательно, с одинаковым именем хоста. Если имя хоста не будет тем, которое я хочу им использовать, я сделаю немедленное перенаправление 301, чтобы они увидели правильный URL в своем браузере. Для моих сайтов на основе PHP я решаю проблему в PHP, а не в файле .htaccess или web.config, поскольку он более переносим и его легче тестировать на серверах разработки и промежуточных серверах. Я одновременно обрабатываю соединения с базой данных, так как они также различаются для разных серверов разработки / подготовки / производства.

Вот упрощенная версия моего типичного кода. Обратите внимание на канонические перенаправления в конце.

    $Host = $_SERVER['HTTP_HOST'];
    switch ( $Host ) {
        case 'exampleweb.local':                    // my local dev machine
                $MysqliParams = array(
                        'host'      =>  'localhost',
                        'username'  =>  'root',
                        'passwd'    =>  'snoopy',
                        'dbname'    =>  'exampledb');
                break;
        case 'www.exampleweb.com':                  // the "live" site
                $MysqliParams = array(
                        'host'      =>  'superhost1.net',
                        'username'  =>  'examp302',
                        'passwd'    =>  'anything-but-snoopy',
                        'dbname'    =>  'examp302_db');
                $GoogleAccount = 'UA-13243546-01;   // only enable for live site
                break;
        case 'exampleweb.mystagingsite.net':        // the client preview site
                $MysqliParams = array(
                        'host'      =>  'superhost1.net',
                        'username'  =>  'examp302',
                        'passwd'    =>  'anything-but-snoopy',
                        'dbname'    =>  'examp302_staging');
                break;
        case 'exampleweb.com':                  // canonical redirects 
        case 'exampleweb.com.':
        case 'www.exampleweb.com.':
                header('HTTP/1.1 301 Moved Permanently');
                header("Location: http://www.exampleweb.com");
                exit;
        default:
                die("invalid hostname $Host");
    }   

мой комментарий на https://core.trac.wordpress.org/ticket/35248#comment:9 :

мой ответ на текст по первой ссылке ( https://web.archive.org/web/20160604095348/http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/web-fully-qualified-domain-name.html ):

Первоначально, как определено в RFC 1738 (п. 3.1), часть «хоста» URL-адреса (общей схемы Интернета) всегда и безоговорочно представляла собой полностью определенное доменное имя и общепринятый механизм отличия полностью определенных доменных имен от не полностью квалифицированные доменные имена не применяются. Будь то example.com. или example.com, хост должен был быть таким же.

- я думаю, что он не прав, я думаю, что "example.com" вообще не был разрешен в URL согласно rfc 1738, он цитируется во втором тексте, и я цитирую это:

3.1. Общий синтаксис интернет-схемы
        // <пользователь>: <пароль> @ <хост>: <порт> / <URL-путь>
    хозяин
        Полное доменное имя сетевого хоста

и "example.com" в то время не мог использоваться в заголовках http, потому что rfc 1738 имеет 1994 год, а поле host появилось только с http 1.1 в 1997 году (вы можете проверить это в википедии).

так что, действительно, в URL оставлен только fqdn. я думаю, что это была ошибка в RFC 1738, потому что таким образом он делал (пытался сделать) функцию «относительных доменов» бесполезной. если это не запрещает его, теоретически они могут быть использованы в тегах «a» на локальных сайтах со сценариями или в статической html-документации внутри крупных компаний, использующих относительные домены, если это поддерживают браузеры и серверы. но даже если rfc 1738 запретил их, люди не подчинялись ему: они продолжали использовать домены верхнего уровня в относительной форме, то есть без конечной точки, так что это запрещение rfc 1738 не было большой практической проблемой в любом случае, и люди имели и использовали альтернативу для относительных доменов: они просто создали локальные домены верхнего уровня, такие как «localhost» (и использовали и используют их также без конечной точки).

тогда он говорит:

К сожалению, на практике веб-браузеры всегда нарушали эту спецификацию и передавали часть «хоста» через процедуры уточнения имени своих библиотек DNS-клиентов при сопоставлении имени хоста с набором IP-адресов. (Например, те, которые использовали библиотеку DNS-клиента BIND, оставили бы параметр RES_DNSRCH установленным и не добавили бы конечную конечную точку, если она отсутствовала.)

- Я думаю, он имел в виду, что хосты без конечной точки должны быть просто сброшены как ошибка, и только абсолютные домены (fqdn) должны быть переданы в DNS. я думаю, что, вероятно, браузеры передали все домены DNS, потому что люди использовали свои собственные локальные домены верхнего уровня, такие как "localhost" и в любом случае, позже в rfc 2396, опубликованном в 1998 году, было разрешено использование доменов верхнего уровня в URL без конечных точек.

затем автор (Джонатан де Бойн Поллард) цитирует rfc 2396 и сожалеет о том, что оно изменилось в соответствии с установленным человеческим поведением, то есть стандартами де-факто, говорит, что было бы лучше, если бы браузеры подчинялись rfc 1738, и рекомендует всем людям использовать только fqdn, в все места, как это было приказано RFC 1738.

- но что произойдет, если люди подчинятся RFC 1738? URL какhttp://example.com/test.html "и"http: //localhost/test.html "все должно было быть переписано как"http://example.com./test.html "и"http://localhost./test.html". браузер должен будет либо пометить узлы без точек как ошибку, либо перенаправить при щелчке их на полную / абсолютную форму. Все люди, которые настроили локальные домены верхнего уровня, такие как" localhost ", должны будут настроить свои серверы для приема только запросов для доменов, таких как "localhost.", или принять и перенаправить [все URL-адреса внутри] "localhost" на [соответствующие URL-адреса в] "localhost.". Текст, такой как "localhost", останется полезным только при наборе его в адресной строке браузера, но это было бы только очень бесполезным использованием, и функция относительного домена не нужна для этого, потому что браузеры ищут домены при наборе текста. Использование их в источнике html станет бесполезным, потому что это приведет к тому, что такие ссылки не будут работать, или нажав все ссылки с "localhost" будут перемещать пользователя на "localhost.«и это будет просто дополнительная переадресация при каждом клике (по таким ссылкам). Таким образом, rfc 1738 сделает запланированную функцию« относительный домен »совершенно бесполезной. если бы некоторые компании использовали эту функцию и использовали свои относительные домены на своих локальных сайтах, и их URL с относительными доменами не были перенаправлены браузерами в абсолютную форму, поэтому их сайты работали нормально, если бы они также подчинялись rfc 1736, они настроили бы свои серверы на прием только fqdn, и им пришлось бы либо переписать все свои такие URL с fqdn, или работайте с дополнительным перенаправлением при каждом клике по таким URL-адресам. Если этим компаниям нравится иметь короткий домен, такой как «team101» вместо «team101.microsoft.com.» в своих адресных строках и источниках html, им придется начать использовать их собственные внутренние домены верхнего уровня, такие как «team101», т.е.localhost. "вместо поддоменов типа" team101.microsoft.com. "(который можно использовать как просто" team101 ", прежде чем они решат подчиниться rfc 1738).

-

и я обнаружил, что конечная точка, которая была так сильно поддержана rfc 1738, действительно появилась только после стандарта без конечных точек! он появился с rfc 1034 в 1987 году, он упоминается во второй ссылке, и я цитирую это:

Поскольку полное доменное имя заканчивается корневой меткой, это приводит к
печатная форма, которая заканчивается точкой. Мы используем это свойство, чтобы различать:
- строка символов, которая представляет полное доменное имя
 (часто называют «абсолютным»). Например, «Понерия.ISI.EDU.»
- строка символов, представляющая начальные метки
 доменное имя, которое является неполным, и должно быть заполнено
 локальное программное обеспечение, использующее знание локального домена (часто
 называется "родственник"). Например, «Понерия» используется в
 Домен ISI.EDU.

rfc 1034 (от 1987) только что объявил все используемые домены, кажется, что все они были без конечных точек, объявил их как относительные домены! но они все еще работали, как и раньше, поэтому, вероятно, мало кто знал об этом и продолжал думать, что они однозначно запрашивают уникальный реальный сайт "example.com", когда они используют "example.com" без конечной точки. таким образом, это стало дополнительным нарушением безопасности в некоторых случаях: известный реальный example.com мог быть подделан администратором субдомена, даже если ему не были предоставлены права на создание какого-либо локального домена, такого как «localhost». Итак, rfc 1034 также не был спроектирован очень хорошо: кажется, его авторы не ожидали, что, возможно, он будет {не широко известен, поэтому создает брешь в безопасности}!

вероятно, rfc 1738 (1994) попытался, наконец, донести идею о разграничении абсолютных и относительных доменов до широкой аудитории, а также исправить это нарушение безопасности через 6 лет, {но, исправив нарушение безопасности, запретив относительные домены в URL, он сделал относительные домены бесполезными , {но я думаю, что они, вероятно, не использовались широко, вероятно, только в некоторых крупных компаниях}}. Итак, что было бы [оставлено] в результате выполнения 1737 рфк, если бы ему подчинялись? - 1) относительные домены, объявленные в 1987 году, в конечном итоге станут бесполезными, поэтому конечная точка, предназначенная для отображения абсолютного домена, также станет в конечном итоге бесполезной и избыточной «юридически», то есть как определено в rfcs! (но, возможно, они планировали позже повторно разрешить относительные домены в URL-адресах через много лет, когда широкая аудитория (широкая публика) начнет узнавать о возможности относительных доменов). 2) и РФС 1737 г. если бы это было выполнено, также исправило бы нарушение безопасности. - но даже rfc 1034 не создаст брешь в безопасности, если он достигнет массы, и было широко известно, что использование относительного домена небезопасно! Итак, основной рецепт, чтобы исправить это, достиг широкой аудитории, и публикация еще одного rfc была лишь одним из многих способов сделать это.

Теперь я думаю, что, вероятно, функция относительного домена не стала широко известной после rfc 1034 (1987 г.), потому что она была слишком ограничена: только в некоторых крупных компаниях или локальных сетях провайдеров, и это была функция, не имеющая практической ценности, поскольку локальные сети уже могут создавать любой локальный домен, так что эта функция была только для себя, на самом деле это был просто бесполезный текст в rfc, который любой должен знать и использовать без каких-либо дополнительных преимуществ! но люди создали небольшое нарушение безопасности, широко игнорируя rfc, в то время как браузеры начали подчиняться ему.

Я проверил функцию относительных доменов вчера, она работает. (это нормально, потому что rfc 2396 (от 1998 года) повторно разрешил его после того, как rfc 1034 (от 1987 года) отказал, и позже RFC 3986 (от 2005 года) все еще разрешает их). я добавил суффикс dns в windows 10 - панель управления - ... - свойства сетевого устройства - свойства ipv4 - дополнительные - вкладка dns. когда я добавил "google.com", то открыл "http: // mail / "в firefox, он открыл сервер Google, но он не был настроен для работы только с" mail "в заголовке http" host ", поэтому я получил что-то вроде страницы" 404 ".

-

мой ответ на текст по второй ссылке ( http://www.dns-sd.org/trailingdotsindomainnames.html ):

он также цитирует правило в RFC 1738 и говорит:

К сожалению, люди, реализующие клиенты веб-браузера, похоже, не поняли, что это значит. Когда вы обращаетесь к веб-сайту, значение, которое большинство веб-браузеров вводят в поле «Host:», - это то, что набрал пользователь, а не то, что компьютер фактически использовал после применения списка поиска пользователя DNS для создания полностью определенного имени из частичное имя Например, вот три различных способа, которыми пользователь может обращаться к хосту «www.example.com». ... При отправке параметра "Host:" на веб-сервер клиент веб-браузера вместо этого вводит то, что набрал пользователь ("www.example.com.", "Www.example.com" или "www"). о том, что клиент в действительности искал в DNS («www.example.com.» во всех трех случаях). ...

- это не очень верно (правильно), потому что rfc 1738 был очень строгим в этом отношении, и он запрещал относительные домены во всех URL, даже если он находится в адресной строке браузера, и сам URL является [рекомендуемым] способом создания любые ссылки на сайты, даже если люди пишут это на бумаге, поэтому пользователям не разрешалось ссылаться на этот сайт этими тремя способами к rfc 1738, если эти пользователи будут думать, что они используют URL!

и, кажется, автор этого текста (Стюарт Чешир) не знал о rfc 2396, поэтому этот текст устарел.

-

и какова ситуация в настоящее время? рфк 3986 (https://tools.ietf.org/html/rfc3986#page-21 ) позволяет ссылаться на абсолютный домен без конечной точки: он говорит: «За самой правой доменной меткой полного доменного имени в DNS может следовать один». «» и что его следует использовать, если «необходимо различать полное доменное имя и какой-либо локальный домен». Я думаю, что из-за стандартов де-факто это почти никогда не требуется, поэтому WordPress может принять стандарт де-факто и перенаправить с адреса с конечной точкой на адрес без него.