Ponta: Ctrl F pesquisa rápida| Código de status Http | Significado do código de status |
|---|---|
| 100 | O cliente deve continuar a enviar a solicitação. Essa resposta temporária é usada para informar ao cliente que parte de sua solicitação foi recebida pelo servidor e ainda não foi rejeitada. O cliente deve continuar a enviar o restante da solicitação ou ignorar essa resposta se a solicitação tiver sido concluída. O servidor deve enviar uma resposta final ao cliente após a conclusão da solicitação. |
| 101 | O servidor entendeu a solicitação do cliente e notificará o cliente por meio do cabeçalho da mensagem Upgrade para usar um protocolo diferente para concluir essa solicitação. Depois de enviar a última linha vazia dessa resposta, o servidor mudará para os protocolos definidos no cabeçalho da mensagem Upgrade. Uma medida semelhante só deve ser tomada se for mais vantajoso mudar para um novo protocolo. Por exemplo, mudar para uma nova versão HTTP tem uma vantagem sobre a versão antiga ou mudar para um protocolo sincronizado e em tempo real para transmitir recursos que aproveitam esses recursos. |
| 102 | O código de estado que é estendido por WebDAV(RFC 2518), significa que o processamento será continuado. |
| 200 | A solicitação foi bem sucedida e o cabeçalho de resposta ou corpo de dados desejado pela solicitação retornará com esta resposta. |
| 201 | A solicitação foi realizada e um novo recurso foi estabelecido de acordo com as necessidades da solicitação, e seu URI foi retornado com as informações do cabeçalho de localização. Se os recursos necessários não puderem ser estabelecidos a tempo, o '202 Accepted' deve ser devolvido. |
| 202 | O servidor aceitou o pedido, mas ainda não foi processado. Assim como pode ser negado, eventualmente o pedido pode ou não ser executado. No caso de operação assíncrona, não há prática mais conveniente do que enviar este código de status. O objetivo da resposta que retorna o código de estado 202 é permitir que o servidor aceite solicitações de outros processos (como uma operação baseada em lote que é executada apenas uma vez por dia), sem ter que manter o cliente conectado ao servidor até que a operação em lote seja concluída. Uma resposta que aceita o processamento de solicitação e retorna o código de estado 202 deve incluir alguma informação na entidade retornada indicando o estado atual do processamento, bem como um ponteiro para o monitor de estado de processamento ou previsão de estado para que o usuário possa estimar se a operação foi concluída. |
| 203 | O servidor processou a solicitação com sucesso, mas a metainformação do cabeçalho de entidade retornada não é uma coleção de determinação válida no servidor original, mas uma cópia de um terceiro local ou local. A informação atual pode ser um subconjunto ou um superconjunto da versão original. Por exemplo, a inclusão de metadados de um recurso pode fazer com que o servidor original conheça o super metainformação. O uso deste código de estado não é necessário e é adequado apenas se a resposta retornar 200 OK sem usar este código de estado. |
| 204 | O servidor processa a solicitação com sucesso, mas não precisa retornar nenhum conteúdo da entidade e deseja retornar a metainformação atualizada. A resposta pode ser na forma de um cabeçalho de entidade, retornando uma metainformação nova ou atualizada. Se esta informação de cabeça estiver presente, ela deverá ser ecoada com a variável solicitada. Se o cliente for um navegador, o navegador do usuário deve manter a página que enviou a solicitação sem gerar alterações na visualização do documento, mesmo que a meta-informação nova ou atualizada de acordo com a especificação seja aplicada à visualização da atividade do navegador do usuário. Como a resposta 204 é proibida de conter qualquer corpo de mensagem, ela sempre termina com a primeira linha vazia atrás do cabeçalho da mensagem. |
| 205 | O servidor processou a solicitação com sucesso e não retornou nada. Mas, diferentemente da resposta 204, a resposta que retorna esse código de estado requer que o solicitante redefina a visualização do documento. A resposta é usada principalmente para redefinir o formulário imediatamente após aceitar a entrada do usuário, para que o usuário possa iniciar facilmente outra entrada. Tal como acontece com a resposta 204, a resposta também é proibida de conter qualquer corpo de mensagem e termina com a primeira linha vazia após o cabeçalho de mensagem. |
| 206 | O servidor já processou com sucesso algumas solicitações GET. Ferramentas de download via HTTP, como o FlashGet ou o Xunlei, utilizam esse tipo de resposta para implementar a recuperação de downloads interrompidos ou para dividir um arquivo grande em várias partes, baixando-as simultaneamente. A requisição deve incluir o cabeçalho Range para indicar o intervalo de conteúdo desejado pelo cliente e pode também incluir o cabeçalho If-Range como condição da requisição. A resposta deve incluir os seguintes campos de cabeçalho: Content-Range, para indicar o intervalo de conteúdo retornado nesta resposta; se o campo Content-Type for multipart/byteranges, indicando um download em múltiplos segmentos, cada segmento multipart deve conter também o campo Content-Range, especificando o intervalo de conteúdo desse segmento. Se a resposta contiver o cabeçalho Content-Length, o seu valor deve corresponder ao número real de bytes do intervalo de conteúdo retornado. Data ETag e/ou Content-Location, caso a mesma solicitação devesse retornar uma resposta 200. Expires, Cache-Control e/ou Vary, caso os seus valores possam ser diferentes dos valores correspondentes em outras respostas para a mesma variável.Se a solicitação correspondente tiver utilizado a verificação de cache forte If-Range, então esta resposta não deverá incluir outros campos de cabeçalho de entidade; se a solicitação tiver utilizado a verificação de cache fraca If-Range, então é proibido que esta resposta contenha outros campos de cabeçalho de entidade; isso evita a inconsistência entre o conteúdo da entidade armazenada em cache e as informações atualizadas dos campos de cabeçalho da entidade. Caso contrário, esta resposta deve incluir todos os campos de cabeçalho de entidade que deveriam estar presentes em uma resposta com código 200. Se as cabeçalhas ETag ou Last-Modified não corresponderem com precisão, o cache do cliente deve impedir que o conteúdo retornado pela resposta 206 seja combinado com qualquer conteúdo previamente armazenado em cache. Qualquer cache que não suporte os cabeçalhos Range e Content-Range é obrigado a não armazenar em cache o conteúdo retornado por uma resposta 206. |
| 207 | O código de estado estendido pelo WebDAV(RFC 2518), que significa que o corpo da mensagem subsequente será uma mensagem XML, pode conter uma série de códigos de resposta independentes de acordo com o número de subsolicitações anteriores. |
| 300 | Os recursos solicitados têm uma variedade de informações de feedback para escolher, cada um com seu próprio endereço específico e informações negociadas pelo navegador. O usuário ou navegador pode selecionar um endereço preferido para redirecionar. A menos que seja uma solicitação HEAD, a resposta deve incluir uma entidade com uma lista de recursos e endereços para que o usuário ou navegador possa selecionar o endereço de redirecionamento mais adequado. O formato dessa entidade é determinado pelo formato definido pelo Content-Type. O navegador pode fazer automaticamente a escolha mais adequada com base no formato da resposta e na capacidade do próprio navegador. Obviamente, a especificação RFC 2616 não especifica como essa seleção automática deve ser feita. Se o próprio servidor já tiver a opção de feedback preferida, o URI desse feedback deve ser indicado em Location; o navegador pode usar esse valor de Location como o endereço para redirecionamento automático. Além disso, a menos que especificado adicionalmente, essa resposta também é armazenável em cache. |
| 301 | O recurso solicitado foi permanentemente movido para um novo local, e qualquer referência a esse recurso no futuro deve usar um dos vários URIs retornados por esta resposta. Se possível, o cliente com a função de edição de link deve modificar automaticamente o endereço solicitado para o endereço retornado do servidor. A menos que especificado adicionalmente, essa resposta também é armazenável em cache. O novo URI permanente deve retornar no domínio da localização da resposta. A menos que seja uma solicitação HEAD, a entidade respondida deve conter um hiperlink e uma breve descrição para o novo URI. Se esta não for uma solicitação GET ou HEAD, o navegador proíbe o redirecionamento automático, a menos que seja confirmado pelo usuário, pois as condições da solicitação podem mudar. Nota: Para alguns navegadores que usam o protocolo HTTP/1.0, quando a solicitação POST que eles enviam recebe uma resposta 301, a próxima solicitação de redirecionamento se tornará um método GET. |
| 302 | Os recursos solicitados agora respondem temporariamente a solicitações de um URI diferente. Como tal redirecionamento é temporário, o cliente deve continuar a enviar solicitações posteriores para o endereço original. Essa resposta só pode ser armazenada em cache se for especificada no Cache-Control ou Expires. O novo URI temporário deve retornar no domínio da localização da resposta. A menos que seja uma solicitação HEAD, a entidade respondida deve conter um hiperlink e uma breve descrição para o novo URI. Se esta não for uma solicitação GET ou HEAD, o navegador proíbe o redirecionamento automático, a menos que seja confirmado pelo usuário, pois as condições da solicitação podem mudar. Nota: Embora as especificações RFC 1945 e RFC 2068 não permitam que os clientes alterem o método de solicitação durante o redirecionamento, muitos navegadores existentes consideram a resposta 302 como a resposta 303 e usam o método GET para acessar o URI especificado na localização, ignorando o método de solicitação original. Os códigos de status 303 e 307 foram adicionados para esclarecer como o servidor espera que o cliente reaja. |
| 303 | A resposta correspondente à solicitação atual pode ser encontrada em outro URI, e o cliente deve usar o GET para acessar esse recurso. Este método existe principalmente para permitir que a saída de solicitação POST ativada pelo script seja redirecionada para um novo recurso. Este novo URI não é uma referência alternativa ao recurso original. Ao mesmo tempo, a proibição de resposta 303 é armazenada em cache. Naturalmente, a segunda solicitação (redirecionamento) pode ser armazenada em cache. O novo URI deve retornar no domínio Location da resposta. A menos que seja uma solicitação HEAD, a entidade respondida deve conter um hiperlink e uma breve descrição para o novo URI. Nota: Muitos navegadores anteriores da versão HTTP/1.1 não entendem o status 303 corretamente. Se você precisar considerar a interação com esses navegadores, o código de status 302 deve ser competente, porque a maneira como a maioria dos navegadores lida com a resposta 302 é exatamente o que as especificações acima exigem que o cliente faça ao lidar com a resposta 303. |
| 304 | Se o cliente enviou uma solicitação GET condicional e a solicitação foi permitida, e o conteúdo do documento (desde a última visita ou de acordo com as condições solicitadas) não mudou, o servidor deve retornar o código de status. A resposta 304 proíbe a inclusão de um corpo de mensagem e, portanto, sempre termina com a primeira linha vazia após o cabeçalho da mensagem. A resposta deve conter as seguintes informações de cabeçalho: Date, a menos que este servidor não tenha um relógio. Se um servidor sem relógio também cumprir essas regras, o servidor proxy e o cliente podem adicionar o campo Date ao cabeçalho de resposta recebido (conforme especificado no RFC 2068), e o mecanismo de cache funcionará normalmente. ETag e/ou Content-Location, se a mesma solicitação deve retornar 200 respostas. Expires,Cache-Control e/ou Vary, se seu valor pode ser diferente do valor correspondente a outras respostas da mesma variável antes.Se esta solicitação de resposta usa autenticação de cache forte, então esta resposta não deve conter outros cabeçudos de entidade; caso contrário (por exemplo, uma solicitação GET condicional usa validação de cache fraca), esta resposta proíbe outros cabeçudos de entidade; isso evita a inconsistência entre o conteúdo da entidade armazenado em cache e as informações do cabeçalho da entidade atualizadas. Se uma resposta 304 indica que uma entidade atual não tem cache, então o sistema de cache deve ignorar essa resposta e enviar repetidamente solicitações que não contêm restrições. Se uma resposta 304 que solicita a atualização de uma entrada de cache for recebida, o sistema de cache deve atualizar a entrada inteira para refletir os valores de todos os campos atualizados na resposta. |
| 305 | O recurso solicitado deve ser acessado por meio de um proxy especificado. O domínio Location fornecerá as informações de URI onde o agente especificado está localizado. O destinatário precisa enviar uma solicitação separada repetidamente para acessar o recurso correspondente por meio desse agente. Somente o servidor original pode estabelecer uma resposta 305. Nota: Não está claro no RFC 2068 que a resposta 305 é para redirecionar uma solicitação separada e só pode ser estabelecida pelo servidor original. Ignorar essas limitações pode levar a sérias conseqüências de segurança. |
| 306 | Na versão mais recente da especificação, o código de status 306 não é mais usado. |
| 307 | Os recursos solicitados agora respondem temporariamente a solicitações de um URI diferente. Como tal redirecionamento é temporário, o cliente deve continuar a enviar solicitações posteriores para o endereço original. Essa resposta só pode ser armazenada em cache se for especificada no Cache-Control ou Expires. O novo URI temporário deve retornar no domínio da localização da resposta. A menos que seja uma solicitação HEAD, a entidade respondida deve conter um hiperlink e uma breve descrição para o novo URI. Como parte do navegador não pode reconhecer a resposta 307, a informação necessária acima precisa ser adicionada para que o usuário possa entender e emitir uma solicitação de acesso ao novo URI. Se esta não for uma solicitação GET ou HEAD, o navegador proíbe o redirecionamento automático, a menos que seja confirmado pelo usuário, pois as condições da solicitação podem mudar. |
| 400 | 1. A semântica está errada e a solicitação atual não pode ser entendida pelo servidor. O cliente não deve enviar essa solicitação repetidamente, a menos que seja modificada. 2. Os parâmetros de solicitação estão incorretos. |
| 401 | A solicitação atual requer a validação do usuário. A resposta deve conter um cabeçalho de informação WWW-Authenticate aplicável ao recurso solicitado para solicitar informações do usuário. O cliente pode enviar repetidamente uma solicitação que contenha as informações apropriadas do cabeçalho da Authorization. Se a solicitação atual já inclui certificados de Autorização, a resposta 401 representa que a validação do servidor rejeitou esses certificados. Se a resposta 401 contém o mesmo inquérito de autenticação que a resposta anterior, e o navegador já tentou a validação pelo menos uma vez, o navegador deve mostrar ao usuário as informações de entidade incluídas na resposta, porque as informações de entidade podem conter informações de diagnóstico relevantes. Cf. RFC 2617. |
| 402 | O código de estado é reservado para possíveis necessidades futuras. |
| 403 | O servidor já entendeu o pedido, mas se recusou a executá-lo. Ao contrário da resposta 401, a autenticação não oferece nenhuma ajuda e essa solicitação não deve ser enviada repetidamente. Se esta não for uma solicitação HEAD e o servidor quiser deixar claro por que a solicitação não pode ser executada, o motivo da rejeição deve ser descrito dentro da entidade. Claro, o servidor também pode retornar uma resposta 404 se não quiser que o cliente obtenha qualquer informação. |
| 404 | A solicitação falha e os recursos desejados pela solicitação não são descobertos no servidor. Nenhuma informação pode dizer ao usuário se essa situação é temporária ou permanente. Se o servidor souber a situação, o código de estado 410 deve ser usado para informar que o recurso antigo não está disponível permanentemente devido a alguns problemas internos de mecanismo de configuração e não há endereço que possa ser pulado. 404 Este código de status é amplamente utilizado quando o servidor não deseja revelar exatamente por que a solicitação é rejeitada ou não há outra resposta adequada disponível. |
| 405 | O método de solicitação especificado na linha de solicitação não pode ser usado para solicitar o recurso correspondente. A resposta deve retornar uma informação de cabeçalho Allow para representar uma lista de métodos de solicitação que o recurso atual pode aceitar. Em vista do PUT, o método DELETE irá gravar os recursos no servidor, portanto, a maioria dos servidores web não oferece suporte ou não permite o método de solicitação acima na configuração padrão, e um erro 405 será retornado para essas solicitações. |
| 406 | As características de conteúdo do recurso solicitado não podem satisfazer as condições no cabeçalho da solicitação e, portanto, não podem gerar uma entidade de resposta. A menos que seja uma solicitação HEAD, a resposta deve retornar uma entidade que possa permitir que o usuário ou o navegador selecione os recursos de entidade mais adequados e a lista de endereços. O formato da entidade é determinado pelo tipo de mídia definido no cabeçalho Content-Type. O navegador pode fazer a melhor escolha de acordo com o formato e suas próprias habilidades. No entanto, não há nenhum critério definido na especificação para fazer essa seleção automática. |
| 407 | Semelhante à resposta 401, exceto que o cliente deve se autenticar em um servidor proxy. O servidor proxy deve retornar um Proxy-Authenticate para consulta de identidade. O cliente pode retornar um cabeçalho de informação Proxy-Authorization para verificação. Cf. RFC 2617. |
| 408 | Pedido de tempo limite. O cliente não concluiu o envio de uma solicitação dentro do tempo que o servidor está pronto para esperar. O cliente pode enviar esta solicitação novamente a qualquer momento sem nenhuma alteração. |
| 409 | A solicitação não pode ser concluída devido a um conflito com o estado atual do recurso solicitado. Esse código só pode ser usado em situações em que o usuário é considerado capaz de resolver o conflito e reenviar uma nova solicitação. A resposta deve conter informação suficiente para que o usuário descubra a fonte do conflito. Conflitos geralmente ocorrem no processamento de solicitações de PUT. Por exemplo, em um ambiente em que a verificação de versão é usada, as informações de versão anexadas a uma solicitação de modificação para um recurso específico enviada pelo PUT entram em conflito com uma solicitação anterior (de terceiros), então o servidor deve retornar um erro 409 neste momento, informando ao usuário que a solicitação não pode ser concluída. Nesse momento, é provável que a entidade de resposta inclua uma comparação de diferenças entre as duas versões conflitantes, para que os usuários possam reenviar uma nova versão posteriormente. |
| 410 | Os recursos solicitados não estão mais disponíveis no servidor e não há endereços de encaminhamento conhecidos. Tal situação deve ser considerada permanente. Se possível, o cliente com a função de edição de link deve remover todas as referências a esse endereço após obter a permissão do usuário. Se o servidor não sabe ou não pode determinar se esta situação é permanente, então o código de estado 404 deve ser usado. A menos que especificado adicionalmente, esta resposta é armazenável em cache. O objetivo da resposta 410 é principalmente ajudar o administrador do site a manter o site, informar ao usuário que o recurso não está mais disponível e que o proprietário do servidor deseja que todas as conexões remotas para esse recurso também sejam excluídas. Esses incidentes são comuns em serviços de valor agregado e por tempo limitado. Da mesma forma, a resposta 410 também é usada para informar o cliente de que os recursos que originalmente pertenciam a um indivíduo não estão mais disponíveis no site do servidor atual. Obviamente, se todos os recursos permanentemente indisponíveis precisam ser marcados como '410 Gone' e quanto tempo você precisa manter essa marca depende inteiramente do proprietário do servidor. |
| 411 | O servidor se recusou a aceitar o pedido sem definir o cabeçalho Content-Length. Depois de adicionar um cabeçalho Content-Length válido indicando o comprimento do corpo da mensagem de solicitação, o cliente pode enviar a solicitação novamente. |
| 412 | O servidor não satisfaz um ou mais dos pré-requisitos que são fornecidos no campo de cabeçalho da solicitação. Este código de estado permite que o cliente defina pré-condições nas metainformações solicitadas (dados de campo de cabeçalho de solicitação) ao obter o recurso, de modo a evitar que o método de solicitação seja aplicado a recursos que não sejam o conteúdo desejado. |
| 413 | O servidor se recusa a processar a solicitação atual porque a solicitação é submetida a um tamanho de dados de entidade maior do que o servidor está disposto ou capaz de processar. Nesse caso, o servidor pode fechar a conexão para que o cliente não continue enviando essa solicitação. Se essa situação for temporária, o servidor deve retornar um cabeçalho de resposta do Retry-After para informar ao cliente quanto tempo ele pode tentar novamente. |
| 414 | O comprimento do URI solicitado excede o comprimento que o servidor é capaz de interpretar, de modo que o servidor se recusa a fornecer serviço à solicitação. Isso é relativamente raro. Os casos comuns incluem: O envio de formulário que deveria usar o método POST se torna o método GET, resultando em uma string de consulta muito longa. Redireciona o "buraco negro" do URI. Por exemplo, o URI antigo é usado como parte do novo URI a cada redirecionamento, resultando em um URI muito longo após vários redirecionamentos. Os clientes estão tentando atacar os servidores com uma vulnerabilidade de segurança existente em alguns servidores. Este tipo de servidor usa um buffer de comprimento fixo para ler ou operar o URI solicitado. Quando o parâmetro após GET excede um determinado valor, um estouro de buffer pode ser gerado, resultando na execução de código arbitrário [1]. Um servidor sem tais vulnerabilidades deve retornar um código de status 414. |
| 415 | Para o método atual solicitado e os recursos solicitados, a entidade enviada na solicitação não é um formato suportado no servidor e, portanto, a solicitação é rejeitada. |
| 416 | Se o cabeçalho de solicitação Range estiver incluído na solicitação e qualquer intervalo de dados especificado no Range não coincidir com o escopo disponível do recurso atual, e o cabeçalho de solicitação If-Range não estiver definido na solicitação, o servidor deve retornar o código de status 416. Se o Range estiver usando um intervalo de bytes, esse caso 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 também deve incluir um cabeçalho de entidade Content-Range ao retornar o código de estado 416 para indicar o comprimento do recurso atual. Esta resposta também foi proibida de usar multipart/byteranges como seu Content-Type. |
| 417 | O conteúdo esperado especificado no cabeçalho de solicitação Expect não pode ser satisfeito pelo servidor, ou o servidor é um servidor proxy, que tem evidências óbvias de que o conteúdo do Expect não pode ser satisfeito no próximo nó do roteamento atual. |
| 421 | O número de conexões do endereço IP do cliente atual para o servidor excede o intervalo máximo de licenças do servidor. Tipicamente, o endereço IP aqui se refere ao endereço de cliente visto do servidor (por exemplo, o gateway do usuário ou o endereço do servidor proxy). Neste caso, o cálculo do número de conexões pode envolver mais de um usuário final. |
| 422 | O número de conexões do endereço IP do cliente atual para o servidor excede o intervalo máximo de licenças do servidor. Tipicamente, o endereço IP aqui se refere ao endereço de cliente visto do servidor (por exemplo, o gateway do usuário ou o endereço do servidor proxy). Neste caso, o cálculo do número de conexões pode envolver mais de um usuário final. |
| 422 | A solicitação está formatada corretamente, mas não pode responder devido a um erro semântico. (RFC 4918 WebDAV)423 Locked O recurso atual está bloqueado. (RFC 4918 WebDAV) |
| 424 | Devido a um erro ocorrido em uma solicitação anterior, a solicitação atual falhou, por exemplo, PROPPATCH. (RFC 4918 WebDAV) |
| 425 | É definido no rascunho do WebDav Advanced Collections, mas não aparece no Protocolo de Conjunto Sequencial WebDAV (RFC 3658). |
| 426 | O cliente deve mudar para TLS/1.0. (RFC 2817) |
| 449 | Expandido pela Microsoft, o pedido do representante deve ser tentado novamente após a execução das operações apropriadas. |
| 500 | O servidor encontrou uma situação inesperada que o levou a não conseguir concluir o processamento da solicitação. Geralmente, esse problema ocorre quando o código do servidor está errado. |
| 501 | O servidor não oferece suporte a um recurso necessário para a solicitação atual. Quando o servidor não consegue identificar o método de solicitação e não pode suportar sua solicitação para qualquer recurso. |
| 502 | Quando um servidor que trabalha como um gateway ou proxy tenta executar uma solicitação, uma resposta inválida é recebida do servidor upstream. |
| 503 | O servidor atualmente não pode processar a solicitação devido à manutenção temporária ou sobrecarga do servidor. Esta condição é temporária e será restaurada após algum tempo. Se o tempo de atraso puder ser estimado, um cabeçalho Retry-After pode ser incluído na resposta para indicar esse tempo de atraso. Se esta informação de Retry-After não for fornecida, o cliente deve processá-la de uma forma que processe as respostas 500. Nota: A presença do código de estado 503 não significa que o servidor deve usá-lo quando estiver sobrecarregado. Alguns servidores nada mais são do que uma conexão que deseja rejeitar o cliente. |
| 504 | Quando um servidor que trabalha como um gateway ou proxy tenta executar uma solicitação, ele não recebe uma resposta do servidor upstream (o servidor identificado pelo URI, como HTTP, FTP, LDAP) ou do servidor secundário (como DNS) a tempo. Observação: alguns servidores proxy retornam erros 400 ou 500 no tempo limite da consulta DNS |
| 505 | O servidor não suporta ou se recusa a oferecer suporte à versão HTTP usada na solicitação. Isso implica que o servidor não pode ou não deseja usar a mesma versão que o cliente. A resposta deve incluir uma entidade que descreve por que a versão não é suportada e quais protocolos o servidor suporta. |
| 506 | Expandido pelo "Acordo de Negociação de Conteúdo Transparente" (RFC 2295), significa que o servidor tem um erro de configuração interna: o recurso variável de negociação solicitado é configurado para usar a si mesmo na negociação de conteúdo transparente, portanto, não é um foco adequado em um processamento de negociação. |
| 507 | O servidor não pode armazenar o conteúdo necessário para concluir a solicitação. Esta situação é considerada temporária. WebDAV(RFC 4918) |
| 509 | O servidor atinge o limite de largura de banda. Este não é um código de status oficial, mas ainda é amplamente utilizado. |
| 510 | As estratégias necessárias para obter recursos não são atendidas. (RFC 2774) |
Link amigável:iCMS