Path: usenet.cis.ufl.edu!usenet.eel.ufl.edu!gatech!newsfeed.internetmci.com!info.ucla.edu!psgrain!nntp.teleport.com!usenet
From: Jerry LeVan <
[email protected]>
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:
[email protected] (comp.lang.perl.announce)
Message-ID: <
[email protected]>
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: usenet.cis.ufl.edu comp.lang.perl.announce:307 comp.lang.perl.misc:25637
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
[email protected]
*********************************************************************************
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 <ISINDEX> 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 <filename> &
Start the daemon using the file specified on the command line.
4) mhttpd -p nnnn -c <filename> &
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
[email protected]