Respostas:
\r\n, porque é definido como a quebra de linha na especificação do protocolo. A RFC2616 declara no início da seção 2.2, "Regras básicas" , sem ambiguidade:
CR = <US-ASCII CR, retorno de carro (13)>
LF = <US-ASCII LF, avanço de linha (10)>
HTTP / 1.1 define a sequência CR LF como o marcador de fim de linha para todos os elementos do protocolo, exceto a entidade -corpo
O RFC2616 foi tecnicamente obsoleto pelo RFC7230, mas não faz alterações drásticas e novamente chama o CRLF como o delimitador na seção 3 , e esse RFC faz referência ao RFC5234, Apêndice B.1 para definir "CRLF" como %x0D %x0A.
No entanto, reconhecendo que as pessoas quebram o padrão para quaisquer fins, existe uma "provisão de tolerância" na seção 19.3 (observe que ele reitera a sequência correta ):
O terminador de linha para os campos do cabeçalho da mensagem é a sequência CRLF. No entanto, recomendamos que os aplicativos, ao analisar esses cabeçalhos, reconheçam um único LF como um terminador de linha e ignorem o CR principal.
No mais novo RFC7230 recente, § 3.5
Embora o terminador de linha para os campos de linha de início e cabeçalho seja a sequência CRLF, um destinatário PODE reconhecer um único LF como terminador de linha e ignorar qualquer CR anterior.
Portanto, a menos que você queira ser mau ou violar as regras da RFC, use \r\n.
\ r \ n porque o RFC 2616 diz isso (Seção 2.2, "Regras básicas"):
O HTTP / 1.1 define a sequência CR LF como o marcador de fim de linha para todos os
elementos do protocolo, exceto o corpo da entidade (consulte o apêndice 19.3 para
aplicações tolerantes). O marcador de fim de linha em um corpo da entidade é definido pelo tipo de mídia associado, conforme descrito na seção 3.7.CRLF = CR LF
CRLF ("\ r \ n"), porque os navegadores seguem o RFC2616 .