| Código de status HTTP | Significado do código de status |
|---|
| 100 | O lado cliente deve continuar a enviar solicitações. Esta resposta temporária é usada para informar o lado cliente de que algumas de suas solicitações foram recebidas pelo servidor e não foram rejeitadas. O lado cliente deve continuar a enviar o resto da solicitação ou ignorar a resposta se a solicitação já foi completada. O servidor deve enviar uma resposta final para o lado cliente após a conclusão da solicitação. |
| 101 | O servidor compreendeu o pedido do cliente e informará o lado cliente através do cabeçalho Upgrade para usar um protocolo diferente para completar o pedido. Após enviar a última linha em branco na resposta, o servidor passará para aqueles protocolos definidos no cabeçalho Upgrade. Medidas semelhantes devem ser tomadas apenas quando a troca para um novo protocolo for mais benéfica. Por exemplo, trocar para uma nova versão do HTTP tem vantagens em relação a uma versão antiga, ou trocar para um real-tempo e protocolo síncrono para entregar recursos que aproveitam tais funcionalidades. |
| 102 | O código de status estendido pelo WebDAV (RFC 2518) indica que o processamento continuará. |
| 200. | O pedido foi bem-sucedido, e os cabeçalhos de resposta ou corpos de dados desejados são retornados com a resposta. |
| 201 | O pedido foi atendido, e um novo recurso foi criado com base nos requisitos do pedido, e seu URI foi retornado com o cabeçalho Location. Se o recurso requerido não puder ser criado a tempo,'202 Aceito' deve ser retornado. |
| 202 | O servidor aceitou o pedido, mas ainda não o processou. Assim como ele pode ser rejeitado, o pedido pode ou não ser executado eventualmente. No caso de operações assíncronas, não há maneira mais conveniente de fazer isso do que enviar este código de status. O propósito de retornar um 202 resposta de código de status para permitir que o servidor aceite pedidos de outros processos (como um lote-operação baseada que é executada apenas uma vez por dia) sem a necessidade de manter o lado cliente conectado ao servidor até que a operação em lote seja concluída. Em resposta ao aceitar um pedido para processamento e retornar um 202 código de status, a entidade retornada deve incluir algumas informações que indiquem o estado atual do processo, bem como um ponteiro para o monitor ou previsão de status do processo, para que o usuário possa estimar se a operação foi concluída. |
| 203 | o servidor processou com sucesso a solicitação, mas a informação meta do cabeçalho de entidade retornada não é um conjunto determinístico válido no servidor de origem, mas é local ou de terceiro-copia da parte. As informações atuais podem ser um subconjunto ou superconjunto da versão original. Por exemplo, metadados contendo recursos podem fazer o servidor de origem saber o supermeta. O uso deste código de status não é necessário e é apropriado apenas se a resposta retornar 200 OK sem este código de status. |
| 204 | o servidor processou com sucesso a solicitação, mas não precisa retornar qualquer conteúdo físico, e deseja retornar informações meta atualizadas. A resposta pode estar na forma de um cabeçalho de entidade, retornando novas ou informações meta atualizadas. Se essa informação de cabeçalho existir, deve corresponder à variável solicitada. Se o lado do cliente for um navegador, então o navegador do usuário deve manter a página que enviou a solicitação sem qualquer alteração na visualização do documento, mesmo que novas ou informações meta atualizadas devam ser aplicadas ao documento na visualização ativa do navegador do usuário de acordo com a especificação. Desde que o 204 a resposta não é permitida para incluir qualquer corpo de mensagem, ela sempre termina com a primeira linha em branco após o cabeçalho. |
| 205 | o servidor processou com sucesso a solicitação e não retornou nada. Mas ao contrário do 204 resposta, a resposta que retorna este código de status requer que o solicitante redefina a visualização do documento. Esta resposta é usada principalmente para redefinir o formulário imediatamente após aceitar a entrada do usuário, para que o usuário possa facilmente começar outra entrada. Como o 204 resposta, essa resposta também é proibida de incluir qualquer corpo de mensagem e termina com a primeira linha em branco após o cabeçalho. |
| 206 | O servidor processou com sucesso parte da solicitação GET. Ferramentas de download HTTP como FlashGet ou Xunlei usam esse tipo de resposta para implementar uma continuação de interrupção ou para dividir um grande documento em múltiplos segmentos de download para download simultâneo. A solicitação deve conter um cabeçalho Range para indicar o intervalo de conteúdo desejado pelo lado do cliente, e pode incluir If-Range como condição de solicitação. A resposta deve conter os seguintes campos de cabeçalho: Content-Range para indicar o intervalo de conteúdo retornado nessa resposta; se for um multi-download do segmento com Content-Tipo multipart/byteranges, cada segmento multipart deve conter um Content-campo Range para indicar o intervalo de conteúdo deste segmento. Se a resposta contiver Content-Length, então seu valor deve coincidir com o número real de bytes no intervalo de conteúdo que ela retorna. Data ETag e/ou Content-Location, se a mesma solicitação devia retornar uma 2resposta 00. Expires, Cache-Controle, e/ou Vary, se seu valor pode ser diferente do valor correspondente a outras respostas para a mesma variável antes. Se essa solicitação de resposta usar If-cache de validação forte do Range, então essa resposta não deve incluir outros cabeçalhos de entidade; se essa resposta de solicitação usar If-cache de validação fraca do Range, então essa resposta não deve incluir outros cabeçalhos de entidade; isso evita inconsistências entre o conteúdo armazenado em cache da entidade e as informações de cabeçalho da entidade atualizadas. De outra forma, essa resposta deve conter todos os campos de cabeçalho de entidade que devem ser retornados em uma 2resposta 00. Se o ETag ou o Last-Modified não coincidem exatamente, o cache do lado do cliente deve proibir a combinação do conteúdo retornado na 206 resposta com qualquer conteúdo armazenado em cache anteriormente. Qualquer cache que não suporte Range e os cabeçalhos-O cabeçalho Range é proibido de armazenar em cache o conteúdo retornado pelo 206 resposta. |
| 207 | Um código de status estendido pelo WebDAV (RFC 2518) representa que o corpo da mensagem subsequente será uma mensagem XML, e pode conter uma série de códigos de resposta independentes dependendo do número de sub-do navegador. |
| 300 | O recurso solicitado tem uma faixa de opções de feedback, cada uma com seu próprio endereço específico e solicitações de navegador-informações. O usuário ou navegador pode escolher um endereço preferido para redirecionamento. A menos que seja uma solicitação HEAD, a resposta deve incluir uma entidade com uma lista de atributos do recurso e endereços dos quais o usuário ou navegador pode escolher o endereço de redirecionamento mais apropriado. O formato desta entidade é determinado pelo formato definido pelo Content-Tipo. O navegador pode fazer a escolha mais apropriada automaticamente com base no formato da resposta e nas próprias capacidades do navegador. Claro, a negociação guiada pelo RFC 2616 a especificação não especifica como essa seleção automática deve ser realizada. Se o servidor já tiver uma seleção de feedback preferida, o URI do feedback deve ser especificado no campo Location; os navegadores podem usar este valor de Location como o endereço para redirecionamento automático. Além disso, a menos que especificado de outra forma, a resposta também é cacheável. |
| 301 | O recurso solicitado foi movido permanentemente para um novo local, e qualquer referência futura a este recurso deve usar um dos vários URIs retornados por esta resposta. Se possível, o lado do cliente com capacidade de edição de links deve alterar automaticamente o endereço solicitado para o endereço retornado do servidor. A menos que especificado de outra forma, esta resposta também é cacheável. O novo URI permanente deve ser retornado no campo Location da resposta. A menos que seja uma solicitação HEAD, a entidade da resposta deve conter um hyperlink 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 as condições da solicitação podem mudar como resultado. Nota: Para alguns navegadores que usam o HTTP/1.0 protocolo, quando eles enviam uma solicitação POST e recebem uma 301 resposta, o solicitação de redirecionamento subsequente será GET. |
| 302 | O recurso solicitado está respondendo temporariamente à solicitação de um URI diferente. Since such redirects are temporary, the client side should continue to send future requests to the original address. This response is cacheable only if specified in Cache-Controle ou Expira. O novo URI temporário deve ser retornado no campo Location da resposta. A menos que seja uma solicitação HEAD, a entidade da resposta deve conter um hyperlink para o novo URI e uma breve descrição. Se não for uma solicitação GET ou HEAD, o navegador proíbe a redirecionamento automático a menos que seja confirmado pelo usuário, pois as condições da solicitação podem mudar como resultado. Nota: Embora o RFC 1945 e RFC 2068 especificações não permitem que o lado do cliente mude o método da solicitação ao redirecionar, muitos navegadores existentes tratam 302 resposta como uma 303 resposta e usar GET para acessar o URI especificado no campo Location, ignorando o método de solicitação original. Códigos de status 303 e 307 foram adicionados para esclarecer o que o servidor espera do lado do cliente. |
| 303 | a resposta para a solicitação atual pode ser encontrada em outro URI, e o lado do cliente deve ter acesso GET a esse recurso. Este método existe principalmente para permitir que scripts-ativou a saída da solicitação POST para ser redirecionada para um novo recurso. Este novo URI não é uma referência substituta para o recurso original. Além disso: 303 respostas são proibidas de serem armazenadas em cache. Claro, uma segunda solicitação (redirecionamento) pode ser armazenada em cache. O novo URI deve ser retornado no campo Location da resposta. A menos que seja uma solicitação HEAD, a entidade da resposta deve conter um hyperlink para o novo URI e uma breve descrição. Nota: muitos navegadores antes do HTTP/1.1 não compreendem 303 status corretamente. Se precisar considerar a interação com esses navegadores, o 302 o código de status deve ser suficiente, porque a maioria dos navegadores lida 302 respostas exatamente da maneira que a especificação acima requer que o lado do cliente lidar 303 respostas. |
| 304 | Se o lado do cliente enviar uma solicitação GET condicional e a solicitação tiver sido permitida, e o conteúdo do documento não tenha mudado (desde a última visita ou de acordo com as condições da solicitação), o servidor deve retornar este código de status. 304 respostas são proibidas de incluir corpos de mensagem, então sempre terminam com a primeira linha em branco após o cabeçalho. A resposta deve conter as seguintes informações de cabeçalho: Data, a menos que este servidor não tenha um relógio.
Se o servidor sem um relógio também seguir essas regras, então o servidor proxy e o lado do cliente podem adicionar o campo Data ao cabeçalho da resposta recebida por si mesmos (como especificado no RFC 2068), e o mecanismo de cache funcionará bem. ETag e/ou Content-Location, se a mesma solicitação devia retornar uma 2resposta 00. Expires, Cache-Controle, e/ou Vary, se seu valor pode ser diferente do valor correspondente a outras respostas para a mesma variável antes.
Se essa solicitação de resposta usar validação de cache forte, então essa resposta não deve incluir outros cabeçalhos de entidade; de outra forma (por exemplo, uma solicitação GET condicional usa validação de cache fraca), essa resposta é proibida de incluir outros cabeçalhos de entidade; isso evita inconsistências entre o conteúdo da entidade em cache e as informações de cabeçalho da entidade atualizadas. Se um 304 resposta indica que uma entidade não está atualmente em cache, o sistema de cache deve ignorar a resposta e enviar solicitações repetidas sem restrições.
Se um 304 resposta recebida para atualizar uma entrada em cache, o sistema de cache deve atualizar toda a entrada para refletir os valores de todos os campos que foram atualizados na resposta. |
| 305 | O recurso solicitado deve ser acessado através do proxy especificado. As informações do URI do proxy especificado são fornecidas no campo Location. O receptor precisa enviar repetidamente uma solicitação separada para acessar o recurso correspondente através deste proxy. Apenas o servidor de origem pode estabelecer um 305 resposta. Nota: Não há explicitamente 305 resposta no RFC 2068 para redirecionar uma única solicitação e só pode ser estabelecida pelo servidor de origem. Ignorar essas restrições pode levar a consequências de segurança graves. |
| 306 | Na versão mais recente da especificação, a 306 código de status já não é usado. |
| 307 | O recurso solicitado está respondendo temporariamente à solicitação de um URI diferente. Como esses redirecionamentos são temporários, o lado do cliente deve continuar a enviar futuras solicitações para o endereço original. Esta resposta só é cacheável se especificado em Cache-Controle ou Expira. O novo URI temporário deve ser retornado no campo Location da resposta. A menos que seja uma solicitação HEAD, a entidade respondente deve conter um hyperlink apontando para o novo URI e uma breve descrição. Como alguns navegadores não reconhecem o 307 resposta, a informação acima precisa ser adicionada para que o usuário possa entender e solicitar acesso ao novo URI.
Se esta não for uma solicitação GET ou HEAD, o navegador proíbe a redirecionamento automático a menos que seja confirmado pelo usuário, pois as condições da solicitação podem mudar como resultado. |
| 400 | 1. A semântica está errada e a solicitação atual não pode ser compreendida pelo servidor. A menos que seja modificada, o lado cliente não deve submeter a solicitação repetidamente. 2. Os parâmetros da solicitação estão errados. |
| 401 | solicitação atual requer autenticação do usuário. A resposta deve conter um WWW-cabeçalho de autenticação para o recurso solicitado para pedir informações ao usuário. O lado cliente pode reenviar uma solicitação com informações apropriadas no cabeçalho de Autorização. Se a solicitação atual já contiver certificados de Autorização, então a 401 resposta representa que o servidor rejeitou esses certificados. Se o 401 resposta contém a mesma consulta de autenticação da resposta anterior e o navegador tentou autenticação pelo menos uma vez, então o navegador deve mostrar ao usuário as informações contidas na entidade da resposta, pois essas informações podem conter informações de diagnóstico relevantes. Veja RFC 2617. |
| 402 | Este código de status é reservado para possíveis futuras necessidades. |
| 403 | O servidor compreendeu a solicitação, mas recusou a execução. Diferente de um 401 resposta, a autenticação não ajuda e a solicitação não deve ser repetida. Se este não for um pedido HEAD e o servidor desejar ser capaz de explicar por que a solicitação não pode ser executada, então a razão pela qual a solicitação foi rejeitada deve ser descrita dentro da entidade. Claro, o servidor também pode retornar um 404 resposta se não deseja que o lado cliente obtenha alguma informação. |
| 404 | A solicitação falhou e o recurso desejado não foi encontrado no servidor. Não há informações para informar ao usuário se a condição é temporária ou permanente. Se o servidor estiver ciente da situação, a 410 O código de status deve ser usado para informar o recurso antigo de que ele não está mais disponível permanentemente devido a algum mecanismo de configuração interna e não há endereço para qual saltar. The 404 O código de status é amplamente usado quando o servidor não deseja revelar por que a solicitação foi rejeitada ou não há outra resposta adequada disponível. |
| 405 | O método de solicitação especificado na linha da solicitação não pode ser usado para solicitar o recurso correspondente. A resposta deve retornar um cabeçalho Allow indicando uma lista de métodos de solicitação que podem ser aceitos pelo recurso atual. Como os métodos PUT e DELETE escrevem em recursos do servidor, a maioria dos servidores web não suporta ou não permite o método de solicitação acima por padrão e retornará um 405 erro para essas solicitações. |
| 406 | As características do conteúdo do recurso solicitado não atendem às condições no cabeçalho da solicitação, portanto, não pode ser gerada uma entidade de resposta. A menos que seja uma solicitação HEAD, a resposta deve retornar uma entidade que permita ao usuário ou navegador escolher as características mais apropriadas da entidade e a lista de endereços. O formato da entidade é determinado pelo tipo de mídia definido no Content-Cabeçalho de tipo. O navegador pode fazer a melhor escolha com base no formato e nas próprias capacidades. No entanto, a especificação não define quaisquer critérios para fazer tais seleções automáticas. |
| 407 | Semelhante ao 401 resposta, exceto que o lado do cliente deve se autenticar no servidor proxy. O servidor proxy deve retornar um Proxy-Autenticação para autenticação. O lado do cliente pode retornar um Proxy-Cabeçalho de autorização para autenticação. Veja RFC 2617. |
| 408 | A solicitação expirou. O lado do cliente não completou o envio da solicitação dentro do tempo que o servidor estava pronto para esperar. O lado do cliente pode reenviar a solicitação a qualquer momento sem quaisquer alterações. |
| 409 | A solicitação não pode ser completada devido a um conflito com o estado atual do recurso solicitado. Este código só pode ser usado se se presumir que o usuário possa 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 uma versão-ambiente verificado, se a informação de versão anexada a um PUT-solicitação de modificação enviada para um recurso específico conflita com uma anterior (terceira-partes) solicitação, o servidor deve retornar um 409 erro informando ao usuário que a solicitação não pôde ser completada.
Neste ponto, a entidade de resposta provavelmente contém uma comparação das diferenças entre as duas versões conflitantes, para que o usuário possa submeter novamente a versão combinada. |
| 410 | O recurso solicitado não está mais disponível no servidor e não possui nenhum endereço de encaminhamento conhecido. Essa condição deve ser considerada permanente. Se possível, o lado do cliente com capacidade de edição de links deve 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 essa condição é permanente, então um 404 código de status deve ser usado. A menos que especificado de outra forma, essa resposta é cacheável. O propósito do 410 a resposta é principalmente para ajudar o webmaster a manter o site, informar o usuário de que o recurso não está mais disponível e que o proprietário do servidor deseja que todas as conexões remotas a esse recurso sejam deletadas.
Esse tipo de evento é comum no tempo-limitado, valor-serviços adicionados. Similarmente, o 410 a resposta é usada para informar o lado do cliente de que recursos originalmente pertencentes a um indivíduo não estão mais disponíveis no site do servidor atual. Claro, depende entirely do proprietário do servidor se marcar todos os recursos permanentemente indisponíveis como' 410 Faltando ', e por quanto tempo manter essa marca. |
| 411 | O servidor recusa a aceitar a solicitação sem definir um conteúdo-Cabeçalho de comprimento. Após adicionar um conteúdo válido-Cabeçalho de comprimento indicando o comprimento do corpo da solicitação, o lado do cliente pode submeter a solicitação novamente. |
| 412 | O servidor falhou em atender a uma ou mais das pré-requisitos ao verificar se foram fornecidas no campo do cabeçalho da solicitação. Este código de status permite que o lado do cliente defina pré-requisitos nos metadados solicitados (dados do campo do cabeçalho da solicitação) ao buscar recursos, assim prevenindo que o método de solicitação seja aplicado a recursos além do que ele deseja. |
| 413 | O servidor recusa-se a processar a solicitação atual porque a solicitação envia mais dados de entidade do que o servidor está disposto ou capaz de lidar. Neste caso, o servidor pode fechar a conexão para evitar que o lado do cliente continue a enviar a solicitação. Se essa situação for temporária, o servidor deve retornar um Retry-Após o cabeçalho de resposta para informar o lado do cliente quanto tempo ele pode tentar novamente. |
| 414 | O URI solicitado é mais longo do que o servidor pode interpretar, então o servidor recusa-se a atender a solicitação. Isso é raro e os casos comuns incluem: Uma submissão de formulário que deve ter usado o método POST se torna um método GET, causando a string de consulta (Query String) a ser muito longa. URI de redirecionamento "buracos negros", como cada redirecionamento usando o URI antigo como parte do novo URI, resultando no URI ser muito longo após vários redirecionamentos. O cliente está tentando atacar o servidor com bugs de segurança que existem em alguns servidores.
Este tipo de servidor usa um-buffer de comprimento para ler ou manipular o URI solicitado. Quando os parâmetros após GET excedem um certo valor, pode ocorrer um buffer overflow, resultando na execução de código arbitrário [1]. Servidores sem tais vulnerabilidades devem retornar um 414 código de status. |
| 415 | Para o método da solicitação atual e o recurso solicitado, o entidade enviada na solicitação não está no formato suportado pelo servidor, então a solicitação é rejeitada. |
| 416 | Se a solicitação contiver um cabeçalho de intervalo e nenhum dos intervalos de dados especificados no intervalo coincidir com o intervalo disponível do recurso atual, e o If-O cabeçalho de intervalo não está definido na solicitação, o servidor deve retornar um 416 código de status. Se o Range usar um intervalo de bytes, isso significa que a posição do primeiro byte de todos os intervalos de dados especificados pela solicitação excede o comprimento do recurso atual. O servidor也应包括 um Content-cabeçalho de entidade de intervalo juntamente com o 416 código de status para indicar o comprimento do recurso atual. Esta resposta também é proibida de usar multipart/byteranges como seu Conteúdo-Tipo. |
| 417 | O conteúdo esperado especificado no cabeçalho de solicitação Expect não pode ser satisfeito pelo servidor, ou o servidor é um servidor proxy que tem evidências claras de que o conteúdo esperado não pode ser satisfeito no próximo nó do caminho atual. |
| 421 | O número de conexões ao servidor a partir do endereço de Protocolo de Internet onde o lado cliente está localizado excede o máximo permitido pelo servidor. Tipicamente, o endereço de Protocolo de Internet aqui se refere ao endereço do lado cliente visto pelo servidor (como o endereço de gateway ou proxy do usuário). Neste caso, o contagem de conexões pode envolver mais de um usuário final. |
| 422 | O número de conexões ao servidor a partir do endereço de Protocolo de Internet onde o lado cliente está localizado excede o máximo permitido pelo servidor. Tipicamente, o endereço de Protocolo de Internet aqui se refere ao endereço do lado cliente visto pelo servidor (como o endereço de gateway ou proxy do usuário). Neste caso, o contagem de conexões pode envolver mais de um usuário final. |
| 422 | A solicitação foi formatada corretamente, mas não pôde ser respondida devido a um erro semântico. (RFC 4918 WebDAV) 423 Bloqueado O recurso atual está bloqueado. (RFC 4918 WebDAV) |
| 424 | A solicitação atual falhou devido a um erro em uma solicitação anterior, como PROPPATCH. (RFC 4918 WebDAV) |
| 425 | Definido no rascunho de Coleções Avançadas do WebDav, mas não no Protocolo Sequencial do WebDAV (RFC 3658). |
| 426 | O lado cliente deve mudar para TLS/1.0. (RFC 2817) |
| 449 | Estendido pela Microsoft, as solicitações devem ser refeitas após a realização da ação apropriada. |
| 500 | O servidor encontrou uma situação inesperada que impedeu-o de completar a solicitação. Geralmente, esse problema ocorre quando o código do servidor falha. |
| 501 | O servidor não suporta um recurso requerido pela solicitação atual. Quando o servidor não pode reconhecer o método solicitado e não pode suportar sua solicitação para qualquer recurso. |
| 502 | Quando um servidor funcionando como gateway ou proxy tenta executar uma solicitação, ele recebe uma resposta inválida de um servidor upstream. |
| 503 | O servidor atualmente não pode processar solicitações devido a manutenção temporária do servidor ou sobrecarga. Esta condição é temporária e será restaurada após algum tempo. Se o tempo de atraso puder ser previsto, a resposta pode incluir um Retry-cabeçalho para indicar o tempo de atraso. Se este Retry-Após a informação não ser fornecida, o lado do cliente deve tratá-la como se fosse um 5resposta 00. Nota: A existência de um 503 código de status não significa que o servidor deve usá-lo no caso de sobrecarga. Alguns servidores simplesmente desejam negar a conexão do cliente. |
| 504 | Quando um servidor funcionando como gateway ou proxy tenta executar uma solicitação, ele falha em receber uma resposta de um servidor upstream (identificado pelo URI, como HTTP, FTP, LDAP) ou um servidor secundário (como DNS) de maneira rápida e eficiente. Nota: Alguns servidores proxy retornam um 400 ou 5Erro 00 quando a consulta DNS expira |
| 505 | O servidor não suporta ou recusa suportar a versão do HTTP usada na solicitação. Isso implica que o servidor não pode ou não usará a mesma versão que o lado do cliente. A resposta deve incluir uma entidade que descreva por que a versão não é suportada e quais protocolos o servidor suporta. |
| 506 | Extendido pelo Protocolo de Negociação de Conteúdo Transparente (RFC 2295), isso representa um erro de configuração interna no servidor: a variável de negociação de recursos solicitada está configurada para usar a si mesma em uma negociação de conteúdo transparente e, portanto, não é um foco apropriado em um processo de negociação. |
| 507 | O servidor não pode armazenar o conteúdo necessário para completar a solicitação. Esta condição é considerada temporária. WebDAV (RFC 4918) |
| 509 | O servidor atingiu o limite de largura de banda. Este não é um código de status oficial, mas ainda é amplamente utilizado. |
| 510 | As políticas necessárias para adquirir recursos não são atendidas. (RFC 2774) |
