> Am 21.08.2023 um 12:20 schrieb Yann Ylavic <ylavic....@gmail.com>:
>
> On Wed, Aug 16, 2023 at 1:43 PM Ruediger Pluem <rpl...@apache.org> wrote:
>>
>> On 8/16/23 1:32 PM, Eric Covener wrote:
>>>>> So a few questions:
>>>>>
>>>>> - Is it reasonable as a standalone additional HTTPProtocolOption to
>>>>> decide the behavior?
>>>>> - Thoughts on behavior change in 2.4.x?
>>>>> - 400 as a status code?
>>>>>
>>>>> https://httpwg.org/specs/rfc9112.html#rfc.section.6.1.p.15
>>>>>
>>>>> A server MAY reject a request that contains both Content-Length and
>>>>> Transfer-Encoding or process such a request in accordance with the
>>>>> Transfer-Encoding alone. Regardless, the server MUST close the
>>>>> connection after responding to such a request to avoid the potential
>>>>> attacks.
>>>>
>>>> We currently ignore the content-length header, proceed and close the
>>>> connection
>>>> afterwards as suggested above. Do you suggest that we should reject such
>>>> requests
>>>> based on a configuration setting?
>>>
>>> Yes, reject when both are set.
>>>
>>
>> Sounds fine for me as long as we don't make it the default, at least not in
>> 2.4
>
> Fine by me too, likely those requests come mainly/solely from the
> usual suspects (pentesters, auditors, papers..), so I'd be fine with
> blocking by default with an opt-out too (eg. HttpProtocolOptions
> Allow_CL+TE). I've never seen a "legitimate" request with both set
> personally, if it happens for some app it might be interesting for the
> users to know it and fix their chain, we've done the same for "Strict"
> and "Allow0.9" without too much pain IIRC.
+1 as configurable with default to keep current 2.4.x behaviour.
Cheers,
Stefan
