Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску
Эта статья о методе HTTP. Его не следует путать с самотестированием при включении .
HTTP
Способы запроса
Поля заголовка
Коды состояния
Методы управления безопасным доступом
Уязвимости безопасности

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

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

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

Публикация данных [ править ]

Всемирная паутина и HTTP основаны на нескольких методах запросов или «глаголах», включая POST и GET, а также PUT, DELETE и некоторые другие. Веб-браузеры обычно используют только GET и POST, но онлайн- приложения RESTful используют многие другие. Место POST в диапазоне методов HTTP заключается в отправке на сервер представления нового объекта данных, чтобы он был сохранен как новый подчиненный ресурс, идентифицированный URI . [1] Например, для URIhttp://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-адресах и строках запроса может значительно увеличить их длину, и хотя 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] символов.

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

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

Ссылки [ править ]

  1. ^ a b «Протокол передачи гипертекста (HTTP / 1.1): семантика и контент - 4.3.3 POST» . Проверено 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 символов» . Microsoft.
  7. ^ «Протокол передачи гипертекста (HTTP / 1.1): семантика и контент - 9.4 Раскрытие конфиденциальной информации в URI» . RFC 7231 . Проверено 25 июля 2014 .
  8. ^ Бернерс-Ли, Тим ; Коннолли, Дэн (22 сентября 1995 г.). «Язык разметки гипертекста - 2.0 - Формы» . Консорциум World Wide Web . Проверено 15 января 2011 года .
  9. ^ «Формы в HTML-документах» .
  10. ^ a b Корпела, Юкка (28 сентября 2003 г.). «Методы GET и POST в HTML-формах - в чем разница?» . Технологический университет Тампере . Проверено 15 января 2011 года .
  11. ^ RFC 7231, 4.2.1 Безопасные методы

Внешние ссылки [ править ]

  • Прямое определение POST
  • Глагол POST в спецификации HTTP
  • URI, адресуемость и использование HTTP GET и POST [1]
  1. ^ «Развертывание хранилища в Google Cloud Platform», Учебное руководство сертифицированного специалиста по облачным технологиям Google Cloud , Wiley, 2019-03-28, стр. 275–308, doi : 10.1002 / 9781119564409.ch12 , ISBN 9781119564409