HTTP Range Range multipart/byteranges - есть ли CRLF в конце?

Question

RFC7233 хорош и понятен, за исключением концов строк.

Меня особенно интересует тело ответа HTTP multipart/byteranges ответ. Я предполагаю, что каждая строка завершается CRLF, как заголовки HTTP, но этот документ не говорит об этом явно. То, что меня полностью смущает, так это последняя строка: --THIS_SEPARATOR_SEPARATES--, Это сопровождается CRLF?

Полный блок:

HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Length: 1741
Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES

--THIS_STRING_SEPARATES
Content-Type: application/pdf
Content-Range: bytes 500-999/8000

...the first range...
--THIS_STRING_SEPARATES
Content-Type: application/pdf
Content-Range: bytes 7000-7999/8000

...the second range
--THIS_STRING_SEPARATES--

Извините, я действительно не могу найти его, поэтому помощь будет принята с благодарностью. ПРИМЕЧАНИЕ: пожалуйста, никаких интуитивных чувств, только ссылки RFC.

Answer 1

Если вы читаете RFC 7233 более внимательно, в Приложении A содержится ссылка на Раздел 5.1 RFC 2046 для фактического формата данных MIME в теле HTTP:

Когда ответное сообщение 206 (частичное содержимое) включает в себя содержимое нескольких диапазонов, они передаются как части тела в теле составного сообщения ([RFC2046], раздел 5.1) с типом мультимедиа "multipart/byteranges".

Раздел 5.1 RFC 2046 определяет формальное определение мультимедийного типа мультимедиа и того, как его границы форматируются и анализируются.

Чтобы ответить на ваш вопрос, вот формальный синтаксис из RFC 2046:

   Ограничитель границы ДОЛЖЕН встречаться в начале строки, т. Е.
   после CRLF, и начальный CRLF считается прикрепленным
   до границы разделительной линии, а не части предыдущего
   часть. Граница может сопровождаться нулем или более символов
   линейный пробел. Затем он завершается другим CRLF и
   поля заголовка для следующей части или двумя CRLF, в этом случае
   для следующей части нет полей заголовка. Если нет Content-Type
   поле присутствует, предполагается, что это "message/rfc822" в
   "multipart/digest" и "text/plain" в противном случае.

   ПРИМЕЧАНИЕ. CRLF, предшествующий линии границы, концептуально
   прикреплен к границе, так что возможно иметь часть, которая
   не заканчивается CRLF (перевод строки). Части тела, которые должны быть
   считается завершенным с переносами строк, поэтому должны иметь два CRLF
   предшествующей линии границы раздела, первая из которых является частью
   предыдущая часть тела, а вторая часть является частью
   граница инкапсуляции.

...

   Граничная линия, следующая за последней частью тела, представляет собой
   Выделенный разделитель, который указывает, что больше нет частей тела
   будет следовать. Такая разделительная линия идентична предыдущей
   разделительные линии, с добавлением еще двух дефисов после
   значение граничного параметра.

     --gc0pJq0M:08jU534c0p--

   ПРИМЕЧАНИЕ ДЛЯ РЕАЛИЗОВАТЕЛЕЙ: Сравнение границ строк должно сравнивать
   граничное значение с началом каждой строки-кандидата. Точный
   совпадение всей кандидатской линии не требуется; это достаточно
   что граница появляется полностью после CRLF.

...

   Единственный обязательный глобальный параметр для мультимедийного типа
   граничный параметр, который состоит из 1 до 70 символов от
   набор символов, которые, как известно, очень устойчивы через почтовые шлюзы, и
   НЕ заканчивается пробелами. (Если появляется линия границы
   конец с пробелом, предполагается, что пробел был
   добавлены шлюзом и должны быть удалены.) Формально указано
   следующим БНФ:

     граница:= 0*69 bcharsnospace

     bchars:= bcharsnospace / " "

     bcharsnospace:= ЦИФРА / АЛЬФА / "'" / "(" / ")" /
                      "+" / "_" / "," / "-" / "." /
                      знак равно

   В целом, тело "составного" объекта может быть указано как
   следующим образом:

     граница тире:= "-" граница; граница берется из значения; граничный параметр; Поле Content-Type.

     multipart-body:= [преамбула CRLF]
                       транспортно-отступная граница в тире CRLF
                       тело-часть * инкапсуляция
                       Транспортный отступ
                       [CRLF эпилог]

     транспорт-отступ:= *LWSP-char; Композиторы НЕ ДОЛЖНЫ генерировать; транспорт ненулевой длины; дополнения, но приемники ДОЛЖНЫ; уметь справляться с набивкой; добавлено транспортами сообщений.

     инкапсуляция: = разделитель транспорта-заполнения
                      CRLF часть тела

     разделитель:= CRLF-тире

     разделитель: = разделитель "-"

     преамбула: = отбросить текст

     эпилог: = сбросить текст

     discard-text:= *(* текст CRLF) * текст; Может быть проигнорировано или отброшено.

     body-part:= MIME-part-headers [CRLF *OCTET]; Линии в части тела не должны начинаться; с указанной тире-границей и; разделитель не должен появляться нигде; в части тела. Обратите внимание, что; семантика части тела отличается от; семантика сообщения, как; описано в тексте.

     OCTET:= <любое значение 0-255 октетов>

Каждый разделитель в начале новой части заканчивается CRLF, и любой CRLF, который непосредственно предшествует разделителю, анализируется как часть границы, а не как данные предыдущей части. Однако CRLF на конце последней закрывающей границы отсутствует, если только не присутствует эпилог (который очень редко используется в электронной почте, и я никогда не видел его в HTTP, поскольку нет способа определить, когда заканчивается эпилог если нет действительного Content-Length присутствует заголовок, который не должен использоваться с самоограниченными типами контента, такими как MIME).

Answer 2

Это спецификация ссылок:

https://tools.ietf.org/html/rfc2046

Который явно заявляет:

 --gc0pJq0M:08jU534c0p

Ограничитель границы ДОЛЖЕН появляться в начале строки, т. Е. После CRLF, а начальный CRLF считается прикрепленным
до границы разделительной линии, а не части предыдущего
часть. Граница может сопровождаться нулем или более символов
линейный пробел. Затем он завершается другим CRLF и
поля заголовка для следующей части или двумя CRLF, в этом случае
для следующей части нет полей заголовка. Если нет Content-Type
поле присутствует, предполагается, что это "message/rfc822" в
"multipart/digest" и "text/plain" в противном случае.