Oups, I pulled the discussion off the list, sorry.
On Wed, Sep 18, 2013 at 2:57 PM, Yann Ylavic <[email protected]> wrote: > On Wed, Sep 18, 2013 at 2:27 PM, Yann Ylavic <[email protected]> wrote: > >> On Wed, Sep 18, 2013 at 2:06 PM, Jim Jagielski <[email protected]> wrote: >> >>> >>> On Sep 17, 2013, at 7:07 PM, Yann Ylavic <[email protected]> wrote: >>> > } >>> > - /* test lenp, because it gives another case we can handle >>> */ >>> > - else if (!lenp) { >>> > - /* Something that isn't in HTTP, unless some future >>> > + else if (f->r->proxyreq != PROXYREQ_RESPONSE) { >>> > + /* Something that isn't a HTTP request, unless some >>> future >>> > * edition defines new transfer encodings, is >>> unsupported. >>> > */ >>> >>> >>> ?? >>> >> >> When mod_proxy_http handles a response, r->proxyreq == PROXYREQ_RESPONSE, >> in any other case (or I'm missing something), ap_http_filter is called for >> a request. >> >> The draft states that : >> >> 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. If a Transfer-Encoding header field >> is present in a request and the chunked transfer coding is not >> the final encoding, the message body length cannot be determined >> reliably; the server MUST respond with the 400 (Bad Request) >> status code and then close the connection. >> >> >> So this code checks whether the filter is handling a request or a >> response, in the former case it denies (APR_ENOTIMPL) the transfer-coding, >> whereas in the latter case it falls through until connection closed >> (filter's state BODY_NONE). >> > > I should add that ap_read_request in never called for anything else than a > request, so the check request/response is not necessary there... >
