CRLF is obsolete and should be abolished

Original Article ↗ Hacker News Discussion ↗

Scope of the proposal

  • Article argues CRLF is obsolete; suggests treating LF (U+000A) as “newline” everywhere, ignoring CR where possible, and even sending LF-only on protocols that specify CRLF.
  • Some commenters like the spirit: simplifying stacks, reducing historical cruft, and converging on a single line-ending convention.

Backwards compatibility & standards

  • Strong pushback that intentionally violating well‑established protocols (HTTP/1.1, SMTP, FTP, CSV) is irresponsible.
  • Many argue benefits (slightly simpler code, a few bytes saved) are tiny versus risk and cost of hunting subtle breakage.
  • Standards are seen by some as normative contracts that avoid “dumb debugging”; others see them as tools, not laws, and accept “de facto” practice shaping future revisions.

Security implications

  • Multiple comments connect mixed CR/LF handling to real vulnerabilities (SMTP smuggling, HTTP request smuggling).
  • Core concern: inconsistent parsing across proxies, middleboxes, and backends lets attackers smuggle extra headers or messages.
  • Some argue strict CRLF-only parsing is safer; others note the internet already contains many LF‑tolerant servers, so uniformity is already lost.

Existing ecosystem behavior

  • Empirical tests show many major HTTP sites reject bare-LF requests with 400/505 or no response, contradicting the claim that “almost all” implementations accept LF.
  • Some servers and tools (historically sendmail, some CSV tools, some HTTP stacks) do accept bare LF; others are intentionally strict.
  • CSV is cited as a case where practice (LF / platform endings) diverges from the spec (CRLF).

Terminals, history, and naming

  • Debate over whether Unix’s LF‑only was a mistake or a reasonable simplification separating storage from terminal control.
  • Clarifications that Unicode labels U+000A as LF, NL, and EOL, but terminal raw mode still treats CR and LF distinctly.
  • Some note LF is meaningful (e.g., progress bars using CR; potential uses of LF‑only motion).

Tooling & cross‑platform issues

  • Git’s autocrlf and .gitattributes debated: some say Git should never touch line endings; others rely on normalization to juggle Windows/Unix tools.
  • Editors and POSIX “final newline” expectations surface as parallel line‑ending frictions.

Author’s follow‑up (from thread)

  • Author later clarifies intent: allow LF as an accepted terminator while still accepting CRLF, not reject CRLF.
  • After real breakage (e.g., with some HTTP clients), they reverted their own LF‑only change and declare the “revolution over,” accepting that CRLF will persist.