Як веб-сайти повинні обробляти ім'я хоста з крапкою?

Я читав це питання Як URL-адреси можуть мати крапку. наприкінці, наприклад, www.bla.de.? і зрозумійте, що FQDN повинен містити контур .для кореневої мітки дерева 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 - Недійсне ім'я хоста.

7) Можливо, що пошукові системи можуть виявити, що ваш ресурс має дублікат вмісту, якщо хтось випадково чи навмисно розмістив посилання на ваші веб-сторінки з крапкою в кінці доменного імені.

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

Щоб частково відповісти на ваше запитання, ви можете додати його до канонічних правил експедирування htaccess. У базовому сенсі HTTP він шукає період перед URI і працює над тим, який механізм переадресації переадресації ви використовуєте. Наведемо приклад, що включає загальний маршрут "домен додатка" для додаткового маршруту:

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. Загальний синтаксис схеми Інтернету
        // <користувач>: <пароль> @ <хост>: <port> / <url-path>
    господар
        Повноцінне доменне ім’я мережевого хоста

і "example.com" в той час не можна було використовувати в заголовках http, оскільки rfc 1738 - це 1994 року, а поле хосту з'явилося лише з http 1.1 у 1997 році (ви можете перевірити у wikipedia).

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

тоді він каже:

На жаль, на практиці веб-браузери завжди порушували цю специфікацію та передавали частину "хост" через процедури кваліфікації імен своїх бібліотек клієнтів DNS під час зіставлення імені хоста на набір IP-адрес. (Наприклад, ті, хто використовував бібліотеку BIND DNS-клієнтів, залишить набір параметрів 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."
- символьний рядок, який представляє початкові мітки a
 доменне ім'я, яке є неповним і має бути заповнене
 локальне програмне забезпечення, що використовує знання локального домену (часто
 називається "відносним"). Наприклад, "Понорія", що використовується в
 Домен ISI.EDU

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

ймовірно, rfc 1738 (1994) намагався нарешті довести ідею про розмежування абсолютних та відносних доменів широкій аудиторії, а також виправити це порушення безпеки через 6 років, {але виправивши порушення безпеки, заборонивши відносні домени в URL-адресах, це зробило відносні домени марними. , {але я думаю, що вони, ймовірно, не використовувались широко, напевно, лише в деяких великих компаніях}}. Отже, що буде [ліворуч] у результаті rfc 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 - додаткові - вкладка dns. коли я додав "google.com", то відкрив "http: // mail / "у firefox, він відкрив сервер google, але він не був налаштований на роботу з просто" поштою "у заголовку" хоста "http, тому я отримав щось на зразок сторінки" 404 ".

-

моя відповідь на текст за другим посиланням ( http://www.dns-sd.org/trailingdotsindomainnames.html ):

він також цитує це правило в rfc 1738 і говорить:

На жаль, люди, які реалізують клієнтів веб-браузера, не розуміють, що це означає. Коли ви звертаєтесь до веб-сайту, значення більшості веб-браузерів, що вводяться у поле "Хост:", - це те, що ввів користувач, а не те, що використовував комп'ютер, після застосування списку пошуку 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 може прийняти фактичний стандарт і переадресувати з адреси з останньою крапкою на адресу без нього.