Заголовок ответа

Познакомившись на практике с примерами реальных HTTP-сообщений запроса, будет нелишним взглянуть и на то, чт? сервер отправляет клиенту в составе сообщения ответа. Проанализируем пример:
01 HTTP/1.1 200 OK
02 Date: Tue, 28 Feb 2006 19:28:02 GMT
03 Server: Apache/1.3.33 (Unix)
04 Cache-Control: max-age=0
05 Expires: Tue, 28 Feb 2006 19:28:02 GMT
06 Connection: close
07 Transfer-Encoding: chunked
08 Content-Type: text/html; charset=windows-1251
Первая строка представляет собой, очевидно, статусную строку. Используется протокол HTTP 1.1, код статуса — 200, поясняющая фраза — OK. Все это обсуждалось выше, и дополнительные комментарии здесь, полагаю, не требуются.
Во второй строке в поле Date фигурирует дата и время отправки HTTP-сообщения ответа в формате, оговариваемом в RFC 1123. Допустимы и некоторые другие форматы даты и времени. Принципиально важно то, что время всегда указывается по Гринвичу (GMT — Greenwich Mean Time).
В третьей строке сервер сообщает о себе в поле заголовка Server. Очевидно, запрошенный ресурс обслуживается веб-сервером Apache версии 1.3.33, работающим под управлением ОС семейства UNIX.
Четвертая строка являет нам поле заголовка Cache-Control. Это поле используется для управления кэшированием и предполагает достаточно широкий набор директив, которые могут фигурировать в составе своего значения. Мы не будем разбирать их — это выходит за рамки тематики нашей книги. Отметим лишь, что параметр max-age в данном случае сообщает клиенту, через какое количество секунд (в нашем примере — 0) следует считать устаревшим документ, переданный в теле сообщения ответа.
Поле Expires (пятая строка примера), значением которого являются те же дата и время, что и у поля Date, в данном случае используется в целях, аналогичных тем, что преследуются полем Cache-Control строкой выше. А именно, сервер сообщает клиенту, что содержимое запрошенного ресурса может быть подвержено изменению в любой момент после отправки данного сообщения ответа.
В шестой строке, пользуясь полем заголовка Connection со значением close, сервер уведомляет клиента о своем намерении разорвать TCP-соединение. Иными словами, сервер не настроен на работу с постоянными соединениями.
Примечание
Рассматриваемое сообщение HTTP-ответа принадлежит серверу одного из провайдеров, обслуживающему несколько виртуальных веб-узлов. Владельцы этих аккаунтов не имеют возможности самостоятельно изменять общие настройки сервера.
К сожалению, во многих подобных случаях приходится мириться с тем, что конфигурация сервера бывает далека от оптимальной. В частности, запрет на постоянные соединения и отсутствие динамического сжатия существенно снижают скорость загрузки страниц. Спорными являются и столь категоричные настройки кэширования. Неудобно отсутствие поля заголовка Last-Modified, указывающего дату и время последнего изменения ресурса.
Провайдеров, конечно, тоже можно понять — ими, в первую очередь, движут соображения безопасности, производительности и унификации настроек сервера, обслуживающего множество самых разноплановых сайтов.
Поле Transfer-Encoding определяет способ преобразования, применяемого к телу сообщения в целях обеспечения защищенности его передачи. Спецификация HTTP 1.1 определяет только один тип кодирования — chunked («кусочный», в соответствии с которым тело сообщения разбивается на фрагменты с собственными индикаторами размера), подразумевая возможность использования альтернативных (расширенных) алгоритмов. В рамках протокола HTTP 1.0 какие бы то ни было способы кодирования сообщений при передаче не предусмотрены.
Наконец, заключительная, восьмая строка заголовка рассматриваемого примера содержит уже знакомое нам поле Content-Type. Помимо типа содержимого (text/html) в значении поля фигурирует кодировка текста, в которой представлен передаваемый документ (windows-1251, кириллический символьный набор, принятый для русскоязычных текстовых документов в ОС Windows).
После завершающей строки заголовка сообщения следует пустая строка, за которой размещается HTML-код отправляемой сервером веб-страницы.
Пример заголовка HTTP-сообщения ответа другого сервера лишь немногим отличается от рассмотренного выше. Сигнатура веб-сервера включает в себя упоминание ряда дополнительных модулей (mod_fastcgi, FrontPage, PHP, mod_gzip, mod_ssl и т. д.). Кроме того, в заголовке встречается поле Vary, которое мы еще не обсуждали:
Vary: accept-charset
В поле Vary обычно перечисляются имена заголовков клиентского запроса, от значений которых может так или иначе зависеть содержимое передаваемых сервером объектов. В данном случае сервер сообщает, что кодировка текста документа может быть изменена по желанию клиента в зависимости от того, какие предпочтения клиент сформулирует в поле Accept-Charset заголовка сообщения запроса.
…Итак, мы на реальных примерах HTTP-сообщений рассмотрели назначение почти двух десятков заголовочных полей. Автор настоятельно рекомендует не ограничиваться в изучении протокола HTTP прочтением настоящей главы — обязательно установите себе программу, подобную расширению LiveHTTPHeaders для браузера Mozilla Firefox, пройдитесь по нескольким десяткам сайтов, на которых вы обычно бываете, посмотрите, какие HTTP-заголовки возвращают серверы, обслуживающие эти ресурсы. Постарайтесь непременно понять смысл каждого служебного поля, вооружившись текстом RFC 2616 или раздобыв где бы то ни было русский перевод этой спецификации.
И вообще побольше практикуйтесь, смелее модифицируйте примеры кода, рассматриваемые в этой книге, вдумчиво анализируйте результаты, не бойтесь заглядывать в тексты спецификаций, не гнушайтесь справочной литературы.


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


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