On 6/1/23 3:30 PM, Stefan Eissing via dev wrote:
>>> Modified: httpd/httpd/trunk/modules/http/http_request.c
>>> URL:
>>> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http/http_request.c?rev=1910161&r1=1910160&r2=1910161&view=diff
>>> ==============================================================================
>>> --- httpd/httpd/trunk/modules/http/http_request.c (original)
>>> +++ httpd/httpd/trunk/modules/http/http_request.c Thu Jun 1 12:21:03 2023
>>> @@ -84,38 +84,25 @@ static void ap_die_r(int type, request_r
>>> return;
>>> }
>>>
>>> - if (!ap_is_HTTP_VALID_RESPONSE(type)) {
>>> - ap_filter_t *next;
>>> -
>>> - /*
>>> - * Check if we still have the ap_http_header_filter in place. If
>>> - * this is the case we should not ignore the error here because
>>> - * it means that we have not sent any response at all and never
>>> - * will. This is bad. Sent an internal server error instead.
>>> - */
>>> - next = r->output_filters;
>>> - while (next && (next->frec != ap_http_header_filter_handle)) {
>>> - next = next->next;
>>> - }
>>
>> Out of curiosity: You changed to using the flag instead as the above did not
>> detect all cases correctly or because it is not
>> performance optimal?
>
> It did not catch all cases any longer since the httpd header filter does not
> remove itself any longer. This is a result of the RESPONSE buckets changes in
> trunk. So when ap_die() was called during response body processing, it added
> a 500 body content to the response.
>
> Instead of fiddling here with filter chain expectations, I found it more sane
> to keep the bit at request_rec. But it can be discussed if there is a better
> choice.
I think the new approach is cleaner and less performance consuming. I was just
curious about the motivation to do it.
Regards
Rüdiger
