- From: Willy Tarreau <w@1wt.eu>
- Date: Tue, 1 Jul 2014 16:52:23 +0200
- To: Zhong Yu <zhong.j.yu@gmail.com>
- Cc: Anne van Kesteren <annevk@annevk.nl>, HTTP Working Group <ietf-http-wg@w3.org>
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 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. Willy
Received on Tuesday, 1 July 2014 14:52:51 UTC