Comment 5 for bug 1495988

Revision history for this message
In , Rainer Jung (rainer-jung-kippdata) wrote :

First steps of analysis for trunk. The problem happens with all MPMs, especially also with prefork and event.

The hang until timeout happens in ap_discard_request_body called from mod_proxy_http.c in line 1640:

1629 /* PR 41646: get HEAD right with ProxyErrorOverride */
1630 if (ap_is_HTTP_ERROR(r->status) && dconf->error_override) {
1631 /* clear r->status for override error, otherwise ErrorDocument
1632 * thinks that this is a recursive error, and doesn't find the
1633 * custom error page
1634 */
1635 r->status = HTTP_OK;
1636 /* Discard body, if one is expected */
1637 if (!r->header_only && /* not HEAD request */
1638 (proxy_status != HTTP_NO_CONTENT) && /* not 204 */
1639 (proxy_status != HTTP_NOT_MODIFIED)) { /* not 304 */
1640 ap_discard_request_body(backend->r);
1641 }
1642 proxy_run_detach_backend(r, backend);
1643 return proxy_status;
1644 }

In ap_discard_request_body - which is used here to discard the reponse body from the origin server - I can see two brigades being read. The first has one bucket which contains the original error page coming form the origin server (here 206 bytes), the second brigade only has a EOS bucket. Reading the second brigade is where it blocks until proxy timeout.

For 2.2 the situation is different: the first brigade read has two buckets, the first again containing the origin server response body, the second one the EOS. The brigade with both buckets could be read immediately without waiting for timeout.

Any ideas what's going one? Hints in which direction to proceed?

Regards,

Rainer