All such programs should be thoroughly tested using the following procedures:

1. Before trying your code from the web, bench test it thoroughly from your Hercules account.
   
   • For SSI programs this is extremely simple. Since you know exactly what parameter(s) (if any) your program is expecting, you can very easily test it from a standard command prompt. Make sure that any output it produces is either recognizable as HTML, or is plain text that can be inserted into HTML.

• Note that if the script/program output is multi-line, it will not be multi-line when viewed by a web browser unless you take extra steps to make it so. For example, modifying the output to include "<BR>" tags, or bracketing the entire output within a "<PRE> ... </PRE>" block.
  
• For CGI programs the process is a bit more complicated. You will have to create an input file and/or Environment variables that contain the required parameters. You can then test your program from the command prompt. Since this program will be providing a complete HTML web page, make sure that the first output from it is:

  content-type: text/html

  and the rest of its output is a complete HTML page.
  
• You can also send other headers, such as those that set cookies or various cache control options.
  
• It is also possible to send HTML Status headers, but you will need to use the "nph-cgiwrap" program in your URL.
  
• A blank line is required at the end of the headers, before the start of the HTML content.
  
  
2. Other types of web content can be sent by using the appropriate "content-type:" header. Be especially thorough when testing non-text content, as mismatches between the declared type and the actual type can be hard to debug.
   
   
3. Make all URL's Server Relative. ie. Do not specify the name of a Web Server in the URL.

   Use:
   <FORM ACTION="/cgi-bin/cgiwrap/username/CGIprogram ...
   
    or:
   
   <A HREF="/cgi-bin/cgiwrap/username/CGIprogram?Parameters ... 

   NOT:
   <FORM ACTION="http://www.cs.uregina.ca/cgi-bin/cgiwrap/ ...

4. Make sure that these Forms and Links are not accessible from any other Web Pages you may have, until all of your testing is complete. In particular:

   • Do NOT place these URL's on your Home Page (index.html).
     
   • If your "index.html" page is a FRAMESET description, do NOT place these URL's on any page that is loaded into one of your Frames.
     
   • Do NOT make any links to the web pages that contain these Forms or Links.
     
     
5. Before starting a Web Browser (Firefox, Internet Explorer, etc) make an SSH connection to Hercules.
   
   
6. Test the page containing the Form or Link by explicitly specifying Hercules as the Web Server. In the Location: bar of a Web Browser, type:

   http://hercules.cs.uregina.ca/~username/testpage.html

   Where "testpage.html" is the name of the page containing the Form or Link.
   
   
7. Use the SSH connection that you previously opened, to check for problems with your code.

   
   

   • If you persist in using SSI programs that run under the user ID of the Web Server (not setuid), type:
     ps -ef | grep SSI_programName
     Where "SSI_programName" is the name of the SSI program that you are testing.
     If you see any processes running with the name of your SSI program that are being run by user "nobody", they will have to be cancelled.
     You can't do this! Contact the Systems Administrator Immediately. Do this in person. Run - Don't Walk to the SysAdmin's office. Jump up and down frantically until someone opens the door. If you are doing your testing on a Friday evening, you might have to wait until Monday!
     You will get the lecture about bench-testing your code, and about not using SSI programs unless they run setuid. However, if you are sufficiently contrite and this is a first offense, you might keep your account.
     
     
   • For all CGI programs, and for any SSI programs that can run setuid, type:
     ps -f -u username
     Where "username" is the user ID that you login with.
     If you see any processes running that bear the name of your CGI/SSI program, then "kill" them using:
     kill -9 PIDnumber
     Where "PIDnumber" is the number that was shown under the column heading PID on the output of the "ps" command.
     
   • For CGI programs that are used to process an HTML FORM, complete the form on your test page and click the "submit" button. Repeat the above check for processes running under your user ID.
     
     
8. If you only get an error message from your CGI program, then try to run it using the debugging version of "cgiwrap". Modify your ACTION or HREF, replacing the word "cgiwrap" with the word "cgiwrapd". Or, by replacing "nph-cgiwrap" with "nph-cgiwrapd". Note that the output from the debugging version of the nph wrapper is almost unreadable as it contains absolutely no formatting.
   
   
9. You can also get hints about why your CGI/SSI program didn't work by examining the Apache Error Log. This file is in "/var/log/httpd/LOG.ApacheError". The file is world readable.
   There are a lot of entries written to this log, so it can sometimes be difficult to find the entry pertaining to your error. It is often easier to:

   cd /var/log/httpd/
   tail -f LOG.ApacheError 

   and watch as you submit your web page.
   
   
10. If you are preparing content for the departmental web site, contact the Computer Science Systems Administrator for assistance in testing for the production server.

Once all of the above tests have been successfully completed, you may make links to the web page containing these Forms or Links. You may also incorporate them into your Home Page.