Forum OpenACS Q&A: Nsvhr and nsunix for AOLserver 3.3ad13 available

A new release of nsvhr and nsunix can be found at http://www.theashergroup .com/download/. This release of nsvhr and nsunix contains the following new features:
  • fixing of several memory leaks within the nsunix module
  • use of nssock's output routine within the nsunix module
  • new command, ns_vhr, to examine, start, stop proxy activity at runtime.
  • new menuUrl behavior: requests to hosts that are not found are redirected to the menuUrl
  • new menuUrl and errorUrl behavior: when redirected to these urls, a host parameter and error information is passed as query parameters
  • improved support for HTTP/1.0 clients: Specifically, the "location" parameter can now contain information regarding both nsunix and nssock connections, so that HTTP/1.0 clients can be presented a menu that contains appropriate direct PORT connections.

This release introduces the nsvhr command that can be used to examine, start, and stop nsvhr redirection at runtime. ns_vhr Overview
Find out information about an ns_vhr configuration, and/or start/top/modify a particular ns_vhr host.
Syntax ns_vhr names ?pattern

ns_vhr get ?pattern

ns_vhr delete host

ns_vhr update host location


ns_vhr names ?pattern similar to array names, returns the names (keys) of the hosts that are being proxied. If pattern is given, the host must match the pattern.

ns_vhr get ?pattern similar to array get returns the names and locations of the hosts that are being proxied. If pattern is given, the hosts must match the pattern.

ns_vhr delete ?host deletes a host from the proxying list. Requests for that host will not be proxied, but will be redirected to the errorUrl or menuUrl.

ns_vhr update ?host ?location updates (or adds) the host to the proxying list. Requests for that host will be proxied to the appropriate location.

Known Issues
The AOLserver implementation of nssock uses an internal buffer to help make network reads more efficient. Nsvhr needs to read the bytes out of this buffer in order to pass those bytes on to the nsunix module. This implementation of nsvhr adds a new socket layer communication procedure: ioctlProc, which has been implemented within nssock to both return the number of bytes in the internal buffer that can be read without requiring a new network read, and to close a socket immediately and not use the standard nssock graceful close procedures.

What does this mean? The communication driver structure increaed in size, with the new slot (at the end of the structure) being used to hold the driver ioctl proc. While it is probably safe to use an AOLserver with these patches with older modules, it is certainly the case that it is safer, to recompile all modules when using them within an AOLserver containing these patches.

Joshua Ginsberg reported a bug in nsvhr/nsunix: POSTs of binary data may fail with the first NULL. (I called Ns_DStringAppend instead of Ns_DStringNAppend)

Thank you Joshua!

The bug can be fixed with the patch I am including below.

If this patch gets munged in this post, you can find it at:

Index: nsvhr.c
RCS file: /cvs/ad33.13/aolserver/nsvhr/nsvhr.c,v
retrieving revision 1.2
retrieving revision 1.3
diff -r1.2 -r1.3
< static const char *RCSID = "@(#) $Header: /cvs/ad33.13/aolserver/nsvhr/nsvhr.c,v 1.2 2001/08/30 05:33:44 jerry Exp $, compiled: " __DATE__ " " __TIME__;
> static const char *RCSID = "@(#) $Header: /cvs/ad33.13/aolserver/nsvhr/nsvhr.c,v 1.3 2001/09/19 10:57:03 jerry Exp $, compiled: " __DATE__ " " __TIME__;
<         // Ns_LogDumpString(Dev, buffer, numRead);
>         Ns_LogDumpString(Dev, buffer, numRead);
< 	Ns_DStringAppend(&request, buffer);
> 	Ns_DStringNAppend(&request, buffer, numRead);
<     Ns_Log(Dev, "nsvhr: sending to unix:%s on socket %d: %d [%s:%d] bytes.",
>     Ns_Log(Dev, "nsvhr: sending to unix:%s on socket %d: %d bytes. [%s:%d] ",