Hi,
I have been working on an output filter, using the bucket brigade API --
since the stream API still seems to have a flew kludges left to hammer
out.
What I first thought would be a simple task has turned out to be quite a
deal though...
Here is some feedback that could perhaps be useful :
BRIEFLY (details are below)
-------
1) mod-perl (or perl-script) RESPONSE HANDLERS don't seem to send an EOS
at the end of the reponse.
This seems to be a major issue. ==> WORKAROUND : afaik, NONE
that is clean enough
-------
2) Currently, there is no way to MIX & MATCH mod-perl FILTERS declared
via "PerlOutputFilterHandler" with APACHE standard ones.
==> WORKAROUND : It's so hairy & awful, I won't tell :-)
Need a way to "declare" (register) a filter in "httpd.conf" and later
activate it for a given context via the usual Apache directives (i.e
AddOutputFilter, AddOutputFilterByType, SetOutputFilter, ...)
IMHO, among all other options that are taken up in "todo/filters.txt",
this is the most versatile approach.
-------
3) SUBROUTINE ATTRIBUTES don't seem to be working as documented (at
least under Perl 5.8). Maybe my fault. ==> WORKAROUND : Was able to just
omit the "FilterRequestHandler" attribute and things worked just fine
for my case (as it is the default).
DETAILS .....
*** 1) EOS ------------------------
mod-perl (or perl-script) RESPONSE HANDLERS don't seem to send an EOS at
the end of the reponse.
This makes it impossible for a filter to do post-reponse processing. And
it so happens, this filter (CheeseBurger) needs to insert some more
content at the end of the reponse.
As things stand now, the filter can never unambigiusly tell that it has
reached the end of the response output when the response comes from a
mod-perl handler of any kind (mod-perl or perl-script, either with
Registery or PerlRun, or even just a pure mod-perl handler).
In other words, for all the buckets that come thru :
bucket->is_eos() is always FALSE.
I haven't been able to find a clean-enough work-around for this one.
Note that all the other "usual" response handlers (like "defaut-handler"
and "cgi-script") and even the more extravagent ones like
"server-status" are behaving correctly in this manner, but not mod-perl.
*** 2) -------- Living in HARMONY with other filters
--------------------------
It seems that mod-perl filters declared via "PerlOutputFilterHandler"
are systematically added at the end of the Apache filter chain,
regardless of their order in "httpd.conf". This makes it impossible to
hand over the filter's output to a standard Apache filter (like
INCLUDES). The following won't work as expected for example :
<Location /someplace>
# my filter which takes a wrapper template that contains
a
# special tag "[%content%]" that will be replaced by the
actual response on output.
PerlOutputFilterHandler
QWL::Apache::CheeseBurger
# the wrapper template, which also contains some SSI in
it.
PerlSetVar CB_WRAPPER
"/test/wrapper.html"
AddOutputFilterByType INCLUDES text/html
</Location>
<Directory /test>
AddOutputFilterByType INCLUDES text/html
</Directory>
The actual response does go thru SSI before reaching the CheeseBurger
filter. But not the final output from the filter.
It seems like we need the ability to seperately declare (register) a
perl filter and then activate it in a given context, such as :
PerlOutputFilter CHEESEBURGER
QWL::Apache::CheeseBurger
<Location /someplace>
AddOutputFilterByType CHEESEBURGER;INCLUDES;DEFLATE
text/html
PerlSetVar CB_WRAPPER
"/test/wrapper.html"
</Location>
*** 3) ----------- Subroutine attributes ------------------------
The SUBROUTINE ATTRIBUTES don't seem to work with Perl 5.8 (I recall
that they did work for Perl 5.6.1 though). Maybe I am doing something
wrong here but, the following code won't even compile :
# Code won't
compile under 5.8 !!!
use base qw(Apache::Filter); # Neither with this
#use Apache::Filter (); # Nor with this!
sub handler : FilterRequestHandler { # As long there is
"FilterRequestHandler" here.
...
...
}
Perl complains that it doesn't recognize the "FilterRequestHandler"
attribute. When Perl recognizes the attribute (such as for "locked",
"method", "lvalue"), it has no problems with it.
Did the Perl guys discourage the experimental attribute feature in 5.8
or something?
In my particular case, I was able to just leave out the attribute
altogether as it is the default (FilterRequestHandler). But if I were
writing a connection filer, I couldn't have...
*** 4) ------------- Keeping filter CONTEXT : is it an issue ?
--------------------------
Keeping context between multiple calls to the filter has been an issue.
For this, I hear there will be a "$filter->ctx".
But then, is it really needed? The usual $r->pnotes() seems to be
working just fine for me.
Or am I doing something wrong by using pnotes for things like :
- Detecting a first call into the filter handler for a given
request
- Keeping context that concerns that concerns that particular
request
----------------------------------
As a final note :
I am using mod_perl 1.99.05 and Apache 2.0.40, which are admitedly a bit
old. I have, on the other hand, gone thru the CHANGES documents for both
upto the latest releases (MP 1.99.08 & A2.0.44). And there doesn't seem
to be anything that relates to the problems mentioned above.
Anyway, after a week's sweat, it now basically works ... under most
circumstances.
In fact, it seems to work fine under the usual response handlers such
as,
- Apache's default-handler
- Apache's cgi-script handler
- more extravagent handlers such as "server-status",
"server-info", ...
However, to my surprise, it doesn't work when the response handler has
got anything to to with mod-perl. :
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
