Headers HTTP – Cabeçalhos HTTP do Servidor

A parte inicial de uma solicitação foi recebida e ainda não foi rejeitada pelo servidor. O servidor pretende enviar uma resposta final depois que a solicitação for totalmente recebida e posta em prática.

Quando a solicitação contém um campo de cabeçalho Expect que inclui uma expectativa de continuação 100, a resposta 100 indica que o servidor deseja receber o corpo1 da carga útil da solicitação. O cliente deve continuar enviando a solicitação e descartar a resposta 100.

Se a solicitação não continha um campo de cabeçalho Expect contendo a expectativa de continuação de 100, o cliente pode simplesmente descartar essa resposta provisória.

O servidor entende e está disposto a atender a solicitação do cliente, através do campo 1 do cabeçalho de atualização, de alteração do protocolo de aplicação utilizado nesta conexão.

O servidor DEVE gerar um campo de cabeçalho de atualização na resposta que indica qual (is) protocolo (s) será (ão) alterado (s) imediatamente após a linha vazia que encerra a 101 resposta.

Presume-se que o servidor somente concordará em trocar de protocolo quando for vantajoso fazê-lo. Por exemplo, mudar para uma versão mais recente do HTTP pode ser vantajoso em relação às versões mais antigas, e mudar para um protocolo síncrono em tempo real pode ser vantajoso ao fornecer recursos que usam esses recursos.

Uma resposta provisória usada para informar ao cliente que o servidor aceitou a solicitação completa, mas ainda não a concluiu.

Este código de status DEVE ser enviado apenas quando o servidor tiver uma expectativa razoável de que a solicitação levará um tempo significativo para ser concluída. Como orientação, se um método está levando mais de 20 segundos (um valor razoável, mas arbitrário) para processar, o servidor DEVE retornar uma resposta 102 (Processamento). O servidor DEVE enviar uma resposta final após a conclusão da solicitação.

Os métodos podem levar potencialmente um longo período de tempo para serem processados, especialmente os métodos que suportam o cabeçalho Depth. Nesses casos, o cliente pode expirar a conexão enquanto espera por uma resposta. Para evitar isso, o servidor pode retornar um código de status 102 Processing para indicar ao cliente que o servidor ainda está processando o método.

A solicitação foi bem-sucedida.

A carga útil enviada em uma resposta 200 depende do método de solicitação. Para os métodos definidos por esta especificação, o significado pretendido da carga útil pode ser resumido como:

• GET uma representação do recurso de destino
• HEAD a mesma representação de GET, mas sem os dados de representação
• POST uma representação do status ou resultados obtidos da ação;
  • PUT DELETE uma representação do status da ação;
  • OPTIONS uma representação das opções de comunicação;
  • TRACE uma representação da mensagem de solicitação recebida pelo servidor final.

Além das respostas para CONNECT, uma resposta 200 sempre tem uma carga útil, embora um servidor de origem PODE gerar um corpo de carga útil de comprimento zero. Se nenhuma carga for desejada, um servidor de origem deve enviar 204 Sem conteúdo em seu lugar. Para CONNECT, nenhuma carga útil é permitida porque o resultado bem-sucedido é um túnel, que começa imediatamente após a seção de cabeçalho de 200 respostas.

Uma resposta 200 pode ser armazenada em cache por padrão; ou seja, a menos que indicado de outra forma pela definição do método ou controles de cache explícitos.

A solicitação foi atendida e resultou na criação de um ou mais novos recursos.

O recurso principal criado pela solicitação é identificado por um campo de cabeçalho Location na resposta ou, se nenhum campo Location for recebido, pelo URI de solicitação efetiva.

A carga útil da resposta 201 normalmente descreve e vincula os recursos criados. Consulte a Seção 7.2 do RFC7231 para uma discussão sobre o significado e a finalidade dos campos de cabeçalho do validador, como ETag e Última modificação, em uma resposta 201.

A solicitação foi aceita para processamento, mas o processamento não foi concluído. A solicitação pode ou não ser executada, pois pode ser desautorizada quando o processamento realmente ocorrer.

Não há facilidade em HTTP para reenviar um código de status de uma operação assíncrona.

A resposta 202 é intencionalmente evasiva. Sua finalidade é permitir que um servidor aceite uma solicitação para algum outro processo (talvez um processo orientado a lote que é executado apenas uma vez por dia) sem exigir que a conexão do agente do usuário com o servidor persista até que o processo seja concluído. A representação enviada com esta resposta deve descrever o status atual da solicitação e apontar para (ou incorporar) um monitor de status que pode fornecer ao usuário uma estimativa de quando a solicitação será atendida.

A solicitação foi bem-sucedida, mas a carga útil incluída foi modificada da resposta 200 OK do servidor de origem por um proxy em transformação.

Este código de status permite que o proxy notifique os destinatários quando uma transformação foi aplicada, uma vez que esse conhecimento pode afetar decisões posteriores sobre o conteúdo. Por exemplo, solicitações futuras de validação de cache para o conteúdo podem ser aplicáveis ​​apenas ao longo do mesmo caminho de solicitação (por meio dos mesmos proxies).

A resposta 203 é semelhante ao código de Aviso de 214 Transformação Aplicada, que tem a vantagem de ser aplicável a respostas com qualquer código de status.

Uma resposta 203 pode ser armazenada em cache por padrão; ou seja, a menos que indicado de outra forma pela definição do método ou controles de cache explícitos.

O servidor atendeu à solicitação com êxito e não há conteúdo adicional a ser enviado no corpo da carga de resposta.

Os metadados nos campos do cabeçalho da resposta referem-se ao recurso de destino e sua representação selecionada após a aplicação da ação solicitada.

Por exemplo, se um código de status 204 for recebido em resposta a uma solicitação PUT e a resposta contiver um campo de cabeçalho ETag, então o PUT foi bem-sucedido e o valor do campo ETag contém a tag de entidade para a nova representação desse recurso de destino.

A resposta 204 permite que um servidor indique que a ação foi aplicada com sucesso ao recurso de destino, ao mesmo tempo que sugere que o agente do usuário não precisa se afastar de sua "visualização do documento" atual (se houver). O servidor assume que o agente do usuário fornecerá alguma indicação do sucesso ao seu usuário, de acordo com sua própria interface, e aplicará quaisquer metadados novos ou atualizados na resposta à sua representação ativa.

Por exemplo, um código de status 204 é comumente usado com interfaces de edição de documentos correspondendo a uma ação "salvar", de forma que o documento sendo salvo permaneça disponível para o usuário para edição. Também é freqüentemente usado com interfaces que esperam que as transferências de dados automatizadas sejam predominantes, como em sistemas de controle de versão distribuídos.

Uma resposta 204 é encerrada pela primeira linha vazia após os campos de cabeçalho porque não pode conter um corpo de mensagem.

Uma resposta 204 pode ser armazenada em cache por padrão; ou seja, a menos que indicado de outra forma pela definição do método ou controles de cache explícitos.

O servidor atendeu à solicitação e deseja que o agente do usuário redefina a "visualização do documento", que causou o envio da solicitação, ao estado original recebido do servidor de origem.

Esta resposta destina-se a oferecer suporte a um caso de uso comum de entrada de dados em que o usuário recebe conteúdo que suporta a entrada de dados (um formulário, bloco de notas, tela, etc.), insere ou manipula dados nesse espaço, faz com que os dados inseridos sejam enviados em um pedido e, em seguida, o mecanismo de entrada de dados é redefinido para a próxima entrada para que o usuário possa facilmente iniciar outra ação de entrada.

Visto que o código de status 205 implica que nenhum conteúdo adicional será fornecido, um servidor NÃO DEVE gerar uma carga útil em uma resposta 205. Em outras palavras, um servidor DEVE fazer um dos seguintes para uma resposta 205: a) indicar um corpo de comprimento zero para a resposta, incluindo um campo de cabeçalho Content-Length com um valor de 0; b) indicar uma carga útil de comprimento zero para a resposta, incluindo um campo de cabeçalho Transfer-Encoding com um valor de chunked e um corpo de mensagem consistindo em um único chunk de comprimento zero; ou, c) feche a conexão imediatamente após enviar a linha em branco encerrando a seção do cabeçalho.

O servidor está atendendo com êxito uma solicitação de intervalo para o recurso de destino, transferindo uma ou mais partes da representação selecionada que correspondem aos intervalos satisfatórios encontrados no campo de cabeçalho Intervalo da solicitação.

Se uma única parte estiver sendo transferida, o servidor que está gerando a resposta 206 DEVE gerar um campo de cabeçalho Content-Range, descrevendo qual intervalo da representação selecionada está incluído, e uma carga útil consistindo do intervalo. Por exemplo:

HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Range: bytes 21010-47021/47022
Content-Length: 26012
Content-Type: image/gif

... 26012 bytes of partial image data ...

Se várias partes estão sendo transferidas, o servidor que gera a resposta 206 DEVE gerar uma carga útil "multipart / byteranges" e um campo de cabeçalho Content-Type contendo o tipo de mídia multipart / byteranges e seu parâmetro de limite obrigatório. Para evitar confusão com respostas de parte única, um servidor NÃO DEVE gerar um campo de cabeçalho Content-Range no cabeçalho HTTP seção de uma resposta de parte múltipla (este campo será enviado em cada parte).

Dentro da área do cabeçalho de cada parte do corpo na carga útil multipartes, o servidor DEVE gerar um campo de cabeçalho Content-Range correspondente ao intervalo que está sendo encerrado nessa parte do corpo. Se a representação selecionada tivesse um campo de cabeçalho Content-Type em uma resposta 200 OK, o servidor DEVERIA gerar esse mesmo campo Content-Type na área do cabeçalho de cada parte do corpo. Por exemplo:

HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Length: 1741
Content-Type: multipart/byteranges;
boundary=THIS_STRING_SEPARATES

--THIS_STRING_SEPARATES
Content-Type: application/pdf
Content-Range: bytes 500-999/8000

...the first range...
--THIS_STRING_SEPARATES
Content-Type: application/pdf
Content-Range: bytes 7000-7999/8000

...the second range
--THIS_STRING_SEPARATES--

Quando vários intervalos são solicitados, um servidor PODE unir qualquer um dos intervalos que se sobrepõem, ou que são separados por uma lacuna que é menor do que a sobrecarga de envio de várias partes, independentemente da ordem em que a especificação de intervalo de bytes correspondente apareceu em o campo de cabeçalho de intervalo recebido. Uma vez que a sobrecarga típica entre as partes de uma carga útil multipart / byteranges é de cerca de 80 bytes, dependendo do tipo de mídia da representação selecionada e do comprimento do parâmetro de limite escolhido, pode ser menos eficiente transferir muitas pequenas partes disjuntas do que transferir todo o selecionado representação.

Um servidor NÃO DEVE gerar uma resposta multiparte para uma solicitação de um único intervalo, uma vez que um cliente que não solicita várias partes pode não suportar respostas multipartes. No entanto, um servidor PODE gerar uma carga útil multipart / byteranges com apenas uma única parte do corpo se vários intervalos forem solicitados e apenas um intervalo for considerado satisfatório ou apenas um intervalo permanecer após a coalescência. Um cliente que não consegue processar uma resposta multipart / byteranges NÃO DEVE gerar uma solicitação que solicite vários intervalos.

Quando uma carga útil de resposta multipartes é gerada, o servidor DEVE enviar as partes na mesma ordem em que a especificação de intervalo de bytes correspondente apareceu no campo de cabeçalho de intervalo recebido, excluindo aqueles intervalos que foram considerados insatisfatórios ou que foram agrupados em outros gamas. Um cliente que recebe uma resposta multiparte DEVE inspecionar o campo de cabeçalho Content-Range presente em cada parte do corpo, a fim de determinar qual intervalo está contido nessa parte do corpo; um cliente não pode contar com o recebimento dos mesmos intervalos que solicitou, nem do mesmo pedido que solicitou.

Quando uma resposta 206 é gerada, o servidor DEVE gerar os seguintes campos de cabeçalho, além dos exigidos acima, se o campo teria sido enviado em uma resposta 200 OK para a mesma solicitação: Data, Cache-Control, ETag , Expira, local do conteúdo e varia.

Se um 206 é gerado em resposta a uma solicitação com um campo de cabeçalho If-Range, o remetente NÃO DEVE gerar outros campos de cabeçalho de representação além dos exigidos acima, porque o cliente é entendido como já tendo uma resposta anterior contendo esses campos de cabeçalho . Caso contrário, o remetente DEVE gerar todos os campos de cabeçalho de representação que teriam sido enviados em uma resposta 200 OK para a mesma solicitação.

Uma resposta 206 pode ser armazenada em cache por padrão; ou seja, a menos que indicado de outra forma por controles de cache explícitos.

Uma resposta Multi-Status transmite informações sobre vários recursos em situações em que vários códigos de status podem ser apropriados.

O corpo de resposta Multi-Status padrão é uma entidade HTTP text / xml ou application / xml com um elemento raiz 'multistatus'. Outros elementos contêm códigos de status de séries 200, 300, 400 e 500 gerados durante a invocação do método. Os códigos de status da série 100 NÃO DEVEM ser registrados em um elemento XML de 'resposta'.

Embora '207' seja usado como o código de status de resposta geral, o destinatário precisa consultar o conteúdo do corpo de resposta de multistatus para obter mais informações sobre o sucesso ou falha da execução do método. A resposta PODE ser usada em casos de sucesso, sucesso parcial e também em situações de falha.

O elemento raiz 'multistatus' contém zero ou mais elementos de 'resposta' em qualquer ordem, cada um com informações sobre um recurso individual. Cada elemento de 'resposta' DEVE ter um elemento 'href' para identificar o recurso.

Uma resposta Multi-Status usa um dos dois formatos distintos para representar o status:

1. Um elemento 'status' como filho do elemento 'resposta' indica o status da execução da mensagem para o recurso identificado como um todo1. Algumas definições de método fornecem informações sobre códigos de status específicos que os clientes devem estar preparados para ver em uma resposta. No entanto, os clientes DEVEM ser capazes de lidar com outros códigos de status, usando as regras genéricas definidas na RFC2616 Seção 10.

2. Para PROPFIND e PROPPATCH, o formato foi estendido usando o elemento 'propstat' em vez de 'status', fornecendo informações sobre propriedades individuais de um recurso. Este formato é específico para PROPFIND e PROPPATCH e é descrito em detalhes na RFC4918 Seção 9.1 e RFC4918 Seção 9.2.

Usado dentro de um elemento de resposta DAV: propstat para evitar enumerar os membros internos de várias ligações para a mesma coleção repetidamente.

Para cada associação a uma coleção dentro do escopo da solicitação, apenas uma será relatada com um status 200, enquanto os elementos DAV: response subsequentes para todas as outras associações usarão o status 208 e nenhum elemento DAV: response para seus descendentes será incluído.

Observe que o status 208 ocorrerá apenas para solicitações "Profundidade: infinito" e que é de particular importância quando as várias ligações de coleção causam um loop de ligação.

Um cliente pode solicitar a propriedade DAV: resource-id em uma solicitação PROPFIND para garantir que ele possa reconstruir com precisão a estrutura de ligação de uma coleção com várias ligações para um único recurso.

Para compatibilidade com clientes que não estão cientes do código de status 208 que aparece em corpos de resposta multistatus, ele NÃO DEVE ser usado, a menos que o cliente tenha sinalizado o suporte para esta especificação usando o cabeçalho de solicitação "DAV". Em vez disso, um status 508 Loop Detected deve ser retornado quando um loop de ligação é descoberto. Isso permite que o servidor retorne o 508 como o status de retorno de nível superior, se o descobrir antes de iniciar a resposta, ou no meio de um multistatus, se o descobrir no meio do fluxo de uma resposta multistatus.

O servidor atendeu a uma solicitação GET para o recurso e a resposta é uma representação do resultado de uma ou mais manipulações de instância aplicadas à instância atual.

A instância atual real pode não estar disponível, exceto combinando esta resposta com outras respostas anteriores ou futuras, conforme apropriado para a (s) manipulação (ões) de instância específica (s). Nesse caso, os cabeçalhos da instância resultante são o resultado da combinação dos cabeçalhos da resposta 226 e das outras instâncias, seguindo as regras da seção 13.5.3 da especificação HTTP / 1.1.

O pedido DEVE ter incluído um campo de cabeçalho A-IM listando pelo menos uma instância de manipulação. A resposta DEVE incluir um campo de cabeçalho Etag fornecendo a tag de entidade da instância atual.

Uma resposta recebida com um código de status 226 PODE ser armazenada por um cache e usada em resposta a uma solicitação subsequente, sujeita ao mecanismo de expiração de HTTP e quaisquer cabeçalhos Cache-Control e aos requisitos da seção 10.6.

Uma resposta recebida com um código de status 226 PODE ser usada por um cache, em conjunto com uma entrada de cache para a instância base, para criar uma entrada de cache para a instância atual.

O recurso de destino tem mais de uma representação, cada uma com seu próprio identificador mais específico, e informações sobre as alternativas estão sendo fornecidas para que o usuário (ou agente do usuário) possa selecionar uma representação preferida redirecionando sua solicitação para um ou mais desses identificadores .

Em outras palavras, o servidor deseja que o agente do usuário se envolva em uma negociação reativa para selecionar a (s) representação (ões) mais apropriada (s) para suas necessidades.

Se o servidor tiver uma escolha preferida, o servidor DEVE gerar um campo de cabeçalho Location contendo uma referência de URI de escolha preferencial. O agente do usuário PODE usar o valor do campo Localização para redirecionamento automático.

Para métodos de solicitação diferentes do HEAD, o servidor DEVE gerar uma carga útil na resposta 300 contendo uma lista de metadados de representação e referência (s) URI a partir da qual o usuário ou agente do usuário pode escolher o mais preferido. O agente do usuário PODE fazer uma seleção dessa lista automaticamente se entender o tipo de mídia fornecido. Um formato específico para seleção automática não é definido por esta especificação porque o HTTP tenta permanecer ortogonal à definição de suas cargas úteis. Na prática, a representação é fornecida em algum formato facilmente analisado que se acredita ser aceitável para o agente do usuário, conforme determinado pelo design compartilhado ou negociação de conteúdo, ou em algum formato de hipertexto comumente aceito.

Uma resposta 300 pode ser armazenada em cache por padrão; ou seja, a menos que indicado de outra forma pela definição do método ou controles de cache explícitos.

Nota: A proposta original para o código de status 300 definiu o campo de cabeçalho URI como fornecendo uma lista de representações alternativas, de modo que seria utilizável para 200, 300 e 406 respostas e ser transferido em respostas para o método HEAD. No entanto, a falta de implantação e desacordo sobre a sintaxe levou a URI e Alternates (uma proposta subsequente) sendo retirados desta especificação. É possível comunicar a lista usando um conjunto de campos de cabeçalho de Link, cada um com uma relação de "alternativo", embora a implantação seja um problema do ovo e da galinha.

O recurso de destino foi atribuído a um novo URI permanente e quaisquer referências futuras a este recurso devem usar um dos URIs incluídos.

Os clientes com recursos de edição de link devem vincular novamente as referências ao URI de solicitação efetivo a uma ou mais das novas referências enviadas pelo servidor, quando possível.

O servidor DEVE gerar um campo de cabeçalho Location na resposta contendo uma referência URI preferencial para o novo URI permanente. O agente do usuário PODE usar o valor do campo Localização para redirecionamento automático. A carga útil de resposta do servidor geralmente contém uma pequena nota de hipertexto com um hiperlink para o (s) novo (s) URI (s).

Nota: Por razões históricas, um agente do usuário PODE alterar o método de solicitação de POST para GET para a solicitação subsequente. Se esse comportamento for indesejado, o código de status 307 Redirecionamento temporário pode ser usado em seu lugar.

Uma resposta 301 pode ser armazenada em cache por padrão; ou seja, a menos que indicado de outra forma pela definição do método ou controles de cache explícitos.

O recurso de destino reside temporariamente em um URI diferente. Como o redirecionamento pode ser alterado ocasionalmente, o cliente deve continuar a usar o URI de solicitação efetivo para solicitações futuras.

O servidor DEVE gerar um campo de cabeçalho Location na resposta contendo uma referência de URI para os diferentes URI. O agente do usuário PODE usar o valor do campo Localização para redirecionamento automático. A carga útil de resposta do servidor geralmente contém uma pequena nota de hipertexto com um hiperlink para os diferentes URIs.

Nota: Por razões históricas, um agente do usuário PODE alterar o método de solicitação de POST para GET para a solicitação subsequente. Se esse comportamento for indesejado, o código de status 307 Redirecionamento temporário pode ser usado em seu lugar.

O servidor está redirecionando o agente do usuário para um recurso diferente, conforme indicado por um URI no campo de cabeçalho Local, que se destina a fornecer uma resposta indireta à solicitação original.

Um agente de usuário pode executar uma solicitação de recuperação direcionada a esse URI (uma solicitação GET ou HEAD se estiver usando HTTP), que também pode ser redirecionado e apresentar o resultado eventual como uma resposta à solicitação original. Observe que o novo URI no campo de cabeçalho Location não é considerado equivalente ao URI de solicitação efetiva.

Este código de status é aplicável a qualquer método HTTP. É usado principalmente para permitir a saída de uma ação POST para redirecionar o agente do usuário para um recurso selecionado, uma vez que isso fornece as informações correspondentes à resposta POST em uma forma que pode ser identificada separadamente, marcada e armazenada em cache, independentemente do pedido original.

Uma resposta 303 a uma solicitação GET indica que o servidor de origem não tem uma representação do recurso de destino que pode ser transferido pelo servidor por HTTP. No entanto, o valor do campo Local se refere a um recurso que é descritivo do recurso de destino, de forma que fazer uma solicitação de recuperação nesse outro recurso pode resultar em uma representação útil para os destinatários, sem implicar que representa o recurso de destino original. Observe que as respostas às perguntas sobre o que pode ser representado, quais representações são adequadas e o que pode ser uma descrição útil estão fora do escopo do HTTP.

Exceto para respostas a uma solicitação HEAD, a representação de uma resposta 303 deve conter uma nota de hipertexto curta com um hiperlink para a mesma referência de URI fornecida no campo de cabeçalho Localização.

Uma solicitação GET ou HEAD condicional foi recebida e teria resultado em uma resposta 200 OK se não fosse pelo fato de que a condição foi avaliada como falsa.

Em outras palavras, não há necessidade de o servidor transferir uma representação do recurso de destino porque a solicitação indica que o cliente, que tornou a solicitação condicional, já possui uma representação válida; o servidor está, portanto, redirecionando o cliente para fazer uso dessa representação armazenada como se fosse a carga de uma resposta 200 OK.

O servidor que gera uma resposta 304 DEVE gerar qualquer um dos seguintes campos de cabeçalho que teriam sido enviados em uma resposta 200 OK para a mesma solicitação: Cache-Control, Content-Location, Date, ETag, Expires e Vary.

Uma vez que o objetivo de uma resposta 304 é minimizar a transferência de informações quando o destinatário já tem uma ou mais representações em cache, um remetente NÃO DEVE gerar metadados de representação além dos campos listados acima, a menos que esses metadados existam com o propósito de orientar as atualizações de cache (por exemplo, Última modificação pode ser útil se a resposta não tiver um campo ETag).

Os requisitos em um cache que recebe uma resposta 304 são definidos na Seção 4.3.4 do RFC7234. Se o pedido condicional foi originado de um cliente de saída, como um agente de usuário com seu próprio cache enviando um GET condicional para um proxy compartilhado, o proxy DEVERIA encaminhar a 304 resposta a esse cliente.

Uma resposta 304 não pode conter um corpo de mensagem; ele sempre termina com a primeira linha vazia após os campos do cabeçalho.

Definido em uma versão anterior desta especificação e agora está obsoleto, devido a questões de segurança relacionadas à configuração dentro da banda de um proxy.

O recurso de destino reside temporariamente em um URI diferente e o agente do usuário NÃO DEVE alterar o método de solicitação se executar um redirecionamento automático para esse URI.

Como o redirecionamento pode mudar com o tempo, o cliente deve continuar usando o URI de solicitação efetiva original para solicitações futuras.

O servidor DEVE gerar um campo de cabeçalho Location na resposta contendo uma referência de URI para os diferentes URI. O agente do usuário PODE usar o valor do campo Localização para redirecionamento automático. A carga útil de resposta do servidor geralmente contém uma pequena nota de hipertexto com um hiperlink para os diferentes URIs.

Nota: Este código de status é semelhante a 302 Found, exceto que não permite alterar o método de solicitação de POST para GET. Esta especificação não define nenhuma contrapartida equivalente para 301 Moved Permanently (RFC7238, no entanto, propõe a definição do código de status 308 Redirecionamento Permanente para este fim).

O recurso de destino foi atribuído a um novo URI permanente e quaisquer referências futuras a este recurso devem usar um dos URIs incluídos.

Os clientes com recursos de edição de link devem vincular novamente as referências ao URI1 de solicitação efetiva a uma ou mais das novas referências enviadas pelo servidor, quando possível.

O servidor DEVE gerar um cabeçalho de localização field2 na resposta contendo uma referência URI preferencial para o novo URI permanente. O agente do usuário PODE usar o valor do campo Localização para redirecionamento automático. A carga útil de resposta do servidor geralmente contém uma pequena nota de hipertexto com um hiperlink para o (s) novo (s) URI (s).

Uma resposta 308 pode ser armazenada em cache por padrão; ou seja, a menos que indicado de outra forma pela definição do método ou controles de cache explícitos3.

Nota: Este código de status é semelhante a 301 Moved Permanently, exceto que não permite alterar o método de solicitação de POST para GET.

O servidor não pode ou não processará a solicitação devido a algo que é percebido como um erro do cliente (por exemplo, sintaxe de solicitação malformada, enquadramento de mensagem de solicitação inválido ou roteamento de solicitação enganoso).

A solicitação não foi aplicada porque não possui credenciais de autenticação válidas para o recurso de destino.

O servidor que gera uma resposta 401 DEVE enviar um cabeçalho WWW-Authenticate campo contendo pelo menos um desafio aplicável ao recurso de destino.

Se a solicitação incluiu credenciais de autenticação, a resposta 401 indica que a autorização foi recusada para essas credenciais. O agente do usuário PODE repetir a solicitação com um novo campo de cabeçalho de autorização ou substituído. Se a resposta 401 contiver o mesmo desafio da resposta anterior, e o agente do usuário já tiver tentado a autenticação pelo menos uma vez, o agente do usuário DEVE apresentar a representação anexa ao usuário, uma vez que geralmente contém informações diagnósticas relevantes.

Reservado para uso futuro.

O servidor entendeu a solicitação, mas se recusa a autorizá-la.

Um servidor que deseja tornar público o motivo da proibição da solicitação pode descrever esse motivo na carga de resposta (se houver).

Se as credenciais de autenticação foram fornecidas na solicitação, o servidor as considera insuficientes para conceder acesso. O cliente NÃO DEVE repetir automaticamente o pedido com as mesmas credenciais. O cliente PODE repetir o pedido com credenciais novas ou diferentes. No entanto, uma solicitação pode ser proibida por motivos não relacionados às credenciais.

Um servidor de origem que deseja "ocultar" a existência atual de um recurso de destino proibido PODE responder com um código de status 404 Not Found.

O servidor de origem não encontrou uma representação atual para o recurso de destino ou não está disposto a divulgar que existe.

Um código de status 404 não indica se essa falta de representação é temporária ou permanente; o código de status 410 Gone tem preferência sobre 404 se o servidor de origem sabe, presumivelmente por meio de alguns meios configuráveis, que a condição provavelmente será permanente.

Uma resposta 404 pode ser armazenada em cache por padrão; ou seja, a menos que indicado de outra forma pela definição do método ou controles de cache explícitos.

O método recebido na linha de solicitação é conhecido pelo servidor de origem, mas não é suportado pelo recurso de destino.

O servidor de origem DEVE gerar um campo Permitir cabeçalho em uma resposta 405 contendo uma lista dos métodos atualmente suportados pelo recurso de destino.

Uma resposta 405 pode ser armazenada em cache por padrão; ou seja, a menos que indicado de outra forma pela definição do método ou controles de cache explícitos.

O recurso de destino não possui uma representação atual que seria aceitável para o agente do usuário, de acordo com os campos de cabeçalho de negociação proativa recebidos na solicitação1, e o servidor não está disposto a fornecer uma representação padrão.

O servidor DEVE gerar uma carga útil contendo uma lista de características de representação disponíveis e identificadores de recursos correspondentes, a partir dos quais o usuário ou agente do usuário pode escolher o mais apropriado. Um agente de usuário PODE selecionar automaticamente a escolha mais apropriada dessa lista. No entanto, esta especificação não define nenhum padrão para tal seleção automática, conforme descrito na RFC7231 Seção 6.4.1.

Semelhante a 401 Unauthorized, mas indica que o cliente precisa se autenticar para usar um proxy.

O proxy DEVE enviar um campo de cabeçalho Proxy-Authenticate contendo um desafio aplicável a esse proxy para o recurso de destino. O cliente PODE repetir o pedido com um campo novo ou substituído do cabeçalho Proxy-Authorization.

O servidor não recebeu uma mensagem de solicitação completa dentro do tempo em que estava preparado para aguardar.

Um servidor DEVE enviar a conexão "fechar" opção na resposta, uma vez que 408 indica que o servidor decidiu encerrar a conexão em vez de continuar esperando. Se o cliente tiver um pedido pendente em trânsito, o cliente PODE repetir esse pedido em uma nova conexão.

A solicitação não pôde ser concluída devido a um conflito com o estado atual do recurso de destino. Este código é usado em situações em que o usuário pode resolver o conflito e reenviar a solicitação.

O servidor DEVE gerar uma carga útil que inclua informações suficientes para que o usuário reconheça a origem do conflito.

Os conflitos são mais prováveis ​​de ocorrer em resposta a uma solicitação PUT. Por exemplo, se o controle de versão estava sendo usado e a representação sendo PUT incluía alterações em um recurso que conflita com aquelas feitas por uma solicitação anterior (de terceiros), o servidor de origem pode usar uma resposta 409 para indicar que não pode completar o solicitar. Nesse caso, a representação da resposta provavelmente conteria informações úteis para mesclar as diferenças com base no histórico de revisão.

O recurso de destino não está mais disponível no servidor de origem e essa condição provavelmente será permanente.

Se o servidor de origem não souber ou não tiver facilidade para determinar se a condição é permanente ou não, o código de status 404 Not Found deve ser usado.

A resposta 410 tem como objetivo principal auxiliar a tarefa de manutenção da web, notificando o destinatário de que o recurso está intencionalmente indisponível e que os proprietários do servidor desejam que os links remotos para esse recurso sejam removidos. Tal evento é comum para serviços promocionais por tempo limitado e para recursos pertencentes a indivíduos não mais associados ao site do servidor de origem. Não é necessário marcar todos os recursos permanentemente indisponíveis como "perdidos" ou manter a marca por qualquer período de tempo - isso é deixado ao critério do proprietário do servidor.

O servidor se recusa a aceitar a solicitação sem um Content-Length definido.

O cliente PODE repetir a solicitação se adicionar um campo de cabeçalho Content-Length válido contendo o comprimento do corpo da mensagem na mensagem de solicitação.

Uma ou mais condições fornecidas nos campos do cabeçalho da solicitação foram avaliadas como falsas quando testadas no servidor.

Esse código de resposta permite que o cliente coloque pré-condições no estado do recurso atual (suas representações e metadados atuais) e, assim, evite que o método de solicitação seja aplicado se o recurso de destino estiver em um estado inesperado.

O servidor se recusa a processar uma solicitação porque a carga útil da solicitação é maior do que o servidor deseja ou é capaz de processar.

O servidor PODE fechar a conexão para evitar que o cliente continue o pedido.

Se a condição for temporária, o servidor DEVE gerar um campo de cabeçalho Retry-After para indicar que é temporário e após o tempo o cliente PODE tentar novamente.

O servidor está se recusando a atender à solicitação porque o request-target é mais longo do que o servidor está disposto a interpretar.

Esta condição rara só pode ocorrer quando um cliente converteu indevidamente uma solicitação POST em uma solicitação GET com informações de consulta longas, quando o cliente caiu em um "buraco negro" de redirecionamento (por exemplo, um prefixo URI redirecionado que aponta para um seu próprio sufixo) ou quando o servidor está sendo atacado por um cliente que tenta explorar brechas de segurança em potencial.

Uma resposta 414 pode ser armazenada em cache por padrão; ou seja, a menos que indicado de outra forma pela definição do método ou controles de cache explícitos.

O servidor de origem se recusa a atender à solicitação porque a carga útil está em um formato não compatível com este método no recurso de destino.

O problema de formato pode ser devido ao tipo de conteúdo ou codificação de conteúdo indicado da solicitação, ou como resultado da inspeção direta dos dados.

Nenhum dos intervalos no campo do cabeçalho de intervalo da solicitação se sobrepõe à extensão atual do recurso selecionado ou o conjunto de intervalos solicitado foi rejeitado devido a intervalos inválidos ou uma solicitação excessiva de intervalos pequenos ou sobrepostos.

Para intervalos de bytes, a falha em sobrepor a extensão atual significa que a posição do primeiro byte de todos os valores de especificação de intervalo de bytes eram maiores do que o comprimento atual da representação selecionada. Quando este código de status é gerado em resposta a uma solicitação de intervalo de bytes, o remetente DEVERIA gerar um campo de cabeçalho Content-Range especificando o comprimento atual da representação selecionada.

Por exemplo:

HTTP/1.1 416 Range Not Satisfiable
Date: Fri, 20 Jan 2012 15:41:54 GMT
Content-Range: bytes */47022

Nota: Como os servidores são livres para ignorar Range, muitas implementações simplesmente responderão com toda a representação selecionada em uma resposta 200 OK. Isso ocorre em parte porque a maioria dos clientes está preparada para receber um 200 OK para concluir a tarefa (embora com menos eficiência) e em parte porque os clientes podem não parar de fazer uma solicitação parcial inválida até que tenham recebido uma representação completa. Assim, os clientes não podem depender de receber uma resposta 416 Faixa Não Satisfável, mesmo quando for mais apropriado.

A expectativa fornecida no campo do cabeçalho Expect da solicitação não pôde ser atendida por pelo menos um dos servidores de entrada.

Qualquer tentativa de preparar café com um bule de chá deve resultar no código de erro "418 I'm a bule". O corpo da entidade resultante PODE ser curto e robusto.

A solicitação foi direcionada a um servidor que não pode produzir uma resposta. Isso pode ser enviado por um servidor que não está configurado para produzir respostas para a combinação de esquema e autoridade que estão incluídos no URI do pedido.

Os clientes que recebem uma resposta de 421 Solicitação mal direcionada de um servidor PODEM tentar novamente a solicitação - seja o método de solicitação idempotente ou não - por meio de uma conexão diferente. Isso é possível se uma conexão for reutilizada1ou se um serviço alternativo for selecionado ALT-SVC.

Este código de status NÃO DEVE ser gerado por proxies.

Uma resposta 421 é armazenável em cache por padrão, ou seja, a menos que indicado de outra forma pela definição do método ou controles de cache explícitos.

O servidor entende o tipo de conteúdo da entidade de solicitação (portanto, um código de status 415 de tipo de mídia não suportado é inadequado) e a sintaxe da entidade de solicitação está correta (portanto, um código de status de solicitação incorreta 400 é inadequado), mas não foi capaz de processar o contido instruções.

Por exemplo, essa condição de erro pode ocorrer se um corpo de solicitação XML contiver instruções XML bem formadas (ou seja, sintaticamente corretas), mas semanticamente erradas.

O recurso de origem ou destino de um método está bloqueado.

Esta resposta DEVE conter um código de pré-condição ou pós-condição apropriado, como 'lock-token-enviado' ou 'sem conflito-lock'.

The method could not be performed on the resource because the requested action depended on another action and that action failed.

For example, if a command in a PROPPATCH method fails, then, at minimum, the rest of the commands will also fail with 424 Failed Dependency.

O servidor se recusa a realizar a solicitação usando o protocolo atual, mas pode estar disposto a fazê-lo depois que o cliente atualizar para um protocolo diferente.

O servidor DEVE enviar um campo de cabeçalho de atualização em uma resposta 426 para indicar o (s) protocolo (s) necessário (s)

Exemplo:

HTTP/1.1 426 Upgrade Required
Upgrade: HTTP/3.0
Connection: Upgrade
Content-Length: 53
Content-Type: text/plain

This service requires use of the HTTP/3.0 protocol.

O servidor de origem requer que a solicitação seja condicional.

Seu uso típico é para evitar o problema de "atualização perdida", onde um cliente obtém o estado de um recurso, modifica-o e o coloca de volta no servidor, quando entretanto um terceiro modificou o estado no servidor, levando a um conflito. Ao exigir que as solicitações sejam condicionais, o servidor pode garantir que os clientes estejam trabalhando com as cópias corretas.

As respostas que usam este código de status DEVEM explicar como reenviar a solicitação com êxito.

Respostas com o código de status 428 NÃO DEVEM ser armazenadas por um cache.

O usuário enviou muitas solicitações em um determinado período de tempo ("limitação de taxa").

As representações de resposta DEVEM incluir detalhes explicando a condição, e PODEM incluir um cabeçalho Retry-After indicando quanto tempo esperar antes de fazer um novo pedido.

Observe que esta especificação não define como o servidor de origem identifica o usuário, nem como conta as solicitações. Por exemplo, um servidor de origem que está limitando as taxas de solicitação pode fazer isso com base nas contagens de solicitações por recurso, em todo o servidor ou mesmo entre um conjunto de servidores. Da mesma forma, ele pode identificar o usuário por suas credenciais de autenticação ou um cookie com estado.

Respostas com o código de status 429 NÃO DEVEM ser armazenadas por um cache.

O servidor não deseja processar a solicitação porque seus campos de cabeçalho são muito grandes. O pedido PODE ser reenviado após reduzir o tamanho dos campos do cabeçalho do pedido.

Ele pode ser usado quando o conjunto de campos de cabeçalho de solicitação no total é muito grande e quando um único campo de cabeçalho está em falta. No último caso, a representação da resposta DEVE especificar qual campo de cabeçalho é muito grande.

Respostas com o código de status 431 NÃO DEVEM ser armazenadas por um cache.

Um código de status não padrão usado para instruir o nginx a fechar a conexão sem enviar uma resposta ao cliente, mais comumente usado para negar solicitações mal-intencionadas ou malformadas.

Este código de status não é visto pelo cliente, ele aparece apenas nos arquivos de log do nginx.

Um código de status não padrão introduzido pelo nginx para o caso em que um cliente fecha a conexão enquanto o nginx está processando a solicitação.

O servidor encontrou uma condição inesperada que o impediu de atender à solicitação.

O servidor não oferece suporte à funcionalidade necessária para atender à solicitação.

Esta é a resposta apropriada quando o servidor não reconhece o método de solicitação e não é capaz de suportá-lo para nenhum recurso.

Uma resposta 501 pode ser armazenada em cache por padrão; ou seja, a menos que indicado de outra forma pela definição do método ou controles de cache explícitos.

O servidor, ao atuar como gateway ou proxy, recebeu uma resposta inválida de um servidor de entrada que ele acessou ao tentar atender à solicitação.

No momento, o servidor não pode atender à solicitação devido a uma sobrecarga temporária ou manutenção programada, que provavelmente será aliviada após algum atraso.

O servidor PODE enviar um campo de cabeçalho Retry-After para sugerir um período de tempo apropriado para o cliente esperar antes de tentar novamente a solicitação.

Nota: A existência do código de status 503 não significa que um servidor tenha que usá-lo ao ficar sobrecarregado. Alguns servidores podem simplesmente recusar a conexão.

O servidor, ao atuar como gateway ou proxy, não recebeu uma resposta oportuna de um servidor upstream que precisava acessar para concluir a solicitação.

O servidor não oferece suporte ou se recusa a aceitar a versão principal do HTTP usada na mensagem de solicitação.

O servidor está indicando que não pode ou não deseja concluir a solicitação usando a mesma versão principal do cliente, conforme descrito na Seção 2.6 do RFC7230, exceto com esta mensagem de erro. O servidor DEVE gerar uma representação para a resposta 505 que descreva por que essa versão não é suportada e quais outros protocolos são suportados por aquele servidor.

O servidor tem um erro de configuração interno: o recurso variante escolhido está configurado para se envolver na própria negociação de conteúdo transparente e, portanto, não é um ponto final adequado no processo de negociação.

O método não pôde ser executado no recurso porque o servidor não pode armazenar a representação necessária para concluir a solicitação com êxito.

Esta condição é considerada temporária. Se a solicitação que recebeu este código de status foi o resultado de uma ação do usuário, a solicitação NÃO DEVE ser repetida até que seja solicitada por uma ação separada do usuário.

O servidor encerrou uma operação porque encontrou um loop infinito ao processar uma solicitação com "Profundidade: infinito". Este status indica que toda a operação falhou.

A política de acesso ao recurso não foi atendida na solicitação. O servidor deve enviar de volta todas as informações necessárias para o cliente emitir uma solicitação estendida.

Está fora do escopo desta especificação especificar como as extensões informam o cliente.

Se a resposta 510 contiver informações sobre extensões que não estavam presentes na solicitação inicial, o cliente PODE repetir a solicitação se tiver motivos para acreditar que pode cumprir a política de extensão, modificando a solicitação de acordo com as informações fornecidas na resposta 510. Caso contrário, o cliente PODE apresentar ao usuário qualquer entidade incluída na resposta 510, desde que essa entidade possa incluir informações diagnósticas relevantes.

O cliente precisa se autenticar para obter acesso à rede.

A representação da resposta DEVE conter um link para um recurso que permite ao usuário enviar credenciais (por exemplo, com um formulário HTML).

Observe que a resposta 511 NÃO DEVE conter um desafio ou a própria interface de login, porque os navegadores mostram a interface de login como estando associada ao URL originalmente solicitado, o que pode causar confusão.

O status 511 NÃO DEVE ser gerado pelos servidores de origem; destina-se ao uso para interceptar proxies que são interpostos como um meio de controlar o acesso à rede.

As respostas com o código de status 511 NÃO DEVEM ser armazenadas por um cache.

O código de status 511 é projetado para mitigar problemas causados ​​por "portais cativos" para software (especialmente agentes não navegadores) que estão esperando uma resposta do servidor para o qual uma solicitação foi feita, e não da infraestrutura de rede intermediária. Não se destina a encorajar a implantação de portais cativos - apenas para limitar os danos causados ​​por eles.

Uma operadora de rede que deseja exigir alguma autenticação, aceitação de termos ou outra interação do usuário antes de conceder acesso geralmente o faz identificando clientes que não o fizeram ("clientes desconhecidos") usando seus endereços de Controle de Acesso à Mídia (MAC).

Os clientes desconhecidos têm então todo o tráfego bloqueado, exceto aquele na porta TCP 80, que é enviado a um servidor HTTP (o "servidor de login") dedicado a "efetuar login" de clientes desconhecidos e, claro, o tráfego para o próprio servidor de login.

Por exemplo, um agente de usuário pode se conectar a uma rede e fazer a seguinte solicitação HTTP na porta TCP 80:

GET /index.htm HTTP/1.1
Host: www.example.com

Ao receber essa solicitação, o servidor de login geraria uma resposta 511

Aqui, o código de status 511 garante que os clientes que não sejam navegadores não interpretem a resposta como sendo do servidor de origem, e o elemento META HTML redireciona o agente do usuário para o servidor de login.

Este código de status não é especificado em nenhum RFC, mas é usado por alguns proxies HTTP para sinalizar um tempo limite de conexão de rede atrás do proxy para um cliente na frente do proxy.