You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by John Ingram <jo...@cavaliers.org> on 2000/04/21 08:01:24 UTC
DBILogger Error Status Codes
Hi,
I was thrilled when I started using the latest version of DBILogger,
especially when I found that I could set the HTTP_USER programmatically,
so I can log the name of the user with each entry, even though I'm using
CGI database authentication. Yippee!
My only concern right now is that I would really like to query the
table for any 500s or 404s that I get, so I can known where a problem
might have been on the site... but the "urlpath" column for 404s is
always /error/404.html and for 500 it's /error/500.html. Of course it
is, because those are indeed the names of my error pages.
The problem is that I believe Apache is doing it's own internal request
for the static error page and displaying the contents of that page to
the user, in response to the request that they made for some other URL.
For example, I issue a request for /cgi-bin/foo.pl -- which fails for
some reason. When I get the Error 500 in my browser I'm seeing the URL
of /cgi-bin/foo.pl, but the actual message that I see, if other than the
Apache default, it the contents of /error/500.html... but I wasn't
actually redirected to the page. This was some sort of Apache internal
request that it made to process the error. Am I making any sense?
Anyway, the original URL that was requested is what, in my view, should
be logged in the table for error codes. Has anybody dealt with this
problem before? I was going to go into DBILogger and see if I can get
it to log whatever the original request URI was, but figured I wouldn't
reinvent the wheel if somebody has already done this.
Thanks,
John Ingram
Re: DBILogger Error Status Codes
Posted by "Randal L. Schwartz" <me...@stonehenge.com>.
>>>>> "Matt" == Matt Sergeant <ma...@sergeant.org> writes:
Matt> On 21 Apr 2000, (Randal L. Schwartz) wrote:
>> Just in case you missed it... (but notice, no instructions!):
>>
>> package Stonehenge::Reload;
Matt> Thanks!
Matt> When perl is your day job, instructions just get in the way (I guess you
Matt> gathered that from XML::XPath's instructions - did my email help you
Matt> figure it out - or did you drop it?)
I dropped it for the "due last week" column, and the next 72 hours.
However, your message inspired me to learn more about it and your
noxslt processor, so I'll be picking that back up on my next research
cycle.
Instead, this upcoming WT column uses XML::Parser (instead of
XML::XPath) and DBD::RAM to create an in-memory SQL-queryable
representation. The data I used was the XML list of the "Perl
Mongers" contact database. Should be pretty fun (and already turned
in).
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<me...@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: DBILogger Error Status Codes
Posted by Matt Sergeant <ma...@sergeant.org>.
On 21 Apr 2000, (Randal L. Schwartz) wrote:
> Just in case you missed it... (but notice, no instructions!):
>
> package Stonehenge::Reload;
Thanks!
When perl is your day job, instructions just get in the way (I guess you
gathered that from XML::XPath's instructions - did my email help you
figure it out - or did you drop it?)
--
<Matt/>
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org http://xml.sergeant.org
Re: DBILogger Error Status Codes
Posted by "Randal L. Schwartz" <me...@stonehenge.com>.
>>>>> "Matt" == Matt Sergeant <ma...@sergeant.org> writes:
Matt> On 21 Apr 2000, (Randal L. Schwartz) wrote:
Matt> and I'd be
Matt> interested in seeing Stonehenge::Reload, but I don't fancy
Matt> searching the archives of this list (which you posted it to,
Matt> IIRC), and a central repository of all your mod_perl stuff would
Matt> be nice.
>>
>> If they were documented independently of the context in which they
>> appeared, as in WT columns, I'd be happy to. As is, they'd be these
>> wonderously marvelful snippets of undocumented, slightly opaque code
>> with no operating guide. :)
Matt> Hey that sounds like most of the stuff on CPAN anyway <g>.
>>
>> Perhaps at least a pointer in my online WT repository to the columns
>> that include mod_perl goodies? Would that help?
Matt> It sure would... now where is Stonehenge::Reload? ;-)
Only in the archive of the list. Hey, I could post links to the
mod_perl mailing list archive there too. :)
Just in case you missed it... (but notice, no instructions!):
package Stonehenge::Reload;
use vars qw($VERSION);
$VERSION = (qw$Revision: 1.1 $ )[-1];
use Apache::Log;
my %mtime;
sub reload_me {
goto &reload_me if &_reload_caller; # test myself first
goto &_reload_caller; # now test for caller
}
sub _reload_caller {
my $file = (caller)[1];
## Apache->server->log->notice("$$ is testing $file with $mtime{$file}");
return 0 if exists $mtime{$file} and $mtime{$file} == -M $file;
## Apache->server->log->notice("$$ is recompiling $file");
delete @INC{grep $INC{$_} eq $file, keys %INC};
my $old = \&{(caller(1))[3]};
do $file;
my $new = \&{(caller(1))[3]};
## Apache->server->log->notice("$$ got $old => $new for $file");
return 0 if $old == $new; # safety
$mtime{$file} = -M $file;
return 1;
}
sub import {
my $file = (caller)[1];
## Apache->server->log->notice("$$ is importing ",__PACKAGE__," into $file");
$mtime{$file} = -M $file;
}
BEGIN {
__PACKAGE__->import; # for self reload watching
};
1;
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<me...@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: DBILogger Error Status Codes
Posted by Matt Sergeant <ma...@sergeant.org>.
On 21 Apr 2000, (Randal L. Schwartz) wrote:
> Matt> and I'd be
> Matt> interested in seeing Stonehenge::Reload, but I don't fancy
> Matt> searching the archives of this list (which you posted it to,
> Matt> IIRC), and a central repository of all your mod_perl stuff would
> Matt> be nice.
>
> If they were documented independently of the context in which they
> appeared, as in WT columns, I'd be happy to. As is, they'd be these
> wonderously marvelful snippets of undocumented, slightly opaque code
> with no operating guide. :)
Hey that sounds like most of the stuff on CPAN anyway <g>.
>
> Perhaps at least a pointer in my online WT repository to the columns
> that include mod_perl goodies? Would that help?
It sure would... now where is Stonehenge::Reload? ;-)
--
<Matt/>
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org http://xml.sergeant.org
Re: DBILogger Error Status Codes
Posted by "Randal L. Schwartz" <me...@stonehenge.com>.
>>>>> "Matt" == Matt Sergeant <ma...@sergeant.org> writes:
Matt> Speaking of Stonehenge::* modules - any chance you can put up a
Matt> repository of them on your web page - I just installed
Matt> Stonehenge::Pictures (which is very cool - but I'd like to
Matt> extend it to automatically do the thumbnails)
I thought of that during the initial development, but realized the
thumbnail directory would have to be separate from the main directory,
otherwise the timestamps would be modified and the directory needed to
be web-user writable. Oooh wait... I'd just have it try to write in
./thumb/foo.jpg, and if it failed it'd decline entirely, so if ./thumb
was not web-writable, then Stonehenge::Pictures would decline! oooh!!!!
echo add thumb sub directory to Stonehenge::Pictures >>WT-ideas
Matt> and I'd be
Matt> interested in seeing Stonehenge::Reload, but I don't fancy
Matt> searching the archives of this list (which you posted it to,
Matt> IIRC), and a central repository of all your mod_perl stuff would
Matt> be nice.
If they were documented independently of the context in which they
appeared, as in WT columns, I'd be happy to. As is, they'd be these
wonderously marvelful snippets of undocumented, slightly opaque code
with no operating guide. :)
Perhaps at least a pointer in my online WT repository to the columns
that include mod_perl goodies? Would that help?
I've often wanted to include a TOC beyond the simple titles, like
"these columns have mod_perl", "these columns have CGI.pm", "these
columns make HTTP requests", "these columns serve HTTP", etc. But
alas, the tuit server keeps coming up empty at my RealWorld Service
Provider. :)
But, seeing as my stuff seems to be getting used, even in absence of
my included docs, maybe I should just get the docs done and get'em out
there. I could even put them in the CPAN then. :)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<me...@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: DBILogger Error Status Codes
Posted by Matt Sergeant <ma...@sergeant.org>.
On 21 Apr 2000, (Randal L. Schwartz) wrote:
> Yes. The Stonehenge::DBILog that I put into WebTechniques last month
[snip]
Speaking of Stonehenge::* modules - any chance you can put up a repository
of them on your web page - I just installed Stonehenge::Pictures (which is
very cool - but I'd like to extend it to automatically do the
thumbnails) and I'd be interested in seeing Stonehenge::Reload, but I
don't fancy searching the archives of this list (which you posted it to,
IIRC), and a central repository of all your mod_perl stuff would be nice.
--
<Matt/>
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org http://xml.sergeant.org
Re: DBILogger Error Status Codes
Posted by "Randal L. Schwartz" <me...@stonehenge.com>.
>>>>> "John" == John Ingram <jo...@cavaliers.org> writes:
John> The problem is that I believe Apache is doing it's own internal request
John> for the static error page and displaying the contents of that page to
John> the user, in response to the request that they made for some other URL.
John> For example, I issue a request for /cgi-bin/foo.pl -- which fails for
John> some reason. When I get the Error 500 in my browser I'm seeing the URL
John> of /cgi-bin/foo.pl, but the actual message that I see, if other than the
John> Apache default, it the contents of /error/500.html... but I wasn't
John> actually redirected to the page. This was some sort of Apache internal
John> request that it made to process the error. Am I making any sense?
John> Anyway, the original URL that was requested is what, in my view, should
John> be logged in the table for error codes. Has anybody dealt with this
John> problem before? I was going to go into DBILogger and see if I can get
John> it to log whatever the original request URI was, but figured I wouldn't
John> reinvent the wheel if somebody has already done this.
Yes. The Stonehenge::DBILog that I put into WebTechniques last month
doesn't do that, because it gets the URI not from $r->uri but from the
second word of splitting $r->the_request on whitespace. You might
consider that change. (I figured this out by looking at the C
code for the real log code. :)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<me...@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!