it-roy-ru.com

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

Я прочитал этот вопрос Как 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 перенаправление для имен хостов без конечной точки? Как правильно решать эту проблему последовательным и последовательным образом?

15
user47113

Чтобы частично ответить на ваш вопрос, вы можете добавить его в правила канадского перенаправителя 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.

Всех жду:

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

3
dhaupin

мой комментарий на 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. Общий синтаксис схемы Интернета 
 //<user>:<password>@<Host>:<port>/<url-path>
 Host 
 Полное доменное имя Хост сети 

и "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 году, он упоминается во второй ссылке, и я цитирую это:

Поскольку полное доменное имя заканчивается корневой меткой, это приводит к печатной форме 
, Которая заканчивается точкой. Мы используем это свойство для различения: 
 - символьная строка, представляющая полное доменное имя 
 (Часто называемое "абсолютным"). Например, "poneria.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) и RFC 1737, если оно будет выполнено, также исправит нарушение безопасности. - но даже rfc 1034 не создал бы нарушения безопасности, если бы он достиг массы, и было широко распространено мнение, что использование относительного домена небезопасно! Итак, основной рецепт, чтобы исправить это, достиг широкой аудитории, и публикация еще одного rfc была лишь одним из многих способов сделать это.

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

я вчера проверил функцию относительных доменов, она работает. (это нормально, потому что rfc 2396 (от 1998 года) повторно разрешил его после того, как rfc 1034 (от 1987 года) отказал, а позже RFC 3986 (от 2005 года) все еще разрешает их). я добавил DNS суффикс в Windows 10 - панель управления - ... - свойства сетевого устройства - свойства ipv4 - дополнительные - вкладка днс. Когда я добавил "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, поэтому этот текст устарел.

-

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

1
qdinar

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

По моему извращенному пути, я на самом деле нахожу конечную точку довольно удобной. Если я проверяю чужой веб-сайт и хочу начать все заново, без кэширования, без файлов 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");
    }   
1
Tom Robinson