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

Глава 21. Условия сессий и кэша ответа

Условия этой главы разделены на две группы. Первая группа (разделы 21.1-21.4) проверяет состояние аутентификационной сессии пользователя. Вторая группа (разделы 21.5-21.10) оценивает свойства HTTP-ответа от вышестоящего сервера в контексте кэширования.

21.1. session.has_valid_session=

Проверяет, имеет ли текущий клиент валидную аутентифицированную сессию. Сессия считается валидной, если пользователь прошёл аутентификацию и сессия не истекла.

Статус: планируется. Использование в CPL файле приведёт к ошибке парсинга.

Синтаксис:

session.has_valid_session=yes|no

где:

  • yes — клиент имеет валидную сессию.
  • no — сессия отсутствует или истекла.

Слои и транзакции: Proxy.

Пример:

<Proxy>
    ; Запросить аутентификацию если нет сессии
    session.has_valid_session=no authenticate(my_realm)

    ; Разрешить доступ только с валидной сессией
    session.has_valid_session=yes ALLOW

См. также: session.duration= (раздел 21.2), authenticate() (глава 27).

21.2. session.duration=

Проверяет длительность текущей аутентифицированной сессии в секундах. Позволяет применять политики в зависимости от продолжительности сессии (например, принудительная повторная аутентификация после определённого времени).

Статус: планируется. Использование в CPL файле приведёт к ошибке парсинга.

Синтаксис:

session.duration=value
session.duration=range_start..range_end

где:

  • value — длительность сессии в секундах.
  • range_start..range_end — диапазон длительности (включительно).

Слои и транзакции: Proxy.

Пример:

<Proxy>
    ; Повторная аутентификация после 8 часов
    session.duration=28800..4294967295 authenticate(my_realm)

    ; Логировать долгие сессии
    session.duration=3600..7200 log.header.x-session-warning("long_session")

См. также: session.has_valid_session= (раздел 21.1), authentication.from_cache= (раздел 21.3).

21.3. authentication.from_cache=

Проверяет, были ли учётные данные пользователя проверены из локального кэша аутентификации (без обращения к серверу LDAP/RADIUS). Позволяет отличить кэшированную аутентификацию от актуальной.

Статус: планируется. Использование в CPL файле приведёт к ошибке парсинга.

Синтаксис:

authentication.from_cache=yes|no

где:

  • yes — учётные данные проверены из кэша.
  • no — учётные данные проверены на сервере.

Слои и транзакции: Proxy.

Пример:

<Proxy>
    ; Логировать кэшированные аутентификации
    authentication.from_cache=yes log.header.x-auth-source("cache")

    ; Для критических ресурсов — всегда проверять на сервере
    url.path.regex="/admin/.*" authentication.from_cache=yes authenticate(my_realm)

См. также: authentication.cache_ttl= (раздел 21.4), session.has_valid_session= (раздел 21.1).

21.4. authentication.cache_ttl=

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

Статус: планируется. Использование в CPL файле приведёт к ошибке парсинга.

Синтаксис:

authentication.cache_ttl=value
authentication.cache_ttl=range_start..range_end

где:

  • value — оставшееся время жизни кэша в секундах.
  • range_start..range_end — диапазон (включительно).

Слои и транзакции: Proxy.

Пример:

<Proxy>
    ; Принудительная повторная аутентификация при TTL < 10 минут
    authentication.cache_ttl=0..600 authenticate(my_realm)

См. также: authentication.from_cache= (раздел 21.3).

21.5. cacheable=

Проверяет, является ли HTTP-ответ кэшируемым в соответствии с RFC 7234. Ответ считается кэшируемым при выполнении следующих условий: код статуса 2xx, отсутствие директивы Cache-Control: no-store, наличие информации о свежести (Expires, max-age, или эвристическое кэширование).

Синтаксис:

cacheable=yes|no

где:

  • yes — ответ кэшируем.
  • no — ответ не кэшируем.

Слои и транзакции: Cache.

Пример:

<Cache>
    ; Принудительно кэшировать некэшируемые ответы для определённого домена
    url.domain=static.example.com cacheable=no force_cache(3600)

    ; Логировать некэшируемые ответы
    cacheable=no log.header.x-cache-miss("not_cacheable")

См. также: response.cache_control= (раздел 21.8), response.max_age= (раздел 21.10).

21.6. response.status=

Проверяет код HTTP-статуса ответа от вышестоящего сервера. Поддерживает точные значения и диапазоны.

Синтаксис:

response.status=code
response.status=range_start..range_end

где:

  • code — HTTP код статуса (100-599).
  • range_start..range_end — диапазон кодов (включительно).

Слои и транзакции: Cache, Exception.

Пример:

<Cache>
    ; Не кэшировать ответы с ошибками
    response.status=400..599 delete(cache)

    ; Кэшировать только успешные ответы
    response.status=200..299 cache(ttl=3600)

<Exception>
    ; Своя страница для 404
    response.status=404 exception(custom_404_page)

    ; Своя страница для всех серверных ошибок
    response.status=500..599 exception(server_error_page)

См. также: exception.id= (раздел 22.1).

21.7. response.cache_control=

Проверяет наличие конкретных директив Cache-Control в HTTP-ответе. Поддерживает одиночные значения и списки.

Синтаксис:

response.cache_control=directive
response.cache_control=(directive, directive, ...)

где:

  • directive — имя директивы Cache-Control: no-cache, no-store, private, public, must-revalidate, max-age и другие.

Слои и транзакции: Cache.

Пример:

<Cache>
    ; Не кэшировать ответы с no-store
    response.cache_control=no-store delete(cache)

    ; Принудительная валидация для private ответов
    response.cache_control=(no-cache, private) cache(revalidate)

См. также: cacheable= (раздел 21.5), response.max_age= (раздел 21.10).

21.8. response.has_etag=

Проверяет наличие заголовка ETag в HTTP-ответе. ETag используется для условной валидации кэша (механизм If-None-Match).

Синтаксис:

response.has_etag=yes|no

где:

  • yes — заголовок ETag присутствует.
  • no — заголовок ETag отсутствует.

Слои и транзакции: Cache.

Пример:

<Cache>
    ; Не кэшировать ответы без валидаторов
    response.has_etag=no response.has_last_modified=no delete(cache)

См. также: response.has_last_modified= (раздел 21.9), cacheable= (раздел 21.5).

21.9. response.has_last_modified=

Проверяет наличие заголовка Last-Modified в HTTP-ответе. Last-Modified используется для условной валидации кэша (механизм If-Modified-Since).

Синтаксис:

response.has_last_modified=yes|no

где:

  • yes — заголовок Last-Modified присутствует.
  • no — заголовок Last-Modified отсутствует.

Слои и транзакции: Cache.

Пример:

<Cache>
    ; Предпочитать Last-Modified для статического контента
    url.path.regex="\.(css|js|png|jpg)$" response.has_last_modified=yes cache(heuristic)

См. также: response.has_etag= (раздел 21.8), cacheable= (раздел 21.5).

21.10. response.max_age=

Проверяет значение директивы max-age из заголовка Cache-Control ответа (в секундах). Если директива max-age отсутствует в ответе, условие не совпадает. Поддерживает точные значения и диапазоны.

Синтаксис:

response.max_age=value
response.max_age=range_start..range_end

где:

  • value — значение max-age в секундах.
  • range_start..range_end — диапазон (включительно).

Слои и транзакции: Cache.

Пример:

<Cache>
    ; Переопределить короткий max-age для статики
    url.path.regex="\.(css|js|woff2)$" response.max_age=0..300 cache(ttl=86400)

    ; Логировать ответы с очень длинным max-age
    response.max_age=86400..4294967295 log.header.x-cache-note("long_ttl")

См. также: response.cache_control= (раздел 21.7), cacheable= (раздел 21.5).