Как передавать параметры в post запросе
POST запрос, составное содержимое (multipart/form-data)
Передача составных данных методом POST
В жизни любого программиста попадаются задачки, которые человека цепляют. Вот не нравится стандартный метод решения и все! А порой бывает, что стандартные решения не подходят по какой-то причине. Некоторые люди обходят такие задачи стороной, другие же любят решать их. Можно даже сказать сами их находят. Одна из таких задач отсылка файла или несколько файлов методом POST.
Некоторые наверное скажут, эта задача совсем не задача. Ведь есть замечательная библиотека CURL, которая довольно простая и решает эту задачу легко! Но не спешите. Да, CURL мощная библиотека, да она загружает файлы, но… Как Вы знаете у нее есть маленькая особенность — файл должен быть размещен на жестком диске!
А теперь давайте представим себе такую ситуацию, Вы генерируете динамически файл или же он уже находится в памяти и нужно его отправить методом POST на удаленный Web сервер. Что же тогда получается? Перед его отправкой нужно его сохранить? Да именно так и поступило бы 90% программистов. Зачем искать лишние проблемы, если решение лежит на поверхности? Но мы же с Вами не из этих 90%! Мы же лучше, мы же можем решить любую задачку. Зачем нам лишнее действие? Во-первых, оно задействует не быструю файловую систему жесткого диска. Во-вторых, у нас может и не быть доступа к файловой системе или же там выделено слишком мало места.
Как же нам тогда решить эту задачку? Для этого надо взглянуть как собственно передаются данные методом POST. Единственный вариант решения — это передача файла составным запросом с помощью multipart/form-data. Этот метод хорошо описан в RFC7578. Давайте взглянем как будет выглядеть тело POST запроса multipart/form-data:
Наше тело состоит из двух частей, в первой части мы передаем значение поля формы name=«field» равное: text. Во второй части мы передаем поле name=«file» с содержимым файла filename=«sample.txt»: Content file. В заголовке мы указываем формат содержимого POST запроса — Content-Type: multipart/form-data, строку разделитель составных частей: boundary=————-573cf973d5228 и длину сообщения — Content-Length: 288.
Осталось, собственно, написать программу реализующий этот метод. Так как мы люди умные и не пишем по сто раз одно и тоже в разных проектах, то оформим все в виде класса реализующий этот метод. Плюс к этому, расширим его для разных вариантов отправки как файлов, так и простых элементов формы. А что бы отличить среди массива POST данных, наличие файла, создадим отдельный файл — контейнер с содержимым файла и его данных (имя и расширение). Таким образом он будет выглядеть следующим образом:
Теперь собственно сам класс по формированию тела multipart/form-data для POST запроса:
Данный класс состоит из нескольких методов. Метод — PartPost формирует отдельные части составного запроса, а метод — Get объединяет эти части и формирует тело POST запроса в формате — multipart/form-data.
Теперь у нас есть универсальный класс для отправки тела POST запроса. Осталось написать программу использующую данный класс для отправки файлов на удаленный Web сервер. Воспользуемся библиотекой CURL:
Если CURL не подходит, то данную библиотеку можно применить и для отправки через сокеты. Ну и собственно ссылки на источники:
Как параметры отправляются в HTTP-запрос POST?
В запросе HTTP GET параметры отправляются как строка запроса :
В запросе HTTP POST параметры не отправляются вместе с URI.
Где значения? В заголовке запроса? В теле запроса? Как это выглядит?
ОТВЕТЫ
Ответ 1
Значения отправляются в тело запроса в формате, указанном типом содержимого.
Ответ 2
Содержимое помещается после заголовков HTTP. Формат HTTP POST должен состоять из заголовков HTTP, за которыми следует пустая строка, за которой следует тело запроса. Переменные POST хранятся в виде пар ключ-значение в теле.
Это можно увидеть в исходном содержимом HTTP-сообщения, показанного ниже:
Вы можете увидеть это с помощью инструмента, такого как Fiddler, который вы можете использовать для просмотра необработанных запросов HTTP-запроса и ответа, передаваемых по проводке.
Ответ 3
Теперь отпустите немного, что может помочь понять разницу;)
Разница между запросами GET и POST в значительной степени семантична. Они также «используются» по-разному, что объясняет разницу в том, как передаются значения.
GET (соответствующий раздел RFC)
Итак, с точки зрения вашего кода приложения (части, которая получает запрос) вам нужно будет проверить часть запроса URI, чтобы получить доступ к этим значениям.
POST (соответствующий раздел RFC)
При выполнении запроса POST клиент фактически отправляет новый документ удаленному хосту. Таким образом, строка запроса не (семантически) имеет смысл. Вот почему у вас нет доступа к ним в вашем коде приложения.
POST немного сложнее (и более гибким):
Используя стандартный HTML-документ, закодированный в качестве примера, приложение должно выполнить следующие шаги:
PUT (соответствующий раздел RFC)
A PUT запрос, напротив, должен «откладывать» ресурс именно в этом URI и именно с этим контентом. Не больше, не меньше. Идея заключается в том, что клиент несет ответственность за создание полного ресурса до «PUTting». Сервер должен принять его как есть на заданном URL.
Как следствие, запрос POST обычно не используется для замены существующего ресурса. Запрос PUT может создавать и заменять.
Side-Note
Также есть » параметры пути», которые могут использоваться для отправки дополнительных данных на пульт, но они настолько необычны, что я выиграл Здесь не слишком подробно. Но, для справки, вот отрывок из RFC:
Помимо точечных сегментов в иерархических путях рассматривается сегмент пути непрозрачный по обобщенному синтаксису. URI-приложения часто используют зарезервированные символы, разрешенные в сегменте для разграничения схемы или подкомпоненты, специфичные для разыменования. Например, точка с запятой ( «;» ) и equals ( «=» ) зарезервированные символы часто используются для разграничения параметров и значения параметров, применимые к этому сегменту. Запятая ( «,» ) зарезервирована характер часто используется для аналогичных целей. Например, один производитель URI может использовать сегмент, такой как «name; v = 1.1», чтобы указать ссылку на версию 1.1 «name», тогда как другой может использовать сегмент, такой как «name, 1.1» to указывают на то же самое. Типы параметров могут определяться по схеме семантика, но в большинстве случаев синтаксис параметра специфичен для реализация алгоритма разыменования URI.
Ответ 4
Вы не можете ввести его прямо в строке URL браузера.
Вы можете увидеть, как данные POST отправляются в Интернете с помощью Live HTTP Headers. Результат будет что-то вроде этого
будут значениями post.
Ответ 5
Это помещается в тело запроса после заголовков HTTP.
Ответ 6
Некоторые веб-службы требуют, чтобы вы размещали данные запроса и метаданные отдельно. Например, удаленная функция может ожидать, что подписанная строка метаданных будет включена в URI, а данные будут отправляться в HTTP-корпусе.
Запрос POST может семантически выглядеть следующим образом:
Обратите внимание: HTTP/1.1 заключен в #32 (пробел) слева и #10 (строка) справа.
Ответ 7
Значения форм в HTTP-POST-сообщениях отправляются в тело запроса в том же формате, что и запрос.
Для получения дополнительной информации см. spec.
Ответ 8
Прежде всего, давайте сделаем различие между GET и POST
POST: Он используется для безопасной отправки данных на сервер, поэтому все, что нужно, это формат запроса POST
Почему POST более GET?
теперь вопрос безопасности не совсем верен только для HTTP, данные в теле не обязательно очень безопасны, если они не зашифрованы с использованием протокола HTTP.
Вы можете использовать сетевой раздел Инструментов Google для разработчиков, чтобы просмотреть основную информацию о том, как запросы поступают на серверы.
Ответ 9
Чтобы добавить дополнительную информацию, ниже также поможет выяснить различия.
Я использовал Java в качестве HTTP-клиента, чтобы показать формирование запроса GET и POST. Комментарии для описания заявления.
HTTP-запрос методом POST.
Кроме метода GET, который мы рассмотрели в предыдущей заметке, существует еще один метод отправки запроса по протоколу HTTP – метод POST. Метод POST тоже очень часто используется на практике.
Если, для того, чтобы обратиться к серверу методом GET, нам достаточно было набрать запрос в URL-адрес, то в методе POST все работает по другому принципу.
Для того, чтобы выполнить этот вид запроса, нам необходимо нажать на кнопку с атрибутом type=»submit», которая расположена на веб-странице. Обратите внимание, что эта кнопка расположена в элементе
Если пользователь введет в текстовое поле какой-либо текст и нажмет на кнопку «Отправить», то на сервер будет отправлена переменная text со значением того содержимого, которое ввел пользователь. Эта переменная будет отправлена методом POST.
Если в форме написать так:
То данные будут отправляться методом GET.
Если, в случае с GET-запросом, объем данных, которые мы могли передать ограничивался длиной адресной строки браузера, то в случае с запросом POST, такого ограничения нет, и мы можем передавать значительные объемы информации.
Еще одно отличие метода POST от GET, метод POST скрывает все передаваемые им переменные и их значения, в своём теле (Entity-Body). В случае с методом GET они хранились в строке запроса (Request-URI).
Вот пример запроса, выполненного методом POST:
Таким образом, передавая данные методом POST, их будет намного труднее перехватить злоумышленнику, т.к. они скрыты от непосредственного просмотра, поэтому метод передачи данных методом POST считается более безопасным способом.
Кроме того, методом POST можно передавать не только текст, но и мультимедиа данные (картинки, аудио, видео). Существует специальный параметр Content-Type, который определяет тот вид информации, который необходимо передать.
Ну и, наконец, чтобы на сервере получить данные, которые были переданы этим методом, используется переменная POST.
Вот пример обработки на языке PHP:
Все мои уроки по серверному программированию здесь.
POST-запросы
URL запроса
Имя пользователя. Должно совпадать с логином в Яндекс.Паспорте, заданным при регистрации.
Значение API-ключа, выданного при регистрации.
Правило фильтрации результатов поиска (исключение из результатов поиска документов в соответствии с одним из правил). Возможные значения:
Если параметр не задан, используется умеренная фильтрация.
Идентификатор страны или региона поиска. Определяет правила ранжирования документов. Например, если передать в данном параметре значение «11316» (Новосибирская область), при формировании результатов поиска используется формула, определенная для Новосибирской области.
Список идентификаторов часто используемых стран и регионов приведен в приложении.
Возможные значения зависят от используемого типа поиска:
Инициирует проверку пользователя для возможной защиты от роботов.
Имя пользователя. Должно совпадать с логином в Яндекс.Паспорте, заданным при регистрации.
Значение API-ключа, выданного при регистрации.
Правило фильтрации результатов поиска (исключение из результатов поиска документов в соответствии с одним из правил). Возможные значения:
Если параметр не задан, используется умеренная фильтрация.
Идентификатор страны или региона поиска. Определяет правила ранжирования документов. Например, если передать в данном параметре значение «11316» (Новосибирская область), при формировании результатов поиска используется формула, определенная для Новосибирской области.
Список идентификаторов часто используемых стран и регионов приведен в приложении.
Возможные значения зависят от используемого типа поиска:
Инициирует проверку пользователя для возможной защиты от роботов.