GET /cgi-bin/form_handler.cgi?name=Vasya&okbutton=OK HTTP/1.0\r\n

Host: www.example.com\r\n

\r\n

Нажатие submit-кнопки в форме с методом отправки "GET" аналогично вводу соответствующего URL (со знаком вопроса и данными формы в конце) в адресной строке браузера: http://www.example.com/cgi-bin/form_handler.cgi?name=Vasya&okbutton=OK

На самом деле, метод GET используется всегда, когда Вы запрашиваете с сервера какой-либо документ, просто введя его URL, или щелкнув по ссылке. При использовании <form method="GET" ... >, к URL просто добавляются знак вопроса и данные формы.

Как же нам в сценарии получить строку параметров, переданную после знака вопроса в URL при обращении к сценарию? Для этого можно проанализировать переменную окружения QUERY_STRING, которая в РНР доступна под именем $_SERVER[QUERY_STRING].

Напишем пример, чтобы это проиллюстрировать (листинг qs.php).

Листинг qs.php. Вывод параметров командной строки.

<?php

echo «Данные из командной строки: $_SERVER[QUERY_STRING]»;

?>

Если теперь запустить этот сценарий из браузера (перед этим сохранив его в корневом каталоге сервера) таким образом:

http://localhost/qs.php?this+is+the+world/

то получим документ следующего содержания: Данные из командной строки: this+is+the+world

Обратите внимание на то, что URL-декодирование символов не произошло: строка $_server [' query_string '], как и одноименная переменная окружения, всегда приходит в той же самой форме, в какой она была послана браузером.

Так как РНР изначально создавался именно как язык для Web-программирования, то он дополнительно проводит некоторую работу с переменной query_string перед передачей управления сценарию. А именно, он разбивает ее по пробельным символам (в примере пробелов нет, их заменяют символы +, но эти символы РНР также понимает правильно) и помещает полученные кусочки в массив-список $argv, который впоследствии может быть проанализирован в программе.

Массив $argv используется при программировании на РНР крайне редко, что связано с большими возможностями интерпретатора по разбору данных, поступивших от пользователя. Однако в некоторых (учебных) ситуациях его применение оправдано.

Возможно, все эти технические подробности кажутся невероятно скучными и даже ненужными ("а при чем тут PHP?"). Но это основы работы по протоколу HTTP, которые необходимо знать каждому web-программисту.

Теперь заменим первую строку нашей формы на следующую:

<form method="POST" action="/cgi-bin/form_handler.cgi">

Мы указали метод отправки "POST". В этом случае данные отправляются на сервер несколько другим способом:

telnet www.example.com 80

POST /cgi-bin/form_handler.cgi HTTP/1.0\r\n

Host: www.example.com\r\n

Content-Type: application/x-www-form-urlencoded\r\n

Content-Length: 22\r\n

\r\n

name=Vasya&okbutton=OK

При использовании метода POST данные формы отправляются уже после "двух Enter-ов" - в теле запроса. Все, что выше - на самом деле заголовок запроса (и когда мы использовали метод GET, данные формы отправлялись в заголовке).

Для того, чтобы сервер знал, на каком байте закончить чтение тела запроса, в заголовке присутствует строка Content-Length; о том же, что данные формы будут переданы виде параметр1=значение1&параметр2=значение2..., причем значения передаются в виде urlencode - то есть, точно так же, как и с помощью метода GET, но в теле запроса, - серверу сообщает заголовок "Content-Type: application/x-www-form-urlencoded".

О том, что такое urlencode - чуть ниже.

Преимущество метода POST: отсутствие ограничения на длину строки с данными формы.

При использовании метода POST невозможно отправить форму, просто "зайдя по ссылке", как было с GET.

Для краткости изложения, введем термины "GET-форма" и "POST-форма", где префикс соответствует значению атрибута method тэга <form>.

При использовании POST-формы, в ее атрибуте action можно указать после знака вопроса и параметры GET-формы. Таким образом, метод POST включает в себя и метод GET.

Страницы: 1, 2, 3, 4