home | O'Reilly's CD bookshelfs | FreeBSD | Linux | Cisco | Cisco Exam    

Book HomeApache: The Definitive GuideSearch this book

Appendix C. NCSA and Apache Compatibility

This email was sent by Alexei Kosut to the members of the Apache Group to explain the compatibility problems between the NCSA server and Apache 1.1.1.

There has been some discussion lately about the end of NCSA httpd development, and Apache replacing it for once and all, and so forth and so on...anyhow, I just thought I'd take this opportunity to point out what NCSA httpd 1.5.2 does that Apache does not currently do, feature and config-file wise:

  • NCSA supplements the Redirect directive with the RedirectTemp and RedirectPermanent directives, to allow for 301 redirects as well as 302. This is very simple to do.

  • NCSA optionally supports Kerberos authentication. I know there's a module out there that does as well; is it compatible with the NCSA syntax?

  • Speaking of auth syntax, NCSA's dbm implementation is different than ours. Namely, where we use:

    AuthUserFile /some/flat/file
    AuthDBMUserFile /some/dbm/file

    NCSA uses:

    AuthUserFile /some/flat/file standard
    AuthUserFile /some/dbm/file dbm
  • Satisfy. There are enough patches floating around; can't we just commit one already (one that works, hopefully)?

  • The KeepAlive syntax in NCSA httpd is different from ours. KeepAliveTimeout is the same in both, but we use KeepAlive where they use MaxKeepAliveRequests (and 0 means different things in the two), and they have an additional KeepAlive On/Off directive. It can be made to work, it just doesn't now.

  • NCSA supports CERN imagemap format as well as NCSA. Do we? (I forget. We should.)

  • NCSA supports SSI-parsed CGI output optionally. I don't think we should do this, at least not until 2.0 (SSI could be rewritten as a filter of sorts, implemented with a stacked discipline or some such).

  • You can use "referer allow|deny" in access control sections to deny or allow requests based on the Referer header. This is what mod_block.c (in /dist/contrib/modules) does, but with vastly different syntax.

  • Redirect doesn't require a full URL: if you omit the server name, it will redirect to the local server.

  • "Redirects in .htaccess files can now take regular expressions." I have no idea what this means, but that's what it says in the release notes. I can find no evidence of anything regular-expression-like in the code.

  • Built-in FastCGI support. This would be trivial; just grab mod_fastcgi and add it to the distribution (they even include a mod_fastcgi.html in just the right format to add to our docs. Nice of 'em). Their license even lets us do it without asking them first (though it would probably be polite to). This might be a good idea (or not; the thing's 97k, even larger than mod_rewrite and mod_proxy), FastCGI seems pretty nice and well-designed (even if half of their web site is an ad for their web server). Does anyone have any experience with it?

I think that's about it.



Library Navigation Links

Copyright © 2001 O'Reilly & Associates. All rights reserved.











??????????????@Mail.ru