PERL: Intelligent redirect

[Peter Murray]

--On Tue, Mar 10, 1998 11:29 AM -0800 "Roy Tennant"
<rtennant at library.berkeley.edu> wrote: 

> That part seems
> to work fine. My problem comes in when there is something wrong with the
> rest of the URL. Rather than being sent to my static page for "when all
> else fails", they get the cryptic server-produced "404 Not Found" error,
> which is unacceptable. 

I couldn't duplicate the cryptic "404 Not Found" error on
'sunsite.berkeley.edu' server, but I suspect that since your program wasn't
working your removed it from the configuration.  Can you set up a test case
on a server on a different port?

I couldn't see anything wrong from this end:  your looks okay, and the file
/errors/notfound.html is definitely there.

One thing that I did note, though, is that you are not sending back HTTP
error codes as the first line of the response, and that may cause
inconsistent browser performance.  In order to do this, you need to make
your script one of the "Non-Processed Header" script variety.  With most
servers (like the NCSA server I think you are running), you add the prefix
"nph-" to the front of the filename (e.g. 'nph-notfound').  Once you do
that, the first line of any response sent back should look like:

  HTTP/1.0 nnn FREE-TEXT RESPONSE

where 'nnn' is one of the HTTP response codes[1]:

  200  -- Okay
  302  -- File moved temporarily
  404  -- File not found

for instance, in the middle of your script:

   s/govdata/GovData/;
   print "HTTP/1.0 302 Document has moved\n";
   print "Location: $_\n\n";
 } else {
   print "HTTP/1.0 404 File Not Found\n";
   print "Location: /errors/notfound.html\n\n";


> I have tried to catch the fact that I've already been bounced once by
> seeing if the HTTP_REFERER environment variable has the program name, but
> that doesn't work. Any other ideas out there in Web4Lib land?

The usefulness of the HTTP_REFERER field is spotty at best.  For instance,
with some versions of Netscape if you type in a URL in the address field (or
select one from the bookmarks) the browser still reports the URL of page
previously displayed in the browser (even though the new URL doesn't appear
anywhere on the page).

Still, you might also consider logging the HTTP_REFERER field to notify
folks that they are using the wrong URL.  A code snippet like this would do
the trick.

  my($logfile) = "/location/to/logfile/writable/by/web/server/process";
  open (LOGFILE, ">>$logfile") && {      ## Open the logfile for appending
    print LOGFILE scalar(localtime())."\t";  ## Print the time string
    print LOGFILE "$ENV{'PATH_INFO'}\t";     ## Print what was asked for
    print LOGFILE "$ENV{'HTTP_REFERER'}\n";  ## Print where they came from
    close LOGFILE;
  };

(The '&& {...};' syntax is a shortcut for
'if-this-succeeds-do-everything-in-the-next-block'.  If the open fails, the
entire block of printing to the log file is silently skipped.)


Peter

[1]: See "Section 9. Status Code Definitions" of the specification of
HTTP/1.0.  http://www.w3.org/Protocols/rfc1945/rfc1945
--
Peter Murray, Library Systems Manager                    pem at po.cwru.edu
Digital Media Services                 http://www.cwru.edu/home/pem.html
Case Western Reserve University, Cleveland, Ohio          W:216-368-5888