HTTP - Campos de cabeçalho

Os campos de cabeçalho HTTP fornecem informações necessárias sobre a solicitação ou resposta, ou sobre o objeto enviado no corpo da mensagem. Existem quatro tipos de cabeçalhos de mensagens HTTP:

General-header: Esses campos de cabeçalho têm aplicabilidade geral para mensagens de solicitação e resposta.
Client Request-header: Esses campos de cabeçalho têm aplicabilidade apenas para mensagens de solicitação.
Server Response-header: Esses campos de cabeçalho têm aplicabilidade apenas para mensagens de resposta.
Entity-header: Esses campos de cabeçalho definem metainformações sobre o corpo da entidade ou, se nenhum corpo estiver presente, sobre o recurso identificado pela solicitação.

Cabeçalhos Gerais

Cache-Control

O campo de cabeçalho geral Cache-Control é usado para especificar as diretivas que DEVEM ser obedecidas por todo o sistema de cache. A sintaxe é a seguinte:

Cache-Control : cache-request-directive|cache-response-directive

Um cliente ou servidor HTTP pode usar o Cache-controlcabeçalho geral para especificar parâmetros para o cache ou para solicitar certos tipos de documentos do cache. As diretivas de armazenamento em cache são especificadas em uma lista separada por vírgulas. Por exemplo:

Cache-control: no-cache

A tabela a seguir lista as diretivas de solicitação de cache importantes que podem ser usadas pelo cliente em sua solicitação HTTP:

SN	Diretiva e descrição de solicitação de cache
1	no-cache Um cache não deve usar a resposta para satisfazer uma solicitação subsequente sem revalidação bem-sucedida com o servidor de origem.
2	no-store O cache não deve armazenar nada sobre a solicitação do cliente ou a resposta do servidor.
3	max-age = seconds Indica que o cliente está disposto a aceitar uma resposta cuja idade não seja maior que o tempo especificado em segundos.
4	max-stale [ = seconds ] Indica que o cliente está disposto a aceitar uma resposta que excedeu o tempo de expiração. Se segundos forem fornecidos, ele não deve expirar por mais do que esse tempo.
5	min-fresh = seconds Indica que o cliente está disposto a aceitar uma resposta cujo tempo de vida de atualização não seja menor que a idade atual mais o tempo especificado em segundos.
6	no-transform Não converte o corpo-entidade.
7	only-if-cached Não recupera novos dados. O cache pode enviar um documento somente se estiver no cache e não deve contatar o servidor de origem para ver se existe uma cópia mais recente.

As seguintes diretivas de resposta de cache importantes que podem ser usadas pelo servidor em sua resposta HTTP:

SN	Diretiva de resposta de cache e descrição
1	public Indica que a resposta pode ser armazenada em cache por qualquer cache.
2	private Indica que toda ou parte da mensagem de resposta é destinada a um único usuário e não deve ser armazenada em cache por um cache compartilhado.
3	no-cache Um cache não deve usar a resposta para satisfazer uma solicitação subsequente sem uma revalidação bem-sucedida com o servidor de origem.
4	no-store O cache não deve armazenar nada sobre a solicitação do cliente ou a resposta do servidor.
5	no-transform Não converte o corpo-entidade.
6	must-revalidate O cache deve verificar o status dos documentos obsoletos antes de usá-lo e os expirados não devem ser usados.
7	proxy-revalidate A diretiva proxy-revalidate tem o mesmo significado que a diretiva must-revalidate, exceto que não se aplica a caches de agentes de usuário não compartilhados.
8	max-age = seconds Indica que o cliente está disposto a aceitar uma resposta cuja idade não seja maior que o tempo especificado em segundos.
9	s-maxage = seconds A idade máxima especificada por esta diretiva substitui a idade máxima especificada pela diretiva max-age ou pelo cabeçalho Expires. A diretiva s-maxage é sempre ignorada por um cache privado.

Conexão

O campo de cabeçalho geral de conexão permite que o remetente especifique as opções desejadas para aquela conexão particular e não deve ser comunicado por proxies em outras conexões. A seguir está a sintaxe simples para usar o cabeçalho de conexão:

Connection : "Connection"

HTTP / 1.1 define a opção de conexão "fechar" para o remetente sinalizar que a conexão será fechada após a conclusão da resposta. Por exemplo:

Connection: close

Por padrão, o HTTP 1.1 usa conexões persistentes, onde a conexão não fecha automaticamente após uma transação. O HTTP 1.0, por outro lado, não possui conexões persistentes por padrão. Se um cliente 1.0 deseja usar conexões persistentes, ele usa okeep-alive parâmetro da seguinte forma:

Connection: keep-alive

Encontro

Todos os carimbos de data / hora HTTP DEVEM ser representados no horário de Greenwich (GMT), sem exceção. Os aplicativos HTTP podem usar qualquer uma das três representações de carimbos de data / hora a seguir:

Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 822, updated by RFC 1123
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format

Aqui, o primeiro formato é o mais preferido.

Pragma

O campo de cabeçalho geral Pragma é usado para incluir diretivas específicas de implementação que podem ser aplicadas a qualquer destinatário ao longo da cadeia de solicitação / resposta. Por exemplo:

Pragma: no-cache

A única diretiva definida em HTTP / 1.0 é a diretiva no-cache e é mantida em HTTP 1.1 para compatibilidade com versões anteriores. Nenhuma nova diretiva Pragma será definida no futuro.

Reboque

O valor do campo geral Trailer indica que o determinado conjunto de campos de cabeçalho está presente no trailer de uma mensagem codificada com codificação de transferência em partes. A seguir está a sintaxe do campo de cabeçalho do Trailer:

Trailer : field-name

Os campos de cabeçalho de mensagem listados no campo de cabeçalho do trailer não devem incluir os seguintes campos de cabeçalho:

Transfer-Encoding
Content-Length
Trailer

Transfer-Encoding

O campo de cabeçalho geral Transfer-Encoding indica que tipo de transformação foi aplicada ao corpo da mensagem para transferi-la com segurança entre o remetente e o destinatário. Isso não é o mesmo que codificação de conteúdo porque as codificações de transferência são uma propriedade da mensagem, não do corpo da entidade. A sintaxe do campo de cabeçalho Transfer-Encoding é a seguinte:

Transfer-Encoding: chunked

Todos os valores de codificação de transferência não diferenciam maiúsculas de minúsculas.

Melhoria

O cabeçalho geral de atualização permite que o cliente especifique quais protocolos de comunicação adicionais ele suporta e gostaria de usar se o servidor achar apropriado para alternar protocolos. Por exemplo:

Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11

O campo de cabeçalho de atualização se destina a fornecer um mecanismo simples para a transição de HTTP / 1.1 para algum outro protocolo incompatível.

Através da

O cabeçalho geral Via deve ser usado por gateways e proxies para indicar os protocolos e destinatários intermediários. Por exemplo, uma mensagem de solicitação pode ser enviada de um agente de usuário HTTP / 1.0 para um proxy interno denominado "fred", que usa HTTP / 1.1 para encaminhar a solicitação para um proxy público em nowhere.com, que conclui a solicitação por encaminhá-lo para o servidor de origem em www.ics.uci.edu. A solicitação recebida por www.ics.uci.edu teria então o seguinte campo de cabeçalho Via:

Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)

O campo de cabeçalho de atualização se destina a fornecer um mecanismo simples para a transição de HTTP / 1.1 para algum outro protocolo incompatível.

Atenção

O cabeçalho geral de Aviso é usado para transportar informações adicionais sobre o status ou transformação de uma mensagem que pode não estar refletida na mensagem. Uma resposta pode conter mais de um cabeçalho de Aviso.

Warning : warn-code SP warn-agent SP warn-text SP warn-date

Cabeçalhos de solicitação de cliente

Aceitar

O campo Aceitar cabeçalho da solicitação pode ser usado para especificar certos tipos de mídia que são aceitáveis para a resposta. A sintaxe geral é a seguinte:

Accept: type/subtype [q=qvalue]

Vários tipos de mídia podem ser listados separados por vírgulas e o qvalue opcional representa um nível de qualidade aceitável para aceitar tipos em uma escala de 0 a 1. A seguir está um exemplo:

Accept: text/plain; q=0.5, text/html, text/x-dvi; q=0.8, text/x-c

Isso seria interpretado como text/html e text/x-c e são os tipos de mídia preferidos, mas se eles não existirem, envie o text/x-dvi entidade, e se esta não existir, envie o text/plain entidade.

Accept-Charset

O campo de cabeçalho de solicitação Accept-Charset pode ser usado para indicar quais conjuntos de caracteres são aceitáveis para a resposta. A seguir está a sintaxe geral:

Accept-Charset: character_set [q=qvalue]

Vários conjuntos de caracteres podem ser listados separados por vírgulas e o qvalue opcional representa um nível de qualidade aceitável para conjuntos de caracteres não preferidos em uma escala de 0 a 1. A seguir está um exemplo:

Accept-Charset: iso-8859-5, unicode-1-1; q=0.8

O valor especial "*", se presente no Accept-Charset campo, corresponde a cada conjunto de caracteres e se não Accept-Charset cabeçalho estiver presente, o padrão é que qualquer conjunto de caracteres seja aceitável.

Aceitar-Codificação

O campo de cabeçalho de solicitação Accept-Encoding é semelhante a Aceitar, mas restringe as codificações de conteúdo que são aceitáveis na resposta. A sintaxe geral é:

Accept-Encoding: encoding types

Os exemplos são os seguintes:

Accept-Encoding: compress, gzip
Accept-Encoding:
Accept-Encoding: *
Accept-Encoding: compress;q=0.5, gzip;q=1.0
Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0

Accept-Language

O campo de cabeçalho de solicitação Accept-Language é semelhante a Accept, mas restringe o conjunto de linguagens naturais que são preferidas como uma resposta à solicitação. A sintaxe geral é:

Accept-Language: language [q=qvalue]

Vários idiomas podem ser listados separados por vírgulas e o qvalue opcional representa um nível de qualidade aceitável para idiomas não preferenciais em uma escala de 0 a 1. A seguir está um exemplo:

Accept-Language: da, en-gb;q=0.8, en;q=0.7

Autorização

O valor do campo do cabeçalho de solicitação de autorização consiste em credenciais contendo as informações de autenticação do agente do usuário para a região do recurso que está sendo solicitado. A sintaxe geral é:

Authorization : credentials

A especificação HTTP / 1.0 define o esquema de autorização BASIC, onde o parâmetro de autorização é a string de username:password codificado na base 64. A seguir está um exemplo:

Authorization: BASIC Z3Vlc3Q6Z3Vlc3QxMjM=

O valor decodifica em é guest:guest123 Onde guest é o ID do usuário e guest123 é a senha.

Bolacha

O valor do campo Cookie request-header contém um par nome / valor de informações armazenadas para esse URL. A seguir está a sintaxe geral:

Cookie: name=value

Vários cookies podem ser especificados separados por ponto e vírgula da seguinte forma:

Cookie: name1=value1;name2=value2;name3=value3

Espero

O campo Expect request-header é usado para indicar que um determinado conjunto de comportamentos de servidor é exigido pelo cliente. A sintaxe geral é:

Expect : 100-continue | expectation-extension

Se um servidor receber uma solicitação contendo um campo Expect que inclui uma extensão de expectativa não compatível, ele deve responder com um status 417 (Expectation Failed).

De

O campo do cabeçalho da solicitação De contém um endereço de e-mail da Internet para o usuário humano que controla o agente do usuário solicitante. A seguir está um exemplo simples:

From: [email protected]

Este campo de cabeçalho pode ser usado para fins de registro e como um meio de identificar a origem de solicitações inválidas ou indesejadas.

Hospedeiro

O campo de cabeçalho de solicitação do Host é usado para especificar o host da Internet e o número da porta do recurso que está sendo solicitado. A sintaxe geral é:

Host : "Host" ":" host [ ":" port ] ;

UMA hostsem nenhuma informação de porta final implica a porta padrão, que é 80. Por exemplo, uma solicitação no servidor de origem para http://www.w3.org/pub/WWW/ seria:

GET /pub/WWW/ HTTP/1.1
Host: www.w3.org

If-Match

O campo de cabeçalho de solicitação If-Match é usado com um método para torná-lo condicional. Este cabeçalho solicita que o servidor execute o método solicitado apenas se o valor fornecido nesta tag corresponder às tags de entidade fornecidas representadas porETag. A sintaxe geral é:

If-Match : entity-tag

Um asterisco (*) corresponde a qualquer entidade e a transação continua apenas se a entidade existir. A seguir estão alguns exemplos possíveis:

If-Match: "xyzzy"
If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-Match: *

Se nenhuma das tags de entidade corresponder, ou se "*" for fornecido e nenhuma entidade atual existir, o servidor não deve executar o método solicitado e deve retornar uma resposta 412 (Falha de pré-condição).

Se-Modificado-Desde

O campo de cabeçalho de solicitação If-Modified-Since é usado com um método para torná-lo condicional. Se a URL solicitada não foi modificada desde o tempo especificado neste campo, uma entidade não será retornada do servidor; em vez disso, uma resposta 304 (não modificada) será retornada sem qualquer corpo de mensagem. A sintaxe geral de if-modify-since é:

If-Modified-Since : HTTP-date

Um exemplo do campo é:

If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

If-None-Match

O campo de cabeçalho de solicitação If-None-Match é usado com um método para torná-lo condicional. Este cabeçalho solicita que o servidor execute o método solicitado apenas se um dos valores fornecidos nesta tag corresponder às tags de entidade fornecidas representadas porETag. A sintaxe geral é:

If-None-Match : entity-tag

Um asterisco (*) corresponde a qualquer entidade e a transação continua apenas se a entidade não existir. A seguir estão os exemplos possíveis:

If-None-Match: "xyzzy"
If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-None-Match: *

If-Range

O campo de cabeçalho de solicitação If-Range pode ser usado com um GET condicional para solicitar apenas a parte da entidade que está faltando, se não tiver sido alterada, e a entidade inteira, se tiver sido alterada. A sintaxe geral é a seguinte:

If-Range : entity-tag | HTTP-date

Tanto uma tag de entidade quanto uma data podem ser usadas para identificar a entidade parcial já recebida. Por exemplo:

If-Range: Sat, 29 Oct 1994 19:43:31 GMT

Aqui, se o documento não foi modificado desde a data fornecida, o servidor retorna o intervalo de bytes fornecido pelo cabeçalho Range, caso contrário, ele retorna todo o novo documento.

If-Unmodified-Since

O campo de cabeçalho de solicitação If-Unmodified-Since é usado com um método para torná-lo condicional. A sintaxe geral é:

If-Unmodified-Since : HTTP-date

Se o recurso solicitado não foi modificado desde a hora especificada neste campo, o servidor deve realizar a operação solicitada como se o cabeçalho If-Unmodified-Since não estivesse presente. Por exemplo:

If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT

Se a solicitação resultar em algo diferente de um status 2xx ou 412, o cabeçalho If-Unmodified-Since deve ser ignorado.

Max-Forwards

O campo de cabeçalho de solicitação Max-Forwards fornece um mecanismo com os métodos TRACE e OPTIONS para limitar o número de proxies ou gateways que podem encaminhar a solicitação para o próximo servidor de entrada. Aqui está a sintaxe geral:

Max-Forwards : n

O valor Max-Forwards é um número inteiro decimal que indica o número restante de vezes que essa mensagem de solicitação pode ser encaminhada. Isso é útil para depuração com o método TRACE, evitando loops infinitos. Por exemplo:

Max-Forwards : 5

O campo de cabeçalho Max-Forwards pode ser ignorado para todos os outros métodos definidos na especificação HTTP.

Autorização Proxy

O campo do cabeçalho de solicitação Proxy-Authorization permite que o cliente se identifique (ou seu usuário) para um proxy que requer autenticação. Aqui está a sintaxe geral:

Proxy-Authorization : credentials

O valor do campo Proxy-Authorization consiste em credenciais contendo as informações de autenticação do agente do usuário para o proxy e / ou domínio do recurso que está sendo solicitado.

Alcance

O campo de cabeçalho de solicitação de intervalo especifica os intervalos parciais do conteúdo solicitado do documento. A sintaxe geral é:

Range: bytes-unit=first-byte-pos "-" [last-byte-pos]

O valor da posição do primeiro byte em uma especificação de intervalo de bytes fornece o deslocamento de byte do primeiro byte em um intervalo. O valor pos do último byte fornece o deslocamento de byte do último byte no intervalo; ou seja, as posições de byte especificadas são inclusivas. Você pode especificar uma unidade de byte como bytes. Os deslocamentos de bytes começam em zero. Alguns exemplos simples são os seguintes:

- The first 500 bytes 
Range: bytes=0-499

- The second 500 bytes
Range: bytes=500-999

- The final 500 bytes
Range: bytes=-500

- The first and last bytes only
Range: bytes=0-0,-1

Vários intervalos podem ser listados, separados por vírgulas. Se o primeiro dígito no (s) intervalo (s) de bytes separados por vírgula (s) estiver faltando, o intervalo será considerado contando a partir do final do documento. Se o segundo dígito estiver faltando, o intervalo será o byte n até o final do documento.

Referer

O campo Referer request-header permite que o cliente especifique o endereço (URI) do recurso do qual a URL foi solicitada. A sintaxe geral é a seguinte:

Referer : absoluteURI | relativeURI

A seguir está um exemplo simples:

Referer: http://www.tutorialspoint.org/http/index.htm

Se o valor do campo for um URI relativo, ele deve ser interpretado em relação ao URI de Solicitação .

TE

O campo de cabeçalho de solicitação TE indica qual codificação de transferência de extensão ele está disposto a aceitar na resposta e se está ou não disposto a aceitar campos de trailer em uma codificação de transferência em partes . A seguir está a sintaxe geral:

TE   : t-codings

A presença da palavra-chave "trailers" indica que o cliente está disposto a aceitar campos de trailer em uma codificação de transferência em partes e é especificada de uma das seguintes maneiras:

TE: deflate
TE:
TE: trailers, deflate;q=0.5

Se o valor do campo TE estiver vazio ou se nenhum campo TE estiver presente, apenas a codificação de transferência será fragmentada . Uma mensagem sem codificação de transferência é sempre aceitável.

Agente de usuário

O campo de cabeçalho de solicitação do Agente do Usuário contém informações sobre o agente do usuário que originou a solicitação. A seguir está a sintaxe geral:

User-Agent : product | comment

Exemplo:

User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)

Cabeçalhos de resposta do servidor

Intervalos de aceitação

O campo de cabeçalho de resposta Accept-Ranges permite que o servidor indique sua aceitação de solicitações de intervalo para um recurso. A sintaxe geral é:

Accept-Ranges  : range-unit | none

Por exemplo, um servidor que aceita solicitações de intervalo de bytes pode enviar:

Accept-Ranges: bytes

Os servidores que não aceitam nenhum tipo de solicitação de intervalo para um recurso podem enviar:

Accept-Ranges: none

Isso aconselhará o cliente a não tentar uma solicitação de intervalo.

Era

O campo de cabeçalho de resposta Age transmite a estimativa do remetente da quantidade de tempo desde que a resposta (ou sua revalidação) foi gerada no servidor de origem. A sintaxe geral é:

Age : delta-seconds

Os valores de idade são inteiros decimais não negativos, representando o tempo em segundos. A seguir está um exemplo simples:

Age: 1030

Um servidor HTTP / 1.1 que inclui um cache deve incluir um campo de cabeçalho Age em cada resposta gerada a partir de seu próprio cache.

ETag

O campo de cabeçalho de resposta ETag fornece o valor atual da tag de entidade para a variante solicitada. A sintaxe geral é:

ETag :  entity-tag

Aqui estão alguns exemplos simples:

ETag: "xyzzy"
ETag: W/"xyzzy"
ETag: ""

Localização

O campo de cabeçalho de resposta de localização é usado para redirecionar o destinatário para um local diferente do URI de solicitação para conclusão. A sintaxe geral é:

Location : absoluteURI

A seguir está um exemplo simples:

Location: http://www.tutorialspoint.org/http/index.htm

O campo de cabeçalho Content-Location difere de Location porque Content-Location identifica o local original da entidade incluída na solicitação.

Proxy-Authenticate

O campo de cabeçalho de resposta Proxy-Authenticate deve ser incluído como parte de uma resposta 407 (Autenticação de proxy necessária). A sintaxe geral é:

Proxy-Authenticate  : challenge

Tentar novamente depois

O campo de cabeçalho de resposta Retry-After pode ser usado com uma resposta 503 (Serviço Indisponível) para indicar por quanto tempo o serviço ficará indisponível para o cliente solicitante. A sintaxe geral é:

Retry-After : HTTP-date | delta-seconds

Exemplos:

Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120

No último exemplo, o atraso é de 2 minutos.

Servidor

O campo de cabeçalho de resposta do servidor contém informações sobre o software usado pelo servidor de origem para lidar com a solicitação. A sintaxe geral é:

Server : product | comment

A seguir está um exemplo simples:

Server: Apache/2.2.14 (Win32)

Se a resposta estiver sendo encaminhada por meio de um proxy, o aplicativo proxy não deve modificar o cabeçalho de resposta do servidor.

Set-Cookie

O campo de cabeçalho de resposta Set-Cookie contém um par nome / valor de informações a serem retidas para este URL. A sintaxe geral é:

Set-Cookie: NAME=VALUE; OPTIONS

O cabeçalho de resposta Set-Cookie compreende o token Set-Cookie, seguido por uma lista separada por vírgulas de um ou mais cookies. Aqui estão os valores possíveis que você pode especificar como opções:

SN	Opções e descrição
1	Comment=comment Esta opção pode ser usada para especificar qualquer comentário associado ao cookie.
2	Domain=domain O atributo Domain especifica o domínio para o qual o cookie é válido.
3	Expires=Date-time A data em que o cookie irá expirar. Se estiver em branco, o cookie irá expirar quando o visitante sair do navegador.
4	Path=path O atributo Path especifica o subconjunto de URLs aos quais este cookie se aplica.
5	Secure Ele instrui o agente do usuário a retornar o cookie apenas em uma conexão segura.

A seguir está um exemplo de um cabeçalho de cookie simples gerado pelo servidor:

Set-Cookie: name1=value1,name2=value2; Expires=Wed, 09 Jun 2021 10:18:14 GMT

Variar

O campo de cabeçalho de resposta Vary especifica que a entidade tem várias fontes e pode, portanto, variar de acordo com a lista especificada de cabeçalho (s) de solicitação. A seguir está a sintaxe geral:

Vary : field-name

Você pode especificar vários cabeçalhos separados por vírgulas e um valor de asterisco "*" sinaliza que os parâmetros não especificados não estão limitados aos cabeçalhos de solicitação. A seguir está um exemplo simples:

Vary: Accept-Language, Accept-Encoding

Aqui, os nomes dos campos não diferenciam maiúsculas de minúsculas.

WWW-Authenticate

O campo de cabeçalho de resposta WWW-Authenticate deve ser incluído nas mensagens de resposta 401 (não autorizado). O valor do campo consiste em pelo menos um desafio que indica o (s) esquema (s) de autenticação e os parâmetros aplicáveis ao URI de solicitação. A sintaxe geral é:

WWW-Authenticate : challenge

O valor do campo WWW- Authenticate pode conter mais de um desafio ou, se mais de um campo de cabeçalho WWW-Authenticate for fornecido, o conteúdo de um desafio em si pode conter uma lista separada por vírgulas de parâmetros de autenticação. A seguir está um exemplo simples:

WWW-Authenticate: BASIC realm="Admin"

Cabeçalhos de Entidade

Permitir

O campo Permitir cabeçalho de entidade lista o conjunto de métodos suportados pelo recurso identificado pelo URI de Solicitação. A sintaxe geral é:

Allow : Method

Você pode especificar vários métodos separados por vírgulas. A seguir está um exemplo simples:

Allow: GET, HEAD, PUT

Este campo não pode impedir um cliente de tentar outros métodos.

Codificação de conteúdo

O campo de cabeçalho de entidade Content-Encoding é usado como um modificador para o tipo de mídia. A sintaxe geral é:

Content-Encoding : content-coding

A codificação de conteúdo é uma característica da entidade identificada pelo Request-URI. A seguir está um exemplo simples:

Content-Encoding: gzip

Se a codificação de conteúdo de uma entidade em uma mensagem de solicitação não for aceitável para o servidor de origem, o servidor deve responder com um código de status 415 (Tipo de mídia não suportado).

Content-Language

O campo de cabeçalho de entidade Content-Language descreve a (s) linguagem (s) natural (is) do público-alvo da entidade incluída. A seguir está a sintaxe geral:

Content-Language : language-tag

Vários idiomas podem ser listados para conteúdo que se destina a vários públicos. A seguir está um exemplo simples:

Content-Language: mi, en

O objetivo principal do Content-Language é permitir que um usuário identifique e diferencie entidades de acordo com o idioma de preferência do usuário.

Comprimento do conteúdo

O campo Content-Length entity-header indica o tamanho da entidade-corpo, em número decimal de OCTETs, enviado ao destinatário ou, no caso do método HEAD, o tamanho da entidade-corpo que teria sido enviado, caso o pedido fosse um GET. A sintaxe geral é:

Content-Length : DIGITS

A seguir está um exemplo simples:

Content-Length: 3495

Qualquer Content-Length maior ou igual a zero é um valor válido.

Content-Location

O campo de cabeçalho de entidade Content-Location pode ser usado para fornecer a localização do recurso para a entidade incluída na mensagem quando essa entidade está acessível a partir de um local separado do URI do recurso solicitado. A sintaxe geral é:

Content-Location:  absoluteURI | relativeURI

A seguir está um exemplo simples:

Content-Location: http://www.tutorialspoint.org/http/index.htm

O valor de Content-Location também define o URI de base para a entidade.

Content-MD5

O campo de cabeçalho de entidade Content-MD5 pode ser usado para fornecer um resumo MD5 da entidade para verificar a integridade da mensagem no recebimento. A sintaxe geral é:

Content-MD5  : md5-digest using base64 of 128 bit MD5 digest as per RFC 1864

A seguir está um exemplo simples:

Content-MD5  : 8c2d46911f3f5a326455f0ed7a8ed3b3

O resumo MD5 é calculado com base no conteúdo do corpo da entidade, incluindo qualquer codificação de conteúdo que foi aplicada, mas não incluindo nenhuma codificação de transferência aplicada ao corpo da mensagem.

Content-Range

O campo de cabeçalho de entidade Content-Range é enviado com um corpo de entidade parcial para especificar onde no corpo de entidade completo o corpo parcial deve ser aplicado. A sintaxe geral é:

Content-Range : bytes-unit SP first-byte-pos "-" last-byte-pos

Exemplos de valores de especificação de intervalo de conteúdo de byte, supondo que a entidade contenha um total de 1234 bytes:

- The first 500 bytes:
Content-Range : bytes 0-499/1234

- The second 500 bytes:
Content-Range : bytes 500-999/1234

- All except for the first 500 bytes:
Content-Range : bytes 500-1233/1234

- The last 500 bytes:
Content-Range : bytes 734-1233/1234

Quando uma mensagem HTTP inclui o conteúdo de um único intervalo, esse conteúdo é transmitido com um cabeçalho Content-Range e um cabeçalho Content-Length mostrando o número de bytes realmente transferidos. 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

Tipo de conteúdo

O campo Content-Type entity-header indica o tipo de mídia do corpo-entidade enviado ao destinatário ou, no caso do método HEAD, o tipo de mídia que teria sido enviado se a solicitação fosse um GET. A sintaxe geral é:

Content-Type : media-type

A seguir está um exemplo:

Content-Type: text/html; charset=ISO-8859-4

Expira

O campo de cabeçalho de entidade Expires fornece a data / hora após a qual a resposta é considerada obsoleta. A sintaxe geral é:

Expires : HTTP-date

A seguir está um exemplo:

Expires: Thu, 01 Dec 1994 16:00:00 GMT

Última modificação

O campo do cabeçalho da entidade Última modificação indica a data e hora em que o servidor de origem acredita que a variante foi modificada pela última vez. A sintaxe geral é:

Last-Modified: HTTP-date

A seguir está um exemplo:

Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT