Cache de resposta em ASP.NET Core

Por Rick Anderson e Kirk Larkin

Exibir ou baixar código de exemplo (como baixar)

O cache de resposta reduz o número de solicitações que um cliente ou proxy faz a um servidor Web. O cache de resposta também reduz a quantidade de trabalho que o servidor Web executa para gerar uma resposta. O cache de resposta é definido em cabeçalhos.

O atributo ResponseCache define cabeçalhos de cache de resposta. Clientes e proxies intermediários devem honrar os cabeçalhos para armazenar respostas em cache na especificação de cache HTTP 1.1.

Para o cache do lado do servidor que segue a especificação de cache HTTP 1.1, use o Middleware de Cache de Resposta. O middleware pode usar as propriedades para influenciar o ResponseCacheAttribute comportamento de cache do lado do servidor.

O middleware de cache de resposta:

  • Habilita o cache de respostas do servidor com base em cabeçalhos de cache HTTP. Implementa a semântica de cache HTTP padrão. Caches com base em cabeçalhos de cache HTTP, como proxies fazem.
  • Normalmente, não é útil para aplicativos de interface do usuário, como Razor Páginas, porque os navegadores geralmente definem cabeçalhos de solicitação que impedem o cache. O cache de saída está sendo considerado para a próxima versão do ASP.NET Core, o que beneficiará os aplicativos de interface do usuário. Com o cache de saída, a configuração decide o que deve ser armazenado em cache independentemente dos cabeçalhos HTTP. Saiba mais neste tópico do GitHub.
  • Pode ser útil para solicitações públicas de API GET ou HEAD de clientes em que as condições de cache são atendidas.

Use Fiddler, Postman ou outra ferramenta que possa definir explicitamente cabeçalhos de solicitação. Definir cabeçalhos explicitamente é preferencial para testar o cache. Para obter mais informações, consulte Solução de problemas

Cache de resposta baseado em HTTP

A especificação de cache HTTP 1.1 descreve como os caches da Internet devem se comportar. O cabeçalho HTTP primário usado para cache é o Cache-Control, que é usado para especificar diretivas de cache. As diretivas controlam o comportamento de cache à medida que as solicitações fazem seu caminho de clientes para servidores e como respostas fazem seu caminho de servidores de volta para clientes. Solicitações e respostas são movidas por meio de servidores proxy e os servidores proxy também devem estar em conformidade com a especificação de cache HTTP 1.1.

As diretivas comuns Cache-Control são mostradas na tabela a seguir.

Diretiva Ação
público Um cache pode armazenar a resposta.
Privada A resposta não deve ser armazenada por um cache compartilhado. Um cache privado pode armazenar e reutilizar a resposta.
max-age O cliente não aceita uma resposta cuja idade é maior que o número especificado de segundos. Exemplos: max-age=60 (60 segundos) max-age=2592000 (1 mês)
no-cache Em solicitações: um cache não deve usar uma resposta armazenada para atender à solicitação. O servidor de origem regenera a resposta para o cliente e o middleware atualiza a resposta armazenada em seu cache.

Em respostas: a resposta não deve ser usada para uma solicitação subsequente sem validação no servidor de origem.
no-store Em solicitações: um cache não deve armazenar a solicitação.

Em respostas: um cache não deve armazenar nenhuma parte da resposta.

Outros cabeçalhos de cache que desempenham uma função no cache são mostrados na tabela a seguir.

Cabeçalho Função
Age Uma estimativa da quantidade de tempo em segundos desde que a resposta foi gerada ou validada com êxito no servidor de origem.
Expira O tempo após o qual a resposta é considerada obsoleta.
Pragma Existe para compatibilidade com versões anteriores com caches HTTP/1.0 para comportamento de configuração no-cache . Se o Cache-Control cabeçalho estiver presente, o Pragma cabeçalho será ignorado.
Variar Especifica que uma resposta armazenada em cache não deve ser enviada, a menos que todos os campos de Vary cabeçalho correspondam tanto na solicitação original da resposta armazenada em cache quanto na nova solicitação.

O cache baseado em HTTP respeita as diretivas de Cache-Control de solicitação

A especificação de cache HTTP 1.1 para o cabeçalho Cache-Control requer um cache para honrar um cabeçalho válido Cache-Control enviado pelo cliente. Um cliente pode fazer solicitações com um no-cache valor de cabeçalho e forçar o servidor a gerar uma nova resposta para cada solicitação.

Sempre honrar cabeçalhos de solicitação de cliente Cache-Control faz sentido se você considerar a meta de cache HTTP. De acordo com a especificação oficial, o cache destina-se a reduzir a latência e a sobrecarga de rede de solicitações satisfatórias em uma rede de clientes, proxies e servidores. Não é necessariamente uma maneira de controlar a carga em um servidor de origem.

Não há controle do desenvolvedor sobre esse comportamento de cache ao usar o Middleware de cache de resposta porque o middleware segue a especificação de cache oficial. O suporte para o cache de saída para controlar melhor a carga do servidor é uma proposta de design para uma versão futura do ASP.NET Core. Para obter mais informações, consulte Adicionar suporte para cache de saída (dotnet/aspnetcore #27387).

Atributo ResponseCache

Especifica ResponseCacheAttribute os parâmetros necessários para definir os cabeçalhos apropriados no cache de resposta.

Aviso

Desabilite o cache para conteúdo que contém informações para clientes autenticados. O cache só deve ser habilitado para conteúdo que não seja alterado com base na identidade de um usuário ou se um usuário está conectado.

VaryByQueryKeys varia a resposta armazenada pelos valores da lista determinada de chaves de consulta. Quando um único valor é * fornecido, o middleware varia as respostas de todos os parâmetros de cadeia de caracteres de consulta de solicitação.

O Middleware de Cache de Resposta deve estar habilitado para definir a VaryByQueryKeys propriedade. Caso contrário, uma exceção de runtime será gerada. Não há um cabeçalho HTTP correspondente para a VaryByQueryKeys propriedade. A propriedade é um recurso HTTP tratado pelo Middleware de Cache de Resposta. Para que o middleware atenda a uma resposta armazenada em cache, a cadeia de caracteres de consulta e o valor da cadeia de caracteres de consulta devem corresponder a uma solicitação anterior. Por exemplo, considere a sequência de solicitações e resultados mostrados na tabela a seguir:

Solicitação Retornado de
http://example.com?key1=value1 Servidor
http://example.com?key1=value1 Middleware
http://example.com?key1=NewValue Servidor

A primeira solicitação é retornada pelo servidor e armazenada em cache no middleware. A segunda solicitação é retornada pelo middleware porque a cadeia de caracteres de consulta corresponde à solicitação anterior. A terceira solicitação não está no cache do middleware porque o valor da cadeia de caracteres de consulta não corresponde a uma solicitação anterior.

Ele ResponseCacheAttribute é usado para configurar e criar (por meio IFilterFactory) de um Microsoft.AspNetCore.Mvc.Internal.ResponseCacheFilter. O ResponseCacheFilter trabalho de atualização dos cabeçalhos e recursos HTTP apropriados da resposta. O filtro:

  • Remove todos os cabeçalhos existentes para Vary, Cache-Controle Pragma.
  • Grava os cabeçalhos apropriados com base nas propriedades definidas no ResponseCacheAttribute.
  • Atualizações o recurso HTTP de cache de resposta se VaryByQueryKeys estiver definido.

Variar

Esse cabeçalho só é gravado quando a VaryByHeader propriedade é definida. A propriedade definida como o Vary valor da propriedade. O exemplo a seguir usa a VaryByHeader propriedade:

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

Exiba os cabeçalhos de resposta com o Fiddler ou outra ferramenta. Os cabeçalhos de resposta incluem:

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

O código anterior requer a adição dos serviços AddResponseCaching middleware de cache de resposta à coleção de serviços e configura o aplicativo para usar o middleware com o UseResponseCaching método de extensão.

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 e Location.None

NoStore substitui a maioria das outras propriedades. Quando essa propriedade é definida como true, o Cache-Control cabeçalho é definido como no-store. Se Location estiver definido como None:

  • Cache-Control é definido como no-store,no-cache.
  • Pragma é definido como no-cache.

Se NoStore for false e Location for None, Cache-Controle Pragma estiver definido como no-cache.

NoStore normalmente é definido para true páginas de erro. O seguinte produz cabeçalhos de resposta que instruem o cliente a não armazenar a resposta.

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

O código anterior inclui os seguintes cabeçalhos na resposta:

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

Para aplicar a ResponseCacheAttribute todos os controladores MVC do aplicativo ou Razor respostas de página de Páginas, adicione-o com um filtro MVC ou Razor filtro Pages.

Em um aplicativo MVC:

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

Para obter uma abordagem que se aplica aos Razor aplicativos Pages, consulte Adicionar ResponseCacheAttribute à lista de filtros globais do MVC não se aplica a Razor Páginas (dotnet/aspnetcore #18890). O exemplo fornecido no comentário de problema foi escrito para aplicativos direcionados ASP.NET Core antes do lançamento de APIs mínimas em 6.0. Para aplicativos 6.0 ou posteriores, altere o registro de serviço no exemplo para builder.Services.AddSingleton...Program.cs.

Local e Duração

Para habilitar o cache, Duration deve ser definido como um valor positivo e Location deve ser Any (o padrão) ou Client. A estrutura define o Cache-Control cabeçalho como o valor do local seguido pela max-age resposta.

Location's opções de Any e traduzir em Cache-Control valores de cabeçalho de public eprivateClient, respectivamente. Conforme observado na seção NoStore e Location.None, a configuração Location para None definir os cabeçalhos e Pragma os Cache-Control cabeçalhos como no-cache.

Location.Any (Cache-Control definido como public) indica que o cliente ou qualquer proxy intermediário pode armazenar o valor em cache, incluindo Middleware de Cache de Resposta.

Location.Client (Cache-Control definido como private) indica que somente o cliente pode armazenar o valor em cache. Nenhum cache intermediário deve armazenar em cache o valor, incluindo Middleware de Cache de Resposta.

Os cabeçalhos de controle de cache fornecem diretrizes para clientes e proxies intermediários quando e como armazenar em cache respostas. Não há garantia de que clientes e proxies honrem a especificação de cache HTTP 1.1. O Middleware de Cache de Resposta sempre segue as regras de cache estabelecidas pela especificação.

O exemplo a seguir mostra os cabeçalhos produzidos pela configuração Duration e deixando o valor padrão Location :

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

O código anterior inclui os seguintes cabeçalhos na resposta:

Cache-Control: public,max-age=10

Perfis de cache

Em vez de duplicar as configurações de cache de resposta em muitos atributos de ação do controlador, os perfis de cache podem ser configurados como opções ao configurar o MVC/Razor Pages. Os valores encontrados em um perfil de cache referenciado são usados como padrões pelo ResponseCacheAttribute e são substituídos por quaisquer propriedades especificadas no atributo.

O exemplo a seguir mostra um perfil de cache de 30 segundos:

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();

O código a seguir faz referência ao perfil de Default30 cache:

[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());
}

A resposta de cabeçalho resultante pelo perfil de Default30 cache inclui:

Cache-Control: public,max-age=30

O [ResponseCache] atributo pode ser aplicado a:

  • Razor Páginas: Atributos não podem ser aplicados a métodos de manipulador. Navegadores usados com aplicativos de interface do usuário impedem o cache de resposta.
  • Controladores MVC.
  • Métodos de ação MVC: atributos no nível do método substituem as configurações especificadas em atributos de nível de classe.

O código a seguir aplica o [ResponseCache] atributo no nível do controlador e no nível do método:

[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());
}

Recursos adicionais

Exibir ou baixar código de exemplo (como baixar)

O cache de resposta reduz o número de solicitações que um cliente ou proxy faz a um servidor Web. O cache de resposta também reduz a quantidade de trabalho que o servidor Web executa para gerar uma resposta. O cache de resposta é controlado por cabeçalhos que especificam como você deseja que o cliente, o proxy e o middleware armazenem respostas em cache.

Os [ResponseCache] participantes da configuração de cabeçalhos de cache de resposta. Clientes e proxies intermediários devem honrar os cabeçalhos para respostas de cache na especificação de cache HTTP 1.1.

Para o cache do lado do servidor que segue a especificação de cache HTTP 1.1, use o Middleware de Cache de Resposta. O middleware pode usar as [ResponseCache] propriedades para definir cabeçalhos de cache do lado do servidor.

Cache de resposta baseado em HTTP

A especificação de cache HTTP 1.1 descreve como os caches da Internet devem se comportar. O cabeçalho HTTP primário usado para cache é Cache-Control, que é usado para especificar diretivas de cache. As diretivas controlam o comportamento de cache à medida que as solicitações fazem seu caminho de clientes para servidores e à medida que as respostas fazem seu caminho de servidores de volta para clientes. Solicitações e respostas se movem por meio de servidores proxy, e os servidores proxy também devem estar em conformidade com a especificação de cache HTTP 1.1.

As diretivas comuns Cache-Control são mostradas na tabela a seguir.

Diretiva Ação
público Um cache pode armazenar a resposta.
Privada A resposta não deve ser armazenada por um cache compartilhado. Um cache privado pode armazenar e reutilizar a resposta.
max-age O cliente não aceita uma resposta cuja idade é maior que o número especificado de segundos. Exemplos: max-age=60 (60 segundos) max-age=2592000 (1 mês)
no-cache Em solicitações: um cache não deve usar uma resposta armazenada para atender à solicitação. O servidor de origem regenera a resposta para o cliente e o middleware atualiza a resposta armazenada em seu cache.

Em respostas: a resposta não deve ser usada para uma solicitação subsequente sem validação no servidor de origem.
no-store Em solicitações: um cache não deve armazenar a solicitação.

Em respostas: um cache não deve armazenar nenhuma parte da resposta.

Outros cabeçalhos de cache que desempenham uma função no cache são mostrados na tabela a seguir.

Cabeçalho Função
Age Uma estimativa da quantidade de tempo em segundos desde que a resposta foi gerada ou validada com êxito no servidor de origem.
Expira O tempo após o qual a resposta é considerada obsoleta.
Pragma Existe para compatibilidade com versões anteriores com caches HTTP/1.0 para definir no-cache o comportamento. Se o Cache-Control cabeçalho estiver presente, o Pragma cabeçalho será ignorado.
Variar Especifica que uma resposta armazenada em cache não deve ser enviada, a menos que todos os campos de Vary cabeçalho correspondam tanto na solicitação original da resposta armazenada em cache quanto na nova solicitação.

O cache baseado em HTTP respeita as diretivas de Cache-Control de solicitação

A especificação de cache HTTP 1.1 para o cabeçalho Cache-Control requer um cache para honrar um cabeçalho válido Cache-Control enviado pelo cliente. Um cliente pode fazer solicitações com um valor de no-cache cabeçalho e forçar o servidor a gerar uma nova resposta para cada solicitação.

Sempre honrar cabeçalhos de solicitação de cliente Cache-Control faz sentido se você considerar a meta de cache HTTP. De acordo com a especificação oficial, o cache destina-se a reduzir a latência e a sobrecarga de rede de atender solicitações em uma rede de clientes, proxies e servidores. Não é necessariamente uma maneira de controlar a carga em um servidor de origem.

Não há controle do desenvolvedor sobre esse comportamento de cache ao usar o Middleware de cache de resposta porque o middleware segue a especificação de cache oficial. O suporte para o cache de saída para controlar melhor a carga do servidor é uma proposta de design para uma versão futura do ASP.NET Core. Para obter mais informações, consulte Adicionar suporte para cache de saída (dotnet/aspnetcore #27387).

Outra tecnologia de cache no ASP.NET Core

cache na memória

O cache na memória usa memória do servidor para armazenar dados armazenados em cache. Esse tipo de cache é adequado para um único servidor ou vários servidores usando afinidade de sessão. A afinidade de sessão também é conhecida como sessões autoadesivas. A afinidade de sessão significa que as solicitações de um cliente são sempre roteada para o mesmo servidor para processamento.

Para obter mais informações, consulte Cache na memória em ASP.NET Core e solucionar problemas de afinidade de sessão Gateway de Aplicativo do Azure.

Cache distribuído

Use um cache distribuído para armazenar dados na memória quando o aplicativo estiver hospedado em um farm de nuvem ou servidor. O cache é compartilhado entre os servidores que processam solicitações. Um cliente pode enviar uma solicitação que é tratada por qualquer servidor no grupo se os dados armazenados em cache para o cliente estiverem disponíveis. ASP.NET Core funciona com caches distribuídos SQL Server, Redis e NCache.

Para obter mais informações, consulte Cache distribuído em ASP.NET Core.

Auxiliar de marca de cache

Armazene o conteúdo em cache de um modo de exibição MVC ou Razor página com o Auxiliar de Marca de Cache. O Auxiliar de Marca de Cache usa o cache na memória para armazenar dados.

Para obter mais informações, consulte Auxiliar de Marca de Cache no ASP.NET Core MVC.

Auxiliar de Marca de Cache Distribuído

Armazene em cache o conteúdo de um modo de exibição MVC ou Razor página em cenários de nuvem distribuída ou farm da Web com o Auxiliar de Marca de Cache Distribuído. O Auxiliar de Marca de Cache Distribuído usa SQL Server, Redis ou NCache para armazenar dados.

Para obter mais informações, consulte o Auxiliar de Marca de Cache Distribuído no ASP.NET Core.

Atributo ResponseCache

Especifica ResponseCacheAttribute os parâmetros necessários para definir os cabeçalhos apropriados no cache de resposta.

Aviso

Desabilite o cache para conteúdo que contém informações para clientes autenticados. O cache só deve ser habilitado para conteúdo que não seja alterado com base na identidade de um usuário ou se um usuário está conectado.

VaryByQueryKeys varia a resposta armazenada pelos valores da lista determinada de chaves de consulta. Quando um único valor é * fornecido, o middleware varia as respostas de todos os parâmetros de cadeia de caracteres de consulta de solicitação.

O Middleware de Cache de Resposta deve estar habilitado para definir a VaryByQueryKeys propriedade. Caso contrário, uma exceção de runtime será gerada. Não há um cabeçalho HTTP correspondente para a VaryByQueryKeys propriedade. A propriedade é um recurso HTTP tratado pelo Middleware de Cache de Resposta. Para que o middleware atenda a uma resposta armazenada em cache, a cadeia de caracteres de consulta e o valor da cadeia de caracteres de consulta devem corresponder a uma solicitação anterior. Por exemplo, considere a sequência de solicitações e resultados mostrados na tabela a seguir.

Solicitação Result
http://example.com?key1=value1 Retornado do servidor.
http://example.com?key1=value1 Retornado do middleware.
http://example.com?key1=value2 Retornado do servidor.

A primeira solicitação é retornada pelo servidor e armazenada em cache no middleware. A segunda solicitação é retornada pelo middleware porque a cadeia de caracteres de consulta corresponde à solicitação anterior. A terceira solicitação não está no cache do middleware porque o valor da cadeia de caracteres de consulta não corresponde a uma solicitação anterior.

Ele ResponseCacheAttribute é usado para configurar e criar (por meio IFilterFactory) de um Microsoft.AspNetCore.Mvc.Internal.ResponseCacheFilter. O ResponseCacheFilter trabalho de atualização dos cabeçalhos e recursos HTTP apropriados da resposta. O filtro:

  • Remove todos os cabeçalhos existentes para Vary, Cache-Controle Pragma.
  • Grava os cabeçalhos apropriados com base nas propriedades definidas no ResponseCacheAttribute.
  • Atualizações o recurso HTTP de cache de resposta se VaryByQueryKeys estiver definido.

Variar

Esse cabeçalho só é gravado quando a VaryByHeader propriedade é definida. A propriedade definida como o Vary valor da propriedade. O exemplo a seguir usa a VaryByHeader propriedade:

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

Usando o aplicativo de exemplo, exiba os cabeçalhos de resposta com as ferramentas de rede do navegador. Os cabeçalhos de resposta a seguir são enviados com a resposta da página Cache1:

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

NoStore e Location.None

NoStore substitui a maioria das outras propriedades. Quando essa propriedade é definida como true, o Cache-Control cabeçalho é definido como no-store. Se Location estiver definido como None:

  • Cache-Control é definido como no-store,no-cache.
  • Pragma é definido como no-cache.

Se NoStore for false e Location for None, Cache-Controle Pragma estiver definido como no-cache.

NoStore normalmente é definido como true para páginas de erro. A página Cache2 no aplicativo de exemplo produz cabeçalhos de resposta que instruem o cliente a não armazenar a resposta.

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

O aplicativo de exemplo retorna a página Cache2 com os seguintes cabeçalhos:

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

Para aplicar a ResponseCacheAttribute todas as respostas de página do controlador MVC ou Razor páginas do aplicativo, adicione-o com um filtro MVC ou Razor filtro Pages.

Em um aplicativo MVC:

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

Para obter uma abordagem que se aplica aos Razor aplicativos Pages, consulte Adicionar ResponseCacheAttribute à lista de filtros globais do MVC não se aplica a Razor Páginas (dotnet/aspnetcore #18890).

Local e Duração

Para habilitar o cache, Duration deve ser definido como um valor positivo e Location deve ser Any (o padrão) ou Client. A estrutura define o Cache-Control cabeçalho como o valor do local seguido pela max-age resposta.

Location's opções de Any e traduzir em Cache-Control valores de cabeçalho de public e privateClient , respectivamente. Conforme observado na seção NoStore e Location.None, a configuração Location para None definir os cabeçalhos e Pragma os Cache-Control cabeçalhos como no-cache.

Location.Any (Cache-Control definido como public) indica que o cliente ou qualquer proxy intermediário pode armazenar em cache o valor, incluindo o Middleware de Cache de Resposta.

Location.Client (Cache-Control definido como private) indica que somente o cliente pode armazenar o valor em cache. Nenhum cache intermediário deve armazenar em cache o valor, incluindo Middleware de Cache de Resposta.

Os cabeçalhos de controle de cache apenas fornecem diretrizes para clientes e proxies intermediários quando e como armazenar em cache respostas. Não há garantia de que clientes e proxies respeitarão a especificação de cache HTTP 1.1. O Middleware de Cache de Resposta sempre segue as regras de cache estabelecidas pela especificação.

O exemplo a seguir mostra o modelo de página Cache3 do aplicativo de exemplo e os cabeçalhos produzidos pela configuração Duration e deixando o valor padrão Location :

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

O aplicativo de exemplo retorna a página Cache3 com o seguinte cabeçalho:

Cache-Control: public,max-age=10

Perfis de cache

Em vez de duplicar as configurações de cache de resposta em muitos atributos de ação do controlador, os perfis de cache podem ser configurados como opções ao configurar o MVC/Razor Pages em Startup.ConfigureServices. Os valores encontrados em um perfil de cache referenciado são usados como padrões pelo ResponseCacheAttribute e são substituídos por quaisquer propriedades especificadas no atributo.

Configurar um perfil de cache. O exemplo a seguir mostra um perfil de cache de 30 segundos no aplicativo de Startup.ConfigureServicesexemplo:

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

O modelo de página Cache4 do aplicativo de exemplo faz referência ao perfil de Default30 cache:

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

Pode ResponseCacheAttribute ser aplicado a:

  • Razor Páginas: Os atributos não podem ser aplicados aos métodos de manipulador.
  • Controladores MVC.
  • Métodos de ação MVC: atributos no nível do método substituem as configurações especificadas em atributos de nível de classe.

O cabeçalho resultante aplicado à resposta da página Cache4 pelo perfil de Default30 cache:

Cache-Control: public,max-age=30

Recursos adicionais