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

201–210 of 273 posts

Re: CRLF is obsolete and should be abolished

#201

Post by inopinatus »

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…

Not just potential bugs, there'll be definite security failures.

Changing the line endings can invalidate signatures over plaintext content. So an email MTA, for example, could never do so. Nor most proxy implementations. Then there's the high latent potential for request smuggling, command injection, and privilege escalation, via careful crafting of ambiguous header lines or protocol commands that target less robust implementations. With some protocols, it may cause declared content sizes to be incorrect, leading to bizarre hangs, which is to say, another attack surface.

In practice, retiring CRLF can't be safely performed unilaterally or by fiat, we'll need to devise a whole new handshake to affirm that both ends are on the same page re. newline semantics.

Re: CRLF is obsolete and should be abolished

#202

Post by eviks »

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

Re: CRLF is obsolete and should be abolished

#204

Post by Ygg2 »

inopinatus wrote: post #199
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.

It also goes a bit more than that, for optimal UTF8 search you want the ASCII separators. It's always easier to search for a single byte than two or more bytes of special pattern.

That said, I do agree we should abolish CRLF. And replace it with LF.

Re: CRLF is obsolete and should be abolished

#205

Post by eviks »

shadowgovt wrote: post #25

Define "abolish." We could certainly try to write no new software that uses them. But last I checked, there are terabytes and terabytes of stored data in various formats (to say nothing of living protocols already deployed) and they aren't gonna stop using CRLF any time soon.

Is defined in 4 points at the end

Re: CRLF is obsolete and should be abolished

#206

Post by eviks »

akira2501 wrote: post #160
rkeene2 wrote: post #21

Earlier quoted context omitted.

People don't seem to mind when Chrome does it [0]. The response "standards aren't a death pact" stands out in particular. [0] https://news.ycombinator.com/item?id=13860682

Death pact? Jeez. Standards simply prevent people from having to waste time debugging dumb issues that rightfully could have been avoided.

They also add to the time wasted by not removing needless complexity in due time

Re: CRLF is obsolete and should be abolished

#207

Post by inopinatus »

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.

That was already motivated by Postel's Law. It's a step beyond to change what the strict form is; relying on the same to justify unilaterally transposing the form is asking too much of middlebox implementations of just about any line-oriented protocol, and possible violates Postel's Law itself by asserting the inverse.

Re: CRLF is obsolete and should be abolished

#209

Post by bvrmn »

LegionMammal978 wrote: post #42
javajosh wrote: post #11

Earlier quoted context omitted.

>What would be the benefit... It is interesting that you ignore the benefits the OP describes and instead present a vague and fearful characterization of the costs. Your reaction lies at the heart of cargo-culting, the maintenance of previous decisions out of sheer dread. One can do a cost-benefit analysis and decide what to do, or you can let your emotions decide. I suggest that the world is better off with the form…

The cost is, if people start transitioning to a world where senders only transmit LF in opposition to current standards for protocols like HTTP/1.1 or SMTP (especially aggressively, e.g., by creating popular HTTP libraries without a CRLF option), then it will create the mental and procedural overhead of tracking which receivers accept LF alone vs. which still require CRLF. Switching established protocols is never fre…

2-to-3 fiasco was solely caused by inadequate support to write py2 compatible code until python 3.4. It was literally "you devs, stop write ugly py2, let's write godly py3".

Re: CRLF is obsolete and should be abolished

#210

Post by perching_aix »

oasisaimlessly wrote: post #197
perching_aix wrote: post #189

Earlier quoted context omitted.

> 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").

That is also true, adding to the bafflement factor of it supposedly being "non-existent".
Post reply on HN