POST — HTTP | MDN
HTTP-метод POST
предназначен для отправки данных на сервер. Тип тела запроса указывается в заголовке Content-Type
.
Разница между PUT
и POST
состоит в том, что PUT
является идемпотентным: повторное его применение даёт тот же результат, что и при первом применении (то есть у метода нет побочных эффектов), тогда как повторный вызов одного и того же метода POST
может иметь такие эффекты, как например, оформление одного и того же заказа несколько раз.
Запрос POST
обычно отправляется через форму HTML и приводит к изменению на сервере. element or the formenctype attribute of the <input> or <button> elements:»>В этом случае тип содержимого выбирается путём размещения соответствующей строки в атрибуте enctype
элемента <form>
или formenctype
атрибута элементов <input>
или
:
application/x-www-form-urlencoded
: значения кодируются в кортежах с ключом, разделённых символом'&'
, с'='
между ключом и значением. Не буквенно-цифровые символы — percent encoded: это причина, по которой этот тип не подходит для использования с двоичными данными (вместо этого используйтеmultipart/form-data
)multipart/form-data
: каждое значение посылается как блок данных («body part»), с заданными пользовательским клиентом разделителем («boundary»), разделяющим каждую часть. Эти ключи даются в заголовкиContent-Disposition
каждой частиtext/plain
Когда запрос POST
отправляется с помощью метода, отличного от HTML-формы, — например, через XMLHttpRequest
— тело может принимать любой тип. Как описано в спецификации HTTP 1.1, POST
предназначен для обеспечения единообразного метода для покрытия следующих функций:
- Аннотация существующих ресурсов
- Публикация сообщения на доске объявлений, в новостной группе, в списке рассылки или в аналогичной группе статей;
- Добавление нового пользователя посредством модальности регистрации;
- Предоставление блока данных, например, результата отправки формы, процессу обработки данных;
- Расширение базы данных с помощью операции добавления.
Запрос имеет тело | Да |
---|---|
Успешный ответ имеет тело | Да |
Безопасный | Нет |
Идемпотентный | Нет |
Кешируемый | Только если включена информация о свежести сообщения |
Допускается в HTML-формах | Да |
POST /index.html
Простая форма запроса, используя стандартный application/x-www-form-urlencoded
POST / HTTP/1.1 Host: foo.com Content-Type: application/x-www-form-urlencoded Content-Length: 13 say=Hi&to=Mom
Форма запроса, используя multipart/form-data
content type:
POST /test.html HTTP/1.1 Host: example.org Content-Type: multipart/form-data;boundary="boundary" --boundary Content-Disposition: form-data; name="field1" value1 --boundary Content-Disposition: form-data; name="field2"; filename="example. txt" value2 --boundary--
Specification |
---|
HTTP Semantics # POST |
BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.
Content-Type
Content-Disposition
- GET
Found a content problem with this page?
- Edit the page on GitHub.
- Report the content issue.
- View the source on GitHub.
Want to get more involved?
Learn how to contribute.
This page was last modified on by MDN contributors.
php — Где в post-запросе передаются параметры?
Вопрос задан
Изменён 5 лет 7 месяцев назад
Просмотрен 32k раз
В стандарте HTTP есть 3 составляющие: стартовая строка, заголовки и тело.
Когда отправляю GET-запрос, то все параметры идут вместе с URI. Например
GET /index.php?name='myname'&age=26 HTTP/1.1
А когда я передаю те же самые данные, но методом POST, то эти параметры name и age где передаются? В теле запроса? В заголовках? Как выглядит этот HTTP-запрос?
Имеется ввиду чистый HTTP-запрос, как прописано в протоколе.
Если переформулировать вопрос. PHP, когда формирует массив $_POST
, то данные этого массива из какой части HTTP-запроса берет?
В случае с $_GET
все понятно, берет из URI. А с $_POST
неясно.
- php
- http
- post
2
Итак, подытожу всё что тут сказали
GET Передаётся в URL
GET https://example.com/comments?page=2&pageSize=10
POST Передаёт данные в теле
POST https://example.com/comments HTTP/1.1 content-type: application/json { "name": "sample", "time": "Wed, 21 Oct 2015 18:27:50 GMT" }
Заголовок content-type определяет как данные будут переданы (JSON или кодированы url-encoded) таким образом сервер поймёт как их обработать.
На заметку:
GET
- Могут кэшироваться
- Остаются в истории браузера
- Могут быть/стать «закладкой»
- Не должны использоваться для передачи паролей и всего такого
- Имеют ограничение по длине (URL и в некоторых браузерах свои заморочки)
POST
- Никогда не кэшируются
- Не остаются в истории браузера
- Не могут быть/стать «закладкой»
- Не имеют таких ограничений по длине (обычно в браузерах и на web серверах есть ограничение по умолчанию)
3
Данные POST запроса передаются в теле. То есть стартовая строка, потом заголовки, пустая строчка, а дальше идут параметры POST. Часто в формате url-encoded (formdata) — это как в адресной сроке у GET запроса, но в последнее время есть тенденция передавать в теле json. Формат кодировки запроса определяется по заголовку Content-encoding.
А когда я передаю те же самые данные, но методом POST, то как выглядит этот http-запрос?
Очень удобно использовать утилиту nc для отладки текстовых протоколов. Запустите её с флагом -l
с указанием порта, который она будет прослушивать, и выполните свой POST-запрос на
в соседнем терминале.
nc -l 8080 curl http://localhost:8080/index.php -d name=myname -d age=26
Вы увидите примерно следующее
POST /index.php HTTP/1.1 Host: localhost:8080 User-Agent: curl/7.47.0 Accept: */* Content-Length: 18 Content-Type: application/x-www-form-urlencoded name=myname&age=26
Зарегистрируйтесь или войдите
Регистрация через Google
Регистрация через Facebook
Регистрация через почту
Отправить без регистрации
Почта
Необходима, но никому не показывается
Отправить без регистрации
Почта
Необходима, но никому не показывается
Нажимая на кнопку «Отправить ответ», вы соглашаетесь с нашими пользовательским соглашением, политикой конфиденциальности и политикой о куки
POST-HTTP | MDN
POST
отправляет данные на сервер. Тип тела запроса указывается заголовком Content-Type
. Разница между PUT
и POST
заключается в том, что PUT
является идемпотентным: вызов его один или несколько раз подряд имеет тот же эффект (то есть не побочный эффект ), тогда как последовательные идентичные POST
могут иметь дополнительные эффекты, такие как передача заказа несколько раз.
Запрос POST
обычно отправляется через HTML-форму и приводит к изменению на сервере. В этом случае тип содержимого выбирается путем помещения соответствующей строки в атрибут
элемента или в атрибут
formenctype
элементов
или
:
-
application/x-www-form-urlencoded
: ключи и значения закодированы в кортежах ключ-значение, разделенных'&'
, с'='
между ключом и значением. Небуквенно-цифровые символы как в ключах, так и в значениях закодированы в URL: по этой причине этот тип не подходит для использования с двоичными данными (вместо этого используйтеmultipart/form-data
) -
multipart/form-data
: каждое значение отправляется как блок данных («часть тела») с разделителем, определяемым агентом пользователя («граница»), разделяющим каждую часть. Ключи указаны в заголовкеContent-Disposition
каждой части. -
текстовый/обычный
Когда запрос POST
отправляется с помощью метода, отличного от HTML-формы, например, через XMLHttpRequest
, тело может принимать любой тип. Как описано в спецификации HTTP 1.1, POST
предназначен для обеспечения единого метода для следующих функций:
- Аннотации существующих ресурсов
- Публикация сообщения на доске объявлений, в группе новостей, в списке рассылки или в аналогичной группе статей;
- Добавление нового пользователя через модальное окно регистрации;
- Предоставление блока данных, например, результата отправки формы, в процесс обработки данных;
- Расширение базы данных с помощью операции добавления.
Запрос имеет тело | Да |
---|---|
Успешный ответ имеет тело | Да |
Сейф | № |
Идемпотент | № |
Кэшируемый | Только если включена информация о свежести |
Разрешено в формах HTML | Да |
ПОСТ/тест
Простая форма с использованием стандартного application/x-www-form-urlencoded
типа контента:
POST /test HTTP/1. 1 Хост: foo.example Content-Type: application/x-www-form-urlencoded Длина контента: 27 поле1=значение1&поле2=значение2
Форма с типом содержимого multipart/form-data
:
POST /test HTTP/1.1 Хост: foo.example Content-Type: multipart/form-data;boundary="boundary" --граница Content-Disposition: данные формы; имя = "поле1" значение1 --граница Content-Disposition: данные формы; имя="поле2"; имя_файла="example.txt" значение2 --граница--
Спецификация |
---|
Семантика HTTP # POST |
Таблицы BCD загружаются только в браузере с включенным JavaScript. Включите JavaScript для просмотра данных.
-
Тип содержимого
-
Контент-Расположение
-
ПОЛУЧИТЬ
Обнаружили проблему с содержанием этой страницы?
- Отредактируйте страницу на GitHub.
- Сообщить о проблеме с содержимым.
- Посмотреть исходный код на GitHub.
Хотите принять больше участия?
Узнайте, как внести свой вклад.
Последний раз эта страница была изменена участниками MDN.
Как передаются параметры в запросе HTTP POST?
Краткий ответ: в POST-запросах значения отправляются в «теле» запроса. С веб-формами они, скорее всего, отправляются с типом носителя application/x-www-form-urlencoded
или multipart/form-data
. Языки программирования или фреймворки, которые были разработаны для обработки веб-запросов, обычно поступают правильно с такими запросами и предоставляют вам легкий доступ к легко декодируемым значениям (например, 9).0004 $_REQUEST или $_POST
в PHP или cgi.FieldStorage()
, flask. request.form
в Python).
Теперь давайте немного отвлечемся, это может помочь понять разницу 😉
Разница между запросами GET
и POST
в основном семантическая. Они также «используются» по-разному, что объясняет разницу в том, как передаются значения.
При выполнении запроса GET
вы запрашиваете у сервера один или набор объектов. Чтобы позволить клиенту фильтровать результат, он может использовать так называемую «строку запроса» URL-адреса. Строка запроса — это часть после ?
. Это часть синтаксиса URI.
Итак, с точки зрения кода вашего приложения (часть, которая получает запрос), вам нужно будет проверить часть запроса URI, чтобы получить доступ к этим значениям.
Обратите внимание, что ключи и значения являются частью URI. Браузеры могут налагать ограничение на длину URI. Стандарт HTTP гласит, что ограничений нет. Но на момент написания этой статьи большинство браузеров и ограничивают URI (у меня нет конкретных значений). Запросы GET
должны никогда не использоваться для отправки новой информации на сервер. Особенно не большие документы. Вот где вы должны использовать POST
или PUT
.
При выполнении запроса POST
клиент фактически отправляет новый документ на удаленный хост. Таким образом, строка запроса не имеет (семантического) смысла. Вот почему у вас нет доступа к ним в коде вашего приложения.
ПОСТ
немного сложнее (и способ более гибкий):
При получении запроса POST вы всегда должны ожидать «полезную нагрузку» или, в терминах HTTP: тело сообщения. Тело сообщения само по себе довольно бесполезно, так как нет стандартного формата (насколько я могу судить. Может быть, application/octet-stream?). Формат тела определяется заголовком Content-Type
. При использовании элемента HTML FORM
с method="POST"
это обычно приложение/x-www-form-urlencoded
. Другим очень распространенным типом является multipart/form-data, если вы используете загрузку файлов. Но это может быть что угодно , начиная от text/plain
, более application/json
или даже пользовательского application/octet-stream
.
В любом случае, если запрос POST
сделан с Content-Type
, который не может быть обработан приложением, он должен вернуть код состояния 415
.
Большинство языков программирования (и/или веб-фреймворков) предлагают способ декодирования/декодирования тела сообщения из/в наиболее распространенные типы (например, application/x-www-form-urlencoded
, multipart/form-data
или application/json
). Так что это легко. Пользовательские типы потенциально требуют немного больше работы.
Используя в качестве примера документ, закодированный в стандартной форме HTML, приложение должно выполнить следующие шаги:
- Считать поле
Content-Type
- Если значение не является одним из поддерживаемых медиа-типов, верните ответ с кодом состояния
415
- , в противном случае декодировать значения из тела сообщения.
Опять же, такие языки, как PHP, или веб-фреймворки для других популярных языков, вероятно, справятся с этим за вас. Исключением является ошибка 415
. Ни один фреймворк не может предсказать, какие типы контента ваше приложение будет поддерживать и/или не поддерживать. Это зависит от вас.
Запрос PUT
обрабатывается точно так же, как запрос POST
. Большая разница в том, что Запрос POST
должен позволить серверу решить, как (и если вообще) создать новый ресурс. Исторически (из устаревшего RFC2616 нужно было создать новый ресурс как «подчиненный» (дочерний) URI, на который был отправлен запрос).
Запрос PUT
, напротив, должен «депонировать» ресурс ровно по адресу этого URI, а с ровно по этому контенту. Не больше, не меньше. Идея состоит в том, что клиент отвечает за создание завершить ресурс , прежде чем «PUTting» его. Сервер должен принять его как есть по данному URL-адресу.
Как следствие, запрос POST
обычно не используется для замены существующего ресурса. Запрос PUT
может выполнять как создание , так и замену .
Существуют также «параметры пути», которые можно использовать для отправки дополнительных данных на удаленный компьютер, но они настолько необычны, что я не буду вдаваться в подробности. Но, для справки, вот выдержка из RFC:
Помимо точечных сегментов в иерархических путях, сегмент пути считается непрозрачный по общему синтаксису. Приложения, создающие URI, часто используют зарезервированные символы, разрешенные в сегменте для разграничения конкретных схем или подкомпоненты, специфичные для обработчика разыменования. Например, точка с запятой («;») и равно («=») зарезервированные символы часто используются для разделения параметров и значения параметров, применимые к этому сегменту. Запятая («,») зарезервирована характер часто используется для аналогичных целей. Например, один производитель URI может использовать такой сегмент, как «name;v=1.