From uhog.mit.edu!news.mathworks.com!newsfeed.internetmci.com!info.ucla.edu!psgrain!nntp.teleport.com!usenet 30 Mar 1996 21:09:37 GMT Path: uhog.mit.edu!news.mathworks.com!newsfeed.internetmci.com!info.ucla.edu!psgrain!nntp.teleport.com!usenet From: Jerry LeVan Newsgroups: comp.lang.perl.announce,comp.lang.perl.misc Subject: MHTTPD a personal WWW server Followup-To: comp.lang.perl.misc Date: 30 Mar 1996 21:09:37 GMT Organization: Eastern Kentucky University, Richmond KY. Lines: 194 Approved: merlyn@stonehenge.com (comp.lang.perl.announce) Message-ID: <4jk7uh$rcf@nadine.teleport.com> NNTP-Posting-Host: julie.teleport.com Keywords: WWW,Perl X-Disclaimer: The "Approved" header verifies header information for article transmission and does not imply approval of content. Xref: uhog.mit.edu comp.lang.perl.announce:134 comp.lang.perl.misc:15520 Hello, I have written a small perl script that can function as a WWW server. Mhttpd enables an individual to serve their own documents and makes a nice platform for building and testing CGI scripts. The script runs on a Linux 1.2.10(a.out) Perl 5.002 system. Enclosed the the "documentation". The "package" can be obtained at http://eagle.eku.edu/pub/perl The filename is mhttpd-0.1.tar.gz It is not clear to me how to send the package to CPAN, could someone offer a clueless soul a hint? I would appreciate feedback, suggestions, bug and security fixes and enhancements. Thanks -- Jerry LeVan levan@eagle.eku.edu ********************************************************************************* MHTTPD a simple WWW Server for Unix Release 0.1 Jerry LeVan March 22, 1996 Preliminary Documentation Mhttpd is a simple perl script that provides most of the functionality of the more sophiscated WWW servers. It is only about 300 lines of perl code ( plus a bunch of comments and blank lines..) The distribution consists of three files: 1) mhttpd.doc This file. 2) mhttpd.conf A sample configuration file. 3) mhttpd The perl source for the daemon. Some of the features: 1) Support both GET and POST methods. 2) Will generate directory listings of directories in the "root" tree. ( not done if the directory contains the default document by default index.html, or the directory is marked as protected.) 3) Individual directories can be protected against directory listings. 4) Supports NCSA and CERN format mapping files for "clickable" images. 5) Supports server executables ( must live in the cgi-bin directory). 6) Supports "Forms". 7) Logs all accesses (also uses the ident protocol). 8) Has an easy to use IP based scheme to allow/deny access to the server. 9) It is very easy to configure. 10) Mhttpd supports directives. Known Problems: 1) Only tested on Linux 1.2.10(a.out) systems. You will probably have to do a little hacking to get it to run on other systems. 2) Startup code is sloppy, I handle the "zombie" problem by ignoring SIGCHLD upon death of the child. This probably will not work for many Unices. 3) Most of the work was done over a one week period, looking at the code will reveal a lot of ad hoc solutions (aka kludges). 4) Configuration ought to be handled by specifying a configuration file. Perhaps the next release. [..time passes..] OK, mhttpd must now be started by specifying a configuration file. See the sample configuration file mhhtpd.conf. 5) My handling of relocations is kludgy. If a relocation is detected and the URI starts with a "/" then I force a complete URI by prepending a "http://server:port" to the string. This forces an extra trip by the client. Configuration: The top part of the program has a section where some global variables are defined. One of the variables, $defaultConfigFile, can be set to the location of a configuration file. If no configuration file is specified at startup time, and this variable is the path name of a configuration file then that configuration file will be used. This should be the only variable you have to change in mhttpd. The rest of the configuration is done by setting values in a configuration file. The distribution contains a sample configuration file "mhttpd.conf" which must be edited in order to ensure proper operation of the server. 1) Decide which port your server will use. Remember that you must be root to use a port <= 1024. Set the variable $defaultport to the chosen value. This can be changed by specifying a port number on the command line at startup time. Running as root is discouraged in the most strongest way. 2) Decide where the "root" directory for your server will be loccated. You will need read access to this directory. The the variable $root to the full path name of this directory. Create a file "index.html" containing whatever you wish to "advertise" and place it in the root directory. ( or whatever you assign to $default ). 3) Decide where the "cgi-bin" directory will be located. This is where the executable scripts live. It can be outside of the root directory. Set the variable $cgibin to the full path name of this directory. 4) Decide which IP addresses will be allowed to access the server. The specification must use the "dotted" IP notation, any of the integer parts of the specification can replaced by '*' which will match any integer. Set the array @accesslist to this list. ex: @accesslist = ("157.89.*.*", "128.163.*.*"); The above list would allow any machine in the domain eku.edu and the domain uk.edu to access the server. Note the IP's must be quoted. 5) Decide which IP addresses will be excluded from using the server even if they pass the "accesslist" test. The format of the list is the same as the accesslist variable. Assign this list to the variable @denylist as above. The denylist will be scanned after the accesslist. 6) Decide which file name will be used to prevent the server from listing any directory that contains a file of that name. Assign that name to the variable $private ex: $private = "HIDDEN"; 7) Decide on the default file name and assign this name to the variable @default. ex: $default="index.html"; Index.html is the traditional name for this file. If a directory contains a file of this name, then the file will be returned by the server. 8) Decide on the name and location of the log file. Assign the variable $logfile the path name of this file. ex: $logfile = "/home1/faculty/user/obewan/httpd.log"; 9) Set $verbose = 1; If you wish to have the initial client dialog with the server written into the log file. ( The default value is zero.) Starting the Server: Starting the program, at least on linux systems, can be done in several ways: 1) mhttpd & The above command will try to find and use the configuration file specified by the variable $defaultConfigFile. 2) mhttpd -p nnnn & Start the daemon, use the configuration file specified by the variable $defaultConfigFile but use the port specified on the command line. 3) mhttpd -c & Start the daemon using the file specified on the command line. 4) mhttpd -p nnnn -c & Start the daemon using the file specified on the command line but use the port specified on the command line instead of the port specified in the configuration file. The program should start, and an entry will be made into the log file. The ps program should reveal something like "mhttpd(yourloginname:portnumber)". Stopping the server: To stop the program, get the pid from the ps program, and use the command "kill pid" The time of death will be noted in the log file. Rational: I had recently updated our Perl systems to release 5.002 and wanted to show my programming students some of the nifty things that can be done with Perl. Since the WEB is this years hot topic it seemed natural to combine the two ideas. I initially cast about the Perl Usenet News Groups for some guidence and found some scripts by Bob Diertens and Pratap Pereira ( See the credits in the source) I initially wanted a simple "Forms Server" so students could devise/debug their own forms without having access to the cgi-bin directories of our "offical" servers. It turns out that a "full blown" server is not that much more difficult to produce. Mhttpd will allow an indivdual to start their own server run their forms, devise new services and actually see the process. Perl offers an ideal platform for rapid prototyping. (The only drawback is that processes can become quite large, mhttpd requires two to three times the amount of core that the CERN or NCSA daemons use.) Mhttpd is not intended to be a "site" WWW server. ( I do not warrant the security of the program). The "m" in mhttpd stands for "mini". I hope it will be used and improved by individuals. Please remember the daemon is running under your uid and can access all of the files in the specified root directory tree ( I hope that is the case :) and hopefully no others. Please send me email with bug fixes, improvements, and what you think about the program. --Enjoy Jerry LeVan levan@eagle.eku.edu