ПОСТ (HTTP)

Метод запроса в протоколе 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, скорее всего, будет описывать страницу обработки веб-приложения и ее технологию, например . Во-вторых, учитывая естественное ограничение большинства веб-браузеров, позволяющее использовать только GET или POST, разработчики посчитали необходимым перепрофилировать POST для выполнения многих других задач по отправке и управлению данными, включая изменение существующих записей и их удаление.http://example.com/applicationform.php

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

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

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

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

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

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

Имя: Гарет УайлиВозраст: 24Формула: а+b == 21

кодируются как

Имя=Гарет+Уайли&Возраст=24&Формула=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]

Ссылки

^ ab Fielding, R.; Reschke, J. (2014). Fielding, R.; Reschke, J. (ред.). "Протокол передачи гипертекста (HTTP/1.1): семантика и содержимое - 4.3.3 POST". tools.ietf.org . doi :10.17487/RFC7231. S2CID 14399078 . Получено 24.07.2014 . Метод POST требует, чтобы целевой ресурс обработал представление, заключенное в запросе, в соответствии с собственной конкретной семантикой ресурса.
^ Бернерс-Ли, Тим (1998). "Cool URIs don't change". 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 символов». Microsoft.
^ Филдинг, Р.; Решке, Дж. (2014). Филдинг, Р.; Решке, Дж. (ред.). "Протокол передачи гипертекста (HTTP/1.1): семантика и содержимое - 9.4 Раскрытие конфиденциальной информации в URI". RFC 7231 . doi :10.17487/RFC7231. S2CID 14399078 . Получено 25 июля 2014 г. .
^ Бернерс-Ли, Тим ; Коннолли, Дэн (22 сентября 1995 г.). "Язык гипертекстовой разметки - 2.0 - Формы". Консорциум Всемирной паутины . Получено 15 января 2011 г.
^ «Формы в HTML-документах».
^ ab Korpela, Jukka (28 сентября 2003 г.). "Методы GET и POST в HTML-формах — в чем разница?". Tampere University of Technology . Получено 15 января 2011 г.
^ RFC 7231, 4.2.1 Безопасные методы

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

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

[RFC_def-1] Fielding, R.; Reschke, J. (2014). Fielding, R.; Reschke, J. (ред.). "Протокол передачи гипертекста (HTTP/1.1): семантика и содержимое - 4.3.3 POST". tools.ietf.org . doi :10.17487/RFC7231. S2CID 14399078 . Получено 24.07.2014 . Метод POST требует, чтобы целевой ресурс обработал представление, заключенное в запросе, в соответствии с собственной конкретной семантикой ресурса.

[2] Бернерс-Ли, Тим (1998). "Cool URIs don't change". 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 символов». Microsoft.

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

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

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

[Korpela-10] Korpela, Jukka (28 сентября 2003 г.). "Методы GET и POST в HTML-формах — в чем разница?". Tampere University of Technology . Получено 15 января 2011 г.

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