You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Neil Nelson <ne...@dslextreme.com> on 2003/04/19 20:45:07 UTC
PerlChildExitHandler
Dear mod_perl Users Group,
(Trying this post again under the proper connect name.)
I was just working on the mod_perl Server Life Cycle
Handlers page
http://perl.apache.org/docs/2.0/user/handlers/server.html
and hit an error that does not seem immediately resolved.
On that page is the line
PerlChildExitHandler MyApache::StartupLog::child_exit
that is put into httpd.conf. But this results in the
following error when starting Apache.
Syntax error on line 254 of /usr/local/apache2/conf/httpd.conf:
Invalid command 'PerlChildExitHandler', perhaps mis-spelled
or defined by a module not included in the server configuration
Another mod_perl doc page
http://perl.apache.org/docs/1.0/guide/install.html#Callback_Hooks
indicates that PerlChildExitHandler is in the default install.
Regards,
Neil Nelson
Re: PerlChildExitHandler
Posted by Neil Nelson <ne...@dslextreme.com>.
Perrin Harkins wrote:
>On Saturday 19 April 2003 2:45 pm, Neil Nelson wrote:
>
>
>>Another mod_perl doc page
>>
>>http://perl.apache.org/docs/1.0/guide/install.html#Callback_Hooks
>>
>>indicates that PerlChildExitHandler is in the default install.
>>
>>
>
>Yes, but that's the documentation for mod_perl 1.
>
>It does look like this hook should work in mp 2 though. Perhaps you put it
>inside a <DIrectory> or <Location> directive?
>
On page http://perl.apache.org/docs/2.0/user/handlers/server.html
there are two lines (of five to be put in httpd.conf)
PerlChildInitHandler MyApache::StartupLog::child_init
PerlChildExitHandler MyApache::StartupLog::child_exit
and PerlChildInitHandler works. That is if PerlChildExitHandler
is commented in httpd.conf no error appears. These are basic
thread starting and stopping handlers.
Also at
http://perl.apache.org/docs/2.0/user/handlers/server.html#PerlChildExitHandler
which does not make much sense from the handler organization
described on the prior page.
There is a note on
http://perl.apache.org/docs/2.0/user/handlers/intro.html#Single_Phase_s_Multiple_Handlers_Behavior
Note: |PerlChildExitHandler
<http://perl.apache.org/docs/2.0/user/handlers/http.html#PerlChildExitHandler>|
and |PerlCleanupHandler
<http://perl.apache.org/docs/2.0/user/handlers/http.html#PerlCleanupHandler>|
are not real Apache hooks, but to mod_perl users they behave as all
other hooks.
which might point toward a solution.
Regards,
Neil Nelson
Re: PerlChildExitHandler
Posted by Perrin Harkins <pe...@elem.com>.
On Saturday 19 April 2003 2:45 pm, Neil Nelson wrote:
> Another mod_perl doc page
>
> http://perl.apache.org/docs/1.0/guide/install.html#Callback_Hooks
>
> indicates that PerlChildExitHandler is in the default install.
Yes, but that's the documentation for mod_perl 1.
It does look like this hook should work in mp 2 though. Perhaps you put it
inside a <DIrectory> or <Location> directive?
- Perrin
Re: PerlChildExitHandler
Posted by Stas Bekman <st...@stason.org>.
Neil Nelson wrote:
> Dear mod_perl Users Group,
>
> (Trying this post again under the proper connect name.)
>
> I was just working on the mod_perl Server Life Cycle
> Handlers page
>
> http://perl.apache.org/docs/2.0/user/handlers/server.html
>
> and hit an error that does not seem immediately resolved.
> On that page is the line
>
> PerlChildExitHandler MyApache::StartupLog::child_exit
>
> that is put into httpd.conf. But this results in the
> following error when starting Apache.
>
> Syntax error on line 254 of /usr/local/apache2/conf/httpd.conf:
> Invalid command 'PerlChildExitHandler', perhaps mis-spelled
> or defined by a module not included in the server configuration
It was added after 1.99_08 was released. Either use the current cvs
http://perl.apache.org/download/source.html#Development_mod_perl_2_0_Source_Distribution
or wait for the soon-to-be-released 1.99_09.
__________________________________________________________________
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
RE: Handler attributes
Posted by "Marc M. Adkins" <mm...@Doorways.org>.
> > I just updated mod_perl using mpinstall.pl (as described on
> > perl.apache.org). Now I've got mod_perl/1.99_10-dev, which has the same
> > loading order problem (I was running 199_9-dev earlier today).
> I'll try to
> > remember to check back on this periodically and confirm the fix.
>
> Does it build from the source or downloads a binary?
BFM. It _looks_ like it uses PPM for some of it and installs a pre-built
.so module. I found it under binary installs on perl.apache.org. So far it
appears to work pretty well. I tried to do it manually at one point and
remember being somewhat frustrated.
I don't know how often the binary is rebuilt, how up-to-date it is, etc.
Like I said, BFM. I'm just happy it works, it saves me much time and
frustration.
mma
Re: Handler attributes
Posted by Stas Bekman <st...@stason.org>.
Marc M. Adkins wrote:
>>Don't worry, I'm pretty sure that my patch fixes the problem. It
>>was obviously
>>different from the execution order on non-vhost server.
>
>
> I just updated mod_perl using mpinstall.pl (as described on
> perl.apache.org). Now I've got mod_perl/1.99_10-dev, which has the same
> loading order problem (I was running 199_9-dev earlier today). I'll try to
> remember to check back on this periodically and confirm the fix.
Does it build from the source or downloads a binary?
>>While you work through the filter docs, if you have any
>>suggestions please
>>mentions those. doc patches to improve language, clarity, etc.
>>are very welcome.
>
>
> I'd been thinking of doing some of the boilerplate fill-in that is needed.
> Like there is a fairly useful set of tutorial-type doc on handlers but the
> methods for Apache::RequestRec and Apache::Filter and other classes are
> still blank. Is this stuff in the source tree (which I don't have right
> now)? If so I could maybe fill in the few of the easy ones (that I may
> actually understand) and send in patches.
Well, the problem with mp2 manpages is very simple: we wanted to get an
automatic conversion of the docs from the C header files. However for some
reason folks who have worked on this sub-project are busy with other things.
The plan was to import the existing docs automatically and then polish the.
I'm CC'ing Gerald. May be he has some updates on this issue.
__________________________________________________________________
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
RE: Handler attributes
Posted by "Marc M. Adkins" <mm...@Doorways.org>.
> Don't worry, I'm pretty sure that my patch fixes the problem. It
> was obviously
> different from the execution order on non-vhost server.
I just updated mod_perl using mpinstall.pl (as described on
perl.apache.org). Now I've got mod_perl/1.99_10-dev, which has the same
loading order problem (I was running 199_9-dev earlier today). I'll try to
remember to check back on this periodically and confirm the fix.
> As for M$ building probs, consider getting an unix flavor OS, I
> have heard
> people reporting good results with using vmware if you can't
> afford dropping M$.
Actually, I have Mandrake Linux running on a separate partition, but all my
email and useful utilities are on Windows so I don't boot over all that
often. I used to have a separate Linux machine but when the wife spilled
coffee in the laptop I had to give up my Linux box for her use. Heavy sigh.
> While you work through the filter docs, if you have any
> suggestions please
> mentions those. doc patches to improve language, clarity, etc.
> are very welcome.
I'd been thinking of doing some of the boilerplate fill-in that is needed.
Like there is a fairly useful set of tutorial-type doc on handlers but the
methods for Apache::RequestRec and Apache::Filter and other classes are
still blank. Is this stuff in the source tree (which I don't have right
now)? If so I could maybe fill in the few of the easy ones (that I may
actually understand) and send in patches.
mma
Re: Handler attributes
Posted by Stas Bekman <st...@stason.org>.
Marc M. Adkins wrote:
>>Can you please test the current modperl-2.0 cvs or alternatively
>>apply this
>>patch and let me know if this works now without the workaround?
>>http://marc.theaimsgroup.com/?l=apache-modperl-cvs&m=105183931629250&w=2
>
>
> Unfortunately I'm not building Apache or mod_perl right at the moment. I
> get sooooo frustrated building open-source / cross-platform packages on
> Windows I'm in kind of avoidance mode right now. You could probably talk
> (or guilt) me into it but probably not before next week. All that
> downloading and fussing and breaking of furniture to consider.
>
> Seems ungrateful I know...but I really have had a lot of serious pain
> building stuff on Windows and my fuse has gotten short. I went to build APR
> or Apache just a few weeks ago and ran into some 'usual problem' (like I
> would have to give M$ money for new versions of software or download 133Mb
> of software over a 56K line or something like that) and just blew it off and
> downloaded binaries. Sigh.
>
> So right now I'm running:
>
> Apache 2.0.45
> mod_perl 1.99_09-dev
> ActiveState Perl build 804 (5.8.0)
> Windows 2000
>
> all from binaries _including_ mod_perl which I got from wherever
> perl.apache.org said to get it.
>
> Yell at me some offline and I'll probably acquire the proverbial round tuit.
Don't worry, I'm pretty sure that my patch fixes the problem. It was obviously
different from the execution order on non-vhost server.
As for M$ building probs, consider getting an unix flavor OS, I have heard
people reporting good results with using vmware if you can't afford dropping M$.
[...]
> So when I demonstrated the problem to myself I went back to the doc and lo
> and behold, there it was:
>
> HTTP request output filters should probably also unset the C-L header,
> if they change the size of the data that goes through it. (e.g. lc()
> filter shouldn't do it).
>
> $filter->r->headers_out->unset('Content-Length');
>
> A good candidate for boldface in the final documentation revision, but all
> my own problem even so.
;)
> Note that my dummy PerlResponseHandler made it work OK where using the file
> straight from Apache did not. Well, whaddyaknow, my dummy
> PerlResponseHandler never set the content length. Apache probably does.
> Mystery solved (I think).
Yes, that must be it. Cool!
While you work through the filter docs, if you have any suggestions please
mentions those. doc patches to improve language, clarity, etc. are very welcome.
__________________________________________________________________
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
RE: Handler attributes
Posted by "Marc M. Adkins" <mm...@Doorways.org>.
> Can you please test the current modperl-2.0 cvs or alternatively
> apply this
> patch and let me know if this works now without the workaround?
> http://marc.theaimsgroup.com/?l=apache-modperl-cvs&m=105183931629250&w=2
Unfortunately I'm not building Apache or mod_perl right at the moment. I
get sooooo frustrated building open-source / cross-platform packages on
Windows I'm in kind of avoidance mode right now. You could probably talk
(or guilt) me into it but probably not before next week. All that
downloading and fussing and breaking of furniture to consider.
Seems ungrateful I know...but I really have had a lot of serious pain
building stuff on Windows and my fuse has gotten short. I went to build APR
or Apache just a few weeks ago and ran into some 'usual problem' (like I
would have to give M$ money for new versions of software or download 133Mb
of software over a 56K line or something like that) and just blew it off and
downloaded binaries. Sigh.
So right now I'm running:
Apache 2.0.45
mod_perl 1.99_09-dev
ActiveState Perl build 804 (5.8.0)
Windows 2000
all from binaries _including_ mod_perl which I got from wherever
perl.apache.org said to get it.
Yell at me some offline and I'll probably acquire the proverbial round tuit.
> > Yeah, I have app-specific code collecting the incoming data and
> then I spew
> > it at the end after seeing EOS. I've tinkered some and can't reproduce
> > without
> > my code so I'm guessing it's my problem. If I can reproduce w/o my code
> > I'll certainly pass along the example.
>
> I don't think we have a filter test that has no mod_perl handler
> that produces
> the response. If you can write one, that would be great! If you
> need help, ask.
After much fussing I finally determined that I got the problem when I
changed the content length during the filtration. Yes, I have in fact read
the documentation, but of course the importance of the 'details' doesn't
always become apparent until after spending an hour or so wondering WTFO.
And of course my test scripts prior to the last posting did exactly what you
suggested: they just passed input to output. Which doesn't alter the
length, wouldn't ya know it. Not that I wouldna thunk up the same test
myself, the obvious next step, just took another little bit to go on to a
simple handler that made the output length longer in passing like my real
handler does.
So when I demonstrated the problem to myself I went back to the doc and lo
and behold, there it was:
HTTP request output filters should probably also unset the C-L header,
if they change the size of the data that goes through it. (e.g. lc()
filter shouldn't do it).
$filter->r->headers_out->unset('Content-Length');
A good candidate for boldface in the final documentation revision, but all
my own problem even so.
Note that my dummy PerlResponseHandler made it work OK where using the file
straight from Apache did not. Well, whaddyaknow, my dummy
PerlResponseHandler never set the content length. Apache probably does.
Mystery solved (I think).
mma
Re: Handler attributes
Posted by Stas Bekman <st...@stason.org>.
Marc M. Adkins wrote:
>>>But using the '+' notation works jus' fine. Weird.
>>
>>Doh! Must be the order of executing PerlRequire and PerlModule
>>entries. Was
>>this configuration inside a VirtualHost container?
>
>
> Like this:
>
> <VirtualHost *:80>
> PerlOutputFilterHandler +Site::Wrapper
> </VirtualHost>
>
>>The vhost is need was the other way around, I'll commit the fix
>>that changes the order now.
>
>
> Cool. Though I have a work-around, so I'm happy anyway.
Can you please test the current modperl-2.0 cvs or alternatively apply this
patch and let me know if this works now without the workaround?
http://marc.theaimsgroup.com/?l=apache-modperl-cvs&m=105183931629250&w=2
>>$filter->remove completely removes the filter from the chain, so it's not
>>going to be invoked at all. Much faster.
>
>
> I'm assuming that this is on a per connect basis. That the handler is not
> removed permanently from the chain, but only for the rest of the calls on a
> given page.
That's correct.
>>> while ($filter->read(my $buffer, 1024)) {
>>> # process $buffer appropriately
>>> }
>>
>>of course, you have to print the data out. unless you have
>>stripped that code
>>in this example. If you did, what happens if your filter simply
>>prints out
>>data unmodified? Does it get all the data?
>
>
> Yeah, I have app-specific code collecting the incoming data and then I spew
> it at the end after seeing EOS. I've tinkered some and can't reproduce
> without
> my code so I'm guessing it's my problem. If I can reproduce w/o my code
> I'll certainly pass along the example.
I don't think we have a filter test that has no mod_perl handler that produces
the response. If you can write one, that would be great! If you need help, ask.
__________________________________________________________________
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
RE: Handler attributes
Posted by "Marc M. Adkins" <mm...@Doorways.org>.
> > But using the '+' notation works jus' fine. Weird.
>
> Doh! Must be the order of executing PerlRequire and PerlModule
> entries. Was
> this configuration inside a VirtualHost container?
Like this:
<VirtualHost *:80>
PerlOutputFilterHandler +Site::Wrapper
</VirtualHost>
> The vhost is need was the other way around, I'll commit the fix
> that changes the order now.
Cool. Though I have a work-around, so I'm happy anyway.
> $filter->remove completely removes the filter from the chain, so it's not
> going to be invoked at all. Much faster.
I'm assuming that this is on a per connect basis. That the handler is not
removed permanently from the chain, but only for the rest of the calls on a
given page.
> > while ($filter->read(my $buffer, 1024)) {
> > # process $buffer appropriately
> > }
>
> of course, you have to print the data out. unless you have
> stripped that code
> in this example. If you did, what happens if your filter simply
> prints out
> data unmodified? Does it get all the data?
Yeah, I have app-specific code collecting the incoming data and then I spew
it at the end after seeing EOS. I've tinkered some and can't reproduce
without
my code so I'm guessing it's my problem. If I can reproduce w/o my code
I'll certainly pass along the example.
mma
Re: Handler attributes
Posted by Stas Bekman <st...@stason.org>.
Marc M. Adkins wrote:
>>PerlRequire /path/to/startup.pl (where @INC is adjusted)
>>PerlModule Site::Filter
>><Location /filter>
>> SetHandler modperl
>> PerlOutputFilterHandler Site::Filter
>></Location>
>
>
> That's what I was doing. I kept getting error messages at Apache startup
> saying that it couldn't find the module. It showed me the @INC and it
> wasn't what startup.pl was supposed to be setting.
>
> Just tried it again:
>
> [Thu May 01 18:15:17 2003] [error]
> Can't locate Site/Wrapper.pm in @INC
> (@INC contains: C:/Perl/lib C:/Perl/site/lib . C:/Apache2/
> C:/Apache2/lib/perl) at (eval 1) line 3.
>
> But using the '+' notation works jus' fine. Weird.
Doh! Must be the order of executing PerlRequire and PerlModule entries. Was
this configuration inside a VirtualHost container?
If not it's PerlRequire that is executed first, followed by PerlModule entries.
The vhost is need was the other way around, I'll commit the fix that changes
the order now.
> What's weird now is that I'm not sure that the output filter is getting
> invoked properly on 'default' pages. That is to say, just using an output
> filter to wrap formatting around a plain 'ole HTML page as opposed to
> wrapping the output of a PerlResponseHandler.
>
> To be more specific...if I configure:
>
> AddHandler modperl html
> PerlResponseHandler Site::Dummy
>
> PerlOutputFilterHandler +Site::Wrapper
>
> where Site::Dummy simply reads the target HTML file from disk and sends it
> out via the request object, everything works fine. But if I just use:
>
> PerlOutputFilterHandler +Site::Wrapper
>
> by itself the pages don't 'complete.' The tail end of each page is for some
> reason lost. It's like I'm hitting the EOS marker before processing all of
> the data from the source page, but I know that I'm not.
>
> The core code from my output filter is in fact:
>
> # We only process HTML documents:
> return Apache::DECLINED
> unless $filter->r->content_type =~ m|text/html|i;
what you really want to do here is:
unless ($filter->r->content_type =~ m|text/html|i){
$filter->remove;
return Apache::DECLINED;
}
I know this new feature is not documented yet. Will be soon.
$filter->remove completely removes the filter from the chain, so it's not
going to be invoked at all. Much faster.
Alternatively (a tiny bit more efficient) consider to insert the filter in
TransHandler only if you need it:
package MyTransHandler;
...
sub handler {
my $r = shift;
$r->add_input_filter("myfilter")
if $filter->r->content_type =~ m|text/html|i
...
}
> while ($filter->read(my $buffer, 1024)) {
> # process $buffer appropriately
> }
of course, you have to print the data out. unless you have stripped that code
in this example. If you did, what happens if your filter simply prints out
data unmodified? Does it get all the data?
> # Don't do anything until the page is finished:
> return Apache::OK
> unless $filter->seen_eos;
>
> # At this point the page is finished and I send all data
> # out via the $filter object
Ah, you want to do that. Use $filter->ctx for that. I suppose that that's what
you do:
my $data = $filter->ctx;
$data = '' unless defined $data;
while ($filter->read(my $buffer, 1024)) {
$data .= $buffer;
}
$filter->ctx($data);
if ($filter->seen_eos) {
print $filter->ctx;
}
> I've been wondering if there was some Apache::Filter::flush() call I was
> missing, but it _works_ when I use the Site::Dummy PerlResponseHandler. It
> only misses the end when I just let the page be fed in _without_ the
> response handler.
Yes, mod_perl's response handler flushes data. But so does the filter handler.
Look at line 670 in src/modules/perl/modperl_filter.c. It skips the flush only
if it had already sent EOS before.
Could you change one of the filter tests to reproduce this problem?
__________________________________________________________________
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
RE: Handler attributes
Posted by "Marc M. Adkins" <mm...@Doorways.org>.
> PerlRequire /path/to/startup.pl (where @INC is adjusted)
> PerlModule Site::Filter
> <Location /filter>
> SetHandler modperl
> PerlOutputFilterHandler Site::Filter
> </Location>
That's what I was doing. I kept getting error messages at Apache startup
saying that it couldn't find the module. It showed me the @INC and it
wasn't what startup.pl was supposed to be setting.
Just tried it again:
[Thu May 01 18:15:17 2003] [error]
Can't locate Site/Wrapper.pm in @INC
(@INC contains: C:/Perl/lib C:/Perl/site/lib . C:/Apache2/
C:/Apache2/lib/perl) at (eval 1) line 3.
But using the '+' notation works jus' fine. Weird.
> Actually you don't need 'SetHandler modperl' if you don't run a
> response phase in mod_perl.
Yeah, I've been discovering that.
-------------------------------------------------------
What's weird now is that I'm not sure that the output filter is getting
invoked properly on 'default' pages. That is to say, just using an output
filter to wrap formatting around a plain 'ole HTML page as opposed to
wrapping the output of a PerlResponseHandler.
To be more specific...if I configure:
AddHandler modperl html
PerlResponseHandler Site::Dummy
PerlOutputFilterHandler +Site::Wrapper
where Site::Dummy simply reads the target HTML file from disk and sends it
out via the request object, everything works fine. But if I just use:
PerlOutputFilterHandler +Site::Wrapper
by itself the pages don't 'complete.' The tail end of each page is for some
reason lost. It's like I'm hitting the EOS marker before processing all of
the data from the source page, but I know that I'm not.
The core code from my output filter is in fact:
# We only process HTML documents:
return Apache::DECLINED
unless $filter->r->content_type =~ m|text/html|i;
while ($filter->read(my $buffer, 1024)) {
# process $buffer appropriately
}
# Don't do anything until the page is finished:
return Apache::OK
unless $filter->seen_eos;
# At this point the page is finished and I send all data
# out via the $filter object
I've been wondering if there was some Apache::Filter::flush() call I was
missing, but it _works_ when I use the Site::Dummy PerlResponseHandler. It
only misses the end when I just let the page be fed in _without_ the
response handler.
mma
Re: Handler attributes
Posted by Stas Bekman <st...@stason.org>.
Marc M. Adkins wrote:
>>I saw this recently - the cause IIRC was that I didn't preload the module
>>with PerlModule first, so try that if you haven't already.
I'll check why this doesn't work without preloading.
> I've been using:
>
> <Location /filter>
> SetHandler modperl
> PerlOutputFilterHandler +Site::Filter
> </Location>
>
> The '+' is supposed to implicitly call PerlModule (and apparently does).
>
> When I attempt to use the PerlModule directive separately (outside of the
> <Location> tag) I get an error related to the @INC value not including my
> code directory, which is in fact set up in startup.pl. So far the directive
> above is the only configuration that I've managed to get working.
+ is fine.
but when do you load startup.pl? This should work:
PerlRequire /path/to/startup.pl (where @INC is adjusted)
PerlModule Site::Filter
<Location /filter>
SetHandler modperl
PerlOutputFilterHandler Site::Filter
</Location>
Actually you don't need 'SetHandler modperl' if you don't run a response phase
in mod_perl.
>>which is the example from the perl.com article
>>
>>http://www.perl.com/pub/a/2003/04/17/filters.html
>
>
> Ah, yes, there's that thing where the filter is invoked multiple times...I
> had read about that but forgotten. Doubtless that is why I'm getting double
> output. D'oh!
Use $filter->ctx to ensure that something happens once (this is documented).
Or $filter->remove. I'll update the filter docs soonish.
> Note that your example from the article does not actually use the
> FilterRequestHandler attribute (I'm still wondering just exactly what it is
> supposed to do...I suppose I'll have to traipse through the code sometime).
> Meanwhile, I had apparently gotten the right configuration (using the '+' as
> discussed above) and not re-checked my code with the attribute because _now
> it works_ for me.
FilterRequestHandler marks the handler as a request filter handler (which is
the default, so you don't have to use that attribute). However if you want to
use a connection filter you have to use the FilterConnectionHandler attribute.
Why do you need to mark these? Because the configuration directive doesn't say
anything about the type of the filter:
PerlOutputFilterHandler Site::Filter
So if we don't know if it's a connection filter or a request one, we don't
know when to invoke it. Perhaps reading the whole filters document and working
through all examples will make it more clear.
> Now I've fixed my code to do single output. A side note, in case anyone
> cares...the method Filter::seen_eos() will _never_ be true unless the code
> calls Filter::read() enough times to go through all of the input. An
> obvious thing, once it happens. Perhaps worth a note in the doc, perhaps
> not. I only found out because I was ignoring the input in my simplistic
> test code, an unrealistic situation for an output handler. -- mma
That's correct. $f->seen_eos() is a special function for streaming filters and
you have to read all the input in a loop to get it set. This will be
documented in the Apache::Filter manpage.
__________________________________________________________________
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
Re: Handler attributes
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>>which is the example from the perl.com article
>>
>>http://www.perl.com/pub/a/2003/04/17/filters.html
>
>
> Ah, yes, there's that thing where the filter is invoked multiple times...I
> had read about that but forgotten. Doubtless that is why I'm getting double
> output. D'oh!
tricky, isn't it :)
>
> Note that your example from the article does not actually use the
> FilterRequestHandler attribute
no, it doesn't. that the filter is an output filter is assumed. I
have gotten the filter to work with it, though (which is required when
using the FilterInitHandler, which was going to be the subject of
another article :)
> (I'm still wondering just exactly what it is
> supposed to do...I suppose I'll have to traipse through the code sometime).
stas can explain that better than I can. I think it has to do
something with source filters being used to add your handler to the
proper filter chain - the attributes are used as part of the source
filter mechanism.
> Meanwhile, I had apparently gotten the right configuration (using the '+' as
> discussed above) and not re-checked my code with the attribute because _now
> it works_ for me.
cool :)
--Geoff
RE: Handler attributes
Posted by "Marc M. Adkins" <mm...@Doorways.org>.
> I saw this recently - the cause IIRC was that I didn't preload the module
> with PerlModule first, so try that if you haven't already.
I've been using:
<Location /filter>
SetHandler modperl
PerlOutputFilterHandler +Site::Filter
</Location>
The '+' is supposed to implicitly call PerlModule (and apparently does).
When I attempt to use the PerlModule directive separately (outside of the
<Location> tag) I get an error related to the @INC value not including my
code directory, which is in fact set up in startup.pl. So far the directive
above is the only configuration that I've managed to get working.
> which is the example from the perl.com article
>
> http://www.perl.com/pub/a/2003/04/17/filters.html
Ah, yes, there's that thing where the filter is invoked multiple times...I
had read about that but forgotten. Doubtless that is why I'm getting double
output. D'oh!
Note that your example from the article does not actually use the
FilterRequestHandler attribute (I'm still wondering just exactly what it is
supposed to do...I suppose I'll have to traipse through the code sometime).
Meanwhile, I had apparently gotten the right configuration (using the '+' as
discussed above) and not re-checked my code with the attribute because _now
it works_ for me.
Double d'oh!
thx,
marc
P.S.
Now I've fixed my code to do single output. A side note, in case anyone
cares...the method Filter::seen_eos() will _never_ be true unless the code
calls Filter::read() enough times to go through all of the input. An
obvious thing, once it happens. Perhaps worth a note in the doc, perhaps
not. I only found out because I was ignoring the input in my simplistic
test code, an unrealistic situation for an output handler. -- mma
Re: Handler attributes
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Marc M. Adkins wrote:
> I have yet to be able to append an attribute to a handler function, e.g.:
>
> # ...
>
> use base qw(Apache::Filter);
>
> # ...
>
> sub handler : FilterRequestHandler # $filter
>
> # ...
>
> When I do this I get no information in the Apache error log. The page hangs
> for a moment and then goes away.
I saw this recently - the cause IIRC was that I didn't preload the module
with PerlModule first, so try that if you haven't already.
other than that, the examples in t/filter/TestFilter should be enough to get
you going - if you can run them on your mod_perl installation successfully
then the problem is probably just something simple. I haven't tried it on
Win32 before, but you could also try runningthe test suite and then altering
the code from
http://www.modperlcookbook.org/~geoff/perl.com/Apache-Clean-2.0.tar.gz
which is the example from the perl.com article
http://www.perl.com/pub/a/2003/04/17/filters.html
good luck and HTH
--Geoff
Handler attributes
Posted by "Marc M. Adkins" <mm...@Doorways.org>.
I have yet to be able to append an attribute to a handler function, e.g.:
# ...
use base qw(Apache::Filter);
# ...
sub handler : FilterRequestHandler # $filter
# ...
When I do this I get no information in the Apache error log. The page hangs
for a moment and then goes away. When I remove the attribute it 'works'
(right now it prints double, but that's undoubtedly some other error).
Are these attributes actually necessary? What do they do? How do I get
them to work?
I thought I had seen a post regarding this but can't find it now.
I am using:
Apache 2.0
mod_perl 1.99_09-dev
ActiveState Perl build 804 (5.8.0)
Windows 2000
I downloaded all packages as binaries.
thx,
mma