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: > > ap_die() looks like a safety guard to me... > >> >> This seems to be how the in-tree ones work, sans mod_ssl when it fails >> to do a TLS upgrade (unclear to me if all hope is lost there) >> >> Any thoughts? I don't think there is anything easy we can do about >> modules who ignore the AP_FILTER_ERROR and write data anyway, but we >> can stop double error responses and logged status codes that don't >> match error documents. > > If ap_die() does nothing (ie. r->status is still HTTP_OK after the > call), can't the "original" status be simply restored to avoid logging > HTTP_OK instead? > > Regards, > Yann. -- Eric Covener [email protected]
