>From: rst@ai.mit.edu (Robert S. Thau)
>Date: Tue, 4 Jul 95 11:49:19 EDT
>...
> *) More changes in alloc.c --- new cleanup_for_exec() function,
> which tracks down and closes all file descriptors which have been
> registered with the alloc.c machinery before the server exec()s a
> child process for CGI or <!--#exec-->. CGI children now get
> started with exactly three file descriptors open. Hopefully,
> this cures the problem Rob H. was having with overly persistent
> CGI connections.
Why not mark the fd's as close-on-exec, so that the kernel closes them for
you? It should be more efficient.
> *) Mutual exclusion around the accept() in child_main() --- this is
> required on at least SGI, Solaris and Linux, and is #ifdef'ed in
> by default on those systems only (-DFCNTL_SERIALIZED_ACCEPT).
> This uses fcntl(F_SETLK,...) on the error log descriptor because
> flock() on that descriptor won't work on systems which have BSD
> flock() semantics, including (I think) Linux 1.3 and Solaris.
I don't like the lock being on the error log; this has the potential of
being global to the system (consider multiple servers, single error log), and
may be on an NFS server. Instead, create a file in /tmp, unlink it and
use that file descriptor.
> *) For NCSA bug-compatibility, set QUERY_STRING env var (to a null
> string) even if none came in with the request.
I don't think this is a bug; in my version of the CGI spec
(<URL:http://www.ast.cam.ac.uk/%7Edrtr/cgi.html>) an unset variable is
the same as a null string. The argument is that http://x/a and http://x/a?
are identical URLs; the '?' is a separator, and is not part of the query_string
or path. So it does not seem particularly useful to encode the presence or
absence of the '?' by setting or unsetting the QUERY_STRING variable.
David.
|