Odpowiedzi:
\r\n, ponieważ jest zdefiniowany jako podział wiersza w specyfikacji protokołu. RFC2616 stwierdza na początku sekcji 2.2, „Zasady podstawowe” , dość jednoznacznie:
CR = <US-ASCII CR, powrót karetki (13)>
LF = <US-ASCII LF, linefeed (10)>
HTTP / 1.1 definiuje sekwencję CR LF jako znacznik końca linii dla wszystkich elementów protokołu z wyjątkiem jednostki -ciało
RFC2616 został technicznie przestarzały przez RFC7230, ale nie wprowadza drastycznych zmian i ponownie wywołuje CRLF jako separator w sekcji 3 , a RFC odwołuje się do RFC5234, dodatek B.1, aby zdefiniować „CRLF” jako %x0D %x0A.
Jednak uznając, że ludzie będą łamać standard w jakimkolwiek celu, w sekcji 19.3 znajduje się „postanowienie dotyczące tolerancji” (należy pamiętać, że powtarza on poprawną kolejność):
Terminatorem wiersza dla pól nagłówka wiadomości jest sekwencja CRLF. Jednak zalecamy, aby aplikacje podczas analizowania takich nagłówków rozpoznawały pojedynczy LF jako zakończenie linii i ignorowały wiodącą CR.
W nowszym RFC7230, § 3.5
Chociaż terminatorem linii dla pól linii początkowej i nagłówka jest sekwencja CRLF, odbiorca MOŻE rozpoznać pojedynczy LF jako terminator linii i zignorować każdą poprzedzającą ją CR.
Dlatego jeśli nie chcesz być Zły lub w inny sposób złamać zasady RFC, użyj \r\n.
\ r \ n, ponieważ tak mówi RFC 2616 (sekcja 2.2, „Podstawowe zasady”):
HTTP / 1.1 definiuje sekwencję CR LF jako znacznik końca linii dla wszystkich
elementów protokołu poza ciałem jednostki (patrz dodatek 19.3 dla
aplikacji tolerancyjnych). Znacznik końca linii w treści jednostki jest definiowany przez powiązany z nim typ mediów, jak opisano w sekcji 3.7.CRLF = CR LF
CRLF ("\ r \ n"), ponieważ przeglądarki przestrzegają RFC2616 .