←back to thread

422 points km | 1 comments | | HN request time: 0s | source
Show context
SQLite ◴[] No.41833507[source]
Author here:

My title was imprecise and unclear. I didn't mean that you should raise errors if CRLF is used as a line terminator in (for example) HTTP, only that a bare NL should be allowed as an acceptable line terminator. RFC2616 recommends as much (section 19.3 paragraph 3) but doesn't require it. The text of my proposal does say that CRLF should continue to be accepted, for backwards compatibility, just not required and not generated by default. I failed to make that point clear.

My initial experiments suggested that this idea would work fine and that few people would even notice. Initially, it appeared that when systems only generate NL instead of CRLF, everything would just keep working seamlessly and without problems. But, alas, there are more systems in circulation that are unable to deal with bare NLs than I knew. And I didn't sell my idea very well. So there was breakage and push-back.

I have revised the document accordingly and reverted the various systems that I control to generate CRLFs again. The revolution is over. Our grandchildren will have to continue dealing with CRLFs, it seems. Bummer.

Thanks to everyone who participated in my experiment. I'm sorry it didn't work out.

replies(2): >>41833769 #>>41834412 #
inopinatus ◴[] No.41834412[source]
The problem with trying to legislate a specific case of Postel's Law is that everyone who might get on board because of it, is already on board because of it, and vice versa.
replies(1): >>41834524 #
1. Ygg2 ◴[] No.41834524[source]
It also goes a bit more than that, for optimal UTF8 search you want the ASCII separators. It's always easier to search for a single byte than two or more bytes of special pattern.

That said, I do agree we should abolish CRLF. And replace it with LF.