Re: Apache::Filter
[EMAIL PROTECTED] (Manfred Hui) wrote:
>I have recently installed Kent Williams' Apache::Filter Module, and
>tested it with the supplied UC module and it worked with simple cgi scripts.
>
>However I have experienced a problem though when my cgi calls CGI.pm's
>redirect() and header().
>
>Instead of getting the appropiate headers, eg. 302 Moved.
>
>I get a standard Content-type: text/html without reference to any
>location headers.
>
>I was wondering if anyone else had experienced the same problem and/or
>have a solution to this?
>
>Here is what my cgi script looks like.
>
>#!/usr/bin/perl -w
>use CGI;
>my $ob = new CGI;
>print $ob->redirect('http://www.cnn.com');
>
>My Apache PerlHandler is set to Apache::RegistryFilter Apache::UC
Manfred,
I think there is a problem with the CGI->redirect method, because it
uses Apache->request (and there is a problem with that). So your script
must use shift() to get the current request object, and then send
headers manually. Try this instead (untested):
#!/usr/bin/perl -w
my $r = shift;
$r->err_header_out(Location => 'http://www.cnn.com');
$r->status(302);
$r->send_http_header();
The downside of this, of course, is that it won't work under regular CGI.
------
Ken Williams Last Bastion of Euclidity
[EMAIL PROTECTED]The Math Forum
Re: Apache::Filter - get_handlers
You need to rebuild your mod_perl with stacked handlers, i.e.
PERL_STACKED_HANDLERS=1 or more simply EVERYTHING=1. The relevant code is in
Apache.xs.
[EMAIL PROTECTED] (Miguel A.L. Paraz) wrote:
>Hi all,
>
>Where is get_handlers lurking? I couldn't find it in any of the Apache::
>modules.
>
>The error:
>[error] Can't locate object method "get_handlers" via package "Apache"
>at /usr/lib/perl5/site_perl/5.005/Apache/Filter.pm line 77.
>
>The code:
>if (@{$r->get_handlers('PerlHandler')} == $info->{'count'}) {
>
>mod_perl 1.21, Apache::Filter 1.005.
>
>Thanks,
>---m
>
>--
> [EMAIL PROTECTED]Miguel "Migs" A.L. Paraz
> http://www.iphil.netIPhil Communications Network, Inc.
> +63-2-750-2288Business Development Group
>
>
>
>
------
Ken Williams Last Bastion of Euclidity
[EMAIL PROTECTED]The Math Forum
Re: Apache::Filter - get_handlers
Hi, Yup, using David H's apache-modperl RPM fixed it. I was previously using Red Hat's RPM - I guess they built it wrong? Next question - a HEAD request on this Filter'ed page is treated as a GET. Is that right? Thanks, ---m On Sat, Oct 23, 1999 at 10:47:58AM -0500, Ken Williams wrote: > You need to rebuild your mod_perl with stacked handlers, i.e. > PERL_STACKED_HANDLERS=1 or more simply EVERYTHING=1. The relevant code is in > Apache.xs.
Re: Apache::Filter - get_handlers
Yes, for the moment that's right. The idea is that the various filters may need to process the entire body before they know what kind of response to generate. I suppose we don't actually need to _send_ the content out, though. [EMAIL PROTECTED] (Miguel A.L. Paraz) wrote: >Hi, > >Yup, using David H's apache-modperl RPM fixed it. I was previously using >Red Hat's RPM - I guess they built it wrong? > >Next question - a HEAD request on this Filter'ed page is treated as a GET. >Is that right? > >Thanks, >---m > > >On Sat, Oct 23, 1999 at 10:47:58AM -0500, Ken Williams wrote: >> You need to rebuild your mod_perl with stacked handlers, i.e. >> PERL_STACKED_HANDLERS=1 or more simply EVERYTHING=1. The relevant code is in >> Apache.xs. > ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
Re: Apache::Filter headers
> does mod_perl automatically send headers for PerlHandler routines? I know > when to use it with Registry stuff, but as I move to handlers for lots of > stuff I see that PerlHandlers seem ok without it. no, mod_perl will only send headers (by calling ap_send_http_header) if you have PerlSendHeader On.
Re: Apache::Filter Help Please!!
I tried out your config and handlers pretty much verbatim and got them to work just fine. the only real change was that I needed to comment out > return $status unless $status == OK; from filter one, since $fh is $r->filename for the first filter, which brings up 404 when the file is not found. that said, yes I see the same thing, but only for 404s. I think the problem is that you need to deal with your error code properly. > > now, according to what I've read, this should print out the "Filter 1Filter > 2", which is what I need to let me get real work done, but all I get is > Filter 2. So all powerful list, WTF am I missing (it's gotta be something > obvious, it always is). $fh is $r->filename for the first filter in the chain. if $r->filename does not exist, you need to handle this. $status is one way of handling it. checking for $fh (which will be undef if $r->filename does not exist) is another. basically, you definitely don't want to read from $fh if $fh is not defined :) this situation should probably be protected against in Apache::Filter better, but it basically looks like it is a problem with your logic. HTH --Geoff
Re: Apache::Filter Help Please!!
ok, that make sense, so I modified my filter1 to just register the filter, print out some text, and return ok, that's it. and it still doesn't print anything if filter2 comes after it? Does that sound wrong to anybody but me? On Friday 07 December 2001 12:47 pm, you wrote: > I tried out your config and handlers pretty much verbatim and got them > to work just fine. the only real change was that I needed to comment > out > > > return $status unless $status == OK; > > from filter one, since $fh is $r->filename for the first filter, which > brings up 404 when the file is not found. > > that said, yes I see the same thing, but only for 404s. I think the > problem is that you need to deal with your error code properly. > > > now, according to what I've read, this should print out the "Filter > > 1Filter 2", which is what I need to let me get real work done, but all I > > get is Filter 2. So all powerful list, WTF am I missing (it's gotta be > > something obvious, it always is). > > $fh is $r->filename for the first filter in the chain. if > $r->filename does not exist, you need to handle this. $status is one > way of handling it. checking for $fh (which will be undef if > $r->filename does not exist) is another. basically, you definitely > don't want to read from $fh if $fh is not defined :) > > this situation should probably be protected against in Apache::Filter > better, but it basically looks like it is a problem with your logic. > > HTH > > --Geoff -- Jayce^
Re: Apache::Filter Help Please!!
Jason Hall wrote:
>
> ok, that make sense, so I modified my filter1 to just register the filter,
> print out some text, and return ok, that's it. and it still doesn't print
> anything if filter2 comes after it? Does that sound wrong to anybody but me?
>
try this:
package One;
use Apache::Constants qw(OK);
use strict;
sub handler {
my $r = shift;
$r = $r->filter_register();
print "Filter 1";
return OK;
}
1;
package Two;
use Apache::Constants qw(OK);
use strict;
sub handler {
my $r = shift;
$r = $r->filter_register();
my ($fh, $status) = $r->filter_input();
return $status unless $status == OK;
$r->send_http_header('text/plain');
while(<$fh>) {
print;
}
print "Filter 2";
return OK;
}
1;
looks like if you don't send your headers things go slightly amuck.
--Geoff
Re: Apache::Filter Help Please!!
AHAH!!! I found it.. thanks, your example showed the difference.
What it was is that I was sending my header before my final filter, which as
I now am guessing, maps STDOUT, which this needs. I'm recommending to the
author to put a note in about where the headers should be printed.
Thanks for your help, definately made the difference
On Friday 07 December 2001 01:10 pm, you wrote:
> Jason Hall wrote:
> > ok, that make sense, so I modified my filter1 to just register the
> > filter, print out some text, and return ok, that's it. and it still
> > doesn't print anything if filter2 comes after it? Does that sound wrong
> > to anybody but me?
>
> try this:
>
> package One;
>
> use Apache::Constants qw(OK);
> use strict;
>
> sub handler {
> my $r = shift;
> $r = $r->filter_register();
> print "Filter 1";
> return OK;
> }
> 1;
>
> package Two;
>
> use Apache::Constants qw(OK);
> use strict;
>
> sub handler {
> my $r = shift;
> $r = $r->filter_register();
> my ($fh, $status) = $r->filter_input();
> return $status unless $status == OK;
> $r->send_http_header('text/plain');
> while(<$fh>) {
> print;
> }
> print "Filter 2";
> return OK;
> }
> 1;
>
>
> looks like if you don't send your headers things go slightly amuck.
>
> --Geoff
--
Jayce^
Re: Apache::Filter Help Please!!
Jason Hall wrote:
>
> AHAH!!! I found it.. thanks, your example showed the difference.
>
> What it was is that I was sending my header before my final filter, which as
> I now am guessing, maps STDOUT, which this needs.
well, you should be able to print your headers from any filter in the
chain - they are a no-op for all but the final filter.
package One;
use Apache::Constants qw(OK);
use strict;
sub handler {
my $r = shift;
$r = $r->filter_register();
$r->send_http_header('text/plain');
print "Filter 1";
return OK;
}
1;
should work just as well...
> I'm recommending to the
> author to put a note in about where the headers should be printed.
>
> Thanks for your help, definately made the difference
no problem :)
--Geoff
Re: Apache::Filter Install Problem
Hi there, On Thu, 2 Nov 2000, Adam Prime wrote: > i built mod_perl with this: > perl Makefile.PL DO_HTTPD=1 USE_APACI=1 APACHE_PREFIX=/usr/local/apache > PERL_STACKED_HANDLERS=1 > Any insight would be appreciated. I'm installing it on a redhat 6.2 box > with apache 1.3.14 and mod_perl 1.24_01 installed from source, and the perl > 5.005 updated rpm from redhat. Pretty good description. I'd try rebuilding Perl 5.005_03 from source. Use the same compiler you used to build mod_perl. Don't use RPMs. I'm not promising anything mind... 73, Ged.
Re: Apache::Filter Install Problem
[EMAIL PROTECTED] (G.W. Haywood) wrote: >Hi there, > >On Thu, 2 Nov 2000, Adam Prime wrote: > >> i built mod_perl with this: >> perl Makefile.PL DO_HTTPD=1 USE_APACI=1 APACHE_PREFIX=/usr/local/apache >> PERL_STACKED_HANDLERS=1 >> Any insight would be appreciated. I'm installing it on a redhat 6.2 box >> with apache 1.3.14 and mod_perl 1.24_01 installed from source, and the perl >> 5.005 updated rpm from redhat. > >Pretty good description. I'd try rebuilding Perl 5.005_03 from source. >Use the same compiler you used to build mod_perl. Don't use RPMs. Off-list, Adam figured out that mod_perl needed to be built with EVERYTHING=1 (actually just needed a couple more things than he had, particularly Perl sections). Worked fine then. ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
RE: Apache::Filter and cookies
> -Original Message-
> From: JR Mayberry [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, April 10, 2001 11:31 AM
> To: [EMAIL PROTECTED]
> Subject: Apache::Filter and cookies
>
>
> Anyone have experience w/ Apache::Filter and handlers that
> set cookies..
>
> It looks like they are being lost..
I can set them just fine. see the packages below...
>
> I found an article on an archive of someone saying they are
> having the same
> problem and someone else said the solution was to just not
> send the header,
in recent versions of Filter, calling send_http_header is basically a no-op
unless you are the last filter in the chain (I say basically because it will
set the content-type if you call send_http_header($type), though).
> but you were fine as long as you were setting them... this
> does not appear
> to be working for me..
>
> Also what do people prefer Apache::Filter or
> Apache::OutputChain...
I think OutputChain is getting deprecated. it is rather old and hasn't been
updated in a while.
Ken (somehow:) manages to keep tweaking Filter and more and more modules are
taking advantage of it.
> I tried
> OutputChain yesterday but no matter what I tried it wasnt actually
> compressing the output (w/ Apache::GzipChain), and I followed the
> documentation to a T.
>
>
HTH
--Geoff
package Custom::One;
use Apache::Constants qw( OK );
use strict;
sub handler {
my $r = shift;
$r = $r->filter_register;
# try both ways...
my $cookie = Apache::Cookie->new($r,
-name=> "foo",
-value => "492f183ad42ec80fc84d",
-path=> "/",
-expires => "+10d"
);
$cookie->bake;
$r->headers_out->set('Set-Cookie' => "name=bar");
$r->send_http_header('text/plain');
print "filter one...\n";
return OK ;
}
1;
package Custom::Two;
use Apache::Constants qw( OK );
use strict;
sub handler {
my $r = shift;
$r = $r->filter_register;
my $fh = $r->filter_input;
local $/;
my $string = <$fh>;
$r->send_http_header('text/plain');
print $string, "filter two...\n";
print join "\n", $r->headers_out->get('Set-Cookie');
return OK ;
}
1;
RE: Apache::Filter upgrade issues...
> -Original Message-
> From: Trevor Phillips [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, May 05, 2001 2:21 AM
> To: ModPerl Mail List
> Subject: Apache::Filter upgrade issues...
>
>
> Hi! I recently upgraded a test server to a recent
> Apache::Filter, and hit
> problems due to the new dependency on filter_register() being
> called. I
> don't mind upgrading my filters to call this, but I have one,
> in which I
> use Apache::Request (a sub-class of Apache), which I cannot
> seem to work
> around.
>
> The guts of the code goes something like this:
>
> sub handler
> {
>my $r = shift;
>my $IsFilter = ($r->dir_config('Filter') =~ /^on/i?1:0);
>$r = Apache::Request->new($r);
>if ($IsFilter)
>{
> $r = $r->filter_register();
> my ($fh, $status) = $r->filter_input();
> return $status unless $status == OK; # The Apache::Constants OK
> my @file = <$fh>;
>}
> etc...
> }
>
> The above code fails in that the extra methods provided by
> Apache::Request
> are
> no longer there.
>
> The above code worked fine previously (prior to the requirement of
> filter_register)...
>
> Any ideas? How can I use both Apache::Filter and
> Apache::Request together?
well, part of the problem is that Apache->request($r) doesn't bless a new
request properly.
I know that Ken has recently tried working on the problem and had placed it
on Doug's radar:
http://marc.theaimsgroup.com/?t=9860080401&w=2&r=1
(ping :)
at any rate, it probably won't work, but maybe try switching the order
around? That is, maybe call Apache::Request->new on the request object
returned by filter_register?
HTH
--Geoff
RE: Apache::Filter upgrade issues...
I've run into this before as well, and what i ended up doing to get around
it was keeping the original $r around long enough to call filter_register.
my $r = shift;
my $req = Apache::Request->new($r);
$r = $r->filter_register();
adam
> -Original Message-
> From: Trevor Phillips [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, May 05, 2001 2:21 AM
> To: ModPerl Mail List
> Subject: Apache::Filter upgrade issues...
>
>
> Hi! I recently upgraded a test server to a recent
> Apache::Filter, and hit
> problems due to the new dependency on filter_register() being
> called. I
> don't mind upgrading my filters to call this, but I have one,
> in which I
> use Apache::Request (a sub-class of Apache), which I cannot
> seem to work
> around.
>
> The guts of the code goes something like this:
>
> sub handler
> {
>my $r = shift;
>my $IsFilter = ($r->dir_config('Filter') =~ /^on/i?1:0);
>$r = Apache::Request->new($r);
>if ($IsFilter)
>{
> $r = $r->filter_register();
> my ($fh, $status) = $r->filter_input();
> return $status unless $status == OK; # The Apache::Constants OK
> my @file = <$fh>;
>}
> etc...
> }
>
> The above code fails in that the extra methods provided by
> Apache::Request
> are
> no longer there.
>
> The above code worked fine previously (prior to the requirement of
> filter_register)...
>
> Any ideas? How can I use both Apache::Filter and
> Apache::Request together?
>
> --
> . Trevor Phillips -
http://jurai.murdoch.edu.au/ .
: CWIS Systems Administrator - [EMAIL PROTECTED] :
| IT Services - Murdoch University |
>--- Member of the #SAS# & #CFC# <
| On nights such as this, evil deeds are done. And good deeds, of /
| course. But mostly evil, on the whole. /
\ -- (Terry Pratchett, Wyrd Sisters) /
Re: Apache::Filter problems with HEAD...
Aha, this is a new bug with the new version of Apache::Filter. As of 1.008, the headers aren't sent until the first body text is output. That means that during a HEAD request, they're never sent. I've got a fix in mind - in the meantime you can downgrade to 1.007. [EMAIL PROTECTED] (Trevor Phillips) wrote: >I've discovered some problems that I think are related to Apache::Filter. It >certainly seems to affect only mod_perl scripts which use Apache::Filter... > >Basically, when you do a HEAD request method, you don't get any headers back. >In fact, you don't get anything! When you do a normal GET method, you get all >the headers, as well as the page content. > >I've tested this with different mod_perl scripts (which all support >Apache::Filter), and they all seem to do it. > >Is this a problem with Apache::Filter's handling of HEAD requests? > >-- >.. Trevor Phillips - http://jurai.murdoch.edu.au/ . >: CWIS Systems Administrator - [EMAIL PROTECTED] : >| IT Services - Murdoch University | > >--- Member of the #SAS# & #CFC# < >| On nights such as this, evil deeds are done. And good deeds, of / >| course. But mostly evil, on the whole. / > \ -- (Terry Pratchett, Wyrd Sisters) / > ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
Re: Apache::Filter/::RegistryFilter/::Compress problem.
On Mon, 2 Oct 2000, kevin montuori wrote: > > > folks -- > > i'm wondering if anyone else has seen the following behaviour, and, > if you have, how you dealt with it. here's the problem: > > i have a bunch (200 or so) CGI scripts being handled by > Apache::RegistryFilter then Apache::Compress, i.e., > > >SetHandlerperl-script >PerlSetVarFilter On >PerlHandler Apache::RegistryFilter Apache::Compress > > > this typically works very well; however, on occasion i get the > following error (reformatted): > > [Sun Oct 1 21:19:49 2000] [error] [Sun Oct 1 21:19:49 2000] > null: Undefined subroutine &Apache::RegistryFilter::handler > called at > /usr/local/lib/perl5/site_perl/5.005/Apache/Compress.pm line 37. Do you have StatINC in that mix anywhere? -- Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org | AxKit: http://axkit.org
Re: Apache::Filter/::RegistryFilter/::Compress problem.
>>> Matt Sergeant writes: ms> On Mon, 2 Oct 2000, kevin montuori wrote: >> i'm wondering if anyone else has seen the following behaviour, >> and, if you have, how you dealt with it. [...] ms> Do you have StatINC in that mix anywhere? i do not. should i? k. -- kevin montuori support independent booksellers -- http://www.booksense.com
Re: Apache::Filter/::RegistryFilter/::Compress problem.
[EMAIL PROTECTED] (kevin montuori) wrote: > i'm wondering if anyone else has seen the following behaviour, and, > if you have, how you dealt with it. here's the problem: > > i have a bunch (200 or so) CGI scripts being handled by > Apache::RegistryFilter then Apache::Compress, i.e., > > > SetHandlerperl-script > PerlSetVarFilter On > PerlHandler Apache::RegistryFilter Apache::Compress > Hi Kevin, Do you also have config lines like PerlModule Apache::RegistryFilter PerlModule Apache::Compress somewhere in the config file? You should. If you don't, I think mod_perl does some magical loading of modules you need (I'm not even sure of that, since I always load the modules explicitly), but it might get messed up when new children are created or something. Other than that, is the filtering setup working okay? ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
Re: Apache::Filter/::RegistryFilter/::Compress problem.
>>> Ken Williams writes: kw> Do you also have config lines like kw> PerlModule Apache::RegistryFilter kw> PerlModule Apache::Compress kw> somewhere in the config file? You should. i don't; i've been letting mod_perl do its own thing there. i'll make that change. kw> Other than that, is the filtering setup working okay? indeed. it's pretty excellent how much of a performance kick compressing the content gets you. furthermore, i like the apache::filter API (such as it is) -- it's been trivial to write custom filters. thanks for your help. cheers, k. -- kevin montuori support independent booksellers -- http://www.booksense.com
Re: Apache::Filter doesn't filter right
On Tue, 3 Apr 2001, Michael Nachbaur wrote: > I'm having a problem with Apache::Filter (and Apache::OutputChain) which I > don't think is related to Apache::Filter itself, but I can't seem to track > the problem down. > > I wrote a content handler which outputs XML, which I want to then be > processed by AxKit. So, I did: > > SetHandler perl-script > PerlSetVar Filter On > PerlHandler HTTPFilter AxKit > > The output that I get is the combination of HTTPFilter's output, and AxKit's > output (one right before the other). So, it seems that HTTPFilter's output > is successfully making it into AxKit (otherwise it wouldn't process its > output correctly), but is still making its way to the browser. > > Any ideas? It could be the bug in AxKit, which is fixed by 1.3_90 (and _91). -- /||** Founder and CTO ** ** http://axkit.com/ ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\
Re: Apache::Filter: Can't locate object method "TIEHANDLE"
I think your assessment is correct, though I'm not sure what would cause it.
How about changing the following at line 72 for some info:
warn "Untie()ing STDOUT" if $debug;
warn "tied(*STDOUT) is " . tied(*STDOUT) . ", " . *STDOUT if $debug;
$info->{'old_stdout'} = ref tied(*STDOUT);
untie *STDOUT;
[EMAIL PROTECTED] (Roland Alder) wrote:
>Hi there.
>
>I want to use Apache::Filter, but i can't get it running.
>
>I'm using Apache 1.3.9 with mod_perl 1.21 (EVERYTHING=1) and Perl
>5.004_04.
>
>My installation, as well 'make test' of Apache::Filter return the
>following error in the Apache Log:
>
>[error] Can't locate object method "TIEHANDLE" via package "" at
>/var/galaxyweb/perl/Apache/Filter.pm line 81.
>
>When i enable debug in Apache::Filter, i see the following messages:
>
>***info for /var/galaxyweb/htdocs/index.html is at
>/var/galaxyweb/perl/Apache/Filter.pm line 32.
>/var/galaxyweb/htdocs/index.html: This is the first filter at
>/var/galaxyweb/perl/Apache/Filter.pm line 61.
>Untie()ing STDOUT at /var/galaxyweb/perl/Apache/Filter.pm line 71.
>Tie()ing STDOUT to Apache::Filter at /var/galaxyweb/perl/Apache/Filter
>..pm line 86.
>END info is old_stdout count 1 fh_in GLOB(0x8571808) at
>/var/galaxyweb/perl/Apache/Filter.pm line 90.
>
>***info for /var/galaxyweb/htdocs/index.html is old_stdout count
>1 fh_in GLOB(0x8571808) at /var/galaxyweb/perl/Apache/Filter.pm line
>32, chunk 179.
>Turning STDOUT (Apache::Filter) into filter_fh_in at
>/var/galaxyweb/perl/Apache/Filter.pm line 55.
>Tie()ing STDOUT to '' for finish at /var/galaxyweb/perl/Apache/Filter.
>pm line 79.
>[Fri Oct 15 00:56:30 1999] [error] Can't locate object method
>"TIEHANDLE" via package "" at /var/galaxyweb/perl/Apache/Filter.pm
>line 81.
>
>It seems to me, that the 'ref tied(*STDOUT)' saved to $info->
>{'old_stdout'} in the first filter doesn't return anything.
>
>Snippet of my Apache Configfile:
>
>PerlModule Apache::Filter
>
>
> SetHandler perl-script
> PerlSetVar Filter On
> PerlHandler Apache::Testfilter2 Apache::Testfilter2
> Options +ExecCGI
>
>
>It would be great, if someone has some hints what i can do or what
>goes wrong. Everything else i tried (Apache::Registry and a
>standalone handler) is working fine.
>
>Thank you.
>
>With kind regards,
>
> Roland Alder
>
>
------
Ken Williams Last Bastion of Euclidity
[EMAIL PROTECTED]The Math Forum
Re: Apache::Filter: Can't locate object method "TIEHANDLE"
Dear Ken.
Thank you for your assistance.
> warn "tied(*STDOUT) is " . tied(*STDOUT) . ", " . *STDOUT if $debug;
> $info->{'old_stdout'} = ref tied(*STDOUT);
> untie *STDOUT;
I did the change and got the following output:
***info for /var/galaxyweb/htdocs/index.html is at
/var/galaxyweb/perl/Apache/Filter.pm line 32.
/var/galaxyweb/htdocs/index.html: This is the first filter at
/var/galaxyweb/perl/Apache/Filter.pm line 61.
Untie()ing STDOUT at /var/galaxyweb/perl/Apache/Filter.pm line 71.
tied(*STDOUT) is , *main::STDOUT at /var/galaxyweb/perl/Apache/Filter.
pm line 72.
Tie()ing STDOUT to Apache::Filter at /var/galaxyweb/perl/Apache/Filter
.pm line 91.
END info is old_stdout count 1 fh_in GLOB(0x8630dac) at
/var/galaxyweb/perl/Apache/Filter.pm line 95.
***info for /var/galaxyweb/htdocs/index.html is old_stdout count
1 fh_in GLOB(0x8630dac) at /var/galaxyweb/perl/Apache/Filter.pm line
32, chunk 179.
Turning STDOUT (Apache::Filter) into filter_fh_in at
/var/galaxyweb/perl/Apache/Filter.pm line 55.
Tie()ing STDOUT to '' for finish at /var/galaxyweb/perl/Apache/Filter.
pm line 84.
[Fri Oct 15 09:03:11 1999] [error] Can't locate object method
"TIEHANDLE" via package "" at /var/galaxyweb/perl/Apache/Filter.pm
line 86.
It seems to me (i don't know much about tieing) as STDOUT isn't tied.
Do you have an idea? What should tied(*STDOUT) return?
I will try it today on another plattform (Solaris instead of Linux) and look what's
happening there.
Thank you again,
Roli
--
Roland Alder, Doerfli 3 / Schmidweg, CH-8634 Hombrechtikon
e-mail: [EMAIL PROTECTED], WWW: http://galaxy.ch/roli/
Re: Apache::Filter: Can't locate object method "TIEHANDLE"
Yes, that's what it looks like to me too. STDOUT is supposed to be tied to the
Apache package, and for some reason it's not. I'm not sure why that would be -
can anyone on the list shed some light?
Perhaps it got untied in some previous run of the server. As a simple test,
you might try restarting the server and testing whether it also happens on the
first request, possibly even running in -X mode.
[EMAIL PROTECTED] (Roland Alder) wrote:
>Dear Ken.
>
>Thank you for your assistance.
>
>> warn "tied(*STDOUT) is " . tied(*STDOUT) . ", " . *STDOUT if $debug;
>> $info->{'old_stdout'} = ref tied(*STDOUT);
>> untie *STDOUT;
>
>I did the change and got the following output:
>
>***info for /var/galaxyweb/htdocs/index.html is at
>/var/galaxyweb/perl/Apache/Filter.pm line 32.
>/var/galaxyweb/htdocs/index.html: This is the first filter at
>/var/galaxyweb/perl/Apache/Filter.pm line 61.
>Untie()ing STDOUT at /var/galaxyweb/perl/Apache/Filter.pm line 71.
>tied(*STDOUT) is , *main::STDOUT at /var/galaxyweb/perl/Apache/Filter.
>pm line 72.
>Tie()ing STDOUT to Apache::Filter at /var/galaxyweb/perl/Apache/Filter
>..pm line 91.
>END info is old_stdout count 1 fh_in GLOB(0x8630dac) at
>/var/galaxyweb/perl/Apache/Filter.pm line 95.
>***info for /var/galaxyweb/htdocs/index.html is old_stdout count
>1 fh_in GLOB(0x8630dac) at /var/galaxyweb/perl/Apache/Filter.pm line
>32, chunk 179.
>Turning STDOUT (Apache::Filter) into filter_fh_in at
>/var/galaxyweb/perl/Apache/Filter.pm line 55.
>Tie()ing STDOUT to '' for finish at /var/galaxyweb/perl/Apache/Filter.
>pm line 84.
>[Fri Oct 15 09:03:11 1999] [error] Can't locate object method
>"TIEHANDLE" via package "" at /var/galaxyweb/perl/Apache/Filter.pm
>line 86.
>
>It seems to me (i don't know much about tieing) as STDOUT isn't tied.
>Do you have an idea? What should tied(*STDOUT) return?
>I will try it today on another plattform (Solaris instead of Linux) and look
what's
>happening there.
>
>Thank you again,
>
>Roli
>
>
>--
>Roland Alder, Doerfli 3 / Schmidweg, CH-8634 Hombrechtikon
>e-mail: [EMAIL PROTECTED], WWW: http://galaxy.ch/roli/
>
>
------
Ken Williams Last Bastion of Euclidity
[EMAIL PROTECTED]The Math Forum
Re: Apache::Filter: Can't locate object method "TIEHANDLE"
Hi Ken.
Thank you again.
> Perhaps it got untied in some previous run of the server. As a
> simple test, you might try restarting the server and testing
> whether it also happens on the first request, possibly even
> running in -X mode.
I tried it. It is unset on the first request too. It is even unset
in the first request when i start apache with -X.
I tested this also with Embperl ([+ tied(*STDOUT) +]). It's unset to
(no surprise).
Can the sfio Library i compiled perl with be a problem?
I've compiled perl with sfio for historical reasons (was required
earlier for FastCGI and such). But i think this shouldn't be a
problem.
Because on my installation PerlHandlers seem to work (Embperl und
such),
even *STDOUT isn't tied, i came to the idea to untie *STDOUT in the
last
Filter (instead of tieing it to the stored value ('old_stdout').
I replaced "tie *STDOUT, $info->{'old_stdout'};" with "untie
*STDOUT;" and
tested it. It works. Is this a bad idea with more problems to rise,
or a
usable workaround?
Thanks.
--
Roland Alder, Doerfli 3 / Schmidweg, CH-8634 Hombrechtikon
e-mail: [EMAIL PROTECTED], WWW: http://galaxy.ch/roli/
Re: Apache::Filter: Can't locate object method "TIEHANDLE"
Aha. I bet sfio is the problem, and I bet your solution is the correct
one. I think that when you use sfio, mod_perl doesn't need to tie
STDOUT (it uses other methods for redirection), so Apache::Filter gets
confused. Can anyone confirm these hypotheses?
If the following patch works for you, I'll incorporate it into the
official version.
-
--- Filter.pm 1999/09/12 03:25:45 1.3
+++ Filter.pm 1999/10/17 05:58:27
@@ -78,7 +78,13 @@
# it was originally (usually the browser, unless this is a sub-request)
warn "Tie()ing STDOUT to '$info->{'old_stdout'}' for finish" if $debug;
-tie *STDOUT, $info->{'old_stdout'}; # Do we need to pass $r too? Hope not.
+ if ($info->{'old_stdout'}) {
+ # Running under stdio, restore previous tie
+ tie *STDOUT, $info->{'old_stdout'};
+ } else {
+ # Running under sfio, just untie
+ untie *STDOUT;
+ }
$r->send_http_header();
} else {
# There are more filters after this one.
-
[EMAIL PROTECTED] (Roland Alder) wrote:
>Hi Ken.
>
>Thank you again.
>
>> Perhaps it got untied in some previous run of the server. As a
>> simple test, you might try restarting the server and testing
>> whether it also happens on the first request, possibly even
>> running in -X mode.
>
>I tried it. It is unset on the first request too. It is even unset in
>the first request when i start apache with -X.
>
>I tested this also with Embperl ([+ tied(*STDOUT) +]). It's unset to
>(no surprise).
>
>Can the sfio Library i compiled perl with be a problem? I've compiled
>perl with sfio for historical reasons (was required earlier for FastCGI
>and such). But i think this shouldn't be a problem.
>
>Because on my installation PerlHandlers seem to work (Embperl und
>such), even *STDOUT isn't tied, i came to the idea to untie *STDOUT in
>the last Filter (instead of tieing it to the stored value
>('old_stdout').
>
>I replaced "tie *STDOUT, $info->{'old_stdout'};" with "untie *STDOUT;"
>and tested it. It works. Is this a bad idea with more problems to rise,
>or a usable workaround?
>
>Thanks.
>
>
>--
>Roland Alder, Doerfli 3 / Schmidweg, CH-8634 Hombrechtikon
>e-mail: [EMAIL PROTECTED], WWW: http://galaxy.ch/roli/
>
>
------
Ken Williams Last Bastion of Euclidity
[EMAIL PROTECTED]The Math Forum
Re: Apache::Filter: Can't locate object method "TIEHANDLE"
Hi Ken. > If the following patch works for you, I'll incorporate it into the > official version. It works. I tested it with my Module as the only Filter and with a Chain of EmbperlFilter and my Module. Thank you for your assistance, Roli -- Roland Alder, Doerfli 3 / Schmidweg, CH-8634 Hombrechtikon e-mail: [EMAIL PROTECTED], WWW: http://galaxy.ch/roli/
