httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann Ylavic <ylavic....@gmail.com>
Subject Re: svn commit: r1524161 - in /httpd/httpd/trunk: CHANGES docs/log-message-tags/next-number modules/http/http_filters.c server/protocol.c
Date Wed, 18 Sep 2013 14:41:33 GMT
On Wed, Sep 18, 2013 at 4:39 PM, Yann Ylavic <ylavic.dev@gmail.com> wrote:

> On Wed, Sep 18, 2013 at 3:36 PM, Yann Ylavic <ylavic.dev@gmail.com> 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...

Mime
View raw message