Яка межа в мультичастинах / формах-даних?

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

Чи ???вільний повинен визначати користувач? Або він генерується з HTML? Чи можна для мене визначити ??? = abcdefg?

Чи ???вільний повинен визначати користувач?

Так.

або це постачається 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, що надсилаються серверу.

• Будьте послідовними та використовуйте однакове значення скрізь у повідомленні запиту.

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

Якщо ви використовуєте один із multipart/*типів вмісту, вам фактично потрібно вказати boundaryпараметр у Content-Typeзаголовку, інакше сервер (у випадку запиту HTTP) не зможе розібрати корисний навантаження.

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

Кілька релевантних уривків з RFC2046 :

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

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

• 5.1. Тип мультимедіа-носія

  Як зазначено у визначенні поля Content-Transfer-Encoding [RFC 2045], жодне кодування, окрім "7bit", "8bit" або "binary", не допускається для об'єктів типу "multipart". "Багаточастинні" граничні роздільники та поля заголовків завжди представлені як 7-бітні US-ASCII в будь-якому випадку (хоча поля заголовка можуть кодувати текст не в заголовку США-ASCII відповідно до RFC 2047), а дані в частинах тіла можуть бути кодовані на по частинах, із полями передачі-кодування вмісту для кожної відповідної частини тіла.

  Поле "Тип вмісту" для багаточастинних об'єктів вимагає одного параметра "межа". Лінія розмежувача кордону потім визначається як рядок, що складається повністю з двох дефісних символів ("-", десяткове значення 45) з подальшим значенням граничного параметра з поля заголовка "Тип вмісту", необов'язкового лінійного пробілу та закінчуючого 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--

multipart / form-data містить межу для розділення пар імен / значень. Межа діє як маркер кожної частини імен / значень пар, переданих при надходженні форми. Межа автоматично додається до типу вмісту заголовка запиту.

Форма з атрибутом enctype = "multipart / form-data" матиме заголовок запиту Content-Type: Contentpart / multi -data-data; межа --- 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 ("багаточастинні / форма-дані").

Остерігайтеся, під час тестування веб-сервісу за допомогою хромованого листоноші потрібно перевірити параметр даних форми (перемикач) та меню Файл у спадному вікні, щоб надіслати вкладення. Явне надання типу вмісту у вигляді багаточастинних / форм-даних призводить до помилки. Оскільки межа відсутня, оскільки вона перекриває запит на вигин поштового чоловіка на сервер із типом контенту, додаючи межу, яка працює добре.

Див. RFC1341, розділ 7.2 Багаточастинковий тип вмісту