httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Turner <>
Subject Re: [users@httpd] ErrorDocument initiated from a CGI program
Date Sat, 29 Mar 2003 08:07:11 GMT
Zac Stevens wrote:

>On Fri, Mar 28, 2003 at 10:20:08PM -0600, Gary Turner wrote:
>> Jack Roth wrote:
>> >We want the script to generate an error which is caught by the
>> >ErrorDocument.
>> You may be fixating on the means, and ignoring alternatives.  The errors
>> you want to deal with, as I understand, are not Apache errors, but are
>> interactive/backend limitations.  True?  In that case, do not worry
>> about http error codes.  Use cgi scripts, maybe combined with SSI to
>> present custom informational messages.
>Yes, but why should a developer need to create two sets of custom error
>pages - one for errors generated on the static part of the site, and
>another for the dynamic area?  Conceptually, there is no difference between
>an object that cannot be found on the filesystem, and one which cannot be
>located in a database - the difference lies only in the implementation.

I don't think we're all that far apart.  I am more familiar with 1.3
than 2.0, but your reference seems to imply a more direct way of
implementing (in 2.0) just what I was suggesting; an error message or
page for anything that might require more info than a generic 'page not
found', or 'server error'.

>From the client/user's point of view, there is quite a difference
between a page not found, and data not available.  These should generate
different error messages, and/or in some cases notify somebody.

It may simply be my purely personal prejudice, but I like to test/verify
all data, and I like error messages to be as specific as possible.

>While I agree that this is a non-issue where static ErrorDocuments are
>concerned, I've come across a number of more complex implementations to do
>such things as automatically notify a human of the error, make a
>best-effort at finding the appropriate object, kick off a search, etc etc.

This is all part of the script/program decision tree, no?

>These are all trivial to do from a dynamic ErrorDocument as the environment
>is populated with details of the failed request[1].  All this is lost if
>static redirects are made from the failing CGI.

Use these variables to control redirects or error messages, and exit
gracefully.  It is not the CGI script that is failing.  It is an out of
allowable range situation.

>The best kludge I can think of to work around the problem would be to
>redirect from within your CGI (using a Location: header) and include a
>querystring containing the useful parts of the original request. 

As required.

The advice is free, and worth every cent.

The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:> for more info.
To unsubscribe, e-mail:
   "   from the digest:
For additional commands, e-mail:

View raw message