ПОСТ (HTTP)

В вычислениях , POST — это метод запроса поддерживаемый HTTP, используемый во Всемирной паутине . По своей конструкции метод запроса POST запрашивает, чтобы веб-сервер принял данные, заключенные в теле сообщения запроса, скорее всего, для их хранения. ^{[ 1 ]} Он часто используется при загрузке файла или при отправке заполненной веб-формы .

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

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

Размещение данных

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

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

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

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

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

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

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

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 определяется как нуллипотентный , без побочных эффектов, а идемпотентные операции «не имеют побочных эффектов на второй или будущие запросы». ^{[ 10 ]}^{[ 11 ]} По этой причине веб-сканеры , такие как индексаторы поисковых систем, обычно используют исключительно методы GET и HEAD, чтобы предотвратить выполнение таких действий своими автоматическими запросами.

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

Ссылки

^ Jump up to: ^а ^б Филдинг, Р.; Решке, Дж. (2014). Филдинг, Р.; Решке, Дж. (ред.). «Протокол передачи гипертекста (HTTP/1.1): семантика и содержимое — 4.3.3 POST» . www.tools.ietf.org . дои : 10.17487/RFC7231 . S2CID 14399078 . Проверено 24 июля 2014 г. Метод POST запрашивает, чтобы целевой ресурс обработал представление, включенное в запрос, в соответствии с собственной конкретной семантикой ресурса.
^ Бернерс-Ли, Тим (1998). «Крутые URI не меняются» . W3C . Проверено 17 октября 2012 г.
^ Фридман, Майк (2009). «Использование методов HTTP PUT и DELETE в веб-приложениях» . Проверено 17 октября 2012 г.
^ «Отправка формы» . Спецификация HTML 4.01 . W3C. 1999 . Проверено 17 октября 2012 г.
^ Ригсби, Дэн (2008). «REST и максимальный размер URL» . Архивировано из оригинала 4 ноября 2012 года . Проверено 17 октября 2012 г.
^ «Максимальная длина URL-адреса в Internet Explorer составляет 2048 символов» . Майкрософт.
^ Филдинг, Р.; Решке, Дж. (2014). Филдинг, Р.; Решке, Дж. (ред.). «Протокол передачи гипертекста (HTTP/1.1): семантика и контент – 9.4 Раскрытие конфиденциальной информации в URI» . РФК 7231 . дои : 10.17487/RFC7231 . S2CID 14399078 . Проверено 25 июля 2014 г.
^ Бернерс-Ли, Тим ; Коннолли, Дэн (22 сентября 1995 г.). «Язык гипертекстовой разметки — 2.0 — Формы» . Консорциум Всемирной паутины . Проверено 15 января 2011 г.
^ «Формы в HTML-документах» .
^ Jump up to: ^а ^б Корпела, Юкка (28 сентября 2003 г.). «Методы GET и POST в HTML-формах — в чем разница?» . Технологический университет Тампере . Проверено 15 января 2011 г.
^ RFC 7231, 4.2.1 Безопасные методы

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

Простое определение POST
Глагол POST в спецификации HTTP
«Развертывание хранилища в облачной платформе Google», Учебное руководство для сертифицированного младшего облачного инженера Google Cloud , Wiley, 28 марта 2019 г., стр. 275–308, doi : 10.1002/9781119564409.ch12 , ISBN 9781119564409 , S2CID 241576882

[RFC_def-1] Jump up to: ^а ^б Филдинг, Р.; Решке, Дж. (2014). Филдинг, Р.; Решке, Дж. (ред.). «Протокол передачи гипертекста (HTTP/1.1): семантика и содержимое — 4.3.3 POST» . www.tools.ietf.org . дои : 10.17487/RFC7231 . S2CID 14399078 . Проверено 24 июля 2014 г. Метод POST запрашивает, чтобы целевой ресурс обработал представление, включенное в запрос, в соответствии с собственной конкретной семантикой ресурса.

[2] Бернерс-Ли, Тим (1998). «Крутые URI не меняются» . W3C . Проверено 17 октября 2012 г.

[3] Фридман, Майк (2009). «Использование методов HTTP PUT и DELETE в веб-приложениях» . Проверено 17 октября 2012 г.

[4] «Отправка формы» . Спецификация HTML 4.01 . W3C. 1999 . Проверено 17 октября 2012 г.

[5] Ригсби, Дэн (2008). «REST и максимальный размер URL» . Архивировано из оригинала 4 ноября 2012 года . Проверено 17 октября 2012 г.

[6] «Максимальная длина URL-адреса в Internet Explorer составляет 2048 символов» . Майкрософт.

[7] Филдинг, Р.; Решке, Дж. (2014). Филдинг, Р.; Решке, Дж. (ред.). «Протокол передачи гипертекста (HTTP/1.1): семантика и контент – 9.4 Раскрытие конфиденциальной информации в URI» . РФК 7231 . дои : 10.17487/RFC7231 . S2CID 14399078 . Проверено 25 июля 2014 г.

[8] Бернерс-Ли, Тим ; Коннолли, Дэн (22 сентября 1995 г.). «Язык гипертекстовой разметки — 2.0 — Формы» . Консорциум Всемирной паутины . Проверено 15 января 2011 г.

[9] «Формы в HTML-документах» .

[Korpela-10] Jump up to: ^а ^б Корпела, Юкка (28 сентября 2003 г.). «Методы GET и POST в HTML-формах — в чем разница?» . Технологический университет Тампере . Проверено 15 января 2011 г.

[11] RFC 7231, 4.2.1 Безопасные методы

[ 1 ]

[ 2 ]

[ 3 ]

[ 4 ]

[ 5 ]

[ 6 ]

[ 7 ]

[ 8 ]

[ 9 ]

[ 10 ]

[ 11 ]