Кришнамурти Б., Рексфорд Дж. Web-протоколы. Теория и практика

Подождите немного. Документ загружается.

Web-клиенты

В предыдущей главе вы узнали о трех основных видах программных компонен-

тах Web: клиентах, прокси- и Web-серверах. Большинство пользователей Web не-

посредственно имеют дело с Web-клиентами и почти никогда с прокси- или

Web-серверами. Web-серверы являются необходимым компонентом, прокси-серве-

ры играют важную роль, а сеть необходима для передачи данных. И все же брау-

зер — наиболее известный тип Web-клиента

—

это то, что конечные пользователи

реально

используют

для взаимодействия с Web.

Можгю сказать, что появление Web-браузера Mosaic [Mos] явилось главной

причиной, благодаря которой Всемирная паутина стала частью повседневной жиз-

ни миллионов людей. Прошло всего три года после создания браузера Mosaic, а

число пользователей Web достигло десятков миллионов. Ни один другой про-

граммный компонент не смог привлечь так много новых пользователей к новой

или .уже существующей технологии за такой короткий промежуток времени. Как

следствие, возросло число документов, доступных в Internet. Несмотря на то, что

Web существовала уже за несколько лет до начала широкого использования

Mosaic, браузер существенно способствовал привлечению новых пользователей.

Хотя с точки зрения пользователя браузер является центральной (и даже един-

ственной) частью его восприятия Web, другие клиенты играют столь же важную,

хотя и не такую очевидную роль. В этой главе рассматриваются три вида Web-кли-

еитов: браузер, как наиболее популярный вид Web-клиента; программы-пауки

(спайдеры)

и их роль в качестве ключевой составляющей поисковых систем в Web,

а также менее известное программное обеспечение

—

агенты пользователя.

Глава начинается с рассмотрения происхождения Web-клиента

—

программы,

которая отправляет Web-запросы и принимает ответы. Популярность графических

растровых дисплеев и простота навигации сыграла ключевую роль в эволюции

браузеров. Для подробного обзора роли браузеров при взаимодействии с Web ис-

пользуется классический пример. Далее рассматривается настройка браузера, кото-

рая заключается в задании атрибутов или параметров, которые являются специфи-

ческими для протокола HTTP. Браузеры выполняют несколько функций, которые

пе связаны с протоколом HTTP, например, вызов программ для интерпретации и

отображения ответов. Рассматривается также возможность настройки этих действий.

Браузер является наиболее близким к пользователю из трех основных видов

программных компонентов. Проблемы безопасности, связанные с доступом к ре-

сурсам и загрузкой сценариев или других исполняемых программ, являются неотъ-

емлемой составной частью взаимодействия браузера с Web. После рассмотрения

вопросов безопасности мы обсудим роль cookies в управлении состоянием между

Web-транзакциями. Исследуется важная, но по большей части скрытая роль брау-

зера при работе с cookies.

Часть

П.

Компоненты программного обеспечения

Web

Спайдер

—

это разновидность клиентской программы, которая не взаимодейст-

вует с пользователями напрямую. Спайдеры необходимы для поиска и индексиро-

вания ресурсов. Рассмотрев, как осуществляется поиск, мы расскажем о той нише,

которую спайдеры занимают в Web.

Помимо браузеров и спайдеров, большая роль отводится агентам — програм-

мам, функционирующим в интересах пользователей в специфических приложени-

ях, включая средства для участия в аукционах и средства фильтрации данных, ко-

торые менее известны. Мы рассмотрим некоторые популярные виды таких про-

граммных компонентов. В заключение мы остановимся на общих принципах

построения клиентов, а также на их практическом применении.

2.1.

Клиент как программа

Web-клиент представляет собой разновидность программного обеспечения.

Главная задача Web-клиента

—

отправлять Web-запросы от имени пользователя и

принимать ответы. Клиент также используется для многих других целей. Web

была разработана после появления традиционной архитектуры программного обес-

печения клиент-сервер, в которой клиент связывается с сервером и отправляет ему

запрос, после чего получает ответ сервера. На момент создания Web другие систе-

мы клиент-сервер (о чем уже говорилось в главе 1) предлагали услуги, аналогич-

ные тем, которые предоставляла Web. Имелась возможность посылать запросы на

поиск ресурсов путем обращения к индексам, в которых и осуществлялся поиск.

Любая из обращавшихся с запросом программ являлась клиентом. Web развива-

лась вместе с этими системами (Archie, Gopher, группы новостей и т.д.), поэтому

сначала Web-клиент был во многом схож с другими аналогичными компонентами

в традициогнюй схеме клиент-сервер.

В типовой системе клиент-сервер клиенты являются относительно простыми

компонентами. Клиент формирует запрос, посылает его серверу, а затем читает,

анализирует и отображает ответ. В типовых системах клиент-сервер интеллекту-

альная часть расположена на сервере. Для Web же это не совсем так. Серверы

по-прежнему берут на себя значительную часть функций. Однако на практике

Web-клиенты являются достаточно сложными компонентами. Эта сложгюсть проис-

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

должным образом оформленного Web-запроса, установка соединения и взаимодей-

ствие с Web-сервером через надежное соединение транспортного уровня. По боль-

шей части сложность клиентской программы определяется факторами, сопровож-

дающими базовый обмен запрос-ответ,

—

возможностями настройки при создании

запроса, интерпретации ответа и его отображении.

2.2.

Эволюция браузеров

Первоначально браузер был простой программой, которая давала возможность

пользователям получать ресурсы из любой точки Web; то есть он был всего лишь

воплощением Web-клиента. Через очень короткое время он стал основой практиче-

ски для всех взаимодействий с компьютером для многих пользователей. Пользова-

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

с группами новостей, участия в интерактивных форумах и доступа к Web. Браузер

часто считается

пользовательским

агентом, а не просто клиентом, поскольку он

инициирует

Web-запрос.

Глава

Web-клиенты

Большинству пользователей браузеров не известно о разнице между Internet и

Web.

Они также не знают, что большинство приложений, которые они использу-

ют, включая электронную почту, группы новостей и т.д., существовало задолго до

Web.

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

во взаимодействии с Web. Помимо этого мы обсудим некоторые вопросы, связан-

ные с настройкой браузера пользователем.

Растровые графические дисплеи появились в массовом порядке в середине 80-х

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

терщующего на популярность среди пользователей. Преимущества графического

интерфейса над текстовым уже тогда были широко известны. Однако многие поль-

зователи компьютеров еще не имели возможности работать с растровыми дисплея-

ми и часто использовали текстовый интерфейс для доступа к своим файлам. Это

нашло отражение в конце 80-х годов в виде интерфейсов к различным средствам

доступа к информации, таким как Archie, Gopher и Wide Area Information Server

(WAIS)

(CM.

главу 1). Пользователи перешли от доступа к локальным файлам

к доступу ко всем имеющимся в Internet ресурсам. Способ доступа также изменил-

ся от доступа к ресурсу с заранее известным местоположением на доступ к ресур-

сам путем поиска в Internet.

Пользователи выигрывают оттого, что им известно множество ресурсов, доступ-

ных в данный момент времени, а также имеется информация о последних обраще-

ниях к этим ресурсам при работе с группой ресурсов. При доступе к большей кол-

лекции ресурсов в Internet возможность быстро перемещаться между ресурсами

приобретает существенное значение. Возможность перемещения между группами

ресурсов и между отдельными ресурсами требует наличия ясного и интуитивно по-

нятного пользовательского интерфейса. Коллекция ресурсов в данном месте может

быть организована иным способом, чем в других местах. Хотя пользователи полу-

чили доступ к большому количеству ресурсов по всему миру, их способность обра-

батывать информацию увеличилась не столь заметно. Средство, которое дает воз-

можность пользователям перемещаться между коллекциями ресурсов, должно

удовлетворять следующим требованиям:

• Иметь представление о текущем контексте (где находится пользователь и что

доступно из этого места).

• Знать, куда пользователь может перейти дальше, и где гюльзователь был до

этого момента.

• Иметь возможности настройки средств навигации и отображения ресурсов,

к которым осуществляется доступ.

• Быть способным осуществлять поиск в коллекции ресурсов.

Первый браузер был создан в лаборатории CERN с использованием графиче-

ского интерфейса пользователя NeXTStep [BLCGP92] и продемонстрировал мощ-

ные возможности использования гипертекстовых ссылок для просмотра коллекций

документов. Он получил название Worldwide Web и был написан создателем Web

Тимом Бернерс-Ли. Были также созданы клиентские программы, которые могли

работать и в текстовом режиме. С точки зрения Web-сервера клиент был лишь

программой, независимо от интерфейса, предоставляемого конечному пользовате-

лю.

Работа над созданием первого текстового браузера под названием linemode

[Pel91] началась в конце 1990-го года, а доступен он стал в марте 1991 г. Браузер

LineMode был браузером, который давал возможность пользователям перемещать-

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

родной информации. LineMode гарантировал доступ к Web для всех пользовате-

Часть

П.

Компоненты программного обеспечения

Weh

лей, независимо от терминала, который они использовали. Пользователи могли пе-

ремещаться по коллекции Web-докумептов с помощью только клавиатуры и всего

двух управляющих последовательностей: возврата каретки и перевода строки.

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

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

ссылка. В клиентской программе имелось ровно семь команд [Pel91J, таких как

List (для вывода списка всех ссылок в документе), К для выполнения поиска по

ключевому слову и Recall для вывода списка документов, просмотренных в сеансе

на данный момент (прототип журнала регистрации событий).

Первый браузер представлял собой нечто большее, чем демонстрацию правильно-

сти концепции. Он заложил основные принципы, используемые при создании совре-

менных браузеров. Если отвлечься от внешнего оформления, главным достоинством

современных браузеров является их способность легко перемещаться по ссылкам

в Internet,

—

эта возможность была реализована на самых первых порах существова-

ния Web. Другими словами, браузер стал реализацией концепции, в соответствии

с которой пользователям предоставлялась возможность быстро перемещаться между

коллекциями документов и интуитивно понятгю осуществлять эти действия.

После LineMode появилось несколько других браузеров, от браузера Curses

с навигацией с помощью клавиш управления курсором до семейства браузеров, ра-

ботающих под управлением различных популярных систем построения оконного

интерфейса: XII Window System (Viola, tkWWW, Midas WWW), браузера, напи-

санного для компьютеров Macintosh, и даже браузера, написанного на Perl. Появ-

ление браузера Mosaic стало значительным шагом вперед, а Mosaic стал основным

широко используемым браузером. Текстовой браузер Lynx появился в 1992 г. и до

сих пор находит ограниченное применение. Некоторые из разработчиков Mosaic

затем создали браузер Netscape, а несколькими годами позже был создан браузер

Internet Explorer. На момент подготовки этой книги к публикации (на протяжении

последнего года или около этого) в браузеры не было добавлено каких-либо значи-

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

В то же время Web-серверы постоянно модифицируются с целью увеличения про-

изводительности, надежности и предоставления различного уровня сервиса раз-

личным клиентам.

2.3.

Функции браузера, относящиеся к Web

Браузер прежде всего реализует функции Web-клиента: формирует и отправля-

ет HTTP-запрос, затем получает, синтаксически анализирует и отображает ответ.

Сеанс работы браузера представляет собой набор запросов, посылаемых пользова-

телем, возможно, на основе ответов, полученных на каждом из этапов. Сеанс рабо-

ты браузера может длиться как несколько минут, так и несколько часов. На рис. 2.1

показаны различные шаги процесса работы с Web-запросом. Несколько упрощая,

можно сказать, что сначала осуществляется синтаксический анализ указанного

пользователем URL (Uniform Resource Locator

—

унифицированный указатель ре-

сурса),

определяется IP-адрес Web-сервера, с которым следует связаться, затем ус-

танавливается соединение с сервером, после чего посылается HTTP-запрос. Заме-

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

пользования кэширования — браузер может иметь копию ответа, полученного

ранее, что избавляет от необходимости отправлять запрос на этот ресурс снова.

Подробнее кэширование будет рассмотрено в разделе

2.3.3.

Глава 2. Web-клиенты

Браузер DNS-сервер

1 Запрос к DNS

URL

Исходный сервер

2 ТСР-соединение

3 HTTP-запрос

4 НТТР-отввт

5 Дополнительные параллельные

соединения

N -Н

Рис. 2.1. Основные шаги работы браузера

URL может быть предоставлен различными способами; чаще всего это щелчок

мышью на имеющейся на странице гиперссылке. URL может быть также введен

в адресной строке браузера или выбран из файла закладок (файла, содержащего

URL и краткие описания часто посещаемых ресурсов) или из журнала браузера.

Браузеры воспринимают http как протокол по умолчанию, если не указано иное, а

также могут завершать ввод пользователя, предлагая па выбор недавно использо-

ванные URL. В таблице 2.1 представлены некоторые действия пользователя, кото-

рые могут породить Web-запрос.

Таблица 2.1. Действия пользователя, которые могут породить запрос

Вариант ввода

Кнопка Forward/Backward

(Вперед/Назад)

Выбор гиперссылки

Закладки (избранное)

Щелчок па кнопке Submit (О

нажатие клавиши Return или

Адресная строка

Различные меню

Изображения

Обновление

гправить).

Enter

Способ создания запроса {

Механизм запоминания последних обращений

пользователя |

Из соответствующей строки URL

в HTML-тексте |

Из пользовательского набора часто

используемых гиперссылок |

URL извлекается из соответствующей формы

Пользовательский ввод |

Из выбрапгюго пункта меню |

Щелчок мышью автоматически генерирует

запрос 1

Текущий URL 1

Часть

II. Компоненты программного обеспечения Web

В начале раздела мы рассмотрим классический пример, иллюстрирующий

функции Web-браузера. Далее мы познакомимся с типичным способом построения

запросов

—

заполнением формы. Затем мы рассмотрим роль, которую играет кэши-

рование при работе с браузером. После этого мы оценим роль прокси-сервера, если

таковой имеется на пути между клиентом и сервером. Затем будет рассмотрены

функции браузера в построении заголовков HTTP-запроса. Наконец, мы обсудим,

как браузер обрабатывает HTTP-ответ.

2.3.1.

Классический пример, иллюстрирующий функции

Web-браузера

Мы будем использовать нижеследующий пример па протяжении всей книги. До-

кумент, в который встроено несколько изображений, должен быть загружен клиентом

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

действует с исходным сервером без промежуточных звеньев, таких как прокси-сер-

веры. Кроме того, мы предполагаем, что кэширование ресурсов не используется.

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

URL скрыт от пользователя. Видимая часть гиперсе^ылки обычно является поясне-

нием, хотя игюгда используются фразы типа «щелкните здесь». Видимая часть ги-

перссылки обычно определенным образом выделяется, например, цветом и/или

подчеркиванием. Пользователь активизирует гиперссылку, щелкая на ней мышью

или вводя URL в предусмотренном для этого адресном поле в браузере. Предполо-

жим, что пользователь выбрал ссылку http://www.bar.com/foo.html. Браузер вы-

полняет синтаксический анализ URL http://www.bar.com/foo.html. Первая часть,

предшествующая символу ':', соответствует протоколу, который браузер будет ис-

гюльзовать для выборки ресурса www.bar.com/foo.html. В данном случае это http,

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

как File Transfer Protocol (FTP) или Telnet. Сам ресурс www.bar.com/foo.html

имеет две части: начальную часть, состоящую из доменного имени компьютера

(www.bar.com), на котором размещен Web-сервер, и имени ресурса (/foo.html),

доступного на сервере www.bar.com. Браузер делает запрос к серверу домегнтых

имен (DNS) для преобразования доменного имени www.bar.com в IP-адрес серве-

ра (этап 1 на рис. 2.1). После получения IP-адреса компьютера www.bar.com брау-

зер устанавливает соединение на транспортном уровне с Web-сервером, используя

протокол Transmission Control Protocol (TCP) (этан 2). После успешного установ-

ления соединения браузер отправляет сформатированный НТТР-занрос на ресурс

/foo.html (этап 3). Web-сервер www.bar.com возвращает текущее содержания ре-

сурса /foo.html (этап 4).

Таблица 2.2. Ресурсы, используемые в примере, и их тип содержания

Ресурс

/foo.html

/fool.gif

/foo2.gif

/foo3.jpg

/book.cgi

/mp.tv

Описание

Коитейперный HTML-документ

Встроенное изображение

Исполняемый сценарий

Мультимедийный документ

Тип содержания |

HTML

GIF

JPEG

CGI

Специальный формат

Глава 2. Web-клиенты

Браузер осуществляет синтаксический анализ ответа и может устанавливать до-

полнительные соединения для загрузки встроенных ресурсов. В этом примере мы

полагаем, что в /foo.html имеются три встроенных ресурса. На странице также име-

ется ссылка на ресурс, представляющий собой CGI-сценарий (об этом пойдет речь

в главе 4, раздел 4.2.3), и ссылка на мультимедийный объект. В таблице 2.2 перечис-

лены ресурсы, используемые в примере. Браузер может сразу начать отображение

частично загруженного содержимого /foo.html, даже если он устанавливает допол-

нительные соединения для запроса встроенных изображений\ Дополнительные со-

единения, необходимые для загрузки изображений, могут быть установлены парал-

лельно. Соединения не обязательно могут устанавливаться с тем же исходным сер-

вером, поскольку некоторые из встроенных ресурсов документа /foo.html мохут

размещаться на других серверах. Браузер также может начать отображение каждого

из изображений по мере их получении. Задача браузера завершается после того, как

он получит все встроенные изображения и отобразит их. На рис. 2.2 показано, как

контейнерный документ foo.html должен выглядеть вместе с тремя встроенными

изображениями, формой и ссылкой на м}У1ьтимедийный документ.

fool .gif

foo2.gif

foo3.jpg

Name: ..

Address:

I Credit Card:

! Book Title: .

SUBMIT

book, eg i

mp.tv

Рис. 2.2. Контейнерный документ foo.html

2.3.2. Выдача запроса браузером

Большинство пользователей делают запрос, щелкая па видимой части гипер-

ссылки на Web-странице или вводя URL в адресной строке браузера. Однако в не-

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

Для этого в теге <img> необходимо задать ширину и высоту изображения.

—

Прим.

ред.

Часть

П.

Компоненты программного обеспечения

Web

процесс. Рассмотрим пример, связанный с заказом книг в Web, для чего требуется

заполнить форму, состоящую из набора полей, значения которых должны быть вы-

браны из меню или введены. Типичными примерами создания запросов в результа-

те заполнения пользователем формы являются приложения электронной коммер-

ции и поисковые системы. Одна из причин построения запросов с помощью форм

состоит в том, что значительную часть всех запросов в Web получают поисковые

сайты. Пользователь обычно делает запрос на поиск, заполняя поисковую форму и

щелкая на кнопке передачи данных, либо нажимая клавишу Enter. Отправка дан-

ных формы или щелчок на гиперссылке приводят к одному и тому же действию

—

построению соответствующим образом сформатированного HTTP-запроса.

Вернемся к предыдущему примеру, в котором имеется ссылка на исполняемый

па сервере сценарий /book.cgi. Страница заказа книг включает в себя форму, ко-

торую пользователь заполняет информацией, необходимой для заказа книги. На-

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

дитной карты и название книги. Заполненная форма может быть отправлена ис-

ходному серверу по меньшей мере двумя способами. В первом способе значение

каждого поля и соответствующее имя поля трактуются как пары (имя, значение).

Коллекция пар (имя, значение) включается в качестве параметров в заголовок

HTTP-запроса GET. Например, если одно из полей в форме есть поле имени, а

пользователь вводит в него Noam Chomsky, пара может быть включена в URL

в виде http://www.foo.com/book.cgi?name=Noam+Chomsky. Другой способ —

включить данные формы в тело HTTP-сообщения с помощью другого метода за-

проса (POST).

2.3.3.

Кэширование в браузере

в этом разделе мы вкратце остановимся на кэшировании в Web применительно

к браузерам. Кэш

—

это локальное хранилище данных, которое может использо-

ваться для уменьшения времени ожидания пользователем ответа от сервера.

В браузере обычно применяются два вида кэширования: с использованием памяти

вьшолршющегося процесса и с использованием дискового пространства, выделяе-

мого для кэширования. Если сеть сильно загружена или если Web-сервер активно

используется, получение ресурсов с сайта может занять длительное время. По-

скольку большинство пользователей часто посещают одни и те же Web-сайты,

браузеру выгодно кэшировать последние загруженные страницы. Если пользова-

тель попытается вернуться к Web-странице, которую он недавно посетил, страница

может быть отображена из кэша браузера. Привычка пользователей возвращаться

к недавно просмотренной странице столь распространена, что в большинстве брау-

зеров предусмотрена кнопка Back (Назад), дающая возможность пользователю воз-

вращаться к последним запрошенным страницам.

Предположим, что одно из встроенных изображений ресурса /foo.html, скажем,

/fool.gif,

было сохранено в кэше браузера. Чтобы повторно вывести изображение,

браузеру не нужно выполнять отдельный запрос на него. Поскольку отдельный

HTTP-запрос не нужен, нет необходимости и в запросе к DNS на преобразование

доменного имени исходного сервера в IP-адрес, в установлении ТСР-соединения

для отправки HTTP-запроса и в передаче потока байтов, соответствующих изобра-

жению

/fool.gif,

через сеть. Все это приводит к значительному сокращению време-

ни ожидания на стороне пользователя

—

интервала времени между щелчком поль-

зователя на гиперссылке и началом отображения страницы в окне браузера.

Глава 2. Web-клиенты 49

Однако существует возможность, что ресурс был изменен с момента его кэши-

рования. Браузеру может понадобиться проверить, что кэшированный ответ

по-прежнему актуальный, сопоставив кэшировапную копию с текущей копией на

исходном сервере. Подобная проверка получила название проверки актуальности

кэша. Если версия на исходном сервере более новая, то кэшированная копия уста-

рела. Например, ресурс /fool.gif мог измениться с момента его последней загрузки.

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

при этом делается так, что кэшированные ресурсы являются актуальными. Кэш,

который осуществляет проверку кэшировапной версии на соответствие версии на

исходном сервере каждый раз, когда выполняется запрос па кэшированный ресурс,

поддерживает высокую степень актуальности кэша. Если кэш использует эвристи-

ческий подход для определения, по-прежнему ли считать актуальным кэширован-

ный ответ, то поддерживается низкая степень актуальности кэша. В последнем слу-

чае ответы могут возвращаться без сопоставления с ресурсом на исходном сервере.

Для поддержания актуалыюсти кэшированных ресурсов используется несколько

эвристических алгоритмов. Проверка кэшированных ресурсов может выполняться

периодически через фиксированные интервалы времени, либо через меняющиеся

интервалы времени в зависимости от атрибутов ресурса (размер, время последней

модификации, тин содержимого и т.д.). Решение, следует ли возвращать кэширо-

ванный ресурс, принимается в зависимости от стратегии проверки актуальности,

используемой браузером в данный момент. Браузер может решить, что изменение

изображений происходит не так часто, как изменение текстовых ресурсов, и ис-

пользовать кэшированное значение без проверки его актуальности с помощью об-

ращения к исходному серверу. Хотя браузер может и не предполагать, что ресурс

/foo.html по-прежнему актуален, он вполне может допустить, что изображение

/fool.gif в последнее время не менялось. При этом возникает возможность возвра-

та устаревшего ресурса в качестве ответа, если браузер поддерживает низкую сте-

пень актуалыюсти кэша.

Пользователь может обойти эвристическую проверку достоверности кэша брау-

зером и принудить браузер отправлять запрос непосредственно па исходный сер-

вер.

Например, в браузере Netscape это делается с помощью щелчка на кнопке

Reload при предварительно нажатой клавише Shift.

При записи в кэш ответа исходного сервера в него включается значение «време-

ни последней модификации», указывающее, когда ресурс был в последний раз мо-

дифицирован на исходном сервере. Кэш будет хранить это значение и включать его

в заголовок запроса как часть процесса проверки актуальности. Если первоначаль-

ный ответ сервера не содержит времени последней модификации, кэш присваивает

значение эвристически. Например, кэш может присвоить значение времени, соот-

ветствующее времени получения ответа. Исходный сервер сравнивает текущее вре-

мя последней модификации ресурса со значением для кэшированного ресурса, что-

бы дать знать, если ресурс был изменен.

Если запрашиваемый ресурс не содержится в кэше браузера, запрос передается

серверу, который может быть или не быть исходным Web-сервером.

Подробнее о кэшировании мы поговорим в главе 11.

2.3.4. Заголовки сообщения-запроса

Итак, мы узнали, как может быть выбран URL, как форма может быть преобра-

зована в запрос, и как браузер принимает решение об отправке запроса после про-

верки его кэшировапной копии. Теперь мы рассмотрим, как действие пользователя