| Código de estado HTTP | Código de estado Significado |
|---|
| 100 | O cliente deve continuar a enviar pedidos. Esta resposta temporária é utilizada para informar o cliente de que parte do seu pedido foi recebida pelo servidor e não foi rejeitada. O cliente deve continuar a enviar o resto do pedido, ou ignorar esta resposta se o pedido estiver completo. O servidor deve enviar uma resposta final ao cliente quando o pedido estiver completo. |
| 101 | O servidor compreendeu o pedido do cliente e notificará o cliente através do cabeçalho da mensagem Upgrade para utilizar um protocolo diferente para completar o pedido. Depois de enviar a última linha em branco desta resposta, o servidor mudará para os protocolos definidos no cabeçalho da mensagem Upgrade. Isto só deve ser feito se for mais vantajoso mudar para um novo protocolo. Por exemplo, a mudança para uma nova versão do HTTP é mais vantajosa do que uma versão mais antiga, ou a mudança para um protocolo em tempo real e síncrono para fornecer recursos que tirem partido dessas caraterísticas. |
| 102 | Os códigos de estado, alargados pelo WebDAV (RFC 2518), representam que o processamento irá continuar. |
| 200 | O pedido foi bem sucedido e o cabeçalho de resposta ou o corpo de dados desejado pelo pedido será devolvido com esta resposta. |
| 201 | O pedido foi satisfeito e um novo recurso foi criado conforme exigido pelo pedido e o seu URI foi devolvido com o cabeçalho Location. Se o recurso requerido não puder ser criado a tempo, deve ser devolvido '202 Accepted'. |
| 202 | O servidor aceitou o pedido, mas ainda não o processou. Tal como pode ser rejeitado, eventualmente o pedido pode ou não ser executado. No contexto de operações assíncronas, não há nada mais conveniente do que enviar este código de estado. O objetivo de devolver uma resposta com um código de estado 202 é permitir que o servidor aceite pedidos de outros processos (como uma operação baseada em lotes que é executada apenas uma vez por dia) sem ter de manter o cliente ligado ao servidor até que a operação em lotes esteja totalmente concluída. Uma resposta que aceite um pedido de processamento e devolva um código de estado 202 DEVERÁ incluir na entidade devolvida alguma informação que indique o estado atual do processo, bem como um ponteiro para um monitor de estado de processamento ou previsão de estado, para que o utilizador possa estimar se a operação foi concluída. |
| 203 | O servidor processou com êxito o pedido, mas a meta-informação do cabeçalho da entidade devolvida não é um conjunto definitivo válido no servidor original, mas uma cópia de um terceiro ou local. A informação atual pode ser um subconjunto ou um superconjunto da versão original. Por exemplo, os metadados que contêm recursos podem fazer com que o servidor original conheça a meta-informação super. A utilização deste código de estado não é obrigatória e só é adequada se a resposta tivesse devolvido 200 OK sem ele. |
| 204 | O servidor processou o pedido com êxito, mas não necessita de devolver qualquer conteúdo físico e pretende devolver meta-informação actualizada. A resposta pode devolver meta-informação nova ou actualizada sob a forma de cabeçalhos de entidade. Se esses cabeçalhos existirem, devem corresponder às variáveis pedidas. Se o cliente for um programa de navegação, o programa de navegação do utilizador DEVERÁ manter a página para a qual o pedido foi enviado sem qualquer alteração da visualização do documento, embora, de acordo com a especificação, as meta-informações novas ou actualizadas DEVEM ser aplicadas ao documento na visualização ativa do programa de navegação do utilizador. Uma vez que a resposta 204 é proibida de conter qualquer corpo de mensagem, termina sempre com a primeira linha em branco após o cabeçalho da mensagem. |
| 205 | O servidor processou o pedido com êxito e não devolveu nada. No entanto, ao contrário da resposta 204, a resposta que devolve este código de estado pede ao requerente para repor a vista do documento. Esta resposta é utilizada principalmente para reiniciar o formulário imediatamente após aceitar a entrada do utilizador, para que este possa iniciar facilmente outra entrada. Tal como a resposta 204, esta resposta não pode 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 do pedido GET. As ferramentas de descarregamento HTTP, como o FlashGet ou o Thunderbolt, utilizam este tipo de resposta para efetuar descarregamentos intermitentes ou para dividir um documento de grandes dimensões em vários segmentos de descarregamento em simultâneo. O pedido deve conter um cabeçalho Range para indicar o intervalo de conteúdos que o cliente pretende receber e pode conter um If-Range como condição de pedido. A resposta deve conter os seguintes campos de cabeçalho: Content-Range para indicar o âmbito do conteúdo devolvido nesta resposta; no caso de uma descarga multi-segmento com um Content-Type de multipart/byteranges, cada segmento multi-parte deve conter um campo Content-Range indicando o âmbito do conteúdo nesse segmento. Se a resposta contiver um Content-Length, o seu valor deve corresponder ao número real de bytes no intervalo de conteúdo que devolve. date ETag e/ou Content-Location, se o mesmo pedido deveria ter devolvido uma resposta 200. Expires, Cache-Control e/ou Vary, se os seus valores puderem ser diferentes de outras respostas com as mesmas variáveis. Expires, Cache-Control, e/ou Vary, se os seus valores puderem ser diferentes dos valores de outras respostas anteriores para as mesmas variáveis. Esta resposta NÃO DEVERÁ conter outros cabeçalhos de entidade se o pedido utilizar a validação de cache forte If-Range, e NÃO DEVERÁ conter outros cabeçalhos de entidade se o pedido utilizar a validação de cache fraca If-Range; isto evita inconsistências entre o conteúdo da entidade em cache e a informação actualizada do cabeçalho da entidade. Caso contrário, esta resposta DEVERÁ conter todos os campos de cabeçalho de entidade que deveriam ter sido devolvidos em todas as respostas 200 que deveriam ter sido devolvidas. Se os cabeçalhos ETag ou Last-Modified não corresponderem exatamente, a cache do lado do cliente DEVERÁ proibir a combinação do conteúdo devolvido na resposta 206 com qualquer conteúdo previamente colocado em cache. Qualquer cache que não suporte os cabeçalhos Range e Content-Range está proibida de armazenar em cache o conteúdo devolvido pela resposta 206. |
| 207 | O código de estado, tal como alargado pelo WebDAV (RFC 2518), significa que o corpo da mensagem subsequente será uma mensagem XML e pode conter uma série de códigos de resposta separados, dependendo do número de subpedidos anteriores. |
| 300 | O recurso solicitado tem uma série de mensagens de retorno alternativas, cada uma com o seu próprio endereço específico e informações de negociação orientadas para o navegador. O utilizador ou o browser podem selecionar um endereço preferido para redireccionamento. A menos que se trate de um pedido HEAD, a resposta deve incluir uma entidade que é uma lista de caraterísticas e endereços de recursos a partir da qual o utilizador ou o navegador pode selecionar o endereço de redireccionamento mais adequado. O formato desta 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 nas capacidades do próprio navegador. É claro que a especificação RFC 2616 não especifica como essa escolha automática deve ser feita. Se o próprio servidor já tiver uma escolha preferida de retorno, então o URI desse retorno deve ser especificado em Localização; o navegador pode usar esse valor de Localização como endereço para redireccionamento automático. Além disso, esta resposta também pode ser armazenada em cache, a menos que especificado de outra forma. |
| 301 | O recurso solicitado foi movido permanentemente para a nova localização e quaisquer referências futuras a ele devem usar um dos vários URIs retornados nesta resposta. Se possível, os clientes com capacidades de edição de ligações devem alterar automaticamente o endereço solicitado para o endereço devolvido pelo servidor. Esta resposta também pode ser armazenada em cache, salvo indicação em contrário. O novo URI permanente deve ser devolvido no campo Location da resposta. A menos que se trate de um pedido HEAD, a entidade de resposta deve conter uma hiperligação para o novo URI e uma breve descrição. Se não se tratar de um pedido GET ou HEAD, o navegador está, por conseguinte, proibido de redirecionar automaticamente, a menos que seja confirmado pelo utilizador, uma vez que os termos do pedido podem mudar em consequência. Nota: Para alguns navegadores que utilizam o protocolo HTTP/1.0, quando enviam um pedido POST e obtêm uma resposta 301, o pedido de redireccionamento seguinte será um GET. |
| 302 | O recurso solicitado responde agora temporariamente ao pedido a partir de um URI diferente. Uma vez que este redireccionamento é temporário, o cliente deve continuar a enviar futuros pedidos para o endereço original. Esta resposta só é armazenável em cache se for especificada em Cache-Control ou Expires. O novo URI temporário deve ser devolvido no campo Location da resposta. A menos que se trate de um pedido HEAD, a entidade de resposta deve conter uma hiperligação para o novo URI e uma breve descrição. Se não se tratar de um pedido GET ou HEAD, o navegador está proibido de redirecionar automaticamente, a menos que seja confirmado pelo utilizador, uma vez que os termos do pedido podem ser alterados em consequência. Nota: Embora as especificações RFC 1945 e RFC 2068 não permitam que o cliente altere o método do pedido no redireccionamento, muitos navegadores existentes tratam a resposta 302 como uma resposta 303 e utilizam GET para aceder ao URI especificado na Localização, ignorando o método do pedido original. Os códigos de estado 303 e 307 foram adicionados para clarificar a resposta que o servidor espera do cliente. |
| 303 | A resposta ao pedido atual pode ser encontrada noutro URI e o cliente deve aceder a esse recurso utilizando GET. Este método existe principalmente para permitir que a saída do pedido POST ativado por script seja redireccionada para um novo recurso. Este novo URI não é uma referência alternativa ao recurso original. Além disso, a resposta 303 é proibida de ser armazenada em cache. Naturalmente, o segundo pedido (redireccionamento) pode ser colocado em cache. O novo URI deve ser devolvido no campo Location da resposta. A menos que se trate de um pedido HEAD, a entidade de resposta deve conter uma hiperligação para o novo URI e uma breve descrição. Nota: Muitos navegadores anteriores às versões HTTP/1.1 não compreendem corretamente o estado 303. Se for necessário considerar a interação com estes navegadores, o código de estado 302 deve ser suficiente, uma vez que a maioria dos navegadores trata a resposta 302 exatamente da mesma forma que a especificação acima requer que o cliente trate a resposta 303. |
| 304 | O servidor DEVERÁ devolver este código de estado se o cliente enviar um pedido GET condicional que tenha sido autorizado e se o conteúdo do documento (desde a última visita ou de acordo com as condições do pedido) não tiver sido alterado. As respostas 304 são proibidas de conter corpos de mensagens e, por conseguinte, terminam sempre com a primeira linha em branco após o cabeçalho da mensagem. A resposta DEVE conter os seguintes cabeçalhos: Data, exceto se o servidor não tiver um relógio. Se um servidor sem relógio seguir estas regras, então o servidor proxy e o cliente podem adicionar o campo Data 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 o mesmo pedido tivesse devolvido uma resposta 200.Expires Expires, Cache-Control e/ou Vary, se o valor puder ser diferente do valor correspondente a outras respostas anteriores para a mesma variável. Se este pedido de resposta utiliza uma validação de cache forte, então esta resposta não deve conter outros cabeçalhos de entidade; caso contrário (por exemplo, um pedido GET condicional utiliza uma validação de cache fraca), esta resposta está proibida de conter outros cabeçalhos de entidade; isto evita inconsistências entre o conteúdo da entidade em cache e a informação actualizada do cabeçalho da entidade. Se uma resposta 304 indicar que uma entidade não está atualmente em cache, o sistema de cache deve ignorar a resposta e repetir o pedido 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 actualizados na resposta. |
| 305 | O recurso solicitado deve ser acedido através do proxy especificado. O campo Localização dará informações sobre o URI onde o proxy especificado está localizado. o destinatário terá de enviar um pedido separado repetidamente para aceder ao recurso através deste proxy. Apenas o servidor original pode criar uma resposta 305. Nota: Não está claro no RFC 2068 que uma resposta 305 se destina a redirecionar um único pedido e só pode ser criada pelo servidor original. Ignorar essas restrições pode levar a sérias conseqüências de segurança. |
| 306 | Na última versão da especificação, o código de estado 306 já não é utilizado. |
| 307 | O recurso solicitado passa a responder temporariamente ao pedido a partir de um URI diferente. Uma vez que estes redireccionamentos são temporários, os clientes devem continuar a enviar futuros pedidos para o endereço original. Esta resposta só é armazenável em cache se for especificada em Cache-Control ou Expires. O novo URI temporário deve ser devolvido no campo Location da resposta. A menos que se trate de um pedido HEAD, a entidade de resposta deve conter uma hiperligação para o novo URI e uma breve descrição. Como alguns navegadores não reconhecem a resposta 307, é necessário acrescentar as informações acima para que o utilizador possa compreender e solicitar o acesso ao novo URI. Se não se tratar de um pedido GET ou HEAD, o browser proíbe o redireccionamento automático, a menos que seja confirmado pelo utilizador, porque as condições do pedido podem mudar. |
| 400 | 1) Existe um erro semântico e o pedido atual não pode ser entendido pelo servidor. A menos que seja modificado, o cliente não deve submeter repetidamente este pedido. 2, os parâmetros do pedido estão errados. |
| 401 | O pedido atual requer a autenticação do utilizador. A resposta deve conter um cabeçalho WWW-Authenticate para o recurso solicitado para pedir informações sobre o utilizador. O cliente pode submeter repetidamente um pedido que contenha a informação apropriada do cabeçalho Authorisation. Se o pedido atual já contiver credenciais de autorização, a 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 tentado a autenticação pelo menos uma vez, então o navegador DEVERÁ apresentar ao utilizador as informações sobre a entidade contidas na resposta, uma vez que estas informações sobre a entidade podem conter informações de diagnóstico relevantes. Ver RFC 2617. |
| 402 | Este código de estado está reservado para possíveis requisitos futuros. |
| 403 | O servidor compreendeu o pedido mas recusa-se a executá-lo. Ao contrário de uma resposta 401, a autenticação não fornece qualquer ajuda e este pedido não deve ser reenviado. Se não se tratar de um pedido HEAD e o servidor quiser falar claramente sobre o motivo pelo qual o pedido não pode ser executado, então o motivo da recusa deve ser descrito na entidade. É claro que o servidor também pode devolver uma resposta 404 se não quiser dar qualquer informação ao cliente. |
| 404 | O pedido falhou, o recurso solicitado não foi encontrado no servidor. Não existe qualquer informação que permita ao utilizador saber se a situação é temporária ou permanente. Se o servidor tiver conhecimento da situação, deve utilizar o código de estado 410 para informar o utilizador de que o recurso antigo está permanentemente indisponível devido a um mecanismo de configuração interno e que não há redireccionamento disponível. O 404 é muito utilizado quando o servidor não quer revelar a razão pela qual o pedido foi rejeitado ou quando não há outra resposta adequada disponível. |
| 405 | O método de pedido especificado na linha de pedido não pode ser utilizado para pedir o recurso correspondente. A resposta deve devolver um cabeçalho Allow indicando a lista de métodos de pedido que são aceitáveis para o recurso atual. Dado que os métodos PUT e DELETE escrevem no recurso no servidor, a maioria dos servidores Web não suporta estes métodos de pedido ou não os permite por defeito, e devolverá um erro 405 para tais pedidos. |
| 406 | As caraterísticas do conteúdo do recurso solicitado não satisfazem as condições do cabeçalho do pedido e a entidade de resposta não pode ser gerada. A menos que se trate de um pedido HEAD, a resposta deve devolver uma entidade que contenha uma lista de propriedades e endereços de entidades a partir da qual o utilizador ou o browser podem selecionar o mais adequado. O formato da entidade é determinado pelo tipo de media definido no cabeçalho Content-Type. Os navegadores podem fazer as suas próprias escolhas com base no formato e nas suas próprias capacidades. No entanto, a especificação não define quaisquer critérios para efetuar essas escolhas automáticas. |
| 407 | Semelhante à resposta 401, exceto que o cliente DEVE autenticar-se no servidor proxy. O servidor proxy DEVE devolver um Proxy-Authenticate para interrogação de identidade. O cliente PODE devolver um cabeçalho Proxy-Authorization para autenticação. Ver RFC 2617. |
| 408 | Tempo limite do pedido. O cliente não concluiu o envio de um pedido dentro do tempo que o servidor estava preparado para esperar. O cliente pode voltar a enviar o pedido em qualquer altura sem efetuar quaisquer alterações. |
| 409 | O pedido não pôde ser concluído devido a um conflito com o estado atual do recurso solicitado. Este código só pode ser utilizado se o utilizador for considerado capaz de resolver o conflito e voltar a apresentar um novo pedido. A resposta deve conter informações suficientes para que o utilizador possa descobrir a origem do conflito. Os conflitos ocorrem normalmente no processamento de pedidos PUT. Por exemplo, num ambiente de verificação de versões, se a informação de versão anexada a um PUT submetido para modificar um determinado recurso entrar em conflito com um pedido anterior (de terceiros), o servidor deve devolver um erro 409 informando o utilizador de que o pedido não pôde ser completado. Neste caso, é provável que a entidade de resposta contenha uma comparação das diferenças entre as duas versões em conflito, para que o utilizador possa voltar a apresentar a nova versão após a fusão. |
| 410 | O recurso solicitado já não está disponível no servidor e não tem qualquer endereço de reencaminhamento conhecido. Esta situação deve ser considerada permanente. Se possível, os clientes com capacidades de edição de ligações devem remover todas as referências a este endereço com a autorização do utilizador. Se o servidor não souber ou não puder determinar se esta condição é permanente, deve ser utilizado um código de estado 404. Salvo indicação em contrário, esta resposta pode ser armazenada em cache.410 O objetivo da resposta é principalmente ajudar o webmaster a manter o sítio, informando o utilizador de que o recurso já não está disponível e que o proprietário do servidor deseja que todas as ligações remotas a este recurso sejam também removidas. Este tipo de evento é comum em serviços de valor acrescentado com tempo limitado. Do mesmo modo, a resposta 410 é utilizada para notificar os clientes de que um recurso que pertencia originalmente a um indivíduo no sítio do servidor atual já não está disponível. Naturalmente, cabe inteiramente ao proprietário do servidor decidir se todos os recursos permanentemente indisponíveis precisam de ser marcados como "410 Gone" e durante quanto tempo esta marcação precisa de ser mantida. |
| 411 | O servidor recusa-se a aceitar pedidos sem o cabeçalho Content-Length definido. Depois de adicionar um cabeçalho Content-Length válido indicando o comprimento do corpo da mensagem do pedido, o cliente pode submeter o pedido novamente. |
| 412 | O servidor não conseguiu satisfazer um ou mais dos pré-requisitos ao verificar que eles foram fornecidos no campo de cabeçalho do pedido. Este código de estado permite ao cliente definir pré-condições na meta-mensagem do pedido (dados do campo do cabeçalho do pedido) aquando da obtenção de um recurso, impedindo assim que o método de pedido seja aplicado a recursos diferentes do conteúdo pretendido. |
| 413 | O servidor recusa-se a processar o pedido atual porque este apresenta dados de entidade de um tamanho superior ao que o servidor está disposto ou é capaz de tratar. Neste caso, o servidor pode fechar a ligação para impedir que o cliente continue a enviar este pedido. Se esta condição for temporária, o servidor deve devolver um cabeçalho de resposta Retry-After para informar o cliente de quanto tempo pode voltar a tentar. |
| 414 | O comprimento do URI do pedido excede o comprimento que o servidor pode interpretar, pelo que o servidor se recusa a servir o pedido. Esta situação é rara e ocorre frequentemente quando um envio de formulário que deveria ter utilizado o método POST se transforma num método GET, resultando numa cadeia de caracteres de consulta longa. Redirecionar URI "buracos negros", como a utilização do URI antigo como parte do novo URI em cada redireccionamento, resultando num URI longo após vários redireccionamentos. Os clientes estão a tentar atacar os servidores explorando as vulnerabilidades de segurança que existem em alguns servidores. Esses servidores utilizam uma memória intermédia de comprimento fixo para ler ou manipular o URI de um pedido e, quando os parâmetros após um GET excedem um determinado valor, pode ocorrer um estouro da memória intermédia, conduzindo à execução arbitrária de código [1]. Os servidores sem estas vulnerabilidades devem devolver um código de estado 414. |
| 415 | Para o método e o recurso atualmente solicitados, a entidade apresentada no pedido não está num formato suportado pelo servidor, pelo que o pedido é rejeitado. |
| 416 | Se o pedido contiver um cabeçalho de pedido Range, e quaisquer intervalos de dados especificados no Range não se sobrepuserem aos intervalos disponíveis para o recurso atual, e o cabeçalho de pedido If-Range não estiver definido no pedido, então o servidor deverá devolver um código de estado 416. Se o Intervalo utilizar intervalos de bytes, é esse o caso se a primeira posição de bytes de todos os intervalos de dados especificados no pedido exceder o comprimento do recurso atual. O servidor deve também incluir um cabeçalho de entidade Content-Range que especifique o comprimento do recurso atual juntamente com o código de estado 416. Esta resposta também está proibida de utilizar multipart/byteranges como Content-Type. |
| 417 | O conteúdo esperado especificado no cabeçalho do pedido Expect não pode ser cumprido pelo servidor, ou este servidor é um servidor proxy que tem provas claras de que o conteúdo de Expect não pode ser cumprido no próximo nó da rota atual. |
| 421 | O número de ligações ao servidor a partir do endereço IP onde o cliente atual está localizado excede o máximo permitido pelo servidor. Normalmente, o endereço IP refere-se aqui ao endereço do cliente visto do servidor (por exemplo, o gateway do utilizador ou o endereço do servidor proxy). Neste caso, a contagem de ligações pode envolver mais do que um utilizador final. |
| 422 | O número de ligações ao servidor a partir do endereço IP do cliente atual excede o máximo permitido pelo servidor. Normalmente, o endereço IP refere-se ao endereço do cliente visto do servidor (por exemplo, o gateway do utilizador ou o endereço do servidor proxy). Neste caso, a contagem de ligações pode envolver mais do que um utilizador final. |
| 422 | O pedido foi formatado corretamente, mas não pôde ser respondido porque continha erros de semântica. (RFC 4918 WebDAV) 423 Bloqueado O recurso atual está bloqueado. (RFC 4918 WebDAV) |
| 424 | O pedido atual falhou devido a um erro que ocorreu num pedido anterior, tal como PROPPATCH. (RFC 4918 WebDAV) |
| 425 | Definido no projeto de Colecções Avançadas WebDav, mas não aparece no Protocolo de Colecções Sequenciais WebDAV (RFC 3658). |
| 426 | Os clientes devem mudar para TLS/1.0.(RFC 2817) |
| 449 | Alargado pela Microsoft para representar que os pedidos devem ser repetidos após a ação apropriada ter sido executada. |
| 500 | O servidor deparou-se com uma condição imprevista que o impediu de concluir o processamento do pedido. Normalmente, esse problema ocorre quando há um erro no código do programa do servidor. |
| 501 | O servidor não suporta uma caraterística específica que é necessária para o pedido atual. Quando o servidor não consegue reconhecer o método solicitado e não consegue suportar o seu pedido de qualquer recurso. |
| 502 | Um servidor que funciona como gateway ou proxy recebe uma resposta inválida de um servidor a montante quando tenta executar um pedido. |
| 503 | O servidor não pode atualmente processar o pedido devido a uma manutenção temporária do servidor ou a uma sobrecarga. Esta condição é temporária e será restabelecida após algum tempo. Se for expetável um atraso, a resposta pode incluir um cabeçalho Retry-After para indicar o atraso. Se esta informação "Retry-After" não for fornecida, o cliente deve tratá-la da mesma forma que uma resposta 500. Nota: A existência do código de estado 503 não significa que o servidor tenha de o utilizar se estiver sobrecarregado. Alguns servidores desejam simplesmente negar uma ligação ao cliente. |
| 504 | Um servidor que funciona como gateway ou proxy e que tenta efetuar um pedido não recebe uma resposta atempada de um servidor a montante (um servidor identificado por um URI, como HTTP, FTP, LDAP) ou de um servidor secundário (como DNS). Nota: Alguns servidores proxy devolvem um erro 400 ou 500 quando a pesquisa de DNS não é possível. |
| 505 | O servidor não suporta, ou recusa-se a suportar, a versão de HTTP utilizada no pedido. Isto implica que o servidor não pode ou não quer utilizar a mesma versão que o cliente. A resposta deve conter uma entidade que descreva a razão pela qual a versão não é suportada e quais os protocolos que o servidor suporta. |
| 506 | Alargado pelo Protocolo de Negociação de Conteúdos Transparentes (RFC 2295) para representar uma má configuração interna por parte do servidor: o recurso da Variante de Negociação solicitado está configurado para se utilizar a si próprio na negociação de conteúdos transparentes, pelo que não é um foco adequado num processo de negociação. |
| 507 | O servidor não é capaz de armazenar o conteúdo necessário para completar o pedido. Esta condição é considerada temporária.WebDAV (RFC 4918) |
| 509 | O servidor atingiu o seu limite de largura de banda. Este não é um código de status oficial, mas ainda é amplamente utilizado. |
| 510 | A política necessária para obter o recurso não não foi cumprida. (RFC 2774) |