Перейти к содержанию

Глава 29. Кэширование

Действия кэширования управляют хранением HTTP-ответов в кэше прокси (L1 RAM + L2 Disk). Доступны в слое <Cache>.

Аналог BlueCoat: cache().

29.1. cache(yes/no) — кэшировать объект

Разрешает или запрещает кэширование HTTP-ответа.

Синтаксис:

cache(yes|no)

where: yes — разрешить кэширование; no — запретить кэширование (ответ не сохраняется в кэш).

Тип: Нетерминальное.

Слои и транзакции: Cache. Применяется к HTTP-транзакциям.

Пример:

<Cache>
    url.path=/api cache(no)
    cache(yes)

См. также: bypass_cache, force_cache


29.2. bypass_cache(yes|no) — пропустить кэш

Управляет тем, обходится ли кэш: - bypass_cache(yes) — запрос всегда отправляется на origin, минуя кэш (и чтение, и запись). - bypass_cache(no)значение по умолчанию — использовать кэш (закешированные части отдаются из кэша).

Голое bypass_cache принимается как сокращение для bypass_cache(yes).

Синтаксис:

bypass_cache(yes|no)
bypass_cache         ; = bypass_cache(yes)

Тип: Нетерминальное. bypass_cache(no) не обходит кэш (эквивалент дефолта).

Слои и транзакции: <Cache>, <Proxy>. HTTP/HTTPS/FTP-over-HTTP.

Соответствие BlueCoat 7.3: дословно — «bypass_cache(yes): played directly from the server even if cached; (no) (the default): cached portions play from the cache».

Пример:

<Cache>
    authenticated=yes bypass_cache

См. также: cache(yes/no)


Объявляет, что контент по этому URL варьируется в зависимости от значения Cookie (персонализирован под пользователя/сессию). Объект с таким признаком нельзя обслуживать из общего (shared) кэша — иначе один пользователь получил бы кэшированный контент другого. Поэтому по BlueCoat 7.3 cookie_sensitive(yes) имеет тот же эффект, что cache(no) — объект не кэшируется. Это policy-аналог HTTP-механизмов Vary: Cookie / Cache-Control: private, когда origin их не выставил. Из того же семейства, что ua_sensitive() (зависимость от User-Agent).

Синтаксис:

cookie_sensitive(yes|no)

Значение по умолчанию — no (кэшировать как обычно, по HTTP-заголовкам).

Тип: Нетерминальное.

Слои и транзакции: <Cache>. HTTP proxy (кроме FTP-over-HTTP).

Поведение: cookie_sensitive(yes) запрещает кэширование (как cache(no)/bypass_cache); cookie_sensitive(no) молча ничего не делает (кэширование по умолчанию). При сохранении политики имя cookie_sensitive(...) сохраняется без изменений.

Пример:

<Cache>
    ; Личный кабинет персонализирован по cookie — не кэшировать
    url.path=/dashboard cookie_sensitive(yes)

См. также: cache(yes/no), bypass_cache


29.3. force_cache — принудительное кэширование

Принудительно кэширует ответ, даже если сервер указал Cache-Control: no-cache, no-store или private. Переопределяет директивы кэширования origin-сервера.

Синтаксис:

force_cache

Тип: Нетерминальное.

Слои и транзакции: Cache. Применяется к HTTP-ответам.

Пример:

<Cache>
    url.extension=(jpg, png, css, js, woff2) force_cache ttl(86400)

См. также: ttl


29.4. ttl(seconds) — время жизни в кэше

Переопределяет TTL (время жизни) объекта в кэше. Приоритетнее заголовков Cache-Control: max-age и Expires от сервера.

Синтаксис:

ttl(<seconds>)

where: seconds — целое число, время жизни в секундах.

Тип: Нетерминальное.

Слои и транзакции: Cache. Применяется к кэшируемым HTTP-ответам.

Пример:

<Cache>
    url.extension=(css, js) ttl(3600)          ; 1 час
    url.extension=(jpg, png, gif) ttl(86400)   ; 1 сутки

См. также: force_cache


29.4a. always_verify(yes|no) — всегда ревалидировать с origin

Управляет тем, ревалидируется ли кэшированный объект с origin-сервером (OCS) при каждом запросе к данному URL. URL-специфичная альтернатива глобальной настройке always-verify-source.

  • always_verify(yes) — на каждый запрос принудительная ревалидация с origin (даже если объект свеж по max-age). Множественные одновременные обращения сводятся к одному запросу к origin.
  • always_verify(no)значение по умолчанию — обычное кэш-поведение (отдача из кэша, пока свежо).

Голое always_verify = always_verify(yes).

Синтаксис:

always_verify(yes|no)
always_verify          ; = always_verify(yes)

Тип: Нетерминальное. always_verify(no) — дефолт (не форсит ревалидацию).

Слои и транзакции: <Cache>, <Proxy>.

Пример:

<Cache>
    url.domain=//prices.example.com/ always_verify(yes)   ; всегда свежие цены

Поведение: при always_verify(yes) ответ из кэша не отдаётся без ревалидации с origin-сервером.

Соответствие BlueCoat 7.3: дословно — «verify each request for the objects at a particular URL with the origin content server… The default behavior is no… simultaneous accesses reduced to a single request». Слои <Cache>/<Proxy>.

При always_verify(yes) второй запрос ревалидируется с origin-сервером; при always_verify(no) ответ отдаётся из кэша.

См. также: refresh


29.5. refresh(yes|no) / never_refresh_before_expiry(yes|no) / never_serve_after_expiry(yes|no)

Управляют ревалидацией и отдачей stale-объектов из кэша. Все три — форма (yes|no), голое имя = (yes).

Синтаксис:

refresh(yes|no)
never_refresh_before_expiry(yes|no)
never_serve_after_expiry(yes|no)
Действие Семантика BlueCoat 7.3
refresh(no) НЕ ревалидировать кэшированный объект — отдавать из кэша. refresh(yes) (default) — обычное поведение.
never_refresh_before_expiry(yes) Не ревалидировать свежий объект до истечения TTL (даже если клиент форсит, напр. Cache-Control: max-age=0).
never_serve_after_expiry(yes) Никогда не отдавать stale (просроченный) объект — обязательно тянуть свежее.

Тип: Нетерминальное (все три). <Cache>, <Proxy>.

Пример:

<Cache>
    ; «Замороженный» контент — отдавать из кэша без ревалидации
    url.domain=//static.example.com/ refresh(no)
    ; Не дёргать origin лишний раз, пока объект свеж
    url.extension=(css, js) never_refresh_before_expiry(yes)
    ; Котировки: после истечения — только свежие, stale не отдавать
    url.domain=//prices.example.com/ never_serve_after_expiry(yes)

Поведение: - refresh(no) — объект трактуется как свежий (отдаётся без ревалидации). - never_refresh_before_expiry(yes) — пока объект не просрочен, ревалидация подавляется даже при клиентском max-age=0. - never_serve_after_expiry(yes) — просроченный объект не отдаётся из кэша (запрашивается свежий).

Соответствие BlueCoat 7.3: дословно — refresh(no)=«prevent refreshing of the object if it is cached»; never_refresh_before_expiry ≈ http strict-expiration refresh; never_serve_after_expiry ≈ http strict-expiration serve. Слой <Cache>.

Поведение: - refresh(no) — объект с no-cache отдаётся из кэша без обращения к origin-серверу. - never_refresh_before_expiry(yes) — свежий объект отдаётся вопреки клиентскому max-age=0. - never_serve_after_expiry(yes) — просроченный объект не отдаётся из кэша. На практике эффект совпадает с поведением по умолчанию: кэш и так не отдаёт просроченные объекты без ревалидации, поэтому директива служит дополнительной гарантией.


29.6. http.allow_compression(yes|no) / http.allow_decompression(yes|no) — (де)компрессия на лету

Управляют тем, может ли прокси сжимать/распаковывать тело ответа «в полёте». Значение по умолчанию у обоих — no.

  • http.allow_compression(yes) — прокси может сжать несжатый ответ origin перед отдачей клиенту (если клиент принимает кодировку, Accept-Encoding).
  • http.allow_decompression(yes) — прокси может распаковать сжатый ответ на лету (например, чтобы отдать клиенту, не принимающему encoding, или для инспекции). После распаковки Content-Encoding снимается.

Синтаксис:

http.allow_compression(yes|no)
http.allow_decompression(yes|no)

Тип: Нетерминальное. Слои: <Cache>, <Proxy>. HTTP-транзакции (proxy, refresh, pipeline).

Пример:

<Proxy>
    ; Сжимать текстовые ответы для мобильных клиентов
    request.header.User-Agent="Mobile" http.allow_compression(yes)
    ; Распаковывать для последующей инспекции/трансформации
    url.domain=//scan.example.com/ http.allow_decompression(yes)

Поведение: - http.allow_compression(yes) — прокси сжимает ответ согласно Accept-Encoding клиента, в дополнение к глобальной настройке сжатия. - http.allow_decompression(yes) — ответ отдаётся распакованным, заголовок Content-Encoding снимается.

Соответствие BlueCoat 7.3: дословно — «Determines whether the HTTP proxy is allowed to compress/decompress data in transit», default no, слои <Cache>/<Proxy>.

Поведение: - http.allow_compression(yes) — ответ приходит с Content-Encoding: gzip. - http.allow_decompression(yes) — gzip-ответ origin-сервера отдаётся клиенту распакованным (без заголовка Content-Encoding).


29.6a-enc. http.client.allow_encoding(br|deflate|gzip, ...) — какие кодировки разрешены клиенту

Назначение. Ограничивает, какие content-encodings прокси может использовать в ответе клиенту. В отличие от http.allow_compression (факт «сжимать или нет», P93), это выбор набора кодировок. Слой <Proxy> (и др.).

Синтаксис (реализована каноническая форма):

http.client.allow_encoding(deflate)            ; только deflate
http.client.allow_encoding(gzip, deflate)      ; gzip или deflate

Семантика. Прокси при выборе кодировки ответа берёт лучшую из (принятых клиентом Accept-Encoding) ∩ (разрешённых политикой), предпочтение gzip > deflate, иначе без сжатия (Identity). Пример: клиент шлёт Accept-Encoding: gzip, deflate, политика allow_encoding(deflate) → прокси отдаёт deflate (хотя по умолчанию предпочёл бы gzip).

Пример.

<Proxy>
  http.allow_compression(yes) http.client.allow_encoding(deflate)

Поведение. Прокси умеет производить только gzip/deflate, поэтому allow_encoding(br) (br прокси не генерирует) приводит к ответу без сжатия.

Поведение: allow_encoding(deflate)Content-Encoding: deflate (принудительно поверх gzip); allow_encoding(br) → нет Content-Encoding.

Ограничение: формы .enc(yes|no) и [enc,..](yes|no) пока не поддерживаются — политика с ними отвергается валидатором (поддерживается только каноническая форма (enc,..)).


29.6b. http.compression_level(low|medium|high) — уровень сжатия

Задаёт уровень (степень) сжатия, применяемый HTTP-прокси, когда активна http.allow_compression() (§29.6). Чем выше уровень — тем лучше сжатие (меньше размер), но больше CPU.

Синтаксис:

http.compression_level(low|medium|high)

where: low — быстрое сжатие (flate2::Compression::fast); medium — по умолчанию (Compression::default); high — максимальное (Compression::best).

Тип: Нетерминальное. Слои: <Cache>, <Proxy>. Применяется только вместе с http.allow_compression(yes).

Пример:

<Proxy>
    url.domain=//static.example.com/ http.allow_compression(yes) http.compression_level(high)

Соответствие BlueCoat 7.3: «Determines the compression level used by HTTP proxy when http.allow_compression() is true», значения low|medium|high.

Поведение: уровень low соответствует быстрому сжатию, medium — сжатию по умолчанию, high — максимальному.

Поведение: на одном и том же теле high даёт строго меньший сжатый ответ, чем low (оба Content-Encoding: gzip), что подтверждает реальное применение уровня сжатия.


29.6c. http.client.persistence(yes|no|preserve) — keep-alive клиентского соединения

Управляет persistence (keep-alive) клиентского соединения к прокси: - yes — принудительно держать соединение живым (keep-alive); - no — закрыть соединение после ответа (прокси отдаёт Connection: close клиенту); - preserveпо умолчанию — оставить как запросил клиент (не переопределять).

Синтаксис:

http.client.persistence(yes|no|preserve)

Тип: Нетерминальное. Слои: <Proxy> (и connection-фаза).

Пример:

<Proxy>
    ; закрывать соединение для отдельного класса трафика
    url.path=/one-shot/ http.client.persistence(no)

Соответствие BlueCoat 7.3: «Controls persistence of individual client connections to the HTTP client», (yes|no|preserve).

Поведение: значение управляет keep-alive соединения (yes — держать живым, no — закрыть, preserve — молча ничего не делать) и влияет на заголовок Connection в ответе.

Поведение: persistence(no) → ответ с Connection: close; persistence(yes) → keep-alive (закрытие не навязывается), если origin-сервер не выставил собственный заголовок Connection.


29.6a. HTTP-свойства соединения — пока не реализованы

Следующие HTTP-свойства существуют в BlueCoat 7.3, но в Redcoat не реализованы. Применяется безопасный отказ: парсер их не принимает, политика с ними отвергается валидатором (а не молча игнорируется). Семантика приведена для справки и будущей реализации.

Свойство (BlueCoat 7.3) Синтаксис Семантика Статус
http.client.recv.timeout() (auto\|recv-timeout) Таймаут приёма байт от клиента не реализовано
http.dns_handoff() (yes\|no) Передача DNS-запросов на DoH-серверы (DNS-over-HTTPS) не реализовано
http.force_ntlm_for_server_auth() (yes\|no) Принудительный NTLM для серверной аутентификации (обходной путь для Microsoft; переопределение глобальной настройки http force-ntlm на уровне правила) не реализовано
http.refresh.recv.timeout() (auto\|recv-timeout) Таймаут приёма от вышестоящего сервера при ревалидации (родственник http.client.recv.timeout) не реализовано

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

Уже реализовано (вынесено из этой таблицы): http.request.apparent_data_type.allow()/.deny() — см. §37.2.