Re: svn commit: r1874775 - /httpd/httpd/trunk/test/README.travis

[Ruediger Pluem]

On 3/31/20 6:31 PM, Yann Ylavic wrote:
> On Tue, Mar 31, 2020 at 7:11 AM Ruediger Pluem <rpl...@apache.org> wrote:
>>
>> On 3/31/20 1:19 AM, Yann Ylavic wrote:
>>> Index: server/core_filters.c
>>> ===================================================================
>>> --- server/core_filters.c     (revision 1875881)
>>> +++ server/core_filters.c     (working copy)
>>> @@ -543,6 +543,12 @@ static apr_status_t send_brigade_nonblocking(apr_s
>>>
>>>                  rv = apr_bucket_read(bucket, &data, &length, 
>>> APR_BLOCK_READ);
>>>              }
>>> +            if (APR_STATUS_IS_EOF(rv)) {
>>> +                /* Morphing bucket exhausted, next. */
>>> +                apr_bucket_delete(bucket);
>>> +                rv = APR_SUCCESS;
>>> +                continue;
>>> +            }
>>>              if (rv != APR_SUCCESS) {
>>>                  goto cleanup;
>>>              }
>>
>>
>> How is the above related to the issue here? I guess this is something 
>> probably all callers to apr_bucket_read need to take care,
>> of, correct?
> 
> Since the core output filter can now have to handle morphing buckets
> (not retained by ap_request_core_filter() anymore), I thought it was
> related..
> Agreed that all apr_bucket_read() users should do that.

I have checked socket, pipe and cgi buckets and none of them seem to return 
EOF. In case they hit EOF they replace themselves with
an immortal bucket of length 0. So above seems just an additional safety if a 
(future) morphing bucket behaves differently and
returns EOF, but with the current code that path should not be hit really.

Regards

Rüdiger