Windows httpd V1.3 Release Notes


Version 1.3Pre is the pre-production release of NCSA httpd for Windows. Features are now frozen, and all known bugs have been fixed. This Windows version was written by Bob Denny <rdenny@netcom.com>.

WinSock Bugs

Field tests have revealed weaknesses in some of the Windows Sockets packages that are in common use. My network I/O routines make use of features that were put into WinSock to permit concurrent transactions, and to minimize the impact of communications on the rest of the system. Also, httpd is a server, and therefore uses connection functions that are different from those used by client programs.

If you experience communication hangs, incomplete document deliveries, etc., try adding "-n" to the httpd command line. This disables multi-session support, disables all Windows efficiency optimizations, and reverts to simple blocking-mode operation. If this "cures" your problem, you need to gather evidence for submitting a bug report to your WinSock vendor.

Remove the "-n" and enable the network I/O tracing feature of httpd and look at the log. I will be glad to assist in interpretation. If it turns out to be a server bug, I'll fix it. If not, you'll have to live with single-session support and lower performance (with "-n turned on) until you can get your WinSock package fixed.

On the other hand, if httpd appears to work well except under heavy load conditions, it may be that the Windows "message queue" is overflowing. None of the WinSock packages I tested perform "reliable" delivery of event messages. Under heavy load with lots of concurrent requests for small documents, the message rate can be high, and the 8-message queue limit may be exceeded. Add the following to the [Windows] section of WIN.INI:

DefaultQueueSize=32
In any case, adding this will be harmless, so give it a try.

There are severe limitations with using COMMAND.COM as the shell for executing CGI scripts (see the scripting docs).

If you have Visual Basic, you can take advantage of the experimental native Windows CGI interface. As of this release, the interface between the server and Windows back-end programs is not a formal part of the CGI specification. All of the CGI-required data items, plus fully decoded Mosaic forms fields, are made available by the interface. Samples, including a CGI test "script" are included with the package, in the cgi-src directory. The file CGI.BAS contains a description of the interface, plus all of the code to handle setting up the CGI environment within Visual Basic. It is also possible to use other Windowsprogramming environments such as Access or FoxPro, but you'll need to get familiar with the environment using Visual Basic first.

Neither NCSA nor the authors are in a position to provide technical support for this server. Direct your questions and problems to the comp.infosystems.www USENET newsgroup. The authors do monitor this newsgroup, as do many other people who may be able to help you with questions and/or problems.

Server configuration and operation has been kept as similar as possible to the Unix httpd.


Features supported: Unix httpd 1.1 major features not supported: Unix httpd 1.3 major features not supported:
Changes since V1.2b8
  • Revealed the Windows CGI interface. Later beta versions had Windows CGI, but the names were different, and form decoding was handled differently. It was being used by some adventurous testers. The interface has changed since then. You must use the CGI.BAS that comes with this release!
  • Convert imagemap program to native Windows app. It runs much faster
  • Log only successful transactions
  • Fix "server too busy" message to be HTTP/1.0 and have error 503 header
  • Unset the BlockingHook, and free the proc instance, on shutdown
  • Fix BlockingHook function so program doesn't exit on a blocking mode timeout
  • Change reported version CGI protocol to include "(experimental)"
  • Added logfile cycling, triggered by WM_USER+13 message. See docs in the /support directory
  • Removed code that does shared open of access log. It was causing sharing problems. Logfile cycling is a much better solution to the problem or reading the logs while the server is running.
  • Added program and VB-callable DLL to do logfile cycling
  • Fixed 304 (not modified) response to return proper header and a useful message body. This was confusing the CERN proxy server
  • Fixed bug where server would abort without cleaning up if there was a problem opening the error or access logfile
    Return to the Overview
    Robert B. Denny <rdenny@netcom.com>