← Cloudflare Cache / cache / concepts

Origin Cache Control

Origin Cache Control это функция Cloudflare. Если она включена на сайте клиента с планом Enterprise, это означает, что Cloudflare должен строго соблюдать Cache-Control директивы, полученные от сервера источника. У клиентов на тарифах Free, Pro и Business эта функция включена по умолчанию.

Cache-Control директивы в ответе HTTP от вашего сервера источника задают определённые инструкции по кешированию ↗ промежуточным сервисам вроде Cloudflare.

При включенной функции Origin Cache Control Cache-Control директивы в ответе сервера источника будут соблюдаться как указано. Например, если ответ содержит max-age директива со значением 3600 секунд, Cloudflare будет кешировать ресурс в течение этого времени, прежде чем снова обратиться к серверу источника за обновлениями.

Cloudflare Cache Rules позволяет пользователям дополнять или переопределять для исходного сервера Cache-Control заголовки или политики по умолчанию заданный Cloudflare.

В следующих разделах рассматриваются:

• Наиболее распространённые Cache-Control директивы.
• Как включить Origin Cache Control.
• Как Origin Cache Control работает с Cache-Control директивы.
• Как другие продукты Cloudflare взаимодействуют с Cache-Control директивы.

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

Если передается несколько директив одновременно, они разделяются запятой. Если директива принимает аргумент, он указывается после неё через знак равенства. Например: max-age=86400.

Директивы делятся на четыре группы: кешируемость, истечение срока действия, повторная проверка, а также другое.

Пригодность к кешированию показывает, должен ли ресурс попадать в кеш. Приведённые ниже директивы определяют эту пригодность для конкретного ресурса.

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

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

• max-age=seconds Указывает, что ответ считается устаревшим, если его возраст превышает заданное число секунд. Возраст определяется как время в секундах, прошедшее с момента получения ресурса с исходного сервера. seconds аргумент представляет собой целое число без кавычек.
• s-maxage=seconds Указывает, что в общих кэшах максимальный возраст, заданный этой директивой, имеет приоритет над максимальным возрастом, заданным max-age директива или Expires заголовка. s-maxage директива также подразумевает семантику директивы proxy-revalidate директиву ответа. Браузеры игнорируют s-maxage.

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

Убедитесь, что HTTP Expires заголовок на исходном сервере задан с использованием времени по Гринвичу (GMT), как это предусмотрено в RFC 2616 ↗.

Ревалидация определяет, как должен вести себя кеш после истечения срока действия ресурса, а перечисленные ниже директивы влияют на это поведение.

• must-revalidate Указывает, что после того как ресурс устареет, кэш (клиента или прокси) не должен использовать этот ответ для последующих запросов без успешной проверки на исходном сервере.
• proxy-revalidate Имеет то же значение, что и must-revalidate директиву ответа, за исключением того, что она не применяется к приватным кешам клиента.
• stale-while-revalidate=<seconds> Если присутствует в HTTP-ответе, указывает, что кэши могут отдавать этот ответ после того, как он устареет, в течение указанного числа секунд с момента истечения срока действия ресурса. Если Always Online включен, то stale-while-revalidate и stale-if-error директивы игнорируются. Эта директива не поддерживается при использовании методов Cache API cache.match или cache.put. Дополнительную информацию см. в Документация Workers по Cache API.

• stale-if-error=<seconds> Указывает, что при возникновении ошибки для обработки запроса может быть использован устаревший кэшированный ответ, независимо от прочей информации об актуальности. Чтобы избежать такого поведения, добавьте stale-if-error=0 директиву с объектом, полученным от источника. Эта директива не поддерживается при использовании методов Cache API cache.match или cache.put. Дополнительную информацию см. в Документация Workers по Cache API.

stale-if-error директива игнорируется, если Always Online включен или передана явная директива протокола. Примеры явных директив протокола: no-store или no-cache cache директива, must-revalidate cache-response-directive или применимую s-maxage или proxy-revalidate cache-response-directive.

Ниже перечислены дополнительные директивы, влияющие на поведение кэша.

• no-transform Указывает, что промежуточный узел (независимо от того, реализует ли он кэш) не должен преобразовывать содержимое.
• vary По умолчанию Cloudflare не учитывает значения Vary при принятии решений о кэшировании. Значения Vary учитываются, если настроен Настройка Vary в Cache Rules, когда Vary for images настроен, а заголовок vary vary: accept-encoding.
• immutable Сообщает клиентам, что тело ответа не меняется со временем. Ресурс, пока не истёк срок его действия, остаётся неизменным на сервере. Пользователю не следует отправлять условный запрос на повторную проверку, например If-None-Match или If-Modified-Since, чтобы проверить наличие обновлений, даже если пользователь явно обновляет страницу. Эта директива не влияет на публичные кеши, такие как Cloudflare, но изменяет поведение браузера.

Часто возникает путаница между директивами Cache-Control: no-store и Cache-Control: no-cache, особенно в том, как они влияют на кеширование в браузере и такие функции, как Back-Forward Cache ↗ (BFCache).

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

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

Дополнительные сведения о том, как эти директивы работают при включённом или отключённом Origin Cache Control, см. в разделе Директивы раздел.

Если включить Origin Cache Control, Cloudflare будет стремиться строго соблюдать RFC 7234 ↗. Клиенты на плане Enterprise могут выбирать, должен ли Cloudflare следовать этому поведению, включая или отключая Origin Cache Control для своих сайтов через Cache Rules в панель управления или через API. У клиентов на планах Free, Pro и Business эта опция включена по умолчанию и не может быть отключена.

В этом разделе рассматриваются директивы и условия поведения, связанные с включением и отключением Origin Cache Control.

В таблице ниже перечислены директивы и их поведение при отключённом и включённом Origin Cache Control.

Некоторые сценарии также влияют на поведение Origin Cache Control, независимо от того, включена эта функция или отключена.

Ознакомьтесь с примерами ниже, чтобы узнать, какие директивы использовать с Cache-Control заголовок для управления определённым поведением кеширования.

В этом разделе описано, как другие функции Cloudflare взаимодействуют с Cache-Control директивы.

Edge Cache TTL Cache Rules переопределяют s-maxage и отключает директивы повторной проверки, если они присутствуют. Когда Origin Cache Control включен в Cloudflare, исходный Cache-Control заголовок передаётся дальше по цепочке от периферийного сервера Cloudflare, даже если заданы переопределения Edge Cache TTL. В противном случае, когда Origin Cache Control отключён в Cloudflare, Cloudflare переопределяет Origin Cache Control.

Browser Cache TTL Cache Rules переопределяют max-age настройки, передаваемые далее из нашей периферийной сети, как правило в браузеры ваших посетителей.

Polish отключён, если no-transform директива присутствует.

Сжатие отключено, если no-transform директива присутствует. Если исходный ресурс, полученный от источника, сжат, он отдаётся посетителю в сжатом виде. Если исходный ресурс не сжат, сжатие не применяется.

JavaScript Detections внедрение отключено, если no-transform директива присутствует. cf.bot_management.js_detection.passed поле будет отображаться как missing для затронутых запросов.