Как запретить браузеру кеширование?
Заказчик специфический, каждый раз забывает обновлять кэш и каждый раз ругается. Ликбез на тему кэширования не работает, хочется на время презентаций запретить браузеру клиента кешировать контент и каждый раз подгружать его с чистого листа. Как такое реализовать лучше всего?
- Вопрос задан более трёх лет назад
- 5891 просмотр
Комментировать
Решения вопроса 1
Веб-разработчик
upd: по теме кеширования sitear.ru/material/zapret-keshirovaniya-stranicy-h.
Ответ написан более трёх лет назад
Нравится 2 2 комментария
CrewCut @CrewCut Автор вопроса
Данный мета-тег актуален, работает на мобильных устройствах? Где-то читал про него, что он уже вышел из использования, но не могу точно сказать
CrewCut: маловероятно, тег то для браузеров, соответственно и поддержку тега должен браузер осуществлять. + еще раз перечитал вопрос, а действительно оно вам надо, чую я вам не это изначально нужно, т.к. зачем клиенту запрещать кешировать страницы, что с этого заказчику. другое дело если бы заказчик хотел на своей стороне (сервера) запретить кеширование.
Предотвращение кэширования в Internet Explorer
Устаревшее и не поддерживаемое классическое приложение Internet Explorer 11 было окончательно отключено с помощью обновления Microsoft Edge в некоторых версиях Windows 10. Дополнительные сведения см. в статье Часто задаваемые вопросы о прекращении использования классических приложений Internet Explorer 11.
В этой статье описывается использование заголовков HTTP для управления кэшированием веб-страниц в Internet Explorer.
Исходная версия продукта: Internet Explorer
Исходный номер базы знаний: 234067
Аннотация
Вы можете использовать Microsoft Internet Information Server (IIS), чтобы легко помечать страницы с высокой степенью активности или конфиденциальности с помощью следующего скрипта в крайнем начале определенных страниц Active Server (ASP):
Срок действия и заголовок Expires
Настоятельно рекомендуется, чтобы все веб-серверы использовали схему для истечения срока действия всех веб-страниц. Для веб-сервера не рекомендуется предоставлять сведения об истечении срока действия через заголовок ответа HTTP Expires для каждого ресурса, возвращаемого запрашивающим клиентам. Большинство браузеров и промежуточных прокси-серверов сегодня уважают эту информацию об истечении срока действия и используют ее для повышения эффективности связи по сети.
Всегда используйте заголовок Expires, чтобы указать наиболее разумное время, когда конкретный файл на сервере должен быть обновлен клиентом. При регулярном обновлении страниц наиболее эффективным ответом будет следующий период обновления. Возьмем, например, ежедневную новостную страницу в Интернете, которая обновляется каждый день в 5 утра. Веб-сервер для этой страницы новостей должен вернуть заголовок Expires со значением 5 утра на следующий день. После этого браузеру не нужно снова обращаться к веб-серверу, пока страница не изменится.
Страницы, которые не должны изменяться, должны быть помечены датой окончания срока действия примерно один год.
Во многих случаях веб-серверы имеют одну или несколько изменяющихся страниц на сервере, которые содержат сведения, которые могут быть немедленно изменены. Эти страницы должны быть помечены сервером значением «-1» для заголовка Expires. При последующих запросах пользователя Internet Explorer обычно связывается с веб-сервером для обновления этой страницы с помощью условного запроса If-Modified-Since. Однако страница остается в кэше диска (временные файлы Интернета). Страница используется в соответствующих ситуациях без обращения к удаленному веб-серверу, например:
- когда для доступа к журналу навигации используются кнопки НАЗАД и ВПЕРЕД.
- если браузер находится в автономном режиме.
Заголовок Cache-Control
Однако некоторые страницы настолько изменчивы или конфиденциальны, что кэширование диска не требуется. Для этого Internet Explorer поддерживает заголовок HTTP 1.1 Cache-Control. Этот заголовок предотвращает кэширование определенного веб-ресурса, если значение без кэша указано сервером HTTP 1.1.
Страницы, которые хранятся вне кэша, недоступны до тех пор, пока браузер не сможет повторно использовать веб-сервер. Таким образом, серверы должны использовать заголовок Cache-Control экономно. В большинстве случаев рекомендуется использовать значение Expires: -1.
Заголовок Pragma: No-Cache
К сожалению, устаревшие серверы HTTP 1.0 не могут использовать заголовок Cache-Control. Для обеспечения обратной совместимости с серверами HTTP 1.0 Internet Explorer поддерживает специальное использование заголовка HTTP Pragma: no-cache. Если клиент взаимодействует с сервером по безопасному соединению ( https:// ), а сервер возвращает заголовок Pragma: no-cache с ответом, Internet Explorer не кэширует ответ.
Однако заголовок Pragma: no-cache не предназначен для этой цели. В соответствии со спецификациями HTTP 1.0 и 1.1 этот заголовок определяется только в контексте запроса, а не ответа. Он предназначен для прокси-серверов, которые могут препятствовать получению определенных важных запросов к целевому веб-серверу. Для будущих приложений заголовок Cache-Control является правильным средством управления кэшированием.
Метатеги HTTP-EQUIV
HTML-страницы позволяют использовать специальную форму HTTP-EQUIV тега META, которая указывает определенные заголовки HTTP из HTML-документа. Ниже приведен краткий пример HTML-страницы, в котором используются как Pragma: no-cache, так и Expires: -1:
Pragma: без кэша запрещает кэширование только при использовании через безопасное подключение. Тег META Pragma: no-cache обрабатывается так же, как и Expires: -1, если используется на небезопасной странице. Страница будет кэширована, но помечена как немедленно истекла.
Cache-Control метатеги HTTP-EQUIV игнорируются и не действуют в Internet Explorer версии 4 или 5. Чтобы использовать Cache-Control, этот заголовок должен быть указан с помощью заголовков HTTP, как описано в разделе Cache-Control выше.
Использование стандартных заголовков HTTP гораздо предпочтительнее, чем теги META. Теги META обычно должны отображаться в верхней части раздела HTML HEAD. Кроме того, существует по крайней мере одна известная проблема с тегом PRAgma HTTP-EQUIV META.
Параметры сервера для кэширования
Если заголовок Cache-Control необходимо использовать на страницах, отличных от ASP, для автоматического добавления этого заголовка может потребоваться использовать параметры в конфигурации сервера. Процесс добавления заголовков HTTP в ответы сервера для определенного каталога см. в документе сервера. Например, в IIS 4 выполните следующие действия.
- Запустите диспетчер IIS.
- В дереве компьютеров и служб откройте веб-сервер по умолчанию или соответствующий веб-сервер. Найдите каталог, содержащий содержимое, которому требуется заголовок Cache-Control.
- Откройте диалоговое окно Свойства для этого каталога.
- Перейдите на вкладку Заголовки HTTP .
- Нажмите кнопку Добавить в группе Настраиваемые заголовки HTTP и добавьте Cache-Control для имени заголовка и no-cache для значения заголовка.
Не рекомендуется использовать этот заголовок глобально на всем веб-сервере. Ограничьте его использование только контентом, который абсолютно не должен кэшироваться на клиенте.
Контрольный список проблем
Если вы применили методы, описанные в этой статье, и у вас по-прежнему возникают проблемы с кэшированием и Internet Explorer, просмотрите этот удобный контрольный список шаг за шагом, прежде чем обращаться в Корпорацию Майкрософт за технической поддержкой:
- Используется ли заголовок Cache-Control со свойством ASP Response.CacheControl или через возвращенный заголовок HTTP? Это единственный способ предотвратить кэширование в Internet Explorer.
- Вы используете Internet Explorer 4.01 с пакетом обновления 2 (SP2) или более поздней версии? Полностью предотвратить кэширование в более ранних версиях браузера невозможно.
- Вы перепроверили, что на веб-сервере включен протокол HTTP 1.1 и что он возвращает ответы HTTP 1.1 в Internet Explorer? Cache-Control заголовки недопустимы в ответах HTTP 1.0.
- Если вы используете CGI/ISAPI/Servlets на стороне сервера, точно ли вы следуете спецификации HTTP 1.1, особенно о завершении CRLF заголовков HTTP? В интересах производительности Internet Explorer обычно не умоляет ответов, которые нарушают спецификацию HTTP 1.1. Обычно это приводит к игнорированию заголовков или отчетов о непредвиденных ошибках сервера.
- Правильно ли написаны заголовки HTTP?
См. также
- Дополнительные сведения о протоколе HTTP 1.1 см. по этой внешней ссылке: RFC 2616.
- Кэш клиента в IIS
Обратная связь
Были ли сведения на этой странице полезными?
Как отключить кэш раз и навсегда на странице
Что нужно прописать на странице, чтобы все браузеры, которые заходят на эту страницу, без исключения никогда не обращались в кэш, а каждый раз заново перечитывали стили и скрипты из присоединённых файлов, т.к. там постоянно бывают изменения. Следующие предписания абсолютно не дают никакого результата:
Также безрезультатны аналогичные комманды на PHP:
Как отключить кэш для всего (css и js), навсегда и для всех браузеров?
Отслеживать
Pavel Sumarokov
задан 24 июн 2019 в 17:12
Pavel Sumarokov Pavel Sumarokov
555 1 1 золотой знак 5 5 серебряных знаков 22 22 бронзовых знака
И не дадут. Это указания кеширования самой страницы, а не включаемых файлов. Для включаемых файлов надо отдельно отдавать заголовок Cache-control, например средствами web сервера. Или делать динамические url для самих включаемых файлов, вроде
Приватный (private) кеш браузера
Приватный кеш предназначен для отдельного пользователя. Вы, возможно, уже видели параметры кеширования в настройках своего браузера. Кеш браузера содержит все документы, загруженные пользователем по HTTP. Он используется для доступа к ранее загруженным страницам при навигации назад/вперёд, позволяет сохранять страницы, или просматривать их код, не обращаясь лишний раз к серверу. Кроме того, кеш полезен при отключении от сети.
Общий (shared) прокси-кеш
Кеш совместного использования — это кеш, который сохраняет ответы, чтобы их потом могли использовать разные пользователи. Например, в локальной сети вашего провайдера или компании, может быть установлен прокси, обслуживающий множество пользователей, чтобы можно было повторно использовать популярные ресурсы, сокращая тем самым сетевой трафик и время ожидания.
Цели кеширования
Кеширование в HTTP не является обязательным, однако в большинстве случаев бывает полезно повторно использовать ранее сохранённые ресурсы. Тем не менее, стандартные кеши HTTP обычно способны кешировать только ответы на запросы методом GET , а другие отклоняют.
Первичный ключ состоит из метода запроса и запрашиваемого URI (зачастую используется только URI, поскольку целью кеширования являются только GET-запросы). Вот примеры того, что обычно записывается в кеш:
- Успешно загруженные ресурсы: ответ 200 OK на запрос методом GET HTML-документов, изображений или файлов.
- Постоянные перенаправления: ответ 301 Moved Permanently («перемещено навсегда»).
- Сообщения об ошибках: ответ 404 Not Found («не найдено»).
- Неполные результаты: ответ 206 Partial Content («частичное содержимое»).
- Ответы на запросы отличные от GET , если есть что-либо, подходящее для использования в качестве ключа кеша.
Запись в кеше может также состоять из множества ответов, различаемых по вторичному ключу, если при формировании ответа производится согласование данных. Подробнее об этом рассказано ниже, в разделе, посвящённом заголовку Vary .
Управление кешированием
Заголовок Cache-control
Поле Cache-Control общего заголовка HTTP/1.1 используется для задания инструкций по механизму кеширования как в запросах, так и в ответах. Применяется для задания политик кеширования.
Полное отсутствие кеширования
В кеше не должно сохраняться ничего — ни по запросам клиента, ни по ответам сервера. Запрос всегда отправляется на сервер, ответ всегда загружается полностью.
Cache-Control: no-store Cache-Control: no-cache, no-store, must-revalidate
Кешировать, но проверять актуальность
Перед тем, как выдать копию, кеш запрашивает исходный сервер на предмет актуальности ресурса.
Cache-Control: no-cache
Приватные (private) и общие (public) кеши
Директива «public» указывает, что ответ можно сохранять в любом кеше. Это бывает полезно, если возникает потребность сохранить страницы с HTTP-аутентификацией, или такими кодами ответа, которые обычно не кешируются. Директива же «private» указывает, что ответ предназначен отдельному пользователю и не должен храниться в кеше совместного использования. В этом случае ответ может сохраняться приватным кешем браузера.
Cache-Control: private Cache-Control: public
Срок действия (Expiration)
Самой важной здесь является директива «max-age=» — максимальное время, в течение которого ресурс считается «свежим». В отличие от директивы Expires , она привязана к моменту запроса. К неизменяющимся файлам приложения обычно можно применять «агрессивное» кеширование. Примером таких статических файлов могут быть изображения, файлы стилей (CSS) или скриптов (JavaScript).
Подробнее об этом рассказывается в разделе Свежесть ресурса.
Cache-Control: max-age=31536000
Проверка актуальности
При использовании директивы «must-revalidate» кеш обязан проверять статус ресурсов с истёкшим сроком действия. Те копии, что утратили актуальность, использоваться не должны. Подробнее об этом рассказано ниже, в разделе Валидация кеша.
Cache-Control: must-revalidate
Заголовок Pragma
Pragma является заголовком HTTP/1.0. Он не описан для HTTP-ответов и, таким образом, не может служить надёжной заменой общему заголовку Cache-Control протокола HTTP/1.1, хотя его поведение аналогично «Cache-Control: no-cache» когда поле заголовка Cache-Control опущено в запросе. Использовать его следует только для совместимости с клиентами HTTP/1.0.
Свежесть сохранённой копии
Однажды попав в кеш, ресурс, теоретически, может храниться там вечно. Однако, поскольку объем хранилища конечен, записи периодически приходится оттуда удалять. Этот процесс называют вытеснением данных из кеша (cache eviction). Кроме того, ресурсы могут изменяться на сервере, поэтому кеш требуется обновлять. Поскольку HTTP является клиент-серверным протоколом, сервера не могут сами обращаться к кешам и клиентам при изменении ресурса; им необходимо договориться о сроке действия сохранённой копии. До его истечения ресурс считается свежим (fresh), после — устаревшим (stale). Алгоритмы вытеснения отдают предпочтение «свежим» ресурсам. Тем не менее, копия ресурса не удаляется из кеша сразу же по истечении её срока действия; при получении запроса на устаревший ресурс кеш передаёт его дальше с заголовком If-None-Match (en-US) на случай, если копия все ещё актуальна. Если это так, сервер возвращает заголовок 304 Not Modified («не изменялось»), а тело ресурса не посылает, экономя тем самым трафик.
Вот пример того, как протекает этот процесс при использовании совместного кеша прокси:
Срок действия (freshnessLifetime) вычисляется на основании нескольких заголовков. Если задан заголовок «Cache-control: max-age=N», то срок действия равен N. Если его нет, а это бывает очень часто, проверяется заголовок Expires , и, если он есть, то срок действия берётся равным значению заголовка Expires минус значение заголовка Date. Наконец, если нет ни того ни другого, смотрят заголовок Last-Modified. Если он есть, то срок действия равен значению заголовка Date минус значение заголовка Last-modified разделить на 10. Время устаревания (expirationTime) вычисляется следующим образом:
expirationTime = responseTime + freshnessLifetime - currentAge
где responseTime — это время получения ответа по часам браузера, а currentAge — текущий возраст кеша.
Обновление статических ресурсов (Revved resources)
Чем больше ресурсов может быть взято из кеша, тем быстрее сайт реагирует на запросы и тем выше его производительность. Из этих соображений их «срок годности» имеет смысл делать как можно большим. Однако, возникает проблема с ресурсами, которые обновляются редко и нерегулярно. Как раз их кеширование даёт больше всего выгоды, но сильно затрудняет обновление. Такие ресурсы можно найти на любой веб-странице: файлы скриптов (JavaScript) и стилей (CSS) изменяются редко, но уж если это произошло, обновление надо произвести как можно быстрее.
Веб-разработчики разработали метод, который Стив Сандерс (Steve Sounders) назвал revving[1], что можно перевести как «оборачиваемость». Для редко обновляемых файлов используют особый способ именования: в их URL, обычно в имя файла, добавляют номер релиза или версии. Таким образом, каждая новая версия считается отдельным ресурсом, срок устаревания которого отодвинут далеко в будущее, как правило, на год, или больше. Недостатком этого метода является то, что для получения новых версий ресурса приходится обновлять все ссылки на него — это некоторое усложнение, справиться с которым разработчику помогает цепочка инструментов. Обновление статических ресурсов влечёт за собой обновление и часто изменяемых ресурсов. Когда считываются первые, считываются и новые версии вторых.
Этот метод имеет дополнительное достоинство: одновременное обновление двух кешированных ресурсов не приводит к ситуации, при которой устаревшая версия одного ресурса используется вместе с новой версией другого. Это очень важно для сайтов с взаимосвязанными файлами стилей CSS или JS-скриптов — связь может возникнуть, например, из-за ссылок на одни и те же элементы HTML-страницы.
Номер версии, добавляемый к статическому ресурсу, не обязательно записывать в виде стандартного номера версии наподобие 1.1.3, или другого возрастающего числового значения. Это может быть что угодно, позволяющее избежать совпадений — например, дата.
Валидация кеша
Валидация кеша запускается при нажатии пользователем кнопки перезагрузки. Кроме того, она может выполняться в ходе обычного просмотра страниц, если кешированный ответ включает заголовок «Cache-control: must-revalidate». Другим фактором являются настройки кеширования браузера — можно потребовать принудительной валидации при каждой загрузке документа.
При истечении срока годности документа он либо проходит валидацию, либо повторно доставляется с сервера. Валидация может выполняться только если на сервере реализован сильный валидатор или слабый валидатор.
Заголовки ETag
Заголовок ответа ETag является непрозрачным для клиентского приложения (агента) значением, которое можно использовать в качестве сильного валидатора. Суть в том, что клиент, например, браузер, не знает, что представляет эта строка и не может предсказать, каким будет её значение. Если в ответе присутствует заголовок ETag , клиент может транслировать его значение через заголовок If-None-Match (en-US) будущих запросов для валидации кешированного ресурса.
Заголовок ответа Last-Modified можно использовать в качестве слабого валидатора. Слабым он считается из-за того, что имеет 1-секундное разрешение. Если в ответе присутствует заголовок Last-Modified , то для валидации кешированного документа клиент может выводить в запросах заголовок If-Modified-Since .
При запросе на валидацию сервер может либо проигнорировать валидацию и послать стандартный ответ 200 OK , либо вернуть ответ 304 Not Modified (с пустым телом), тем самым указывая браузеру взять копию из кеша. В последнем случае в ответ могут входить также заголовки для обновления срока действия кешированного ресурса.
Изменяющиеся ответы
Заголовок HTTP-ответа Vary определяет, как по заголовкам будущих запросов понять, может ли быть использована копия из кеша, или нужно запросить новые данные у сервера.
Если кеш получает запрос, который можно удовлетворить сохранённым в кеше ответом с заголовком Vary , то использовать этот ответ можно только при совпадении всех указанных в Vary полей заголовка исходного (сохранённого в кеше) запроса и нового запроса.
Это может быть полезно, например, при динамическом предоставлении контента. При использовании заголовка Vary: User-Agent кеширующие сервера, принимая решение об использовании страницы из кеша, должны учитывать агент пользователя. Так можно избежать ситуации, когда пользователи мобильных устройств по ошибке получат десктопную версию вашего сайта. Вдобавок, это может помочь Google и другим поисковым системам обнаружить мобильную версию страницы, и может также указать им на то, что здесь нет никакой подмены контента с целью поисковой оптимизации (Cloaking).
Vary: User-Agent
Поскольку значение заголовка User-Agent различается («varies») у мобильных и десктопных клиентов, закешированный мобильный контент не будет по ошибке отсылаться пользователям десктопов и наоборот.
Смотрите также
- RFC 7234: Hypertext Transfer Protocol (HTTP/1.1): Caching
- Caching Tutorial – Mark Nottingham
- HTTP caching – Ilya Grigorik
- RedBot, инструмент для проверки относящихся к кешу заголовков HTTP .
Found a content problem with this page?
- Edit the page on GitHub.
- Report the content issue.
- View the source on GitHub.
This page was last modified on 7 авг. 2023 г. by MDN contributors.