Counterpoint: Unix deciding on a non-standard line ending was always a mistake. It has produced decades of random incompatibility for no particular benefit. CRLF isn’t a convention: it’s two different pieces of the base terminal API. You have no idea how many programs rely on CR and LF working correctly.
CRLF is obsolete and should be abolished
41–50 of 273 posts
Re: CRLF is obsolete and should be abolished
#42> various protocols (HTTP, SMTP, CSV) still "require" CRLF at the end of each line What would be the benefit to updating legacy protocols to just use NL? You save a handful of bits at the expense of a lot of potential bugs. HTTP/1(.1) is mostly replaced by HTTP/2 and later by now anyway. Sure, it makes sense not to require CRLF with any new protocols, but it doesn't seem worth updating legacy things. > Even if an est…
>What would be the benefit... It is interesting that you ignore the benefits the OP describes and instead present a vague and fearful characterization of the costs. Your reaction lies at the heart of cargo-culting, the maintenance of previous decisions out of sheer dread. One can do a cost-benefit analysis and decide what to do, or you can let your emotions decide. I suggest that the world is better off with the form…
The cost is, if people start transitioning to a world where senders only transmit LF in opposition to current standards for protocols like HTTP/1.1 or SMTP (especially aggressively, e.g., by creating popular HTTP libraries without a CRLF option), then it will create the mental and procedural overhead of tracking which receivers accept LF alone vs. which still require CRLF. Switching established protocols is never free, even when there are definite benefits: see the Python 2-to-3 fiasco, caused by newer programs being incompatible with most older libraries.
Re: CRLF is obsolete and should be abolished
#43Well, at least the title is honest. Straight up asking people to break standards out of sheer conviction is a new one for me personally, but it's definitely one of the attitudes of all time, so maybe it's just me being green. Can we ask for the typical *nix text editors to disobey the POSIX standard of a text file next, so that I don't need to use hex editing to get trailing newlines off the end of files?
People don't seem to mind when Chrome does it [0]. The response "standards aren't a death pact" stands out in particular. [0] https://news.ycombinator.com/item?id=13860682
Might be just my personal impression, but I'm pretty sure Chrome is extremely notorious for abusing its market leader position, including in this way. So gonna have to disagree there, from my view people do mind Chrome and its implementation particularities quite a lot.
Re: CRLF is obsolete and should be abolished
#44Earlier quoted context omitted.
> I'm hoping this is satire. Why intentionally introduce potential bugs for the sake of making a point? It’s worse than satire. Postel’s Law is definitively wrong, at least in the context of network protocols, and delimiters, especially, MUST be precise. See, for example: https://www.postfix.org/smtp-smuggling.html Send exactly what the spec requires, and parse exactly as the spec requires. Do not accept garbage. And…
If two systems agree, independent of any specification someone somewhere else wrote, to accept a bare NL where a CRLF is specified, that is not "garbage". Standards documents are not laws; the horse drags the cart.
> Standards documents are not laws; the horse drags the cart.
They can be: c.f. legally-enforced safety-regulations.
Re: CRLF is obsolete and should be abolished
#45> various protocols (HTTP, SMTP, CSV) still "require" CRLF at the end of each line What would be the benefit to updating legacy protocols to just use NL? You save a handful of bits at the expense of a lot of potential bugs. HTTP/1(.1) is mostly replaced by HTTP/2 and later by now anyway. Sure, it makes sense not to require CRLF with any new protocols, but it doesn't seem worth updating legacy things. > Even if an est…
Exactly. Please DO NOT mess with protocols, especially legacy critical protocols based on in-band signaling. HTTP/1.1 was regrettably but irreversibly designed with security-critical parser alignment requirements. If two implementations disagree on whether `A:B\nC:D` contains a value for C, you can build a request smuggling gadget, leading to significant attacks. We live in a post-Postel world, only ever generate and…
This would be more persuasive if HTTP servers didn't already widely accept bare 0ah line termination. What's the first major public web site you can find that doesn't?
Re: CRLF is obsolete and should be abolished
#46Earlier quoted context omitted.
If two systems agree, independent of any specification someone somewhere else wrote, to accept a bare NL where a CRLF is specified, that is not "garbage". Standards documents are not laws; the horse drags the cart.
> Standards documents are not laws; the horse drags the cart. They can be: c.f. legally-enforced safety-regulations.
These aren't.
Re: CRLF is obsolete and should be abolished
#47> various protocols (HTTP, SMTP, CSV) still "require" CRLF at the end of each line What would be the benefit to updating legacy protocols to just use NL? You save a handful of bits at the expense of a lot of potential bugs. HTTP/1(.1) is mostly replaced by HTTP/2 and later by now anyway. Sure, it makes sense not to require CRLF with any new protocols, but it doesn't seem worth updating legacy things. > Even if an est…
Thinking about it. Using CR alone in protocols actually make infinitely more sense. As that would allow use of LF in records. Which would make many use cases much simpler. Just think about text protocols like HTTP, how much easier something like cookies would be to parse if you had CR as terminating character. And then each record separated by LF.
[deleted]
Re: CRLF is obsolete and should be abolished
#48Can OP please tell me how to abolsih CR while in Raw Mode? Did he forget about it, or am I just unimaginative?
Re: CRLF is obsolete and should be abolished
#49I could not possibly disagree with this more strongly or violently.
In short - shutup and deal with it. Is it an extremely mild and barely inconvenient nuisance to deal with different or mixed line endings? Yes. Is this actually a hard or difficult problem? No.
Stop trying to force everyone to break their backs so your life is inconsequentially easier. Deal with it and move on.
Re: CRLF is obsolete and should be abolished
#50> various protocols (HTTP, SMTP, CSV) still "require" CRLF at the end of each line What would be the benefit to updating legacy protocols to just use NL? You save a handful of bits at the expense of a lot of potential bugs. HTTP/1(.1) is mostly replaced by HTTP/2 and later by now anyway. Sure, it makes sense not to require CRLF with any new protocols, but it doesn't seem worth updating legacy things. > Even if an est…
Exactly. Please DO NOT mess with protocols, especially legacy critical protocols based on in-band signaling. HTTP/1.1 was regrettably but irreversibly designed with security-critical parser alignment requirements. If two implementations disagree on whether `A:B\nC:D` contains a value for C, you can build a request smuggling gadget, leading to significant attacks. We live in a post-Postel world, only ever generate and…
I wouldn't be too worried and making personal judgements, he says the same thing you are (though I assume you disagree)