O código de estado HTTP é um código de 3 dígitos devolvido pelo servidor em resposta a um pedido, que é utilizado para identificar o resultado do pedido. Esta ferramenta fornece uma classifica??o normalizada e uma interpreta??o de cenários, adequada para programadores, pessoal de opera??es e manuten??o e estudantes de tecnologia de redes.
Todas as explica??es s?o baseadas no documento padr?o RFC, evitando diferen?as regionais de express?o e garantindo que os utilizadores de todo o mundo compreendem o mesmo.
| Códigos 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 tiver sido concluído. O servidor deve enviar uma resposta final ao cliente quando o pedido estiver completo. |
| 101 | O servidor compreendeu o pedido do cliente e notificá-lo-á através do cabe?alho Upgrade de que foi utilizado um protocolo diferente para completar o pedido. Depois de enviar a última linha em branco da resposta, o servidor mudará para os protocolos definidos no cabe?alho Upgrade. Isto só deve ser feito se for mais vantajoso mudar para o novo protocolo. Por exemplo, mudar para uma nova vers?o do HTTP pode ser vantajoso em rela??o a uma vers?o mais antiga, ou mudar para um protocolo síncrono e em tempo real para fornecer recursos que tirem partido de tais caraterísticas. |
| 102 | Os códigos de estado, alargados pelo WebDAV (RFC 2518), indicam que o processamento irá continuar. |
| 200 | O pedido foi bem sucedido, e os cabe?alhos de resposta ou o corpo de dados desejado pelo pedido ser?o devolvidos com a resposta. |
| 201 | O pedido foi satisfeito e um novo recurso foi criado em resposta ao pedido, e o seu URI foi devolvido com o cabe?alho Location. Se o recurso solicitado n?o puder ser criado a tempo, deve ser devolvido o seguinte'202 Accepted'。 |
| 202 | O servidor aceitou o pedido, mas ainda n?o o processou. Assim como pode ser rejeitado, o pedido pode ou n?o ser executado eventualmente. No caso 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 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 que o cliente tenha de manter uma liga??o ao servidor até que a opera??o em lotes esteja concluída. Uma resposta que aceite um pedido de processamento e devolva um código de estado 202 deve 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 ou n?o concluída. |
| 203 | O servidor processou com sucesso 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 local ou de um terceiro. A informa??o atual pode 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 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 estes 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 a meta-informa??o nova ou actualizada DEVA, de acordo com a especifica??o, ser aplicada 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 trata o pedido com êxito e n?o devolve 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 ficheiro grande em vários descarregamentos ao mesmo tempo. 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 ou, no caso de descarregamentos 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 ?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 devolvido. Expires, Cache-Control, e/ou Vary, se os seus valores puderem ser diferentes dos valores de outras respostas anteriores com as mesmas variáveis. Esta resposta n?o deve conter outros cabe?alhos de entidade se o pedido utilizar uma valida??o de cache If-Range forte, e n?o deve conter outros cabe?alhos de entidade se o pedido utilizar uma valida??o de cache If-Range fraca; 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 na resposta 200. Se os cabe?alhos ETag ou Last-Modified n?o corresponderem exatamente, a cache do lado do cliente n?o deve permitir a combina??o do conteúdo devolvido na resposta 206 com qualquer conteúdo previamente armazenado 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 | Códigos de estado alargados pelo WebDAV(RFC 2518) O código de estado, tal como alargado pelo WebDAV, 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 respostas alternativas, cada uma com o seu próprio endere?o específico e informa??es de negocia??o orientadas para o navegador. Cabe ao utilizador ou ao navegador escolher 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. Obviamente, a especifica??o RFC 2616 n?o especifica como deve ser feita esta sele??o automática. Se o próprio servidor já tiver uma op??o de retorno preferida, o URI do retorno deve ser especificado na Localiza??o; os navegadores podem utilizar este valor de Localiza??o como endere?o para o redireccionamento 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 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á proibido de redirecionar automaticamente, a menos que seja confirmado pelo utilizador, uma vez que os termos do pedido podem mudar em resultado disso. 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á 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. A resposta só pode ser armazenada 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 durante o 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 de substitui??o para o recurso original. Além disso, a resposta 303 n?o pode ser armazenada em cache. Obviamente, o segundo pedido (redireccionamento) pode ser armazenado 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 ao 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 deverá funcionar, 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 | Este código de estado deve ser devolvido pelo servidor se o cliente enviar um pedido GET condicional e o pedido for permitido, e se o conteúdo do documento n?o tiver sido alterado (quer desde a última visita, quer de acordo com as condi??es do pedido). As respostas 304 s?o proibidas de conter um corpo de mensagem, pelo que terminam sempre com a primeira linha em branco após o cabe?alho da mensagem. A resposta deve conter as seguintes informa??es de cabe?alho: Data, exceto se o servidor n?o tiver um relógio. Se o servidor n?o tiver um relógio segue 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 (como especificado na RFC 2068), e o mecanismo de cache funcionará corretamente.ETag e/ou Content-Location, se o mesmo pedido deveria ter retornado uma resposta 200. Expires, Cache-Control e/ou Vary, se os seus valores puderem ser diferentes dos valores de outras respostas anteriores com as mesmas variáveis. Se o pedido de resposta utilizar uma valida??o de cache forte, ent?o a resposta n?o deve conter cabe?alhos de entidade adicionais; caso contrário (por exemplo, um pedido GET condicional utiliza uma valida??o de cache fraca), a resposta é proibida de conter cabe?alhos de entidade adicionais; 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 de um proxy especificado. O campo Localiza??o fornecerá informa??es sobre o URI do proxy especificado e o destinatário terá de enviar repetidamente um pedido separado 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 de origem. 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 | Os recursos solicitados agora respondem temporariamente a pedidos de URIs diferentes. Uma vez que este redireccionamento é temporário, 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 navegador proíbe o redireccionamento automático, salvo confirma??o do utilizador, porque as condi??es do pedido podem mudar. |
| 400 | 1, erro sem?ntico, o pedido atual n?o pode ser entendido pelo servidor. A menos que seja modificado, o cliente n?o deve repetir o 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 voltar a apresentar um pedido com as informa??es adequadas do cabe?alho Authorisation. Se o pedido 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 deve mostrar ao utilizador as informa??es sobre a entidade contidas na resposta, uma vez que essas informa??es 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 o pedido n?o deve ser reenviado. Se n?o se tratar de um pedido HEAD e o servidor quiser poder dizer porque é que o pedido n?o pode ser executado, ent?o o motivo da recusa deve ser descrito na entidade. Naturalmente, o servidor também pode devolver uma resposta 404 se n?o quiser que o cliente obtenha qualquer informa??o. |
| 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 estiver ciente da situa??o, deve utilizar o código de estado 410 para informar o servidor de que o recurso antigo está permanentemente indisponível devido a algum mecanismo de configura??o interna e que n?o há redireccionamento disponível. 404 é amplamente 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. Uma vez 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 n?o pode ser gerada uma entidade de resposta. A menos que se trate de um pedido HEAD, a resposta deve devolver uma entidade que contenha as caraterísticas de entidade mais adequadas e uma lista de endere?os a partir dos quais o utilizador ou o browser podem escolher. O formato da entidade é determinado pelo tipo de media definido no cabe?alho Content-Type. O navegador pode fazer a melhor escolha 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 tem de se autenticar no servidor proxy. O servidor proxy DEVE devolver um Proxy-Authenticate para interroga??o de identidade. O cliente pode devolver um cabe?alho Proxy-Authorisation para autentica??o. Ver RFC 2617. |
| 408 | Tempo limite do pedido. O cliente n?o completou um pedido dentro do tempo que o servidor estava preparado para esperar. O cliente pode voltar a apresentar 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 frequentemente no processamento de pedidos PUT. Por exemplo, num ambiente de verifica??o de vers?es, um PUT apresentado para modificar um determinado recurso com informa??es de vers?o que entrem em conflito com um pedido anterior (de terceiros) deve devolver um erro 409 informando o utilizador de que o pedido n?o p?de ser concluído. 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 submeter a nova vers?o fundida. |
| 410 | O recurso solicitado já n?o está disponível no servidor e n?o existe um 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 a situa??o é permanente, deve ser utilizado um código de estado 404. Salvo especifica??o em contrário, esta resposta pode ser armazenada em cache. O objetivo da resposta 410 é 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 pretende que todas as liga??es remotas ao recurso sejam também eliminadas. Este tipo de evento é comum em servi?os de valor acrescentado com tempo limitado. Do mesmo modo, a resposta 410 é utilizada para notificar o cliente de que um recurso pertencente a um indivíduo já n?o está disponível no sítio atual do servidor. Naturalmente, a quest?o de saber se todos os recursos permanentemente indisponíveis precisam de ser marcados como tal, e por quanto tempo precisam de ser mantidos assim, também é importante.'410 Gone'， A marca??o de recursos permanentemente indisponíveis e o período de tempo durante o qual devem ser mantidos assim é da inteira responsabilidade do proprietário do servidor. |
| 411 | O servidor recusa-se a aceitar pedidos sem o cabe?alho Content-Length definido. O cliente pode reenviar o pedido depois de adicionar um cabe?alho Content-Length válido indicando o comprimento do corpo da mensagem do pedido. |
| 412 | O servidor n?o conseguiu satisfazer um ou mais dos pré-requisitos indicados no campo do cabe?alho do pedido aquando da valida??o do pedido. Este código de estado permite ao cliente definir condi??es prévias na meta-informa??o do pedido (dados do campo do cabe?alho do pedido) quando obtém um recurso, impedindo assim que o método de pedido seja aplicado a recursos que n?o sejam o conteúdo pretendido. |
| 413 | O servidor recusa-se a processar o pedido atual porque este apresenta mais dados físicos do 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 o pedido. Se a situa??o for temporária, o servidor deve devolver um cabe?alho Retry-After para informar o cliente de quanto tempo disp?e para tentar novamente. |
| 414 | O URI do pedido é mais longo do que o servidor pode interpretar, pelo que o servidor se recusa a servir o pedido. Isto é raro, e normalmente ocorre quando um envio de formulário que deveria ter usado o método POST se torna um método GET, resultando numa Query String longa. Redirecionar URI "buracos negros", como a utiliza??o do URI antigo como parte do novo URI para 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 solicitado, o que pode resultar num estouro da memória intermédia quando o par?metro GET excede um determinado valor, 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 atualmente solicitado e o recurso solicitado, a entidade apresentada no pedido n?o está num formato suportado pelo servidor e o pedido é rejeitado. |
| 416 | Se o pedido contiver um cabe?alho de pedido Range, e quaisquer intervalos de dados especificados no Range n?o coincidirem com os 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 Range utilizar intervalos de bytes, isso significa que o primeiro byte de todos os intervalos de dados especificados no pedido excede 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 o 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 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, mais do que um utilizador final pode estar envolvido na contagem de liga??es. |
| 422 | O número de liga??es do endere?o IP do cliente atual para o servidor 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 endere?o do gateway do utilizador ou do servidor proxy). Neste caso, mais do que um utilizador final pode estar envolvido na contagem de liga??es. |
| 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) 423 Bloqueado |
| 424 | O pedido atual falhou devido a um erro num pedido anterior, como o PROPPATCH. (RFC 4918 WebDAV) |
| 425 | Definido no projeto 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 | 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 funcionalidade requerida pelo pedido atual. Quando o servidor n?o reconhece o método solicitado e n?o pode 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 um período de 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 querem simplesmente negar uma liga??o ao cliente. |
| 504 | Um servidor que actua como gateway ou proxy que tenta executar 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 consegue armazenar o conteúdo necessário para satisfazer 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 estado oficial, mas continua a ser amplamente utilizado. |
| 510 | A política necessária para obter o recurso n?o foi satisfeita. (RFC 2774) |