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.
