- From: Willy Tarreau <w@1wt.eu>
- Date: Wed, 6 Sep 2023 05:18:16 +0200
- To: "Roy T. Fielding" <fielding@gbiv.com>
- Cc: RFC Errata System <rfc-editor@rfc-editor.org>, mnot@mnot.net, julian.reschke@greenbytes.de, superuser@gmail.com, francesca.palombini@ericsson.com, tpauly@apple.com, squid3@treenet.co.nz, ietf-http-wg@w3.org
On Tue, Sep 05, 2023 at 06:47:25PM -0700, Roy T. Fielding wrote: > REJECT > > 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. Willy
Received on Wednesday, 6 September 2023 03:19:15 UTC