POST (HTTP) - POST (HTTP)
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/customers
http://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, может стать очень длинной, особенно из-за процентного кодирования .
использованная литература
внешние ссылки
- Прямое определение POST
- Глагол POST в спецификации HTTP
- «Развертывание хранилища в Google Cloud Platform», Учебное пособие для сертифицированного специалиста по облачным технологиям, сертифицированного Google Cloud , Wiley, 28 марта 2019 г., стр. 275–308, doi : 10.1002 / 9781119564409.ch12 , ISBN 9781119564409