←back to thread

CRLF is obsolete and should be abolished

(fossil-scm.org)
422 points km | 1 comments | 13 Oct 24 19:16 UTC | HN request time: 0.001s | source
Show context
michaelmior ◴[13 Oct 24 20:03 UTC] No.41831072[source]▶
> 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 established protocol (HTTP, SMTP, CSV, FTP) technically requires CRLF as a line ending, do not comply.

I'm hoping this is satire. Why intentionally introduce potential bugs for the sake of making a point?

replies(13): >>41831206 #>>41831210 #>>41831225 #>>41831256 #>>41831322 #>>41831364 #>>41831391 #>>41831706 #>>41832337 #>>41832719 #>>41832751 #>>41834474 #>>41835444 #
amluto ◴[13 Oct 24 20:36 UTC] No.41831364[source]▶
> 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 LF, where CRLF is specified, is garbage.

replies(2): >>41831386 #>>41831719 #
tptacek ◴[13 Oct 24 20:38 UTC] No.41831386[source]▶
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.
replies(4): >>41831436 #>>41831513 #>>41831973 #>>41835480 #
perching_aix ◴[13 Oct 24 20:56 UTC] No.41831513[source]▶
Laws are also just some ink on paper (and are routinely overruled, circumvented or unenforced in certain jurisdictions), so using this kind of logic in order to encourage standard violations is unsound.

There is a method to this madness, and that's revising the standards.

replies(1): >>41831619 #
tptacek ◴[13 Oct 24 21:09 UTC] No.41831619[source]▶
What's a "standard violation"? The original history of the IETF is a rejection of exactly this mode of thinking about the inviolability of standards, which was the ethos of the OSI.
replies(2): >>41831646 #>>41831874 #
perching_aix ◴[13 Oct 24 21:12 UTC] No.41831646[source]▶
When an implementation is noncomformant to a standard in question.
replies(2): >>41831669 #>>41832571 #
sophacles ◴[13 Oct 24 23:11 UTC] No.41832571[source]▶
I've implemented a lot of protocols. Most implementations I've come across for most protocols not strictly standards conformant, for many reasons.

Big ones being:

* The standards are often not detailed enough, or contain enough loose verbage that there are many ways to understand how to implement some part, yet those ways are not interoperable.

* Many protocols allow vendor specifications in such a way that 2 implementations that are 100% compliant won't interoperate.

* Many protocol implementations are interoperable quite well, converging on behavior that isn't specified in any standard (often to the surprise of people who haven't read the relevant standards)

At least this is my experience for ietf rfc standards.

replies(1): >>41833221 #
1. perching_aix ◴[14 Oct 24 01:10 UTC] No.41833221[source]▶
I'm aware of these factors, wasn't trying to suggest that the practice doesn't differ from the theory. What I was more going for was to highlight that the goal should be to primarily try and have these eventually converge, preferably sooner than later, not trying to strongarm the practice side and wait for the standards body in question to wake up one day and decide to amend the standard. That might give the impression of suddenness, but the core issue remains unsolved that way.

Usually when there's a high disparity between the "de jure" and the "de facto", it's due to a discrepancy in the interests and the leverage, resulting in a breakdown in communication and cooperation. Laying into either then is a bandaid attempt, not a solution. It's how either standard sprawl starts, or how standards bodies lose relevance.