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:
- HTTP/1.0 protocol, including proxy support via "If-modified-since"
(httpd is not a proxy server)
- HEAD, GET and POST methods
- Supports up to 8 simultaneous connections with fine-grain overlap
- Very fast, can deliver well over 25,000 requests/hour (4KB average,
486DX/66, VLbus Disk/Ethernet, Netmanage 4.0, Windows/Workgroups 3.11)
- Dual-mode CGI interface
- CGI 1.1 (modified) script interface using DOS Virtual Machine
- Experimental Windows CGI interface with form field decoding
- Server-generated directory indexes with type-specific icons, conforms
to formatting of current CERN and Unix NCSA servers
- Directory indexes can be annotated with HTML links & readme file
- Automatic extract of <TITLE>...</TITLE> string from
HTML documents for directory index descriptions
- Automatic mapping of MIME types to DOS file extensions
- URL aliasing and redirection permit disjoint document collections
to be mapped to a virtual directory tree as seen by the server
- Includes NCSA "imagemap" support (Windows CGI port), pre-configured
- Global and local document access controls
- Access authentication using the "real" Unix crypt() for passwords
- Password file maintenance utility runs from DOS command line
- WinSock 1.1 compliant, uses recommended asynchronous API
- WinSock "fallback" mode for sub-standard WinSock packages (single-session only)
- Efficient cooperative multitasking, will not bog down your machine,
or make clients wait on other clients' time-consuming transactions
- Common Log Format access log file
- Server can perform logfile "cycles" while running, up to 30 cycles
- Large integrated set of HTML documentation, including
authoring and administration references and primers
- WinCron utility included for logfile management and other periodic tasks
- Demo pages (also useful for initial checkout and examples) that
illustrate basic serving, ISINDEX, forms, image maps, password protection
- Extensive built-in tracing facilities to help diagnose problems
- Icon animation, shows when (and how many) people are using your server
Unix httpd 1.1 major features not supported:
- RFC 931 (TAP) identification
- PEM or PGP encryption
- Server-side includes
Unix httpd 1.3 major features not supported:
- Enhanced icon mapping for automatic directory indexes
- Server-side include enhancements
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>