david_dick at iprimus
Feb 10, 2003, 5:32 PM
Post #4 of 8
(536 views)
Permalink
|
|
Re: Registry return codes handling (was Re: Possible bug with a 206 Partial Response)
[In reply to]
|
|
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 is Apache::OK return that new status. Otherwise
>>> return the execution status (which will be either Apache::OK or
>>> Apache::SERVER_ERROR)
>>>
>>
>> this is different that how Apache::Registry in 1.0 handles it,
>> specifically under circumstances like redirects, where people
>> typically do
>>
>> $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.
>
>
> 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 status.
> Because if the script doesn't use the mod_perl API, it normally may
> return absolutely anything, which may mess things up. So the safest
> approach, is to run the script, ignore its return value (not status!)
> and return OK or SERVER_ERROR based on whether the execution was
> error-free or not. Plus add the hack of returning of the new status if
> it was changed by the script. That's the approach that is taken by
> Apache::Registry and it seems that most people are happy with it.
> PerlRun does return the execution status, but when I first made the
> Cooker use this approach we immediately received a bug report, where
> the script wasn't doing the right thing.
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 guessing the
script and adding to the script, something that for (especially)
USE_LOCAL_COPY and PARTIAL_CONTENT responses is just wrong. I've just
ended up writing my own version of Apache::Registry that always returns
OK, which works for my purposes and therefore I'm content.
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 emulation layer), we will
accommodate them. However, if the s/he just expects Apache::Registry to
behave like it mod_cgi (except faster, more brilliant, etc :)) then they
will be disappointed. I am probably just fixated over my current work
and can't see the proverbial forest. Can somebody explain this for me?
|
