POST (HTTP) - POST (HTTP)

В вычислениях , POST является метод запроса поддерживается HTTP , используемый World Wide Web . По замыслу метод запроса POST требует, чтобы веб-сервер принял данные, заключенные в теле сообщения запроса, скорее всего, для их сохранения. Он часто используется при загрузке файла или при отправке заполненной веб-формы .

Напротив, метод запроса HTTP GET получает информацию с сервера. В рамках запроса GET некоторые данные могут быть переданы в строке запроса URL-адреса с указанием (например) условий поиска, диапазонов дат или другой информации, определяющей запрос.

В рамках запроса POST произвольный объем данных любого типа может быть отправлен на сервер в теле сообщения запроса. Поле заголовка в запросе POST обычно указывает на тип интернет - СМИ тела сообщения.

Публикация данных

Всемирная паутина и HTTP основаны на нескольких методах запросов или «глаголах», включая POST и GET, а также PUT, DELETE и некоторые другие. Веб-браузеры обычно используют только GET и POST, но онлайн- приложения RESTful используют многие другие. Место POST в диапазоне HTTP-методов заключается в отправке на сервер представления нового объекта данных, чтобы он был сохранен как новый подчиненный ресурс, идентифицированный URI . Например, для URI запросы POST могут представлять новых клиентов, каждый из которых включает их имя, адрес, контактные данные и так далее. Первые дизайнеры веб-сайтов отклонились от этой первоначальной концепции по двум важным причинам. Во-первых, нет никаких технических причин для URI для текстового описания веб-ресурса, подчиненного которому будут храниться данные POST. Фактически, если не будут предприняты некоторые усилия, последняя часть URI, скорее всего, будет описывать страницу обработки веб-приложения и ее технологию, например . Во-вторых, учитывая естественное ограничение большинства веб-браузеров на использование только GET или POST, дизайнеры почувствовали необходимость переназначить POST для выполнения многих других задач по отправке данных и управлению данными, включая изменение существующих записей и их удаление. http://example.com/customershttp://example.com/applicationform.php

Попытки некоторых влиятельных авторов исправить первую проблему начались еще в 1998 году. Фреймворки веб-приложений, такие как Ruby on Rails и другие, облегчают дизайнерам предоставление своим пользователям семантических URL-адресов . Что касается второго пункта, можно использовать сценарии на стороне клиента или писать автономные приложения, чтобы использовать другие методы HTTP, где они актуальны, но за пределами этого большинство веб-форм, которые отправляют или изменяют данные сервера, продолжают использовать POST для этой цели.

Это не означает, что каждая веб-форма должна указывать method="post"в открывающем теге . Многие формы используются для более точного определения получения информации с сервера без какого-либо намерения изменять основную базу данных. Формы поиска, например, идеально подходят для method="get"указания.

Бывают случаи, когда HTTP GET менее подходит даже для извлечения данных. Примером этого является ситуация, когда в URL-адресе необходимо указать большой объем данных. Браузеры и веб-серверы могут иметь ограничения на длину URL-адреса, который они будут обрабатывать без усечения или ошибок. Процентное кодирование зарезервированных символов в URL-адресах и строках запроса может значительно увеличить их длину, и хотя HTTP-сервер Apache может обрабатывать до 4000 символов в URL-адресе, Microsoft Internet Explorer ограничен 2048 символами в любом URL-адресе. Точно так же HTTP GET не следует использовать, когда конфиденциальная информация, такая как имена пользователей и пароли, должна быть отправлена ​​вместе с другими данными для выполнения запроса. Даже если используется HTTPS , предотвращающий перехват данных при передаче, история браузера и журналы веб-сервера, скорее всего, будут содержать полный URL-адрес в виде открытого текста, который может быть раскрыт, если какая-либо система будет взломана. В этих случаях следует использовать HTTP POST.

Использовать для отправки веб-форм

Когда веб-браузер отправляет запрос POST из элемента веб-формы , типом Интернет-носителя по умолчанию является « application / x-www-form-urlencoded ». Это формат для кодирования пар ключ-значение с возможно повторяющимися ключами. Каждая пара «ключ-значение» отделяется символом «&», а каждый ключ отделяется от своего значения знаком «=». Ключи и значения экранируются заменой пробелов символом «+» и последующим использованием процентного кодирования для всех других не буквенно-цифровых символов.

Например, пары "ключ-значение"

Name: Gareth Wylie
Age: 24
Formula: a+b == 21

закодированы как

Name=Gareth+Wylie&Age=24&Formula=a%2Bb+%3D%3D+21

Начиная с HTML 4.0, формы могут также отправлять данные в формате multipart / form-data, как определено в RFC 2388 (см. Также RFC 1867 для более ранней экспериментальной версии, определенной как расширение HTML 2.0 и упомянутой в HTML 3.2).

Особый случай отправки POST на ту же страницу, к которой принадлежит форма, известен как обратная передача .

Влияние на состояние сервера

Согласно RFC 7231, метод POST не является идемпотентным , что означает, что несколько идентичных запросов могут не иметь того же эффекта, что и передача запроса только один раз. Таким образом, POST подходит для запросов, которые меняют состояние каждый раз, когда они выполняются, например, отправка комментария к сообщению в блоге или голосование в онлайн-опросе. GET определяется как нульпотентный , без побочных эффектов, а идемпотентные операции «не имеют побочных эффектов для второго или будущих запросов». По этой причине веб-сканеры, такие как индексаторы поисковых систем, обычно используют исключительно методы GET и HEAD, чтобы их автоматические запросы не выполняли такие действия.

Однако есть причины, по которым POST используется даже для идемпотентных запросов, особенно если запрос очень длинный. Из-за ограничений URL-адресов строка запроса, генерируемая методом GET, может стать очень длинной, особенно из-за процентного кодирования .

использованная литература

внешние ссылки