| Código de Status HTTP |
Significado do Código |
| 100 |
O cliente deve continuar a enviar a solicitação. Esta resposta temporária é usada para informar ao cliente que uma 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 se a solicitação já estiver completa, ignorar essa resposta. O servidor deve enviar uma resposta final ao cliente após a conclusão da solicitação. |
| 101 |
O servidor já entendeu a solicitação do cliente e notificará o cliente através do cabeçalho Upgrade para adotar um protocolo diferente para concluir essa solicitação. Após enviar esta resposta com a última linha em branco, o servidor mudará para os protocolos definidos no cabeçalho Upgrade. Isso deve ser feito somente se for benéfico mudar para o novo protocolo, como quando a nova versão do HTTP é mais vantajosa que a antiga, ou quando uma troca para um protocolo em tempo real e síncrono é feita para transmitir recursos que se beneficiam dessas características. |
| 102 |
Código de status estendido pelo WebDAV (RFC 2518), representando que o processamento continuará. |
| 200 |
A solicitação foi bem-sucedida, e os cabeçalhos de resposta ou o corpo de dados desejados serão retornados com esta resposta. |
| 201 |
A solicitação foi implementada e um novo recurso foi criado de acordo com a necessidade da solicitação, e seu URI foi retornado com a informação do cabeçalho Location. Se o recurso necessário não puder ser criado de imediato, deve-se retornar '202 Accepted'. |
| 202 |
O servidor aceitou a solicitação, mas ainda não a processou. Como pode ser rejeitada, a solicitação pode ou não ser executada. Esta resposta é conveniente na situação de operações assíncronas, permitindo ao servidor aceitar solicitações para outros processos (por exemplo, uma operação baseada em lote que se executa apenas uma vez por dia) sem que o cliente precise manter uma conexão com o servidor até que toda a operação em lote seja concluída. A resposta que aceita o processamento da solicitação e retorna um status 202 deve incluir, no corpo da resposta, algumas informações indicando o estado atual do processamento, além de um link para um monitor de status ou previsão do estado, para que os usuários possam estimar se a operação já foi concluída. |
| 203 |
O servidor processou a solicitação com sucesso, mas os metadados da entidade retornada não são uma representação válida do conjunto original em seu servidor, mas sim uma cópia local ou de terceiros. A informação atual pode ser um subconjunto ou superconjunto da versão original. Por exemplo, a metainformação sobre um recurso pode levar o servidor original a saber que a metainformação é uma superconjunto. O uso deste código de status não é necessário, e ele é apropriado somente quando a resposta não poderia ter retornado 200 OK. |
| 204 |
O servidor processou a solicitação com sucesso, mas não precisa retornar nenhum corpo de entidade, e deseja retornar as informações de meta atualizadas. A resposta pode retornar novas ou atualizadas informações meta por meio dos cabeçalhos da entidade. Se esses cabeçalhos estiverem presentes, eles devem corresponder às variáveis solicitadas. Se o cliente for um navegador, ele deve manter a página que enviou a solicitação sem fazer nenhuma alteração na visualização do documento, mesmo correta na norma as novas ou atualizadas informações meta deveriam ser aplicadas à visualização de documento da atividade do navegador do usuário. Como a resposta 204 é proibida de incluir 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 sucesso e não retornou nenhum conteúdo. Mas, ao contrário da resposta 204, a resposta que retorna este código de status exige que o solicitante redefina a visualização do documento. Esta resposta é principalmente utilizada para redefinir o formulário imediatamente após aceitar a entrada do usuário, permitindo que o usuário comece facilmente uma nova entrada. Tal como a resposta 204, essa resposta também é proibida de incluir qualquer corpo de mensagem e termina com a primeira linha em branco após o cabeçalho da mensagem. |
| 206 |
O servidor processou com sucesso uma parte da solicitação GET. Ferramentas de download HTTP como FlashGet ou Thunder usam tais respostas para implementar a recuperação de pontos de interrupção ou dividir um grande documento em vários segmentos para download simultâneo. A solicitação deve incluir o cabeçalho Range para indicar ao cliente o intervalo de conteúdo desejado e pode incluir If-Range como condição da solicitação. A resposta deve incluir os seguintes cabeçalhos de campo: Content-Range para indicar o intervalo do conteúdo retornado nesta resposta; se for um download multipart/byteranges, cada parte multipart deve incluir o campo Content-Range para indicar o intervalo do conteúdo daquela parte. Se a resposta incluir Content-Length, seu valor deve corresponder ao número real de bytes do 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 forem diferentes dos valores em outras respostas correspondentes às mesmas variáveis. Se esta resposta da solicitação usou validação de cache forte If-Range, então esta resposta não deve incluir outros cabeçalhos de entidade; se esta resposta da solicitação usou validação de cache fraca If-Range, então esta resposta não pode incluir outros cabeçalhos de entidade; isso evita a inconsistência entre o conteúdo da entidade em cache e as informações de cabeçalho da entidade atualizadas. Caso contrário, esta resposta deve incluir todos os cabeçalhos de entidade que deveriam ter retornado na resposta 200. Se o cabeçalho ETag ou Last-Modified não puder corresponder exatamente, o cache do cliente deve proibir a combinação do conteúdo retornado na resposta 206 com qualquer conteúdo anteriormente armazenado em cache. Qualquer cache que não suporte os cabeçalhos Range e Content-Range é proibido de armazenar o conteúdo retornado na resposta 206. |
| 207 |
Código de status estendido pelo WebDAV (RFC 2518), representando que o corpo da mensagem seguinte será uma mensagem XML e pode incluir uma série de códigos de resposta independentes, dependendo do número de subsolicitações anteriores. |
| 300 |
Os recursos solicitados têm uma série de informações de feedback disponíveis, cada uma com seu próprio endereço e informações de marketing específicas do navegador. O usuário ou navegador pode escolher um endereço preferido para redirecionar. A menos que seja uma solicitação HEAD, essa resposta deve incluir um corpo que contém uma lista de características e endereços do recurso, para que o usuário ou navegador possa escolher o endereço mais adequado para o redirecionamento. O formato desse corpo é determinado pelo formato definido pelo cabeçalho Content-Type. O navegador pode fazer a escolha mais adequada automaticamente, dependendo do formato da resposta e das capacidades do próprio navegador. No entanto, a norma RFC 2616 não especifica como essa escolha automática deve ser feita. Se o servidor já tiver uma escolha de feedback preferida, o URI desse feedback deve ser indicado no Local; o navegador pode usar esse valor de Location como o endereço para o redirecionamento automático. Além disso, a menos que especificado de outra forma, essa resposta também é cacheável. |
| 301 |
O recurso solicitado foi movido permanentemente para um novo local, e qualquer referência futura a esse recurso deve usar um dos URIs retornados nesta resposta. Se possível, os clientes com capacidade de edição de link devem automaticamente modificar o endereço solicitado para o endereço retornado pelo servidor. A menos que especificado de outra forma, essa resposta também é cacheável. O novo URI permanente deve ser retornado no cabeçalho Location da resposta. A menos que seja uma solicitação HEAD, o corpo da resposta deve incluir um hyperlink para o novo URI e uma breve descrição. Se isso não for uma solicitação GET ou HEAD, o navegador deve proibir redirecionamentos automáticos, a menos que tenha a confirmação do usuário, pois as condições da solicitação podem mudar. Nota: Para alguns navegadores que usam o protocolo HTTP/1.0, quando um POST é enviado e recebe uma resposta 301, o próximo pedido de redirecionamento será feito como um GET. |
| 302 |
O recurso solicitado agora responde a solicitações temporariamente de um URI diferente. Como esse redirecionamento é temporário, o cliente deve continuar a enviar solicitações para o endereço original nas solicitações futuras. Essa resposta só é cacheável se especificado no Cache-Control ou Expires. O novo URI temporário deve ser retornado no cabeçalho Location da resposta. A menos que seja uma solicitação HEAD, o corpo da resposta deve incluir um hyperlink para o novo URI e uma breve descrição. Se isso não for uma solicitação GET ou HEAD, o navegador deve proibir redirecionamentos automáticos, a menos que tenha a confirmação do usuário, pois as condições da solicitação podem mudar. Nota: Embora as normas RFC 1945 e RFC 2068 não permitam que o cliente mude o método da solicitação ao redirecionar, muitos navegadores existentes tratam uma resposta 302 como uma resposta 303, usando o método GET para acessar o URI especificado no cabeçalho Location, ignorando o método original da solicitação. Os códigos de status 303 e 307 foram adicionados para esclarecer qual reação o servidor espera do cliente. |
| 303 |
A resposta à solicitação atual pode ser encontrada em outro URI, e o cliente deve usar o método GET para acessar esse recurso. Esta existência é principalmente para permitir que a saída de uma solicitação POST ativada por um script redirecione para um novo recurso. Este novo URI não é uma referência alternativa ao recurso original. Além disso, a resposta 303 não pode ser cacheada. É claro que a segunda solicitação (redirecionamento) pode ser cacheada. O novo URI deve ser retornado no cabeçalho Location da resposta. A menos que seja uma solicitação HEAD, o corpo da resposta deve incluir um hyperlink para o novo URI e uma breve descrição. Nota: Muitos navegadores anteriores ao HTTP/1.1 não entendem corretamente o status 303. Se a interação com esses navegadores for uma preocupação, o código de status 302 deve ser suficiente, pois a maioria dos navegadores lida com a resposta 302 da mesma forma que a norma exige que os clientes tratem a resposta 303. |
| 304 |
Se o cliente enviou uma solicitação GET condicional que foi permitida, e o conteúdo do documento (desde a última visita ou conforme os critérios da solicitação) não foi alterado, o servidor deve retornar este código de status. As respostas 304 não podem incluir o corpo da mensagem, portanto, sempre terminam com a primeira linha em branco após o cabeçalho da mensagem. A resposta deve incluir os seguintes cabeçalhos: Date, a menos que o servidor não tenha relógio. Se servidores sem relógio seguissem essas regras, o servidor proxy e o cliente poderiam adicionar o campo Date ao cabeçalho de resposta recebido (como especificado em RFC 2068), e o mecanismo de cache funcionaria normalmente. O ETag e/ou Content-Location, caso a mesma solicitação deveria ter retornado uma resposta 200. Expires, Cache-Control e/ou Vary, se seus valores forem diferentes dos valores em outras respostas correspondentes às mesmas variáveis. Se a solicitação desta resposta usou validação de cache forte, então esta resposta não deve incluir outros cabeçalhos de entidade; caso contrário (por exemplo, uma solicitação GET condicional usando validação de cache fraca), esta resposta não pode incluir outros cabeçalhos de entidade; isso evita a inconsistência entre o conteúdo da entidade em cache e as informações de cabeçalho da entidade atualizadas. Se uma resposta 304 indicar que a entidade atual não está em cache, o sistema de cache deve ignorar essa resposta e repetir a solicitação sem condições. Se receber uma resposta 304 exigindo atualizar uma entrada em cache, o sistema de cache deve atualizar a entrada completa para refletir todos os valores dos campos que foram atualizados na resposta. |
| 305 |
O recurso solicitado deve ser acessado através do proxy especificado. O cabeçalho de localização conterá informações sobre o URI do proxy especificado, o receptor deve enviar um pedido separado através deste proxy para acessar o recurso correspondente. Apenas o servidor original pode gerar respostas 305. Nota: A RFC 2068 não deixa claro que a resposta 305 destina-se a redirecionar um pedido separado e deve ser gerada apenas pelo servidor original. Ignorar estas limitações pode resultar em consequências graves de segurança. |
| 306 |
Nos padrões mais recentes, o código de status 306 não é mais utilizado. |
| 307 |
O recurso solicitado agora responde a solicitações temporariamente de um URI diferente. Como esse redirecionamento é temporário, o cliente deve continuar a enviar solicitações para o endereço original nas solicitações futuras. Apenas quando Cache-Control ou Expires estiverem especificados, essa resposta é cacheável. O novo URI temporário deve ser retornado no cabeçalho Location da resposta. A menos que seja uma solicitação HEAD, o corpo da resposta deve incluir um hyperlink para o novo URI e uma breve descrição. Como alguns navegadores não reconhecem a resposta 307 adequadamente, é necessário incluir as informações de cabeçalho necessárias para que o usuário possa entender e acessar o novo URI. Se isso não for uma solicitação GET ou HEAD, o navegador deve proibir redirecionamentos automáticos, a menos que tenha a confirmação do usuário, pois as condições da solicitação podem mudar. |
| 400 |
1. Semântica incorreta: a solicitação atual não pode ser compreendida pelo servidor. A menos que modificada, o cliente não deve reenviar essa solicitação. 2. Parâmetros da solicitação estão incorretos. |
| 401 |
A solicitação atual requer autenticação do usuário. Essa resposta deve incluir um cabeçalho WWW-Authenticate adequado para o recurso solicitado para solicitar as informações do usuário. O cliente pode reenviar uma solicitação com o cabeçalho Authorization adequado. Se a solicitação atual já incluía credenciais de autorização, a resposta 401 representa que a validação do servidor rejeitou essas credenciais. Se a resposta 401 incluir o mesmo pedido de autenticação que a resposta anterior e o navegador já tentou autenticar pelo menos uma vez, o navegador deve mostrar a entidade contida na resposta ao usuário, pois essa entidade pode conter informações de diagnóstico relevantes. Consulte a RFC 2617. |
| 402 |
Este código de status é reservado para possíveis demandas futuras. |
| 403 |
O servidor compreendeu a solicitação mas se recusa a executá-la. Ao contrário da resposta 401, a validação não ajudará, e essa solicitação não deve ser reenviada. Se isso não for uma solicitação HEAD, e o servidor deseja esclarecer o motivo da recusa, deve descrever a razão pelo qual a solicitação foi rejeitada no corpo da entidade. Obviamente, o servidor também pode retornar uma resposta 404 se não desejar que o cliente obtenha qualquer informação. |
| 404 |
A solicitação falhou e o recurso desejado não foi encontrado no servidor. Não há informação que informe ao usuário se essa situação é temporária ou permanente. Se o servidor souber, deve usar o código de status 410 para informar que um recurso antigo não está mais disponível devido a algum problema interno de configuração, e não há endereço para redirecionar. O código de status 404 é amplamente utilizado quando o servidor não deseja revelar o motivo pelo qual a solicitação foi rejeitada ou quando não há outra resposta adequada disponível. |
| 405 |
O método de requisição especificado na linha de requisição não pode ser usado para a solicitação correspondente. Essa resposta deve retornar um cabeçalho Allow para indicar uma lista de métodos de requisição aceitos pelo recurso atual. Devido à natureza dos métodos PUT e DELETE que realizam operações de gravação em recursos no servidor, a grande maioria dos servidores web não suporta ou não permite esses métodos na configuração padrão, retornando um erro 405 para tais requisições. |
| 406 |
As características de conteúdo do recurso solicitado não podem satisfazer as condições nos cabeçalhos da solicitação, então o corpo da resposta não pode ser gerado. A menos que isso seja uma solicitação HEAD, a resposta deve retornar um corpo que contenha uma lista de características de entidade que o usuário ou navegador possa escolher. O formato do corpo é determinado pelo tipo de mídia definido no cabeçalho Content-Type. O navegador pode fazer a melhor escolha automaticamente, com base no formato e nas capacidades do próprio navegador. No entanto, a norma não define qualquer padrão para tal seleção automática. |
| 407 |
Semelhante à resposta 401, exceto que o cliente deve autenticar-se no servidor proxy. O servidor proxy deve retornar um cabeçalho Proxy-Authenticate para solicitar a autenticação. O cliente pode retornar um cabeçalho Proxy-Authorization para autenticação. Consulte a RFC 2617. |
| 408 |
O tempo limite da requisição. O cliente não completou o envio de uma solicitação dentro do tempo que o servidor estava disposto a esperar. O cliente pode reenviar esta solicitação a qualquer momento sem necessidade de mudanças. |
| 409 |
Devido a um conflito com o estado atual do recurso solicitado, a solicitação não pode ser concluída. Este código só deve ser usado em circunstâncias onde se presume que o usuário pode resolver o conflito e reenviar uma nova solicitação. A resposta deve conter informações suficientes para que o usuário descubra a fonte do conflito. Conflitos geralmente ocorrem ao processar solicitações PUT. Por exemplo, em um ambiente de verificação de versões, se a versão informada em um pedido PUT para modificar um recurso específico entra em conflito com um pedido anterior (de um terceiro), o servidor deve retornar um erro 409, informando ao usuário que a solicitação não pode ser concluída. Nesse caso, o corpo da resposta pode conter comparações de diferenças entre as duas versões em conflito para permitir que o usuário reenvie a nova versão mesclada. |
| 410 |
O recurso solicitado não está mais disponível no servidor, e não há nenhum endereço conhecido para redirecionamento. Essa situação deve ser considerada permanente. Se possível, clientes com a capacidade de editar links devem, após obter a permissão do usuário, excluir todas as referências a esse endereço. Se o servidor não souber ou não puder determinar se essa situação é permanente, deve usar o código de status 404. A menos que se indique o contrário, essa resposta é cacheável. A resposta 410 é principalmente destinada a ajudar administradores de sites a manter os sites, e notificar os usuários de que um recurso não está mais disponível, além de que o proprietário do servidor deseja que todas as conexões externas apontando para esse recurso sejam excluídas. Esses eventos são comuns em serviços com prazo ou serviços premium. Da mesma forma, a resposta 410 também é utilizada para informar ao cliente que um recurso que originalmente pertencia a um usuário específico não está mais disponível no site do servidor atual. Obviamente, se todos os recursos permanentemente não disponíveis devem ser marcados como '410 Gone', e quanto tempo essa marca deve ser mantida, cabe ao proprietário do servidor. |
| 411 |
O servidor se recusa a aceitar a solicitação sem um cabeçalho Content-Length definido. O cliente pode reenviar a solicitação após adicionar um cabeçalho Content-Length válido que informe o comprimento da mensagem de solicitação. |
| 412 |
O servidor falhou ao verificar que um ou mais pré-requisitos dados nos cabeçalhos da solicitação foram atendidos. Este código de status permite que o cliente configure pré-requisitos na informação metainformacional (dados dos cabeçalhos da solicitação) para evitar que o método de solicitação seja aplicado a um recurso além do desejado. |
| 413 |
O servidor se recusa a processar a solicitação atual porque o tamanho dos dados da entidade incluídos na solicitação excedem o limite que o servidor está disposto ou capaz de processar. Nesse caso, o servidor pode fechar a conexão para evitar que o cliente continue a enviar essa solicitação. Se essa situação for temporária, o servidor deve retornar um cabeçalho Retry-After na resposta para informar ao cliente quando tentar novamente. |
| 414 |
O comprimento da URI solicitada excede o comprimento que o servidor pode processar, e, portanto, o servidor recusa-se a atender a solicitação. Isso é relativamente raro e pode incluir casos onde um formulário que deveria usar o método POST foi transformado em uma requisição GET, resultando em uma string de consulta excessivamente longa. URI de redirecionamento "blackhole", por exemplo, cada redirecionamento inclui o URI antigo como parte do novo URI, levando a um URI longo após várias redirecionamentos. O cliente está tentando explorar uma vulnerabilidade de segurança em certos servidores. Esses servidores podem utilizar buffers de largura fixa para ler ou manipular a URI da solicitação, e quando os parâmetros após GET excedem um determinado número, podem causar um estouro de buffer, permitindo a execução de código arbitrário[1]. Servidores sem esses tipos de vulnerabilidades devem retornar o código de status 414. |
| 415 |
Para o método atual da solicitação e o recurso solicitado, os dados da entidade incluídos não são em um formato suportado pelo servidor, portanto, a solicitação foi rejeitada. |
| 416 |
Se a solicitação incluir o cabeçalho Range e qualquer intervalo especificado em Range não sobrepor o intervalo disponível atualmente do recurso, enquanto a solicitação não define o cabeçalho If-Range, então o servidor deve retornar o código de status 416. Se Range usar bytes como limite, esta situação ocorre quando todas as posições iniciais dos dados solicitados ultrapassam o comprimento atual do recurso. O servidor deve incluir um cabeçalho de entidade Content-Range ao retornar o código de status 416 para indicar o comprimento atual do recurso. Essa resposta também é proibida de usar multipart/byteranges como seu Content-Type. |
| 417 |
O conteúdo esperado especificado nos cabeçalhos Expect da solicitação não pode ser satisfeito pelo servidor, ou esse servidor é um servidor proxy que possui evidência clara de que no próximo nó na rota atual, o conteúdo Expect não pode ser satisfeito. |
| 421 |
O número de conexões do endereço IP atual do cliente ao servidor excedeu o limite máximo permitido pelo servidor. Geralmente, esse endereço IP refere-se ao endereço do cliente visto pelo servidor (como o gateway ou proxy do usuário). Nesse caso, a contagem de conexões pode envolver mais de um usuário final. |
| 422 |
O formato da solicitação está correto, mas não pode ser respondido devido a erro semântico. (RFC 4918 WebDAV) 423 Locked O recurso atual está bloqueado. (RFC 4918 WebDAV) |
| 424 |
A solicitação falhou devido a um erro prévio que causou o erro na solicitação atual, como em PROPPATCH. (RFC 4918 WebDAV) |
| 425 |
Definido no rascunho do WebDav Advanced Collections, mas não aparece na 'WebDAV Ordered Collections Protocol' (RFC 3658). |
| 426 |
O cliente deve mudar para TLS/1.0. (RFC 2817) |
| 449 |
Expansão da Microsoft, representa que a solicitação deve ser tentada novamente após a execução da manipulação apropriada. |
| 500 |
O servidor encontrou uma condição inesperada que o impediu de concluir o processamento da solicitação. Geralmente, esse problema ocorre quando há um erro no código do servidor. |
| 501 |
O servidor não suporta uma funcionalidade necessária para a solicitação atual. Quando o servidor não reconhece o método de solicitação e não pode suportar solicitações a qualquer recurso. |
| 502 |
Um servidor que atua como um gateway ou proxy recebeu uma resposta inválida ao tentar executar a solicitação a partir do servidor upstream. |
| 503 |
O servidor não pode processar a solicitação no momento devido à manutenção temporária ou sobrecarga. Essa condição é temporária e será restaurada depois de um tempo. Se o tempo de atraso puder ser previsto, a resposta pode incluir um cabeçalho Retry-After indicando esse atraso. Se essa informação Retry-After não for dada, o cliente deve tratar isso como uma resposta 500. Nota: A presença do código 503 não implica que o servidor deve usá-lo quando estiver sobrecarregado. Alguns servidores apenas desejam recusar a conexão do cliente. |
| 504 |
Um servidor que atua como um gateway ou proxy não recebeu uma resposta rápida do servidor upstream (servidor uri identificado, como HTTP, FTP, LDAP) ou do servidor auxiliar (como DNS) ao tentar executar a solicitação. Nota: Alguns servidores proxy retornam erros 400 ou 500 em caso de tempo limite de consulta DNS |
| 505 |
O servidor não suporta ou recusa a suportar a versão HTTP usada na requisiçã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 descreva porque a versão não é suportada e quais protocolos são suportados pelo servidor. |
| 506 |
Estendida pela 'Transparent Content Negotiation Protocol' (RFC 2295), representando que há um erro de configuração interno do servidor: o recurso de negociação solicitado foi configurado para usar a si mesmo na negociação de conteúdo transparente, e portanto não é um foco apropriado dentro de um tratamento de negociação. |
| 507 |
O servidor não pode armazenar o conteúdo necessário para completar a solicitação. Essa situação é considerada temporária. WebDAV (RFC 4918) |
| 509 |
O servidor atingiu o limite de banda. Este não é um código de status oficial, mas ainda é amplamente utilizado. |
| 510 |
As políticas necessárias para obter o recurso não foram atendidas. (RFC 2774) |