Проклятие поддомена WWW: чеклист молодого админа

Должен ли адрес веб-сайта включать поддомен WWW и стоит ли вообще его создавать – тема многолетней спецолимпиады в этих наших Интернетах. Как «за», так и «против» приводится множество аргументов разной степени маразматичности разумности, которые я не стану воспроизводить в 100500-й раз. Отмечу лишь два момента. Первый: существуют разумные доводы в пользу обоих вариантов, поэтому следует решать, сообразуясь лишь со своими целями и обстоятельствами. Второй: не существует RFC, который явно требовал бы наличия или отсутствия поддомена WWW.

Краткая историческая справка

Поддомен WWW появился в позднем кайнозое на заре Всемирной паутины, чтобы явно обозначить: по данному URI пользователя ждет веб-контент, а не какой-нибудь FTP или, прости, Тим-Бернес, gopher. Такие URI страдали ожирением избыточностью, поскольку и схема – http:// – и поддомен – WWW – указывали на одно и то же обстоятельство: по данному адресу расположен ожидается гипертекстовой контент. Сегодня, сообщая кому-либо адрес своего хоста, мы по умолчанию подразумеваем расположенный на нем веб-сайт. Поэтому URI стали сокращать, отбрасывая от него то схему, то поддомен WWW, а то и оба два сразу и от указания полного URL (например, www.ifap.ru) пришли к указанию только имени хоста (т.е. просто ifap.ru – и так всем всё понятно).

Вот эта подразумеваемость и приводит подчас к глупым ошибкам в конфигурировании веб-серверов, на которые мы регулярно натыкаемся в рамках «Мониторинга госсайтов». Согласно нашей методике, любой ее критерий должен выполняться при обращении к сайту как с включением в URI поддомена WWW, так и без него, а некоторые критерии – и без указания схемы. Тут-то и начинается интересное…

Например, если мы зайдем на сайт правительства Ивановской области набрав в адресной строке браузера ivanovoobl.ru, то будем автоматически переадресованы на защищенное соединение – https://ivanovoobl.ru, а если добавим к адресу поддомен – www.ivanovoobl.ru – то окажемся на незащищенном http://www.ivanovoobl.ru

На нескольких сайтах в ходе нашего последнего исследования был обнаружен TLS-сертификат, недействительный для URI с поддоменом WWW, но после выпуска доклада по его результатам эти ошибки были исправлены перевыпуском сертификатов.

Формально схема URI и наличие поддомена WWW никак не связаны, но на практике связь есть, и заключается она в неверной настройке автоматической переадресации запроса клиента (GET) на правильный (с точки зрения администратора веб-сервера) URI, называемый еще каноническим (canonical).

Например, какой бы URL вы ни набрали, чтобы попасть на наш сайт – http(s)://(www.)ifap.ru – в итоге вы будете автоматически переадресованы на каноничѣный (в нашей системе координат) ifap.ru Увы, с магией переадресации справляются не все администраторы веб-серверов, в чем мы только что убедились.

Кто виноват? Что делать?

Первый вопрос, связанный с поддоменом WWW, на который должен ответить себе админ – создавать ли его вообще. Довод «за» – некоторые пользователи старой школы, набирающие адрес сайта руками, непременно добавляют к нему «www.» (или за них это делает браузер) и впадают в ступор, когда в ответ видят «host not found». Доводов «против» вроде как и нет, разве что лень лишнюю NS-запись создать.

Также поддомен WWW дает недокументированные возможности творческим личностям, упорно нежелающим соблюдать закон «Об обеспечении доступа к информации о деятельности государственных органов и органов местного самоуправления» в части требований к официальным сайтам государственных органов. Напомню, что согласно закону официальным сайтом госоргана может считаться лишь тот, электронный адрес которого включает доменное имя, права на которое принадлежат государственному органу или органу местного самоуправления.

Но правительство Астраханской области упорно не желает передавать госоргану права на домен своего сайта (astrobl.ru) и нашло весьма оригинальное объяснение: да, права на домен astrobl.ru принадлежат госпредприятию, но сайт правительства расположен не там, а по адресу www.astrobl.ru, и вот права на этот домен уже принадлежат областному правительству.

Если поддомен WWW решено создать, то предстоит ответить на следующий вопрос: что с ним делать? Войдет ли он в канонический адрес, станет ли «зеркалом» или «псевдонимом» (alias)? Соответственно, будет ли при обращении к нему происходить переадресация на домен уровнем выше или наоборот?

На заре кайнозоя Всемирной паутины у администратора веб-сервера было всего три варианта:
1.
http://www.ifap.ru → 200 OK
http:// ifap.ru → 200 OK

2.
http://www.ifap.ru → 200 OK
http:// ifap.ru → 301 Moved Permanently → http://www.ifap.ru

3.
http://www.ifap.ru → 301 Moved Permanently → http://ifap.ru
http:// ifap.ru → 200 OK

Новая эра принесла еще одну опцию – автоматическую смену схемы URI с http:// на https:// – количество вариантов удвоилось, и с таким вызовом справились уже не все, в чем мы регулярно убеждаемся. И это еще без учета совсем экзотических вариантов, когда с WWW и без него клиенту отдается разный контент, или когда по схеме https:// клиент попадает совсем не туда, куда по http://, как, например, на сайте правительства Дагестана (заходим по http:// и по https:// с разным результатом).

Что конкретно делать?

1. Веб-сайт должен быть доступен вне зависимости от того, указан ли в URI поддомен WWW или нет; в обоих случаях должен отдаваться один и тот же контент.

2. Допустимые варианты ответа веб-сервера при обращении к сайту с WWW и без него (HTTP status code) – 200 OK или 301 Moved Permanently. Ответ NS-сервера host not found – нежелательный ответ, т.к. поставит в тупик часть пользователей.

3. Ответ 200 OK на оба варианта обращения (с WWW и без) – допустимый вариант, но может быть нежелателен с точки зрения поисковой оптимизации.

4. Разумно совместить переадресацию с WWW на домен уровнем выше (или наоборот) с принудительным переключением схемы URI с http:// на https://

5. TLS-сертификат сайта должен покрывать адрес как с WWW, так и без (т.е. ifap.ru и www.ifap.ru или ifap.ru и *.ifap.ru).

Проверьте, что все перечисленные варианты обращения к хосту приводят к ожидаемому результату (заменив «ifap» именем своего хоста):

• http://ifap.ru
• http://www.ifap.ru
• https://ifap.ru
• https://www.ifap.ru

и не забудьте, что актуальные версии браузеров могут производить автоматическую смену схемы URI с http:// на https:// поэтому проверять лучше старым браузером.