Комментарии 50
есть мысль обойтись одной регуляркой и ифом. Как бы задать такое условие?
if ($host ~* "^(не www)\.example\.com$") {
rewrite…
}
if ($host ~* "^(не www)\.example\.com$") {
rewrite…
}
0
тоже о таком думал, но не смог составить простую регулярку, которая бы это делала.
Поэтому остановился на таком костыле, который позволяет обойти ограничение, что нельзя использовать логический оператор «и» и вложенные if в nginx
Поэтому остановился на таком костыле, который позволяет обойти ограничение, что нельзя использовать логический оператор «и» и вложенные if в nginx
0
Логику вложенных if можно сделать установкой переменных.
if условие {
set a «a»;
}
if условие2 {
set $aa «a»;
}
if $a==«aa» {
и т. д.
}
if условие {
set a «a»;
}
if условие2 {
set $aa «a»;
}
if $a==«aa» {
и т. д.
}
0
if ($host ~* "([a-z0-9\-]+)(?<!^www)\.example\.com$") { rewrite }
+1
Спасибо, добавил в израбнное на будущее.
0
Спасибо, сейчас стоит такая задача — подыскиваю наиболее подходящий вариант решения.
0
Это же достаточно элементарно. А вот про минусы не понял :/, вы раньше апачем напрямую всё отдавали?
0
Еще надо учесть, что нижнее подчеркивание нельзя использовать в поддоменах.
Еще одна статья в тему
Пользовательские поддомены
Еще одна статья в тему
Пользовательские поддомены
+3
собственно, мое решение основано на этой статье, только там не решена проблема с www — там делается редирект, а я предложил способ, как сохранить работоспособность www
Про нижнее подчеркивание — исправил регулярку в статье
Про нижнее подчеркивание — исправил регулярку в статье
0
можете аргументированно пояснить, почему нельзя?
0
Ответ из старого топика из обсуждений
«Интересные имена со знаком „_“ :) Особенно в поддоменах. IE не берет с такого домена куки, а опера ругается, что введенный урл не соответствет стандартам (потому что не соответствует) и не грузит страницу совсем. „
Сейчас попробовал набрать
www_123.ya.ru/
www-123.ya.ru/
По первому адресу 400 Bad Request
По второму — 404
«Интересные имена со знаком „_“ :) Особенно в поддоменах. IE не берет с такого домена куки, а опера ругается, что введенный урл не соответствет стандартам (потому что не соответствует) и не грузит страницу совсем. „
Сейчас попробовал набрать
www_123.ya.ru/
www-123.ya.ru/
По первому адресу 400 Bad Request
По второму — 404
0
С яндексом пример некорректен. Что касается утверждения выше, то видно, что вы самостоятельно его не проверяли.
Есть много работающих ресуров, где с указанными браузерами описанных проблем не наблюдается. Например, модуль субдоменов для движка Livestreet установлен на множестве сайтов, ни от кого не поступало таких жалоб да и тестирование также не выявило никаких проблем кроме эпизода с написанием доменов в разных регистрах (сафари).
Я не знаю, о каких «стандартах» говорил тот хабраюзер, но если открыть RFC1738 (Uniform Resource Locators), то можно прочесть следующее:
Вы можете указать, какой конкретно стандарт запрещает использовать символ "_" для субдоменов?
Есть много работающих ресуров, где с указанными браузерами описанных проблем не наблюдается. Например, модуль субдоменов для движка Livestreet установлен на множестве сайтов, ни от кого не поступало таких жалоб да и тестирование также не выявило никаких проблем кроме эпизода с написанием доменов в разных регистрах (сафари).
Я не знаю, о каких «стандартах» говорил тот хабраюзер, но если открыть RFC1738 (Uniform Resource Locators), то можно прочесть следующее:
Thus, only alphanumerics, the special characters "$-_.+!*'(),", and
reserved characters used for their reserved purposes may be used
unencoded within a URL.
Вы можете указать, какой конкретно стандарт запрещает использовать символ "_" для субдоменов?
0
Не путайте URL и Domain Names. В URL "_" допустим, в доменном имени — нет. Конкретно стандарт RFC1035, цитирую:
2.3.1. Preferred name syntax
<domain> ::= <subdomain> | " "
<subdomain> ::= <label> | <subdomain> "." <label>
<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
<let-dig-hyp> ::= <let-dig> | "-"
<let-dig> ::= <letter> | <digit>
<letter> ::= any one of the 52 alphabetic characters A through Z in upper case and a through z in lower case
<digit> ::= any one of the ten digits 0 through 9
…
The labels must follow the rules for ARPANET host names. They must
start with a letter, end with a letter or digit, and have as interior
characters only letters, digits, and hyphen. There are also some
restrictions on the length. Labels must be 63 characters or less.
0
2.3.1. Preferred name syntax
Я не увидел здесь прямого запрета, а вы? Предпочтительный синтаксис не означает строгого следования этим правилам. С документом ошибся, вы правы.
-1
Ок, есть еще RFC1123 «Requirements for Internet Hosts». Читаем:
Достаточно или еще гуглом для вас поработать? ;)
Все эти стандарты в некотором смысле рекомендательные, т.е. нет службы полицаев, которые посадят или оштрафуют за то, что вы им не следуете. Так что всегда находятся люди, которые вертели на стержне все эти RFC и рекомендации как делать предпочтительно, им пофиг, у них своё видение как всё должно работать. Слава богу их меньшинство, иначе интернета могло бы и вовсе не быть в том виде, в котором мы его знаем, а были бы кучки разрозненных анклавов.
2.1 Host Names and NumbersОткрываем RFC-952:
The syntax of a legal Internet host name was specified in RFC-952 [DNS:4].
ASSUMPTIONS
1. A «name» (Net, Host, Gateway, or Domain name) is a text string up
to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus
sign (-), and period (.). Note that periods are only allowed when
they serve to delimit components of «domain style names». (See
RFC-921, «Domain Name System Implementation Schedule», for
background). No blank or space characters are permitted as part of a
name. No distinction is made between upper and lower case. The first
character must be an alpha character. The last character must not be
a minus sign or period.
Достаточно или еще гуглом для вас поработать? ;)
Все эти стандарты в некотором смысле рекомендательные, т.е. нет службы полицаев, которые посадят или оштрафуют за то, что вы им не следуете. Так что всегда находятся люди, которые вертели на стержне все эти RFC и рекомендации как делать предпочтительно, им пофиг, у них своё видение как всё должно работать. Слава богу их меньшинство, иначе интернета могло бы и вовсе не быть в том виде, в котором мы его знаем, а были бы кучки разрозненных анклавов.
0
Спасибо за потраченное время, но документы 1985 года в наши дни выглядят несколько архаично. Не исключено даже, что есть какие-то более новые документы, регулириующие эти вопросы. Я попробую вечером их найти.
Исходя из ваших слов, их на стержне вертит даже ICANN, что доказывает вот этот домен, который серьёзно превышает лимит в 24 символа: thelongestlistofthelongeststuffatthelongestdomainnameatlonglast.com
Исходя из ваших слов, их на стержне вертит даже ICANN, что доказывает вот этот домен, который серьёзно превышает лимит в 24 символа: thelongestlistofthelongeststuffatthelongestdomainnameatlonglast.com
0
В том же RFC1035 указано не 24 символа для имени а 63 для сегмента (label), т.е. этот лимит расширили. Это прям в моем предыдущем комментарии написано. Так что ICANN никого не вертит.
0
Сегменты с вхождением "_" обнаружить нетрудно:
Получается, вертят крупнейшие игроки IT? Да, это не записи типа A, но всё же полноправные labels.
$ dig beta._domainkey.google.com TXT
$ dig beta._domainkey.google.com TXT
$ dig beta._domainkey.google.com TXT
$ dig _spf-a.microsoft.com TXT
$ dig _domainkey.cern.ch TXT
Получается, вертят крупнейшие игроки IT? Да, это не записи типа A, но всё же полноправные labels.
0
$ dig _domainkey.ebay.com TXT
$ dig _domainkey.yahoo.com TXT
$ dig _domainkey.yandex.ru TXT
$ dig _domainkey.yahoo.com TXT
$ dig _domainkey.yandex.ru TXT
0
Вот и стандарт от 2000 года нашёлся, который это дело разрешает: www.ietf.org/rfc/rfc2782.txt
0
Я не конца понял о чем этот стандарт, но судя по смыслу в нем предлагается использовать _ для специальных целей, что скорее даже подчеркивает тот факт, что _ нельзя использовать просто так от балды. Тут как бы сразу два нарушения — сам факт использования подчерка и расположение его на первом месте, где может быть только буква или цифра. Т.е. с таким же успехом они могли взять $, который тоже не разрешен в именах доменов или % и это бы не означало, что его теперь можно использовать где угодно.
Мутная тема ;)
Мутная тема ;)
0
Я привёл это в качестве развенчания мифа, что "_" нельзя использовать в сегментах (узлах) DNS. Как видно, он широко используется в Sender Policy Framework.
0
В общем мне очень понравилась наша с вами дискуссия, весьма конструктивная я считаю. Можно немного подытожить:
1. Нифига не понятно :)
2. Есть рекомендации по синтаксису доменных имен, в них "_" не рекомендован, во избежание проблем с клиентским софтом (так сказано в RFC1035)
3. Есть старые документы, прямо запрещающие использование "_" в именах хостов, доментов и т.п.
4. Есть более новые документы, разрешающие "_" в строго определенной позиции(первым символом) и в специальных DNS-записях, т.е. это алиасы на сервисы.
5. Есть чисто прикладные проблемы связанные в "_". Насколько я помню, squid, например, возможно не во всех версиях, попросту не пропускает через себя клиентов с запросами на такие домены. Админы на работе с этим сталкивались, это реальный случай.
Итого, не знаю как вы, но я сделал вывод, что все таки "_" лучше не использовать, и кстати я не вижу никаких проблем, чем дефис хуже подчерка, непонятно.
Спасибо вам за интересную беседу ;)
1. Нифига не понятно :)
2. Есть рекомендации по синтаксису доменных имен, в них "_" не рекомендован, во избежание проблем с клиентским софтом (так сказано в RFC1035)
3. Есть старые документы, прямо запрещающие использование "_" в именах хостов, доментов и т.п.
4. Есть более новые документы, разрешающие "_" в строго определенной позиции(первым символом) и в специальных DNS-записях, т.е. это алиасы на сервисы.
5. Есть чисто прикладные проблемы связанные в "_". Насколько я помню, squid, например, возможно не во всех версиях, попросту не пропускает через себя клиентов с запросами на такие домены. Админы на работе с этим сталкивались, это реальный случай.
Итого, не знаю как вы, но я сделал вывод, что все таки "_" лучше не использовать, и кстати я не вижу никаких проблем, чем дефис хуже подчерка, непонятно.
Спасибо вам за интересную беседу ;)
+1
К тому же есть практическая сторона. Rucenter не позволит вам зарегистриовать доменное имя с "_" и если попробуете проверить такое доменное имя на свободность, выдаст ошибку:
Название домена должно состоять более чем из одного символа, начинаться и заканчиваться буквой латинского алфавита или цифрой. Промежуточными символами могут быть буквы латинского алфавита, цифры или дефис.Т.е. для регистратора это правило очевидно (если знаете какого нибудь регистратора, который позволяет — напишите). Понятное дело, что домен второго уровня ничем принципиально от третьего (четвертого, пятого...) не отличается и правила должны быть едиными.
0
Мы сейчас говорим о субдоменах, то есть о сегментах четвёртого уровня в иерархии DNS. Контролируя домен второго уровня, вы можете создать произвольный субдомен без участия регистратора.
0
Регистрацию доменов в зоне .ru регулирует регламент, который запрещает всё, кроме a-z,0-9,-
Регалмент может быть основан на стандартах, но он никоим образом не может диктовать владельцу домена, какие ему создавать и поддерживать субдомены.
Регалмент может быть основан на стандартах, но он никоим образом не может диктовать владельцу домена, какие ему создавать и поддерживать субдомены.
0
ISPmanager нормально работает с nginx и без там это делается в 2 клика:
Выбираем нужный домен — добавить запись-
Имя: *
Тип: A
Адрес: Ip адрес сайта
На мастерхосте в админке помнится тоже делалось аналогично, создавался поддомен *.example.com, указывающий на основную папку домена.
Остальное — работа самой CMS, правила в .htaccess.
И будет хоть username.example.com, хоть username.users.example.com, хоть super-article.news.example.com
Выбираем нужный домен — добавить запись-
Имя: *
Тип: A
Адрес: Ip адрес сайта
На мастерхосте в админке помнится тоже делалось аналогично, создавался поддомен *.example.com, указывающий на основную папку домена.
Остальное — работа самой CMS, правила в .htaccess.
И будет хоть username.example.com, хоть username.users.example.com, хоть super-article.news.example.com
-1
как раз правила в .htaccess это самое интересное, dns прописать дело 2 минут
0
Смотря как CMS сделана, и для чего требуются динамические поддомены. .htaccess и тот не всегда будет нужен — можно обойтись и вообще без его изменения. Только с CMS немного повозиться, что бы ссылки автоматом заменяла и соображала что показывать на главной странице поддомена, когда больше никаких параметров в url не задано.
0
НЛО прилетело и опубликовало эту надпись здесь
Ну я имею в виду что добавление A записи *.example.com — дело 2 минут, а вот наладить сервер чтобы работали все рерайты как надо для поддоменов — уже сложнее (особенно если надо не просто рерайтить поддомен в папку а для поддомена сделать чтобы были работоспособны все человеко-понятные адреса страниц, которые уже есть на сайте, т.е. сделать рерайт вида username.example.com => example.com/users/username => example.com/users.php?page=about&name=username)
Мое решение позволило мне вынести на поддомен довольно большое количетсво страниц (страница с контактами, анкета, еще несколько), приэтом не переписывая заново все рерайты в .htaccess а просто добавив несколько строк в конфиг nginx
Мое решение позволило мне вынести на поддомен довольно большое количетсво страниц (страница с контактами, анкета, еще несколько), приэтом не переписывая заново все рерайты в .htaccess а просто добавив несколько строк в конфиг nginx
0
Дописали, бы в статье своей что нужно еще сделать для того чтоб username.example.com работал без указания всех возможных доменов в конфиге веб-сервера.
0
Статья как делать НЕ НАДО — if,rewrite это зло.
Правильное решение:
Правильное решение:
server { server_name www.example.com; location / { proxy_pass 11.22.33.44:8080; } } server { server_name ~^(?<user>[a-z0-9\-]+)\.example.com$; location / { proxy_pass 11.22.33.44:8080/users/$user$uri$is_args$args; } }
+11
А вас не беспокоит, что, к примеру, у вас остаются рабочими обе ссылки:
example.com/user
и
user.example.com/
И для них URL для ссылок, стилей и скриптов могут указывать на разные файлы.
<a href="/contacts.html">контакты</a> — /var/www/contacts.html | /var/www/example.com/user/contacts.html
example.com/user
и
user.example.com/
И для них URL для ссылок, стилей и скриптов могут указывать на разные файлы.
<a href="/contacts.html">контакты</a> — /var/www/contacts.html | /var/www/example.com/user/contacts.html
+1
Не беспокоит, у меня настроен permanent redirect с example.com/user на user.example.com/
Дело в том, что у на нашем сайте выносить свой аккаунт на поддомен могут только платные пользователи, поэтому бесплатным доступен адрес example.com/user, а платные могут выбрать себе урл и получить адрес user.example.com/ с перманентным редиректом со старого адреса, чтобы сохранить все страницы в поиске.
Ссылки не волнуют, они генерируются автоматически, и являются не относительными, а абсолютными.
Дело в том, что у на нашем сайте выносить свой аккаунт на поддомен могут только платные пользователи, поэтому бесплатным доступен адрес example.com/user, а платные могут выбрать себе урл и получить адрес user.example.com/ с перманентным редиректом со старого адреса, чтобы сохранить все страницы в поиске.
Ссылки не волнуют, они генерируются автоматически, и являются не относительными, а абсолютными.
0
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Динамические поддомены с использованием nginx+apache