perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: VOID => RUN_ALL or what?
Date Wed, 04 Jun 2003 01:51:23 GMT
Geoffrey Young wrote:
>> It just strikes me odd where we have: this handler if of type VOID, 
>> but in mod_perl we expect it to return Apache::OK. While we are 
>> changing this stacked handlers behavior, may be we should also decide 
>> on this one.
>> So I see two choices:
>> 1. s/VOID/RUN_ALL/ in the docs
>> 2. fix the code to ignore return values for VOID types and remove the 
>> doc comment of "we expect VOID handlers to return Apache::OK 
>> nevertheless"
>> I believe the second choice is the correct one. Since it really 
>> follows the Apache spec.
> while I tend to want to follow the apache specs closely, I'm not sure 
> about this.  the standard mod_perl meme is to always return a value from 
> a handler - by letting ignoring the return value of these and letting 
> the request proceed we're loosing functionality. for instance, filters 
> would no longer be able to use SERVER_ERROR to throw errors, which 
> strikes me as very wrong - what it an input filter fails to process 
> things correctly, the request is allowed to proceed anyway and produce a 
> valid response with possibly corrupt data?

not if you die(). And if you die the client will get 500 in any case.

> as I excercise the filter mechanism, they seem to be a good first try 
> but a bit lacking in a few areas (this would be one) - I supposed it 
> makes sense to continue if the deflate filter fails, since you already 
> have the data, and if the header filter fails the request obviously does 
> as well, but for anything else ignoring return values seems a bad idea.  
> I guess I'd probably prefer to do the right thing over following Apache 
> closely.

Apache filters assert() when something is wrong. Which is equivalent to perl's 
die(), but assert() tends to segfault on me :(

I suppose we have to first define what is the right thing, before going on.

Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker     mod_perl Guide --->

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message