Art Sackett's CGI Redirection Perl Script

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.pl Version 0.9, the first public release.

 

 

 

Introduction

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 all of the little pieces that it leaves behind, if any. 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.pl", 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.pl, 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. Live like you want to live.

 

 

What it Does

The Mostly Generic Part

redirect.pl 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, be "the right place" your server, your directory (or directories) within your server, or even, if you're really generous and the system will let it happen, from one of your buddy's pages. Security is a relative thing, and shouldn't keep you from living how you want to live. Of course, if your buddy can't make calls to your CGI stuff already, I'm not in a position, nor is my script, to let him do it now.

The Cooler Part

My redirect.pl 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.pl which to use when you form the SSI directive if the default isn't right for this page. 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 requires only that the path to your Perl interpreter be correct in the heading of the script, and if you intend to use the thing's SSI capabilities that you write only one file in your favorite text editor. The defaults are all sensible enough. If you intend to use the function to limit it's use to your own directories on your server (in case your system will let other users make calls to your CGI stuff), you have to change a zero to a one on one line of the script, and add a line or two to another plain text file telling redirect.pl which referring URL's are okay. Then you upload the script and those two files into the right place on your server, set the permissions on the script (chmod 755 redirect.pl) like you always have done with these things before, and you're on your way.

The Coolest Part

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 the message Referring URL denied. 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 ref_list.txt file from an 'r' to a 'q' ", but 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.

 

 

Compatibility Issues

redirect.pl has been tested only on a couple of Unix operating systems (Linux and FreeBSD) at this time (the day I finished messing with the script), both running the Apache HTTP Server (one plain vanilla, the other Stronghold). It should have no problems at all in other Unixen. Unices? Whatever. If you run it on any other OS or server, please tell me how it works and if there was anything out of the ordinary you had to do to get it working. Especially if it's NT Server, in which case I'll grin whether it worked fine or broke the server completely ;-) Seriously, though, if other Perl scripts will run and work with CGI on your system without any serious hacks, redirect.pl ought to work just fine. If it doesn't and it's not a case of a stupidly configured server, please let me know and I'll see what I can do about it.

If your Perl interpreter is some version prior to 5.002, the module that redirect.pl depends on (CGI.pm) may not be installed (it is now a part of the standard distribution, though). Or if for some reason that module is not installed on a newer version, you are in the same boat. If you don't have CGI.pm available, trying to run redirect.pl will get you your good friend Server Error 500. (Other things can cause this, so if you're reading this wondering if that's the problem you're having, don't assume it just yet!) It is possible to load all 160k of CGI.pm into your user directory and make redirect.pl work that way. It's a pain, but it's possible. I'm not going to suggest it, and I'm not going to answer any questions at all about how to do it. If you want to do this and you don't know how, first abandon hope, then head on over to http://www.cpan.org where the bulk of public knowledge regarding Perl, and every module you could ever want, are stored.

 

 

How to get it

That's easy. Pick a method (HTTP or FTP) and a format (.zip or .tgz) and use the appropriate link right here. The extracted redirect.cgi is 7960 bytes, the rest is documentation.