Mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@ai.mit.edu (Robert S. Thau)
Subject Re: Informing NCSA, archive of the list
Date Tue, 28 Feb 1995 11:20:23 GMT
   Date: Mon, 27 Feb 1995 17:44:25 -0800 (PST)
   From: Brian Behlendorf <brian@wired.com>

   I've set up a very simple mailbox archive, at 
   http://hyperreal.com/httpd/archive - I'll spend some time later tonight 
   to convert it to hypermail if I have time.  Would someone be willing to 
   summarize our current position and mail it to the list for the benefit of 
   new subscribers and the archive?  I nominate rst for this.

OK, Brian, you asked for it.  Here's my impression of the group
consensus on areas where I think there is a consensus, along with a
few important issues where I don't think a consensus has been reached.

>From the top:

NCSA httpd 1.3 was originally released the better part of a year ago.
Since this release (which came more or less with the departure of Rob
McCool to what is now Netscape), there hasn't been a new release of
Unix server software from NCSA.

However, 1.3 is not a perfect product, and in the absence of further
visible development from NCSA, a lot of people have found themselves
fixing or extending 1.3 to meet their needs --- in the process fixing
the same bugs and deficiencies over and over, at different sites.  For
instance, there are now three initgroups() patches floating around.
This group consists of people who've all had to patch 1.3 at one time
or another, either to extend server functionality, fix bugs, or
improve performance.

Our goal is to produce a revised version of NCSA 1.3 which has all the
popular fixes in it directly, in order to have a supported server
which actually meets our needs.

(In the meantime, NCSA has actually announced 1.4, which is now in
early beta.  What we do about this is our biggest unresolved issue).

Our current plan is to set up an RCS source tree someplace (probably
hyperreal.com), with the distributed NCSA server (which one?) as a
base.  We're going to apply patches to this, test the result, and when
it works, distribute it. --- probably under the name "Apache".  The
current consensus seems to be that we should have a review process for
which patches get applied, but the details remain to be hashed out.
(For instance, do we want an expedited process for simple bug-fixes,
of which an awful lot seem to be drifting by these days?)

[NB, that's not a consensus that your humble reporter particularly
*likes*, but it does seem to be the consensus].

As to the product, we seem to have decided to call it Apache.  (If
you're wondering about the name, say "Apache server" ten time fast.
Europeans may want to fake their best American accent while trying
this).  We may have just decided that the working sources will not
have #ifdefs around sections which are changed from the NCSA base
code, since RCS can generate the #ifdefs automatically whenever
required, and since some of the code would get awfully cluttered if
every bug fix had #ifdefs around it (particularly once we reach the
inevitable point of fixing bugs in our own code).  However, that was a
very recent discussion, and someone with serious objections may not
have spoken up.

Finally, I might as well start listing the various patches which I've
seen discussed here over the past few days, with a view towards
starting some kind of discussion about which we are actually going go
with in the immediate future.  Going just from memory, with apologies
to anyone with something critical which I left out, we have the
following:

Bug fixes:  (most available in multiple versions)

 *) The stack-scribbling security hole.  Note that there are two
    patches for this -- the CIAC/CERT patch, and the official NCSA
    patch.  The CERT patch makes the server processes substantially
    larger; the NCSA patch doesn't, but a lot of us don't trust it.

 *) Server always pauses 3 seconds for scripts which send a redirect,
    then gratuitously kills the process (which is probably dead anyway
    at that point).

 *) <!--#config timefmt --> server-side include doesn't always take.

 *) log files should be written with O_APPEND.

 *) when access control is "Limit"ed with "Order allow,deny", the
    server allows by default, making any Allow directives which may be
    present redundant.

 *) httpd can't handle numeric User specs in httpd.conf unless that
    uid appears in the passwd file.  If multiple usernames have the
    same uid, it sometimes sets group permissions with the wrong one.
    (Integrated with drtr's version of the initgroups() fix).

Performance enhancements:  (most available in multiple versions)

 *) Don't do initgroups() once per connection.  (But do redo it after
    rereading the config files).

 *) Don't do kernel read()s of one character, when reading MIME
    headers from clients, or script CGI headers.

 *) Don't do open_locale() and tzset() once per connection.  (These
    routines are called from C library time conversion code).

 *) Shared-memory name server cache.  [I have this, though it's less
    portable than it could be].

Functional enhancements:  (Note that many of these are still in the
process of being packaged up for submittal):

 *) DBM-based user databases for HTTP authentication. [Brian]

 *) New CGI variables (DOCUMENT_ROOT, SCRIPT_TRANSLATED_NAME). [Brian?]

 *) *.doit scripts (allows *any* URL to invoke a script, whether it
    ends in a magic *.cgi suffix or not). [rst]

 *) Logging User-agent and Referer, at least on errors. [Roy Fielding?]

 *) Load throttling --- reject incoming connections if load is too
    high. [Robert Evans]

If anyone has something *right* *now* that they'd like to see in an
early Apache release, which I haven't listed, this would be a good
time to step forward.

rst

Mime
View raw message