Pragma no cache как настроить

Предотвращение кэширования в 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 выполните следующие действия.

1. Запустите диспетчер IIS.
2. В дереве компьютеров и служб откройте веб-сервер по умолчанию или соответствующий веб-сервер. Найдите каталог, содержащий содержимое, которому требуется заголовок Cache-Control.
3. Откройте диалоговое окно Свойства для этого каталога.
4. Перейдите на вкладку Заголовки HTTP .
5. Нажмите кнопку Добавить в группе Настраиваемые заголовки 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

Обратная связь

Были ли сведения на этой странице полезными?

Кэширование ответов в ASP.NET Core

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

Атрибут ResponseCache задает заголовки кэширования ответов. Клиенты и промежуточные прокси-серверы должны учитывать заголовки для кэширования ответов в RFC 9111: кэширование HTTP.

Для кэширования на стороне сервера, следующего за спецификацией кэширования HTTP 1.1, используйте ПО промежуточного слоя кэширования ответа. По промежуточному слоям можно использовать ResponseCacheAttribute свойства для влияния на поведение кэширования на стороне сервера.

По промежуточному слоям кэширования ответа:

• Включает кэширование ответов сервера на основе заголовков кэша HTTP. Реализует стандартную семантику кэширования HTTP. Кэши на основе заголовков кэша HTTP, таких как прокси-серверы.
• Обычно не подходит для приложений пользовательского интерфейса, таких как Pages, так как Razor браузеры обычно задают заголовки запросов, которые предотвращают кэширование. Кэширование выходных данных, доступное в ASP.NET Core 7.0 и более поздних версий, обеспечивает преимущества приложений пользовательского интерфейса. При кэшировании выходных данных конфигурация решает, что следует кэшировать независимо от заголовков HTTP.
• Может оказаться полезным для общедоступных запросов GET или HEAD API от клиентов, где выполняются условия кэширования .

Чтобы проверить кэширование ответов, используйте Fiddler, Postman или другое средство, которое может явно задать заголовки запросов. Для тестирования кэширования предпочтительнее явно задать заголовки. Дополнительные сведения см. в разделе Устранение неполадок.

Postman > go to settings > uncheck Send no-cache header —>

Кэширование ответа на основе HTTP

RFC 9111: кэширование HTTP описывает поведение кэшей Интернета. Основной заголовок HTTP, используемый для кэширования, — cache-Control, который используется для указания директив кэша. Директивы управляют поведением кэширования, так как запросы делают свой путь от клиентов к серверам и как ответы делают свой путь от серверов обратно к клиентам. Запросы и ответы перемещаются через прокси-серверы, а прокси-серверы также должны соответствовать спецификации кэширования HTTP 1.1.

Общие Cache-Control директивы показаны в следующей таблице.

Другие заголовки кэша, которые играют роль в кэшировании, показаны в следующей таблице.

Кэширование на основе HTTP учитывает директивы cache-Control для запросов

RFC 9111: кэширование HTTP (раздел 5.2. Cache-Control) требует кэша для учета допустимого Cache-Control заголовка, отправленного клиентом. Клиент может выполнять запросы со значением заголовка no-cache и принудительно создавать новый ответ для каждого запроса.

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

При использовании по промежуточного слоя кэширования ответа нет никакого контроля разработчика, так как ПО промежуточного слоя соответствует официальной спецификации кэширования. Добавлена поддержка кэширования выходных данных для повышения нагрузки сервера управления в .NET 7. Дополнительные сведения см. в разделе «Кэширование выходных данных».

Атрибут ResponseCache

Указывает ResponseCacheAttribute параметры, необходимые для задания соответствующих заголовков в кэшировании ответа.

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

VaryByQueryKeys зависит от сохраненных ответов по значениям заданного списка ключей запросов. Если указано одно значение, ПО промежуточного * слоя зависит от всех параметров строки запроса запроса.

Для задания свойства необходимо включить по промежуточному слоям кэширования ответов VaryByQueryKeys . В противном случае создается исключение среды выполнения. Для свойства отсутствует соответствующий заголовок VaryByQueryKeys HTTP. Это свойство — это функция HTTP, обработанная по промежуточному слоям кэширования ответа. Чтобы ПО промежуточного слоя служило кэшированному ответу, строка запроса и значение строки запроса должны соответствовать предыдущему запросу. Например, рассмотрим последовательность запросов и результатов, показанных в следующей таблице:

Первый запрос возвращается сервером и кэшируется в ПО промежуточного слоя. Второй запрос возвращается ПО промежуточного слоя, так как строка запроса соответствует предыдущему запросу. Третий запрос не в кэше ПО промежуточного слоя, так как значение строки запроса не соответствует предыдущему запросу.

Используется ResponseCacheAttribute для настройки и создания (с помощью IFilterFactory) Microsoft.AspNetCore.Mvc.Internal.ResponseCacheFilter . Выполняет ResponseCacheFilter работу по обновлению соответствующих заголовков HTTP и функций ответа. Фильтр:

• Удаляет все существующие заголовки для Vary , Cache-Control и Pragma .
• Записывает соответствующие заголовки на основе свойств, заданных в файле ResponseCacheAttribute.
• Обновления функцию кэширования ответа HTTP, если VaryByQueryKeys задано значение.

Изменчивость

Этот заголовок записывается только при VaryByHeader установке свойства. Свойство, заданное значением Vary свойства. В следующем примере используется VaryByHeader свойство:

[ApiController] public class TimeController : ControllerBase < [Route("api/[controller]")] [HttpGet] [ResponseCache(VaryByHeader = "User-Agent", Duration = 30)] public ContentResult GetTime() =>Content( DateTime.Now.Millisecond.ToString()); 

Просмотр заголовков ответа с помощью Fiddler или другого средства. К заголовкам ответа относятся:

Cache-Control: public,max-age=30 Vary: User-Agent 

Предыдущий код требует добавления служб AddResponseCaching промежуточного слоя кэширования ответа в коллекцию служб и настраивает приложение для использования ПО промежуточного слоя с методом UseResponseCaching расширения.

var builder = WebApplication.CreateBuilder(args); builder.Services.AddControllers(); builder.Services.AddResponseCaching(); var app = builder.Build(); app.UseHttpsRedirection(); // UseCors must be called before UseResponseCaching //app.UseCors(); app.UseResponseCaching(); app.UseAuthorization(); app.MapControllers(); app.Run(); 

NoStore и Location.None

NoStore переопределяет большинство других свойств. Если для этого свойства задано true значение, Cache-Control заголовок имеет no-store значение . Если Location задано значение None :

• Cache-Control задан как no-store,no-cache .
• Pragma задан как no-cache .

Если NoStore имеет значение и None Location имеет false значение , Cache-Control и Pragma задано значение no-cache .

NoStore обычно задано значение true для страниц ошибок. Ниже приведены заголовки ответов, которые указывают клиенту не хранить ответ.

[Route("api/[controller]/ticks")] [HttpGet] [ResponseCache(Location = ResponseCacheLocation.None, NoStore = true)] public ContentResult GetTimeTicks() => Content( DateTime.Now.Ticks.ToString()); 

Приведенный выше код содержит следующие заголовки в ответе:

Cache-Control: no-store,no-cache Pragma: no-cache 

Чтобы применить ResponseCacheAttribute все ответы на страницы или контроллер MVC приложения, Razor добавьте его с фильтром MVC или Razor фильтром Pages.

В приложении MVC:

builder.Services.AddControllersWithViews().AddMvcOptions(options => options.Filters.Add( new ResponseCacheAttribute < NoStore = true, Location = ResponseCacheLocation.None >)); 

Подход, применяемый к Razor приложениям Pages, см. в статье «Добавление ResponseCacheAttribute в глобальный список фильтров MVC» не применяется к Razor Страницам (dotnet/aspnetcore #18890). Пример, приведенный в примечании проблемы, был написан для приложений, предназначенных для ASP.NET Core до выпуска минимальных API в версии 6.0. Для приложений версии 6.0 или более поздних версий измените регистрацию службы в примере builder.Services.AddSingleton. на Program.cs .

Расположение и длительность

Чтобы включить кэширование, Duration необходимо задать положительное значение и Location иметь значение Any (по умолчанию) или Client . Платформа задает Cache-Control заголовок значению расположения, за которым следует max-age ответ.

LocationПараметры и переводятся в Cache-Control значения заголовков public Any и private соответственно. Client Как отмечалось в разделе NoStore и Location.None, для параметра None Location заданы оба Cache-Control значения и Pragma заголовки no-cache .

Location.Any ( Cache-Control задано public значение ) указывает, что клиент или любой промежуточный прокси-сервер могут кэшировать значение, включая ПО промежуточного слоя кэширования ответа.

Location.Client ( Cache-Control задано значение private ) указывает, что только клиент может кэшировать значение. Промежуточный кэш не должен кэшировать значение, включая ПО промежуточного слоя кэширования ответа.

Заголовки элементов управления кэшем предоставляют рекомендации клиентам и промежуточным прокси-серверам, когда и как кэшировать ответы. Нет никаких гарантий, что клиенты и прокси-серверы будут учитывать RFC 9111: кэширование HTTP. По промежуточному слоям кэширования ответа всегда следует правилам кэширования, изложенным спецификацией.

В следующем примере показаны заголовки, созданные параметром Duration и выходом из значения по умолчанию Location :

[Route("api/[controller]/ms")] [HttpGet] [ResponseCache(Duration = 10, Location = ResponseCacheLocation.Any, NoStore = false)] public ContentResult GetTimeMS() => Content( DateTime.Now.Millisecond.ToString()); 

Приведенный выше код содержит следующие заголовки в ответе:

Cache-Control: public,max-age=10 

Профили кэша

Вместо дедупликации параметров кэша ответов во многих атрибутах действия контроллера профили кэша можно настроить в качестве параметров при настройке MVC/Razor Pages. Значения, найденные в профиле кэша со ResponseCacheAttribute ссылкой, используются в качестве значений по умолчанию и переопределяются любыми свойствами, указанными в атрибуте.

В следующем примере показан 30-секундный профиль кэша:

using Microsoft.AspNetCore.Mvc; var builder = WebApplication.CreateBuilder(args); builder.Services.AddResponseCaching(); builder.Services.AddControllers(options => < options.CacheProfiles.Add("Default30", new CacheProfile() < Duration = 30 >); >); var app = builder.Build(); app.UseHttpsRedirection(); // UseCors must be called before UseResponseCaching //app.UseCors(); app.UseResponseCaching(); app.UseAuthorization(); app.MapControllers(); app.Run(); 

Следующий код ссылается на профиль кэша Default30 :

[ApiController] [ResponseCache(CacheProfileName = "Default30")] public class Time2Controller : ControllerBase < [Route("api/[controller]")] [HttpGet] public ContentResult GetTime() =>Content( DateTime.Now.Millisecond.ToString()); [Route("api/[controller]/ticks")] [HttpGet] public ContentResult GetTimeTicks() => Content( DateTime.Now.Ticks.ToString()); > 

Результирующий ответ заголовка профиля кэша Default30 включает:

Cache-Control: public,max-age=30 

Атрибут [ResponseCache] можно применить к:

• Razor Pages: атрибуты нельзя применять к методам обработчика. Браузеры, используемые с приложениями пользовательского интерфейса, предотвращают кэширование ответов.
• Контроллеры MVC.
• Методы действий MVC: атрибуты уровня метода переопределяют параметры, указанные в атрибутах уровня класса.

Следующий код применяет [ResponseCache] атрибут на уровне контроллера и уровне метода:

[ApiController] [ResponseCache(VaryByHeader = "User-Agent", Duration = 30)] public class Time4Controller : ControllerBase < [Route("api/[controller]")] [HttpGet] public ContentResult GetTime() =>Content( DateTime.Now.Millisecond.ToString()); [Route("api/[controller]/ticks")] [HttpGet] public ContentResult GetTimeTicks() => Content( DateTime.Now.Ticks.ToString()); [Route("api/[controller]/ms")] [HttpGet] [ResponseCache(Duration = 10, Location = ResponseCacheLocation.Any, NoStore = false)] public ContentResult GetTimeMS() => Content( DateTime.Now.Millisecond.ToString()); > 

Дополнительные ресурсы

• Хранение ответов в кэшах
• Элемент управления cache-control
• Кэширование в памяти в ASP.NET Core
• Распределенное кэширование в ASP.NET Core
• Обнаружение изменений с помощью маркеров изменений в ASP.NET Core
• ПО промежуточного слоя для кэширования ответов в ASP.NET Core
• Вспомогательный компонент тега кэша в ASP.NET Core MVC
• Вспомогательный компонент тега распределенного кэша в ASP.NET Core

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

Он [ResponseCache] участвует в настройке заголовков кэширования ответов. Клиенты и промежуточные прокси-серверы должны учитывать заголовки для кэширования ответов в RFC 9111: кэширование HTTP.

Для кэширования на стороне сервера, следующего за спецификацией кэширования HTTP 1.1, используйте ПО промежуточного слоя кэширования ответа. По промежуточному слоям можно использовать [ResponseCache] свойства для задания заголовков кэширования на стороне сервера.

Кэширование ответа на основе HTTP

RFC 9111: кэширование HTTP описывает поведение кэшей Интернета. Основной заголовок HTTP, используемый для кэширования, — cache-Control, который используется для указания директив кэша . Директивы управляют поведением кэширования, так как запросы делают свой путь от клиентов к серверам и как ответы делают свой путь от серверов обратно к клиентам. Запросы и ответы перемещаются через прокси-серверы, а прокси-серверы также должны соответствовать спецификации кэширования HTTP 1.1.

Общие Cache-Control директивы показаны в следующей таблице.

Другие заголовки кэша, которые играют роль в кэшировании, показаны в следующей таблице.

Кэширование на основе HTTP учитывает директивы cache-Control для запросов

RFC 9111: кэширование HTTP (раздел 5.2. Cache-Control) требует кэша для учета допустимого Cache-Control заголовка, отправленного клиентом. Клиент может выполнять запросы со значением заголовка no-cache и принудительно создавать новый ответ для каждого запроса.

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

При использовании по промежуточного слоя кэширования ответа нет никакого контроля разработчика, так как ПО промежуточного слоя соответствует официальной спецификации кэширования. Поддержка кэширования выходных данных для повышения нагрузки сервера управления — это проектное предложение для будущего выпуска ASP.NET Core. Дополнительные сведения см. в разделе «Добавление поддержки кэширования выходных данных» (dotnet/aspnetcore #27387).

Другие технологии кэширования в ASP.NET Core

Кэширование в памяти

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

Дополнительные сведения см. в разделе «Кэш в памяти» в ASP.NET Core и устранение неполадок с сходством сеансов Шлюз приложений Azure.

Распределенный кэш

Используйте распределенный кэш для хранения данных в памяти, когда приложение размещается в облачной или серверной ферме. Кэш используется на серверах, обрабатывающих запросы. Клиент может отправить запрос, который обрабатывается любым сервером в группе, если кэшированные данные для клиента доступны. ASP.NET Core работает с распределенными кэшами SQL Server, Redis и NCache .

Вспомогательная функция тега кэша

Кэшируйте содержимое из представления или Razor страницы MVC с помощью вспомогательного средства тега кэша. Вспомогательный элемент тега кэша использует кэширование в памяти для хранения данных.

Вспомогательная функция тега распределенного кэша

Кэшируйте содержимое из представления MVC или Razor страницы в сценариях распределенной облачной или веб-фермы с помощью вспомогательного средства тега распределенного кэша. Помощник по тегу распределенного кэша использует SQL Server, Redis или NCache для хранения данных.

Атрибут ResponseCache

Указывает ResponseCacheAttribute параметры, необходимые для задания соответствующих заголовков в кэшировании ответа.

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

VaryByQueryKeys зависит от сохраненных ответов по значениям заданного списка ключей запросов. Если указано одно значение, ПО промежуточного * слоя зависит от всех параметров строки запроса запроса.

Для задания свойства необходимо включить по промежуточному слоям кэширования ответов VaryByQueryKeys . В противном случае создается исключение среды выполнения. Для свойства отсутствует соответствующий заголовок VaryByQueryKeys HTTP. Это свойство — это функция HTTP, обработанная по промежуточному слоям кэширования ответа. Чтобы ПО промежуточного слоя служило кэшированному ответу, строка запроса и значение строки запроса должны соответствовать предыдущему запросу. Например, рассмотрим последовательность запросов и результатов, показанных в следующей таблице.

Первый запрос возвращается сервером и кэшируется в ПО промежуточного слоя. Второй запрос возвращается ПО промежуточного слоя, так как строка запроса соответствует предыдущему запросу. Третий запрос не в кэше ПО промежуточного слоя, так как значение строки запроса не соответствует предыдущему запросу.

Используется ResponseCacheAttribute для настройки и создания (с помощью IFilterFactory) Microsoft.AspNetCore.Mvc.Internal.ResponseCacheFilter . Выполняет ResponseCacheFilter работу по обновлению соответствующих заголовков HTTP и функций ответа. Фильтр:

• Удаляет все существующие заголовки для Vary , Cache-Control и Pragma .
• Записывает соответствующие заголовки на основе свойств, заданных в файле ResponseCacheAttribute.
• Обновления функцию кэширования ответа HTTP, если VaryByQueryKeys задано значение.

Изменчивость

Этот заголовок записывается только при VaryByHeader установке свойства. Свойство, заданное значением Vary свойства. В следующем примере используется VaryByHeader свойство:

[ResponseCache(VaryByHeader = "User-Agent", Duration = 30)] public class Cache1Model : PageModel  

Cache-Control: public,max-age=30 Vary: User-Agent 

[ResponseCache(Duration = 0, Location = ResponseCacheLocation.None, NoStore = true)] public class Cache2Model : PageModel  

Cache-Control: no-store,no-cache Pragma: no-cache 

services.AddMvc().AddMvcOptions(options => options.Filters.Add( new ResponseCacheAttribute < NoStore = true, Location = ResponseCacheLocation.None >)); 

[ResponseCache(Duration = 10, Location = ResponseCacheLocation.Any, NoStore = false)] public class Cache3Model : PageModel  

Cache-Control: public,max-age=10 

public void ConfigureServices(IServiceCollection services) < services.AddRazorPages(); services.AddMvc(options =>< options.CacheProfiles.Add("Default30", new CacheProfile() < Duration = 30 >); >); > 

[ResponseCache(CacheProfileName = "Default30")] public class Cache4Model : PageModel  

Cache-Control: public,max-age=30 

  Header set Cache-Control "max-age=31536000, public" Header set Cache-Control "max-age=31536000, public"  

server < #. location ~* \.(?:ico|css|js|gif|jpe?g|png)$ < add_header Cache-Control "max-age=88000, public"; >#. >

HTTP/1.1 200 OK Server: nginx/1.13.1 Date: Fri, 09 Jun 2017 12:54:24 GMT Content-Type: image/jpeg Content-Length: 124024 Connection: keep-alive X-Image-Generated: 29 X-Image-Meta: 1024x768 X-Image-Read: 71 Expires: Wed, 06 Dec 2017 12:51:43 GMT Access-Control-Allow-Origin: * Last-Modified: Sun, 01 Jan 2017 12:00:00 GMT Cache-Control: max-age=315360000, public — время, на которое файл будет закеширован на сервере в секундах. Cache: HIT — файл отдался из кеша CDN. X-Cached-Since: 2017-06-09T12:51:43+00:00 — время, с которого файл находится в кеше сервера CDN. X-Node: m9-up-e245 — сервер CDN, с которого был отдан файл.

Pragma: no-cache Expires: дата из прошлого Cache-Control: private, no-cache, no-store 

header('Cache-Control: public, max-age=900, stale-while-revalidate=5');