Содержание

Получение данных из строки запроса

Получение данных из строки запроса

Последнее обновление: 15.03.2021

Самым простым способом передачи данных на сервер приложению PHP извне представляет передача данных через строку запроса.

Строка запроса представляет набор параметров, которые помещаются в адресе после вопросительного знака. При этом каждый параметр определяет название и значение. Например, в адресе:

http://localhost/user.php?name=Tom&age=36

Часть ?name=Tom&age=36 представляет строку запроса, в которой есть два параметра name и age. Для каждого параметра определено имя и значение, которые отделяются знаком равно. Параметр name имеет значение «Tom», а параметр age — значение 36. Друг от друга параметры отделяются знаком амперсанда.

Например, определим следующий скрипт user.php со следующим содержимым:


<?php
$name = "не определено";
$age = "не определен";
if(isset($_GET["name"])){
 
    $name = $_GET["name"];
}
if(isset($_GET["age"])){
 
    $age = $_GET["age"];
}
echo "Имя: $name <br> Возраст: $age";
?>

Когда мы вводим в адресную строку браузера некий адрес и нажимаем на оправку, то серверу отправляется запрос типа GET. В PHP по умолчанию определен глобальный ассоциативный массив $_GET, который хранит все значения, передаваемые в запроса GET. Используя ключи передаваемых данных, мы можем из массива $_GET получить передаваемые значения.

При отправки строки запроса ключами в этом массиве будут названия параметров, а значениями — значения параметров.

Например, в строке запроса передается параметр

name=Tom. Соответственно, чтобы получить значение параметра name из запроса, обращаемся по соответствующему ключу:

$name = $_GET["name"];	// Tom

Однако стоит учитывать, что в адресной строке необязательно будет использоваться строка запроса или конкретно данный параметр. Поэтому перед получением значения параметра сначала смотрим, а передан ли вообще такой параметр:

if(isset($_GET["name"])){

Теперь обратимся к этому скрипту, например, так http://localhost/user.php?name=Tom&age=36:

Если мы не передадим значения какого-либо параметра, то соответствующая переменная будет использовать значение по умолчанию:

GET параметры в url — что это такое простыми словами?

GET параметры задействуются почти каждый раз, когда сайт отправляет запрос на сервер. Если их будет слишком много, то у вас могут возникнуть проблемы с продвижением в поисковых системах.

Продвижение в социальных сетях (2)

Чтобы этого не допустить, нужно подробнее разобраться в теме GET-параметров.

 

GET параметры в url — что это такое простыми словами?

GET- запрос – это всего лишь метод передачи данных.

Когда пользователь запрашивает у сервера какую-то информацию, тот может предоставить её по-разному.

Чаще всего get-запросы используют для того, чтобы настроить работу фильтров.

То есть, когда вся основная информация остаётся неизменной, тогда уместно использовать get-параметры, чтобы не создавать новую страницу.

Выглядят они примерно следующим образом: htttp://site.ru/index.php?name= Иван&surname=Ivanov

ГЕТ-параметры – это весь текст после запятой.

В данном случае Иван – это первый параметр, а Иванов – второй.

Главный плюс этого метода в том, что вся основная информация сохраняется.

Это очень удобно, если пользователь захочет поделиться ссылкой на эту страницу с друзьями.

Но пользуются ей не так часто из-за проблем с конфиденциальностью.

ГЕТ-параметры видят все, поэтому для случаев, когда лучше сохранить информацию, нужно использовать что-то вроде POST.

Ещё страницы с GET-параметрами всегда выглядят неизменно.

 

GET параметры php и js

В формате php этот запрос может выглядеть примерно, как:

<?php

echo ‘Имя: ‘ . $_GET[‘name’] . ‘<br />’;

echo ‘Фамилия: ‘ . $_GET[‘surname’] . ‘<br />’;

?>,

В любом из форматов важно понимать, что главное – правильно использовать GET-параметры.

То есть не нужно переборщить с их количеством.

  1. Во-первых, если поставить слишком много параметров, то можно раз и навсегда забыть о ЧПУ (человекопонятные УРЛ), потому что ссылка будет очень длинной.
  2. Во-вторых, они очень сильно нагружают страницу, поэтому у людей со слабым интернетом или обладателям стареньких устройств будет тяжело.
  3. Ну и в-третьих, поисковые системы могут относить эти страницы в дубликаты основной, а это чревато низким рейтингом в поисковой выдачи.

И в большинстве случаев последнее – худший вариант. Потому что чем ниже ваш сайт в поисковой выдаче – тем меньше у вас новых посетителей.

Здесь стоит понять ещё, что некоторые GET-запросы урезает сервер.

У каждого есть свои лимиты. Но в среднем рекомендуется использовать не больше пяти.

Всё дело в том, что размер GET-запроса колеблется от 512 до 1024 килобайт. И если их будет много, то контролировать их все будет трудно. Как сайту, так и серверу.

Это приведёт к проблемам, урезаниям, а также подвисанию страниц.

А если вы используете ЧПУ, то GET-параметры показываться не будут.

Чтобы увидеть их в полном объёме, нужно будет отключить человекопонятные УРЛ.

 

PHP для начинающих. ГЕТ-параметры в PHP — смотреть видео

 

Что означает GET параметры в запросе?

Get-параметры в запросе обозначают собой фильтры.

Например, вы отправились в интернет-магазин. Вам нужно купить какой-то товар. Но вы знаете лишь группу из них.

Пусть, это будет видеокарта.

И вот вам нужно выбрать видеокарту по приемлемой цене.

Вы устанавливаете фильтр, а заодно выбираете нужную категорию.

И, чтобы не создавать отдельную страницу, разработчики сайтов используют GET-запросы. И все параметры, которые вы зададите, будут отображаться в URL.

Получается, что таким образом вы сможете узнать GET-параметры URL в запросе.

Если на сайте стоит человекопонятный УРЛ, то с этим могут возникнуть проблемы.

Но сейчас есть полно сервисов, которые помогают проанализировать всё до мельчайших деталей.

И GET-параметры – не исключение.

Воспользуйтесь сервисом от SerpStat.

Там вам нужно будет указать сайт, а дальше настройте сканирование под себя.

Вы сможете указать, сколько страниц робот должен проверить.

Через некоторое время он покажет вам, какие основные GET-параметры в запросах, а также – насколько их много.

При этом робот сам найдёт ошибки и укажет их вам. А значит, вы получите всю необходимую информацию.

И дальше вы сможете понять, какие у вас прописаны GET-параметры в запросе, и как их нужно изменить, чтобы сайт стал работать быстрее.

 

P.S. Возможно вам интересна будет запись: «DNS серверы — это что такое: подробное разъяснение простыми словами»

Заключение

GET-параметры – это лишь часть GET-запросов. И то, и то звучит сложно, но на деле понять не трудно.

Get-запросы – это более подробный поиск, а GET-параметры – это фильтры, по которым он осуществляется.

Например, интернет-магазин.

Вы там можете выбрать категорию товара указать его цену и т.д. И все фильтры – это GET-параметры.

Интуитивно понятно, что никому не было бы выгодно, если после каждого параметра сайт обновлялся.

К плюсам GET-параметров относится то, что такой ссылкой легко делиться с друзьями.

Но в этом и её главный минус – отсутствие конфиденциальности.

Всю информацию о фильтрах легко получить из URL, если глянуть на то, что написано после «?”.

Ещё один недостаток GET-запросов, в среднем их рекомендуется делать не больше 5.

Для работы с большими объёмами, а также для конфиденциальности лучше использовать POST.

Проверить частоту GET-запросов можно с помощью сервисов, например Serpstat.

 

P.S. А еще мы предоставляем услуги по продвижению ваших аккаунтов и групп в социальных сетях. Ознакомиться с ними вы сможете на этой странице


 

P.S.S. Чтобы написать данную статью, было потрачено много сил и времени. И если она принесла пользу вам, то возможно она принесет пользу и вашим друзьям.

Для этого нажмите и поделитесь с друзьями в социальных сетях.   А для нас это будет лучшей благодарностью и мотивацией на будущее!

А хотите первыми узнавать об обновлениях? Подписывайтесь на новости блога

PHP: POST и GET запросы для начинающих

Да да, все когда-то учились чему либо. Единственное что в этом плане отличает людей — кому-то учения даются легко, а кто-то не может разобраться в сути вопроса долгие месяцы. Сегодня мы поговорим о POST и GET запросах в HTML\PHP.

Сами запросы POST и GET (далее просто запросы) давно проросли корнями во все Интернет ресурсы. Если вдруг когда нибудь и появится альтернатива данным технологиям, то наверное это будет не скоро, да и, наверное, не нужно. Потому что наши запросы вполне полно выполняют задачу обмена данными между Интернет страницами.

Давайте рассмотри сначала запрос типа GET. Создадим файл index.php со стандартным html кодом, а так же разместим на нем форму, пусть это будет форма заказа товара.


<html>
<head></head>
<body>
   <form action="index.php" method="GET">
      <input type="text" name="orderName" />
      <input type="text" name="count" />
      <input type="submit" value="Заказать" />
   </form>   
</body>
</html>

Здесь обратим внимание на тег form. Он имеет два параметра action и method. Первый отвечает за адрес страницы, на которую мы будем передавать наши данные, второй — за метод, которым эти данные будут передаваться. Внутри данного тега описываются набор наших данных, которые мы хотим передавать. Обязательно данным присваиваются имена (параметр

name). Так же обязателен input типа submit, который является кнопкой, по нажатию на которую происходит отправка данных.

Давайте сохраним наш файл и откроем его в браузере.
Путь нашей страницы в браузере «…/index.php». На самой странице мы видим два поля для ввода и кнопку. Давайте вобъем в наши поля что-нибудь и нажмем на кнопку «Заказать». Наша страница обновилась. Давайте посмотрим на ее адрес: «…/index.php?orderName=Test&count=12». (я вбил в первое поле слово ‘Test’ во второе ’12’). Как мы видим адрес страницы немного поменялся. Дело в том что передача параметров GET запросом осуществляется путем их приписывания в строку адреса страницы. Параметры отделяются от основного адреса символом ‘?’, а разные параметры символом ‘&’. Структура параметров следующая:

название_параметра=значение. Название параметра будет совпадать со значением атрибута name в поле input.
Давайте немного подредактируем код страницы:


<html>
<head></head>
<body>
   <form action="index.php" method="GET">
      <input type="text" name="orderName" value=<?=$_GET["orderName"]?> >
      <input type="text" name="count" value=<?=$_GET["count"]?> >
      <input type="submit" value="Заказать" />
   </form>   
</body>
</html>

Теперь нажмем на кнопку «Заказать» еще раз. Как мы видим страница обновилась, однако наши поля остались заполнены. Это произошло благодаря тому, что мы указали значение по умолчанию для наших полей. Причем эти значения — полученный параметр GET. Как мы видим в PHP коде GET параметры являются массивом со строковым индексом равным имени параметра. Если сейчас поиграться с адресом сайта и в нем поменять значения параметров и нажать кнопку «Enter», то мы опять заметим картину с обновлением страницы и заполнением нашей формы.

Очевидно что пересылать секретные или служебные данные в GET запросе неправильно (и не безопасно). Его лучше использовать для передачи, например, id новости, которую стоит взять из базы или имени страницы, которую стоит отобразить.

Другое дело POST запрос. Работает он аналогично, однако не сохраняет параметры в строке адреса. Изменим нашу форму:


<html>
<head></head>
<body>
   <form action="index.php" method="POST">
      <input type="text" name="orderName" value=<?=$_POST["orderName"]?> >
      <input type="text" name="count" value=<?=$_POST["count"]?> >
      <input type="submit" value="Заказать" />
   </form>   
</body>
</html>

Как видно изменилось не многое, Однако! Откроем нашу страницу, вобъем что-нибудь в поля и нажмем кнопку «Заказать». Все сработало аналогично, однако (однако), как мы видим в строке запросов красуется адрес «…/index.php» без всякого рода параметров. Таким образом мы как бы «скрыли» наши данные от посторонних глаз. Конечно понятие скрыли, достаточно условное, так как эти данные все равно можно перехватить, но это уже другая история. Давайте допишем в наш адрес параметры «…/index.php?orderName=Trololo&count=100» и нажмем «Enter». Как мы видим страница загрузилась, однако даже не смотря на передачу параметров, поля оказались пустые. Это говорит о том что несмотря на большую схожесть, данные виды запросов никак не пересекаются между собой и если есть необходимость стоит писать обработчик для каждого типа запроса отдельно.

Думаю на этом хватит. Азы вопроса, я думаю, описаны с головой.

И еще немного… Не стоит забывать о проверке передаваемых параметров. Если Вы точно знаете, что параметр должен являться числом, то присекайте все попытки передачи не числового значения и т.п…

Как передать get параметр в ссылке php

GET запросы с помощью ссылок в PHP

В реальном мире, конечно же, пользователи вашего сайта не будут отправлять GET запросы вручную через адресную строку.

Для этого мы будем предоставлять им ссылки, содержащие параметры GET запроса. Пользователи будут переходить по ссылкам и автоматически отправлять GET запросы.

Давайте посмотрим на примерах. При переходе по следующей ссылке мы попадем на страницу index.php , отправив GET параметры:

Саму страницу в ссылке можно и не указывать, а просто начать адрес со знака ? . В этом случае при переходе по ссылке мы вернемся на текущую страницу, но с GET параметрами в адресной строке. Вот пример:

Сделайте три ссылки. Пусть первая передает число 1 , вторая — число 2 , третья — число 3 . Сделайте так, чтобы по нажатию на ссылку на экран выводилось ее число.

Сформируйте в цикле 10 ссылок. Пусть каждая ссылка передает свое число. Сделайте так, чтобы по нажатию на ссылку на экран выводилось ее число.

Сделайте так, чтобы с помощью GET запроса можно было вывести любой элемент этого массива. Для этого с помощью цикла foreach сделайте ссылку для каждого элемента массива.

Как передать метод get в ссылку

Как передать в ссылку метод get и что бы при нажатии появлялась определенная информация.

Ну так просто в параметр передайте значение.
А на странице уже работайте с ним.

&#x412;&#x441;&#x451; &#x435;&#x449;&#x451; &#x438;&#x449;&#x435;&#x442;&#x435; &#x43E;&#x442;&#x432;&#x435;&#x442;? Посмотрите другие вопросы с метками php php7 или задайте свой вопрос.

дизайн сайта / логотип &#169; 2021 Stack Exchange Inc; материалы пользователей предоставляются на условиях лицензии cc by-sa. rev 2021.11.30.40849

Нажимая &#171;Принять все файлы cookie&#187; вы соглашаетесь, что Stack Exchange может хранить файлы cookie на вашем устройстве и раскрывать информацию в соответствии с нашей Политикой в отношении файлов cookie.

Передача переменных в PHP. Методы GET и POST

Итак, мы снова продолжаем изучение основ PHP и в этой статье познакомимся со способами передачи переменных в PHP, а именно с методами GET и POST. Каждый из них имеет свои плюсы и минусы, и применяется в соответствующих ситуациях, речь о которых пойдет в данной статье. Мы также рассмотрим примеры кода, которые демонстрируют работу методов POST и GET.

Передача переменных при помощи метода GET

Данный метод передачи переменных применяется в PHP для передачи переменных в файл при помощи адресной строки. То есть переменные передаются сразу через адресную строку браузера. Примером может быть, например, ссылка на статью в WordPress без использования ЧПУ (SEF), которая имеет примерно следующий вид:

То есть в данном случае передается переменная $p со значением 315. Теперь давайте более подробно на примере рассмотрим работу метод GET. Пускай нам нужно передать в файл три переменных $a, $b и $c методом GET и вывести их сумму на экран. Для этого можно использовать следующий код.

Поскольку все переменные перед передачей будут помещаться в глобальный массив GET (Массивы в PHP), то мы первым делом присваиваем нашим переменным значения соответствующих элементов массива GET. Делаем это в самом начале во избежание разнообразных ошибок при передаче переменных. Далее для демонстрации работы прописываем произвольную формулу и выводим результат на экран.

Для проверки работы метода GET достаточно просто добавить к ссылке на файл знак вопроса «?» и через амперсанд «&» перечислить переменные с их значениями. Пускай у нас есть файл get.php, который лежит в корне сайта https://archive.dmitriydenisov.com. Для того чтобы передать в файл переменные, достаточно прописать в адресной строке следующее.

Как видно с примера, сначала мы добавляем знак вопроса сразу после названия файла. Далее прописываем переменную и через равно указываем ее значение. После этого через амперсанд аналогичным образом перечисляем другие переменные. Теперь при переходе по этой ссылке нам выведется сумма переменных $a, $b и $c.

Данный способ очень простой и не требует создания дополнительных файлов. Все необходимые данные поступают прямо через адресную строку браузера.

Ну а теперь давайте перейдем ко второму способу передачи переменных в PHP – методу POST.

Передача переменных в PHP при помощи метода POST

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

Код первого файла с формой для отправки данных. Дадим ему название post-1.php

  • action – указываем файл, в который будут передаваться переменные.
  • method – метод передачи переменных. В нашем случае это метод POST.
  • name – название формы. Одновременно в файл будет передана переменная с таким именем.
  • name – имена переменных. В нашем случае это имя и фамилия (переменные name и lastname).
  • type – тип поля. В нашем случае это текстовое поле.
  • name – имя кнопки и переменной, которая будет передана вместе с другими переменными.
  • type – тип кнопки. В нашем случае это кнопка для отправки данных.
  • value – текст на кнопке.

Код второго файла, который будет служить приемником переменных. Назовем его post-2.php

Как и с методом GET, мы первым делом присваиваем переменным значения соответствующих элементов глобального массива POST. Далее для наглядности выводим эти переменные на экран при помощи оператора вывода echo.

Теперь при загрузке первого файла у нас загрузится форма. После введения данных жмем по кнопке «Отправить», в результате чего в новой вкладке у нас откроется страница со вторым файлом, на которой выведутся значения, прописанные в форме на предыдущей странице. То есть второму файлу будут переданы значения переменных с первого файла.

На этом данная статья про передачу переменных в PHP подошла к концу. Если вы не хотите пропустить появления других статей на блоге, рекомендую подписаться на новостную рассылку любым удобным способом в пункте «Подписка» либо воспользоваться формой ниже.

POST и GET запросы для начинающих. 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) Думаю я уже достаточно объяснил что из этого получится и какие параметры в какой массив попадут.

1. Протокол HTTP. Введение

Сразу хочу уточнить одну маленькую вещь. Страшное слово протокол есть не что иное, как соглашение множества людей, просто в один прекрасный момент люди решили: «Давайте будем делать так, и тогда все будет в порядке». Бояться нечего, все просто до безобразия и это безобразие мы сейчас будем вскрывать. Итак, что же это такое протокол HTTP и с чем его едят?

1.1 Клиент и сервер

Чудес в мире, а тем более в мире программизма и интернета не бывает! Усвойте это как незыблемую истину. И, если программа не работает или работает не так как хочется, то, значит, скорее всего, она либо написана не правильно, либо содержит ошибки. Итак, как же все-таки браузер просит сервер прислать ему хоть что-нибудь? Да очень просто! Надо только немного расслабиться и начать получать удовольствие от процесса:-)

1.2. Пишем наш первый HTTP запрос

Если Вы думаете, что все слишком сложно, то Вы ошибаетесь. Человек так устроен, что просто не способен создавать что-то сложное, иначе он сам в этом запутается:-) Итак, есть браузер и есть Web-сервер. Инициатором обмена данными всегда выступает браузер. Web-сервер никому, никогда просто так ничего не пошлет, чтобы он что-нибудь отправил браузеру — надо, чтобы браузер об этом попросил. Простейший HTTP запрос моет выглядеть, например, так:

GET http : //www.php.net/ HTTP/1.0rnrn


* GET (В переводе с английского означает «получить») — тип запроса, тип запроса может быть разным, например POST, HEAD, PUT, DELETE (часть из них мы рассмотрим ниже).
* http://www.php.net/ — URI (адрес) от которого мы хотим получить хоть какую-нибудь информацию (естественно мы надеемся подучить HTML страницу).
* HTTP/1.0 — тип и версия протокола, который мы будем использовать в процессе общения с сервером.
* rn — конец строки, который необходимо повторить два раза, зачем, станет понятно немного позднее.

Вы можете выполнить данный запрос очень просто. Запустите программу telnet.exe, введите в качестве хоста www.php.net, укажите порт 80, и просто наберите данный запрос, нажав два раза Enter в качестве rnrn. В ответ вы получите HTML код главной страницы сайта www.php.net.

1.3 Структура запроса

Рассмотрим, из чего состоит HTTP запрос. Все достаточно просто. Начнем с того, что HTTP запрос — это вполне осмысленный текст. Из чего же он состоит в общем случае? Будем рассматривать протокол HTTP 1.0. Итак :

Request — Line [ General — Header | Request — Header | Entity — Header ] rn [ Entity — Body ]


* Request-Line — строка запроса
*

Формат : «Method Request-URI HTTP-Versionrn»
* 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».

Нам крайне интересны методы обработки GET и POST. Методом GET можно просто передать параметры в скрипт, а методом POST можно эмулировать submit формы.

Для метода GET, Request-URI может выглядеть, например, так: «/index.html?param1=1&param2=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 | HEADn».
Параметр игнорируется при указании метода обработки POST в Request-Line. Задает допустимые методы обработки запроса. Прокси сервера не модифицируют параметр Allow и он в неизменном виде доходит до сервера.

* From — e-mail адрес, пославшего запрос.
Формат: «From: adderssrn».
Например, «From: [email protected]».

* If-Modified-Since — указывает, что запрос не модифицировался с такого-то времени.
Формат: «If-Modified-Since: datern»
Используется только для метода обработки GET. Дата указывается по Гринвичу в таком же формате, как и для параметра Date в General-Header.

* Referrer — абсолютная ссылка на страницу, с которой произошла инициация запроса, т. е. ссылка на страницу, с которой пользователь перешел на нашу.
Формат: «Referrer: urln».
Пример: «Referrer: www.host.ru/index.htmln».
* User-Agent — тип браузера.
Например: «User-Agent: Mozilla/4.0n»

* 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-gzipn». Символ «|» означает слово «или», то есть то или то или то и.т.д.
Другой тип может указывать на способ кодирования данных, например, для метода POST: «Сontent-Encoding: application/x-www-form-urlencodedn».

* Content-Length — количество байт, пересылаемых в Entity-Body. Значение Content-Length имеет совсем другой смысл для данных, пересылаемых в формате MIME, где он выступает как параметр описания части данных — «external/entity-body». Допустимыми являются целые числа от нуля и больше.
Пример: «Content-Length: 26457n».

* Content-Type — тип передаваемых данных.
Например: «Content-Type: text/htmln».

* Expires — Время, когда страница должна быть удалена из кэша браузера.
Формат: «Expires: daten». Формат даты алогичен формату даты для параметра Date из General-Header.

* Last-Modified — время последнего изменения пересылаемых данных.
Формат: «Last-Modified: daten». Формат даты алогичен формату даты для параметра Date из General-Header.

* Extention-header — часть заголовка, которая может предназначаться, например, для обработки браузером, или другой программой, которая принимает документ. В данной части можно описывать свои параметры в формате «ParameterName: parametervaluen». Данные параметры будут игнорироваться, если программа-клиент не знает, как их обработать.
Например: «Cookie: r=1rn» — устанавливает всем известные печеньки для страницы.

А теперь после таких страшных слов давайте попробуем немного успокоиться и понять, что же нам надо? Понимать мы естественно будем на примерах.

Давайте представим, что нам надо получить страницу с сайта, передав Cookies (Печеньки), иначе нас просто пошлют как незванных гостей, и более того, известно, что на данную страницу пускают только после того, как Вы побывали на главной странице сайта.

2 Метод GET

Напишем наш запрос.

GET http :
Host : www . site . rurn

Cookie : income = 1rn
rn


Данный запрос говорит нам о том, что мы хотим получить содержимое страницы по адресу 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.0rn
Host : www . site . rurn
Referer : http : //www.site.ru/index.htmlrn
Cookie : income = 1rn
rn


Логин у нас «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 для передачи логина и пароля, который был рассмотрен в предыдущей главе:

POST http : //www.site.ru/news.html HTTP/1.0rn
Host : www . site . rurn
Referer : http : //www.site.ru/index.htmlrn
Cookie : income = 1rn
Content — Type : application / x — www — form — urlencodedrn
Content — Length : 35rn
rn


Здесь мы видим пример использования Content-Type и Content-Length полей заголовка. Content-Length говорит, сколько байт будет занимать область данных, которая отделяется от заголовка еще одним переводом строки rn. А вот параметры, которые раньше для запроса GET помещались в Request-URI, теперь находятся в Entity-Body. Видно, что они формируются точно также, просто надо написать их после заголовка. Хочу отметить еще один важный момент, ничто не мешает, одновременно с набором параметров в Entity-Body, помещать параметры с другими именами в Request-URI, например:

POST http : //www.site.ru/news.html?type=user HTTP/1.0rn
…..
rn
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.0rn
Host : www . site . rurn
Referer : http : //www.site.ru/index.htmlrn
Cookie : income = 1rn

Content — Length : 209rn
rn
— 1BEF0A57BE110FD467Arn
Content — Disposition : form — data ; name = «login» rn
rn
Petya Vasechkinrn
— 1BEF0A57BE110FD467Arn
Content — Disposition : form — data ; name = «password» rn
rn
qqrn
— 1BEF0A57BE110FD467A — rn


Теперь давайте разбираться в том что написано. 🙂 Я специально выделил некоторые символы rn жирным, чтобы они не сливались с данными. Присмотревшись внимательно можно заметить поле boundary после Content-Type. Это поле задает разделитель разделов — границу. В качестве границы может быть использована строка, состоящая из латинских букв и цифр, а так же из еще некоторых символов (к сожалению, не помню каких еще). В теле запроса в начало границы добавляется «—«, а заканчивается запрос — границей, к которой символы «—» добавляются еще и в конец. В нашем запросе два раздела, первый описывает поле login, а второй поле password. Content-Disposition (тип данных в разделе) говорит, что это будут данные из формы, а в поле name задается имя поля. На этом заголовок раздела заканчивается и далее следует область данных раздела, в котором помещается значение поля (кодировать значение не требуется!).

Хочу обратить Ваше внимание та то, что в заголовках разделов не надо использовать Content-Length, а вот в заголовке запроса надо и его значение является размером всего Entity-Body, стоящего после второго rn, следующего за Content-Length: 209rn. Т.е. Entity-Body отделяется от заголовка дополнительным переводом строки (что можно заметить и в разделах).

А теперь давайте напишем запрос для передачи файла.

POST http : //www.site.ru/postnews.html HTTP/1.0rn
Host : www . site . rurn
Referer : http : //www.site.ru/news.htmlrn
Cookie : income = 1rn
Content — Type : multipart / form — data ; boundary = 1BEF0A57BE110FD467Arn
Content — Length : 491rn
rn
— 1BEF0A57BE110FD467Arn
Content — Disposition : form — data ; name = «news_header» rn
rn
Пример новостиrn
— 1BEF0A57BE110FD467Arn
Content — Disposition : form — data ; name = «news_file» ; filename = «news.txt» rn
Content — Type : application / octet — streamrn
Content — Transfer — Encoding : binaryrn
rn
А вот такая новость , которая лежит в файле news . txtrn
— 1BEF0A57BE110FD467A — rn


В данном примере в первом разделе пересылается заголовок новости, а во втором разделе пересылается файл news.txt. Внимательный да увидит поля filename и Content-Type во втором разделе. Поле filename задает имя пересылаемого файла, а поле Content-Type — тип данного файла. Application/octet-stream говорит о том, что это стандартный поток данных, а Content-Transfer-Encoding: binary говорит на о том, что это бинарные данные, ничем не закодированные.

Очень важный момент. Большинство CGI скриптов написано умными людьми, поэтому они любят проверять тип пришедшего файла, который стоит в Content-Type. Зачем? Чаще всего закачка файлов на сайтах используется для получения картинок от посетителя. Так вот, браузер сам пытается определить что за файл посетитель хочет отправить и вставляет соответствующий Content-Type в запрос. Скрипт его проверяет при получении, и, например, если это не gif или не jpeg игнорирует данный файл. Поэтому при «ручном» формировании запроса позаботьтесь о значении Content-Type, чтобы оно было наиболее близким к формату передаваемого файла.

Image/gif для gif
image/jpeg для jpeg
image/png для png
image/tiff для tiff (что используется крайне редко, уж больно емкий формат)

В нашем примере формируется запрос, в котором передается текстовый файл. Точно так же формируется запрос для передачи бинарного файла.

4. Постскриптум.

Думаю, что о передаче запросов на сервер не стоит рассказывать подробно. Это уже дело чисто РНР техники:-). Достаточно внимательно прочитать раздел о функциях работы с сокетами, или о функциях модуля CURL в официальной документации РНР.

Из выше сказанного, надеюсь теперь понятно, почему вопрос: «Как мне сформировать POST запрос, используя функцию header?» — бессмысленен. Функция header(string) добавляет запись только в заголовок запроса, но никак не в тело запроса.

Этот пост — ответ на вопрос, заданный в комментарии к одной из моих статей.

В статье я хочу рассказать, что же из себя представляют HTTP-методы GET/POST/PUT/DELETE и другие, для чего они были придуманы и как их использовать в соответствии с REST.

Итак, что же представляет из себя один из основных протоколов интернета? Педантов отправлю к RFC2616 , а остальным расскажу по-человечески:)

Этот протокол описывает взаимодействие между двумя компьютерами (клиентом и сервером), построенное на базе сообщений, называемых запрос (Request) и ответ (Response). Каждое сообщение состоит из трех частей: стартовая строка, заголовки и тело. При этом обязательной является только стартовая строка.

Стартовые строки для запроса и ответа имеют различный формат — нам интересна только стартовая строка запроса, которая выглядит так:

METHOD URI HTTP/VERSION ,

Где METHOD — это как раз метод HTTP-запроса, URI — идентификатор ресурса, VERSION — версия протокола (на данный момент актуальна версия 1.1).

Заголовки — это набор пар имя-значение, разделенных двоеточием. В заголовках передается различная служебная информация: кодировка сообщения, название и версия браузера, адрес, с которого пришел клиент (Referrer) и так далее.

Тело сообщения — это, собственно, передаваемые данные. В ответе передаваемыми данными, как правило, является html-страница, которую запросил браузер, а в запросе, например, в теле сообщения передается содержимое файлов, загружаемых на сервер. Но как правило, тело сообщения в запросе вообще отсутствует.

Рассмотрим пример.

Запрос:
GET /index.php HTTP/1.1 Host: example.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9b5) Gecko/2008050509 Firefox/3.0b5 Accept: text/html Connection: close
Первая строка — это строка запроса, остальные — заголовки; тело сообщения отсутствует

Ответ:
HTTP/1.0 200 OK Server: nginx/0.6.31 Content-Language: ru Content-Type: text/html; charset=utf-8 Content-Length: 1234 Connection: close … САМА HTML-СТРАНИЦА…

Вернемся к стартовой строке запроса и вспомним, что в ней присутствует такой параметр, как URI. Это расшифровывается, как Uniform Resource Identifier — единообразный идентификатор ресурса. Ресурс — это, как правило, файл на сервере (пример URI в данном случае «/styles.css»), но вообще ресурсом может являться и какой-либо абстрактный объект («/blogs/webdev/» — указывает на блок «Веб-разработка», а не на конкретный файл).

Тип HTTP-запроса (также называемый HTTP-метод) указывает серверу на то, какое действие мы хотим произвести с ресурсом. Изначально (в начале 90-х) предполагалось, что клиент может хотеть от ресурса только одно — получить его, однако сейчас по протоколу HTTP можно создавать посты, редактировать профиль, удалять сообщения и многое другое. И эти действия сложно объединить термином «получение».

Для разграничения действий с ресурсами на уровне HTTP-методов и были придуманы следующие варианты:

  • GET — получение ресурса
  • POST — создание ресурса
  • PUT — обновление ресурса
  • DELETE — удаление ресурса
Обратите внимание на тот факт, что спецификация HTTP не обязывает сервер понимать все методы (которых на самом деле гораздо больше, чем 4) — обязателен только GET, а также не указывает серверу, что он должен делать при получении запроса с тем или иным методом. А это значит, что сервер в ответ на запрос DELETE /index.php HTTP/1.1 не обязан удалять страницу index.php на сервере, так же как на запрос GET /index.php HTTP/1.1 не обязан возвращать вам страницу index.php, он может ее удалять, например:)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.

Похожие статьи:

Загрузка. Пожалуйста, подождите…

Как получить параметры URL.

В этом руководстве по PHP для начинающих я покажу вам, как получить параметры строки запроса из URL-адреса. Я также расскажу вам, как избежать некоторых наиболее распространенных ошибок.

Возьмем в качестве примера следующий URL-адрес, который содержит два параметра GET:

page.php?id=23&page=34

В приведенном выше URL-адресе есть два параметра GET. id , который содержит значение 23 и страница , который содержит значение 34.

Теперь предположим, что мы хотим получить эти значения, чтобы использовать их в нашем PHP-скрипте.

Если мы хотим получить значения этих двух параметров, мы можем просто получить доступ к суперглобальному массиву $_GET следующим образом:

 //Получить два наших параметра GET.
$id = $_GET['id'];
$страница = $_GET['страница']; 

Хотя код PHP будет работать, он предполагает, что рассматриваемые параметры GET всегда будут существовать. В результате всегда существует вероятность того, что наш сценарий выдаст уродливое уведомление о неопределенном индексе, если пользователь вручную или по ошибке удалит один из наших параметров из URL-адреса.

Это приведет к тому, что PHP выдаст уродливое сообщение об ошибке:

Примечание: неопределенный индекс: идентификатор в /path/to/file.php в строке 4

Чтобы предотвратить это, вам нужно будет проверить, существует ли переменная GET перед тем, как вы попытаетесь получить ее:

 $id = ложь;
если(isset($_GET['id'])){
    $id = $_GET['id'];
}

$страница = ложь;
если(isset($_GET['страница'])){
    $страница = $_GET['страница'];
} 

В приведенном выше примере мы используем функцию PHP isset , чтобы проверить, действительно ли существует рассматриваемый параметр.Если это так, мы присваиваем его одной из наших переменных. Если это не так, то наши переменные сохраняют свои значения FALSE по умолчанию.

Никогда не доверяйте параметрам GET как таковым. Всегда подтверждайте их.

К параметрам

GET следует всегда относиться с особой осторожностью.

  1. Нельзя предполагать, что они будут существовать всегда.
  2. Если они существуют, нельзя сбрасывать со счетов возможность того, что пользователь подделал рассматриваемый URL-адрес.

т. е. если вы ожидаете, что id будет целочисленным значением, и пользователь решит вручную изменить его на «blahblahblah», ваш PHP-скрипт должен быть в состоянии справиться с этим сценарием.Параметры URL являются внешними переменными, а внешним переменным никогда нельзя доверять.

Никогда не выводить параметры GET напрямую на страницу.

Распечатка параметров GET без их очистки — это путь к катастрофе, поскольку это сделает ваше веб-приложение широко открытым для XSS-атак.

Возьмем следующий пример:

 $страница = ложь;
если(isset($_GET['страница'])){
    $страница = $_GET['страница'];
}

если($страница !== ложь){
   echo ' 

Страница: ' .$ страница . '

'; }

Здесь я все сделал правильно, кроме последнего шага:

  1. Я проверил, установлен ли параметр GET, прежде чем пытаться получить доступ к его значению.
  2. Я убедился, что не печатаю номер страницы, если она не существует.

Однако я не очищал переменную перед тем, как распечатать ее. Это означает, что злоумышленник может просто заменить мою переменную GET на некоторый HTML или JavaScript и заставить ее выполняться при загрузке страницы.Затем они могут перенаправить других пользователей на эту «испорченную» ссылку.

Чтобы защититься от этого, мы можем просто использовать функцию PHP htmlentities :

 //Защита от XSS
если($страница !== ложь){
   echo ' 

Страница: ' . htmlсущности($страница) . '

'; }

Функция htmlentities будет защищать от XSS, преобразовывая все специальные символы в соответствующие объекты HTML. Например: что-то вроде