Edge Security Acceleration:Regras de cache padrão

Extensões de arquivos em cache padrão

Por padrão, o ESA armazena um arquivo em cache apenas se sua extensão corresponder a uma das listadas abaixo. A regra de cache correspondente determina o TTL.

Extensões de arquivo suportadas por categoria:

• Documentos:

  • DOC e DOCX: documentos do Microsoft Word.

  • PPT e PPTX: apresentações do Microsoft PowerPoint.

  • PDF: documentos portáteis.

  • CSV: arquivos de valores separados por vírgula.

• Arquivos de imagem:

  • BMP: imagens de mapa de bits.

  • GIF: imagens no formato Graphics Interchange Format (GIF).

  • ICO: imagens de ícone.

  • JPEG e JPG: imagens no formato Joint Photographic Experts Group (JPEG).

  • PNG: imagens no formato Portable Network Graphics (PNG).

  • SVG e SVGZ: imagens no formato Scalable Vector Graphics (SVG).

  • TIF e TIFF: imagens no formato Tagged Image File Format (TIFF).

  • WEBP: imagens WebP com suporte a compressão com e sem perdas.

• Arquivos de áudio:

  • MP3: arquivos MPEG-1 Audio Layer III (MP3).

  • FLAC: arquivos Free Lossless Audio Codec (FLAC).

  • MID e MIDI: arquivos Musical Instrument Digital Interface (MIDI).

• Arquivos de vídeo:

  • AVI: arquivos Audio Video Interleave (AVI).

  • MP4: arquivos MPEG-4 (MP4).

  • MKV: arquivos Matroska Video (MKV).

  • WEBM: formato de contêiner de mídia aberto com suporte a vídeo e áudio.

• Arquivos compactados:

  • 7Z: arquivos 7-Zip.

  • GZ: arquivos GNU Gzip.

  • RAR: arquivos RAR.

  • TAR: arquivos TAR.

  • ZIP: arquivos ZIP.

  • ZST: arquivos Zstandard.

• Arquivos executáveis (programas executáveis/pacotes de instalação):

  • APK: arquivos de pacote Android.

  • BIN: arquivos binários, frequentemente usados para atualizações de firmware.

  • CLASS: arquivos de bytecode Java.

  • DMG: arquivos de imagem de disco macOS.

  • EXE: arquivos executáveis do Windows.

  • JAR: arquivos Java archive (JAR).

  • MSI: arquivos de instalador do Windows.

  • ISO: arquivos de imagem ISO.

• Arquivos de fonte:

  • EOT: arquivos de fonte Embedded OpenType (EOT).

  • OTF: arquivos de fonte OpenType (OTF).

  • TTF: arquivos de fonte TrueType (TTF).

  • WOFF e WOFF2: arquivos Web Open Font Format (WOFF).

• Arquivos de script e código:

  • CSS: arquivos Cascading Style Sheets (CSS).

  • EJS: arquivos de modelo Embedded JavaScript (EJS).

  • JS: arquivos JavaScript (JS).

  • Arquivos de design e gráficos vetoriais:

  • EPS: arquivos Encapsulated PostScript (EPS).

  • PICT: arquivos Apple PICT.

  • PS: arquivos PostScript (PS).

  • SWF: arquivos Shockwave Flash (SWF).

7Z	CSV	GIF	MIDI	PNG	TIF	ZIP
AVI	DOC	GZ	MKV	PPT	TIFF	ZST
AVIF	DOCX	ICO	MP3	PPTX	TTF
APK	DMG	ISO	MP4	PS	WEBM
BIN	EJS	JAR	OGG	RAR	WEBP
BMP	EOT	JPG	OTF	SVG	WOFF
BZ2	EPS	JPEG	PDF	SVGZ	WOFF2
CLASS	EXE	JS	PICT	SWF	XLS
CSS	FLAC	MID	PLS	TAR	XLSX

Regras de cache para respostas bem-sucedidas e redirecionamentos

Códigos de status aplicáveis: 200, 203, 206, 300, 301 e 410.

O TTL de cache de borda possui quatro opções:

• Honor Origin TTL or Use Default Cache Rule: Se a resposta do servidor de origem contiver os cabeçalhos Cache-Control, Expires, Last-Modified e ETag para definir uma política de cache, o ESA utilizará a política de cache do servidor de origem. Caso a resposta não contenha nenhum dos cabeçalhos Cache-Control, Expires, Last-Modified e ETag, o ESA armazenará os recursos em cache com base na política de cache padrão do ESA.

  Detalhes da política de cache

  

  Cache-Control na resposta

  O cabeçalho Cache-Control na resposta de origem especifica uma das seguintes políticas:

  1. Se o cabeçalho Cache-Control tiver uma das diretivas a seguir, o recurso não será armazenado em cache:

     • no-cache

     • no-store

     • max-age=0

  2. Caso o cabeçalho Cache-Control contenha a diretiva max-age ou s-maxage com valor maior que 0, como 3600, o TTL especificado pela diretiva será utilizado. Se ambas as diretivas max-age e s-maxage existirem, o valor da diretiva s-maxage prevalecerá.

  Ausência de Cache-Control na resposta

  Se a resposta de origem não contiver o cabeçalho Cache-Control, a política de cache padrão do ESA será usada. Prioridade dos cabeçalhos (do maior para o menor): Expires > Last-Modified > ETag.

  1. Quando a resposta de origem contém o cabeçalho Expires, como Expires:Tue, 25 Nov 2031 17:25:43 GMT, o ESA usa o TTL definido no cabeçalho Expires.

  2. Se a resposta de origem não contiver o cabeçalho Expires, mas contiver o cabeçalho Last-Modified, o TTL será calculado conforme as regras a seguir:

     • TTL = (Hora atual - Valor de Last-Modifie d) × 0,1. Se o valor resultante estiver entre 10 segundos e 3.600 segundos, o valor real será usado. Se for menor que 10 segundos, o TTL será de 10 segundos. Se for maior que 3.600 segundos, o TTL será de 3.600 segundos.

  3. Caso a resposta de origem contenha apenas o cabeçalho ETag, o TTL será de 10 segundos.

  4. Quando a resposta de origem não contém os cabeçalhos Cache-Control, Expires, ETag ou Last-Modified, o recurso não é armazenado em cache.

• Honor Origin TTL or Do Not Cache: Se a resposta do servidor de origem contiver o cabeçalho Cache-Control para definir uma política de cache, o ESA usará a política de cache do servidor de origem. Caso a resposta não contenha o cabeçalho Cache-Control, o ESA não armazenará os recursos em cache.

  Detalhes da política de cache

  

  Determinação da política de cache do servidor de origem

  Verifique se a resposta de origem contém o cabeçalho Cache-Control. Se estiver ausente, os recursos não serão armazenados em cache. Se presente, uma das seguintes políticas se aplica:

  1. Se o cabeçalho Cache-Control contiver a diretiva no-cache, no-store ou max-age=0, os recursos não serão armazenados em cache.

  2. Caso o cabeçalho Cache-Control contenha a diretiva max-age ou s-maxage com valor maior que 0, como 3600, o TTL especificado pela diretiva será utilizado. Se ambas as diretivas max-age e s-maxage existirem, o valor da diretiva s-maxage prevalecerá.

• Do Not Cache: Nenhum recurso recuperado do servidor de origem é armazenado em cache nos POPs do ESA.

• Use Custom TTL: O ESA ignora os cabeçalhos Cache-Control, Expires, Last-Modified e ETag da política de cache na resposta de origem e utiliza o TTL definido no ESA.

Regras de cache para respostas com códigos de status de erro

• Para os códigos de status 204, 305, 404, 405, 414, 424, 429, 500, 501, 502, 503 e 504, as regras de cache são as seguintes:

  

  1. Se o servidor de origem retornar um cabeçalho de resposta set-cookie, a resposta não será armazenada em cache.

  2. Caso o servidor de origem não retorne um cabeçalho de resposta set-cookie, o sistema verificará se há um TTL configurado para o código de status no console:

     1. Se houver um TTL configurado, a resposta será armazenada em cache conforme as definições do console. Quando houver várias regras definidas, a regra com o menor número ordinal entrará em vigor.

     2. Na ausência de TTL configurado, a resposta será armazenada em cache com base nos cabeçalhos de resposta Pragma, Cache-Control ou Expires do servidor de origem.

  3. Se o servidor de origem não retornar os cabeçalhos de resposta Pragma, Cache-Control ou Expires, a resposta será armazenada em cache por 1 segundo por padrão.

• Para os códigos de status 302, 307 e 403, as regras de cache são as seguintes:

  

  1. Se o servidor de origem retornar um cabeçalho de resposta set-cookie, a resposta não será armazenada em cache.

  2. Caso o servidor de origem não retorne um cabeçalho de resposta set-cookie, o sistema verificará se há um TTL configurado para o código de status no console:

     1. Se houver um TTL configurado, a resposta será armazenada em cache conforme as definições do console. Quando houver várias regras definidas, a regra com o menor número ordinal entrará em vigor.

     2. Na ausência de TTL configurado, a resposta será armazenada em cache com base nos cabeçalhos de resposta Pragma, Cache-Control ou Expires do servidor de origem.

  3. Se o servidor de origem não retornar os cabeçalhos de resposta Pragma, Cache-Control ou Expires, a resposta não será armazenada em cache.

• Para outros códigos de status de erro, como 400, as regras de cache são as seguintes:

  1. Se o servidor de origem retornar um cabeçalho de resposta set-cookie, a resposta não será armazenada em cache.

  2. Caso o servidor de origem não retorne um cabeçalho de resposta set-cookie, o sistema verificará se há um TTL configurado para o código de status no console. Quando houver várias regras definidas, a regra com o menor número ordinal entrará em vigor.

  3. Em todos os outros casos, a resposta não será armazenada em cache.

• Para solicitações que usam busca de origem por intervalo, se um POP receber uma resposta com código de status diferente de 206 do servidor de origem, o POP excluirá os fragmentos de arquivo em cache. Um tempo limite de busca de origem não causa a exclusão dos arquivos em cache.

  Ao usar a busca de origem por intervalo, o servidor de origem divide um arquivo grande em vários fragmentos menores e os envia ao POP. Por exemplo, se um arquivo for dividido em 10 fragmentos e o POP já tiver armazenado 5 deles em cache, quando o POP solicitar o 6º fragmento e o servidor de origem retornar um código de status 5xx, o POP excluirá todos os 5 fragmentos armazenados.

Informações de resposta de cache

Os POPs do ESA retornam cabeçalhos de resposta relacionados ao cache com as seguintes informações:

• Ali-Swift-Global-Savetime: Hora em que o recurso entrou pela primeira vez no POP do ESA (determinado pela arquitetura de cache do site, que pode ser um POP L2 ou um POP em outra camada de cache).

  • Seu valor é um carimbo de data/hora UNIX. Por exemplo: 1745053111 indica 16:58:31 em 19 de abril de 2025.

• Date: Data em que o servidor de origem retorna o recurso ao POP do ESA.

  • A data é atualizada quando o POP do ESA inicia uma solicitação de origem contendo o cabeçalho If-Modified-Since ou If-None-Match para revalidar o recurso e o servidor de origem retorna o código de status HTTP 304.

  • A hora está no formato GMT. Exemplo: Sat, 19 Apr 2025 08:58:31 GMT.

• X-Site-Cache-Status: Status de cache do recurso solicitado no POP do ESA. A lista a seguir descreve os estados do recurso:

  • HIT: O recurso foi encontrado no cache do POP do ESA.

  • MISS: O recurso não foi encontrado no cache do POP do ESA. O POP recupera o recurso do servidor de origem e o retorna ao cliente.

  • NONE/UNKNOWN: O recurso não é elegível para cache pelos seguintes motivos:

    • Uma função de borda gera uma resposta, mas não envia nenhuma subsolicitação. Nesse caso, a resposta não vem do cache e o status de cache é registrado como none/unknown.

    • Quando a solicitação principal de uma função de borda inicia uma subsolicitação (fetch), o status de cache é registrado para a subsolicitação, enquanto o status de cache da solicitação principal é registrado como none/unknown. Isso ocorre porque o módulo de função de borda é executado antes do módulo de cache, impedindo que a solicitação principal passe pelo cache.

    • Uma solicitação de cliente atinge uma regra personalizada do WAF e é bloqueada pelo WAF. Como o WAF é executado antes do módulo de cache, a solicitação não passa pelo cache e o status de cache é registrado como none/unknown.

    • Uma solicitação de cliente atinge um Redirecionamento de solicitação ou uma Regra HTTPS. O POP então envia uma resposta de redirecionamento para outra URL. Como essas regras são executadas antes do módulo de cache, o status de cache é registrado como none/unknown.

  • EXPIRED: O recurso foi encontrado no cache do POP do ESA, mas expirou. O POP recupera o recurso do servidor de origem e o retorna ao cliente. O código de status retornado pelo servidor de origem é 200 ou 206.

  • STALE:

    O recurso é servido a partir do cache do POP do ESA, mas expirou. Isso ocorre nos seguintes casos:

    • A configuração de cache é Honor Origin TTL e a resposta de origem contém Cache-Control:stale-while-revalidate=<seconds>. Dentro do tempo especificado, o ESA inicia uma solicitação ao servidor de origem para revalidar o recurso e serve o cache expirado ao cliente.

    • A configuração de cache é Honor Origin TTL e a resposta de origem contém Cache-Control:stale-if-error=<seconds>. Dentro do tempo especificado, o ESA serve o cache expirado ao cliente quando o ESA não consegue se conectar ao servidor de origem para recuperar o recurso atualizado.

    • O recurso Configurar Servir Conteúdo Obsoleto está ativado. Esse recurso permite que o POP do ESA sirva o cache expirado ao cliente quando a resposta de origem atingir o tempo limite ou quando o servidor de origem estiver inacessível.

  • BYPASS

    A solicitação ao recurso ignora o cache do ESA. Isso ocorre nos seguintes casos:

    • A configuração de cache não é Honor Origin TTL e o ESA define um TTL de cache personalizado como 0 segundos.

    • A configuração de cache é Honor Origin TTL, mas o valor do cabeçalho Cache-Control retornado pelo servidor de origem é no-store.

  • REVALIDATED

    O recurso é servido pelo cache do ESA, mas expirou. O ESA inicia uma solicitação de origem contendo o cabeçalho If-Modified-Since ou lf-None-Match ao servidor de origem para revalidar o recurso. O servidor de origem retorna o código de status HTTP 304.

  • DYNAMIC

    O ESA detecta que o recurso é conteúdo dinâmico e nenhuma regra de cache definida se aplica a essa solicitação. Nesse caso, o ESA recupera o recurso do servidor de origem e o retorna ao cliente.

• X-Swift-Cachetime: Especifica o TTL do recurso no POP em segundos. O valor de X-Swift-Cachetime não é igual ao TTL definido no ESA. Ele é calculado usando a seguinte fórmula: X-Swift-Cachetime = Ali-Swift-Global-Savetime + o TTL definido no ESA - X-Swift-SaveTime. Os seguintes cenários podem ocorrer:

  • O valor de X-Swift-Cachetime é igual ao TTL definido no ESA, por exemplo, 3600 segundos.

  • O valor de X-Swift-Cachetime é ligeiramente menor que o TTL definido no ESA. Por exemplo, se o TTL definido no ESA for 300 segundos, o valor de X-Swift-Cachetime poderá ser 295 segundos. Essa discrepância pode ocorrer pelos seguintes motivos:

    • Alta latência ocorre quando um nó L1 busca conteúdo de um nó L2.

    • Os relógios nos nós L1 e L2 não estão sincronizados.

  • O valor de X-Swift-Cachetime é negativo. Isso pode ocorrer se você alterar a configuração de TTL no ESA após um recurso ser armazenado em cache. Isso acontece quando uma solicitação de cliente chega após a expiração do cache do nó L1, mas enquanto o cache do nó L2 ainda é válido. Por exemplo, o TTL foi originalmente definido como 3600 segundos no ESA e posteriormente alterado para 300 segundos. Se um cliente enviar uma solicitação 600 segundos após o recurso ter sido armazenado em cache, a resposta incluirá X-Swift-Cachetime:-300. Para resolver esse problema, atualize o cache.

• X-Swift-Cachetime:

  O TTL de cache do recurso no POP do ESA. Unidade: segundos.

• X-Swift-SaveTime:

  • A hora em que o recurso entrou pela primeira vez no POP atual (POP L1) que recebe a solicitação do cliente.

  • A hora está no formato GMT. Exemplo: Sat, 19 Apr 2025 08:58:31 GMT.

Política Do Not Cache

O POP do ESA não armazena arquivos em cache e repassa todas as solicitações de arquivo nas seguintes condições:

• Edge Cache TTL na página Settings do ESA está definido como Honor Origin TTL or Do Not Cache e a resposta de origem é Cache-Control: no-store.

• [CONREF:app_site_cache_configuration_node_expiration_title] na página Settings do ESA está definido como Do Not Cache.

• [CONREF:app_site_cache_configuration_node_expiration_title] na página Settings do ESA está definido como Use Custom TTL e o TTL de cache está definido como 0 segundos.

Revalidação de cache

Após a expiração de um arquivo em cache no POP do ESA, o POP do ESA envia uma solicitação de validação ao servidor de origem na próxima solicitação do cliente. Se o arquivo não tiver sido alterado, o servidor de origem retorna 304 not-modified, e o POP do ESA serve o arquivo em cache sem baixá-lo novamente. Isso reduz o tráfego de origem e melhora a velocidade de resposta.

• Configuração de política especial: Um arquivo é armazenado em cache por 0 segundos, e o POP do ESA redireciona cada solicitação ao servidor de origem para validação.

  • Edge Cache TTL na página Settings do ESA está definido como Honor Origin TTL or Use Default Cache Rule, e a resposta de origem atende às seguintes condições:

    • Cache-Control: no-cache

    • Cache-Control: max-age=0

• Configuração de política regular: O servidor de origem responde à política relacionada à validação de cache, e o POP do ESA executa a política real.

  • Edge Cache TTL na página Settings do ESA está definido como Honor Origin TTL or Use Default Cache Rule, e a resposta de origem atende a uma das seguintes políticas de validação de cache:

    • must-revalidate

    • proxy-revalidate

    • stale-while-revalidate=seconds

    • stale-if-error=seconds

• Política de validação de cache

  Políticas de validação de cache:

  • must-revalidate

    • Descrição: Uma vez expirado, qualquer cache (proxy ou navegador) deve revalidar o recurso com o servidor de origem antes de servi-lo. O cache não pode servir conteúdo expirado mesmo se a rede estiver indisponível, a menos que o recurso tenha sido validado como inalterado.

    • Exemplo: Cache-Control: max-age=3600, must-revalidate indica que um recurso deve ser retornado ao servidor de origem para validar sua atualização após a expiração do recurso.

  • proxy-revalidate

    • Descrição: Semelhante a must-revalidate, mas aplica-se apenas a caches compartilhados (CDN, servidores proxy). Caches privados, como navegadores, não estão sujeitos a essa restrição.

    • Exemplo: Cache-Control: max-age=3600, proxy-revalidate indica que um recurso deve ser retornado ao servidor de origem para validar sua atualização após a expiração do recurso.

  • stale-while-revalidate=seconds

    • Descrição: Após a expiração, o cache serve conteúdo obsoleto pela duração especificada enquanto revalida assincronamente com a origem em segundo plano. Use esta opção quando a redução da latência for mais importante do que servir conteúdo brevemente obsoleto.

    • Exemplo: Cache-Control: max-age=3600, stale-while-revalidate=60 indica que um recurso é considerado atualizado por 3.600 segundos (1 hora) após sua primeira publicação. Uma vez expirado, o recurso ainda pode ser fornecido aos usuários pelos próximos 60 segundos. Ao mesmo tempo, o POP tenta obter atualizações do servidor de origem.

  • stale-if-error=seconds

    • Descrição: Quando a origem está inacessível (falha no servidor, erro de rede), o POP serve conteúdo em cache expirado pela duração especificada. Isso melhora a tolerância a falhas e mantém a disponibilidade durante interrupções na origem.

    • Exemplo: Cache-Control: max-age=86400, stale-if-error=604800 indica que um recurso é considerado atualizado por 86.400 segundos (24 horas) após sua primeira publicação. Se a revalidação após os 86.400 segundos falhar, o último recurso armazenado em cache com sucesso ainda poderá ser fornecido pelos próximos 604.800 segundos (uma semana).