Not totally lost, it depends on whether the failing output filter is
before or after the http_header filter.
In the latter case, we already sent (part of) the response to the
client, so we must abort.
But in the former case, ap_die() will generate a 500, so to not let
the client without any response.
On Thu, Jun 4, 2015 at 7:20 PM, Eric Covener <cove...@gmail.com> wrote:
> maybe part of what I am missing is that any output filter failure is a lost
> cause, and the mapping happens on the input filter side.
>
>
> On Thu, Jun 4, 2015 at 1:15 PM Eric Covener <cove...@gmail.com> wrote:
>>
>> 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 <wr...@rowe-clan.net>
>> 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 <wr...@rowe-clan.net>
>>> 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 <wr...@rowe-clan.net>
>>>> wrote:
>>>>>
>>>>> On Tue, Jun 2, 2015 at 6:32 AM, Jim Jagielski <j...@jagunet.com> 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.
>>>>
>>>>
>>>
>
