Toda vez que uma tarefa é executada em um dispositivo monitorado, o servidor alvo retorna códigos de status HTTP para indicar o status da resposta do servidor.
Esses códigos de status HTTP, ou códigos de erro de rede,aparecerão nos resultados de uma sessão de monitoramento, bem como em notificações de alerta. Esses códigos de status são mantidos pela Autoridade de Números Atribuídos à Internet (IANA) e a lista de códigos mais atual pode ser encontrada aqui.
Usando filtros, você pode remover resultados com códigos de status específicos de suas tarefas, alertas e relatórios. Clique nos documentos de referência do RFC na lista abaixo para obter detalhes completos dos códigos de status.
What é oProtocolo HTTP?
Toda vez que um usuário visita um site, ele está fazendo uma solicitação de seu navegador/cliente para um servidor que responde com os recursos que solicitou . Todas essas solicitações seguem o padrão HTTP (Hypertext Transfer Protocol). O HTTP protocolo, que é tecnicamente parte da camada de aplicação dentro do conjunto Protocolo da Internet, é apenas um muitos protocolossob opacote IP. O O protocolo HTTP é a espinha dorsal da Internet usada para comunicação e envio de dados entre clientes e servidores. Alguns dos outros protocolos de Internet mais comuns você muitos se depararam incluem o seguinte:
Protocolos de camada
de aplicativos
o aplicação laTEr especifica os protocolos e métodos de interface usados por clientes e servidores. ela É a camada waqui o interação entre pessoa e computador ocorre anod informações pode ser enviado para frente e para trás a partir de um servidor através de um cliente/navegador e interpretado e exibido para usuários.
- DNS
:
O protocolo DNS ( Domain NameSystem) converte nomes de domínio em endereços IP legívels por humanos para navegador para que os recursos possam ser carregados.
- FTP
: O protocolo FTP (File TransferProtocol) é usado para transferir arquivos entre um navegador e um servidor within uma rede de computador.
- SMTP
: O protocolo SMTP (SimpleMail Transfer Protocol) é usado para enviar um e-mail nd receive entre remetentes e receptores em uma rede.
- TLS/
SSL
: O protocolo SSL (SecureSockets Layer) foi oficialmente preterido em 2015. O TLS (Transport Layer Security) foi introduzido em seu lugar para fornecer uma maneira segura de se comunicar através de uma rede.
- IMAP
: O protocolo IMAP (Internet Message Access Protocol) é usado para gerenciar e receber mensagens de um servidor de e-mail. Ao contrário do SMTP, você não pode usar o protocolo IMAP para enviar mensagens de e-mail.
- POP
: O protocolo POP (Protocolo dos Correios) é como o IMAP, mas a diferença é que o protocolo POP permite que o usuário receba mensagens de um servidor de e-mail, mas a mensagem é então excluída do servidor de e-mail. O protocolo IMAP pode sincronizar mensagens em vários dispositivos. Depende realmente de como você quer que os usuários acessem seus e-mails.
- SIP
: TheSIP (Protocolode Iniciação de Sessão) é um protocolo de sinalização que é usado em voz em tempo real, vídeo e aplicativos de mensagens. SIP é o protocolo que é usado para habilitar edeploy VoIP (Voice Over Internet Protocol) Serviços. SIP também é usado em conjunto com outros protocolos, como SDP(Session Description Protocol), UDP, TCP e TLS para transportar dados e mídia de sessão.
Protocolos de camada
de transporte
A camada de transporte lida com a transmissão de dados,que também inclui o TCP e o UDP protocolos, e garantir que os dados são enviados e recebidos corretamente e prontamente.
- Tcp: O protocolo TCP (Transport Control Protocol) é usado para garantir que as transmissões entre um cliente e um servidor sejam seguras e que o comunicação inteira foi processada. por exemplo quando um servidor envia de volta um arquivo devido a uma solicitação do cliente, a camada HTTP se comunicará com a camada de transporte para configurar e enviar o arquivo solicitado. O protocolo TCP gerencia o processo de montagem e envio (e às vezes re-envio, se necessário) os pacotes de dados e garante que todos os pacotes foram enviados e entregues.
- UDP
: O protocolo UDP (User Datagram Protocol) permite que os aplicativos enviem mensagens, chamadas datagramas, para outros hosts em uma rede.
Protocolos de camada
de Internet
A camada de internet, também chamada de camada de rede, é encarregada de enviar e remontar a rede packets da maneira mais eficiente usando endereços de rede/endereço IP para enviar pacotes para o seu destino.
- IP
: O IP (Internet Protocol) protocol, juntamente com o protocolo TCP, é um conjunto de requisitos que definem como os dados são enviados pela Internet.
- ICMP
: O protocolo ICMP (Internet Control Message Protocol) é um protocolo de rede que permite que dispositivos de rede, como roteadores,ajudem a diagnosticar problemas de comunicação. O protocolo do ICMP não se preocupa com a troca dados,em vez de seu propósito é tercerteza se os dados estão chegando ao destino pretendido.
Protocolos de camada
de link
A camada de link é ogrupode métodos de comunicação que gerencia a transmissão de dados entre dispositivos físicos e uma rede.
- ARP
: Oprotocolo/procedimento ARP (Address Resolution Protocol) para mapear endereços de rede IP para um endereço de um dispositivo de hardware físico, também conhecido como endereço MAC.
- MAC
: O protocolo MAC (Controle de Acesso Médio) dá aos dispositivos de hardware seu número de identificação único. Ele fornece uma maneira para as redes para connect e comunicar-se com dispositivos.
- Wi-Fi
: O protocolo Wi-Fi (Wireless Fidelity), que é um dos protocolos em que todos nós confiamos para o dia a dia, é um grupo de protocolos de rede sem fio que é usado para se conectar ao acesso à Internet e LANs (Redes locais).
Quais são os códigos de status e por que são importantes?
Há até extensões do Protocolo HTTP, que includes HTTPS (Hypertext Transfer Protocol Secure) e WebDAV (Web-based Distributed Authoring and Versioning),que discutiremos mais dentro dos códigos de status HTTP abaixo. Quando um cliente faz uma solicitação ao servidor, os códigos de status avisam se a solicitação foi bem sucedida, falhada ou algo diferente. Os códigos de status são mantidos pelo Autoridade de Números Atribuídos à Internet, ou IANA, e inclui códigos de status da Força-Tarefa de Engenharia da Internet (IETF) e da Internet Society (ISOC). Conforme definido pela IANA organizaçãoTaqui estão cinco classificações de bacalhau de status HTTPEs:
1xx: Informational – Solicitação recebida, processo contínuo
2xx: Sucesso – A ação foi recebida com sucesso, entendida e aceita
3xx: Redirecionamento – Outras medidas devem ser tomadas para concluir a solicitação
4xx: Erro do cliente – A solicitação contém sintaxe ruim ou não pode ser cumprida
5xx: Erro do servidor – O servidor não cumpriu uma solicitação aparentemente válida
Indivíduos e
engenheiros
regularmente
propor novos códigos de status através de Pedidos de Comments (RFC), e o IETF revisará, adotar, e aposentar status Códigos conforme necessário.
Códigos de status http explicados
As informações abaixo fornecem uma visão geral de todos os códigos de status HTTP mais comuns, bem como os códigos de status HTTP que a maioria das pessoas raramente nunca vê ou sequer sabe existir. Como mencionamos, muitos códigos de resposta nunca são vistos pelos usuários, pois são visualizais apenas dentro da rede.
O primeiro dígito do código de status identifica a classe; no entanto, os dois dígitos segundos não desempenham qualquer papel na definição do código de status para um tipo específico de mensagem/resposta. Dentro desses grupos de classificação, pode haver vários códigos de status, e alguns grupos têm mais códigos de status do que outros. E embora existam oficialmente mais de 60 códigos de status únicos, a maioria das pessoas só vai regularmente encontrar um punhado ou dois ao longo do tempo.
A maioria desses códigos de status são interpretados e processados nos bastidores. Você também verá que existem grupos de códigos que são rotulados como “Não assinados”. Embora a maioria dos códigos de status que vemos hoje foram padronizados e têm não alterados ao longo do tempo, esses números não assinados deixam espaço para criar códigos de status adicionais, conforme necessário. Além disso, embora alguns dos códigos de usuário não assinados não façam parte do padrão HTTP (Hypertext Transfer Protocol), existem empresas que os usam como resposta personalizada do servidor para usuários, permitindo que as empresas melhorem problemas que os usuários possam estar enfrentando. Clique nos links de documentos de referência do RFC na lista abaixo para obter detalhes completos do código de status HTTP específico.
Uma lista completa e uma visão geral dos códigos de status HTTP
1
xx
Código de Status
s
:
Informativo
O 1Xx-códigos de status HTTP de nível dizem aos usuários que a solicitação que eles ter feito tem sido recebido, mas ainda está processando. Os códigos de status 1xx fazem não necessariamente significa que há um problema, ele eus apenas lá para deixar-lhe algo ainda está no processo de completar. incluso neste grupo são apenas um punhado de 1Xx códigos que os usuários podem encontrar e precisa estar ciente.
100
: Continue
Status code 100 Continue informa que uma parte do pedido foi recebida sem problemas. em neste ponto tudo é Ok, mas. ainda é em processo. Se o parte restante do pedido não é rejeitado, o saqueR enviará uma resposta final uma vez que a solicitação foi concluídaEd. Se os cabeçalhos HTTP foram rejeitados, isso garante que o cliente faça não enviar um pedido para o corpo. No entanto, se a solicitação fez não containum campo de cabeçalho, então o navegador simplesmente ignorará as response. See RFC7231, Seção 6.2.1
para mais informações.
101: Troca de protocolos
Houve muitos protocolos HTTP criados desde o humilde início da Internet. A primeira versão documentada do protocolo HTTP foi HTTP 0.9. A iteração atual é HTTP 2.0 ou HTTP/2. Código de status 101 Protocolos de comutação indica que o servidor aceita a solicitação do cliente para mudar para um protocolo HTTP diferente através do campo de cabeçalho Upgrade. Quando um navegador faz uma solicitação para uma página, ele pode receber o Código de status HTTP 101 e, em seguida, o cabeçalho upgrade, whiCh Indica o corte está mudando para uma versão HTTP diferente. Finalmente, tele suposição é que o servidor vai concordar em mudar protocolos apenas quando é benéfico, como atualizar/mudar para um protocolo mais novo versus um mais antigo. See RFC7231, Seção 6.2.2
para mais informações.
102: Processamento
Um status code 102 O processamento só é usado com WebDAV (Web Distributed Authoring and Versioning). A maioria das páginas são somente lidas. WebDAV é uma extensão do HTTP protocolo que dá aos clientes a capacidade to editar conteúdo remotamente e transferir arquivos. o WebDAV protocolo foi criado para dar aos usuários a capacidade de colaborare em arquivos com outros, gostar Dropbox ou Google Drive. Código de status 102 é umn código de resposta provisória, dizendo ao cliente que o servidor aceitou a solicitação completa, mas não completou o pedido. Este código de status HTTP só é enviado pelo servidor se um solicitação está levando mais de 20 segundos. ver RFC2518, Seção 10.2
para mais informações.
103: Dicas iniciais
Códigos de status 10
3 Dicas Iniciais
estão atualmente na
avaliação/
fase experimental. Este código de status seria usado ao pré-carregar conteúdo/recursos externos. O protocolo HTTP/2 permite que o conteúdo seja empurrado para acelerar a entrega, para que os desenvolvedores web pudessem empurrar conteúdo específico enquanto esperam por outros recursos externos para carregar. Isso é benéfico da perspectiva do usuário final, pois minimiza o tempo de carga percebido. Tseu código de resposta HTTP seria indicar para um navegador que o servidor é vai enviar uma resposta final
,juntamente com os campos de cabeçalho incluídos na resposta.
S
ee
para mais informações
104-199: Sem assinatura
Os códigos de status 104 a 199 estão atualmente não assinados.
Código de status 2xx: Sucesso
Os códigos de status HTTP de nível 2xx indicam que a solicitação do cliente ao servidor foi bemrecebida eprocessada. Ao contrário dos códigos de status 4xx, códigos de status 2xx são o que você quer obter. Como códigos de status 1xx, os códigos de status 2xx são processados nos bastidores e raramente vistos pelos usuários, a menos queestejam usando ferramentas de desenvolvedor ou SEO para ver todas as respostas HTTP de uma página.
200: OK
Um dos códigos de status HTTP mais amplamente utilizados, o código de status 200 OK é usado para indicar que uma solicitação foi recebida,processada e bem sucedida. No entanto, dependendo do método de solicitação utilizado (GET, HEAD, POST, PUT, DELETE, OPTIONS, TRACE). Por exemplo, se a solicitação for uma solicitação GET, a resposta incluirá o recurso. Se ele É qualquer um dos outros remissões, a resposta incluirá o resultado das ações. o 200 status código é um de mais de 10 outros códigos de resposta que também é armazenado em cache, o que significa que ele pode ser salvo e recuperado através do cliente, de modo a não ter que fazer outra solicitação para o servidor em o futuro. SEe RFC7231, Seção 6.3.1 para mais informações.
201: Criado
Um código de status criado em 201 é como um código de status OK de 200, no entanto, um código de status de 201 significa que uma solicitação foi processada com sucesso, e ela retornou,ou criou, um recurso ou resources no processo. um O código de status de 201 é normalmente usado para solicitações PUT. Por exemplo, when uma solicitação PUT é usada, um novo recurso écriado na URL especificado na solicitação. Se houver um código de status de 201 em uma solicitação POST, significa que um recurso foi criado em um ponto final/localização de API diferente. See RFC7231, Seção 6.3.2
para mais informações.
202: Aceito
o 202 aceitado status código significa que o servidor tem recebeu um pedido de processamento, e ele eufoi aceito, mas o pedido tem não foi concluído. Ele também faz não significa que o pedido será eventualmente aceito, pois vai depender de quando o processamento real ocorre. Esse tipo de solicitação é normalmente vista em APIs onde um processo de lote é executado uma vez por dia. desde ali É nenhuma maneira de HTTP para se comunicar depois de um pedido foi bem sucedido ou conexão do usuário foi fechada, uma API pode enviar um e-mail para um usuário notificante eles que o processo foi bem sucedido. SEe RFC7231, Section 6.3.3 para mais informações.
203: Informações não autorizadas
O código de status de informações não autorizadas de 203 é normalmente usado por um Proxy HTTP ou terceiro. O proxy, sentado entre o cliente e o servidor pode alterar as respostas antes de chegar ao cliente. Para indicar que algo foi mudado durante o processo, um código de status 203 é usado. No entanto, a desvantagem deste método é que it eus não é possível saber o que o código de status original era se um proxy mudou algo na resposta. Uma solução sugerida é usar um cabeçalho de aviso juntamente com um 214 status código que é usado Para indicare que houve uma mudança ou modificação na response. Usando o warning cabeçalho permite que o código de status original para passou through. See RFC7231, Section 6.3.4
para mais informações.
204: Sem Conteúdo
Um código de status de 204 Sem Conteúdo Indica que a resposta foi entregue com sucesso pelo servidor e cumprida e nenhum cont maisent deve ser enviado no corpo da resposta. Como exemplo, se a solicitação for enviada no formulário em uma página, uma vez que o response é enviado, o cliente/navegador não é suposto mudar a visão, o que significa que a forma deve não ser atualizado ou direto Usuários para um novo pagecstasy. Não conteúdos adicionais devem ser substituídos ou aparecer em termos da perspectiva do usuário. See RFC7231, Section 6.3.5
para mais informações.
205: Redefinir o conteúdo
Como o 204 No Content status code, um código de status 205 Conteúdo de redefinição indica que o servidor enviou a solicitação com sucesso e requer que o agente do usuário atualize/reinicie a exibição para o seu ouiestado ginal. Se usarmos o exemplo de um formulário em uma página, uma vez que o usuário completa e enviaro formulário, ocliente/navegador deve limpar o formulário de volta ao seu estado original para que um usuário possa tomar furtsua ação. um O código de status 205 pressupõe que nenhum conteúdo adicional será fornecido. See RFC7231, Seção 6.3.6
para mais informações.
206:
Conteúdo
Parcial
Um 206 O código de status de conteúdo parcial pode ser usado para uma variedade de solicitações e normalmente Indica que o servidor cumpriu um parcial solicitação de um recurso. Por exemplo, se um cliente está apenas procurando por um específico porção, ou alcance, de um específico recurso ou página. Outro exemplo de onde um 206 status código é usado é em vídeo. Um cliente só pode carregar vídeo em pedaços como não ter que esperar o vídeo para buffer ou carga, ajudando a evitar uma experiência negativa do usuário onde um usuário teria que esperar mais antes do vídeo ser reproduzido. Esta é a melhor prática normal entre o reprodutor de vídeo HTTPs para evitar largura de banda e problemas de latência percebidas. See RFC7233, Seção 4.1
para mais informações.
207: Multi-Status
o 207 Multi-Status status código Fornece status para vários processos independentes e usado por servidores WebDAV. A mensagem/resposta padrão é uma mensagem de texto/XML. ela Indica que várias operações ocorreram e que o status para cada operação pode ser visto no corpo do response. Os códigos de status podem variar entre qualquer uma das cinco categorias. Os códigos de resposta variam dependendo do número de submissões. Ao contrário de outros 200 status códigos, um código de status 207 não confirmar que o processo foi bem sucedido. O cliente precisa visualizar o corpo de cada solicitação para determinar se foi bem sucedido ou não. See RFC4918, Seção 11.1
para mais informações.
208: Já relatado
o 208 Já relatado status código é outro código de status usado dentro da extensão WebDAV. gostar o 207 status código, ele permite que um cliente/navegador indicar para o servidor que um recurso já foi processado. Quando um cliente pede recursos, pode ser possível que uma resposta inclua recursos duplicados, o que significaria que os mesmos recursos seriam enviados várias vezes, o que é redundante. o A resposta ao status 208 evita a possibilidade de processamento e repetição a mesma resposta. Código de status 208 Respostas só aparecerá no corpo de resposta e nunca como uma resposta HTTP real. See RFC5842, Seção 7.1
para mais informações.
209-225: Sem assinatura
Os códigos de status 209 a 225 estão atualmente não assinados.
226:
IM
Usado
Um código de status usado de 226 IM (Manipulações de instância) é usado para indicar que um servidor concluiu uma solicitação GET para um recurso,mas a resposta é a representação de uma ou várias manipulações de instância que foram aplicadas à instância atual. Dentro do protocolo HTTP há uma extensão chamada codificação Delta em HTTP que é suportada no lado do servidor. Se isso é implemented, o cliente pode solicitar alterações na versão em cache, e o servidor enviará as alterações em vez de re-enviar toda a fonte de re-fonte novamente. Para ser capaz de implementar esse recurso, a solicitação cliente/navegador precisa especificar qual tipo IM suportado. Se o servidor suportar esse recurso também, ele responderá com o Código de status 226 e as mudanças. Se um 200 código de status é enviado de volta, o que indica que o recurso não é suportado. See RFC3229, Seção 10.4.1
para mais informações.
227-299: Sem assinatura
Os códigos de status 227 a 299 estão atualmente não assinados.
3xx: Redirecionamento
Os códigos de status 3xx são usados em casos de redirecionamento de URL. Os sites estão sempre mudando e evoluindo, então pode haver momentos em que os marketers precisam direcionar os usuários para uma página atualizada ou diferente. Redirecionamentos ajudam a aliviar os usuários de ter que procurar o que eles estão procurando e manter sua classificação em mecanismos de busca. As ações de redirecionamento podem ser realizadas automaticamente pelo navegador ou podem exigir interação adicional dos usuários. Os códigos de status 3xx HTTP são vitais para SEO (Otimização do Mecanismo de Busca) e experiência do usuário, bem como dizer aos mecanismos de pesquisa que conteúdo você deseja que eles engatinham e indexem. euf não devidamente implementado, os usuários podem ser direcionados para um local não intencional,o que pode resultar em um código de status 4xx e pode afetar as pontuações de qualidade do SEO.
300: Múltiplas Escolhas
O código de status 300 Escolhas Múltiplas indica que um resource se moveu e pode redirecionar para vários locais. Neste caso, o usuário deve decidir qual recurso usar. O servidor pode indicar uma escolha preferida e que deve ser Indicado no cabeçalho campo onde o agente do usuário poderia redirecionar para a escolha preferida automaticamente. Em uso prático, tseu código de status raramente é usado, pois não há uma maneira padronizada de escolher entre múltiplas respostas. SEe RFC7231, Seção 6.4.1 para mais informações.
301: Movido permanentemente
Um código de status 301 movido permanentemente é utilizado para indicar que um recurso de destino foi movido para um local permanente. O código de status 301 diz ao navegador/cliente para usar este novo local ou URL daqui para frente no cabeçalho. Junto com o 301 status código, a nova URL será dado na resposta bem como atualizar quaisquer URLs no anterior location(s), juntamente com a atualização para a nova URL. SEe RFC7231, Seção 6.4.2 para mais informações.
302: Encontrado
Um código de status 302 encontrado indica a um cliente/navegador que um recurso que eles estão acessando está temporariamente localizado sob um local diferente. Ao contrário do código de status 301, um 302 código de status indica um movimento temporário, de modo que o cliente não deve automaticamente atualizar sua Links para o novo local, como, novamente, eus significava ser temporário. Um exemplo de onde o 302 status código deve ser usado se houver are múltiplo URLs, mas eles poderia ser servido em línguas diferentes. Um usuário pode chegar a URL específica, mas o cliente pode redirecioná-los automaticamente para tele página adequada com base em suas configurações de navegador e usar este on visitas subsequentes. É ié observou que, em alguns casos, os navegadores podem alterar uma solicitação do POST para GET. No caso de que esta ação é não favorável, um código de status 307 deve ser usado. See RFC7231, Seção 6.4.3
para mais informações.
303: Veja outros
Um código de status 303 Ver Outro indica que um servidor estará redirecionando o cliente/navegador para outro recurso. O recurso será indicado como uma URL do campo de cabeçalho. Ao contrário dos códigos de status 301 e 302, ele faz não significa que um recurso tem temporaRily ou permanentemente mover, eles intenção é especificar o URL para onde a resposta ao specifeuC solicitação pode ser fundar através de uma solicitação GET. 303 códigos de status devem não ser armazenado em cache, no entanto, a resposta ao subsequente solicitação pode ser armazenado em cache. Um uso típico do 303 status código seria para garantir que os usuários do não acidentalmente reenviar dados de formulário através de uma solicitação POST. Eles devem ser direcionados para uma nova página. Se não, eles podem clicar sem saber o botão de trás em seu navegador, que podepedir-lhes para reenviar novamente, o que leva a unnecessary duplicate submissões. See RFC7231, Seção 6.4.4
para mais informações.
304: Não Modificado
Um código de status de 304 Não Modificado é enviado em resposta a uma solicitação condicional GET ou HEAD. Clientes/navegadores podem enviar uma solicitação condicional,como Se-match
, Se-Nenhum-Match
, Se-Modificado-Desde
, Se-Não Modificado-Desde
, ou If-Range
, perguntando se um recurso específico foi modificado desde uma data/hora específica. este É feito apenas se o cliente já acessou, baixou e salvou o recurso anteriormente. Se foi modificado desde aquela data/hora específica acessada pela última vez, o servidor retornará um código de status OK de 200 OK. Se ele tem não foi alterado desde essa data/hora, o 304 status código é enviado como a resposta, Indicando que o recurso salvo deve ser servido uma vez que tem não Sido modificado desde a última vez que foi acessado. SEe RFC7232, Seção 4.1 para mais informações.
305: Use proxy
O código de status proxy 305 usa um código destatus preterido que não é mais usado devido à consideração de segurança. ela foi usado para ndicate a um cliente que o resource que eles estavam acessando deve ser acessado através de um proxy. Para obter mais informações sobre o código de status proxy 305 Use, consulte RFC7231, Seção 6.4.5
306:
Nãousada
Como o código de status 305, o status 306 Não-US era originalmente conhecido como Switch Proxy. o 306 código de status foi usado em um anterior especificação. Sua intenção era ser usado como em indicação ao cliente de que o subsequente requests para um recurso deve usar o proxy que foi especificado. Isso foi considerado como uma questão de segurança, por isso não é mais usado. Para obter mais informações sobre o código de status 306 NãoUsed, consulte RFC7231, Seção 6.4.6
307: Redirecionamento Temporário
gostar o código de status de redirecionamento 302 encontradoTele 307 Redirecionamento Temporário status código Indica ao cliente/navegador que um recurso ou documento está disponível em um diferentetemporário URL e retorna essa URL. Uma vez que o redirecionamento é temporário e pode mudar, o navegador/cliente deve continuar a acessar a URL atual para subsequente Solicitações. A principal diferença entre o 302 status código e o 307 status código é que o 307 status código não permite alterar solicitações de um Postar solicitação a um Obter pedir, então se o cliente solicitou solicitação POST, ele será redirecionado e iniciar o pedido POST novamente. SEe RFC7231, Seção 6.4.7
308: Redirecionamento Permanente
Um código de status de redirecionamento permanente 308 é um código de status em cache (a menos que os controles de cache sejam implementados) que indica que um recurso de destino está agora localizado em uma URL permanente e subsequent solicitações devem ser direcionadas para essa URL também. Além disso, o cliente deve atualizar qualquer velhos marcadores para o novo local. O código de status 308 é muito semelhante ao código de status 301, no entanto, se um código de status 308 for enviado, o client tem que iniciar e enviar a mesma solicitação no local alvo. um 301 código de status não faz t tem que fazer isso. A maioria dos navegadores/clientes altera a solicitação POST para um REQ GETuest. See RFC7238, Seção 3
para mais informações.
309-399: Sem assinatura
Os códigos de status 309 a 399 estão atualmente não assinados.
4xx: Erro do cliente
A classificação com mais códigos de status HTTP, Os códigos de status 4xx HTTP não são o que você quer que seus usuários vejam. Qualquer código de status que começa com um 4 significa que há um problema com o cliente. Os códigos de status 4xx geralmente são gerados se uma página tiver sido excluída e não redirecionada, ou algo inserido incorretamente dentro de uma URL ou link. Se os usuários recebem um temido código de status 4xx, isso significa que há um problema com o cliente/navegador recebendo informações do servidor. estes são erros que os usuários vão ver aparecer em sua tela e criar uma experiência negativa do usuário,levando a um pouco de frustração e eles procurando em outro lugar. Se os mecanismos de busca rastrearem seu site e receberem um erro 404, por exemplo, isso aparecerá como um erro no relatório. um poucos 404 erros são bons e os mecanismos de busca não necessariamente os vêem como uma coisa negativa,mas um 404 que redireciona para um 404 poderia impacte negativamente seu SEO. Não só isso, se a página em questão for usada para impulsionar o tráfego ou as vendas, isso pode levar a perdas em receitas potenciais.
400: Pedido ruim
Um pedido de 400% código de status de erro significa que o servidor não pode processar a solicitação devido a um problema do cliente. Isso pode ser devido a qualquer número de razões, como um arquivo ser muito grande, sintaxe ruim, uma URL inválida, ou algum outro problemausado porum aplicativo deterceiros, e é por isso que o código de status 400 às vezes é usado como um código de status catch all, mesmoque haja um problema no lado do servidor. Isso pode tornar a solução de problemas um 400 status código um pouco mais demorado e difícil, no entanto, juntamente com o 400 status erro de código e informações de cabeçalho, tele servidor pode fornecer adicional resposta ao longo sagacidadeh, que pode ser exibido para o usuário para ajudar identificar a questão e facilitar o processo de solução de problemas e diagnóstico do erro. SEe RFC7231, Seção 6.5.1 para mais informações.
401: Não autorizado
Um erro não autorizado 401 o código de status indica que a solicitação não inclui as credenciais de autenticação apropriadas, a authsedutora falhou,ou o usuário deve fazerlogin. O cliente requer autenticação do servidor. Os termos autorizados e autenticados são frequentemente usados de forma intercambiável, mas significam coisas separadas. um código de status de 401 é strictly preocupado com autenticação. Nos casos em que você gostaria de informar um cliente que eles não são permitidos Absolutamente, então um código de status de 403 deve ser implementado. umccording à especificação, o 401 status código também deve incluir o WWW-Authenticate cabeçalho do servidor resposta, Indicando ao cliente que esquema de autenticação ou método o servidor réquirEs. SEe RFC7235, Seção 3.1 para mais informações.
402: Pagamento obrigatório
Originalmente criard como parte de uma maneira de permitir potencial métodos de pagamento digitais futuros,o erro exigido de pagamento 402 código de status é oficialmente reservado para uso futuro, mas usou alguns limitados, mas raro, situações. Para obter mais informações sobre o código de erro exigido pelo pagamento 402, consulte RFC7231, Seção 6.5.2
403: Proibido
O 403 O código de status de erro proibido indica que a solicitação do cliente foi compreendida, mas o servidor não irá autorizá-lo,de modoque o clientenão pode acessá-lo. O servidor pode tornar conhecido o razão que wiii não autorizar a solicitação dentro da resposta, que pode ser devido a várias razões como senha incorreta ou nome de usuário. Ao contrário do 401 status código, que requerem autenticação, um 403 status código pode indicar que o cliente realmente não tem autorização para acessar esses recursos, de modo a autenticação neste caso É não possível. SEe RFC7231, Seção 6.5.3 para mais informações.
404: Não Encontrado
Um dos códigos de status mais comuns e infames encontrados pelos usuários e desenvolvedores, o 404 Não encontrado erro código de status Indica que o recurso Necessário do servidor faz não existir ou é nonão disposto a fornecê-lo ao cliente. um 404 status código não vai indicar se thecstasy falta de fornecer o recurso é temporariamente ou permanentemente,mas o cliente pode fazer subsesolicitações de quent para acessá-lo. Nos casos em que se sabe que os recursos se foram permanentemente, o código de status 410 deve ser usado. 404 códigos de status, por padrão, também são armazenados em cache, a menos que outros controles de cache areinplace. See RFC7231, Seção 6.5.4
para mais informações.
405: Método não permitido
O código de status de erro 405 não permitido indica que um recurso específico solicitado pelo cliente não é suportado por o servidor. O método 405 não permitido é gostar o 403 Paracódigo de status proibido, no entanto, o 403 status código Indica que o recurso pode estar disponívelela eus apenas que o cliente faz não ter a autorização necessária para realizar a solicitação. Juntamente com o 405 Método Não Permitido status, o servidor deve indicar o appropriate e Suportado Métodos para o recurso alvo. Para obter mais informações sobre o código de erro 405 Method Not Allowed, consulte RFC7231, Seção 6.5.5
406: Inaceitável
Como o código de status de erro 405 Method Not Allowed, o código de erro 406 Não Aceitável indica que não há suporte para uma solicitação específica. Neste caso, ele406 Código de status Inaceitável indica que o servidor entendeu a solicitação, mas a resposta não é suportado ou compreendido pelo cliente. Um cliente pode solicitar versões específicas de um recurso no cabeçalho, como A-IM ou Aceitar linguagem, entre outros, mas se o servidor faz não apoiá-lo, ele responde com o código de status 406 Não Aceitável. O servidor pode responder com uma lista de recurso apropriado identificadores que o cliente pode escolher De. SEe RFC7231, Seção 6.5.6 para morecstasy informação.
407: Autenticação proxy necessária
A autenticação proxy 407 necessária erro scódigo tatus é gostar o código de status 401 não autorizado, no entanto, no caso de um 407 status código a fim de use um proxy, o cliente deve primeiro ser autenticado. O proxy deve retornar o método de autenticação. Não tão comum hoje devido ao surgimento de VPNs, proxies atuam como intermediários entre os usuários/clientes e a Internet, permitindo que os usuários acessem recursos mais rapidamente, como o conteúdo é tipicamente Cache, e pode também fornecer uma camada de segurança e anonimato para os usuários. Para obter mais informações sobre o código de erro exigido para autenticação proxy 407, consulte RFC7235, Seção 3.2
408: Solicitar tempo limite
Um código de status de erro de tempo limite de solicitação 408 significa que o servidor não recebeu uma solicitação do cliente em um período de tempo especificado. Uma solicitação atrasada do cliente pode ser devida por uma variedade de razões, como uma conexão lenta ou quebrada. Uma vez que esse tempo tenha passado, o status de timeout de solicitação 408 é enviado pelo servidor e o usuário/cliente pode ressarender a solicitação novamente. Para obter mais informações sobre o código de erro de tempo limite de solicitação 408, consulte RFC7231, Seção 6.5.7
409: Conflito
Um conflito 409 erro código de status Indica que o pedido do cliente poderia noT ser processado devido a um conflito com o servidor. O pedido do cliente foi bom, mas não há Estava problemas no lado do servidor que impedem que a solicitação seja executada. Um exemplo disso poderia ser se houvesse um pedido para que um arquivo específico fosse editado, excluird, ou criado pelo usuário, mas essas funcionalidades não são permitidas. Juntamente com a resposta 409, o servidor deve retornar instruções sobre como o usuário pode resolver esse problema ou indicare por que o problema é ocorrer g. See RFC7231, Seção 6.5.8
para mais informações.
410: Foi-se
Como o código de status de erro 404 Não Encontrado que cobrimos anteriormente, ocódigo de status t he410 Gone indica que o recurso que o cliente está solicitando foi removido e não está mais disponível no servidor. no mais informações são fornecidas em termos de redirecionamento de URL ou onde acessar o recurso. Foi removido indefinidamente. Para obter mais informações sobre o código de erro 410 Gone, consulte RFC7231, Seção 6.5.9
411: Comprimento necessário
O código de status de erro necessário de 411 comprimento indica que o servidor não permite a solicitação do cliente devido a uma solicitação predefinida do corpo de ctent length. A solicitação pode ser repetida pelo cliente se um cabeçalho válido de duração de conteúdo for especificado na solicitação de recurso subsequente. Para obter mais informações sobre o código de erro necessário de comprimento 411, consulte RFC7231, Seção 6.5.10
412: Falha na pré-condição
Solicitações condicionais ao servidor são permitidos como parte do protocolo HTTP. Se o direito condições são atendidas na solicitação, a solicitação é executada e processada pelo servidor. Um código de status de erro de falha pré-condição 412 significa que uma ou várias condições no cabeçalho de solicitação falharam. Por exemplo, isso pode ser usado na solicitação GETs umnd um solicitação condicional é utilizado Para retransformar o recurso apenas se esse recurso has mudou. Para obter mais informações sobre o código de erro de falha pré-condição 412, consulte RFC7232, Seção 4.2
413: Solicite entidade muito grande
o 413 Entidade de Solicitação Muito Grande erro código de status Indica que o servidor wmal não aceitar e processar a solicitação due ao pedido corpo sendo maior do que o servidor vai permitir ou pode processo. Tais exemplos incluem o upload de um arquivo onde o arquivo excede o máximo tamanho de upload definido pelo servidor ou quando o número máximo de uploads tiver sido excedido. Nos casos em quee 413 Solicitar entidade muito grande erro ocorre, o servidor pode fechar a conexão completamente para evitar que o cliente continuando a enviar o pedido. Em alguns casos, it eus provavelmente o servidor permitiria que o cliente rejulásse a solicitação, seeus uma condição temporária, e deve incluir essa mensagem de volta para o cliente. However, ele eus possível que a solicitação poderia fazer com que o próprio servidor se esgotasse de físico espaço em disco. Neste caso, o erro de armazenamento insuficiente 507 é a resposta que o cliente deve receber de volta. See RFC7231, Seção 6.5.11
para mais informações.
414: URI Muito Tempo
Não é uma resposta muito comum do servidor, o código de status de erro URI Muito Longo 6 significa que o servidor recusou a solicitação do cliente devido ao A URL é mais longa do que o servidor pode processar. manowsers e mecanismos de busca colocam limites no comprimento dos URLs, em parte para evitar ataques DDoS ou erros de código,mas o caminho de uma URL ou HTTP não têm limites explícitos. Então, se limit excede o que é definido pelo servidor, o erro 414 URI Too Long ocorrerá. Para obter mais informações sobre o código de erro URI Too Long 414, consulte RFC7231, Seção 6.5.12
415: Tipo de mídia sem suporte
O código de status de erro do tipo de mídia sem suporte 415 indica que o servidor não pode processar o órgãode solicitação , ou parte do órgãode solicitação , devido a um formato de mídia semsuporte. Mesmo que a solicitação do cliente seja suportada, o erro 415 pode ser devolvido se houver conteúdo não suportado no corpo da solicitação. Um código de erro tipo de mídia sem suporte 415 é como o código de status 406 Não Aceitável. A diferença é que um código de erro 406 Não aceitável não é devido ao conteúdo no cabeçalho ou codificação, pelocontrário, é devido ao valor definido dentro do cabeçalho HTTP. Garantir que o servidor possa processar o formato definido, juntamente com o envio da solicitação com o formulário correto, evitará que um código de status de erro do Tipo de Mídia não suportado de 415 aconteça. See RFC7231, Seção 6.5.13
para mais informações.
416: Faixa não satisfiável
Conforme mencionado com o código de status de Solicitação Parcial 206, é possível que clientes/navegadores solicitem uma resposta parcial do saquer, seja ele is uma parte específica de um arquivo ou vídeo, por exemplo. Clientes e servidores usam o que é chamado de solicitações de intervalo para executar esses pedidos. No entanto, se o servidor faz não suportar esses tiposde solicitações, ele simplesmente retornará todo o resource juntamente com uma resposta de 200 OK. Se o servidor fizer solicitações de intervalo de suporte, that é onde o 416 Solicitação Parcial erro código de status entra na imagem e devolverá o que o cliente está pedindo. Em uma situação em que o servidor faz solicitações de intervalo de suporte, mas o doe servidornão s concordo com o pedir recebido porque ele faz não cair dentro do alcance ou possivelmente além o intervalo especificado, o range 416 Não Satisfiable erro código de status será devolvido. SEe RFC7233, Seção 4.4 para mais informações.
417: Expectativa falha
Os clientes podem usar um cabeçalho Expect
para indicar que espera um comportamento específico do servidor. Como descrito no código de status 100 Continue, os clientes podem verificar com o servidor se ele aceitará uma solicitação. Se isso acontecer, o servidor responderá com o código de status 100 Continue. Se não, tele 417 Expectativa Falhou erro código de status Indica Isso o servidor fez não entender o esperar cabeçalho ou apoiá-lo, portanto, ele podenão processar o clienT pedir. Para obter mais informações sobre o código de erro de falha de expectativa 417, consulte RFC7231, Seção 6.5.14
418-42
0
: Não assinado
Oscódigos de tatus de erro 418-421 estão atualmente não assinados, no entanto, código de status 418 Eu sou um Pequeno Bule é usado em alguns casos. Criado como uma piada de abril tolo, ele ganhou alguma tração e é às vezes usado como uma piada ou ovo de Páscoa e não usado para fins reais cotidianos. A maioria dos navegadores ignorá-lo, pois não é um código de status oficial. Outro nesta categoria é o 420 Enhance Your Calm error status code que foi introduzido pelo Twitter. ela ié umcódigode erro n que diz aos clientes que eles are sendo taxa limitada, which é uma restrição sobre o número de solicitações que eles podem fazer dentro de um período de tempo especificado. Desde 1989,o Editor da RFC publicará os RFCs mais humorísticos. A Wikipédia tem um resumo completo
dos RFCs mais humorísticos de April Fool.
421: Solicitação mal direcionada
Introduzido com o protocolo HTTP/2, o 421 Solicitação Mal direcionada erro código de status significa que o servidor received um pedido que foi não destinado a esse servidor específico e não pode responder adequadamente. Isso pode acontecer se o DNS (Domain Name System) estiver definido como o endereço IP errado. Clientes são obrigados a incluir um anfitrião cabeçalho no pedido. Isso também pode ocorrer com sites que têm um único SSL certificado de vários domínios. Isso pode ser causado por umn problema com o provedor de hospedagem e/ou navegador específico usado, por isso pode exigir uma grande quantidade de trabalho para realmente entender onde o problema está. Se um servidor sabe que um domínio não está configurado no request, responderá com o Pedido 421 Mal direcionado resposta de erro. SEe RFC7540, Seção 9.1.2 para mais informações.
422:
Entidade Não
Processada
Um 422 Inprocessável entidade erro código de status Indica um problema com o conteúdo do sintaxe de um pedido. o arranjo do pedido foi entendido pelo servidormas o campos dentro da solicitação são inválidos ou faz não corresponder ao que o servidor espera. gostar o Processamento 102 e o 207 Multi-Códigos de status, um 422 Inprocessável entidade erro código é parte do protocolo WebDAV e frequentemente usado com serviços web/APIs. Geralmente, um 400 Má Solicitação é a resposta recomendada, mas se o WebDAV é suportado, então tele 422 Inprocessável entidade deve ser usado. SEe RFC4918, Seção 11.2 para mais informações.
423: Bloqueado
Como o código de status de erro da Entidade NãoProcessável 422, o erro bloqueado 423 o código de status também faz parte do protocolo WebDAV. O código de status bloqueado 423 indica que um file, recurso, ou diretamente, por exemplo, não pode ser editado. Seu objetivo é evitar que vários usuários atualizem um arquivo, recurso, etc., simultaneamente. Esses recursos podem então ser desbloqueados para edição, wgalinha necessária. Para obter mais informações sobre o código de erro bloqueado 423, consulte RFC4918, Seção 11.3
424: Dependência falhada
Outro código de status suportado pelo WebDav protocolo; a dependência falha do 424 código de status de erro indica a solicitação do cliente falhou devido a uma dependência de outro pedido que também falhou. O WebDAV utiliza um método conhecido como PROPPATCH
para atualizar certas propriedades resource. Para indicar se um recurso foi atualizado com sucesso ou não, o WebDAV usa respostas padrão de código de status HTTP. Além disso, o código de status de dependência falha 424 só é usado no caso em que a resposta no órgão HTTP tenha o 207 Multi-Stresposta atus. So, se o PROPPATCH
for usado e o recurso não atualizar, ele enviará um código de status de 4xx indicando há um erro atualizando o recurso, o código de erro de dependência falhada 424 também será enviado juntamente com as outras solicitações que dependiam dessa atualização ser bem sucedida, mas falhadas. See RFC4918, Seção 11.4
para mais informações.
425: Muito cedo
Não é um código de status HTTP comum que é usado hoje, o código de resposta de erro 425 Too Early é usado em situações em que um cliente HTTP está se conectando a um cliente HTTPS. Durante o processo, pode levar muito tempo para estabelecer uma conexão entre o servidor e o cliente. Esse processo pode representar um problema de segurança, de modo que o servidor dirá ao cliente para tentar novamente a solicitação até que a conexão TLS (Transport Layer Security) segura tenha sido feito. Nesse caso, o código de status 425 Too Early será devolvido. Para obter mais informações sobre o código de erro 425 Too Early, consulte RFC8470, Seção 5.2
426: Atualização necessária
O código de status de erro necessário para atualização 426 indica ao cliente que ele precisa utilizar um protocolo mais novo a fim de enviar solicitações para o servidor. Por exemplo, o cliente pode estar usando e versão mais antiga de HTTP, como HTTP/1.0, mas o servidor Requer HTTP2.0. O servidor não aceitará o pedido, mas vai responder de volta ao clienT Indicando qual protocolo ou protocolos são aceitáveis. Uma vez que o cliente tenha atualizado para o protocolos obrigatórios, o servidor aceitará solicitações do cliente. Para obter mais informações sobre o código de erro necessário para atualização 426, consulte RFC7231, Seção 6.5.15
427: Não assinado
Ocódigo 427 do erro está atualmente não assinado.
428: Pré-condição necessária
O código de status de erro necessário 428 pré-condição indica ao cliente que a solicitação ao servidor deve ser uma solicitação condicional. Como mencionado no 304 Código de status não modificado, um cliente pode enviar uma solicitação condicional para o servidorcomo If-Match, Se-Nenhum-Match, Se modificado-desde, Se-Não modificado-Desdeou If-Range. No entanto, essas solicitações condicionais não são Necessário. Se eles forem exigidos pelo servidor, o servidor Indica isso respondendo com o código de erro 428 Pré-condição Exigido. Isso é um pouco semelhante a o código de erro de falha pré-condição 412, mas o 412 Falha na pré-condição código de erro é devolvido apenas se o cliente incluiu uma solicitação condicional no cabeçalho que faz não match o estado do recurso no servidor‘s lado. Ao notificar os usuários de que as solicitações devem ser de natureza condicional, isso garante que os usuários estejam trabalhando com os arquivos ou recursos certos e ajuda a prevenir usuários de alterações potencialmente sobrescrevendo. SEe RFC6585, Seção 3 para mais informações.
429: Muitos pedidos
Assim como o nome do erro código indica, o código de status de errode 429 Too Many Requestsignifica que alimitação da taxa é implementada, e que o client passou do limite para como muitos pedidos ele pode fazer em uma quantidade especificada de tempo. Juntamente com a resposta de erro 429 Too Many Requests, deve ser Indicado quanto tempo esperar antes Iniciar uma nova solicitação ao servidor, mas não é antigamente Necessário para fazê-lo. Para obter mais informações sobre o código de erro Too Many Requests, consulte RFC6585, Seção 4
430: Não assinado
O código de status de erro 430 está atualmente não assinado, no entanto, foi uma vez proposto para ser o código de erro 430 Bloco dentro do protocolo HTTP/1.1. A intenção era servir como uma resposta ao que é conhecido como Pipelining. Isso permitiu que os clientes enviassem várias solicitações, sobre uma conexão TCP, enquanto esperava o servidor respond . eut nunca oficialmente fez isso no padrão como o protocolHTTP foi atualizado para HTTP/2.0 e o suporte para pipelining nunca foi amplamente adotado.
431 Pedidos de cabeçalhos muito grandes
O código de status de erro 431 Request Headers Too Large indica que o cliente enviou um cabeçalho request que excede o limite permitido. Diferentes servidores web têm limites de tamanho permitidos variados quando se trata de cabeçalhos. Isso pode ser devido a uma solicitação de cabeçalho individual ser muito grande ou devido a todo o combinado tamanho de todos os pedidos de cabeçalho. Na maioria dos casos, isso pode ser fácil de remediar, pois é tipicamente causado pelo envio de cookies demais ou cookies que são muito grandes em tamanho de arquivo. Para obter mais informações sobre o código de erro 431 Request Headers Too Large, consulte RFC6585, Seção 5
432-450
:
Sem assinatura
Os códigos de status de erro 432 a 450 estão atualmente não assinados.
451:
Indisponível por Razões Legais
Erros scódigo tatus 451 Indisponível por Razões Legais Indica o servidor está se recusando a servir o conteúdo solicitado devido a legal Razões e também deve incluir o motivo do erro na resposta ao usuário. Razões para usar o 451 Indisponível Devido a Razões Legais código de erro pode incluir governos que censuram conteúdo específico, conteúdo que viola leis de direitos autorais, como o DMCA (Digital Millennium Copyright Acts), ou conteúdo que viole leis ou ordens judiciais. O 403 Proibido e 404 Códigos de status não encontrados são às vezesusados no lugar do código de status de erro 451, mas o código de status de erro 451 fornece mais informações ou explicações em why o erro está ocorrendo. Os usuários normalmente se locomoverame 451 erro implementando VPNs para acessar o conteúdo. See RFC7725, Seção 3
para mais informações.
452-499: Sem assinatura
Os códigos de erro 452-499 estão atualmente não assinados.
5xx: Erro do servidor
Como os códigos de status 4xx, os códigos de status 5xx indicam que há um erro,no entanto, o erro em questão não é provável devido a uma conexão ruim ou ao próprio navegador . Códigos de status 5xx indicam há um problema no nível do servidor e não pode processar o solicitação do cliente. Junto com o erro, o servidor deve responder com uma explicação do erro, seja uma condiçãotemporária ou permanente, e como ela pode ser remediada.
500: Erro do servidor interno
O código de status de erro do servidor interno 500 simplesmente significa que o servidor encontrou um problema e não pode processar a solicitação. tipicamente, o código de erro do servidor interno 500 usado mais como um código de erro do servidor genérico se o problema exato nãose enquadrar em nenhum dos outros códigos de status de erro do servidor 5xx Especificações. Tele 500 Código de erro do servidor interno é provavelmente o mais usado dos códigosde classificação de erro do servidor 5xx . Consulte RFC7231, Seção 6.6
para obter mais informações.
501
:
Não implementado
Um 501 não implementado códigos de status de erro ocorre quando o servidor faz não reconhecer o método da solicitação e, portanto, não pode support ou processar a solicitação. ela eus gostar o método 405 não permitido código de status de erro do clientemas um código de status de erro não implementado 501 poderia indicar que o método de solicitação do cliente é válido, apenas não suportado pelo servidor. O status de erro 405 método não permitido seria indicar que o método chamado pelo cliente é não Suportado e deve não Foram utilizado. ver RFC7231, Seção 6.6.2 para mais informações.
502
:
Bad Gateway
O código de status de erro do Bad Gateway 502 significa que um servidor está agindo como um proxy e recebeu uma resposta de um servidor de origem que voltou como inválido. ela eus possível que eus devido a um servidor sobrecarregado e o cliente pode reenviar a solicitação, mas na maioria dos casos, it eus devido Para um problema com o servidor web ou CDN (Rede de Distribuição de Conteúdo) sentado entre o cliente e o servidor e pode requerer adicional solução de problemas com o provedor de hospedagem para entender por que o erro está sendo jogado. ver RFC7231, Seção 6.6.3
para mais informações.
503
:
Serviço indisponível
O código de status de erro 503 Service Unaindica que o servidor está atualmente sobrecarregado com solicitações ou fora de recursos,está atualmenteem manutenção, ou possivelmente no aplicativo que eles estão tentando acessar está para baixo, e o servidor não pode concluir a solicitação devido ao estado atual. Às vezes, os clientes veem uma mensagem junto com o código de status de erro indisponível do serviço 503, dizendo-lhes para tentar a solicitação novamente posterior. No entanto, pode não fornecer uma explicação definitiva de quando ou quanto tempo o código de status de erro indisponível do serviço pode durar. Consulte RFC7231, Seção 6.6.4
para obter informações.
504: Gateway Timeout
Como o código de status de erro do 502 Bad Gateway, o código de status de erro do Gateway Gateway 504 é usado quando o servidor está agindo como proxy, mas responderá com um Gateway Timeout 504 código de status de erro se a resposta de umn servidor de origem leva muito tempo para responder. Um código de status de erro do Bad Gateway 502 deve ser usado nos casos em que a resposta foi inválida ou não recebido pelo servidor proxy Absolutamente. A mensagem junto com o Gat 504ecstasytempo limite de maneira pode indicar e recomendar que o cliente tentar resending a solicitação. ver RFC7231, Seção 6.6.5 para mais informações.
505: Versão HTTP não suportada
Uma versão HTTP 505 Código de status de erro não suportado significa que o servidor não suporta a versão do protocolo HTTP usado na mensagem da solicitaçãoe, portanto,não pode processar o pedido. Junto com a versão 505 HTTP Código de status de erro não suportado,a resposta do servidor deve incluir uma mensagem indicando por que esse protocolo HTTP específico não é suportado e quais protocolos são suportados. Consulte RFC7231, Seção 6.6.6
para obter mais informações.
506: Variant também negocia
A Variant 506 Também Negocia é um código de status HTTP experimental e não faz parte do padrão de hoje. Uma Variante 506 Também Negocia indica que há um problema de configuração interna com o servidor devido a questões de negociação de conteúdo. Negociação de conteúdo permite que os clientes enviem múltiplos aceitam cabeçalhos e diz ao servidor qual representação específica de um recurso para servir conforme indicado por o navegador. Isso poderia ser para servindo a linguagem certa, documento formarumt, etc. Mesmo que a Variante 506 também negocie código de status de erro está em ano o status experimental e não oficialmente parte do padrão HTTP, é usado em casos raros. Alguns usuáriosdo Google Playencontraram esse problema no passado ao tentar baixar várias versões de um aplicativo, fazendo com que osdispositivosir tentassem continuamente baixar o aplicativo em um processode loop fechado. Consulte RFC2295, Seção 8.1
para obter mais informações.
507: Armazenamento insuficiente
Um código de status de erro do servidor de armazenamento insuficiente de 507 também faz parte do protocolo WebDAV. O código de status de erro de armazenamento insuficiente 507 indica para o clienttchapéu a solicitação,como um PUT
ou POST
solicitação, era muito grande em tamanho de arquivo. Também pode indicar que o servidor tem temporariamente ficar sem armazenamento. Consulte RFC4981, Seção 11.5
para obter mais informações.
508: Loop detectado
O loop 508 detectado servidor código de status de erro, como o código de erro do servidor de armazenamento insuficiente 507, faz parte do protocolo WebDAV. Dentro do protocolo WebDAV, it eus possível que o cliente possa fazer uma solicitação a um servidor para um diretório inteiro e criar um alvo algunsonde esse mesmo diretório, resultando em um loop infinito de solicitação/resposta. O código de status de erro do servidor detectado em loop 508 Indica que o servidor terminado a solicitação do clienteespecificamente Profundidade: Emfáinidade, porque o servEr Identificado o pedido como resultando em um iloop nfinite, repetidamente chamando de volta em si mesmo. ver RFC5842, seção 7.2 para mais informação.
509: Não assinado
O código de status de erro do servidor 509 está atualmente não assinado.
510: Não prorrogado
Um código de status de erro do servidor não estendido 510 está atualmente em status proposto/experimental e não faz parte da especificação padrão do código de status HTTP. O 510 Not Extended indica ao cliente que a solicitação requer uma solicitação HTTP estendida. Se o servidor responder com o código de status de erro do servidor 510 Não Estendido, ele também deve incluir como o client deve remEdy seu pedido, mas a especificação faz não explicitamente estado Isso. aliDebate se tseu should cair sob a classificação de erro do servidor 5xx, uma vez que poderia ser visto como um erro do cliente 4xx, mas desde Itis não formalmente parte do padrão, ele eunão relevformiga e raramente usado para uso diário. ver RFC2774, Seção 7 para mais informações.
511: Autorização de rede necessária
O código de status de erro do servidor 511 requere necessária que o cliente se autua para ter acesso a uma rede. Por exemplo, os usuários podem ver isso ao tentar se conectar a uma rede Wi-Fi pública em uma empresa e os usuários devem concordar com seus termos e condições antes de serem concedidos acesso. Juntamente com a autorização de rede 511 necessária resposta de erro do servidor, os usuários também devem ser direcionados para onde podem fazer login. Consulte RFC6585, Seção 6
para obter mais informações.
512-599: Sem assinatura
Os códigos de status de erro do servidor 512-599 estão atualmente não assinados, mas algumas empresas podem usar qualquer uma delas como mensagens de erro personalizadas do servidor para os clientes.
Monitorando
respostas
de código de status HTTP
Para ver uma lista de códigos de status para uma URL específica em primeira mão, você pode verificar a guia de ferramentas do desenvolvedor dentro de sua navegaçãoR. Juntamente com as métricas de velocidade de velocidade de carga da página, você também pode visualizar quaisquer respostas do servidor, juntamente com todos os códigos de status HTTP associados, para garantir que tudo em sua página esteja carregando e Renderização devidamente.
Para uma abordagemde monitoramento mais proativa e automatizada, as soluções de monitoramento profissional do Dotcom-Monitor podem ter certeza de que sempre que um código de erro HTTP específicoé encontrado por um usuário, suasequipes r são notificadas imediatamente so eles podem rapidamente remediar a questão. Você também pode usar o Recurso de filtros para remover códigos de status HTTP individuais de tarefas, alertas e relatórios,para que você desconsidere quaisquer códigos de status HTTP que não sejam relevantes para suas necessidades específicas.