HTTP 304 Not Modified: o que significa

O que este erro significa e como reconhecê-lo

• Uma ferramenta de desenvolvedor do navegador, cliente de API, ferramenta de monitoramento ou verificador informa o status 304 Not Modified.
• A resposta contém cabeçalhos de cache ou validadores, mas não contém o corpo do recurso.
• Um navegador pode exibir a página normalmente porque reutiliza sua representação armazenada em cache.
• Um cliente de API ou verificador pode aparentar receber uma resposta vazia se não implementar corretamente o cache condicional.
• O resultado pode se aplicar a uma URL ou recurso específico, e não ao site inteiro.
• DNS e TLS ainda podem estar funcionando, pois o cliente alcançou um endpoint HTTP e recebeu uma resposta HTTP.

Causas principais, por probabilidade

1. O cliente enviou uma solicitação condicional. Cabeçalhos de solicitação como If-None-Match ou If-Modified-Since perguntaram se a representação armazenada em cache ainda estava atualizada.
2. O recurso não foi alterado. O servidor ou um intermediário correspondeu o validador fornecido, como um valor ETag ou Last-Modified, e retornou 304 corretamente.
3. Um navegador, proxy ou CDN realizou a validação normal do cache. A resposta pode ter sido gerada por um intermediário, e não pela aplicação de origem.
4. Um cliente ou ferramenta de monitoramento expôs uma resposta normal de cache como erro. Algumas ferramentas são configuradas para esperar um corpo de resposta completo e podem não reutilizar sua cópia armazenada.
5. A configuração de validadores ou do cache é inconsistente. Resultados inesperados podem ocorrer quando implantações da aplicação, regras de proxy ou cabeçalhos da origem produzem validadores de cache obsoletos, conflitantes ou abrangentes demais.

HTTP 304, por si só, não é um redirecionamento, uma falha de autenticação, uma resposta de limite de taxa ou uma interrupção do servidor. Essas condições devem ser confirmadas a partir do status, dos cabeçalhos e dos logs reais, em vez de serem inferidas a partir do 304.

Como corrigir

Para visitantes

1. Deixe o navegador tratar a resposta primeiro. Um navegador normal deve usar sua cópia armazenada em cache ao receber 304. Se a página estiver correta, normalmente nenhuma ação será necessária.
2. Verifique a URL exata. Confirme o hostname, o caminho, a query string e o protocolo. URLs diferentes podem ter representações armazenadas em cache separadas.
3. Tente novamente uma vez se o conteúdo exibido estiver desatualizado ou incompleto. Use os controles normais de recarregamento do navegador, em vez de atualizar repetidamente.
4. Compare com outro cliente somente quando for útil. Se um navegador exibir conteúdo desatualizado e outro não, registre a URL afetada, o horário aproximado e o comportamento do cliente para o responsável pelo site.
5. Entre em contato com o responsável pelo site se o recurso não puder ser carregado. Informe a URL e o horário, mas não compartilhe senhas, cookies, cabeçalhos de autorização ou outros dados privados.

Para desenvolvedores e responsáveis pelo site

1. Capture o contexto completo da solicitação e da resposta. Registre o método HTTP, a URL completa incluindo os parâmetros de consulta relevantes, o status, os validadores da solicitação, os validadores da resposta, Cache-Control, Vary e quaisquer cabeçalhos de proxy ou CDN. Remova credenciais e dados pessoais antes de compartilhar.
2. Confirme que a solicitação é condicional. Procure If-None-Match ou If-Modified-Since. Um 304 normalmente é significativo quando o cliente tem uma representação armazenada em cache para validar.
3. Verifique a camada que produz a resposta. Determine se o 304 veio do navegador, de um proxy local ou compartilhado, CDN, proxy reverso, servidor web ou aplicação. Quando disponível, use o identificador da solicitação e o horário dessa camada.
4. Compare os validadores com o recurso. Verifique se ETag ou Last-Modified representa corretamente a representação solicitada e se a negociação de conteúdo é coberta por uma política Vary apropriada, quando relevante.
5. Teste uma solicitação não condicional quando precisar do corpo atual. Use um cliente de diagnóstico autorizado ou omita temporariamente os cabeçalhos de solicitação condicionais em um teste controlado. Essa é uma comparação somente de leitura, mas siga os controles normais de acesso do serviço e evite enviar cabeçalhos confidenciais a ferramentas não confiáveis.
6. Revise alterações recentes no cache e nas implantações. Verifique releases da aplicação, geração de assets, regras de proxy ou CDN, compactação e negociação de conteúdo, roteamento e comportamento de invalidação do cache. Concentre-se nas alterações que afetam a rota específica, em vez de mudar imediatamente as configurações globais.
7. Aplique a correção segura mais restrita. Corrija o validador, a política de cache ou a regra do intermediário somente depois de identificar a inconsistência. Evite desativar o cache globalmente quando apenas uma rota ou representação for afetada.
8. Teste novamente o mesmo caminho da solicitação. Teste uma solicitação condicional e uma solicitação nova e, em seguida, confirme que as rotas e os métodos de solicitação relacionados continuam retornando os status e as representações esperados.

Prevenção e como verificar a correção

• Trate o 304 como um resultado esperado da validação de cache no monitoramento, a menos que o cliente não consiga usar sua representação armazenada em cache.
• Teste rotas importantes com solicitações comuns e condicionais após as implantações.
• Mantenha o comportamento de ETag, Last-Modified, Cache-Control e Vary intencional e documentado.
• Garanta que os validadores de cache sejam alterados quando a representação servida mudar, incluindo variantes relevantes de negociação de conteúdo.
• Monitore as taxas de status por rota e por camada de cache para que um padrão inesperado de 304 seja distinguível do tráfego normal de navegadores.
• Mantenha, quando possível, a configuração de proxy, CDN, servidor web e aplicação sob controle de versão.
• Retenha identificadores de solicitação e horários sanitizados por tempo suficiente para associar um relatório à camada que gerou a resposta.

Perguntas frequentes