If you are not viewing this document online at http://www.artsackett.com/freebies/redirect/index.html it may not be the most current version. This document was written for redirect.cgi Version 0.91, the second public release. The previous version contains a security vulnerability and if you have it deployed you must replace it with the latest version.
Art Sackett's CGI Redirection Perl Script is free. That should answer your first question ;-) It is not guaranteed in any way -- if it breaks, or if it breaks something, you get to keep any little pieces that it leaves behind. It comes with no support, so you might be on your own if it doesn't work.
My redirection script does a couple of things that most don't, which is why I wrote the thing. I'm not a big fan of reinventing the wheel. If you don't want the features, don't use them -- it doesn't force you to do anything that you wouldn't have to do with a more generic version written by someone else.
I call the thing "Art Sackett's ..." because everybody and their brother has written a script named "redirect.cgi", and I don't want mine confused with theirs. It's easier to support the thing, if I ever actually do, if I know that it is in fact my redirect.cgi, and not some other one, when I get email.
What it Looks Like
Pretty generic, really. Here's a sample interface with no formatting to pretty it up:
Yep, your common everyday everybody-has-one popup menu. Or anything else you decide to create that acts like an HTML form element. The interface is not the cool part, though. What's cool is all the stuff you can do with the Perl script if you decide to use Server Side Includes to allow it to make a popup menu form for you. No one is going to force you to, and the script doesn't care how you do it as long as you do it properly. Just send it a URL and it works. It doesn't have to be a popup menu interface. Radio buttons might be cool for your layout. Plain old links will work, too, even though relatively pointlessly. Live like you want to live.
What it Does
redirect.cgi processes the output of an HTML form that sends it a URL to which you think your users ought to be sent, then sends them there. It gets along with both the POST and GET methods. Along the way, it checks to see if it thinks the page the form is on came from the right place, where the right place means "somewhere on the same server".
My redirect.cgi can also generate your form for you, if you can use Server Side Includes. All you need to do is create a file containing paired URL's and titles for your links in the right format (you're in trouble if your keyboard doesn't have tab and return keys on it!). Or you can create a pile of files, and tell redirect.cgi which to use when you form the SSI directive. If you're not familiar with SSI, you might want to have a look at my grey paper on the subject, SSI for the Rest of Us. The things you can control from the SSI directive are:
I like using the SSI method because it gets me out of a lot of writing. Great big form, one line of SSI directive to make it happen. No cutting and pasting from this document into that one, and doing it for every page on a site when one little link changes. I'd much rather update one text file than a hundred HTML documents just to change one link that happens to appear everywhere on my site. (Ever do a global replace, only to find that you made a small typo and have to do it all over again? I hate that!)
Because the script only writes HTML for the form, any Cascading Style Sheets you have that alter the appearance of form elements should happily work themselves into the form. And because the encoding type of the form is set to application/x-www-form-encoded, the form is compatible with any browser that knows how to render forms. The script doesn't try to tell you what you can and can't do with the HTML around the form, so you can place the form into a table, into a frame, align it anywhere on the page you want, wrap text all around it, whatever.
Because configuring and installing CGI applications can be a serious pain in the butt, the minimal installation should work "right out of the box". The hardest part is editing your HTML to use it, and even that is easy.
If the script won't send you on your way when you try it out and you don't get a server error, it means that the script refused to cooperate with what it thought was a foreign page. In this case, the script simply sends a 500 Internal Server Error message. Uh-oh, fixing that's sure to be a challenge, right? Would I do that to you? Of course not. Change another zero to a one in the script to turn on the debugging mode for this situation, and give it a whirl. The script will tell you why it didn't redirect your browser, and how to fix it. Maybe not specifically "Change the fourth character in the eleventh line your HTML from an 'r' to a 'q' ", but it'll get you close enough that you ought to be able to fix things in short order. Then, when you're done and everything works right, just change that one back to a zero to turn debugging off, and you're in bidness.
redirect.cgi has been tested only with the Apache HTTP server, and only on Linux and a couple of BSD operating systems. If you're not using Apache or Linux/BSD I don't know if it'll work and I don't have any other OS'es here to test with so I probably won't be able to provide assistance.
Version 0.91 (current) is mostly backward-compatible with the previous version. The SSI-generation is functionally equivalent but requires that the links file resides within the web server's document root. The previous 'paranoid' mode is no longer configurable, is always on, will not cooperate with any client that does not provide the HTTP_REFERER header, and will not allow off-server referrers. If you're upgrading, you may safely remove any redirect.cgi ref_list file that exists.
If your Perl interpreter is some version prior to 5.002 (and there's just no excuse for that in the 21st century), the modules that redirect.cgi depends on (CGI.pm and Cwd.pm) may not be installed (they are now a part of the standard distribution, though). If you don't have those modules available, trying to run redirect.cgi will get you your good friend Server Error 500. An Apache-generated 500 is presented in HTML, while a redirect.cgi 500 is plain text, so it's easy enough to tell them apart.
How to get it
That's easy. Pick a format (.zip or .tgz) and use the appropriate link right here. The extracted redirect.cgi is 8765 bytes, the rest is documentation.
These links will always point to the most recent version. The package comes with the script and the documentation in HTML format, essentially a copy of the applicable portions of this site.
That's the end of this page. Time to go looking around. Maybe it'a a good time for me to let you use that cool script I wrote...
NOTE:If you are viewing this document offline, or on your own server without a properly configured redirect.cgi in the right place (you may need to edit the paths in the forms), you're not going anywhere by using that form. Try these instead:
|Internet Applications Developer and Remote System Administrator Art Sackett
If you believe you've found a bug in redirect.cgi or wish to hire me to write some custom software or provide remote system administration services, please feel free to contact Art Sackett, Perl Programmer and Remote System Administrator.