[EMAIL PROTECTED] (Danny Rathjens) wrote:
>In looking at the mod_perl_2.0 features I noticed this:
>> The AddFilter directive takes any number of filters, for example,
>> this configuration will first send the output to mod_include, which
>> will in turn pass its output down to Apache::ReverseFilter:
>> AddFilter INCLUDE Apache::ReverseFilter
>
>Is there any way to pipe output from my own handler into mod_include
>and thence into GzipChain like the above?
>or is the inability to do this the reason Apache::SSI exists?
It's one of the main reasons - c content modules and Perl content
modules can't play together.
>I've been reading Apache::OutputChain and Apache::Filter trying
>to figure all this out.
Note: Apache::Filter and Apache::OutputChain are alternative solutions
to the issue. You don't use them together (just wanted to make sure).
>If you want to know why I just don't use Apache::SSI it is because
>I am dealing with a OpenAdStream from realmedia which has a modifed
>mod_include.so which makes calls to a 'proprietary' library.
>So it seems a lot easier to just be able to send the output from my
>handler into their mod_include.
If you truly need to get them to work together, you'll have to do a LWP
request and get the document produced by mod_include, then do Perl
processing on the result. Not pretty.
I'd suggest subclassing Apache::SSI with the same changes they've made
to mod_include. If that's not possible, then I guess you can chalk up
the ugliness to proprietary software woes.
Of course, Apache 2.0 will have a much more flexible filtering that will
render this conversation moot.
------------------- -------------------
Ken Williams Last Bastion of Euclidity
[EMAIL PROTECTED] The Math Forum
