Ferramentas Online
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)
Acesso aos registos: