В последнее время я все более часто наблюдаю в основном форуме РНРClub вопросы на тему создания POST и GET запросов, а так же вопросы на тему: "Как мне посредством функции header сформировать POST запрос". Я считаю, что уже давно назрела необходимость расставить точки над "и" в использовании данной технологии, поскольку начинающие программисты просто не понимают принципов работы веба, как такового. Итак, начнем наше путешествие по миру протокола HTTP.
1. Протокол HTTP. Введение
Сразу хочу уточнить одну маленькую вещь. Страшное слово протокол есть не что иное, как соглашение множества людей, просто в один прекрасный момент люди решили: "Давайте будем делать так, и тогда все будет в порядке". Бояться нечего, все просто до безобразия и это безобразие мы сейчас будем вскрывать. Итак, что же это такое протокол HTTP и с чем его едят?
1.1 Клиент и сервер
Чудес в мире, а тем более в мире программизма и интернета не бывает! Усвойте это как незыблемую истину. И, если программа не работает или работает не так как хочется, то, значит, скорее всего, она либо написана не правильно, либо содержит ошибки. Итак, как же все-таки браузер просит сервер прислать ему хоть что-нибудь? Да очень просто! Надо только немного расслабиться и начать получать удовольствие от процесса:-)
1.2. Пишем наш первый HTTP запрос
Если Вы думаете, что все слишком сложно, то Вы ошибаетесь. Человек так устроен, что просто не способен создавать что-то сложное, иначе он сам в этом запутается:-) Итак, есть браузер и есть Web-сервер. Инициатором обмена данными всегда выступает браузер. Web-сервер никому, никогда просто так ничего не пошлет, чтобы он что-нибудь отправил браузеру - надо, чтобы браузер об этом попросил. Простейший HTTP запрос моет выглядеть, например, так:
GET http://www.php.net/ HTTP/1.0\r\n\r\n
- GET (В переводе с английского означает "получить") - тип запроса, тип запроса может быть разным, например POST, HEAD, PUT, DELETE (часть из них мы рассмотрим ниже).
- http://www.php.net/ - URI (адрес) от которого мы хотим получить хоть какую-нибудь информацию (естественно мы надеемся подучить HTML страницу).
- HTTP/1.0 - тип и версия протокола, который мы будем использовать в процессе общения с сервером.
- \r\n - конец строки, который необходимо повторить два раза, зачем, станет понятно немного позднее.
1.3 Структура запроса
Рассмотрим, из чего состоит HTTP запрос. Все достаточно просто. Начнем с того, что HTTP запрос - это вполне осмысленный текст. Из чего же он состоит в общем случае? Будем рассматривать протокол HTTP 1.0. Итак:
Request-Line [ General-Header | Request-Header | Entity-Header ]\r\n[ Entity-Body ]
- Request-Line - строка запроса
- Method - метод, которым будет обрабатываться ресурс Request-URI, может быть GET, POST, PUT, DELETE или HEAD.
- Request-URI - относительная или абсолютная ссылка на страницу с набором параметров, например, /index.html или http://www.myhost.ru/index.html или /index.html?a=1&b=qq. В последнем случае серверу будет передан запрос с набором переменных a и b с соответствующими значениями, а знак "&" - амперсант служит разделителем между параметрами.
- HTTP-Version - версия HTTP протокола, в нашем случае "HTTP/1.0".
Формат: "Method Request-URI HTTP-Version\r\n"
Нам крайне интересны методы обработки GET и POST. Методом GET можно просто передать параметры в скрипт, а методом POST можно эмулировать submit формы.
Для метода GET, Request-URI может выглядеть, например, так: "/index.html?param1=1¶m2=2".
- General-Header
- главная часть
заголовка.
Формат:
Может иметь только два параметра: Date или Pragma. Date - дата по Гринвичу в формате "День недели, Число Месяц Год ЧЧ:ММ:СС GMT", например, "Tue, 15 Nov 1994 08:12:31 GMT" - дата создания запроса. Pragma может иметь одно значение no-cache, которое запрещает кэширование страницы. - Request-Header
- часть заголовка,
описывающая запрос.
Request-Header может иметь следующие параметры: Allow, Authorization, From, If-Modified-Since, Referer, User-Agent .
В данной главе мы не будем рассматривать параметр Autorization, так как он используется для доступа к закрытым ресурсам, что требуется не так уж часто. Вы можете самостоятельно изучить формирование заголовка для авторизованного доступа на сайте www.w3c.org. - Allow
- задает допустимые методы
обработки.
Формат: "Allow: GET | HEAD\n".
Параметр игнорируется при указании метода обработки POST в Request-Line. Задает допустимые методы обработки запроса. Прокси сервера не модифицируют параметр Allow и он в неизменном виде доходит до сервера. - From
- e-mail адрес, пославшего
запрос.
Формат: "From: adderss\r\n".
Например, "From: [email protected]\r\n". - If-Modified-Since
- указывает, что
запрос не модифицировался с такого-то
времени.
Формат: "If-Modified-Since: date\r\n"
Используется только для метода обработки GET. Дата указывается по Гринвичу в таком же формате, как и для параметра Date в General-Header. - Referrer
- абсолютная ссылка на
страницу, с которой произошла
инициация запроса, т. е. ссылка на
страницу, с которой пользователь
перешел на нашу.
Формат: "Referrer: url\n".
Пример: "Referrer: www.host.ru/index.html\n". - User-Agent
- тип браузера.
Например: "User-Agent: Mozilla/4.0\n" - Entity-Header
- часть заголовка,
описывающая данные Entity-Body.
В данной части запроса задаются параметры, которые описывают тело страницы. Entity-Header может содержать следующие параметры: Allow, Content-Encoding, Content-Length, Content-Type, Expires, Last-Modified, extension-header . - Allow - параметр аналогичный Allow из General-Header.
- Content-Encoding
- тип кодирования
данных Entity-Body.
Формат: "Сontent-Encoding: x-gzip | x-compress | другой тип\n".
Пример: "Сontent-Encoding: x-gzip\n". Символ "|" означает слово "или", то есть то или то или то и.т.д.
Другой тип может указывать на способ кодирования данных, например, для метода POST: "Сontent-Encoding: application/x-www-form-urlencoded\n". - Content-Length
- количество байт,
пересылаемых в Entity-Body. Значение Content-Length
имеет совсем другой смысл для данных,
пересылаемых в формате MIME, где он
выступает как параметр описания части
данных - "external/entity-body".
Допустимыми являются целые числа от
нуля и больше.
Пример: "Content-Length: 26457\n". - Content-Type
- тип передаваемых
данных.
Например: "Content-Type: text/html\n". - Expires
- Время, когда страница
должна быть удалена из кэша браузера.
Формат: "Expires: date\n". Формат даты алогичен формату даты для параметра Date из General-Header. - Last-Modified
- время последнего
изменения пересылаемых данных.
Формат: "Last-Modified: date\n". Формат даты алогичен формату даты для параметра Date из General-Header. - Extention-header
- часть заголовка,
которая может предназначаться,
например, для обработки браузером, или
другой программой, которая принимает
документ. В данной части можно
описывать свои параметры в формате
"ParameterName: parametervalue\n". Данные
параметры будут игнорироваться, если
программа-клиент не знает, как их
обработать.
Например: "Cookie: r=1\r\n" - устанавливает всем известные печеньки для страницы.
А теперь после таких страшных слов давайте попробуем немного успокоиться и понять, что же нам надо? Понимать мы естественно будем на примерах.
Давайте представим, что нам надо получить страницу с сайта, передав Cookies (Печеньки), иначе нас просто пошлют как незванных гостей, и более того, известно, что на данную страницу пускают только после того, как Вы побывали на главной странице сайта.
2 Метод GET
Напишем наш запрос.
GET http://www.site.ru/news.html HTTP/1.0\r\n
Host: www.site.ru\r\n
Cookie: income=1\r\n
\r\n
Данный запрос говорит нам о том, что мы хотим получить содержимое страницы по адресу http://www.site.ru/news.html, использую метод GET. Поле Host говорит о том, что данная страница находится на сервере www.site.ru, поле Referer говорит о том, что за новостями мы пришли с главной страницы сайта, а поле Cookie говорит о том, что нам была присвоена такая-то кука. Почему так важны поля Host, Referer и Сookie? Потому что нормальные программисты при создании динамических сайтов проверяют данные поля, которые появляются в скриптах (РНР в том числе) в виде переменных. Для чего это надо? Для того, например, чтобы сайт не грабили, т.е. не натравливали на него программу для автоматического скачивания, или для того, чтобы зашедший на сайт человек всегда попадал бы на него только с главной страницы и.т.д.
Теперь давайте представим, что нам надо заполнить поля формы на странице и отправить запрос из формы, пусть в данной форме будет два поля: login и password (логин и пароль),- и, мы естественно знаем логин и пароль.
GET http://www.site.ru/news.html?login=Petya%20Vasechkin&password=qq
HTTP/1.0\r\n
Host: www.site.ru\r\n
Referer: http://www.site.ru/index.html\r\n
Cookie: income=1\r\n
\r\n
Логин у нас "Petya Vasechkin" Почему же мы должны писать Petya%20Vasechkin? Это из=за того, что специальные символы могут быть распознаны сервером, как признаки наличия нового параметра или конца запроса и.т.д. Поэтому существует алгоритм кодирования имен параметров и их значений, во избежание оштбочных ситуаций в запросе. Полное описание данного алгоритма можно найти , а в PHP есть функции rawurlencode и rawurldecode для кодирования и декодирования соответственно. Хочу отметеить, что декодирование РНР делает сам, если в запросе были переданы закодированные параметры. На этом я закону первую главу знакомства c протоколом HTTP. В следуючей главе мы рассмотрим построение запросов типа POST (в переводе с английского - "отправить"), что будет гораздо интереснее, т.к. именно данный тип запросов используется при отправке данных из HTML форм.
3. Метод POST.
В случае HTTP запроса типа POST существует два варианта передачи полей из HTML форм, а именно, используя алгоритм application/x-www-form-urlencoded и multipart/form-data. Различия между данными алгоритмами весьма существенные. Дело в том, что алгоритм первого типа создавался давным-давно, когда в языке HTML еще не предусматривали возможность передачи файлов через HTML формы. Итак, давайте рассмотрим эти алгоритмы на примерах.
3.1 Content-Type: application/x-www-form-urlencoded.
Пишем запрос, аналогичный нашему запросу GET для передачи логина и пароля, который был рассмотрен в предыдущей главе:
Host: www.site.ru\r\n
Referer: http://www.site.ru/index.html\r\n
Cookie: income=1\r\n
Content-Type: application/x-www-form-urlencoded\r\n
Content-Length: 35\r\n
\r\n
Здесь мы видим пример использования Content-Type и Content-Length полей заголовка. Content-Length говорит, сколько байт будет занимать область данных, которая отделяется от заголовка еще одним переводом строки \r\n. А вот параметры, которые раньше для запроса GET помещались в Request-URI, теперь находятся в Entity-Body. Видно, что они формируются точно также, просто надо написать их после заголовка. Хочу отметить еще один важный момент, ничто не мешает, одновременно с набором параметров в Entity-Body, помещать параметры с другими именами в Request-URI, например:
POST http://www.site.ru/news.html?type=user HTTP/1.0\r\n
.....
\r\n
login=Petya%20Vasechkin&password=qq
3.2 Content-Type: multipart/form-data
Как только интернет мир понял, что неплохо бы было через формы отсылать еще и файлы, так W3C консорциум взялся за доработку формата POST запроса. К тому времени уже достаточно широко применялся формат MIME (Multipurpose Internet Mail Extensions - многоцелевые расширения протокола для формирования Mail сообщений), поэтому, чтобы не изобретать велосипед заново, решили использовать часть данного формата формирования сообщений для создания POST запросов в протоколе HTTP.
Каковы же основные отличия этого формата от типа application/x-www-form-urlencoded?
Главное отличие в том, что Entity-Body теперь можно поделить на разделы, которые разделяются границами (boundary). Что самое интересное - каждый раздел может иметь свой собственный заголовок для описания данных, которые в нем хранятся, т.е. в одном запросе можно передавать данные различных типов (как в Mail письме Вы одновременно с текстом можете передавать файлы).
Итак, приступим. Рассмотрим опять все тот же пример с передачей логина и пароля, но теперь в новом формате.
POST http://www.site.ru/news.html HTTP/1.0\r\n
Host: www.site.ru\r\n
Referer: http://www.site.ru/index.html\r\n
Cookie: income=1\r\n
Content-Length: 209\r\n
\r\n
--1BEF0A57BE110FD467A\r\n
Content-Disposition: form-data; name="login"\r\n
\r\n
Petya Vasechkin\r\n
--1BEF0A57BE110FD467A\r\n
Content-Disposition: form-data; name="password"\r\n
\r\n
qq\r\n
--1BEF0A57BE110FD467A--\r\n
Теперь давайте разбираться в том что написано. :-) Я специально выделил некоторые символы \r\n жирным, чтобы они не сливались с данными. Присмотревшись внимательно можно заметить поле boundary после Content-Type. Это поле задает разделитель разделов - границу. В качестве границы может быть использована строка, состоящая из латинских букв и цифр, а так же из еще некоторых символов (к сожалению, не помню каких еще). В теле запроса в начало границы добавляется "--", а заканчивается запрос - границей, к которой символы "--" добавляются еще и в конец. В нашем запросе два раздела, первый описывает поле login, а второй поле password. Content-Disposition (тип данных в разделе) говорит, что это будут данные из формы, а в поле name задается имя поля. На этом заголовок раздела заканчивается и далее следует область данных раздела, в котором помещается значение поля (кодировать значение не требуется!).
Хочу обратить Ваше внимание та то, что в заголовках разделов не надо использовать Content-Length, а вот в заголовке запроса надо и его значение является размером всего Entity-Body, стоящего после второго \r\n, следующего за Content-Length: 209\r\n. Т.е. Entity-Body отделяется от заголовка дополнительным переводом строки (что можно заметить и в разделах).
А теперь давайте напишем запрос для передачи файла.
POST http://www.site.ru/postnews.html HTTP/1.0\r\n
Host: www.site.ru\r\n
Referer: http://www.site.ru/news.html\r\n
Cookie: income=1\r\n
Content-Type: multipart/form-data; boundary=1BEF0A57BE110FD467A\r\n
Content-Length: 491\r\n
\r\n
--1BEF0A57BE110FD467A\r\n
Content-Disposition: form-data; name="news_header"\r\n
\r\n
Пример новости\r\n
--1BEF0A57BE110FD467A\r\n
Content-Disposition: form-data; name="news_file";
filename="news.txt"\r\n
Content-Type: application/octet-stream\r\n
Content-Transfer-Encoding: binary\r\n
\r\n
А вот такая новость, которая лежит в файле
news.txt\r\n
--1BEF0A57BE110FD467A--\r\n
В данном примере в первом разделе пересылается заголовок новости, а во втором разделе пересылается файл news.txt. Внимательный да увидит поля filename и Content-Type во втором разделе. Поле filename задает имя пересылаемого файла, а поле Content-Type - тип данного файла. Application/octet-stream говорит о том, что это стандартный поток данных, а Content-Transfer-Encoding: binary говорит на о том, что это бинарные данные, ничем не закодированные.
Очень важный момент. Большинство CGI скриптов написано умными людьми, поэтому они любят проверять тип пришедшего файла, который стоит в Content-Type. Зачем? Чаще всего закачка файлов на сайтах используется для получения картинок от посетителя. Так вот, браузер сам пытается определить что за файл посетитель хочет отправить и вставляет соответствующий Content-Type в запрос. Скрипт его проверяет при получении, и, например, если это не gif или не jpeg игнорирует данный файл. Поэтому при "ручном" формировании запроса позаботьтесь о значении Content-Type, чтобы оно было наиболее близким к формату передаваемого файла.
В нашем примере формируется запрос, в котором передается текстовый файл. Точно так же формируется запрос для передачи бинарного файла.
4. Постскриптум.
Думаю, что о передаче запросов на сервер не стоит рассказывать подробно. Это уже дело чисто РНР техники:-). Достаточно внимательно прочитать раздел о функциях работы с сокетами, или о функциях модуля CURL в официальной документации РНР.
Из выше сказанного, надеюсь теперь понятно, почему вопрос: "Как мне сформировать POST запрос, используя функцию header?" - бессмысленен. Функция header(string) добавляет запись только в заголовок запроса, но никак не в тело запроса.
Есть еще один тип запросов - Content-Type: multipart/mixed, надеюсь после прочтения данной статьи Вы легко разберетесь с данным типом сами. Подробно изучить его можно
HTTP — протокол транспортировки гипертекста, один из протоколов стека TCP/IP. Изначально протокол был создан для передачи и получения HTML страниц, но сейчас он отлично используется для распределенных информационных систем. Это один из самых используемых протоколов во всемирной паутине.
Рисунок — 1
Основан на схема запроса/ответа. Когда клиент отправляет запрос на сервер, он может это делать с помощью 3 видов запроса: GET, PUT и POST.
GET запрос протокола HTTP
GET — это клиентский запрос информации. Веб браузер клиента отправляет сообщение GET, чтобы взять страницы из него. Запрос имеет две части:
- строка запроса
- заголовки
GET запрос не имеет тело данных, однако это не значит, что он не может передавать серверу никаких данных. С помощью специальных параметров в URL строке можно передавать серверу данные. Знак ? после домена в URL значит, что дальше будут передавать параметры. На рис.2 видно какую именно информацию передает браузер серверу.
Рисунок — 2
POST и PUT запрос протокола HTTP
Эти два метода реализуют для того, чтобы отправлять информацию на веб сервер. К примеру с помощью специальных веб-форм заполнив их, мы отправляем их на сервер с помощью метода POST. PUT же загружает ресурсы или данные на веб сервер (картинка, видео).
HTTP не является безопасным протоколом, и сообщения POST можно перехватить и прочитать, так как оно не зашифровано. Для безопасности передачи данных с помощью метода POST, используют протокол HTTPS. Он шифрует данные и может проводить аутентификацию. Также он реализует дополнительные требования для прохождения информации между транспортным и прикладным уровнями.
Основные различия между методами POST и GET показаны в таблице 1.
На рис.3 видно основные правила, которым нужно следовать при выборе метода GET или POST для реализации работы на вашем сервере.
Общего между ними то что они работают одинаково. Разницы между ними технически никакой. А вот идеологические различия есть.
Я расскажу о них в контексте PHP. Прошу заметить что протокол HTTP к PHP имеет косвенное отношение потому что он создавался для обмена html страницам а PHP просто расширяет возможности и того и другого.
GET запрос используется чтобы получить данные а POST чтобы отправить. (Напоминаю что технически они работают одинаково).
Поэтому в контексте PHP опираясь на эту идеологию сделали следующим образом:
1. При каждом запуске PHP по умолчанию создаются суперглобальные массивы ($_GET, $_POST).
2. Если в строке запроса есть вопросительный знак(?). То все что после него считается параметрами
GET запроса они представлены в формате "ключ"="значение" и в качестве разделителя используется знак амперсанда (&)
Пример:
GET /index.php?name=Андрей&surname=Галкин
это строка запроса, тут 2 параметра. эти параметры попадут в массив $_GET.
3. $_POST заполняется другим способом. содержимое этого массива заполняется из "заголовков запроса". То есть из места, скрытого от глаз в явном виде. Всю рутину по созданию таких заголовков берет на себя браузер. Хотя иногда и что-то редактируется в заголовках в ручную.
Чаще всего пост запрос используется в формах (для отправки данных).
Например у нас есть форма для входа 2 поля логин и пароль.
Представим что мы используем GET метод. Тогда при отправке формы мы перейдем на следующий адрес /login.php?login=Андрей&password=123 согласитесь что так передавать такую информацию совсем не безопасно. Любой может открыть ваш браузер и начиная вводить адрес сайта он из истории может увидеть ваши пароли и логины.
А вот если бы мы указали методом POST то мы бы получили следующий запрос:
POST /login.php (login=Андрей&password=123) то что в скобочках было бы скрыто и никак не сохранено в браузере.
В общем подводя итог:
GET - это чтобы получить определенную страницу в определенном виде (сортировка, текущая страница в блоге, строка поиска и т.п.).
POST - для оправки данных которые не влияют на отображение страницы, в том плане что эти данные влияют только на результат выполнения скрипта (логины, пароли, номера кредиток, сообщения и т.п.).
И еще одна хорошая новость их можно комбинировать, например
POST /index.php?page=login (login=Андрей&password=123) Думаю я уже достаточно объяснил что из этого получится и какие параметры в какой массив попадут.
Этот пост предназначен для объяснения принципов передачи данных в интернете с помощью двух основных методов: GET и POST. Написал я его в качестве дополнения к инструкции по генератору сменного графика работы для тех, кому вряд ли интересны подробности ☺.
Перейдите по следующему адресу (это для наглядного объяснения): http://calendarin.net/calendar.php?year=2016 Обратите внимание на адресную строку браузера: calendarin.net/calendar.php?year=2016 Основной файл называется, за ним следует вопросительный знак (?) и параметр «year» со значением «2016». Так вот, всё, что следует за вопросительным знаком, это и есть GET-запрос. Всё просто. Чтобы передать не один параметр, а несколько, то их нужно разделить амперсандом (&). Пример: calendarin.net/calendar.php?year=2016&display=work-days-and-days-off
Основной файл всё также называется, за ним следует вопросительный знак (?), затем - параметр «year» со значением «2016», затем - амперсанд (&), затем - параметр «display» со значением «work-days-and-days-off».
GET-параметры могут изменяться прямо в адресной строке браузера. Например, изменив значение «2016» на «2017» и нажав клавишу, вы перейдёте к календарю на 2017 год.
Это передача данных скрытым способом (адрес страницы не изменяется); то есть увидеть, что было передано, можно только с помощью программы (скрипта). Например, в следующем инструменте для подсчёта символов в тексте исходные данные передаются методом POST: http://usefulonlinetools.com/free/character-counter.php
Если остались вопросы, комментарии и мой E-mail к вашим услугам.
Кроме метода GET, который мы рассмотрели в предыдущей заметке, существует еще один метод отправки запроса по протоколу HTTP – метод POST. Метод POST тоже очень часто используется на практике.
Если, для того, чтобы обратиться к серверу методом GET, нам достаточно было набрать запрос в URL-адрес, то в методе POST все работает по другому принципу.
Для того, чтобы выполнить этот вид запроса, нам необходимо нажать на кнопку с атрибутом type=»submit», которая расположена на веб-странице. Обратите внимание, что эта кнопка расположена в элементе
Если пользователь введет в текстовое поле какой-либо текст и нажмет на кнопку «Отправить», то на сервер будет отправлена переменная text со значением того содержимого, которое ввел пользователь.
POST и GET запросы простыми словами
Эта переменная будет отправлена методом POST.
Если в форме написать так: