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

Ответ 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-данных, отправленных на сервер.

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

Ответ 2

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

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

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

Несколько релевантных выписок из RFC2046:

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

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

• 5,1. Тип многостраничного носителя

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

  В поле Content-Type для многочастных объектов требуется один параметр "граница". Линия пограничного разделителя затем определяется как строка, состоящая всего из двух дефисных символов ( "-", десятичное значение 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--

Ответ 3

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

Форма с атрибутом 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.