First of all, I thank you both for your expert opinion on the topic. I have
never had to fiddle with this sort of Apache customization, so I'm learning
in the process...
As for the way to communicate the file name to the filter, sure, we would
like to keep it as simple as possible and avoid pitfalls. I agree that Perl
is a powerful tool that can easily screw many things up if applied
carelessly.
I guess if we properly implement the custom header option, it shouldn't
become a problem. We'll give it a try.
--------------------------------------------------
From: "André Warnier" <a...@ice-sa.com>
Sent: Tuesday, February 10, 2009 4:04 PM
To: <modperl@perl.apache.org>
Subject: Re: Capturing Apache response
Mark Hedges wrote:
[...]
Then the connection output filter can read it from there.
Remove "connection" and I agree, that's much cleaner than putting it in a
header.
A similar post-request PerlCleanupHandler or PerlLogHandler
could save any info needed after the request was processed.
But not what the OP is trying to do, which is to save the headers *and*
the body of the responses (plus some data about the request).
I think the PerlCleanupHandler or PerlLogHandler are a bit late for that.
You shouldn't overload headers to save this kind of info.
I basically agree, but this was not done in a vacuum.
It's the OP's first mod_perl venture, unless I'm confusing him with
someone else. So I did not want to push it by introducing yet another
perl module. I assumed that adding a response header was the easiest way
to go, in whatever response handler is being used now (and which is not a
perl handler).
That's a messy way to write code and that kind of
undisciplined coding is the reason some people hate perl.
That's hard. I love perl and mod_perl.
And I'm sure the OP will love it also, since it gives him a way to achieve
what he cannot otherwise.
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
I believe the OP's filter is not a connection filter, but a Request output
filter (even if he chose the difficult way and is using the buckets
version).
He is right too, because saving each request data separately would be a
lot harder to do in a Connection filter.
So, Dear Original Poster, do you feel ready to add another perl handler
*before* your request gets processed, to save some information about the
request, in a location where the output filter (running *after* the
request gets processed) can find it ?
This would allow you to decide, at request time, the filename for the
saved response, and have the output filter place it there.
Both parts can co-exist in the same code module.
And there is also an example on the mod_perl site.
