From dhyan на nataraj.su Sun Mar 5 15:41:17 2023 From: dhyan на nataraj.su (Nikolay Shaplov) Date: Sun, 05 Mar 2023 18:41:17 +0300 Subject: [proposal] SERVER_NAME =?UTF-8?B?0LI=?= fastcgi_params Message-ID: <2248451.uKp60E1Vhr@thinkpad-pgpro> Приветствую! Разбираясь с 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 Тип: application/pgp-signature Размер: 488 байтов Описание: This is a digitally signed message part. URL: From bgx на protva.ru Sun Mar 5 15:49:10 2023 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Sun, 5 Mar 2023 18:49:10 +0300 Subject: [proposal] SERVER_NAME =?utf-8?B?0LIg?= =?utf-8?Q?fastcgi=5Fparams?= In-Reply-To: <2248451.uKp60E1Vhr@thinkpad-pgpro> References: <2248451.uKp60E1Vhr@thinkpad-pgpro> Message-ID: Добрый день. On Sun, Mar 05, 2023 at 06:41:17PM +0300, Nikolay Shaplov wrote: > Разбираясь с cgi-скриптом обслуживающим многочисленные доменные имена > столкнулся со следующей проблемой: > > В /etc/nginx/fastcgi_params написано > > fastcgi_param SERVER_NAME $server_name; [...] > Скрипту, тем ни менее нужно знать доменное имя которое он сейчас обслуживает, > и он смотрит на переменную окружения SERVER_NAME. > > А в этой переменной пусто. Подумайте об использовании переменной $host. -- Eugene Berdnikov From dhyan на nataraj.su Sun Mar 5 15:59:24 2023 From: dhyan на nataraj.su (Nikolay Shaplov) Date: Sun, 05 Mar 2023 18:59:24 +0300 Subject: [proposal] SERVER_NAME =?UTF-8?B?0LI=?= fastcgi_params In-Reply-To: References: <2248451.uKp60E1Vhr@thinkpad-pgpro> Message-ID: <5729163.cooL43t4gv@thinkpad-pgpro> В письме от воскресенье, 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 Тип: application/pgp-signature Размер: 488 байтов Описание: This is a digitally signed message part. URL: From chipitsine на gmail.com Sun Mar 5 19:04:35 2023 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Sun, 5 Mar 2023 20:04:35 +0100 Subject: =?UTF-8?Q?Re=3A_=5Bproposal=5D_SERVER=5FNAME_=D0=B2_fastcgi=5Fparams?= In-Reply-To: <5729163.cooL43t4gv@thinkpad-pgpro> References: <2248451.uKp60E1Vhr@thinkpad-pgpro> <5729163.cooL43t4gv@thinkpad-pgpro> Message-ID: вс, 5 мар. 2023 г. в 16:59, Nikolay Shaplov : > В письме от воскресенье, 5 марта 2023 г. 18:49:10 MSK пользователь Evgeniy > Berdnikov написал: > > > > > > Скрипту, тем ни менее нужно знать доменное имя которое он сейчас > > > обслуживает, и он смотрит на переменную окружения SERVER_NAME. > > > > > > А в этой переменной пусто. > > > > Подумайте об использовании переменной $host. > Выглядит как хороший вариант, лучше чем $http_host. Это спасибо. > > Но не следует ли заменить $server_name на $host в конфигах *cgi_params в > дистрибутиве nginx? Я в первую очередь с этой мыслью сюда пришел... > боюсь, что изменение дефолтного поведения обычно не приветствуется. но, с другой стороны, существующие механизмы позволяют вам использовать $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 > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From dhyan на nataraj.su Mon Mar 6 06:42:04 2023 From: dhyan на nataraj.su (Nikolay Shaplov) Date: Mon, 06 Mar 2023 09:42:04 +0300 Subject: [proposal] SERVER_NAME =?UTF-8?B?0LI=?= fastcgi_params In-Reply-To: References: <2248451.uKp60E1Vhr@thinkpad-pgpro> <5729163.cooL43t4gv@thinkpad-pgpro> Message-ID: <5102654.WBXMQbHMOj@thinkpad-pgpro> В письме от воскресенье, 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 Тип: application/pgp-signature Размер: 488 байтов Описание: This is a digitally signed message part. URL: From andrey на kopeyko.ru Mon Mar 6 10:59:30 2023 From: andrey на kopeyko.ru (Andrey Kopeyko) Date: Mon, 6 Mar 2023 13:59:30 +0300 (MSK) Subject: =?KOI8-R?Q?Re=3A_=5Bproposal=5D_SERVER=5FNAME_=D7_fastcgi=5Fparam?= =?KOI8-R?Q?s?= In-Reply-To: <5102654.WBXMQbHMOj@thinkpad-pgpro> References: <2248451.uKp60E1Vhr@thinkpad-pgpro> <5729163.cooL43t4gv@thinkpad-pgpro> <5102654.WBXMQbHMOj@thinkpad-pgpro> Message-ID: On Mon, 6 Mar 2023, Nikolay Shaplov wrote: > В письме от воскресенье, 5 марта 2023 г. 22:04:35 MSK пользователь Илья > Шипицин написал: >> > Но не следует ли заменить $server_name на $host в конфигах *cgi_params в >> > дистрибутиве nginx? Я в первую очередь с этой мыслью сюда пришел... > >> но, с другой стороны, существующие механизмы позволяют вам использовать >> $host и не зависеть от дефолтных конфигов, верно ? > Я в данном вопросе беспокоюсь скорее за других, чем за себя. Я в свое время > убил очень много времени, пока траблшутил проблему вызванную отсутствием > корректного значения в SERVER_NAME, и в таких случаях обычно стараюсь сделать > так, чтобы никому после меня не пришлось бы снова ходть по проделанному мной > пути. Изменение дефолта в конфигах *cgi_params, решит эту задачу лучше всего > >> боюсь, что изменение дефолтного поведения обычно не приветствуется. > > В данном случае я бы сказал что это изменение более чем оправдано. > > 1. Нынешнее положение дел приводит к нарушению RFC. Исправление приведет к > соблюдению RFC "из коробки". Соблюдать RFC -- не только хорошо, но и очень > важно. Николай, к "нарушению RFC" приводит ваша конкретная конфигурация - когда вы обрабатываете множество имён в дефолтном сервере, для которого вы _не задаёте_ server_name. Вот корень всех бед. И именно поэтому дефолтное поведение менять не следует. Если вы зададите для этого сервера несуществующее имя ("_" как рекомендует документация, или "fakehost.fakedomain") - переменная SERVER_NAME волшебным образом появится. P.S. Будете в офисе - подходите, обсудим подробнее (ибо голосом будет удобнее). > > 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 -- Best regards, Andrey A. Kopeyko From dhyan на nataraj.su Mon Mar 6 11:07:02 2023 From: dhyan на nataraj.su (Nikolay Shaplov) Date: Mon, 06 Mar 2023 14:07:02 +0300 Subject: [proposal] SERVER_NAME =?UTF-8?B?0LI=?= fastcgi_params In-Reply-To: References: <2248451.uKp60E1Vhr@thinkpad-pgpro> <5102654.WBXMQbHMOj@thinkpad-pgpro> Message-ID: <2011793.9W5K0aF0Qx@thinkpad-pgpro> В письме от понедельник, 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 Тип: application/pgp-signature Размер: 488 байтов Описание: This is a digitally signed message part. URL: From andrey на kopeyko.ru Mon Mar 6 11:22:25 2023 From: andrey на kopeyko.ru (Andrey Kopeyko) Date: Mon, 6 Mar 2023 14:22:25 +0300 (MSK) Subject: =?KOI8-R?Q?Re=3A_=5Bproposal=5D_SERVER=5FNAME_=D7_fastcgi=5Fparam?= =?KOI8-R?Q?s?= In-Reply-To: <2011793.9W5K0aF0Qx@thinkpad-pgpro> References: <2248451.uKp60E1Vhr@thinkpad-pgpro> <5102654.WBXMQbHMOj@thinkpad-pgpro> <2011793.9W5K0aF0Qx@thinkpad-pgpro> Message-ID: On Mon, 6 Mar 2023, Nikolay Shaplov wrote: > В письме от понедельник, 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. Вот это самое правило вы и нарушаете, в описанной вами конфигурации, - но раз вам так надо и вы понимаете что вы делаете, то пускай. Обходной хак вам подсказали - использовать $http_host, и быть готовым что там тоже может быть пусто. Но вы продолжаете желать странного - поломать дефотное поведение для всех прочих случаев... Приходите в офис, обсудим. > ... > > ... 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. >> Будете в офисе - подходите, обсудим подробнее (ибо голосом будет удобнее). > Буду в городе в начале след. недели. Обсудим, да... > -- Best regards, Andrey A. Kopeyko From bgx на protva.ru Mon Mar 6 14:17:34 2023 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Mon, 6 Mar 2023 17:17:34 +0300 Subject: [proposal] SERVER_NAME =?koi8-r?B?1yBm?= =?koi8-r?Q?astcgi=5Fparams?= In-Reply-To: References: <2248451.uKp60E1Vhr@thinkpad-pgpro> <5102654.WBXMQbHMOj@thinkpad-pgpro> <2011793.9W5K0aF0Qx@thinkpad-pgpro> Message-ID: On Mon, Mar 06, 2023 at 02:22:25PM +0300, Andrey Kopeyko wrote: > On Mon, 6 Mar 2023, Nikolay Shaplov wrote: > > Я бы с этим всем согласился, приняв на веру, если бы в RFC не было бы > > написано: > > > > The SERVER_NAME variable MUST be set to the name of the server host > > to which the client request is directed. > > Вот это самое правило вы и нарушаете, в описанной вами конфигурации, - но > раз вам так надо и вы понимаете что вы делаете, то пускай. Товарищ, наверное, хотел сказать, что составитель дефолтной конфигурации не заметил некоторые проблемы, с которыми могут столнуться пользователи. И что если вместо $server_name написать $host, то вероятность возникновения этих проблем будет несколько ниже. С чем трудно не согласиться. Как всегда, ждём, какие аргументы придумают авторы, чтобы ничего не менять. :) -- Eugene Berdnikov From dhyan на nataraj.su Mon Mar 6 15:17:10 2023 From: dhyan на nataraj.su (Nikolay Shaplov) Date: Mon, 06 Mar 2023 18:17:10 +0300 Subject: [proposal] SERVER_NAME =?UTF-8?B?0LI=?= fastcgi_params In-Reply-To: References: <2248451.uKp60E1Vhr@thinkpad-pgpro> <5102654.WBXMQbHMOj@thinkpad-pgpro> Message-ID: <1808459.mIUDgPjuXr@thinkpad-pgpro> В письме от понедельник, 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 Тип: application/pgp-signature Размер: 488 байтов Описание: This is a digitally signed message part. URL: From chipitsine на gmail.com Mon Mar 6 18:34:15 2023 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 6 Mar 2023 19:34:15 +0100 Subject: =?UTF-8?Q?Re=3A_=5Bproposal=5D_SERVER=5FNAME_=D0=B2_fastcgi=5Fparams?= In-Reply-To: References: <2248451.uKp60E1Vhr@thinkpad-pgpro> <5102654.WBXMQbHMOj@thinkpad-pgpro> <2011793.9W5K0aF0Qx@thinkpad-pgpro> Message-ID: пн, 6 мар. 2023 г. в 15:17, Evgeniy Berdnikov : > On Mon, Mar 06, 2023 at 02:22:25PM +0300, Andrey Kopeyko wrote: > > On Mon, 6 Mar 2023, Nikolay Shaplov wrote: > > > Я бы с этим всем согласился, приняв на веру, если бы в RFC не было бы > > > написано: > > > > > > The SERVER_NAME variable MUST be set to the name of the server host > > > to which the client request is directed. > > > > Вот это самое правило вы и нарушаете, в описанной вами конфигурации, - но > > раз вам так надо и вы понимаете что вы делаете, то пускай. > > Товарищ, наверное, хотел сказать, что составитель дефолтной конфигурации > не заметил некоторые проблемы, с которыми могут столнуться пользователи. > И что если вместо $server_name написать $host, то вероятность > возникновения > этих проблем будет несколько ниже. С чем трудно не согласиться. > > Как всегда, ждём, какие аргументы придумают авторы, чтобы ничего не > менять. :) > а непонятно, есть ли вообще такая проблема "у других пользователей". ну гипотетически, в чем польза от смены дефолта ? у кого-то резко починится ? а ему оно надо )) ? > -- > Eugene Berdnikov > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From dhyan на nataraj.su Mon Mar 6 18:36:53 2023 From: dhyan на nataraj.su (Nikolay Shaplov) Date: Mon, 06 Mar 2023 21:36:53 +0300 Subject: [proposal] SERVER_NAME =?UTF-8?B?0LI=?= fastcgi_params In-Reply-To: References: <2248451.uKp60E1Vhr@thinkpad-pgpro> Message-ID: <2406286.pNjZeK7liR@thinkpad-pgpro> В письме от понедельник, 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 Тип: application/pgp-signature Размер: 484 байтов Описание: This is a digitally signed message part. URL: From chipitsine на gmail.com Mon Mar 6 18:40:49 2023 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 6 Mar 2023 19:40:49 +0100 Subject: =?UTF-8?Q?Re=3A_=5Bproposal=5D_SERVER=5FNAME_=D0=B2_fastcgi=5Fparams?= In-Reply-To: <2406286.pNjZeK7liR@thinkpad-pgpro> References: <2248451.uKp60E1Vhr@thinkpad-pgpro> <2406286.pNjZeK7liR@thinkpad-pgpro> Message-ID: пн, 6 мар. 2023 г. в 19:36, Nikolay Shaplov : > В письме от понедельник, 6 марта 2023 г. 21:34:15 MSK пользователь Илья > Шипицин написал: > > > > Товарищ, наверное, хотел сказать, что составитель дефолтной > конфигурации > > > не заметил некоторые проблемы, с которыми могут столнуться > пользователи. > > > И что если вместо $server_name написать $host, то вероятность > > > > > > возникновения > > > > > > этих проблем будет несколько ниже. С чем трудно не согласиться. > > > > > > Как всегда, ждём, какие аргументы придумают авторы, чтобы ничего не > > > > > > менять. :) > > > > а непонятно, есть ли вообще такая проблема "у других пользователей". > > ну гипотетически, в чем польза от смены дефолта ? > > > > у кого-то резко починится ? а ему оно надо )) ? > > Кто-то сэкономит рабочий день потраченный на поиск "почему при переходе на > nginx не работает" > > это вы говорите про тех, кто еще не пользуется nginx, и собирается заехать на него. а есть непустое множество тех, кто уже пользуется, и вы поменяете им поведение после апгрейда. > > > -- > Nikolay Shaplov aka Nataraj > Fuzzing Engineer at Postgres Professional > Matrix IM: @dhyan:nataraj.su > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From bgx на protva.ru Mon Mar 6 18:51:17 2023 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Mon, 6 Mar 2023 21:51:17 +0300 Subject: [proposal] SERVER_NAME =?utf-8?B?0LIg?= =?utf-8?Q?fastcgi=5Fparams?= In-Reply-To: References: <2248451.uKp60E1Vhr@thinkpad-pgpro> <2406286.pNjZeK7liR@thinkpad-pgpro> Message-ID: On Mon, Mar 06, 2023 at 07:40:49PM +0100, Илья Шипицин wrote: > а есть непустое множество тех, кто уже пользуется, и вы поменяете им > поведение после апгрейда. Неужели? И как же оно поменяется? Поставим лучше вопрос так: что у них сломается и почему? -- Eugene Berdnikov From dhyan на nataraj.su Mon Mar 6 18:55:21 2023 From: dhyan на nataraj.su (Nikolay Shaplov) Date: Mon, 06 Mar 2023 21:55:21 +0300 Subject: [proposal] SERVER_NAME =?UTF-8?B?0LI=?= fastcgi_params In-Reply-To: References: <2248451.uKp60E1Vhr@thinkpad-pgpro> Message-ID: <4441586.FRCoYXIQKI@thinkpad-pgpro> В письме от понедельник, 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 Тип: application/pgp-signature Размер: 488 байтов Описание: This is a digitally signed message part. URL: From chipitsine на gmail.com Mon Mar 6 20:00:22 2023 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 6 Mar 2023 21:00:22 +0100 Subject: =?UTF-8?Q?Re=3A_=5Bproposal=5D_SERVER=5FNAME_=D0=B2_fastcgi=5Fparams?= In-Reply-To: <4441586.FRCoYXIQKI@thinkpad-pgpro> References: <2248451.uKp60E1Vhr@thinkpad-pgpro> <4441586.FRCoYXIQKI@thinkpad-pgpro> Message-ID: пн, 6 мар. 2023 г. в 19:55, Nikolay Shaplov : > В письме от понедельник, 6 марта 2023 г. 21:51:17 MSK пользователь Evgeniy > Berdnikov написал: > > On Mon, Mar 06, 2023 at 07:40:49PM +0100, Илья Шипицин wrote: > > > а есть непустое множество тех, кто уже пользуется, и вы поменяете им > > > поведение после апгрейда. > > > > Неужели? И как же оно поменяется? > > Поставим лучше вопрос так: что у них сломается и почему? > > +1 > > Мой мысленный эксперимент показал что ничего ни у кого не сломается. См. в > более ранних письмах. > ну допустим, у кого-то далее по цепочке стоит nginx, который логирует в access_log параметр server_name от апстрима. и там всегда был прочерк. и на это значение завязались аналитики. ситуация нелепая, но зачем же таким людям делать хорошо против их воли > > > -- > 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 > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From dhyan на nataraj.su Mon Mar 6 20:13:46 2023 From: dhyan на nataraj.su (Nikolay Shaplov) Date: Mon, 06 Mar 2023 23:13:46 +0300 Subject: [proposal] SERVER_NAME =?UTF-8?B?0LI=?= fastcgi_params In-Reply-To: References: <2248451.uKp60E1Vhr@thinkpad-pgpro> <4441586.FRCoYXIQKI@thinkpad-pgpro> Message-ID: <2521812.69BRItMStf@thinkpad-pgpro> В письме от понедельник, 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 Тип: application/pgp-signature Размер: 488 байтов Описание: This is a digitally signed message part. URL: From andrey на kopeyko.ru Mon Mar 6 20:25:27 2023 From: andrey на kopeyko.ru (Andrey Kopeyko) Date: Mon, 6 Mar 2023 23:25:27 +0300 (MSK) Subject: =?KOI8-R?Q?Re=3A_=5Bproposal=5D_SERVER=5FNAME_=D7_fastcgi=5Fparam?= =?KOI8-R?Q?s?= In-Reply-To: <2521812.69BRItMStf@thinkpad-pgpro> References: <2248451.uKp60E1Vhr@thinkpad-pgpro> <4441586.FRCoYXIQKI@thinkpad-pgpro> <2521812.69BRItMStf@thinkpad-pgpro> Message-ID: On Mon, 6 Mar 2023, Nikolay Shaplov wrote: > В письме от понедельник, 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 ведет к потенциальным проблемам и потерям времени > (я тому пример) Николай, к потере вашего времени привело не несоблюление RFC (требовать соблюдения которого в данном конкрентном случае - не очень правильно; тут должно быть многа букв, расскажу голосом...), а Ваше непонимание разницы между параметром конфига server_name и переменной запроса $http_host. Сожалею о Вашем потерянном времени. Приходите в офис, всё расскажу. Вот дописать в доку статью "о (вреде и) подводных камнях обработки запроса в дефолтном сервере" - наверное, было бы полезным. -- Best regards, Andrey A. Kopeyko From bgx на protva.ru Mon Mar 6 22:18:21 2023 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Tue, 7 Mar 2023 01:18:21 +0300 Subject: [proposal] SERVER_NAME =?utf-8?B?0LIg?= =?utf-8?Q?fastcgi=5Fparams?= In-Reply-To: References: <2248451.uKp60E1Vhr@thinkpad-pgpro> <4441586.FRCoYXIQKI@thinkpad-pgpro> <2521812.69BRItMStf@thinkpad-pgpro> Message-ID: On Mon, Mar 06, 2023 at 11:25:27PM +0300, Andrey Kopeyko wrote: > Николай, к потере вашего времени привело не несоблюление RFC (требовать > соблюдения которого в данном конкрентном случае - не очень правильно; тут > должно быть многа букв, расскажу голосом...), а Ваше непонимание разницы > между параметром конфига server_name и переменной запроса $http_host. > > Сожалею о Вашем потерянном времени. > > Приходите в офис, всё расскажу. Расскажите лучше здесь. В том числе тем, кто не может и не хочет ходить в офис (чай на дворе не средние века, а видеосвязь давно изобрели). > Вот дописать в доку статью "о (вреде и) подводных камнях обработки запроса в > дефолтном сервере" - наверное, было бы полезным. Обратите внимание на то, что интерес инициатора треда заключался не в том, чтобы изучать разнообразные грабли, а в том, как один конкретный камень убрать с проторенной дороги. Идеально сделанный интерфейс не допускает никаких подводных камней, противоречий и неоднозначностей. Им просто пользуешься и "всё работает". То же самое должно быть и с дефолтным конфигом. А если камни всё-таки вылезают, нужно в первую очередь думать о том, как их устранить, и в последнюю -- о том, как их документировать. -- Eugene Berdnikov From mdounin на mdounin.ru Mon Mar 6 22:51:53 2023 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 7 Mar 2023 01:51:53 +0300 Subject: [proposal] SERVER_NAME =?koi8-r?B?1yBm?= =?koi8-r?Q?astcgi=5Fparams?= In-Reply-To: References: <2248451.uKp60E1Vhr@thinkpad-pgpro> <5102654.WBXMQbHMOj@thinkpad-pgpro> <2011793.9W5K0aF0Qx@thinkpad-pgpro> Message-ID: Hello! On Mon, Mar 06, 2023 at 02:22:25PM +0300, Andrey Kopeyko wrote: > On Mon, 6 Mar 2023, Nikolay Shaplov wrote: > > > В письме от понедельник, 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. > > Вот это самое правило вы и нарушаете, в описанной вами конфигурации, - но раз > вам так надо и вы понимаете что вы делаете, то пускай. > > Обходной хак вам подсказали - использовать $http_host, и быть готовым что там > тоже может быть пусто. Я скромно замечу, что использовать переменную $http_host для чего либо, кроме проверки собственно заголовка Host - не стоит. Этот заголовок может отсутствовать вообще или не совпадать с тем хостом, которому обращался клиент. Конфигурация с $http_host - это почти всегда как минимум глюки в краевых случаях, а как максимум - "дыра в безопасности". Как уже было верно отмечено в этом треде, если нужна переменная, отражающая запрошенный клиентом хост, то следует использовать переменную $host. -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Tue Mar 7 00:23:41 2023 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 7 Mar 2023 03:23:41 +0300 Subject: [proposal] SERVER_NAME =?koi8-r?B?1yBm?= =?koi8-r?Q?astcgi=5Fparams?= In-Reply-To: References: <2248451.uKp60E1Vhr@thinkpad-pgpro> <5102654.WBXMQbHMOj@thinkpad-pgpro> <2011793.9W5K0aF0Qx@thinkpad-pgpro> Message-ID: Hello! On Mon, Mar 06, 2023 at 05:17:34PM +0300, Evgeniy Berdnikov wrote: > On Mon, Mar 06, 2023 at 02:22:25PM +0300, Andrey Kopeyko wrote: > > On Mon, 6 Mar 2023, Nikolay Shaplov wrote: > > > Я бы с этим всем согласился, приняв на веру, если бы в RFC не было бы > > > написано: > > > > > > The SERVER_NAME variable MUST be set to the name of the server host > > > to which the client request is directed. > > > > Вот это самое правило вы и нарушаете, в описанной вами конфигурации, - но > > раз вам так надо и вы понимаете что вы делаете, то пускай. > > Товарищ, наверное, хотел сказать, что составитель дефолтной конфигурации > не заметил некоторые проблемы, с которыми могут столнуться пользователи. > И что если вместо $server_name написать $host, то вероятность возникновения > этих проблем будет несколько ниже. С чем трудно не согласиться. > > Как всегда, ждём, какие аргументы придумают авторы, чтобы ничего не менять. :) Да вообще легко :)) Дефолтная конфигурация, по историческим причинам, заточена на конфигурации, где server_name задан: это было поведением по умолчанию до nginx версии 0.8.48. Подобная конфигурация в целом предполагает, что запрашиваемое клиентом имя может использовать для выбора блока server{}, но в дальнейшем не используется: для всех остальных действий используется каноническое имя сервера. Например, все перенаправления возвращаются с использованием канонического имени сервера (см. server_name_in_redirect). Очевидно, что в подобной конфигурации SERVER_NAME, передаваемый в CGI-like бэкенды, тоже должен отражать каноническое имя сервера, то есть $server_name. Замена его на $host приведёт к использованию в CGI-like бэкендах некорректного имени, использование которого не предполагается конфигурацией. Более того, если речь идёт про сервер по умолчанию для данного слушающего сокета - то имя окажется полностью под контролем клиента, что может привести уже к проблемам безопасности, если на бэкенде что-либо завязано на проверку этого имени. Суммируя вышеизложенное: замена $server_name на $host гарантировано сломает конфигурации, полагающиеся на существующее поведение с передачей на CGI-like бэкенды канонического имени сервера, и для корректной работы таких конфигураций потребуется менять $host на $server_name обратно. Какие конфигурации приоритетнее - сложно сказать, но лично я бы рекомендовал указывать server_name всегда, а не полагаться на то, что nginx сможет обрабатывать любые имена. Именно так, в частности, делает и конфигурация по умолчанию - там server_name явно указан. -- Maxim Dounin http://mdounin.ru/ From nginx-ru на ivanoff.spb.ru Mon Mar 13 06:17:17 2023 From: nginx-ru на ivanoff.spb.ru (Dmitry Ivanov) Date: Mon, 13 Mar 2023 09:17:17 +0300 Subject: =?utf-8?Q?Re:_[proposal]_SERVER=5FNAME_=D0=B2_fastcgi=5Fparams?= In-Reply-To: <2248451.uKp60E1Vhr@thinkpad-pgpro> References: <2248451.uKp60E1Vhr@thinkpad-pgpro> Message-ID: <488840076.20230313091717@ivanoff.spb.ru> Здравствуйте, Nikolay. Вы писали 5 марта 2023 г., 18:41:17: > При этом в самом конфиге сайта server_name не указан, сервер обслуживает все > доменные имена (фильтрация по имени осуществляется на фронтэнде). Видимо, надо потыкать в RFC разработчиков фронта и забыть о "проблеме" -- С уважением, Dmitry nginx-ru на ivanoff.spb.ru From dhyan на nataraj.su Mon Mar 13 06:20:49 2023 From: dhyan на nataraj.su (Nikolay Shaplov) Date: Mon, 13 Mar 2023 09:20:49 +0300 Subject: [proposal] SERVER_NAME =?UTF-8?B?0LI=?= fastcgi_params In-Reply-To: <488840076.20230313091717@ivanoff.spb.ru> References: <2248451.uKp60E1Vhr@thinkpad-pgpro> <488840076.20230313091717@ivanoff.spb.ru> Message-ID: <3299722.9JVUtZQNTA@thinkpad-pgpro> В письме от понедельник, 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 Тип: application/pgp-signature Размер: 488 байтов Описание: This is a digitally signed message part. URL: From mdounin на mdounin.ru Mon Mar 13 07:27:10 2023 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 13 Mar 2023 10:27:10 +0300 Subject: [proposal] SERVER_NAME =?koi8-r?B?1yBm?= =?koi8-r?Q?astcgi=5Fparams?= In-Reply-To: <3299722.9JVUtZQNTA@thinkpad-pgpro> References: <2248451.uKp60E1Vhr@thinkpad-pgpro> <488840076.20230313091717@ivanoff.spb.ru> <3299722.9JVUtZQNTA@thinkpad-pgpro> Message-ID: 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. > Я вроде об этом уже писал выше по треду. Не противоречит, на бэкенд отправляется каноническое имя виртуального сервера. Хотите, чтобы было по другому - сконфигурируйте по другому и/или явно опишите виртуальные сервера, в разных блоках server{}. Подробнее про текущее поведение я писал тут: https://mailman.nginx.org/pipermail/nginx-ru/2023-March/USR4N4KMUMDT2KKUV4J5RJVBOZTSNCFF.html Если остались какие-то вопросы - спрашивайте. -- Maxim Dounin http://mdounin.ru/ From dhyan на nataraj.su Mon Mar 13 07:33:36 2023 From: dhyan на nataraj.su (Nikolay Shaplov) Date: Mon, 13 Mar 2023 10:33:36 +0300 Subject: [proposal] SERVER_NAME =?UTF-8?B?0LI=?= fastcgi_params In-Reply-To: References: <2248451.uKp60E1Vhr@thinkpad-pgpro> <3299722.9JVUtZQNTA@thinkpad-pgpro> Message-ID: <4008136.x2F00kuhBD@thinkpad-pgpro> В письме от понедельник, 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 Тип: application/pgp-signature Размер: 488 байтов Описание: This is a digitally signed message part. URL: From kulmaks на gmail.com Mon Mar 13 07:46:51 2023 From: kulmaks на gmail.com (Maksim Kulik) Date: Mon, 13 Mar 2023 10:46:51 +0300 Subject: =?UTF-8?Q?Re=3A_=5Bproposal=5D_SERVER=5FNAME_=D0=B2_fastcgi=5Fparams?= In-Reply-To: <4008136.x2F00kuhBD@thinkpad-pgpro> References: <2248451.uKp60E1Vhr@thinkpad-pgpro> <3299722.9JVUtZQNTA@thinkpad-pgpro> <4008136.x2F00kuhBD@thinkpad-pgpro> Message-ID: Мне кажется, что в RFC речь идет скорее про разные блоки server {}, т.к. речь явно про several virtual hosts, а не про several server names. То есть веб-сервер вполне корректно по RFC выбирает блок server {} по имени хоста и используется главное имя этого блока далее в работе. Вы в своем примере имеете один виртуал хост и N имен (алиасов, если хотите) в нем, где N может быть бесконечным в случае дефолтного хоста. Ваш сервер и выбирает этот самый хост по имени, которое видит в заголовке. пн, 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 > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From dhyan на nataraj.su Mon Mar 13 07:50:37 2023 From: dhyan на nataraj.su (Nikolay Shaplov) Date: Mon, 13 Mar 2023 10:50:37 +0300 Subject: [proposal] SERVER_NAME =?UTF-8?B?0LI=?= fastcgi_params In-Reply-To: References: <2248451.uKp60E1Vhr@thinkpad-pgpro> <4008136.x2F00kuhBD@thinkpad-pgpro> Message-ID: <1860728.QSd4bnokfV@thinkpad-pgpro> В письме от понедельник, 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 Тип: application/pgp-signature Размер: 488 байтов Описание: This is a digitally signed message part. URL: From mdounin на mdounin.ru Mon Mar 13 08:27:09 2023 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 13 Mar 2023 11:27:09 +0300 Subject: [proposal] SERVER_NAME =?koi8-r?B?1yBm?= =?koi8-r?Q?astcgi=5Fparams?= In-Reply-To: <4008136.x2F00kuhBD@thinkpad-pgpro> References: <2248451.uKp60E1Vhr@thinkpad-pgpro> <3299722.9JVUtZQNTA@thinkpad-pgpro> <4008136.x2F00kuhBD@thinkpad-pgpro> Message-ID: Hello! On Mon, Mar 13, 2023 at 10:33:36AM +0300, Nikolay Shaplov wrote: > В письме от понедельник, 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" Так nginx и использует "request's Host header field to select the correct virtual host" (на самом деле там сложнее, подробнее в стандартах HTTP). И в соответствии с этим - ставит SERVER_NAME в каноническое значение имени выбранного виртуального сервера. Нормативного требования использовать значение заголовка Host в переменной SERVER_NAME - в RFC 3875 нет. (И, в общем-то, быть не может, потому что такое требование противоречило бы нормативным требованиям стандарта HTTP, см. выше про "там сложнее".) -- Maxim Dounin http://mdounin.ru/ From bgx на protva.ru Mon Mar 13 08:37:47 2023 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Mon, 13 Mar 2023 11:37:47 +0300 Subject: [proposal] SERVER_NAME =?utf-8?B?0LIg?= =?utf-8?Q?fastcgi=5Fparams?= In-Reply-To: <1860728.QSd4bnokfV@thinkpad-pgpro> References: <2248451.uKp60E1Vhr@thinkpad-pgpro> <4008136.x2F00kuhBD@thinkpad-pgpro> <1860728.QSd4bnokfV@thinkpad-pgpro> Message-ID: On Mon, Mar 13, 2023 at 10:50:37AM +0300, Nikolay Shaplov wrote: > В письме от понедельник, 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 попадает первый > из алиасов, а не тот на который пришли??? В этом нет вообще никакой логики. +1 И нужно отметить, что RFC про протокол взаимодействия, он не диктует как писать конфиги, поэтому там ничего нет "про разные блоки server {}". RFC связывает параметры запроса HTTP с параметрами CGI. -- Eugene Berdnikov From bgx на protva.ru Mon Mar 13 08:50:33 2023 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Mon, 13 Mar 2023 11:50:33 +0300 Subject: [proposal] SERVER_NAME =?utf-8?B?0LIg?= =?utf-8?Q?fastcgi=5Fparams?= In-Reply-To: References: <2248451.uKp60E1Vhr@thinkpad-pgpro> <4008136.x2F00kuhBD@thinkpad-pgpro> <1860728.QSd4bnokfV@thinkpad-pgpro> Message-ID: On Mon, Mar 13, 2023 at 11:37:47AM +0300, Evgeniy Berdnikov wrote: > On Mon, Mar 13, 2023 at 10:50:37AM +0300, Nikolay Shaplov wrote: > > В письме от понедельник, 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 попадает первый > > из алиасов, а не тот на который пришли??? В этом нет вообще никакой логики. > > +1 > > И нужно отметить, что RFC про протокол взаимодействия, он не диктует как > писать конфиги, поэтому там ничего нет "про разные блоки server {}". > RFC связывает параметры запроса HTTP с параметрами CGI. Однако, нет, перечитав ещё несколько раз п.4.1.14 rfc3875, беру свои слова обратно. -- Eugene Berdnikov From mdounin на mdounin.ru Mon Mar 13 08:56:49 2023 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 13 Mar 2023 11:56:49 +0300 Subject: [proposal] SERVER_NAME =?koi8-r?B?1yBm?= =?koi8-r?Q?astcgi=5Fparams?= In-Reply-To: <1860728.QSd4bnokfV@thinkpad-pgpro> References: <2248451.uKp60E1Vhr@thinkpad-pgpro> <4008136.x2F00kuhBD@thinkpad-pgpro> <1860728.QSd4bnokfV@thinkpad-pgpro> Message-ID: Hello! On Mon, Mar 13, 2023 at 10:50:37AM +0300, Nikolay Shaplov wrote: > В письме от понедельник, 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 попадает первый > из алиасов, а не тот на который пришли??? В этом нет вообще никакой логики. Потому что первое из имён, указанных в директиве server_name - каноническое. Это, кстати, явно описано в документации (https://nginx.org/ru/docs/http/ngx_http_core_module.html#server_name): : Первое имя становится основным именем сервера. Разделение на каноническое имя и алиасы - оно ещё из Apache, где имя сервера указывается отдельно, директивой ServerName, а алиасы, соответственно, директивой ServerAlias. В nginx'е всех отличий в этом плане - алиасы задаются с помощью той же директивы server_name. Выбор же между "использовать каноническое имя" или "использовать имя, на которое пришли" - это вопрос, в первую очередь, желаемого поведения. Скажем, мы можем хотеть во всех перенаправлениях / ссылках / текстах использовать каноническое имя, чтобы пользователь получал одно и то же, независимо от того, по какому конкретно имени он пришёл. Например, это может быть важно, чтобы тексты сгенерированных страниц всегда совпадали, и их можно было кэшировать для всех пользователей. Или просто из эстетических соображений. Или наоборот, можем хотеть, чтобы пользователю всегда возвращались ссылки ровно с тем именем, на которое он пришёл, потому что для разных пользователей сайт может быть доступен под разными именами. Что именно нужно в конкретной конфигурации - это решение того, кто пишет конфигурацию nginx'а. В некоторых случаях оно явно вынесено в отдельные директивы (см. упоминавшуюся ранее server_name_in_redirect), в случае же CGI-like бэкендов оно делается неявно с помощью задания переменной SERVER_NAME. -- Maxim Dounin http://mdounin.ru/ From dhyan на nataraj.su Mon Mar 13 09:09:26 2023 From: dhyan на nataraj.su (Nikolay Shaplov) Date: Mon, 13 Mar 2023 12:09:26 +0300 Subject: [proposal] SERVER_NAME =?UTF-8?B?0LI=?= fastcgi_params In-Reply-To: References: <2248451.uKp60E1Vhr@thinkpad-pgpro> <1860728.QSd4bnokfV@thinkpad-pgpro> Message-ID: <12623503.A4JhE9V6uF@thinkpad-pgpro> В письме от понедельник, 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 Тип: application/pgp-signature Размер: 488 байтов Описание: This is a digitally signed message part. URL: From chipitsine на gmail.com Mon Mar 13 09:40:14 2023 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 13 Mar 2023 10:40:14 +0100 Subject: =?UTF-8?Q?Re=3A_=5Bproposal=5D_SERVER=5FNAME_=D0=B2_fastcgi=5Fparams?= In-Reply-To: <12623503.A4JhE9V6uF@thinkpad-pgpro> References: <2248451.uKp60E1Vhr@thinkpad-pgpro> <1860728.QSd4bnokfV@thinkpad-pgpro> <12623503.A4JhE9V6uF@thinkpad-pgpro> Message-ID: пн, 13 мар. 2023 г. в 10:09, Nikolay Shaplov : > В письме от понедельник, 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" > все верно. но это про другое же речь. в цитируемом фрагменте речь про то, что если у вас несколько виртуальных хостов, но выбрать правильный можно и нужно исходя из 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 > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From dhyan на nataraj.su Mon Mar 13 10:12:03 2023 From: dhyan на nataraj.su (Nikolay Shaplov) Date: Mon, 13 Mar 2023 13:12:03 +0300 Subject: [proposal] SERVER_NAME =?UTF-8?B?0LI=?= fastcgi_params In-Reply-To: References: <2248451.uKp60E1Vhr@thinkpad-pgpro> <12623503.A4JhE9V6uF@thinkpad-pgpro> Message-ID: <2092545.0XQliXMXtT@thinkpad-pgpro> В письме от понедельник, 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; include fastcgi_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 Тип: application/pgp-signature Размер: 488 байтов Описание: This is a digitally signed message part. URL: From kulmaks на gmail.com Mon Mar 13 10:16:25 2023 From: kulmaks на gmail.com (Maksim Kulik) Date: Mon, 13 Mar 2023 13:16:25 +0300 Subject: =?UTF-8?Q?Re=3A_=5Bproposal=5D_SERVER=5FNAME_=D0=B2_fastcgi=5Fparams?= In-Reply-To: <2092545.0XQliXMXtT@thinkpad-pgpro> References: <2248451.uKp60E1Vhr@thinkpad-pgpro> <12623503.A4JhE9V6uF@thinkpad-pgpro> <2092545.0XQliXMXtT@thinkpad-pgpro> Message-ID: h1.example.com - это и есть имя сервера, остальное - алиасы. пн, 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; > include fastcgi_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 > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From dhyan на nataraj.su Mon Mar 13 10:21:23 2023 From: dhyan на nataraj.su (Nikolay Shaplov) Date: Mon, 13 Mar 2023 13:21:23 +0300 Subject: [proposal] SERVER_NAME =?UTF-8?B?0LI=?= fastcgi_params In-Reply-To: References: <2248451.uKp60E1Vhr@thinkpad-pgpro> <2092545.0XQliXMXtT@thinkpad-pgpro> Message-ID: <2866687.c60cIBLkeJ@thinkpad-pgpro> В письме от понедельник, 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; > > include fastcgi_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 Тип: application/pgp-signature Размер: 488 байтов Описание: This is a digitally signed message part. URL: From kulmaks на gmail.com Mon Mar 13 10:26:22 2023 From: kulmaks на gmail.com (Maksim Kulik) Date: Mon, 13 Mar 2023 13:26:22 +0300 Subject: =?UTF-8?Q?Re=3A_=5Bproposal=5D_SERVER=5FNAME_=D0=B2_fastcgi=5Fparams?= In-Reply-To: <2866687.c60cIBLkeJ@thinkpad-pgpro> References: <2248451.uKp60E1Vhr@thinkpad-pgpro> <2092545.0XQliXMXtT@thinkpad-pgpro> <2866687.c60cIBLkeJ@thinkpad-pgpro> Message-ID: Да, т.к. name of the server - это первое имя в директиве server_name. Выше в переписке уже писали, что это упомянуто в документации - http://nginx.org/ru/docs/http/ngx_http_core_module.html#server_name Кроме этого, Максим писал про аналоги в веб-сервере Apache - там есть ServerName, в котором описывается только одно имя и ServerAlias, которых может быть много. В приведенном вами примере ServerName - h1.example.com, остальное - алиасы. А алиас никогда не попадает в переменную SERVER_NAME. пн, 13 мар. 2023 г. в 13:21, Nikolay Shaplov : > В письме от понедельник, 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; > > > include fastcgi_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 > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Mon Mar 13 10:50:15 2023 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 13 Mar 2023 11:50:15 +0100 Subject: =?UTF-8?Q?Re=3A_=5Bproposal=5D_SERVER=5FNAME_=D0=B2_fastcgi=5Fparams?= In-Reply-To: <2092545.0XQliXMXtT@thinkpad-pgpro> References: <2248451.uKp60E1Vhr@thinkpad-pgpro> <12623503.A4JhE9V6uF@thinkpad-pgpro> <2092545.0XQliXMXtT@thinkpad-pgpro> Message-ID: пн, 13 мар. 2023 г. в 11: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; > include fastcgi_params; > fastcgi_pass unix:/var/run/my-fastcgi; > > Я браузером захожу на h2.example.com > > Что должно оказаться в SERVER_NAME для cgi-скрипта который будет отвечать > на > этот запрос? > процитированный Вами фрагмент RFC говорит, что, если у вас есть несколько блоков server { ... }, то выбрать надо данный конкретный, потому что в server_name у него присутствует h2.example.com а что писать в SERVER_NAME для cgi-скрипта - тут нет четкого мнения, скажем так, могут быть варианты. > > -- > Nikolay Shaplov aka Nataraj > Fuzzing Engineer at Postgres Professional > Matrix IM: @dhyan:nataraj.su > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From kulmaks на gmail.com Mon Mar 13 10:53:38 2023 From: kulmaks на gmail.com (Maksim Kulik) Date: Mon, 13 Mar 2023 13:53:38 +0300 Subject: =?UTF-8?Q?Re=3A_=5Bproposal=5D_SERVER=5FNAME_=D0=B2_fastcgi=5Fparams?= In-Reply-To: References: <2248451.uKp60E1Vhr@thinkpad-pgpro> <12623503.A4JhE9V6uF@thinkpad-pgpro> <2092545.0XQliXMXtT@thinkpad-pgpro> Message-ID: В RFC на эту тему есть вполне четкое мнение: The SERVER_NAME variable MUST be set to the name of the server host to which the client request is directed. Там должно быть имя сервера, который обслуживает этот запрос. Из документации nginx: Первое имя становится основным именем сервера. Всё вполне однозначно при внимательном прочтении. пн, 13 мар. 2023 г. в 13:50, Илья Шипицин : > > > пн, 13 мар. 2023 г. в 11: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; >> include fastcgi_params; >> fastcgi_pass unix:/var/run/my-fastcgi; >> >> Я браузером захожу на h2.example.com >> >> Что должно оказаться в SERVER_NAME для cgi-скрипта который будет отвечать >> на >> этот запрос? >> > > процитированный Вами фрагмент RFC говорит, что, если у вас есть несколько > блоков server { ... }, то > выбрать надо данный конкретный, потому что в server_name у него > присутствует 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 > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Mon Mar 13 11:09:26 2023 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 13 Mar 2023 12:09:26 +0100 Subject: =?UTF-8?Q?Re=3A_=5Bproposal=5D_SERVER=5FNAME_=D0=B2_fastcgi=5Fparams?= In-Reply-To: References: <2248451.uKp60E1Vhr@thinkpad-pgpro> <12623503.A4JhE9V6uF@thinkpad-pgpro> <2092545.0XQliXMXtT@thinkpad-pgpro> Message-ID: и да и нет. в конфиге сервера, приведенным топикстартером server_name отсутствует, а запрос смаршрутизировался, потому что указан default_server в listen. а как интерпретировать MUST в случае отсутствующего server_name RFC не говорит )) пн, 13 мар. 2023 г. в 11:53, Maksim Kulik : > В RFC на эту тему есть вполне четкое мнение: > > The SERVER_NAME variable MUST be set to the name of the server host > to which the client request is directed. > > Там должно быть имя сервера, который обслуживает этот запрос. Из > документации nginx: Первое имя становится основным именем сервера. Всё > вполне однозначно при внимательном прочтении. > > пн, 13 мар. 2023 г. в 13:50, Илья Шипицин : > >> >> >> пн, 13 мар. 2023 г. в 11: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; >>> include fastcgi_params; >>> fastcgi_pass unix:/var/run/my-fastcgi; >>> >>> Я браузером захожу на h2.example.com >>> >>> Что должно оказаться в SERVER_NAME для cgi-скрипта который будет >>> отвечать на >>> этот запрос? >>> >> >> процитированный Вами фрагмент RFC говорит, что, если у вас есть несколько >> блоков server { ... }, то >> выбрать надо данный конкретный, потому что в server_name у него >> присутствует 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 >> > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From kulmaks на gmail.com Mon Mar 13 11:19:29 2023 From: kulmaks на gmail.com (Maksim Kulik) Date: Mon, 13 Mar 2023 14:19:29 +0300 Subject: =?UTF-8?Q?Re=3A_=5Bproposal=5D_SERVER=5FNAME_=D0=B2_fastcgi=5Fparams?= In-Reply-To: References: <2248451.uKp60E1Vhr@thinkpad-pgpro> <12623503.A4JhE9V6uF@thinkpad-pgpro> <2092545.0XQliXMXtT@thinkpad-pgpro> Message-ID: Все же понимают, что отсутствующий server_name - это просто способ "упрощения" минимально необходимого конфига и на самом деле имя сервера все равно присутствует (дефолтное значение - пустая строка). Что именно попадет в этом случае в SERVER_NAME - не совсем понятно. Но исходя из всей вышеописанной логики - туда должна попасть пустая строка. пн, 13 мар. 2023 г. в 14:09, Илья Шипицин : > и да и нет. > в конфиге сервера, приведенным топикстартером server_name отсутствует, а > запрос смаршрутизировался, потому что указан default_server в listen. > > а как интерпретировать MUST в случае отсутствующего server_name RFC не > говорит )) > > пн, 13 мар. 2023 г. в 11:53, Maksim Kulik : > >> В RFC на эту тему есть вполне четкое мнение: >> >> The SERVER_NAME variable MUST be set to the name of the server host >> to which the client request is directed. >> >> Там должно быть имя сервера, который обслуживает этот запрос. Из >> документации nginx: Первое имя становится основным именем сервера. Всё >> вполне однозначно при внимательном прочтении. >> >> пн, 13 мар. 2023 г. в 13:50, Илья Шипицин : >> >>> >>> >>> пн, 13 мар. 2023 г. в 11: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; >>>> include fastcgi_params; >>>> fastcgi_pass unix:/var/run/my-fastcgi; >>>> >>>> Я браузером захожу на h2.example.com >>>> >>>> Что должно оказаться в SERVER_NAME для cgi-скрипта который будет >>>> отвечать на >>>> этот запрос? >>>> >>> >>> процитированный Вами фрагмент RFC говорит, что, если у вас есть >>> несколько блоков server { ... }, то >>> выбрать надо данный конкретный, потому что в server_name у него >>> присутствует 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 >>> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> https://mailman.nginx.org/mailman/listinfo/nginx-ru >> > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Tue Mar 28 16:44:09 2023 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 28 Mar 2023 19:44:09 +0300 Subject: nginx-1.23.4 Message-ID: Изменения в nginx 1.23.4 28.03.2023 *) Изменение: теперь протокол TLSv1.3 разрешён по умолчанию. *) Изменение: теперь nginx выдаёт предупреждение при переопределении параметров listen-сокета, задающих используемые протоколы. *) Изменение: теперь, если клиент использует pipelining, nginx закрывает соединения с ожиданием дополнительных данных (lingering close). *) Добавление: поддержка byte ranges для ответов модуля ngx_http_gzip_static_module. *) Исправление: диапазоны портов в директиве listen не работали; ошибка появилась в 1.23.3. Спасибо Валентину Бартеневу. *) Исправление: для обработки запроса мог быть выбран неверный location, если в конфигурации использовался префиксный location длиннее 255 символов. *) Исправление: не-ASCII символы в именах файлов на Windows не поддерживались модулями ngx_http_autoindex_module и ngx_http_dav_module, а также директивой include. *) Изменение: уровень логгирования ошибок SSL "data length too long", "length too short", "bad legacy version", "no shared signature algorithms", "bad digest length", "missing sigalgs extension", "encrypted length too long", "bad length", "bad key update", "mixed handshake and non handshake data", "ccs received early", "data between ccs and finished", "packet length too long", "too many warn alerts", "record too small", и "got a fin before a ccs" понижен с уровня crit до info. *) Исправление: при использовании HTTP/2 и директивы error_page для перенаправления ошибок с кодом 400 могла происходить утечка сокетов. *) Исправление: сообщения об ошибках записи в syslog не содержали информации о том, что ошибки происходили в процессе записи в syslog. Спасибо Safar Safarly. *) Изменение: при использовании zlib-ng в логах появлялись сообщения "gzip filter failed to use preallocated memory". *) Исправление: в почтовом прокси-сервере. -- Maxim Dounin http://nginx.org/ From izorkin на gmail.com Fri Mar 31 07:43:33 2023 From: izorkin на gmail.com (izorkin на gmail.com) Date: Fri, 31 Mar 2023 10:43:33 +0300 Subject: =?windows-1251?B?bmdpbnhRdWljOiDn4OLo8eDt6OUg8e7l5Ojt5e3o/yDoIPHh8O7xIO3gIEhUVFAvMiDv8O7y?= =?windows-1251?B?7uru6w==?= Message-ID: <1612586774.20230331104333@gmail.com> Здравствуйте. Столкнулся с очередной ошибкой в работе с протоколом HTTP/3. В первом случае при запросе через curl соединение сбрасывается на HTTP/2 протокол: curl --head --http3 https://example.com/test.txt HTTP/2 200 server: nginx/1.23.4 date: Fri, 31 Mar 2023 07:24:25 GMT content-type: text/plain content-length: 5 last-modified: Thu, 30 Mar 2023 18:51:19 GMT etag: "6425da27-5" alt-svc: h3=":443"; ma=86400 accept-ranges: bytes Во втором случае соединение зависает и curl начинает загружать ядро процессора на 100%. Конфигурацию и логи прикрепил в архиве. -- С уважением, Izorkin mailto:izorkin на gmail.com ----------- следующая часть ----------- Вложение не в текстовом формате было извлечено… Имя: nginx_debug.zip Тип: application/x-zip-compressed Размер: 11551 байтов Описание: отсутствует URL: