Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CRLF is obsolete and should be abolished

fossil-scm.org

Post reply on HN
Print view View original

251–260 of 273 posts

Re: CRLF is obsolete and should be abolished

#251

Post by ericyd »

chowells wrote: post #142
ericyd wrote: post #111

I'm not trying to be obtuse but I am actually confused how a modern machine correctly interprets CRLF based on the description in this post. If a modern machine interprets LF as a newline, and the cursor is moved to the left of the current row before the newline is issued, wouldn't that add a newline _before_ the current line, i.e. a newline before the left most character of the current line? Obviously this isn't how…

Line feed is "move the cursor down one line". It's irrelevant what is currently on the line. These are printer/terminal control instructions, not text editing instructions.

Ok, I conflated terminal instruction with text editing instruction. I thought the post made them sound like they behave the same but it sounds like I misunderstood, thank you.

Re: CRLF is obsolete and should be abolished

#252

Post by nuancebydefault »

It is a bit like saying, let's forget about AM radio since FM radio is much better. Oh wait forget FM since DAB exists. Oh wait forget about broadcast protocols since everything is point to point or multicast now.

The reality is that existing protocols CANNOT be changed. Only new versions are released and the old ones (which might rely on CRLF) will never die.

Re: CRLF is obsolete and should be abolished

#253

Post by samatman »

cowsandmilk wrote: post #166
numpad0 wrote: post #115

Earlier quoted context omitted.

isn't CR without LF how CLI progress bars work?

He says there are good usages of CR, he only argues for getting rid of LF.

Replacing LF behavior with NL behavior in terminal raw mode is a non-starter, decades worth of software will break. The enter/return key only sends CR anyway, software has to decide what to do with that: sometimes the answer is emit CRLF, often there are program-defined margins so the CR gets translated to direct cursor movements.

I'm pretty sure drh is making a case only against the use of CRLF in protocols, not trying to redesign terminal in the process. If you're emulating a machine which understands LF then you're kinda stuck with line feed semantics, for better and for worse.

Re: CRLF is obsolete and should be abolished

#254

Post by akira2501 »

eviks wrote: post #231
akira2501 wrote: post #215

Earlier quoted context omitted.

The complexity of CRLF? The balance here, of course, being backwards compatability. I'd sooner kill EBCDIC, bad ASCII and Code Pages than worry about CRLF if we didn't have to care about ancient systems. Programming languages still retain C's operator precedence hierarchy even though it was itself meant to be a backwards compatible compromise and leads to errors around logical operator expressions. Anyways, this arti…

> The complexity of CRLF? You didn't limit your general admiration of standards to CRLF, so no, not only that. > about actively breaking systems like some kind of protocol terrorist in order to achieve an outcome at any cost, That's simply false, he isn't > Almost all implementations of these protocols will accept a bare NL as an end-of-line mark, even if it is technically incorrect.

> You didn't limit your general admiration of standards to CRLF, so no, not only that.

So your position, then, is that all standards include "needless complexity?" What argument are you actually trying to make here?

> That's simply false, he isn't

Yea.. that's why the word "like" is present, it implies a near association, not a direct accusation.

> Almost all implementations of these protocols will accept a bare NL as an end-of-line mark, even if it is technically incorrect.

So, right back to my original point, then, standards prevent people from having to debug dumb issues that could have been avoided. This advice is basically "go ahead, create dumb issues, see if I care."

I may have flippantly labeled that as "protocol terrorism" but I don't think it's pure hyperbole either.

Re: CRLF is obsolete and should be abolished

#255

Post by eviks »

akira2501 wrote: post #254
eviks wrote: post #231

Earlier quoted context omitted.

> The complexity of CRLF? You didn't limit your general admiration of standards to CRLF, so no, not only that. > about actively breaking systems like some kind of protocol terrorist in order to achieve an outcome at any cost, That's simply false, he isn't > Almost all implementations of these protocols will accept a bare NL as an end-of-line mark, even if it is technically incorrect.

> You didn't limit your general admiration of standards to CRLF, so no, not only that. So your position, then, is that all standards include "needless complexity?" What argument are you actually trying to make here? > That's simply false, he isn't Yea.. that's why the word "like" is present, it implies a near association, not a direct accusation. > Almost all implementations of these protocols will accept a bare NL a…

> What argument are you actually trying to make here?

That you're mistaken in your one-sided generalization of the benefits of standards.

> So your position, then, is that all standards include "needless complexity?"

No, that's just another extreme you've made up.

> Yea.. that's why the word "like" is present, it implies a near association, not a direct accusation.

Your mistake is before "like", you can't be "about actively breaking systems" when you explicitly say that no systems will be broken

> "see if I care."

That this is false is also easy to see - the author reverted a change after he realized it breaks something ancient, so clearly he does care.

> standards prevent people from having to debug dumb issues that could have been avoided.

Not to circle the conversaion back to my original response to your point: why do you think "Almost all implementations" break the standard and "accept a bare NL"? Could it be that such unintuitive limitations don't prevent anything, and people still have to debug "dumb issues" because common expectations are more powerful?

Re: CRLF is obsolete and should be abolished

#256

Post by psd1 »

djha-skin wrote: post #238
Kwpolska wrote: post #120

Earlier quoted context omitted.

Nope. Git should not mess with line endings, the remote repository not matching the code in your local clone can bite you when you least expect it. On Windows, one should disable the autocrlf misfeature (git config --global core.autocrlf false) and configure their text editor to default to LF.

Sure, don't use autocrlf. But some _windows_ tools need crlf, like for powershell or batch build scripts. Defaulting to lf in the editor will not save you. Don't use `auto`, full marks, but the gitattributes file is indispensable as a safety net when explicit entries are used in it. I mean, the whole point of the file is not everyone who is working on the project has their editors set to lf. Furthermore, not every to…

Powershell doesn't care about line endings, and hasn't since 2006 when v2 was launched. I have never seen v1 installed but

Re: CRLF is obsolete and should be abolished

#257

Post by eqvinox »

perching_aix wrote: post #230
eqvinox wrote: post #216

Earlier quoted context omitted.

A trailing newline to me is "\n\n" at the end of a file, i.e. a superfluous empty line. That doesn't seem to be what the root comment is referring to, though?

I'm referring to files ending with a \n, and I do not see why this wouldn't be a trailing newline. It's a newline... at the end.

In my head, a trailing newline is a newline, at the end, on its own, a blank line after the last line in a file… that's a file ending in \n\n (or more).

It hadn't even occurred to me until today that anything else could be meant :o

Re: CRLF is obsolete and should be abolished

#258

Post by Smar »

MobiusHorizons wrote: post #194
tptacek wrote: post #104

Earlier quoted context omitted.

That appears to be an argument in favor of accepting bare-0ah, since as a positive statement that is the situation on the Internet today.

If you expect to be behind a reverse proxy that manages internal headers for you (removes them on incoming requests, and adds them based on internal criteria) then accepting bare 0x0a newlines could be a security vulnerability, as a malicious request could sneak an internal header that would not be stripped by the reverse proxy.

Only in the case the reverse proxy does not handle bare 0a newlines?

Re: CRLF is obsolete and should be abolished

#260

Post by Aeolun »

immibis wrote: post #237
Aeolun wrote: post #153

Earlier quoted context omitted.

Well, you can achieve the desired behavior in all situations by ignoring CR and treating any seen LF as NL. I just don’t see why you’d not want to do that as the implementer. If there’s some way to exploit that behavior I can’t see it.

The exploit is that your request went through a proxy which followed the standard (but failed to reject the bare NL) and the client sent a header after a bare NL which you think came from the proxy but actually came from the client - such as the client's IP address in a fake X-Forwarded-For, which the proxy would have removed if it had parsed it as a header. This attack is even worse when applied to SMTP because the…

Thanks, that was actually a very clear description of the problem!

The problem here is not to use one or the other, but to use a mix of both.

Post reply on HN