101–110 of 273 posts
Earlier quoted context omitted.
It makes writing parsers more complicated in certain cases because you can't tell without lookahead if a newline character should be treated as a newline or an eof.
What? Which crazy non-binary format makes a distinction between CRLF(EOF) and just (EOF)? Apart from a plain text file, that is.
No mention of what happened the last time we mixed and matched line endings? https://smtpsmuggling.com/
Doesn’t this show that ignoring CR and only processing LFs is a good idea? If I’m understanding right (probably wrong), this vuln relied on some servers using CRLF only as endings, and others supporting both CRLF and LF. If every server updated to line-end of LF, thereby supporting both types, this vuln wouldn’t happen? Of course if there’s is a mixed bag then I guess this is still possible, if your server only suppo…
Unfortunately, asking more people to ignore the currently estabilished standards makes the problem worse, not better.
Earlier quoted context omitted.
This would be more persuasive if HTTP servers didn't already widely accept bare 0ah line termination. What's the first major public web site you can find that doesn't?
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…
> 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?
It was used for "graphics" on character-only terminals.
I think I can offer most reasonable compromise here. Decide upon on new UTF-8 code point. Have the use mandated and ignore and ban all end-points that do not use this code-point instead of CRLF or just LF alone.
Earlier quoted context omitted.
IETF standards are tools to help developers get stuff done on the Internet. They are not the only tool, and they don't carry any moral force.
Apart from colloquially considering standards not-necessarily-normative being, in my opinion, nonsensical (see below), to the best of my knowledge at the very least the STD subseries of IETF standards documents are normative in nature: https://datatracker.ietf.org/doc/std > They are not the only tool, and they don't carry any moral force. Indeed there are countless other standards bodies in the world also producing n…
The article had some major gaffes. Teletypes never had a ball. The stationary platen models had type boxes and cylinders, but never balls.
Not sure whether this changes anything about your critique, but note that the IBM 2741 terminal embedded a Selectric typewriter: > Selectric-based mechanisms were also widely used as terminals for computers, replacing both Teletypes and older typebar-based output devices. One popular example was the IBM 2741 terminal https://en.wikipedia.org/wiki/IBM_Selectric
stop reinventing terms. it's literally standardized with the name "LF" / "line feed" in Unicode.
> 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…
Easy - being able to use a plain text protocol as a human being without having to worry if my terminal sends the right end of line terminator. Using netcat to debug SMTP issues is actually something I do often enough.