- From: Zhong Yu <zhong.j.yu@gmail.com>
- Date: Tue, 1 Jul 2014 10:00:17 -0500
- To: Willy Tarreau <w@1wt.eu>
- Cc: Anne van Kesteren <annevk@annevk.nl>, HTTP Working Group <ietf-http-wg@w3.org>
On Tue, Jul 1, 2014 at 9:52 AM, Willy Tarreau <w@1wt.eu> wrote: > Hi, > > On Tue, Jul 01, 2014 at 09:36:01AM -0500, Zhong Yu wrote: >> > Please take a look at 3.5. "Message Parsing Robustness" : >> > >> > "Although the line terminator for the start-line and header fields is >> > the sequence CRLF, a recipient MAY recognize a single LF as a line >> > terminator and ignore any preceding CR." >> >> The text in RFC2616 was >> http://tools.ietf.org/html/rfc2616#section-19.3 >> > we recommend that applications, when parsing such headers, recognize a single LF as a line terminator and ignore **the** leading CR. >> >> The change from [CR] LF to *CR LF is dangerous, IMO. Previously, >> CRCRLF must be rejected, now, in rfc7230, it MAY be accepted as one >> line break. > > I don't read it this way, here above I read "any CR" as "the CR if it > exists" just like in "anyone", with "CR" still being used in singular I see, thanks for the explanation. > and not plural form. I guess we would have come up with "any and all" > or "any series of CR" or something like this if there was an intent > to indicate more than one. But at least now that you raise this, I > admit it can be confusing. > >> (And then Anne wanted it to be accepted as two line >> breaks). >> >> It's always troubling if different agents MAY interpret the same >> message differently. We cannot add any more leniency to parsing. If >> any new software generates anything but CRLF in 2014, it's just sloppy >> programming. > > In fact it's still common to see that in shell scripts. I've seen > some monitoring scripts use echo $REQUEST | netcat $dest. Yes, we have to accept single LFs. But that's it... We cannot accept LFCR as two line breaks; the only sane thing to do is outright rejection. Zhong Yu bayou.io
Received on Tuesday, 1 July 2014 15:00:48 UTC