You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Eric Covener <co...@gmail.com> on 2014/01/21 14:02:09 UTC

AP_FILTER_ERROR and error documents

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().

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.

-- 
Eric Covener
covener@gmail.com

Re: AP_FILTER_ERROR and error documents

Posted by Eric Covener <co...@gmail.com>.
On Tue, Jan 21, 2014 at 7:41 PM, Eric Covener <co...@gmail.com> wrote:
> On Tue, Jan 21, 2014 at 9:25 AM, Yann Ylavic <yl...@gmail.com> wrote:
>> On Tue, Jan 21, 2014 at 2:02 PM, Eric Covener <co...@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.
>
> 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.

Re: AP_FILTER_ERROR and error documents

Posted by Eric Covener <co...@gmail.com>.
On Tue, Jan 21, 2014 at 9:25 AM, Yann Ylavic <yl...@gmail.com> wrote:
> On Tue, Jan 21, 2014 at 2:02 PM, Eric Covener <co...@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.

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
covener@gmail.com

Re: AP_FILTER_ERROR and error documents

Posted by Yann Ylavic <yl...@gmail.com>.
On Tue, Jan 21, 2014 at 2:02 PM, Eric Covener <co...@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.