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

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

Для запроса методом POST обязательны два заголовка содержимого: Content-Length и Content-Type.

Content-Length
НТТР/1.0 требовал наличия корректного поля Content-Length во всех запросах POST. В НТТР/1.0 не было другого способа определить длину содержимого. В НТТР/1.1 это можно сделать так же с помощью механизма разбиения на фрагменты (см. описание заголовка Transfer-Encoding: chunked). Поэтому стандарт RFC 2616 по НТТР/1.1 не требует обязательного наличия заголовка Content-Length в POST-запросе.
Но это лишь стандарт. Если какая-либо реализация протокола HTTP/1.1 потребует обязательного наличия этого заголовка в POST-запросах, то это не будет нарушением протокола. Так например, самый популярный на сегодняшний день сервер Apache, требует наличия заголовка Content-Length в POST-запросе. Если он не обнаружится, сервер возвращает ответ 411 Length Required. Но это не значит, что этот сервер просто поддерживает HTTP/1.0 и ничего не знает о способе разбиения содержимого на части. Потому что, если Вы попытаетесь передать ему POST-запрос разбитый на части с соответствующим этому заголовком Transfer-Encoding: chunked, сервер проинформирует Вас: "chunked Transfer-Encoding forbidden" - "Разбиение на части запрещено".

Content-Type
Этот заголовок информирует сервер о типе содержимого POST-запроса. Основным способом отправки POST-запроса служит HTML-форма, тип содержимого которой указывается в свойстве enctype:

<form method="POST" enctype="multipart/form-data">

При отправке формы значение свойства enctype записывается в заголовок запроса Content-Type. В HTML у свойства enctype определено два возможных значения: application/x-www-form-urlencoded и multipart/form-data. Тип application является значением по умолчанию и может не указываться.

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
Этот тип позволяет передавать данные, разбитые на части, каждая из которых может относится к различным типам данных. Этот способ передачи данных незаменим при передаче файлов. Правила оформления тела запроса данного типа несколько сложнее, чем application/x-www-form-urlencoded. Общие правила оформления сообщения типа multipart описаны в документе RFC 2046, а более конретные правила оформления сообщения типа multipart/form-data описаны в документе RFC 2388. Рассмотрим эти правила на следующем примере.

POST /index.php HTTP/1.1
Content-Type: multipart/form-data; boundary="w23renff491nc4rth56u349"
Content-Length: 203409
[пустая строка]
--w23renff491nc4rth56u349
Content-Disposition: form-data; name="city"
[пустая строка]
Moscow
--w23renff491nc4rth56u349
Content-Disposition: form-data; name="number"
[пустая строка]
16
--w23renff491nc4rth56u349
Content-Disposition: form-data; name="photo"; filename="18728.jpg"
Content-Type: image/jpeg
[пустая строка]
[бинарные данные файла]
--w23renff491nc4rth56u349--
[пустая строка]

Заголовок Content-Type должен содержать параметр boundary, необходимый только для типов данных multipart. Этот параметр содержит в себе разделитель частей данных. Это должна быть уникальная строка из ASCII символов, которая не встречается в самих данных. Значение параметра может не браться в кавычки, если строка не содержит специальных символов.

После заголовков, как и положено, следует пустая строка, а далее следует первый разделитель. Разделитель всегда начинается с двух тире "--", а затем следует строка из параметра boundary.
После разделителя могут идти HTTP заголовки содержимого, относящиеся к текущей части данных. Это, прежде всего Content-Type, Content-Encoding и Content-Disposition и др.

То, как здесь применяется заголовок Content-Disposition описано только в стандарте RFC 2388. В документе RFC 2183, описывающем заголовок Content-Disposition, о директиве form-data ничего не написано. Однако, именно с помощью заголовка Content-Disposition: form-data и параметра name передается имя поля HTML-формы. Если был передан файл, то в этот заголовок добавляется дополнительный параметр filename. При передаче файла могут присутствовать и другие параметры, присущие заголовку Content-Disposition, описывающие свойства этого файла.

В случае передачи файла добавляется заголовок Content-Type, который содержит тип данных этого файла. Для обычного поля формы этот заголовок отсутствует.

После строк заголовков, как и положено, идет пустая строка и далее следуют сами данные. После данных идет очередной разделитель.
Завершающий разделитель оканчивается, в отличие от обычных разделителей, двумя тире "--". После завершающего разделителя идет, так называемый, эпилог. По стандарту протокола HTTP, эпилог должен быть пустым. Поэтому после завершающего разделителя обязательно следует пустая строка.

POST-параметры в PHP

В зависимости от значения заголовка Content-Type POST-запроса PHP интерпретирует содержимое запроса и помещает все POST-параметры в специальный глобальный массив $_POST, а все файлы в глобальный массив $_FILES. При работе с POST-данными в PHP вам не обязательно знать, каким способом они были представлены в запросе. Единственное, что вам нужно помнить, это то что для отправки файлов значение заголовка Content-Type обязательно должно быть multipart/form-data.

Кэширование POST-запросов

Метод POST является неидемпотентным методом. Это значит, что для последовательности идентичных запросов ответы могут различаться. Это связано с тем, что запрос обрабатывается программой и ее логика никак не регламентирована в протоколе HTTP/1.1
Например, когда вы авторизуетесь на каком-либо сайте, Вы отправляете POST запрос с логином и паролем учетной записи. Если авторизация прошла успешно, то при повторной отправке того же запроса Вам может быть возвращен другой ответ, в котором будет сообщаться, что Вы уже авторизованы.
Поэтому кешировать POST запросы нет никакого смысла. В стандарте RFC 2616 написано, что ответы на POST-запросы не кэшируются, за исключением ответов с соответствующими инструкциями в заголовках Cache-Control или Expires.