You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by ayhan <ay...@drexel.edu> on 2003/02/09 19:45:43 UTC
Filters -- Any reason why EOS is not being sent from mod-perl response handlers?
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: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: Filters -- Any reason why EOS is not being sent from mod-perl
response handlers?
Posted by Stas Bekman <st...@stason.org>.
Stas Bekman wrote:
>> BTW, are you aware of any recent changes that would invalidate the
>> following piece of code :
>>
>> $filter->next->pass_brigade($bb_ctx);
>>
>> This line worked up until 1.99.08 but not yesterday's CVS version.
>> Now Perl says it can't find method "pass_brigade" via package
>> Apache::Filter.
There was a problem indeed. Now fixed in cvs.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: Filters -- Any reason why EOS is not being sent from mod-perl
response handlers?
Posted by Stas Bekman <st...@stason.org>.
ayhan wrote:
> Thanks for your prompt response, Stas.
>
> We've pulled the cvs version yesterday.
> Will do some tests and get back to you.
>
> BTW, are you aware of any recent changes that would
> invalidate the following piece of code :
>
> $filter->next->pass_brigade($bb_ctx);
>
> This line worked up until 1.99.08 but not yesterday's CVS version.
> Now Perl says it can't find method "pass_brigade" via package
> Apache::Filter.
>
> Maybe it's a state-inconsistency in the cvs or something...
Does the test suite pass for you? These two tests do this call and it works
for me:
t/filter/TestFilter/out_bbs_ctx.pm
t/filter/TestFilter/out_bbs_basic.pm
> Anyway, I'll report to you once I've got some results.
But please in the future reports please report each problem separately. Thanks.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
RE: Filters -- Any reason why EOS is not being sent from mod-perl response handlers?
Posted by ayhan <ay...@drexel.edu>.
Thanks for your prompt response, Stas.
We've pulled the cvs version yesterday.
Will do some tests and get back to you.
BTW, are you aware of any recent changes that would
invalidate the following piece of code :
$filter->next->pass_brigade($bb_ctx);
This line worked up until 1.99.08 but not yesterday's CVS version.
Now Perl says it can't find method "pass_brigade" via package
Apache::Filter.
Maybe it's a state-inconsistency in the cvs or something...
Anyway, I'll report to you once I've got some results.
Thanks again
Ayhan
-----Original Message-----
From: Stas Bekman [mailto:stas@stason.org]
Sent: dimanche 9 février 2003 23:41
To: ayhan
Cc: dev@perl.apache.org
Subject: Re: Filters -- Any reason why EOS is not being sent from
mod-perl response handlers?
Thanks ayhan for the detailed report, but had you used the latest cvs
version,
it would have been much shorter ;)
> 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.
You have to be more explicit of what kludges you are talking about. But
first
get the latest cvs of mod_perl.
> 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
You have to use the cvs version of mod_perl, where this has been fixed.
> -------
> 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.
Yes, that's quite possible. Need to look at this issue.
> *** 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...
Don't have this problem here, please try with the latest cvs again.
> *** 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
it's already implemented. $filter->ctx is better because it's private to
the
filter and destroyed as soon as the filter is finished.
> ----------------------------------
> 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.
because you should have read the Changes file of the cvs version.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: Filters -- Any reason why EOS is not being sent from mod-perl
response handlers?
Posted by Stas Bekman <st...@stason.org>.
Thanks ayhan for the detailed report, but had you used the latest cvs version,
it would have been much shorter ;)
> 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.
You have to be more explicit of what kludges you are talking about. But first
get the latest cvs of mod_perl.
> 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
You have to use the cvs version of mod_perl, where this has been fixed.
> -------
> 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.
Yes, that's quite possible. Need to look at this issue.
> *** 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...
Don't have this problem here, please try with the latest cvs again.
> *** 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
it's already implemented. $filter->ctx is better because it's private to the
filter and destroyed as soon as the filter is finished.
> ----------------------------------
> 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.
because you should have read the Changes file of the cvs version.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org