| Código de status HTTP | Significado do código de status |
|---|
| 100 | O cliente deve continuar enviando solicitações. Esta resposta provisória é utilizada para informar ao cliente que parte de sua solicitação foi recebida pelo servidor e ainda não foi rejeitada. O cliente DEVE continuar enviando o restante da solicitação ou ignorar esta resposta se a solicitação já 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 de atualização para usar um protocolo diferente para concluir a solicitação. Após enviar a última linha em branco desta resposta, o servidor mudará para os protocolos definidos no cabeçalho Upgrade. Tais medidas só devem ser tomadas quando a mudança para um novo protocolo for mais benéfica. Por exemplo, mudar para uma nova versão HTTP tem vantagens em relação a uma versão mais antiga, ou mudar para um protocolo síncrono e em tempo real para fornecer recursos que aproveitem tais recursos. |
| 102 | Um código de status estendido pelo WebDAV (RFC 2518) indicando que o processamento continuará. |
| 200 | A solicitação foi bem-sucedida e os cabeçalhos de resposta ou corpo de dados esperados pela solicitação serão retornados com esta resposta. |
| 201 | A solicitação foi atendida, um novo recurso foi criado com base nas necessidades da solicitação e seu URI foi retornado com o cabeçalho Location. Se os recursos necessários não puderem ser criados a tempo, '202 Aceito' deverá ser retornado. |
| 202 | O servidor aceitou a solicitação, mas ainda não a processou. Assim como pode ser negado, o pedido pode ou não ser executado. No caso de operações assíncronas, não há forma mais conveniente do que enviar este código de status. O objetivo de retornar uma resposta de 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 ter que manter o cliente conectado ao servidor até a operação em lote. está completo. Uma resposta que aceita processamento de solicitação e retorna um código de status 202 deve conter algumas informações na entidade retornada indicando o status atual do processamento, 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 completado. |
| 203 | O servidor processou a solicitação com êxito, mas a metainformação do cabeçalho da entidade retornada não é um conjunto definido válido no servidor original, mas uma cópia de um local ou de terceiros. A informação atual pode ser um subconjunto ou um superconjunto da versão original. Por exemplo, conter metadados para um recurso pode fazer com que o servidor de origem conheça as superinformações sobre os metadados. O uso desse código de status não é obrigatório e só é apropriado se a resposta tivesse retornado 200 OK sem esse código de status. |
| 204 | O servidor processou a solicitação com êxito, mas não precisa retornar nenhum conteúdo da entidade e deseja retornar metainformações atualizadas. A resposta pode retornar metainformações novas ou atualizadas na forma de cabeçalhos de entidade. Esses cabeçalhos, se presentes, deverão corresponder às variáveis solicitadas. Se o cliente for um navegador, o navegador do usuário DEVE manter a página para a qual a solicitação foi feita sem quaisquer alterações na visualização do documento, mesmo que metainformações novas ou atualizadas devam ser aplicadas à atividade do navegador do usuário de acordo com a especificação Documentos em visualização. Como é proibido que uma resposta 204 contenha qualquer corpo de mensagem, ela sempre termina com a primeira linha vazia após o cabeçalho da mensagem. |
| 205 | O servidor processou a solicitação com êxito e não retornou nada. Mas, diferentemente de uma resposta 204, uma resposta que retorna esse código de status exige 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 iniciar facilmente outra entrada. Assim como a resposta 204, esta 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. Ferramentas de download HTTP como FlashGet ou Thunder usam esse tipo de resposta para retomar downloads interrompidos ou dividir um documento grande em vários segmentos de download para download simultâneo. A solicitação deve incluir um cabeçalho Range para indicar o intervalo de conteúdo que o cliente espera e pode incluir um If-Range como condição de solicitação. A resposta deve incluir os seguintes campos de cabeçalho: Content-Range é usado para indicar o intervalo de conteúdo retornado nesta resposta; se for um download multipart com Content-Type multipart/byteranges, cada parte multipart deve conter Content-Range The domínio é usado para indicar o escopo do conteúdo deste parágrafo. Se um Content-Length for incluído na resposta, seu valor deverá corresponder ao número real de bytes no intervalo de conteúdo retornado. Data ETag e/ou Content-Location, se a mesma solicitação deveria ter retornado uma resposta 200. Expira, Cache-Control e/ou Vary, se seu valor puder ser diferente do valor correspondente a outras respostas anteriores à mesma variável. Se esta solicitação de resposta usar verificação de cache forte If-Range, então esta resposta não deverá conter outros cabeçalhos de entidade; se esta solicitação de resposta usar verificação de cache fraco If-Range, então esta resposta será proibida de conter outros cabeçalhos de entidade; isso evita Resolve inconsistências entre conteúdo da entidade em cache e informações atualizadas do cabeçalho da entidade. Caso contrário, esta resposta deverá conter todos os campos do cabeçalho da entidade que deverão ser retornados em uma resposta 200. Se o cabeçalho ETag ou Last-Modified não corresponder exatamente, o cache do cliente não deverá combinar o conteúdo retornado pela resposta 206 com qualquer conteúdo armazenado em cache anteriormente. Qualquer cache que não suporte cabeçalhos Range e Content-Range está proibido de armazenar em cache o conteúdo retornado por uma resposta 206. |
| 207 | O código de status 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 independentes, dependendo do número de subsolicitações anteriores. |
| 300 | O recurso solicitado possui uma série de respostas opcionais, cada uma com seu próprio endereço específico e informações de negociação do driver do navegador. O usuário ou navegador pode escolher um endereço preferencial para redirecionamento. A menos que se trate de uma solicitação HEAD, a resposta deve incluir uma entidade com uma lista de atributos de recursos e endereços a partir 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-Type. O navegador pode fazer automaticamente a escolha mais apropriada com base no formato da resposta e nas capacidades do próprio navegador. É claro que a especificação RFC 2616 não especifica como essa seleção automática deve ser realizada. Se o próprio servidor já tiver uma opção de feedback preferencial, o URI desse feedback deverá ser especificado em Local; o navegador poderá usar esse valor de Local como o endereço para redirecionamento automático. Além disso, esta resposta pode ser armazenada em cache, a menos que especificado de outra forma. |
| 301 | O recurso solicitado foi movido permanentemente para um novo local e quaisquer referências futuras a este recurso deverão utilizar um dos vários URIs devolvidos com esta resposta. Se possível, os clientes com capacidade de edição de link deverão modificar automaticamente o endereço solicitado para o endereço retornado do servidor. A menos que especificado de outra forma, esta resposta também pode ser armazenada em cache. O novo URI permanente deve ser retornado no campo Localização da resposta. A menos que se trate de uma solicitação HEAD, a entidade de resposta deverá conter um hiperlink para o novo URI e uma breve descrição. 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 de acordo. Nota: Para alguns navegadores que usam o protocolo HTTP/1.0, quando a solicitação POST enviada recebe uma resposta 301, a solicitação de redirecionamento subsequente se tornará um método GET. |
| 302 | O recurso solicitado agora responde temporariamente a solicitações de um URI diferente. Como esses redirecionamentos são temporários, o cliente deverá continuar a enviar solicitações futuras para o endereço original. Esta resposta só pode ser armazenada em cache se especificada em Cache-Control ou Expires. O novo URI temporário deve ser retornado no campo Localização da resposta. A menos que se trate de uma solicitação HEAD, a entidade de resposta deverá conter um hiperlink para o novo URI e uma breve descrição. 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 de acordo. Nota: Embora as especificações RFC 1945 e RFC 2068 não permitam que o cliente altere o método de solicitação ao redirecionar, muitos navegadores existentes consideram a resposta 302 como uma resposta 303 e usam o método GET para acessar o URI especificado no Local, independentemente do 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 usar GET para acessar esse recurso. Este método existe principalmente para permitir que a saída da solicitação POST ativada por script seja redirecionada para um novo recurso. Este novo URI não é uma referência de substituição ao recurso original. Ao mesmo tempo, 303 respostas estão proibidas de serem armazenadas em cache. Obviamente, a segunda solicitação (redirecionamento) pode ser armazenada em cache. O novo URI deve ser retornado no campo Localização da resposta. A menos que se trate de uma solicitação HEAD, a entidade de resposta deverá conter um hiperlink para o novo URI e uma breve descrição. Nota: Muitos navegadores pré-HTTP/1.1 não entendem corretamente o status 303. Se você precisar considerar a interação com esses navegadores, o código de status 302 deverá ser suficiente, porque a maioria dos navegadores lida com respostas 302 exatamente da maneira que a especificação acima exige que os clientes lidem com respostas 303. |
| 304 | Caso o cliente envie uma solicitação GET condicional e a solicitação seja permitida, mas o conteúdo do documento não tenha mudado (desde o último acesso ou de acordo com as condições da solicitação), o servidor deverá retornar este código de status. Uma resposta 304 é proibida de incluir o corpo da mensagem, por isso sempre termina 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, a menos que o servidor não possua relógio. Se os servidores sem relógios também cumprirem essas regras, os servidores proxy e os clientes poderão adicionar o campo Data aos próprios cabeçalhos de resposta recebidos (conforme especificado na RFC 2068) e o mecanismo de cache funcionará normalmente. ETag e/ou Content-Location, se a mesma solicitação deveria ter retornado uma resposta 200. Expira, Cache-Control e/ou Vary, se seu valor puder ser diferente do valor correspondente a outras respostas anteriores à mesma variável. Se esta solicitação de resposta usar verificação de cache forte, então esta resposta não deverá conter outros cabeçalhos de entidade; caso contrário (por exemplo, uma solicitação GET condicional usa verificação de cache fraca), esta resposta será proibida de conter outros cabeçalhos de entidade; isso evita Resolve inconsistências entre caches conteúdo da entidade e informações atualizadas do cabeçalho da entidade. Se uma resposta 304 indicar que uma entidade não está atualmente armazenada em cache, o sistema de cache deverá ignorar a resposta e repetir a solicitação sem restrição. Se for recebida uma resposta 304 que exija uma atualização de uma entrada de cache, o sistema de cache deverá atualizar toda a entrada para refletir os valores de todos os campos que foram atualizados na resposta. |
| 305 | O recurso solicitado deve ser acessado por meio do proxy especificado. As informações de URI do proxy especificado serão fornecidas no campo Localização. O destinatário precisa enviar repetidamente uma solicitação separada para acessar os recursos correspondentes através deste proxy. Somente o servidor de origem pode estabelecer uma resposta 305. NOTA: A RFC 2068 não especifica que uma resposta 305 se destina a redirecionar uma única solicitação e só pode ser estabelecida pelo servidor de origem. 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 a solicitações de um URI diferente. Como esses redirecionamentos são temporários, o cliente deverá continuar a enviar solicitações futuras para o endereço original. Esta resposta só pode ser armazenada em cache se especificada em Cache-Control ou Expires. O novo URI temporário deve ser retornado no campo Localização da resposta. A menos que se trate de uma solicitação HEAD, a entidade de resposta deverá conter um hiperlink para o novo URI e uma breve descrição. Como alguns navegadores não conseguem reconhecer a resposta 307, as informações necessárias acima precisam ser adicionadas para que os usuários possam entender e fazer solicitações 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 de acordo. |
| 400 | 1. A semântica está incorreta e a solicitação atual não pode ser compreendida pelo servidor. O cliente não deve reenviar esta solicitação, a menos que seja modificada. 2. Os parâmetros da solicitação estão incorretos. |
| 401 | A solicitação atual requer autenticação do usuário. A resposta DEVE incluir um cabeçalho WWW-Authenticate apropriado ao recurso solicitado que solicita informações do usuário. O cliente pode enviar repetidamente uma solicitação contendo as informações apropriadas do cabeçalho de autorização. Se a solicitação atual já contiver certificados de autorização, a resposta 401 indicará que a verificação do servidor rejeitou esses certificados. Se a resposta 401 contiver a mesma consulta de autenticação da resposta anterior, e o navegador tiver tentado a autenticação pelo menos uma vez, o navegador deverá exibir ao usuário as informações da entidade contidas na resposta, pois essas informações da entidade podem conter informações de diagnóstico relevantes. Consulte RFC 2617. |
| 402 | Este código de status está reservado para possíveis necessidades futuras. |
| 403 | O servidor entendeu a solicitação, mas recusou-se a executá-la. Ao contrário de uma resposta 401, a autenticação não fornece nenhuma ajuda e a solicitação não deve ser reenviada. Se esta não for uma solicitação HEAD e o servidor quiser explicar por que a solicitação não pode ser executada, o motivo da rejeição deverá ser descrito na entidade. Claro, o servidor também pode retornar uma resposta 404 se não quiser que o cliente obtenha nenhuma informação. |
| 404 | A solicitação falhou. O recurso solicitado não foi encontrado no servidor. Não há informações que digam ao usuário se a condição é temporária ou permanente. Caso o servidor conheça a situação, deverá utilizar o código de status 410 para informar que o recurso antigo está permanentemente indisponível devido a alguns problemas internos do mecanismo de configuração e não há endereço de salto. O código de status 404 é amplamente utilizado quando o servidor não deseja revelar por que a solicitação foi rejeitada ou nenhuma outra resposta adequada está 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 informações de cabeçalho Allow para indicar a lista de métodos de solicitação que o recurso atual pode aceitar. Como os métodos PUT e DELETE gravarão recursos no servidor, a maioria dos servidores web não suporta ou não permite os métodos de solicitação acima na configuração padrão, e um erro 405 será retornado para tais solicitações. |
| 406 | As características de conteúdo do recurso solicitado não satisfazem as condições no cabeçalho da solicitação, portanto a entidade de resposta não pode ser gerada. A menos que se trate de uma solicitação HEAD, a resposta deve retornar uma entidade contendo uma lista de atributos e endereços da entidade a partir dos quais o usuário ou navegador pode escolher o mais apropriado. O formato da entidade é determinado pelo tipo de mídia definido no cabeçalho Content-Type. O navegador pode fazer sua melhor escolha com base no formato e em seus recursos. Contudo, a especificação não define quaisquer critérios para fazer tais seleções automáticas. |
| 407 | Semelhante a uma resposta 401, exceto que o cliente deve se autenticar no servidor proxy. O servidor proxy deve retornar um Proxy-Authenticate para consulta de identidade. O cliente pode retornar um cabeçalho Proxy-Authorization para verificação. Consulte RFC 2617. |
| 408 | A solicitação expirou. 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 esta solicitação a qualquer momento sem fazer nenhuma alteração. |
| 409 | A solicitação não pode ser concluída devido a um conflito com o estado atual do recurso solicitado. Este código só deve ser usado se o usuário for 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. Geralmente ocorrem conflitos no processamento de solicitações PUT. Por exemplo, em um ambiente que usa verificação de versão, se as informações de versão anexadas a uma solicitação de modificação de um recurso específico enviada por um PUT entrarem em conflito com uma solicitação anterior (de terceiros), o servidor deverá retornar um erro 409 neste momento. Informe ao usuário que a solicitação não pode ser concluída. Neste momento, é provável que a entidade de resposta contenha uma comparação de diferenças entre as duas versões conflitantes, para que o usuário possa reenviar a nova versão após a fusão. |
| 410 | O recurso solicitado não está mais disponível no servidor e não possui nenhum endereço de encaminhamento conhecido. Tal situação deveria ser considerada permanente. Se possível, os clientes com capacidade de edição de links deverão remover todas as referências a este endereço com a permissão do usuário. Se o servidor não souber ou não puder determinar se a condição é permanente, o código de status 404 deverá ser usado. Salvo indicação em contrário, esta resposta pode ser armazenada em cache. O objetivo da resposta 410 é principalmente ajudar os administradores do site a manter o site, notificar os usuários de que o recurso não está mais disponível e o proprietário do servidor espera que todas as conexões remotas que apontam para este recurso também sejam excluídas. Esse tipo de incidente é comum entre serviços de valor agregado por tempo limitado. Da mesma forma, a resposta 410 também é usada para notificar o cliente de que os recursos originalmente pertencentes a um indivíduo não estão mais disponíveis no site do servidor atual. Claro, cabe inteiramente ao proprietário do servidor se todos os recursos permanentemente indisponíveis precisam ser marcados como '410 Gone' e por quanto tempo eles precisam para manter essa marca. |
| 411 | O servidor se recusa a aceitar a solicitação sem o cabeçalho Content-Length definido. 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 atendeu a um ou mais pré-requisitos fornecidos nos campos de cabeçalho da solicitação ao validá-los. Este código de status permite que o cliente defina pré-condições na metainformação da solicitação (dados do campo do cabeçalho da solicitação) ao recuperar o recurso, evitando assim que o método de solicitação seja aplicado ao recurso diferente do esperado. |
| 413 | O servidor está se recusando a processar a solicitação atual porque a solicitação enviou dados da entidade que são maiores do que o servidor deseja ou é capaz de manipular. Neste caso, o servidor pode fechar a conexão para evitar que o cliente continue enviando esta solicitação. Se a situação for temporária, o servidor deverá retornar um cabeçalho de resposta Retry-After para informar ao cliente por quanto tempo ele poderá tentar novamente. |
| 414 | O URI solicitado é mais longo do que o servidor pode interpretar, portanto o servidor se recusa a atender a solicitação. Isso é relativamente raro. Situações comuns incluem: o envio de um formulário que deveria usar o método POST torna-se o método GET, resultando na string de consulta (Query String) muito longa. Redirecionar URI "buraco negro", por exemplo, cada redirecionamento usa o URI antigo como parte do novo URI, fazendo com que o URI fique muito longo após vários redirecionamentos. O cliente está tentando atacar o servidor explorando uma vulnerabilidade de segurança que existe em alguns servidores. Este tipo de servidor usa um buffer de comprimento fixo para ler ou operar o URI solicitado. Quando os parâmetros após GET excedem um determinado valor, pode ocorrer um buffer overflow, causando a execução de código arbitrário [1]. Servidores sem tais vulnerabilidades devem retornar um código de status 414. |
| 415 | Para o método e recurso solicitado atualmente, a entidade enviada na solicitação não está em um formato suportado pelo servidor, portanto a solicitação é rejeitada. |
| 416 | Se a solicitação contiver o cabeçalho da solicitação Range e qualquer intervalo de dados especificado no Range não coincidir com o intervalo disponível do recurso atual e o cabeçalho da solicitação If-Range não estiver definido na solicitação, o servidor deverá retornar um status 416 código. Se Range usar um intervalo de bytes, essa situação significa que a primeira posição de byte de todos os intervalos de dados especificados na solicitação excede o comprimento do recurso atual. O servidor também deve incluir um cabeçalho de entidade Content-Range para indicar o comprimento do recurso atual enquanto retorna o código de status 416. Esta resposta também está proibida de usar multipart/byteranges como seu tipo de conteúdo. |
| 417 | O conteúdo esperado especificado no cabeçalho da solicitação Expect não pode ser atendido pelo servidor ou o servidor é um servidor proxy e possui evidências claras de que o conteúdo de Expect não pode ser atendido no próximo nó na rota atual. |
| 421 | O número de conexões ao servidor a partir do endereço IP do cliente atual excede o intervalo máximo permitido do servidor. Normalmente, o endereço IP aqui se refere ao endereço do cliente visto no servidor (como o gateway do usuário ou o endereço do servidor proxy). Neste caso, a 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 IP do cliente atual excede o intervalo máximo permitido do servidor. Normalmente, o endereço IP aqui se refere ao endereço do cliente visto no servidor (como o gateway do usuário ou o endereço do servidor proxy). Neste caso, a contagem de conexões pode envolver mais de um usuário final. |
| 422 | A solicitação está bem formatada, mas não pode ser respondida devido a erros semânticos. (RFC 4918 WebDAV) 423 BloqueadoO recurso atual está bloqueado. (RFC 4918WebDAV) |
| 424 | A solicitação atual falhou devido a um erro em uma solicitação anterior, como PROPPATCH. (RFC 4918WebDAV) |
| 425 | Definido no rascunho de Coleções Avançadas WebDav, mas não aparece no "Protocolo de Coleta de Sequência WebDAV" (RFC 3658). |
| 426 | Os clientes devem mudar para TLS/1.0. (RFC2817) |
| 449 | Estendido pela Microsoft, indica que as solicitações devem ser repetidas após a execução das ações apropriadas. |
| 500 | O servidor encontrou uma condição inesperada que o impediu de concluir o processamento da solicitação. De modo geral, esse problema ocorrerá quando houver um erro no código do programa do servidor. |
| 501 | O servidor não oferece suporte a um recurso exigido pela solicitação atual. Quando o servidor não reconhece o método solicitado e não consegue suportar sua solicitação de nenhum recurso. |
| 502 | Um servidor funcionando como gateway ou proxy recebeu uma resposta inválida de um servidor upstream ao tentar executar uma solicitação. |
| 503 | Devido à manutenção ou sobrecarga temporária do servidor, o servidor não consegue processar solicitações no momento. Esta condição é temporária e será restaurada após um período de tempo. Se o tempo de atraso puder ser esperado, a resposta poderá incluir um cabeçalho Retry-After para indicar o tempo de atraso. Se esta mensagem Retry-After não for fornecida, o cliente DEVE tratá-la da mesma forma que trata uma resposta 500. Nota: A presença do código de status 503 não significa que o servidor deva utilizá-lo quando estiver sobrecarregado. Alguns servidores simplesmente desejam negar conexões de clientes. |
| 504 | Quando um servidor que funciona como gateway ou proxy tenta executar uma solicitação, ele não consegue receber uma resposta oportuna do servidor upstream (o servidor identificado pelo URI, como HTTP, FTP, LDAP) ou do servidor auxiliar (como DNS ). Nota: Alguns servidores proxy retornarão um erro 400 ou 500 quando a consulta DNS atingir o tempo limite. |
| 505 | O servidor não oferece suporte 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 do cliente. A resposta deve conter uma entidade descrevendo por que a versão não é suportada e quais protocolos o servidor suporta. |
| 506 | Estendido pelo Protocolo de Negociação de Conteúdo Transparente (RFC 2295), indica que o servidor possui um erro de configuração interna: o recurso de argumento de negociação solicitado está configurado para ser usado 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 pode armazenar o conteúdo necessário para concluir a solicitação. Esta condição é considerada temporária. WebDAV (RFC 4918) |
| 509 | O servidor atingiu seu 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 ainda não estão satisfeitas. (RFC2774) |