httpd.conf(5)


NAME
     httpd.conf httpd.mtype - configuration files  for  the  Minix  httpd  web
     server

SYNOPSIS
     /etc/httpd.conf /etc/httpd.mtype

DESCRIPTION
     /etc/httpd.conf is the configuration file for the Minix httpd web  server
     written  by  Michael  Temari.   A  sample  version  is  included with the
     distribution archive and is unpacked in the  source  directory  (normally
     /usr/local/src/httpdxxx).   Also provided is an example httpd.mtype file.
     This is an extension of the main configuration  file  which  is  normally
     included when the main file is read.

     The makefile does not install httpd.conf and  httpd.mtype  automatically.
     The sample files included in the distribution are only examples, you must
     copy and edit them for the needs of your own installation.

CONFIGURATION FILE FORMAT
     httpd.conf is an ascii file which consists  of  lines  of  the  following
     form:

     directive LWS [parameters separated by LWS]
     NOTE: LWS denotes Linear White Space which is spaces and/or tabs

CONFIGURATION FILE DIRECTIVES
     The following are valid configuration  file  directives  (listed  in  the
     order  they  appear  in  the  sample  httpd.conf  file  provided  in  the
     distribution):

     serverroot redirect user chroot logfile  dbgfile  dirsend  direxec  vhost
     auth proxyauth vpath include mtype

     To make the file more readable,  for  directives  which  occupy  multiple
     lines  you may eliminate the directive on lines after the first and begin
     these lines with LWS.


DESCRIPTIONS OF DIRECTIVES

     serverroot path

     The serverroot directive sets the translation for // to the given path.

     redirect url

     The redirect directive will redirect the entire website  via  error  code
     "301 MOVED PERM" to specified url and original path of request.

     user username

     The user directive causes  the  server  to  run  as  the  given  username
     otherwise the server will run as whoever started it (normally root).

     chroot directory

     The chroot directive causes the server to chroot to the  given  directory
     after  the  configuration  and log files have been opened.  Normally this
     will be the home directory of the given username in the user directive.
     NOTE: /~user will be translated to the home directory of user.
     NOTE:  // will be translated to the serverroot directory.
     NOTE: if this directive is used then beware of the consequences.

     logfile filename

     The logfile directive tells the server where to log http transactions.
     NOTE: the log file must exist to enable logging.

     dbgfile filename

     The dbgfile directive tells the server where to  log  debugging  of  http
     transactions.
     NOTE: the debug log file must exist to enable debug logging.

     dirsend filelist

     The dirsend directive tells the server that when a directory is requested
     that  it  should  send the first file that it finds in the directory from
     the filelist for the request.

     direxec program

     The direxec directive tells the server that when a directory is requested
     and  no  file  is found from the dirsend directive that it should run the
     given program.
     NOTE: the program normally generates a directory listing on the fly using
     the dir2html program.
     NOTE: the program access is considered X with no access restrictions.

     vhost hostname vhostroot

     The vhost directive is for defining access for virtual  hosts.   If  none
     are  configured  then  any host is accepted.  If specified then access is
     only granted for requests for hosts which are configured  here.   In  the
     vpath  section  below  the  ///  gets  translated  to  the  corresponding
     vhostroot.


     auth authname authdescription access [passwdfile [users]]
     The auth directive sets up different authorizations with the server.  The
     authname  is the name given to the authorization and is case insensitive.
     The authdescription is the description of the authorization and  is  what
     the  user  will  see  when  asked  to enter a username and password.  The
     access is one or more of (RWX). R tells the server the URL can be read. W
     tells  the server the URL can be overwritten. X tells the server that the
     URL can and should be executed.  Access is in  addition  to  normal  Unix
     security considerations.  For instance a file that can be written to that
     does not have the W access will have an error returned.   The  passwdfile
     is  the  name  of  the  password  file  to  validate  users  against.  If
     passwdfile is given as '.' then the system  password  file  (/etc/passwd)
     will be used.  If no passwdfile is given then no authorization is allowed
     for anyone.  If no users are given then any validated user is authorized,
     otherwise only the given users are allowed.

     proxyauth authname authdescription access [passwdfile [users]]

     The proxyauth directive defines access authorization to be used for Proxy
     access.
     authname = Same as auth above
     authdescription = Same as auth above
     access = Must be R to allow proxy
     passwdfile = Same as auth above
     users = Same as auth above

     vpath from to [auth [access]]

     The vpath directive sets up URL path translations and authorizations.   A
     requested   URL that matches from will be translated to to with the given
     auth and access. If auth does not exist then the URL will have no access.
     If access is not given then the access is taken from the auth record (see
     above).  A '.' in place of the to means that  the  server  should  use  a
     translation  from  another vpath record, but associate the given auth and
     access with the requested URL.  A '*' may be at the end only of the  from
     to  provide  a wildcard match.  For example if the from has /AB* then any
     of /ABCDEF or /AB or /ABmichael will match, but /AD or /a will not.   The
     requested  URL  is first checked against each vpath record until an exact
     match (meaning URL match from and from had no '*') is found or the end of
     the  list.   Therefore  a  wildcard match will match the last from in the
     list in which it matched.
     NOTE: if at the beginning of the to field
           /~user will get translated to the home directory of the given user
           // will get translated to the serverroot directory

     include filename

     The include directive tells the server to read configuration  information
     from the given filename.
     NOTE: normally you get mtype directives in an included file.

     mtype mimetype extensions

     The mtype directive tells the server  what  mimetype  to  associate  with
     files  which  have any of the given extensions. If no match is found then
     the file will be treated as application/octet-stream.



FILES
     /etc/httpd.conf /etc/httpd.mtype /etc/passwd

SEE ALSO
     httpd(8) http_status(5)

NOTES
     The  source  directory  contains  a  commented  sample   httpd.conf   and
     httpd.mtype files.

     You can run the server as httpd -t /etc/httpd.conf  to  see  whether  the
     configuration file is being parsed correctly.

     Although standard Minix does not have a graphical  interface  to  support
     browsers  such  as  Netscape  and  Microsoft  Internet Explorer, the lynx
     browser can be used on 32-bit Minix systems with enough memory.  You  can
     point  lynx  to your own site to browse your own pages.  When debugging a
     web server there is nothing quite like browsing your  own  pages  to  see
     whether  things are working right. That said, be aware that different web
     browsers may vary in how they interpret standard web page  features,  and
     will  certainly  vary  in  how  they  interpret  "extensions" to the HTML
     standards. So checking a page with several browsers on several  platforms
     is always a good idea.

BUGS
     Not really a bug, but you can get in trouble if a real directory you want
     to  access shares the first part of its name with a vpath definition. You
     just have to pay attention to the directory names you use.

AUTHOR
     The Minix httpd server was created by and is maintained by Michael Temari
     <Michael@TemWare.Com>

     This man page was compiled by Al Woodhull <asw@woodhull.com>


VERSION NOTE
     This man page is applicable to Minix 2 and Minix 3 releases through Minix
     3.1.2a. This page was not part of the standard set of man pages for Minix
     releases through Minix 3.1.2a.