Загрузка файла на сервер без использования формы
Со временем возникла необходимость через формы отсылать еще и файлы. Тогда консорциум W3C взялся за доработку формата POST запроса. К тому времени уже достаточно широко применялся формат MIME (Multipurpose Internet Mail Extensions — многоцелевые расширения протокола для формирования Mail сообщений), поэтому, чтобы не изобретать велосипед заново, решили использовать часть данного формата формирования сообщений для создания POST запросов в протоколе HTTP.
Главное отличие multipart/form-data от application/x-www-form-urlencoded в том, что тело запроса теперь можно поделить на разделы, которые разделяются границами. Каждый раздел может иметь свой собственный заголовок для описания данных, которые в нем хранятся, т.е. в одном запросе можно передавать данные различных типов (как в теле письма можно одновременно с текстом передавать файлы). Пример запроса:
Boundary (граница) — это последовательность байтов, которая не должна встречаться внутри передаваемых данных. Content-Length — суммарный объём, включая дочерние заголовки. Само содержимое полей при этом оставляется «как есть».
CURL, multipart/form-data
Файл get.php на сервере http://server.com:
Важный момент: на форуме PHPCLUB.RU встретил упоминание, что может потребоваться указание полного пути файла — иначе CURL выдает ошибку.
CURL, application/x-www-form-urlencoded
Файл get.php на сервере http://server.com:
Сокеты, multipart/form-data
Файл get.php на сервере http://server.com:
Сокеты, application/x-www-form-urlencoded
Файл get.php на сервере http://server.com:
Метод PUT
Описанные выше способы работают для относительно небольших файлов (примерно до 2-х мегабайт, для получения более точного значения необходимо смотреть в настройках PHP максимальный объем принимаемых данных методом POST). Чтобы обойти это ограничение, будем передавать файл методом PUT:
POST без формы + HTTP-аутентификация
ThyBzi
Новичок
POST без формы + HTTP-аутентификация
Поискал в форуме и факах, ничего подобного не нашёл.
Написал в этот раздел, так как считаю, что тема напрямую касается cURL (а ведь это, насколько я понял, одна из библиотек PECL).
Значится, суть проблемы такая. Имеем админку к сайту, в ней есть (в т.ч.) два файла: index.php, через который работает весь юзерский интерфейс (в т.ч. удаления/изменения/добавления событий в БД), и dbrw.php, который напрямую работает с БД, в зависимости от того, какие action и id (и другие данные) ему пришли по POSTу от index.php, а затем отсылает страницу обратно к index.php.
С добавлением нового события и удалением имеющегося проблем не возникает, нужные данные передаются постом от index к dbrw, выполняется соответствующий запрос, и всё путём.
Проблема возникает, когда событие нужно редактировать. Т.е.:
1) передать странице dbrw.php постом переменные action = edit и (на самом деле передаётся ещё и section, которое соответствует типу записи в БД — из какой таблицы и какие поля вытащить);
2) составить запрос на выборку имеющихся данных (полей много, и в зависимости от section их число и имена меняются);
3) и то, что собственно не получается: передать эти данные обратно index.php.
Возможные варианты решения, которые я рассматривал:
1) Передать данные GETом.
Чем плохо. Далеко не любые данные можно безопасно передать через адресную строку (особенно касается длинных текстов, в т.ч. содержащих переносы строк и др. — эти переносы потеряются, и думаю, не только они)
2) Создать форму с методом POST, в ней все значения вписать hidden-ами, а затем отправить форму средствами JavaScript.
Чем плохо. Неэлегантое решение, ибо это «выкрутасы» (или выкручивание 
. К тому же, в HTML-код страницы, которая заведомо ничего не должна показывать юзеру, выводится огромная форма. А ещё я считаю плохим стилем доверять JS выполнение важных операций.
4) Отправить данные POSTом без использования форм. Это был бы идеальный вариант. Пошарил в инете на эту тему и выяснил, что подобные вещи позволяет делать cURL…
Если вы не забыли, речь идёт об админке, соответственно там используется аутентификация (в данном случае — HTTPшная, через 401 «ошибку»). Т.е. если тупо передать нужные данные POSTом, скрипту ответят этой самой 401-й ошибкой.
Попытался совместить примеры передачи данных POSTом и HTTP-аутентификации из мануала по cURL (http://www.zend.com/pecl/tutorials/curl.php), всё равно выдаётся ошибка 401.
где:
$referer — это http-реферер ) т.е. index.php?section=имя_раздела
BuildVarStr($data2post) — это строка «GET-вида» (var1=12&var2=345=var3=gdfgd). Самописная функция BuildVarStr() формирует такую строку из массива («var1» => 12, «var2» => 345. ). В мануале по cURL в примере используется строка именно такого вида.
Уважаемые члены сообщества! Буду весьма признателен, если укажите мне на местонахождение и суть моей ошибки в ДНК. ) А особенно — путей исправления оной и путей решение данной задачи. Заранее благодарен.
P.S. cURL включен, разумеется. ))
Метод POST в PHP как главное средство передачи данных на сервер
Дата публикации: 2017-02-24
От автора: POST сдал – POST принял! Наверное, служившие в армии подумают, что мы будем играть в войнушки. С армией у нас и так все в порядке, а вот с передачей данных в Сети не так все хорошо. Нужно знать, когда использовать метод POST в PHP, а когда GET.
Различия в примерах
Для начала создадим экспериментальную форму, с помощью которой будем тестировать оба метода. Именно формы чаще всего используются для сбора данных и пересылки их на сервер. Разметка простейшей:
Бесплатный курс по PHP программированию
Освойте курс и узнайте, как создать динамичный сайт на PHP и MySQL с полного нуля, используя модель MVC
В курсе 39 уроков | 15 часов видео | исходники для каждого урока
О прикладном протоколе HTTP много говорить не буду. Упомяну лишь, что он предоставляет несколько методов для указания того ресурса, к которому направлен запрос. Чаще всего для доставки информации на сервер используются передача методом POST в PHP или GET. Метод передачи прописывается в атрибуте веб-формы method.
Сначала GET, а потом POST
Сначала отправляем данные с помощью GET. Поместите разметку формы и обработчик по разным файлам. Хотя можно обойтись и одним, если не прописывать атрибут action. В этом случае обработка будет происходить в этом же файле.
Бесплатный курс по PHP программированию
Освойте курс и узнайте, как создать динамичный сайт на PHP и MySQL с полного нуля, используя модель MVC
В курсе 39 уроков | 15 часов видео | исходники для каждого урока
Как видите, с помощью GET значения переменных передаются в URL. Что плохо, если вы пересылаете на сервер конфиденциальные данные. Теперь пробуем POST. В коде обработчика будет использовать глобальный массив _POST:
Мы убедились, что этот метод передает данные на сервер не через URL, а в теле запроса. Теперь разберемся, как с помощью PHP отправить POST методы.
Без форм
При передаче данных можно обойтись и без веб-форм. Следующий пример иллюстрирует, как достичь такого же эффекта средствами cURL. Думаю, разобраться вам не составит большого труда. Код первого скрипта:
Как передать переменную без формы
Я пытаюсь сохранить пользовательскую систему PHP. Я пытаюсь передать переменную на вторую страницу PHP. Ранее это делалось через форму с раскрывающимся списком:
(каким-то образом даже без закрытия тега option это все же работало)
За ними следовали отдельные кнопки, которые определяли, куда он шел
«Awardedit.php»
Однако выпадающий список — это не тот путь, когда у нас большое количество пользователей. Удобство использования не велико.
Я пытаюсь выполнить запрос к базе данных, чтобы получить список пользователей, а затем отобразить пользователей в таблице вместе с теми кнопками, с помощью которых вы можете перейти к различным разделам на сайте wonit.php.
Я знаю, как отобразить имя пользователя, чтобы показать имя пользователя, но я не знаю код для передачи через переменную.
Решение
Вот следующие решения вашей проблемы:
ПОЛУЧИТЬ :
использование ПОЛУЧИТЬ передать переменную на другую страницу:
Замечания : Теперь он становится ссылкой, когда вы нажимаете на него, чтобы он прошел ваш username переменные данные к вашему awardedit.php стр.
И тогда на этой странице вы можете поймать значение переменной, используя следующий код:
Если вы хотите сделать это таким образом, то вы можете использовать следующий способ для этого:
ПЕЧЕНЬЕ:
использование COOKIES если вы не хотите делать что-то небезопасное:
А потом принеси печенье на свой awardedit.php страница как:
Тем не менее, если вы не хотите делать это таким образом, вы можете сделать это следующим образом, и это более безопасный способ:
СЕССИИ:
Установите сессию так:
И по вашему awardedit.php страница для получения значения. Вы можете сделать это следующим образом:
Типы HTTP-запросов и философия REST
Этот пост — ответ на вопрос, заданный в комментарии к одной из моих статей.
В статье я хочу рассказать, что же из себя представляют HTTP-методы GET/POST/PUT/DELETE и другие, для чего они были придуманы и как их использовать в соответствии с REST.
Итак, что же представляет из себя один из основных протоколов интернета? Педантов отправлю к RFC2616, а остальным расскажу по-человечески 
Этот протокол описывает взаимодействие между двумя компьютерами (клиентом и сервером), построенное на базе сообщений, называемых запрос (Request) и ответ (Response). Каждое сообщение состоит из трех частей: стартовая строка, заголовки и тело. При этом обязательной является только стартовая строка.
Стартовые строки для запроса и ответа имеют различный формат — нам интересна только стартовая строка запроса, которая выглядит так:
где METHOD — это как раз метод HTTP-запроса, URI — идентификатор ресурса, VERSION — версия протокола (на данный момент актуальна версия 1.1).
Заголовки — это набор пар имя-значение, разделенных двоеточием. В заголовках передается различная служебная информация: кодировка сообщения, название и версия браузера, адрес, с которого пришел клиент (Referrer) и так далее.
Тело сообщения — это, собственно, передаваемые данные. В ответе передаваемыми данными, как правило, является html-страница, которую запросил браузер, а в запросе, например, в теле сообщения передается содержимое файлов, загружаемых на сервер. Но как правило, тело сообщения в запросе вообще отсутствует.
Пример HTTP-взаимодействия
Первая строка — это строка запроса, остальные — заголовки; тело сообщения отсутствует
Ресурсы и методы
Вернемся к стартовой строке запроса и вспомним, что в ней присутствует такой параметр, как URI. Это расшифровывается, как Uniform Resource Identifier — единообразный идентификатор ресурса. Ресурс — это, как правило, файл на сервере (пример URI в данном случае ‘/styles.css’), но вообще ресурсом может являться и какой-либо абстрактный объект (‘/blogs/webdev/’ — указывает на блок «Веб-разработка», а не на конкретный файл).
Тип HTTP-запроса (также называемый HTTP-метод) указывает серверу на то, какое действие мы хотим произвести с ресурсом. Изначально (в начале 90-х) предполагалось, что клиент может хотеть от ресурса только одно — получить его, однако сейчас по протоколу HTTP можно создавать посты, редактировать профиль, удалять сообщения и многое другое. И эти действия сложно объединить термином «получение».
В игру вступает REST
REST (REpresentational State Transfer) — это термин был введен в 2000-м году Роем Филдингом (Roy Fielding) — одним из разработчиков протокола HTTP — в качестве названия группы принципов построения веб-приложений. Вообще REST охватывает более широкую область, нежели HTTP — его можно применять и в других сетях с другими протоколами. REST описывает принципы взаимодействия клиента и сервера, основанные на понятиях «ресурса» и «глагола» (можно понимать их как подлежащее и сказуемое). В случае HTTP ресурс определяется своим URI, а глагол — это HTTP-метод.
REST предлагает отказаться от использования одинаковых URI для разных ресурсов (то есть адреса двух разных статей вроде /index.php?article_id=10 и /index.php?article_id=20 — это не REST-way) и использовать разные HTTP-методы для разных действий. То есть веб-приложение, написанное с использованием REST подхода будет удалять ресурс при обращении к нему с HTTP-методом DELETE (разумеется, это не значит, что надо давать возможность удалить всё и вся, но любой запрос на удаление в приложении должен использовать HTTP-метод DELETE).
REST дает программистам возможность писать стандартизованные и чуть более красивые веб-приложения, чем раньше. Используя REST, URI для добавления нового юзера будет не /user.php?action=create (метод GET/POST), а просто /user.php (метод строго POST).
В итоге, совместив имеющуюся спецификацию HTTP и REST-подход наконец-то обретают смысл различные HTTP-методы. GET — возвращает ресурс, POST — создает новый, PUT — обновляет существующий, DELETE — удаляет.
Проблемы?
Да, есть небольшая проблема с применением REST на практике. Проблема эта называется HTML.
PUT/DELETE запросы можно отправлять посредством XMLHttpRequest, посредством обращения к серверу «вручную» (скажем, через curl или даже через telnet), но нельзя сделать HTML-форму, отправляющую полноценный PUT/DELETE-запрос.
Дело в том, спецификация HTML не позволяет создавать формы, отправляющие данные иначе, чем через GET или POST. Поэтому для нормальной работы с другими методами приходится имитировать их искусственно. Например, в Rack (механизм, на базе которого Ruby взаимодействует с веб-сервером; с применением Rack сделаны Rails, Merb и другие Ruby-фреймворки) в форму можно добавить hidden-поле с именем «_method», а в качестве значения указать название метода (например, «PUT») — в этом случае будет отправлен POST-запрос, но Rack сможет сделать вид, что получил PUT, а не POST.