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

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

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

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

•          Разделение вопросов о том, можно ли размещать ответ в кэше и можно ли хранящийся в кэше ответ использовать без опасений. Задача протокола состоит в формулировании правил, а не выборе стратегии, как долго объект может храниться в кэше, когда и как содержание кэша следует обновлять.

•          Обеспечение корректности, даже если это связано с дополнительными издержками. Кэш не должен «бездумно» возвращать устаревшие значения. Спецификация допускает ослабление семантической прозрачности в некоторых обстоятельствах. Клиент или сервер-исгочпик могуг явным образом снизить уровень прозрачности. Кэш может предупреждать пользователя, если ответ не соответствует требуемому уровню прозрачности (с помощью предупреждающего заголовка, как мы увидим позже в разделе 7.12.2).

•          Предоставление серверу возможности давать больше информации о возможности кэширования ресурса, а пользователям — контроля за тем, что хранится в кэше.

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

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

Рассматривалось несколько других менее значительных вопросов, таких как разделение механизмов кэширования и регистрации предыстории браузером (обсуждалось в главе 2, раздел 2.3). Механизм регистрации предыстории позволяет пользователю обращаться к предшествующим запросам независимо от актуальности ресурса, представленного пользователю. Протокол все же позволяет агентам пользователя давать пользователю информацию об устаревании конкретного ресурса. Некоторые браузеры на самом деле перезагружают сграиицы, срок годности которых мог истечь с того времени, когда страница была сохранена в кэше.

Так как в НТТР/1.0 уже существовало понятие об истечении срока годности (заголовок Expires), то измепепия, относящиеся к механизму кэширования, должны были быть совместимы с использованием времени окончания срока годностп. В НТТР/1.1 были введепы механизмы для решения вопросов о возможности кэширования и обеспечения семантической прозрачности. Кроме того, с добавлением к механизму кэширования иовых возможностей, должпы были быть созданы яспые правила для обработки сочетаний заголовков. В протоколе правила для обработки любой возможной комбинации заголовков не определены явпо. Комбипаторпый взрыв, являющийся результатом перебора всех возможных комбинаций пар заголовков, делает это невозможным. Столкнувшись с обработкой комбинаций заголовков, реализации должпы уметь адаптироваться и следовать набору основных правил. Часто используется так называемый принцип устойчивости, рассмотренный в RFC 791 Цоп81]. Принцип устойчивости — ноложепие часто цитируемое в различных коптекстах, звучит так

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

Применительно к HTTP эгот афоризм Можно истолковать гак, что компоненты, получающие сообщения, должпы быть невосприимчивы к неточностям, путанице или непредусмотренным комбинациям заголовков, по сами должпы стремиться передавать только осмысленные сочетания заголовков.

НТТР/1.1 устанавливает некоторые особые правила сочетания заголовков для надлежащей генерации ответов из кэша. При получении ответа от сервера-исгоч- ника прокси-сервер, осуществляющий кэширование, должен решить, что нослать клиенту, от которого исходит запрос. Если сервер-источник послал ответ 200 OK, возможно, с повой копией ресурса, кэш может сохранить новый ответ и передать его клиенту. Однако предположим, что получеп ответ 304 Not Modified, то есть кэшу разрешается использовать хранящийся в нем ответ для передачи клиенту. Кэш не может использовать сквозные заголовки в ответе, хранящемся в кэше. Но кэш обязан использовать сквозные заголовки в ответе, который им только что получен от сервера-источника. Это важно, так как сервер-источпик может послать ответ 304 Not Modified с дополнительными заголовками, например, Expires п Cache-Control.

В НТТР/1.1 введепы четыре новых заголовка, относящиеся к кэшированию: Age, Cache-Control, ETag и Vary. Далее обсуждается их семаптика.

ЗАГОЛОВОК AGE

Сервер использует заголовок Age, чтобы указать, как давно ответ был сгенерирован Web-сервером. Если сервер — эго кэширующий прокси-сервер (г.е. не сервер-источпик), то это значение определяет, как давно проверялась акгуалыюсть сохраненного в кэше ответа. Прокси-серверы обязаны генерировать заголовок Age. Значение заголовка Age указывается в секундах и не может быть огрицательпым.

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

В отличие от модели кэширования, принятой в НТТР/1.0, НТТР/1.1 предлагает более изощренный механизм уиравлепия кэшем. Для обеспечения управление процессом кэширования и со стороны отправителя, и со стороны получателя в НТТР/1.1 добавлен повый общий заголовок Cache-Control. И в запросах, и в ответах Можно использовать песколько директив управления кэшем, состав которых Можно расширять. Web-серверы могут потребовать, чтобы ответ был приватным и предназначался единственному пользователю. Можно также заставить кэш проверять по прошествии определенного времени актуальность сохраненных ответов перед тем, как возвращать их инициаторам запроса. Промежуточные серверы должны передавать далее директивы управления кэшем, так как они могут относиться ко всем прокси-серверам и шлюзам в цепочке запрос-ответ. Заметим, что эти директивы относятся к обязательным требованиям (уровепь MUST) и все кэши должны подчиняться им. При этом важпо помпить, что требование совместимости, предъявляемое протоколом, не означает, что кэши на самом деле будут выполнять эти директивы. В главе 15 (раздел 15.3), мы рассмотрим последствия несовместимости Web-K0Mii0iienT0B.

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

Таблица 7.12. Директивы запросов, относящиеся к управлению кэшированием

Директива

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

no-cache

only-if-cached

no-store

max-age

max-stale

min-fresh no-transform

extension tokens

Принудительная загрузка с Wcb-еервера

Получение ресурса только из кэша

Кэшам не разрешено сохранять запрос, ответ

Возраст ответа должен быть не больше данного значения

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

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

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

• no-cache. Директива запроса no-cache выполняет ту же функцию, что и директива НТТР/1.0 Pragma: no-cache; то есть любому прокси-серверу на пути между отправителем и сервером-источником не разрешено возвращать ответ из кэша. Вместо этого прокси-сервер обязап пересылать запрос дальше серве- ру-псточпнку. Этот процесс известен как «сквозпая перезагрузка (end-to-end reload)». Например, когда пользователь щелкает мышью на кнопке Reload браузера Netscape (при нажатой клавише Shift), браузер посылает директиву

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

•      onIy-if-cached. Зеркальным отражением директивы no-cache является директива only-if-cached. Вместо уверенности в том, что ответ на запрос будет по- лучеп от сервера-источника, а не из кэша, в этом случае, отправителю пужеп ответ только из кэша. Может быть, отправитель озабочен задержкой ответа или его не беспокоит актуальность кэшировапного ответа. Кэш может послать ответ, если это соответствует условиям запроса, по в других обстоятельствах может вернуть код ответа 504 Gateway Timeout. Прокси-сервер может вернуть заведомо устаревший ответ, по только если запрос не содержит других ограпичепий, таких как заголовка If-Modified-Since. Условия семантической прозрачности требуют только, чтобы прокси-серверы не возвращали устаревший ответ, не зпая о гом, что оп устарел.

•      no-store. Директива запроса no-store не допускает сохрапепия запроса и ответа в кэше. Возможно, пользователь не хочет, чтобы запрос был сохранен даже на короткое время. Директива no-store полезное средство, отвечающее требованиям конфиденциальности. Эта директива запрещает сохранять в кэше запрос, а также любой ответ на пего. Однако не существует гарантии, что запрос (или ответ) не будут случайно где-либо сохранены. Возможно, было бы лучше для пользователя зашифровать этот запрос.

•      max-age. Чтобы решить, является ли ответ в кэше устаревшим, Агент пользователя может изменить действующий по умолчанию механизм истечения срока годности с помощью директивы управления кэшированием max-age. Ответ должен иметь «возраст» меньше, чем значение времени (в секундах), определенное в директиве max-age. Таким образом, директива max-age=0 форсирует сквозпую проверку актуальности.

•      max-stale. Директива max-stale выражает готовность клиента принимать ответы из кэша, срок годности которых возможно истек. Однако время истечения срока годности ответа не должно превышать значение, указанное в значении параметра директивы (если оно имеется). Если значение параметра не за- дапо, клиент готов принять любой ответ. Задание max-stale позволяет клиентам обойти правила, которыми руководствуется прокси-сервер. Директива max-stale=60 означает, что Агент пользователя готов принять ответ, который может быть устарел, по не более чем на минуту.

•      min-fresh. Директива min-fresh выражает желание клиента принять ответ, который будет актуальным по мепьшей мере заданное число секунд. Если в качестве Значения параметра директивы min-fresh задано число 60, ожидаемый результат состоит в том, что ответ не будет устаревшим через 60 секупд.

•      no-transform. Директива no-transform не допускает, чтобы кэш измепял тин (например, text/html, image/gif) тела содержимого. Преобразование тела содержимого может включать изменение алгоритма кодирования содержания (например, сжатие тела содержимого), типа содержания (изменение формата изображения GIF на форма’1’JPEG) или проверку целостности (контрольная сумма). Одной из нричип преобразования тела содержимого является эффективность — сжатие ответа ускоряет его передачу. Однако в некоторых случаях, ответ не должен изменяться; так измепепие степени детализации медицинского снимка может привести к потере критически важной информации. Если получатель тела содержимого полагается на свою контрольную сумму ири

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

Промежуточный кэш не имеет права отменять сквозные соглашения отправителя и получателя. Директива запроса no-transform возвращает управление отправителю (и получателю в случае директивы ответа). Однако кэши могут игнорировать и игнорируют сквозные соглашения, принимая локаль- но-оптимальпые решепия. Одним из примеров, когда у кэша может быть законное основание проигнорировать директиву, является академический сайт, игнорирующий запросы на загрузку обновленных копий ресурсов сомнительного характера. Но, если кэш игнорирует любые явно заданные директивы запроса (например, no-cache), он должен включить в ответ предупреждение, указывая, что ответ, возМожно, устарел.

• лексемы расширений. Наличие возможностей расширения пабора директив управления механизмом кэширования позволяет добавлять новые директивы запросов. Однако если кэши не воспринимают или не памерепы выполнять новые директивы, они могут благонолучпо их игнорировать. Протокол требует (требование уровня MUST), чтобы перасиозпанные директивы управления кэшем игнорировались. В любых ситуациях, семантическая прозрачность кэша является Главным фактором.

Директивы ответов, относящиеся к управлению кэшированием. Директивы ответов, относящиеся к управлению кэшированием, являются для сервера средством обеспечения особого характера функционирования кэшей, расположенных на пути следования ответа. Список различных директив ответов, относящихся к управлению кэшированием, приведен в таблице 7.13. Директивы ответов предоставляют серверу возможность ограничивать кэширование ответов. Можно управлять кэшированием в диапазоне от разрешения кэшировать ответ до определения того, какие части ответа можно кэшировать и кто имеет доступ к кэшировапному ответу.

Таблица 7.13. Директивы ответов, относящиеся к управлению кэшированием

Директива

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

public

Разрешение кэшировать ответ, где угодно

private

Ответ только для конкретного пользователя

no-store

Hc разрешено кэшировать ответ, запрос

no-cache

Не обслуживать из кэша без предварительной проверки актуальности

no-transform

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

must-revalidate

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

proxy-revalidate

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

max-age

Возраст ответа не должен превышать заданного значения

s-maxage

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

лексемы расширений

Лексемы, представляющие новые директивы ответов

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

•      public. Управление кэшированием в НТТР/1.1 по большей части является симметричным. И серверы, и клиенты имеют одинаковые возможности управлять кэшированием ответов. Сервер может установить режим кэширования конкретного ответа, и эти установки буду г иметь приоритет над любыми установками, используемыми кэшами по умолчанию. Например, принимая во впимаиие, что кэш, возможно, решит не сохранять определенные ответы из опасения нарушить их конфиденциальность, сервер, включая заголовок ответа Cache-Control: public, может показать, что данный конкретный ответ можно сохранять в кэше.

•      private. Директива ответа private ограничивает возможность кэширования ответа только одним пользователем. Слово private (частный, личный, приватный) вероятно было не лучшим вариантом, так как эта директива пн коим образом не влияет на конфиденциальность сообщения. Разработчики искали ап- топим к слову shared (совместно используемый), так как директива private препятствует сохранению ответа в совместно используемом кэше. Кроме того, область действия директивы private может быть сужена со всего сообщения до его частей путем добавления параметра с именем поля. Например, включение в ответ

Cache-Control: private = "CustomerID"

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

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

•      no-cache. В отличие от директивы no-store, директива no-cache не запрещает сохранять ответ в кэше. Тем не менее, директива no-cache эффективно препятствует такому сохранению, вынуждая кэш проверить актуальность ответа на сервере-источпике до того, как отвечать на запрос. Основное пазпачепие этой директивы — существенно снизить вероятность возврата некоторыми кэшами устаревших ответов. Ответ по-прежпему может храниться в кэше, но кэш должен гараитировать его актуальность путем дополнительной проверки актуальности. Хотя дополнительная проверка увеличивает задержку, если проверка оказывается успешной, можно все же снизить издержки на загрузку ресурса с исходного сервера.

Директиву no-cache можно использовать и с именами полей заголовков и без них. Если директива включает одно или несколько имен полей заголовков, то ее действие распространяется на указанные поля заголовков. Например, предположим, что запрос выглядит следующим образом:

НТТР/1.1 200 0K Server: Apache/1.2.6 Red Hat Date: Thu, 24 Feb 2000 18:13:36 GMT Content-Type: text/html

Location: http://kinghascome.com/ads/elvis_has_left.gif Cache-Control: no-cache=Location

Смысл директивы ответа no-cache смягчен присутствием в пей дополнительных полей заголовков. Остальное содержание ответа, за исключение заголовка Location, может использоваться повторно, снижая, таким образом, неэффективную нагрузку на сеть и воспринимаемую пользователем задержку. Но существует предел контролю Web-сервера над ответом. Кэш должен удалять поле заголовка Location, прежде нем отправлять ответ клиенту. Исходный сервер, отказавшись при управлении кэшированием ответа от концепции все или пичего, может сохранить частичный контроль за ресурсами. Аналогично, с помощью директивы Cache-Control: no-cache=set-cookie2 исходный сервер может запретить сохранять в кэше заголовок Set-Cookie2 [KM00J.

•     no-transform. Директива ответа no-transform аналогична такой же директиве запроса и используется, чтобы не допустить изменения ответа (например, уменьшение разрешения изображения).

•     must-revalidate. Директива must-revalidate позволяет Web-серверу обратить внимание на то, что для некоторых ответов может оказаться слишком риско- ванным для кэша возвращать возможно устаревшие копии. Эта директива вы- пуждает кэш провести дополнительную проверку актуальности ресурса на сервере-источнике. Более важпо то, что если прокси-сервер не может осуществить проверку актуальности на сервере-источпике (например, если про- кси-сервер не может связаться с Web-сервером), то кэш должен вернуть клиенту не устаревший ответ, а сообщение об ошибке. Различие между директивой must-revalidate и похожей на первый взгляд директивой no-cache заключается в том, что кэши вряд ли сохрапят ответы, которые включают директиву no-cache. Если ответ включает директиву must-revalidate, то он может быть сохрапеп в кэше, но актуальность его должна быть проверена. Директива no-cache выпуждает кэш провести проверку независимо от того, когда этот ответ устарел. На практике, так как кэши вряд ли сохрапят ответы, которые включают директиву no-cache, запрос на такое содержимое приведет к загрузке данных с сервера-источпика, а не просто к их проверке. Использование директивы must-revalidate по сравнению с использованием директивы no-cache экономнее в отношении нагрузки на сеть. Однако пользователь, пользующийся «магазинной тележкой» в приложениях электронной коммерции, предпочтет либо точно знать ее содержимое, либо получить сообщение об ошибке, но не устаревшие данные.

Предположим, что кэш ждет ответа от предыдущего сервера на пу ги сообщения и не получает эгот ответ в течение некоторого времени. Если это вынудит кэш отказаться от выполнения директивы must-revalidate, то кэш обязан передать новый код ответа НТТР/1.1 504 Gateway Timeout (как и в случае директивы only-if-cached). Сервер может выбрать конкретное время для таймаута. Ответ 504 Gateway Timeout выглядит более содержательным, чем ответ общего характера 500 Internal Server Error.

Директива управления кэшем no-store гарантирует, что запрос-ответ не будет сохрапеп, тогда как no-cache допускает сохранение, по гарантирует, что не будут возвращаться устаревшие ответы. Директива must-revalidate допускает сохранение ответа, но гарантирует, что устаревшие ответы будут обновляться. Однако ответ, который кэш считает обновленным, может быть уже изменен на сервере-источиике. Это различие между директивами является ключевым для понимания необходимости обеих директив: no-cache и must- revalidate. Директива no-store вообще исключает кэширование. В случае no-cache существует возможность кэширования, по отсутствует риск возвращения ответа, который уже измеиеп. В случае must-revalidate существует ре- альпая возможность кэширования и не существует возможности устаревания, хотя остается возможность возвращения ответа, который уже был измепеп.

•          proxy-revalidate. Директива ответа proxy-revalidate является менее ограничительной, чем директива must-revalidate. В то время как последняя относится ко всем кэшам, proxy-revalidate не относится к не используемым совместно кэшам агентов пользователей. Кэш агента пользователя (в отличие от кэша прокси-сервера) может возвращать ответы из кэша без перепроверки. Некоторые действия (например, аутентификация) могут без риска выполняться кэшем агента пользователя однократно и запоминаться. Однако совместно используемый кэш используется многими пользователями и, следовательно, действия предпринятые от лица одного пользователя могут не подходить другому. Поэтому перепроверка ответов в совместно используемых кэшах является необходимой. Детализированное управление кэшированием типично для усовершенствований в НТТР/1.1.

•          max-age. Директива ответа max-age является предпочтительным способом задать срок годности содержимого. Наличие директивы ответа Cache-Control: max-age отменяет любое значение заголовка Expires при вычислении периода актуальности кэшированпого ответа. Это пример нового свойства НТТР/1.1, обеспечивающего большую гибкость вновь разрабатываемым компонентам: кэш, использующий НТТР/1.1, получая директиву max-age, будет придерживаться указанного гам срока годности, тогда как кэш, использующий НТТР/1.0, Обычно игнорирует директиву max-age.

•          s-maxage. Заголовок s-maxage имеет отношение только к совместно используемым кэшам и применяется для отмены значений директивы Expires и директивы max-age. Как уже обсуждалось ранее, совместно используемые кэши обязаны перепроверять ответы с истекшим сроком s-maxage.

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

ЗАГОЛОВОК ETAG

Атрибут содержимого (ETag) был сначала введен в НТТР/1.1 в качестве индикатора непрозрачности [Mog95] для сравнения содержимого кэша с возможно более повой версией. Даипый ресурс может иметь разные версии, и каждая версия будет иметь индивидуальный атрибут содержимого. Атрибут содержимого всегда связан с конкретным ресурсом и не должен использоваться для сравнения разных ресурсов. Структура атрибута содержимого созпателыю сделана непрозрачной в том смысле, что от получателей не требуется делать никаких умозаключений, исследуя строку атрибута содержимого.

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

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

Ответ для ресурса foo.html может включать атрибут содержимого следующим образом:

НТТР/1.1 200 0K

Date: Sun, 26 Dec 26 1999 18:12:26 GMT

Server: Apache/1.2.6 Red Hat .

Last-Modified: Fri, 24 Dec 1999 06:21:42 GMT

ETag: cc678-12d12-66394036

Content-Length: 15044

Content-Type: text/html

<содержание foo.html>

НТТР/1.1 принимает во внимание тот факг, что существуют многочисленные версии ресурсов, и запрос мог быть сделап на любую из этих версий. Новые модификаторы запроса в НТТР/1.1 If-Match и If-None-Match используют атрибуты содержимого. В частности эти модификаторы запроса могут быть использованы вместе с атрибутами содержимого, чтобы указать на конкретную версию ресурса. Модификатор запроса If-Match позволяет клиенту задать один и более атрибутов содержимого, чтобы проверить, совпадают ли они с текущим вариантом на сервере. Например, отправитель, использующий метод PUT для обновления ресурса, может использовать условный PUT, задавая ту версию ресурса, которую он хочет изменить, чтобы убедиться, что ресурс за это время не изменился. Если у ресурса другая версия, попытка окажется неудачной и сервер вернет код состояния 412 Precondition Failed.

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

PUT /big.html НТТР/1.1

If-Match: "er82s1poy", "weoi2re"

<новое содержание для big.html>

Сервер сравнит атрибут содержимого текущей версии big.html, чтобы определить совпадает ли он с "er82slpoy" или с "weoi2re". Если атрибут содержимого совпал с любым из них, сервер выполнит запрашиваемое действие. В этом случае, выгюлиение запроса приведет к обновлению той версии big.html, которая соответствует атрибуту содержимого. Если ни один из атрибутов содержимого в запросе не совпадает с текущей версией, сервер не будет выполнять этог запрос. Вместо этого он вернет код ответа 412 Precondition Failed.

Новый заголовок запроса If-None-Match также можно использовать с атрибутами содержимого. Хорошее применение этого заголовка — это страховка от случайного изменения существующего ресурса. Например, использование заголовка If- None-Match: * с методом PUT гарантирует, что запрос не будет успешпо завершен, если ресурс существует.

Спецификация НТТР/1.1 проводит различие между строгими и слабыми атрибутами содержимого. Строгий атрибут содержимого изменяется всякий раз, когда одно содержимое отличается от другого хотя бы на один байт. Однако Web-сервер может изменить строгий атрибут содержимого, даже когда содержимое вариантов не различается. Слабый атрибут содержимого изменяется только тогда, когда существует семантическое отличие. Предполагается, что слабый атрибут содержимого не изменяется, если Web-сервер не считает, что между вариантами существует семантическое отличие.

В отличие от НТТР/1.0 ответы 201 Created в НТТР/1.1 могуг включать атрибут содержимого. Заголовок ответа ETag, включенный в ответ 201 Created, содержит атрибут содержимого того варианта, который был создай (часто в качестве результата запроса POST).

ЗАГОЛОВОК VARY

В НТТР/1.0 URI используется в качестве ключа при сохранении и извлечении ответа из кэша. Однако различные варианты представления одного и того же ресурса делают URI пеадекватпым ключом. Согласование содержания допускает выбор ответа, основанный не только на хранящемся в кэше содержании, по и на вариантах его представления (таких как язык и набор символов). Если кэшируются ответы с согласованным содержимым, кэш должен отбирать соответствующие варианты. Заголовок ответа Vary используется для перечисления набора заголовков запросов, которые должпы использоваться для выбора соответствующих вариантов из набора, хранящегося в кэше.

Сервер определяет, какие критерии должны быть использованы для выбора подходящего варианта. Например, рассмотрим следующий ответ, который посылает Web-cepBep:

НТТР/1.1 200 0K

Date: Sun, 26 Dec 26 1999 18:12:26 GMT Server: Apache/1.2.6 Red Hat Last-Modified: Fri, 24 Dec 1999 06:21:42 GMT ETag: cc678-12d12-66394036 Content-Length: 15044 Content-Type: text/html Vary: Accept-Language

Кэш, сохраняющий данный ответ, должен также сохранить значение заголовков запросов перечисленных в заголовке ответа Vary (в данном примере Accept- Language). Если последующий запрос, сделаипый к кэшу, касается получения кэ- шированного ответа, кэш должен убедиться, что все заголовки в этом запросе, которые перечислены в заголовке Vary, идентичны тем, которые были в исходном запросе. Таким образом, если в исходном запросе, результатом которого стал данный ответ, было

Accept-Language: en-us

тогда для того, чтобы кэш вернул кэшированпый ответ на последующий запрос, в пем должпо быть Accept-Language: en-us. Если в последующем запросе имеется

Accept-Language: en-cockney

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

Источник: Web-протоколы. Теория и практика. — M.: ЗАО «Издательство БИНОМ», 2002 г. – 592 c.: ил.

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете оставить ответ, или trackback с вашего собственного сайта.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100