Looking at the (f->r->proxyreq == PROXYREQ_RESPONSE) code path, the comments note;
* http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-23 * Section 3.3.3.3: "If a Transfer-Encoding header field is * present in a response and the chunked transfer coding is not * the final encoding, the message body length is determined by * reading the connection until it is closed by the server." All well and good. However, that statement makes almost no sense if the response is not Connection: close (or http/1.0, absent keep-alive). ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, f->r, APLOGNO(01586) "Unknown Transfer-Encoding: %s;" " using read-until-close"); Here we've unset C-L and T-E. but it makes no sense to wait if the origin server has no immediate plan to close the connection. Jim, Yann, was this case thought through? It seems premature to commit the backport without considering that edge case.
