Quando um ponto de presença (POP) do CDN busca um recurso no servidor de origem, a origem retorna um código de status HTTP. Por padrão, o CDN usa os cabeçalhos de cache da origem para decidir se o código de status deve ser armazenado em cache e por quanto tempo. O TTL de código de status permite substituir esse comportamento: defina uma duração de cache personalizada por código de status para que os POPs forneçam a resposta diretamente aos clientes sem buscar na origem até que o TTL expire.
Como funciona
Um POP recebe uma solicitação para um recurso que não está em seu cache. Ele busca o recurso na origem, que retorna um código de status. Se você configurou um TTL para esse código de status, o POP o armazena em cache pela duração configurada. Durante esse período, solicitações subsequentes para o mesmo recurso recebem o código de status em cache imediatamente — sem busca na origem. Quando o TTL expira, a próxima solicitação aciona uma nova busca na origem.
Caso de uso: Um arquivo é excluído do servidor de origem, mas os clientes continuam solicitando-o. Sem um TTL configurado, cada solicitação chega à origem e recebe uma resposta 404, o que aumenta a carga na origem. Após configurar um TTL de 10 segundos para 404, o POP armazena a primeira resposta 404 em cache e a fornece diretamente pelos próximos 10 segundos.
Comportamento padrão de cache
A tabela a seguir resume como o CDN lida com códigos de status anormais quando nenhum TTL está configurado no console e a origem não retorna nenhum cabeçalho Set-Cookie.
| Grupo de códigos de status | Comportamento padrão (sem configuração no console, sem Set-Cookie) |
|---|---|
| 204, 305, 404, 405, 414, 424, 429, 500, 501, 502, 503, 504 | Armazenado em cache conforme o cabeçalho Pragma, Cache-Control ou Expires da origem. Se nenhum desses cabeçalhos estiver presente, armazenado em cache por 1 segundo. |
| 302, 307, 403 | Armazenado em cache conforme o cabeçalho Pragma, Cache-Control ou Expires da origem. Se nenhum desses cabeçalhos estiver presente, não armazenado em cache. |
| 304 | Nunca armazenado em cache. Não é possível configurar um TTL para esse código de status. |
| Outros códigos anormais (por exemplo, 400) | Não armazenado em cache, a menos que você configure um TTL no console. |
Se a origem retornar um cabeçalho Set-Cookie, o CDN não armazena a resposta em cache, independentemente do código de status ou de qualquer configuração no console.Regras de cache para códigos de status anormais
Códigos de status 204, 305, 404, 405, 414, 424, 429, 500, 501, 502, 503, 504
Se a origem retornar um cabeçalho de resposta
set-cookie, o CDN não armazena a resposta em cache.Quando a origem não retorna um cabeçalho Set-Cookie, a resposta fica armazenada em cache pela duração configurada no console do CDN. Para detalhes sobre como múltiplas regras interagem, consulte Prioridade de múltiplas regras.
Caso nenhum cabeçalho Set-Cookie esteja presente e nenhum TTL esteja configurado no console, a resposta será armazenada em cache com base no cabeçalho de resposta
Pragma,Cache-ControlouExpiresda origem.Se nenhuma das condições acima se aplicar — sem Set-Cookie, sem configuração no console e sem cabeçalho
Pragma,Cache-ControlouExpires— a resposta fica armazenada em cache por 1 segundo.
Códigos de status 302, 307, 403
Quando a origem retorna um cabeçalho de resposta
set-cookie, o CDN não armazena a resposta em cache.Se a origem não retornar um cabeçalho Set-Cookie, a resposta será armazenada em cache pela duração configurada no console do CDN.
Caso nenhum cabeçalho Set-Cookie esteja presente e nenhum TTL esteja configurado no console, a resposta será armazenada em cache com base no cabeçalho de resposta
Pragma,Cache-ControlouExpiresda origem.Se nenhuma das condições acima se aplicar, a resposta não é armazenada em cache (ao contrário do grupo anterior, não há fallback de 1 segundo).
Código de status 304
O CDN não armazena respostas 304 em cache. Não é possível configurar um TTL para esse código de status.
Outros códigos de status anormais (por exemplo, 400)
Caso a origem retorne um cabeçalho de resposta
set-cookie, o CDN não armazena a resposta em cache.Se a origem não retornar um cabeçalho Set-Cookie, a resposta será armazenada em cache pela duração configurada no console do CDN.
Em todos os outros cenários, a resposta não é armazenada em cache.
Comportamento de busca de origem por range
Em uma busca de origem por range, a origem divide um arquivo grande em shards menores e os retorna ao POP sequencialmente. Se um POP receber um código de status diferente de 206 da origem durante uma busca de origem por range, todos os shards previamente armazenados em cache desse arquivo serão excluídos.
Exemplo: Um arquivo é dividido em 10 shards. O POP armazenou cinco shards em cache. Quando o POP solicita o sexto shard, a origem retorna um código de status 5xx. O CDN exclui todos os cinco shards armazenados em cache anteriormente.
Um timeout de busca de origem não causa a exclusão dos shards armazenados em cache.
Prioridade de múltiplas regras
Quando uma solicitação corresponde a mais de uma regra de cache para o mesmo código de status, apenas uma regra entra em vigor. O CDN determina a regra efetiva da seguinte forma:
O tipo tem precedência: regras de File Extension têm prioridade sobre regras de Directory.
Ordem de criação como desempate: se várias regras compartilham o mesmo tipo, a regra criada primeiro (exibida mais acima na lista de regras) entra em vigor.
A ordem de avaliação é: File Extension > Directory e, para o mesmo tipo, older > newer.
Criar uma regra de cache de código de status
Pré-requisitos
Antes de começar, certifique-se de que você tem:
Um nome de domínio do Alibaba Cloud CDN configurado e ativo
Acesso ao console do CDN
Etapas
Faça login no console do CDN.
No painel de navegação à esquerda, clique em Domain Names.
Na página Domain Names, localize o nome de domínio desejado e clique em Manage na coluna Actions.
No painel de navegação do domínio, clique em Cache.
Clique na aba Status Code TTL.
Clique em Create Rule. Configure os seguintes parâmetros:
Parâmetro Descrição Type Selecione Directory ou File Extension. Regras de File Extension têm prioridade sobre regras de Directory. Object Directory: insira o caminho completo de um único diretório. O caminho deve começar com uma barra ( /). Por exemplo,/directory/aaa. File Extension: insira uma ou mais extensões de arquivo separadas por vírgulas. Por exemplo,jpg,txt. As regras diferenciam maiúsculas de minúsculas:jpgeJPGsão tratados como extensões diferentes, e uma regra posterior para a mesma extensão (com diferença de maiúsculas/minúsculas) sobrescreve a anterior. Asteriscos (*) não são aceitos.Expire In Especifique os códigos de status e suas durações de cache. A duração máxima é de três anos. A unidade é segundos. Separe vários códigos de status com vírgulas. Para códigos 2xx e 3xx, especifique apenas códigos individuais (por exemplo, 201=10). Padrões com curingas como2xx=12não são aceitos para códigos 2xx e 3xx. Para códigos 4xx e 5xx, tanto códigos individuais (por exemplo,401=10) quanto padrões com curingas (por exemplo,4xx=12) são aceitos.Honor Origin TTL Se ativado e a origem retornar cabeçalhos Cache-ControlouPragma, a política de cache da origem terá precedência sobre o TTL configurado.Ignore Origin No-Cache Header Se ativado, os POPs do CDN ignoram os seguintes cabeçalhos da origem: Cache-Control: no-store,Cache-Control: no-cache,Cache-Control: max-age=0ePragma: no-cache.Follow POP Cache Policy Se ativado, o POP do CDN retorna a política de cache efetiva final ao cliente. Force Revalidation Aplica-se apenas quando a duração do cache é definida como 0. Shutdown (default): os nós do CDN não armazenam o conteúdo em cache. A cada solicitação, o CDN busca na origem. Enabled: os nós do CDN armazenam o conteúdo em cache, mas a cada solicitação, o CDN busca na origem para revalidar o conteúdo em cache antes de servi-lo.
Clique em OK.
A regra aparece na lista da aba Expire In. Para atualizar ou remover uma regra, clique em Modify ou Delete na linha da regra.
Exemplos de configuração
Exemplo 1: regra de Directory

Esta regra tem como alvo o diretório /directory/aaa. Para solicitações nesse diretório, todos os códigos de status 4xx são armazenados em cache por 10 segundos e o código de status 201 é armazenado em cache por 15 segundos. Durante esses períodos, os POPs respondem diretamente sem buscar na origem. Após a duração do cache expirar, a próxima solicitação aciona uma busca na origem.
Exemplo 2: regra de File Extension

Esta regra tem como alvo arquivos .jpg e .txt. Para esses arquivos, o código de status 403 é armazenado em cache por 10 segundos e o código de status 404 é armazenado em cache por 15 segundos.
Exemplo 3: prioridade quando os tipos de regra diferem

Uma regra de Directory e uma regra de File Extension são configuradas com TTLs diferentes para o código de status 404. Um cliente solicita http://example.com/directory/aaa/test.jpg. O recurso não está em cache. O POP busca na origem, que retorna 404. A solicitação corresponde a ambas as regras. Como File Extension > Directory, a regra de File Extension entra em vigor e o código de status 404 é armazenado em cache por 20 segundos.
Exemplo 4: prioridade quando os tipos de regra são iguais

A Regra de Directory 1 tem como alvo /directory. A Regra de Directory 2 tem como alvo /directory/aaa. Ambas atribuem TTLs diferentes ao código de status 404. Um cliente solicita http://example.com/directory/aaa/test.jpg. A solicitação corresponde a ambas as regras de Directory. Como regras do mesmo tipo seguem a ordem older > newer, a Regra de Directory 1 (criada primeiro) entra em vigor e o código de status 404 é armazenado em cache por 15 segundos.
Referência da API
Para configurar o TTL de código de status usando a API, use BatchSetCdnDomainConfig.