perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoffrey Young <>
Subject Re: VOID => RUN_ALL or what?
Date Fri, 06 Jun 2003 13:28:06 GMT

>> 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.

so that's the idiom - return OK or die() from filters?  I guess that's ok, 
but it really seems counterintuitive to me when you set up a filter as


since it means that filter handlers behave differently than other handlers. 
  well, I guess directive handlers also behave differently, but I'm more 
inclined to accept that difference because it's config time and not request 
time - here, we're saying that a subset of request handlers behave 
differently than the rest wrt return codes, and something seems funny about 

>> 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.

well, if there is an official API for this, then we should probably open it 
up (if it isn't already :).  we could also offer shortcuts for the streaming 
API - raw BB filters could have access to $filter->assert, while streaming 
filters could just return SERVER_ERROR, which we could trap and then call 
assert() transparently.

of course, if assert() is segfaulting then it's probably not the preferred 
design :)


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

View raw message