Modperl Handlers [ was: Apache Client Filehandle]

[Leo <le...@secline.com.br>]

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

Re: Modperl Handlers [ was: Apache Client Filehandle]

[Geoffrey Young <ge...@modperlcookbook.org>]

Leo wrote:
> I'm replying to myself :) ? Cool.
> 
> I found the answers to my questions below in the list and/or documentation.

fancy that :)

> Thanks for your time Geoffrey.

sure

>  I sometimes need to take a moment and
> look at documentation before I pop off emails.

that's always a good thing to do.  but feel free to keep posting here as
well - we're a nice place to be, full of helpful souls.

welcome.

--Geoff

Re: Modperl Handlers [ was: Apache Client Filehandle]

[Leo <le...@secline.com.br>]

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