POST (HTTP)

Материал из Википедии — свободной энциклопедии
Перейти к: навигация, поиск

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

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

Посылаемые данные[править | править исходный текст]

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

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

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

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

Использование для представления веб-форм[править | править исходный текст]

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

Например, Name: Jonathan Doe Age: 23 Formula: a + b == 13 %!

будет закодировано как Name=Jonathan+Doe&Age=23&Formula=a+%2B+b+%3D%3D+13 %25%21

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

Влияние на состояние сервера[править | править исходный текст]

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

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

Ссылки[править | править исходный текст]

Ссылки[править | править исходный текст]