I'm replying to myself :) ? Cool.
I found the answers to my questions below in the list and/or documentation.
Thanks for your time Geoffrey. I sometimes need to take a moment and look at documentation before I pop off emails.
Leo
Leo wrote:
Geoffrey Young wrote:
please keep posts on-list so everyone can benefit :)
Oops. I'll do that.
Thanks for the sugestion; my handler has a flag that is set in an
application specific config file (not the apache.conf or any included
files therein) that should be able to turn off compression.
what you could do in that case is just disable mod_deflate:
$r->subprocess_env('no-gzip' => 1) if $some_custom_condition;
Very cool indead.
the trick is, you need to do it before the PerlResponseHandler phase, such
as from a PerlFixupHandler.
Even if no header data has been sent by the PerlResponseHandler?
I have only been using the ResponseHandler in my code except for one instance where I read my application specific config file where I use the PostConfigHandler. But this configuration flag is specific to the data instance being handled...
Maybe I'll divide the work between several handlers from now on. Maybe I can use the PerlFixupHandler to the actual processing, use DBI, process session data, set whatever special requirements are needed like your sugestion above.
Then I can use the Response handler to perform the final template processing before I send the clients it's data.
Do file scoped variables in perl survive between subsequent handler calls? what about subrequests (as in $r->internal_redirect(<somewhere>))
Lastly, I gather my initial idea of using some internal filehandle to steal control even in special (rare) circumstances is unorthodox, but not technically impossible, right?
Leo
HTH
--Geoff
