Кэширование ответов в ASP.NET Core
Авторы: Рик Андерсон (Rick Anderson) и Кирк Ларкин (Kirk Larkin)
Просмотреть или скачать образец кода (описание загрузки)
Кэширование ответов уменьшает количество запросов, выполняемых клиентом или прокси-сервером. Кэширование ответов также уменьшает объем работы веб-сервера для создания ответа. Кэширование ответов задается в заголовках.
Атрибут ResponseCache задает заголовки кэширования ответов. Клиенты и промежуточные прокси-серверы должны учитывать заголовки для кэширования ответов в RFC 9111: кэширование HTTP.
Для кэширования на стороне сервера, следующего за спецификацией кэширования HTTP 1.1, используйте ПО промежуточного слоя кэширования ответа. По промежуточному слоям можно использовать ResponseCacheAttribute свойства для влияния на поведение кэширования на стороне сервера.
По промежуточному слоям кэширования ответа:
- Включает кэширование ответов сервера на основе заголовков кэша HTTP. Реализует стандартную семантику кэширования HTTP. Кэши на основе заголовков кэша HTTP, таких как прокси-серверы.
- Обычно не подходит для приложений пользовательского интерфейса, таких как Pages, так как Razor браузеры обычно задают заголовки запросов, которые предотвращают кэширование. Кэширование выходных данных, доступное в ASP.NET Core 7.0 и более поздних версий, обеспечивает преимущества приложений пользовательского интерфейса. При кэшировании выходных данных конфигурация решает, что следует кэшировать независимо от заголовков HTTP.
- Может оказаться полезным для общедоступных запросов GET или HEAD API от клиентов, где выполняются условия кэширования .
Чтобы проверить кэширование ответов, используйте Fiddler или другое средство, которое может явно задать заголовки запросов. Для тестирования кэширования предпочтительнее явно задать заголовки. Дополнительные сведения см. в разделе Устранение неполадок.
Кэширование ответа на основе HTTP
RFC 9111: кэширование HTTP описывает поведение кэшей Интернета. Основной заголовок HTTP, используемый для кэширования, — cache-Control, который используется для указания директив кэша. Директивы управляют поведением кэширования, так как запросы делают свой путь от клиентов к серверам и как ответы делают свой путь от серверов обратно к клиентам. Запросы и ответы перемещаются через прокси-серверы, а прокси-серверы также должны соответствовать спецификации кэширования HTTP 1.1.
Общие Cache-Control
директивы показаны в следующей таблице.
Директива | Действие |
---|---|
public | Кэш может хранить ответ. |
private | Ответ не должен храниться общим кэшем. Частный кэш может хранить и повторно использовать ответ. |
max-age | Клиент не принимает ответ, возраст которого превышает указанное количество секунд. Примеры: max-age=60 (60 секунд), max-age=2592000 (1 месяц) |
no-cache | При запросах: кэш не должен использовать сохраненный ответ для удовлетворения запроса. Сервер-источник повторно создает ответ для клиента, а ПО промежуточного слоя обновляет сохраненный ответ в своем кэше. Ответы: ответ не должен использоваться для последующего запроса без проверки на исходном сервере. |
no-store | При запросах: кэш не должен хранить запрос. При ответах: кэш не должен хранить какую-либо часть ответа. |
Другие заголовки кэша, которые играют роль в кэшировании, показаны в следующей таблице.
Верхний колонтитул | Function |
---|---|
Возраст | Оценка времени в секундах после создания или успешного проверки ответа на исходном сервере. |
Срок действия истекает | Время, после которого ответ считается устаревшим. |
Pragma | Существует для обратной совместимости с кэшами HTTP/1.0 для настройки no-cache поведения. Если заголовок Cache-Control присутствует, Pragma заголовок игнорируется. |
Менять | Указывает, что кэшированный ответ не должен отправляться, если только все Vary поля заголовка не соответствуют исходному запросу кэшированного ответа и новому запросу. |
Кэширование на основе HTTP учитывает директивы cache-Control для запросов
RFC 9111: кэширование HTTP (раздел 5.2. Cache-Control) требует кэша для учета допустимого Cache-Control
заголовка, отправленного клиентом. Клиент может выполнять запросы со значением заголовка no-cache
и принудительно создавать новый ответ для каждого запроса.
Всегда учитывать заголовки запросов клиента Cache-Control
имеет смысл, если вы считаете цель кэширования HTTP. В рамках официальной спецификации кэширование предназначено для уменьшения задержки и сетевой нагрузки на выполнение запросов в сети клиентов, прокси-серверов и серверов. Это не обязательно способ управления нагрузкой на исходном сервере.
При использовании по промежуточного слоя кэширования ответа нет никакого контроля разработчика, так как ПО промежуточного слоя соответствует официальной спецификации кэширования. Добавлена поддержка кэширования выходных данных для повышения нагрузки сервера управления в .NET 7. Дополнительные сведения см. в разделе "Кэширование выходных данных".
Атрибут ResponseCache
Указывает ResponseCacheAttribute параметры, необходимые для задания соответствующих заголовков в кэшировании ответа.
Предупреждение
Отключите кэширование для содержимого, содержащего сведения для прошедших проверку подлинности клиентов. Кэширование должно быть включено только для содержимого, которое не изменяется на основе пользователя identity или вошедшего пользователя.
VaryByQueryKeys зависит от сохраненных ответов по значениям заданного списка ключей запросов. Если указано одно значение, ПО промежуточного *
слоя зависит от всех параметров строки запроса запроса.
Для задания свойства необходимо включить по промежуточному слоям кэширования ответов VaryByQueryKeys . В противном случае создается исключение среды выполнения. Для свойства отсутствует соответствующий заголовок VaryByQueryKeys HTTP. Это свойство — это функция HTTP, обработанная по промежуточному слоям кэширования ответа. Чтобы ПО промежуточного слоя служило кэшированному ответу, строка запроса и значение строки запроса должны соответствовать предыдущему запросу. Например, рассмотрим последовательность запросов и результатов, показанных в следующей таблице:
Запросить | Возвращено из |
---|---|
http://example.com?key1=value1 |
Сервер |
http://example.com?key1=value1 |
ПО промежуточного слоя |
http://example.com?key1=NewValue |
Сервер |
Первый запрос возвращается сервером и кэшируется в ПО промежуточного слоя. Второй запрос возвращается ПО промежуточного слоя, так как строка запроса соответствует предыдущему запросу. Третий запрос не в кэше ПО промежуточного слоя, так как значение строки запроса не соответствует предыдущему запросу.
Используется 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
директивы показаны в следующей таблице.
Директива | Действие |
---|---|
public | Кэш может хранить ответ. |
private | Ответ не должен храниться общим кэшем. Частный кэш может хранить и повторно использовать ответ. |
max-age | Клиент не принимает ответ, возраст которого превышает указанное количество секунд. Примеры: max-age=60 (60 секунд), max-age=2592000 (1 месяц) |
no-cache | При запросах: кэш не должен использовать сохраненный ответ для удовлетворения запроса. Сервер-источник повторно создает ответ для клиента, а ПО промежуточного слоя обновляет сохраненный ответ в своем кэше. Ответы: ответ не должен использоваться для последующего запроса без проверки на исходном сервере. |
no-store | При запросах: кэш не должен хранить запрос. При ответах: кэш не должен хранить какую-либо часть ответа. |
Другие заголовки кэша, которые играют роль в кэшировании, показаны в следующей таблице.
Верхний колонтитул | Function |
---|---|
Возраст | Оценка времени в секундах после создания или успешного проверки ответа на исходном сервере. |
Срок действия истекает | Время, после которого ответ считается устаревшим. |
Pragma | Существует для обратной совместимости с кэшами HTTP/1.0 для настройки no-cache поведения. Если заголовок Cache-Control присутствует, Pragma заголовок игнорируется. |
Менять | Указывает, что кэшированный ответ не должен отправляться, если только все Vary поля заголовка не соответствуют исходному запросу кэшированного ответа и новому запросу. |
Кэширование на основе 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 .
Дополнительные сведения см. в статье Распределенное кэширование в ASP.NET Core.
Вспомогательная функция тега кэша
Кэшируйте содержимое из представления или Razor страницы MVC с помощью вспомогательного средства тега кэша. Вспомогательный элемент тега кэша использует кэширование в памяти для хранения данных.
Дополнительные сведения см . в справке по тегу кэша в ASP.NET Core MVC.
Вспомогательная функция тега распределенного кэша
Кэшируйте содержимое из представления MVC или Razor страницы в сценариях распределенной облачной или веб-фермы с помощью вспомогательного средства тега распределенного кэша. Помощник по тегу распределенного кэша использует SQL Server, Redis или NCache для хранения данных.
Дополнительные сведения см . в справке по тегу тега распределенного кэша в ASP.NET Core.
Атрибут ResponseCache
Указывает ResponseCacheAttribute параметры, необходимые для задания соответствующих заголовков в кэшировании ответа.
Предупреждение
Отключите кэширование для содержимого, содержащего сведения для прошедших проверку подлинности клиентов. Кэширование должно быть включено только для содержимого, которое не изменяется на основе пользователя identity или вошедшего пользователя.
VaryByQueryKeys зависит от сохраненных ответов по значениям заданного списка ключей запросов. Если указано одно значение, ПО промежуточного *
слоя зависит от всех параметров строки запроса запроса.
Для задания свойства необходимо включить по промежуточному слоям кэширования ответов VaryByQueryKeys . В противном случае создается исключение среды выполнения. Для свойства отсутствует соответствующий заголовок VaryByQueryKeys HTTP. Это свойство — это функция HTTP, обработанная по промежуточному слоям кэширования ответа. Чтобы ПО промежуточного слоя служило кэшированному ответу, строка запроса и значение строки запроса должны соответствовать предыдущему запросу. Например, рассмотрим последовательность запросов и результатов, показанных в следующей таблице.
Запросить | Результат |
---|---|
http://example.com?key1=value1 |
Возвращается с сервера. |
http://example.com?key1=value1 |
Возвращается из ПО промежуточного слоя. |
http://example.com?key1=value2 |
Возвращается с сервера. |
Первый запрос возвращается сервером и кэшируется в ПО промежуточного слоя. Второй запрос возвращается ПО промежуточного слоя, так как строка запроса соответствует предыдущему запросу. Третий запрос не в кэше ПО промежуточного слоя, так как значение строки запроса не соответствует предыдущему запросу.
Используется 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
{
Используя пример приложения, просмотрите заголовки ответа с помощью сетевых средств браузера. Следующие заголовки ответов отправляются с ответом на страницу Cache1:
Cache-Control: public,max-age=30
Vary: User-Agent
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
для страниц ошибок. Страница Cache2 в примере приложения создает заголовки ответов, которые указывают клиенту не хранить ответ.
[ResponseCache(Duration = 0, Location = ResponseCacheLocation.None, NoStore = true)]
public class Cache2Model : PageModel
{
Пример приложения возвращает страницу Cache2 со следующими заголовками:
Cache-Control: no-store,no-cache
Pragma: no-cache
Чтобы применить ResponseCacheAttribute все ответы на страницы или контроллер MVC приложения, Razor добавьте его с фильтром MVC или Razor фильтром Pages.
В приложении MVC:
services.AddMvc().AddMvcOptions(options =>
options.Filters.Add(
new ResponseCacheAttribute
{
NoStore = true,
Location = ResponseCacheLocation.None
}));
Подход, применяемый к Razor приложениям Pages, см. в статье "Добавление ResponseCacheAttribute
в глобальный список фильтров MVC" не применяется к Razor Страницам (dotnet/aspnetcore #18890).
Расположение и длительность
Чтобы включить кэширование, 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. По промежуточному слоям кэширования ответа всегда следует правилам кэширования, изложенным спецификацией.
В следующем примере показана модель страницы Cache3 из примера приложения и заголовков, созданных Duration параметром и выходом из значения по умолчанию Location :
[ResponseCache(Duration = 10, Location = ResponseCacheLocation.Any, NoStore = false)]
public class Cache3Model : PageModel
{
Пример приложения возвращает страницу Cache3 со следующим заголовком:
Cache-Control: public,max-age=10
Профили кэша
Вместо дедупликации параметров кэша ответов во многих атрибутах действия контроллера профили кэша можно настроить в качестве параметров при настройке MVC/Razor Pages в Startup.ConfigureServices
. Значения, найденные в профиле кэша со ResponseCacheAttribute ссылкой, используются в качестве значений по умолчанию и переопределяются любыми свойствами, указанными в атрибуте.
Настройка профиля кэша. В следующем примере показан 30-секундный профиль кэша в примере приложения Startup.ConfigureServices
:
public void ConfigureServices(IServiceCollection services)
{
services.AddRazorPages();
services.AddMvc(options =>
{
options.CacheProfiles.Add("Default30",
new CacheProfile()
{
Duration = 30
});
});
}
Модель страницы кэша 4 примера приложения ссылается на Default30
профиль кэша:
[ResponseCache(CacheProfileName = "Default30")]
public class Cache4Model : PageModel
{
К нему можно применить следующее ResponseCacheAttribute :
- Razor Pages: атрибуты нельзя применять к методам обработчика.
- Контроллеры MVC.
- Методы действий MVC: атрибуты уровня метода переопределяют параметры, указанные в атрибутах уровня класса.
Результирующий заголовок, примененный к ответу страницы Cache4 профилем Default30
кэша:
Cache-Control: public,max-age=30
Дополнительные ресурсы
- Хранение ответов в кэшах
- RFC 9111: кэширование HTTP (раздел 5.2. Cache-Control)
- Кэширование в памяти в ASP.NET Core
- Распределенное кэширование в ASP.NET Core
- Обнаружение изменений с помощью маркеров изменений в ASP.NET Core
- ПО промежуточного слоя для кэширования ответов в ASP.NET Core
- Вспомогательный компонент тега кэша в ASP.NET Core MVC
- Вспомогательный компонент тега распределенного кэша в ASP.NET Core
ASP.NET Core