You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Alden DoRosario <ad...@chitika.com> on 2007/01/10 00:18:11 UTC
Modifying the Apache Log Entry
In modperl 1.99 I used to use the code below to append a bunch of
parameters to the log entry for a request.
Example: A request to /handler?client=demo would be written to the log
as: (notice how sysinfo has been appended to the log)
fios.verizon.net - - [09/Jan/2007:16:39:17 -0500] "GET
/handler?client=demo&sysinfo=servtime%3D3.976863 HTTP/1.1" 200 1893 "-"
"Mozilla/5.0 Firefox/1.0.6 (ax)" 4098034 -
sub append_to_log {
my ($r, $plog) = @_;
my $uri = "";
if ($r->the_request =~ / (.*) /) {
$uri = $1;
} else {
return;
}
my $info = "&sysinfo=" . uri_escape(join("&", @{$plog}));
(my $request_line = $r->the_request) =~ s/ (.*) / $uri$info /;
$r->the_request($request_line);
}
Problem is: In Modperl 2.0+, the method the_request suddenly became
read-only and the code stopped working.
From: http://search.cpan.org/dist/mod_perl/Changes
Apache::RequestRec methods changes [Stas] - readwrite => readonly:
connection, canonical_filename, header_only, main, next, prev,
pool, per_dir_config, request_config, proto_num, protocol,
request_time, server, the_request, unparsed_uri
Can anyone suggest an alternate way of modifying the log entry ? In
other words, what way does MP2 allow for us to control what gets logged
to the Apache access_log ?
Alternatively: Can the_request in Apache::RequestRec be made writable
again so that it works like before ?
Any help is really appreciated. Thanks.
--
Alden DoRosario
CTO
Chitika, Inc.
www.chitika.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: Modifying the Apache Log Entry
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>>> connection, canonical_filename, header_only, main, next, prev,
>>> pool, per_dir_config, request_config, proto_num, protocol,
>>> request_time, server, the_request, unparsed_uri
>>
>>
>> opening up $r->request_line() is probably acceptable. I'd also consider
>> protocol and maybe proto_num (after researching what it is),
>> unparsed_uri, and perhaps header_only. but that's about all.
>>
>> thoughs from other devs?
>
>
> I think one of the biggest gains I made as a programmer was when I
> overcame the mental block of what you could do with writing to 'read
> only' methods. I know I was one of the people who suggested that those
> methods be read only - in retrospect I think that was a big mistake, and
> I have regretted it ever since I broke through that mental block.
:)
>
> I would suggest making them _all_ read write :) You can do so much
> cool stuff with the API, and I'd rather see it break because someone was
> pushing the limits, rather than having to say "we don't allow that
> because it might break".
>
> my $0.02, for what it's worth :)
appreciated :)
some of those fields, though, are really messy. for example,
per_dir_config is an internal httpd configuration vector, so to set it
properly we'd probably need a whole new typemap entry. and there's no
reason you'd ever want to mess with it since we have an interface to all
the custom config stuff already. similar for something like write
access to a $r->pool - that's just no good no matter how you look at it :)
I think making logical things like header_only or request_line writable
is good for subverting when we know better, but that's because they
represent attributes of the request we'd be interested in faking.
making something like $r->next() writable makes far less sense, since it
represents private httpd bookkeeping that could have core-dump like effects.
things like $r->server() or $r->connection() would be ok, but you'd
really want to set those to your own subclass I'd think, not things at
random. I'd have to mull that one over.
anyway, for the fields I've mentioned, making them writable is just
flicking the appropriate flag in apache2_structures.map (see
ModPerl::MapUtil for an explanation) and I guess adding some basic tests
to make sure things don't blow up when you try to write to them.
low-hanging fruit :)
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: Modifying the Apache Log Entry
Posted by Fred Moyer <fr...@taperfriendlymusic.org>.
Geoffrey Young wrote:
>> Alternatively: Can the_request in Apache::RequestRec be made writable
>> again so that it works like before ?
>
>> From: http://search.cpan.org/dist/mod_perl/Changes
>> Apache::RequestRec methods changes [Stas] - readwrite => readonly:
>>
>> connection, canonical_filename, header_only, main, next, prev,
>> pool, per_dir_config, request_config, proto_num, protocol,
>> request_time, server, the_request, unparsed_uri
>
> opening up $r->request_line() is probably acceptable. I'd also consider
> protocol and maybe proto_num (after researching what it is),
> unparsed_uri, and perhaps header_only. but that's about all.
>
> thoughs from other devs?
I think one of the biggest gains I made as a programmer was when I
overcame the mental block of what you could do with writing to 'read
only' methods. I know I was one of the people who suggested that those
methods be read only - in retrospect I think that was a big mistake, and
I have regretted it ever since I broke through that mental block.
I would suggest making them _all_ read write :) You can do so much
cool stuff with the API, and I'd rather see it break because someone was
pushing the limits, rather than having to say "we don't allow that
because it might break".
my $0.02, for what it's worth :)
>
> --Geoff
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
> For additional commands, e-mail: dev-help@perl.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: Modifying the Apache Log Entry
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Fred Moyer wrote:
> Geoffrey Young wrote:
>
>>> connection, canonical_filename, header_only, main, next, prev,
>>> pool, per_dir_config, request_config, proto_num, protocol,
>>> request_time, server, the_request, unparsed_uri
>>
>>
>> opening up $r->request_line() is probably acceptable. I'd also consider
>> protocol and maybe proto_num (after researching what it is),
>> unparsed_uri, and perhaps header_only. but that's about all.
>>
>> thoughs from other devs?
>
>
> I'm hacking out some tests. Did you mean request_time? I can't find
> request_line() anywhere in the docs.
my mistake - I meant $r->the_request.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: Modifying the Apache Log Entry
Posted by Fred Moyer <fr...@taperfriendlymusic.org>.
Geoffrey Young wrote:
>> connection, canonical_filename, header_only, main, next, prev,
>> pool, per_dir_config, request_config, proto_num, protocol,
>> request_time, server, the_request, unparsed_uri
>
> opening up $r->request_line() is probably acceptable. I'd also consider
> protocol and maybe proto_num (after researching what it is),
> unparsed_uri, and perhaps header_only. but that's about all.
>
> thoughs from other devs?
I'm hacking out some tests. Did you mean request_time? I can't find
request_line() anywhere in the docs.
>
> --Geoff
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
> For additional commands, e-mail: dev-help@perl.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: Modifying the Apache Log Entry
Posted by Fred Moyer <fr...@taperfriendlymusic.org>.
On Thu, 11 Jan 2007, Geoffrey Young wrote:
>
>> Philip mentioned that he wanted to shoot for the next release in
>> February. I'll hack out a fix for this in the coming weekend
>
> the svn changes stas introduced are probably a good place to start:
>
> http://svn.apache.org/viewvc?view=rev&revision=71107
> http://svn.apache.org/viewvc?view=rev&revision=71094
>
> looks like there were no tests involved, but I'd be in favor of having
> some at this point if they're not too difficult to hack into place.
Ok I'll hack out some tests first, then flip the bits, and submit a patch
for review.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: Modifying the Apache Log Entry
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> Philip mentioned that he wanted to shoot for the next release in
> February. I'll hack out a fix for this in the coming weekend
the svn changes stas introduced are probably a good place to start:
http://svn.apache.org/viewvc?view=rev&revision=71107
http://svn.apache.org/viewvc?view=rev&revision=71094
looks like there were no tests involved, but I'd be in favor of having
some at this point if they're not too difficult to hack into place.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: Modifying the Apache Log Entry
Posted by Fred Moyer <fr...@taperfriendlymusic.org>.
On Wed, 10 Jan 2007, Alden DoRosario wrote:
> > opening up $r->request_line() is probably acceptable.
> Regarding this issue (and the follow on responses to it), my vote would
> go to making it writable again. Having old code work is huge for grunts
> like me. The approach above seems to have solved the major problem
> (logging the data) but is introducing side effects (for example, if I
> have not set a note for SYSINFO or if apache is serving a static file
> like index.html, it is getting logged as index.html- -- notice the dash
> at the end).
>
> Naive question: If making request_line writable again is accepted, when
> should it make it to a stable release ?
Philip mentioned that he wanted to shoot for the next release in February.
I'll hack out a fix for this in the coming weekend, so you could pull from
subversion at that time, or you could hack apache2_structures.map in the
source, and rebuild it.
HTH
>
> Thanks so much for your help guys. Really appreciate it.
>
> - Alden.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: Modifying the Apache Log Entry
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> Can anyone suggest an alternate way of modifying the log entry ?
the typical way to do this is to add something to $r->notes and use the
%{Foobar}n
syntax as documented in
http://httpd.apache.org/docs/2.0/mod/mod_log_config.html
in fact, there is a whole flood of variables you can use for this - so
many that you can fake $r->the_request() in a LogFormat with it's
various components. see, for example, recipe 16.3 here:
http://www.modperlcookbook.org/chapters/ch16.pdf
which shows both your method and an alternate way to achieve the same
thing. you could certainly add what you want using these, I'd think.
> In
> other words, what way does MP2 allow for us to control what gets logged
> to the Apache access_log ?
in general, mod_perl has nothing to do with this - you're using mod_perl
to be devious and change around what gets logged. the proper approach
is probably to be straightforward about what you're logging.
>
> Alternatively: Can the_request in Apache::RequestRec be made writable
> again so that it works like before ?
> From: http://search.cpan.org/dist/mod_perl/Changes
> Apache::RequestRec methods changes [Stas] - readwrite => readonly:
>
> connection, canonical_filename, header_only, main, next, prev,
> pool, per_dir_config, request_config, proto_num, protocol,
> request_time, server, the_request, unparsed_uri
opening up $r->request_line() is probably acceptable. I'd also consider
protocol and maybe proto_num (after researching what it is),
unparsed_uri, and perhaps header_only. but that's about all.
thoughs from other devs?
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org