Какова граница в 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 параметр в Content-Type заголовок, в противном случае сервер (в случае HTTP-запроса) не сможет проанализировать полезную нагрузку.

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

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

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

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

• 5.1. Multipart Media Type

  Как указано в определении поля Content-Transfer-Encoding [RFC 2045], для объектов типа "multipart" не допускается никакое кодирование, кроме "7-битных", "8-битных" или "двоичных". "Составные" граничные разделители и поля заголовка всегда представлены как 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 содержит границу для разделения пар имя / значение. Граница действует как маркер каждого куска пар имя / значение, переданных при отправке формы. Граница автоматически добавляется к типу содержимого заголовка запроса.

Форма с атрибутом 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 приводит к ошибке. Потому что border отсутствует, так как он переопределяет запрос curl почтового человека на сервер с типом контента, добавляя границу, которая работает нормально.

См. RFC1341 sec7.2 Multipart Content-Type.

Answer 4

мы должны разделить наши данные. Итак, сервер понимает, что мы отправляем.

1 Пример: мы разделяем данные

      $email = $_POST['email'];
$p_id = $_POST['pid'];

2. Пример: если мы отправляем данные JSON (With) с типом содержимого Multipart / form-data, мы получаем предупреждение, связанное с границей

       $json = file_get_contents("php://input");

Answer 5

использовать это

      headers: {
    'content-type': 'application/x-www-form-urlencoded'
  }

для граничной ошибки