Isto é uma lista de códigos de estado de resposta do Protocolo de Transferência de Hipertexto (HTTP). Os códigos de estado são emitidos por um servidor como resposta a um pedido de um cliente feito ao servidor. Inclui os códigos padrões de internet da IETF, outras especificações e alguns ​​códigos adicionais usados.

O primeiro dígito do código de status indica uma das cinco classes de resposta. O mínimo necessário para um cliente HTTP é que ele reconheça essas cinco classes. Microsoft IIS pode usar sub-códigos decimais adicionais, específicos para fornecer mais informações, mas estes não estão listados aqui. As frases utilizadas são os exemplos padrão, mas qualquer alternativa humana legível pode ser fornecida. Salvo disposição em contrário, o código de status é parte do padrão HTTP/1.1.

1xx Informativa Indica que a requisição foi recebida e entendida. Essa resposta é despachada provisoriamente, enquanto o processamento da requisição continua. Serve para alertar ao cliente que espere pela resposta final. A mensagem constitui-se apenas do status-line e cabeçalhos opcionais; e é encerrada por uma linha vazia, dado que a versão HTTP/1.0 não definiu nenhum código de status 1xx, os servidores não devem enviar uma resposta 1xx para um cliente HTTP/1.0, exceto sob condições experimentais.

100 Continuar Isso significa que o servidor recebeu os cabeçalhos da solicitação; e que o cliente deve proceder para enviar o corpo do pedido (no caso de haver um pedido, um corpo deve ser enviado, por exemplo, um POST pedido). Se este corpo é grande, enviá-lo a um servidor, se o pedido já foi rejeitado, com base em cabeçalhos inadequados, é ineficiente. Para ter um cheque do servidor se o pedido pode ser aceito com base no pedido de cabeçalhos sozinho, o cliente deve enviar: Esperar 100-continue, como um cabeçalho no seu pedido inicial e verificar se a "100 Continuar", código de status, é recebido em resposta antes de permanente (ou receber "417 Falha" na expectativa e não continuar).

101 Mudando protocolos Isso significa que o solicitante pediu ao servidor para mudar os protocolos; e este está reconhecendo que irá fazê-lo.

102 Processamento (WebDAV) (RFC 2518) Como uma solicitação WebDAV pode conter muitos sub-pedidos que envolvam operações de arquivo, pode demorar muito tempo para concluir o pedido. Este código indica que o servidor recebeu e está processando o pedido, mas ainda nenhuma resposta está disponível. Isso impede que o cliente ultrapasse o tempo limite e assuma que a requisição tenha sido perdida.

122 Pedido-URI muito longo Este é um padrão IE7. Somente código não significa que o URI é mais do que um máximo de 2083 caracteres. (Ver código 414).

2xx Sucesso Esta classe de códigos de status indica que a ação solicitada pelo cliente foi recebida, compreendida, aceita e processada com êxito.

200 OK Padrão de resposta para solicitações HTTP sucesso. A resposta real dependerá do método de solicitação usado. Em uma solicitação GET, a resposta conterá uma entidade que corresponde ao recurso solicitado. Em uma solicitação POST a resposta conterá a descrição de uma entidade, ou contendo o resultado da ação.

201 Criado O pedido foi cumprido e resultou em um novo recurso que está sendo criado.

202 Aceito O pedido foi aceito para processamento, mas o tratamento não foi concluído. O pedido poderá ou não vir a ser posto em prática, pois pode ser anulado quando o processamento ocorre realmente.

203 não-autorizado (desde HTTP/1.1) O servidor processou a solicitação com sucesso, mas está retornando informações que podem ser de outra fonte.

204 Nenhum conteúdo O servidor processou a solicitação com sucesso, mas não é necessária nenhuma resposta.

205 Reset O servidor processou a solicitação com sucesso, mas não está retornando nenhum conteúdo. Ao contrário da 204, esta resposta exige que o solicitante redefina a exibição de documento.

206 Conteúdo parcial O servidor está entregando apenas parte do recurso devido a um "cabeçalho intervalo" enviado pelo cliente. O cabeçalho do intervalo é usado por ferramentas como wget para permitir retomada de downloads interrompidos; ou dividir um download em vários fluxos simultâneos.

207-Status Multi (WebDAV) (RFC 4918) O corpo da mensagem que se segue é um XML da mensagem e pode conter um número de códigos de resposta individual, dependendo de quantos sub-pedidos foram feitos.

3xx Redirecionamento O cliente deve tomar medidas adicionais para completar o pedido. Essa classe de código de status indica que a ação ainda precisa ser levada pelo agente de usuário, a fim de atender à solicitação. A ação necessária pode ser realizada pelo agente, sem interação com o usuário, se e somente se o método utilizado no segundo pedido é GET ou HEAD. Um agente de usuário não deve redirecionar automaticamente uma solicitação de mais de cinco vezes, uma vez que tais redirecionamentos geralmente indicam um loop infinito.

300 Múltipla escolha Indica várias opções para o recurso que o cliente pode acompanhar. É, por exemplo, usado para apresentar opções de formato diferente para o vídeo; arquivos de lista com diferentes extensões; ou desambiguação do sentido da palavra.

301 Movido Esta e todas as solicitações futuras devem ser direcionadas para o URL.

302 Encontrado Este é um exemplo de boas práticas industriais contradizendo a norma. A especificação HTTP/1.0 (RFC 1945) exigia ao cliente executar um redirecionamento temporário (a frase original que descreve o método era "Movido temporariamente"), mas os browsers populares executavam o 302 com a funcionalidade de um "303 Consulte Outros". Por isso, o HTTP/1.1 acrescentou os códigos de status 303 e 307 para distinguir entre os dois comportamentos. No entanto, a maioria das aplicações Web e os frameworks ainda usam o código de status 302 como se fosse o 303.

303 Consulte Outros A resposta a esta requisição pode ser encontrada sob outro URI usando o 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 enviar uma nova requisição GET para o URI dado.

304 Não modificado Indica que o recurso não foi modificado desde o último pedido. Normalmente, o cliente fornece um cabeçalho HTTP do tipo If-Modified-Since ou If-None-Match para proporcionar um tempo contra o qual para comparar. Usar este cabeçalho poupa largura de banda e reprocessamento no servidor e cliente, uma vez que apenas os dados do cabeçalho são enviados e recebidos; e são utilizados os dados armazenados em cache.

305 Use Proxy (desde HTTP/1.1) Muitos clientes HTTP (como o Mozilla e Internet Explorer) podem não tratar corretamente as respostas com este código de status, principalmente por razões de segurança.

306 Proxy Switch Mudança de proxy. Deixou de ser usado.

307 Redirecionamento temporário (desde HTTP/1.1) Nesta ocasião, o pedido deve ser repetido com outro URI, mas futuras solicitações ainda pode usar o URI original. Em contraste com o 303, o método de pedido não deve ser mudado quanto à reedição do pedido original. Por exemplo, uma solicitação POST deve ser repetida com outro pedido POST.

308 Redirecionamento permanente (RFC 7538) Indica que o recurso foi movido para um novo URI permanente e todas as requisições futuras devem usar um dos URIs retornados. Os códigos 307 e 308 são similares ao comportamento dos códigos 302 e 301, mas não permitem que o método HTTP seja modificado.

4xx Erro de cliente A classe 4xx de código de status é destinada para os casos em que o cliente parece ter cometido um erro. Exceto quando estiver respondendo a uma solicitação HEAD, o servidor deve incluir uma entidade que contém uma explicação sobre a situação de erro; e se é uma condição temporária ou permanente. Esses códigos de status são aplicáveis a qualquer método de solicitação. Os agentes de usuário devem exibir qualquer entidade incluída para o user. Estes são tipicamente os códigos de erro mais comuns encontrados online.

400 Requisição inválida O pedido não pôde ser entregue devido à sintaxe incorreta.

401 Não autorizado Semelhante ao 403 Proibido, mais especificamente para o uso quando a autenticação é possível, mas não conseguiu ou ainda não foram fornecidos. A resposta deve incluir um cabeçalho do campo www-authenticate contendo um desafio aplicável ao recurso solicitado. Veja autenticação de acesso Basic e Digest.

402 Pagamento necessário Reservado para uso futuro. A intenção original era que esse código pudesse ser usado como parte de alguma forma de dinheiro digital ou esquema de micro pagamento, mas isso não aconteceu; e esse código não é usado normalmente.

403 Proibido O pedido é reconhecido pelo servidor, mas este recusa-se a executá-lo. Ao contrário da resposta "401 Não Autorizado", aqui a autenticação não fará diferença e o pedido não deve ser requisitado novamente.

404 Não encontrado O recurso requisitado não foi encontrado, mas pode ser disponibilizado novamente no futuro. As solicitações subsequentes pelo cliente são permitidas.

405 Método não permitido Foi feita uma solicitação de um recurso usando um método de pedido que não é compatível com esse recurso, por exemplo, usando GET em um formulário, que exige que os dados sejam apresentados via POST, PUT; ou usados em um recurso somente de leitura.

406 Não Aceitável O recurso solicitado é apenas capaz de gerar conteúdos não aceitáveis ​​de acordo com os cabeçalhos Accept enviados na solicitação.

407 Autenticação de proxy necessária O acesso está vinculado a um túnel de proxy e deve ser autenticado por meio de credenciais. Este vínculo pode ter sido configurado pelos administradores do conteúdo ao qual o acesso foi solicitado pelo usuário; ou pelos administradoras da rede a qual o usuário está conectado. Este último exige a autenticação para acesso a todos os conteúdos listados pelos administradores da rede.

408 Tempo de requisição esgotou (Timeout) O servidor sofreu timeout ao aguardar a solicitação. De acordo com as especificações HTTP W3: "O cliente não apresentou um pedido dentro do tempo que o servidor estava preparado para esperar. O cliente PODE repetir o pedido sem modificações a qualquer momento mais tarde."

409 Conflito geral Indica que a solicitação não pôde ser processada por causa do conflito no pedido, como um conflito de edição.

410 Gone Indica que o recurso solicitado não está mais disponível; e também não estará novamente. Isto deve ser usado quando um recurso foi intencionalmente removido e os recursos devem ser removidos. Ao receber um código de estado 410, o cliente não deverá solicitar o recurso novamente no futuro. Clientes como motores de busca devem remover o recurso de seus índices. A maioria dos casos de uso não necessitam de clientes e motores de busca para purgar o recurso, e um "404 Not Found" pode ser utilizado.

411 Comprimento necessário O pedido não especifica o comprimento do seu conteúdo, o que é exigido pelo recurso solicitado.

412 Pré-condição falhou O servidor não cumpre uma das condições que o solicitante coloca na solicitação.

413 Entidade de solicitação muito grande A solicitação é maior do que o servidor está disposto ou capaz de processar.

414 Pedido-URI Too Long O URI fornecido foi muito longo para ser processado pelo servidor.

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

416 Solicitação de Faixa Não Satisfatória O cliente solicitou uma parte do arquivo, mas o servidor não pode fornecer essa parte. Por exemplo, se o cliente pediu uma parte do arquivo que está para além do final deste.

417 Falha na expectativa O servidor não pode cumprir as exigências do campo de cabeçalho "Espere-pedido".

418 Eu sou um bule de chá