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

Reply via email to