CTDATA has experienced a problem getting a CGI-based custom error response handler to work properly on Netscape Enterprise Server version 3.63 running on Windows NT 4. We are attempting to implement this error handler as a part of a multi-stage migration off of this platform to a LAMP-based server that is patched to current standards.
Read on for more details:
Background
Problem
Solution
Background
At CTDATA, we are trying to migrate some of our web sites from a server that runs Netscape Enterprise Server version 3.63 on Windows NT 4. Our ultimate goal is to move these web sites to a LAMP platform within the next two months.
In order to do this, we have to migrate from a proprietary content management system based on the Slash Open Source Project to a content management tool that is LAMP-compatible. We have chosen MovableType because of its simplicity and platform neutrality.
In order to preserve links to the valuable permanent content on our web sites, we had to develop a migration strategy that allows us to redirect visitors from the old URLs generated by the Slash system to the new URLs generated by the MovableType system. This is why we decided to write a custom error response handler.
Problem
We got the idea for writing the custom response handler from the document called Trapping CGI Script Abuse. This article does not solve the problem that we are trying to solve, but it shows how to write a custom error response handler for both Apache and iPlanet / Netscape Enterprise Server.
While "Trapping CGI Script Abuse" explains how to configure the iPlanet / Netscape Enterprise Server, the configuration it suggests does not work on the Windows version of Netscape Enterprise Server. In order to detemine this, we did the following:
- Wrote a simple Perl script that runs properly from the server's Windows command line.
- Logged into the server's iPlanet / Netscape Administration Server, chose the proper Enterprise Server instance, selected the "Server Preference" tab, then the "Error Responses" from the sub-menu.
- Found the Error code: Not Found entry in the Error Responses form, and entered the full Windows path to the CGI program.
- Checked the "CGI" checkbox below the filename that we just entered.
- Saved and applied the changes.
- Entered a URL that did not point to a valid page on our server into a web browser window.
When we did this, we expected the CGI program to execute properly. Instead we got an uncustomized 404 error:
Not found
The requested object does not exist on the server. The link you followed is either outdated, inaccurate, or the server has been instructed not to let you have it.
In addition, we found that the web server's error log said:
failure: (process number) : cgi_send:cgi_start_exec {full windows path to CGI program} failed
This was followed by hours of Google searches, hoping to uncover a document that would provide some insight into why the approach suggested by Advosys did not work on Windows.
Solution
As is the case with many perplexing problems, the answer came to us after entirely stopping work on it for several hours, and temporarily focusing on other problems.
One of the recurring themes of working with CGI programs on Netscape Enterprise Server for Windows is that there are differences between the way regular CGI and so-called shell CGI programs are handled. Shell CGI programs depend upon Windows file system associations between file types and programs that execute them. For example, the Perl executable is associated with files ending in .pl.
However, we recognized that the Error Response form in Netscape Enterprise Server provided a "CGI", not a "Shell CGI" designation. So, we tried wrapping the Perl program in a Windows batch file. We created a program called redirect.bat with the following content:
@echo off
C:\Perl\bin\perl.exe {full path to the redirect.pl program}
{Note that C:\Perl\bin\perl.exe is the full path to the Perl executable on the server.}
When we repeated the test of requesting a URL that pointed to nothing, we got a response from the custom error response handler.
We are pleased to have solved this problem. But, the difficulty we had in figuring out the solution points out the major problem of using obsolete software products: documentation and technical support information often disappears from the Web.
We realize that one of the reasons enterprise software companies put server products into end-of-life status is to allow them to stop supporting very old versions. But, we would have hoped that help with solutions to this problem would not have been so elusive.
Although this is probably nearly a worst-case scenario, it increases our resolve to get off the Netscape Enterprise Server platform as soon as possible.
