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: phttpd?
Date Thu, 18 May 1995 09:40:13 GMT
   Date: Wed, 17 May 1995 19:30:17 -0700 (PDT)
   From: Brian Behlendorf <brian@organic.com>
   Precedence: bulk
   Reply-To: new-httpd@hyperreal.com


   Anyone heard of or used/tested "phttpd"?  Written by a company in Sweden, 
   it's GPL'd for better or worse.  It's multithreaded and only runs on 
   Solaris right now.  It's at 

   http://www.signum.se/phttpd/

	   Brian

Hmmm... it suffers from a serious lack of documentation, it has some
quirks (do you really need to *reimplement* stdio on Solaris just to
make it thread-safe?) and its config file formats aren't back
compatible with anything.  Also, it *seems* a bit lacking in the
security department (I can't find anything which implements even HTTP
basic authentication, which is potentially worrisome in a server which
naively implements PUT and runs *.cgi files out of random directories
--- this probably isn't the monstrous hole I've just implied, if only
because it probably doesn't set the X-permission bits on the files,
but there may be something equally nasty lurking).

On the other hand, the code is *real* clean, it doesn't suffer from a
pox of global variables, and it has a loadable module structure whose
interface I don't quite understand but which might make a decent API
--- and I think APIs are likely to be important in the future.

BTW, I've been thinking a bit about what a cleaned-up NCSA-compatible
server might look like.  As you'll all recall from the discussion of
content negotiation, I tend to think in code on these matters
(noodling an hour here and an hour there to relax when I get fed up
with the robot), but really cleaning up the server is, unfortunately,
a much bigger job than CN.

My full wish list for this thing, which I'm tentatively calling
Hypatia (I wouldn't mind seeing it as Apache 3.0, or something, but I
obviously can't push it on the group) would be something like:

*) A decent API, which is adequate to implement replacements for much
   of the core server functionality.

*) Much of the core server functionality (certainly includes, dirs,
   SSI, and CGI, and hopefully auth/access) moved into modules which
   use the API.

*) An end to the global variable and MAX_STRING_LENGTH poxes.

*) NCSA back-compatibility wherever it isn't impossibly awkward.

*) Compool-style resource management.  (This is a technique used in
   some compilers --- gcc and lcc at least --- in which memory used to
   handle a particular statement, function, or (for a web server)
   transaction is allocated out of pools which keep track of what have
   been allocated, and freed en bloc once processing is over --- which
   means that you *don't* have to write code which obsessively tracks
   down and frees every byte of allocated storage in the face of such
   nastiness as transactions being killed on asynchronous timeouts).

I'll probably continue noodling --- (I *might* have something which
serves simple file requests in a week or two, if I'm not letting my
optimism run away with me), but while there are things I prefer about
the approach I've been taking (in particular, I've been trying to stay
NCSA back-compatible), it seems that phttpd includes at least several
of the above, weighted towards the top priority items...

(Incidentally, this is why I asked about wish lists earlier this week,
to try and get some pulse of the group about whether people share the
wish list above or not, and to what extent).

rst

Mime
View raw message