On Fri, 7 Apr 1995, Mark J Cox wrote:
> I like Apache - its got lots of patches that I had also attempted! I just
> compared my patches with Apache and here are the differences: "things I'd
> like to see in Apache". I've got the patches for all of these - is there
> a mailing list for the Apache "team" yet? Some place you have your
> discussions?
Yup, I'm cc'ing them on this reply. If you want to subscribe, send mail
to majordomo@hyperreal.com with the words "subscribe new-httpd". It's
rather high volume so only subscribe if you know how to filter your mail
or whatnot :)
We're about ready to roll together a 0.5 (I think - guys?) with the aim
of using one more week to debug that without adding new features, and
then making a general release announcement. So, Wait until 0.5 comes out
before submitting patches for the below just yet... go to
http://hyperreal.com/httpd/newpatch/ to see how we're handling the patch
file submissions.
> SubAlias Patch (December 94)
> Useful for when I close off areas of my server, you can alias
> an entire sub-tree to point to a given HTML document (or CGI
> script). Adding a line SubAlias /fish /home/www/nofish.html to
> your config file would mean any accesses to /fish,
> /fish/fred.html, /fish/pike/tuna.html would all return the
> nofish.html document.
This would be very useful! I wish Alias could use real Perl-style regular
expressions, and then I forget we're not using Perl :)
> Other Patches (January 95)
> Added a couple of environoment variables for CGI scripts to
> use, DOCUMENT_ROOT and SERVER_ADMIN. Having the Server Admin
> email address is incredibly handy - if my CGI scripts detect
> errors they can mail server_admin rather than some hard-wired
> address.
We added DOCUMENT_ROOT - I definitely see a benefit in SERVER_ADMIN, too.
A little more general approach might be to allow people to specify extra,
static (meaning they are the same for every transaction) CGI variables in
srm.conf:
AddCGI SERVER_ADMIN brian@hyperreal.com
To avoid name space problems an X_ might have to be prepended....
> Indexing Patch (June 94)
> Patches to allow descriptions for files to be generated from a
> 4dos-like description file. Heres an example directory listing
> and the corresponding descript.ion and .README files. (MJC)
>
> Just like a BBS system :) Look at below for an example
> URL: http://www.telescope.org/rti/fits/
Sort of like an AddDescription but set on a per-directory basis like
.htaccess... what about allowing AddDescription in .htaccess?
> Referer Logging
> I use the field reserved for identd info (its too slow to have
> turned on) to store the Referer. Means in all my logs I can
> trace the paths of users.
We talked a lot about logging, customizable logging, etc etc. The
problem with making small changes here and there to the log file format
is that it suddenly is *not* in the Common Log Format, so log file
analysers could break. Your change would probably not break those, but
anyone who does care about identd info is fuct.
Given these constraints, and in lieu of a real configurable solution that
doesn't require a recompile with every change and that can also be fast,
I would probably support a patch that added referrer and user_agent to
the end of the log files - URL's can't have spaces so it should be safe
to keep them space-delinieated (but I don't think anyone follows the
recommended user_agent standard so I don't think we can come up with a
character to encapsulate user_agent within the same way the date is
encapsulated within [ and ]). This should be a config file switch, since
it will nearly double the size of the logfiles, and we should also
distribute a perl script that will strip away this info if requested.
I don't like NCSA 1.4's implementation at all - it logs these two bits
of info into two *separate* log files so you can't do any sort of
statistical correspondence with the accesses (NCSA correct me if I'm
wrong). Also, the default is to turn it on, and one has to explicitely
point it to /dev/null to turn it off. Ew.
> DBM Password Patch (November 94)
> Current .htpasswd and .htgroup files are inefficient. It can
> take 10 seconds to serve each page when there are more than a
> few hundred users. This patch allows a new type "BasicDBM" in
> the .htaccess file. Usernames, Passwords, Groups and other
> details are then stored in a DBM file with instant access.
>
> Now My DBM files are keyed on username with content of
>
> crypt_password:groups:anything[:...]
>
> Where groups are a comma separated list of groups. All my server
> uses the same DBM user file:
>
> AuthUserFile /extdisk/www-adm/dbmpasswd
> AuthName Submitting Jobs
> AuthType BasicDBM
>
> <Limit GET POST>
> require group rti
> </Limit>
>
> Just allows users with "rti" in their group fields in. Do you
> want the patch for this Brian? If you incorporate the group
> facility into Apache it will be worth me swapping over.
Hmm - I personally don't like this type of binding, as I can see situations
(indeed, we have them here) where those who want to be able to edit the
.htgroup file do not also have access to modify the password files. It also
puts more info in the content fields, which could bloat the size of the
password file (which is an issue for those of us with 160,000 users in our
database :)
I've documented the current implementation in 0.4 at
<URL:http://hyperreal.com/apache/docs/P14>... I feel it's as close to a
drop-in replacement for .htpasswd files as one can get.
> PS I found two things in Apache 0.4 that had to be fixed before it
> would compile
>
> in http_log.c it doesn't like the "default:" clause to be empty before the
> closing brace.
> in http_mime_db.c it doesn't like the structure definition around line 390
> it's pro
Were you compiling with -Wall, or were these actual problems that needed
to be changed before complete compile? What platform were you on?
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@hotwired.com brian@hyperreal.com http://www.hotwired.com/Staff/brian/
> I like Apache - its got lots of patches that I had also attempted! I just
> compared my patches with Apache and here are the differences: "things I'd
> like to see in Apache". I've got the patches for all of these - is there
> a mailing list for the Apache "team" yet? Some place you have your
> discussions?
Yup, I'm cc'ing them on this reply. If you want to subscribe, send mail
to majordomo@hyperreal.com with the words "subscribe new-httpd". It's
rather high volume so only subscribe if you know how to filter your mail
or whatnot :)
We're about ready to roll together a 0.5 (I think - guys?) with the aim
of using one more week to debug that without adding new features, and
then making a general release announcement. So, Wait until 0.5 comes out
before submitting patches for the below just yet... go to
http://hyperreal.com/httpd/newpatch/ to see how we're handling the patch
file submissions.
> SubAlias Patch (December 94)
> Useful for when I close off areas of my server, you can alias
> an entire sub-tree to point to a given HTML document (or CGI
> script). Adding a line SubAlias /fish /home/www/nofish.html to
> your config file would mean any accesses to /fish,
> /fish/fred.html, /fish/pike/tuna.html would all return the
> nofish.html document.
This would be very useful! I wish Alias could use real Perl-style regular
expressions, and then I forget we're not using Perl :)
> Other Patches (January 95)
> Added a couple of environoment variables for CGI scripts to
> use, DOCUMENT_ROOT and SERVER_ADMIN. Having the Server Admin
> email address is incredibly handy - if my CGI scripts detect
> errors they can mail server_admin rather than some hard-wired
> address.
We added DOCUMENT_ROOT - I definitely see a benefit in SERVER_ADMIN, too.
A little more general approach might be to allow people to specify extra,
static (meaning they are the same for every transaction) CGI variables in
srm.conf:
AddCGI SERVER_ADMIN brian@hyperreal.com
To avoid name space problems an X_ might have to be prepended....
> Indexing Patch (June 94)
> Patches to allow descriptions for files to be generated from a
> 4dos-like description file. Heres an example directory listing
> and the corresponding descript.ion and .README files. (MJC)
>
> Just like a BBS system :) Look at below for an example
> URL: http://www.telescope.org/rti/fits/
Sort of like an AddDescription but set on a per-directory basis like
.htaccess... what about allowing AddDescription in .htaccess?
> Referer Logging
> I use the field reserved for identd info (its too slow to have
> turned on) to store the Referer. Means in all my logs I can
> trace the paths of users.
We talked a lot about logging, customizable logging, etc etc. The
problem with making small changes here and there to the log file format
is that it suddenly is *not* in the Common Log Format, so log file
analysers could break. Your change would probably not break those, but
anyone who does care about identd info is fuct.
Given these constraints, and in lieu of a real configurable solution that
doesn't require a recompile with every change and that can also be fast,
I would probably support a patch that added referrer and user_agent to
the end of the log files - URL's can't have spaces so it should be safe
to keep them space-delinieated (but I don't think anyone follows the
recommended user_agent standard so I don't think we can come up with a
character to encapsulate user_agent within the same way the date is
encapsulated within [ and ]). This should be a config file switch, since
it will nearly double the size of the logfiles, and we should also
distribute a perl script that will strip away this info if requested.
I don't like NCSA 1.4's implementation at all - it logs these two bits
of info into two *separate* log files so you can't do any sort of
statistical correspondence with the accesses (NCSA correct me if I'm
wrong). Also, the default is to turn it on, and one has to explicitely
point it to /dev/null to turn it off. Ew.
> DBM Password Patch (November 94)
> Current .htpasswd and .htgroup files are inefficient. It can
> take 10 seconds to serve each page when there are more than a
> few hundred users. This patch allows a new type "BasicDBM" in
> the .htaccess file. Usernames, Passwords, Groups and other
> details are then stored in a DBM file with instant access.
>
> Now My DBM files are keyed on username with content of
>
> crypt_password:groups:anything[:...]
>
> Where groups are a comma separated list of groups. All my server
> uses the same DBM user file:
>
> AuthUserFile /extdisk/www-adm/dbmpasswd
> AuthName Submitting Jobs
> AuthType BasicDBM
>
> <Limit GET POST>
> require group rti
> </Limit>
>
> Just allows users with "rti" in their group fields in. Do you
> want the patch for this Brian? If you incorporate the group
> facility into Apache it will be worth me swapping over.
Hmm - I personally don't like this type of binding, as I can see situations
(indeed, we have them here) where those who want to be able to edit the
.htgroup file do not also have access to modify the password files. It also
puts more info in the content fields, which could bloat the size of the
password file (which is an issue for those of us with 160,000 users in our
database :)
I've documented the current implementation in 0.4 at
<URL:http://hyperreal.com/apache/docs/P14>... I feel it's as close to a
drop-in replacement for .htpasswd files as one can get.
> PS I found two things in Apache 0.4 that had to be fixed before it
> would compile
>
> in http_log.c it doesn't like the "default:" clause to be empty before the
> closing brace.
> in http_mime_db.c it doesn't like the structure definition around line 390
> it's pro
Were you compiling with -Wall, or were these actual problems that needed
to be changed before complete compile? What platform were you on?
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@hotwired.com brian@hyperreal.com http://www.hotwired.com/Staff/brian/