transpond16 мар 2013 в 09:15

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

4 мин

99K

Веб-разработка * Информационная безопасность *

+110

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

kekekeks 16 мар 2013 в 09:42

Интересный факт: точка в конце пути (http://example.com/path.) может привести к тому, что System.Uri его неправильно распарсит. Баг тянется чуть ли не с первого фреймворка и фиксить его никто не собирается (есть workaround, который неприменим к изолированным окружениям типа Silverlight).

amarao 16 мар 2013 в 09:43

А чем плоха точка в конце uri? Точка после слеша к dns уже никакого отношения не имеет.

kekekeks 16 мар 2013 в 09:47

Она ничем не плоха, плох баг в парсере мелкомягких, который пытается воспринять путь из Url как путь в файловой системе и считает, что точка в конце имени файла может быть проигнорирована.
Кстати, в Mono-вской реализации mscorlib этот баг отсутствует.

amarao 16 мар 2013 в 09:42

who care? Если на сайт зайдут по IP, то в куче случаев он тоже не будет работать, и? Повод всем бежать и прописывать default?

transpond 16 мар 2013 в 09:47

«Случайно» зайти по IP на сайт довольно сложно.

amarao 16 мар 2013 в 10:08

Чем это отличается от «захода» на сайт вида .www.yandex.ru? Кривой url — кривое отображение. Тем паче, что большинство url'ов всё-таки содержат путь, так что точка попаёт в путь, а не в доменное имя.

dm9 16 мар 2013 в 11:26

Скорее, «www.yandex.ru.». У меня во фреймворке такие заходы логируются (чисто из интереса), и, я скажу, народ постоянно приходит на домены с точкой. По-видимому, у кого-то просто срабатывает моторный рефлекс, и люди ставят в конце точку как точку в конце предложения.

Krypt 16 мар 2013 в 22:46

Это особенности некоторых парсеров сайтов, которые выделяют урлы автоматом: если после урла стоит точка, завершающая предложение, они её запихивают в урл. Например так было раньше на сайте www.habrahabr.ru. Сейчас уже исправленно, как видите.

ivan386 13 окт 2014 в 15:24

У меня ваш пример не открывается.

bO_oblik 16 мар 2013 в 09:49

Это для самых любящих веб-мастеров, у них интерфейс сайта работоспособен даже если отключить javascript, браузер, компьютер, пырнуть монитор ножом.

nooze 16 мар 2013 в 14:19

Я встречал заказчика (такой дядечка 50+ лет) который требовал что бы его напичканный яваскриптом и аяксом интернет магазин на битриксе был работоспособен даже в текстовых браузерах типа lynx! Местные разрабочики пытались долго его отговаривать и в итоге все таки сделали супер-облегченную версию специально под lynx и подобные браузеры на основе какого-то wap-шаблона. Шутили что дальше он захочет что бы покупать товары можно было через telnet.

ICELedyanoj 16 мар 2013 в 09:48

twitter.com./ не понравился Касперскому. Сказал, что не может проверить подлинность сертификата.

ICELedyanoj 16 мар 2013 в 20:26

Как-то я не понял что произошло и откуда такая бурная реакция?
В статье сказано, что twitter.com./ выдает 404, а я лишь добавил, что кроме этого KIS не нравится сертификат twitter, открытого по такому варианту URL.
Я вас не понимаю, люди. Еще и прямо в карму наплевали…

Katagi 17 мар 2013 в 07:39

Подозреваю, что люди удивлены причем тут KIS и проверка подлинности сертификата.

kin63camapa 16 мар 2013 в 09:49

А нет какой-нибудь статиски, наприемер с DNS крупного ресурса, насколько часто такие запросы приходят?

middle 16 мар 2013 в 11:46

На уровне DNS точка есть всегда. Нужно смотреть на уровне веб-сервера.

kin63camapa 16 мар 2013 в 12:36

хорошо, это я понял, но как то хочется узнать насколько часто люди переходят по адресам с точкой в конце домена (ну не считая хабравчан которые прочитав эту статью принялись эксперементировать).

middle 16 мар 2013 в 12:45

Надо собирать статистику на уровне веб-сервера.

zapimir 16 мар 2013 в 12:53

Та крайне редко переходят, на уровне опечаток. Тем более что большинство народу думает, что точка после домена это ошибка, и там максимум слэш может стоять (ну или двоеточие с номером порта).

qazwsx 16 мар 2013 в 09:54

На Хабре с домена с точкой нельзя проголосовать.

ivaschenko 16 мар 2013 в 09:54

Судя по всему, Яндекс нормально отрабатывает.

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

187 16 мар 2013 в 10:04

Не знаю как, но у меня пару лет назад при случайном открытии домена с точкой, появился листинг директорий и файлов. Так и не понял, как это вышло, то ли баг, то ли еще что-то…

amarao 16 мар 2013 в 10:09

default был так настроен. Зашли бы по IP, показало бы то же самое.

kin63camapa 16 мар 2013 в 10:12

Скорее всего недосмотр админа, что кому попало листинг выдаётся, а так ничего удивительного, в файловой системе издавна точка обозначала текущую директорию. Я ради интереса, наткнись на такой ресурс, попробывал бы ещё и две точки подряд: директория уровнем выше.

kin63camapa 16 мар 2013 в 10:29

пожалуй фигню пишу, ибо в этом случае точка после слеша должна быть, а покуда она до разделителя то это часть доменного имени, так что получил бы я скорее всего Bad Request

rassadin 16 мар 2013 в 10:26

Ух ты, в AdBlock Plus оказывается есть специльный helper

oleksa 16 мар 2013 в 21:07

Он не совсем для этого «специальный». Он исправляет ошибки/описки в доменах верхнего уровня.

Bo0oM 16 мар 2013 в 11:04

Помню, вместо yandex.ru. открывался ya.ru

thecoder 16 мар 2013 в 11:04

Часто на сайт вешается куча алиасов с дополнительных доменных имен. Так что как правило такой rewrite и так стоит, с перенаправлением на основной домен.

MaksSlesarenko 16 мар 2013 в 11:05

…

akke 16 мар 2013 в 11:14

При включенном HTTPS решение проблемы в статье не помогает, на HTTP все ок (сервер Apache). Кто-нибудь знает работающее решение?

basilisk 16 мар 2013 в 20:32

Поигрался самоподписанными сертификатами. Сертификат для домена с точкой не работает на домене без точки и наоборот.

Таким образом, ничего на ум не приходит, кроме создания двух сертификатов (для example.com и example.com.) и настройки сервера для выбора сертификата.

grossws 17 мар 2013 в 01:28

При SSL handshake сервер ещё не знает, куда хотел зайти пользователь.

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

Правда, в X509 есть хитрые поля, которые позволяют использовать сертификат для нескольких доменов (например example.com и *.example.com), но в CN всё равно написан только один.

J_o_k_e_R 20 мар 2013 в 18:36

А как же SNI?

grossws 20 мар 2013 в 18:45

Спасибо за информацию, не встречал ранее RFC6066.
Буду использовать, хоть и не админ ни разу)

Teodorix 16 мар 2013 в 11:48

В ВК это удобная фича для просмотра страниц, на которых ты в бане. Разлогиниваться лень, открывать новое окно — инкогнито — неудобно.

vertus 31 мар 2013 в 20:23

Палите контору.

6opoDuJIo 13 апр 2013 в 00:31

уже пофиксили, редиректит на vk.com

Athari 16 мар 2013 в 11:55

На самом деле такие глюки с доменами возникают чаще, чем вы вы думаете. Подавляющее большинство написанных на коленке «автоматических превращалок текста в 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>.

— и всё, у вас битые ссылки.

putnik 16 мар 2013 в 12:02

Я по этой причине в сообщениях после доменов всегда слэш ставлю: если ошибка и будет, то не настолько критичная.

Athari 16 мар 2013 в 12:06

Я или использую BB-теги, если они поддерживаются, или всегда ставлю пробел после URL.

Слэши после домена, кстати, в любом случае имеет смысл ставить — запросы без слэша на конце почти всегда ведут к дополнительному запросу после редиректа на URL со слэшем. :)

qw1 16 мар 2013 в 16:32

не понял, как это на уровне HTTP выглядит?
при заходе просто на yandex.ru формируется запрос

GET / HTTP/1.1
Host: yandex.ru

путь к файлу (после GET) не может быть пустым.

Athari 16 мар 2013 в 17:15

Гм. Да. Если подумать, то я чушь сморозил. Уже и не помню, где и когда это читал. Возможно, лет десять назад на заре своих занятий вебом. %)

VolCh 16 мар 2013 в 21:45

Возможно спутали с урлами вида example.com/sub и example.com/sub/ — там действительно многое зависит от настроек сервера, вплоть до выдачи 404, а в каких-то рекомендациях встречалось 301 выдавать в целях SEO, емнип.

moonlighter 16 мар 2013 в 12:58

А я просто всегда ставлю пробел после URL'а, причём уже настолько приучил себя, что даже подсознательно это происходит. Конечно, коряво — пробел перед запятой/скобкой/…, но спокойствие нервов (точно интерпретируется правильно) дороже.

Кстати, насчёт на-коленке-парсеров: разумеется, в нормальных соцсетях и скайпах такое редко встречается. Но лично у меня привычку эту выработали ранние Twitter-клиенты, которых я, когда только зарегался в начале 2009-го, менял много в попытках найти хоть какой-то юзабельный. Вот там-то этого наколеночного безобразия было просто навалом.

vertus 31 мар 2013 в 20:30

В этом плане самый крутой парсер, наверное, в VK, не то что знаки препинания после доменного имени, ему даже отсутствие объявления http не мешает распознать ссылку. Видимо, понимают, с какой аудиторией имеют дело.

charon 16 мар 2013 в 12:02

спасибо за статью и тест. Во время чтения статьи я немного напрягся, но тесты показали что всеми негативами можно просто пренебречь. Никого не беспокоит такое поведение, даже крупнейшие компании, поэтому и я не буду напрягаться.

cadmi 16 мар 2013 в 12:27

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 внутри. В интернете и так этой чуши полно написано, не приумножайте.

transpond 16 мар 2013 в 12:35

Спасибо. Изменено.

aefimov 16 мар 2013 в 12:47

Не надо там rewrite использовать, вам опять упячку посоветовали. В этом случае просто return надо.
Вот тут все случаи разобраны: wiki.nginx.org/Pitfalls

transpond 16 мар 2013 в 18:42

Проверка показала (Nginx 1.2.7, FF 19.0.2), что при обращении к domain.zone. Nginx не заходит внутрь:

server {
     server_name domain.zone. ;
    ...
}

symbix 16 мар 2013 в 22:08

Еще лучше:

- rewrite  ^/(.*)$  http://domain.zone/$1 permanent;
+ return 301 http://domain.zone$request_uri;

white_panda 16 мар 2013 в 12:57

Я как-то случайно не убрал точку в скопированном адресе, открыл его в хроме в таком виде и тут же переключился на другую вкладку. Через секунду услышал звук, будто что-то горит в ноутбуке — запаниковал, думаю, батарея загорелась! (я тогда как раз неродную китайскую поставил) Тут же ноутбук подальше от себя, выключаю скорее кнопкой. Смотрю, а ничего вроде и не горит. Подождал, успокоился, обнюхал все. Решил попробовать запустить снова. Загружаю компьютер, запускаю хром — и снова тот же звук.

Оказалось, тот домен с точкой перенаправлял на сайт по продаже каминов, где в качестве фонового звука стоял звук горения, весьма натуральный. При том, что оригинальный домен, без точки, к каминам никакого отношения вообще не имел. Испугался я тогда знатно, но зато про точку с тех пор хорошо запомнил.

Narada 16 мар 2013 в 13:05

Cool story, bro!

bO_oblik 16 мар 2013 в 14:02

Я вообще офигел, думал все закончится: не трогайте точку, у меня так брат умер.

А он тут настоящая история о_0

adic3x 17 мар 2013 в 07:50

Сайты с фоновым звуком — зло.

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

P. S Вчера видел сайт на флеше. Бррр…

НЛО прилетело и опубликовало эту надпись здесь

VBart 16 мар 2013 в 13:38

Nginx

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

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

Во-вторых, абсолютно бесполезная конструкция. Т.к. nginx сам нормализует имя хоста перед поиском его по дереву виртуальных хостов. Запрос в данный виртуальный сервер никогда не попадет.

frol 16 мар 2013 в 13:50

Вместо $http автор, вероятно, хотел $scheme использовать, но, тем не менее, это действительно бесполезная конструкция. Собственно вопрос — остаётся только if использовать?

VBart 16 мар 2013 в 14:30

ИМХО проблема высосана из пальца. Переменная $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>

frol 16 мар 2013 в 14:37

Ну, с сертификатом действительно редирект не поможет, но ведь с куками вполне поможет… Хотя всё-равно эта точка такая экзотика, что тут пользователь сам себе злой буратино, лишь бы сайт продолжал функционировать.

aefimov 16 мар 2013 в 17:58

Я не совсем понял о чем пункт №7 у вас, но уверяю, что и те и другие инженеры все это знают. А в документации к Nginx явно сказано, что $host нормализуется и может отличаться от оригинального $http_host (где будет точка). Правда, там говорится лишь о том, что из него будет убран номер порта, если он есть. Однако и точку он тоже убирает, что кстати немного противоречит стандарту.
wiki.nginx.org/HttpCoreModule#.24host

Если же надо сделать такой редирект, то делается это, например, так:

if ($http_host ~* ^domain\.zone\.) {
    return 301 $scheme://$host$request_uri
}

И я не мог тестами вынудить браузер на таком редиректе ругнуться на SSL сертификат, хотя тот выписан на домен без точки в конце. Вероятно этот домен нормализуется ещё и при проверки сертификатов.

VBart 16 мар 2013 в 23:35

Про пункт 7 — я к тому, чтобы понизить градус паники в топике. А то сейчас набегут сеошники, и начнут писать реврайты только чтобы поисковые роботы не проиндексировали их сайт несколько раз (c точкой, без точки, и N вариантов написания с использованием верхнего регистра). Разумеется тут никакой проблемы нет.

И если кому-то всё-таки захочется, то наилучший вариант:

if ($http_host ~ "\.$") {
    return 301 $scheme://$host$request_uri;
}

Какой у вас за браузер? =) Firefox 19 и Chromium 26 ругаются.

aefimov 16 мар 2013 в 23:45

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

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

BTW, проверять точку в конце может быть не совсем верно, так как Браузеры в этот заголовок могут писать порт.

achekalin 17 мар 2013 в 08:51

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

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

VBart 17 мар 2013 в 16:55

1. Как поможет решить проблему данная конструкция? Я прямо указал на то, что ни один запрос (с точкой или без) в указанный виртуальный сервер не попадет.

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

И забудьте про SEO. Оно тут никаким боком.

achekalin 17 мар 2013 в 17:18

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

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

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

Я, ко всему, люблю считать, что у сайта есть одно имя, а остальные приводят на него — мне так кажется аккуратнее, и логичнее.

VBart 18 мар 2013 в 01:03

1. Перечитайте ещё раз комментарий, на который отвечаете. Я не понимаю с чем идет спор. Конструкция, которая предлагалась в статье на момент написания мной того комментария:

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

не работает, и работать не может. Причины я описал.

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

3. Если вы за это боритесь, то делать редирект на домен с точкой — ваш единственный вариант.

VBart 18 мар 2013 в 01:42

2. Для наглядной иллюстрации можете выполнить:

# echo -e "search vbart.ru\noptions ndots:5" >> /etc/resolv.conf

После этого yandex.ru и yandex.ru. у вас будут вести на разные сайты.

side2k 16 мар 2013 в 15:36

Facebook чот нифига не перенаправляет: ompldr.org/vaHJ6ag

Eefrit 16 мар 2013 в 15:43

На Dropbox с точкой в конце из хрома попасть вообще невозможно.
Судя по тому, что я вижу, у них таки настроен редирект.

mexanism 16 мар 2013 в 19:06

аналогично www.google.com.

nonname 16 мар 2013 в 22:23

Тут как раз все понятно, подставляя точку веб сервер не видит контекста с таким доменным именем и выкидывает запрос в default, а там реврайтом довешивается редирект. А не заходит потому, как сертификат выдан на конкретное доменное имя, а имя с точкой воспринимается как другое имя.

НЛО прилетело и опубликовало эту надпись здесь

Haoose 16 мар 2013 в 18:52

А вот Ucoz на сайты с точкой пишет, что сайт не зарегистрирован.

achekalin 16 мар 2013 в 22:29

По мне, так сайт (любой) должен иметь один-единственный адрес, а со всех остальных «похожих» адресов надо делать 301 Moved Permanently.

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

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

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

6opoDuJIo 17 мар 2013 в 00:51

удалено

oleksiivinogradov 17 мар 2013 в 07:02

конструкция для апача реально работает, но только на сам домен, а вот если внутренние ссылки с точками в домене вызывать, то переадресации не происходит, правильнее будет написать, что то типа:
RewriteCond %{HTTP_HOST} !^domain\.zone$
RewriteRule ^(.*)$ domain.zone/$1 [L,R=301]

Triang3l 17 мар 2013 в 11:28

Проверил node.js require('url').parse(request.url).pathname, с точкой нормально работает.

funca 18 мар 2013 в 05:08

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 достается задаром — его не надо отдельно регистрировать и париться за киберсвотеров. :)

Haystov 18 мар 2013 в 13:25

Кто подскажет как проделать это через web.config?

EllaVS 20 мар 2013 в 06:42

Можно использовать модуль для 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.
И проблема именно в точке, т.к. если изменить точку, к примеру, на запятую (^(.*),$), то работает.

Люди добрые, подскажите, как правильно настроить это правило.

EllaVS 20 мар 2013 в 09:01

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий