Что такое граничный параметр в HTTP-запросе, состоящем из нескольких частей?

Question

Я пытаюсь разработать гаджет для боковой панели, который автоматизирует процесс проверки веб-страницы на предмет изменения моей квоты на передачу. Я почти на этом, но есть один последний шаг, который мне нужен, чтобы заставить его работать: отправка HttpRequest с правильными данными POST на страницу php Используя плагин Firefox, вот как выглядит «Content-Type» заголовка:

Content-Type=multipart/form-data; boundary=---------------------------99614912995

с параметром "border", который выглядит случайным, и POSTDATA это:

POSTDATA =-----------------------------99614912995
Content-Disposition: form-data; name="SOMENAME"

Formulaire de Quota
-----------------------------99614912995
Content-Disposition: form-data; name="OTHERNAME"

SOMEDATA
-----------------------------99614912995--

Я не понимаю, как правильно эмулировать POSTDATA с возвращением загадочного параметра «границы».

Кто-нибудь знает, как я могу решить это?

Answer 1

Процитируем из RFC 1341, раздел 7.2.1 , что я считаю соответствующими битами параметра boundary заголовка Content-Type (для MIME):

Все подтипы "multipart" имеют общий синтаксис ...

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

, а затем уточняет:

Таким образом, типичное многокомпонентное поле заголовка Content-Type может выглядеть следующим образом:

 Content-Type: multipart/mixed; boundary=gc0p4Jq0M2Yt08jU534c0p

Это указывает на то, что объект состоит из нескольких частей, каждая из которых имеет структуру, синтаксически идентичную сообщению RFC 822, за исключением того, что область заголовка может быть полностью пустой, и что каждой части предшествует строка --gc0p4Jq0M2Yt08jU534c0p

На что обратить внимание:

1. Граница инкапсуляции должна появляться в начале строки, то есть после CRLF (перевода строки возврата каретки)
2. За границей должен немедленно следовать либо другой CRLF и поля заголовка для следующей части, либо два CRLF, и в этом случае нет полей заголовка для следующей части (и поэтому предполагается, что это Content- Введите текст / обычный).
3. Границы инкапсуляции не должны появляться внутри инкапсуляций и должны быть не более 70 символов, не считая двух ведущих дефисов.

Последнее, но не менее важное:

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

 --gc0p4Jq0M2Yt08jU534c0p-- 

Я надеюсь, что это поможет кому-то еще в будущем, так как мне пришлось некоторое время бродить, чтобы получить полную картину (пожалуйста, прочитайте необходимые RFC, чтобы получить самое глубокое понимание).

Answer 2

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

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

Answer 3

Фактическая спецификация для multipart / form-data находится в RFC 7578 . Граница определена в Раздел 4.1 .