nginx + CGI

[MZ]

Если будет реализован первый вариант, то реализация второго тривиальна -
запускаем специальный nginx который будет заниматься только!
cgi-запросами, а дальше на него форвардить запросы по классической
схеме.
Этот специальный nginx может работать как в standalone режиме так и
запускаться отдельным воркером (аналог cgid в апаче2).

Ну и надо предусмотреть возможность работы такого воркера (который будет
обслуживать только cgi) из под рута для suexec, для standalone варианта
достаточно будет просто указать user root; в основном конфе.

В ср, 14/01/2009 в 13:08 +0300, Igor Sysoev пишет:
> On Tue, Jan 13, 2009 at 08:12:26PM +0300, Сергей Волков wrote:
> 
> > 13 января 2009 г. 17:28 пользователь Igor Sysoev <is at rambler-co.ru> написал:
> > 
> > > On Mon, Dec 29, 2008 at 08:17:19AM +0300, Khramov Anton wrote:
> > >
> > > > Я понимаю, что для _быстрого_ web сервера CGI не приемлем, но увы
> > > приходится изобретать велосипед в виде fastcgi -> cgi конвертера или nginx
> > > proxy -> mini_httpd.
> > 
> > > Нет. Реализация менеджера CGI в nginx'е - не самая тривальная задача,
> > 
> > Здается мне что написать некий nginx-cgid(FastCGI враппер) со всеми
> > прелестями suexec-ка плюс всякие чруты/улимиты написать не настолько сложная
> > задача. осталось найти писателя :-)
> > IMO данная софтулена мгновенно найдет своих потребителей, а nginx приобретет
> > удобную поддержку CGI приложений.
> 
> Это не сложная задача. Эта задача требует времени. Есть два решения:
> 
> 1) В лоб: воркер, который получил запрос для CGI, делает fork/exec.
> 
> 2) Правильное решение: специальный процесс, работающий от рута (для suexec),
>    которому через unix-сокеты передаются сокеты клиента, а он для них
>    делает fork/exec.
> 
> Второй вариант по сути ничем не отличается от nginx/mini_httpd, а вот
> времени на него мне жалко.
> 
>