Re: [Technical Errata Reported] RFC9112 (7633)

On Tue, Sep 05, 2023 at 06:47:25PM -0700, Roy T. Fielding wrote:
> The difference was intentional. A chunked parser is not a start line or field
> parser (it is a message body parser) and it is supposed to be less forgiving
> because it does not have to retain backwards compatibility with 1.0 parsers.
> Hence, bare LF around the chunk sizes would be invalid and should result in
> the connection being marked as invalid.
> If an implementation chooses to ignore what is currently defined by the spec
> and somehow reads less of the content than it would have with CRLF, then it
> has more problems than this would fix. AFAICT, it's not possible to turn that
> into an attack based only on whether the recipient accepts or rejects a
> chunked message.
> In any case, suggestions to further hardening of the chunked parser would
> have to be defined in that section, not here. 

FWIW while I've always been tolerant for bare LFs in headers and trailers
(at least to support telnet/netcat), I've never accepted them in chunks
nor even when chunk extensions were needed, and never got a single report
of breakage due to not accepting them, thus I really think that all
implementations do correctly use CRLF and that it's not worth risking to
weaken the protocol by starting to support variations there.


Received on Wednesday, 6 September 2023 03:19:15 UTC