O código de status HTTP é um código de três dígitos retornado pelo servidor em resposta a uma solicita??o, que é usado para identificar o resultado da solicita??o. Essa ferramenta fornece uma classifica??o padronizada e interpreta??o de cenários, adequada para desenvolvedores, pessoal de opera??es e manuten??o e estudantes de tecnologia de rede.
Todas as explica??es s?o baseadas no documento padr?o RFC, evitando diferen?as regionais na express?o e garantindo que os usuários de todo o mundo entendam o mesmo.
| Códigos de status Http | Código de status Significado |
|---|---|
| 100 | O cliente deve continuar a enviar solicita??es. Essa resposta temporária é usada para informar ao cliente que parte de sua solicita??o foi recebida pelo servidor e n?o foi rejeitada. O cliente deve continuar a enviar o restante da solicita??o ou ignorar essa resposta se a solicita??o estiver concluída. O servidor deve enviar uma resposta final ao cliente quando a solicita??o for concluída. |
| 101 | O servidor entendeu a solicita??o do cliente e notificará o cliente por meio do cabe?alho Upgrade de que um protocolo diferente foi usado para concluir a solicita??o. Depois de enviar a última linha em branco da resposta, o servidor mudará para os protocolos definidos no cabe?alho Upgrade. Isso só deve ser feito se for mais vantajoso mudar para o novo protocolo. Por exemplo, a mudan?a para uma nova vers?o do HTTP pode ser mais vantajosa do que uma vers?o mais antiga, ou a mudan?a para um protocolo síncrono e em tempo real para fornecer recursos que aproveitem esses recursos. |
| 102 | Os códigos de status, ampliados pelo WebDAV (RFC 2518), indicam que o processamento continuará. |
| 200 | A solicita??o foi bem-sucedida, e os cabe?alhos de resposta ou o corpo de dados desejado pela solicita??o ser?o retornados com a resposta. |
| 201 | A solicita??o foi atendida e um novo recurso foi criado em resposta à solicita??o, e seu URI foi retornado com o cabe?alho Location. Se o recurso solicitado n?o puder ser criado a tempo, deverá ser retornado o seguinte'202 Accepted'。 |
| 202 | O servidor aceitou a solicita??o, mas ainda n?o a processou. Assim como pode ser rejeitada, a solicita??o pode ou n?o ser executada eventualmente. No caso de opera??es assíncronas, n?o há nada mais conveniente do que enviar esse código de status. O objetivo de retornar uma resposta 202 é permitir que o servidor aceite solicita??es de outros processos (como uma opera??o baseada em lote que é executada apenas uma vez por dia) sem que o cliente tenha que manter uma conex?o com o servidor até que a opera??o em lote seja concluída. Uma resposta que aceita uma solicita??o de processamento e retorna um código de status 202 deve incluir na entidade retornada algumas informa??es que indiquem o status atual do processo, bem como um ponteiro para um monitor de status de processamento ou previs?o de status, para que o usuário possa estimar se a opera??o foi concluída ou n?o. |
| 203 | O servidor processou a solicita??o com êxito, mas as meta-informa??es do cabe?alho da entidade retornada n?o s?o um conjunto definitivo válido no servidor original, mas uma cópia de um local ou de terceiros. As informa??es atuais podem ser um subconjunto ou um superconjunto do original. Por exemplo, os metadados que contêm recursos podem fazer com que o servidor de origem conhe?a as superinforma??es de meta-informa??o. O uso desse código de status n?o é obrigatório e só é apropriado se a resposta tivesse retornado 200 OK sem ele. |
| 204 | O servidor processou a solicita??o com êxito, mas n?o precisa retornar nenhum conteúdo físico e deseja retornar metainforma??es atualizadas. A resposta pode retornar meta-informa??es novas ou atualizadas na forma de cabe?alhos de entidade. Se esses cabe?alhos existirem, eles dever?o corresponder às variáveis solicitadas. Se o cliente for um navegador, o navegador do usuário DEVER? manter a página na qual a solicita??o foi enviada sem nenhuma altera??o na exibi??o do documento, embora as metainforma??es novas ou atualizadas DEVEM, de acordo com a especifica??o, ser aplicadas ao documento na exibi??o ativa do navegador do usuário. Como a resposta 204 é proibida de conter qualquer corpo de mensagem, ela sempre termina com a primeira linha em branco após o cabe?alho da mensagem. |
| 205 | O servidor processa a solicita??o com êxito e n?o retorna nada. No entanto, ao contrário da resposta 204, a resposta que retorna esse código de status pede que o solicitante redefina a exibi??o do documento. Essa resposta é usada principalmente para redefinir o formulário imediatamente após aceitar a entrada do usuário, para que ele possa iniciar facilmente outra entrada. Como a resposta 204, essa resposta é proibida de conter qualquer corpo de mensagem e termina com a primeira linha em branco após o cabe?alho da mensagem. |
| 206 | O servidor processou com êxito parte da solicita??o GET. As ferramentas de download HTTP, como o FlashGet ou o Thunderbolt, usam esse tipo de resposta para realizar downloads intermitentes ou para dividir um arquivo grande em vários downloads ao mesmo tempo. A solicita??o deve conter um cabe?alho Range para indicar o intervalo de conteúdo que o cliente deseja receber e pode conter um If-Range como condi??o de solicita??o. A resposta deve conter os seguintes campos de cabe?alho: Content-Range para indicar o escopo do conteúdo retornado nessa resposta ou, no caso de downloads de várias partes com um Content-Type de multipart/byteranges, um campo Content-Range em cada segmento de várias partes para indicar o escopo do conteúdo nesse segmento. Se a resposta contiver um Content-Length, seu valor deverá corresponder ao número real de bytes no intervalo de conteúdo retornado. Expires, Cache-Control e/ou Vary, se seus valores puderem ser diferentes dos valores de outras respostas anteriores com as mesmas variáveis. Essa resposta n?o deve conter outros cabe?alhos de entidade se a solicita??o usar valida??o de cache If-Range forte e n?o deve conter outros cabe?alhos de entidade se a solicita??o usar valida??o de cache If-Range fraca; isso evita inconsistências entre o conteúdo da entidade em cache e as informa??es atualizadas do cabe?alho da entidade. Caso contrário, essa resposta DEVER? conter todos os campos de cabe?alho de entidade que deveriam ter sido retornados na resposta 200. Se os cabe?alhos ETag ou Last-Modified n?o corresponderem exatamente, o cache do lado do cliente n?o deverá permitir a combina??o do conteúdo retornado na resposta 206 com qualquer conteúdo previamente armazenado em cache. Qualquer cache que n?o seja compatível com os cabe?alhos Range e Content-Range está proibido de armazenar em cache o conteúdo retornado pela resposta 206. |
| 207 | Códigos de status estendidos pelo WebDAV(RFC 2518) O código de status, conforme estendido pelo WebDAV, significa que o corpo da mensagem subsequente será uma mensagem XML e poderá conter uma série de códigos de resposta separados, dependendo do número de sub-solicita??es anteriores. |
| 300 | O recurso solicitado tem uma série de respostas alternativas, cada uma com seu próprio endere?o específico e informa??es de negocia??o orientadas pelo navegador. Cabe ao usuário ou ao navegador escolher um endere?o preferencial para redirecionamento. A menos que se trate de uma solicita??o HEAD, a resposta deve incluir uma entidade que seja uma lista de características e endere?os de recursos a partir da qual o usuário ou o navegador possa selecionar o endere?o de redirecionamento mais adequado. O formato dessa entidade é determinado pelo formato da defini??o Content-Type. O navegador pode fazer automaticamente a sele??o mais adequada com base no formato da resposta e nos recursos do próprio navegador. Obviamente, a especifica??o RFC 2616 n?o especifica como essa sele??o automática deve ser feita. Se o próprio servidor já tiver uma op??o de retorno preferencial, o URI do retorno deverá ser especificado no Location; os navegadores poder?o usar esse valor de Location como endere?o para redirecionamento automático. Além disso, a resposta é armazenável em cache, a menos que especificado de outra forma. |
| 301 | O recurso solicitado foi movido permanentemente para o novo local, e todas as referências futuras a ele devem usar um dos vários URIs retornados nessa resposta. Se possível, os clientes com recursos de edi??o de links devem alterar automaticamente o endere?o solicitado para o endere?o retornado pelo servidor. Essa resposta também pode ser armazenada em cache, a menos que seja especificado de outra forma. O novo URI permanente deve ser retornado no campo Location da resposta. A menos que se trate de uma solicita??o HEAD, a entidade de resposta deve conter um hiperlink para o novo URI e uma breve descri??o. Se n?o for uma solicita??o GET ou HEAD, o navegador está proibido de redirecionar automaticamente, a menos que seja confirmado pelo usuário, pois os termos da solicita??o podem mudar como resultado. Observa??o: para alguns navegadores que usam o protocolo HTTP/1.0, quando eles enviam uma solicita??o POST e recebem uma resposta 301, a próxima solicita??o de redirecionamento será GET. |
| 302 | O recurso solicitado agora responde temporariamente à solicita??o de um URI diferente. Como esse redirecionamento é temporário, o cliente deve continuar a enviar solicita??es futuras para o endere?o original. A resposta pode ser armazenada em cache somente se for especificada em Cache-Control ou Expires. O novo URI temporário deve ser retornado no campo Location da resposta. A menos que essa seja uma solicita??o HEAD, a entidade de resposta deve conter um hiperlink para o novo URI e uma breve descri??o. Se n?o for uma solicita??o GET ou HEAD, o navegador está proibido de redirecionar automaticamente, a menos que seja confirmado pelo usuário, pois os termos da solicita??o podem mudar como resultado. Observa??o: embora as especifica??es RFC 1945 e RFC 2068 n?o permitam que o cliente altere o método da solicita??o durante o redirecionamento, muitos navegadores existentes tratam a resposta 302 como uma resposta 303 e usam GET para acessar o URI especificado no Location, ignorando o método da solicita??o original. Os códigos de status 303 e 307 foram adicionados para esclarecer qual resposta o servidor espera do cliente. |
| 303 | A resposta à solicita??o atual pode ser encontrada em outro URI, e o cliente deve acessar esse recurso usando GET. Esse método existe principalmente para permitir que a saída da solicita??o POST ativada por script seja redirecionada para um novo recurso. Esse novo URI n?o é uma referência de substitui??o do recurso original. Além disso, n?o é permitido que a resposta 303 seja armazenada em cache. Obviamente, a segunda solicita??o (redirecionamento) pode ser armazenada em cache. O novo URI deve ser retornado no campo Location da resposta. A menos que essa seja uma solicita??o HEAD, a entidade de resposta deve conter um hiperlink para o novo URI e uma breve descri??o. Observa??o: muitos navegadores anteriores ao HTTP/1.1 n?o entendem corretamente o estado 303. Se a intera??o com esses navegadores precisar ser considerada, o código de status 302 deverá funcionar, pois a maioria dos navegadores trata a resposta 302 exatamente da mesma forma que a especifica??o acima exige que o cliente trate a resposta 303. |
| 304 | Esse código de status deve ser retornado pelo servidor se o cliente enviar uma solicita??o GET condicional e a solicita??o for permitida, e o conteúdo do documento n?o tiver sido alterado (desde a última visita ou de acordo com as condi??es da solicita??o). A resposta deve conter as seguintes informa??es de cabe?alho: Data, a menos que o servidor n?o tenha um relógio. Se um servidor sem relógio seguir essas regras, o servidor proxy e o cliente poder?o adicionar o campo Date ao cabe?alho da resposta de entrada por conta própria (conforme especificado na RFC 2068), e o mecanismo de cache funcionará corretamente. ETag e/ou Content-Location, se a mesma solicita??o deveria ter retornado uma resposta 200. Expires, Cache-Control e/ou Vary, se seus valores puderem ser diferentes dos valores de outras respostas anteriores com as mesmas variáveis. Se a solicita??o de resposta usar valida??o de cache forte, a resposta n?o deverá conter cabe?alhos de entidade adicionais; caso contrário (por exemplo, uma solicita??o GET condicional usa valida??o de cache fraca), a resposta n?o poderá conter cabe?alhos de entidade adicionais; isso evita inconsistências entre o conteúdo da entidade em cache e as informa??es atualizadas do cabe?alho da entidade. Se uma resposta 304 indicar que uma entidade n?o está armazenada em cache no momento, o sistema de cache deve ignorar a resposta e repetir a solicita??o sem a restri??o. Se for recebida uma resposta 304 solicitando a atualiza??o de uma entrada de cache, o sistema de cache DEVE atualizar toda a entrada para refletir os valores de todos os campos atualizados na resposta. |
| 305 | O recurso solicitado deve ser acessado por meio de um proxy especificado. O campo Location fornecerá informa??es sobre o URI do proxy especificado, e o destinatário precisará enviar uma solicita??o separada repetidamente para acessar o recurso por meio desse proxy. Somente o servidor original pode criar uma resposta 305. Observa??o: n?o está claro na RFC 2068 que uma resposta 305 se destina a redirecionar uma única solicita??o e só pode ser criada pelo servidor de origem. Ignorar essas restri??es pode levar a sérias consequências de seguran?a. |
| 306 | Na vers?o mais recente da especifica??o, o código de status 306 n?o é mais usado. |
| 307 | Os recursos solicitados agora respondem temporariamente a solicita??es de URIs diferentes. Como esse redirecionamento é temporário, os clientes devem continuar a enviar solicita??es futuras para o endere?o original. Essa resposta só pode ser armazenada em cache se for especificada em Cache-Control ou Expires. O novo URI temporário deve ser retornado no campo Location da resposta. A menos que se trate de uma solicita??o HEAD, a entidade de resposta deve conter um hiperlink para o novo URI e uma breve descri??o. Como alguns navegadores n?o reconhecem a resposta 307, é necessário adicionar as informa??es acima para que o usuário possa entender e solicitar acesso ao novo URI. Se essa n?o for uma solicita??o GET ou HEAD, o navegador proibirá o redirecionamento automático, a menos que seja confirmado pelo usuário, porque as condi??es da solicita??o podem mudar. |
| 400 | 1, erro sem?ntico, a solicita??o atual n?o pode ser compreendida pelo servidor. A menos que seja modificada, o cliente n?o deve repetir a solicita??o. 2, os par?metros da solicita??o est?o errados. |
| 401 | A solicita??o atual exige autentica??o do usuário. A resposta deve conter um cabe?alho WWW-Authenticate para que o recurso solicitado solicite informa??es do usuário. O cliente pode reenviar uma solicita??o com as informa??es apropriadas do cabe?alho Authorisation. Se a solicita??o atual já contiver credenciais de autoriza??o, uma resposta 401 significa que o servidor verifica se essas credenciais foram rejeitadas. Se a resposta 401 contiver a mesma consulta de autentica??o que a resposta anterior e o navegador já tiver feito pelo menos uma tentativa de autentica??o, o navegador deverá mostrar ao usuário as informa??es de entidade contidas na resposta, pois essas informa??es de entidade podem conter informa??es de diagnóstico relevantes. Consulte a RFC 2617. |
| 402 | Esse código de status é reservado para possíveis requisitos futuros. |
| 403 | O servidor entendeu a solicita??o, mas se recusa a executá-la. Ao contrário de uma resposta 401, a autentica??o n?o fornece nenhuma ajuda e a solicita??o n?o deve ser reenviada. Se n?o se tratar de uma solicita??o HEAD e o servidor quiser poder dizer por que a solicita??o n?o pode ser executada, o motivo da recusa deve ser descrito na entidade. Obviamente, o servidor também pode retornar uma resposta 404 se n?o quiser que o cliente obtenha nenhuma informa??o. |
| 404 | A solicita??o falhou, o recurso solicitado n?o foi encontrado no servidor. N?o há informa??es para informar ao usuário se a situa??o é temporária ou permanente. Se o servidor estiver ciente da situa??o, deverá usar o código de status 410 para informar ao servidor que o recurso antigo está permanentemente indisponível devido a algum mecanismo de configura??o interna e que n?o há redirecionamento disponível. 404 é amplamente usado quando o servidor n?o quer revelar por que a solicita??o foi rejeitada ou quando n?o há outra resposta adequada disponível. |
| 405 | O método de solicita??o especificado na linha de solicita??o n?o pode ser usado para solicitar o recurso correspondente. A resposta deve retornar um cabe?alho Allow indicando a lista de métodos de solicita??o que s?o aceitáveis para o recurso atual. Como os métodos PUT e DELETE gravam no recurso no servidor, a maioria dos servidores da Web n?o os suporta ou permite por padr?o e retornará um erro 405 para essas solicita??es. |
| 406 | As características do conteúdo do recurso solicitado n?o satisfazem as condi??es do cabe?alho da solicita??o e uma entidade de resposta n?o pode ser gerada. A menos que se trate de uma solicita??o HEAD, a resposta deve retornar uma entidade que contenha uma lista de endere?os da qual o usuário ou o navegador possa selecionar as características de entidade mais adequadas. O formato da entidade é determinado pelo tipo de mídia definido no cabe?alho Content-Type. O navegador pode fazer a melhor escolha com base no formato e em seus próprios recursos. Entretanto, a especifica??o n?o define nenhum critério para fazer essas escolhas automáticas. |
| 407 | Semelhante à resposta 401, exceto pelo fato de que o cliente deve se autenticar no servidor proxy. O servidor proxy DEVE retornar um Proxy-Authenticate para interroga??o de identidade. O cliente pode retornar um cabe?alho Proxy-Authorisation para autentica??o. Consulte a RFC 2617. |
| 408 | Tempo limite da solicita??o. O cliente n?o concluiu uma solicita??o dentro do tempo que o servidor estava preparado para esperar. O cliente pode reenviar a solicita??o a qualquer momento sem fazer nenhuma altera??o. |
| 409 | A solicita??o n?o p?de ser concluída devido a um conflito com o estado atual do recurso solicitado. Esse código só poderá ser usado se o usuário for considerado capaz de resolver o conflito e reenviar uma nova solicita??o. A resposta deve conter informa??es suficientes para que o usuário descubra a origem do conflito. Os conflitos geralmente ocorrem no processamento de solicita??es PUT. Por exemplo, em um ambiente de verifica??o de vers?o, uma PUT enviada para modificar um determinado recurso com informa??es de vers?o que entrem em conflito com uma solicita??o anterior (de terceiros) deve retornar um erro 409 informando ao usuário que a solicita??o n?o p?de ser concluída. Nesse caso, a entidade de resposta provavelmente conterá uma compara??o das diferen?as entre as duas vers?es conflitantes, para que o usuário possa reenviar a nova vers?o mesclada. |
| 410 | O recurso solicitado n?o está mais disponível no servidor e n?o há endere?o de encaminhamento conhecido. Essa situa??o deve ser considerada permanente. Se possível, os clientes com recursos de edi??o de links devem remover todas as referências a esse endere?o com a permiss?o do usuário. Se o servidor n?o souber ou n?o puder determinar se a condi??o é permanente, deverá ser usado um código de status 404. A menos que especificado de outra forma, essa resposta pode ser armazenada em cache. A finalidade da resposta 410 é principalmente ajudar o webmaster a manter o site, informando ao usuário que o recurso n?o está mais disponível e que o proprietário do servidor deseja que todas as conex?es remotas com o recurso também sejam excluídas. Esse tipo de evento é comum em servi?os de valor agregado e com tempo limitado. Da mesma forma, a resposta 410 é usada para notificar o cliente de que um recurso pertencente a um indivíduo n?o está mais disponível no site do servidor atual. Obviamente, a quest?o de saber se todos os recursos permanentemente indisponíveis precisam ser marcados como tal e por quanto tempo precisam ser mantidos dessa forma também é importante.'410 Gone'， A marca??o e o tempo em que ela deve ser mantida dependem inteiramente do proprietário do servidor. |
| 411 | O servidor se recusa a aceitar solicita??es sem o cabe?alho Content-Length definido. O cliente pode reenviar a solicita??o depois de adicionar um cabe?alho Content-Length válido indicando o tamanho do corpo da mensagem da solicita??o. |
| 412 | O servidor n?o conseguiu atender a um ou mais dos pré-requisitos fornecidos no campo de cabe?alho da solicita??o ao validá-la. Esse código de status permite que o cliente defina pré-condi??es nas meta-informa??es da solicita??o (dados do campo do cabe?alho da solicita??o) ao obter um recurso, impedindo assim que o método de solicita??o seja aplicado a recursos diferentes do conteúdo desejado. |
| 413 | O servidor se recusa a processar a solicita??o atual porque ela envia mais dados físicos do que o servidor deseja ou pode processar. Nesse caso, o servidor pode fechar a conex?o para impedir que o cliente continue a enviar a solicita??o. Se a situa??o for temporária, o servidor deverá retornar um cabe?alho Retry-After para informar ao cliente quanto tempo ele tem para tentar novamente. |
| 414 | O URI da solicita??o é mais longo do que o servidor pode interpretar, portanto o servidor se recusa a atender à solicita??o. Isso é raro e geralmente ocorre quando um envio de formulário que deveria ter usado o método POST se torna um método GET, resultando em uma Query String longa. Redirecionar "buracos negros" de URI, como usar o URI antigo como parte do novo URI para cada redirecionamento, resultando em um URI longo após vários redirecionamentos. Os clientes est?o tentando atacar os servidores explorando as vulnerabilidades de seguran?a existentes em alguns servidores. Esses servidores usam um buffer de comprimento fixo para ler ou manipular o URI solicitado, o que pode resultar em um estouro de buffer quando o par?metro GET excede um determinado valor, levando à execu??o arbitrária de código.[1]。 Os servidores sem essas vulnerabilidades devem retornar um código de status 414. |
| 415 | Para o método atualmente solicitado e o recurso solicitado, a entidade enviada na solicita??o n?o está em um formato suportado pelo servidor e a solicita??o é rejeitada. |
| 416 | Se a solicita??o contiver um cabe?alho de solicita??o Range, e qualquer intervalo de dados especificado no Range n?o coincidir com os intervalos disponíveis para o recurso atual, e a solicita??o n?o definir um cabe?alho de solicita??o If-Range, o servidor deverá retornar um código de status 416. Se o Range usar intervalos de bytes, isso significa que o primeiro byte de todos os intervalos de dados especificados na solicita??o excede o comprimento do recurso atual. O servidor também deve incluir um cabe?alho de entidade Content-Range que especifique o comprimento do recurso atual junto com o código de status 416. Essa resposta também é proibida de usar multipart/byteranges como seu Content-Type. |
| 417 | O conteúdo esperado especificado no cabe?alho de solicita??o Expect n?o pode ser atendido pelo servidor, ou o servidor é um servidor proxy que tem evidências claras de que o conteúdo de Expect n?o pode ser atendido no próximo nó da rota atual. |
| 421 | O número de conex?es com o servidor a partir do endere?o IP do cliente atual excede o máximo permitido pelo servidor. Normalmente, o endere?o IP aqui se refere ao endere?o do cliente visto do servidor (por exemplo, o gateway do usuário ou o endere?o do servidor proxy). Nesse caso, mais de um usuário final pode estar envolvido na contagem de conex?es. |
| 422 | O número de conex?es do endere?o IP do cliente atual com o servidor excede o máximo permitido pelo servidor. Normalmente, o endere?o IP aqui se refere ao endere?o do cliente visto do servidor (por exemplo, o gateway do usuário ou o endere?o do servidor proxy). Nesse caso, mais de um usuário final pode estar envolvido na contagem de conex?es. |
| 422 | A solicita??o foi formatada corretamente, mas n?o p?de ser respondida porque continha erros de sem?ntica. (RFC 4918 WebDAV) 423 Bloqueado O recurso atual está bloqueado. (RFC 4918 WebDAV) 423 Bloqueado |
| 424 | A solicita??o atual falhou devido a um erro em uma solicita??o anterior, como PROPPATCH. (RFC 4918 WebDAV) |
| 425 | Definido no rascunho do WebDav Advanced Collections, mas n?o aparece no protocolo WebDAV Sequential Collections (RFC 3658). |
| 426 | Os clientes devem mudar para TLS/1.0. (RFC 2817) |
| 449 | Estendido pela Microsoft para representar que as solicita??es devem ser repetidas depois que a a??o apropriada tiver sido executada. |
| 500 | O servidor encontrou uma condi??o imprevista que o impediu de concluir o processamento da solicita??o. Normalmente, esse problema ocorre quando há um erro no código do programa do servidor. |
| 501 | O servidor n?o oferece suporte a um recurso exigido pela solicita??o atual. Quando o servidor n?o reconhece o método solicitado e n?o pode dar suporte à sua solicita??o de qualquer recurso. |
| 502 | Um servidor que funciona como gateway ou proxy recebe uma resposta inválida de um servidor upstream quando tenta executar uma solicita??o. |
| 503 | No momento, o servidor n?o pode processar a solicita??o devido à manuten??o temporária ou sobrecarga do servidor. Essa condi??o é temporária e será restaurada após um período de tempo. Se for possível esperar um atraso, a resposta poderá incluir um cabe?alho Retry-After para indicar o atraso. Se essa informa??o Retry-After n?o for fornecida, o cliente deverá tratá-la da mesma forma que uma resposta 500. Observa??o: a existência do código de status 503 n?o significa que o servidor deva usá-lo se estiver sobrecarregado. Alguns servidores simplesmente querem negar uma conex?o ao cliente. |
| 504 | Um servidor atuando como gateway ou proxy que tenta executar uma solicita??o n?o recebe uma resposta oportuna de um servidor upstream (um servidor identificado por um URI, como HTTP, FTP, LDAP) ou de um servidor secundário (como DNS). Observa??o: alguns servidores proxy retornam um erro 400 ou 500 quando a pesquisa de DNS atinge o tempo limite. |
| 505 | O servidor n?o é compatível ou se recusa a ser compatível com a vers?o do HTTP usada na solicita??o. Isso implica que o servidor n?o pode ou n?o quer usar a mesma vers?o que o cliente. A resposta deve conter uma entidade que descreva por que a vers?o n?o é compatível e quais protocolos o servidor suporta. |
| 506 | Estendido pelo Protocolo de Negocia??o de Conteúdo Transparente (RFC 2295) para representar uma configura??o interna incorreta por parte do servidor: o recurso de Variante de Negocia??o solicitado está configurado para usar a si mesmo na Negocia??o de Conteúdo Transparente e, portanto, n?o é um foco apropriado em um processo de negocia??o. |
| 507 | O servidor n?o consegue armazenar o conteúdo necessário para atender à solicita??o. Essa condi??o é considerada temporária.WebDAV(RFC 4918) |
| 509 | O servidor atingiu seu limite de largura de banda. Esse n?o é um código de status oficial, mas ainda é amplamente usado. |
| 510 | A política necessária para obter o recurso n?o foi atendida. (RFC 2774) |