Solutio at Gmail wrote:
> Thanks, your version works like a charm...but doesn't
> quite meets our needs. I apologize for being too vague
> regarding passing parameters on to the filter. Basically,
> we would like to somehow link the location and name of the
> response dump with the request data, like the date/time of
> the request, session ID, username, URL. We log that
> information in the audit data repository. In other words,
> the file handle for the captured data needs to point to a
> dynamically created file name.
How about a PerlInitHandler that saves the request information in
the connection object pnotes?
use Apache2::Connection ();
use Apache2::ConnectionUtil ();
use Apache2::RequestRec ();
sub handler {
my $r = shift;
my $c = $r->connection;
# parse cookies, get session id, whatever
my $data = {
protocol => $r->protocol,
session_id => $session_id,
# etc.
};
$c->pnotes(request_data => $data);
}
Then the connection output filter can read it from there.
A similar post-request PerlCleanupHandler or PerlLogHandler
could save any info needed after the request was processed.
You shouldn't overload headers to save this kind of info.
That's a messy way to write code and that kind of
undisciplined coding is the reason some people hate perl.
Is that syntax for $c->pnotes correct from Apache2::ConnectionUtil?
It's not like how $r->pnotes seems to work these days, I would
have expected
$c->pnotes->{request_data} = $data;
or something like that.
Mark