home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / www_text / www-servers.txt < prev    next >
Text File  |  1996-07-29  |  15KB  |  325 lines
  1.                           An Information Provider's Guide to Web Servers
  2.                             INTRODUCTION
  3.                                   
  4. This document is an introduction to the programs that provide
  5. information on the World Wide Web.  It is not an introduction to the Web
  6. --- see the parallel document ``World Wide Web Primer'' for this (see
  7. the section ``How to obtain this document'' for instructions on
  8. obtaining it).  It describes the current HTTP servers and their relative
  9. features, as well as discussing whether an HTTP is even necessary.
  10.  
  11. This document is available on the Web, as well as being posted
  12. fortnightly to the Usenet newsgroups comp.infosystems.www,
  13. alt.hypertext, news.answers, comp.answers and alt.answers.  It is
  14. available as LaTeX, plain ASCII, DVI and Postscript files via anonymous
  15. ftp.  For instructions on retrieving the latest version of this
  16. document, consult the last section, called ``How to obtain this
  17. document''.
  18.  
  19. This document was last revised on Wed Sep 15 15:26:45 NZT 1993by Nathan
  20. Torkington.
  21.  
  22.                           TABLE OF CONTENTS
  23.                                   
  24.     Introduction
  25.    
  26.     Table of Contents
  27.    
  28.     Hypermedia or Not?
  29.    
  30.     Load Generated by Hypermedia Servers
  31.    
  32.     CERN server
  33.    
  34.     NCSA server
  35.    
  36.     Plexus server
  37.    
  38.     Obtaining This Document
  39.    
  40.                          HYPERMEDIA OR NOT?
  41.                                   
  42. You will probably want to provide information in a hypermedia format
  43. (HTML) rather than plain text, because of the power of HTML.  Not only
  44. can you represent plain text in HTML, but you can also represent
  45. gopher-like menus, true hypertext (where certain words in a paragraph
  46. can bring up other pages), and hypermedia (where images and audio can be
  47. the destination of a hyper-link).  If you only want to provide plain
  48. text and menus, you might want to try something like gopher (which is
  49. accessable by Web browsers).
  50.  
  51. Running an HTTP isn't the only way to put hypermedia on the Web
  52. (browsers can access FTP sites and gopher servers).  This is because (on
  53. the Web) the protocol and the data format are different --- you can
  54. provide both hypermedia and plain text via FTP and HTTP.  Knowing this,
  55. you can decide how you want to provide information.
  56.  
  57. FTP servers have the benefit that they may already be set up at your
  58. site, they have reasonable logging, and automatic filename indexing (via
  59. archie).  There is a lot of behind-the-scenes overhead for the browser
  60. programs in obtaining files via FTP, however (the anonymous user and
  61. password need to be sent each time a file is retrieved). Because
  62. hypertext often consists of little files, with lots of links, this
  63. overhead may prove the deciding factor against using an FTP server.
  64.  
  65. Gopher also has automatic title indexing (Veronica), and a fairly simple
  66. setup struture (see Chapter n).  Because gopher's HTML type isn't
  67. recognised by gopher clients, hypertext cannot be easily served through
  68. gopher and for this reason I recommend setting up a gopher server only
  69. if you don't need to serve hypertext.
  70.  
  71. HTTP servers are geared toward hypertext, and because plain text is a
  72. degenerate case of hypertext they do equally well at serving plain text.
  73.  There are three main HTTP servers in use, and all three are briefly
  74. described below.
  75.  
  76.                 LOAD GENERATED BY HYPERMEDIA SERVERS
  77.                                   
  78. The load generated by the servers varies, depending on the task
  79. requested by the browser.  Resource intensive tasks such as searching
  80. files, translating between data formats, or starting other programs,
  81. will cause a larger load than simple document delivery.  In general, a
  82. well-used server such as that run by NCSA or CERN, should sit on a
  83. devoted low-to-mid-range machine, whereas less-used servers can exist
  84. quite happily on a multiuser machine.
  85.  
  86.                              CERN SERVER
  87.                                   
  88. CERN is a high-energy physics organisation, based in Switzerland. They
  89. started the World Wide Web project, and provided much of the initial
  90. software that helped it gain acceptance.  E-mail regarding the server
  91. should be sent to www-bugs@info.cern.ch.
  92.  
  93. Features
  94.  
  95.   Remapping of requests  This enables requests for files to remapped onto
  96.                       requests for other files, not necessarily on the
  97.                       same server.  For instance, I can specify in my
  98.                       rule file that requests for /cern/* can be
  99.                       remapped into requests for http://info.cern.ch/*
  100.                       and the server will remap requests anything in the
  101.                       /cern/ directory to requests for files from a
  102.                       machine in Switzerland.
  103.                       
  104.   Mapping from filename suffix to file type
  105.                       You can specify rules to convert file suffixes
  106.                       (.tex, for instance) for instance, onto MIME types
  107.                       (application/tex, in this case).
  108.                       
  109.   HTTP/1.0 ability       The initial, simple, implementation of HTTP had no
  110.                       way of specifying which data formats clients could
  111.                       cope with, which version of HTTP was being used,
  112.                       and no MIME typing.  HTTP/1.0 is a version of HTTP
  113.                       which does provide all these features (and more).
  114.                       
  115.   Ability to act as a gateway to WAIS
  116.                       Using the remapping above, wais: queries can be
  117.                       passed on to other machines.
  118.                       
  119.   Ability to act as a gateway through a firewall
  120.                       Also implemented using the remapping feature.
  121.                       
  122.   Both standalone and inetd capability
  123.                       Being able to be run ``standalone'' means that you
  124.                       don't have to be superuser to use it.  ``inetd''
  125.                       is a Unix system utility that provides a nice
  126.                       interface between TCP ports and programs, but
  127.                       requires superuser access to add programs to.
  128.                       
  129.   Automatically presents directory listings nicely
  130.                       When a browser requests a directory, rather than a
  131.                       file, the server will produce a menu of the files
  132.                       in the directory.
  133.                       
  134.   Support for README files
  135.                       If a browser requests a directory, and there is a
  136.                       README file present, the server will prepend the
  137.                       README file to the directory listing.
  138.                       
  139.   Multiformat documents  If you have the same document stored in multiple
  140.                       formats, the server will return a format that the
  141.                       browser can understand (if the browser is using
  142.                       the HTTP/1.0 protocol).
  143.                       
  144.   Logging                For each request, the server logs the date, time,
  145.                       IP number of the machine originating the request,
  146.                       and the text of the request (without the HTTP/1.0
  147.                       MIME information).
  148.                       
  149.   Access Control         Simple user authentication and access control is
  150.                       new in this version.
  151.                       
  152. The CERN server is available as
  153. ftp://info.cern.ch/pub/www/src/WWWLineMode_XXX.tar.Z where XXX is the
  154. latest version number.  It requires the CERN WWW library, available as
  155. ftp://info.cern.ch/pub/www/src/WWWLibrary_XXX.tar.Z where XXX is the
  156. library version number.
  157.  
  158. It will compile automatically for most systems.
  159.  
  160.                              NCSA SERVER
  161.                                   
  162. NCSA, the National Centre for Supercomputing Applications, is based out
  163. of the University of Illinois at Urbana-Champaign, in the USA. They are
  164. responsible for providing the Mosaic series of browsers, and
  165. accelerating the acceptance of Web browsers.  E-mail regarding the
  166. server should be sent to httpd@ncsa.uiuc.edu.
  167.  
  168. Features
  169.  
  170.   Simple                 It consists of less than ten source-code files,
  171.                       and is easy to install because of it.
  172.                       
  173.   Can operate from a gopher setup
  174.                       The server will map the gopher .cap and
  175.                       .linksfiles into menus, when directories are
  176.                       requested.
  177.                       
  178.   inetd and standalone support
  179.                       See the same section in the description of the
  180.                       CERN server.
  181.                       
  182.   Logging                For each request, the server logs the hostname of
  183.                       the machine originating the connection, the date,
  184.                       time, and the request (without the HTTP/1.0 MIME
  185.                       information).
  186.                       
  187.   HTTP/1.0 ability       See the same section in the description of the
  188.                       CERN server.
  189.                       
  190. Because of its extreme simplicity, the NCSA server will compile readily
  191. on most systems.  It is available in
  192. ftp://ftp.ncsa.uiuc.edu/Web/ncsa_httpd/.  It is a good place to start if
  193. you are already running a gopher server.
  194.  
  195.                                PLEXUS
  196.                                   
  197. Plexus is written by Tony Sanders (sanders@bsdi.com) and is written in
  198. perl (an interpreted language, suitable for most text-processing and
  199. system management tasks).
  200.  
  201. Features
  202.  
  203.   Written in perl        Because perl is an interpreted language, there is
  204.                       no compilation step between changing the code and
  205.                       running it.  Because of this, making changes to
  206.                       the code is quicker than changing (for instance)
  207.                       the CERN code.
  208.                       
  209.   Built-in setext, archie, calendar, manual page and finger gateways
  210.                       These provide excellent base services for a local
  211.                       server, as well as giving good indication on how
  212.                       to implement new gateways.
  213.                       
  214.   Easily extendable      The code is exceptionally easy to understand and
  215.                       add to, and perl is not difficult to learn.
  216.                       
  217.   Access control on a per-directory basis
  218.                       You can deny or permit access to files in
  219.                       directories based on the IP address/hostname of
  220.                       the machine the browser is running from.
  221.                       
  222.   Recommended only as stand-alone
  223.                       Because the perl interpreter is rather large, it
  224.                       is not recommended that Plexus be run from inetd
  225.                       (which would run perl for each connection),
  226.                       although it does have inetd support if you really
  227.                       want to do this.
  228.                       
  229.   Logging                For each request, Plexus logs the hostname of the
  230.                       machine originating the connection, the date and
  231.                       time, and the text of the request.
  232.                       
  233.   HTTP/1.0 ability       See the same section in the description of the
  234.                       CERN server.
  235.                       
  236. Perl is available in ftp://ftp.uu.net/pub/languages/perl/.
  237.  
  238. Configuring Plexus
  239.  
  240. (this section is for release 2 of Plexus.  Release 3 will probably have
  241. a different system).
  242.  
  243. The configuration for Plexus is done in the file plexus.conf, and via
  244. environment variables.  The environment variables are:
  245.  
  246.   $HTTPD                 The directory base from which the server can serve
  247.                       files.
  248.                       
  249.   $HTTPD_CONF            The configuration file (relative to the directory
  250.                       base).
  251.                       
  252.   $HTTPD_DEBUG           Whether debugging should be turned on.
  253.                       
  254. The variables to set in plexus.conf are:
  255.  
  256.   $http_support          This should be HTML that describes how to report
  257.                       errors.  For instance,
  258.                       '<ADDRESS>www-admin@vuw.ac.nz</ADDRESS>.
  259.                       
  260.   $http_homepage         The file (relative to the directory base above)
  261.                       that should be returned if the user requests
  262.                       http://host/
  263.                       
  264.   $http_index            The filename in a directory that should be
  265.                       returned if the user requests http://host/path/
  266.                       
  267.   $http_log              The filename to place log messages in.  This does
  268.                       not need to be relative to the directory base.
  269.                       
  270.   $http_indexdirs        Set to 1 if directories should be indexed, 0
  271.                       otherwise.
  272.                       
  273.   $http_chroot           If non-zero, the server should use the chroot()
  274.                       call.
  275.                       
  276. Also inside plexus.conf are the mappings which decide which HTTP
  277. commands are understood.  These look like:
  278.  
  279.  
  280.      $method{'get'} = "do_get";
  281.  
  282. Any mapping commented out with a # at the start of the line, will not
  283. have the corresponding command recognised by the server.  The mappings
  284. commented out in the distribution are the mappings which the server
  285. doesn't have code for (they are only included for completeness).
  286.  
  287. After the mappings in plexus.conf are the configuration options for the
  288. methods, the configuration options for the gateways, and the list of
  289. scripts to load.  Gateways are implemented by mapping URLs like
  290. http://host/specialstring/blah into a request for blah from the gateway.
  291.  These mappings are called translations, and are defined after the list
  292. of scripts to load.
  293.  
  294. The mapping from filename extensions to MIME content types is done
  295. through the list of assignments after the translations.  These all look
  296. like
  297.  
  298.  
  299.      $ext{'dvi'}   = $ext{'DVI'}   = 'application/dvi';
  300.  
  301. Similarly the MIME encoding definitions follow those for content types.
  302.  
  303. The remainder of plexus.conf is all internal to plexus and should not be
  304. changed.
  305.  
  306.                      HOW TO OBTAIN THIS DOCUMENT
  307.                                   
  308. The latest version of this document is always available on the Web as
  309. http://www.vuw.ac.nz/non-local/gnat/www-servers.html, and the most
  310. recently posted ASCII version will be available via anonymous FTP from
  311. rtfm.mit.edu in the directory /pub/usenet/news.answers/www as servers.
  312. The ASCII, LaTeX, DVI, and PostScript versions will be available via
  313. anonymous FTP from wuarchive.wustl.edu in the directory /doc/misc/www/.
  314.  
  315. This document is part of a series: ``World Wide Web Primer'', ``An
  316. Information Provider's Guide to HTML'', and ``An Information Provider's
  317. Guide to Web Servers''.  The other documents in the series are available
  318. from the archives above.
  319.  
  320. Please send feedback to the author, Nathan Torkington, at the e-mail
  321. address Nathan.Torkington@vuw.ac.nz --- all discussion will be treated
  322. as public domain and may be used in future versions of this document.
  323.  
  324.  
  325.