CGI Failing with 404 on IIS

  • Article

Yes... software can have bugs, even if you test it. :-)

Question:

I have written a C EXE that I have renamed as 'prog.cgi'. I have tested it successfully on IIS 5.0 on Windows 2000 Server and IIS 6.0 on Windows 2003 Server.

The program is invoked like so:

https://mysite.com/cgi-bin/prog.cgi

During the first run the program creates a dynamic page that includes a form with ACTION="prog.cgi". It sets a hidden state variable so that the program can keep track of which screen to display. Very basic stuff.

I have a customer who has installed the file on their server (IIS 5.0 on W 2000 Svr), and they can get the first screen, but they get a 404 when they submit the form from the first screen with ACTION="prog.cgi".

It looks to me like a relative path vs. absolute path issue. In the code, I used the ACTION as the program name only, as opposed to making it "/cgi-bin/prog.cgi" to allow customers to install it in and directory they saw fit on their system.

I have read about absolute and relative paths in various places but they all seem to be referring to the file system and not the virtual path like the issue seems to be here.

I did not see this in any of my testing on any version of Windows with IIS or OmniHTTPD, or Unix (with Apache).

Thanks for any ideas.

Answer:

Yup, your issue is with relative path resolution of URIs by browsers, and it is caused by a bug in your CGI. Yes, I know you say that you have successfully tested the CGI on a number of platforms, but at the end of the day, your customer demonstrated a flaw within your CGI despite your testing, so you simply have to accept and fix it.

To allow your customers to install your CGI wherever they want, I suggest that you fix your CGI to use the Server Variable (or CGI environment variable) SCRIPT_NAME to generate the correct URI for ACTION. SCRIPT_NAME resolves back to the URL that invoked the CGI, wherever the user installed it. So, for a first run URL of https://mysite.com/cgi-bin/prog.cgi , SCRIPT_NAME returns /cgi-bin/prog.cgi... which should correctly resolve as ACTION for your subsequent PostBack.

If you just use "prog.cgi" as ACTION, you are assuming that the BROWSER resolves /cgi-bin as the base directory of the request and makes the PostBack to /cgi-bin/prog.cgi. If the browser does not resolve /cgi-bin as the base directory, the PostBack likely results in a 404. You can verify this with the server log file corresponding to the failed PostBack that results in a 404.

//David