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 <[email protected]> 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 <[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. >>>> >>> >>> >>
