Antworten:
\r\n
, weil es als Zeilenumbruch in der Protokollspezifikation definiert ist. RFC2616 stellt am Anfang von Abschnitt 2.2, "Grundregeln" , ganz eindeutig fest:
CR = <US-ASCII CR, Wagenrücklauf (13)>
LF = <US-ASCII LF, Zeilenvorschub (10)>
HTTP / 1.1 definiert die Sequenz CR LF als Zeilenende-Markierung für alle Protokollelemente mit Ausnahme der Entität -Körper
RFC2616 wurde von RFC7230 technisch überholt, nimmt jedoch keine drastischen Änderungen vor und ruft CRLF erneut als Trennzeichen in Abschnitt 3 auf . RFC verweist auf RFC5234, Anhang B.1 , um "CRLF" als zu definieren %x0D %x0A
.
In Anbetracht der Tatsache , dass Personen gegen den Standard verstoßen, gibt es in Abschnitt 19.3 eine "Toleranzbestimmung" (beachten Sie, dass die richtige Reihenfolge wiederholt wird):
Der Zeilenabschluss für Nachrichtenkopffelder ist die Sequenz CRLF. Wir empfehlen jedoch, dass Anwendungen beim Parsen solcher Header einen einzelnen LF als Zeilenabschluss erkennen und den führenden CR ignorieren.
Im neueren RFC7230 ist § 3.5
Obwohl der Zeilenabschluss für die Startzeilen- und Kopfzeilenfelder die Sequenz CRLF ist, kann ein Empfänger einen einzelnen LF als Zeilenabschluss erkennen und alle vorhergehenden CR ignorieren.
Verwenden Sie daher, es sei denn, Sie möchten böse sein oder auf andere Weise gegen die RFC-Regeln verstoßen \r\n
.
\ r \ n, weil RFC 2616 dies sagt (Abschnitt 2.2, "Grundregeln"):
HTTP / 1.1 definiert die Sequenz CR LF als Zeilenende-Marker für alle
Protokollelemente mit Ausnahme des Entity-Body (
tolerante Anwendungen siehe Anhang 19.3 ). Die Zeilenende-Markierung innerhalb eines Entitätskörpers wird durch den zugehörigen Medientyp definiert, wie in Abschnitt 3.7 beschrieben.CRLF = CR LF
CRLF ("\ r \ n"), da Browser RFC2616 folgen .