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

191–200 of 273 posts

Re: CRLF is obsolete and should be abolished

#191

Post by AndyKelley »

SQLite wrote: post #178

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 requi…

Copying my comment from lobste.rs in case you didn't see it:

I really appreciate this attitude. As programmers, we love to complain and grumble to each other about how the state of things suck, or that things are over complicated, but then too often the response is the software engineering equivalent of “I paid my student loans, so you should have to, too”. A new person joins the project, and WTFs at something, and the traumatized veterans say, “haha oh boy welcome, yeah everything sucks! You’ll get used to it soon.”

I hate that attitude.

We are at the very, very beginning of software protocols that could potentially last for millennia. From that perspective, you would look back at this situation and think of Richard’s blog post as super obvious, the clear voice of reason, and the reaction of everyone here as myopic.

Even if our software protocols for whatever reason don’t last that long, we need to be working on reducing global system complexity. Beauty and elegance aside, there is such a thing as complexity budget which is limited by the laws of information theory, the computer science equivalent of the laws of physics. People like Richard understand this intuitively, and actively work towards reconstructing our world to regain complexity currency so that it can be spent on more productive things.

I would have backed you 100%.

Re: CRLF is obsolete and should be abolished

#192

Post by romwell »

fijiaarone wrote: post #183
romwell wrote: post #128

Earlier quoted context omitted.

>The latter is what typewriters do for the Return key. Minor correction: mechanical typewriters do not have a Return key, but they have both operations (line feed, as well as carriage return). The carriage return lever is typically rigged to also do line feed at the same time, by a preset amount of lines (which can be set to 0), or you can push the carriage without engaging line feed. Technically, the lever would do…

On manual typewriters there is a lever that turns the roller to accomplish a line feed (or two if set for double space.) This lever is usually located on the left side of the carriage to make it convenient to push it back to the right side in the same motion.

Isn't this what I said?

>the lever would do LF, and pushing on it further would do CR (tensioning the carriage spring).

In any case, carriage return is just as important function of the lever as line feed:

- you can also directly do line feed by turning the roller

- line feed, by itself, doesn't need a large lever

- carriage return, by itself, doesn't need a large lever either - you can simply push the carriage

- however, having a large lever is an ergonomic feature which allows you to:

1) return the carriage without moving your hands too far from the keyboard

2) do CRLF in one motion without it feeling like two things

3) If needs be, do a line feed by itself, since the force required for that is much smaller compared to the one to move the carriage (lever advantage!).

The long lever makes it so that line feed happens before carriage return. If the lever were short, you'd be able to move the carriage until it stops, and only then would the paper move up.

So I wondered why the control codes are doing the operations in the opposite order from the typewriter.

Turns out, the reasons are mechanical[1]:

>The separation of newline into two functions concealed the fact that the print head could not return from the far right to the beginning of the next line in time to print the next character. Any character printed after a CR would often print as a smudge in the middle of the page while the print head was still moving the carriage back to the first position. "The solution was to make the newline two characters: CR to move the carriage to column one, and LF to move the paper up.

Aha! Makes sense.

In a way, this was creating a de-facto protocol by usage, in a similar spirit the the author is suggesting to get rid of it.

As in: the existing standard wasn't really supported, but letting the commands go through nevertheless and allowing things to break incentivized people to collectively stick to the way of doing things that didn't result in misprints.

____ [1] https://en.wikipedia.org/wiki/Newline

Re: CRLF is obsolete and should be abolished

#193

Post by perching_aix »

AndyKelley wrote: post #191
SQLite wrote: post #178

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 requi…

Copying my comment from lobste.rs in case you didn't see it: I really appreciate this attitude. As programmers, we love to complain and grumble to each other about how the state of things suck, or that things are over complicated, but then too often the response is the software engineering equivalent of “I paid my student loans, so you should have to, too”. A new person joins the project, and WTFs at something, and t…

You remind me to the common wisdom regarding user feedback. That when your users complain about something, you should listen - not to their advice per se, but to their gripes. Because while their gripes may be legitimate, their advice is near guaranteed to be rubbish (they're not developers after all).

Specifically, I'm referring to your new guy example here. The new guy usually very correctly identifies that things suck, what he lacks is perspective. This means that both his priorities will be off, as well as his approaches. Trust the gripe, not the advice.

This is also I think what people in this thread are/were generally about here. Not because Richard would be some new unknown kid on the block mind you, but because our grandchildren having to deal with CRLF is approximately as harrowing as the eventual heat death of the universe, and because instead of standards revisions, he was calling for standards violations.

Re: CRLF is obsolete and should be abolished

#194

Post by MobiusHorizons »

tptacek wrote: post #104
hifromwork wrote: post #99

Earlier quoted context omitted.

As the parent mentioned, it's security critical that every HTTP parser in the world - including every middleware, proxy, firewall, WAF - parses the headers in the same way. If you write a HTTP parser for a server application it's imperative you don't introduce random inconsistences with the standard (I can't believe I have to write this). On the other hand, as a client, it's OK to send malformed requests, as long as…

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.

Re: CRLF is obsolete and should be abolished

#195

Post by Izkata »

romwell wrote: post #128
jfengel wrote: post #113

Earlier quoted context omitted.

LF only? Huh. In its original terms for printing terminals, carriage return might be ambiguous. It could means either "just send the print head to column zero" or "print head to 0 and advance the line by one". The latter is what typewriters do for the Return key. But LF always meant Line Feed, moving the paper but not the print head. These are of course wildly out of date concepts. But it still strikes me as odd to s…

>The latter is what typewriters do for the Return key. Minor correction: mechanical typewriters do not have a Return key, but they have both operations (line feed, as well as carriage return). The carriage return lever is typically rigged to also do line feed at the same time, by a preset amount of lines (which can be set to 0), or you can push the carriage without engaging line feed. Technically, the lever would do…

They didn't say "mechanical typewriters", just "typewriters". Electric typewriters did have a Return key that did work the way they described.

Re: CRLF is obsolete and should be abolished

#197

Post by oasisaimlessly »

perching_aix wrote: post #189
bityard wrote: post #161

Earlier quoted context omitted.

Why would you want that? All Unix text processing tools assume that every line in a text file ends in a newline. Otherwise, it's not a text file. There's no such thing as a "trailing newline," there is only a line-terminating newline. I've yet to hear a convincing argument why the last line should be an exception to that extremely long-standing and well understood convention.

> There's no such thing as a "trailing newline," there is only a line-terminating newline. Is "line-terminating newline" a controlled / established term I'm unfamiliar with or am I right to hold deep contempt against you? Because "trailing newline", contrary to what you claim, is 100% established terminology (in programming anyways), so I'd most definitely consider it "existing", and I find it actively puzzling that…

"Trailing newline" isn't anymore of a special phrase than "leading whitespace" (or "leftmost banana").

Re: CRLF is obsolete and should be abolished

#198

Post by anonymousiam »

TacticalCoder wrote: post #134
anonymousiam wrote: post #79

This article seems like it was written to troll people into a flame war. There is no such character as NL, and the article does not at all address that fact that the "ENTER" key on every keyboard sends a CR and not a LF. Things work fine the way they are.

> There is no such character as NL ... More specifically the Unicode control character U+000a is, in the Unicode standard , named both LF and NL (and that comes from ASCII but in ASCII I think 0x0a was only called LF). It literally has both names in Unicode: but LINEFEED is written in uppercase while newline is written in lowercase (not kidding you). You can all see for yourself that U+000a has both names (and eol to…

Try the cat example again with your tty in raw mode instead of cooked mode.

(stty raw)

Note that your job control characters will no longer function, so you will need to kill the cat command from a different terminal, then type: stty sane (or stty cooked) to restore your terminal to "normal" operation.

You will then see the 0d hex carriage return characters in the /tmp/anonymousiam file, and no 0a hex linefeed characters present.

Re: CRLF is obsolete and should be abolished

#199

Post by inopinatus »

SQLite wrote: post #178

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 requi…

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.

Re: CRLF is obsolete and should be abolished

#200

Post by eviks »

perching_aix wrote: post #145
tryauuum wrote: post #143

Earlier quoted context omitted.

I do like concatenating files with cat, and if a file has its final line not ending in newline symbol the result is ugly. I know it's just me but my worldview is that the world would be better if all editors had "insert final newline" behavior

My problem is that what I input (and observe!) doesn't match what's persisted. Worse still, editors lie about it to me until I close the file and reopen it. And just to really turn the knife, various programs will then throw a fit that a character that I did not input and my editor lies about not being present, is present. I hope it's appreciable why I find this frustrating. I expect my editor to do what I say, not s…

Wait, are they're no editors that don't lie to you?
Post reply on HN