Вводная лекция о структуре HTTP-запроса
Представьте что вы - редколлегия студенческого журнала. Денег на издание журнала “в формате мертвого дерева” само собой у вас нет, поэтому вы мудро решаете издаваться в web, допустим на “шаровом” сервере предоставленном университетом. Вы отсканировали архив статей и набили новые статьи в файлы. Теперь надо как то разместить их в web. Можно создать весь сайт на чистом HTML, тупо верстая каждую страницу… Но именно для того, чтобы не заниматься тупой работой, создавая однотипные файлы Statya1.html, Statya2.html и так еще 348 раз, можно отмучаться один раз, создав файл Statya.php и с помощью него отображать все 350 статей вашего студенческого журнала. Но все-же чего то не хватает. Как же скрипт Statya.php узнает, какую именно статью пожелал увидеть пользователь на экране своего браузера ? Для этой благородной цели был разработан механизм передачи дополнительных параметров от клиента серверу при запросе.
Допустим вы хотите создать страницу на которой выводится 350 ссылок на все статьи вашего сайта. Каждая из ссылок должна иметь такой вид: Statya.php?id=1 Statya.php?id=2 и так далее. Такая запись позволяет передать на сервер не только название запрашиваемого скрипта, но и идентификатор статьи которую хотите вывести на экран. Если ваши статьи идентифицируются не числовым ключем, а текстовым, то можно например передавать такой параметр: Statya.php?nazvanie=Peredacha+dannih+v+HTTP+zaprose. Пробелы в таком случае будут заменены символом +, а также будут заменены другие служебные символы. Это требование накладывается стандартом RFC1738 который определяет вид строки запроса (URI). Так как параметры очевидно являются частью URI - то требования стандарта распространяются и на них. Если надо передать больше чем 1 параметр, строка запроса выглядит так: Statya.php?id=230&category=10 - то есть параметры разделяются символом амперсанда (&). Когда пользователь нажмет такую ссылку, браузер пошлет серверу запрос такого вида:
GET /Statya.php?id=23 HTTP/1.1 Host: student-journal.comТо есть, браузер, используя метод протокола HTTP GET, “попросит” сервер выдать (или выполнить) Statya.php и все параметры будут переданы тут-же вместе с именем запрошенного файла. Достоинство метода очевидно - можно легко сгенерировать ссылку нужного вида и передать серверу на обработку. Недостаток этого метода в том, что таким образом нельзя передать данные большого объема или содержащие символы не из таблицы ASCII и двоичную информацию (файлы). Хотя стандарт RFC2616 не накладывает ограничения длину заголовка запроса вообще и на длину строки запроса (URI) в частности, такие ограничения накладываются браузерами, web-серверами и прокси-серверами. Обычно не стоит делать длину запроса больше 2000 символов.
Форма как один из важнейших HTML-элементов позволяет передавать серверу вводимые пользователем сайта данные. В простейшем, но рабочем, случае форму можно определить как:
<form action="search.php"> <input type="text" name="search"/> <input type="submit" value="Search"/> </form>Эта форма поиска примет от пользователя строку текста в поле и отправит на сервер странице search.php. Так как мы не задали атрибут method, по умолчанию будет использован метод GET. Запрос посылаемый серверу в этом случае ничем не будет отличаться от первого случая - когда пользователь нажимал на ссылку.
GET /search.php?search=blabla HTTP/1.1 Host: student-journal.comПолучается, мы опять сталкиваемся с ограничением на длину вводимых данных. Как-же например передать на сервер текст статьи из 20-30 страниц ? Надо воспользоваться методом POST. При запросе GET не используется тело запроса, а только заголовок. При запросе POST можно передать данные в теле запроса. Для этого изменим форму:
<form method="post" action="search.php"> <input type="text" name="search"/> <input type="submit" value="Search"/> </form>В этом случае, при посылаемый запрос будет иметь такой вид:
POST /search.php HTTP/1.1 Content-Type: application/x-www-form-urlencoded Content-Length: 13 Host: student-journal.com search=blablaКак видно, параметры теперь посылаются в теле запроса, а длина запрашиваемого URL значительно сокращается. Опять же, по стандарту нет никаких ограничений на длину посылаемых в теле запроса данных, однако такие ограничения вводятся администраторами веб-серверов для предотвращения атак на сайты. В любом случае, эти ограничения происходят из здравого смысла, и например для сайтов посвященных музыке ограничения будут в районе десятков мегабайт — чтобы можно было загружать mp3 файлы. Загрузка файлов через веб-браузер - тема интересная и заслуживает отдельного изложения.