Re: CRLF requirement


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
> > 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.


Received on Tuesday, 1 July 2014 14:52:51 UTC