Відповіді:
\r\n, оскільки він визначається як розрив рядка в специфікації протоколу. RFC2616 говорить на початку розділу 2.2 "Основні правила" досить однозначно:
CR = <CR-US-ASCII, повернення каретки (13)>
LF = <US-ASCII LF, передача рядків (10)>
HTTP / 1.1 визначає послідовність CR LF як маркер кінцевого рядка для всіх елементів протоколу, крім сутності -тіла
RFC2616 технічно застарів RFC7230, але він не вносить кардинальних змін і знову закликає CRLF як роздільник, в розділі 3 , і що посилання RFC посилається на RFC5234, додаток B.1, щоб визначити "CRLF" як %x0D %x0A.
Однак, визнаючи, що люди порушують стандарт для будь-яких цілей, в розділі 19.3 є "положення про толерантність" (зауважте, що воно повторює правильну послідовність):
Термінальним рядком для полів заголовка повідомлень є послідовність CRLF. Однак ми рекомендуємо, щоб програми, розбираючи такі заголовки, розпізнавали один LF як термінальний рядок і ігнорували провідний CR.
У новій RFC7230, § 3.5
Хоча термінальний рядок для полів початкового рядка та заголовка є послідовністю CRLF, одержувач МОЖЕ розпізнати один LF як термінальний рядок і ігнорувати будь-який попередній CR.
Тому, якщо ви не хочете бути Злом або порушити іншим чином правила RFC, використовуйте \r\n.
\ r \ n тому, що RFC 2616 говорить так (Розділ 2.2, "Основні правила"):
HTTP / 1.1 визначає послідовність CR LF як маркер кінця рядка для всіх
елементів протоколу, за винятком суті-тіла (див. Додаток 19.3 для
толерантних додатків). Маркер кінця рядка в тілі суб'єкта визначається його асоційованим типом медіа, як описано в розділі 3.7.CRLF = CR LF
CRLF ("\ r \ n"), тому що браузери дотримуються RFC2616 .