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

Параметры передаваемые в строке запроса

Допустим вы хотите создать страницу на которой выводится 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 файлы. Загрузка файлов через веб-браузер – тема интересная и заслуживает отдельного изложения.

Ссылки по теме

Стандарт на посылку форм в HTTP запросах
Записка Microsoft о максимальной длине строки запроса (URI)
Опыты по определению максимальной длины строки запроса

Когда вы пробовали создавать первые HTML страницы, вы либо открывали их через двойное нажатие мышкой браузером прямо с диска (файловой системы), либо выкладывали на локальный или удаленный web-сервер и открывали браузером URL. В обоих случаях, результать один и тот-же – вы видете HTML страницу в браузере. Однако, когда вы открываете страницу расположенную на web-сервере через HTTP протокол, неявно передается достаточно много дополнительной информации, а именно заголовки HTTP. Протокол передачи – это договор между сервером и клиентом о допустимых вопросах и ответах. Протокол задокументирован в виде стандарта RFC2616.

Общение между сервером и клиентом может быть описано как разговор человека в магазине:

Клиент: Привет! Я Мозилла-Файрфокс, можно-ли мне файлик products.html с хоста shop.com ?
Сервер: Да, есть у меня такой файлик, он имеет тип text|/html и вот его содержимое.
(Клиент получает целиком файл, смотрит на него и натыкается на тег <img>)
Клиент: Привет! Я Мозилла-Файрфокс, можно ли мне файлик product.jpg с хоста shop.com ?
Сервер: Да, есть у меня такой файлик, он имеет тип image/jpg и вот его содержимое.
(Клиент получает файл и отображает на экране)

И так далее. Что кстати сразу замечу – сервер понятия не имеет что оба раза это был один и тот же клиент. HTTP-протокол называется “stateless” – он не хранит состояние соединения и передачи. Вопрос – ответ – “вiльна каса”.

Вернемся к заголовкам. Они бывают двух типов – заголовки запроса (request) и заголовки ответа (response). Например, вы набираете URL нашего сайта и он открывается. На языке современного протокола HTTP версии 1.1 это выглядит так:

Запрос:

GET / HTTP/1.1
Host: iwannabedeveloper.com
User-Agent: Mozilla/5.0


Ответ сервера:

HTTP/1.1 200 OK
Date: Mon, 25 Jun 2007 13:50:37 GMT
Server: Apache/2.0.46 (CentOS)
Accept-Ranges: bytes
X-Powered-By: PHP/4.3.2
X-Pingback: http://iwannabedeveloper.com/xmlrpc.php
Content-Encoding: gzip
Vary: Accept-Encoding
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8

После заголовков следует содержимое страницы в виде HTML:


< !DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

Выглядит довольно просто. В запросе клиент указывает какой файл он просит сервер вернуть и опознает себя (хоть и не обязан) как Mozilla. Запрос посылается методом GET, и есть еще метод POST, но о нем в следующий раз. В ответ клиент получает информацию о запрашиваемом файле и сам файл. Наиболее значимые заголовки ответа – это Content-Type и Status. Content-Type сообщает клиенту какого типа файл будет передаваться, а в случае HTML, какая кодировка будет использоваться. Список типов файлов (MIME-types) стандартизована и с ней можно ознакомится здесь. Status – (200 ОК) – это стандартизованный код выполнения запроса. Код 200 означает что запрошенный файл был найден и успешно передан клиенту. Например код 404 означает что файл не найден, код 301 – что файл перемещен в другое место, а код 500 – что во время выполнения запроса произошла непоправимая ошибка на сервере. Список кодов описан в упомянутом стандарте RFC2616.

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