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?
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.
--Geoff
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
