Пользователь
0,0
рейтинг
16 марта 2013 в 13:15

Разработка → Чем может грозить точка в конце доменного имени

Существует такое понятие, как корневой домен, соответственно, в конце каждого домена есть точка. Возможно, вы и не подозреваете, что ваш сайт доступен по доменному имени с точкой в конце (domain.zone.), так как браузеры позволяют обращаться к сайтам, как с точкой в конце домена, так и без неё.

Здесь можно почитать поподробнее про полные и относительные доменные имена.

Возможные проблемы


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

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

2) Может не работать авторизация, т.к. кука чаще всего ставится на доменное имя без указания точки в конце. Пользователь в этом случае будет долго недоумевать, почему ему не удаётся авторизоваться. Примечательно, что, если вы установите куку на доменное имя с точкой в конце, она НЕ будет передана доменному имени без точки в конце и наоборот.

3) Может ломаться JavaScript на странице, если не учтена вероятность доступа к сайту по доменному имени с точкой в конце, что для солидных ресурсов недопустимо.

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

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

6) Если веб-сервер не настроен на обслуживание доменного имени с точкой в конце, пользователь, случайно набрав точку в конце домена, увидит что-то вроде: Bad Request — Invalid Hostname.

7) Теоретически поисковые системы могут посчитать, что на вашем ресурсе имеет место дублирование контента, если кто-то случайно или умышленно разместит ссылки на страницы вашего сайта с точкой в конце доменного имени (если вы располагаете информацией о том, воспринимают ли поисковые системы domain.zone и domain.zone. как один домен – добро пожаловать в комментарии к топику).

Решение


Избежать части вышеописанных проблем позволит редирект с доменного имени с точкой на доменное имя без точки:

Apache (.htaccess)
RewriteCond %{HTTP_HOST} !^domain\.zone$
RewriteRule ^(.*)$ http://domain.zone/$1 [L,R=301]

Nginx (nginx.conf)
if ($http_host != 'domain.zone') {
    return 301 http://domain.zone$request_uri;
} 

IIS (web.config)
<httpRuntime relaxedUrlToFileSystemMapping="true"/>
<rule name="point" stopProcessing="true"> <match url="^(.*)\.$" />
    <action type="Redirect" url="{R:1}" redirectType="Temporary" /> 
</rule>

Разведка боем


Facebook
https://www.facebook.com.
Перенаправляет на www.facebook.com (после соглашения с предупреждением о недоверенном соединении).

Megaupload
https://mega.co.nz./#login
Авторизация успешно отрабатывает, но после перехода на домен без точки в конце https://mega.co.nz, пользователь считается неавторизованным.

Stack Overflow
http://stackoverflow.com.
Bad Request — Invalid Hostname
HTTP Error 400. The request hostname is invalid.

GitHub
https://github.com./login
Авторизация не работает.

Twitter
https://twitter.com.
404 — Страница не найдена.

Yahoo
https://login.yahoo.com.
Авторизация не работает.

Wikipedia
http://en.wikipedia.org./w/index.php?title=Special:UserLogin
Авторизация не работает.

MSN
http://msn.com.
Bad Request — Invalid Hostname
HTTP Error 400. The request hostname is invalid.

Microsoft
http://microsoft.com.
Bad Request — Invalid Hostname
HTTP Error 400. The request hostname is invalid.

eBay
https://signin.ebay.com./ws/eBayISAPI.dll?SellItem
Авторизация успешно отрабатывает.

Tumblr
http://www.tumblr.com.
Не найдено.

Flickr
http://www.flickr.com.
Извините, Flickr не разрешает встраивание в iframe.

Dropbox
www.dropbox.com./login
Ошибка (403) Кажется, вы пытались сделать что-то странное. Вы авторизовались в другом аккаунте Dropbox в соседнем окне?

VK
http://vk.com.
Авторизация не работает.
Ошибка JavaScript: «NS_ERROR_DOM_BAD_DOCUMENT_DOMAIN: Illegal document.domain value» vk.com. (строка 41)

Alexa
https://www.alexa.com.
Перенаправляет на www.alexa.com

Яндекс-Почта
https://mail.yandex.ru.
Авторизация успешно отрабатывает и происходит редирект на mail.yandex.ru/neo2/#inbox

Яндекс-Поиск
www.yandex.ru.
Ошибка JavaScript: «NS_ERROR_DOM_BAD_DOCUMENT_DOMAIN: Illegal document.domain value» www.yandex.ru. (строка 5)

Хабрахабр
http://habrahabr.ru./login/
Авторизация не работает.

Mail.ru
http://mail.ru.
Настроен редирект на mail.ru
https://e.mail.ru./cgi-bin/login
Авторизация не работает.

UPD:
1) В Nginx у вас не получится настроить виртуальный сервер, указав в качестве server_name полностью определённое доменное имя (#comment_6011533):
server {
     server_name domain.zone. ;
    ...
}
А что вы делаете с точкой в конце доменов ваших ресурсов?

Проголосовало 3335 человек. Воздержался 791 человек.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

@transpond
карма
28,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (83)

  • +2
    Интересный факт: точка в конце пути (http://example.com/path.) может привести к тому, что System.Uri его неправильно распарсит. Баг тянется чуть ли не с первого фреймворка и фиксить его никто не собирается (есть workaround, который неприменим к изолированным окружениям типа Silverlight).
    • +4
      А чем плоха точка в конце uri? Точка после слеша к dns уже никакого отношения не имеет.
      • +10
        Она ничем не плоха, плох баг в парсере мелкомягких, который пытается воспринять путь из Url как путь в файловой системе и считает, что точка в конце имени файла может быть проигнорирована.
        Кстати, в Mono-вской реализации mscorlib этот баг отсутствует.
  • +29
    who care? Если на сайт зайдут по IP, то в куче случаев он тоже не будет работать, и? Повод всем бежать и прописывать default?
    • +4
      «Случайно» зайти по IP на сайт довольно сложно.
      • +2
        Чем это отличается от «захода» на сайт вида .www.yandex.ru? Кривой url — кривое отображение. Тем паче, что большинство url'ов всё-таки содержат путь, так что точка попаёт в путь, а не в доменное имя.
        • +4
          Скорее, «www.yandex.ru.». У меня во фреймворке такие заходы логируются (чисто из интереса), и, я скажу, народ постоянно приходит на домены с точкой. По-видимому, у кого-то просто срабатывает моторный рефлекс, и люди ставят в конце точку как точку в конце предложения.
          • +3
            Это особенности некоторых парсеров сайтов, которые выделяют урлы автоматом: если после урла стоит точка, завершающая предложение, они её запихивают в урл. Например так было раньше на сайте www.habrahabr.ru. Сейчас уже исправленно, как видите.
        • –1
          У меня ваш пример не открывается.
    • +45
      Это для самых любящих веб-мастеров, у них интерфейс сайта работоспособен даже если отключить javascript, браузер, компьютер, пырнуть монитор ножом.
      • +6
        Я встречал заказчика (такой дядечка 50+ лет) который требовал что бы его напичканный яваскриптом и аяксом интернет магазин на битриксе был работоспособен даже в текстовых браузерах типа lynx! Местные разрабочики пытались долго его отговаривать и в итоге все таки сделали супер-облегченную версию специально под lynx и подобные браузеры на основе какого-то wap-шаблона. Шутили что дальше он захочет что бы покупать товары можно было через telnet.
  • –19
    twitter.com./ не понравился Касперскому. Сказал, что не может проверить подлинность сертификата.
    • +3
      Как-то я не понял что произошло и откуда такая бурная реакция?
      В статье сказано, что twitter.com./ выдает 404, а я лишь добавил, что кроме этого KIS не нравится сертификат twitter, открытого по такому варианту URL.
      Я вас не понимаю, люди. Еще и прямо в карму наплевали…
      • +3
        Подозреваю, что люди удивлены причем тут KIS и проверка подлинности сертификата.
  • +3
    А нет какой-нибудь статиски, наприемер с DNS крупного ресурса, насколько часто такие запросы приходят?
    • +6
      На уровне DNS точка есть всегда. Нужно смотреть на уровне веб-сервера.
      • 0
        хорошо, это я понял, но как то хочется узнать насколько часто люди переходят по адресам с точкой в конце домена (ну не считая хабравчан которые прочитав эту статью принялись эксперементировать).
        • 0
          Надо собирать статистику на уровне веб-сервера.
        • +1
          Та крайне редко переходят, на уровне опечаток. Тем более что большинство народу думает, что точка после домена это ошибка, и там максимум слэш может стоять (ну или двоеточие с номером порта).
  • +1
    На Хабре с домена с точкой нельзя проголосовать.
  • +3
    Судя по всему, Яндекс нормально отрабатывает.

    image

    image

    (При попытке добавить домен с точкой говорит о том, что он уже проиндексировался, но в индексе только нормальный домен.)
  • +1
    Не знаю как, но у меня пару лет назад при случайном открытии домена с точкой, появился листинг директорий и файлов. Так и не понял, как это вышло, то ли баг, то ли еще что-то…
    • +7
      default был так настроен. Зашли бы по IP, показало бы то же самое.
    • 0
      Скорее всего недосмотр админа, что кому попало листинг выдаётся, а так ничего удивительного, в файловой системе издавна точка обозначала текущую директорию. Я ради интереса, наткнись на такой ресурс, попробывал бы ещё и две точки подряд: директория уровнем выше.
      • +3
        пожалуй фигню пишу, ибо в этом случае точка после слеша должна быть, а покуда она до разделителя то это часть доменного имени, так что получил бы я скорее всего Bad Request
  • +13
    Ух ты, в AdBlock Plus оказывается есть специльный helper

    • 0
      Он не совсем для этого «специальный». Он исправляет ошибки/описки в доменах верхнего уровня.
  • 0
    Помню, вместо yandex.ru. открывался ya.ru
  • 0
    Часто на сайт вешается куча алиасов с дополнительных доменных имен. Так что как правило такой rewrite и так стоит, с перенаправлением на основной домен.
  • –2
  • 0
    При включенном HTTPS решение проблемы в статье не помогает, на HTTP все ок (сервер Apache). Кто-нибудь знает работающее решение?
    • +1
      Поигрался самоподписанными сертификатами. Сертификат для домена с точкой не работает на домене без точки и наоборот.

      Таким образом, ничего на ум не приходит, кроме создания двух сертификатов (для example.com и example.com.) и настройки сервера для выбора сертификата.
      • +1
        При SSL handshake сервер ещё не знает, куда хотел зайти пользователь.

        Поэтому на одном ip по одному 443 порту может висеть сервер с одним сертификатом.

        Правда, в X509 есть хитрые поля, которые позволяют использовать сертификат для нескольких доменов (например example.com и *.example.com), но в CN всё равно написан только один.
        • +1
          А как же SNI?
          • 0
            Спасибо за информацию, не встречал ранее RFC6066.
            Буду использовать, хоть и не админ ни разу)
  • +15
    В ВК это удобная фича для просмотра страниц, на которых ты в бане. Разлогиниваться лень, открывать новое окно — инкогнито — неудобно.
    • 0
      Палите контору.
    • 0
      уже пофиксили, редиректит на vk.com
  • +2
    На самом деле такие глюки с доменами возникают чаще, чем вы вы думаете. Подавляющее большинство написанных на коленке «автоматических превращалок текста в URLы» (обычно длиной в один regex) игнорирует тот факт, что точка или запятая в конце адреса, скорее всего, являются частью предложения, а не URL. Например:

    Зайди на www.example.com, http://example.com, www.example.com/test, потом на http://www.example.com/test.
    спокойно может превратиться в
    Зайди на <a href="http://www.example.com,">www.example.com,</a> <a href="http://example.com,">http://example.com,</a> <a href="www.example.com/test,">www.example.com/test,</a> потом на <a href="http://www.example.com/test.">http://www.example.com/test.</a>
    а не в
    Зайди на <a href="http://www.example.com">www.example.com</a>, <a href="http://example.com">http://example.com</a>, <a href="www.example.com/test">www.example.com/test</a>, потом на <a href="http://www.example.com/test">http://www.example.com/test</a>.
    — и всё, у вас битые ссылки.
    • +1
      Я по этой причине в сообщениях после доменов всегда слэш ставлю: если ошибка и будет, то не настолько критичная.
      • +1
        Я или использую BB-теги, если они поддерживаются, или всегда ставлю пробел после URL.

        Слэши после домена, кстати, в любом случае имеет смысл ставить — запросы без слэша на конце почти всегда ведут к дополнительному запросу после редиректа на URL со слэшем. :)
        • +1
          не понял, как это на уровне HTTP выглядит?
          при заходе просто на yandex.ru формируется запрос
          GET / HTTP/1.1
          Host: yandex.ru

          путь к файлу (после GET) не может быть пустым.
          • 0
            Гм. Да. Если подумать, то я чушь сморозил. Уже и не помню, где и когда это читал. Возможно, лет десять назад на заре своих занятий вебом. %)
            • +1
              Возможно спутали с урлами вида example.com/sub и example.com/sub/ — там действительно многое зависит от настроек сервера, вплоть до выдачи 404, а в каких-то рекомендациях встречалось 301 выдавать в целях SEO, емнип.
      • +3
        А я просто всегда ставлю пробел после URL'а, причём уже настолько приучил себя, что даже подсознательно это происходит. Конечно, коряво — пробел перед запятой/скобкой/…, но спокойствие нервов (точно интерпретируется правильно) дороже.

        Кстати, насчёт на-коленке-парсеров: разумеется, в нормальных соцсетях и скайпах такое редко встречается. Но лично у меня привычку эту выработали ранние Twitter-клиенты, которых я, когда только зарегался в начале 2009-го, менял много в попытках найти хоть какой-то юзабельный. Вот там-то этого наколеночного безобразия было просто навалом.
    • 0
      В этом плане самый крутой парсер, наверное, в VK, не то что знаки препинания после доменного имени, ему даже отсутствие объявления http не мешает распознать ссылку. Видимо, понимают, с какой аудиторией имеют дело.
  • 0
    спасибо за статью и тест. Во время чтения статьи я немного напрягся, но тесты показали что всеми негативами можно просто пренебречь. Никого не беспокоит такое поведение, даже крупнейшие компании, поэтому и я не буду напрягаться.
  • +15
    Nginx

    if ($http_host != 'domain.zone') {
        rewrite  ^/(.*)$  http://domain.zone/$1 permanent;
    }  
    

    
    server {
         server_name domain.zone. ;
         rewrite  ^/(.*)$  http://domain.zone/$1 permanent;
    }
    


    И прекратите уже совать в howto «про nginx» эти вечные if на каждый запрос. Да еще зачаствую и с regexp'ами и set внутри. В интернете и так этой чуши полно написано, не приумножайте.
    • 0
      Спасибо. Изменено.
      • +12
        Не надо там rewrite использовать, вам опять упячку посоветовали. В этом случае просто return надо.
        Вот тут все случаи разобраны: wiki.nginx.org/Pitfalls
    • 0
      Проверка показала (Nginx 1.2.7, FF 19.0.2), что при обращении к domain.zone. Nginx не заходит внутрь:

      server {
           server_name domain.zone. ;
          ...
      }
      
    • 0
      Еще лучше:

      - rewrite  ^/(.*)$  http://domain.zone/$1 permanent;
      + return 301 http://domain.zone$request_uri;
      
  • +35
    Я как-то случайно не убрал точку в скопированном адресе, открыл его в хроме в таком виде и тут же переключился на другую вкладку. Через секунду услышал звук, будто что-то горит в ноутбуке — запаниковал, думаю, батарея загорелась! (я тогда как раз неродную китайскую поставил) Тут же ноутбук подальше от себя, выключаю скорее кнопкой. Смотрю, а ничего вроде и не горит. Подождал, успокоился, обнюхал все. Решил попробовать запустить снова. Загружаю компьютер, запускаю хром — и снова тот же звук.

    Оказалось, тот домен с точкой перенаправлял на сайт по продаже каминов, где в качестве фонового звука стоял звук горения, весьма натуральный. При том, что оригинальный домен, без точки, к каминам никакого отношения вообще не имел. Испугался я тогда знатно, но зато про точку с тех пор хорошо запомнил.
    • +7
      Cool story, bro!
      • +10
        Я вообще офигел, думал все закончится: не трогайте точку, у меня так брат умер.

        А он тут настоящая история о_0
    • +1
      Сайты с фоновым звуком — зло.

      Если каждый из нас убедит хотя-бы одного человека не ставить или убрать фоновый звук с сайта — мир станет лучше.

      P. S Вчера видел сайт на флеше. Бррр…
      • +3
        Звучит как: «Вчера видел маньяка во дворе, доедающего мертвую шлюху».
  • +2
    Nginx

    server {
         server_name domain.zone. ;
         return 301 $http://domain.zone$request_uri;
    }
    


    Вы это сами придумали? Во-первых, переменной $http в nginx не существует. И с такой конфигурацией он просто не запустится, если такую переменную специально не создать.

    Во-вторых, абсолютно бесполезная конструкция. Т.к. nginx сам нормализует имя хоста перед поиском его по дереву виртуальных хостов. Запрос в данный виртуальный сервер никогда не попадет.
    • 0
      Вместо $http автор, вероятно, хотел $scheme использовать, но, тем не менее, это действительно бесполезная конструкция. Собственно вопрос — остаётся только if использовать?
      • +2
        ИМХО проблема высосана из пальца. Переменная $host в nginx всегда будет содержать уже нормализованное имя хоста, и если вы используете её в конфигурации (а не raw-данные от клиента $http_host ), то у вас не должно быть никаких проблем. Вся внутренняя обработка имени хоста также проходит уже с учетом нормализованного имени.

        Проблемы могут возникнуть только у отдельных сайтописателей (включая js-программистов), которые считают за правило не читать стандартов и не знать как работает HTTP, и другие протколы, которыми они позволяют себе пользоваться. Завтра окажется, например, что их скрипт не работает, если в домене есть символы в верхнем регистре.

        Напихать if-ов в конфигурацию конечно можно, но зачем?

        По пунктам из статьи: (1) Редирект вас не спасет, поскольку проверка сертификата, очевидно, происходит до того, как браузер вообще запрашивает ресурс, (2 и 3-сюда же) — опять же «чаще всего» — это ошибка конфигурации/ошибка в скриптах, чаще или реже — не берусь судить, (4) Видимо потому, что они использую nginx и прекрасно кэшируют по нормализованному доменному имени. (5) Если конфигурировать веб-сервер копипастой из туториалов, не разбираясь, что у вас написано, то возможно всё и без точки. Как я уже написал выше, сконфигурировать nginx так, чтобы он сломался от точки — это нужно специально постараться. (6) Ну вы поняли, обычно специально даже ничего настраивать не нужно. (7) Да, конечно, инженеры отвечающие за поиск в Google или Яндекс (не путать с писателями сервисов типа почты), не знают про точку (так они и про hABraHABr.ru тогда могут не знать, что же далать аааа! =) ).

        % telnet habrahabr.ru 80
        Trying 212.24.43.42...
        Connected to habrahabr.ru.
        Escape character is '^]'.
        GET / HTTP/1.1
        Host: hABraHABr.ru
        
        HTTP/1.1 200 OK
        Server: nginx
        Date: Sat, 16 Mar 2013 14:24:38 GMT
        Content-Type: text/html; charset=utf-8
        Transfer-Encoding: chunked
        Connection: keep-alive
        Keep-Alive: timeout=25
        
        17d6d
        
        <!DOCTYPE html>
           
        <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ru">
                <head>
                        <meta http-equiv="content-type" content="text/html; charset=utf-8" />
                        <title>Лучшие за сутки / Посты / Хабрахабр</title>
        
        
        • +1
          Ну, с сертификатом действительно редирект не поможет, но ведь с куками вполне поможет… Хотя всё-равно эта точка такая экзотика, что тут пользователь сам себе злой буратино, лишь бы сайт продолжал функционировать.
        • 0
          Я не совсем понял о чем пункт №7 у вас, но уверяю, что и те и другие инженеры все это знают. А в документации к Nginx явно сказано, что $host нормализуется и может отличаться от оригинального $http_host (где будет точка). Правда, там говорится лишь о том, что из него будет убран номер порта, если он есть. Однако и точку он тоже убирает, что кстати немного противоречит стандарту.
          wiki.nginx.org/HttpCoreModule#.24host

          Если же надо сделать такой редирект, то делается это, например, так:
          if ($http_host ~* ^domain\.zone\.) {
              return 301 $scheme://$host$request_uri
          }

          И я не мог тестами вынудить браузер на таком редиректе ругнуться на SSL сертификат, хотя тот выписан на домен без точки в конце. Вероятно этот домен нормализуется ещё и при проверки сертификатов.
          • 0
            Про пункт 7 — я к тому, чтобы понизить градус паники в топике. А то сейчас набегут сеошники, и начнут писать реврайты только чтобы поисковые роботы не проиндексировали их сайт несколько раз (c точкой, без точки, и N вариантов написания с использованием верхнего регистра). Разумеется тут никакой проблемы нет.

            И если кому-то всё-таки захочется, то наилучший вариант:
            if ($http_host ~ "\.$") {
                return 301 $scheme://$host$request_uri;
            }
            


            Какой у вас за браузер? =) Firefox 19 и Chromium 26 ругаются.
            • 0
              У меня браузер на базе 24 хромиума и 25 ванильный хром, а также Safari 6.0.3. проверяю так — просто захожу на www.dropbox.com. (с точкой в конце), если верить комментарию ниже, это приводит к проблемам.

              Ну правда у меня Mac OS X, может быть дело в этом.

              BTW, проверять точку в конце может быть не совсем верно, так как Браузеры в этот заголовок могут писать порт.
    • 0
      Вы не правы, что это бесполезно. Пример: есть у Вас сайт «site.ru», и кто-то зашел на него по адресу с точкой в конце («site.ru.»). Сайт откроется, но в адресной строке у человека будет что? Правильно, домен с точкой на конце. Захочет он ссылку другу послать (по почте, в аське, в скайпе) — скопирует он адресную строку, пошлет — и друг также откроет вариант с точкой на конце. Далее кто-то в блоге такую ссылку запостит — опять вариант с точкой будет попадаться людям «под мышь».

      Куда лучше ситуация, когда все «не те» варианты (т.е. все, отличные от «просто site.ru»: «www.site.ru», «site.ru.», «www.site.ru.») безусловно перенаправляют на правильный адрес (т.е. на «site.ru»), и именно он идет «в народ» (в ссылках, аськах, и т.д.). Даже единообразия ради, про SEO уж умолчу.
      • +2
        1. Как поможет решить проблему данная конструкция? Я прямо указал на то, что ни один запрос (с точкой или без) в указанный виртуальный сервер не попадет.

        2. Что значит «не те» варианты? FQDN понимаете что такое? Вариант с точкой — это самый правильный и точный вариант адресации конкретного домена. Вариант без точки вообще может привести пользователя на другой сайт (злоумышленника, например).

        И забудьте про SEO. Оно тут никаким боком.
        • 0
          1. Проверил — попадает. Точнее, вариант с точкой попадает в тот же вирт. сервер, где настроен вариант без точки. Просто когда в него попадаем, есть варианты: просто отдавать юзеру контент сайта (т.е. браузер думает, что хостнейм другой, т.к. для него «с точкой» и «без» — это разные имена, а сайт отдается на них тот же), или сделать перенаправление (неважно, каким образом, но сделать именно «301» на какое-то одно имя — вероятно, все же, на вариант «без точки»). Я за второй вариант, как писал выше.

          2. Мы вроде и боремся с этим? А как да другой сайт, если сервер ваш, на нем настроена «ловля» и того, и другого варианта, и DNS указывает на ваш сервер?

          3. SEO мне и Вам не нужно особо, но Вы забываете, что у любого действия должна быть цель. Сферический веб-сервер в вакууме — штука академически полезная, но, если только это не лично для свои целей сервер, надо как-то и «о мире» подумать.

          Я, ко всему, люблю считать, что у сайта есть одно имя, а остальные приводят на него — мне так кажется аккуратнее, и логичнее.
          • 0
            1. Перечитайте ещё раз комментарий, на который отвечаете. Я не понимаю с чем идет спор. Конструкция, которая предлагалась в статье на момент написания мной того комментария:
            server {
                 server_name domain.zone. ;
                 return 301 $http://domain.zone$request_uri;
            }
            
            не работает, и работать не может. Причины я описал.

            2. Домен без точки — это относительный адрес, и он может указывать куда угодно. Разница примерно такая же, как между: cd /data/web и cd data/web. Что покажет pwd после выполнения второй команды предсказать нельзя, это зависит от того, в какой вы директории находитесь. Какие бывают проблемы, читайте например RFC 1535 (хотя с тех пор не актуально, но представление дает).

            3. Если вы за это боритесь, то делать редирект на домен с точкой — ваш единственный вариант.
            • 0
              2. Для наглядной иллюстрации можете выполнить:
              # echo -e "search vbart.ru\noptions ndots:5" >> /etc/resolv.conf
              

              После этого yandex.ru и yandex.ru. у вас будут вести на разные сайты.
  • 0
    Facebook чот нифига не перенаправляет: ompldr.org/vaHJ6ag
  • –2
    На Dropbox с точкой в конце из хрома попасть вообще невозможно.
    Судя по тому, что я вижу, у них таки настроен редирект.

    • –2
      аналогично www.google.com.
    • 0
      Тут как раз все понятно, подставляя точку веб сервер не видит контекста с таким доменным именем и выкидывает запрос в default, а там реврайтом довешивается редирект. А не заходит потому, как сертификат выдан на конкретное доменное имя, а имя с точкой воспринимается как другое имя.
  • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    А вот Ucoz на сайты с точкой пишет, что сайт не зарегистрирован.
  • +1
    По мне, так сайт (любой) должен иметь один-единственный адрес, а со всех остальных «похожих» адресов надо делать 301 Moved Permanently.

    За себя скажу, что давным-давно привык для каждого сайта заводить 2 виртуальных сервера:
    — один для адреса (возьмем для примера) site.ru, безо всяких алиасов, и
    — второй, в котором перечислены все-все варианты неправильного указания адреса того же домена, плюс все домены-синонимы — и вся настройка этого виртуального сервера сводится к (для Апача) Redirect permanent / site.ru/.
    В результате и волки оказываются сыты, и овцы целы — сайт открывается строго по одному адресу (ибо только он и прописан для этого вирт. хоста), а все-все варианты, как еще к сайту можно добраться, будут успешно перенаправлять на основной адрес.

    Так вот в список именов хоста для второго вирт. сервера, естественно, добавляем и вариант написания с точкой на конце:
    — вирт. хост 1: site.ru
    — вирт. хост 2: www.site.ru, site.ru., www.site.ru.

    За статью огромное «спасибо», тема мало где раскрывается, тем более применительно к вебу.

  • 0
    удалено
  • 0
    конструкция для апача реально работает, но только на сам домен, а вот если внутренние ссылки с точками в домене вызывать, то переадресации не происходит, правильнее будет написать, что то типа:
    RewriteCond %{HTTP_HOST} !^domain\.zone$
    RewriteRule ^(.*)$ domain.zone/$1 [L,R=301]
  • 0
    Проверил node.js require('url').parse(request.url).pathname, с точкой нормально работает.
  • 0
    RFC3986 (URI) описывает несколько видов нормализации URI при сравнении, но про «host» в нем говорится лишь то, что они должны сравниваться как строки, без учета регистра. в RFC2616 (HTTP/1.1) определение host отдается на откуп RFC2396 (который устарел и замен RFC3986) и там тоже ни какой отдельной нормализации для хостов не предполагается.

    отсюда я делаю вывод, что хоть «server.com» и «server.com.» резолвятся в DNS одинаково, с точки зрения URI, это два разных хоста. тогда не понятно, почему в nginx считает их эквивалентными? видимо отсюда возникает часть этой путаницы:
    вы и не подозреваете, что ваш сайт доступен по доменному имени с точкой в конце (domain.zone.), так как браузеры позволяют обращаться к сайтам, как с точкой в конце домена, так и без неё
    с той лишь разницей, что неподозреваемая доступность сайта лежит на совести сервера, а не браузера.

    согласен с выводом в статье, что в большинстве случаев для web-сайта будет хорошим тоном при запросе к «server.com.» откликаться 301 редиректом на «server.com», как и во всех остальных случаях с alias'ами. просто этот aiias достается задаром — его не надо отдельно регистрировать и париться за киберсвотеров. :)
  • 0
    Кто подскажет как проделать это через web.config?
    • 0
      Можно использовать модуль для IIS — URL Rewrite (http://www.iis.net/downloads/microsoft/url-rewrite).
      Но мне тоже никак не удается настроить правило для точки.

      Пытаюсь сделать так:

      <rule name="point" stopProcessing="true"> <match url="^(.*)\.$" /> <action type="Redirect" url="{R:1}" redirectType="Temporary" /> </rule>

      Правило стоит первым. Но оно не срабатывает и в итоге все равно получаем 404.
      И проблема именно в точке, т.к. если изменить точку, к примеру, на запятую (^(.*),$), то работает.

      Люди добрые, подскажите, как правильно настроить это правило.
      • +1
        Нашла ответ здесь
        Чтобы данное правило работало для MVC, необходимо в web.config добавить параметр:
        <httpRuntime relaxedUrlToFileSystemMapping="true"/>

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.