On Wed, Sep 18, 2013 at 4:39 PM, Yann Ylavic <[email protected]> wrote:
> 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. > > But it can't hurt to strip the Content-Length from the headers checked by the filter when applyable, should it be used elsewhere...
