Глава 29. Кэширование¶
Действия кэширования управляют хранением HTTP-ответов в кэше прокси (L1 RAM + L2 Disk). Доступны в слое <Cache>.
Аналог BlueCoat:
cache().
29.1. cache(yes/no) — кэшировать объект¶
Разрешает или запрещает кэширование HTTP-ответа.
Синтаксис:
where: yes — разрешить кэширование; no — запретить кэширование (ответ не сохраняется в кэш).
Тип: Нетерминальное.
Слои и транзакции: Cache. Применяется к HTTP-транзакциям.
Пример:
См. также: bypass_cache, force_cache
29.2. bypass_cache(yes|no) — пропустить кэш¶
Управляет тем, обходится ли кэш:
- bypass_cache(yes) — запрос всегда отправляется на origin, минуя кэш (и чтение, и запись).
- bypass_cache(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(yes/no)
29.2a. cookie_sensitive(yes/no) — кэш зависит от Cookie¶
Объявляет, что контент по этому URL варьируется в зависимости от значения Cookie (персонализирован под пользователя/сессию). Объект с таким признаком нельзя обслуживать из общего (shared) кэша — иначе один пользователь получил бы кэшированный контент другого. Поэтому по BlueCoat 7.3 cookie_sensitive(yes) имеет тот же эффект, что cache(no) — объект не кэшируется. Это policy-аналог HTTP-механизмов Vary: Cookie / Cache-Control: private, когда origin их не выставил. Из того же семейства, что ua_sensitive() (зависимость от User-Agent).
Синтаксис:
Значение по умолчанию — 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-сервера.
Синтаксис:
Тип: Нетерминальное.
Слои и транзакции: Cache. Применяется к HTTP-ответам.
Пример:
См. также: ttl
29.4. ttl(seconds) — время жизни в кэше¶
Переопределяет TTL (время жизни) объекта в кэше. Приоритетнее заголовков Cache-Control: max-age и Expires от сервера.
Синтаксис:
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(no) — дефолт (не форсит ревалидацию).
Слои и транзакции: <Cache>, <Proxy>.
Пример:
Поведение: при 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).
Синтаксис:
| Действие | Семантика 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снимается.
Синтаксис:
Тип: Нетерминальное. Слои: <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).
Пример.
Поведение. Прокси умеет производить только 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.
Синтаксис:
where: low — быстрое сжатие (flate2::Compression::fast); medium — по умолчанию (Compression::default); high — максимальное (Compression::best).
Тип: Нетерминальное. Слои: <Cache>, <Proxy>. Применяется только вместе с http.allow_compression(yes).
Пример:
Соответствие 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 — по умолчанию — оставить как запросил клиент (не переопределять).
Синтаксис:
Тип: Нетерминальное. Слои: <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.