httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann Ylavic <>
Subject Re: http_filter.c r1524770 open issue?
Date Wed, 13 Nov 2013 14:21:51 GMT
On Wed, Nov 13, 2013 at 8:25 AM, William A. Rowe Jr. <>wrote:

> Looking at the (f->r->proxyreq == PROXYREQ_RESPONSE) code path,
> the comments note;
>  *
>  * Section "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 -

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...


View raw message