Комментарии 83
Интересный факт: точка в конце пути (http://example.com/path.) может привести к тому, что System.Uri его неправильно распарсит. Баг тянется чуть ли не с первого фреймворка и фиксить его никто не собирается (есть workaround, который неприменим к изолированным окружениям типа Silverlight).
who care? Если на сайт зайдут по IP, то в куче случаев он тоже не будет работать, и? Повод всем бежать и прописывать default?
«Случайно» зайти по IP на сайт довольно сложно.
Чем это отличается от «захода» на сайт вида .www.yandex.ru? Кривой url — кривое отображение. Тем паче, что большинство url'ов всё-таки содержат путь, так что точка попаёт в путь, а не в доменное имя.
Скорее, «www.yandex.ru.». У меня во фреймворке такие заходы логируются (чисто из интереса), и, я скажу, народ постоянно приходит на домены с точкой. По-видимому, у кого-то просто срабатывает моторный рефлекс, и люди ставят в конце точку как точку в конце предложения.
Это особенности некоторых парсеров сайтов, которые выделяют урлы автоматом: если после урла стоит точка, завершающая предложение, они её запихивают в урл. Например так было раньше на сайте www.habrahabr.ru. Сейчас уже исправленно, как видите.
У меня ваш пример не открывается.
Это для самых любящих веб-мастеров, у них интерфейс сайта работоспособен даже если отключить javascript, браузер, компьютер, пырнуть монитор ножом.
Я встречал заказчика (такой дядечка 50+ лет) который требовал что бы его напичканный яваскриптом и аяксом интернет магазин на битриксе был работоспособен даже в текстовых браузерах типа lynx! Местные разрабочики пытались долго его отговаривать и в итоге все таки сделали супер-облегченную версию специально под lynx и подобные браузеры на основе какого-то wap-шаблона. Шутили что дальше он захочет что бы покупать товары можно было через telnet.
twitter.com./ не понравился Касперскому. Сказал, что не может проверить подлинность сертификата.
Как-то я не понял что произошло и откуда такая бурная реакция?
В статье сказано, что twitter.com./ выдает 404, а я лишь добавил, что кроме этого KIS не нравится сертификат twitter, открытого по такому варианту URL.
Я вас не понимаю, люди. Еще и прямо в карму наплевали…
В статье сказано, что twitter.com./ выдает 404, а я лишь добавил, что кроме этого KIS не нравится сертификат twitter, открытого по такому варианту URL.
Я вас не понимаю, люди. Еще и прямо в карму наплевали…
А нет какой-нибудь статиски, наприемер с DNS крупного ресурса, насколько часто такие запросы приходят?
На Хабре с домена с точкой нельзя проголосовать.
Судя по всему, Яндекс нормально отрабатывает.
(При попытке добавить домен с точкой говорит о том, что он уже проиндексировался, но в индексе только нормальный домен.)
(При попытке добавить домен с точкой говорит о том, что он уже проиндексировался, но в индексе только нормальный домен.)
Не знаю как, но у меня пару лет назад при случайном открытии домена с точкой, появился листинг директорий и файлов. Так и не понял, как это вышло, то ли баг, то ли еще что-то…
default был так настроен. Зашли бы по IP, показало бы то же самое.
Скорее всего недосмотр админа, что кому попало листинг выдаётся, а так ничего удивительного, в файловой системе издавна точка обозначала текущую директорию. Я ради интереса, наткнись на такой ресурс, попробывал бы ещё и две точки подряд: директория уровнем выше.
Ух ты, в AdBlock Plus оказывается есть специльный helper
Помню, вместо yandex.ru. открывался ya.ru
Часто на сайт вешается куча алиасов с дополнительных доменных имен. Так что как правило такой rewrite и так стоит, с перенаправлением на основной домен.
…
При включенном HTTPS решение проблемы в статье не помогает, на HTTP все ок (сервер Apache). Кто-нибудь знает работающее решение?
Поигрался самоподписанными сертификатами. Сертификат для домена с точкой не работает на домене без точки и наоборот.
Таким образом, ничего на ум не приходит, кроме создания двух сертификатов (для example.com и example.com.) и настройки сервера для выбора сертификата.
Таким образом, ничего на ум не приходит, кроме создания двух сертификатов (для example.com и example.com.) и настройки сервера для выбора сертификата.
При SSL handshake сервер ещё не знает, куда хотел зайти пользователь.
Поэтому на одном ip по одному 443 порту может висеть сервер с одним сертификатом.
Правда, в X509 есть хитрые поля, которые позволяют использовать сертификат для нескольких доменов (например example.com и *.example.com), но в CN всё равно написан только один.
Поэтому на одном ip по одному 443 порту может висеть сервер с одним сертификатом.
Правда, в X509 есть хитрые поля, которые позволяют использовать сертификат для нескольких доменов (например example.com и *.example.com), но в CN всё равно написан только один.
А как же SNI?
В ВК это удобная фича для просмотра страниц, на которых ты в бане. Разлогиниваться лень, открывать новое окно — инкогнито — неудобно.
На самом деле такие глюки с доменами возникают чаще, чем вы вы думаете. Подавляющее большинство написанных на коленке «автоматических превращалок текста в 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>.
Я по этой причине в сообщениях после доменов всегда слэш ставлю: если ошибка и будет, то не настолько критичная.
Я или использую BB-теги, если они поддерживаются, или всегда ставлю пробел после URL.
Слэши после домена, кстати, в любом случае имеет смысл ставить — запросы без слэша на конце почти всегда ведут к дополнительному запросу после редиректа на URL со слэшем. :)
Слэши после домена, кстати, в любом случае имеет смысл ставить — запросы без слэша на конце почти всегда ведут к дополнительному запросу после редиректа на URL со слэшем. :)
не понял, как это на уровне HTTP выглядит?
при заходе просто на yandex.ru формируется запрос
путь к файлу (после GET) не может быть пустым.
при заходе просто на yandex.ru формируется запрос
GET / HTTP/1.1
Host: yandex.ruпуть к файлу (после GET) не может быть пустым.
А я просто всегда ставлю пробел после URL'а, причём уже настолько приучил себя, что даже подсознательно это происходит. Конечно, коряво — пробел перед запятой/скобкой/…, но спокойствие нервов (точно интерпретируется правильно) дороже.
Кстати, насчёт на-коленке-парсеров: разумеется, в нормальных соцсетях и скайпах такое редко встречается. Но лично у меня привычку эту выработали ранние Twitter-клиенты, которых я, когда только зарегался в начале 2009-го, менял много в попытках найти хоть какой-то юзабельный. Вот там-то этого наколеночного безобразия было просто навалом.
Кстати, насчёт на-коленке-парсеров: разумеется, в нормальных соцсетях и скайпах такое редко встречается. Но лично у меня привычку эту выработали ранние Twitter-клиенты, которых я, когда только зарегался в начале 2009-го, менял много в попытках найти хоть какой-то юзабельный. Вот там-то этого наколеночного безобразия было просто навалом.
В этом плане самый крутой парсер, наверное, в VK, не то что знаки препинания после доменного имени, ему даже отсутствие объявления http не мешает распознать ссылку. Видимо, понимают, с какой аудиторией имеют дело.
спасибо за статью и тест. Во время чтения статьи я немного напрягся, но тесты показали что всеми негативами можно просто пренебречь. Никого не беспокоит такое поведение, даже крупнейшие компании, поэтому и я не буду напрягаться.
Nginx
И прекратите уже совать в howto «про nginx» эти вечные if на каждый запрос. Да еще зачаствую и с regexp'ами и set внутри. В интернете и так этой чуши полно написано, не приумножайте.
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 внутри. В интернете и так этой чуши полно написано, не приумножайте.
Спасибо. Изменено.
Не надо там rewrite использовать, вам опять упячку посоветовали. В этом случае просто return надо.
Вот тут все случаи разобраны: wiki.nginx.org/Pitfalls
Вот тут все случаи разобраны: wiki.nginx.org/Pitfalls
Проверка показала (Nginx 1.2.7, FF 19.0.2), что при обращении к domain.zone. Nginx не заходит внутрь:
server {
server_name domain.zone. ;
...
}
Еще лучше:
- rewrite ^/(.*)$ http://domain.zone/$1 permanent;
+ return 301 http://domain.zone$request_uri;
Я как-то случайно не убрал точку в скопированном адресе, открыл его в хроме в таком виде и тут же переключился на другую вкладку. Через секунду услышал звук, будто что-то горит в ноутбуке — запаниковал, думаю, батарея загорелась! (я тогда как раз неродную китайскую поставил) Тут же ноутбук подальше от себя, выключаю скорее кнопкой. Смотрю, а ничего вроде и не горит. Подождал, успокоился, обнюхал все. Решил попробовать запустить снова. Загружаю компьютер, запускаю хром — и снова тот же звук.
Оказалось, тот домен с точкой перенаправлял на сайт по продаже каминов, где в качестве фонового звука стоял звук горения, весьма натуральный. При том, что оригинальный домен, без точки, к каминам никакого отношения вообще не имел. Испугался я тогда знатно, но зато про точку с тех пор хорошо запомнил.
Оказалось, тот домен с точкой перенаправлял на сайт по продаже каминов, где в качестве фонового звука стоял звук горения, весьма натуральный. При том, что оригинальный домен, без точки, к каминам никакого отношения вообще не имел. Испугался я тогда знатно, но зато про точку с тех пор хорошо запомнил.
Nginx
server { server_name domain.zone. ; return 301 $http://domain.zone$request_uri; }
Вы это сами придумали? Во-первых, переменной $http в nginx не существует. И с такой конфигурацией он просто не запустится, если такую переменную специально не создать.
Во-вторых, абсолютно бесполезная конструкция. Т.к. nginx сам нормализует имя хоста перед поиском его по дереву виртуальных хостов. Запрос в данный виртуальный сервер никогда не попадет.
Вместо $http автор, вероятно, хотел $scheme использовать, но, тем не менее, это действительно бесполезная конструкция. Собственно вопрос — остаётся только if использовать?
ИМХО проблема высосана из пальца. Переменная $host в nginx всегда будет содержать уже нормализованное имя хоста, и если вы используете её в конфигурации (а не raw-данные от клиента $http_host ), то у вас не должно быть никаких проблем. Вся внутренняя обработка имени хоста также проходит уже с учетом нормализованного имени.
Проблемы могут возникнуть только у отдельных сайтописателей (включая js-программистов), которые считают за правило не читать стандартов и не знать как работает HTTP, и другие протколы, которыми они позволяют себе пользоваться. Завтра окажется, например, что их скрипт не работает, если в домене есть символы в верхнем регистре.
Напихать if-ов в конфигурацию конечно можно, но зачем?
По пунктам из статьи: (1) Редирект вас не спасет, поскольку проверка сертификата, очевидно, происходит до того, как браузер вообще запрашивает ресурс, (2 и 3-сюда же) — опять же «чаще всего» — это ошибка конфигурации/ошибка в скриптах, чаще или реже — не берусь судить, (4) Видимо потому, что они использую nginx и прекрасно кэшируют по нормализованному доменному имени. (5) Если конфигурировать веб-сервер копипастой из туториалов, не разбираясь, что у вас написано, то возможно всё и без точки. Как я уже написал выше, сконфигурировать nginx так, чтобы он сломался от точки — это нужно специально постараться. (6) Ну вы поняли, обычно специально даже ничего настраивать не нужно. (7) Да, конечно, инженеры отвечающие за поиск в Google или Яндекс (не путать с писателями сервисов типа почты), не знают про точку (так они и про hABraHABr.ru тогда могут не знать, что же далать аааа! =) ).
Проблемы могут возникнуть только у отдельных сайтописателей (включая 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>
Ну, с сертификатом действительно редирект не поможет, но ведь с куками вполне поможет… Хотя всё-равно эта точка такая экзотика, что тут пользователь сам себе злой буратино, лишь бы сайт продолжал функционировать.
Я не совсем понял о чем пункт №7 у вас, но уверяю, что и те и другие инженеры все это знают. А в документации к Nginx явно сказано, что
wiki.nginx.org/HttpCoreModule#.24host
Если же надо сделать такой редирект, то делается это, например, так:
И я не мог тестами вынудить браузер на таком редиректе ругнуться на SSL сертификат, хотя тот выписан на домен без точки в конце. Вероятно этот домен нормализуется ещё и при проверки сертификатов.
$host нормализуется и может отличаться от оригинального $http_host (где будет точка). Правда, там говорится лишь о том, что из него будет убран номер порта, если он есть. Однако и точку он тоже убирает, что кстати немного противоречит стандарту.wiki.nginx.org/HttpCoreModule#.24host
Если же надо сделать такой редирект, то делается это, например, так:
if ($http_host ~* ^domain\.zone\.) {
return 301 $scheme://$host$request_uri
}И я не мог тестами вынудить браузер на таком редиректе ругнуться на SSL сертификат, хотя тот выписан на домен без точки в конце. Вероятно этот домен нормализуется ещё и при проверки сертификатов.
Про пункт 7 — я к тому, чтобы понизить градус паники в топике. А то сейчас набегут сеошники, и начнут писать реврайты только чтобы поисковые роботы не проиндексировали их сайт несколько раз (c точкой, без точки, и N вариантов написания с использованием верхнего регистра). Разумеется тут никакой проблемы нет.
И если кому-то всё-таки захочется, то наилучший вариант:
Какой у вас за браузер? =) Firefox 19 и Chromium 26 ругаются.
И если кому-то всё-таки захочется, то наилучший вариант:
if ($http_host ~ "\.$") {
return 301 $scheme://$host$request_uri;
}
Какой у вас за браузер? =) Firefox 19 и Chromium 26 ругаются.
У меня браузер на базе 24 хромиума и 25 ванильный хром, а также Safari 6.0.3. проверяю так — просто захожу на www.dropbox.com. (с точкой в конце), если верить комментарию ниже, это приводит к проблемам.
Ну правда у меня Mac OS X, может быть дело в этом.
BTW, проверять точку в конце может быть не совсем верно, так как Браузеры в этот заголовок могут писать порт.
Ну правда у меня Mac OS X, может быть дело в этом.
BTW, проверять точку в конце может быть не совсем верно, так как Браузеры в этот заголовок могут писать порт.
Вы не правы, что это бесполезно. Пример: есть у Вас сайт «site.ru», и кто-то зашел на него по адресу с точкой в конце («site.ru.»). Сайт откроется, но в адресной строке у человека будет что? Правильно, домен с точкой на конце. Захочет он ссылку другу послать (по почте, в аське, в скайпе) — скопирует он адресную строку, пошлет — и друг также откроет вариант с точкой на конце. Далее кто-то в блоге такую ссылку запостит — опять вариант с точкой будет попадаться людям «под мышь».
Куда лучше ситуация, когда все «не те» варианты (т.е. все, отличные от «просто site.ru»: «www.site.ru», «site.ru.», «www.site.ru.») безусловно перенаправляют на правильный адрес (т.е. на «site.ru»), и именно он идет «в народ» (в ссылках, аськах, и т.д.). Даже единообразия ради, про SEO уж умолчу.
Куда лучше ситуация, когда все «не те» варианты (т.е. все, отличные от «просто site.ru»: «www.site.ru», «site.ru.», «www.site.ru.») безусловно перенаправляют на правильный адрес (т.е. на «site.ru»), и именно он идет «в народ» (в ссылках, аськах, и т.д.). Даже единообразия ради, про SEO уж умолчу.
1. Как поможет решить проблему данная конструкция? Я прямо указал на то, что ни один запрос (с точкой или без) в указанный виртуальный сервер не попадет.
2. Что значит «не те» варианты? FQDN понимаете что такое? Вариант с точкой — это самый правильный и точный вариант адресации конкретного домена. Вариант без точки вообще может привести пользователя на другой сайт (злоумышленника, например).
И забудьте про SEO. Оно тут никаким боком.
2. Что значит «не те» варианты? FQDN понимаете что такое? Вариант с точкой — это самый правильный и точный вариант адресации конкретного домена. Вариант без точки вообще может привести пользователя на другой сайт (злоумышленника, например).
И забудьте про SEO. Оно тут никаким боком.
1. Проверил — попадает. Точнее, вариант с точкой попадает в тот же вирт. сервер, где настроен вариант без точки. Просто когда в него попадаем, есть варианты: просто отдавать юзеру контент сайта (т.е. браузер думает, что хостнейм другой, т.к. для него «с точкой» и «без» — это разные имена, а сайт отдается на них тот же), или сделать перенаправление (неважно, каким образом, но сделать именно «301» на какое-то одно имя — вероятно, все же, на вариант «без точки»). Я за второй вариант, как писал выше.
2. Мы вроде и боремся с этим? А как да другой сайт, если сервер ваш, на нем настроена «ловля» и того, и другого варианта, и DNS указывает на ваш сервер?
3. SEO мне и Вам не нужно особо, но Вы забываете, что у любого действия должна быть цель. Сферический веб-сервер в вакууме — штука академически полезная, но, если только это не лично для свои целей сервер, надо как-то и «о мире» подумать.
Я, ко всему, люблю считать, что у сайта есть одно имя, а остальные приводят на него — мне так кажется аккуратнее, и логичнее.
2. Мы вроде и боремся с этим? А как да другой сайт, если сервер ваш, на нем настроена «ловля» и того, и другого варианта, и DNS указывает на ваш сервер?
3. SEO мне и Вам не нужно особо, но Вы забываете, что у любого действия должна быть цель. Сферический веб-сервер в вакууме — штука академически полезная, но, если только это не лично для свои целей сервер, надо как-то и «о мире» подумать.
Я, ко всему, люблю считать, что у сайта есть одно имя, а остальные приводят на него — мне так кажется аккуратнее, и логичнее.
1. Перечитайте ещё раз комментарий, на который отвечаете. Я не понимаю с чем идет спор. Конструкция, которая предлагалась в статье на момент написания мной того комментария:
2. Домен без точки — это относительный адрес, и он может указывать куда угодно. Разница примерно такая же, как между:
3. Если вы за это боритесь, то делать редирект на домен с точкой — ваш единственный вариант.
server {
server_name domain.zone. ;
return 301 $http://domain.zone$request_uri;
}
2. Домен без точки — это относительный адрес, и он может указывать куда угодно. Разница примерно такая же, как между:
cd /data/web и cd data/web. Что покажет pwd после выполнения второй команды предсказать нельзя, это зависит от того, в какой вы директории находитесь. Какие бывают проблемы, читайте например RFC 1535 (хотя с тех пор не актуально, но представление дает).3. Если вы за это боритесь, то делать редирект на домен с точкой — ваш единственный вариант.
2. Для наглядной иллюстрации можете выполнить:
После этого yandex.ru и yandex.ru. у вас будут вести на разные сайты.
# echo -e "search vbart.ru\noptions ndots:5" >> /etc/resolv.conf
После этого yandex.ru и yandex.ru. у вас будут вести на разные сайты.
Facebook чот нифига не перенаправляет: ompldr.org/vaHJ6ag
На Dropbox с точкой в конце из хрома попасть вообще невозможно.
Судя по тому, что я вижу, у них таки настроен редирект.
Судя по тому, что я вижу, у них таки настроен редирект.
аналогично www.google.com.
Тут как раз все понятно, подставляя точку веб сервер не видит контекста с таким доменным именем и выкидывает запрос в default, а там реврайтом довешивается редирект. А не заходит потому, как сертификат выдан на конкретное доменное имя, а имя с точкой воспринимается как другое имя.
НЛО прилетело и опубликовало эту надпись здесь
А вот Ucoz на сайты с точкой пишет, что сайт не зарегистрирован.
По мне, так сайт (любой) должен иметь один-единственный адрес, а со всех остальных «похожих» адресов надо делать 301 Moved Permanently.
За себя скажу, что давным-давно привык для каждого сайта заводить 2 виртуальных сервера:
— один для адреса (возьмем для примера) site.ru, безо всяких алиасов, и
— второй, в котором перечислены все-все варианты неправильного указания адреса того же домена, плюс все домены-синонимы — и вся настройка этого виртуального сервера сводится к (для Апача) Redirect permanent / site.ru/.
В результате и волки оказываются сыты, и овцы целы — сайт открывается строго по одному адресу (ибо только он и прописан для этого вирт. хоста), а все-все варианты, как еще к сайту можно добраться, будут успешно перенаправлять на основной адрес.
Так вот в список именов хоста для второго вирт. сервера, естественно, добавляем и вариант написания с точкой на конце:
— вирт. хост 1: site.ru
— вирт. хост 2: www.site.ru, site.ru., www.site.ru.
За статью огромное «спасибо», тема мало где раскрывается, тем более применительно к вебу.
За себя скажу, что давным-давно привык для каждого сайта заводить 2 виртуальных сервера:
— один для адреса (возьмем для примера) site.ru, безо всяких алиасов, и
— второй, в котором перечислены все-все варианты неправильного указания адреса того же домена, плюс все домены-синонимы — и вся настройка этого виртуального сервера сводится к (для Апача) Redirect permanent / site.ru/.
В результате и волки оказываются сыты, и овцы целы — сайт открывается строго по одному адресу (ибо только он и прописан для этого вирт. хоста), а все-все варианты, как еще к сайту можно добраться, будут успешно перенаправлять на основной адрес.
Так вот в список именов хоста для второго вирт. сервера, естественно, добавляем и вариант написания с точкой на конце:
— вирт. хост 1: site.ru
— вирт. хост 2: www.site.ru, site.ru., www.site.ru.
За статью огромное «спасибо», тема мало где раскрывается, тем более применительно к вебу.
удалено
конструкция для апача реально работает, но только на сам домен, а вот если внутренние ссылки с точками в домене вызывать, то переадресации не происходит, правильнее будет написать, что то типа:
RewriteCond %{HTTP_HOST} !^domain\.zone$
RewriteRule ^(.*)$ domain.zone/$1 [L,R=301]
RewriteCond %{HTTP_HOST} !^domain\.zone$
RewriteRule ^(.*)$ domain.zone/$1 [L,R=301]
Проверил node.js require('url').parse(request.url).pathname, с точкой нормально работает.
RFC3986 (URI) описывает несколько видов нормализации URI при сравнении, но про «host» в нем говорится лишь то, что они должны сравниваться как строки, без учета регистра. в RFC2616 (HTTP/1.1) определение host отдается на откуп RFC2396 (который устарел и замен RFC3986) и там тоже ни какой отдельной нормализации для хостов не предполагается.
отсюда я делаю вывод, что хоть «server.com» и «server.com.» резолвятся в DNS одинаково, с точки зрения URI, это два разных хоста. тогда не понятно, почему в nginx считает их эквивалентными? видимо отсюда возникает часть этой путаницы:
согласен с выводом в статье, что в большинстве случаев для web-сайта будет хорошим тоном при запросе к «server.com.» откликаться 301 редиректом на «server.com», как и во всех остальных случаях с alias'ами. просто этот aiias достается задаром — его не надо отдельно регистрировать и париться за киберсвотеров. :)
отсюда я делаю вывод, что хоть «server.com» и «server.com.» резолвятся в DNS одинаково, с точки зрения URI, это два разных хоста. тогда не понятно, почему в nginx считает их эквивалентными? видимо отсюда возникает часть этой путаницы:
вы и не подозреваете, что ваш сайт доступен по доменному имени с точкой в конце (domain.zone.), так как браузеры позволяют обращаться к сайтам, как с точкой в конце домена, так и без неёс той лишь разницей, что неподозреваемая доступность сайта лежит на совести сервера, а не браузера.
согласен с выводом в статье, что в большинстве случаев для web-сайта будет хорошим тоном при запросе к «server.com.» откликаться 301 редиректом на «server.com», как и во всех остальных случаях с alias'ами. просто этот aiias достается задаром — его не надо отдельно регистрировать и париться за киберсвотеров. :)
Кто подскажет как проделать это через web.config?
Можно использовать модуль для IIS — URL Rewrite (http://www.iis.net/downloads/microsoft/url-rewrite).
Но мне тоже никак не удается настроить правило для точки.
Пытаюсь сделать так:
Правило стоит первым. Но оно не срабатывает и в итоге все равно получаем 404.
И проблема именно в точке, т.к. если изменить точку, к примеру, на запятую (^(.*),$), то работает.
Люди добрые, подскажите, как правильно настроить это правило.
Но мне тоже никак не удается настроить правило для точки.
Пытаюсь сделать так:
<rule name="point" stopProcessing="true">
<match url="^(.*)\.$" />
<action type="Redirect" url="{R:1}" redirectType="Temporary" />
</rule>Правило стоит первым. Но оно не срабатывает и в итоге все равно получаем 404.
И проблема именно в точке, т.к. если изменить точку, к примеру, на запятую (^(.*),$), то работает.
Люди добрые, подскажите, как правильно настроить это правило.
Нашла ответ здесь
Чтобы данное правило работало для MVC, необходимо в web.config добавить параметр:
Чтобы данное правило работало для MVC, необходимо в web.config добавить параметр:
<httpRuntime relaxedUrlToFileSystemMapping="true"/>Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Чем может грозить точка в конце доменного имени