The only thing that puzzles me about this thread is that it seems to be
leaning towards the position that says;
If the developer just does straight out weird stuff and messes with
$r-status in a cgi-script and expects it to work with Apache::Registry
(which as far as I understand is a cgi
OK, so we are not done with it.
The first thing I'd like to see is to have Apache::Registry and
Apache::PerlRun agree on how they handle return codes, because they
aren't the same. Once this happens, the Cooker will do the same.
As you have mentioned we have a problem with relying on return
Geoffrey Young wrote:
OK, so we are not done with it.
The first thing I'd like to see is to have Apache::Registry and
Apache::PerlRun agree on how they handle return codes, because they
aren't the same. Once this happens, the Cooker will do the same.
As you have mentioned we have a problem
The logic here is simpler:
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.
Geoffrey Young wrote:
The logic here is simpler:
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
Stas Bekman wrote:
Geoffrey Young wrote:
The logic here is simpler:
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
David Dick wrote:
[...]
The only thing that messed me up was when running a script with mod_cgi,
you can return your own status codes and apache will happily go along
with it. However, when you run the same script under mod_perl's
Apache::Registry, you suddenly get Apache::Registry second
