←back to thread

CRLF is obsolete and should be abolished

(fossil-scm.org)
422 points km | 7 comments | 13 Oct 24 19:16 UTC | HN request time: 0.991s | source | bottom
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 #
1. tptacek ◴[13 Oct 24 21:15 UTC] No.41831669[source]▶
IETF standards are tools to help developers get stuff done on the Internet. They are not the only tool, and they don't carry any moral force.
replies(1): >>41831797 #
2. perching_aix ◴[13 Oct 24 21:31 UTC] No.41831797[source]▶
Apart from colloquially considering standards not-necessarily-normative being, in my opinion, nonsensical (see below), to the best of my knowledge at the very least the STD subseries of IETF standards documents are normative in nature: https://datatracker.ietf.org/doc/std

> They are not the only tool, and they don't carry any moral force.

Indeed there are countless other standards bodies in the world also producing normative definitions for many things, so I'm definitely a bit confused why the focus on IETF specifically.

To be even more exact, I do not know of any standards bodies who would publish what they and the world consider as standards, that would be entirely, or at least primarily, informational rather than normative in nature. Like, do I know the word "standard" incorrectly? What even is a point of a standard, if it doesn't aim to control?

replies(1): >>41832287 #
3. tptacek ◴[13 Oct 24 22:30 UTC] No.41832287[source]▶
Ok, but just to be clear: the standards-track HTTP RFC says you can use a single LF. I don't think this issue is as clear as people seem to want it to be.
replies(4): >>41832388 #>>41832537 #>>41832566 #>>41832954 #
4. perching_aix ◴[13 Oct 24 22:43 UTC] No.41832388{3}[source]▶
Ah, this is a subthread about HTTP specifically - didn't notice. Explains why you focused on the IETF too. Nevertheless, my points I believe still all stand.

As for HTTP or any other protocols' definitions go, I'd rather not join in on that back and forth. I'd imagine it's well defined what's expected. Skim reading RFC-2616 now certainly suggests so.

5. vitus ◴[13 Oct 24 23:05 UTC] No.41832537{3}[source]▶
Sure. HTTP/1.1 isn't the only network protocol, though, IETF standardization or otherwise.

For SMTP (which this subthread started with):

   In addition, the appearance of "bare" "CR" or "LF" characters in text
   (i.e., either without the other) has a long history of causing
   problems in mail implementations and applications that use the mail
   system as a tool.  SMTP client implementations MUST NOT transmit
   these characters except when they are intended as line terminators
   and then MUST, as indicated above, transmit them only as a <CRLF>
   sequence.
https://datatracker.ietf.org/doc/html/rfc5321#section-2.3.8
6. halter73 ◴[13 Oct 24 23:10 UTC] No.41832566{3}[source]▶
Can you provide a citation for this? I’ve read older RFCs that "recommend" recipients allow single LFs to terminate headers for robustness. I’ve also read newer RFCs that weaken that recommendation and merely say the recipient "MAY" allow single LFs. I’ve never noticed an HTTP RFC say you can send headers without the full CRLF sequence, but maybe I missed something.

https://datatracker.ietf.org/doc/html/rfc2616#section-19.3 https://datatracker.ietf.org/doc/html/rfc9112#section-2.2

7. convolvatron ◴[14 Oct 24 00:20 UTC] No.41832954{3}[source]▶
none of this is as clear as anyone wants it to be. if standards _could_ be completely formally described, it would be an entirely different world. I did quite a bit of work implementing draft standards in the IETF, and and the end of the day the standard is the best we can make it, but for non-trivial things good luck actually implementing it without something to test against or a reference implementation.

thats the context in which Postel's law make absolute sense. not that you should forgo any sanity checking, or attempt to interpret garbage or make up frame boundaries. but when there is a potential ambiguity, and you can safely tolerate it, then its really helpful for you to do so.