Re: [PATCH] Enforce that CR precede LF in chunk lines

2024-02-14 Thread Ben Kallus
> Overall, I don't think there is a big difference here. All I can say is that the hardest part of pulling off that type of attack is guessing the length correctly. If you want to make that job marginally easier, that's fine by me :) > It won't, because "-C" is a non-portable flag provided by a D

Re: [PATCH] Enforce that CR precede LF in chunk lines

2024-01-25 Thread Maxim Dounin
Hello! On Thu, Jan 25, 2024 at 08:32:17PM +, Ben Kallus wrote: > > Still, there is a robustness principle which allows applications > > to parse requests with various deviations from the grammar. > > Whether this is principle is good is a matter of opinion. I tend to > lean toward thinking t

Re: [PATCH] Enforce that CR precede LF in chunk lines

2024-01-25 Thread Ben Kallus
> Still, there is a robustness principle which allows applications > to parse requests with various deviations from the grammar. Whether this is principle is good is a matter of opinion. I tend to lean toward thinking that it is not (as you can probably tell) but reasonable minds will differ on th

Re: [PATCH] Enforce that CR precede LF in chunk lines

2024-01-25 Thread Maxim Dounin
Hello! On Thu, Jan 25, 2024 at 03:21:16AM +, Ben Kallus wrote: > The HTTP/1.1 standards allow the recognition of bare LF as a line > terminator in some contexts. > > From RFC 9112 Section 2.2: > > Although the line terminator for the start-line and fields is the sequence > > CRLF, a recipie

[PATCH] Enforce that CR precede LF in chunk lines

2024-01-24 Thread Ben Kallus
The HTTP/1.1 standards allow the recognition of bare LF as a line terminator in some contexts. From RFC 9112 Section 2.2: > Although the line terminator for the start-line and fields is the sequence > CRLF, a recipient MAY recognize a single LF as a line terminator and ignore > any preceding CR.