Transfer-Encoding - HTTP

Transfer-Encoding
=================

O cabeçalho **`Transfer-Encoding`** especifica a forma de codificação usada para transferir seguramente o corpo da mensagem (payload body (en-US)) para o usuário.

**Nota:** HTTP/2 não suporta o mecanismo de codificação de trasferência fragmentada do HTTP 1.1, já que ele provém o próprio, e mais eficiente, mecanismo para *streaming* de dados.

`Transfer-Encoding` é um cabeçalho salto-por-salto (*hop-by-hop header*), que é aplicado a uma mensagem entre dois nós, não ao recurso em si. Cada segmento da conexão multi-nós pode usar diferentes valores `Transfer-Encoding`. Se você quer comprimir dados através da conexão inteira, use o cabeçalho `Content-Encoding` ao invés disso.

Quando presente em uma resposta para uma requisição `HEAD` que não tem corpo, ele indica o valor que seria aplicado a mensagem `GET` correspondente.

|  |  |
| --- | --- |
| Tipo de cabeçalho | Response header (en-US) |
| Forbidden header name | sim |

Sintaxe
-------
```

Transfer-Encoding: chunked
Transfer-Encoding: compress
Transfer-Encoding: deflate
Transfer-Encoding: gzip
Transfer-Encoding: identity

// Diversos valores podem ser listados, separados por vírgula
Transfer-Encoding: gzip, chunked
```

Diretivas
---------

`chunked`

Dados enviados em uma série de fragmentos. O cabeçalho `Content-Length` é omitido neste caso e no começo de cada fragmento, você precisa adicionar o tamanho do fragmento atual em formato hexadecimal, seguido por '`\r\n`' e o fragmento em si, seguido por outro '`\r\n`'. O fragmento final é um fragmento normal, com exceção que seu tamanho é zero. Ele é seguido por um reboque, que consiste de uma (possívelmente vazia) sequência de cabeçalhos de entidade.

`compress`

 Um formato usando o algoritmo Lempel-Ziv-Welch (LZW). O nome do valor foi pego do programa UNIX *compress*, que implementa o algoritmo.
 Como o programa de compressão, que desapareceu da maioria das distribuições UNIX, esta codificação de conteúdo não é usada por quase nenhum navegador atualmente, em partes por causa do seu problema de patente (que expirou em 2003).

`deflate`

Usando a estrutura zlib (definida na RFC 1950), com o algoritmo de compressão *deflate* (definido em RFC 1951).

`gzip`

O formato usando a codificação Lempel-Ziv (LZ77), com CRC 32-bit. Este é originalmente o formato do programa UNIX *gzip*. O padrão HTTP/1.1 também recomenda que os servidores que suportem esta codificação de conteúdo devem reconhecer `x-gzip` como um pseudônimo, para propósitos de compatibilidade.

`identity`

Indica a função de identidade (i.e. sem compressão, nem modificação). Este *token*, exceto se explicitamente especificado, é sempre considerado aceitável.

Exemplos
--------

### Codificação fragmentada

Codificação fragmentada é útil quando grandes quantidade de dados estão sendo enviados para o cliente e o tamanho total da resposta pode não ser conhecido até que a requisição seja totalmente processada. Por exemplo, quando gerando uma grande tabela HTML resultante de uma consulta no banco de dados ou transmitindo grandes imagens. A resposta fragmentada se parece com isto:
```

HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked

7\r\n
Mozilla\r\n
9\r\n
Developer\r\n
7\r\n
Network\r\n
0\r\n
\r\n
```

Especificações
--------------

| Especificação | Título |
| --- | --- |
| RFC 7230, sessão 3.3.1: Transfer-Encoding | Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing |

Compatibilidade com navegadores
-------------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Veja também
-----------

* `Accept-Encoding`
* `Content-Encoding`
* `Content-Length`
* Cabeçalho que regulam o uso de reboques: `TE` (requisições) e `Trailer` (respostas).
* Codificação de transferência fragmentada


Feature-Policy - HTTP

Feature-Policy
==============

O cabeçalho HTTP **`Feature-Policy`** provê um mecanismo para permitir ou proibir o uso de funcionalidades do navegador no seu próprio enquadramento, e o conteúdo dentro de quaisquer elementos `<iframe>` no documento.

**Nota:** Este cabeçalho ainda está em estado experimental, e é sujeito a mudança a qualquer momento. Tenha cautela quando implementando isso no seu site. O cabeçalho agora foi renomeado para `Permissions-Policy` na especificação, e este artigo irá eventualmente ser atualizado para refletir estas atualizações.

Para mais informação, veja o artigo principal Policy Feature.

|  |  |
| --- | --- |
| Tipo de cabeçalho | Response header (en-US) |
| Forbidden header name | sim |

Sintaxe
-------
```

Feature-Policy: <directive> <allowlist>
```

`<directive>`

A diretiva Feature Policy que irá aplicar a `allowlist`. Veja Diretivas abaixo para a lista de nomes de diretivas.

`<allowlist>`
{{page("Web/HTTP/Feature\_Policy/Using\_Feature\_Policy", "allowlist")}}
Diretivas
---------

`accelerometer` (en-US)

Controla se o documento atual é permitido de coletar informação sobre a aceleração do dispositivo através da interface `Accelerometer` (en-US).

`ambient-light-sensor` (en-US)

Controla se o documento atual é permitido de coletar informação sobre a quantidade de luz no ambiente ao redor do dispositivo através da interface `AmbientLightSensor` (en-US).

`autoplay` (en-US)

Controla se o documento atual é permitido de tocar a mídia requisitada automaticamente através da interface `HTMLMediaElement` (en-US). Quando esta política é desabilitada e não há ação do usuário, o `Promise` (en-US) retornado pelo `HTMLMediaElement.play()` (en-US) irá rejeitar com uma `DOMException` (en-US). O atributo *autoplay* em elementos `<audio>` e `<video>` será ignorado.

`battery` (en-US)

Controla se o uso da API de Status de Bateria é permitido. Quando esta política está desabilitada, o `Promise` retornado pelo`Navigator.getBattery()` irá rejeitar com um `NotAllowedError` `DOMException` (en-US).

`camera` (en-US)

Controla se o documento atual é permitido de usar entradas de dispositivos de vídeo. Quando esta política está desabilitada, o `Promise` retornado pelo `getUserMedia()` (en-US) irá rejeitar com um `NotAllowedError` `DOMException` (en-US).

`display-capture` (en-US)

Controla se o documento atual é permitido ou não de usar o método `getDisplayMedia()` (en-US) para capturar conteúdos de tela. Quando esta política está desabilitada, a `Promise` retornada pelo `getDisplayMedia()` irá rejeitar com um `NotAllowedError` se a permissão não for obtida para capturar os conteúdos da tela.

`document-domain` (en-US)

Controle se o documento atual é permitido de colocar `document.domain` (en-US). Quando esta política está desabilitada, tentativas em colocar `document.domain` (en-US) irão falhar e causar uma `SecurityError` `DOMException` (en-US) a ser jogada.

`encrypted-media` (en-US)

Controla se o documento atual é permitido de usar a API Extensões de Mídias Encriptadas (*Encrypted Media Extensions*) (en-US) (EME). Quando esta política é desabilitada, a `Promise` (en-US) retornada pelo `Navigator.requestMediaKeySystemAccess()` (en-US) irá rejeitar com um `DOMException` (en-US).

`execution-while-not-rendered`

Controla se as tarefas devem ser executadas em enquadramentos enquanto não são renderizados (e.g. se um enquadramento é `hidden` ou `display: none`).

`execution-while-out-of-viewport`

Controla se as tarefas devem ser executadas em enquadramentos enquanto eles estão fora da janela de visualização visível.

`fullscreen` (en-US)

Controla se o documento atual é permitido de usar `Element.requestFullScreen()` (en-US). Quando esta política está desabilitada, a `Promise` retornada rejeita com um `TypeError` `DOMException` (en-US).

`geolocation` (en-US)

Controla se o documento atual é permitido de usar a interface `Geolocation`. Quando a política está desabilitada, chamadas para `getCurrentPosition()` e `watchPosition()` irão causar aos *callbacks* da funções serem invocados com um `PositionError` de `PERMISSION_DENIED`.

`gyroscope` (en-US)

Controla se o documento atual é permitido de coletar informação sobre a orientação do dispositivo através da interface `Gyroscope` (en-US).

`layout-animations` (en-US)

Controla se o documento atual é permitido de mostrar animações de *layout*.

`legacy-image-formats` (en-US)

Controla se o documento atual é permitido de mostrar imagens em formatos legados.

`magnetometer` (en-US)

Controla se o documento atual é permitido de coletar informação sobre a orientação do dispositivo através da interface `Magnetometer` (en-US).

`microphone` (en-US)

Controla se o documento atual é permitido de usar entradas de dispositivos de áudio. Quando esta política está desabilitada, a `Promise` retornada pelo `MediaDevices.getUserMedia()` (en-US) irá rejeitar com um `NotAllowedError`.

`midi` (en-US)

Controla se o documento atual é permitido de usar a API Web MIDI (en-US). Quando esta política está desabilitada, a `Promise` retornada pelo `Navigator.requestMIDIAccess()` (en-US) irá rejeitar com um `DOMException` (en-US).

`navigation-override`

Controla a disponibilidade de mecanismos que habilitam o autor da página a tomar controle sobre o comportamento da navegação espacial (spatial navigation), ou cancelar completamente.

`oversized-images` (en-US)

Controla se o documento atual é permitido de baixar e mostrar imagens grandes.

`payment` (en-US)

Controla se o documento atual permite o uso da API de Requisição de Pagamento (*Payment Request API*) (en-US). Quando esta política está desabilitada, o construtor `PaymentRequest()` (en-US) irá jogar um `SecurityError` `DOMException` (en-US).

`picture-in-picture` (en-US)

Controla se o documento atual permite que um vídeo seja permitido tocar no modo *Picture-in-Picture* através da API correspondente.

`publickey-credentials-get` (en-US)

Controla se o documento atual é permitido de usar a API de Autenticação Web (en-US) para resgatar credenciais de chave pública já guardadas, i.e. através do `navigator.credentials.get({publicKey: ..., ...})` (en-US).

`sync-xhr` (en-US)

Controla se o documento atual é permitido de fazer requisições síncronas `XMLHttpRequest`.

`usb` (en-US)

Controla se o documento atual é permitido de usar a API WebUSB.

`vr` (en-US)
Deprecated

Controla se o documento atual é permitido de usar a API WebVR. Quando esta política é desabilitada, o `Promise` retornado pelo `Navigator.getVRDisplays()` (en-US) irá rejeitar com um `DOMException` (en-US). Tenha em mente que o padrão WebVR está em processo de ser substituído pelo WebXR (en-US).

`wake-lock` (en-US)

Controla se o documento atual é permitido de usar a API Wake Lock para indicar que o dispositivo não deve entrar em modo de economia de energia.

`screen-wake-lock` (en-US)

Controla se o documento atual é permitido de utilizar a API Screen Wake Lock (en-US) para indicar se o dispositivo deve ou não escurecer a tela.

`xr-spatial-tracking` (en-US)

Controla se o documento atual é permitido ou não de usar a API WebXR Device (en-US) para intergir com a sessão WebXR.

Exemplos
--------

SecureCorp Inc. quer desabilitar o Microfone e as APIs de Geolocalização em sua aplicação. Isso pode ser feito entregando o seguinte cabeçalho de resposta HTTP para definir a política de funcionalidade:
```

Feature-Policy: microphone 'none'; geolocation 'none'
```

Especificando a palavra-chave `'none'` para a lista de origem, as funcionalidades especificadas serão desabilitadas para todos os contextos de navegaçnao (incluindo todos os *iframes*), independente da origem.

Especificações
--------------

| Specification |
| --- |
| Permissions Policy # permissions-policy-http-header-field |

Compatibilidade com navegadores
-------------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Veja também
-----------

* Feature Policy (en-US)
* Usando Feature Policy
* `Document.featurePolicy` (en-US) and `FeaturePolicy` (en-US)
* Feature-Policy Tester (Chrome Developer Tools extensão)
* `Content-Security-Policy`
* `Referrer-Policy`


If-None-Match - HTTP

If-None-Match
=============

O cabeçalho de requisição HTTP **`If-None-Match`** faz uma requisição condicional. Para os métodos `GET` e `HEAD`, o servidor irá mandar de volta o recurso requisitado, com um código de status `200`, somente se ele não tiver um `ETag` correspondendo as *tags* dadas pela requisição. Para outros métodos, a requisição será processada somente o recurso existente eventualmente não possuir nenhuma `ETag` correspondente nos valores listados.

Quando a condição falha para métodos `GET` e `HEAD`, então o servidor deve retornar um código de status HTTP 304 (Not Modified). Para outros métodos que aplicam mudanças no lado do servidor, o código de status 412 (Precondition Failed) é utilizado. Note que o servidor gerando uma resposta 304 DEVE gerar qualquer um dos seguintes cabeçalhos que seriam enviados em uma resposta 200 (OK) para a mesma requisição: Cache-Control, Content-Location, Date, ETag, Expires, and Vary.

A comparação com a `ETag` guardada usa o *algoritmo de comparação fraco*, significa que dois arquivos são considerados idênticos se o conteúdo é equivalente — eles não precisam ser idênticos *byte* por *byte*. Por exemplo, duas páginas que diferem pela data de sua geração no rodapé ainda assim serão consideradas como idênticas.

Quando usado em combinação com `If-Modified-Since`, **`If-None-Match`** tem precedência (se o servidor suporta isso).

Existem dois casos de uso comuns:

* Para métodos `GET` e `HEAD`, para atualizar uma entidade cacheada que possui um `ETag` associado.
* Para outros métodos, e em particular para `PUT`, `If-None-Match` usado com o valor `*` pode ser utilizado para salvar um arquivo que não se sabia existir, garantindo que outro *upload* não tenha acontecido anteriormente, perdendo os dados do *PUT* anterior; esse problema é uma variação do problema de perda de atualização.

|  |  |
| --- | --- |
| Tipo de cabeçalho | Request header |
| Forbidden header name | não |

Sintaxe
-------
```

If-None-Match: "<etag_value>"
If-None-Match: "<etag_value>", "<etag_value>", …
If-None-Match: *
```

Diretivas
---------

<etag\_value>

*Tags* de entidade que representam unicamente os recursos requisitados. Eles são uma cadeia de caracteres ASCII colocados entre aspas duplas (como `"675af34563dc-tr34"`). Elas podem ser prefixadas por `W/` para indicar que o *algoritmo de comparação fraco* deve ser utilizado (Isso é inútil com `If-None-Match` por ele utilizar somente este algoritmo).

`*`

O asterísco é um valor especial representando qualquer recurso. Eles somente são úteis quando fazendo o *upload* de um recurso, geralmente com `PUT`, para checar se outro recurso com a identidade já teve seu *upload* feito anteriormente.

Exemplos
--------
```

If-None-Match: "bfc13a64729c4290ef5b2c2730249c88ca92d82d"

If-None-Match: W/"67ab43", "54ed21", "7892dd"

If-None-Match: *
```

Especificações
--------------

| Especificação | Título |
| --- | --- |
| RFC 7232, sessão 3.2: If-None-Match | Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests |

Compatibilidade com navegadores
-------------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Veja também
-----------

* `ETag`
* `If-Unmodified-Since`
* `If-Modified-Since`
* `If-Match`
* `304` `Not Modified`
* `412` `Precondition Failed`


Last-Modified - HTTP

Last-Modified
=============

A linha de cabeçalho **`Last-Modified`** do cabeçalho de resposta HTTP contém a data e a hora em que o servidor de origem acredita que o recurso foi modificado pela última vez. É usado como um validador para determinar se um recurso recebido ou armazenado é o mesmo. Menos preciso do que um cabeçalho `ETag`, é um mecanismo de retorno. Os pedidos condicionais `If-Modified-Since` or `If-Unmodified-Since` fazem uso deste campo.

|  |  |
| --- | --- |
| Header type | Response header (en-US) |
| Forbidden header name | no |
| CORS-safelisted response-header (en-US) | yes |

Syntax
------
```

Last-Modified: <day-name>, <day> <month> <year> <hour>:<minute>:<second> GMT
```

Directives
----------

<day-name>

One of "Mon", "Tue", "Wed", "Thu", "Fri", "Sat", or "Sun" (case-sensitive).

<day>

2 digit day number, e.g. "04" or "23".

<month>

One of "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" (case sensitive).

<year>

4 digit year number, e.g. "1990" or "2016".

<hour>

2 digit hour number, e.g. "09" or "23".

<minute>

2 digit minute number, e.g. "04" or "59".

<second>

2 digit second number, e.g. "04" or "59".

`GMT`

Greenwich Mean Time. HTTP dates are always expressed in GMT, never in local time.

Examples
--------
```

Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT
```

Specifications
--------------

| Specification | Title |
| --- | --- |
| RFC 7232, sessão 2.2: Last-Modified | Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests |

Compatibilidade com navegadores
-------------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `If-Modified-Since`
* `If-Unmodified-Since`
* `Etag`


Link - HTTP

Link
====

O cabeçalho de entidade **`Link`** provém maneiras para serializar um ou mais links em cabeçalhos HTTP. Ele é semanticamente equivalente ao elemento HTML `<link>`.

Sintaxe
-------
```

Link: < uri-reference >; param1=value1; param2="value2"
```

`<uri-reference>`

A referência da URI, precisa ser encapsulado entre `<` e `>`.

### Parâmetros

O cabeçalho *link* contém parâmetros, os quais são separados com `;` e são equivalentes aos atributos do elemento `<link>`.

Exemplos
--------

A URI precisa ser encapsulado entre `<` e `>`:

```http
Link: <https://example.com>; rel="preconnect"
```

```http
Link: https://bad.example; rel="preconnect"
```

### Especificando múltiplos *links*

Você pode especificar múltiplos *links* separados por vírgulas, por exemplo:
```

Link: <https://one.example.com>; rel="preconnect", <https://two.example.com>; rel="preconnect", <https://three.example.com>; rel="preconnect"
```

Especificações
--------------

| Especificação | Status | Comentários |
| --- | --- | --- |
| RFC 8288, sessão 3: Link Serialisation in HTTP Headers | IETF RFC |  |
| RFC 5988, sessão 5: The Link Header Field | IETF RFC | Definição inicial |

Compatibilidade com navegadores
-------------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Veja também
-----------

* `103 Early Hints`


Origin - HTTP

Origin
======

O cabeçalho de requisição **`Origin`** indica onde a requisição se originou. Ele não inclui nenhuma informação do caminho, somente o nome do servidor. Ele é enviado com requisições CORS, também como requisições `POST`. Ele é similar ao cabeçalho `Referer`, mas, diferente deste cabeçalho, ele não mostra o caminho inteiro.

**Nota:** O cabeçalho `Origin` não é colocado em requisições Fetch com um método `HEAD` ou `GET` (este comportamento foi corrigido no Firefox 65 — veja Erro do Firefox 1508661).

|  |  |
| --- | --- |
| Tipo de cabeçalho | Request header |
| Forbidden header name | sim |

Sintaxe
-------
```

Origin: null
Origin: <scheme> "://" <hostname> [ ":" <port> ]
```

Diretivas
---------

<scheme>

O protocolo que é usado. Usualmente ele é o protocolo HTTP ou na sua versão segura, HTTPS.

<hostname>

O nome do domínio do servidor (para *host* virtual) ou o endereço IP.

<port> Optional

O número da porta TCP que o servidor está escutando. Se a porta não é dada, a porta padrão do serviço requisitado é implítica (e.g., "80" para uma URL HTTP).

Exemplos
--------
```

Origin: https://developer.mozilla.org
```

Especificações
--------------

| Specification |
| --- |
| The Web Origin Concept # section-7 |
| Fetch Standard # origin-header |

Compatibilidade com navegadores
-------------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Veja também
-----------

* `Host`
* `Referer`
* Same-origin policy (en-US)


Clear-Site-Data - HTTP

Clear-Site-Data
===============

O cabeçalho HTTP **`Clear-Site-Data`** limpa os dados de navegação (*cookies*, armazenamento, *cache*) associados com o site requisitado. Ele permite desenvolvedores web terem maior controle sobre os dados armazenados localmente pelo navegador para suas origens.

|  |  |
| --- | --- |
| Tipo de cabeçalho | Response header (en-US) |
| Forbidden header name | não |

Sintaxe
-------

O cabeçalho `Clear-Site-Data` aceita uma ou mais diretivas. Se todos os dados devem ser limpos, a diretiva coringa (`"*"`) pode ser usada.
```

// Diretiva única
Clear-Site-Data: "cache"

// Múltiplas diretivas (separado por vírgula)
Clear-Site-Data: "cache", "cookies"

// Coringa
Clear-Site-Data: "*"
```

Diretivas
---------

**Nota:** Todas as diretivas devem estar de acordo com a gramática de cadeia de caracteres com as aspas. A diretiva que não inclui aspas duplas é inválida.

`"cache"`

Indica que o servidor quer remover localmente os dados cacheados (i.e. o cache do navegador, veja HTTP caching) para a URL de origem da resposta. Dependendo do navegador, essa diretiva pode acabar apagando outras coisas como páginas pré-renderizadas, *scripts* armazenados, shaders WebGL ou sugestões na barra de endereço.

`"cookies"`

Indica que o servidor quer remover todos os *cookies* da URL de origem da resposta. Credenciais de autenticação HTTP também são limpas. Isso afeta o registro inteiro do domínio, incluindo subdomínios. Então, `https://example.com` também como `https://stage.example.com`, terão seus *cookies* limpos.

`"storage"`

Indica que o servidor quer remover todo o armezenamento DOM para a URL de origem da resposta. Isso incluí mecanismos de armazenamento como:

* localStorage (executa `localStorage.clear`),
* sessionStorage (executa `sessionStorage.clear`),
* IndexedDB (para cada banco de dados, executa `IDBFactory.deleteDatabase` (en-US)),
* Registros de serviços de trabalhadores (para cada registro de serviço de trabalhador, executa `ServiceWorkerRegistration.unregister` (en-US)),
* AppCache,
* Banco de dados WebSQL,
* FileSystem API data (en-US),
* Dados de plugin (Flash via `NPP_ClearSiteData`).

`"executionContexts"`

Indica que o servidor quer recarregar todos os contextos do navegador da origem da resposta (`Location.reload`).

`"*"` (coringa)

Indica que o servidor quer limpar todos os tipos de dados da origem da resposta. Se mais tipos de dados forem adicionados nesse cabeçalho, eles também serão cobertos.

Exemplos
--------

### Deslogar de um site

Se um usuário se desloga de um site ou serviço, você talvez queira remover dados armazenados localmente. Você pode atingir isso adicionando o cabeçalho `Clear-Site-Data` quando enviando a página confirmando o desligamento da autenticação da pessoa do site foi feito com sucesso (`https://example.com/logout`, por exemplo):
```

Clear-Site-Data: "cache", "cookies", "storage", "executionContexts"
```

### Limpando cookies

Se o cabeçalho é entregue com a resposta em `https://example.com/clear-cookies`, todos os *cookies* no mesmo domínio e qualquer subdomínio (como `https://stage.example.com`, etc), serão limpos.
```

Clear-Site-Data: "cookies"
```

Especificações
--------------

| Especificação | Status | Título |
| --- | --- | --- |
| Clear Site Data | Working Draft | Initial definition. |

Compatibilidade com navegadores
-------------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Veja também
-----------

* `Cache-Control`


Host - HTTP

Host
====

O cabeçalho de solicitação de **`Host`** especifica o nome de domínio do servidor (para hospedagem virtual), e (opcionalmente) o número da porta TCP no qual o servidor está escutando.

Se nenhuma porta for fornecida a porta padrão para o serviço solicitado (por exemplo, "80" para um HTTP URL) está implícita.

Um campo de cabeçalho de `Host` deve ser enviado em todas as mensagens desolicitação HTTP / 1. 1. Um código de status `400` (Bad Request) será enviado para qualquer mensagem de solicitação HTTP/1.1 que não contenha um campo de cabeçalho do host ou contenha mais de um.

|  |  |
| --- | --- |
| Header type | Request header |
| Forbidden header name | yes |

Syntax
------
```

Host: <host>:<port>
```

Directives
----------

<host>

the domain name of the server (for virtual hosting).

<port> Optional

TCP port number on which the server is listening.

Examples
--------
```

Host: developer.mozilla.org
```

Specifications
--------------

| Specification | Title |
| --- | --- |
| RFC 7230, sessão 5.4: Host | Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing |

Compatibilidade com navegadores
-------------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `400`


Cookie - HTTP

Cookie
======

O cabeçalho de requisição HTTP **`Cookie`** contém cookies HTTP armazenados anteriormente que foram enviados pelo servidor com o cabeçalho `Set-Cookie`.

O cabeçalho `Cookie` é opicional e pode ser omitido se, por exemplo, as configurações de privacidade do navegador bloqueiam *cookies*.

|  |  |
| --- | --- |
| Tipo de cabeçalho | Request header |
| Forbidden header name | sim |

Sintaxe
-------
```

Cookie: <cookie-list>
Cookie: name=value
Cookie: name=value; name2=value2; name3=value3
```

<cookie-list>

Uma lista de pares nome-valor na forma de `<cookie-name>=<cookie-value>`. Pares na lista são separados por ponto e vírgula e um espaço (`'; '`).

Exemplos
--------
```

Cookie: PHPSESSID=298zf09hf012fh2; csrftoken=u32t4o3tb3gg43; _gat=1;
```

Especificações
--------------

| Especificação | Título |
| --- | --- |
| RFC 6265, sessão 5.4: Cookie | HTTP State Management Mechanism |

Compatibilidade com navegadores
-------------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Veja também
-----------

* `Set-Cookie`
* `Document.cookie` (en-US)


Forwarded - HTTP

Forwarded
=========

O cabeçalho **`Forwarded`** contém informação dos servidores de proxy reverso (en-US) que é alterada ou perdida quando um proxy está envolvido no caminho da requisição.

A versão alternativa e de fato padrão deste cabeçalho são os cabeçalhos `X-Forwarded-For`, `X-Forwarded-Host` e `X-Forwarded-Proto`.

Este cabeçalho é utilizado para depuração, estatísticas, e gerar conteúdo localmente dependente e por design ele expõe informações privadas sensíveis, como o endereço IP do cliente. Sendo assim, a privacidade do usuário deve sempre estar em mente quando utilizando este cabeçalho.

|  |  |
| --- | --- |
| Tipo de cabeçalho | Request header |
| Forbidden header name | não |

Sintaxe
-------
```

Forwarded: by=<identifier>;for=<identifier>;host=<host>;proto=<http|https>
```

Diretivas
---------

<identifier>

Um identificador divulgando a informação que é alterada ou perdida usando um proxy. Ela pode ser tanto:

* um endereço IP (v4 ou v6, opicionalmente com a porta, e IPv6 encapsulado por colchetes e aspas),
* um identificador ofuscado (como um "\_hidden" ou "\_secret"),
* ou "unknown" (desconhecido) quando a entidade precedente não é conhecida (e você ainda quer indicar que aquela repassagem da requisição foi feita).

by=<identifier>

A interface onde a requisição chegou ao servidor proxy.

for=<identifier>

O cliente que iniciou a requisição e subsequentes proxies na cadeia de proxies.

host=<host>

O cabeçalho de requisição `Host` como foi recebido pelo proxy.

proto=<http|https>

Indica qual protocolo foi usado para fazer a requisição (tipicamente "http" ou "https").

Exemplos
--------

### Usando o cabeçalho `Forwarded`
```

Forwarded: for="_mdn"

# sem sensibilidade de capitalização
Forwarded: For="[2001:db8:cafe::17]:4711"

# separado por ponto e vírgula
Forwarded: for=192.0.2.60;proto=http;by=203.0.113.43

# múltiplos valores podem ser concatenados usando uma vírgula
Forwarded: for=192.0.2.43, for=198.51.100.17
```

### Transicionando de `X-Forwarded-For` para `Forwarded`

Se a sua aplicação, servidor, ou proxy suporta o cabeçalho padrozinado `Forwarded`, o cabeçalho `X-Forwarded-For` pode então ser substituído. Note que o endereço IPv6 está entre colchetes e aspas em `Forwarded`.
```

X-Forwarded-For: 123.34.567.89
Forwarded: for=123.34.567.89

X-Forwarded-For: 192.0.2.43, "[2001:db8:cafe::17]"
Forwarded: for=192.0.2.43, for="[2001:db8:cafe::17]"
```

Especificações
--------------

| Especificação | Título |
| --- | --- |
| RFC 7239, sessão 4: Forwarded | Forwarded HTTP Extension |

Compatibilidade com navegadores
-------------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Veja também
-----------

* `X-Forwarded-For`
* `X-Forwarded-Host`
* `X-Forwarded-Proto`
* `Via` – provém informação sobre o proxy em si, não sobre o cliente conectando a ele.


Content-Length - HTTP

Content-Length
==============

O cabeçalho de entidade **`Content-Length`** indica o tamanho do corpo da entidade, em bytes, enviado ao destinatário.

|  |  |
| --- | --- |
| Tipo de cabeçalho | Entity header |
| Forbidden header name | sim |

Sintaxe
-------
```

Content-Length: <tamanho>
```

Diretivas
---------

<tamanho>

O tamanho em número decimal de octetos.

Especificações
--------------

| Especificação | Título |
| --- | --- |
| RFC 7230, sessão 3.3.2: Content-Length | Protocolo de Transferência de Hypertexto (HTTP/1.1): Sintaxe de mensagem e Roteamento |

Compatibilidade com navegadores
-------------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Veja também
-----------

* `Transfer-Encoding`


Access-Control-Allow-Origin - HTTP

Access-Control-Allow-Origin
===========================

O **`Access-Control-Allow-Origin`** cabeçalho de resposta indica se os recursos da resposta podem ser compartilhados com a origin dada.

|  |  |
| --- | --- |
| Tipo de cabeçalho | Response header (en-US) |
| Forbidden header name | no |

Sintaxe
-------
```

Access-Control-Allow-Origin: *
Access-Control-Allow-Origin: <origin>
```

Diretivas
---------

`*`

Para as requisições sem credenciais, o servidor pode especificar "\*" como um curinga, permitindo assim que qualquer origem acesse o recurso.

`<origin>`

Especifica a URI que pode acessar o recurso.

Exemplos
--------

Para permitir que qualquer origin acesse o seu recurso, você pode especificar desta forma:
```

Access-Control-Allow-Origin: *
```

Para permitir que `https://developer.mozilla.org` acesse seu recurso, você pode especificar:
```

Access-Control-Allow-Origin: https://developer.mozilla.org
```

### CORS e caching

Se o servidor especificar um host de origem em vez de "\*", ele também deverá incluir "Origin" no cabeçalho de resposta `Vary` para indicar aos clientes que as respostas do servidor serão diferentes com base no valor da solicitação Origin cabeçalho.
```

Access-Control-Allow-Origin: https://developer.mozilla.org
Vary: Origin
```

Especificações
--------------

| Specification |
| --- |
| Fetch Standard # http-access-control-allow-origin |

Compatibilidade com navegadores
-------------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Veja também
-----------

* `Origin`
* `Vary`


Pragma - HTTP

Pragma
======

O cabeçalho genérico HTTP/1.0 **`Pragma`** é um cabeçalho de implementação específica que pode ter vários efeitos ao longo da cadeia de requisição e resposta. Ele é usado para compatibilidade retroativa com caches do HTTP/1.0 onde o cabeçalho HTTP/1.1 `Cache-Control` ainda não está presente.

**Nota:** `Pragma` não é especificado para respostas HTTP e por isso não é uma substituição confiável para o cabeçalho genérico HTTP/1.1 `Cache-Control`, apesar de ele ter o mesmo comportamento que `Cache-Control: no-cache`, se o cabeçalho `Cache-Control` for omitido na requisição. Use `Pragma` somente para compatibilidade retroativa com clientes HTTP/1.0.

|  |  |
| --- | --- |
| Tipo de cabeçalho | General header, mas o comportamente de
 resposta não é especificado e portanto específico de implementação.
  |
| Forbidden header name | não |
| CORS-safelisted response header (en-US) | sim |

Sintaxe
-------
```

Pragma: no-cache
```

Diretivas
---------

no-cache

O mesmo que `Cache-Control: no-cache`. Força os caches a mandarem uma requisição ao servidor de origem para validação antes de liberar a versão cacheada.

Exemplos
--------
```

Pragma: no-cache
```

Especificações
--------------

| Especificação | Título |
| --- | --- |
| RFC 7234, sessão 5.4: Pragma | Hypertext Transfer Protocol (HTTP/1.1): Caching |

Compatibilidade com navegadores
-------------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Veja também
-----------

* `Cache-Control`
* `Expires`


X-DNS-Prefetch-Control - HTTP

X-DNS-Prefetch-Control
======================

O cabeçalho de resposta HTTP **`X-DNS-Prefetch-Control`** controla a pré-busca de DNS, um recurso pelo qual os navegadores realizam proativamente a resolução de nomes de domínio em ambos os links que o usuário pode escolher, além de URLs para itens referenciados pelo documento, incluindo imagens , CSS, JavaScript e assim por diante.
Essa pré-busca é realizada em segundo plano, de forma que o DNS (en-US) provavelmente tenha sido resolvido quando os itens referenciados forem necessários. Isso reduz a latência quando o usuário clica em um link.

|  |  |
| --- | --- |
| Header type | Response header (en-US) |
| Forbidden header name | no |

Sintaxe
-------
```

X-DNS-Prefetch-Control: on
X-DNS-Prefetch-Control: off
```

### Diretrivas

on

Ativar pré-busca de DNS. Isso é o que os navegadores fazem, se eles suportam o recurso, quando esse cabeçalho não está presente.

off

Desativa a pré-busca de DNS. Isso é útil se você não controla o link nas páginas ou sabe que não deseja vazar informações para esses domínios.

Descrição
---------

As solicitações de DNS são muito pequenas em termos de largura de banda, mas a latência pode ser bastante alta, especialmente em redes móveis. Por meio da pré-busca especulativa de resultados de DNS, a latência pode ser reduzida significativamente em determinados momentos, como quando o usuário clica no link. Em alguns casos, a latência pode ser reduzida em um segundo.

A implementação desta pré-busca em alguns navegadores permite que a resolução de nomes de domínio ocorra em paralelo com (em vez de em série com) a busca do conteúdo real da página. Ao fazer isso, o processo de resolução de nome de domínio de alta latência não causa atrasos ao buscar conteúdo.

Os tempos de carregamento de páginas - especialmente em redes móveis - podem ser melhorados dessa maneira. Se os nomes de domínio para imagens puderem ser resolvidos antes das imagens serem solicitadas, as páginas que carregarem muitas imagens poderão ver uma melhoria de 5% ou mais no tempo de carregamento das imagens.

### Configurando a Pré-busca no Navegador

Em geral, você não precisa fazer nada para gerenciar a pré-busca. No entanto, o usuário pode querer desabilitar a pré-busca. No Firefox, isso pode ser feito configurando a preferência `network.dns.disablePrefetch` como `true`.

Além disso, por padrão, a pré-busca de nomes de host de link incorporado não é executada em documentos carregados em HTTPS. No Firefox, isso pode ser alterado configurando a preferência `network.dns.disablePrefetchFromHTTPS` como `false`.

Exemplos
--------

### Ativando e desativando a pré-busca

Você pode enviar o cabeçalho do lado do servidor X-DNS-Prefetch-Control ou de documentos individuais, usando o atributo `http-equiv` no `<meta>` elemento, assim:

```html
<meta http-equiv="x-dns-prefetch-control" content="off" />
```

Você pode reverter essa configuração configurando o `content` como "`on`".

### Forçando a procura de nomes de host específicos

Você pode forçar a pesquisa de nomes de host específicos sem fornecer âncoras específicas usando esse nome de host com o uso de `rel` no elemento `<link>` com um tipo de link de `dns-prefetch`:

```html
<link rel="dns-prefetch" href="http://www.spreadfirefox.com/" />
```

Neste exemplo, o nome de domínio "www.spreadfirefox.com" será pré-resolvido.

Da mesma forma, o elemento de link pode ser usado para resolver nomes de host sem fornecer uma URL completa, mas apenas, precedendo o nome do host com duas barras:

```html
<link rel="dns-prefetch" href="//www.spreadfirefox.com" />
```

Pré-busca forçada de nomes de host pode ser útil, por exemplo, na página inicial de um site para forçar a pré-resolução de nomes de domínio que são referenciados com frequência em todo o site, mesmo que eles não sejam usados na própria home page. Isso melhorará o desempenho geral do site, mesmo que o desempenho da página inicial não seja afetado.

Compatibilidade com navegadores
-------------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Veja também
-----------

* DNS Prefetching for Firefox (blog post)
* Google Chrome handles DNS prefetching control


Content-Type - HTTP

Content-Type
============

O cabeçalho **Content-Type** é utilizado para indicar o tipo de arquivo (en-US) do recurso.Em respostas, o `Content-Type` diz para o client qual é o tipo de conteúdo que a resposta, de fato, tem. Alguns browsers vão realizar o chamado "MIME Sniffing" em alguns casos e não vão, necessariamente, seguir o valor declarado por este cabeçalho. Para previnir este comportamento é possível definir o cabeçalho `X-Content-Type-Options` para o valor `nosniff`.Em requisições, como `POST` ou `PUT`, o client diz ao servidor qual o tipo de dado que está, de fato, sendo enviado.

|  |  |
| --- | --- |
| tipo de cabeçalho | Cabeçalho de entidade |
| Nome de cabeçalho proibido | não |
| Cabeçalho de resposta na lista segura do CORS | sim |

Sintaxe
-------
```

Content-Type: text/html; charset=utf-8
Content-Type: multipart/form-data; boundary=something
```

Diretivas
---------

`media-type`

O MIME type do recurso ou dado.

charset

O encoding da string

boundary

Para entidades do tipo multipart, a diretiva `boundary` é obrigatória. Ela consiste em uma sequencia de 1 a 70 caracteres de um conjunto conhecido por sua robustez em gateways de e-mail, e não podem terminar com espaço em branco. É utilizado para encapsular as bordas das multiplas partes da mensagem.

Exemplos
--------

### `Content-Type` em formulários HTML

Em uma requisição `POST`, resultado de uma submissão de um formulário HTML, o `Content-Type` da requisição é especificado pelo atributo `enctype` do elemento `<form>` (en-US) do HTML.

```html
<form action="/" method="post" enctype="multipart/form-data">
  <input type="text" name="description" value="some text" />
  <input type="file" name="myFile" />
  <button type="submit">Submit</button>
</form>
```

A requisição vai parecer com isto (alguns headers não importantes foram omitidos):
```

POST /foo HTTP/1.1
Content-Length: 68137
Content-Type: multipart/form-data; boundary=---------------------------974767299852498929531610575

---------------------------974767299852498929531610575
Content-Disposition: form-data; name="description"

some text
---------------------------974767299852498929531610575
Content-Disposition: form-data; name="myFile"; filename="foo.txt"
Content-Type: text/plain

(content of the uploaded file foo.txt)
---------------------------974767299852498929531610575
```

Especificações
--------------

| Especificação | Título |
| --- | --- |
| RFC 7233, sessão 4.1: Content-Type in multipart | Hypertext Transfer Protocol (HTTP/1.1): Range Requests |
| RFC 7231, sessão 3.1.1.5: Content-Type | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |

Compatibilidade com navegadores
-------------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Ver também
----------

* `Accept` e `Accept-Charset`
* `Content-Disposition`
* `206` Partial Content
* `X-Content-Type-Options`


Expect - HTTP

Expect
======

O cabeçalho de requisição HTTP **`Expect`** indica expectativas que precisão ser cumpridas pelo servidor para lidar com a requisição apropriadamente.

A única expectativa definida na especificação é `Expect: 100-continue`, para qual o servidor deve responder com:

* `100` se a informação contida no cabeçalho é suficiente para causar sucesso imediato,
* `417` (Expectativa Falhou) se ele não pode se comprometer com a expectativa; ou qualquer outro código de status 4xx caso contrário.

Por exemplo, o servidor pode rejeitar a requisição se o cabeçalho `Content-Length` for muito grande.

Navegadores comuns não enviam um cabeçalho `Expect`, mas alguns clientes como o cURL fazem isso por padrão.

|  |  |
| --- | --- |
| Tipo de cabeçalho | Request header |
| Forbidden header name | sim |

Sintaxe
-------

Nenhuma outra expectativa exceto "100-continue" foi especificada atualmente.
```

Expect: 100-continue
```

Diretivas
---------

100-continue

Informa os receptores que o cliente está para mandar uma mensagem com corpo (presumidamente grande) na requisição e deseja receber um código de status `100` (Continue) como resposta interina.

Exemplos
--------

### Mensagem de corpo grande

Um cliente envia uma requisição com cabeçalho Expect e aguarda a resposta do servidor antes de mandar o corpo da mensagem.
```

PUT /somewhere/fun HTTP/1.1
Host: origin.example.com
Content-Type: video/h264
Content-Length: 1234567890987
Expect: 100-continue
```

O servidor checa os cabeçalhos da requisição e responde com uma resposta `100` (Continue) para instruir o cliente a continuar e enviar o corpo da mensagem, ou ele irá mandar um código de status `417` (Expectativa Falhou) se qualquer uma das expectativas não pode ser cumprida.

Especificações
--------------

| Especificação | Título |
| --- | --- |
| RFC 7231, sessão 5.1.1: Expect | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |

Compatibilidade com navegadores
-------------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Veja também
-----------

* `417` `Expectation Failed`
* `100` `Continue`


Content-Location - HTTP

Content-Location
================

O cabeçalho **`Content-Location`** indica uma localização alternativa para os dados retornados. O principal uso é para indicar o URL de um recurso transmitido como resultado de uma negociação de conteúdo.

`Location` e `Content-Location` são diferentes. `Location` indica o URL de um redirecionamento, enquanto `Content-Location` indica o URL direto usado para acessar o recurso, sem qualquer outra negociação de conteúdo no futuro. `Location` é um cabeçalho associado com a resposta, enquanto `Content-Location` é associado com os dados retornados. Essa distinção parece abstrata sem exemplos. Essa distinção pode parecer abstrata sem exemplos.

|  |  |
| --- | --- |
| Tipo de cabeçalho | Entity header |
| Forbidden header name | no |

Sintaxe
-------
```

Content-Location: <url>
```

Diretivas
---------

<url>

Uma URL relativa (en-US) (à URL da requisição) ou URL absoluta (en-US).

Exemplos
--------

### Requerindo dados de um servidor em diferentes formatos

Digamos que uma API de um site pode retornar dados em formatos JSON, XML, ou CSV. Se a URL para um documento em particular está em `https://example.com/documents/foo`, o site pode retornar diferentes URLs para `Content-Location` dependendo do cabeçalho `Accept` nas requisições:

| Cabeçalho de requisição | Cabeçalho de resposta |
| --- | --- |
| `Accept: application/json, text/json` | `Content-Location: /documents/foo.json` |
| `Accept: application/xml, text/xml` | `Content-Location: /documents/foo.xml` |
| `Accept: text/plain, text/*` | `Content-Location: /documents/foo.txt` |

Estas URLs são exemplos — o site pode servir diferentes formatos de arquivos com qualquer padrão URL que ele deseje, como por exemplo, um query string parameter (en-US): `/documents/foo?format=json`, `/documents/foo?format=xml`, entre outros.

Então o cliente pode lembrar que a versão JSON está disponível em uma URL em particular, evitando negociação de conteúdo da próxima vez que ele requerer aquele documento.

O servidor também pode considerar outros cabeçalhos de negociação de conteúdo, como o `Accept-Language`.

### Apontando para um novo documento (HTTP 201 Created)

Digamos que você está criando um novo *post* no blog através da API do site:
```

PUT /new/post
Host: example.com
Content-Type: text/markdown

# Meu primeiro post no blog!

Eu fiz através da API do `example.com`. Espero que ele tenha funcionado.
```

O site retorna uma mensagem de sucesso genérica confirmando que o *post* foi publicado. O servidor especifica onde o novo *post* está com `Content-Location`:
```

HTTP/1.1 201 Created
Content-Type: text/plain; charset=utf-8
Content-Location: /meu-primeiro-post-no-blog

✅ Sucesso!
```

### Indicando a URL do resultado de uma transação

Digamos que você tem um `<form>` (en-US) para enviar dinheiro para outro usuário do de um site.

```html
<form action="/mandar-pagamento" method="post">
  <p>
    <label
 >Para quem você quer enviar o dinheiro?
      <input type="text" name="destinatario" />
    </label>
  </p>

  <p>
    <label
 >Quanto?
      <input type="number" name="quantidade" />
    </label>
  </p>

  <button type="submit">Enviar Dinheiro</button>
</form>
```

Quando o formulário é submetido, o site gera um recibo para a transação. O servidor pode usar `Content-Location` para indicar a URL do recibo para acesso futuro.
```

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Location: /meus-recibos/38

<!doctype html>
(Um monte de HTML…)

<p>Você mandou R$38.00 para UsuárioExemplo.</p>

(Mais um monte de HTML…)
```

Especificações
--------------

| Especificação | Título |
| --- | --- |
| RFC 7231, sessão 3.1.4.2: Content-Location | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |

Compatibilidade com navegadores
-------------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Veja também
-----------

* `Location`


Content-Range - HTTP

Content-Range
=============

O cabeçalho de resposta HTTP **`Content-Range`** indica em que lugar uma mensagem parcial pertence em uma mensagem completa no corpo.

|  |  |
| --- | --- |
| Tipo de cabeçalho | Response header (en-US) |
| Forbidden header name | não |
| CORS-safelisted response-header (en-US) | não |

Sintaxe
-------
```

Content-Range: <unit> <range-start>-<range-end>/<size>
Content-Range: <unit> <range-start>-<range-end>/*
Content-Range: <unit> */<size>
```

Diretivas
---------

<unit>

A unidade nos quais a variação é especificada. Geralmente em `bytes`.

<range-start>

Um inteiro na dada unidade indicando o começo da variação da requisitada.

<range-end>

Um inteiro na dada unidade indicando o fim da variação requisitada.

<size>

O tamanho total do documento (ou `'*'` se desconhecido).

Exemplos
--------
```

Content-Range: bytes 200-1000/67589
```

Especificações
--------------

| Especificação | Título |
| --- | --- |
| RFC 7233, sessão 4.2: Content-Range | Hypertext Transfer Protocol (HTTP/1.1): Range Requests |

Compatibilidade com navegadores
-------------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Veja também
-----------

* `If-Range`
* `Range`
* `Content-Type`
* `206` `Partial Content`
* `416` `Range Not Satisfiable`


DPR - HTTP

DPR
===

**Secure context:** This feature is available only in secure contexts (en-US) (HTTPS), in some or all supporting browsers.

**Experimental:** **Esta é uma tecnologia experimental (en-US)**
Verifique a tabela de compatibilidade entre Navegadores cuidadosamente antes de usar essa funcionalidade em produção.

O cabeçalho **`DPR`** é um cabeçalho de requisição *Client Hints (en-US)* que representa a razão de pixeis do dispositivo do cliente, por isso (DPR)(*device pixel ratio*), que é o número de pixeis físicos do dispositivo correspondendo a cada pixel CSS.

|  |  |
| --- | --- |
| Tipo de cabeçalho | Request header |
| Forbidden header name | ? |

**Nota:** *Client Hints* são acessíveis somente em origens seguras (via TLS). Servidor deve optar em receber um cabeçalho `DPR` do cliente enviando cabeçalhos de resposta `Accept-CH` e `Accept-CH-Lifetime`.

Sintaxe
-------
```

DPR: <number>
```

Exemplos
--------

O servidor primeiro optar por receber o cabeçalho `DPR` enviando os cabeçalhos de resposta `Accept-CH` contendo `DPR` e `Accept-CH-Lifetime`.
```

Accept-CH: DPR
Accept-CH-Lifetime: 86400
```

Então as requisições subsequentes do cliente podem enviar o cabeçalho `DPR` de volta:
```

DPR: 1.0
```

Compatibilidade com navegadores
-------------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Veja também
-----------

* `Accept-CH`
* `Accept-CH-Lifetime`
* `Vary`


From - HTTP

From
====

O cabeçalho de requisição **`From`** contém um endereço de email da Internet para um usuário humano que controla o agente de usuário requisitante poder enviar uma mensagem.

Se você está rodando um agente de usuário robótico (e.g. um *crawler*), o cabeçalho `From` deve ser enviado, para que você possa contatar se problemas ocorrerem em servidores, como por exemplo, o robô estar enviando requisições excessivas, não desejadas ou inválidas.

**Aviso:** Você não deve usar o cabeçalho `From` para controle de acesso ou autenticação.

|  |  |
| --- | --- |
| Tipo de cabeçalho | Request header |
| Forbidden header name | não |

Sintaxe
-------
```

From: <email>
```

Directives
----------

<email>

Um endereço de email utilizável para mensagens serem enviadas.

Exemplos
--------
```

From: webmaster@example.org
```

Especificações
--------------

| Especificação | Título |
| --- | --- |
| RFC 7231, sessão 5.5.1: From | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |

Compatibilidade com navegadores
-------------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Veja também
-----------

* `Host`


Location - HTTP

Location
========

O cabeçalho de resposta **`Location`** indica o URL para qual página deve-se ser redirecionada. Ele só tem significado quando é enviado junto a uma resposta de status `3xx` (redirecionamento) ou `201` (criado).

Em casos de redirecionamento, o método HTTP utilizado para fazer a nova requisição à página apontada pelo cabeçalho `Location` depende do método original e do tipo de redirecionamento:

* Se respostas com status `303` (Veja também) sempre levam ao uso do método `GET`, `307` (Redirecionamento Temporário) e `308` (Redirecionamento Permanente) não mudam o método utilizado na requisição original;
* `301` (Movido Permanentemente) e `302` (Encontrado) não mudam o método na maior parte das vezes, entretanto agentes de usuário antigos talvez mudem (basicamente você não sabe se eles farão isso).

Todas as respostas com um desses códigos de status enviam um cabeçalho `Location`.

Em casos de recursos de criação, ele indica o URL para o novo recurso criado.

`Location` e `Content-Location` são diferentes: `Location` indica o alvo de redirecionamento (ou URL do novo recurso criado), enquanto `Content-Location` indica o URL direto para ter acesso ao recurso quando negociação de conteúdo acontecer, sem a necessidade de futura negociação de conteúdo. `Location` é um cabeçalho associado com a resposta, enquanto `Content-Location` é associado com a entidade retornada.

|  |  |
| --- | --- |
| Tipo de cabeçalho | Response header (en-US) |
| Forbidden header name | não |

Sintaxe
-------
```

Location: <url>
```

Diretivas
---------

<url>

Uma URL relativa (ao URL de requisição) ou absoluta.

Exemplos
--------
```

Location: /index.html
```

Especificações
--------------

| Especificação | Título |
| --- | --- |
| RFC 7231, sessão 7.1.2: Location | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |

Compatibilidade com navegadores
-------------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Veja também
-----------

* `Content-Location`
* Código de status de respostas que incluem o cabeçalho `Location`: `201`, `301`, `302`, `303`, `307`, `308`.


Age - HTTP

Age
===

O cabeçalho **`Age`** contém o tempo, em segundos, em que o objeto já está no *cache* de um proxy.

O cabeçalho `Age` é normalmente perto de zero. Se `Age: 0`, é provável que ele tenha acabado de ser obtido do servidor de origem; senão, é normalmente calculado como a diferença entre a data corrente do proxy e o cabeçalho genérico `Date` incluído na resposta HTTP.

|  |  |
| --- | --- |
| Tipo de cabeçalho | Response header (en-US) |
| Forbidden header name | não |

Sintaxe
-------
```

Age: <delta-seconds>
```

Diretivas
---------

<delta-seconds>

Um inteiro não-negativo, representando o tempo em segundos em que o objeto já está no *cache* do proxy.

Exemplos
--------
```

Age: 24
```

Especificações
--------------

| Especificação | Título |
| --- | --- |
| RFC 7234, sessão 5.1: Age | Hypertext Transfer Protocol (HTTP/1.1): Caching |

Compatibilidade com navegadores
-------------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Veja também
-----------

* `Cache-Control`
* `Expires`


DNT - HTTP

DNT
===

O cabeçalho de requisição **`DNT`** (**D**o **N**ot **T**rack) indica a preferência do usuário de permitir ser "seguido". Ele indica se o usuário prefere privacidade ao invés de conteúdo personalizado.

|  |  |
| --- | --- |
| Tipo de cabeçalho | Request header |
| Forbidden header name | sim |

Sintaxe
-------
```

DNT: 0
DNT: 1
```

Diretivas
---------

0

O usuário prefere **permitir** ser seguido no site alvo.

1

O usuário prefere **não permitir** ser seguido no site alvo.

Exemplos
--------

### Lendo status Do Not Track status do JavaScript

A preferência DNT do usuário também pode ser lida do JavaScript usando a propriedade `Navigator.doNotTrack` (en-US):

```js
navigator.doNotTrack; // "0" or "1"
```

Especificações
--------------

#### No specification found

No specification data found for `http.headers.DNT`.
Check for problems with this page or contribute a missing `spec_url` to mdn/browser-compat-data. Also make sure the specification is included in w3c/browser-specs.

Compatibilidade com navegadores
-------------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Veja também
-----------

* `Navigator.doNotTrack` (en-US)
* Cabeçalho `Tk`
* Do Not Track no Wikipedia
* What Does the "Track" in "Do Not Track" Mean? – EFF
* donottrack.us
* Ajuda das configurações DNT dos navegadores:
    + Firefox
    + Chrome


Allow - HTTP

Allow
=====

O cabeçalho de resposta **`Allow`** lista um conjunto de métodos suportados pelo recurso.

O cabeçalho deve ser enviado se o servidor responde com um código de resposta `405` `Method Not Allowed`, para indicar quais métodos de requisição podem ser utilizados. Um cabeçalho `Allow` vazio indica que o recurso não permite cabeçalhos de requisição, o que pode acontecer temporariamente para um dado recurso, por exemplo.

|  |  |
| --- | --- |
| Tipo de cabeçalho | Entity header |
| Forbidden header name | não |

Sintaxe
-------
```

Allow: <métodos-http>
```

Diretivas
---------

<métodos-http>

Uma lista de métodos de requisição HTTP separados por vírgula.

Exemplos
--------
```

Allow: GET, POST, HEAD
```

Especificações
--------------

| Especificação | Título |
| --- | --- |
| RFC 7231, sessão 7.4.1: Allow | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |

Veja também
-----------

* `405`
* `Server`


Digest - HTTP

Digest
======

O cabeçalho de resposta HTTP **`Digest`** provém uma digest (en-US) do recurso requisitado.

Nos termos da RFC 7231 esta é a *representação selecionada* de um recurso. A representação selecionada depende dos valores dos cabeçalhos `Content-Type` e `Content-Encoding`: então um único recurso pode ter diversos valores de "digestão".

A "digestão" é calculada através da representação inteira. A representação em si pode ser:

* totalmente contida no corpo da mensagem de resposta
* não contida no corpo da mensagem (por exemplo, na resposta para uma requisição `HEAD`)
* parcialmente contido no corpo da mensagem (por exemplo, em uma resposta para uma requisição de intervalo (en-US)).

|  |  |
| --- | --- |
| Tipo do cabeçalho | Response header (en-US) |
| Forbidden header name | não |

Sintaxe
-------
```

Digest: <digest-algorithm>=<digest-value>

Digest: <digest-algorithm>=<digest-value>,<digest-algorithm>=<digest-value>
```

Diretivas
---------

`<digest-algorithm>`

Algoritmos de digestão suportados são definidos na RFC 3230 e RFC 5843, e incluem `SHA-256` e `SHA-512`. Alguns dos algoritmos suportados, incluindo `unixsum` e `MD5` são sujeitos a colisões e não são recomendados para aplicações onde resistência à colisções é importante.

`<digest-value>`

O resultado de aplicação do algoritmo de digestão na representação do recurso e codificando o resultado. A escolha do algoritmo de digestão também determina a codificação a ser usada: por exemplo `SHA-256` usa codificação *base64*.

Exemplos
--------
```

Digest: sha-256=X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=
Digest: sha-256=X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=,unixsum=30637
```

Especificações
--------------

| Especificação | Título |
| --- | --- |
| draft-ietf-httpbis-digest-headers-latest | Resource Digests for HTTP |

Este cabeçalho foi originalmente definido na RFC 3230, mas a definição de "representação selecionada" na RFC 7231 fez com que a definição original ficasse inconsistente com as especificações atuais do HTTP. Quando lançado, o rascunho de "Digestão de recursos para HTTP" tornará a RFC 3230 obsoleta e atualizará o padrão para ser consistente.

Compatibilidade com navegadores
-------------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Veja também
-----------

* `Want-Digest`
* Requisições de intervalo HTTP (en-US)
* `206 Partial Content`


If-Match - HTTP

If-Match
========

O cabeçalho de requisição HTTP **`If-Match`** faz a requisição condicional. Para métodos `GET` e `HEAD`, o servidor irá mandar de volta o recurso requisitado somente se ele corresponde com uma das `ETags` listadas. Para `PUT` e outros métodos não-seguros, ele somente irá fazer o upload do recurso neste caso.

A comparação com a `ETag` guardada usa o *algoritmo de comparação forte*, significa dois arquivos são considerados idênticos *byte* a *byte* somente. Se a `ETag` listada com o prefixo `W/` indicando a *tag* como uma entidade fraca, ele nunca irá combinar usando este algoritmo de comparação.

Existem dois casos de uso comuns:

* Para os métodos `GET` e `HEAD`, utilizado em combinação com o cabeçalho `Range`, ele pode garantir que novos intervalos requisitados venham do mesmo recurso ao invés do anterior. Se ele não corresponde, então uma resposta `416` (Range Not Satisfiable) é retornarda.
* Para outros métodos, e em particular para o método `PUT`, `If-Match` pode ser usado para previnir o problema de perde de atualização. Ele pode checar se a modificação de um recurso que o usuário que fazer o upload não sobrescreverá outra modificação que foi feita desde que o recurso original foi buscado. Se a requisição não puder ser completada, a resposta `412` (Precondition Failed) é retornada.

|  |  |
| --- | --- |
| Tipo de cabeçalho | Request header |
| Forbidden header name | não |

Sintaxe
-------
```

If-Match: <etag_value>
If-Match: <etag_value>, <etag_value>, …
```

Diretivas
---------

<etag\_value>

*Tags* de entidade que representam unicamente os recursos requisitados. Eles são uma cadeia de caracteres ASCII colocados entre aspas duplas (como `"675af34563dc-tr34"`). Elas podem ser prefixadas por `W/` para indicar que elas são "fracas", i.e. que elas representam o recurso semânticamente, mas não byte-por-byte. Entretanto, em um cabeçalho **`If-Match`**, *tags* de entidade fraca nunca irão corresponder.

`*`

O asterísco é um valor especial representando qualquer recurso.

Exemplos
--------
```

If-Match: "bfc13a64729c4290ef5b2c2730249c88ca92d82d"

If-Match: "67ab43", "54ed21", "7892dd"

If-Match: *
```

Especificações
--------------

| Especificação | Título |
| --- | --- |
| RFC 7232, sessão 3.1: If-Match | Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests |

Compatibilidade com navegadores
-------------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Veja também
-----------

* `ETag`
* `If-Unmodified-Since`
* `If-Modified-Since`
* `If-None-Match`
* `416` `Range Not Satisfiable`
* `412` `Precondition Failed`


Early-Data - HTTP

Early-Data
==========

**Experimental:** **Esta é uma tecnologia experimental (en-US)**
Verifique a tabela de compatibilidade entre Navegadores cuidadosamente antes de usar essa funcionalidade em produção.

O cabeçalho **`Early-Data`** é colocado por um intermediário para indicar que a requisição foi transportada em dados precoces do TLS (TLS *early data*) (en-US), e também indica que o intermediário entende o código de status `425 (Too Early)`.

O cabeçalho `Early-Data` **não é** definido pelo gerador da requisição (i.e., um navegador).

|  |  |
| --- | --- |
| Tipo de cabeçalho | Request header |
| Forbidden header name | não |

Sitnaxe
-------
```

Early-Data: 1
```

Exemplos
--------
```

GET /resource HTTP/1.0
Host: example.com
Early-Data: 1
```

Especificações
--------------

| Especificação | Título |
| --- | --- |
| RFC 8470, sessão 5.1: The Early-Data Header Field | Using Early Data in HTTP |

Compatibilidade com navegadores
-------------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.


X-Frame-Options - HTTP

X-Frame-Options
===============

O cabeçalho de resposta HTTP **`X-Frame-Options`** pode ser usado para indicar se o navegador deve ou não renderizar a página em um `<frame>` (en-US), `<iframe>`, `<embed>` ou `<object>` (en-US). Sites podem usar isso para evitar ataques *click-jacking (en-US)*, assegurando que seus conteúdos não sejam embebedados em outros sites.

A segurança adicionada é provida somente se o usuário acessando o documento está usando o navegador que suporte `X-Frame-Options`.

**Nota:** O cabeçalho HTTP `Content-Security-Policy`possui uma diretiva `frame-ancestors` que torna este cabeçalho obsoleto para navegadores que o suportam.

|  |  |
| --- | --- |
| Tipo de cabeçalho | Response header (en-US) |
| Forbidden header name | não |

Sintaxe
-------

Existem duas diretivas possíveis para `X-Frame-Options`:
```

X-Frame-Options: DENY
X-Frame-Options: SAMEORIGIN
```

### Diretivas

Se você especifica `DENY`, não somente tentativas em carregar a página em um enquadramento irão falhar quando carregadas de outros sites, mas irão falhar também se forem carregadas do mesmo site. Por outro lado, se você especifica `SAMEORIGIN`, você ainda pode usar a página em um enquadramento enquanto o site que o está incluindo no enquadramento seja o mesmo servindo a página.

`DENY`

A página não pode ser mostrada em um enquadramento, independente do site que esteja tentando fazer isso.

`SAMEORIGIN`

A página só pode ser exibida em um enquadramento se for da mesma origem da página em si. A especificação deixa a cargo do navegador para decidir se esta opção se aplica ao nível mais alto, ao parente, ou à cadeia inteira, entretanto é discutido se a opção não é muito útil a não ser que todos os ancestrias estejam na mesma origem (veja Erro do Firefox 725490). Veja também Browser compatibility para mais detalhes de suporte.

`ALLOW-FROM uri`

Esta é uma diretiva obsoleta que não funciona mais em navegadores modernos. Não a utilize. Em navegadores legado que a suportam, a página pode ser mostrada em um enquadramento somente na URI de origem especificada. Note que implementação legada do Firefox isso ainda sofria do mesmo problema que a `SAMEORIGIN` sofreu — ela não checa se os enquadramentos ancestrais para ver se eles são da mesma origem. O cabeçalho HTTP `Content-Security-Policy` tem a diretiva `frame-ancestors` que você pode usar ao invés disso.

Exemplos
--------

**Nota:** Colocar X-Frame-Options dentro de um elemento `<meta>` é inútil! Por enquanto, `<meta http-equiv="X-Frame-Options" content="deny">` não tem nenhum efeito. Não o utilize! `X-Frame-Options` funciona somente colocando a configuração através do cabeçalho HTTP, como nos exemplos abaixo.

### Configurando o Apache

Para configurar o Apache para que ele envie o cabeçalho `X-Frame-Options` para todas as páginas, adicione isto nas configurações do seu site:
```

Header always set X-Frame-Options "SAMEORIGIN"
```

Para configurar o Apache para colocar o `X-Frame-Options` como DENY, adicione isto nas configurações do seu site:
```

Header set X-Frame-Options "DENY"
```

### Configurando o nginx

Para configurar o nginx para enviar o cabeçalho `X-Frame-Options`, adicione isto na configuração do seu http, servidor ou localização:
```

add_header X-Frame-Options SAMEORIGIN always;
```

### Configurando o IIS

Para configurar o IIS para enviar o cabeçalho `X-Frame-Options`, adicione isto no arquivo `Web.config` do seu site:

```xml
<system.webServer>
  ...

  <httpProtocol>
    <customHeaders>
      <add name="X-Frame-Options" value="SAMEORIGIN" />
    </customHeaders>
  </httpProtocol>

  ...
</system.webServer>
```

Ou veja este artigo de suporte de configuração da Microsoft utilizando a interface de usuário IIS Manager.

### Configurando o HAProxy

Para configurar o HAProxy para enviar o cabeçalho `X-Frame-Options`, adicione isto na sua configuração do seu *front-end*, *listen*, ou *backend*:
```

rspadd X-Frame-Options:\ SAMEORIGIN
```

Alternativamente, em versões mais novas:
```

http-response set-header X-Frame-Options SAMEORIGIN
```

### Configurando o Express

Para configurar o Express para enviar o cabeçalho `X-Frame-Options`, você pode usar o helmet que utiliza o frameguard para colocar o cabeçalho. Adicione isto na configuração do seu servidor:

```js
const helmet = require("helmet");
const app = express();
app.use(helmet.frameguard({ action: "SAMEORIGIN" }));
```

Alternativamente, você pode usar o *frameguard* diretamente:

```js
const frameguard = require("frameguard");
app.use(frameguard({ action: "SAMEORIGIN" }));
```

Especificações
--------------

| Especificação | Título |
| --- | --- |
| RFC 7034 | HTTP Header Field X-Frame-Options |

Compatibilidade com navegadores
-------------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Veja também
-----------

* `frame-ancestors` (CSP)
* Cabeçalho HTTP X-Frame-Options (HTTP Header Field X-Frame-Options) - RFC 7034
* Defesas contra ClickJacking (ClickJacking Defenses) - IEBlog
* Combatendo ClickJacking com X-Frame-Options (Combating ClickJacking with X-Frame-Options) - IEInternals


Accept-CH-Lifetime - HTTP

Accept-CH-Lifetime
==================

**Secure context:** This feature is available only in secure contexts (en-US) (HTTPS), in some or all supporting browsers.

**Experimental:** **Esta é uma tecnologia experimental (en-US)**
Verifique a tabela de compatibilidade entre Navegadores cuidadosamente antes de usar essa funcionalidade em produção.

O cabeçalho **`Accept-CH-Lifetime`** é colocado pelo servidor para especificar a persistência do valor do cabeçalho `Accept-CH`, que especifica para quais cabeçalhos Client Hints (en-US) o cliente deve incluir nas suas requisições subsequentes.

|  |  |
| --- | --- |
| Tipo de cabeçalho | Response header (en-US) |
| Forbidden header name | ? |

**Nota:** Client Hints são acessíveis somente em origens seguras (via TLS). Os cabeçalhos Accept-CH e Accept-CH-Lifetime devem ser persistidos por todas as requisições seguras para assegurar que os Client Hints são enviados com segurança.

Sintaxe
-------
```

Accept-CH-Lifetime: <age>
```

Exemplos
--------
```

Accept-CH: Viewport-Width, DPR
Accept-CH-Lifetime: 86400
```

Compatibilidade com navegadores
-------------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Veja também
-----------

* `Accept-CH`
* `Vary`


If-Unmodified-Since - HTTP

If-Unmodified-Since
===================

A requisição **`If-Unmodified-Since`** do cabeçalho HTTP realiza uma requisição condicional: o servidor enviará de volta o recurso solicitado ou o aceitará no caso de um `POST` ou non-safe método, somente se não tiver sido modificado pela última vez após a data especificada. Se a solicitação tiver sido modificada após a data já especificada, a resposta será um erro `412` (Precondition Failed).

A requisição

There are two common use cases:

* In conjunction with non-safe methods, like `POST`, it can be used to implement an optimistic concurrency control, like done by some wikis: editions are rejected if the stored document has been modified since the original has been retrieved.
* In conjunction with a range request with a `If-Range` header, it can be used to ensure that the new fragment requested comes from an unmodified document.

|  |  |
| --- | --- |
| Header type | Request header |
| Forbidden header name | no |

Sintaxe
-------
```

If-Unmodified-Since: <day-name>, <day> <month> <year> <hour>:<minute>:<second> GMT
```

Diretivas
---------

<day-name>

One of "Mon", "Tue", "Wed", "Thu", "Fri", "Sat", or "Sun" (case-sensitive).

<day>

2 digit day number, e.g. "04" or "23".

<month>

One of "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" (case sensitive).

<year>

4 digit year number, e.g. "1990" or "2016".

<hour>

2 digit hour number, e.g. "09" or "23".

<minute>

2 digit minute number, e.g. "04" or "59".

<second>

2 digit second number, e.g. "04" or "59".

`GMT`

Greenwich Mean Time. HTTP dates are always expressed in GMT, never in local time.

Exemplos
--------
```

If-Unmodified-Since: Wed, 21 Oct 2015 07:28:00 GMT
```

Especificações
--------------

| Especificação | Título |
| --- | --- |
| RFC 7232, sessão 3.4: If-Unmodified-Since | Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests |

Compatibilidade com navegadores
-------------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Veja também
-----------

* `Last-Modified`
* `If-Modified-Since`
* `If-Match`
* `If-None-Match`
* `If-Range`
* `412` `Precondition Failed`


Server-Timing - HTTP

Server-Timing
=============

O cabeçalho **`Server-Timing`** comunica uma ou mais métricas e descrições para um dado ciclo de requisição e resposta. Ele é usado para dar uma visão superficial de qualquer métrica de tempo do servidor *backend* (e.g. leitura e escrita de banco de dados, tempo de CPU, acesso ao sistema de arquivos, etc.) nas ferramentas do desenvolvedor no navegador do usuário ou na interface `PerformanceServerTiming` (en-US).

|  |  |
| --- | --- |
| Tipo de cabeçalho | Response header (en-US) |
| Forbidden header name | não |

Sintaxe
-------

A sintaxe do cabeçalho `Server-Timing` permite você comunicar métricas de diversas formas: nome da métrica do servidor somente, métrica com valor, métrica com valor e descrição, métrica com descrição.

A especificação aconselha que nomes e descrições devem ser mantidas o mais curtas possível (use abreviações e omita valores opicionais quando possível) para minimizar o sobrecarregamento HTTP.
```

// Métrica único sem valor
Server-Timing: missedCache

// Métrica única com valor
Server-Timing: cpu;dur=2.4

// Métrica única com descrição e valor
Server-Timing: cache;desc="Cache Read";dur=23.2

// Duas métricas com valor
Server-Timing: db;dur=53, app;dur=47.2

// Server-Timing como reboque (trailer)
Trailer: Server-Timing
--- response body ---
Server-Timing: total;dur=123.4
```

Privacidade e segurança
-----------------------

O cabeçalho `Server-Timing` pode expôr potenciais aplicações sensíveis e informação de infraestrutura. Considere controlar quais métricas são retornadas, quando e para quem no lado do servidor. Por exemplo, você pode mostrar métricas somente para usuários autenticados e nada para o público.

Interface PerformanceServerTiming
---------------------------------

Em adição tendo o cabeçalho `Server-Timing` de métricas aparecendo nas ferramentas de desenvolvedor do navegador, a interface `PerformanceServerTiming` (en-US) habilita ferramentas para automaticamente coletar e processar métricas do JavaScript. Essa interface é restrita para a mesma origem, mas você pode usar o cabeçalho `Timing-Allow-Origin` para especificar domínios que estão permitidos de ter acesso às métricas do servidor. A interface está somente disponível em contextos seguros (HTTPS) em alguns navegadores.

Especificações
--------------

| Specification |
| --- |
| Server Timing # the-server-timing-header-field |

Compatibilidade com navegadores
-------------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Veja também
-----------

* `PerformanceServerTiming` (en-US)


TE - HTTP

TE
==

O cabeçalho de requisição **`TE`** especifica a codificação de transferência que o agente de usuário está propício a aceitar (você poderia informalmente chamar ele de `Accept-Transfer-Encoding`, o que seria mais intuitivo).

**Nota:** Em HTTP/2 - o cabeçalho `TE` somente é aceito se o valor `trailers` é colocado.

Veja também o cabeçalho de resposta `Transfer-Encoding` para maiores detalhes sobre codificações de transferência. Note que `chunked` é sempre aceito para receptores HTTP/1.1 e você não precisa especificar `"chunked"` usando o cabeçalho `TE`. Entretanto, ele é útil para configurar se o cliente está aceitando campos de rabeira (*trailer fields*) em uma codificação de transferência fragmentada usando os valores "*trailers*".

|  |  |
| --- | --- |
| Tipo de cabeçalho | Request header |
| Forbidden header name | sim |

Sintaxe
-------
```

TE: compress
TE: deflate
TE: gzip
TE: trailers

// Multiple directives, weighted with the quality value (en-US) syntax:
TE: trailers, deflate;q=0.5
```

Diretivas
---------

`compress`

Um formato usando o algoritmo de Lempel-Ziv-Welch (LZW) é aceito como nome de codificação de transferência.

`deflate`

Usar a estrutura zlib é aceito como nome da codificação de transferência.

`gzip`

Um formato usando a codificação Lempel-Ziv (LZ77), com um CRC 32-bit é aceito como nome da codificação de transferência.

`trailers`

Indica que o cliente está sujeito a aceitar campos *trailer* em uma codificação de transferência fragmentada.

`q`

Quando múltiplas codificações de transferência são aceitas, o parâmetro `q` da sintaxe de valor de qualidade (en-US) pode elencar codificações por preferência.

Especificações
--------------

| Especificação | Título |
| --- | --- |
| RFC 7230, sessão 4.3: TE | Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing |

Compatibilidade com navegadores
-------------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Veja também
-----------

* `Transfer-Encoding`
* `Trailer`
* Codificação de transferência fragmentada (*Chunked transfer encoding*)


NEL - HTTP

NEL
===

O cabeçalho de resposta HTTP **`NEL`** é usado para configurar o registro de *logs* de requisição na rede.

|  |  |
| --- | --- |
| Tipo de cabeçalho | Response header (en-US) |
| Forbidden header name | não |

Sintaxe
-------
```

NEL: { "report_to": "name_of_reporting_group", "max_age": 12345, "include_subdomains": false, "success_fraction": 0.0, "failure_fraction": 1.0 }
```

Especificações
--------------

| Especificação |
| --- |
| Registro de Erros de Rede |

Veja também
-----------

* Explicação do Registro de Redes de Log [Network Error Logging (NEL)] (en-US)


WWW-Authenticate - HTTP

WWW-Authenticate
================

O cabeçalho da resposta HTTP **`WWW-Authenticate`** define o método de autenticação a ser usado para obter acesso ao recurso.

O cabeçalho `WWW-Authenticate` é enviado junto a resposta `401` `Unauthorized`.

|  |  |
| --- | --- |
| Tipo de cabeçalho | Response header (en-US) |
| Forbidden header name | não |

Sintaxe
-------
```

WWW-Authenticate: <type> realm=<realm>
```

Diretivas
---------

<type>

Tipo de autenticação. Um tipo comum de autenticação é "Basic". IANA mantém uma lista de esquema de autenticação.

realm=<realm>

Uma descrição da área protegida. Se nenhuma área for informada, os clientes frequentemente exibirão um hostname formatado.

charset=<charset>

Informa ao cliente qual é o encoding do servidor quando for submetido usuário e senha. O único valor permitido é "UTF-8". Isso não está relacionado ao encoding da realm string.

Exemplos
--------

Tipicamente, uma resposta do servidor contém um cabeçalho `WWW-Authenticate` que se parece com isso:
```

WWW-Authenticate: Basic

WWW-Authenticate: Basic realm="Access to the staging site", charset="UTF-8"
```

Veja também autenticação HTTP para exemplos em como configurar servidores Apache ou nginx para proteger seu site com senha usando autenticação básica HTTP.

Especificações
--------------

| Especificação | Título |
| --- | --- |
| RFC 7235, sessão 4.1: WWW-Authenticate | HTTP/1.1: Authentication |
| RFC 7617 | The 'Basic' HTTP Authentication Scheme |

Compatibilidade com navegadores
-------------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Veja também
-----------

* Autenticação HTTP
* `Authorization`
* `Proxy-Authorization`
* `Proxy-Authenticate`
* `401`, `403`, `407`


Large-Allocation - HTTP

Large-Allocation
================

O cabeçalho de resposta não padronizado **`Large-Allocation`** diz ao nevagador que a página que está sendo carregada vai performar uma grande alocação. Ele é atualmente implementado somente no Firefox, mas é inofensivo para ser enviado para qualquer navegador.

Aplicações WebAssembly ou *asm.js* podem usar grandes blocos contíguos de memória alocada. Para jogos complexos, por exemplo, estas alocações podem ser bem grandes, algumas vezes grandes na escala de 1GB. O `Large-Allocation` diz ao navegador que o conteúdo web que será carregado vai querer performar uma grande alocação de memória contígua e o navegador pode reagir a este cabeçalho iniciando um processo dedicado para carregador o documento, por exemplo.

|  |  |
| --- | --- |
| Tipo de cabeçalho | Response header (en-US) |
| Forbidden header name | não |

Sintaxe
-------
```

Large-Allocation: 0
Large-Allocation: <megabytes>
```

Diretivas
---------

`0`

0 é um valor especial que representa incerteza em relação a qual será o tamanho da alocação.

`<megabytes>`

O tamanho esperado da alocação a ser performada, em megabytes.

Exemplos
--------
```

Large-Allocation: 0
Large-Allocation: 500
```

Tratamento de erros
-------------------

O cabeçalho `Large-Allocation` joga mensagens de aviso ou erro quando utilizado incorretamente. Você vai encontrá-los no console web.

This page was loaded in a new process due to a `Large-Allocation` header.

Esta mensagem significa que o navegador viu o cabeçalho `Large-Allocation`, e conseguiu recarregar a página em um novo processo que deve ter mais memória contígua disponível.

A `Large-Allocation` header was ignored due to the load being triggered by a non-GET request.

Quando uma requisição `POST` é usada para carregar um documento, aquele carregamento não pode ser redirecionado para um novo processo. Este erro é mostrado quando carregando um documento com um cabeçalho `Large-Allocation` com um método HTTP que não seja GET. Isto pode ter sido causado devido ao documento estar sendo carregado por um formulário de submissão, por exemplo.

A `Large-Allocation` header was ignored due to the presence of windows which have a reference to this browsing context through the frame hierarchy or `window.opener` (en-US).

Este erro significa que o documento não foi carregado no nível mais alto de uma janela ou aba aberta, ou não aberta do usuário. Ele pode ocorrere nestas situações:

* O documento com cabeçalho `Large-Allocation` foi carregado em um `<iframe>`. O Firefox não pode mover um iframe em um novo processo atualmente, então o documento deve carregar no novo processo.
* O documento com cabeçalho `Large-Allocation` foi carregado em uma em uma janela que foi aberta pelo `window.open()` (en-US), `<a target="_blank">` ou outros métodos similares sem `rel="noopener"` ou a funcionalidade `"noopener"` sendo colocado. Estas janelas devem permanecer no mesmo processo que o abriu, já que eles podem se comunicar, significando que não podemos permití-los trocar processos.
* O documento cabeçalho `Large-Allocation` abriu outra janela com `window.open()` (en-US), `<a target="_blank">` ou outros métodos similares sem a funcionalidade `rel="noopener"` ou `"noopener"` sem colocada. Isto é para o mesmo motivo, This is for the same reason as above, ou seja, que eles podem se comunicar e, portanto, não podemos permitir que eles alternem processos.

A `Large-Allocation` header was ignored due to the document not being loaded out of process.

O Firefox moveu para uma arquitetura multiprocesso, e esta arquitetura é necessária para suportar o cabeçalho `Large-Allocation`. Alguns Addons legado podem previnir o Firefox de usar esta nova, e mais rápida arquitetura multiprocesso. Se você tem um destes Addons, então nós vamos continuar a utilizar a antiga arquitetura de processo único para compatibilidade, e não pode lidar com o cabeçalho `Large-Allocation`.

This page would be loaded in a new process due to a `Large-Allocation` header, however `Large-Allocation` process creation is disabled on non-Win32 platforms.

O Firefox atualmente somente suporta o cabeçalho `Large-Allocation` nas versões 32-bits do Windows, como fragmentação de memória não é um problema em versões 64-bits. Se você está rodando uma versão não *win32* do Firefox, este erro irá aparecer. Esta checagem pode ser desabilitada com a preferência de booleano "dom.largeAllocation.

forceEnable" em about:config.

Especificações
--------------

Não faz parte de nenhuma especificação atualmente. Uma explicação das ideias por trás deste cabeçalho podem ser encontradas neste documento.

Compatibilidade com navegadores
-------------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Veja também
-----------

* WebAssembly


Access-Control-Request-Method - HTTP

Access-Control-Request-Method
=============================

O cabeçalho de requisição **`Access-Control-Request-Method`** é usado pelos navegadores quando executando uma preflight request, para deixar o servidor sabendo quais métodos HTTP vão ser usados quando a requisição verdadeira for feita. Este cabeçalho é necessário como toda requisição pré-vôo é um `OPTIONS` e não usa o mesmo método na requisição verdadeira.

|  |  |
| --- | --- |
| Tipo de cabeçalho | Request header |
| Forbidden header name | sim |

Sintaxe
-------
```

Access-Control-Request-Method: <método>
```

Diretivas
---------

<método>

Um dos métodos de requisição HTTP, por exemplo: `GET`, `POST` ou `DELETE`.

Exemplos
--------
```

Access-Control-Request-Method: POST
```

Especificações
--------------

| Specification |
| --- |
| Fetch Standard # http-access-control-request-method |

Compatibilidade com navegadores
-------------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Veja também
-----------

* `Access-Control-Request-Headers`


Strict-Transport-Security - HTTP

Strict-Transport-Security
=========================

O cabeçalho de resposta **HTTP `Strict-Transport-Security`** (geralmente abreviado como HSTS) permite que um site informe aos navegadores que ele deve ser acessado apenas por HTTPS, em vez de usar HTTP.

|  |  |
| --- | --- |
| Tipo de Cabeçalho | Cabeçalho de Resposta |
| Nome do cabeçalho proibido | não |

Sintaxe
-------
```

Strict-Transport-Security: max-age=<expire-time>
Strict-Transport-Security: max-age=<expire-time>; includeSubDomains
Strict-Transport-Security: max-age=<expire-time>; preload
```

Diretivas
---------

`max-age=<expire-time>`

O tempo, em segundos, que o navegador deve lembrar que um site só pode ser acessado usando HTTPS.

`includeSubDomains` Optional

Se este parâmetro opcional for especificado, esta regra também será aplicada a todos os subdomínios do site.

`preload` Optional

Consulte Preloading Strict Transport Security para detalhes. Não faz parte da especificação.

Descrição
---------

Se um site aceitar uma conexão por meio de HTTP e redirecionar para HTTPS, os visitantes poderão se comunicar inicialmente com a versão não criptografada do site antes de serem redirecionados, se, por exemplo, o visitante digitar `http://www.foo.com/` ou até mesmo apenas foo.com Isso cria uma oportunidade para um ataque man-in-the-middle. O redirecionamento pode ser explorado para direcionar os visitantes a um site mal-intencionado em vez da versão segura do site original.

O cabeçalho HTTP Strict Transport Security informa ao navegador que ele nunca deve carregar um site usando HTTP e deve converter automaticamente todas as tentativas de acessar o site usando HTTP para solicitações HTTPS.

**Nota:** O cabeçalho `Strict-Transport-Security` é **ignorado** pelo navegador quando seu site é acessado usando HTTP; isso ocorre porque um invasor pode interceptar conexões HTTP e injetar o cabeçalho ou removê-lo. Quando seu site é acessado por HTTPS sem erros de certificado, o navegador sabe que seu site é capaz de HTTPS e honrará o `Strict-Transport-Security`cabeçalho.

### Um cenário de exemplo

Você faz login em um ponto de acesso Wi-Fi gratuito em um aeroporto e começa a navegar na Web, visitando seu serviço bancário on-line para verificar seu saldo e pagar algumas contas. Infelizmente, o ponto de acesso que você está usando é, na verdade, o laptop de um hacker, e ele está interceptando sua solicitação HTTP original e redirecionando você para um clone do site do seu banco, em vez do real. Agora seus dados privados são expostos ao hacker.

Segurança de Transporte Estrito (Strict Transport Security) resolve esse problema; desde que você tenha acessado o site do seu banco uma vez usando HTTPS, e o site do banco use o Strict Transport Security, seu navegador saberá usar automaticamente apenas HTTPS, o que impede que os hackers realizem um ataque man-in-the-middle.

### Como o navegador lida com isso

Na primeira vez em que seu site é acessado usando HTTPS e retorna o cabeçalho `Strict-Transport-Security`, o navegador registra essas informações, para que futuras tentativas de carregar o site usando HTTP usem o HTTPS automaticamente.

Quando o tempo de expiração especificado pelo cabeçalho Strict-Transport-Security expirar, a próxima tentativa de carregar o site via HTTP prosseguirá normalmente, em vez de usar automaticamente o HTTPS.

Sempre que o cabeçalho Strict-Transport-Security for entregue ao navegador, ele atualizará o tempo de expiração desse site, para que os sites possam atualizar essas informações e impedir que o tempo limite expire. Caso seja necessário desativar a Segurança de Transporte Restrita, a configuração da duração máxima para 0 (através de uma conexão https) expirará imediatamente o cabeçalho `Strict-Transport-Security`, permitindo o acesso via http.

Pré-Carregamento - Strict Transport Security
--------------------------------------------

O Google mantém um serviço de pré-carregamento de HSTS. Ao seguir as diretrizes e enviar seu domínio com sucesso, os navegadores nunca se conectarão ao seu domínio usando uma conexão insegura. Enquanto o serviço é hospedado pelo Google, todos os navegadores declararam a intenção de usar (ou de fato começaram a usar) a lista de pré-carregamento. No entanto, não faz parte da especificação da HSTS e não deve ser tratada como oficial.

* Informações sobre a lista de pré-carregamento de HSTS no Chrome: https://www.chromium.org/hsts
* Consulta da lista de pré-carregamento do Firefox HSTS: nsSTSPreloadList.inc
Exemplos
--------

Todos os subdomínios presentes e futuros serão HTTPS para uma idade máxima de 1 ano. Isso bloqueia o acesso a páginas ou subdomínios que só podem ser veiculados por HTTP.
```

Strict-Transport-Security: max-age=31536000; includeSubDomains
```

Especificações
--------------

| Specification |
| --- |
| HTTP Strict Transport Security (HSTS) # section-6.1 |

Compatibilidade com navegadores
-------------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Veja também
-----------

* Postagem no blog: HTTP Strict Transport Security has landed!
* Postagem no blog: HTTP Strict Transport Security (force HTTPS)
* Artigo OWASP: HTTP Strict Transport Security
* Wikipedia: HTTP Strict Transport Security


X-Forwarded-Host - HTTP

X-Forwarded-Host
================

O cabeçalho **`X-Forwarded-Host`** (XFH) é um cabeçalho padrão de fato para identificar o *host* original requisitado pelo cliente no cabeçalho de requisição HTTP `Host`.

Nomes de *hosts* e portes de proxies reversos (balanceadores de carga, CDNs) pode diferir do servidor de origem que manipula a solicitação, neste caso o cabeçalho `X-Forwarded-Host` é útil para determinar qual Host foi originalmente utilizado.

Este cabeçalho é utilizado para depuração, estatísticas, e gerar conteúdo dependente localmente e por design ele expõe informações privadas sensíveis, como o endereço IP do cliente. Então a privacidade do usuário deve estar em mente quando utilizando este cabeçalho.

Uma versão padronizada deste cabeçalho é o cabeçalho HTTP `Forwarded`.

|  |  |
| --- | --- |
| Tipo de cabeçalho | Request header |
| Forbidden header name | não |

Sintaxe
-------
```

X-Forwarded-Host: <host>
```

Diretivas
---------

<host>

O nome do domínio do servidor encaminhado.

Exemplos
--------
```

X-Forwarded-Host: id42.example-cdn.com
```

Especificações
--------------

Não pertence a nenhuma especificação atualmente. A versão padronizada do cabeçalho é `Forwarded`.

Compatibilidade com navegadores
-------------------------------

{{Compat}}Veja também
-----------

* `Host`
* `Forwarded`
* `X-Forwarded-For`
* `X-Forwarded-Proto`


Keep-Alive - HTTP

Keep-Alive
==========

O cabeçalho **`Keep-Alive`** permite que o remetente indique como a conexão deve ser usada, para definir um tempo limite e um máximo de requisições.

**Nota:** O `Connection` cabeçalho precisa ser definido como "keep-alive" para isso funcionar , `Connection` e `Keep-Alive` são ignorados em conexões HTTP/2; Gerenciamento de conexões são feitos por outros mecanismos.

|  |  |
| --- | --- |
| Tipo de cabeçalho | General header |
| Forbidden header name | sim |

Sintaxe
-------
```

Keep-Alive: parametros
```

Diretivas
---------

*parâmetros*

Uma vírgula separa a lista de parâmetros, Cada consiste de um identificador e um valor separado pelo sinal de igualdade (`'='`). São possíveis os seguintes identificadores:

* `timeout`: indicando a quantidade mínima de tempo que uma conexão deve ser mantida aberta (em segundos). Observe que os tempos limite maiores que o tempo limite do TCP podem ser ignorados se nenhuma mensagem TCP keep-alive estiver definida na camada de transporte.
* `max`: indicando o número máximo de pedidos que podem ser enviados nesta conexão antes de fechá-lo. Menor que `0`, este valor será ignorado por conexões non-pipelined, pois outra requisição será enviada na próxima resposta. Um HTTP pipeline pode usar isso para limitar o pipelining.

Exemplos
--------

Uma resposta content o cabeçalho `Keep-Alive`:
```

HTTP/1.1 200 OK
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Date: Thu, 11 Aug 2016 15:23:13 GMT
Keep-Alive: timeout=5, max=1000
Last-Modified: Mon, 25 Jul 2016 04:32:39 GMT
Server: Apache

(body)
```

Especificações
--------------

| Specification | Title |
| --- | --- |
| HyperText Transport Protocol Keep-Alive Header | The Keep-Alive Header (Experimental specification) |
| RFC 7230, appendix A.1.2: Keep-Alive | Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing |

Compatibilidade com navegadores
-------------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Veja também
-----------

* `Connection`
* Connection management in HTTP/1.x


Proxy-Authenticate - HTTP

Proxy-Authenticate
==================

O cabeçalho de resposta HTTP **`Proxy-Authenticate`** define o método de autenticação que deve ser utilizado para conseguir acesso ao recurso por trás de um proxy server. Ele autentica a requisição ao servidor proxy, permitindo que transmita a requisição em frente.

O cabeçalho `Proxy-Authenticate` é enviado junto com um `407` `Proxy Authentication Required`.

|  |  |
| --- | --- |
| Tipo de cabeçalho | Response header (en-US) |
| Forbidden header name | não |

Sintaxe
-------
```

Proxy-Authenticate: <type> realm=<realm>
```

Diretivas
---------

<type>

Tipo de autenticação. Um tipo comum é "Basic". A IANA mantém uma lista de esquemas de autenticação.

realm=<realm>

A descrição da área protegida, o reino. Se um reino não foi especificado, clientes geralmente mostram um nome de *host* formatado.

Exemplos
--------
```

Proxy-Authenticate: Basic

Proxy-Authenticate: Basic realm="Access to the internal site"
```

Especificações
--------------

| Especificação | Título |
| --- | --- |
| RFC 7235, sessão 4.3: Proxy-Authenticate | HTTP/1.1: Authentication |
| RFC 7617 | The 'Basic' HTTP Authentication Scheme |

Compatibilidade com navegadores
-------------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Veja também
-----------

* Autenticação HTTP
* `Authorization`
* `Proxy-Authorization`
* `WWW-Authenticate`
* `401`, `403`, `407`


Want-Digest - HTTP

Want-Digest
===========

O cabeçalho HTTP **`Want-Digest`** é primordialmente usado em uma requisição HTTP, para pedir ao respondedor para prover uma digestão (digest (en-US)) do recurso requisitado usando o cabeçalho de resposta `Digest`.

O cabeçalho contém identificadores para um ou mais algoritmos de digestão que o remetente deseja que o respondedor use para criar a digestão. O remetente pode usar valores de qualidade (en-US) para indicar sua preferência ordenando dentre as escolhas que ele oferece.

Se `Want-Digest` não inclui nenhum algoritmo de digestão que aquele servidor suporta, o servidor pode responder com:

* uma digestão calculada usando outro algoritmo de digestão, ou
* um erro `400 Bad Request`, e inclui outro cabeçalho `Want-Digest` com a resposta, listando os algoritmos que ele suporta.

Veja a página do cabeçalho `Digest` para mais informações.

|  |  |
| --- | --- |
| Tipo de cabeçalho | General header |
| Forbidden header name | não |

Sintaxe
-------
```

Want-Digest: <digest-algorithm>

// Múltiplos algoritmos, pesados com a sintaxe de qualidade de valor:
Want-Digest: <digest-algorithm><q-value>,<digest-algorithm><q-value>
```

Diretivas
---------

`<digest-algorithm>`

Algoritmos de digestão suportados são definidos na RFC 3230 e RFC 5843, e inclui `SHA-256` e `SHA-512`. Alguns algoritmos suportados, incluindo `unixsum` e `MD5` são sujeitos a colisões e não são apropriados para aplicações em que resistência à colisão é importante.

`<q-value>`

O valor de qualidade (en-US) para aplicar aquela opção.

Exemplos
--------
```

Want-Digest: sha-256
Want-Digest: SHA-512;q=0.3, sha-256;q=1, md5;q=0
```

### Operação básica

O remetente provém a lista de digestões que ele está preparado para aceitar, e o servidor usa um deles:
```

Request:

  GET /item
  Want-Digest: sha-256;q=0.3, sha;q=1

Response:

  HTTP/1.1 200 Ok
  Digest: sha-256=X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=
```

### Digestões não suportadas

O servidor não suporta nenhum do algoritmos de digestão requisitados, então ele usa um algoritmo diferente:
```

Request:

  GET /item
  Want-Digest: sha;q=1

Response:

  HTTP/1.1 200 Ok
  Digest: sha-256=X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=
```

O servidor não suporta nenhuma dos algoritmos de digestão requisitados, então responde com um erro 400 e inclui outro cabeçalho `Want-Digest`, listando os algoritmos que ele suporta:
```

Request:

  GET /item
  Want-Digest: sha;q=1

Response:

  HTTP/1.1 400 Bad Request
  Want-Digest: sha-256, sha-512
```

Especificações
--------------

| Especificação | Título |
| --- | --- |
| draft-ietf-httpbis-digest-headers-latest | Resource Digests for HTTP |

Este cabeçalho foi originalmente definido na RFC 3230, mas a definição de "representação selecionada" na RFC 7231 fez a definição original ficar inconsistente com as atuais especificações HTTP. Quando lançado, o rascunho "Digestões de Recursos para HTTP" tornará a RFC 3230 obsoleta e vai atualizar o padrão para ficar consistente.

Compatibilidade com navegadores
-------------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Veja também
-----------

* `Digest`