Модель проверки пригодности

Когда кэш имеет устаревшую запись, которую бы он хотел использовать в качестве отклика на запрос клиента, он сначала должен произвести сверку с базовым сервером (или, возможно, промежуточным кэшем, содержащим свежий отклик), чтобы убедиться, что кэшированная запись все еще применима. Мы это называем проверкой пригодности записи кэша (validating). Так как мы не хотим пересылки всей записи, если с ней все в порядке, и мы не хотим тратить лишнее время изза RTT в случае, если запись более не пригодна, протокол HTTP/1.1 поддерживает использование условных методов.

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

Сервер сверяет полученный валидатор с текущим валидатором объекта, и, если они совпадают, посылается отклик с соответствующим статусным кодом (обычно, 304 (Not Modified)) и без тела объекта. В противном случае возвращается полный отклик (включая тело объекта). Таким образом, мы избегаем передачи полного отклика, если валидаторы взаимно согласованы.

В HTTP/1.1 условный запрос выглядит точно так же, как и обычный запрос того же самого ресурса, за исключением того, что он несет в себе специальный заголовок (который содержит валидатор) и неявно меняет обычный метод GET на условный.

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

Замечание. Отклик, который не имеет валидатора, может кэшироваться и использоваться до истечения его срока годности, если только это явно не запрещено директивой Cache-Control. Однако кэш не может выполнить условную доставку ресурса, если он не имеет валидатора для запрашиваемого объекта, что означает отсутствие возможности его актуализации после истечения срока годности.

Даты последней модификации

Значение поля заголовка объекта Last-Modified часто используется кэшем в качестве валидатора. Иными словами, запись в кэше рассматривается как пригодная, если объект не был модифицирован с момента, указанного в Last-Modified.

Валидаторы кэша для меток объектов (Entity Tag Cache Validators)

Значение поля заголовка объекта ETag (Entity Tag — метка объекта), представляет собой непрозрачный валидатор кэша. Это может гарантировать большую надежность при контроле пригодности в ситуациях, когда неудобно запоминать модификации дат, где недостаточно односекундного разрешения для значения даты HTTP или где исходный сервер хочет избежать определенных парадоксов, которые могут возникнуть от использования дат модификации.

Слабые и сильные валидаторы

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

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

Метки объекта обычно являются сильными валидаторами, но протокол предлагает механизм установки слабой метки объекта. Можно считать, что сильный валидатор — это тот, который изменяется, если меняется хотя бы один бит в объекте, в то время как значение слабого изменяется при вариации значения объекта.

Сильный валидатор представляет собой часть идентификатора конкретного объекта, а слабый валидатор является частью идентификатора набора семантически эквивалентных объектов.

Замечание. Примером сильного валидатора является целое число, которое увеличивается на единицу всякий раз, когда в объект вносится какое­-либо изменение.

Время модификации объекта при односекундном разрешении может быть лишь слабым валидатором, так как имеется возможность того, что ресурс может быть модифицирован дважды в течение одной и той же секунды.

Поддержка слабых валидаторов является опционной. Однако слабый валидатор позволяет более эффективно кэшировать эквивалентные объекты.

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

Сильные валидаторы могут использоваться в любом контексте. Слабые валидаторы применимы только в контексте, который не зависит от точной эквивалентности объектов. Например, как один, так и другой вид валидаторов применим для условного GET. Однако только сильный валидатор применим для фрагментированного извлечения ресурсов, так как в противном случае клиент может прервать работу с внутренне противоречивым объектом.

Единственной функцией протокола HTTP/1.1, определенной для валидаторов, является сравнение. Существует две функции сравнения валидаторов, в зависимости от того, допускает ли контекст использование слабых валидаторов или нет.

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

• Функция слабого сравнения. Для того, чтобы считаться равными, оба валидатора должны быть идентичными, но либо оба, либо один из них могут иметь метку "слабый" без какого-либо воздействия на результат.

Функция слабого сравнения может быть использована для простых (nonsubrange — не фрагментных) GETзапросов. Функция сильного сравнения должна быть использована во всех прочих случаях. Метка объекта является сильной, если она не помечена явно как слабая.

Параметр Last-Modified time при использовании в качестве валидатора запроса является неявно слабым, если невозможно установить, что он сильный, используя следующие правила:

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

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

Или:

• валидатор предполагается использовать клиентом в заголовке If-Modified-Since или If-Unmodified-Since, так как клиент имеет запись в кэше для соответствующего объекта, и

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

• предлагаемый параметр Last-Modified time соответствует моменту времени, по крайней мере, на 60 секунд раньше значения Date.

Или:

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

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

• предлагаемый параметр Last-Modified time соответствует моменту времени, по крайней мере, на 60 секунд раньше значения Date.

Этот метод базируется на том факте, что, если два различных отклика были посланы исходным сервером в пределах одной и той же секунды, но оба имеют одно и то же время Last-Modified, то, по крайней мере, один из этих откликов имеет значение Date, равное его времени Last-Modified. Произвольный 60-секундный лимит предохраняет против того, что значения Date и Last-Modified сгенерированы с использованием различных часов или в несколько разные моменты времени при подготовке отклика. Конкретная реализация может использовать величину больше 60 секунд, если считается, что 60 секунд слишком мало.

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