Trata-se do roteamento de solicitações de aplicativos e da desativação dinâmica do cache de disco para determinadas solicitações (onde as solicitações vêm de usuários autenticados; se eles são autenticados pode ser decidido por código personalizado).
Na minha configuração, há um servidor executando ARR, despachando solicitações para um site ASP.NET MVC em um servidor diferente. O site usa Autenticação de Formulários (e às vezes autenticação básica HTTP), portanto a autenticação acontece no site MVC, não em ARR: basicamente quando o usuário autentica o site cria um cookie de Autenticação de Formulários.
Gostaria que o seguinte acontecesse no ARR:
- Faça cache de saída para usuários anônimos.
- Para usuários autenticados, armazene apenas em cache arquivos estáticos (por exemplo, arquivos .css, .js, .jpg) e não armazene em cache páginas dinâmicas.
Como é possível ter uma regra de configuração de cache para este cenário? Eu tentei de várias maneiras:
- Cabeçalhos de cache: os cabeçalhos de controle de cache enviados pelo aplicativo MVC não são utilizáveis aqui, pois imagine o seguinte: a página 1 está no cache do ARR. O usuário autentica e visita a página 1. O aplicativo MVC enviaria um cabeçalho sem cache, mas a solicitação não o alcançaria, então o usuário obteria a versão em cache.
- URLs sem cache: embora eu provavelmente definisse que URLs com "no-arr-cache" não deveriam ser armazenados em cache, funcionaria com a reescrita de URL, ou seja, com um provedor de reescrita de URL personalizado, eu reescreveria solicitações autenticadas para ...? sem-arr-cache. Além das regras de controle de cache ARR que não se importam com as strings de consulta, o problema é que o ARR leva em consideração apenas os URLs solicitados quando uma regra de configuração de cache é avaliada, e não o URL reescrito.
Agradeço antecipadamente!
Eu postei isso doFóruns do IISporque ninguém respondeu lá.
Responder1
Foi assim que resolvi.
Devemos ter em mente as seguintes premissas:
- ARR identifica itens armazenados em cache com sua URL (que, dependendo da configuração, inclui a string de consulta; esta deve ser a configuração).
- Durante uma solicitação, o ARR pode ser instruído a não armazenar em cache a saída da solicitação atual.
- Se a saída da solicitação atual (URL) foi armazenada em cache antes, não há como instruir o ARR a não usar a versão em cache.
A grande ideia é alterar a URL da solicitação, ou melhor, reescrevê-la de forma diferente com IIS URL Rewrite dependendo se o usuário está autenticado ou não. Usuários não autenticados obtêm todas as páginas servidas, por exemplo, /my-page?authenticated=false e as autenticadas com /my-page?authenticated=true. As páginas serão armazenadas em cache apenas para usuários anônimos, portanto o ARR não encontrará nenhuma entrada de cache correspondente para usuários autenticados. Assim, o terceiro ponto está resolvido. Por outro lado, a string de consulta anexada aos URLs pode aparecer no corpo HTML; eles devem ser removidos com IIS URL Rewrite.
Para instruir o ARR a não armazenar em cache a solicitação atual, defina a variável do servidor ARR_CACHE_CONTROL_OVERRIDE como "1,no-cache" (você pode fazer isso a partir das regras de reescrita).
Você pode detectar se o usuário está autenticado a partir de um URL Rewrite IRewriteProvider do IIS (consultetutorial), ou seja, você pode usar a saída de tal provedor para reescrever a URL de maneira diferente para usuários autenticados e anônimos.
Espero que ajude alguém.