httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <wr...@rowe-clan.net>
Subject http_filter.c r1524770 open issue?
Date Wed, 13 Nov 2013 07:25:15 GMT
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.




Mime
View raw message