On Wed, Nov 13, 2013 at 8:25 AM, William A. Rowe Jr. <[email protected]>wrote:
> 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. > When the origin gives no C-L and no T-E, ap_http_filter() already assumes a read-until-close, even if "Connection: close" is not specified, as per "rfc2616 - Section 4.4 - Message Length - §5", or "draft-ietf-httpbis-p1-messaging-24 - Section 3.3.3 - Message Body Length - §7". IMHO, this is the same case here, if the origin gives a T-E which is not ending with "chunked" (something likely shared with the client), it is supposed to close the connection when done (as per rfc/ietf-httpbis), and the filter has to trust that... Regards, Yann.
