On Wed, Sep 18, 2013 at 3:36 PM, Yann Ylavic <[email protected]> wrote:
> <...> but I'm not sure if the Content-Length of the fake request_rec used
> here by mod_proxy is forwarded to the client, I'll check that!).
>
It is not, mod_proxy_http does the right thing :
/* can't have both Content-Length and Transfer-Encoding */
if (apr_table_get(r->headers_out, "Transfer-Encoding")
&& apr_table_get(r->headers_out, "Content-Length")) {
/*
* 2616 section 4.4, point 3: "if both Transfer-Encoding
* and Content-Length are received, the latter MUST be
* ignored";
*
* To help mitigate HTTP Splitting, unset Content-Length
* and shut down the backend server connection
* XXX: We aught to treat such a response as uncachable
*/
apr_table_unset(r->headers_out, "Content-Length");
ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r, APLOGNO(01107)
"server %s:%d returned Transfer-Encoding"
" and Content-Length",
backend->hostname, backend->port);
backend->close = 1;
}
Hence the Content-Length is removed from the headers sent to the client
(r->headers_out) but left in the headers received from the backend
(backend->r->headers_in), so the ap_http_filter will do its job (check the
transfer-encoding and reject whatever is not acceptable, incliding both
TE+CL if "ougth to"), while the client will never receive both
Content-Length and Transfer-Encoding.
