httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Candler <B.Cand...@pobox.com>
Subject Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
Date Mon, 05 Dec 2005 09:18:12 GMT
To add my 12 cents, I would like to see the following. (Note that I am
speaking from a mainly Apache 1.3 viewpoint; I'm pretty sure the following
didn't exist in 2.0 when I looked, but I've not checked whether any of these
have made it into 2.2 already)

1. In mod_cgi, an option for the stderr output from CGIs to be captured by
the parent and be sanitised before being passed to the real stdout.

"Sanitised" includes linewise buffering, escaping control charaters, and
having a prefix added to each line to include at least the timestamp and
vhost (preferably customisable a la CustomLog, since in my when I say
'vhost' I really mean '%{Host}i')

The reason is to allow CGI error logs to be written to a single open FD but
chomped and posted into per-user directories later, as is normally done with
access logs.

I believe this should be easy enough to implement, since AFAICS the Windows
version of mod_cgi already captures the stderr output explicitly.

2. Also in mod_cgi, after a CGI process terminates, be able to record the
process usage to stderr. This allows log processing to identify scripts
and/or users who are being silly buggers with CPU resources.

Something along the lines of:

            struct rusage ru;

            while (wait4(pid, &status, 0, &ru) == -1 && errno == ECHILD);
            gettimeofday(&after, 0);
            after.tv_sec -= before.tv_sec;
            after.tv_usec -= before.tv_usec;
            if (after.tv_usec < 0)
              after.tv_sec--, after.tv_usec += 1000000L;
            log_err("info: acct %ld %ld.%06ld %ld.%06ld %ld.%06ld %ld -- %d %s%s%s%s\n",
              (long)getuid(),
              after.tv_sec,
              after.tv_usec,
              ru.ru_utime.tv_sec,
              ru.ru_utime.tv_usec,
              ru.ru_stime.tv_sec,
              ru.ru_stime.tv_usec,
              ru.ru_maxrss,
              status,
              pt ? pt : cwd,
              pt ? " [" : "/",
              cmd,
              pt ? "]" : ""
            );

(where pt is PATH_TRANSLATED and cmd is the actual child process being
executed, so that you get more useful output when the child is just an
'Action' wrapper)

3. The ability to set ServerRoot in a vhost context. This is because a
number of paths are generated relative to ServerRoot, including those for
the access modules. At the moment, every .htaccess file has to have either

    # absolute path
    AuthUserFile /path/to/serverroot/x/y/z/private/myaccess

or

    # relative to serverroot
    AuthUserFile x/y/z/private/myaccess

which means that moving a virtual host around means messing with every
.htaccess file. Allowing ServerRoot to be set for each vhost would allow
them to contain

    AuthuserFile private/myaccess

instead.

4. The ability to force a call to suexec when invoking CGIs or SSI execs. At
the moment, suexec is only called if the vhost 'User' or 'Group' setting is
not equal to the server uid/gid. I have configs which use mod_rewrite and
set environment variables to the appropriate user/group, and a modified
suexec which uses them.

Unfortunately, I have to frig things otherwise suexec is not called at all:

    NameVirtualHost *
    <VirtualHost _default_:*>
    User            bin          # << arbitary user, different to httpd user
    RewriteEngine   On
    RewriteOptions  inherit
    </VirtualHost>

5. As a generalisation of (3) and (4): the ability to set ServerRoot,
DocumentRoot, User and Group from mod_rewrite [*]. This could be as simple
as having specially-named environment variables which override the default
vhost settings. This would make mass virtual hosting a helluvalot simpler.

[*] or from any module on a per-request basis, so that you can cleanly write
your own virtual hosting module. Perhaps the modules can create a temporary
instance of ServerRec with their own overriden values, but I don't think
ServerRoot currently allows this as it is a global setting.

6. A "sock:" RewriteMap type for mod_rewrite, like prg: but which opens a
Unix domain socket to squirt the query and receive the response instead of
forking a child. This means that hundreds of worker processes can share a
single lookup engine, perhaps holding a global cache.

You can do this now using prg: and a small external program which makes the
socket query, but that doubles the number of processes you have lying
around.

Regards,

Brian.

Mime
View raw message