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
PerlOutputFilterHandler
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 that.
There are:
PerlChildInitHandler VOID
and
PerlInputFilterHandler VOID PerlOutputFilterHandler VOID
which currently have the return type of VOID. The first one is a normal handler and we already have to deal with it. The filter handlers *are* different from all other handlers, because they don't stack in the way. And since they don't stack like others, the return value OK/DECLINED/DONE has no relevance. the return value in the case of errors is relevant. But don't forget that RUN_FIRST, RUN_ALL, VOID are different to facilitate stacked handlers, not error handling.
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.
I don't think there is an official API in .h files it just calls assert(), assuming that some other filter has done wrong and this should be fixed before the filter reaches its users. Otherwise they would have chosen some more user friendly response.
of course, if assert() is segfaulting then it's probably not the preferred design :)
;)
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
