Какова граница в multipart / form-data?

Question

Я хочу задать вопрос о multipart/form-data.В заголовке HTTP я обнаружил, что Content-Type: multipart/form-data; boundary=???.

Является ли ??? свободным для определения пользователем?Или это сгенерировано из HTML?Могу ли я определить ??? = abcdefg?

Answer 1

Является ли ??? свободным для определения пользователем?

Да.

или это предоставлено HTML?

Нет. HTML не имеет к этому никакого отношения . Читайте ниже.

Могу ли я определить ??? как abcdefg?

Да.

Если вы хотите отправить на веб-сервер следующие данные:

name = John
age = 12

с использованием application/x-www-form-urlencoded будет выглядеть так:

name=John&age=12

Как видите, сервер знает, что параметры разделены амперсандом &. Если для значения параметра требуется &, то оно должно быть закодировано.

Так как же сервер узнает, где начинается и заканчивается значение параметра, когда он получает HTTP-запрос, используя multipart/form-data?

Использование границы , аналогично &.

Например:

--XXX
Content-Disposition: form-data; name="name"

John
--XXX
Content-Disposition: form-data; name="age"

12
--XXX--

В этом случае граничное значение равно XXX. Вы указываете это в заголовке Content-Type, чтобы сервер знал , как разбивать данные, которые он получает.

Так что вам нужно:

• Используйте значение, которое не будет отображаться в данных HTTP, отправляемых на сервер.

• Будьте последовательны и используйте одно и то же значение везде в сообщении запроса.

Answer 2

Точный ответ на вопрос: да, вы можете использовать произвольное значение для параметра boundary , если оно не превышает 70 байт и состоит только из 7-бит US-ASCII (для печати) символов.

Если вы используете один из multipart/* типов содержимого, на самом деле требуется для указания параметра boundary в *Заголовок 1013 *, иначе сервер (в случае HTTP-запроса) не сможет проанализировать полезную нагрузку.

Возможно, вы также захотите установить для параметра charset значение UTF-8 в своем Content-Type заголовок, если вы не можете быть абсолютно уверен, что в данных полезной нагрузки будет использоваться только US-ASCII кодировка.

Несколько соответствующих выдержек из RFC2046 :

• 4.1.2.Параметр Charset:

  В отличие от некоторых других значений параметров, значения параметра charset НЕ чувствительны к регистру.Набор символов по умолчанию, который должен приниматься при отсутствии параметра набора символов, - US-ASCII.

• 5.1.Составной тип мультимедиа

  Как указано в определении поля Content-Transfer-Encoding [RFC 2045], никакое кодирование, кроме "7bit", "8bit" или "binary", не допускается для объектовтипа "multipart".«Составные» граничные разделители и поля заголовка всегда представлены как 7-битный US-ASCII в любом случае (хотя поля заголовка могут кодировать текст заголовка не-US-ASCII в соответствии с RFC 2047), а данные внутри частей тела могут быть закодированы напо частям, с полями Content-Transfer-Encoding для каждой соответствующей части тела.

  Для поля Content-Type для составных объектов требуется один параметр - border.Строка ограничителя границы затем определяется как строка, состоящая полностью из двух символов дефиса («-», десятичное значение 45), за которыми следует значение параметра границы из поля заголовка Content-Type, необязательный линейный пробел и завершающий CRLF.

  Ограничители границы не должны появляться внутри инкапсулированного материала и должны быть не длиннее 70 символов, не считая двух ведущих дефисов.

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

Вот пример использования произвольной границы:

Content-Type: multipart/form-data; charset=utf-8; boundary="another cool boundary"

--another cool boundary
Content-Disposition: form-data; name="foo"

bar
--another cool boundary
Content-Disposition: form-data; name="baz"

quux
--another cool boundary--

Answer 3

multipart / form-data содержит border для разделения пар имя / значение.Граница действует как маркер каждого куска пар имя / значение, переданных при отправке формы.Граница автоматически добавляется к типу содержимого заголовка запроса.

Форма с атрибутом enctype = "multipart / form-data" будет иметь заголовок запроса Content-Type: multipart / form-data;border --- WebKit193844043-h ( vaue, сгенерированный браузером ).

Переданная полезная нагрузка выглядит примерно так:

Content-Type: multipart/form-data; boundary=---WebKitFormBoundary7MA4YWxkTrZu0gW

    -----WebKitFormBoundary7MA4YWxkTrZu0gW
    Content-Disposition: form-data; name=”file”; filename=”captcha”
    Content-Type:

    -----WebKitFormBoundary7MA4YWxkTrZu0gW
    Content-Disposition: form-data; name=”action”

    submit
    -----WebKitFormBoundary7MA4YWxkTrZu0gW--

На стороне веб-службы она используется вФорма @Consumes ("multipart / form-data").

Осторожно, при тестировании веб-службы с помощью Chrome Postman необходимо проверить параметр данных формы (переключатель) и меню "Файл" из раскрывающегося списка для отправки.крепление.Явное предоставление типа содержимого как multipart / form-data приводит к ошибке.Поскольку граница отсутствует, так как она переопределяет запрос curl почтового служащего на сервер с типом контента, добавляя границу, которая прекрасно работает.

См. RFC1341 sec7.2 Multipart Content-Type