Должен ли адрес веб-сайта включать поддомен WWW и стоит ли вообще его создавать – тема многолетней спецолимпиады в этих наших Интернетах. Как «за», так и «против» приводится множество аргументов разной степени
Краткая историческая справка
Поддомен WWW появился
Вот эта подразумеваемость и приводит подчас к глупым ошибкам в конфигурировании веб-серверов, на которые мы регулярно натыкаемся в рамках «Мониторинга госсайтов». Согласно нашей методике, любой ее критерий должен выполняться при обращении к сайту как с включением в 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 OK2.
http://www.ifap.ru → 200 OK
http:// ifap.ru → 301 Moved Permanently → http://www.ifap.ru3.
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.ruhttp://www.ifap.ruhttps://ifap.ruhttps://www.ifap.ru
и не забудьте, что актуальные версии браузеров могут производить автоматическую смену схемы URI с http:// на https:// поэтому проверять лучше старым браузером.
Комментарии (19)
Elsajalee
09.12.2021 14:42Что делать в плане мониторинга? Так вы же расписали - фиксировать ситуацию "руки из ж..." с детализацией а) неверные перенаправления б) неверные SSL в) особые извращения (это про astrobl) и т.д.
Ну а если www и без www контентно одинаковые и технически всё ОК (SSL) - значит для человека всё хорошо.
Elsajalee
09.12.2021 14:49некоторые пользователи старой школы, набирающие адрес сайта руками, непременно добавляют к нему «www.» (или за них это делает браузер) и впадают в ступор, когда в ответ видят «host not found».
Кстати, я попадался наоборот с сайтами местных госорганов. Набираешь без www, а А записи для домена нет. Но это было давно.
ifap Автор
09.12.2021 15:18Меня тоже терзали смутные сомнения, что сталкивался с подобным, но когда писал статью пробежался по нашим героям, и не нашел таких примеров. Даже сертификаты перевыпустили, злодеи, хотя в начале года было несколько сайтов с недействительными сертификатами для WWW.
khe404
09.12.2021 19:55На сколько можно судить браузер хром может проанализировать SEO сайта и выдать рекомендации в плане правильности маршрутизации и переадресаций к каноническому виду URL.
И особого смысла перебирать варианты вручную уже нет.
Плюс есть еще множество онлайн инструментов проверки. (ssllabs.com, amplify.nginx.com, mxtoolbox.com и куча других по запросу) которые дадут вменяемые рекомендации по настройке не только базовых переадресаций но и множества других параметров, о которых можно было бы только догадываться.
Плюс и Google и Яндекс в поисковых панелях дают рекомендации.
Вообще, сама по себе проблема неканонических URL скорее всего связана с тем, что в самых популярных серверных приложениях (apache и nginx) настройка условной переадресации происходит несколько неожиданным образом.
Вместо привычной для любого программиста конструкции if(запрос содержит www или http://) {переходи по ссылке https://} нужно создавать отдельные конфигурации виртуальных серверов с www и с http и в них создавать перенаправление.
Однако, все это не сильно актуально, так как все настройки все более и более автоматизируются различными панелями управления и в скором времени исчерпают себя так же как ушли в прошлое кодировки страниц и прочие неудобства.
Да и кто в наше время набирает запросы вручную?
ifap Автор
09.12.2021 19:58+2нужно создавать отдельные конфигурации виртуальных серверов с www и с http
RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} ^www\.
RewriteRule (.*) https://ifap.ru%{REQUEST_URI} [NE,R=301]
Это для Apache, 3 строчки в .htaccesskhe404
09.12.2021 20:23Все верно, я скорее думал о nginx а сослался на оба сразу.
server {listen 80;server_name XXX www.XXX;return 301 https://XXX$request_uri;}Но и с Апач тоже не все так просто. Обработка .htaccess будет не в первую очередь, а после обработки серверного блока и всевозможных <Directory ... > <Location >
Да и сам mod_rewrite очень не прост в настройке и эксплуатации, чего только стоят ключи в квадратных скобках.
ifap Автор
09.12.2021 22:12В Nginx просто не помню, но тоже не бином Ньютона. С Апачем просто, мануалы как настроить переадресацию в широком ассортименте, в т.ч. на русском. Нюансы скорее возникают, в каком порядке задавать условия: сперва проверка наличия www. в адресе или схемы? И вот тут начинается нечто странное: хотя инструкция единая, если первой в ней поставить проверку на наличие www., различные чекеры не видят принудительной переадресации на https, хотя она выполняется. Почему — для меня загадка, но стоит изменить порядок проверки и чекеры довольны.
khe404
10.12.2021 11:26Вы правы и по Nginx и по Apache существует масса примеров, документации на любом языке, генераторов конфига и даже исходные коды серверов доступны.
Будет работать и .htaccess, и даже index.php в котором можно проверять и перенаправлять запрос.
Я говорю только о том, что привычное для любого технаря ветвление процесса в конфигах работает не эффективно, порой неожиданно, а зачастую и вовсе не работает.
Даже самые простые действия с конфигами требуют изучения документации, практических экспериментов и непрерывного тестирования.
Естественно, ресурсы с низким бюджетом или сделанные давно и формально будут содержать ошибки и пренебрегут как тестированием, так и изучением мануалов.
Однако, с течением времени все это исправится благодаря тому, что технические вопросы настройки серверов будут изолированы от рядовых пользователей. Да и сейчас уже гораздо проще использовать хостинг, нежели изобретать велосипед и копаться в настройках.
Reformat
10.12.2021 05:13Разве эта "проблема" не решается одной CNAME записью в панели управления DNS?
CNAME www.site.com site.comНастраиваем перенаправление с www на основной домен и все счастливы.
SinnerLike
10.12.2021 08:12+3CNAME не делает перенаправление.
CNAME говорит клиенту "IP для www.site.com спроси у site.com".
А браузер в запрос отправит www.site.com
Сделайте dig www.ya.ru
Браузер отправит на IP ya.ru запрос с адресом www.ya.ru
ev1ua1
10.12.2021 12:44поддомен – WWW – указывали на одно и то же обстоятельство
В конце 90х, когда появились сайты с
пиратскоймузыкой/фильмами и т.д. которые занимали много места на HDD и все не влазили на один сервер, который мог быть обычный ПК, очень часто были домены WWW2., WWW3. которые шли на другой сервер. И частенько при добавлении новинок сразу делались "зеркала" на другие серваки.
Ziptar
11.12.2021 10:19На том единственном сайте, который меня угораздило "поддерживать", просто сделал прозрачный редирект со всевозможных вариантов на вариант с https и без www на уровне апача, без долгих раздумий и страданий
Даже и не думал, что на эту тему копья ломаются вообще
13werwolf13
простите что доколебался до мелочи не по сабжу, но проверять такие вещи лучше вообще не браузером, для этого есть более подходящие и предсказуемо работающие утилиты, например curl
ifap Автор
Вы правы, но не хочется сразу пугать админов, которые не умеют в rewite, заклинаниями высшего порядка, типа curl ;)
amarao
Есть вероятность, что новое поколение админов не знает, что такое rewrite, и вполне логично спрашивает, в каком месте описания ingress controller эту фигню надо писать и нафига.
И они правы.
ifap Автор
Не наговаривайте на госадминов, IG я видел у них раз или два, обычно Nginx или Apache своей
голой жопоймордой в Интернет светит, нередко любезно сообщая свою версию, что снимает вопросы, откуда у них на серверах берутся всякие интересные CVE-2016-* и более ранние ;) Так что про RewriteEngine и т.п. должны хотя бы слышать, а дальше — Гугл в помощь, было бы желание.kerneus
А можно по-подробнее, почему реверс-прокси nginx не должен светить в сеть?
ifap Автор
Я имел в виду, что исследуемые нами веб-сервера, как правило, не «прикрыты» ничем, тем более не используют балансеры. Впрочем, и нету надо — не те задачи, не те нагрузки. А когда их прикрывают, очумелые ручки дают себя знать с новой силой (ключевое слово: Ingress).