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.