NCSA 1.5 --- a first look

["Robert S. Thau" <rs...@ai.mit.edu>]

I've spent some time over the past few hours looking over NCSA 1.5b3
(and over the bugs page, which contains at least a little information
on the way their 2.0 release is shaping up).  Sometime over the next
week, I'll be going over it to see if there are any fixes there to
bugs we still have.  In the meantime, some notes, in no particular
order (except 2.0 stuff grouped down below):

*) They changed the licensing terms; as I understand the new ones,
   commercial *use* is allowed, but redistribution for a fee is not,
   nor is sale of derivative works --- at least not without royalties.
   (NCSA 1.4 was PD, free and clear; the new release is different).

*) They've cleaned up the code a bit.  Most (but not all) of the
   globals holding per-transaction information are now fields in
   structures, there are separate header files for different code
   rather than a monolithic httpd.h, and some particular irritants
   ("unmunge_name" --- yeeeech!) have bit the dust.  Still, on the
   whole, it's a great deal closer to 1.4 than, say, Apache is.

*) At least one of the new features confuses me a bit; this is the
   "Satisfy" directive.  As I read the code, this specifies how
   "requires" lines taken as a group interact with allow/deny
   directives taken as a group; it does *not* specify how individual
   allow/deny or requires directives relate to each other.  So, for
   instance,

      <Limit GET>
      Satisfy all
      Allow from ncsa.uiuc.edu
      Allow from ai.mit.edu
      Allow from mcdonalds.com
      </Limit>

   would *not* somehow require a host to be in all three domains (and
   likewise for multiple requires lines).  However, the documentation
   is far from clear on this point.

   (It might have been better to choose a less generic name for this,
   at least if I'm right about what it does --- "NeedHostOrPassword"
   and "NeedHostAndPassword" might wear people out typing, but I bet
   they'd have fewer questions about them than they would about
   "Satisfy Any" and "Satisfy All").

*) Aside from Satisfy, it looks at first blush like the new
   authentication modes (including NIS-map, which seems to be new with
   1.5b3) can be done as Apache modules, though we might eventually
   want to move direct support for decoding what the client sends
   inwards towards the core (as is already done for HTTP Basic auth).
   The one that's the most of a stretch is Kerberos, for which there
   are some new CGI variables which the Kerberos check routines would
   have to dump in r->subprocess_env.

*) Process management is still done the same way --- there's an
   interesting item on the bugs page from someone who had set
   MaxServers to 10 and wanted to know why he had a hundred servers
   running.  (The fd-passing code is getting hairier, by the way;
   they've got something which uses the /proc filesystem on Linux,
   which looks pretty nasty... on the whole, I'm just as happy doing
   something else).




Finally, some interesting notes from Beth Frank on 2.0, and future
directions:

*) NCSA httpd 2.0 will not be a drop-in replacement for 1.x.  Nothing
   yet on how hard it will be to switch.

*) 2.0 will support an "authentication API" allowing people to slot in
   their own authentication code -- Beth actually says "Authentication
   API", which doesn't make it clear whether there will be APIs for
   other functions as well; also, from her description, it sounds
   vaguely as if the custom authentication code runs in a separate
   process from the server itself, but I could just be confused about
   that.  

   There's no sign of this yet in 1.5 --- check_auth() is still pretty
   monolithic.

*) In the future, they're going to try to move towards a concept they
   call the "Repository", which is apparently intended to leverage the
   current web technologies into something which more directly
   supports group activity and collaborative work.  That sort of thing
   requires extensive support on the client side to be effective (in
   terms of good authoring tools and the like); I take it that NCSA is
   actively working on those now as well.

rst