On Mon, Mar 12, 2018 at 12:53 PM, Yann Ylavic <ylavic....@gmail.com> wrote:
>
> Can you still reproduce with this patch:
>
> Index: modules/http/http_request.c
> ===================================================================
> --- modules/http/http_request.c (revision 1826315)
> +++ modules/http/http_request.c (working copy)
> @@ -470,7 +470,7 @@ AP_DECLARE(void) ap_process_request(request_rec *r
>
> ap_process_async_request(r);
>
> - if (!c->data_in_input_filters) {
> + if (!c->data_in_input_filters && !c->aborted) {
> bb = apr_brigade_create(c->pool, c->bucket_alloc);
> b = apr_bucket_flush_create(c->bucket_alloc);
> APR_BRIGADE_INSERT_HEAD(bb, b);
> ?
Hmm, no, nevermind, ap_pass_brigade() won't return APR_TIMEOUT if
c->aborted already.
The fix could be something like this:
Index: modules/http/http_request.c
===================================================================
--- modules/http/http_request.c (revision 1826315)
+++ modules/http/http_request.c (working copy)
@@ -484,9 +484,8 @@ AP_DECLARE(void) ap_process_request(request_rec *r
* It is still safe to use r / r->pool here as the eor bucket
* could not have been destroyed in the event of a timeout.
*/
- ap_log_rerror(APLOG_MARK, APLOG_INFO, rv, r, APLOGNO(01581)
- "Timeout while writing data for URI %s to the"
- " client", r->unparsed_uri);
+ ap_log_cerror(APLOG_MARK, APLOG_INFO, rv, c, APLOGNO(01581)
+ "flushing data to the client");
}
}
if (ap_extended_status) {
_
Would you test if it works for you?
