Re: [proposal] SERVER_NAME в fastcgi_params
Все же понимают, что отсутствующий 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;
includefastcgi_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
>
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: [proposal] SERVER_NAME в fastcgi_params
и да и нет.
в конфиге сервера, приведенным топикстартером 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;
>>> includefastcgi_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
Re: [proposal] SERVER_NAME в fastcgi_params
В 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;
>> includefastcgi_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
Re: [proposal] SERVER_NAME в fastcgi_params
пн, 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;
> includefastcgi_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
Re: [proposal] SERVER_NAME в fastcgi_params
Да, т.к. 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; > > > 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 > ___ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru
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
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; > 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 > ___ 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: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 > ___ 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
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/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: [proposal] SERVER_NAME в fastcgi_params
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
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: [proposal] SERVER_NAME в fastcgi_params
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
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: [proposal] SERVER_NAME в fastcgi_params
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/ ___ 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
Мне кажется, что в 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
>
___
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
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/
___
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
Здравствуйте, Nikolay. Вы писали 5 марта 2023 г., 18:41:17: > При этом в самом конфиге сайта server_name не указан, сервер обслуживает все > доменные имена (фильтрация по имени осуществляется на фронтэнде). Видимо, надо потыкать в RFC разработчиков фронта и забыть о "проблеме" -- С уважением, Dmitry nginx...@ivanoff.spb.ru ___ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: [proposal] SERVER_NAME в fastcgi_params
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/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: [proposal] SERVER_NAME в fastcgi_params
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/ ___ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: [proposal] SERVER_NAME в fastcgi_params
On Mon, Mar 06, 2023 at 11:25:27PM +0300, Andrey Kopeyko wrote: > Николай, к потере вашего времени привело не несоблюление RFC (требовать > соблюдения которого в данном конкрентном случае - не очень правильно; тут > должно быть многа букв, расскажу голосом...), а Ваше непонимание разницы > между параметром конфига server_name и переменной запроса $http_host. > > Сожалею о Вашем потерянном времени. > > Приходите в офис, всё расскажу. Расскажите лучше здесь. В том числе тем, кто не может и не хочет ходить в офис (чай на дворе не средние века, а видеосвязь давно изобрели). > Вот дописать в доку статью "о (вреде и) подводных камнях обработки запроса в > дефолтном сервере" - наверное, было бы полезным. Обратите внимание на то, что интерес инициатора треда заключался не в том, чтобы изучать разнообразные грабли, а в том, как один конкретный камень убрать с проторенной дороги. Идеально сделанный интерфейс не допускает никаких подводных камней, противоречий и неоднозначностей. Им просто пользуешься и "всё работает". То же самое должно быть и с дефолтным конфигом. А если камни всё-таки вылезают, нужно в первую очередь думать о том, как их устранить, и в последнюю -- о том, как их документировать. -- Eugene Berdnikov ___ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: [proposal] SERVER_NAME в fastcgi_params
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 ___ 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 г. в 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 > ___ 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
On Mon, Mar 06, 2023 at 07:40:49PM +0100, Илья Шипицин wrote: >а есть непустое множество тех, кто уже пользуется, и вы поменяете им >поведение после апгрейда. Неужели? И как же оно поменяется? Поставим лучше вопрос так: что у них сломается и почему? -- Eugene Berdnikov ___ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: [proposal] SERVER_NAME в fastcgi_params
пн, 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 > ___ 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 г. в 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 > ___ 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
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
Re: [proposal] SERVER_NAME в fastcgi_params
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 ___
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
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 ___
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 г. в 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 > ___ 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
Re: [proposal] SERVER_NAME в fastcgi_params
Добрый день. 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 ___ 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
