Migrating Servers: Enabling CGI: Part 1 | Part 2

Mike de Sousa, Director, AbleStable, and Zoltan Milosevic, Fluid Dynamics Software

Related Resources at AbleStable: An introduction to CGI | CHMOD Calculator

You may be fortunate in transferring a site to a new server to see all your scripts work perfectly first time. Most hosts however have their own methods of deploying server architecture, and the paths to scripts are often different from one host to another. Add to this, the possibility that the server demands certain conditions that you may be unaware of, and you've discovered one of the many reasons webmasters will attempt to avoid migrating a website to a new host if at all possible.

This extended two part article presents the principles surrounding the transfer of CGI scripts that will help make server migration a little less painful.

About CGI

Any script can be called a CGI script as long as it's installed on the server end. CGI is a two way exchange of information between the 'client-side' and the 'server-side'.

The client-side in this case is the general user viewing a web page on a web browser. The server-side is the host computer that delivers the web pages from a remote location.

It is not possible to simply cut and paste a CGI script into a web page and hope that it will work on a web site. CGI requires that the host server is CGI enabled, and CGI scripts usually only run from a specified folder like ''/cgi-bin/'' (some hosts may however be more flexible in their server architecture allowing you to place and execute scripts from any folder). The script processes the requests made of it, then delivers the results of the request in some meaningful form back to the client.

Paths and File Names

Before transferring a script be very clear about its current path name. Take care to note whether there is a different path to the CGI Bin than the usual URL path as you may be required to point the script separately to each path (read the instructions that accompany the script instillation carefully). For example your URL path may be:

"/your-script-folder/your-script.cgi"

Your CGI path may be:

"/your-server-home/your-user-name/cgi-bin/your-script.cgi"

Your scripts may also be installed in a non-standard path (be aware that rock solid 'standards' do not exist where server architecture is concerned). Two examples of paths to CGI scripts follow:

A standard path: "/cgi-bin/your-script-folder/your-script.cgi"
A non-standard path: "/your-present-host-cgi/cgi/your-script-folder/your-script.cgi"

Webmasters would be well advised to change all navigation paths to a simple root address. This includes normal HTML footer links like:

"<a href="http://www.your-web-site.com/">index.html</a>"

This would be better coded as:

"<a href="/">index.html</a>"

Finding the Right Host

When you shop around for new hosts there are some important issues you should consider relating to CGI. Ask questions before you buy as you may not be able to receive a refund once you've agreed to the small print of your new host's contract.

1. You may want to ensure you can run CGI in any folder, including ''/your-present-host-cgi/cgi/'', as you may need to create a new folder on your new server that replicates the current path to your script ("/your-existing-host-folder/your-script-folder/your-script.cgi"). Many hosts require you run CGI scripts from the "/cgi-bin/" or "/cgi/" folders. Many scripts will default to a particular path or require they are run from a particular root folder like "/special-folder/your-script.cgi".

2. You may want to ensure you can run CGI with the ".cgi" extension as some servers force the ".pl" extension.

3. If you have to run CGI scripts from the cgi-bin, you may need to install the cgi scripts into the cgi-bin, then upload any associated files (images etc) to a separate folder. That's because many servers are set up so that only scripts run from the cgi-bin.

If you do have to change your path and extension, then you'll need to modify all of your custom forms and links to point to the new location. An additional point to bear in mind here is that search engine bots like Googlebot will generate some errors as they try to go to the old location of the script. Similarly, some of your customers' bookmarks and links might fail if they were linking directly to results resulting from a script action. For this reason it's a good idea to ensure your site has custom error pages to redirect the user should an out of date URL be requested.

Custom Forms and Links

Assuming you'll use the same path like "/your-present-host-cgi/your-script-folder/your-script.cgi" on the new server, your form might start out like:

<form method="get" action="/your-present-host-cgi/your-script-folder/your-script.cgi">

That way, the same exact form will continue to work flawlessly whether your visitor is on your-site.com, your-sub-site.net, or some temporary hostname or IP address. The benefit is you'll be able to migrate all your web pages directly from one server to the other and hopefully carry out accurate tests.

Relative URL's

You may find your scripts may by default link to results with the fully-qualified URL:

''http://www.your-site.com/your-folder/your-content.html''

These links will be problematic during your migration. A better solution is to use relative URL's like:

''/your-folder/your-content.html''

Depending on your script, these relative URL's may then continue to work whether your visitor is on your-site.com, your-site.net, or some temporary hostname or IP address.

Ideally you would enable relative paths about a week before your migration. Then, keep relative paths enabled on both the new and old server during the migration. Finally, a week or so after completing, disable the rule to go back to fully qualified URL paths in the results (if you want). Continue



Related Resources at AbleStable: An introduction to CGI | CHMOD Calculator



Migrating Servers: Enabling CGI: Part 1 | Part 2