196

Which line break style is preferable for use in HTTP headers: \r\n or \n, and why?

Shashank Agrawal
  • 25,161
  • 11
  • 89
  • 121
dpq
  • 9,028
  • 10
  • 49
  • 69

3 Answers3

281

\r\n, because it's defined as the line break in the protocol specification. RFC2616 states at the beginning of section 2.2, "Basic Rules", quite unambiguously:

CR = <US-ASCII CR, carriage return (13)>
LF = <US-ASCII LF, linefeed (10)>
HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all protocol elements except the entity-body

RFC2616 was technically obsoleted by RFC7230, but it makes no drastic changes and again calls out CRLF as the delimiter in section 3, and that RFC references RFC5234, Appendix B.1 to define "CRLF" as %x0D %x0A.

However, recognizing that people will break the standard for whatever purposes, there is a "tolerance provision" in section 19.3 (note that it re-iterates the correct sequence):

The line terminator for message-header fields is the sequence CRLF. However, we recommend that applications, when parsing such headers, recognize a single LF as a line terminator and ignore the leading CR.

In the newer RFC7230, § 3.5

Although the line terminator for the start-line and header fields is the sequence CRLF, a recipient MAY recognize a single LF as a line terminator and ignore any preceding CR.

Therefore, unless you want to be Evil or otherwise break the RFC's rules, use \r\n.

Community
  • 1
  • 1
Piskvor left the building
  • 91,498
  • 46
  • 177
  • 222
  • @Fred: No, there *is* such a thing as being too obvious - unneeded repetition and unnecessarily repeating and pointlessly repeating the same information clouds the message. Especially when the same thing is quoted right above - from the spec, no less. – Piskvor left the building Jul 11 '14 at 12:19
  • 11
    Good clear answer. This is exactly what StackOverflow is best for: simple clear answers to simple clear questions, without the unnecessary and unhelpful clutter of blogs and articles. – Miles Rout Oct 13 '14 at 21:59
  • @Piskvor, Is the response allowed to **start** with `\r\n` ? – Pacerier May 13 '15 at 08:28
  • @Pacerier: No. That would give you a response without any response-header. Since a response code and phrase are *required* on the first line (e.g. `HTTP/1.1 200 OK`), I'd say that a response starting with an endline would be invalid. – Piskvor left the building Sep 11 '15 at 11:23
  • @Piskvor, Does the RFC mention that such *trimming* is not allowed or is it "optional"? – Pacerier Jul 29 '16 at 14:16
  • 2
    @Pacerier: Does not mention any such thing at all; since it essentially specifies "this is the only valid syntax for HTTP," anything else is invalid syntax. Of course, you *could* violate the RFC all you want, there's nobody who could stop you - but then you're technically not implementing a HTTP client anymore, just something that looks sort of similar ;) – Piskvor left the building Aug 18 '16 at 11:46
  • 1
    IMHO, would be interesting to know WHY `\r\n` was chosen instead of other options (`\r`, `\n`, something else). – Dan M. Nov 27 '17 at 16:23
  • 2
    @DanM: Thanks Microsoft! – palswim Jan 31 '18 at 06:11
  • 2
    RFC7230 which obsoletes RFC2616 contains the same text in [Section 3.5](https://tools.ietf.org/html/rfc7230#section-3.5) – Grief Oct 19 '18 at 11:21
  • @Grief: Still proposed only, and didn't exist when this answer was written. Good catch nevertheless! :) – Piskvor left the building Oct 19 '18 at 11:37
30

\r\n because RFC 2616 says so (Section 2.2, "Basic Rules"):

HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all
protocol elements except the entity-body (see appendix 19.3 for
tolerant applications). The end-of-line marker within an entity-body is defined by its associated media type, as described in section 3.7.

   CRLF           = CR LF
vallentin
  • 23,478
  • 6
  • 59
  • 81
SymKat
  • 841
  • 5
  • 5
17

CRLF ("\r\n"), because browsers follow RFC2616.

Jürgen Thelen
  • 12,745
  • 7
  • 52
  • 71