home *** CD-ROM | disk | FTP | other *** search
/ Borland Programmer's Resource / Borland_Programmers_Resource_CD_1995.iso / winsock / web4ham / web4doc.txt < prev    next >
Encoding:
Text File  |  1995-05-19  |  11.0 KB  |  331 lines
  1.         Web4Ham - A World Wibe Web Server
  2.            for the Windows Socket API
  3.             version  0.14
  4.              20-MAR-1994
  5.  
  6.             (c) Gunter Hille 1994
  7.         hille@informatik.uni-hamburg.de
  8.  
  9. This is the first alpha release of my WWW server for the Winsock API.
  10. There is nothing special about this server. Although I know that there
  11. already exists another WWW server (SERWEB), I wrote this program to test
  12. the asynchronous features of the Winsock API.
  13.  
  14. The following features are added to the server:
  15.     - handling multiple connections (not fully implemented)
  16.     - different paths for special hosts and networks
  17.       (can be used for special groups of hosts)
  18.     - server sends UDP hello packets
  19.  
  20.  
  21.             UDP hello packets
  22.  
  23. Before you read on:
  24.  
  25. To test the distribution of software packages in the Internet, I
  26. decided to add a small routine to the code of the server. The server
  27. will send UDP packets to my computer at the University of Hamburg.
  28. So I can see how many people do really use this program.
  29.  
  30. The interval of packets sent to me is long enough (several hours)
  31. not to disturb your local network or flood my computer with packets
  32. from all over the world.
  33.  
  34. If I see my program being run by many users (and not just being
  35. stored in dozens of ftp-servers), I will be definitely encouraged to
  36. improve it's performance.
  37.  
  38. As connectionless UDP packets are used (which might be lost on
  39. their way to Germany), there will be no problem, if your computer
  40. is behind a firewall, if your server is running on a PC not
  41. connected to the internet or if the PC at my office is switched off.
  42.  
  43. The messages sent to me just contain the version of the current server
  44. running, e.g. "Web4Ham/0.13". This feature might as well be useful
  45. if a version has a security bug. I can easily spot those sites running
  46. an old version of the software and inform the postmaster.
  47.  
  48. If you don't like this feature, you are free not use the program,
  49. or you might write me an Email message and I will tell you how to
  50. turn off this feature.
  51.  
  52. I recommend, that the idea of sending hello messages to another
  53. host should not be copied by too many other software developers.
  54. Otherwise there really might be the situation, that the Internet
  55. is flooded by UDP packets.
  56.  
  57.  
  58.         The Web4Ham logfile
  59.  
  60. All requests from clients are written to the file WEB4HAM.LOG.
  61. Only the first line of each request is written to the logfile 
  62. (with the new HTTP/1.0 protocol hundreds of bytes are sent to
  63. the server, sometimes outnumbering the size of a response).
  64. You can see everything the client is sending, if you set the LOGALL
  65. variable in the INI-file to the value 1.
  66.  
  67. The format of the logfile is identical to the logfile written by the 
  68. Go4Ham server (which will be soon updated to an asynchronous version).
  69. A typical logfile will look like this
  70. ("Rigel" is the hostname of my server at home):
  71.  
  72. 19940320,194953,"rigel","Web4Ham/0.14 started"
  73. 19940320,195020,"127.0.0.1","GET /maxmor.htm HTTP/1.0"
  74. 19940320,195020,"127.0.0.1","HTTP/1.0 200 ok"
  75. 19940320,195028,"127.0.0.1","c:\serweb/maxmor.htm 17274 bytes sent"
  76. 19940320,195140,"rigel","Web4Ham/0.14 stopped"
  77.  
  78.  
  79. Each line consists of 4 items. The first item is the date in the
  80. format YYYYMMDD, followed by the time in the format HHMMSS.
  81. The third item is the IP-Address of the client and the last item is
  82. the first line of the client's request. Start and stop messages from the
  83. server contain the name of your host. As this is an alpha version, the
  84. logfile might have error messages from the Winsock interface as well,
  85. they do not show up on the screen, they are just written to the logfile.
  86.  
  87. The status line of the server is witten to the logfile and if a request
  88. has been successful, the retrieved file and its length are logged as well.
  89. The status line messages will help you to locate invalid links to documents.
  90. The IP address is used to identify the connection (we have to add the socket
  91. number if the server is running asynchronous).
  92.  
  93. The logfile is written in SDF format, this format can be handled by
  94. many PC database and spreadsheet programs.
  95.  
  96.  
  97.         The Web4Ham.ini setup file
  98.  
  99. This file should be kept in the same directory than the WWW
  100. server program. All necessary initialization is done in this file.
  101.  
  102.         The [INIT] section
  103.         ==================
  104.  
  105. --------------------------------------
  106. [INIT]
  107. DataDir        = c:\www\others\world
  108. LogFile     = .\web4ham.log
  109. ErrFiles    = .\weber
  110. Debug       = 0
  111. Iconic         = 0
  112. Logall        = 0
  113. HTTPort     = 80
  114. --------------------------------------
  115. DATADIR        This is the default data directory if no match is 
  116.         found in the hostlists. Place your WWW documents
  117.                 in this directory (and in the subdirectories of
  118.                 the data directory).
  119.  
  120. LOGFILE        is the filename of the logfile. You better specify
  121.         the full path to it.
  122.  
  123. ERRFILES    is the path to the error files (prefix of filename).
  124.         you may change the name to any name with less than
  125.         six characters. The server relies on a complete
  126.                 set of files containing the error messages
  127.                 (e.g. WEBER200.HTM, WEBER201.HTM,...)
  128.                 The extension .HTM is mandatory.
  129.  
  130. DEBUG        you should set it to zero, I needed it for debugging
  131.                 in this alpha version.
  132.  
  133. ICONIC        =1 : if the server will start without opening a window.
  134.         =0 : to show client requests in a window
  135.  
  136. LOGALL        =0 : show first line of request only
  137.         =1 : show all lines sent by client
  138.  
  139. HTTPort        the listening port of the server (default: 80)
  140.  
  141.  
  142.         The Netmasks Section
  143.         ====================
  144.  
  145. -----------------------------------------
  146. ; keep this order: special hosts first!
  147. [255.255.255.255]
  148. ; dedicated hosts with full ip address
  149. 127.0.0.1       = c:\www
  150. 134.100.9.166   = c:\www
  151.  
  152. [255.255.255.0]
  153. ;other hosts in the following subnets
  154. 134.100.9      = c:\www\friends
  155. 134.100.8    = c:\www\friends
  156.  
  157. [255.255.0.0]
  158. ;other class B domains
  159. 134.100      = c:\www\others
  160.  
  161. [255.0.0.0]
  162. 44.0        = c:\www\others\ampr
  163.  
  164. ; hosts not in this section will have access to the default directory
  165. specified by the variable "DataDir"
  166. --------------------------------------------------
  167.  
  168. All directories must be considered as root directories for the 
  169. specified hosts, e.g. if a host has access to the directory 
  170. C:\WWW, he can access files in subdirectories of C:\WWW as
  171. well, but he cannot access a file in C:\ or C:\OTHER.
  172.  
  173. NEVER PUT COPYRIGHTED SOFTWARE OR PROTECTED DATA INTO THE DATA DIRECTORY!
  174. EVEN IF NO URL POINTS TO THE FILES, THEY CAN BE ACCESSED BY MALICIOUS CLIENTS!
  175.  
  176. Do not reorder the entries in brackets, they will always be scanned
  177. in this order. As the first matching entry will be allowed, do it the
  178. following way:
  179.  
  180. localhost and trusted hosts (in your domain) have access to the root data dir
  181. hosts of certain class B domains
  182. hosts of certain class A domains
  183.  
  184. No other netmasks than these three are allowed. Hosts not
  185. appearing in the list will only have access to the default directory
  186. specified in the [INIT] section as DATADIR.
  187.  
  188. Do not use host names or domain names, the server does not make
  189. use of DNS calls, as it was developed at home where no DNS access
  190. is available. This is the reason why you will find only IP numbers
  191. in the log file.
  192.  
  193. Remarks:
  194.  
  195. The way we are handling root directories might be not conforming to the
  196. HTTP protocol, because the same URL will point to different locations
  197. for different hosts. If we take the following URL
  198.  
  199. http://my.domain.de/home.htm
  200.  
  201. it  might be expanded to
  202.  
  203. C:/WWW/FRIENDS/HOME.HTM  or to
  204. C:/WWW/OTHERS/HOME.HTM
  205.  
  206. depending on the entries in the [255...] sections.
  207.  
  208. If we would use hostnames instead of IP addresses, then we could give
  209. different home pages for different countries, e.g.
  210.  
  211.   *.fr --> c:/www/french
  212.   *.de --> c:/www/german
  213.  
  214.  
  215.         The [SUFFIXES] section
  216.         ======================
  217.  
  218. ---------------------
  219. [SUFFIXES]
  220. HTM=text/html
  221. PS =text/postscript
  222. TXT=text/plain
  223. DOC=text/msword
  224. RTF=text/rtf
  225. ---------------------
  226.  
  227. If the query is done from a HTTP/1.0 client, the MIME contents
  228. type will be returned in the response. The contents type is based
  229. on the suffix of the file (left of the '=' sign) and the MIME type
  230. of the string following the equal sign in the [SUFFIXES] section.
  231. You might add further types if necessary.
  232.  
  233. The server does not recognize whether the client has the ability to
  234. view just a specific type and thus sends the file without converting
  235. it to another format.
  236.  
  237. If you know about Windows DLLs who can do file type conversion,
  238. please mail me the location of the archives and the names of the
  239. files.
  240.  
  241.         Implemented HTTP methods
  242.  
  243. Only the GET and the HEAD method of the HTTP/1.0 protocol are
  244. implemented. The server can identify the two HTTP protocol versions
  245. and will respond with the correct answer.
  246.  
  247. More methods will be implemented in future versions of the server.
  248. The RFC for the HTTP protocol is still preliminary and many methods
  249. cannot be coded if we rely on the RFC only.
  250.  
  251. *GET            LINK
  252. *HEAD            UNLINK
  253. CHECKOUT        CHECKIN
  254. SHOWMETHOD        TEXTSEARCH
  255. PUT            SPACEJUMP
  256. DELETE            SEARCH
  257. POST
  258.  
  259.  
  260.  
  261.             Error messages
  262.  
  263. All error messages sent to the client can be tailored to the needs 
  264. of your server (e.g. using another language). They follow a naming 
  265. scheme, a file named WEBERxxx.HTM will be sent to the client if 
  266. error xxx is encountered. Make sure that all error files are located
  267. in the directory of the server.
  268.  
  269. If an error file cannot be found, a HTML-message "Error file not 
  270. found" will be passed to the client and to the logfile.
  271.  
  272. The following status codes are defined in the protocol:
  273.  
  274. 200    ok
  275. 201    created
  276. 202    accepted
  277. 203    partial information
  278. 301    moved
  279. 302    found
  280. 303    method
  281. 400    bad request
  282. 401    unauthorized
  283. 402    payment required
  284. 403    forbidden
  285. 404    not found
  286. 500    internal error
  287. 501    not implemented
  288.  
  289.             Known bugs:
  290.             ===========
  291.  
  292. 1. Although the server is written with the help of asynchronous
  293.    Winsock functions, it processes connections in the order of their 
  294.    arrival.
  295.  
  296. 2. Hanging sessions will block other sessions arriving. But there is
  297.    a timer which will kill sessions if no further packets arrive and
  298.    the request is not yet completed. TELNET sessions sending less than
  299.    one character per 10 seconds will be cancelled. This is reported
  300.    in the logfile.
  301.  
  302. 3. The server ignores the methods which the client can accept.
  303.  
  304. 4. I have only two Winsock stack available, so the program was only
  305.    tested with these stacks, there might be problems with other stacks.
  306.    Alpha Testers, please report immediately.
  307.    (Trumpet and Netmage do work!)
  308.  
  309. 5. There will be two windows on your desktop when a connection
  310.    has been accepted. The WEB icon will be empty. Another window
  311.    contains the client's request and the messages of the server.
  312.  
  313. 6. My interpretation of the protocol is, that the following request
  314.  
  315.     GET / HTTP/1.0
  316.  
  317.    should be considered invalid, and an error will be returned.
  318.    You can put an anchor to your home page in the error file
  319.    WEBER404.HTM, so this is not a real bug.
  320.  
  321.  
  322.             History
  323.             =======
  324.  
  325. 20-MAR-1994    version 0.14 - first release for alfa testers.
  326.  
  327.  
  328.  
  329.  
  330.  
  331.