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