> Nobody ever wants to be in the middle of a line, then move down to the next line and continue writing in the next column from where you left off. No real-world program ever wants to do that.
Is this true?
CRLF is obsolete and should be abolished
81–90 of 273 posts
Re: CRLF is obsolete and should be abolished
#82Earlier 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
Might be just my personal impression, but I'm pretty sure Chrome is extremely notorious for abusing its market leader position, including in this way. So gonna have to disagree there, from my view people do mind Chrome and its implementation particularities quite a lot.
I think the parent is equally denigrating the situation.
Leaders choose the standards, especially as they approach monopoly.
Worse still: people will come out of the woodwork to actively defend the monopolist de facto standard producer.
Re: CRLF is obsolete and should be abolished
#83we should leave it for backwards compatibility and adopt U+0085 as the standard next line codepoint. and utf8 libraries could unofficially support every combination of 0A 0D as escape sequences.
Re: CRLF is obsolete and should be abolished
#84Earlier quoted context omitted.
I'm saying the consistency that Filippo says our security depends on doesn't really seem to exist in the world, which hurts the persuasiveness of that particular argument in favor of consistency.
But no one expects 0ah to be sufficient. Change that expectation, and now you have to wonder if your middleware and your backend agree on whether the middleware filtered out internal-only headers.
Yeah, I'm not certain that this is a real issue. It might be? Certainly, I'm read in to things like TECL desync. I get the concern, that any disagreement in parsing policies is problematic for HTTP because of middleboxes. But I think the ship may have sailed on 0ah, and that it may be the case that you simply have to build HTTP systems to be bare-0ah-tolerant if you want your system to be resilient.
Re: CRLF is obsolete and should be abolished
#85> Let's make CRLF one less thing that your grandchildren need to know about or worry about. The struggle is real, the problem is real. Parents, teach your kids to use .gitattribute files[1]. While you're at it, teach them to hate byte order marks[2]. 1: https://stackoverflow.com/questions/73086622/is-a-gitattribu... 2: https://blog.djhaskin.com/blog/byte-order-marks-must-diemd/
The letters after the dot in my filename don't map 1 to 1 with the file format.
Re: CRLF is obsolete and should be abolished
#86Earlier quoted context omitted.
Might be just my personal impression, but I'm pretty sure Chrome is extremely notorious for abusing its market leader position, including in this way. So gonna have to disagree there, from my view people do mind Chrome and its implementation particularities quite a lot.
I think the parent is equally denigrating the situation. Leaders choose the standards, especially as they approach monopoly. Worse still: people will come out of the woodwork to actively defend the monopolist de facto standard producer.
Not defending the producer, just making pragmatic choices!
Re: CRLF is obsolete and should be abolished
#87Earlier quoted context omitted.
> 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…
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.
That's just two systems that happen to agree on garbage.
Re: CRLF is obsolete and should be abolished
#88sqlite is a work of absolute genius. But every once in awhile something comes along to remind us how weird its software background is. Fossil. The build system. The TCL test harness. And now this, a quixotic attempt to break 50+ years of text formatting and network protocols.
Yes CRLF is dumb. No, replacing it is not realistic.
Re: CRLF is obsolete and should be abolished
#89Earlier quoted context omitted.
Yeah, I have no idea what the author is smoking. Deliberately breaking standards is simply not an acceptable solution to the problem, even if it were a serious problem (it's not).
If there truly is a problem with existing protocols, propose and properly design new one that can replace it. Then if it is technically superior solution it should win in long run.
No need. Just convince the king (e.g. Google for HTTP) to make a tweak in the next standard version.
Re: CRLF is obsolete and should be abolished
#90Counterpoint: 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.
It is a standard line ending. ANSI X3.4-1968 says:
10 LF (Line Feed). A format effector that advances the active position to the same character position on the next line. (Also applicable to display devices.) Where appropriate, this character may have the meaning “New Line” (NL), a format effector that advances the active position to the first character position on the next line. Use of the NL convention requires agreement between sender and recipient of data.
ASCII 1968 - https://www.rfc-editor.org/info/rfc20
ASCII 1977 - https://nvlpubs.nist.gov/nistpubs/Legacy/FIPS/fipspub1-2-197...