		Web4Ham - A World Wibe Web Server
		   for the Windows Socket API
			version  0.14
			 20-MAR-1994

		    (c) Gunter Hille 1994
		hille@informatik.uni-hamburg.de

This is the first alpha release of my WWW server for the Winsock API.
There is nothing special about this server. Although I know that there
already exists another WWW server (SERWEB), I wrote this program to test
the asynchronous features of the Winsock API.

The following features are added to the server:
	- handling multiple connections (not fully implemented)
	- different paths for special hosts and networks
	  (can be used for special groups of hosts)
	- server sends UDP hello packets


			UDP hello packets

Before you read on:

To test the distribution of software packages in the Internet, I
decided to add a small routine to the code of the server. The server
will send UDP packets to my computer at the University of Hamburg.
So I can see how many people do really use this program.

The interval of packets sent to me is long enough (several hours)
not to disturb your local network or flood my computer with packets
from all over the world.

If I see my program being run by many users (and not just being
stored in dozens of ftp-servers), I will be definitely encouraged to
improve it's performance.

As connectionless UDP packets are used (which might be lost on
their way to Germany), there will be no problem, if your computer
is behind a firewall, if your server is running on a PC not
connected to the internet or if the PC at my office is switched off.

The messages sent to me just contain the version of the current server
running, e.g. "Web4Ham/0.13". This feature might as well be useful
if a version has a security bug. I can easily spot those sites running
an old version of the software and inform the postmaster.

If you don't like this feature, you are free not use the program,
or you might write me an Email message and I will tell you how to
turn off this feature.

I recommend, that the idea of sending hello messages to another
host should not be copied by too many other software developers.
Otherwise there really might be the situation, that the Internet
is flooded by UDP packets.


		The Web4Ham logfile

All requests from clients are written to the file WEB4HAM.LOG.
Only the first line of each request is written to the logfile 
(with the new HTTP/1.0 protocol hundreds of bytes are sent to
the server, sometimes outnumbering the size of a response).
You can see everything the client is sending, if you set the LOGALL
variable in the INI-file to the value 1.

The format of the logfile is identical to the logfile written by the 
Go4Ham server (which will be soon updated to an asynchronous version).
A typical logfile will look like this
("Rigel" is the hostname of my server at home):

19940320,194953,"rigel","Web4Ham/0.14 started"
19940320,195020,"127.0.0.1","GET /maxmor.htm HTTP/1.0"
19940320,195020,"127.0.0.1","HTTP/1.0 200 ok"
19940320,195028,"127.0.0.1","c:\serweb/maxmor.htm 17274 bytes sent"
19940320,195140,"rigel","Web4Ham/0.14 stopped"


Each line consists of 4 items. The first item is the date in the
format YYYYMMDD, followed by the time in the format HHMMSS.
The third item is the IP-Address of the client and the last item is
the first line of the client's request. Start and stop messages from the
server contain the name of your host. As this is an alpha version, the
logfile might have error messages from the Winsock interface as well,
they do not show up on the screen, they are just written to the logfile.

The status line of the server is witten to the logfile and if a request
has been successful, the retrieved file and its length are logged as well.
The status line messages will help you to locate invalid links to documents.
The IP address is used to identify the connection (we have to add the socket
number if the server is running asynchronous).

The logfile is written in SDF format, this format can be handled by
many PC database and spreadsheet programs.


		The Web4Ham.ini setup file

This file should be kept in the same directory than the WWW
server program. All necessary initialization is done in this file.

		The [INIT] section
		==================

--------------------------------------
[INIT]
DataDir		= c:\www\others\world
LogFile 	= .\web4ham.log
ErrFiles	= .\weber
Debug   	= 0
Iconic     	= 0
Logall		= 0
HTTPort 	= 80
--------------------------------------
DATADIR		This is the default data directory if no match is 
		found in the hostlists. Place your WWW documents
                in this directory (and in the subdirectories of
                the data directory).

LOGFILE		is the filename of the logfile. You better specify
		the full path to it.

ERRFILES	is the path to the error files (prefix of filename).
		you may change the name to any name with less than
		six characters. The server relies on a complete
                set of files containing the error messages
                (e.g. WEBER200.HTM, WEBER201.HTM,...)
                The extension .HTM is mandatory.

DEBUG		you should set it to zero, I needed it for debugging
                in this alpha version.

ICONIC		=1 : if the server will start without opening a window.
		=0 : to show client requests in a window

LOGALL		=0 : show first line of request only
		=1 : show all lines sent by client

HTTPort		the listening port of the server (default: 80)


		The Netmasks Section
		====================

-----------------------------------------
; keep this order: special hosts first!
[255.255.255.255]
; dedicated hosts with full ip address
127.0.0.1       = c:\www
134.100.9.166   = c:\www

[255.255.255.0]
;other hosts in the following subnets
134.100.9  	= c:\www\friends
134.100.8	= c:\www\friends

[255.255.0.0]
;other class B domains
134.100  	= c:\www\others

[255.0.0.0]
44.0    	= c:\www\others\ampr

; hosts not in this section will have access to the default directory
specified by the variable "DataDir"
--------------------------------------------------

All directories must be considered as root directories for the 
specified hosts, e.g. if a host has access to the directory 
C:\WWW, he can access files in subdirectories of C:\WWW as
well, but he cannot access a file in C:\ or C:\OTHER.

NEVER PUT COPYRIGHTED SOFTWARE OR PROTECTED DATA INTO THE DATA DIRECTORY!
EVEN IF NO URL POINTS TO THE FILES, THEY CAN BE ACCESSED BY MALICIOUS CLIENTS!

Do not reorder the entries in brackets, they will always be scanned
in this order. As the first matching entry will be allowed, do it the
following way:

localhost and trusted hosts (in your domain) have access to the root data dir
hosts of certain class B domains
hosts of certain class A domains

No other netmasks than these three are allowed. Hosts not
appearing in the list will only have access to the default directory
specified in the [INIT] section as DATADIR.

Do not use host names or domain names, the server does not make
use of DNS calls, as it was developed at home where no DNS access
is available. This is the reason why you will find only IP numbers
in the log file.

Remarks:

The way we are handling root directories might be not conforming to the
HTTP protocol, because the same URL will point to different locations
for different hosts. If we take the following URL

http://my.domain.de/home.htm

it  might be expanded to

C:/WWW/FRIENDS/HOME.HTM  or to
C:/WWW/OTHERS/HOME.HTM

depending on the entries in the [255...] sections.

If we would use hostnames instead of IP addresses, then we could give
different home pages for different countries, e.g.

  *.fr --> c:/www/french
  *.de --> c:/www/german


		The [SUFFIXES] section
		======================

---------------------
[SUFFIXES]
HTM=text/html
PS =text/postscript
TXT=text/plain
DOC=text/msword
RTF=text/rtf
---------------------

If the query is done from a HTTP/1.0 client, the MIME contents
type will be returned in the response. The contents type is based
on the suffix of the file (left of the '=' sign) and the MIME type
of the string following the equal sign in the [SUFFIXES] section.
You might add further types if necessary.

The server does not recognize whether the client has the ability to
view just a specific type and thus sends the file without converting
it to another format.

If you know about Windows DLLs who can do file type conversion,
please mail me the location of the archives and the names of the
files.

		Implemented HTTP methods

Only the GET and the HEAD method of the HTTP/1.0 protocol are
implemented. The server can identify the two HTTP protocol versions
and will respond with the correct answer.

More methods will be implemented in future versions of the server.
The RFC for the HTTP protocol is still preliminary and many methods
cannot be coded if we rely on the RFC only.

*GET			LINK
*HEAD			UNLINK
CHECKOUT		CHECKIN
SHOWMETHOD		TEXTSEARCH
PUT			SPACEJUMP
DELETE			SEARCH
POST



			Error messages

All error messages sent to the client can be tailored to the needs 
of your server (e.g. using another language). They follow a naming 
scheme, a file named WEBERxxx.HTM will be sent to the client if 
error xxx is encountered. Make sure that all error files are located
in the directory of the server.

If an error file cannot be found, a HTML-message "Error file not 
found" will be passed to the client and to the logfile.

The following status codes are defined in the protocol:

200	ok
201	created
202	accepted
203	partial information
301	moved
302	found
303	method
400	bad request
401	unauthorized
402	payment required
403	forbidden
404	not found
500	internal error
501	not implemented

			Known bugs:
			===========

1. Although the server is written with the help of asynchronous
   Winsock functions, it processes connections in the order of their 
   arrival.

2. Hanging sessions will block other sessions arriving. But there is
   a timer which will kill sessions if no further packets arrive and
   the request is not yet completed. TELNET sessions sending less than
   one character per 10 seconds will be cancelled. This is reported
   in the logfile.

3. The server ignores the methods which the client can accept.

4. I have only two Winsock stack available, so the program was only
   tested with these stacks, there might be problems with other stacks.
   Alpha Testers, please report immediately.
   (Trumpet and Netmage do work!)

5. There will be two windows on your desktop when a connection
   has been accepted. The WEB icon will be empty. Another window
   contains the client's request and the messages of the server.

6. My interpretation of the protocol is, that the following request

	GET / HTTP/1.0

   should be considered invalid, and an error will be returned.
   You can put an anchor to your home page in the error file
   WEBER404.HTM, so this is not a real bug.


			History
			=======

20-MAR-1994	version 0.14 - first release for alfa testers.





