| Código de status HTTP | Código de status Significado |
|---|
| 100 | O cliente deve continuar a enviar solicitações. Essa resposta temporária é usada para informar ao cliente que parte de sua solicitação foi recebida pelo servidor e não foi rejeitada. O cliente deve continuar a enviar o restante da solicitação ou ignorar essa resposta se a solicitação estiver concluída. O servidor deve enviar uma resposta final ao cliente quando a solicitação for concluída. |
| 101 | O servidor entendeu a solicitação do cliente e o notificará por meio do cabeçalho da mensagem Upgrade para que use um protocolo diferente para concluir a solicitação. Depois de enviar a última linha em branco dessa resposta, o servidor mudará para os protocolos definidos no cabeçalho da mensagem Upgrade. Isso só deve ser feito se for mais vantajoso mudar para um novo protocolo. Por exemplo, mudar para uma nova versão do HTTP é mais vantajoso do que uma versão mais antiga, ou mudar para um protocolo em tempo real e síncrono para fornecer recursos que aproveitem esses recursos. |
| 102 | Os códigos de status, ampliados pelo WebDAV (RFC 2518), representam que o processamento continuará. |
| 200 | A solicitação foi bem-sucedida e o cabeçalho da resposta ou o corpo de dados desejado pela solicitação será retornado com essa resposta. |
| 201 | A solicitação foi atendida e um novo recurso foi criado conforme exigido pela solicitação e seu URI foi retornado com o cabeçalho Location. Se o recurso necessário não puder ser criado a tempo, a mensagem "202 Accepted" deverá ser retornada. |
| 202 | O servidor aceitou a solicitação, mas ainda não a processou. Assim como pode ser rejeitada, eventualmente a solicitação pode ou não ser executada. No contexto de operações assíncronas, não há nada mais conveniente do que enviar esse código de status. O objetivo de retornar uma resposta com um código de status 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 precisar manter o cliente conectado ao servidor até que a operação em lote seja totalmente concluída. Uma resposta que aceite uma solicitação de processamento e retorne um código de status 202 DEVERIA incluir na entidade retornada algumas informações que indiquem o estado atual do processo, bem como um ponteiro para um monitor de status de processamento ou previsão de status para que o usuário possa estimar se a operação foi concluída. |
| 203 | O servidor processou a solicitação com êxito, mas as meta-informações do cabeçalho da entidade retornada não são um conjunto definitivo válido no servidor original, mas uma cópia de um local ou de terceiros. As informações atuais podem ser um subconjunto ou um superconjunto da versão original. Por exemplo, os metadados que contêm recursos podem fazer com que o servidor original conheça a superinformação de meta-informação. O uso desse código de status não é obrigatório e só é apropriado se a resposta tivesse retornado 200 OK sem ele. |
| 204 | O servidor processou a solicitação com êxito, mas não precisa retornar nenhum conteúdo físico e deseja retornar meta-informações atualizadas. A resposta pode retornar meta-informações novas ou atualizadas na forma de cabeçalhos de entidade. Se esses cabeçalhos existirem, eles deverão corresponder às variáveis solicitadas. Se o cliente for um navegador, o navegador do usuário DEVERÁ manter a página na qual a solicitação foi enviada sem nenhuma alteração na exibição do documento, embora, de acordo com a especificação, as metainformações novas ou atualizadas DEVEM ser aplicadas ao documento na exibição ativa do navegador do usuário. Como a resposta 204 é proibida de conter qualquer corpo de mensagem, ela sempre termina com a primeira linha em branco após o cabeçalho da mensagem. |
| 205 | O servidor processou a solicitação com êxito e não retornou nada. No entanto, ao contrário da resposta 204, a resposta que retorna esse código de status pede que o solicitante redefina a exibição do documento. Essa resposta é usada principalmente para redefinir o formulário imediatamente após aceitar a entrada do usuário, para que ele possa iniciar facilmente outra entrada. Como a resposta 204, essa resposta é proibida de 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 da solicitação GET. As ferramentas de download HTTP, como o FlashGet ou o Thunderbolt, usam esse tipo de resposta para realizar downloads intermitentes ou para dividir um documento grande em vários segmentos de download ao mesmo tempo. A solicitação deve conter um cabeçalho Range para indicar o intervalo de conteúdo que o cliente deseja receber e pode conter um If-Range como condição de solicitação. A resposta deve conter os seguintes campos de cabeçalho: Content-Range para indicar o escopo do conteúdo retornado nessa resposta; no caso de um download de vários segmentos com um Content-Type de multipart/byteranges, cada segmento de várias partes deve conter um campo Content-Range indicando o escopo do conteúdo nesse segmento. Se a resposta contiver um Content-Length, seu valor deverá corresponder ao número real de bytes no intervalo de conteúdo retornado. date ETag e/ou Content-Location, se a mesma solicitação deveria ter retornado uma resposta 200. Expires, Cache-Control e/ou Vary, se seus valores puderem ser diferentes de outras respostas com as mesmas variáveis. Expires, Cache-Control e/ou Vary, se seus valores puderem ser diferentes dos valores de outras respostas anteriores para as mesmas variáveis. Essa resposta NÃO DEVERÁ conter outros cabeçalhos de entidade se a solicitação usar a validação de cache forte If-Range e NÃO DEVERÁ conter outros cabeçalhos de entidade se a solicitação usar a validação de cache fraca If-Range; isso evita inconsistências entre o conteúdo da entidade em cache e as informações atualizadas do cabeçalho da entidade. Caso contrário, essa resposta DEVERÁ conter todos os campos de cabeçalho de entidade que deveriam ter sido retornados em todas as respostas 200 que deveriam ter sido retornadas. Se os cabeçalhos ETag ou Last-Modified não corresponderem exatamente, o cache do lado do cliente DEVERÁ proibir a combinação do conteúdo retornado na resposta 206 com qualquer conteúdo previamente armazenado em cache. Qualquer cache que não seja compatível com os cabeçalhos Range e Content-Range está proibido de armazenar em cache o conteúdo retornado pela resposta 206. |
| 207 | O código de status, conforme estendido pelo WebDAV (RFC 2518), significa que o corpo da mensagem subsequente será uma mensagem XML e poderá conter uma série de códigos de resposta separados, dependendo do número de solicitações anteriores. |
| 300 | O recurso solicitado tem uma série de mensagens de retorno alternativas, cada uma com seu próprio endereço específico e informações de negociação orientadas pelo navegador. O usuário ou o navegador pode selecionar um endereço preferencial para redirecionamento por conta própria. A menos que se trate de uma solicitação HEAD, a resposta deve incluir uma entidade que seja uma lista de características e endereços de recursos a partir da qual o usuário ou o navegador possa selecionar o endereço de redirecionamento mais adequado. O formato dessa 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 nos recursos do próprio navegador. Obviamente, a especificação RFC 2616 não especifica como essa escolha automática deve ser feita. Se o próprio servidor já tiver uma opção preferencial de retorno, o URI desse retorno deverá ser especificado em Location; o navegador poderá usar esse valor de Location como o endereço para redirecionamento automático. Além disso, essa resposta também pode ser armazenada em cache, a menos que seja especificado de outra forma. |
| 301 | O recurso solicitado foi movido permanentemente para o novo local, e todas as referências futuras a ele devem usar um dos vários URIs retornados nessa resposta. Se possível, os clientes com recursos de edição de links devem alterar automaticamente o endereço solicitado para o endereço retornado pelo servidor. Essa resposta também pode ser armazenada em cache, a menos que seja especificado de outra forma. O novo URI permanente deve ser retornado no campo Location da resposta. A menos que essa seja uma solicitação HEAD, a entidade de resposta deve conter um hiperlink para o novo URI e uma breve descrição. Se essa não for uma solicitação GET ou HEAD, o navegador estará proibido de redirecionar automaticamente, a menos que seja confirmado pelo usuário, pois os termos da solicitação podem mudar como resultado. Observação: Para alguns navegadores que usam o protocolo HTTP/1.0, quando eles enviam uma solicitação POST e recebem uma resposta 301, a próxima solicitação de redirecionamento será um GET. |
| 302 | O recurso solicitado agora responde temporariamente à solicitação de um URI diferente. Como esse redirecionamento é temporário, o cliente deve continuar a enviar solicitações futuras para o endereço original. Essa resposta só pode ser armazenada em cache se for especificada em Cache-Control ou Expires. O novo URI temporário deve ser retornado no campo Location da resposta. A menos que essa seja uma solicitação HEAD, a entidade de resposta deve conter um hiperlink 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 os termos da solicitação podem mudar como resultado. Observação: embora as especificações RFC 1945 e RFC 2068 não permitam que o cliente altere o método da solicitação no redirecionamento, muitos navegadores existentes tratam a resposta 302 como uma resposta 303 e usam GET para acessar o URI especificado no Location, ignorando o método da solicitação original. Os códigos de status 303 e 307 foram adicionados para esclarecer qual resposta o servidor espera do cliente. |
| 303 | A resposta à solicitação atual pode ser encontrada em outro URI e o cliente deve acessar esse recurso usando GET. Esse método existe principalmente para permitir que a saída da solicitação POST ativada por script seja redirecionada para um novo recurso. Esse novo URI não é uma referência alternativa ao recurso original. Além disso, a resposta 303 é proibida de ser armazenada em cache. Obviamente, a segunda solicitação (redirecionamento) pode ser armazenada em cache. O novo URI deve ser retornado no campo Location da resposta. A menos que essa seja uma solicitação HEAD, a entidade de resposta deve conter um hiperlink para o novo URI e uma breve descrição. Observação: muitos navegadores anteriores às versões HTTP/1.1 não entendem corretamente o estado 303. Se for necessário considerar a interação com esses navegadores, o código de status 302 deve ser suficiente, pois a maioria dos navegadores trata a resposta 302 exatamente da mesma forma que a especificação acima exige que o cliente trate a resposta 303. |
| 304 | O servidor DEVERÁ retornar esse código de status se o cliente enviar uma solicitação GET condicional que tenha sido permitida e o conteúdo do documento (desde a última visita ou de acordo com as condições da solicitação) não tiver sido alterado.304 As respostas são proibidas de conter um corpo de mensagem e, portanto, sempre terminam com a primeira linha em branco após o cabeçalho da mensagem. A resposta DEVE conter os seguintes cabeçalhos: Data, a menos que o servidor não tenha um relógio. Se um servidor sem relógio seguir essas regras, o servidor proxy e o cliente poderão adicionar o campo Date ao cabeçalho da resposta de entrada por conta própria (conforme especificado na RFC 2068), e o mecanismo de cache funcionará corretamente.ETag e/ou Content-Location, se a mesma solicitação tiver retornado uma resposta 200.Expires Expires, Cache-Control e/ou Vary, se o valor puder ser diferente do valor correspondente a outras respostas anteriores para a mesma variável. Se essa solicitação de resposta usar validação de cache forte, essa resposta não deverá conter outros cabeçalhos de entidade; caso contrário (por exemplo, uma solicitação GET condicional usa validação de cache fraca), essa resposta não poderá conter outros cabeçalhos de entidade; isso evita inconsistências entre o conteúdo da entidade em cache e as informações atualizadas do cabeçalho da entidade. Se uma resposta 304 indicar que uma entidade não está armazenada em cache no momento, o sistema de cache deve ignorar a resposta e repetir a solicitação 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 a entrada inteira para refletir os valores de todos os campos atualizados na resposta. |
| 305 | O recurso solicitado deve ser acessado por meio do proxy especificado. O campo Location fornecerá informações sobre o URI em que o proxy especificado está localizado. O destinatário precisaria enviar uma solicitação separada repetidamente para acessar o recurso por meio desse proxy. Somente o servidor original pode criar uma resposta 305. Observação: não está claro na RFC 2068 que uma resposta 305 se destina a redirecionar uma única solicitação e só pode ser criada pelo servidor original. Ignorar essas restrições pode levar a sérias consequências de segurança. |
| 306 | Na versão mais recente da especificação, o código de status 306 não é mais usado. |
| 307 | O recurso solicitado agora responde temporariamente à solicitação de um URI diferente. Como esses redirecionamentos são temporários, os clientes devem continuar a enviar solicitações futuras para o endereço original. Essa resposta só pode ser armazenada em cache se for especificada em Cache-Control ou Expires. O novo URI temporário deve ser retornado no campo Location da resposta. A menos que se trate de uma solicitação HEAD, a entidade de resposta deve conter um hiperlink para o novo URI e uma breve descrição. Como alguns navegadores não reconhecem a resposta 307, as informações acima precisam ser adicionadas para que o usuário possa entender e solicitar acesso ao novo URI. Se essa não for uma solicitação GET ou HEAD, o navegador proibirá o redirecionamento automático, a menos que seja confirmado pelo usuário, porque as condições da solicitação podem mudar. |
| 400 | 1) Há um erro de semântica e a solicitação atual não pode ser compreendida pelo servidor. A menos que seja modificado, o cliente não deve enviar essa solicitação repetidamente. 2, os parâmetros da solicitação estão errados. |
| 401 | A solicitação atual exige autenticação do usuário. A resposta deve conter um cabeçalho WWW-Authenticate para que o recurso solicitado solicite informações do usuário. O cliente pode enviar repetidamente uma solicitação que contenha as informações apropriadas do cabeçalho Authorisation. Se a solicitação atual já contiver credenciais de autorização, a resposta 401 significa que o servidor verifica se essas credenciais foram rejeitadas. Se a resposta 401 contiver a mesma consulta de autenticação que a resposta anterior e o navegador já tiver tentado a autenticação pelo menos uma vez, o navegador DEVERÁ apresentar ao usuário as informações de entidade contidas na resposta, pois essas informações de entidade podem conter informações de diagnóstico relevantes. Consulte a RFC 2617. |
| 402 | Esse código de status é reservado para possíveis requisitos futuros. |
| 403 | O servidor entendeu a solicitação, mas se recusa a executá-la. Ao contrário de uma resposta 401, a autenticação não fornece nenhuma ajuda e essa solicitação não deve ser reenviada. Se essa não for uma solicitação HEAD e o servidor quiser falar claramente sobre o motivo pelo qual a solicitação não pode ser executada, o motivo da recusa deve ser descrito na entidade. É claro que o servidor também pode retornar uma resposta 404 se não quiser fornecer nenhuma informação ao cliente. |
| 404 | A solicitação falhou, o recurso solicitado não foi encontrado no servidor. Não há informações para informar ao usuário se a situação é temporária ou permanente. Se o servidor estiver ciente da situação, deverá usar o código de status 410 para informar ao usuário que o recurso antigo está permanentemente indisponível devido a algum mecanismo de configuração interna e que não há redirecionamento disponível. 404 é amplamente usado quando o servidor não deseja revelar por que a solicitação foi rejeitada ou quando 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 um cabeçalho Allow indicando a lista de métodos de solicitação que são aceitáveis para o recurso atual. Como os métodos PUT e DELETE gravam no recurso no servidor, a maioria dos servidores da Web não oferece suporte a esses métodos de solicitação ou não os permite por padrão, e retornará um erro 405 para essas solicitações. |
| 406 | As características do conteúdo do recurso solicitado não satisfazem as condições do cabeçalho da solicitação, e uma entidade de resposta não pode ser gerada. A menos que se trate de uma solicitação HEAD, a resposta deve retornar uma entidade que contenha uma lista de propriedades e endereços de entidades a partir da qual o usuário ou o navegador possa selecionar a mais adequada. O formato da entidade é determinado pelo tipo de mídia definido no cabeçalho Content-Type. Os navegadores podem fazer suas próprias escolhas com base no formato e em seus próprios recursos. Entretanto, a especificação não define nenhum critério para fazer essas escolhas automáticas. |
| 407 | Semelhante à resposta 401, exceto pelo fato de que o cliente DEVE se autenticar no servidor proxy. O servidor proxy DEVE retornar um Proxy-Authenticate para interrogação de identidade. O cliente PODE retornar um cabeçalho Proxy-Authorization para autenticação. Consulte a RFC 2617. |
| 408 | Tempo limite da solicitação. O cliente não concluiu o envio de uma solicitação dentro do tempo que o servidor estava preparado para esperar. O cliente pode reenviar a solicitação a qualquer momento sem fazer nenhuma alteração. |
| 409 | A solicitação não pôde ser concluída devido a um conflito com o estado atual do recurso solicitado. Esse código só poderá ser usado se o usuário for considerado capaz de 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. Normalmente, os conflitos ocorrem no processamento de solicitações PUT. Por exemplo, em um ambiente de verificação de versão, se as informações de versão anexadas a uma PUT enviada para modificar um determinado recurso entrarem em conflito com uma solicitação anterior (de terceiros), o servidor deverá retornar um erro 409 informando ao usuário que a solicitação não pôde ser concluída. Nesse caso, a entidade de resposta provavelmente conterá uma comparação das diferenças entre as duas versões conflitantes para que o usuário possa reenviar a nova versão após a mesclagem. |
| 410 | O recurso solicitado não está mais disponível no servidor e não tem nenhum endereço de encaminhamento conhecido. Essa condição deve ser considerada permanente. Se possível, os clientes com recursos de edição de links devem 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, deverá ser usado um código de status 404. Salvo indicação em contrário, essa resposta pode ser armazenada em cache.410 A finalidade da resposta é principalmente ajudar o webmaster a manter o site, informando 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 com esse recurso também sejam removidas. Esse tipo de evento é comum em serviços de valor agregado com tempo limitado. Da mesma forma, a resposta 410 é usada para notificar os clientes de que um recurso que originalmente pertencia a um indivíduo no site do servidor atual não está mais disponível. Obviamente, cabe inteiramente ao proprietário do servidor decidir se todos os recursos permanentemente indisponíveis precisam ser marcados como "410 Gone" e por quanto tempo essa marcação precisa ser mantida. |
| 411 | O servidor se recusa a aceitar solicitações sem o cabeçalho Content-Length definido. Depois de adicionar um cabeçalho Content-Length válido indicando o tamanho do corpo da mensagem da solicitação, o cliente pode enviar a solicitação novamente. |
| 412 | O servidor não conseguiu atender a um ou mais dos pré-requisitos ao verificar se eles foram fornecidos no campo de cabeçalho da solicitação. Esse código de status permite que o cliente defina pré-condições na metamensagem da solicitação (dados do campo de cabeçalho da solicitação) ao obter um recurso, impedindo assim que o método de solicitação seja aplicado a recursos diferentes do conteúdo desejado. |
| 413 | O servidor se recusa a processar a solicitação atual porque ela envia dados de entidade de um tamanho maior do que o servidor está disposto ou é capaz de manipular. Nesse caso, o servidor pode fechar a conexão para impedir que o cliente continue a enviar essa solicitação. Se essa condição for temporária, o servidor deverá retornar um cabeçalho de resposta Retry-After para informar ao cliente quanto tempo depois ele poderá tentar novamente. |
| 414 | O comprimento do URI da solicitação excede o comprimento que o servidor pode interpretar, portanto, o servidor se recusa a atender à solicitação. Isso é raro e geralmente ocorre quando o envio de um formulário que deveria ter usado o método POST se torna um método GET, resultando em uma Query String longa. Redirecionar "buracos negros" de URI, como usar o URI antigo como parte do novo URI a cada redirecionamento, resultando em um URI longo após vários redirecionamentos. Os clientes estão tentando atacar os servidores explorando as vulnerabilidades de segurança existentes em alguns servidores. Esses servidores usam um buffer de comprimento fixo para ler ou manipular o URI de uma solicitação e, quando os parâmetros após um GET excedem um determinado valor, pode ocorrer um estouro do buffer, levando à execução arbitrária de código [1]. Os servidores sem essas vulnerabilidades devem retornar um código de status 414. |
| 415 | Para o método atualmente solicitado e o recurso solicitado, a entidade enviada na solicitação não está em um formato compatível com o servidor, portanto a solicitação é rejeitada. |
| 416 | Se a solicitação contiver um cabeçalho de solicitação Range e quaisquer intervalos de dados especificados no Range não se sobrepuserem aos intervalos disponíveis para o recurso atual, e o cabeçalho de solicitação If-Range não estiver definido na solicitação, o servidor deverá retornar um código de status 416. Se o Range usar intervalos de bytes, esse será o caso se a primeira posição de byte de todos os intervalos de dados especificados na solicitação exceder o comprimento do recurso atual. O servidor também deve incluir um cabeçalho de entidade Content-Range que especifique o comprimento do recurso atual junto com o código de status 416. Essa resposta também é 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 atendido pelo servidor, ou esse servidor é um servidor proxy que tem evidências claras de que o conteúdo de Expect não pode ser atendido no próximo nó da rota atual. |
| 421 | O número de conexões com o servidor a partir do endereço IP em que o cliente atual está localizado excede o máximo permitido pelo servidor. Normalmente, o endereço IP aqui se refere ao endereço do cliente visto do servidor (por exemplo, o gateway do usuário ou o endereço do servidor proxy). Nesse caso, a contagem de conexões pode envolver mais de um usuário final. |
| 422 | O número de conexões com o servidor a partir do endereço IP do cliente atual excede o máximo permitido pelo servidor. Normalmente, o endereço IP aqui se refere ao endereço do cliente visto do servidor (por exemplo, o gateway do usuário ou o endereço do servidor proxy). Nesse caso, a 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 porque continha erros de semântica. (RFC 4918 WebDAV) 423 Bloqueado O recurso atual está bloqueado. (RFC 4918 WebDAV) |
| 424 | A solicitação atual falhou devido a um erro ocorrido em uma solicitação anterior, como PROPPATCH. (RFC 4918 WebDAV) |
| 425 | Definido no rascunho do 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 | Estendido pela Microsoft para representar que as solicitações devem ser repetidas depois que a ação apropriada tiver sido executada. |
| 500 | O servidor encontrou uma condição imprevista que o impediu de concluir o processamento da solicitação. Normalmente, esse problema ocorre quando há um erro no código do programa do servidor. |
| 501 | O servidor não oferece suporte a um recurso específico que é necessário para a solicitação atual. Quando o servidor não consegue reconhecer o método solicitado e não consegue dar suporte à sua solicitação de qualquer recurso. |
| 502 | Um servidor que funciona como gateway ou proxy recebe uma resposta inválida de um servidor upstream quando tenta executar uma solicitação. |
| 503 | No momento, o servidor não pode processar a solicitação devido à manutenção temporária ou sobrecarga do servidor. Essa condição é temporária e será restaurada após algum tempo. Se for possível esperar um atraso, a resposta poderá incluir um cabeçalho Retry-After para indicar o atraso. Se essa informação Retry-After não for fornecida, o cliente deverá tratá-la da mesma forma que uma resposta 500. Observação: a existência do código de status 503 não significa que o servidor deva usá-lo se estiver sobrecarregado. Alguns servidores simplesmente desejam negar uma conexão ao cliente. |
| 504 | Um servidor que funciona como gateway ou proxy e que tenta executar uma solicitação não recebe uma resposta em tempo hábil de um servidor upstream (um servidor identificado por um URI, como HTTP, FTP, LDAP) ou de um servidor secundário (como DNS). Observação: alguns servidores proxy retornam um erro 400 ou 500 quando a pesquisa de DNS atinge o tempo limite. |
| 505 | O servidor não é compatível ou se recusa a ser compatível com a versão do HTTP usada na solicitação. Isso implica que o servidor não pode ou não quer usar a mesma versão que o cliente. A resposta deve conter uma entidade que descreva por que a versão não é compatível e quais protocolos o servidor suporta. |
| 506 | Estendido pelo Protocolo de Negociação de Conteúdo Transparente (RFC 2295) para representar uma configuração interna incorreta por parte do servidor: o recurso da Variante de Negociação solicitado está configurado para usar a si mesmo na negociação de conteúdo transparente e, portanto, não é um foco apropriado em um processo de negociação. |
| 507 | O servidor não consegue armazenar o conteúdo necessário para concluir a solicitação. Essa condição é considerada temporária.WebDAV (RFC 4918) |
| 509 | O servidor atingiu seu limite de largura de banda. Esse não é um código de status oficial, mas ainda é amplamente usado. |
| 510 | A política necessária para obter o recurso não deixou de ser atendida. (RFC 2774) |