A seguir está uma lista de HyperText Transfer Protocol (HTTP) códigos de status resposta. Isso inclui os códigos da IETF padrões de internet, outras especificações e alguns usados ​​códigos adicionais. O primeiro dígito do código de status indica uma das cinco classes de resposta, o mínimo necessário para um cliente HTTP é que ele reconhece essas cinco classes. Microsoft IIS pode usar adicionais decimal sub-códigos específicos para fornecer mais informações, mas estes não estão listadas aqui. As frases utilizadas são os exemplos padrão, mas qualquer legível alternativa humana pode ser fornecido. Salvo disposição em contrário, o código de status é parte do padrão HTTP/1.1.
Solicitação recebida, dando continuidade ao processo. Essa classe de código de status indica uma resposta provisória, constituída apenas do Status-Line e cabeçalhos opcionais, e é encerrado por uma linha vazia. Desde HTTP/1.0 não define todos os códigos de status 1xx, os servidores não deve enviar uma resposta 1xx para um cliente HTTP/1.0, exceto sob condições experimentais.
100 Continuar: Isso significa que o servidor tenha recebido os cabeçalhos da solicitação, e que o cliente deve proceder para enviar o corpo do pedido (no caso de um pedido para que um corpo deve ser enviado, por exemplo, um POST pedido). Se o corpo é grande o pedido, enviando-os para um servidor, quando o pedido já foi rejeitada com base em cabeçalhos inadequado é ineficiente. Para ter um cheque do servidor se o pedido pode ser aceite com base no pedido de cabeçalhos sozinho, o cliente deve enviar Esperar: 100-continue como um cabeçalho no seu pedido inicial e verifique se a 100 Continuar código de status é recebido em resposta antes de permanente (ou receber 417 Falha na expectativa e não continuar).
Isso significa que o solicitante pediu ao servidor para mudar os protocolos e o servidor está reconhecendo que irá fazê-lo. 102 Processamento (WebDAV) (RFC 2518) Como uma solicitação WebDAV pode conter muitos sub-pedidos que envolvam operações de arquivo, pode demorar muito tempo para concluir o pedido. Este código indica que o servidor recebeu e está processando o pedido, mas nenhuma resposta ainda não está disponível. Isso impede que o cliente o tempo limite e supondo que o pedido foi perdido.
Este é um padrão IE7 somente código não significa que o URI é mais do que um máximo de 2083 caracteres. (Ver código 414).
Padrão de resposta para solicitações HTTP sucesso. A resposta real dependerá do método de solicitação usado. Em uma solicitação GET, a resposta conterá uma entidade que corresponde ao recurso solicitado. Em uma solicitação POST a resposta conterá a descrição de uma entidade, ou contendo o resultado da ação.
O pedido foi aceite para processamento, mas o tratamento não foi concluído. O pedido poderá ou não vir a ser posta em prática, pois pode ser anulado quando o processamento ocorre realmente.
O cliente deve tomar medidas adicionais para completar o pedido. Essa classe de código de status indica que a ação ainda precisa ser levado pelo agente do usuário, a fim de atender à solicitação. A ação necessária pode ser realizada pelo agente, sem interação com o usuário, se e somente se o método utilizado no segundo pedido é GET ou HEAD. Um agente do usuário não deve redirecionar automaticamente uma solicitação de mais de cinco vezes, desde que tais redirecionamentos geralmente indicam um loop infinito .
Este é um exemplo de boas práticas industriais contradizendo a norma. especificação HTTP/1.0 (RFC 1945) exigiu o cliente para executar um redirecionamento temporário (o que descreve frase original era “Movido Temporariamente”), mas os browsers populares executadas 302 com a funcionalidade de um 303 Consulte Outros. Por isso, acrescentou HTTP/1.1 códigos de status 303 e 307 a distinguir entre os dois comportamentos. No entanto, a maioria das aplicações Web e os quadros ainda usam o código de status 302 como se fosse o 303.
Indica que o recurso não foi modificado desde o último pedido. Normalmente, o cliente fornece um cabeçalho HTTP como o Se-Modificado-Desde cabeçalho para proporcionar um tempo contra o qual para comparar. Usando este poupa largura de banda e de reprocessamento no servidor e cliente, uma vez que apenas os dados do cabeçalho devem ser enviados e recebidos em comparação com a totalidade da página que está sendo reprocessados ​​pelo servidor, em seguida, enviado novamente utilizando mais largura de banda do servidor e cliente .
Nesta ocasião, o pedido deve ser repetido com outro URI, mas futuras solicitações ainda pode usar a URI original. Em contraste com a 303, o método de pedido não deve ser mudado quando a reedição do pedido original. Por exemplo, uma solicitação POST deve ser repetido com outro pedido POST.
Semelhante ao 403 Forbidden, mas especificamente para o uso quando a autenticação é possível, mas não conseguiu ou ainda não foram fornecidos. A resposta deve incluir um cabeçalho do campo Authenticate-WWW contendo um desafio aplicável ao recurso solicitado. Veja Basic autenticação de acesso e autenticação Digest acesso .
Reservado para uso futuro. A intenção original era que esse código pode ser usado como parte de alguma forma de dinheiro digital ou de micropagamento regime, mas isso não aconteceu, e esse código não é usado normalmente. Como exemplo de seu uso, no entanto, da Apple, o MobileMe serviço gera um erro 402 (“HttpStatusCode: 402” no Mac OS X log do console) se a conta MobileMe é delinquente.
O pedido foi um pedido legal, mas o servidor está recusando a responder a ela. Ao contrário de um Unauthorized 401 resposta, autenticação não fará diferença.
Foi feita uma solicitação de um recurso usando um método de pedido não é compatível com esse recurso, por exemplo, usando GET em um formulário, que exige que os dados a serem apresentados via POST, PUT ou usar em um recurso somente de leitura.
O servidor sofreu timeout ao aguardar a solicitação. De acordo com as especificações HTTP W3: “O cliente não apresentar um pedido dentro do tempo que o servidor estava preparado para esperar o tempo. O cliente pode repetir o pedido, sem modificações na tarde qualquer. ”