Apache Client Filehandle

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

Hello all:

I want to use Compress::Zlib to deflate contents being sent to the client.

One way is using it's gzopen(<file or filehandle>, <mode>) call.

Is there a filehandle that represents the output stream to the client?

How do I get it?

I am writing my own mod_perl handler for Apache2 (mod_perl2.0 from svs)

Thanks in advance,

Leo

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

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: Apache Client Filehandle

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

please keep posts on-list so everyone can benefit :)

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

the trick is, you need to do it before the PerlResponseHandler phase, such
as from a PerlFixupHandler.

> 
> My module may even cache it's contents...
> 
> Seems that to use mod_deflate with my application specific flag, I'll
> have to reconfigure the server config of mod_deflate at runtime whenever
> the flag is overriding the default right?

no, not the server config.  see above :)

HTH

--Geoff

Re: Apache Client Filehandle

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

Leo wrote:
> Hello all:
> 
> I want to use Compress::Zlib to deflate contents being sent to the client.
> 
> One way is using it's gzopen(<file or filehandle>, <mode>) call.
> 
> Is there a filehandle that represents the output stream to the client?
> 
> How do I get it?
> 
> I am writing my own mod_perl handler for Apache2 (mod_perl2.0 from svs)

if you're using apache 2 then just use mod_deflate - that's what it is for.

  http://httpd.apache.org/docs-2.0/mod/mod_deflate.html

unlike with apache 1.3/mod_perl 1.0, mod_deflate will compress all output on
the way to the client, even dynamically generated scripts or content handlers.

HTH

--Geoff