On Wed, 26 Sep 2001, $Bill Luebkert wrote:
> Chris Devers wrote:
> > my $server = $ENV{'SERVER_NAME'} || "domain.com";
> > my $referer = $ENV{'HTTP_REFERER'} || "unavailable";
> > my $document = $ENV{'DOCUMENT_URI'} || $ENV{'REQUEST_URI'} || "uri
>unavailable";
> > my $remoteaddr = $ENV{'REMOTE_HOST'} || $ENV{'REMOTE_HOST'} ||
>"unavailable";
> > my $query = $ENV{'QUERY_STRING'} || "unavailable";
>
> Most of this info is unusable on an error page handler. Some more relevant
> ones are (not all may be present on a given error doc):
>
> REDIRECT_STATUS These two are the most useful
> REDIRECT_URL
Right, but all of this gets collected later in the script anyway. You're
right though, I should probably re-set the way these are assigned.
> You can base your processing on the REDIRECT_STATUS. In the case of a 404
> error I usually check for stuff like:
Actually, I've got a catchall error page, with Apache directives like:
ErrorDocument 400 /misc/server_error.cgi?status=400
ErrorDocument 401 /misc/server_error.cgi?status=401
etc., so there's no env parsing necessary -- it's a passed parameter.
> I don't want to email myself on these frequent normal conditions -
> maybe just log them.
Rather, the page presents a form and, if the user is stuck, may optionally
send an email. I don't want one for each of the tens of thousands of hits
on "default.ida" either... :)
> > #
> > # get the form data, then the environment data
> > #
> > foreach $name ( $cgi->param() ) {
> > my $value = $cgi->param( -name=> $name );
> > $message_body .= " $name: \t$value\n";
> > }
>
> Normally there is no form data on error pages (but not impossible).
> I just include the query string and stdin in the email.
But there is, because the error page I present allows the visitor to
include their name, email, phone etc so that they may request help if
they're stuck. For forward compatibility, I'm just catching all of the
form data, so the script doesn't have to be rewritten everyt time the form
changes.
> I would use a custom page here indicating what error occurred and what
> to do about it. Include the redirect status and URL for reference.
Again, I am doing that. The full version of the script uses HTML::Template
and some manipulation of the $message_body variable in order to display a
dynamic result page to the user, but I cut all that out for this example
because the original poster was stuck on dynamic mail input, not dynamic
mail output. If he's interested in that then I can post the whole script.
> > Etc. Provided that you have MIME::Lite (and maybe Net::SMTP, I
> > forget), or can get what you need, this is running code. You should
> > be able to modify the parameters grabbed, and the format they're
> > translated into (everything that gets put into $message_body) so
> > suit your needs.
>
> Net::SMTP could be used if sendmail isn't available (you would need to
> override the default mailer).
Installing MIME::Lite seemed to want me to get Net::SMTP while I was at
it, so yeah, either way...
Thanks for the critique... :)
--
Chris Devers [EMAIL PROTECTED]
_______________________________________________
Perl-Win32-Web mailing list
[EMAIL PROTECTED]
http://listserv.ActiveState.com/mailman/listinfo/perl-win32-web
