On Nov 13, 2013 8:22 AM, "Yann Ylavic" <ylavic....@gmail.com> wrote: > > On Wed, Nov 13, 2013 at 8:25 AM, William A. Rowe Jr. <wr...@rowe-clan.net> 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...
Except, in -this- case, we unset the C-L returned by the origin server.
