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 13:47:35 GMT
Oups, I pulled the discussion off the list, sorry.


On Wed, Sep 18, 2013 at 2:57 PM, Yann Ylavic <ylavic.dev@gmail.com> wrote:

> On Wed, Sep 18, 2013 at 2:27 PM, Yann Ylavic <ylavic.dev@gmail.com> wrote:
>
>> On Wed, Sep 18, 2013 at 2:06 PM, Jim Jagielski <jim@jagunet.com> wrote:
>>
>>>
>>> On Sep 17, 2013, at 7:07 PM, Yann Ylavic <ylavic.dev@gmail.com> 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...
>

Mime
View raw message