Ferramentas on-line
Códigos 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 notificará o cliente por meio do cabeçalho Upgrade de que um protocolo diferente foi usado para concluir a solicitação. Depois de enviar a última linha em branco da resposta, o servidor mudará para os protocolos definidos no cabeçalho Upgrade. Isso só deve ser feito se for mais vantajoso mudar para o novo protocolo. Por exemplo, a mudança para uma nova versão do HTTP pode ser mais vantajosa do que uma versão mais antiga, ou a mudança para um protocolo síncrono e em tempo real para fornecer recursos que aproveitem esses recursos.
102 Os códigos de status, ampliados pelo WebDAV (RFC 2518), indicam que o processamento continuará.
200 A solicitação foi bem-sucedida, e os cabeçalhos de resposta ou o corpo de dados desejado pela solicitação serão retornados com a resposta.
201 A solicitação foi atendida e um novo recurso foi criado em resposta à solicitação, e seu URI foi retornado com o cabeçalho Location. Se o recurso solicitado não puder ser criado a tempo, deverá ser retornado o seguinte'202 Accepted'。
202 O servidor aceitou a solicitação, mas ainda não a processou. Assim como pode ser rejeitada, a solicitação pode ou não ser executada eventualmente. No caso 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 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 que o cliente tenha que manter uma conexão com o servidor até que a operação em lote seja concluída. Uma resposta que aceita uma solicitação de processamento e retorna um código de status 202 deve incluir na entidade retornada algumas informações que indiquem o status 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 ou não.
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 do original. Por exemplo, os metadados que contêm recursos podem fazer com que o servidor de origem conheça as superinformações 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 metainformaçõ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 as metainformações novas ou atualizadas DEVEM, de acordo com a especificação, 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 processa a solicitação com êxito e não retorna 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 arquivo grande em vários downloads 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 ou, no caso de downloads de várias partes com um Content-Type de multipart/byteranges, um campo Content-Range em cada segmento de várias partes para indicar o 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. Expires, Cache-Control e/ou Vary, se seus valores puderem ser diferentes dos valores de outras respostas anteriores com as mesmas variáveis. Essa resposta não deve conter outros cabeçalhos de entidade se a solicitação usar validação de cache If-Range forte e não deve conter outros cabeçalhos de entidade se a solicitação usar validação de cache If-Range fraca; 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 na resposta 200. Se os cabeçalhos ETag ou Last-Modified não corresponderem exatamente, o cache do lado do cliente não deverá permitir 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 Códigos de status estendidos pelo WebDAV(RFC 2518) O código de status, conforme estendido pelo WebDAV, 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 sub-solicitações anteriores.
300 O recurso solicitado tem uma série de respostas alternativas, cada uma com seu próprio endereço específico e informações de negociação orientadas pelo navegador. Cabe ao usuário ou ao navegador escolher um endereço preferencial para redirecionamento. 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 seleção automática deve ser feita. Se o próprio servidor já tiver uma opção de retorno preferencial, o URI do retorno deverá ser especificado no Location; os navegadores poderão usar esse valor de Location como endereço para redirecionamento automático. Além disso, a resposta é armazenável em cache, a menos que especificado de outra forma.
301 O recurso solicitado foi movido permanentemente para 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 se trate de 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: 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á 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. A resposta pode ser armazenada em cache somente 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 durante o 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 de substituição do recurso original. Além disso, não é permitido que a resposta 303 seja 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 ao HTTP/1.1 não entendem corretamente o estado 303. Se a interação com esses navegadores precisar ser considerada, o código de status 302 deverá funcionar, 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 Esse código de status deve ser retornado pelo servidor se o cliente enviar uma solicitação GET condicional e a solicitação for permitida, e o conteúdo do documento não tiver sido alterado (desde a última visita ou de acordo com as condições da solicitação). A resposta deve conter as seguintes informações de cabeçalho: 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 deveria ter retornado uma resposta 200. Expires, Cache-Control e/ou Vary, se seus valores puderem ser diferentes dos valores de outras respostas anteriores com as mesmas variáveis. Se a solicitação de resposta usar validação de cache forte, a resposta não deverá conter cabeçalhos de entidade adicionais; caso contrário (por exemplo, uma solicitação GET condicional usa validação de cache fraca), a resposta não poderá conter cabeçalhos de entidade adicionais; 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 toda a entrada 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 campo Location fornecerá informações sobre o URI do proxy especificado, e o destinatário precisará 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 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 Os recursos solicitados agora respondem temporariamente a solicitações de URIs diferentes. Como esse redirecionamento é temporário, 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, é necessário adicionar as informações acima 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, erro semântico, a solicitação atual não pode ser compreendida pelo servidor. A menos que seja modificada, o cliente não deve repetir a solicitação. 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 reenviar uma solicitação com as informações apropriadas do cabeçalho Authorisation. Se a solicitação atual já contiver credenciais de autorização, uma resposta 401 significa que o servidor verifica se essas credenciais foram rejeitadas. Se a resposta 401 contiver a mesma consulta de autenticação que a resposta anterior e o navegador já tiver feito pelo menos uma tentativa de autenticação, o navegador deverá mostrar 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 a solicitação não deve ser reenviada. Se não se tratar de uma solicitação HEAD e o servidor quiser poder dizer por que a solicitação não pode ser executada, o motivo da recusa deve ser descrito na entidade. Obviamente, 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 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 servidor 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 quer 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 os suporta ou 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 endereços da qual o usuário ou o navegador possa selecionar as características de entidade mais adequadas. O formato da entidade é determinado pelo tipo de mídia definido no cabeçalho Content-Type. O navegador pode fazer a melhor escolha 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-Authorisation para autenticação. Consulte a RFC 2617.
408 Tempo limite da solicitação. O cliente não concluiu 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. Os conflitos geralmente ocorrem no processamento de solicitações PUT. Por exemplo, em um ambiente de verificação de versão, uma PUT enviada para modificar um determinado recurso com informações de versão que entrem em conflito com uma solicitação anterior (de terceiros) deve 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 mesclada.
410 O recurso solicitado não está mais disponível no servidor e não há endereço de encaminhamento conhecido. Essa situaçã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 a condição é permanente, deverá ser usado um código de status 404. A menos que especificado de outra forma, essa resposta pode ser armazenada em cache. A finalidade da resposta 410 é 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 o recurso também sejam excluídas. Esse tipo de evento é comum em serviços de valor agregado e com tempo limitado. Da mesma forma, a resposta 410 é usada para notificar o cliente de que um recurso pertencente a um indivíduo não está mais disponível no site do servidor atual. Obviamente, a questão de saber se todos os recursos permanentemente indisponíveis precisam ser marcados como tal e por quanto tempo precisam ser mantidos dessa forma também é importante.'410 Gone'， A marcação e o tempo em que ela deve ser mantida dependem inteiramente do proprietário do servidor.
411 O servidor se recusa a aceitar solicitações sem o cabeçalho Content-Length definido. O cliente pode reenviar a solicitação depois de adicionar um cabeçalho Content-Length válido indicando o tamanho do corpo da mensagem da solicitação.
412 O servidor não conseguiu atender a um ou mais dos pré-requisitos fornecidos no campo de cabeçalho da solicitação ao validá-la. Esse código de status permite que o cliente defina pré-condições nas meta-informações da solicitação (dados do campo do 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 mais dados físicos do que o servidor deseja ou pode processar. Nesse caso, o servidor pode fechar a conexão para impedir que o cliente continue a enviar a solicitação. Se a situação for temporária, o servidor deverá retornar um cabeçalho Retry-After para informar ao cliente quanto tempo ele tem para tentar novamente.
414 O URI da solicitação é mais longo do que o servidor pode interpretar, portanto o servidor se recusa a atender à solicitação. Isso é raro e geralmente ocorre quando um envio de 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 para 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 solicitado, o que pode resultar em um estouro de buffer quando o parâmetro GET excede um determinado valor, 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 suportado pelo servidor e a solicitação é rejeitada.
416 Se a solicitação contiver um cabeçalho de solicitação Range, e qualquer intervalo de dados especificado no Range não coincidir com os intervalos disponíveis para o recurso atual, e a solicitação não definir um cabeçalho de solicitação If-Range, o servidor deverá retornar um código de status 416. Se o Range usar intervalos de bytes, isso significa que o primeiro 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 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 o 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 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, mais de um usuário final pode estar envolvido na contagem de conexões.
422 O número de conexões do endereço IP do cliente atual com o servidor 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, mais de um usuário final pode estar envolvido na contagem de conexões.
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) 423 Bloqueado
424 A solicitação atual falhou devido a um erro 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 exigido pela solicitação atual. Quando o servidor não reconhece o método solicitado e não pode 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 um período de 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 querem negar uma conexão ao cliente.
504 Um servidor atuando como gateway ou proxy que tenta executar uma solicitação não recebe uma resposta oportuna 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 de 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 atender à 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 foi atendida. (RFC 2774)
Acesso aos registros: