On Sat, Feb 07, 2009 at 09:38:41PM +0100, Manlio P. wrote:
It can use a queue to store outgoing request, and if the queue grows too
much return a 503 Service Unavailable, setting Retry-After to a
reasonable (computed?) value.
No browser support 503 response, however.
I mean that using CGI as main response handler on highload site is
CGI may be used for lowload tasks: monitoring, administration, etc.
can be easly handled by Apache or by proxying to Apache.
There are two ways to implement CGI inside nginx:
- simple one: just fork()ing worker process that has received a request
for CGI and exec() a CGI program. It’s simple enough, but has a lot
of overhead. Besides CGI programs will run with worker privilege only.
Nginx could use seteuid, instead of setuid.
So that it can reacquire root privileges.
Yes, but it’s not so safe as setuid().
As for CGI support, some time ago I was trying to implement it.
The idea was to use unix domain sockets (socketpair), and reusing the
However I gave up, a lot of code for connection/upstream setup must be
rewritten, and I hate to write boiler plate code; and expecially having
to maintain it :).
Yes, CGI module should use modified upstream module.
In Nginx one can also easily close all current opened file descriptors,
in child process; Nginx keeps all opened connection in the
ngx_cycle->free_connections variable so one can write a closefrom function.
This can be resolved using fcntl(F_SETFD, FD_CLOEXEC) too.