Código de status HTTP: O guia definitivo

Códigos de status HTTP são números de três dígitos retornados pelos servidores para indicar o status de um recurso solicitado.

Eles indicam se uma solicitação específica foi concluída com sucesso e, em caso negativo, o motivo para tal.

Fazem parte do protocolo HTTP e normalmente são incluídos na resposta enviada de volta ao cliente pelo servidor.

Existem cinco classes de códigos de status HTTP:

1xx (Informativo): A solicitação foi recebida, continuando o processo;
2xx (Bem-sucedido): A solicitação foi recebida, compreendida e aceita com sucesso;
3xx (Redirecionamento): Outras ações precisam ser tomadas para concluir a solicitação;
4xx (Erro do cliente): A solicitação contém sintaxe incorreta ou não pode ser atendida pelo servidor;
5xx (erro do servidor): o servidor falhou ao atender a uma solicitação válida.

Essas classes de códigos foram estabelecidas pela RFC 7231.

Menu de navegação

O que é a RFC 7231?

A RFC 7231 – Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content é uma norma técnica publicada pela Internet Engineering Task Force (IETF) que define os códigos de status HTTP e as regras para sua utilização.

Ela é uma atualização da especificação anterior, a RFC 2616, e foi publicada em junho de 2014.

Esses códigos de status incluem os códigos de sucesso, como 200 (OK) e 201 (Created), códigos de redirecionamento, como 301 (Moved Permanently) e 307 (Temporary Redirect), e códigos de erro, como 400 (Bad Request) e 500 (Internal Server Error).

Além dos códigos de status, a RFC 7231 fornece regras para a utilização de métodos HTTP, cabeçalhos HTTP, entidades de mensagem e outros aspectos da comunicação HTTP.

Ela também disponibiliza informações sobre como os clientes e os servidores devem se comportar em determinadas situações, como lidar com erros de redirecionamento e garantir a segurança da comunicação.

É importante que os desenvolvedores e clientes HTTP estejam familiarizados com a RFC 7231 e sigam as regras e recomendações nela descritas ao desenvolver e implementar aplicativos e servidores HTTP.

Seguir as normas e recomendações da RFC 7231 pode garantir que os aplicativos e servidores sejam compatíveis com outros aplicativos e servidores na Internet e funcionem de maneira previsível e confiável.

Agora vamos conhecer quais os principais tipos de códigos de status HTTP e o que eles significam:

Códigos HTTP 1xx (Informativo)

A solicitação foi recebida, continuando o processo.

100 – Continue

O código de status HTTP 100 – Continue é uma resposta informativa do servidor que indica que ele recebeu os cabeçalhos da solicitação do cliente e que o cliente pode continuar enviando o corpo da mensagem.

Este código é útil principalmente em situações em que o cliente deseja verificar se o servidor está disposto a aceitar a requisição antes de enviar todo o corpo da mensagem.

O código 100 – Continue é geralmente usado em conjunto com o cabeçalho “Expect: 100-continue” no pedido do cliente.

Quando o servidor recebe uma solicitação contendo o cabeçalho “Expect: 100-continue”, ele verifica se está disposto a aceitar a requisição com base nos cabeçalhos fornecidos (como o tamanho da mensagem, os métodos de autenticação e os cabeçalhos de controle de cache).

Se o servidor estiver disposto a aceitar a requisição, ele envia uma resposta com o código de status 100 – Continue.

Caso contrário, o servidor pode enviar um código de erro apropriado, como 413 (Payload Too Large) ou 417 (Expectation Failed), para informar o cliente que a requisição não será aceita.

O uso do código 100 – Continue pode ser benéfico em situações em que o envio do corpo da mensagem é uma operação cara em termos de tempo e recursos, como no caso de grandes uploads de arquivos.

Ao verificar a aceitação do servidor antes de enviar o corpo da mensagem, o cliente pode evitar o consumo desnecessário de largura de banda e recursos do servidor.

No entanto, vale ressaltar que nem todos os servidores suportam o cabeçalho “Expect: 100-continue” e que o uso desse recurso pode não ser adequado em todas as situações.

Além disso, a partir do HTTP/2, o recurso “Expect: 100-continue” tornou-se menos relevante, pois o protocolo introduziu o conceito de fluxos e o controle de fluxo, permitindo que os clientes enviem múltiplas requisições simultaneamente e ajustem a taxa de transferência conforme necessário.

101 – Switching Protocols (Protocolos de comutação)

O código de status HTTP 101 – Switching Protocols (Protocolos de comutação) é uma resposta informativa do servidor que indica que ele compreende e aceita a solicitação do cliente para mudar para um protocolo de comunicação diferente.

O objetivo deste código é facilitar a transição entre diferentes protocolos de comunicação em uma conexão existente, permitindo uma maior flexibilidade e eficiência na comunicação entre cliente e servidor.

Para solicitar a mudança de protocolo, o cliente deve incluir o cabeçalho “Upgrade” na solicitação, especificando o protocolo desejado e, possivelmente, também a versão.

Além disso, o cliente deve incluir o cabeçalho “Connection” com o valor “Upgrade”, para indicar que a conexão deve ser mantida após a mudança de protocolo.

Se o servidor aceitar a solicitação de mudança de protocolo, ele retornará o código de status 101 – Switching Protocols, juntamente com os cabeçalhos “Upgrade” e “Connection” na resposta.

Após o envio dessa resposta, o servidor começará a usar o novo protocolo de comunicação, conforme acordado.

Um exemplo comum do uso do código 101 – Switching Protocols é a atualização de uma conexão HTTP para o protocolo WebSocket, que permite uma comunicação bidirecional e em tempo real entre cliente e servidor.

Nesse caso, a solicitação do cliente incluirá os cabeçalhos “Upgrade: websocket” e “Connection: Upgrade”, e o servidor responderá com o código 101 – Switching Protocols, confirmando a mudança para o protocolo WebSocket.

É importante notar que a mudança de protocolo só ocorrerá se ambas as partes, cliente e servidor, concordarem com a transição.

Se o servidor não suportar o protocolo solicitado ou não desejar realizar a mudança, ele pode ignorar o cabeçalho “Upgrade” e continuar processando a solicitação usando o protocolo atual, ou retornar um código de erro apropriado, como 400 (Bad Request) ou 501 (Not Implemented).

102 – Processing (Processando)

O código de status HTTP 102 – Processing (Processando) é uma resposta informativa usada principalmente em combinação com o protocolo WebDAV (Web Distributed Authoring and Versioning), uma extensão do protocolo HTTP que permite a colaboração e a manipulação remota de recursos na web.

Este código é enviado pelo servidor para indicar que a solicitação do cliente foi recebida e está sendo processada, mas ainda não há uma resposta completa disponível.

O principal objetivo do código 102 – Processing é evitar que o cliente pense que a conexão foi perdida ou que houve algum erro, especialmente em situações em que o processamento da solicitação pode levar um tempo considerável.

Ao enviar este código, o servidor informa ao cliente que a solicitação está sendo processada e que o cliente deve continuar aguardando uma resposta final.

Em geral, o uso do código 102 – Processing é limitado a cenários específicos em que o tempo de processamento da solicitação é longo o suficiente para justificar o envio de uma resposta intermediária.

Em muitos casos, o envio deste código de status pode não ser necessário, uma vez que os clientes HTTP modernos são geralmente capazes de lidar com conexões de longa duração e tempos de espera prolongados sem a necessidade de uma resposta intermediária.

Embora o código 102 – Processing seja mais comumente usado com o protocolo WebDAV, ele também pode ser usado em outros contextos em que as solicitações HTTP podem levar um tempo significativo para serem processadas.

No entanto, o uso deste código de status não é amplamente adotado e sua implementação pode variar entre diferentes servidores e clientes HTTP.

103 – Early Hints (Dicas iniciais)

O código de status HTTP 103 – Early Hints (Dicas iniciais) é um código especial utilizado para otimizar o carregamento de páginas na web, permitindo que o servidor forneça informações antecipadamente sobre os recursos que serão necessários para exibir a página solicitada.

Essas dicas iniciais ajudam os navegadores a iniciar o download desses recursos mais rapidamente, melhorando a performance e a experiência do usuário.

Quando um servidor envia o código 103 – Early Hints, ele inclui cabeçalhos “Link” na resposta, que contêm referências aos recursos adicionais, como arquivos CSS, JavaScript ou imagens, que serão necessários para processar e renderizar a página corretamente.

Os navegadores modernos podem usar essas informações para começar a solicitar e baixar esses recursos enquanto ainda aguardam a resposta final do servidor.

Vale ressaltar que o código 103 – Early Hints não substitui a resposta final do servidor, que normalmente inclui o conteúdo da página e outros cabeçalhos relevantes.

Ele funciona como uma resposta preliminar que pode ser enviada antes da resposta completa, permitindo que o navegador inicie o download de recursos adicionais em paralelo.

O uso do código 103 – Early Hints pode ser especialmente útil em casos onde a geração da resposta final é demorada, por exemplo, quando o servidor precisa consultar bancos de dados ou realizar cálculos complexos antes de enviar o conteúdo da página.

Ao fornecer dicas iniciais, o servidor permite que o navegador otimize o tempo de carregamento da página, mesmo em situações em que a resposta completa leva um tempo considerável para ser gerada.

Códigos 2xx (Bem-sucedido)

A solicitação foi recebida, compreendida e aceita com sucesso.

200 – Ok

O código de status HTTP 200 – Ok é uma resposta padrão e bem-sucedida, indicando que a solicitação do cliente foi processada com sucesso pelo servidor e que as informações solicitadas estão disponíveis para serem enviadas de volta ao cliente.

Esse código é comumente usado em resposta a solicitações GET, POST, PUT e DELETE, bem como outros métodos HTTP, desde que a ação tenha sido executada com êxito.

Quando o servidor envia o código 200 – Ok, ele também inclui o conteúdo da resposta no corpo da mensagem, que pode variar dependendo do tipo de solicitação realizada pelo cliente.

Por exemplo, em uma solicitação GET, o corpo da resposta pode incluir o conteúdo de um documento HTML, um arquivo de imagem ou um arquivo JSON.

Em uma solicitação POST ou PUT, o corpo da resposta pode conter informações sobre o recurso recém-criado ou atualizado, como um identificador único ou um objeto JSON com os dados atualizados.

Além do conteúdo da resposta, o servidor também inclui cabeçalhos HTTP relevantes para fornecer informações adicionais ao cliente, como o tipo de conteúdo (“Content-Type”), a data de modificação do recurso (“Last-Modified”) ou informações de cache (“Cache-Control”).

O código 200 – Ok é fundamental para a comunicação entre clientes e servidores na web, pois é o indicativo mais básico e comum de que uma solicitação foi processada corretamente.

Em casos onde o servidor não consegue processar a solicitação ou quando ocorre algum erro, outros códigos de status são usados para informar ao cliente sobre a situação e a natureza do problema encontrado.

201 – Created (Criado)

O código de status HTTP 201 – Created (Criado) é uma resposta bem-sucedida, indicando que a solicitação do cliente resultou na criação de um novo recurso no servidor.

Esse código é comumente utilizado em resposta a solicitações POST, que geralmente envolvem a criação de novos recursos, como a adição de um item em um banco de dados ou o upload de um arquivo para um servidor.

Quando o servidor envia o código 201 – Created, ele também inclui informações sobre o novo recurso criado. Essas informações podem estar no corpo da resposta, como um objeto JSON contendo os detalhes do recurso, ou em cabeçalhos HTTP relevantes.

Um dos cabeçalhos mais importantes enviados junto com o código 201 é o “Location”, que contém a URI (Uniform Resource Identifier) do novo recurso. Isso permite que o cliente saiba onde encontrar o recurso criado e, se necessário, possa acessá-lo, atualizá-lo ou excluí-lo.

Além do cabeçalho “Location”, o servidor pode incluir outros cabeçalhos relevantes na resposta, como “Content-Type” (para informar o tipo de conteúdo do recurso criado) ou “Cache-Control” (para fornecer instruções de cache ao cliente).

O código 201 – Created é uma parte importante do conjunto de códigos de status HTTP, pois informa ao cliente que a criação de um novo recurso foi bem-sucedida e fornece informações sobre a localização e as características do recurso.

Quando um recurso não pode ser criado devido a erros ou restrições, outros códigos de status, como 400 – Bad Request (Solicitação Ruim) ou 403 – Forbidden (Proibido), são usados para informar ao cliente sobre a natureza do problema encontrado.

202 – Accepted (Aceito)

O código de status HTTP 202 – Accepted (Aceito) é uma resposta bem-sucedida, que indica que a solicitação do cliente foi recebida pelo servidor, mas ainda não foi processada.

Este código é geralmente usado em situações em que o processamento da solicitação pode levar algum tempo e o servidor não pode fornecer uma resposta imediata, ou quando a solicitação está sujeita a aprovação manual ou outras verificações antes de ser processada.

Ao enviar o código 202 – Accepted, o servidor sinaliza que a solicitação foi aceita e está na fila para processamento, mas não garante que o processamento será bem-sucedido.

O servidor pode fornecer informações adicionais sobre o estado do processamento no corpo da resposta, como uma mensagem explicativa ou um objeto JSON que descreve o progresso atual.

Além disso, o servidor pode incluir cabeçalhos HTTP relevantes, como “Retry-After” (para informar ao cliente quando tentar novamente) ou “Content-Type” (para especificar o tipo de conteúdo da resposta).

O código 202 – Accepted é útil em situações onde o processamento assíncrono é necessário ou desejável, como na execução de tarefas em segundo plano, operações demoradas ou em sistemas distribuídos.

Isso permite que o cliente saiba que a solicitação foi aceita e está na fila para processamento, sem precisar aguardar a conclusão do processamento antes de receber a resposta do servidor.

Em casos onde o servidor não aceita a solicitação ou quando ocorre algum erro antes ou durante o processamento, outros códigos de status HTTP são usados para informar ao cliente sobre a natureza do problema encontrado, como 400 – Bad Request (Solicitação Ruim), 401 – Unauthorized (Não Autorizado) ou 500 – Internal Server Error (Erro Interno do Servidor).

203 – Non-Authoritative Information (Informações não autorizadas)

O código de status HTTP 203 – Non-Authoritative Information (Informações não autorizadas) é uma resposta bem-sucedida que indica que o servidor processou a solicitação e está retornando informações que são válidas, mas que foram obtidas a partir de uma fonte de terceiros e, portanto, podem não ser completamente confiáveis.

Essa resposta é usada principalmente quando o servidor atua como um proxy ou gateway e os dados retornados são provenientes de outra fonte.

Ao enviar o código 203 – Non-Authoritative Information, o servidor informa ao cliente que os dados incluídos na resposta podem ser úteis e válidos, mas não são garantidos como precisos ou atualizados.

O corpo da resposta pode conter informações como um objeto JSON, um documento XML ou qualquer outro tipo de conteúdo, dependendo do contexto e da solicitação.

O cabeçalho “Content-Type” é geralmente incluído na resposta para informar ao cliente o tipo de conteúdo da resposta.

Outros cabeçalhos relevantes também podem ser incluídos, como “Cache-Control” (para fornecer instruções de cache ao cliente) ou “ETag” (para identificar uma versão específica do recurso).

O código 203 – Non-Authoritative Information é útil em situações em que o servidor deseja fornecer informações ao cliente, mas não pode garantir sua precisão ou confiabilidade devido à natureza de terceiros dos dados.

Isso permite que o cliente tome decisões informadas sobre como usar e interpretar as informações fornecidas e possa, se necessário, buscar informações adicionais ou confirmar os dados de outra maneira.

Códigos de status HTTP alternativos, como 200 – OK ou 404 – Not Found, podem ser usados caso o servidor possa fornecer informações autorizadas e atualizadas ou se o recurso solicitado não estiver disponível, respectivamente.

204 – No Content (Sem conteúdo)

O código de status HTTP 204 – No Content (Sem conteúdo) é uma resposta bem-sucedida que indica que a solicitação do cliente foi processada corretamente, mas não há conteúdo adicional a ser enviado na resposta.

Este código é usado principalmente quando o servidor realiza uma ação que não resulta em nenhuma alteração visível para o cliente ou quando a solicitação do cliente não requer uma resposta com conteúdo.

Ao enviar o código 204 – No Content, o servidor sinaliza ao cliente que a solicitação foi processada e concluída com sucesso, mas não há dados a serem retornados no corpo da resposta.

O servidor não inclui um corpo na resposta e pode incluir apenas cabeçalhos HTTP relevantes, como “Date” (para indicar a data e hora em que a resposta foi gerada) ou “Cache-Control” (para fornecer instruções de cache ao cliente).

O código 204 – No Content é útil em situações onde a solicitação do cliente é atendida, mas não há necessidade de enviar informações adicionais na resposta.

Por exemplo, pode ser usado em resposta a solicitações DELETE (para excluir um recurso) ou PUT (para atualizar um recurso) quando o servidor processa a solicitação corretamente e não precisa enviar informações adicionais para o cliente.

Além disso, o código 204 – No Content pode ser usado em situações onde o servidor deseja sinalizar ao cliente que a solicitação foi bem-sucedida, mas não há informações relevantes a serem fornecidas na resposta. Isso permite que o cliente saiba que a solicitação foi concluída com sucesso, sem precisar processar ou exibir dados adicionais.

Em casos onde o servidor deseja fornecer informações adicionais após o processamento bem-sucedido da solicitação, outros códigos de status HTTP, como 200 – OK ou 201 – Created, podem ser usados.

205 – Reset Content (Redefinir conteúdo)

O código de status HTTP 205 – Reset Content (Redefinir conteúdo) é uma resposta bem-sucedida que indica que o servidor processou a solicitação do cliente corretamente e solicita que o cliente redefina a visualização do documento atual para o estado original.

Ao enviar o código 205 – Reset Content, o servidor informa ao cliente que a solicitação foi processada com sucesso, mas, em vez de fornecer conteúdo adicional na resposta, instrui o cliente a redefinir a representação do recurso solicitado.

Isso geralmente é usado quando um servidor deseja que o cliente limpe um formulário ou retorne a visualização do documento para o estado original após o processamento bem-sucedido de uma solicitação.

O corpo da resposta HTTP 205 – Reset Content geralmente está vazio, pois a intenção deste código é instruir o cliente a redefinir a visualização do documento e não fornecer informações adicionais.

No entanto, o servidor pode incluir cabeçalhos HTTP relevantes na resposta, como “Date” (para indicar a data e hora em que a resposta foi gerada) ou “Cache-Control” (para fornecer instruções de cache ao cliente).

O código 205 – Reset Content é útil em situações em que o servidor deseja indicar ao cliente que a solicitação foi processada com sucesso, mas que o cliente deve redefinir a visualização do recurso solicitado em vez de atualizá-lo com novos dados.

Isso pode ser especialmente útil em aplicações web com formulários que devem ser limpos após o envio bem-sucedido dos dados.

206 – Partial Content (Conteúdo parcial)

O código de status 206 – Partial Content (Conteúdo parcial) é uma resposta bem-sucedida emitida pelo servidor quando uma solicitação de intervalo de bytes é atendida.

Essa resposta é enviada quando o servidor fornece apenas uma parte do recurso solicitado, em vez de todo o conteúdo. Isso geralmente ocorre quando o cliente solicita apenas uma parte específica de um arquivo ou recurso maior.

A utilização do código 206 – Partial Content é comum em casos onde o cliente deseja fazer o download de um arquivo em partes separadas ou quando deseja retomar um download interrompido anteriormente.

Nesses casos, o cliente envia uma solicitação HTTP com um cabeçalho “Range”, indicando o intervalo de bytes que deseja receber.

Por exemplo, um cliente pode solicitar os primeiros 500 bytes de um arquivo, enviando o cabeçalho “Range: bytes=0-499”. Se o servidor aceitar a solicitação, ele responderá com o código 206 – Partial Content e fornecerá apenas os 500 bytes solicitados no corpo da resposta.

O servidor também incluirá um cabeçalho “Content-Range” na resposta, especificando o intervalo de bytes fornecido e o tamanho total do recurso.

O uso do código 206 – Partial Content tem várias vantagens, incluindo:

Permite retomar downloads interrompidos: Se um download for interrompido, o cliente pode enviar uma nova solicitação com um cabeçalho “Range” apropriado, solicitando apenas a parte do arquivo que ainda não foi baixada. Isso permite que o download seja retomado sem a necessidade de baixar o arquivo inteiro novamente;
Reduz a largura de banda e o tempo de download: Ao baixar apenas as partes necessárias de um arquivo, o cliente pode economizar tempo e recursos de rede;
Streaming de mídia: O código 206 – Partial Content é frequentemente usado para fazer streaming de vídeos e áudios, permitindo que os clientes solicitem apenas as partes do arquivo necessárias para reprodução, em vez de todo o arquivo.

É importante notar que o servidor não é obrigado a atender a solicitações de intervalo e pode optar por enviar o recurso completo usando o código de status 200 – OK.

No entanto, se o servidor optar por atender a solicitação de intervalo, o código 206 – Partial Content deve ser usado para indicar que apenas parte do recurso foi fornecida na resposta.

207 – Multi-Status (WebDAV)

O código de status 207 – Multi-Status (WebDAV) é utilizado na extensão WebDAV do protocolo HTTP. WebDAV é uma abreviação de “Web Distributed Authoring and Versioning” e representa uma série de métodos e extensões que permitem a colaboração e a edição de arquivos em servidores web.

O código 207 – Multi-Status é uma resposta especial do WebDAV que encapsula várias respostas de status em um único documento XML.

Essa resposta é tipicamente usada quando uma única solicitação afeta múltiplos recursos ou quando uma solicitação retorna várias respostas de status.

Por exemplo, o WebDAV permite que os clientes solicitem informações sobre múltiplos recursos em uma única solicitação PROPFIND.

Nesse caso, o servidor responderá com um documento XML contendo o status de cada recurso solicitado.

A resposta Multi-Status (207) possui a seguinte estrutura:

A resposta começa com um cabeçalho de resposta HTTP padrão, incluindo o código de status 207 – Multi-Status;
O corpo da resposta é um documento XML que segue a especificação do WebDAV;
Dentro do documento XML, cada recurso afetado é representado por um elemento “response”;
Cada elemento “response” contém informações sobre o recurso, incluindo seu URI e um elemento “status” que fornece o código de status HTTP associado a esse recurso;
Além disso, o elemento “response” pode incluir informações adicionais, como metadados do recurso e propriedades específicas do WebDAV, dependendo do tipo de solicitação.

O principal benefício do código 207 – Multi-Status é permitir que os clientes WebDAV recebam informações detalhadas sobre vários recursos ou operações em uma única resposta, o que simplifica o processamento das informações e a comunicação entre o cliente e o servidor.

Essa abordagem também pode melhorar a eficiência, pois reduz a quantidade de solicitações e respostas individuais que precisam ser enviadas.

Entretanto, é importante ressaltar que o código 207 – Multi-Status é específico do WebDAV e não é utilizado em comunicações HTTP padrão.

Logo, esse código de status será encontrado apenas em contextos onde a extensão WebDAV é usada para gerenciar recursos em servidores web.

208 – Already Reported (Já reportado)

O código de status HTTP 208 – Already Reported (Já reportado) tem como objetivo principal evitar duplicidades na resposta a solicitações que possam envolver recursos repetidos.

Esse código de status é específico para a extensão WebDAV do protocolo HTTP e é utilizado para otimizar a comunicação entre o cliente e o servidor.

Quando o servidor recebe uma solicitação que envolve vários recursos, pode haver situações em que um mesmo recurso seja incluído mais de uma vez na resposta.

Para evitar essa duplicidade e melhorar a eficiência da comunicação, o servidor utiliza o código 208 – Already Reported.

Ao receber uma resposta contendo o código 208, o cliente entende que o servidor já forneceu informações sobre o recurso em questão em outra parte da resposta e, portanto, não é necessário processar as informações desse recurso novamente.

Diferentemente de outros códigos de status HTTP, o 208 – Already Reported não indica um erro ou sucesso na solicitação, mas sim uma otimização na resposta fornecida pelo servidor.

Essa otimização contribui para a redução do tráfego de dados e facilita o processamento das informações pelo cliente, melhorando a experiência do usuário.

226 – IM Used

O código de status HTTP 226 – IM Used indica que a resposta foi fornecida com sucesso e que o servidor está retornando uma representação do recurso solicitado em um formato diferente, como parte de uma negociação de conteúdo.

O termo “IM” se refere a “Instance Manipulation” (Manipulação de instância) e é usado para descrever a capacidade de um cliente solicitar uma representação de um recurso em um formato diferente do padrão.

Isso é feito por meio do uso de cabeçalhos específicos que indicam ao servidor as preferências de formato do cliente.

O código 226 foi introduzido na especificação HTTP/1.1 para tratar casos em que o servidor retorna uma representação de recurso em um formato diferente, sem afetar a semântica da resposta.

Isso significa que, mesmo que a representação seja diferente do padrão, ela ainda deve ser considerada como a representação do recurso solicitado.

Por exemplo, se um cliente solicita uma imagem no formato PNG, mas o servidor retorna a mesma imagem no formato JPEG em resposta a uma negociação de conteúdo bem-sucedida, o servidor pode retornar o código 226 para indicar que a imagem foi retornada com sucesso em um formato diferente.

O código 226 não é amplamente utilizado e muitas aplicações web podem não suportá-lo completamente.

No entanto, ele pode ser útil em casos específicos em que a negociação de conteúdo é necessária para fornecer uma melhor experiência do usuário, permitindo que os recursos sejam fornecidos em formatos que sejam mais compatíveis com as preferências do cliente.

3xx (Redirecionamento)

Outras ações precisam ser tomadas para concluir a solicitação.

300 – Multiple Choices (Escolhas múltiplas)

O código de status HTTP 300 – Multiple Choices indica que a resposta contém vários recursos que correspondem à solicitação do cliente.

Isso é comumente usado para lidar com situações em que um recurso tem várias representações possíveis.

Ao receber uma solicitação de um cliente, o servidor pode determinar que há várias opções disponíveis para responder à solicitação.

Em vez de escolher uma opção automaticamente, o servidor retorna o código de status 300 com uma lista de opções disponíveis para o cliente escolher. Isso permite que o cliente selecione a opção que melhor atende às suas necessidades.

As opções podem ser apresentadas ao cliente em forma de links ou de outra forma, e o cliente pode selecionar a opção que melhor se adequa às suas necessidades.

Quando o cliente seleciona uma opção, uma nova solicitação é feita ao servidor para obter a representação do recurso correspondente.

Por exemplo, se um cliente solicita um recurso em diferentes formatos, o servidor pode retornar o código de status 300 e uma lista dos formatos disponíveis, como XML, JSON ou CSV.

O cliente pode então selecionar o formato desejado e enviar uma nova solicitação ao servidor com a opção selecionada.

Embora o código de status 300 seja raramente usado na prática, ele pode ser útil em casos em que há várias representações possíveis de um recurso e o servidor deseja permitir que o cliente escolha a opção mais adequada para suas necessidades.

No entanto, a maioria das aplicações web usa o redirecionamento HTTP 301 ou 302 para lidar com situações em que um recurso é movido permanentemente ou temporariamente para um novo local.

301 – Moved Permanently (Movido permanentemente)

O código de status HTTP 301, também conhecido como “Moved Permanently” (Movido permanentemente), é usado quando uma página da web foi movida permanentemente para um novo URL.

Significa que a página antiga não estará mais disponível e que todas as solicitações subsequentes para o URL antigo serão redirecionadas para o novo URL.

O uso adequado do código 301 é importante para garantir que os visitantes do site sejam direcionados para o conteúdo correto e para que os mecanismos de pesquisa saibam que o conteúdo da página foi movido permanentemente para o novo URL.

Isso também ajuda a evitar a criação de conteúdo duplicado, o que pode prejudicar a classificação do site nos resultados de pesquisa.

Além disso, ao usar o código 301, é importante garantir que o redirecionamento seja configurado corretamente.

Se o redirecionamento for configurado de forma inadequada, pode resultar em problemas de rastreamento para os mecanismos de pesquisa e problemas de acessibilidade para os visitantes do site.

Em termos práticos, um exemplo de uso do código de status HTTP 301 seria quando um site muda de domínio ou altera o URL de uma página específica.

Nesse caso, um redirecionamento 301 seria configurado para garantir que os visitantes do site que acessarem o URL antigo sejam direcionados para o novo URL.

302 – Found (Encontrado)

O código de status HTTP 302, também conhecido como “Found” (Encontrado), é um código de redirecionamento que informa ao navegador do cliente que a URL solicitada foi temporariamente movida para uma nova localização.

Esse código de status é geralmente usado para redirecionar o usuário para uma nova URL, como uma página de login ou uma nova versão de um site.

Ao receber uma resposta com o código 302, o navegador do cliente é instruído a enviar uma nova solicitação para a nova URL especificada na resposta.

A nova solicitação é geralmente enviada usando o método GET, a menos que o método original da solicitação fosse POST.

O código de status HTTP 302 é semelhante ao código 301 (Moved Permanently), mas é usado para indicar um redirecionamento temporário, em vez de um redirecionamento permanente.

É importante notar que, embora o código de status 302 seja tecnicamente um redirecionamento temporário, alguns navegadores podem armazenar em cache a nova URL e continuar a redirecionar o usuário para a nova localização, mesmo após o redirecionamento ter sido removido.

É importante usar o código de status 302 com cuidado e apenas quando necessário, para evitar problemas de redirecionamento indesejados para o usuário final.

Se o redirecionamento for permanente, é recomendado o uso do código 301 em vez do código 302.

303 – See Other (Ver outro)

O código de status HTTP 303 indica que a resposta à solicitação pode ser encontrada em outro URI (Identificador Uniforme de Recursos) especificado na resposta.

Esse código é útil para situações em que o cliente enviou uma solicitação que pode ser melhor respondida por uma solicitação GET para outro URI.

Quando um servidor retorna um código de status 303, ele deve incluir um cabeçalho de resposta “Location” que contém o URI do recurso solicitado.

O cliente pode, então, emitir uma nova solicitação GET para esse URI para obter a resposta desejada.

Ao contrário do código de status 302, que também é usado para redirecionamento, o código 303 indica que a solicitação original foi concluída com sucesso e que a resposta à solicitação pode ser encontrada em outro URI.

Além disso, a solicitação subsequente ao URI redirecionado deve ser uma solicitação GET, independentemente do método de solicitação original.

304 – Not Modified (Não modificado)

O código de status HTTP 304 indica que o recurso solicitado não foi modificado desde a última vez que foi acessado.

É usado principalmente em cache para evitar a transferência de recursos que já foram baixados anteriormente pelo cliente.

Quando um cliente faz uma solicitação para um recurso, o servidor verifica se o recurso foi modificado desde a última solicitação.

Se o recurso não foi modificado, o servidor envia o código de status 304 em vez do recurso solicitado.

O cliente, em seguida, utiliza a versão em cache do recurso, economizando tempo e largura de banda.

Este código de status é útil em situações em que os recursos são grandes ou quando há vários usuários solicitando o mesmo recurso ao mesmo tempo.

Ele permite que o servidor economize largura de banda e recursos, garantindo que os clientes tenham acesso aos recursos atualizados apenas quando necessário.

O código de status 304 é geralmente acompanhado pelos cabeçalhos HTTP “ETag” ou “Last-Modified”, que indicam a versão do recurso solicitado que está sendo utilizada pelo cliente.

Esses cabeçalhos são usados pelo servidor para verificar se a versão em cache do recurso ainda é válida ou se deve ser atualizada.

Entretanto, ele só pode ser usado se o cliente já tiver baixado uma cópia do recurso anteriormente.

Se esta for a primeira solicitação do cliente para o recurso, o servidor deverá retornar o recurso completo, acompanhado do código de status 200 – Ok.

305 – Use Proxy (Usar proxy)

O código de status HTTP 305 é usado para informar ao cliente que a solicitação deve ser encaminhada através de um proxy.

Isso é feito para ajudar a manter a privacidade do usuário, pois o proxy pode atuar como um intermediário entre o cliente e o servidor.

Ao receber uma resposta com o código 305, o cliente é informado de que a solicitação não pode ser atendida diretamente pelo servidor de origem e deve ser roteada através de um proxy.

O servidor então fornece ao cliente o endereço do proxy que deve ser usado.

Este código de status foi definido na especificação HTTP/1.1, mas foi removido na especificação HTTP/1.1 devido a problemas de segurança.

O uso de proxies para interceptar e manipular solicitações HTTP pode ser uma ameaça à segurança do usuário e, portanto, a maioria dos navegadores modernos não suporta mais esse código de status.

Caso um cliente receba uma resposta com o código 305, ele deve seguir as instruções fornecidas pela resposta para encaminhar a solicitação através do proxy indicado.

Se o cliente não puder ou não quiser usar o proxy, ele pode enviar uma nova solicitação diretamente para o servidor de origem.

306 – Unused (Não utilizado)

O código de status HTTP 306 – Unused, foi criado na especificação HTTP/1.1, mas nunca foi implementado pelos navegadores.

Ele foi reservado pela Internet Assigned Numbers Authority (IANA) para uso futuro. Portanto, este código nunca é retornado como uma resposta HTTP.

Embora o código 306 não seja usado atualmente, a especificação HTTP permite que ele seja usado para um propósito específico no futuro.

A IANA mantém um registro de todos os códigos de status HTTP definidos na RFC 7231 e em outras especificações relacionadas. Qualquer novo código de status deve ser registrado com a IANA antes de ser usado publicamente.

Portanto, apesar de não ter uso prático atualmente, o código 306 pode ser utilizado em uma possível atualização do protocolo HTTP, caso seja necessário.

307 – Temporary Redirect (Redirecionamento temporário)

O código de status HTTP 307 indica que a requisição foi redirecionada temporariamente para outra URI especificada na resposta.

A diferença entre esse código e o 302 – Found é que o 307 mantém o método HTTP original da requisição, enquanto o 302 pode mudar o método para GET.

O redirecionamento temporário pode ser usado em situações em que a URI original da requisição é temporariamente indisponível ou quando o recurso foi movido temporariamente para outra URI.

Ao receber um código de status 307, o cliente deve enviar uma nova requisição para a URI redirecionada utilizando o mesmo método HTTP da requisição original.

Um exemplo de uso do código 307 é quando um site está em manutenção e precisa redirecionar temporariamente todas as requisições para uma página de manutenção, mas deseja manter a integridade das requisições originais.

É importante lembrar que o uso de redirecionamentos deve ser feito com cuidado, pois pode afetar negativamente a experiência do usuário e o desempenho do site.

O redirecionamento excessivo pode aumentar o tempo de carregamento da página e reduzir a qualidade da experiência do usuário.

308 – Permanent Redirect (Redirecionamento permanente)

O código de status HTTP 308 é semelhante ao código 301 (Movido permanentemente) e 302 (Encontrado), porém, com uma diferença fundamental: ele indica que o redirecionamento é permanente, ou seja, que o recurso solicitado foi movido de forma permanente para outra URL.

Quando o servidor envia uma resposta com o código de status HTTP 308, ele deve incluir um cabeçalho “Location” que indique a nova localização do recurso.

Os agentes de usuário, como navegadores da web, devem então usar essa nova URL em vez da original para todas as solicitações futuras relacionadas a esse recurso.

Assim como o código 301, o 308 é considerado um redirecionamento de nível de servidor, o que significa que ele é executado antes que a solicitação seja processada pelo servidor.

Isso pode ser útil em situações em que um site mudou de domínio ou uma página foi renomeada e você deseja garantir que os visitantes sejam automaticamente direcionados para a nova localização do recurso.

É importante notar que, assim como o código 301, os motores de busca interpretam o código 308 como um sinal de que a página foi permanentemente movida para outra localização.

Portanto, eles atualizarão seus índices com a nova URL e exibirão a nova localização nos resultados da pesquisa.

Códigos HTTP 4xx (Erro do cliente)

A solicitação contém sintaxe incorreta ou não pode ser atendida pelo servidor

400 – Bad Request (Solicitação ruim)

O código de status HTTP 400 – Bad Request (Solicitação ruim) é retornado quando o servidor não pode processar a requisição do cliente devido a um erro no lado do cliente, como uma solicitação mal formada, inválida ou incompleta.

A resposta também pode ser retornada se a requisição do cliente contiver parâmetros inválidos ou incorretos.

Entre as possíveis situações que podem resultar no retorno deste código de status, estão:

Uma solicitação com formato incorreto, como falta de cabeçalhos obrigatórios ou uma sintaxe inválida;
Um payload da solicitação (corpo da mensagem) que não pode ser interpretado corretamente;
Uma requisição que não atende aos requisitos de validação, como o tamanho máximo permitido;
Erros de autenticação ou autorização, como credenciais inválidas ou falta de permissão para acessar um recurso.

É importante ressaltar que este código de status não indica que há um problema no servidor em si, mas sim que a requisição do cliente foi malformada ou contém informações inválidas.

Quando um servidor retorna o código de status 400, geralmente é útil incluir uma mensagem de erro que informe ao cliente qual foi o problema com a solicitação.

Isso pode ajudar o cliente a corrigir a solicitação e tentar novamente, evitando assim a continuação do erro.

401 – Unauthorized (Não autorizado)

O código de status HTTP 401 é usado para indicar que a solicitação do cliente não foi autorizada a acessar o recurso solicitado.

Isso ocorre quando o servidor requer que o cliente se autentique para acessar o recurso e o cliente não forneceu as credenciais corretas ou não as forneceu.

Por exemplo, quando um usuário tenta acessar uma página protegida por senha sem fornecer as credenciais de autenticação corretas, o servidor retorna o código de status HTTP 401.

Além disso, se um usuário já estiver autenticado, mas não tiver as permissões adequadas para acessar o recurso solicitado, o servidor também retornará o código de status 401.

Em alguns casos, os servidores também podem retornar uma página de login personalizada para permitir que o usuário insira suas credenciais e autentique antes de acessar o recurso.

O cabeçalho WWW-Authenticate é usado para indicar quais esquemas de autenticação são suportados pelo servidor.

Para resolver o erro 401, o usuário deve fornecer as credenciais de autenticação corretas ou, se ainda não tiver uma conta, criar uma e fornecer as credenciais de autenticação necessárias.

402 – Payment Required (Pagamento requerido)

O código de status HTTP 402 – Payment Required (Pagamento requerido) é uma resposta que indica que o recurso solicitado requer pagamento para ser acessado.

Esse código foi criado especificamente para situações em que um cliente deve efetuar um pagamento antes de acessar um determinado recurso.

Normalmente, esse código não é usado com frequência, mas é usado por sites que fornecem acesso a conteúdo premium ou por serviços de assinatura que exigem uma taxa de acesso para poder ser utilizado.

Quando um usuário tenta acessar um recurso protegido sem ter feito o pagamento necessário, o servidor retorna esse código como uma forma de avisar que é preciso pagar para acessá-lo.

Além disso, o código 402 também pode ser usado para indicar que um limite de pagamento foi atingido, o que significa que o usuário já pagou o máximo permitido para o serviço ou conteúdo em questão.

Em algumas situações, o servidor pode fornecer informações adicionais sobre como efetuar o pagamento ou sobre as opções de pagamento disponíveis.

É importante lembrar que o código 402 não é um erro de autenticação, mas sim um código de status informativo que indica que é necessário fazer um pagamento antes de acessar o recurso.

Caso a autenticação seja o problema, o código 401 – Unauthorized (Não autorizado) é o código mais apropriado a ser usado.

403 – Forbidden (Proibido)

O código de status HTTP 403 – Forbidden (Proibido) indica que o servidor entendeu a solicitação do cliente, mas está se recusando a executá-la, pois o usuário não possui as permissões necessárias para acessar o recurso solicitado.

Em outras palavras, o servidor não autoriza a ação solicitada pelo usuário. O código 403 pode ser retornado por diversas razões, como por exemplo:

O usuário tentou acessar uma página que requer autenticação e ele não possui as credenciais corretas;
O usuário tentou acessar um recurso que está protegido por senha e não forneceu as credenciais corretas;
O usuário tentou acessar um diretório no qual não possui permissão de leitura ou execução;
O usuário tentou executar uma ação que não é permitida para o seu nível de acesso;
O usuário tentou acessar uma página que foi removida do servidor.

O código de status 403 é semelhante ao código 401 (Não autorizado), mas a principal diferença é que no código 401, o servidor solicita ao cliente que forneça credenciais de autenticação válidas para acessar o recurso, enquanto no código 403, o servidor se recusa a executar a solicitação sem pedir credenciais.

404 – Not Found (Não encontrado)

O código de status HTTP 404 indica que o servidor não pôde encontrar o recurso solicitado pelo cliente.

Em outras palavras, isso significa que a página ou arquivo que o usuário tentou acessar não existe no servidor.

Esse é um dos códigos de erro mais comuns da web e é frequentemente encontrado pelos usuários.

Alguns exemplos de situações em que o código 404 pode ser retornado incluem:

Um link quebrado: se um usuário clicar em um link que aponta para uma página inexistente ou excluída, o servidor retornará um código 404;
Digitação incorreta do URL: se um usuário digitar manualmente um endereço de página que não existe, o servidor retornará um código 404;
Arquivo excluído ou renomeado: se um arquivo que estava disponível anteriormente foi excluído ou renomeado, o servidor não poderá encontrá-lo e retornará um código 404;
Problemas de redirecionamento: se houver problemas com um redirecionamento de página, o servidor pode retornar um código 404.

Ao receber um código 404, os navegadores normalmente exibem uma mensagem de erro padrão que informa ao usuário que a página solicitada não foi encontrada.

No entanto, os proprietários de sites podem personalizar essa mensagem e fornecer instruções para ajudar o usuário a encontrar o conteúdo que está procurando.

Para corrigir o erro 404, o proprietário do site pode tomar medidas, como verificar se o arquivo ou página existe no servidor, corrigir erros de digitação em links ou URLs e corrigir problemas de redirecionamento.

Erro Soft 404

O “Erro Soft 404” é um tipo de resposta HTTP que ocorre quando uma página é retornada com o código de status 200 (OK) em vez do código de status 404 (Não encontrado), apesar da página solicitada não existir.

Ocorre quando um servidor web retorna uma página que contém apenas uma mensagem genérica de “Página não encontrada” ou “404” em vez de uma mensagem personalizada que descreve o problema.

Isso pode acontecer quando o servidor não pode encontrar a página solicitada e, em vez de retornar o código de status correto, ele retorna uma página que se parece com uma página de erro, mas que não é realmente uma página de erro.

Os motores de busca, como o Google, podem detectar esses erros soft 404 e tratá-los como páginas de erro reais, o que pode afetar a classificação do site nos resultados da pesquisa.

Essas páginas podem ser interpretadas como conteúdo de baixa qualidade ou duplicado, o que pode levar a uma diminuição na confiança dos usuários e na relevância da página para determinadas consultas de pesquisa.

Exemplos de situações que podem retornar o erro soft 404 incluem páginas que contêm apenas mensagens genéricas de erro, como “Desculpe, não podemos encontrar a página solicitada”, ou páginas que redirecionam para uma página de erro em vez de retornar o código de status correto.

Para evitar o erro soft 404, é recomendável que os desenvolvedores retornem o código de status correto para páginas que não existem, em vez de retornar uma página de erro genérica.

Além disso, é importante personalizar as mensagens de erro para fornecer informações úteis aos usuários e motores de busca.

A diferença entre HTTP 404 e erro Soft 404

Tanto o código de status HTTP 404 quanto o erro soft 404 indicam que a página solicitada não foi encontrada no servidor.

No entanto, a diferença fundamental entre eles é a forma como são tratados pelos mecanismos de pesquisa.

O código de status HTTP 404 é um erro padrão que indica que a página solicitada não existe no servidor. Isso pode acontecer por diversos motivos, como uma URL digitada incorretamente, uma página removida ou um link quebrado.

Quando o servidor retorna o código de status HTTP 404, ele informa ao navegador que a página solicitada não pode ser encontrada e geralmente exibe uma página de erro padrão para o usuário.

Já o erro soft 404 ocorre quando uma página que não existe mais é redirecionada para uma página de erro personalizada, mas essa página de erro não fornece informações úteis para o usuário e não corresponde ao conteúdo original da página solicitada.

Esse tipo de erro pode ocorrer quando uma página é removida e, em vez de redirecionar o usuário para uma página semelhante ou uma página de categoria relevante, o site redireciona o usuário para uma página de erro genérica que não oferece informações relevantes.

Os mecanismos de pesquisa não gostam de encontrar erros soft 404 em um site, porque isso pode indicar que o site não está oferecendo uma boa experiência para o usuário e pode ser penalizado no ranking de pesquisa.

Por outro lado, o código de status HTTP 404 é um erro legítimo que indica que a página não existe mais e não é penalizado pelos mecanismos de pesquisa.

Portanto, é importante para os proprietários de sites garantir que seus redirecionamentos sejam corretos e evitem erros soft 404 para manter a saúde do site e o bom ranqueamento nos resultados de pesquisa.

405 – Method Not Allowed (Método não permitido)

O código de status HTTP 405 – Method Not Allowed (Método não permitido) é retornado quando o método HTTP utilizado na solicitação não é suportado para o recurso solicitado.

Por exemplo, se um cliente envia uma solicitação POST para um recurso que só aceita solicitações GET, o servidor pode responder com o código 405.

Alguns dos métodos HTTP mais comuns incluem GET, POST, PUT e DELETE. Cada método tem um objetivo específico e espera uma ação diferente do servidor.

Quando um método não é suportado pelo servidor para um determinado recurso, o servidor retornará o código 405 para indicar que o método não é permitido.

Algumas situações que podem levar a um erro 405 incluem:

O cliente tentou enviar uma solicitação usando um método que não é suportado pelo servidor para o recurso solicitado. Por exemplo, um cliente pode tentar enviar uma solicitação POST para um recurso que só aceita solicitações GET;
O servidor está configurado para não permitir determinados métodos HTTP para determinados recursos. Por exemplo, um servidor pode estar configurado para permitir apenas solicitações GET para arquivos de imagem;
Pode haver um erro de programação no servidor que está impedindo a execução correta do método HTTP. Por exemplo, pode haver um problema de programação que impede o servidor de processar solicitações POST.

Para resolver o erro 405, o cliente pode tentar enviar uma solicitação usando um método HTTP diferente que seja suportado pelo servidor para o recurso solicitado.

O desenvolvedor do servidor também pode configurar o servidor para permitir o método HTTP desejado para o recurso específico.

406 – Not Acceptable (Não aceitável)

O código de status HTTP 406 indica que o servidor não é capaz de produzir uma resposta que atenda aos critérios definidos pelo cliente nas headers “Accept” do pedido.

Isso significa que o recurso solicitado está disponível, mas a representação desejada não pode ser fornecida.

Em outras palavras, o servidor não pode fornecer conteúdo no formato solicitado pelo cliente.

O código de status 406 é frequentemente usado em conjunto com a negociação de conteúdo, que é um processo em que o cliente solicita um recurso em diferentes formatos e o servidor responde com o formato que melhor corresponde às preferências do cliente.

Se o servidor não puder atender a nenhuma das opções de formato solicitadas pelo cliente, ele retornará o código de status 406.

Exemplos de situações que podem resultar em um código de status 406 incluem:

O cliente faz uma solicitação para um recurso em um formato específico, como um arquivo de imagem em formato JPEG, mas o servidor só tem esse arquivo em formato PNG;
O cliente solicita uma página em um idioma específico, mas o servidor só tem essa página em outro idioma;
O cliente solicita um vídeo em um formato específico, mas o servidor só tem o vídeo em outro formato que não é compatível com o que o cliente solicitou.

Nesses casos, o servidor retornará um código de status 406 e informará ao cliente que ele não pode atender a essa solicitação em particular.

O servidor também pode incluir informações adicionais na resposta, como uma lista de formatos suportados para o recurso solicitado.

407 – Proxy Authentication Required (Autenticação de proxy necessária)

O código de status HTTP 407 – Proxy Authentication Required (Autenticação de proxy necessária) é retornado quando um cliente tenta acessar um recurso por meio de um proxy, mas é necessário autenticação para obter acesso ao proxy.

O servidor de proxy solicitará as credenciais do usuário antes de permitir o acesso ao recurso solicitado.

Esse código de status é semelhante ao código 401 (Não autorizado), porém, ao invés de autenticar diretamente com o servidor de origem, o cliente deve autenticar com o servidor proxy.

Exemplos de situações que podem retornar o código 407:

O cliente tenta acessar um recurso na internet por meio de um servidor proxy que requer autenticação. Se o cliente não tiver as credenciais corretas para o proxy, o código 407 será retornado;
O servidor proxy pode estar configurado para solicitar autenticação a cada nova conexão ou após um período de tempo específico. Nesse caso, se o cliente não tiver as credenciais corretas, o código 407 será retornado;
Caso o servidor proxy tenha sido mal configurado, é possível que ocorra um erro de autenticação mesmo com as credenciais corretas. Isso também pode levar ao retorno do código 407.

Para resolver o erro 407, o cliente deve fornecer as credenciais de autenticação corretas ao servidor de proxy.

Isso pode ser feito por meio do uso de um diálogo de autenticação, em que o cliente inserirá seu nome de usuário e senha ou por meio da configuração prévia das credenciais no navegador ou software que está sendo usado para acessar o recurso.

408 – Request Timeout (Tempo de solicitação esgotado)

O código de status HTTP 408 indica que o servidor encerrou a conexão porque a solicitação do cliente levou muito tempo para ser concluída.

Esse tempo limite é definido pelo servidor e pode variar de acordo com a configuração.

Esse status pode ser retornado em várias situações, como quando o servidor está sobrecarregado e não consegue lidar com todas as solicitações simultaneamente, ou quando o cliente está com uma conexão lenta ou instável.

Além disso, erros de roteamento de rede ou problemas de conectividade também podem levar a esse status.

Quando um cliente recebe o código de status HTTP 408, ele pode tentar enviar a solicitação novamente, mas é importante lembrar que isso pode não resolver o problema, especialmente se o problema estiver relacionado à sobrecarga do servidor.

Para evitar que esse código de status seja retornado, os desenvolvedores podem otimizar o desempenho do servidor, reduzir o tamanho das solicitações ou ajustar o tempo limite de conexão.

Também é importante verificar a conectividade de rede e garantir que não haja problemas de roteamento.

409 – Conflict (Conflito)

O código de status HTTP 409 indica que a solicitação do cliente não pode ser concluída devido a um conflito com o recurso atualmente em uso.

Em outras palavras, o servidor não pode atender à solicitação do cliente porque o estado do recurso solicitado entra em conflito com outro recurso que está em uso.

Este código de status é frequentemente visto em sistemas de controle de versão, onde há vários usuários trabalhando no mesmo arquivo ao mesmo tempo.

Por exemplo, se dois usuários tentarem fazer alterações diferentes no mesmo arquivo simultaneamente, o servidor retornará um código 409 para um dos usuários para informá-lo que suas alterações estão em conflito com as alterações feitas pelo outro usuário.

Outro exemplo comum é quando um usuário tenta excluir um recurso que está sendo usado por outro processo ou usuário.

Nesse caso, o servidor pode retornar um código 409 para indicar que a exclusão não pode ser realizada devido a um conflito com o recurso em uso.

Ao receber um código de status HTTP 409, o cliente deve lidar com o conflito e tentar novamente.

Isso pode envolver solicitar informações atualizadas sobre o estado do recurso, resolvendo o conflito ou modificando a solicitação original para evitar o conflito.

410 – Gone (Perdido)

O código de status HTTP 410 – Gone é usado para indicar que o recurso solicitado não está mais disponível no servidor e não há um endereço de redirecionamento conhecido para ele.

Isso significa que o recurso foi intencionalmente removido e não deve estar disponível novamente. É uma resposta permanente, ao contrário do código 404 que indica uma resposta temporária.

Esse código é frequentemente usado em situações em que um site ou aplicativo da web foi completamente removido ou em que um recurso foi renomeado ou movido para um local diferente e o endereço antigo não deve ser usado mais.

Também pode ser usado em situações em que o recurso é considerado sensível e o acesso a ele é permanentemente proibido.

Por exemplo, se um usuário tentar acessar um arquivo que foi excluído do servidor, o servidor pode retornar um código 410 para informar que o arquivo não está mais disponível.

Outro exemplo pode ser um site que foi encerrado e não está mais disponível online.

Ao receber um código de status 410, o cliente deve atualizar seus links e referências para o recurso removido.

É uma boa prática incluir uma mensagem explicando por que o recurso foi removido e se houver um substituto ou alternativa disponível para o recurso anteriormente acessado.

411 – Length Required (Comprimento necessário)

O código de status HTTP 411 – Length Required (Comprimento necessário) é uma resposta do servidor indicando que a solicitação feita pelo cliente não possui um cabeçalho “Content-Length” válido, o que é necessário para o processamento da solicitação.

Esse código de status geralmente é encontrado em casos onde o cliente tenta enviar dados ao servidor utilizando métodos como POST ou PUT, sem especificar o tamanho do conteúdo enviado.

O servidor, então, não consegue determinar a quantidade de dados a serem processados e responde com o código de status 411.

Para solucionar esse problema, o cliente deve incluir o cabeçalho “Content-Length” na solicitação, informando o tamanho do conteúdo que está sendo enviado em bytes.

Dessa forma, o servidor será capaz de processar a solicitação corretamente.

Por exemplo, ao enviar um arquivo de texto com 500 bytes, o cabeçalho “Content-Length” deve ser definido como “Content-Length: 500”.

Note que, em algumas situações, o uso do cabeçalho “Content-Length” pode ser substituído pelo cabeçalho “Transfer-Encoding: chunked”.

Essa abordagem permite o envio de dados em partes (chunks) sem a necessidade de especificar o tamanho total do conteúdo enviado.

No entanto, essa opção pode não ser compatível com todos os servidores e pode exigir configurações adicionais.

412 – Precondition Failed (Pré-condição falhou)

O código de status HTTP 412 – Precondition Failed (Pré-condição falhou) é uma resposta do servidor que indica que uma ou mais condições especificadas no cabeçalho da solicitação não foram atendidas.

Isso geralmente ocorre quando o cliente utiliza cabeçalhos condicionais em sua solicitação, como “If-Match”, “If-Modified-Since”, “If-None-Match”, “If-Unmodified-Since” e “If-Range”.

Esses cabeçalhos condicionais permitem que o cliente solicite o recurso apenas se certas condições forem atendidas.

Por exemplo, um cliente pode solicitar um recurso utilizando o cabeçalho “If-Modified-Since” para obter o conteúdo somente se ele foi modificado após uma data específica.

Se a condição não for atendida, o servidor responderá com o código de status 412.

O principal objetivo desses cabeçalhos condicionais é melhorar a eficiência das comunicações entre o cliente e o servidor, permitindo que o cliente solicite informações apenas quando necessário, evitando tráfego desnecessário na rede e melhorando o desempenho geral.

Para solucionar o problema relacionado ao código de status 412, o cliente deve verificar se as condições especificadas nos cabeçalhos condicionais estão corretas e, se necessário, ajustá-las de acordo.

Por exemplo, se o cliente estiver usando o cabeçalho “If-Modified-Since” com uma data incorreta, ele deve corrigir a data e reenviar a solicitação.

Em alguns casos, pode ser necessário remover o cabeçalho condicional para que a solicitação seja processada corretamente.

413 – Payload Too Large (Carga útil muito grande)

O código 413 é retornado pelo servidor quando o corpo da requisição enviada pelo cliente excede o tamanho máximo permitido pelo servidor.

Isso pode ocorrer, por exemplo, ao tentar fazer upload de um arquivo muito grande ou enviar um formulário com muitos dados.

Essa limitação de tamanho é uma medida de segurança implementada pelos servidores para evitar problemas de desempenho, consumo excessivo de recursos e até mesmo ataques maliciosos.

O tamanho máximo permitido pode variar dependendo da configuração do servidor e das especificidades de cada aplicação.

Para resolver essa situação, o usuário pode tentar reduzir o tamanho dos dados enviados, seja comprimindo os arquivos, dividindo-os em partes menores ou removendo informações desnecessárias.

Em alguns casos, pode ser necessário entrar em contato com o administrador do servidor ou o desenvolvedor da aplicação para solicitar um aumento no limite de tamanho da carga útil, se isso for apropriado e seguro para a aplicação em questão.

É importante lembrar que o cabeçalho “Content-Length” é fundamental para informar o servidor sobre o tamanho do conteúdo enviado.

Se o tamanho informado exceder o limite permitido, o servidor retornará o código 413, informando que a carga útil é muito grande.

414 – URI Too Large (URI muito grande)

O código 414 é uma resposta do servidor que indica que a URI (Uniform Resource Identifier) solicitada pelo cliente é maior do que o limite aceito pelo servidor.

A URI é a sequência de caracteres utilizada para identificar e localizar um recurso na web, como um endereço de site ou uma API.

Esse código de status pode ocorrer quando a URI de uma solicitação contém muitos parâmetros de consulta, por exemplo, ao utilizar o método GET para enviar grandes quantidades de informações ao servidor.

Também pode ser resultado de um erro no cliente ao gerar a URI.

Os servidores impõem um limite no tamanho da URI para evitar problemas de desempenho, garantir a segurança e a estabilidade do sistema, além de prevenir ataques maliciosos que exploram URIs excessivamente longas.

Para solucionar esse problema, é recomendável que o cliente revise a URI e verifique se é possível reduzir seu tamanho, como remover parâmetros desnecessários ou otimizar a estrutura da URL.

Em casos onde muitos dados precisam ser enviados ao servidor, pode ser apropriado considerar o uso do método POST em vez do GET, já que o POST permite o envio de informações no corpo da requisição, evitando o uso de uma URI extensa.

Se a URI longa for necessária para a aplicação, o desenvolvedor ou administrador do servidor pode considerar ajustar a configuração do servidor para permitir URIs mais longas, desde que isso não comprometa a segurança e o desempenho do sistema.

415 – Unsupported Media Type (Tipo de mídia não compatível)

O código 415 é uma resposta do servidor informando que o tipo de mídia presente na solicitação do cliente não é suportado ou incompatível com o recurso solicitado.

Geralmente, esse código de status está relacionado ao cabeçalho “Content-Type” da requisição, que especifica o formato dos dados enviados ao servidor.

Esse problema pode ocorrer quando o cliente tenta enviar dados em um formato que o servidor não consegue processar, seja por falta de suporte a esse tipo específico de mídia ou por uma configuração inadequada.

Por exemplo, um servidor que aceita apenas arquivos de imagem no formato JPEG pode retornar o código 415 caso o cliente envie um arquivo PNG.

Para resolver esse problema, o cliente deve verificar o cabeçalho “Content-Type” e certificar-se de que está utilizando o formato correto e compatível com o servidor. Além disso, é importante consultar a documentação do servidor ou da API para entender quais tipos de mídia são suportados.

Em alguns casos, pode ser necessário converter os dados para um formato compatível antes de enviá-los ao servidor.

Por exemplo, se um servidor aceita apenas arquivos de imagem em formato JPEG, o cliente deve converter arquivos PNG em JPEG antes de enviá-los.

Se o servidor precisar suportar um tipo de mídia adicional, o administrador do servidor ou o desenvolvedor da aplicação deve atualizar a configuração do servidor para aceitar esse formato específico.

É importante garantir que a inclusão de novos tipos de mídia seja feita de maneira segura e sem comprometer o desempenho e a estabilidade do sistema.

416 – Range Not Satisfiable (Faixa não satisfatória)

O código 416 é uma resposta do servidor que sinaliza que a faixa solicitada no cabeçalho “Range” da requisição do cliente não pode ser atendida.

Essa situação ocorre quando a faixa especificada não está disponível ou é inválida para o recurso em questão.

O cabeçalho “Range” é empregado para pedir partes específicas de um recurso, em vez de solicitar o recurso completo, sendo especialmente útil para retomar downloads interrompidos ou executar streaming de mídia.

Para resolver essa situação, é importante que o cliente verifique o cabeçalho “Range” e ajuste os valores de faixa, caso necessário.

Certificar-se de que a faixa solicitada esteja dentro dos limites do recurso e em conformidade com a documentação e as especificações do servidor ou da API é fundamental.

Se a funcionalidade de faixa de bytes for crucial para a aplicação e o servidor não a oferecer, será necessário que o administrador do servidor ou o desenvolvedor da aplicação atualize a configuração do servidor para incluir suporte a esse recurso.

No entanto, é imprescindível garantir que a implementação dessa funcionalidade seja segura e não afete negativamente o desempenho do sistema.

Em casos nos quais não seja possível ajustar a faixa solicitada nem modificar a configuração do servidor, o cliente poderá ter que efetuar o download do recurso completo, em vez de requisitar uma faixa específica.

417 – Exception Failed (Falha na exceção)

O código 417 é uma resposta do servidor que manifesta a incapacidade de cumprir a solicitação do cliente devido ao não atendimento de uma ou mais expectativas estabelecidas no cabeçalho “Expect”.

Esse cabeçalho permite que o cliente comunique ao servidor condições específicas que devem ser satisfeitas para que a requisição seja processada corretamente.

Um exemplo comum do uso do cabeçalho “Expect” é o “Expect: 100-continue”.

Nesse caso, o cliente solicita que o servidor confirme a possibilidade de processar a requisição, respondendo com o código de status 100 (Continue) ou retornando um código de erro adequado, caso não seja possível.

Quando o servidor retorna o código 417, indica que não pode ou não deseja satisfazer a expectativa informada no cabeçalho “Expect”.

Isso pode ocorrer devido às configurações do servidor, às limitações de recursos ou às características da aplicação.

Para solucionar esse problema, o cliente deve analisar o cabeçalho “Expect” e as condições nele estabelecidas, corrigindo-as e reenviando a solicitação, se necessário.

Caso o servidor não consiga atender às expectativas mesmo estando corretas, o cliente deve consultar a documentação do servidor ou da API, ajustando a solicitação de acordo com os requisitos e limitações específicos.

Em algumas situações, pode ser necessário entrar em contato com o administrador do servidor ou o desenvolvedor da aplicação para avaliar a possibilidade de ajustar a configuração do servidor ou realizar modificações na aplicação, a fim de atender às expectativas do cabeçalho “Expect”.

Vale ressaltar que o uso do cabeçalho “Expect” não é tão frequente em servidores e aplicativos modernos.

Portanto, muitas vezes, adotar outras abordagens para lidar com erros ou condições específicas na comunicação entre cliente e servidor pode ser mais eficaz.

418 – I’m a Teapot (Eu sou um bule)

O código HTTP 418 – I’m a Teapot (Eu sou um bule) é um código de status incomum e bem-humorado, originado em uma piada no protocolo “Hyper Text Coffee Pot Control Protocol” (HTCPCP), que foi proposto pela primeira vez no dia 1º de abril de 1998, no documento RFC 2324.

Esse protocolo fictício tinha como objetivo controlar, monitorar e diagnosticar cafeteiras através de redes de computadores.

Embora o protocolo HTCPCP e o código 418 sejam uma brincadeira e não tenham uso prático real na comunicação entre cliente e servidor, o código 418 tem sido mantido em várias implementações de servidores e APIs como uma referência à história e à cultura da Internet.

A existência desse código de status serve como um lembrete da importância do bom humor e da criatividade no desenvolvimento de tecnologias e na comunidade de TI em geral.

Por ser uma piada e não ter uma função prática, o código 418 não possui soluções específicas ou implicações técnicas.

No entanto, alguns desenvolvedores e administradores de servidores podem usá-lo como uma resposta personalizada para situações específicas ou como uma forma de injetar humor e diversão em suas aplicações.

421 – Misdirected Request (Solicitação mal direcionada)

O código de status HTTP 421 – Misdirected Request (Solicitação mal direcionada) é uma resposta do servidor que indica que a requisição foi direcionada de forma inadequada para o servidor atual e, por isso, não pode ser processada.

Esse código de status foi introduzido no documento RFC 7540 como parte do protocolo HTTP/2.

Esse erro pode ocorrer em diversas situações, sendo algumas delas:

Quando o cliente tenta reutilizar uma conexão existente com um servidor para enviar uma nova requisição a um recurso que, na verdade, está hospedado em outro servidor;
Há problemas de configuração no servidor, como certificados SSL/TLS incorretos;
A requisição foi direcionada a um servidor inadequado devido a problemas no balanceamento de carga ou no roteamento do tráfego.

Para solucionar o problema relacionado ao código 421, é importante que o cliente e o administrador do servidor trabalhem juntos, identificando a causa do erro.

Caso a origem do problema seja a reutilização incorreta de uma conexão, o cliente deve ajustar sua configuração para estabelecer uma nova conexão apropriada ao recurso desejado.

Se o erro for causado por problemas no servidor, como configurações de SSL/TLS incorretas, o administrador deve corrigir essas configurações e garantir que o servidor esteja apto a processar a requisição.

Se o problema for originado por questões no balanceamento de carga ou no roteamento do tráfego, o administrador do servidor deve revisar e corrigir as configurações dos balanceadores de carga e dos sistemas de roteamento para garantir que as requisições sejam direcionadas corretamente aos servidores apropriados.

422 – Unprocessed Entity (WebDAV) – (Entidade não processada)

Originário da extensão WebDAV (Web Distributed Authoring and Versioning) do protocolo HTTP, o código de status HTTP 422 – Entidade não processada sinaliza que o servidor compreendeu a solicitação, mas não pôde processá-la devido a dados inválidos ou formatados incorretamente fornecidos pelo cliente.

A extensão WebDAV, descrita no documento RFC 4918, permite a manipulação e colaboração remota de recursos da web, incluindo a criação, atualização e remoção de arquivos e diretórios.

O código 422 é utilizado quando há um problema específico nos dados enviados pelo cliente que impede o servidor de processar a solicitação, como campos ausentes, valores incompatíveis ou formatos inválidos.

Este código de status difere do código 400 – Bad Request (Solicitação inválida), que indica um problema genérico na solicitação sem fornecer detalhes sobre o motivo do erro.

Para resolver o problema associado ao código 422, o cliente deve examinar a resposta do servidor em busca de informações sobre o erro nos dados fornecidos.

Muitas vezes, o servidor inclui detalhes sobre o motivo do erro na resposta, como uma mensagem específica ou informações sobre campos inválidos.

Após identificar e corrigir o erro nos dados, o cliente pode reenviar a solicitação.

423 – Locked (WebDAV) – (Bloqueado)

O código 423 – Locked (Bloqueado) é uma resposta do servidor que indica que o recurso requisitado encontra-se bloqueado no momento, impossibilitando o processamento da solicitação até que o bloqueio seja removido.

Essa funcionalidade de bloqueio é usada para evitar conflitos e inconsistências ao trabalhar com arquivos e diretórios compartilhados.

Quando um recurso está bloqueado, somente o cliente que aplicou o bloqueio ou um cliente com permissões apropriadas tem a capacidade de desbloqueá-lo e realizar alterações.

Caso outros clientes tentem modificar o recurso bloqueado, receberão o código de status HTTP 423 – Locked (Bloqueado) como resposta.

Para solucionar o problema associado ao código 423, o cliente deve verificar se possui as permissões necessárias para desbloquear o recurso.

Caso contrário, pode ser preciso aguardar que o cliente responsável pelo bloqueio original desbloqueie o recurso.

Em algumas situações, entrar em contato com o administrador do sistema ou outros colaboradores do projeto pode ser necessário para coordenar a liberação do recurso bloqueado.

424 – Failed Dependency (WebDAV) – (Dependência com falha)

O código de status HTTP 424 – Failed Dependency (Dependência com falha) é uma resposta do servidor que indica que uma solicitação falhou devido à falha de outra solicitação na qual a primeira depende.

Esse código de status é usado principalmente no contexto de operações em lote ou transações envolvendo múltiplas solicitações, onde várias ações estão vinculadas e a falha de uma delas pode afetar o resultado das outras.

Em situações em que várias solicitações são enviadas em uma única operação, a execução bem-sucedida de algumas solicitações pode depender do resultado bem-sucedido de outras solicitações.

Quando uma dessas solicitações dependentes falha, o servidor retorna o código de status 424 – Failed Dependency (Dependência com falha) para as solicitações afetadas. Isso informa o cliente que a solicitação não pôde ser concluída com êxito devido à falha de outra solicitação na qual depende.

Para solucionar o problema relacionado ao código 424, é necessário identificar a solicitação que falhou e causou a dependência com falha.

Em seguida, o cliente deve corrigir o problema com a solicitação que falhou e reenviar as solicitações dependentes.

Geralmente, o servidor fornece informações adicionais sobre a falha na resposta, o que pode ajudar o cliente a identificar e corrigir o problema.

425 – Too Early (Muito cedo)

O código de status HTTP 425 – Too Early (Muito cedo) é uma resposta do servidor que indica que a solicitação não pode ser processada porque o servidor ainda não está pronto para lidar com ela.

Esse código de status é usado principalmente em contextos de protocolos de segurança como o Transport Layer Security (TLS) e o Datagram Transport Layer Security (DTLS).

O código 425 – Too Early (Muito cedo) é retornado quando um cliente envia uma solicitação a um servidor que ainda está estabelecendo uma conexão segura.

Esse processo de estabelecimento de conexão envolve uma série de etapas, incluindo negociação de protocolos e autenticação mútua, que precisam ser concluídas antes que o servidor esteja pronto para lidar com a solicitação do cliente.

Quando um servidor recebe uma solicitação antes de estar pronto para lidar com ela, ele pode responder com o código de status 425 – Too Early (Muito cedo).

Isso informa ao cliente que a solicitação foi recebida, mas que o servidor ainda não está pronto para lidar com ela.

A resposta também pode incluir informações adicionais sobre o motivo pelo qual o servidor ainda não está pronto para processar a solicitação.

Para resolver o problema associado ao código 425, o cliente pode tentar novamente a solicitação após um período adequado de tempo, permitindo que o servidor conclua o processo de estabelecimento de conexão.

O tempo necessário pode variar dependendo da complexidade do processo de autenticação e negociação de protocolos.

426 – Upgrade Required (Atualização necessária)

O código de status HTTP 426 – Upgrade Required (Atualização necessária) é uma resposta do servidor que indica que o cliente precisa fazer uma atualização para que a solicitação possa ser processada.

Esse código de status é usado principalmente em contextos de protocolos de comunicação como o Hypertext Transfer Protocol (HTTP) e o Simple Mail Transfer Protocol (SMTP).

O código 426 – Upgrade Required (Atualização necessária) é retornado quando o servidor deseja mudar para uma versão mais recente ou protocolo diferente do que o cliente está usando. Isso pode ocorrer, por exemplo, quando um servidor deseja mudar de HTTP/1.1 para HTTP/2 ou quando um servidor deseja usar um protocolo de segurança mais recente.

Quando o servidor envia o código de status 426 – Upgrade Required (Atualização necessária), ele geralmente inclui informações adicionais sobre o protocolo ou versão exigida para o processamento da solicitação.

O cliente deve fazer a atualização necessária para atender aos requisitos do servidor e permitir que a solicitação seja processada com sucesso.

O processo de atualização pode incluir, por exemplo, a instalação de uma nova versão do protocolo ou a mudança para um protocolo diferente.

O cliente também pode precisar reconfigurar suas ferramentas ou sistemas para se adequar à nova versão ou protocolo.

428 – Precondition Required (Pré-condição necessária)

O código 428 – Precondition Required é retornado quando um servidor requer que a solicitação seja acompanhada por determinadas informações ou condições prévias para que possa ser processada.

Por exemplo, um servidor pode exigir que um cliente inclua um cabeçalho de autenticação específico ou que um recurso esteja em um determinado estado antes que uma solicitação possa ser processada.

Quando o servidor envia o código de status 428 – Precondition Required, ele geralmente inclui informações adicionais sobre as pré-condições que devem ser satisfeitas para o processamento da solicitação.

O cliente deve atender a essas pré-condições para permitir que a solicitação seja processada com sucesso.

O processo de atendimento às pré-condições pode incluir a inclusão de um cabeçalho de autenticação específico, a modificação de um recurso para atender a um estado específico ou o fornecimento de informações adicionais solicitadas pelo servidor.

Em alguns casos, o servidor pode fornecer um conjunto de pré-condições que o cliente deve cumprir antes que a solicitação possa ser processada.

É importante destacar que o código de status 428 – Precondition Required não se aplica apenas a solicitações HTTP.

Ele pode ser usado em qualquer protocolo que permita o controle de acesso ou autenticação, como o FTP (File Transfer Protocol) e o SMTP (Simple Mail Transfer Protocol).

429 – Too Many Requests (Muitas solicitações)

O código de status HTTP 429 – Too Many Requests (Muitas solicitações) é uma resposta do servidor que indica que o usuário atingiu o limite de solicitações permitidas em um determinado período de tempo.

Esse código de status é usado quando o servidor quer evitar que o cliente faça muitas solicitações em um curto período de tempo, a fim de evitar a sobrecarga do servidor.

Geralmente, os servidores estabelecem limites para o número de solicitações que um cliente pode fazer em um determinado período de tempo.

Esses limites são estabelecidos para evitar que o servidor fique sobrecarregado e não possa atender a todas as solicitações.

Se o cliente ultrapassar o limite de solicitações permitido, o servidor enviará o código de status HTTP 429 – Too Many Requests.

A resposta 429 também pode incluir um cabeçalho Retry-After, que indica ao cliente quando ele pode enviar novas solicitações.

Esse cabeçalho pode ajudar a controlar a taxa de solicitações e impedir que o servidor seja sobrecarregado novamente.

O código de status HTTP 429 – Too Many Requests não é um erro, mas sim uma forma de limitar a carga no servidor e garantir que ele possa atender a todas as solicitações de forma eficiente.

É importante destacar que as políticas de limitação de taxa podem variar entre os servidores e, portanto, os desenvolvedores de aplicativos devem verificar as diretrizes específicas do servidor antes de enviar solicitações.

Para evitar receber o código de status HTTP 429 – Too Many Requests, os desenvolvedores podem limitar a taxa de solicitações enviadas ao servidor.

Isso pode ser feito por meio da implementação de uma política de limitação de taxa, que permite ao cliente fazer um número limitado de solicitações dentro de um determinado período de tempo.

Essas políticas de limitação de taxa podem ser definidas pelo servidor ou pelo cliente.

431 – Request Header Fields Too Large (Campos de cabeçalho de solicitação muito grandes)

O código de status HTTP 431 – Request Header Fields Too Large (Campos de cabeçalho de solicitação muito grandes) é uma resposta do servidor que indica que os campos de cabeçalho da solicitação HTTP excederam o limite permitido pelo servidor.

Os cabeçalhos da solicitação HTTP são usados para fornecer informações adicionais sobre a solicitação que está sendo feita, como o tipo de conteúdo solicitado, a origem da solicitação e informações de autenticação.

No entanto, se esses campos de cabeçalho forem muito grandes, o servidor pode não ser capaz de processar a solicitação corretamente.

O limite de tamanho dos campos de cabeçalho é determinado pelo servidor. Se o tamanho dos campos de cabeçalho exceder o limite permitido, o servidor enviará a resposta 431 – Request Header Fields Too Large.

Para evitar receber o código de status 431, é importante manter os campos de cabeçalho da solicitação dentro dos limites permitidos pelo servidor.

É possível ajustar o tamanho dos campos de cabeçalho ou dividir a solicitação em várias solicitações menores.

É importante destacar que o código de status HTTP 431 – Request Header Fields Too Large não deve ser confundido com o código de status HTTP 413 – Payload Too Large, que se refere ao tamanho do corpo da solicitação HTTP.

451 – Unavailable for Legal Reasons (Indisponível por motivos legais)

O código de status HTTP 451 – Unavailable for Legal Reasons (Indisponível por motivos legais) é uma resposta do servidor que indica que o acesso ao recurso solicitado foi negado por motivos legais.

Esse código de status foi criado para indicar que o servidor está impossibilitado de fornecer o recurso solicitado devido a restrições legais, como censura, bloqueios judiciais ou pedidos de remoção de conteúdo.

O nome “451” é uma referência ao livro “Fahrenheit 451” de Ray Bradbury, que retrata uma sociedade futurista na qual os livros são proibidos e queimados pelos governos para evitar que as pessoas tenham acesso a informações que possam questionar a autoridade.

O código de status 451, portanto, representa uma situação na qual o acesso à informação é negado por razões legais.

O código de status 451 é uma adição relativamente recente ao protocolo HTTP e ainda não é amplamente utilizado.

No entanto, sua inclusão é importante para garantir a transparência e a prestação de contas no que diz respeito à censura e restrição de conteúdo na internet.

499 – Client Closed Request (Solicitação fechada do cliente)

O código de status HTTP 499 – Client Closed Request (Solicitação fechada do cliente) é uma resposta do servidor que indica que a conexão com o cliente foi fechada antes que a resposta pudesse ser enviada.

Esse código de status é específico para o servidor web NGINX e é usado quando o cliente fecha a conexão antes que o servidor tenha concluído o envio da resposta.

Isso pode ocorrer quando o cliente cancela a solicitação ou fecha o navegador antes que a página seja completamente carregada.

O código de status 499 não faz parte dos padrões oficiais do protocolo HTTP e é exclusivo para o NGINX.

Além disso, ele não indica necessariamente um problema com o servidor ou com a solicitação do cliente, mas sim um encerramento prematuro da conexão por parte do cliente.

5xx (erro do servidor)

O servidor falhou ao atender a uma solicitação válida.

500 – Internal Server Error (Erro interno no servidor)

O código de status “HTTP 500 – Internal Server Error (Erro interno no servidor)” é uma resposta de erro genérica, emitida pelo servidor web quando algo inesperado ocorre e impede que ele conclua a solicitação do cliente.

As causas comuns do erro HTTP 500 incluem:

Erros de programação: Scripts mal escritos, como PHP, Python, ou JavaScript, podem causar o erro HTTP 500. Um exemplo comum é um arquivo PHP com erros de sintaxe ou lógica, que faz com que o servidor não consiga executá-lo corretamente;
Configuração incorreta do servidor: Arquivos de configuração incorretos ou incompletos, como o “.htaccess” em servidores Apache, podem resultar em erros HTTP 500. Uma permissão de arquivo incorreta também pode gerar esse erro;
Problemas com recursos do servidor: A falta de recursos, como memória insuficiente ou sobrecarga do servidor, pode fazer com que o servidor responda com um erro HTTP 500.

Para corrigir o erro HTTP 500, é necessário:

Verificar os logs de erro do servidor: Os logs de erro geralmente fornecem informações detalhadas sobre a causa do erro. Analisar os logs ajudará a identificar e corrigir o problema;
Revisar os scripts e arquivos de configuração: Verifique os arquivos de código e configuração em busca de erros de sintaxe, lógica ou configuração incorreta e faça as correções necessárias;
Monitorar e otimizar os recursos do servidor: Acompanhe o uso de recursos do servidor e faça ajustes para melhorar o desempenho, como aumentar a memória, otimizar consultas de banco de dados ou balancear a carga do servidor.

501 – Not Implemented (Não implementado)

O código de status “HTTP 501 – Not Implemented (Não implementado)” é um aviso que surge quando o servidor encontra-se desprovido de recursos para atender à demanda do cliente.

Frequentemente, este erro decorre do emprego de um método de solicitação desconhecido ou atípico, como, por exemplo, COPY ou MOVE, cuja finalidade o servidor não foi concebido para suprir.

Outro fator que pode desencadear o erro HTTP 501 é a situação em que um servidor web está em fase de desenvolvimento e ainda não implementou a funcionalidade necessária para processar a solicitação específica.

Tal circunstância pode ser provisória, até que a funcionalidade seja incorporada ao servidor, ou permanente, se a funcionalidade não for planejada para ser implementada.

Para contornar o erro HTTP 501, os desenvolvedores devem estar cientes dos métodos de solicitação padrão e amplamente aceitos, tais como GET, POST, PUT, DELETE e outros.

Evitar métodos não suportados ou personalizados sem a compatibilidade adequada do servidor é fundamental.

Em determinados casos, a solução do problema pode ser alcançada ao entrar em contato com o provedor de hospedagem ou o administrador do servidor para obter informações sobre o suporte a certos métodos de solicitação ou funcionalidades.

Eles poderão fornecer orientações sobre como agir ou mesmo incluir a funcionalidade necessária para atender à solicitação.

502 – Bad Gateway (Gateway inválido)

Ao deparar-se com um status HTTP 502, é crucial entender sua natureza e os fatores variáveis que podem contribuir para o surgimento desse código de resposta.

Como gateway ou proxy, o servidor tem o papel de intermediário entre o cliente e o servidor de origem, funcionando como uma ponte que interliga os dois.

Diversas situações podem desencadear esse código de resposta; em alguns casos, pode haver dificuldades na conexão com o servidor de origem, enquanto em outros, a causa pode residir em configurações equivocadas no gateway ou proxy.

Esses cenários pontuais e contrastantes evidenciam a importância de analisar cuidadosamente cada situação, evitando soluções simplistas e genéricas.

O erro 502, sendo um erro de servidor, indica que o problema está no âmbito interno do servidor intermediário e não no cliente.

Para solucioná-lo, é indispensável que os administradores do sistema ou desenvolvedores investiguem os registros de erro do servidor em questão, a fim de identificar e corrigir a causa do problema.

A título de informação, vale ressaltar que o uso do código 502 é comum quando o servidor atua como gateway ou proxy e enfrenta dificuldades ao processar a requisição.

Contudo, é necessário atentar-se para o fato de que alguns servidores HTTP ou frameworks de desenvolvimento podem retornar códigos de erro mais específicos – como o 504 Gateway Timeout – que apontam para condições particulares.

503 – Service Unavailable (Serviço indisponível)

O código de status HTTP 503 – Service Unavailable (Serviço Indisponível) serve como um alerta, enviado pelo servidor, que revela que, devido a uma sobrecarga ou manutenção, ele se encontra impossibilitado de processar a solicitação do cliente no momento atual.

Diversas razões podem levar à isso.

Um servidor, por exemplo, pode estar temporariamente indisponível devido a um enorme volume de tráfego, problemas de conectividade, ou mesmo uma manutenção planejada.

Tais situações podem ocorrer quando inúmeros usuários tentam acessar um site ao mesmo tempo ou quando se faz necessário reiniciar um servidor para implementar atualizações.

O código 503 funciona, essencialmente, como um canal de comunicação entre o servidor e o cliente.

Ele informa ao cliente que o serviço está indisponível no momento, mas que a solicitação pode ter sucesso em uma tentativa futura.

Em algumas circunstâncias, a mensagem de erro 503 pode fornecer detalhes adicionais acerca da causa da indisponibilidade do serviço, bem como uma estimativa de quando este voltará a operar normalmente.

É fundamental monitorar constantemente os servidores e estabelecer estratégias para prevenir sobrecargas ou interrupções não planejadas.

Se o código de status 503 for recebido, é imprescindível que se forneça ao usuário uma mensagem precisa e informativa acerca do problema.

Alguns servidores HTTP e/ou frameworks de desenvolvimento podem incluir uma mensagem no corpo da resposta ou no cabeçalho Retry-After para informar ao cliente quando o servidor estará disponível novamente.

504 – Gateway Timeout (Tempo limite do Gateway)

O código de status HTTP 504 – Gateway Timeout (Tempo Limite do Gateway) representa um erro específico que indica que o servidor, ao atuar como um gateway ou proxy, não conseguiu obter uma resposta válida de outro servidor dentro do prazo necessário para completar a solicitação do cliente.

Esse código de status ocorre quando um servidor depende de informações provenientes de outro servidor para atender às demandas do cliente.

O erro 504 pode ser resultado de diversas causas, tais como problemas de conectividade entre o servidor e o gateway, atrasos na comunicação entre os servidores envolvidos, problemas de configuração no servidor de origem ou no gateway, além de sobrecarga no servidor de origem.

Em muitos casos, o problema pode ser temporário e se resolver por conta própria após algum tempo.

Quando o erro 504 ocorre, é importante que os desenvolvedores de aplicativos web investiguem a origem do problema e busquem soluções adequadas.

Algumas abordagens para resolver o erro incluem verificar se há problemas de conectividade, revisar as configurações dos servidores envolvidos e monitorar o desempenho do servidor de origem para identificar possíveis gargalos ou sobrecarga.

Além disso, medidas preventivas podem ser implementadas para reduzir a ocorrência do erro 504.

Entre elas estão o ajuste das configurações de tempo limite do gateway, a otimização do desempenho do servidor de origem e a melhoria da infraestrutura de rede para garantir uma comunicação eficiente entre os servidores.

É fundamental que os usuários sejam informados quando ocorre um erro 504, fornecendo uma mensagem clara e informativa sobre o problema e instruções sobre quando tentar novamente.

Isso pode ajudar a minimizar a frustração do usuário e a garantir uma experiência mais satisfatória, mesmo diante de problemas temporários.

505 – HTTP Version Not Supported (Versão HTTP não suportada)

O código de status HTTP 505 – HTTP Version Not Supported (Versão HTTP não suportada) é uma resposta do servidor que indica que a versão do protocolo HTTP utilizada na solicitação do cliente não é suportada pelo servidor.

Esse código de status é geralmente encontrado quando um cliente tenta fazer uma solicitação usando uma versão do protocolo HTTP que não é mais compatível ou está desatualizada em relação à versão usada pelo servidor.

A comunicação eficiente entre cliente e servidor é fundamental para garantir que os aplicativos e serviços web funcionem corretamente.

No entanto, quando a versão do protocolo HTTP utilizada pelo cliente não é compatível com a do servidor, isso pode levar a erros, como o código 505.

Compreender as causas desse erro e implementar soluções adequadas é essencial para garantir a estabilidade e a eficiência dos aplicativos e serviços web.

Uma das razões pelas quais o erro 505 pode ocorrer é a desatualização do software do cliente ou do servidor.

Atualizações de protocolos são comuns, especialmente quando novas versões são lançadas para melhorar a segurança e a eficiência da comunicação entre clientes e servidores.

Por isso, é importante manter os softwares atualizados para garantir a compatibilidade e evitar erros relacionados à versão do protocolo HTTP.

Para resolver o erro 505, deve-se verificar a versão do protocolo HTTP utilizada pelo cliente e pelo servidor e garantir que ambas sejam compatíveis.

Se necessário, pode ser preciso atualizar o software do cliente ou do servidor para uma versão mais recente que suporte a versão do protocolo HTTP em questão.

507 – Insufficient Storage (WebDAV) – (Armazenamento insuficiente)

O código de status HTTP 507 – Insufficient Storage (Armazenamento Insuficiente) é uma resposta do servidor que indica que a solicitação não pode ser processada devido à falta de espaço de armazenamento no servidor.

Essa situação pode ocorrer quando o servidor está sobrecarregado com dados, levando à incapacidade de armazenar informações adicionais ou realizar operações que demandem mais espaço.

A falta de espaço de armazenamento no servidor pode afetar negativamente a performance e a estabilidade dos aplicativos e serviços web, além de gerar problemas para os usuários finais.

Dessa forma, é crucial entender as causas do erro 507 e implementar soluções adequadas para garantir a eficiência e a continuidade dos serviços prestados.

Um dos principais motivos que podem levar ao erro 507 é a má administração dos recursos de armazenamento do servidor.

Isso pode incluir a falta de monitoramento do uso de espaço, a ausência de políticas de limpeza de arquivos temporários ou obsoletos, ou a alocação inadequada de espaço para diferentes serviços e aplicativos.

Para resolver o erro 507, os desenvolvedores de aplicativos web e administradores de sistemas devem, primeiramente, analisar o uso de espaço no servidor e identificar áreas que possam ser otimizadas.

Ações como a exclusão de arquivos temporários, a compactação de dados e a realocação de recursos podem ajudar a liberar espaço e resolver o problema de armazenamento insuficiente.

Além disso, é importante implementar práticas de gerenciamento eficientes para evitar que o erro 507 ocorra no futuro.

Isso pode incluir o monitoramento regular do espaço de armazenamento, a implementação de políticas de backup e arquivamento de dados, e o planejamento de expansões de armazenamento quando necessário.

Por fim, é crucial fornecer aos usuários uma mensagem clara e informativa sobre o erro e as possíveis soluções, como aguardar a resolução do problema pelos administradores do sistema. O que pode ajudar a minimizar a frustração do usuário e garantir uma experiência mais satisfatória, mesmo diante de problemas temporários relacionados ao armazenamento no servidor.

508 – Loop Detected (WebDAV) – (Loop detectado)

O código de status HTTP 508 – Loop Detected (Loop Detectado) é uma resposta do servidor que sinaliza a detecção de um loop na solicitação, o que pode levar a problemas de processamento e instabilidade nos aplicativos e serviços web.

Essa condição ocorre quando uma série de ações ou operações são executadas repetidamente, de forma circular, causando um ciclo infinito e impedindo a conclusão adequada da solicitação.

A detecção de loops pode ser resultado de vários fatores, incluindo erros de programação, falhas na configuração do servidor ou problemas na estrutura dos dados armazenados.

Compreender as causas do erro 508 e implementar soluções adequadas é crucial para garantir a estabilidade e a eficiência dos aplicativos e serviços web.

Um dos principais desafios ao lidar com o erro 508 é identificar a origem do loop e corrigir a causa subjacente.

Os desenvolvedores de aplicativos web devem analisar o código-fonte e os logs do servidor para determinar onde o loop foi originado e implementar correções que evitem a repetição circular das operações.

Além disso, é importante estabelecer boas práticas de programação e configuração do servidor para minimizar a probabilidade de ocorrência de loops.

Isso inclui a utilização de técnicas de programação defensiva, como a verificação de condições de parada e a validação de dados de entrada, bem como a adoção de políticas de monitoramento e auditoria do servidor para identificar e corrigir problemas potenciais antes que causem erros como o 508.

510 – Not Extended (Não estendido)

O status HTTP 510 – Não Estendido é uma resposta do servidor que sinaliza que o cliente precisa complementar a requisição com dados adicionais para que seja processada apropriadamente.

Esse código de status é menos usual e está geralmente associado à expansibilidade do protocolo HTTP por intermédio de mecanismos, como cabeçalhos de requisição extras, que possibilitam ampliar as funcionalidades do protocolo.

Quando um servidor recebe uma requisição que demanda informações suplementares para ser processada, ele pode responder com o código 510 para comunicar ao cliente a necessidade de fornecer esses dados.

Essa resposta indica que a requisição não pode ser finalizada com base nos dados disponibilizados e necessita de uma extensão para ser atendida de forma adequada.

A fim de solucionar o erro 510, os desenvolvedores de aplicações web devem examinar a requisição e identificar quais informações extras são requeridas para seu correto processamento.

Isso pode envolver a adição de cabeçalhos específicos ou a inclusão de informações adicionais no corpo da requisição.

Ademais, é crucial assegurar que a documentação da aplicação ou serviço web esteja em dia e disponibilize informações precisas sobre os requisitos de extensão para os clientes e assim, auxiliar na prevenção de equívocos e garantir que as requisições sejam corretamente estendidas antes de serem encaminhadas ao servidor.

Ao tratar do erro 510, é fundamental proporcionar aos usuários uma mensagem nítida e informativa acerca do problema e das possíveis soluções, como a atualização do aplicativo cliente para inserir as informações adicionais requeridas.

Isso pode colaborar para reduzir a frustração do usuário e assegurar uma experiência mais gratificante, mesmo em face de problemas temporários relacionados à extensão das requisições.

511 – Network Authentication Required (Autenticação de rede necessária)

O código de status HTTP 511 – Autenticação de Rede Obrigatória representa uma resposta do servidor, sinalizando que o cliente precisa se identificar para acessar a rede.

Comumente, esse código surge em redes que demandam autenticação prévia para conceder acesso à Internet ou outros serviços, como Wi-Fi público ou redes corporativas protegidas.

Ao tentar acessar um recurso em uma rede que requer autenticação, o servidor pode retornar o código 511, indicando a necessidade de fornecer credenciais para prosseguir.

Essa resposta visa garantir a segurança da rede, controlando o acesso aos recursos e evitando utilizações indevidas.

Para solucionar o erro 511, os usuários precisam fornecer as credenciais de autenticação solicitadas, como nome de usuário e senha ou um certificado digital.

O processo de autenticação pode variar conforme as políticas de segurança da rede, incluindo mecanismos adicionais como autenticação em duas etapas ou verificação biométrica.

É fundamental que os administradores de rede configurem adequadamente os sistemas de autenticação e assegurem que as informações de acesso sejam disponibilizadas aos usuários autorizados.

Isso pode envolver a emissão de credenciais temporárias para visitantes ou a implantação de sistemas de gerenciamento de identidades, facilitando o controle de acesso e a segurança da rede.

599 – Network Connect Timeout Error (Erro de tempo limite de conexão de rede)

O código de status HTTP 599 – Erro de Esgotamento do Tempo Limite de Conexão à Rede não é oficialmente reconhecido pelo padrão HTTP, porém é adotado por certas implementações de software para sinalizar um erro de esgotamento de tempo durante a tentativa de conexão com o servidor.

Esse erro pode surgir quando o cliente não consegue estabelecer uma conexão com o servidor dentro de um prazo determinado, o que pode ser ocasionado por vários fatores, como problemas na rede, congestionamento de tráfego ou instabilidade do servidor.

Diante de um erro 599, é crucial investigar as possíveis origens do problema para definir a melhor estratégia de solução.

Algumas das possíveis causas e soluções para este erro abrangem:

Falhas na rede: Verificar a existência de problemas na rede, como cabos desconectados, defeitos nos dispositivos de rede ou interrupção nos serviços de internet. Solucionar essas questões na rede pode auxiliar no restabelecimento da conexão com o servidor e eliminar o erro 599;
Sobrecarga de tráfego: O elevado fluxo de tráfego na rede pode provocar lentidão nas conexões e resultar em erros de esgotamento de tempo. Nestes casos, pode ser proveitoso tentar acessar o recurso em um momento de tráfego reduzido ou otimizar o desempenho da rede para lidar com a sobrecarga;
Instabilidade do servidor: Se o servidor estiver passando por problemas de desempenho ou instabilidade, isso pode afetar a habilidade de estabelecer conexões com os clientes. Nestas situações, é essencial que os administradores de sistemas acompanhem e solucionem problemas no servidor, garantindo a estabilidade e a disponibilidade dos serviços;
Configuração inadequada do tempo limite: Caso o tempo limite definido para estabelecer uma conexão seja muito breve, isso pode resultar em erros 599, mesmo quando a rede e o servidor estão funcionando adequadamente. Ajustar o tempo limite de conexão pode contribuir para prevenir erros de esgotamento de tempo em condições normais de operação.

Tabela dos principais códigos de status HTTP

Os códigos de status HTTP listados abaixo são divididos em classes de acordo com a sua função e significado:

Classe do código	Código	Descrição
1xx (Informativo)	100	Continue
1xx (Informativo)	101	Switching Protocols (Protocolos de comutação)
1xx (Informativo)	102	Processing (Processando)
1xx (Informativo)	103	Early Hints (Dicas iniciais)
2xx (Bem-sucedido)	200	Ok
2xx (Bem-sucedido)	201	Created (Criado)
2xx (Bem-sucedido)	202	Accepted (Aceito)
2xx (Bem-sucedido)	203	Non-Authoritative Information (Informações não autorizadas)
2xx (Bem-sucedido)	204	No Content (Sem conteúdo)
2xx (Bem-sucedido)	205	Reset Content (Redefinir conteúdo)
2xx (Bem-sucedido)	206	Partial Content (Conteúdo parcial)
2xx (Bem-sucedido)	207	Multi-Status (WebDAV)
2xx (Bem-sucedido)	208	Already Reported (Já reportado)
2xx (Bem-sucedido)	226	IM Used
3xx (Redirecionamento)	300	Multiple Choices (Escolhas múltiplas)
3xx (Redirecionamento)	301	Moved Permanently (Movido permanentemente)
3xx (Redirecionamento)	302	Found (Encontrado)
3xx (Redirecionamento)	303	See Other (Ver outro)
3xx (Redirecionamento)	304	Not Modified (Não modificado)
3xx (Redirecionamento)	305	Use Proxy (Usar proxy)
3xx (Redirecionamento)	306	Unused (Não utilizado)
3xx (Redirecionamento)	307	Temporary Redirect (Redirecionamento temporário)
3xx (Redirecionamento)	308	Permanent Redirect (Redirecionamento permanente)
4xx (Erro do cliente)	400	Bad Request (Solicitação ruim)
4xx (Erro do cliente)	401	Unauthorized (Não autorizado)
4xx (Erro do cliente)	402	Payment Required (Pagamento requerido)
4xx (Erro do cliente)	403	Forbidden (Proibido)
4xx (Erro do cliente)	404	Not Found (Não encontrado)
4xx (Erro do cliente)	405	Method Not Allowed (Método não permitido)
4xx (Erro do cliente)	406	Not Acceptable (Não aceitável)
4xx (Erro do cliente)	407	Proxy Authentication Required (Autenticação de proxy necessária)
4xx (Erro do cliente)	408	Request Timeout (Tempo de solicitação esgotado)
4xx (Erro do cliente)	409	Conflict (Conflito)
4xx (Erro do cliente)	410	Gone (Perdido)
4xx (Erro do cliente)	411	Length Required (Comprimento necessário)
4xx (Erro do cliente)	412	Precondition Failed (Pré-condição falhou)
4xx (Erro do cliente)	413	Payload Too Large (Carga útil muito grande)
4xx (Erro do cliente)	414	URI Too Large (URI muito grande)

4xx (Erro do cliente)	415	Unsupported Media Type (Tipo de mídia não compatível)
4xx (Erro do cliente)	416	Range Not Satisfiable (Faixa não satisfatória)
4xx (Erro do cliente)	417	Exception Failed (Falha na exceção)
4xx (Erro do cliente)	418	I’m a Teapot (Eu sou um bule)
4xx (Erro do cliente)	421	Misdirected Request (Solicitação mal direcionada)
4xx (Erro do cliente)	422	Unprocessed Entity (WebDAV) – (Entidade não processada)
4xx (Erro do cliente)	423	Locked (WebDAV) – (Bloqueado)
4xx (Erro do cliente)	424	Failed Dependency (WebDAV) – (Dependência com falha)
4xx (Erro do cliente)	425	Too Early (Muito cedo)
4xx (Erro do cliente)	426	Upgrade Required (Atualização necessária)
4xx (Erro do cliente)	428	Precondition Required (Pré-condição necessária)
4xx (Erro do cliente)	429	Too Many Requests (Muitas solicitações)
4xx (Erro do cliente)	431	Request Header Fields Too Large (Campos de cabeçalho de solicitação muito grandes)
4xx (Erro do cliente)	451	Unavailable for Legal Reasons (Indisponível por motivos legais)
4xx (Erro do cliente)	499	Client Closed Request (Solicitação fechada do cliente)
5xx (Erro do servidor)	500	Internal Server Error (Erro interno no servidor)
5xx (Erro do servidor)	501	Not Implemented (Não implementado)
5xx (Erro do servidor)	502	Bad Gateway (Gateway inválido)
5xx (Erro do servidor)	503	Service Unavailable (Serviço indisponível)
5xx (Erro do servidor)	504	Gateway Timeout (Tempo limite do Gateway)
5xx (Erro do servidor)	505	HTTP Version Not Supported (Versão HTTP não suportada)
5xx (Erro do servidor)	507	Insufficient Storage (WebDAV) – (Armazenamento insuficiente)
5xx (Erro do servidor)	508	Loop Detected (WebDAV) – (Loop detectado)
5xx (Erro do servidor)	510	Not Extended (Não estendido)
5xx (Erro do servidor)	511	Network Authentication Required (Autenticação de rede necessária)