Here's my configuration:
Trumpet Winsock Version 1.0 Rev B beta #6
PC Eudora 1.4
Win/QVTwsk 3.97
LAN Manager version 2.10
HTTPD v1.2b4 with the -n flag
And an example tale of woe:
I arrived in this morning to find httpd active[1].
The logs show a connection over 5 hours earlier, apparently to
http://www.bess.tcd.ie/ireland.html,
which had apparently gone into an infinite loop
(perhaps caused by a trailing / after a .htm filename?):
From access.log:
clark.net - - [26/May/1994:04:46:18 +-100] "GET /gaeilge.html HTTP/1.0" 200 1390
clark.net - - [26/May/1994:04:46:37 +-100] "GET /tourism.html HTTP/1.0" 200 916
solomon.technet.sg - - [26/May/1994:05:11:11 +-100] "GET /ireland.htm/ HTTP/1.0" 403 162
192.169.33.3 - - [26/May/1994:05:11:43 +-100] "GET / HTTP/1.0" 200 710
solomon.technet.sg - - [26/May/1994:10:28:33 +-100] "" 0 0
geordi.datastream.co.uk - - [26/May/1994:10:49:42 +-100] "GET /ireland.html HTTP/1.0" 200 2352
geordi.datastream.co.uk - - [26/May/1994:10:49:46 +-100] "GET /ireland.gif HTTP/1.0" 200 3952
From error.log:
[26/May/1994:05:11:10 +-100] httpd: will not follow link c:/httpd/htdocs/ireland.htm
[26/May/1994:05:11:10 +-100] httpd: access to c:/httpd/htdocs/ireland.htm/ failed for solomon.technet.sg, reason: client denied by server configuration
httpd.log is empty.
Info from Trumpet Winsock:
WINPKT packet driver located on vector $60
My IP = 134.226.88.35 netmask = 255.255.0.0 gateway = 134.226.88.1
IPQ in 0 free 15
TCP Sockets
S# TCB Local IP:Port Remote IP:Port INQ OUTQ State
2 0 134.226.88.35:21 0.0.0.0:0 0 0 listen
3 1 134.226.88.35:514 0.0.0.0:0 0 0 listen
4 2 134.226.88.35:80 0.0.0.0:0 0 0 listen
1 3 134.226.88.35:80 192.169.33.3:3897 0 0 closed
5 4 134.226.88.35:1075 134.226.1.28:25 0 0 established
6 5 134.226.88.35:1076 134.226.81.10:23 0 0 syn_sent
S#5 arose when I tried to send a message with Eudora,
which hung after establishing the connection to the SMTP server
S#6 arose when I opened a terminal session from QVT,
which got as far as opening the telnet window,
but did not present the login: prompt from the host.
At this stage, I tried to close httpd, which stopped responding to the system,
quickly followed by tcpman.exe, culminating with a GPF from Eudora in
winsock.dll at 0004:0AA9.
I had to reboot in order to restore any of my network services.
Perhaps this particular incident was caused by a bug relating to handling
of malformed URLs, but I've had similar behaviour many times in the past,
often from something as simple as closing the HTTPD.
I'll persist with HTTPD for another day or to before reverting to SerWeb,
but would appreciate any advice on tracking down the ultimate cause of the
problems.
Paddy Waldron (pwal...@tcd.ie)
--
Paddy Waldron, Department of Economics, Trinity College, Dublin 2, IRELAND.
E-mail: pwal...@tcd.ie
Telephone: +353 1 702 1667/+353 88 547 230
Fax: +353 1 677 2503