Hacker News 의견

• 기존 프로토콜을 NL로 업데이트하는 것은 잠재적 버그를 초래할 수 있으며, HTTP/1.1은 이미 HTTP/2로 대체되었음
  • 새로운 프로토콜에서는 CRLF를 요구하지 않는 것이 합리적이지만, 기존 프로토콜을 업데이트할 필요는 없다고 주장함
• CRLF를 준수하지 않는 것은 의도적으로 버그를 도입하는 것과 같음
  • SQLite의 HTTP 서버가 \r\n 대신 \n을 사용하도록 업데이트되었으나, 이는 Zig의 HTTP 클라이언트와의 호환성을 깨뜨림
• CRLF를 후손들이 걱정할 필요가 없도록 하자는 의견
  • .gitattribute 파일 사용법을 가르치고, 바이트 순서 표시(Byte Order Mark)를 싫어하도록 교육해야 한다고 주장함
• Unix의 비표준 줄 끝맺음 선택은 실수였으며, 이는 수십 년간의 호환성 문제를 초래했음
  • CRLF는 터미널 API의 두 가지 다른 부분이며, 많은 프로그램이 CR과 LF의 올바른 작동에 의존함
• CRLF는 표준에서 가장 덜 중요한 요소 중 하나임
  • 표준을 깨는 것은 새로운 시도이며, 개인적으로는 낯선 태도임
• SMTP는 메시지 종료 시퀀스가 CR LF . CR LF임을 명확히 하고 있으며, LF . LF를 인식하는 구현도 존재함
  • 원래 SMTP 규칙이 더 이상 중요하지 않을 수도 있음
• CRLF는 많은 장치에 위험을 초래할 수 있으며, 예외를 줄여야 함
• 줄 끝맺음을 혼합했을 때 발생한 문제에 대한 언급이 없음
  • NL이라는 문자는 존재하지 않으며, 모든 키보드의 "ENTER" 키는 CR을 전송함
  • 현재 방식이 잘 작동하고 있음