Эмуляция браузера через telnet

Accept

Cookie

Content-length

Referer

User-Agent

Формат: User-Agent: Mozilla/4.5[en] (Win95; I)

Переменная окружения: HTTPJJSER_AGENT

Уточняет версию браузера (в данном случае это Netscape Navigator).

Формат: Referer: икь_адрес

Переменная окружения: HTTP_REFERER

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

Формат: Content-length: длина

Переменная окружения: CONTENT_LENGTH

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

Формат: Cookie: значения Сооkies

Переменная окружения: HTTP COOKIE

Здесь хранятся все Cookies в URL-кодировке (о Cookies мы подробнее поговорим в следующей главе).

Формат: Accept: text/html, text/plain, image/gif, image/jpeg

Переменная окружения: НТТР АССЕРТ

В этом заголовке браузер перечисляет, какие типы документов он

"понимает". Перечисление идет через запятую. К сожалению, в последнее время браузеры стали несколько небрежны и часто присылают в этом заголовке значение */*, что обозначает любой тип.

Существует еще множество заголовков запроса (часть из них востребуются только протоколом HTTP 1.1).

Между прочим, при передаче запроса браузер "притворяется" пользователем, который запустил telnet-клиента (программу, которая, грубо говоря, умеет подключаться к заданному IP-адресу и порту, посылать по нему то, что набирается на клавиатуре, и отображать на экране поступающие "снаружи" данные) и вводит строки заголовков вручную — т. е., в текстовом виде. Например, вместо того чтобы набрать в браузере http://www.somehost.com/, попробуйте в командной строке ОС (Unix, Windows 95/98/NT/2000 или любой другой) выполнить следующие команды (вместо записи <Enter> нажимая соответствующую клавишу):

telnet www.somehost.com 80<Enter>

GET /index.html HTTP/1.0<Enter>

<Enter>

Вы увидите, как перед вами промелькнут строки HTML-документа index.html. Если у вас указанная процедура не удалась, и сервер все время шлет сообщение "Bad Request", то проверьте регистр символов, в котором вы набираете команды. Все буквы должны быть заглавными, а название протокола HTTP/I.0 — идти без пробелов.

Посмотрим теперь, как работает сервер. А происходит все следующим образом: он считывает все заголовки запроса и дожидается маркера "\n\n" (или, что то же самое, "пустого" заголовка), а как только его получает, начинает разбираться — что же ему за информация пришла, и выполнять соответствующие действия.

С помощью заголовков реализуются такие механизмы, как контроль кодировок, Cookies, метод POST и т. д. Если же сервер не понимает какого-то заголовка, он его либо пропускает, либо жалуется отправителю (в зависимости от воли администратора, который настраивал сервер).

Метод POST

А теперь в предыдущем примере зададим вместо GET слово POST и после последнего заголовка (маркера "\n\n" начнем передавать какие-то данные? В этом случае сервер их воспримет и также передаст сценарию. Только нужно не забыть проставить заголовок Content-length в соответствии с размером данных, например:

POST /script.cgi HTTP/1.0\n

Content-length: 5\n\n

Test!

Сервер начнет обработку запроса, не дожидаясь передачи данных после

маркера конца заголовков. Иными словами, сценарий запустится сразу же после отправки "\n\n", а уж ждать или не ждать, пока придет строка Test! длиной 5 байтов — его дело.

Последнее означает, что сервер никак не интерпретирует POST-данные (точно так же, как он не интерпретирует некоторые заголовки), а пересылает их непосредственно сценарию. Но как же сценарий узнает, когда данные кончаются, т. е. когда ему прекращать чтение информации, поступившей от браузера? В этом ему поможет переменная окружения content-Length, и именно на нее следует ориентироваться.

Зачем нужен метод POST? В основном для того, чтобы передавать большие объемы данных. Например, при загрузке файлов через Web (см. ниже) или при обработке больших форм. Кроме того, метод POST часто используют для эстетических целей: дело в том, что при применении GET, URL сценария становится довольно длинным и неизящным, а POST-запрос оставляет URL без изменения.

Дата добавления: 2014-01-06