CRLF is obsolete and should be abolished

Original Article ↗ Hacker News Discussion ↗

A proposal to treat the carriage-return + line-feed (CRLF) sequence as obsolete and simply send line-feed (LF) in text-based protocols like HTTP, SMTP, and CSV sparked debate over standards compliance versus practical simplification. Supporters see CRLF as pointless historical baggage that complicates cross-platform tooling and parsing, while critics argue that deviating from established specs risks subtle interoperability and security bugs, especially in layered systems and legacy software. After initial experiments broke some clients, the author of the proposal rolled back the change and conceded that CRLF will likely persist, though many agree new protocols should avoid it.

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.