The logic here is simpler:this is different that how Apache::Registry in 1.0 handles it, specifically under circumstances like redirects, where people typically do
1. store the new status code (just in case the script has changed it)
2. reset the status code to the one before the script execution
3. if the script has attempted to change the status by itself and the execution status is Apache::OK return that new status. Otherwise return the execution status (which will be either Apache::OK or Apache::SERVER_ERROR)
$r->headers_out(Location => '/foo');
$r->status(REDIRECT);
return REDIRECT;
what you're saying now is that the status is only propagated if you return OK. (at least that's what I _think_ you're saying - I'm still trying to get back after a week off :)
the logic should probably be something like respect the execution status if it is OK or it matches the new status, making
$r->status(REDIRECT);
return OK;
and
$r->status(REDIRECT);
return REDIRECT;
both valid ways to effectively redirect the request from Registry.
the $r->status() bit was always a hack - nobody is supposed to fiddle with $r->status, which is why mod_perl saves and restores it. we could do with a better way that saved us from all this logic for people who want to use Registry with the mod_perl API. perhaps a version of the Cooker that simply respected (and expected) the script to return a meaningful status code. thus, the script would return SERVER_ERROR if $@ is true, and the return status of the subroutine otherwise. of course, we can't do this in CGI-portable mode, but for folks that want to use Registry as a dispatch mechanism, this is really the preferred way.
--Geoff
