\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.