httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Covener <>
Subject Re: AP_FILTER_ERROR and error documents
Date Wed, 22 Jan 2014 00:44:10 GMT
On Tue, Jan 21, 2014 at 7:41 PM, Eric Covener <> wrote:
> On Tue, Jan 21, 2014 at 9:25 AM, Yann Ylavic <> wrote:
>> On Tue, Jan 21, 2014 at 2:02 PM, Eric Covener <> wrote:
>>> 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.

View raw message