Практическое исследование заголовков сообщений

Заголовок запроса
Итак, служебные поля сообщения запроса имеют вид:
01 GET / HTTP/1.1
02 Host: www.sudmed.ru
03 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; ru;
rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
04 Accept: text/xml, application/xml, application/xhtml+xml,
text/html; q=0.9, text/plain; q=0.8, image/png, */*; q=0.5
05 Accept-Language: ru-ru, ru; q=0.8, en-us; q=0.5, en; q=0.3
06 Accept-Encoding: gzip, deflate
07 Accept-Charset: windows-1251, utf-8; q=0.7, *; q=0.7
08 Keep-Alive: 300
09 Connection: keep-alive
(Строки пронумерованы исключительно для удобства читателя, в реальном сообщении запроса этих номеров и следующих за ними пробелов, естественно, нет.)
Если дополнить эту информацию пустой строкой, мы получим полное HTTP-сообщение запроса, фактически отправленное браузером. Поскольку используется метод GET, запрос закономерно не содержит в себе тела сообщения.
Первая строка представляет собой, очевидно, строку запроса. Запрашивается корневой каталог дерева документов сервера (/) с использованием метода GET в рамках протокола HTTP 1.1.
Адрес хоста сервера указывается во второй строке, в поле заголовка Host. Таким образом, полный абсолютный URI запрашиваемого ресурса — http://www.sudmed.ru/.
Значением поля User-Agent («агент пользователя»; третья строка нашего примера) является сигнатура, т. е. «личная подпись», клиента. Содержимое данного поля свидетельствует о том, что запрос произведен при помощи браузера Firefox 1.5.0.1, работающего под управлением операционной системы (ОС) Windows 2000. 1.1:
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
Анализируя переданное клиентом значение поля User-Agent, мы можем создавать «интеллектуальные» динамические сайты, подстраивающиеся под особенности конкретных браузеров. Однако принимать содержимое этого поля за истину в последней инстанции не следует — любой мало-мальски подкованный программист может за несколько минут написать HTTP-клиент, «подписывающийся» хоть Папой Римским.
Приведем, тем не менее, еще некоторые примеры часто встречающихся сигнатур:
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; en) Opera 8.0 — Opera 8.0 под управлением Windows 2000;
Opera/9.00 (Windows NT 5.1; U; ru) — Opera 9.0 под управлением Windows XP;
Yandex/1.01.001 (compatible; Win16; M) — один из многочисленных роботов «Яндекса»
Googlebot/2.1 (+http://www.google.com/bot.html) — один из не менее многочисленных роботов поисковой системы Google.
Перейдем, однако, к четвертой строке сообщения HTTP-запроса, содержащей поле заголовка Accept. Как мы уже отмечали, в этом поле клиент указывает, объекты какого типа он сможет принять от сервера. Речь идет о MIME-типе содержимого. Напомню, что в соответствии со стандартом MIME, тип содержимого определяется следующим образом:
тип/подтип
Приведу примеры ряда MIME-типов.
Тип верхнего уровня — text (текст):
• text/plain — обычный текст;
• text/html — документ в формате HTML;
• text/xml — документ в формате XML.
Тип верхнего уровня — image (изображение):
• image/gif — изображение в формате GIF;
• image/jpeg — изображение в формате JPEG;
• image/png — изображение в формате PNG.
Тип верхнего уровня — application (приложение):
• application/octet-stream — любой бинарный объект, например, исполняемый код программы;
• application/msword — документ в формате MS Word;
• application/xml — приложение XML;
• application/xhtml+xml — документ XHTML, должный обрабатываться строго в соответствии с правилами XML.
На месте типа и/или подтипа может фигурировать символ звездочки. Запись text/* обозначает все текстовые типы; а */* — вообще любой тип.
В поле заголовка Accept, если присмотреться, поддерживаемые типы содержимого перечисляются через запятую. После некоторых групп типов через точку с запятой может быть указан коэффициент предпочтения — параметр q, представляющий собой число в диапазоне от 0 до 1.
Чем больше это число, тем «охотнее» клиент принимает объекты соответствующего типа. Постарайтесь проанализировать сами, какие типы содержимого и в какой мере предпочитает Firefox.
Internet Explorer 6.0 куда как менее «привередлив» — его, судя по значению поля Accept, в равной мере устраивают любые типы объектов:
Accept: */*
В пятой строке рассматриваемого нами примера HTTP-запроса фигурирует поле Accept-Language, в значении коего указаны предпочтительные языки содержимого (русский с коэффициентом предпочтения q=0.8, американский английский с коэффициентом q=0.5 и английский в любой разновидности с коэффициентом q=0.3). Здесь, я полагаю, все прозрачно.
В значении поля заголовка Accept-Encoding, обнаруживающегося в шестой строке разбираемого нами запроса, указываются поддерживаемые клиентом схемы кодирования информации, пересылаемой сервером в теле сообщения HTTP-ответа. Речь идет, главным образом, об алгоритмах динамического сжатия. К ним, как раз, и относятся фигурирующие в нашем примере gzip и deflate.
Примечание
Упомянутые алгоритмы (по сути своей аналогичные применяемым в архиваторах) используются сервером для того, чтобы «на лету» сжимать объекты, пересылаемые клиенту, непосредственно перед их отправкой. Применение динамического сжатия позволяет уменьшить объем передаваемых данных (особенно, если речь идет о текстовых типах) в несколько раз.
На стороне сервера такая возможность реализуется обычно за счет использования дополнительных модулей, таких как mod_gzip или mod_deflate (если речь идет о модулях для сервера Apache). На стороне клиента, как вы понимаете, необходимо проделать обратную операцию — распаковать сжатые данные. Все распространенные ныне браузеры умеют декодировать сжатые объекты, о чем и сообщают серверу в поле Accept-Encoding.
Седьмая строка исследуемого примера запроса занята полем Accept-Charset. В значении этого поля перечисляются кодировки текста, воспринимаемые клиентом, с возможным указанием коэффициентов предпочтения. Комментировать эту строку, полагаю, излишне.
В восьмой строке нашим очам открывается поле Keep-Alive, не определенное в спецификации HTTP 1.1. Дело в том, что на практике идеология постоянных соединений была экспериментально реализована и ранее за счет использования расширенных заголовков. К настоящему моменту поле Keep-Alive утратило свой смысл. Его можно использовать для совместимости с реализацией постоянных соединений некоторыми устаревшими веб-серверами.
Наконец, в девятой строке мы сталкиваемся с полем Connection, имеющим значение keep-alive. Очевидно, тем самым клиент хочет сообщить серверу, что он планирует использовать постоянное соединение. Однако, согласно букве спецификации HTTP 1.1, данная строка является избыточной, ибо в рамках протокола HTTP 1.1 все соединения считаются постоянными по умолчанию. Если же какая-либо сторона разрывает соединение, она должна отправить явное уведомление об этом в виде поля заголовка:
Connection: close
Теперь предлагаю обсудить отличия только что рассмотренного сообщения HTTP-запроса от другого примера.
Изменения касаются следующих строк:
01 POST /cgi-bin/e-shop/cart.pl HTTP/1.1
02 Host: www.ushenin.com
...
10 Referer: http://www.ushenin.com/friends/
11 Content-Type: application/x-www-form-urlencoded
12 Content-Length: 258
Как явствует из первой строки, запрос выполняется с использованием метода POST в рамках протокола HTTP 1.1. Полный URI запрашиваемого ресурса, если принять во внимание значение поля Host из второй строки — http://www.ushenin.com/friends/.
Этот адрес в достаточной степени информативный. Как можно догадаться, речь идет о CGI-скрипте на языке Perl (характерное расширение файла — pl), обеспечивающем работу корзины заказа (имя файла — cart) интернет-магазина (название подкаталога — e shop).
Метод POST используется для того, чтобы передать указанному скрипту информацию о товарах, выбранных покупателем.
Поле Referer (десятая строка) содержит адрес страницы, которая была загружена в окошко браузера в момент осуществления данного запроса. Очевидно, пользователь выбирал товары при помощи веб-формы, сгенерированной скриптом с именем search.pl (search — поиск).
Этому скрипту, как мы можем наблюдать, в составе URI были переданы дополнительные параметры (id=338-41154459 — должно быть, идентификатор заказа, action=search — «действие=искать», manufacturer — «производитель»; очевидно, это один из критериев поиска, и т. д.).
Примечание
Поле Referer, как видно, может содержать в себе весьма ценную информацию. Анализируя (разумеется, не вручную, а при помощи автоматизированных средств сбора статистики) большое количество запросов, информацию о которых веб-сервер обычно заботливо сохраняет в лог-файлах, вы можете без труда «вычислить», с каких ресурсов приходят посетители к вам на сайт. А если речь идет о визитах со страниц выдачи поисковых систем, можно даже посмотреть, по каким ключевым словам находят ваш сайт пользователи, на основании чего совершенно осознанно строить дальнейшую политику информационного наполнения и продвижения веб-проекта.
Сущность метода POST, напомню, заключается в том, что клиент может передать в теле сообщения HTTP-запроса некие данные на сервер. Строки 11 и 12 нашего примера как раз и содержат поля заголовка, описывающие свойства передаваемого объекта.
Так, значением поля Content-Type выступает MIME-тип содержимого тела сообщения (application/x-www-form-urlencoded — это тип, по умолчанию используемый для данных полей HTML-форм; подробнее об этом мы будем беседовать в ходе главы 5). Поле Content-Length содержит размер передаваемого объекта в байтах.
Сами передаваемые данные (результат заполнения веб-формы пользователем) следуют за рассмотренными выше служебными полями HTTP-сообщения запроса после пустой строки.


© 2008-2018 ОптимизацияВебСайтов.ру


Любое использование текстового и графического контента сайта без активной ссылки на источник не доскается.