Re: rfc: new filtering APIs
Finally, other than add/remove filters APIs which we have talked about, what other APIs do you want for filters? is there an interface to filter_init? see the discussion on http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9673 or CHANGES file for a description of why it was added. this API may be crucial to mod_perl developers who want to handle conditional GET requests properly with their filters. --Geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ModPerl::RegistryCooker messing with status.
I upgraded to 1.99.08 a couple of days ago and noticed strange behavior in my CGI scripts that run under ModPerl::Registry -- in 1.99.07 they worked fine. In 1.99.08, however, every single one of my scripts has this appended to its standard output: - OK Internal Server Error - Seems like even though my scripts execute OK, Registry thinks that bad status was returned, and makes an error page out of it. Looking at CVS, I tracked down the problem to a commit made by Stas 3 weeks ago to ModPerl::RegistryCooker.pm (1.23 -> 1.24). http://cvs.apache.org/viewcvs.cgi/modperl-2.0/ModPerl-Registry/lib/ModPerl/RegistryCooker.pm.diff?r1=1.23&r2=1.24 By reversing the patch and restarting Apache, the problem went away. Most of my scripts end like this: print $t->output; It looks like RegistryCooker examines the value of the last statement in the script -- changing the snippet above to print $t->output; 1; also fixes the problem. However, I think that ending a script with a fall-off is a perfectly valid way to end it. Another point is that this change breaks compatibility with old (1.3) Registry scripts. What do you people think? - Dmitri. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: rfc: new filtering APIs
Geoffrey Young wrote:
Finally, other than add/remove filters APIs which we have talked
about, what other APIs do you want for filters?
is there an interface to filter_init?
see the discussion on
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9673
or CHANGES file for a description of why it was added.
this API may be crucial to mod_perl developers who want to handle
conditional GET requests properly with their filters.
First of all you can always do:
unless ($filter->ctx) {
# filter is called for the first time
# and this code won't be run only once
$filter->ctx(1);
}
so if you want to do something once, or e.g. remove yourself you can do it
in this block. So it seems to be similar to filter_init. Or am I wrong
here? I agree that having a dedicated filter_init seems to be cleaner and
probably more efficient.
If filter_init is wanted, how should it be set by the Perl code? Using an
optional second argument to the filter configuration?
PerlOutputFilterHandler MyFilter MyFilter::init
Also can you please give me some useful test I can play with? Probably one
of the examples from your book will do ;)
Thanks Geoff.
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: ModPerl::RegistryCooker messing with status.
Dmitri Tikhonov wrote:
I upgraded to 1.99.08 a couple of days ago and noticed strange behavior
in my CGI scripts that run under ModPerl::Registry -- in 1.99.07 they
worked fine. In 1.99.08, however, every single one of my scripts has this
appended to its standard output:
As you've figured out my original bug fix was wrong, since it broke other
cases. We need more tests to avoid this kind of bugs in the future. it
seems that Apache::Registry and Apache::PerlRun handle the return codes
differently. So without covering all possible cases I'm not sure what's
the best approach. Can you please try the following patch and let me know
if it works for you? Thanks.
(it's really only the first chunk that tries to fix the bug, the rest are
just some fixes to sync with 1.0.)
Index: lib/ModPerl/RegistryCooker.pm
===
RCS file:
/home/cvs/modperl-2.0/ModPerl-Registry/lib/ModPerl/RegistryCooker.pm,v
retrieving revision 1.27
diff -u -r1.27 RegistryCooker.pm
--- lib/ModPerl/RegistryCooker.pm 6 Jan 2003 10:42:38 - 1.27
+++ lib/ModPerl/RegistryCooker.pm 17 Jan 2003 06:15:14 -
@@ -163,9 +163,13 @@
# handlers shouldn't set $r->status but return it
my $old_status = $self->[REQ]->status;
my $rc = $self->run;
-$self->[REQ]->status($old_status);
+my $new_status = $self->[REQ]->status;
-return ($rc != Apache::OK) ? $rc : $self->[STATUS];
+# only if the script has changed the status, reset to the old
+# status and return the new status
+return $old_status != $new_status
+? $self->[REQ]->status($old_status)
+: $rc;
}
#
@@ -185,11 +189,11 @@
$self->set_script_name;
$self->chdir_file;
-my $rc = Apache::OK;
my $cv = \&{"$package\::handler"};
my %orig_inc = %INC;
+my $rc;
{ # run the code and preserve warnings setup when it's done
no warnings;
eval { $rc = $cv->($r, @_) };
@@ -208,11 +212,11 @@
#XXX: $self->chdir_file("$Apache::Server::CWD/");
-if ( ($rc = $self->error_check) != Apache::OK) {
-return $rc;
+if ( (my $err_rc = $self->error_check) != Apache::OK) {
+return $err_rc;
}
-return Apache::OK;
+return wantarray ? (Apache::OK, $rc) : Apache::OK;
}
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: ModPerl::RegistryCooker messing with status.
On Fri, 17 Jan 2003, Stas Bekman wrote: > Dmitri Tikhonov wrote: > > I upgraded to 1.99.08 a couple of days ago and noticed strange behavior > > in my CGI scripts that run under ModPerl::Registry -- in 1.99.07 they > > worked fine. In 1.99.08, however, every single one of my scripts has this > > appended to its standard output: > > As you've figured out my original bug fix was wrong, since it broke other > cases. We need more tests to avoid this kind of bugs in the future. it > seems that Apache::Registry and Apache::PerlRun handle the return codes > differently. So without covering all possible cases I'm not sure what's > the best approach. Can you please try the following patch and let me know > if it works for you? Thanks. This patch seems to work just fine, thanks, Stas. - Dmitri. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
