On Tue, Jan 21, 2014 at 2:02 PM, Eric Covener <cove...@gmail.com> 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. 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.
