You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by William A Rowe Jr <wr...@rowe-clan.net> on 2015/06/04 18:26:40 UTC
T&R of 2.2.13 [corresponding to Re: T&R of 2.4.13]
[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 <ji...@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.
>
Re: T&R of 2.2.13 [corresponding to Re: T&R of 2.4.13]
Posted by Yann Ylavic <yl...@gmail.com>.
The original thread wrt doubled response is [1] (quite long, sorry).
The rationale is that the handlers should not return an HTTP_* error
blindly when they fail to ap_get_brigade(), because the latter can
return AP_FILTER_ERROR when some input filter responds to the client
by itself (e.g. HTTP filter when LimitRequestBody is reached), and the
final ap_die() needs to know about this.
Hence the fix consists in using ap_map_http_request_error() for any
handler failing with ap_get_brigade(), so to translate the
apr_status_t to an HTTP error code, taking care of preserving
AP_FILTER_ERROR if any.
[1] https://www.mail-archive.com/dev@httpd.apache.org/msg61178.html
On Thu, Jun 4, 2015 at 6:43 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 <ji...@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.
>>
>>
>
Re: T&R of 2.2.13 [corresponding to Re: T&R of 2.4.13]
Posted by Yann Ylavic <yl...@gmail.com>.
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 <co...@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 <co...@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 <ji...@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.
>>>>
>>>>
>>>
>
Re: T&R of 2.2.13 [corresponding to Re: T&R of 2.4.13]
Posted by Eric Covener <co...@gmail.com>.
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 <co...@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 <ji...@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.
>>>>
>>>
>>>
>>
Re: T&R of 2.2.13 [corresponding to Re: T&R of 2.4.13]
Posted by Eric Covener <co...@gmail.com>.
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 <ji...@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.
>>>
>>
>>
>
Re: T&R of 2.2.13 [corresponding to Re: T&R of 2.4.13]
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
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 <ji...@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.
>>
>
>
Re: T&R of 2.2.13 [corresponding to Re: T&R of 2.4.13]
Posted by Rob Stradling <ro...@comodo.com>.
s/2.2.13/2.2.30/
?
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online