Re: [proposal] SERVER_NAME в fastcgi_params
В письме от понедельник, 13 марта 2023 г. 13:16:25 MSK пользователь Maksim Kulik написал: > h1.example.com - это и есть имя сервера, остальное - алиасы. Как должен выглядеть конфиг, для случая который описан в RFC "A deployed server can have more than one possible value for this variable, where several HTTP virtual hosts share the same IP address" ? Соответсвует ли упомянутое вам имя сервера формулировке "name of the server host to which the client request is directed." ? > > пн, 13 мар. 2023 г. в 13:12, Nikolay Shaplov : > > > > В письме от понедельник, 13 марта 2023 г. 12:40:14 MSK пользователь Илья > > Шипицин написал: > > > > > > A deployed server can have more than one possible value for this > > > > variable, where several HTTP virtual hosts share the same IP address. > > > > In that case, the server would use the contents of the request's Host > > > > header field to select the correct virtual host. > > > > > > > > > > > > > > > > Мой вольный перевод "В случае если есть несколько кандидатов на > > > > заполнение > > > > > > переменной окружения SERVER_NAME, например несколько виртальных > > > > хостов > > > > использует один и тот же IP-адрес, серверу следует изучить содержимое > > > > заголовка Host пришедшего в http-запросе и использовать его значение > > > > для > > > > > > того > > > > чтобы выбрать корректный virtual host" > > > > > > > > > > > > все верно. но это про другое же речь. > > > в цитируемом фрагменте речь про то, что если у вас несколько > > > виртуальных > > > хостов, но выбрать правильный можно и нужно исходя из Host. > > > > > > > > > > > > но если по факту вы попали в дефолт, то выбор, описанный выше, вы уже > > > сделали. > > > > > > > > хорошо, давайте совсем на примерах. > > В конфиге написано: > > > > > > > > server_name h1.example.com h2.example.com h3.example.com; > > includefastcgi_params; > > fastcgi_pass unix:/var/run/my-fastcgi; > > > > > > > > Я браузером захожу на h2.example.com > > > > > > > > Что должно оказаться в SERVER_NAME для cgi-скрипта который будет отвечать > > на > > этот запрос? > > > > > > > > -- > > Nikolay Shaplov aka Nataraj > > Fuzzing Engineer at Postgres Professional > > Matrix IM: @dhyan:nataraj.su > > ___ > > nginx-ru mailing list > > nginx-ru@nginx.org > > https://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > -- Nikolay Shaplov aka Nataraj Fuzzing Engineer at Postgres Professional Matrix IM: @dhyan:nataraj.su signature.asc Description: This is a digitally signed message part. ___ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: [proposal] SERVER_NAME в fastcgi_params
В письме от понедельник, 13 марта 2023 г. 12:40:14 MSK пользователь Илья Шипицин написал: > > A deployed server can have more than one possible value for this > > variable, where several HTTP virtual hosts share the same IP address. > > In that case, the server would use the contents of the request's Host > > header field to select the correct virtual host. > > > > Мой вольный перевод "В случае если есть несколько кандидатов на заполнение > > переменной окружения SERVER_NAME, например несколько виртальных хостов > > использует один и тот же IP-адрес, серверу следует изучить содержимое > > заголовка Host пришедшего в http-запросе и использовать его значение для > > того > > чтобы выбрать корректный virtual host" > > все верно. но это про другое же речь. > в цитируемом фрагменте речь про то, что если у вас несколько виртуальных > хостов, но выбрать правильный можно и нужно исходя из Host. > > но если по факту вы попали в дефолт, то выбор, описанный выше, вы уже > сделали. хорошо, давайте совсем на примерах. В конфиге написано: server_name h1.example.com h2.example.com h3.example.com; includefastcgi_params; fastcgi_pass unix:/var/run/my-fastcgi; Я браузером захожу на h2.example.com Что должно оказаться в SERVER_NAME для cgi-скрипта который будет отвечать на этот запрос? -- Nikolay Shaplov aka Nataraj Fuzzing Engineer at Postgres Professional Matrix IM: @dhyan:nataraj.su signature.asc Description: This is a digitally signed message part. ___ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: [proposal] SERVER_NAME в fastcgi_params
В письме от понедельник, 13 марта 2023 г. 10:57:09 MSK пользователь Maksim Kulik написал: > А где написано, что сервер ДОЛЖЕН его ИСПОЛЬЗОВАТЬ дальше? Он должен > использовать это имя для ВЫБОРА виртуал-хоста. Насколько я вижу, в RFC не > описано дальнейшее поведение сервера при наличии более одного SERVER_NAME в > виртуал-хосте. Цитирую: A deployed server can have more than one possible value for this variable, where several HTTP virtual hosts share the same IP address. In that case, the server would use the contents of the request's Host header field to select the correct virtual host. Мой вольный перевод "В случае если есть несколько кандидатов на заполнение переменной окружения SERVER_NAME, например несколько виртальных хостов использует один и тот же IP-адрес, серверу следует изучить содержимое заголовка Host пришедшего в http-запросе и использовать его значение для того чтобы выбрать корректный virtual host" > > пн, 13 мар. 2023 г. в 10:50, Nikolay Shaplov : > > > > > > > > Правильно. И то имя которое совпало должно попасть в переменную окружения > > SERVER_NAME > > > > > > > > Ну даже если не читать сам текст RFC (а там по-моему предельно ясно все > > написано), из соображений общий логики, почему в SERVER_NAME попадает > > первый > > из алиасов, а не тот на который пришли??? В этом нет вообще никакой > > логики. > > > > > > > > > > > -- > > Nikolay Shaplov aka Nataraj > > Fuzzing Engineer at Postgres Professional > > Matrix IM: @dhyan:nataraj.su > > > > -- Nikolay Shaplov aka Nataraj Fuzzing Engineer at Postgres Professional Matrix IM: @dhyan:nataraj.su signature.asc Description: This is a digitally signed message part. ___ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: [proposal] SERVER_NAME в fastcgi_params
В письме от понедельник, 13 марта 2023 г. 10:46:51 MSK пользователь Maksim
Kulik написал:
> Мне кажется, что в RFC речь идет скорее про разные блоки server {}, т.к.
> речь явно про several virtual hosts, а не про several server names. То есть
> веб-сервер вполне корректно по RFC выбирает блок server {} по имени хоста и
> используется главное имя этого блока далее в работе.
> Вы в своем примере имеете один виртуал хост и N имен (алиасов, если хотите)
> в нем, где N может быть бесконечным в случае дефолтного хоста. Ваш сервер и
> выбирает этот самый хост по имени, которое видит в заголовке.
Правильно. И то имя которое совпало должно попасть в переменную окружения
SERVER_NAME
Ну даже если не читать сам текст RFC (а там по-моему предельно ясно все
написано), из соображений общий логики, почему в SERVER_NAME попадает первый
из алиасов, а не тот на который пришли??? В этом нет вообще никакой логики.
>
> пн, 13 мар. 2023 г. в 10:33, Nikolay Shaplov :
>
>
> >
> >
> >A deployed server can have more than one possible value for this
> >variable, where several HTTP virtual hosts share the same IP address.
> >In that case, the server would use the contents of the request's Host
> >header field to select the correct virtual host.
> >
> >
> >
> > Но как? Английским по белому написано ", the server would use the
> > contents
> > of the request's Host header field to select the correct virtual host"
> >
> >
> >
> >
> > --
> > Nikolay Shaplov aka Nataraj
> > Fuzzing Engineer at Postgres Professional
> > Matrix IM: @dhyan:nataraj.su
> > _______
> > nginx-ru mailing list
> > nginx-ru@nginx.org
> > https://mailman.nginx.org/mailman/listinfo/nginx-ru
> >
> >
--
Nikolay Shaplov aka Nataraj
Fuzzing Engineer at Postgres Professional
Matrix IM: @dhyan:nataraj.su
signature.asc
Description: This is a digitally signed message part.
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: [proposal] SERVER_NAME в fastcgi_params
В письме от понедельник, 13 марта 2023 г. 10:27:10 MSK пользователь Maxim
Dounin написал:
> Hello!
>
> On Mon, Mar 13, 2023 at 09:20:49AM +0300, Nikolay Shaplov wrote:
> > В письме от понедельник, 13 марта 2023 г. 09:17:17 MSK пользователь Dmitry
> >
> > Ivanov написал:
> > > Вы писали 5 марта 2023 г., 18:41:17:
> > > > При этом в самом конфиге сайта server_name не указан, сервер
> > > > обслуживает
> > > > все доменные имена (фильтрация по имени осуществляется на фронтэнде).
> > >
> > > Видимо, надо потыкать в RFC разработчиков фронта и забыть о "проблеме"
> >
> > Не достаточно. Если перечислить все обслуживаемые доменные имена в
> > server_name, то в SERVER_NAME при подключении дефолтного fastcgi_params
> > попадает первое из них, а не то, на которое пришли. Что явно противоречит
> > RFC. Я вроде об этом уже писал выше по треду.
>
> Не противоречит, на бэкенд отправляется каноническое имя
> виртуального сервера.
A deployed server can have more than one possible value for this
variable, where several HTTP virtual hosts share the same IP address.
In that case, the server would use the contents of the request's Host
header field to select the correct virtual host.
Но как? Английским по белому написано ", the server would use the contents
of the request's Host header field to select the correct virtual host"
> Хотите, чтобы было по другому -
> сконфигурируйте по другому и/или явно опишите виртуальные сервера,
> в разных блоках server{}.
>
> Подробнее про текущее поведение я писал тут:
>
> https://mailman.nginx.org/pipermail/nginx-ru/2023-March/USR4N4KMUMDT2KKUV4J5
> RJVBOZTSNCFF.html
>
> Если остались какие-то вопросы - спрашивайте.
--
Nikolay Shaplov aka Nataraj
Fuzzing Engineer at Postgres Professional
Matrix IM: @dhyan:nataraj.su
signature.asc
Description: This is a digitally signed message part.
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: [proposal] SERVER_NAME в fastcgi_params
В письме от понедельник, 13 марта 2023 г. 09:17:17 MSK пользователь Dmitry Ivanov написал: > Вы писали 5 марта 2023 г., 18:41:17: > > При этом в самом конфиге сайта server_name не указан, сервер обслуживает > > все доменные имена (фильтрация по имени осуществляется на фронтэнде). > > Видимо, надо потыкать в RFC разработчиков фронта и забыть о "проблеме" Не достаточно. Если перечислить все обслуживаемые доменные имена в server_name, то в SERVER_NAME при подключении дефолтного fastcgi_params попадает первое из них, а не то, на которое пришли. Что явно противоречит RFC. Я вроде об этом уже писал выше по треду. -- Nikolay Shaplov aka Nataraj Fuzzing Engineer at Postgres Professional Matrix IM: @dhyan:nataraj.su signature.asc Description: This is a digitally signed message part. ___ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: [proposal] SERVER_NAME в fastcgi_params
В письме от понедельник, 6 марта 2023 г. 23:00:22 MSK пользователь Илья Шипицин написал: > > +1 > > > > Мой мысленный эксперимент показал что ничего ни у кого не сломается. См. в > > более ранних письмах. > > ну допустим, у кого-то далее по цепочке стоит nginx, который логирует в > access_log параметр server_name от апстрима. > и там всегда был прочерк. и на это значение завязались аналитики. Так вот, значение переменной $server_name никто менять не предлагает. Предлагается в дефолтном конфиге fastcgi_params (и его клонах) изменить значение переменной окружения SERVER_NAME, передаваемой в cgi-скрипт c $server_name на $host. Таким образом будет соблюдена буква RFC, которая в текущей момент не соблюдается. Приведенный вами пример с аналитикой, будет работать так же как и раньше > ситуация нелепая, но зачем же таким людям делать хорошо против их воли Ну вот на одной чаши весов нелепая ситуация, а на другой соблюдение RFC. При этом несоблюдение этого RFC ведет к потенциальным проблемам и потерям времени (я тому пример) -- Nikolay Shaplov aka Nataraj Fuzzing Engineer at Postgres Professional Matrix IM: @dhyan:nataraj.su signature.asc Description: This is a digitally signed message part. ___ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: [proposal] SERVER_NAME в fastcgi_params
В письме от понедельник, 6 марта 2023 г. 21:51:17 MSK пользователь Evgeniy Berdnikov написал: > On Mon, Mar 06, 2023 at 07:40:49PM +0100, Илья Шипицин wrote: > >а есть непустое множество тех, кто уже пользуется, и вы поменяете им > >поведение после апгрейда. > > Неужели? И как же оно поменяется? > Поставим лучше вопрос так: что у них сломается и почему? +1 Мой мысленный эксперимент показал что ничего ни у кого не сломается. См. в более ранних письмах. -- Nikolay Shaplov aka Nataraj Fuzzing Engineer at Postgres Professional Matrix IM: @dhyan:nataraj.su signature.asc Description: This is a digitally signed message part. ___ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: [proposal] SERVER_NAME в fastcgi_params
В письме от понедельник, 6 марта 2023 г. 21:34:15 MSK пользователь Илья Шипицин написал: > > Товарищ, наверное, хотел сказать, что составитель дефолтной конфигурации > > не заметил некоторые проблемы, с которыми могут столнуться пользователи. > > И что если вместо $server_name написать $host, то вероятность > > > > возникновения > > > > этих проблем будет несколько ниже. С чем трудно не согласиться. > > > > Как всегда, ждём, какие аргументы придумают авторы, чтобы ничего не > > > > менять. :) > > а непонятно, есть ли вообще такая проблема "у других пользователей". > ну гипотетически, в чем польза от смены дефолта ? > > у кого-то резко починится ? а ему оно надо )) ? Кто-то сэкономит рабочий день потраченный на поиск "почему при переходе на nginx не работает" -- Nikolay Shaplov aka Nataraj Fuzzing Engineer at Postgres Professional Matrix IM: @dhyan:nataraj.su signature.asc Description: This is a digitally signed message part. ___ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: [proposal] SERVER_NAME в fastcgi_params
В письме от понедельник, 6 марта 2023 г. 13:59:30 MSK пользователь Andrey
Kopeyko написал:
> Если вы зададите для этого сервера несуществующее имя ("_" как рекомендует
> документация, или "fakehost.fakedomain") - переменная SERVER_NAME волшебным
> образом появится.
Проверил на практике:
server_name _;
В $server_name и как следствие в SERVER_NAME попадает "_"; Скрипт не работает
server_name fakehost.fakedomain;
В $server_name и как следствие в SERVER_NAME попадает "fakehost.fakedomain";
Скрипт не работает
Если явно указать все возможные домены
server_name lists.nataraj.su lists.sim-im.org;
то в $server_name и в SERVER_NAME попадает "lists.nataraj.su", вне зависимости
от того на который домен я захожу. Т.е. на lists.sim-im.org отдают контент
который должен отдаваться на lists.nataraj.su.
Это прямо противоречит букве RFC:
A deployed server can have more than one possible value for this
variable, where several HTTP virtual hosts share the same IP address.
In that case, the server would use the contents of the request's Host
header field to select the correct virtual host.
--
Nikolay Shaplov aka Nataraj
Fuzzing Engineer at Postgres Professional
Matrix IM: @dhyan:nataraj.su
signature.asc
Description: This is a digitally signed message part.
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: [proposal] SERVER_NAME в fastcgi_params
В письме от понедельник, 6 марта 2023 г. 13:59:30 MSK пользователь Andrey
Kopeyko написал:
> к "нарушению RFC" приводит ваша конкретная конфигурация - когда вы
> обрабатываете множество имён в дефолтном сервере, для которого вы _не
> задаёте_ server_name.
>
> Вот корень всех бед.
>
> И именно поэтому дефолтное поведение менять не следует.
Я бы с этим всем согласился, приняв на веру, если бы в RFC не было бы
написано:
The SERVER_NAME variable MUST be set to the name of the server host
to which the client request is directed.
...
... where several HTTP virtual hosts share the same IP address.
In that case, the server would use the contents of the request's Host
header field to select the correct virtual host.
MUST как-то обязывает к тому чтобы оно либо было установлено, либо вообще
отказывалось работать, со страшной руганью, на мой вкус...
> Если вы зададите для этого сервера несуществующее имя ("_" как рекомендует
> документация, или "fakehost.fakedomain") - переменная SERVER_NAME волшебным
> образом появится.
>
> P.S.
> Будете в офисе - подходите, обсудим подробнее (ибо голосом будет удобнее).
Буду в городе в начале след. недели. Обсудим, да...
--
Nikolay Shaplov aka Nataraj
Fuzzing Engineer at Postgres Professional
Matrix IM: @dhyan:nataraj.su
signature.asc
Description: This is a digitally signed message part.
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: [proposal] SERVER_NAME в fastcgi_params
В письме от воскресенье, 5 марта 2023 г. 22:04:35 MSK пользователь Илья Шипицин написал: > > Но не следует ли заменить $server_name на $host в конфигах *cgi_params в > > дистрибутиве nginx? Я в первую очередь с этой мыслью сюда пришел... > но, с другой стороны, существующие механизмы позволяют вам использовать > $host и не зависеть от дефолтных конфигов, верно ? Я в данном вопросе беспокоюсь скорее за других, чем за себя. Я в свое время убил очень много времени, пока траблшутил проблему вызванную отсутствием корректного значения в SERVER_NAME, и в таких случаях обычно стараюсь сделать так, чтобы никому после меня не пришлось бы снова ходть по проделанному мной пути. Изменение дефолта в конфигах *cgi_params, решит эту задачу лучше всего > боюсь, что изменение дефолтного поведения обычно не приветствуется. В данном случае я бы сказал что это изменение более чем оправдано. 1. Нынешнее положение дел приводит к нарушению RFC. Исправление приведет к соблюдению RFC "из коробки". Соблюдать RFC -- не только хорошо, но и очень важно. 2. Существующие конфигурации, по моему представлению не будут затронуты этим изменением. Я вижу следующие варианты: 2.1. Либо в конфиге указан srever_name и $host будет возвращать то же значение что и $server_name 2.2. Значение переменной окружения SERVER_NAME перезаписывается после применения дефолтов. Новый дефолт не повлияет на поведение, так как будет перезаписан 2.3. cgi-скрипт вообще игнорирует переменную окружения SERVER_NAME. И изменения дефолта не страшно. То есть для существующих инсталляций поведение никак не изменится. Зато очень сильно упроститься создание новых инсталляций, для случаев, подобных моему. P.S. Мне очень повезло что я настраивал CGI-скрипт написанный на языке который я хорошо знаю, и у меня была возможность пройтись по всей глубине его выполнения и обнаружить причину проблемы. В случае, если настраивающий этот скрипт админ не владел бы языком программирования на котором написан скрипт, задача настройки могла оказаться вообще в принципе не решаемой... Совершенно не очевидное поведение было в отсутствии значения SERVER_NAME. Этот воображаемый админ с большой вероятностью (и не без оснований) обвинил бы во все nginx, ведь под apache все работает из коробки. Вот и я бы хотел чтобы и под nginx оно тоже работало бы из коробки, я патриот nginx ;-). Я все стараюсь поднимать на нем, по мере сил и возможностей. -- Nikolay Shaplov aka Nataraj Fuzzing Engineer at Postgres Professional Matrix IM: @dhyan:nataraj.su signature.asc Description: This is a digitally signed message part. ___ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: [proposal] SERVER_NAME в fastcgi_params
В письме от воскресенье, 5 марта 2023 г. 18:49:10 MSK пользователь Evgeniy Berdnikov написал: > > > Скрипту, тем ни менее нужно знать доменное имя которое он сейчас > > обслуживает, и он смотрит на переменную окружения SERVER_NAME. > > > > А в этой переменной пусто. > > Подумайте об использовании переменной $host. Выглядит как хороший вариант, лучше чем $http_host. Это спасибо. Но не следует ли заменить $server_name на $host в конфигах *cgi_params в дистрибутиве nginx? Я в первую очередь с этой мыслью сюда пришел... -- Nikolay Shaplov aka Nataraj Fuzzing Engineer at Postgres Professional Matrix IM: @dhyan:nataraj.su signature.asc Description: This is a digitally signed message part. ___ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru
[proposal] SERVER_NAME в fastcgi_params
Приветствую! Разбираясь с cgi-скриптом обслуживающим многочисленные доменные имена столкнулся со следующей проблемой: В /etc/nginx/fastcgi_params написано fastcgi_param SERVER_NAME$server_name; При этом в самом конфиге сайта server_name не указан, сервер обслуживает все доменные имена (фильтрация по имени осуществляется на фронтэнде). Скрипту, тем ни менее нужно знать доменное имя которое он сейчас обслуживает, и он смотрит на переменную окружения SERVER_NAME. А в этой переменной пусто. Потому что в $server_name тоже пусто. Я подозреваю что это как-то завязано на пустой server_name в конфиге. RFC же требует чтобы SERVER_NAME был корректно установлен всегда: https://tools.ietf.org/html/rfc3875#section-4.1.14 Я локально решил эту проблему использовав $http_host в качестве источника доменного имени. На практике он определен всегда (хотя в теории может быть только для http >= 1.1 это я не проверял): fastcgi_param SERVER_NAME$http_host; Но это некоторые полумеры которые не решают проблему глобально... Надо либо починить $server_name чтобы он был установлен всегда, либо использовать $http_host для задания переменной окружения SERVER_NAME, либо какая-то более сложная комбинация. Если авторы заинтересованы в решении этой проблемы, я могу провести дополнительные исследования, подготовить тестовые примеры демонстрирующиее это поведение и т.п. (В исходный код nignx наверное глубоко лезть не готов, хотя квалификация позволяет, не знаком я с ним совсем). Если авторы не заинтересованы... Значит придется везде в инструкциях тащить за собой эту уродливую конструкцию с $http_host... -- Nikolay Shaplov aka Nataraj Fuzzing Engineer at Postgres Professional Matrix IM: @dhyan:nataraj.su signature.asc Description: This is a digitally signed message part. ___ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru
