Lista de Códigos de Status HTTP

O cliente deve continuar com sua solicitação. Esta resposta provisória indica que tudo até agora está OK e que o cliente deve continuar com a solicitação ou ignorá-la se já estiver concluída.

O servidor está mudando de protocolos conforme solicitado pelo cliente (por exemplo, através de um cabeçalho de solicitação Upgrade).

WebDAV; O servidor recebeu e está processando a solicitação, mas nenhuma resposta está disponível ainda. Isso evita que o cliente expire e presuma que a solicitação foi perdida.

O servidor está enviando alguns cabeçalhos antes da mensagem HTTP final. Usado para permitir que o cliente comece a pré-carregar recursos enquanto o servidor ainda está preparando uma resposta.

A solicitação foi bem-sucedida. O significado do sucesso depende do método HTTP: GET: O recurso foi buscado e é transmitido no corpo da mensagem. HEAD: Os cabeçalhos da entidade estão no corpo da mensagem. PUT ou POST: O recurso que descreve o resultado da ação é transmitido no corpo da mensagem. TRACE: O corpo da mensagem contém a mensagem de solicitação conforme recebida pelo servidor.

A solicitação foi atendida e resultou na criação de um ou mais novos recursos. O novo recurso é efetivamente criado antes que esta resposta seja enviada de volta e o novo recurso é retornado no corpo da mensagem, seu URI ou uma referência URI a ele.

A solicitação foi aceita para processamento, mas o processamento não foi concluído. A solicitação pode ou não ser eventualmente atendida, pois pode ser desautorizada quando o processamento realmente ocorrer.

A metainformação retornada é de uma cópia local ou de terceiros, não do servidor de origem, e pode estar incorreta. O servidor de origem não validou a informação.

O servidor processou com sucesso a solicitação e não está retornando nenhum conteúdo. Útil para solicitações onde nenhum novo documento deve ser exibido ao usuário (por exemplo, quando um formulário 'salvar e continuar editando' é enviado).

O servidor processou com sucesso a solicitação, pede que o solicitante redefina a visualização do documento e não está retornando nenhum conteúdo. Por exemplo, após o envio de um formulário, para limpar o formulário para nova entrada.

O servidor está entregando apenas parte do recurso (serviço de bytes) devido a um cabeçalho de intervalo enviado pelo cliente. O cabeçalho de intervalo é usado por clientes HTTP para permitir a retomada de downloads interrompidos ou dividir um download em vários fluxos simultâneos.

WebDAV; Fornece status para múltiplas operações independentes. O corpo da mensagem que se segue é uma mensagem XML e pode conter vários códigos de resposta separados, dependendo de quantas sub-solicitações foram feitas.

WebDAV; Os membros de uma ligação DAV já foram enumerados em uma resposta anterior a esta solicitação e não estão sendo incluídos novamente.

O servidor atendeu a uma solicitação GET para o recurso, e a resposta é uma representação do resultado de uma ou mais manipulações de instância aplicadas à instância atual.

Indica múltiplas opções para o recurso a partir do qual o cliente pode escolher. O servidor pode incluir um campo de cabeçalho 'Location' contendo um URI preferencial para o cliente usar.

Esta e todas as futuras solicitações devem ser direcionadas para o URI fornecido. Os motores de busca atualizarão seus links para o recurso (em 'linguagem SEO', diz-se que o 'link-juice' é enviado para o novo URL).

Informa ao cliente para olhar (navegar para) outro URL. O 302 foi substituído por 303 e 307 para este tipo de redirecionamento, embora ainda seja comumente usado. Os motores de busca não atualizam seus links para o recurso.

A resposta à solicitação pode ser encontrada sob outro URI usando um método GET. Quando recebido em resposta a um POST (ou PUT/DELETE), o cliente deve presumir que o servidor recebeu os dados e deve emitir uma nova solicitação GET para o URI fornecido.

Indica que o recurso não foi modificado desde a versão especificada pelos cabeçalhos da solicitação (If-Modified-Since ou If-None-Match). Nesse caso, não há necessidade de retransmitir o recurso, pois o cliente ainda tem uma cópia baixada anteriormente.

O recurso solicitado está disponível apenas através de um proxy, cujo endereço é fornecido na resposta. Muitos clientes HTTP (como Mozilla e Internet Explorer) não lidam corretamente com respostas com este código de status, principalmente por razões de segurança.

A solicitação deve ser repetida com outro URI; no entanto, solicitações futuras ainda devem usar o URI original. Em contraste com a forma como o 302 foi historicamente implementado, o método de solicitação não pode ser alterado ao reemitir a solicitação original.

A solicitação e todas as futuras solicitações devem ser repetidas usando outro URI. 307 e 308 são paralelos aos comportamentos de 302 e 301, mas não permitem que o método HTTP mude. Assim, por exemplo, o envio de um formulário para um recurso permanentemente redirecionado pode continuar sem problemas.

O servidor não pode ou não irá processar a solicitação devido a um aparente erro do cliente (por exemplo, sintaxe de solicitação malformada, tamanho muito grande, enquadramento de mensagem de solicitação inválido ou roteamento de solicitação enganoso).

A autenticação é necessária e falhou ou ainda não foi fornecida. A resposta deve incluir um campo de cabeçalho WWW-Authenticate contendo um desafio aplicável ao recurso solicitado. 'Não Autorizado' significa que o cliente deve se autenticar para obter a resposta solicitada.

Reservado para uso futuro. A intenção original era que este código pudesse ser usado como parte de alguma forma de dinheiro digital ou esquema de micropagamento, mas isso não aconteceu, e este código não é amplamente utilizado.

A solicitação era válida, mas o servidor está recusando a ação. O usuário pode não ter as permissões necessárias para um recurso, ou pode precisar de algum tipo de conta. Diferente de 401, a autenticação não ajudará e a solicitação não deve ser repetida.

O recurso solicitado não pôde ser encontrado, mas pode estar disponível no futuro. Solicitações subsequentes pelo cliente são permitidas. Este é um erro comum encontrado na web.

Um método de solicitação não é suportado para o recurso solicitado; por exemplo, uma solicitação GET em um formulário que requer que os dados sejam apresentados via POST, ou uma solicitação PUT em um recurso somente leitura.

O recurso solicitado é capaz de gerar apenas conteúdo não aceitável de acordo com os cabeçalhos Accept enviados na solicitação. Veja Negociação de conteúdo.

O cliente deve primeiro se autenticar com o proxy. O proxy deve enviar um campo de cabeçalho Proxy-Authenticate contendo um desafio aplicável ao proxy para o recurso solicitado.

O servidor expirou esperando pela solicitação. De acordo com as especificações HTTP: 'O cliente não produziu uma solicitação dentro do tempo que o servidor estava preparado para esperar. O cliente PODE repetir a solicitação sem modificações em qualquer momento posterior.'

Indica que a solicitação não pôde ser processada devido a um conflito no estado atual do recurso, como um conflito de edição entre múltiplas atualizações simultâneas.

Indica que o recurso solicitado não está mais disponível e não estará disponível novamente. Isso deve ser usado quando um recurso foi intencionalmente removido e o recurso deve ser purgado. Os motores de busca devem remover o recurso de seus índices.

A solicitação não especificou o comprimento de seu conteúdo, que é exigido pelo recurso solicitado. O servidor não aceitará a solicitação sem um cabeçalho Content-Length válido.

O servidor não atende a uma das pré-condições que o solicitante colocou nos campos de cabeçalho da solicitação. Este código de resposta permite que o cliente coloque pré-condições no estado atual do recurso e, assim, evite que o método de solicitação seja aplicado se a solicitação for em um recurso inesperado.

A solicitação é maior do que o servidor está disposto ou capaz de processar. Anteriormente chamado de 'Entidade de Solicitação Muito Grande'. Isso pode ser uma condição temporária que o servidor pode aliviar pedindo ao cliente para esperar e tentar novamente.

O URI fornecido era muito longo para o servidor processar. Frequentemente, o resultado de muitos dados sendo codificados como uma string de consulta de uma solicitação GET, caso em que deve ser convertida para uma solicitação POST.

A entidade da solicitação tem um tipo de mídia que o servidor ou recurso não suporta. Por exemplo, o cliente carrega uma imagem como image/svg+xml, mas o servidor requer que as imagens usem um formato diferente.

O cliente pediu uma porção do arquivo (serviço de bytes), mas o servidor não pode fornecer essa porção. Por exemplo, se o cliente pediu uma parte do arquivo que está além do final do arquivo.

O servidor não pode atender aos requisitos do campo de cabeçalho de solicitação Expect. O servidor não está disposto ou é incapaz de cumprir a expectativa dada no campo de cabeçalho Expect.

Este código foi definido em 1998 como uma das piadas tradicionais de Primeiro de Abril da IETF no RFC 2324, Protocolo de Controle de Bule de Café Hipertexto, e não se espera que seja implementado por servidores HTTP reais. No entanto, existem implementações conhecidas.

A solicitação foi direcionada a um servidor que não é capaz de produzir uma resposta. Isso pode ser enviado por um servidor que não está configurado para produzir respostas para a combinação de esquema e autoridade incluídos no URI da solicitação.

WebDAV; A solicitação estava bem formada, mas não pôde ser seguida devido a erros semânticos. O servidor entende o tipo de conteúdo da entidade da solicitação, e a sintaxe da entidade da solicitação está correta, mas não foi capaz de processar as instruções contidas.

WebDAV; O recurso que está sendo acessado está bloqueado. Isso significa que o recurso de origem ou destino de um método está bloqueado.

WebDAV; A solicitação falhou porque dependia de outra solicitação e essa solicitação falhou (por exemplo, um PROPPATCH).

Indica que o servidor não está disposto a arriscar processar uma solicitação que pode ser repetida, o que cria o potencial para um ataque de repetição.

O cliente deve mudar para um protocolo diferente, como TLS/1.0, fornecido no campo de cabeçalho Upgrade. O servidor está se recusando a executar a solicitação usando o protocolo atual, mas pode estar disposto a fazê-lo depois que o cliente atualizar para um protocolo diferente.

O servidor de origem requer que a solicitação seja condicional. Destinado a prevenir o problema da 'atualização perdida', onde um cliente GET o estado de um recurso, modifica-o e o envia de volta (PUT) ao servidor, enquanto um terceiro modificou o estado no servidor, levando a um conflito.

O usuário enviou muitas solicitações em um determinado período de tempo ('limitação de taxa'). As representações de resposta DEVEM incluir detalhes explicando a condição e PODEM incluir um cabeçalho Retry-After indicando quanto tempo esperar antes de fazer uma nova solicitação.

O servidor não está disposto a processar a solicitação porque seus campos de cabeçalho são muito grandes. A solicitação PODE ser reenviada após reduzir o tamanho dos campos de cabeçalho da solicitação.

O servidor está negando acesso ao recurso como consequência de uma demanda legal. Isso pode ser um site bloqueado por um governo ou um aviso de remoção de direitos autorais.

Uma mensagem de erro genérica, dada quando uma condição inesperada foi encontrada e nenhuma mensagem mais específica é adequada. O servidor encontrou uma condição inesperada que o impediu de atender à solicitação.

O servidor não reconhece o método de solicitação ou não tem a capacidade de atender à solicitação. Geralmente, isso implica disponibilidade futura (por exemplo, um novo recurso de uma API de serviço da web).

O servidor estava atuando como um gateway ou proxy e recebeu uma resposta inválida do servidor upstream. Isso geralmente significa que um servidor upstream está inativo ou não está respondendo corretamente.

O servidor está atualmente indisponível (porque está sobrecarregado ou em manutenção). Geralmente, este é um estado temporário. Um campo de cabeçalho Retry-After PODE ser incluído para sugerir um tempo adequado para o cliente esperar antes de tentar novamente a solicitação.

O servidor estava atuando como um gateway ou proxy e não recebeu uma resposta em tempo hábil do servidor upstream. Isso geralmente significa que um servidor upstream está lento ou não está respondendo.

O servidor não suporta a versão do protocolo HTTP usada na solicitação. O servidor não está disposto a concluir a solicitação usando a mesma versão principal que o cliente.

A negociação de conteúdo transparente para a solicitação resulta em uma referência circular. O servidor tem um erro de configuração interno: o recurso variante escolhido está configurado para se envolver na negociação de conteúdo transparente, e, portanto, não é um ponto final adequado no processo de negociação.

WebDAV; O servidor não consegue armazenar a representação necessária para concluir a solicitação. O método não pôde ser executado no recurso porque o servidor não consegue armazenar a representação necessária para concluir com sucesso a solicitação.

WebDAV; O servidor detectou um loop infinito ao processar a solicitação (enviado em vez de 208 Já Reportado). Indica que o servidor encerrou uma operação porque encontrou um loop infinito ao processar uma solicitação com 'Depth: infinity'.

Extensões adicionais à solicitação são necessárias para que o servidor a atenda. A política para acessar o recurso não foi atendida na solicitação.

O cliente precisa se autenticar para obter acesso à rede. Destinado ao uso por proxies de interceptação usados para controlar o acesso à rede (por exemplo, 'portais cativos' usados para exigir concordância com os Termos de Serviço antes de conceder acesso total à Internet através de um hotspot Wi-Fi).