recursal/MDN huggingface dataset:
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
===

**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
====

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
========

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
===

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
===

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
=====

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
======

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
========

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
==========

**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.
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
===================

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
=============

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
==

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*)