On Tue, Jan 21, 2014 at 7:41 PM, Eric Covener <[email protected]> wrote: > On Tue, Jan 21, 2014 at 9:25 AM, Yann Ylavic <[email protected]> wrote: >> On Tue, Jan 21, 2014 at 2:02 PM, Eric Covener <[email protected]> wrote: >>> https://issues.apache.org/bugzilla/show_bug.cgi?id=56035 >>> >>> I think it would simplify a lot of this if we said that any filter >>> that returns AP_FILTER_ERROR should also put an error bucket on the >>> output, allowing us to skip calling ap_die after ap_invoke_handler(). >> >> Contrarywise, if ap_die() is made "robust" against any status (as I >> tried in the PR's proposed patch), why wouldn't it be always called >> after the handler to ensure a response is always sent to the client? >> >> In the OK/DONE cases, just finalize the request; in any HTTP status >> case, send the custom response; in any other case (non-HTTP status >> like AP_FILTER_ERROR), do nothing if a response was already sent or >> raise an INTERNAL_SERVER_ERROR otherwise. > > Per the trunk doc:
(bad paste into browser triggered send) /** Returned by any filter if the filter chain encounters an error * and has already dealt with the error response. */ #define AP_FILTER_ERROR -102 So I think it should go up in the short-circuit with OK|DONE in ap_die(), without any book-keeping to make sure an error was sent.
