В отличие от методов GET и HEAD, которые используются для извлечения информации, метод POST применяется главным образом для модификации имеющегося ресурса или передачи данных обрабатывающему их процессу. Тело запроса содержит данные. Метод POST может изменять содержимое ресурса, поэтому не может считаться безопасным методом. Поскольку побочные эффекты множества идентичных запросов могут отличаться, метод POST не является идемпотентным методом.
Однако надо уточнить, что безопасность метода POST полностью находится в руках разработчика сайта. Инициирование процесса изменения ресурса происходит при помощи программы, которую должен написать разработчик. Если на сайте не существует никакого процесса, который бы принимал и обрабатывал POST-данные, то они будут просто игнорироваться. В этом случае POST-запрос никак не может повлиять на безопасность ресурса и всего сайта.
Для запроса методом POST обязательны два заголовка содержимого:
Content-Length
НТТР/1.0 требовал наличия корректного поля
Но это лишь стандарт. Если какая-либо реализация протокола HTTP/1.1 потребует обязательного наличия этого заголовка в POST-запросах, то это не будет нарушением протокола. Так например, самый популярный на сегодняшний день сервер Apache, требует наличия заголовка
Content-Type
Этот заголовок информирует сервер о типе содержимого POST-запроса. Основным способом отправки POST-запроса служит HTML-форма, тип содержимого которой указывается в свойстве enctype:
При отправке формы значение свойства enctype записывается в заголовок запроса Content-Type. В HTML у свойства enctype определено два возможных значения:
application/x-www-form-urlencoded
Этот тип содержимого POST-запроса представляет данные в виде URL-кодированной строки POST-параметров.
Параметры отделяются друг от друга знаком "&", а имя и значение параметра разделены знаком "=". Строка так называемых POST-параметров ничем не отличается от строки GET-параметров. Все зависит от места ее расположения. Если она включена в конец URL после знака "?", то ее называют строкой GET-параметров. Если она включена в тело POST-запроса, то ее называют строкой POST-параметров. Единственное и весьма важное различие между ними является следствием ограничения длины URL: на строку GET-параметров накладывается ограничение по длине, чего нет в отношении строки POST-параметров.
К строке POST-параметров может быть применено URL-кодирование. Оно заключается в представлении символа в его 16-тиричном коде с ведущим символом "%". URL-кодирование применяется в отношении не ASCII символов, а так же в отношении специальных символов, чтобы нивелировать их особое назначение. Дополнительно о URL-кодированной строке параметров вы можете прочитать в статье метод GET
multipart/form-data
Этот тип позволяет передавать данные, разбитые на части, каждая из которых может относится к различным типам данных. Этот способ передачи данных незаменим при передаче файлов. Правила оформления тела запроса данного типа несколько сложнее, чем
Заголовок Content-Type должен содержать параметр boundary, необходимый только для типов данных multipart. Этот параметр содержит в себе разделитель частей данных. Это должна быть уникальная строка из ASCII символов, которая не встречается в самих данных. Значение параметра может не браться в кавычки, если строка не содержит специальных символов.
После заголовков, как и положено, следует пустая строка, а далее следует первый разделитель. Разделитель всегда начинается с двух тире "--", а затем следует строка из параметра boundary.
После разделителя могут идти HTTP заголовки содержимого, относящиеся к текущей части данных. Это, прежде всего
То, как здесь применяется заголовок Content-Disposition описано только в стандарте RFC 2388. В документе RFC 2183, описывающем заголовок
В случае передачи файла добавляется заголовок
После строк заголовков, как и положено, идет пустая строка и далее следуют сами данные. После данных идет очередной разделитель.
Завершающий разделитель оканчивается, в отличие от обычных разделителей, двумя тире "--". После завершающего разделителя идет, так называемый, эпилог. По стандарту протокола HTTP, эпилог должен быть пустым. Поэтому после завершающего разделителя обязательно следует пустая строка.
POST-параметры в PHP
В зависимости от значения заголовка
Кэширование POST-запросов
Метод POST является неидемпотентным методом. Это значит, что для последовательности идентичных запросов ответы могут различаться. Это связано с тем, что запрос обрабатывается программой и ее логика никак не регламентирована в протоколе HTTP/1.1
Например, когда вы авторизуетесь на каком-либо сайте, Вы отправляете POST запрос с логином и паролем учетной записи. Если авторизация прошла успешно, то при повторной отправке того же запроса Вам может быть возвращен другой ответ, в котором будет сообщаться, что Вы уже авторизованы.
Поэтому кешировать POST запросы нет никакого смысла. В стандарте RFC 2616 написано, что ответы на POST-запросы не кэшируются, за исключением ответов с соответствующими инструкциями в заголовках
фтщт
Спс реально помог. С прогой мучался…
евгений
Ни разрешил я проблему для разблокировки одноклассников
Миша
Ну и хер с ними. Одноклассники это вообще отстой. Соцсеть для быдла.
Переходи Вконтакт.
Любовь
Инструкция по ссылки .Как это делается? Не могу разблокировать свою страничку? Варианты есть как это делается???
Автор
Прочитайте вот этот комментарий http://www.http11.ru/post.php?post=6#comm90. Наверняка у вас тоже самое.
Анатолий
А как же multipart/form-data?
Автор
Да все собираюсь описать этот формат передачи данных. Пока руки не дошли.