httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@ai.mit.edu (Robert S. Thau)
Subject Re: Apache 0.8?
Date Sun, 16 Jul 1995 11:31:23 GMT
   Date: Sat, 15 Jul 1995 20:14:48 -0700 (PDT)
   From: Brian Behlendorf <brian@organic.com>

   Are there any other changes to the documentation on www.apache.org that 
   we should do before the official release of 0.8 next week?

It would be nice to update the VirtualHost docs to indicate that you
can now stick other httpd.conf and srm.conf commands in there, in
addition to those explicitly listed in the current documentation.
Mkgray's new logging modules are undocumented, as is Randy's imagemap
module (I presume we'll want to release with both of those).  There's
also 'TransferLog "| ..."', but given all the caveats on it, the best
thing may be to leave that undocumented for the moment.  API docs are
still incomplete, but I'm resigned to that at this point.

   I have 
   Shambhala running on hyperreal now and have seen no problem with it -
   it's also on Organic, HotWired,

Hmmm... HotWired still calls itself Apache 0.6.1 when I ask, but it
may be lying.  (I hope so --- it would be nice to know it's been
tested on Irix).

   and Links.net now, dishing up a million 
   hits yesterday between all of us without a noticeable problem.  I also 
   wrote to the webmaster at playboy.com asking him if he'd consider 
   switching to shambhala :) 

Well, I've listed below what's in my current development sandbox.
This stuff all passes smoke tests at least, and I'm running with it on
my main server --- it includes several bug fixes, and one new feature
(adapting the number of server processes to ongoing activity) which
*seems*, at least to be working nicely.  I should have a new snapshot
with all of this stuff (also mkgray's logging modules and, if you're
lucky, at least a crude config script) by this evening.

(The hairiest of these changes is the scoreboard-based regulation of
the number of active servers.  I'm a bit antsy about this, but it's
already tested and seems to work well, and the code should be *very*
portable --- the most obscure thing it uses is mktemp()).

   RobT, if there's any release engineering you'd rather not do, let me know 
   and I can finish it up.  How does everyone feel about a monday morning 
   release?  

Hmmm... the stuff that has to be done at this point is mostly
packaging, but even packaging needs time to be done right (and at
least a little testing --- at the level of unpacking it somewhere
other than where it was built, and doing enough with it to determine
that no essential pieces were omitted).

As for things I'd rather *not* do --- there are two; building a *full*
distribution (which actually should involve nothing more than taking
0.[67].x and replacing the 'src' directory), and also, perhaps,
switching the license text everyplace to something with a disclaimer
paragraph which has been looked over by a Real Lawyer (such as the
Berkeley license text included below); that second one would
presumably have to at least be run up the flagpole to see if anyone
objects, though I sincerely doubt anyone would.  If you want to do
that, feel free...

rst

PS --- the attachments:  work completed in my sandbox [this should
be it for changes to server code, barring new modules and further bugfixes].

  *) Scoreboard mechanism for regulating the number of extant server
     processes.  MaxServers and StartServers defaults are the same as
     for NCSA, but the meanings are slightly different.

     Before asking for a new connection, each server process checks
     the number of other servers which are also waiting for a
     connection.  If there are more than MaxServers, it quietly dies
     off.  Conversely, every second, the root, or caretaker, process
     looks to see how many servers are waiting for a new connection;
     if there are fewer than StartServers, it starts a new one.  This
     does not depend on the number of server processes already extant.
     The accounting is arranged through a "scoreboard" file, named
     /tmp/htstatus.*, on which each process has an independant file
     descriptor (they need to seek without interference).

     The end effect is that MaxServers is the maximum number of
     servers on an *inactive* server machine, but more will be forked
     off to handle unusually heavy loads (or unusually slow clients);
     these will die off when they are no longer needed --- without
     reverting to the overhead of full forking operation.  There is a
     hard maximum of 150 server processes compiled in, largely to
     avoid forking out of control and dragging the machine down.
     (This is arguably too high).

     In my server endurance tests, this mechanism did not appear to
     impose any significant overhead, even after I forced it to put the
     scoreboard file on a normal filesystem (which might have more
     overhead than tmpfs).
   
  *) Set HTTP_FOO variables for SSI <!--#exec cmd-->s, not just CGI scripts.
     [Bug reported by Cliff Skolnick]

  *) Read .htaccess files even in directory with <Directory> section.
     (Former incompatibility noted on mailing list, now fixed).

  *) "HEAD /" gives the client a "Bad Request" error message, rather
     than trying to send no body *and* no headers.  [Cliff again].

  *) Don't produce double error reports for some very obscure cases
     mainly involving auth configuration (the "all modules decline to
     handle" case which is a sure sign of a server bug in most cases,
     but also happens when authentication is badly misconfigured).

  *) Moved FCNTL_SERIALIZED_ACCEPT defines into conf.h (that's what
     it's *for*, and this sort of thing really shouldn't be cluttering
     up the Makefile).

  *) Incidental code cleanups in http_main.c --- stop dragging
     sa_client around; just declare it where used.
  
  *) Another acc-related fix from Mark Cox.  (It doesn't like const char
     in some places...).

Berkeley warranty disclaimer (note all caps):

# THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
# ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
# SUCH DAMAGE.


Mime
View raw message