I'm a little confused by AP_FILTER_ERROR as used in the handlers we have
now.  Is this return code evolved to mean only to issue a 500 error if the
response has not been committed?

/** Returned by any filter if the filter chain encounters an error
 *  and has already dealt with the error response.
 */
#define AP_FILTER_ERROR         -102

But now the handlers have this pattern:
                status = ap_pass_brigade(r->output_filters, bbout);
                if (status != APR_SUCCESS) {
                    /* no way to know what type of error occurred */
                    ap_log_rerror(APLOG_MARK, APLOG_DEBUG, status, r,
APLOGNO(01410)
                             "reflector_handler: ap_pass_brigade returned
%i",
                                  status);
                    return AP_FILTER_ERROR;
                }

So we don't actually retain whether some filter really handled the error.
I think in practice this is okay, because the handlers can't make a very
smart decision here anyway.

On Thu, Jun 4, 2015 at 12:44 PM William A Rowe Jr <[email protected]>
wrote:

> More context at your fingertips without refreshing httpd-2.2 branch,
> first...
>
> https://bz.apache.org/bugzilla/show_bug.cgi?id=57832
>
> On Thu, Jun 4, 2015 at 11:26 AM, William A Rowe Jr <[email protected]>
> wrote:
>
>> [Changing subject, don't mean to hijack the 2.4 activity train]
>>
>> There is a modestly important patch, already backported to 2.4.x branch,
>> that is still sitting in 2.2 status.  Could one more committer please
>> review
>> and vote on that remaining fix?
>>
>> Because it helps to avert an unintended doubled response in some edge
>> cases, I consider this one important enough to hold up 2.2 tag for some
>> more hours.
>>
>> Bill
>>
>>
>> On Tue, Jun 2, 2015 at 4:36 PM, William A Rowe Jr <[email protected]>
>> wrote:
>>
>>> On Tue, Jun 2, 2015 at 6:32 AM, Jim Jagielski <[email protected]> wrote:
>>>
>>>> Although there are some cool things that I'd like to see in
>>>> 2.4.13, I don't want to hold off any longer (plus, those
>>>> cool things would be good incentive for a 2.4.14 sooner
>>>> rather than later).
>>>>
>>>> I plan to T&R 2.4.13 on Thurs, by Noon eastern.
>>>>
>>>
>>> +1, planning to match you with a T&R of 2.2.30 on the same timetable.
>>>
>>> There is a nominally important last patch in 2.2 STATUS, if a third pair
>>> of eyes have the cycles to review it.
>>>
>>
>>
>

Reply via email to