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
