Referência de Códigos de Status HTTP grátis

Usado para solicitações com Expect: 100-continue. O servidor reconhece que está disposto a receber o corpo antes que o cliente o envie. Raramente visto em aplicações web modernas.

Mais comumente usado para atualizações WebSocket — o cliente solicita Upgrade: websocket e o servidor responde 101 para alternar.

Uma resposta provisória WebDAV enviada para evitar timeouts de cliente durante operações demoradas. Descontinuado — servidores modernos não devem enviá-lo.

Permite que servidores enviem cabeçalhos Link (preload/preconnect) enquanto a resposta final ainda está sendo preparada, para que os navegadores possam começar a buscar ativos críticos mais cedo.

A resposta de sucesso padrão. O significado depende do método HTTP: GET → recurso retornado, POST/PUT → ação concluída.

Comum após um POST. A resposta deve incluir um cabeçalho Location apontando para a URL do novo recurso.

Para operações assíncronas — o servidor está enfileirando o trabalho. O cliente deve pesquisar um endpoint de status ou verificar mais tarde.

A solicitação foi bem-sucedida, mas um intermediário (como um proxy de cache ou transformação) alterou o payload do servidor de origem — por exemplo, recomprimindo imagens. Raro na prática.

Frequentemente usado para operações DELETE ou atualizações PUT que não precisam retornar um corpo. O cliente não deve sair da página atual.

Como 204, nenhum corpo é retornado — mas o cliente também é instruído a redefinir o formulário ou a visualização que produziu a solicitação (ex. limpar os campos do formulário para a próxima entrada).

Resposta a uma solicitação Range. Usado por players de vídeo e gerenciadores de download para retomar downloads interrompidos ou transmitir arquivos grandes.

WebDAV: um corpo XML relata o resultado de várias sub-operações independentemente — ex. um deslocamento em lote onde alguns itens tiveram sucesso e outros falharam.

WebDAV: usado dentro de respostas 207 Multi-Status para evitar listar repetidamente membros da mesma coleção quando vinculações criam loops.

Codificação delta: o servidor retorna um diff em relação a uma versão anterior em vez do recurso completo, economizando largura de banda. Muito raramente implementado.

O servidor oferece várias opções (ex. diferentes formatos ou idiomas) e o cliente deve escolher uma. Raramente usado, pois a negociação de conteúdo automática geralmente trata disso.

Use para alterações permanentes de URL — mecanismos de busca atualizarão seu índice. A autoridade de SEO é transferida para a nova URL.

Indica que o redirecionamento não é permanente. O cache é menos agressivo que 301. Use para coisas como 'login obrigatório, redirecionando para /login'.

Usado após envios POST — a resposta diz 'seu POST funcionou, veja esta URL GET para o resultado'. Os navegadores sempre obterão a nova URL.

Resposta a uma solicitação condicional (com cabeçalhos If-None-Match ou If-Modified-Since). Economiza largura de banda — nenhum corpo é retornado.

Se o original era POST, o redirecionamento também usa POST. Alternativa moderna para 302 quando a preservação do método é importante.

Substituição moderna para 301 quando você deseja que solicitações POST permaneçam POST após o redirecionamento.

Causas comuns: JSON malformado no corpo, parâmetros de consulta inválidos ou campos obrigatórios ausentes. Verifique o corpo da solicitação e os cabeçalhos.

O cliente deve incluir credenciais de autenticação (cabeçalho Authorization, cookie, token). 'Não autorizado' é um nome impróprio — na verdade significa 'não autenticado'.

Originalmente foi destinado a pagamentos digitais. Uso moderno: às vezes APIs retornam 402 quando um usuário excedeu sua cota paga.

Diferente de 401 — o usuário ESTÁ conectado, mas sua conta não tem permissão para este recurso. Verifique a lógica de papel/permissões.

A URL está errada, o recurso foi deletado ou nunca existiu. Servidores às vezes retornam 404 para ocultar que um 403 seria mais preciso.

Por exemplo, uma solicitação GET para um endpoint que aceita apenas POST. A resposta deve incluir um cabeçalho Allow listando os métodos válidos.

O cliente solicitou um tipo de conteúdo, idioma ou codificação (via Accept, Accept-Language, Accept-Encoding) que o servidor não pode satisfazer. Muitos servidores ignoram a negociação estrita e retornam um padrão.

Como 401, mas emitido por um proxy: o cliente deve enviar credenciais Proxy-Authorization. Visto em redes corporativas com proxies autenticadores.

O cliente demorou muito para enviar o corpo da solicitação ou manteve a conexão ociosa. Tente a solicitação novamente.

Normalmente retornado para conflitos de edição simultânea ou criação de recursos duplicados (por exemplo, criar um usuário com um e-mail que já existe).

Mais forte que 404 — o servidor sabe explicitamente que o recurso EXISTIU mas foi removido permanentemente. Os mecanismos de pesquisa removerão do índice.

A solicitação foi rejeitada porque lhe faltava um cabeçalho Content-Length e o servidor recusa corpos de tamanho desconhecido. Adicione o cabeçalho e tente novamente.

Retornado quando cabeçalhos condicionais como If-Match ou If-Unmodified-Since falham — normalmente bloqueio otimista: alguém alterou o recurso desde sua versão. Busque novamente e tente outra vez.

Comum ao fazer upload de arquivos grandes. A configuração do servidor (nginx, apache) define um tamanho máximo de corpo. Verifique a configuração do servidor.

Geralmente causado por strings de consulta muito longas (por exemplo, codificar dados em um GET). Mude para um corpo POST ou aumente o limite do servidor se você o controlar.

Por exemplo, enviar application/xml para um servidor que só aceita application/json. Configure o cabeçalho Content-Type corretamente.

O cabeçalho Range pede uma parte que o arquivo não possui — por exemplo, retomar um download após o final do arquivo. A resposta deve incluir Content-Range com o tamanho real.

Enviado quando o servidor não suporta Expect: 100-continue. Alguns clientes enviam este cabeçalho por padrão em POSTs grandes; desativar geralmente resolve o erro.

Uma brincadeira de Primeiro de Abril de 1998 (RFC 2324). Algumas APIs reais usam para brincadeiras ou para marcar endpoints descontinuados. Não para uso em produção.

Comum com reutilização de conexão HTTP/2: a solicitação atingiu um servidor que não está configurado para o nome de host de destino. O cliente deve tentar novamente em uma nova conexão.

Por exemplo, JSON foi analisado corretamente mas um campo obrigatório estava faltando, ou um valor de campo estava fora do intervalo. Comum em respostas de validação de API REST.

WebDAV: o recurso de origem ou destino está bloqueado por outro cliente, portanto a operação não pode prosseguir. Aguarde o desbloqueio ou quebre-o com o token apropriado.

WebDAV: em uma cadeia de operações dependentes, uma ação anterior falhou, então esta não foi executada. Procure pela falha anterior pela causa raiz.

Relacionado a TLS 1.3 0-RTT (dados antecipados): o servidor não corre o risco de processar uma solicitação possivelmente reproduzida. O cliente deve tentar novamente após a conclusão do handshake.

O servidor se recusa a servir a solicitação sobre o protocolo atual mas o fará após uma atualização — a resposta inclui um cabeçalho Upgrade nomeando o protocolo necessário.

O servidor exige cabeçalhos condicionais (como If-Match) para evitar conflitos de atualização perdida. Busque o recurso, capture seu ETag e reenvie com If-Match.

Desacelere. A resposta deve incluir um cabeçalho Retry-After indicando quando tentar novamente. Comum com APIs que têm quotas de solicitações.

Ou um cabeçalho ou o tamanho total do cabeçalho excede o limite — mais frequentemente causado por cookies enormes. Limpe cookies ou reduza o que seu aplicativo armazena neles.

O recurso está bloqueado por razões legais — censura, ordens judiciais ou regulamentos regionais. O número é uma referência ao romance Fahrenheit 451.

Um catch-all genérico para erros do lado do servidor. Verifique os logs do servidor pela causa real: exceção não tratada, erro de banco de dados, etc.

Por exemplo, o servidor não reconhece o método HTTP. Raro na prática — mais frequentemente você verá 405.

Comum em arquiteturas de microsserviços. Seu balanceador de carga ou proxy reverso recebeu uma resposta malformada do serviço backend.

Ou está em manutenção ou sobrecarregado. A resposta deve incluir um cabeçalho Retry-After. Frequentemente retornado durante implantações.

O serviço backend não respondeu rápido o suficiente. Verifique a saúde do serviço upstream e as configurações de tempo limite.

A versão principal de HTTP da solicitação não é suportada pelo servidor. Quase nunca visto com clientes modernos.

Negociação de conteúdo transparente terminou em um loop: a variante escolhida está configurada para negociar. Indica um erro de configuração do servidor.

WebDAV-específica em origem mas às vezes usada por servidores gerais. Significa que o servidor não consegue salvar a solicitação devido a restrições de armazenamento.

WebDAV: processando uma solicitação Depth: infinity entrou em um loop (por exemplo, ligações circulares). A operação foi terminada.

Do obsoleto HTTP Extension Framework: o servidor precisa de mais informações antes de poder cumprir a solicitação. Efetivamente não utilizado na web moderna.

Usado por portais cativos (WiFi de hotel/aeroporto) para indicar que o usuário deve fazer login na rede antes de acessar sites externos.