Зачем нужны границы в многостраничном формате данных?
Название говорит само за себя. Я имею в виду, что мы пытаемся загрузить несколько изображений, для каждого составного раздела у нас будут подзаголовки вроде
Content-Disposition: form-data; name = "file"; filename = "mia.jpeg"
Content-Type: image/jpeg
Content-Length: 5379
Content-Length достаточно, чтобы сообщить парсеру, когда эта часть содержимого закончилась и начинается другая часть. Но, скорее всего, я чего-то упускаю, не могли бы вы помочь?
Ответы 2
Content-Length не является требованием для составного контента. Эта проблема использования длин рассматривается в части старый RFC:
5.2 Other data encodings rather than multipart
Various people have suggested using new mime top-level type "aggregate", e.g., aggregate/mixed or a content-transfer-encoding of "packet" to express indeterminate-length binary data, rather than relying on the multipart-style boundaries. While this would be useful, the "multipart" mechanisms are well established, simple to implement on both the sending client and receiving server, and as efficient as other methods of dealing with multiple combinations of binary data.
Однако этого текста нет в текущий; length в нем вообще не фигурирует.
Это имеет особый смысл, если вы считаете, что отправитель отправляет результат потока как часть составного сообщения, когда он может не знать заранее длину данных этого потока. Если требуется длина, потребуется либо кэшировать, либо читать дважды.
да, это имеет смысл, поэтому даже без учета длины серверы должны иметь возможность декодировать составные данные, потому что их алгоритм анализа основан на границах, а не на подсчете байтов?
@GionJh - Верно.
И последнее, я где-то читал (извините, не помню источник), что отправка двоичных данных в формате, состоящем из нескольких частей, нехорошо, и вы должны кодировать их в Base64, что вы думаете?
@GionJh - у меня нет особых знаний об этом, извините.
@ T.J. Crowder Вы выбрали давно устаревший RFC. Проверьте RFC 7578 для получения текущей документации.
@CassioMazzochiMolin - Спасибо, первое, что я нашел, как ни удивительно, я не запомнил их. :-)
@GionJh относительно base64 см. stackoverflow.com/questions/3538021/why-do-we-use-base64, а также stackoverflow.com/questions/4070693/… и base64 или multi-part не является ни или, поскольку они могут использоваться вместе. Они решают разные задачи. Что-то, отправленное как base64, - это просто еще один документ.
Why do we need boundaries in multipart data format?
Границы - это разделители, позволяющие серверу разделить сообщение на фрагменты или части тела. Составной запрос может содержать любое произвольное количество частей тела. Запросы multipart/form-data в настоящее время определены в RFC 7578.
Каждая часть состоит из собственного заголовка содержимого (ноль или более полей заголовка Content-) и тела. Также важно отметить, что ограничитель границ не должен появляться внутри какой-либо из инкапсулированных частей.
Другой соответствующий документ - это RFC 2046, который определяет составные потоки данных MIME:
The body must then contain one or more body parts, each preceded by a boundary delimiter line, and the last one followed by a closing boundary delimiter line. After its boundary delimiter line, each body part then consists of a header area, a blank line, and a body area.
@GionJh Если он отвечает на ваш вопрос, не забудьте принять его.
прежде чем синтаксический анализатор сможет проанализировать длину содержимого, он должен разбить необработанные данные на фрагменты