David Dick wrote:
alrightly, back again. The problem is that Apache::Registry will return a 206, which will trigger the error message. In case there is anyone out there as daft as me :), the crude delegation-type module below can solve this problem. Maniacs who see a need to return 204's, etc can probably extend this to a more general solution. :)

package MyPrefix::Apache::Registry;
use strict;

BEGIN {
use Apache::Registry();
use Apache::Constants qw(:common);
use constant PARTIAL_CONTENT => 206;
}

sub handler {
my ($return) = Apache::Registry::handler(@_);
if ($return == PARTIAL_CONTENT) {
return OK;
} else {
return ($return);
}
}

END { }

1;
When I've tried to run your test script under ModPerl::Registry
(mp2.0) I was surprised to learn that it worked just fine. So far I
was fixing the porting bugs ;) I've added your test script to the
ModPerl::Registry test suite.

We better fix it in the 1.0 core. But before that we need to be clear of how the return codes should be handled, because the currect three implementations all diverge when it comes to handling the return codes/execution status.

In order to simplify the logic, assuming that the script was
successfully executed and inlining some code, the 3 different registry
implementations resemble the following:

Apache::Registry does:

my $old_status = $r->status;
eval { &{$cv}($r, @_) };
return $r->status($old_status);

Apache::PerlRun/RegistryNG do:

my $old_status = $r->status;
eval { &{$cv}($r, @_) };
$r->status($old_status);
return OK;

ModPerl::RegistryCooker does:

# handlers shouldn't set $r->status but return it
my $old_status = $self->[REQ]->status;
eval { &{$cv}($r, @_) };
my $new_status = $self->[REQ]->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)
: OK;

If I'm correct both Apache::PerlRun and Apache::Registry will have
problems in certain situations if we agree that ModPerl::Registry has
the correct logic for handling the execution status. If you can tell
otherwise please give me a test script that doesn't work under
ModPerl::Registry.

But in your particular example, Dick, if you configure the
script to run under Apache::RegistryNG, does it work? If not, that's where the difference between 1.0 and 2.0 lays: ModPerl::Registry doesn't reset status if it wasn't changed by the script.


__________________________________________________________________
Stas Bekman JAm_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



Reply via email to