Modperl Handlers [ was: Apache Client Filehandle]

[prev] [thread] [next] [Date index for 2005/01/27]

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
>
>
>  
>