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

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

230

Часть

III. Web-протоколы

Полный список заголовков ответов в HTTP/1.1 приведен в таблице 7.4.

Таблица 7.4. Заголовки ответов HTTP/1.1.

С помощыо '*' помечены заголовки ответов HTTP/1.0.

Понятие

Переадресация

Дополнительная

информация

Безопасность

Кэширование

Заголовок

Location*

Server*

Retry-After

Accept-Ranges

www-Authenticate*

Proxy-Authenticate

ETag

Age

Vary

Краткое описание

Альтернативное местоположение для URI

Идентификация сервера

Величина задержки перед повторной

попыткой запроса

Частичный запрос

Запрос информации для аутентификации

Проверка непрозрачности

Время с момента создания ответа

Выбор варианта ресурса

Раздел

6.2.3

7.12.2

7.4.1

6.2.3

7.11.3

7.3.3

ЗАГОЛОВКИ СОДЕРЖИМОГО

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

формации о ресурсе или о теле содержимого и имеют ту же семантику, что и

в НТТР/1.0. В дополнение к шести уже имевшимся в HTTP/1.0 заголовкам содер-

жимого (Allow, Content-Encoding, Content-Length, Content-Type, Expires, Last-

Modified) в HTTP/1.1 добавлены четыре новых заголовка. Хотя протокол не нужно

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

принимать новые поля. Нераспознанные поля заголовка содержимого (как и полно-

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

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

ки дальше. В таблице 7.5 приведен список заголовков содержимого в НТТР/1.1.

Таблица 7.5. Заго.71овки содержимого в НТТР/1.1.

С помощыо '*' помечены заголовки содержимого в НТТР/1.0.

Заголовок

Allow*

Content-Encoding*

Content-Length*

Content-Type*

Expires*

Last-Modified*

Content-Language

Content-Location

Content-MD5

Content-Range

Краткое описание

Методы, применимые к ресурсу

Кодирование содержания, примененное к телу

содержимого

Длина тела содержимого

Тип тела содержимого

Продолжительность актуальности тела содержимого

Время последней модификации ресурса

Язык содержимого

Альтернативный адрес ресурса

Контроль целостности тела содержимого

Положение диапазона в теле содержимого

Раздел 1

6.2.3

7.9

7.10

7.4.1

Глава 7. HTTP/1.1

231

ЗАГОЛОВКИ ПРОМЕЖУТОЧНЫХ ПЕРЕДАЧ

В HTTP/1.1 существует восемь заголовков промежуточных передач: Connec-

tion, Keep-Alive, Proxy-Authenticate, Proxy-Authorization, Trailers, ТЕ, Transfer-

Encoding и Upgrade. Остальные заголовки являются сквозными и не могут быть

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

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

изъяты. Новые заголовки могут быть введены и преобразованы в заголовки проме-

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

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

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

распознают этот заголовок. Однако если добавить заголовок.

Connection: Volume

то этот заголовок будет изъят, как только он достигнет следующего получателя.

7.2.3.

Старые и новые коды ответов

Смысл 16 кодов состояния ответов из НТТР/1.0 (об этом шла речь в главе 6,

раздел 6.2.4) остается неизменным в НТТР/1.1. Всего в НТТР/1.1 существует

41 код ответа, как показано в таблице 7.6.

Таблица 7.6. Коды состояний ответов НТТР/1.1.

С помощью '*' помечены коды ответов НТТР/1.0.

100 Continue

101 Switching Protocols

200 OK*

201 Created*

202 Accepted*

203 Non-Authoritative Information

204 No Content*

205 Reset Content

206 Partial Content

300 Multiple Choices*

301 Moved Permanently*

302 Found*

303 Sec Other

304 Not Modified*

305 Use Proxy

306 (Unused)

307 Temporary Redirect

400 Bad Request*

401 Unauthorized*

402 Payment Required

403 Forbidden*

404 Not Found* |

405 Method Not Allowed

406 Not Acceptable

407 Proxy Authentication Required

408 Request Timeout

409 Conflict 1

410 Gone

411 Length Required

412 Precondition Failed

413 Request Entity Too Large

414 Request-иRI Too Long

415 Unsupported Media Type

416 Requested Range Not Satisfiable

417 Expectation Failed

500 Internal Server Error*

501 Not Implemented*

502 Bad Gateway*

503 Service Unavailable*

504 Gateway Timeout

505 HTTP Version Not Supported 1

232

Часть III. Web-протоколы

В HTTP/1.1 в каждом классе зарезервировано несколько новых кодов состоя-

ния. Мы рассмотрим некоторые из самых важных новых кодов состояния и объяс-

ним, для чего их потребовалось ввести в НТТР/1.1. Вместе с тем, не было опреде-

лено ни одного нового класса кодов состояния

—

новые классы не воспринимались

бы клиентами и прокси-серверами, работающими по протоколу НТТР/1.0. Клиен-

ты,

работающие по протоколу НТТР/0.9, не воспринимают коды ответов, посколь-

ку они получают только тело содержимого.

В одной п той же ситуации коды состояния ответов не всегда одни и те же: сер-

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

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

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

конкретной причины сообщения об ошибке.

Трудно равномерно распределить коды ответов по конкретным семантическим

категориям. НТТР/1.0 не дает особых указаний, какой код ответа следует вернуть

для данной ситуации. В основном этого не делает и НТТР/1.1. Таким образОхМ,

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

класса следует верпут!^, не может быть сомнений относительно класса кода отве-

тов,

подходящего в данной ситуации. Например, коды ответов 200 ОК, 201 Created

или 204 No Content могут быть переданы в ответ на запрос PUT. Подобным же об-

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

ции, когда ресурса не существует и когда у данного клиента пет прав доступа

к нему, может использовать вместо ответа 403 Forbidden ответ 404 Not Found.

Если известна информация об особенностях функционирования агента пользовате-

ля,

сервер может посылать разные коды ответов. Например, некоторые агенты

пользователя, созданные до появления НТТР/1.1, не воспринимают ответ 303 See

Other, но при получении ответа 302 Found, они реагируют точно так же, как долж-

\\ы были бы в соответствии со спецификацией реагировать па ответ 303 See Other.

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

ответ 302 Found вместо ответа 303 See Other.

КЛАСС (1ХХ) КОДОВ ОТВЕТОВ НТТР/1.1. ИНФОРМАЦИОННЫЕ СООБЩЕНИЯ

В НТТР/1.0 (RFC 1945), не определено никаких кодов информационного клас-

са (1хх), тогда как в НТТР/1.1, как показано в таблице 7.7, зарезервировано два

новых кода ответов этого класса. В НТТР/1.0 была правильно предугадана необхо-

димость этого класса ответов. Фактически документ RFC 1945 даже включал огра-

ничения на ответы класса (1хх) (ответы не могли иметь тел), хотя сами коды со-

стоя{П1я класса (1хх) в то время отсутствовали.

Таблица 7.7. Класс (1хх) кодов состояния ответов (ипформациопиые сообщения)

Код состояния и строка сообщения

100 Continue

101 Switching Protocols

Краткое описание

Передача запроса разрешена

Псреключспис па другой протокол

Раздел 1

7.4.2

КЛАСС (2ХХ) КОДОВ ОТВЕТОВ НТТР/1.1. УСПЕШНОЕ ЗАВЕРШЕНИЕ

Класс 2хх объединяет семь кодов ответов, четыре из которых перешли из

НТТР/1.0. В таблице 7.8 приведены старые и новые коды, а также разделы, в кото-

рых обсуждается назначение новых кодов ответов.

Глава 7. HTTP/1.1 233

Таблица 7.8. Класс (2хх) кодов состояний ответов (успешное завершение).

'*' обозначены коды ответов HTTP/1.0.

Код состояния и строка сообщения

200 ОК*

201 Created*

202 Accepted*

203 Non-Authoritative Information

204 No Content*

205 Reset Content

206 Partial Content

Краткое описание

Запрос принят

Добавление вариантов

Временный ответ

Метаданные не полны

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

представление

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

представление

Успешный запрос па диапазон

Раздел I

6.2.4

7.3.3

6.2.4

7.12.3

7.4.1,

7.12.з]

КЛАСС (ЗХХ) КОДОВ ОТВЕТОВ НТТР/1.1. ПЕРЕАДРЕСАЦИЯ

Коды ответов класса Зхх используются для определения альтернативных дейст-

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

го запроса. Старый код состояния ответов, связанный с нереадресацией в НТТР/1.0,

300 Multiple Choices имеет в НТТР/1.1 несколько иное значение. Значение другого

кода состояния НТТР/1.0, 302 Found, было также изменено. Кроме того, в НТТР/1.1

добавлены четыре новых кода состояния, относящихся к нереадреса1Н1и. В таб;н1це 7.9

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

изменения.

Таблица 7.9. Класс (Зхх) кодов состояний ответов (персадресацня).

С помощью '*' помечены коды ответов НТТР/1.0

Код состояния и строка сообщения

300 Multiple Choices*

|301 Moved Permanently*

302 Found*

303 See Other

304 Not Modified*

305 Use Proxy

306 (Unused)

307 Temporary Redirect

Краткое описание

Основной код ответа

Новое мсстоположепне ресурса

Изменена строка оппсапня кода

состояния

Некорректная обработка ответа 302

Подтверждение актуальности ответа

Повторить запрос через прокси-сервер

Код вышедший из употребления

Временное изменение URI

Раздел 1

7.9

6.2.4

7.12.3

6.2.4

7.12.3

7.12.3 J

Хотя агент пользователя может не отображать строку описания (фраза па есте-

ственном языке, поясняющая код состояния), ассоциированную с ответом, эти

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

Строка сообщения для кода состояния 302 была изменена при nepexozie от

НТТР/1.0 к НТТР/1.1. Исходная строка сообщения в первых дискуссиях и реали-

зациях была Found, по в RFC 1945 эта строка была из-за небрежности заменена па

Moved Temporarily. Новый вариант этой строки сообщения в НТТР/1.1

—

Found.

234

Часть

III. Web-протоколы

КЛАСС (4ХХ) КОДОВ ОТВЕТОВ НТТР/1.1. ОШИБКИ НА СТОРОНЕ КЛИЕНТА

В НТТР/1.1 появилось 14 новых кодов ответов, относящихся к классу ошибок на

стороне клиента. Новые коды отражают значительно расширенный диапазон откли-

ков,

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

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

казано в таблице 7.10. Первая категория включает четыре кода ответов НТТР/1.0.

Добавились четыре новые категории:

• Коды уточнения состояния. Данные четыре кода ответов уточняют некото-

рые из старых кодов ответов, имевшихся в НТТР/1.0. Изменения относитель-

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

ситуаций.

• Коды согласования. Так как некоторые Web-ресурсы доступны в нескольких

вариантах (язык, набор символов и т.д.), в НТТР/1.0 был введен механизм со-

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

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

зователя. Ключевое изменение в НТТР/1.1

—

это расширение возможностей

согласования между источником и получателем: процесс согласования может

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

• Коды, связанные с размером. В этой категории два кода. Понятие размера

возникает в двух контекстах: размер содержания сообщения и размер URI за-

проса. Серверы могут требовать принятия некоторых мер, основанных на от-

сутствии или присутствии информации о размере.

• Коды состояний, связанные с новыми требованиями. Этот класс состоит из

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

ния возможностей в НТТР/1.1. Они отличаются от предыдущих двух катего-

рий, в которых НТТР/1.0 не предлагал никаких возможностей, требующих

этих кодов.

Таблица 7.10. Класс кодов ответов (4хх). Ошибки па стороне клиента.

С помощью '*' помечены коды ответов НТТР/1.0

Классификация

Коды ошибок НТТР/1.0

Уточнение кодов НТТР/1.0

Использование возможности

согласования НТТР/1.1

Коды, отгюсящиеся к размеру

Код состояния и строка сообщения

400 Bad Request*

401 Unauthorized*

403 Forbidden*

404 Not Found*

405 Method Not Allowed

407 Proxy Authentication Required

408 Request Timeout

410 Gone

406 Not Acceptable

415 Unsupported Media Type

413 Request Entity Too Large

411 Length Required

414 Request-URI Too Long

Раздел 1

6.2.4

7.12.3 1

7.11

7.12.3

7.9

7.12.3

7.10

Глава

7.HTTP/t1

235

Классификация

Новые коды для других

возможностей НТТР/1.1

Код состояния и строка сообщения

402 Payment Required

409 Conflict

412 Precondition Failed

416 Requested Range Not Satisfiable

417 Expectation Failed

Раздел 1

7.12.3

7.3.3

7.4.1

7.4.2 j

КЛАСС (5XX) КОДОВ ОТВЕТОВ НГГР/1.1. ОШИБКИ НА СТОРОНЕ СЕРВЕРА

Коды ответов класса 5хх возвращаются в том случае, когда серверу не удается

обработать данный запрос или он обнаруживает ошибку. В НТТР/1.0 было четыре

кода ответов класса 5хх, тогда как в HTTP/1.1 их стало шесть. Коды ответов клас-

са 5хх приведены в таблице 7.11.

Таблица 7.11. Класс (5хх) кодов ответов. Ошибки па стороне сервера.

С помощью '*' помечены коды ответов НТТР/1.0.

Код состояния и строка сообщения

500 Internal Server Error*

501 Not Implemented*

502 Bad Gateway*

503 Service Unavailable*

504 Gateway Timeout

[505 HTTP Version Not Supported

Краткое описание

Непредвидешюе состояние сервера

Отсутствие функции

Ошибка расположенного на пути

сообщения сервера

Временно невозможно обработать запрос

Расположенный на пути сообщения

сервер превысил лимит времени па ответ

Версия протокола не поддерживается

Раздел 1

6.2.4

7.3.3

7.12.3

В НТТР/1.1 было определено использование заголовка Retry-After с ответом

503 Service Unavailable в НТТР/1.0. Было введено два новых кода состояния: 504

Gateway Timeout и 505 HTTP Version Not Supported.

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

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

кодов ответов в НТТР/1.1.

7.3.

Кэширование

Кэш — это намять для хранения ответов с целью их последующего повторного

использования. Спецификация HTTP включает несколько важных правил относя-

щихся к кэшированию. Эти правила относятся к возможности кэширования

(cacheability), проверке актуальности (validation) и согласованности (coherence)

ответов, хранящихся в кэше. Однако стратегические решения, такие как замещение

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

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

просов кэширования, относящихся к компетенции протокола. Более углубленное

обсуждение общих вопросов кэширования можно найти в главе 11. Мы начнем

с краткого обзора терминологии относящейся к кэшированию вообще и в связи

236

Часть

III. Web-протоколы

с протоколом, затем рассмотрим механизм кэширования в НТТР/1.0. Далее обсу-

дим новые заголовки в НТТР/1.1, связанные с кэшированием.

7.3.1.

Термины, относящиеся к кэшированию

в спецификации протокола используются несколько терминов, связанных с кэ-

ппфовапием. Ответ, который был получен от Web-сервера, может быть сохранен

в кэше на некоторы!! период времени. В зависимости от нескольких критериев от-

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

проса на тот же ресурс. Как правило, в связи с кэшированием используются сле-

дующие термины:

• Возраст (age). Возраст ответа

—

это или время с момента создания его содер-

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

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

• Срок годности (expiration time). Срок годности помещенного в кэш содержи-

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

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

в качестве ответа. Если сервер-источник не устанавливает срока годности, кэш

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

деляемый на основе эвристик, срок годности. Срок годности также измеряется

в секундах.

• Период актуальности (freshness lifetime) и устаревание (staleness). Ответ

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

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

вится некорректным трактовать данный ответ как неустаревший. Как только

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

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

сурс на сервере-источнике или нет. Таким образом, период актуальности— это

период време]Н1 от того момента, когда ответ был создан, и до истечения срока

его годности. Актуальность

—

это период, тогда как срок годности

—

конкрет-

ный момент времени.

• Актуальность (validity). Кэш может проверить па сервере-источнике, являет-

ся ли копия конкретного ресурса, хранящегося в кэше, актуальной. Такая про-

верка называется проверкой актуальности (revalidation). Проверка актуально-

сти может осуществляться по отношению не только к серверу-источнику, но и

прокси-серверу.

• Возможность кэширования (cacheability). Кэш должен принять решение, со-

хранять ответ в кэше или нет. Возможность сохранения ответа в кэше зависит

от ^нloжecтвa факторов, например, от наличия разрешения сервера-источника,

сохранять да1Н1ЫЙ ответ в кэше и от отсутствия явного указания срока годно-

сти.

EcjHi даже какое-то содержимое помещается в кэш, может потребоваться

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

ляются взаимосвязанными, но разными понятиями. Не все ответы являются

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

• Работа с кэшем (cache maintenance). Хранящийся в кэше ответ, может быть

позднее возврап^ен. Работа с кэшем требует решения проблем, включая воз-

можность кэшировагн1я ответа, определения периода времени хранения отве-

та в кэше, принятие решения о проверки актуальности кэшированного ответа.

Глава 7. HTTP/1.1 237

7.3,2. Кэширование в НТТР/1.0

Кэширование стало предметом обсуждения уже в первых дискуссиях но

НТТР/1.0. Ко времени завершения работы над RFC 1945, в НТТР/1.0 была введе-

на минимальная поддержка кэширования. Потребность в кэширование возникла

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

большим количеством запросов па популярные ресурсы. Если ресурс не изменялся

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

и непроизводительной нагрузке на сеть и сервер.

НТТР/1.0 обеспечивал управление кэшированием следующими тремя способами:

• Директива запроса (Pragma: no-cache).

• Модификатор запроса GET (If-Modifled-Since).

• Заголовок ответа (Expires).

В НТТР/1.0 можно было использовать директиву запроса Pragma: no-cache,

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

венно от сервера-источника. Директива Pragma могла быть проигнорирована, но,

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

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

В НТТР/1.0 определен также заголовок содержимого Expires, чтобы дать воз-

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

данный ресурс можно было хранить в кэше и считать актуалынлм.

Еще одним механизмом кэширования в НТТР/1.0 являлся ус./ювный запрос GET

с использованием модификатора запроса If-Modified-Since (обсуждался в главе 6,

в разделе 6.2.3). Если копия данного ответа, хранящаяся в кэи1е но-нрежнему акту-

альна, то сервер возвращает в качестве ответа 304 Not Modified без тела ответа. От-

правитель запроса вместо этого мог использовать копию ответа из кэша. Если время

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

в запросе, сервер возвращает соответствующий код состояния (чаи1е всего 200 ОК)

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

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

кси-сервер послал запрос и получил ответ 304 Not Modified. Прокси-сервер вернет

клиенту или ответ из своего кэша, или 304 Not Modified, в зависимости от того был

ли в переданном клиентом запросе заголовок If-Modified-Since.

Некоторые из реализаций НТТР/1.0 использовали заголовок Expires некор-

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

этого ресурса (препятствуя, таким образом, его сохранению в K3uie). Это известно

как аннулирование кэша (cache busting). В решении сервера-источника аннулиро-

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

гать,

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

попытаться убедиться, что ресурс не сохраняется в кэше. Попадание в кэш (cache

hit) (успешное обнаружение запрашиваемого ресурса при обраще]Н4и к кэшу) ре-

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

«невидимо» для сервера-источника. Сервер-источник может генерировать страни-

цы,

которые включают рекламу в виде отдельных GIF-изображений. С целью уве-

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

лама передавалась клиентам при каждом посещении ими страницы. Сервер-источ-

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

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

в кэше, то запрос клиентом страницы приведет к тому, что GIF-изображения с рек-

238 Часть III. Web-протоколы

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

показов рекламы сервером-источником.

Заголовок Last-Modified обычно означает, что данный ресурс не был сгенериро-

ван динамически, и некоторые кэши, реализующие НТТР/1.0, использовали это

как критерий при принятии решения о том, можно ли дагншш ответ размещать

в кэше. Однако такой логический вывод не всегда справедлив. Некоторые динами-

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

ются. CGI-сценарий, который генерирует гг-ую цифру числа я, генерирует каждый

раз один и тот же результат. Другими словами, в зависимости от запроса и его па-

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

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

оцепить характер выполняемого сценария.

Все сравнения интервалов времени в НТТР/1.0 привязывались к отсчету абсо-

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

бовавшим доработки в НТТР/1.1.

7.3.3.

Кэширование в НТТР/1.1

Популярность Web, высокая популярность небольшого числа ресурсов, похо-

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

ту потребности в кэшировании. В то же время повсеместно ощущалась потреб-

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

Кэш должен обеспечивать возможность возвращения ответов без опасения, что

сервер-источник вернул бы другой ответ.

Некоторые ключевые правила, которым следовали при внесении изменений

в НТТР/1.1, относящихся к кэшированию, были следующими:

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

нящийся в кэше ответ использовать без опасений. Задача протокола состоит

в формулировании правил, а не выборе стратегии, как долго объект может

храниться в кэше, когда и как содержание кэша следует обновлять.

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

держками. Кэш не должен «бездумно» возвращать устаревшие значения. Спе-

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

обстоятельствах. Клиент или сервер-источник могут явным образом снизить

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

соответствует требуемому уровню прозрачности (с помощью предупреждаю-

щего заголовка, как мы увидим позже в разделе 7.12.2).

• Предоставление серверу возможности давать больше информации о возмож-

ности кэширования ресурса, а пользователям

—

контроля за тем, что хранится

в кэше.

• Независимость от абсолютного времени или от требования синхронизации

времени на клиенте и на сервере.

• Обеспечение поддержки согласования кэширования ответов.

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

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

ждалось в главе 2, раздел 2.3). Механизм регистрации предыстории позволяет

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

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

Глава 7, HTTP/1.1 239

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

сурса. Некоторые браузеры на самом деле перезагружают страницы, срок годности

которых мог истечь с того времени, когда страница была сохранена в кэше.

Так как в НТТР/1.0 уже существовало понятие об истечении срока годности

(заголовок Expires), то изменения, относящиеся к механизму кэширования, долж-

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

В НТТР/1.1 были введены механизмы для решения вопросов о возможности кэ-

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

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

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

любой возможной комбинации заголовков не определены явно. Комбинаторный

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

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

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

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

ный в RFC 791 [JonSlJ. Принцип устойчивости — положение часто цитируемое

в различных контекстах, звучит так

Компоненты должны быть либеральными при получении сообщений, и кон-

сервативными при их передаче.

Применительно к HTTP этот афоризм можно истолковать так, что компоненты,

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

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

редавать только осмысленные сочетания заголовков.

НТТР/1.1 устанавливает некоторые особые правила сочетания заголовков для

надлежащей генерации ответов из кэша. При получении ответа от сервера-источ-

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

клиенту, от которого исходит запрос. Если сервер-источник послал ответ 200 ОК,

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

его клиенту. Однако предположим, что получен ответ 304 Not Modified, то есть

кэшу разрешается использовать хранящийся в нем ответ для передачи клиенту.

Кэш не может использовать сквозные заголовки в ответе, хранящемся в кэше. Но

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

лучен от сервера-источника. Это важно, так как сервер-источник может послать от-

вет 304 Not Modified с дополнительными заголовками, например, Expires и

Cache-Control.

В НТТР/1.1 введены четыре новых заголовка, относящиеся к кэшированию:

Age,

Cache-Control, ETag и Vary. Далее обсуждается их семантика.

ЗАГОЛОВОК AGE

Сервер использует заголовок Age, чтобы указать, как давно ответ был сгенери-

рован Web-сервером. Если сервер — это кэширующий прокси-сервер (т.е. не сер-

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

xpaiiCHHoro в кэше ответа. Прокси-серверы обязаны генерировать заголовок Age.

Значение заголовка Age указывается в секундах и не может быть отрицателыш1м.

ЗАГОЛОВОК CACHE-CONTROL

В отличие от модели кэширования, принятой в НТТР/1.0, НТТР/1.1 предлага-

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

процессом кэширования и со стороны отправителя, и со стороны получателя