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

241–250 of 273 posts

Re: CRLF is obsolete and should be abolished

#241

Post by vrighter »

Spooky23 wrote: post #124
FiloSottile wrote: post #40

Earlier quoted context omitted.

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…

What a weird reaction. Microsoft’s use of CRLF is an archaic pain in the ass. Taking a position that it should be deprecated isn’t radical or irresponsible — Microsoft makes gratuitous changes to things all of the time, why not this one? Hipp is probably one of the better engineering leaders out there. His point of view carries weight because of who he is, but should be evaluated on its merits. If Microsoft got rid o…

He's not arguing for deprecating it. He's arguing for just not complying and hoping for the best. He explicitly says so right in the article.

That is never the right approach. You intentionally introduce a problem you expect others to fix. All because he doesn't like 0x0d. The protocol is what it is. If you want to make more sane decisions when designing a new protocol (or an explicitly newer version of some existing one) then by all means, go for it. But intentionally breaking existing ones is not the way to go.

Re: CRLF is obsolete and should be abolished

#242

Post by shadowgovt »

tptacek wrote: post #184
LegionMammal978 wrote: post #174

Earlier quoted context omitted.

Make sure you're contacting hhs.gov and not www.hhs.gov, the www. subdomain reacts differently. $ printf 'GET / HTTP/1.1\r\nHost: hhs.gov\r\n\r\n' | nc hhs.gov 80 HTTP/1.1 302 Found Date: Mon, 14 Oct 2024 01:38:29 GMT Server: Apache Location: http://www.hhs.gov/web/508// Content-Length: 212 Content-Type: text/html; charset=iso-8859-1 302 Found Found The document has moved here . ^C $ printf 'GET / HTTP/1.1\nHost: hhs…

Ahh, that was it, thanks.

And this whole exercise is an example of why this is a non-starter proposal (at least the "change existing implementations" part).

How much do we expect the domain owners to invest in changing an implementation that already works? Hint: it's a number smaller than epsilon.

Google might, but their volume is so high they care about the cost of individual bytes on the wire.

Re: CRLF is obsolete and should be abolished

#243

Post by sebazzz »

eqvinox wrote: post #225
moomin wrote: post #41

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.

Counter-counterpoint: using 2 bytes to signal one relevant operation creates ambiguity out of thin air. If all you care about is "where does the line end?", having CRLF as a line ending creates edge cases for "there is only CR" and "there is only LF". Are those line endings or not? How do you deal with them? And what's LFCR? Personally speaking, I've always written my parsers to be permissive and accept either CR¹, L…

Didn’t some version of an Apple operating system have CR as a line ending?

Re: CRLF is obsolete and should be abolished

#244

Post by tptacek »

shadowgovt wrote: post #242
tptacek wrote: post #184

Earlier quoted context omitted.

Ahh, that was it, thanks.

And this whole exercise is an example of why this is a non-starter proposal (at least the "change existing implementations" part). How much do we expect the domain owners to invest in changing an implementation that already works? Hint: it's a number smaller than epsilon. Google might, but their volume is so high they care about the cost of individual bytes on the wire.

This exercise was about demonstrating that our security can't rely on making sure there's a carriage return in HTTP line termination, because there is no such norm. See the root of the thread, where I asked the question.

Re: CRLF is obsolete and should be abolished

#245

Post by anonymousiam »

eviks wrote: post #202
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, There is, copying from a helpful comment above: > The Unicode standard does call it NL along with LF. 000A  = LINE FEED (LF) = new line (NL) = end of line (EOL) Source: https://www.unicode.org/charts/PDF/U0000.pdf And things don't work fine, there are many issues with this historical baggage

I agree that there are issues. Making radical changes to legacy behavior will cause more.

Re: CRLF is obsolete and should be abolished

#246

Post by shadowgovt »

tptacek wrote: post #244
shadowgovt wrote: post #242

Earlier quoted context omitted.

And this whole exercise is an example of why this is a non-starter proposal (at least the "change existing implementations" part). How much do we expect the domain owners to invest in changing an implementation that already works? Hint: it's a number smaller than epsilon. Google might, but their volume is so high they care about the cost of individual bytes on the wire.

This exercise was about demonstrating that our security can't rely on making sure there's a carriage return in HTTP line termination, because there is no such norm. See the root of the thread, where I asked the question.

Oh, I agree it's about that too, but my point is you've already volunteered more time and resources investigating the situation than most companies would be willing to spend.

Re: CRLF is obsolete and should be abolished

#247

Post by deanishe »

FiloSottile wrote: post #40
michaelmior wrote: post #3

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

> but this is giving me pause about using other software by the same author

Go read the article again. I think you'll be pleasantly surprised.

Re: CRLF is obsolete and should be abolished

#248

Post by pathartl »

zac23or wrote: post #118

> Even if an established protocol (HTTP, SMTP, CSV, FTP) technically requires CRLF as a line ending, do not comply. Send only NL. Insane. First i think it was a April 1st joke, but is not. Let's break everything because YES.

Let's all move to little-endian while we're at it. Don't accept anything else!

Re: CRLF is obsolete and should be abolished

#249

Post by steeeeeve »

Once in a long while, people start looking into things and wanting them to make sense.

Like hey - why don't we start using the field separator and record separator characters when exporting/importing data.

But then you end up realizing that even when you are right, the energy it would take to push a change like that is astounding.

Those who successfully create an RFC and find a way push it through all the way to it becoming a standard are admirable people.

Re: CRLF is obsolete and should be abolished

#250

Post by ericyd »

BlueTemplar wrote: post #148
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…

If you are thinking of it being more like pressing "Home" then "Enter", it would seem that "Enter" actually works more like LFCR ?

Yes this is a good description of my confusion
Post reply on HN