Accept-Encoding - HTTP

Accept-Encoding
===============

O cabeçalho de requisição HTTP **`Accept-Encoding`** indica qual codificação de conteúdo, usualmente um algoritmo de compressão, o cliente está apto a entender. Usando negociação de conteúdo, o servidor seleciona uma das propostas, a utiliza e informa o cliente da escolha feita com o cabeçalho de resposta `Content-Encoding`.

Até mesmo se o cliente e o servidor suportarem os mesmos algoritmos de compressão, o servidor pode escolher não comprimir o corpo da resposta, se o valor de identidade também é aceitável. Dois casos comuns levam a isso:

* Os dados a serem enviados já estão comprimidos e a segunda compressão não irá deixar os dados menores para serem transmitidos. Isso pode ser o caso com alguns formatos de imagens;
* O servidor está sobrecarregado e não pode suportar a sobrecarga computacional induzida pelas exigências da compressão. Tipicamente, a Microsoft recomenda a não comprimir um corpo de resposta se o servidor utiliza mais do que 80% do seu poder computacional.

Enquanto o valor de `identity`, que significa sem codificação, não é explicitamente proibido, por um `identity;q=0` ou um `*;q=0` sem qualquer outra atribuição explícita para a identidade, o servidor nunca deve mandar como resposta um erro `406` `Not Acceptable`.

**Nota:** **Notas:**- Um registro da IANA mantém a lista completa das codificações de conteúdo.

* Duas outras codificações de conteúdo, `bzip` e `bzip2`, são algumas vezes utilizadas, entretanto não são o padrão. Elas implementam o algoritmo usado por estes dois programas UNIX. Note que o primeiro foi descontinuado por problemas de patente.

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

Sintaxe
-------
```

Accept-Encoding: gzip
Accept-Encoding: compress
Accept-Encoding: deflate
Accept-Encoding: br
Accept-Encoding: identity
Accept-Encoding: *

// Múltiplos algoritmos, com pesos baseados na sintaxe de quality value (en-US):
Accept-Encoding: deflate, gzip;q=1.0, *;q=0.5
```

Diretivas
---------

`gzip`

Formato de compressão usando o Lempel-Ziv coding (LZ77), com CRC de 32-bits.

`compress`

Formato de compressão usando o algoritmo Lempel-Ziv-Welch (LZW).

`deflate`

Formato de compressão usando a estrutura zlib, com o algoritmo de compressão *deflate*.

`br`

Formato de compressão usando o algoritmo de Brotli.

`identity`

Indica a identidade da função (i.e. sem compressão, ou sem modificação). Esse valor é sempre considerado como aceitável, mesmo se não estiver presente.

`*`

Aceita qualquer codificação de conteúdo ainda não listada no cabeçalho. Esse é o valor padrão se o cabeçalho não estiver presente. Isto não significa que qualquer algoritmo é suportado; meramente que nenhuma preferência é expressa.

`;q=` (valores de peso q)

Qualquer valor é colocado em uma ordem de preferência expressada usando a quality value (en-US) relativa chamada *peso*.

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

Accept-Encoding: gzip

Accept-Encoding: gzip, compress, br

Accept-Encoding: br;q=1.0, gzip;q=0.8, *;q=0.1
```

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

| Especificação | Título |
| --- | --- |
| RFC 7231, sessão 5.3.4: Accept-Encoding | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Context |

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

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

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

* Negociação de conteúdo HTTP
* Cabeçalho com o resultado do conteúdo de negociação: `Content-Encoding`
* Outros cabeçalhos similares: `TE`, `Accept`, `Accept-Charset`, `Accept-Language`


Device-Memory - HTTP

Device-Memory
=============

**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 **`Device-Memory`** é um cabeçalho da Device Memory API (en-US) que funciona como os cabeçalhos Client Hints (en-US) que representão a quantidade aproximada de RAM que o dispositivo do cliente possui.

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

**Nota:** Client Hints são acessíveis somente em origens seguras (via TLS). O servidor pode optar em receber o cabeçalho `Device-Memory` do cliente mandando os cabeçalhos de resposta `Accept-CH` e `Accept-CH-Lifetime`.

Sintaxe
-------

A quantidade de RAM no dispositivo pode ser usada como variável de pegada, The amount of device RAM can be used as a fingerprinting variable, então os valores para este cabeçalho são intencionalmente grosseiros para reduzir potenciais usos indesejados. O cabeçalho pode ter os seguintes valores: `0.25`, `0.5`, `1`, `2`, `4`, `8`.
```

Device-Memory: <number>
```

Exemplos
--------

O servidor precisa primeiro optar por aceitar o cabeçalho `Device-Memory` mandando os cabeçalhos de resposta `Accept-CH` contendo `Device-Memory` e `Accept-CH-Lifetime`.
```

Accept-CH: Device-Memory
Accept-CH-Lifetime: 86400
```

Então nas requisições subsequentes, o cliente enviará o cabeçalho `Device-Memory` de volta:
```

Device-Memory: 1
```

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

| Specification |
| --- |
| Device Memory # iana-device-memory |

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

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

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

* Device Memory API (en-US)
* `Accept-CH`
* `Accept-CH-Lifetime`
* `Vary`
* `Navigator.deviceMemory`


If-Modified-Since - HTTP

If-Modified-Since
=================

A requisição do cabeçalho HTTP **`If-Modified-Since`** torna a requisição condicional: o servidor enviará de volta o recurso solicitado, com um status `200`, apenas se foi modificado pela ultima vez após a data fornecida. Se a requisição não foi modificada, a resposta será um `304` sem qualquer corpo; o cabeçalho `Last-Modified` irá conter a data da ultima modificação. Ao contrário `If-Unmodified-Since`, `If-Modified-Since` pode ser apenas utilizado com um `GET` ou `HEAD`.

Quando utilizado em combinação com `If-None-Match`, é ignorado, a menos que não suporte `If-None-Match`.

O uso mais comum é para atualizar uma entidade em cache que não tem um `ETag` associado.

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

Sintaxe
-------
```

If-Modified-Since: <nome-dia>, <dia> <mês> <ano> <hora>:<minuto>:<segundo> GMT
```

Diretivas
---------

<nome-dia>

Um entre "Mon", "Tue", "Wed", "Thu", "Fri", "Sat", or "Sun" (sensível ao caso).

<dia>

2 digitos, número do dia. Por exemplo "04" ou "23".

<mês>

Um entre "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" (sensível ao caso).

<ano>

4 digitos, número do ano,. Por exemplo. "1990" ou "2016".

<hora>

2 digitos, número da hora. Por exemplo. "09" ou "23".

<minuto>

2 digiitos, número do minuto. Por exemplo. "04" ou "59".

<segundos>

2 digitos, número dos segundos, Por exemplo. "04" ou "59".

`GMT`

Horário de Greenwich (Greenwich Mean Time). Datas HTTP sempre são expressas em GMT, nunca em tempo local.

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

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

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

| Especificação | Título |
| --- | --- |
| RFC 7232, sessão 3.3: If-Modified-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
-----------

* `ETag`
* `If-Unmodified-since`
* `If-Match`
* `If-None-Match`
* `304` `Not Modified`


Access-Control-Allow-Methods - HTTP

Access-Control-Allow-Methods
============================

O cabeçalho de resposta **`Access-Control-Allow-Methods`** especifica o método ou métodos permitidos quando acessando o recurso em resposta a uma preflight request.

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

Sintaxe
-------
```

Access-Control-Allow-Methods: <método>, <método>, ...
Access-Control-Allow-Methods: *
```

Diretivas
---------

<método>

Lista separada por vírgula com os métodos de requisição HTTP.

`*` (coringa)

O valor "`*`" só conta como valor coringa para requisições sem credenciais (requisições sem cookies HTTP ou informação de autenticação HTTP). Em requisições com credenciais, isso é tratado como o nome de método literal "`*`" sem qualquer semântica especial.

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

Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Methods: *
```

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

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

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

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

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

* `Access-Control-Allow-Origin`
* `Access-Control-Expose-Headers`
* `Access-Control-Allow-Headers`
* `Access-Control-Request-Method`


Expires - HTTP

Expires
=======

O cabeçalho **`Expires`** contém a data/hora após a qual a resposta é considerada velha.

Datas inválidas, como o valor 0, representam uma data no passado e significam que o recurso já expirou.

Se existe um cabeçalho `Cache-Control` com a diretiva "max-age" ou "s-maxage" na resposta, o cabeçalho `Expires` é ignorado.

|  |  |
| --- | --- |
| Tipo de Header | Response header (en-US) |
| Forbidden header name | não |
| CORS-safelisted response-header (en-US) | sim |

Sintaxe
-------
```

Expires: <http-date>
```

Diretivas
---------

<http-date>

Ums data/hora HTTP-date.

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

Expires: Wed, 21 Oct 2015 07:28:00 GMT
```

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

| Especificação | Título |
| --- | --- |
| RFC 7234, sessão 5.3: Expires | 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`
* `Age`


Accept-Patch - HTTP

Accept-Patch
============

O cabeçalho de resposta HTTP **`Accept-Patch`** indica qual tipo de mídia o servidor está apto a entender.

**`Accept-Patch`** na resposta de qualquer método significa que o PATCH é permitido no recurso identificado pela Request-URI. Dois casos comuns que levam a isso:

O servidor recebendo uma requisição PATCH com um tipo de mídia não suportado pode responder com `415` `Unsupported Media Type` e um cabeçalho Accept-Patch referenciando um ou mais tipos de mídia suportados.

**Nota:** **Notas:**- Um registro da IANA mantém uma lista oficial completa das codificações de conteúdo.

* Duas outras codificações de conteúdo, `bzip` e `bzip2`, são algumas vezes utilizadas, entretanto não são o padrão. Elas implementam o algoritmo usado por estes dois programas UNIX. Note que o primeiro foi descontinuado por problemas de patente.

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

Sintaxe
-------
```

Accept-Patch: application/example, text/example
Accept-Patch: text/example;charset=utf-8
Accept-Patch: application/merge-patch+json
```

Diretivas
---------

Nenhuma.

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

Accept-Patch: application/example, text/example

Accept-Patch: text/example;charset=utf-8

Accept-Patch: application/merge-patch+json
```

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

| Specification | Título |
| --- | --- |
| RFC 5789, sessão 3.1: Accept-Patch | HTTP PATCH |

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

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

* Método HTTP `PATCH`
* Semântica e contexto HTTP RFC 7231, sessão 4.3.4: PUT


Proxy-Authorization - HTTP

Proxy-Authorization
===================

O cabeçalho de requisição HTTP **`Proxy-Authorization`** contém as credenciais para autenticar o agente de usuário em um servidor proxy, usualmente depois do servidor responder com um código de status `407` `Proxy Authentication Required` e cabeçalho `Proxy-Authenticate`.

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

Sintaxe
-------
```

Proxy-Authorization: <type> <credentials>
```

Diretivas
---------

<type>

Tipo de autentação. Um tipo comum é "Basic". Veja também o registro IANA de esquemas de autenticação.

<credentials>

As credenciais são construídas assim:

* O nome de usuário e senha combinados com dois pontos (`aladdin:opensesame`).
* O resultado é uma cadeia de caracteres codificado em base64 (en-US) (`YWxhZGRpbjpvcGVuc2VzYW1l`).

**Nota:** Codificação Base64 não significa encriptação ou hashing! Esse método é igualmente seguro se mandar as credenciais em texto limpo (base64 é uma codificação reversível). Prefira o uso de HTTPS em conjunto com Autenticação Básica.

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

Proxy-Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l
```

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

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

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

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


Cache-Control - HTTP

Cache-Control
=============

O campo de cabeçalho genérico **`Cache-Control`** é usado para especificar diretivas para mecanismos de *cache* tanto em requisições quanto em respostas. Diretivas de *cache* são unidirecionais, o que significa que uma dada diretiva em uma requisição não implica em que a mesma seja dada na resposta.

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

Sintaxe
-------

As diretivas são insensíveis à caixa (*case-insensitive)* e tem um argumento opcional, que pode usar tanto a sintaxe de token quanto a de cadeias entre aspas. Multiplas diretivas são separadas por virgula.

### Diretivas de Cache de requisições

Diretivas `Cache-Control` padrão que podem ser usadas pelo cliente em uma requisição HTTP.
```

Cache-Control: max-age=<segundos>
Cache-Control: max-stale[=<segundos>]
Cache-Control: min-fresh=<segundos>
Cache-Control: no-cache
Cache-Control: no-store
Cache-Control: no-transform
Cache-Control: only-if-cached
```

### Diretivas de Cache de respostas

Diretivas `Cache-Control` padrão que podem ser usadas pelo servidor em uma resposta HTTP.
```

Cache-Control: must-revalidate
Cache-Control: no-cache
Cache-Control: no-store
Cache-Control: no-transform
Cache-Control: public
Cache-Control: private
Cache-Control: proxy-revalidate
Cache-Control: max-age=<segundos>
Cache-Control: s-maxage=<segundos>
```

### Diretivas `Cache-Control` Extendidas

Diretivas `Cache-Control` extendidas não são parte do cerne do documento HTTP caching standards. Verifique a tabela de compatibilidade para certificar-se do seu suporte.
```

Cache-Control: immutable
Cache-Control: stale-while-revalidate=<seconds>
Cache-Control: stale-if-error=<seconds>
```

Diretivas
---------

### Cacheabilidade

`public`

Indica que a resposta pode ser memorizada por qualquer cache.

`private`

Indica que a resposta é para um único usuário e não deve ser armazenada por um cache compartilhado. Um cache privativo pode armazenar a resposta.

`no-cache`

Força o cache a submeter a requisição ao servidor origem para validação antes de liberar a cópia em memória.

`only-if-cached`

Indica que novos dados não devem ser obtidos. Se este é o caso, o servidor deseja que o cliente obtenha a resposta somente uma vez e memorize (no cache). A partir desse momento o cliente deveria liberar somente a cópia em cache e evitar contactar o servidor origem para ver se há cópias novas.

### Expiração

`max-age=<segundos>`

Especifica o tempo máximo em que um recurso será considerado fresco. Ao contrário de `Expires`, esta diretiva é relativa à hora da requisição.

`s-maxage=<segundos>`

Tem precedência sobre `max-age` ou o cabeçalho `Expires`, mas só se aplica a caches compartilhados (p.ex., proxies) e é ignorada por caches privados.

`max-stale[=<segundos>]`

Indica que o cliente pode aceitar uma resposta que excedeu seu período de expiração. Opcionalmente, você pode informar um valor em segundos, indicando o tempo em que a resposta não será expirada.

`min-fresh=<segundos>`

Indica que o cliente quer uma resposta que será fresca por pelo menos o número de segundos especificado.

`stale-while-revalidate=<segundos>`
Experimental

Indica que o cliente aceitará uma resposta de caducidade enquanto verifica uma fresca assincronamente em *background*. O valor em segundos indica por quanto tempo o cliente espera a resposta de caducidade.

`stale-if-error=<segundos>`
Experimental

Indica que o cliente espera aceitar uma resposta de caducidade se falhou a verificação de uma fresca. O valor em segundos indica quanto tempo o cliente aceitará a resposta de caducidade após a expiração inicial.

### Revalidação e recarga

`must-revalidate`

O cache deve verificar o estado dos recursos caducos antes de usá-los e não usar recursos expirados.

`proxy-revalidate`

Mesmo que `must-revalidate`, mas só se aplica a caches compartilhados (p.ex., proxies) e é ignorado por um cache privado.

`immutable`

Indica que o corpo da resposta não mudará ao longo do tempo. O recurso, se ainda hábil, está inalterado no servidor e portanto o cliente não deverá enviar uma revalidação condicional para ele (p.ex. `If-None-Match` ou `If-Modified-Since`) a fim de verificar atualiações, mesmo quando o usuário recarrega explicitamente a página. Clientes que não reconhecem esta extensão devem ignorá-la, segundo a especificação HTTP. No Firefox, `immutable` é honrado somente em transações `https://`. Para mais informações, veja também este blog post.

### Outros

`no-store`

O cache não deverá armazenar qualquer coisa sobre a requisição do cliente ou a resposta do servidor.

`no-transform`

Nenhuma transformação ou conversão deverá ser feita no recurso. Os cabeçalhos Content-Encoding, Content-Range, Content-Type não devem ser modificados por um proxy. Um proxy não transparente deve, por exemplo, converter formatos de imagens a fim de economizar espaço de cache ou reduzir o tráfego no link lento. A diretiva `no-transform` não permite isso.

Exemplos
--------

### Prevenindo o cache

Para desligar o armazenamento em cache, você pode enviar o cabeçalho de resposta seguinte. Alem disso, veja também os cabeçalhos `Expires` e `Pragma`.

```bash
Cache-Control: no-cache, no-store, must-revalidate
```

### Cache de conteúdo estático

Para os arquivos da aplicação que não mudarão, você pode usar um cache mais agressivo enviando o cabeçalho de resposta abaixo. Isto inclui arquivos estáticos servidos pela aplicação tais como imagens, arquivos CSS e JavaScript, por exemplo. Veja também o cabeçalho `Expires`.

```bash
Cache-Control: public, max-age=31536000
```

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

| Especificação | Título |
| --- | --- |
| RFC 7234 | Hypertext Transfer Protocol (HTTP/1.1): Caching |
| RFC 5861 | HTTP Cache-Control Extensions for Stale Content |
| RFC 8246 | HTTP Immutable Responses |

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

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

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

* HTTP Caching FAQ (en-US)
* `Age`
* `Expires`
* `Pragma`


Content-Encoding - HTTP

Content-Encoding
================

The **`Content-Encoding`** entity header is used to compress the media-type. When present, its value indicates which encodings were applied to the entity-body. It lets the client know how to decode in order to obtain the media-type referenced by the `Content-Type` header.

The recommendation is to compress data as much as possible and therefore to use this field, but some types of resources, such as jpeg images, are already compressed. Sometimes, using additional compression doesn't reduce payload size and can even make the payload longer.

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

Sintaxe
-------
```

Content-Encoding: gzip
Content-Encoding: compress
Content-Encoding: deflate
Content-Encoding: identity
Content-Encoding: br

// Múltiplo, em ordem nos quais serão aplicados
Content-Encoding: gzip, identity
Content-Encoding: deflate, gzip
```

Diretivas
---------

`gzip`

A format using the Lempel-Ziv coding (LZ77), with a 32-bit CRC. This is the original format of the UNIX *gzip* program. The HTTP/1.1 standard also recommends that the servers supporting this content-encoding should recognize `x-gzip` as an alias, for compatibility purposes.

`compress`

A format using the Lempel-Ziv-Welch (LZW) algorithm. The value name was taken from the UNIX *compress* program, which implemented this algorithm. Like the compress program, which has disappeared from most UNIX distributions, this content-encoding is not used by many browsers today, partly because of a patent issue (it expired in 2003).

`deflate`

Using the zlib structure (defined in RFC 1950) with the *deflate* compression algorithm (defined in RFC 1951).

`identity`

Indicates the identity function (i.e., no compression or modification). This token, except if explicitly specified, is always deemed acceptable.

`br`

A format using the Brotli algorithm.

Exemplos
--------

### Comprimindo com gzip

On the client side, you can advertise a list of compression schemes that will be sent along in an HTTP request. The `Accept-Encoding` header is used for negotiating content encoding.
```

Accept-Encoding: gzip, deflate
```

The server responds with the scheme used, indicated by the `Content-Encoding` response header.
```

Content-Encoding: gzip
```

Note that the server is not obligated to use any compression method. Compression highly depends on server settings and used server modules.

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

| Especificação | Título |
| --- | --- |
| RFC 7932: Brotli Compressed Data Format | Brotli Compressed Data Format |
| RFC 7231, sessão 3.1.2.2: Content-Encoding | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |
| RFC 2616, sessão 14.11: Content-Encoding | Content-Encoding |

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

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

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

* `Accept-Encoding`
* `Transfer-Encoding`


ETag - HTTP

ETag
====

O HTTP provê no cabeçalho (header) da resposta (response), a **`ETag`** que é um identificador para uma versão específica de um recurso. A ETag permite que o cache torne-se mais eficiente e preserve o tráfego de dados (largura de banda), assim um web server não precisa reenviar uma resposta com todos os dados que não tiveram nenhuma mudança em seu conteúdo. Além disso, as ETags ajudam a impedir que atualizações simultâneas de um recurso sejam feitas por outros. Veja sobre ("mid-air collisions").

Se o recurso numa URL sofre mudança, a `Etag` assume um novo valor que deve ser gerado pelo Web Server. Uma comparação entre elas podem determinar se as duas representações do recurso são iguais. Etags são similares às nossas impressões digitais, e por isso também podem ser usadas por alguns servidores como um forma de rastreamento. Elas podem ser configuradas a fim de que possam ser persistidas idenfinidamente por um servidor de rastreamento.

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

Sintaxe
-------
```

ETag: W/"<etag_value>"
ETag: "<etag_value>"
```

Diretivas
---------

`W/` Optional

`'W/'` (case-sensitive) Indica que um validador fraco está sendo usado (veja mais em weak validator (en-US)). *Etags Fracas* são fáceis de serem geradas, mas possuem a desvantagem de serem menos usadas para comparações. *Validadores Fortes* são ideais para comparações mas podem ser muito difíceis de serem gerados de uma forma eficaz. Os valores de uma Etag Fraca para duas representações de um único recurso podem ser equivalentes semanticamente, contudo não são idênticas em byte-for-byte. Isto significa que etags fracas impedem o cache efetivo quando requisições dentro de um intervalo de bytes são realizadas (veja mais em byte range requests ), ao passo que etags fortes permitem que um intervalo de requisições aindam possam ser preservadas no cache.

"<etag\_value>"

Tag na Entidade que possui valor único o qual está representando o recurso requisitado. O valor será do tipo string com caracteres em ASCII que será exibido dentro de aspas duplas, como pode se vê ao lado `"675af34563dc-tr34"`. O método por qual o valor da `ETag` foi gerado não está especificado. Frequentemente, uma hash do conteúdo, uma hash da última modificação ou somente um número de revisão é usado. Por exemplo o MDN usa uma hash hexadecimal para o conteúdo do artigo da wiki.

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

ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
ETag: W/"0815"
```

### Fugindo de ediçoes simultâneas

Com a ajuda da `ETag` e o cabeçalho `If-Match` (*headers*), você pode detectar choque de edições simultânes.

Por exemplo, quando editamos o MDN, o conteúdo atual da wiki é criptografado e colocado dentro de uma `Etag` da resposta (response).
```

ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
```

Quando salvamos as mudanças para a página da wiki, (posting data), a requisição `POST` conterá o cabeçalho `If-Match` contendo o valor da `ETag` para checar a atualização.
```

If-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"
```

Se o hash não for compatível, isto significa que o documento foi editado durante determinado intervalo e uma resposta com o status `412` `Precondition Failed` será enviada ao cliente.

### Armazenando recursos sem alterações

Outro uso típico de cabeçalho (header) com a `ETag` é para guardar recursos que não foram alterados. Se um usuário visitar um recurso dado por uma URL de novo, (é necessaíro ter a `ETag` configurada), e ele deseja saber se está obsoleto (*stale)* (ou antigo para ser considerado como utilizável), o cliente enviará o valor da sua `ETag` por meio de um atributo no cabeçalho `If-None-Match`, veja o exemplo abaixo:
```

If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"
```

O servidor irá comparar a `ETag` do cliente (enviada com `If-None-Match`) com a versão da `ETag` disponível para o recurso, e se ambos os valores forem compatíveis (isto é, o recurso não foi modificado), o servidor enviará de volta a resposta com status `304` `Sem Modificação (Not modified)`, porém sem um body, comunicando ao cliente que a versão guardada na resposta ainda está atualizada (ou boa para uso, *fresh*).

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

| Especificação | Título |
| --- | --- |
| RFC 7232, sessão 2.3: ETag | 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
-----------

* `If-Match`
* `If-None-Match`
* `304` `Not Modified`
* `412` `Precondition Failed`
* W3C Note: Editing the Web – Detecting the Lost Update Problem Using Unreserved Checkout


Accept-Language - HTTP

Accept-Language
===============

O cabeçalho HTTP **`Accept-Language`** anuncia quais linguas o cliente é capaz de entender, e qual é a preferência do variante do Locale. (Por Linguas, queremos dizer linguas como Inglês e portugues) Usando content negotiation, o servidor seleciona uma das propostas, usa ela e informa o cliente da sua escolha com o `Content-Language` cabeçalho de responsta. Navegadores configuram valores adequados para este cabeçalhos de acordo com a língua configurada pelo usuario.

Este cabeçalho é uma dica a ser usada pelo servidor quando ele não possui outra forma de determinar a lingua do cliente, como uma URL específica, que é controlada por uma decisão explicita do usuário. É recomendado que o servidor nunca sobreescreva uma decisão explícita. O conteúdo de `Accept-Language` está comumente fora do controle do usuário (em uma viagem a outro país por exemplo); O usuário pode querer acessar a página em outra língua diferente da decidida pelo navegador.

Se o servicor não encontrar uma língua correspondente, ele pode, teóricamente responder com o código de erro`406` (Not Acceptable) . Mas, para uma melhor experiência de usuário, isso raramente é feito. Mais comumente, quando isso ocorre, o cabeçalho é ignorado.

|  |  |
| --- | --- |
| Tipo de Cabeçalho | Request header |
| Forbidden header name | no |
| CORS-safelisted request-header (en-US) | yes |

Syntax
------
```

Accept-Language: <language>
Accept-Language: *

// Multiple types, weighted with the quality value (en-US) syntax:
Accept-Language: fr-CH, fr;q=0.9, en;q=0.8, de;q=0.7, *;q=0.5
```

Diretivas
---------

`<language>`

A tag language (a qual pode ser chamada de "identificador de Locale") consiste de uma tag de 2 a 3 letras representando a lingua, opcionalmente pode ser seguida de um `'-'` separa outras informações extras. A mais comum informação extra é a região do país (como`'pt-BR'` ou `'pt-PT'`) ou o tipo do alfabeto a ser usado (como`'sr-Latn'`). Outras variantes como o tipo de ortografia (`'de-DE-1996'`) normalmente não são utilizadas no contexto deste cabeçalho.

`*`

Qualquer lingua; `'*'` é utilizado como curinga.

`;q=` (q-factor weighting)

Any value placed in an order of preference expressed using a relative quality value (en-US) called *weight*.

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

Accept-Language: de

Accept-Language: de-CH

Accept-Language: en-US,en;q=0.5
```

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

| Specification | Title |
| --- | --- |
| RFC 7231, sessão 5.3.5: Accept-Language | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Context |
| BCP 47 | Tags for the Identification of Language |

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

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

See also
--------

* HTTP content negotiation
* Header with the result of the content negotiation: `Content-Language`
* Other similar headers: `TE`, `Accept-Encoding`, `Accept-Charset`, `Accept`


Vary - HTTP

Vary
====

O cabeçalho de resposta HTTP **`Vary`** determina como corresponder futuros cabeçalhos de requisição para decidir se uma resposta cacheada pode ser usada ao invés de solicitar uma nova do servidor de origem. Ele é usado pelo servidor para indicar quais cabeçalhos ele utilizou quando selecionando a representação do recurso em um algoritmo de negociação de conteúdo.

O cabeçalho `Vary` deve ser colocado em uma resposta `304` `Not Modified` exatamente como seria colocado em uma resposta `200` `OK` equivalente.

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

Sintaxe
-------
```

Vary: *
Vary: <header-name>, <header-name>, ...
```

Diretivas
---------

\*

Cada requisição para a URL é supostamente tratada como uma requisição única e incacheavél. Um jeito melhor de indicar isso é usar `Cache-Control`: `no-store`, que é mais limpo para se ler e também sinaliza que o objeto não deve ser guardado nunca.

<header-name>

Uma lista separada por vírgula de nomes de cabeçalhos para levar em conta quando for decidir se uma resposta cacheada pode ser usada.

Exemplos
--------

### Servimento dinâmico

Quando utilizando o cabeçalho `Vary: User-Agent`, servidores de cacheamento devem considerar o agente de usuário quando estiverem decidindo se irão servir a página do cache. Por exemplo, se você está servindo conteúdo diferente para usuários móveis, ele pode ajudar você a evitar que um cache possa erroneamente servir uma versão desktop do seu site, para os usuários móveis. Ele pode ajudar o Google e outros motores de busca a descobrir a versão móvel da página, e talvez possa dizer a eles que não existe intenção de Cloaking.
```

Vary: User-Agent
```

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

| Especificação | Título |
| --- | --- |
| RFC 7231, sessão 7.1.4: Vary | 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.

Notas de compatibilidade
------------------------

* Vary com cuidado – Problemas do cabeçalho Vary em IE6-9
Veja também
-----------

* Entendendo o cabeçalho Vary (Understanding The Vary Header) - Smashing Magazine
* Melhores práticas quando utilizando o cabeçalho Vary (Best Practices for Using the Vary Header) – fastly.com
* Negociação de conteúdo


If-Range - HTTP

If-Range
========

O cabeçalho de requisição HTTP **`If-Range`** faz uma requisição de intervalo condicional: se a condição é realizada, a requisição de intervalo será enviada e o servidor mandará de volta como resposta um `206` `Partial Content` com o corpo apropriado. Se a condição não é realizada, a recurso inteiro é enviado de volta, com um código de status `200` `OK`.

Este cabeçalho pode ser usado ou com um validador `Last-Modified`, ou com um `ETag`, mas não com ambos.

O caso de uso mais comum é continuar um *download*, para garantir que o recurso guardado não tenha sido modificado desde o último fragmento que foi recebido.

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

Sintaxe
-------
```

If-Range: <nome-dia>, <dia> <mês> <ano> <hora>:<minuto>:<segundo> GMT
If-Range: <etag>
```

Diretivas
---------

<etag>

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

<nome-dia>

Um entre "Mon", "Tue", "Wed", "Thu", "Fri", "Sat", or "Sun" (sensível ao caso).

<dia>

2 digitos, número do dia. Por exemplo "04" ou "23".

<mês>

Um entre "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" (sensível ao caso).

<ano>

4 digitos, número do ano,. Por exemplo. "1990" ou "2016".

<hora>

2 digitos, número da hora. Por exemplo. "09" ou "23".

<minuto>

2 digiitos, número do minuto. Por exemplo. "04" ou "59".

<segundo>

2 digitos, número dos segundo, Por exemplo. "04" ou "59".

`GMT`

Horário de Greenwich (Greenwich Mean Time). Datas HTTP sempre são expressas em GMT, nunca em tempo local.

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

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

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

| Especificação | Título |
| --- | --- |
| RFC 7233, sessão 3.2: If-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
-----------

* `ETag`
* `Last-Modified`
* `If-Modified-Since`
* `If-Unmodified-Since`
* `If-Match`
* `If-None-Match`
* `206` `Partial Content`
* Requisições Condicionais HTTP (en-US)


Warning - HTTP

Warning
=======

**Nota:** O cabeçalho `Warning` será depreciado em breve; veja Warning (https://github.com/httpwg/http-core/issues/139) e Warning: header & stale-while-revalidate (https://github.com/whatwg/fetch/issues/913) para mais detalhes.

O cabeçalho geral HTTP **`Warning`** contém informação sobre possíveis problemas com o status da mensagem. Mais de um cabeçalho `Warning` pode aparecer na resposta.

O cabeçalho `Warning` geralmente pode ser aplicado para qualquer mensagem, entretanto alguns códigos de aviso são específicos para caches e podem somente ser aplicados para mensagens de resposta.

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

Sintaxe
-------
```

Warning: <warn-code> <warn-agent> <warn-text> [<warn-date>]
```

Diretivas
---------

<warn-code>

Um número de aviso de três dígitos. O primeiro dígito indica se é necessário o `Warning` ser deletado de uma resposta guardada depois da validação.

* Códigos de aviso `1xx` descrevem o frescor ou status de validação da resposta e será deletado por um cache depois da deleção.
* Códigos de aviso `2xx` descrevem algum aspecto da representação que não é retificada por uma validação e não será deletado por uma cache depois da validação a não que a resposta completa seja enviada.

<warn-agent>

O nome ou pseudônimo do servidor ou software adicionando o cabeçalho `Warning` (pode ser "-" quando o agente não é conhecido).

<warn-text>

Texto consultivo descrevendo o erro.

<warn-date>

Opcional. Se mais de um cabeçalho `Warning` é enviado, inclui a data que corresponde com o cabeçalho `Date`.

Códigos de aviso (Warning)
--------------------------

O registro de Códigos de Aviso HTTP em iana.org define o espaço de nomes para códigos de aviso.

| Código | Texto | Descrição |
| --- | --- | --- |
| 110 | Resposta está velha | A resposta provida pela cache está velha (o tempo de expiração já passou). |
| 111 | Revalidação falhou | Uma tentaiva de validar a resposta falhou, por causa da impossibilidade de alcançar o servidor. |
| 112 | Operação Desconectou | O cache desconectou do resto da rede. |
| 113 | Expiração Heurística | Enviado se a cache escolhe heuristicamente um tempo de vida fresco maior que 24 horas e a idade da resposta é maior que 24 horas. |
| 199 | Aviso diverso | Arbitrário, aviso não específico. |
| 214 | Transformação aplicada | Adicionado por um proxy se ele aplica qualquer transformação na representação, como mudar a codificação de conteúdo, tipo de media ou semelhante. |
| 299 | Aviso diverso persistente | O mesmo que 199, mas indicando um aviso persistente. |

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

Warning: 110 anderson/1.3.37 "Response is stale"

Date: Wed, 21 Oct 2015 07:28:00 GMT
Warning: 112 - "cache down" "Wed, 21 Oct 2015 07:28:00 GMT"
```

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

| Especificação | Título |
| --- | --- |
| RFC 7234, sessão 5.5: Warning | 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
-----------

* `Date`
* Código de resposta de status HTTP


Accept-Ranges - HTTP

Accept-Ranges
=============

O cabeçalho de resposta HTTP **`Accept-Ranges`** é um marcador usado pelo servidor para indicar que ele suporta requisições parciais. O valor deste campo indica a unidade utilizada para definir o tamanho.

Na presença do cabeçalho `Accept-Ranges`, o navegador pode tentar retomar um *download* interrompido, ao invés de começar de novo do início.

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

Sintaxe
-------
```

Accept-Ranges: bytes
Accept-Ranges: none
```

Diretivas
---------

`none`

Nenhuma unidade de tamanho é suportada, isso faz com que o cabeçalho seja equivalente a sua própria ausência, sendo então raramente usado, apesar de que alguns navegadores, como o IE9, é usado para habilitar ou desabilitar os botões de pausa no gerenciador de downloads.

`bytes`

A unidade de tamanho são bytes.

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

Accept-Ranges: bytes
```

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

| Especificação | Título |
| --- | --- |
| RFC 7233, sessão 2.3: Accept-Ranges | 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`


Set-Cookie - HTTP

Set-Cookie
==========

O cabeçalho de resposta HTTP **`Set-Cookie`** é usado para enviar cookies de um servidor para o agente usuário.

Para mais informações, veja o guia em HTTP cookies.

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

Sintaxe
-------
```

Set-Cookie: <nome-cookie>=<valor-cookie>
Set-Cookie: <nome-cookie>=<valor-cookie>; Expires=<date>
Set-Cookie: <nome-cookie>=<valor-cookie>; Max-Age=<non-zero-digit>
Set-Cookie: <nome-cookie>=<valor-cookie>; Domain=<domain-value>
Set-Cookie: <nome-cookie>=<valor-cookie>; Path=<path-value>
Set-Cookie: <nome-cookie>=<valor-cookie>; Secure
Set-Cookie: <nome-cookie>=<valor-cookie>; HttpOnly

Set-Cookie: <nome-cookie>=<valor-cookie>; SameSite=Strict
Set-Cookie: <nome-cookie>=<valor-cookie>; SameSite=Lax

// São possíveis multiplas diretivas, por exemplo:
Set-Cookie: <nome-cookie>=<valor-cookie>; Domain=<domain-value>; Secure; HttpOnly
```

Diretivas
---------

`<nome-cookie>=<valor-cookie>`

Um cookie começa com um par nome-valor:

* Um `<nome-cookie>` pode ser qualquer caractere US-ASCII exeto caracteres de controle (CTLs), espaços, ou tabulações (TAB). Também não deve conter um separador de caractere como os seguintes: ( ) < > @ , ; : \ " / [ ] ? = { }.
* Um `<valor-cookie>` pode opcionalmente ser atribuido entre aspas duplas e qualquer caractere US-ASCII são permitidos, exceto caracteres de controle (CTLs), espaços em branco, aspas duplas, vírgula, barra invertida e ponto e vírgula. **Codificação**: Muitas implementações realizam codificação URL nos valores de cookie, contudo não é obrigatório pela especificação do RFC. Isso ajuda a satisfazer os requisitos sobre quais caracteres são permitidos para <valor-cookie>.
* **`Prefixo __Secure-`**: Cookies com o nome começando com `__Secure-` (hífen faz parte do prefixo) precisam ser atribuidos com a flag de segurança e precisam ser de uma página segura (HTTPS).
* **`Prefixo __Host-`**: Cookies com o nome começando com `__Host-` (hífen faz parte do prefixoprecisam ser atribuidos com a flag de segurança, precisam ser de uma página segura (HTTPS), não precisam ter um domínio especificado (portanto não são enviados para subdomínios) e o caminho (path) precisa ser "/".

Expires=<data> Optional

O tempo de vida máximo do cookie como uma marcação de tempo (timestamp) HTTP. Veja `Date` para a formatação detalhada.

Se não especificado, o cookie terá o tempo de vida de uma **sessão de cookie.** Uma sessão é finalizada quando o cliente é desligado, significando que as sessões de cookies serão removidos nesse momento. Contudo, muitos navegadores web têm uma característica denominada de "restaurar sessão" que salvará todas suas abas e as trará de volta na próxima vez em que você utilizar o navegador. Os cookies estarão também presentes e será como se o navegador nunca tivesse sido fechado.

Quando uma data de expiração é atribuída, o tempo e a data são relativos ao cliente em que os cookies estão sendo configurados e não ao servidor.

Max-Age=<digito-diferente-de-0> Optional

Número de segundos até o cookie expirar. Um ou mais digitos de 1 a 9. Navegadores antigos (ie6, ie7 e ie8) não suportam Max-Age. Para cada navegador, se ambos (Expires e Max-Age) forem atribuídos, Max-Age terá precedência.

Domain=<valor-domínio> Optional

Especifica os hosts aos quais o cookie será enviado.

* Se não for especificado, será usado o host do URL do documento atual, não incluindo subdomínios.
* Ao contrário das especificações anteriores, pontos de prefixo em nomes de domínio (`.example.com`) são ignorados.
* Se um domínio for especificado, subdomínios estarão sempre incluídos.

Path=<valor-caminho> Optional

Indica um caminho (path) de URL que necessita existir no recurso solicitado antes de enviar o cabeçalho de Cookie. O caractere %x2F ("/") é interpretado como um separador de diretório e os sub-diretórios serão também correspondidos (por exemplo: Path=/docs, "/docs", "/docs/Web", ou "/docs/Web/HTTP" serão todos correspondidos).

Secure Optional

Um cookie seguro apenas será enviado para o servidor quando uma requisição utilizando os protocol SSL e HTTPS for realizada. No entanto, informações confidenciais ou sensíveis não deverão ser armazenadas ou transmitidas em Cookies HTTP pois todo o mecanismo é inerentemente inseguro e isso não significa, por exemplo que qualquer informação é criptografada.

**Nota:** Sites inseguros (`http:`) não podem mais atribuir cookies com a diretiva "secure" (novo em Chrome 52+ firefox Firefox 52+).

HttpOnly Optional

Cookies HttpOnly não são acessíveis via JavaScript através da propriedade `Document.cookie` (en-US), as API's `XMLHttpRequest` e `Request` são utilizadas para aliviar ataques de cross-site scripting (XSS (en-US)).

SameSite=Strict
 SameSite=Lax Optional
Experimental

Permite que servidores garantam que um cookie não deve ser enviado juntamente com solicitações de sites cruzados (cross-site) , o que fornece novamente alguma proteção aos ataques de falsificação de solicitação entre sites (CSRF) (CSRF (en-US)) *.*

Exemplos
--------

### Sessão de cookie

Sessão de cookie serão removidos quando o cliente desligar. Eles não especificam as diretivas Expires ou Max-Age. Note que o navegador web tem frequentemente a opção "restaurar sessão" habilitada..
```

Set-Cookie: sessionid=38afes7a8; HttpOnly; Path=/
```

### Cookie permanente

Ao invés de expirar quando o cliente fecha, os cookies permantentes expiram numa data especificada (Expires), ou depois de uma duração de tempo especificada (Max-Age).
```

Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly
```

### Domínios inválidos

Um cookie pertencente a um domínio que não inclui o servidor original, deve ser rejeitado pelo agente usuário. Por exemplo: O cookie seguinte será rejeitado se foi atribuído por um servidor hospedado em originalcompany.com.
```

Set-Cookie: qwerty=219ffwef9w0f; Domain=somecompany.co.uk; Path=/; Expires=Wed, 30 Aug 2019 00:00:00 GMT
```

### Prefixo do cookie

Nomes de cookies com os prefixos `__Secure-` e `__Host-` podem ser utilizados apenas de eles forem atribuídos com a diretiva `secure` de uma origem segura (HTTPS). Além disso, cookies com o prefixo `__Host-` devem ter um caminho (path) de `/` (o host inteiro) e não devem ter um atributo de dominio. Para clientes que não implementam prefixos de cookie, você não pode contar com essas garantias adicionais e os cookies serão sempre aceitos.
```

// Ambos aceitos quando de uma origem segura (HTTPS)
Set-Cookie: __Secure-ID=123; Secure; Domain=example.com
Set-Cookie: __Host-ID=123; Secure; Path=/

// Rejeitado devido a não atribuição da diretiva Secure
Set-Cookie: __Secure-id=1

// Rejeitado devido a falta da diretiva Path=/
Set-Cookie: __Host-id=1; Secure

// Rejeitado devido a atribuição de um domínio
Set-Cookie: __Host-id=1; Secure; Path=/; domain=example.com
```

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

| Especificação | Título |
| --- | --- |
| RFC 6265, sessão 4.1: Set-Cookie | HTTP State Management Mechanism |
| RFC draft-ietf-httpbis-cookie-prefixes-00 | Cookie Prefixes |
| RFC draft-ietf-httpbis-cookie-same-site-00 | Same-Site Cookies |
| RFC draft-ietf-httpbis-cookie-alone-01 | Strict Secure Cookies |

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

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

Notas de compatibilidade
------------------------

* Começando com Chrome 53 e Firefox 52, sites inseguros (`http:`) não podem mais atribuir cookies com a diretiva "secure".
Veja também
-----------

* HTTP cookies
* `Cookie`
* `Document.cookie` (en-US)


Cross-Origin-Resource-Policy - HTTP

Cross-Origin-Resource-Policy
============================

**Nota:** Devido a um bug no Chrome, configurar Cross-Origin-Resource-Policy pode quebrar a renderização de PDF, impedindo visitantes de conseguir ler além da primeira página de alguns PDFs. Utilize com cuidado este cabeçalho em um ambiente de produção.

O cabeçalho de resposta HTTP **`Cross-Origin-Resource-Policy`** indica um desejo que o navegador bloqueie requisições que não sejam entre origens e/ou entre sites para um dado recurso.

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

Sintaxe
-------
```

Cross-Origin-Resource-Policy: same-site | same-origin | cross-origin
```

Exemplos
--------

O cabeçalho de resposta abaixo pode causar a agentes de usuário compatíveis a desabilitar requisição que não sejam entre origens:
```

Cross-Origin-Resource-Policy: same-origin
```

Para mais exemplos, veja https://resourcepolicy.fyi/.

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

| Specification |
| --- |
| Fetch Standard # cross-origin-resource-policy-header |

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

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

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

* Explicação da Cross-Origin Resource Policy (CORP) (en-US)
* Considere usar Cross-Origin Resource Policy


Access-Control-Request-Headers - HTTP

Access-Control-Request-Headers
==============================

O cabeçalho da solicitação **`Access-Control-Request-Headers`** é usado ao emitir um preflight request para permitir que o servidor saiba quais cabeçalhos HTTP serão usados quando a solicitação real for feita.

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

Sintaxe
-------
```

Access-Control-Request-Headers: <header-name>, <header-name>, ...
```

Diretivas
---------

<header-name>

Uma lista delimitada por vírgula HTTP headers incluídos na solicitação.

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

Access-Control-Request-Headers: X-PINGOTHER, Content-Type
```

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

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

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

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

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

* `Access-Control-Request-Method`


Referer - HTTP

Referer
=======

O cabeçalho de requisição HTTP **`Referer`** contém o endereço da página web anterior do qual a página atual requerida foi chamada. O `Referer` permite aos servidores identificar de onde as pessoas estão visitando eles e pode usar esses dados para análise, log e cacheamento otimizado, por exemplo.

**Aviso:** **Importante**: Apesar que esse cabeçalho tenha diversos usos inocentes, ele pode ter consequências indesejáveis para segurança e privacidade dos usuários. Veja Referer header: privacy and security concerns (en-US) para mais informações e mitigações.

Note que *referer* é na verdade, uma má pronúncia da palavra "referrer"("referenciador"). Veja HTTP referer no Wikipedia para mais detalhes.

O cabeçalho `Referer` não é enviado pelos navegadores se:

* O recurso referenciado é um arquivo local ou URI de dados.
* Uma requisição HTTP insegura é usada e a página referenciada utilizou o protocolo seguro (HTTPS).

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

Sintaxe
-------
```

Referer: <url>
```

Diretivas
---------

<url>

Um endereço parcial ou absoluto da página web anterior do qual a página atual requirida foi alcançada. Fragmentos de URL (i.e. "#section") e informações de usuário (i.e. "username:password" em "https://username:password@example.com/foo/bar/") não são inclusos.

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

Referer: https://developer.mozilla.org/pt-BR/docs/Web/JavaScript
```

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

| Especificação | Título |
| --- | --- |
| RFC 7231, sessão 5.5.2: Referer | 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
-----------

* HTTP referer no Wikipedia
* `Referrer-Policy`


User-Agent - HTTP

User-Agent
==========

O cabeçalho de requisição **User-Agent** é uma cadeia de caracteres característica que permite servidores e pares de rede identificar a aplicação, sistema operacional, fornecedor, e/ou versão do agente de usuário requisitante.

**Aviso:** Por favor leia Detectando o navegador usando o agente de usuário (Browser detection using the user agent) (en-US) para por quê servir diferentes páginas Web ou serviços para diferentes navegadores é geralmente uma má ideia.

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

Sintaxe
-------
```

User-Agent: <product> / <product-version> <comment>
```

Formato comum para navegadores web:
```

User-Agent: Mozilla/5.0 (<system-information>) <platform> (<platform-details>) <extensions>
```

### Diretivas

`<product>`

Um identificador do produto - seu nome ou codinome de desenvolvimento.

`<product-version>`

Número da versão do produto.

`<comment>`

Zero ou mais comentários contendo mais detalhes; informação de subproduto, por exemplo.

Firefox UA string
-----------------

Para mais cadeias de caracteres de agente de usuário do Firefox e Gecko, veja a referência para cadeias de caracteres de agente de usuário do Firefox (Firefox user agent string reference) (en-US). A cadeia de caracteres UA do Firefox é quebrada em 4 componentes:
```

Mozilla/5.0 (platform; rv:geckoversion) Gecko/geckotrail Firefox/firefoxversion
```

1. `Mozilla/5.0` é o *token* geral que diz que o navegador é compatível com Mozilla. Por razões históricas, quase todo navegador envia isso hoje.
2. ***platform*** descreve a plataforma nativa que navegador está executando (Windows, Mac, Linux, Android, etc.), e se é um telefone celular. Telefones Firefox OS (en-US) simplesmente dizem `Mobile` — a web é a plataforma. Note que ***platform*** pode consistir de múltiplos *tokens* separador por "`;`" (ponto e vírgula). Veja abaixo para mais detalhes e exemplos.
3. **rv:*geckoversion*** indica a versão de *release* do Gecko (como a "*17.0*"). Em navegadores recentes, ***geckoversion*** é o mesmo que ***firefoxversion***.
4. ***Gecko/geckotrail*** indica que o navegador é baseado no Gecko. (No Desktop, ***geckotrail*** é sempre a cadeia de caracteres fixa `20100101`.)
5. ***Firefox/firefoxversion*** indica que o navegador é o Firefox, e provém a versão (como a "*17.0"*).
### Exemplos
```

Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:47.0) Gecko/20100101 Firefox/47.0
Mozilla/5.0 (Macintosh; Intel Mac OS X x.y; rv:42.0) Gecko/20100101 Firefox/42.0
```

Chrome UA string
----------------

A cadeia de caracteres do agente de usuário do Chrome (ou baseados em Chromium/Blink) é similar ao do Firefox. Para compatibilidade, ele adiciona cadeias de caracteres como `KHTML, like Gecko` e `Safari`.

### Exemplos
```

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36
```

Opera UA string
---------------

O navegador Opera também é baseado no Blink, o motivo pelo qual se parecem muito, mas adiciona `"OPR/<version>"`.

### Exemplos
```

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36 OPR/38.0.2220.41
```

Mais antigo, versões do Opera baseados no Presto usavam:
```

Opera/9.80 (Macintosh; Intel Mac OS X; U; en) Presto/2.2.15 Version/10.00
Opera/9.60 (Windows NT 6.0; U; en) Presto/2.1.1
```

Safari UA string
----------------

Neste exemplo, a cadeia de caracteres de agente de usuários é a versão de móvel do Safari. Ela contém a palavra `"Mobile"`.

### Exemplos
```

Mozilla/5.0 (iPhone; CPU iPhone OS 13_5_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.1.1 Mobile/15E148 Safari/604.1
```

Internet Explorer UA string
---------------------------

### Exemplos
```

Mozilla/5.0 (compatible; MSIE 9.0; Windows Phone OS 7.5; Trident/5.0; IEMobile/9.0)
```

Crawler e bot UA strings
------------------------

Exemplos
```

Googlebot/2.1 (+http://www.google.com/bot.html)
```

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

| Especificação | Título |
| --- | --- |
| RFC 7231, sessão 5.5.3: User-Agent | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |
| RFC 2616, sessão 14.43: User-Agent | Hypertext Transfer Protocol — HTTP/1.1 |

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

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

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

* Detecção, histórico e checklist de User-Agent
* Referência para cadeias de caracteres de agente de usuário do Firefox (Firefox user agent string reference) (en-US)
* Detectando o navegador usando o agente de usuário (Browser detection using the user agent) (en-US)


X-Forwarded-For - HTTP

X-Forwarded-For
===============

O cabeçalho **`X-Forwarded-For`** (XFF) é de fato um cabeçalho padrão para identificar o endereço de IP original de um cliente conectando a um servidor web através de um proxy HTTP ou um balenceador de carga. Quando tráfego específico é interceptado entre clientes e servidores, *logs* de acesso do servidor contém o endereço IP do proxy ou balanceador de carga somente. Para ver o endereço IP original do cliente, o cabeçalho de requisição `X-Forwarded-For` é 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`.

`X-Forwarded-For` é também um cabeçalho de email indicando que uma mensagem de email foi redirecionada para outra conta.

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

Sintaxe
-------
```

X-Forwarded-For: <client>, <proxy1>, <proxy2>
```

Diretivas
---------

<client>

O endereço de IP do cliente.

<proxy1>, <proxy2>

Se a requisição atravessa múltiplos proxies, os endereços IP de cada proxy sucessivo são listados. Isto significa, o endereço IP mais a direita é o endereço IP mais do proxy mais recente, e o endereço IP mais a esquerda é o endereço IP originário do cliente.

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

X-Forwarded-For: 2001:db8:85a3:8d3:1319:8a2e:370:7348

X-Forwarded-For: 203.0.113.195

X-Forwarded-For: 203.0.113.195, 70.41.3.18, 150.172.238.178
```

Outras formas não padronizadas:
```

# Usado por alguns serviços da Google
X-ProxyUser-Ip: 203.0.113.19
```

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

* `Forwarded`
* `X-Forwarded-Host`
* `X-Forwarded-Proto`
* `Via`


Trailer - HTTP

Trailer
=======

O cabeçalho de resposta **Trailer** permite o remetente incluir campos adicionais ao final de mensagens fragmentadas visando prover metadados que podem ser dinamicamente gerados enquanto o corpo da mensagem é enviado, como a mensagem de checagem de integridade, assinatura digital, ou status de pós-processamento.

**Nota:** O cabeçalho de requisição `TE` precisa ser colocado como "trailers" para permitir campos de reboque (*trailers*).

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

Sintaxe
-------
```

Trailer: header-names
```

Diretivas
---------

`header-names`

Cabeçalhos HTTP que estarão presentes na parte de reboque das mensagens fragmentadas. Estes campos de cabeçalhos **não** estão permitidos:

* cabeçalhos de enquadramento de mensagem (e.g., `Transfer-Encoding` e `Content-Length`),
* Cabeçalhos de roteamento (e.g., `Host`),
* Modificadores de requisição (e.g., controles e condicionais, como `Cache-Control`, `Max-Forwards` (en-US), ou `TE`),
* cabeçalhos de autenticação (e.g., `Authorization` ou `Set-Cookie`),
* ou `Content-Encoding`, `Content-Type`, `Content-Range`, e `Trailer` em si.

Exemplos
--------

### Codificação de transferência fragmentada usando cabeçalho de reboque

Neste exemplo, o cabeçalho `Expires` é usado no fim da mensagem fragmentada e serve como cabeçalho de reboque.
```

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

7\r\n
Mozilla\r\n
9\r\n
Developer\r\n
7\r\n
Network\r\n
0\r\n
Expires: Wed, 21 Oct 2015 07:28:00 GMT\r\n
\r\n
```

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

| Especificação | Título |
| --- | --- |
| RFC 7230, sessão 4.4: Trailer | Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing |
| RFC 7230, sessão 4.1.2: Chunked trailer part | 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`
* `TE`
* Codificação de transferência fragmentada


Accept-Charset - HTTP

Accept-Charset
==============

O cabeçalho de requisição HTTP **`Accept-Charset`** anuncia quais character encodings o cliente entende. Usando negociação de conteúdo, o servidor seleciona uma das codificações, a utiliza, e informa o cliente da sua escolha dentro do cabeçalho de resposta `Content-Type`, geralmente em um parâmetro `charset=`. Navegadores geralmente não mandam este cabeçalho, por que o valor padrão para cada recurso geralmente está correto e transmiti-lo iria permitir fingerprinting (en-US).

Se o servidor não pode servir nenhum codificação de caracteres vindo deste cabeçalho de requisição, ele pode teoricamente manda de volta um código de erro `406 Not Acceptable`. Mas para uma melhor experiência de usuário, isso raramente é feito e o cabeçalho `Accept-Charset` é ignorado.

**Nota:** Nas versões mais antigas do HTTP/1.1, a codificação de caracteres definida era: ISO-8859-1. Isto não é mais recomendado, e agora todo tipo de conteúdo tem o seu próprio padrão.

O UTF-8 é agora muito bem suportado e extremamente recomendado como codificação de caracteres preferida. Para garantir melhor privacidade e através de menor entropia com base em configuração, todos os navegadores omitem o cabeçalho `Accept-Charset`: Internet Explorer 8+, Safari 5+, Opera 11+, Firefox 10+ e Chrome 27+ não o enviam mais.

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

Sintaxe
-------
```

Accept-Charset: <charset>

// Múltiplos tipos, com pesos baseados na sintaxe de quality value (en-US):
Accept-Charset: utf-8, iso-8859-1;q=0.5
```

Diretivas
---------

`<charset>`

O nome da codificação de caracteres, como `utf-8` ou `iso-8859-15.`

`*`

Qualquer codificação de caracteres não mencionada em qualquer lugar no cabeçalho; `*` é usado como coringa.

`;q=<weight>`

Qualquer codificação de caracteres é colocado na ordem de preferência, expresso usando um quality value (en-US) relativo chamado de *peso*.

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

Accept-Charset: iso-8859-1

Accept-Charset: utf-8, iso-8859-1;q=0.5

Accept-Charset: utf-8, iso-8859-1;q=0.5, *;q=0.1
```

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

| Especificação | Título |
| --- | --- |
| RFC 7231, sessão 5.3.3: Accept-Charset | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Context |

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

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

* Negociação de conteúdo HTTP
* Nunca mais Accept-Charset
* Cabeçalho com a resposta do conteúdo de negociação: `Content-Type`
* Outros cabeçalhos similares: `TE`, `Accept-Encoding`, `Accept-Language`, `Accept`


Server - HTTP

Server
======

O cabeçalho **`Server`** contem informação sobre o software usado pelo servidor de origem para manipular a solicitação.

Valores excessivamente longos e detalhados do Servidor devem ser evitados, já que eles potencialmente revelam detalhes internos de implementação que podem tornar (um pouco) mais fácil para os invasores encontrarem e explorarem falhas de segurança conhecidas.

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

Syntaxe
-------
```

Server: <product>
```

Diretivas
---------

<product>

O nome do software ou (sub) produto que manipula as solicitações.

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

Server: Apache/2.4.1 (Unix)
```

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

| Specification | Title |
| --- | --- |
| RFC 7231, sessão 7.4.2: Server | Hypertext Transfer Protocol (HTTP/1.1): Semântica e Conteúdo |

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

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

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

* `Allow`


Date - HTTP

Date
====

O cabeçalho geral HTTP **`Date`** contém a data e a hora que a mensagem foi gerada.

**Aviso:** Note que `Date` é listado em nomes de cabeçalhos proibidos na especificação do fetch - então este código não enviará o cabeçalho `Date`:

```js
fetch("https://httpbin.org/get", {
  headers: {
    Date: new Date().toUTCString(),
  },
});
```

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

Sintaxe
-------
```

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

Diretivas
---------

<day-name>

Dia da semana, um de "Mon", "Tue", "Wed", "Thu", "Fri", "Sat", ou "Sun" (sensível a capitalização). Segunda-feira até domingo em ordem.

<day>

Um dia em número de 2 dígitos, e.g. "04" ou "23".

<month>

Um de "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" (sensível a capitalização). Os meses em ordem de Janeiro a Dezembro.

<year>

Um ano em número de 4 dígitos, e.g. "1990" ou "2016".

<hour>

Uma hora em número de 2 dígitos, e.g. "09" ou "23".

<minute>

Minutos em número de 2 dígitos, e.g. "04" ou "59".

<second>

Segundos em número de 2 dígitos, e.g. "04" ou "59".

GMT

Meridiano de Greenwich. Datas HTTP são sempre expressadas em GMT, nunca em tempo local.

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

Date: Wed, 21 Oct 2015 07:28:00 GMT
```

```js
new Date().toUTCString();
// "Mon, 09 Mar 2020 08:13:24 GMT"
```

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

| Especificação | Título |
| --- | --- |
| RFC 7231, sessão 7.1.1.2: Date | 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
-----------

* `Age`


Access-Control-Allow-Headers - HTTP

Access-Control-Allow-Headers
============================

O cabeçalho de resposta **`Access-Control-Allow-Headers`** é usado na resposta à uma preflight request na qual incluí o cabeçalho `Access-Control-Request-Headers` para indicar quais cabeçalhos HTTP podem ser utilizados durante a requisição efetiva.

Este cabeçalho é obrigatório se a requisição tem um cabeçalho `Access-Control-Request-Headers`.

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

Sintaxe
-------
```

Access-Control-Allow-Headers: <nome-do-cabeçalho>[, <nome-do-cabeçalho>]*
Access-Control-Allow-Headers: *
```

Diretivas
---------

`<nome-do-cabeçalho>`

O nome de um cabeçalho suportado. O cabeçalho pode listar qualquer quantidade de cabeçalhos, desde que sejam separados por vírgula.

`*` (coringa)

O valor "`*`" só conta como um valor coringa para requisições sem credenciais (requisições sem cookies HTTP ou informação de autenticação HTTP). Em requisições com credenciais, isso é tratado como o nome de cabeçalho literal "`*`" sem qualquer semântica especial. Note que o cabeçalho `Authorization` não pode utilizar um coringa e sempre precisa ser listado explicitamente.

Os cabeçalhos CORS-safelisted request headers (en-US), `Accept`, `Accept-Language`, `Content-Language`, `Content-Type` são sempre permitidos e não precisam ser listados por este cabeçalho necessariamente. Entretanto, note que restrições adicionais são aplicadas com estes cabeçalhos envolvidos por listar estes cabeçalhos no cabeçalho `Access-Control-Allow-Headers` também.

Exemplos
--------

### Um cabeçalho customizado

Aqui está um exemplos de como um cabeçalho `Access-Control-Allow-Headers` pode se parecer. Isso indica que em adição aos *CORS-safelisted request headers*, um cabeçalho customizado chamado `X-Custom-Header` é suportado por requisições CORS pelo servidor.
```

Access-Control-Allow-Headers: X-Custom-Header
```

### Múltiplos cabeçalhos

Este exemplo mostra o cabeçalho `Access-Control-Allow-Headers` quando é especificado para suportar diversos cabeçalhos.
```

Access-Control-Allow-Headers: X-Custom-Header, Upgrade-Insecure-Requests
```

### Burlando restrições adicionais

Apesar de que CORS-safelisted request headers (en-US) são sempre permitidos e geralmente não precisam ser listados no cabeçalho `Access-Control-Allow-Headers`, listá-los de qualquer forma irá envolver as restrições adicionais (en-US) que são aplicadas.
```

Access-Control-Allow-Headers: Accept
```

### Exemplo de requisição pré-vôo

Vamos dar uma olhada em um exemplo de requisição pré-vôo envolvendo o cabeçalho `Access-Control-Allow-Headers`.

#### Requisição

Primeiro, a requisição. A requisição pré-vôo é uma requisição `OPTIONS` que inclui algumas combinações de três cabeçalhos de requisições pré-vôo: `Access-Control-Request-Method`, `Access-Control-Request-Headers`, e `Origin`, como por exemplo:
```

OPTIONS /resource/foo
Access-Control-Request-Method: DELETE
Access-Control-Request-Headers: origin, x-requested-with
Origin: https://foo.bar.org
```

#### Resposta

Se o servidor permite requisições CORS para usar o método `DELETE`, ele responde com um cabeçalho de resposta `Access-Control-Allow-Methods`, no qual lista `DELETE` junto à outros métodos suportados:
```

HTTP/1.1 200 OK
Content-Length: 0
Connection: keep-alive
Access-Control-Allow-Origin: https://foo.bar.org
Access-Control-Allow-Methods: POST, GET, OPTIONS, DELETE
Access-Control-Max-Age: 86400
```

Se o método requisitado não é suportado, o servidor irá responder com um erro.

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

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

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

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

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

* `Access-Control-Allow-Origin`
* `Access-Control-Expose-Headers`
* `Access-Control-Allow-Methods`
* `Access-Control-Request-Headers`


Access-Control-Allow-Credentials - HTTP

Access-Control-Allow-Credentials
================================

O cabeçalho de resposta **`Access-Control-Allow-Credentials`** diz aos navegadores se a resposta deve ser exposta ao código *frontend* JavaScript quando o modo de credenciais da requisição (`Request.credentials` (en-US)) é `include`.

Quando o modo de credenciais da requisição (`Request.credentials` (en-US)) é `include`, navegadores vão somente expor a resposta ao código *frontend* JavaScript se o valor de `Access-Control-Allow-Credentials` for `true`.

Credenciais são *cookies*, cabeçalhos de autorização ou certificados de cliente TLS.

Quando usado como parte de uma resposta a uma requisição pré-vôo (*preflight)*, isso indica se a requisição atual vai ou não ser feita usando credenciais. Note que uma simples requisição `GET` não é feita com pré-vôo, e se uma requisição é feita para um recurso usando credenciais, se o cabeçalho não é retornado com o recurso, a resposta é ignorada pelo navegador e não é retornada ao conteúdo web.

O cabeçalho `Access-Control-Allow-Credentials` funciona em conjunto com a propriedade `XMLHttpRequest.withCredentials` (en-US) ou com a opção `credentials` na construtor da `Request()` na Fetch API. Para requisições CORS com credenciais, para que os navegadores exponham a resposta ao código *frontend* JavaScript, ambos o servidor (usando o cabeçalho `Access-Control-Allow-Credentials`) e o cliente (colocando o modo de credenciais para o XHR, Fetch, ou requisição Ajax) devem indicar que eles estão optando por incluir as credenciais.

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

Sintaxe
-------
```

Access-Control-Allow-Credentials: true
```

Diretivas
---------

true

O único valor válido para este cabeçalho é `true` (case-sensitive). Se você não precisa de credenciais, omita este cabeçalho inteiramente (ao invés de colocar seu valor para `false`).

Exemplos
--------

Permitindo credenciais:
```

Access-Control-Allow-Credentials: true
```

Usando XHR com credenciais:

```js
var xhr = new XMLHttpRequest();
xhr.open("GET", "http://example.com/", true);
xhr.withCredentials = true;
xhr.send(null);
```

Usando Fetch com credenciais:

```js
fetch(url, {
  credentials: "include",
});
```

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

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

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

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

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

* `XMLHttpRequest.withCredentials` (en-US)
* `Request()`


Retry-After - HTTP

Retry-After
===========

O cabeçalho de resposta HTTP **`Retry-After`** indica quanto tempo o agente de usuário deve aguardar antes de fazer outro pedido de acompanhamento. Existem dois casos principais em que este cabeçalho é usado:

* Quando enviado com uma resposta `503` (Service Unavailable), indica quanto tempo o serviço deve ficar indisponível.
* Quando enviado com uma resposta de redirecionamento, como `301` (Moved Permanently), indica o tempo mínimo solicitado que o agente de usuário aguarde antes de realizar o pedido de redirecionamento.

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

Sintaxe
-------
```

Retry-After: <data-http>
Retry-After: <atraso-segundos>
```

Diretivas
---------

<data-http>

Uma data para tentar novamente posteriormente. Veja o cabeçalho `Date` para mais detalhes sobre o formato de data HTTP.

<atraso-segundos>

Um decimal inteiro não-negativo indicando o tempo em segundos para esperar após a resposta ser recebida.

Exemplos
--------

### Lidando com uma indisponibilidade programada

O suporte para o cabeçalho `Retry-After` tanto em clientes quanto em servidores ainda é inconsistente. Apesar disto, alguns indexadores e robôs, como o Googlebot, honram o cabeçalho `Retry-After`. É útil enviá-lo junto com uma resposta `503` (Service Unavailable), assim, os mecanismos de busca poderão continuar indexando o seu site quando a indisponibilidade acabar.
```

Retry-After: Wed, 21 Oct 2015 07:28:00 GMT
Retry-After: 120
```

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

| Especificação | Título |
| --- | --- |
| RFC 7231, sessão 7.1.3: Retry-After | 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
-----------

* Google Webmaster blog: How to deal with planned site downtime
* `503` (Service Unavailable)
* `301` (Moved Permanently)


Alt-Svc - HTTP

Alt-Svc
=======

O cabeçalho de resposta HTTP **`Alt-Svc`** é usado para indicar que serviços alternativos que podem ser utilizados para alcançar o mesmo recurso. Um serviço alternativo é definido por uma combinação de protocolo/host/porta.

Sintaxe
-------
```

Alt-Svc: clear
Alt-Svc: <protocol-id>=<alt-authority>; ma=<max-age>
Alt-Svc: <protocol-id>=<alt-authority>; ma=<max-age>; persist=1
```

`clear`

O valor especial ''clear" indica que todas as requisições alternativas para aquela origem devem ser invalidadas.

`<protocol-id>`

O identificador de protocolo ALPN (en-US). Exemplos incluem o h2 para HTTP/2 e h3-25 como rascunho 25 para o protocolo HTTP/3.

`<alt-authority>`

A cadeia de caracteres entre aspas especificando a autoridade alternativa que consiste em uma sobrecarga de host opicional, dois pontos e um número de porta mandatório.

`ma=<max-age>`Optional

O número de segundos que o serviço alternativo é considerado "fresco". Se omitido, seu padrão é 24 horas. Entradas de serviços alternativos podem ser cacheados até o limite de *<max-age>* segundos, menos a idade da resposta (do cabeçalho Age). Se a entrada cacheada expirar, o cliente não pode mais usar o serviço alternativo para novas conexões.

`persist=1`Optional

Entradas cacheadas de serviços alternativos geralmente são limpas em mudanças nas configurações de rede. O uso do parâmetro persist=1 assegura que a entrada não será deletada para tais mudanças.

Múltiplas entradas podem ser especificadas em um único cabeçalho Alt-Svc usando vírgula como separador. Neste caso, as primeiras entradas são consideradas as mais preferíveis.

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

Alt-Svc: h2=":443"; ma=2592000;
Alt-Svc: h2=":443"; ma=2592000; persist=1
Alt-Svc: h2="alt.example.com:443", h2=":443"
Alt-Svc: h3-25=":443"; ma=3600, h2=":443"; ma=3600
```

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

| Especificação | Status | Comentários |
| --- | --- | --- |
| RFC 7838 | 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
-----------

* Identificando recursos na Web


Accept-CH - HTTP

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

**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`** é colocado pelo servidor para especificar quais cabeçalhos Client Hints (en-US) o cliente deve incluir nas 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: <lista de client hints>
```

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

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

**Nota:** Lembre de variar a resposta (en-US) baseado nos client hints aceitos.

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

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

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

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


X-Content-Type-Options - HTTP

X-Content-Type-Options
======================

O header de resposta HTTP **X-Content-Type-Options** é um marcador usado pelo servidor para indicar que os MIME types enviados pelos headers `Content-Type` não devem ser alterados e seguidos. Isto permite que o usuário opte por não participar do chamado MIME Type Sniffing ou, em outras palavras, é uma forma de dizer que os webmasters estão vendo o que você está fazendo.

Este header foi incluído pela Microsoft no IE 8 como uma maneira de webmasters serem capazes de bloquear o *sniffing* de conteúdo que acontecia na época, e podia transformar tipos MIME não executáveis em tipos executáveis. Desde então, outros browsers acataram a ideia mesmo que seus algoritmos de definição de MIME fossem menos agressivos.

Experts em segurança da informação geralmente esperam que este header esteja presente.

**Nota:** Nota: `nosniff` só se aplica para tipos "script" e "style". Também, aplicar `nosniff` em tipos de imagem provou-se ser incompatível com sites existentes.

|  |  |
| --- | --- |
| Tipo do header | Header de resposta |
| Alteração de nome proibida | não |

Sintaxe
-------
```

X-Content-Type-Options: nosniff
```

Diretivas
---------

`nosniff`

Bloqueia uma requisição se o tipo for:

* "`style`" e o tipo MIME não é "`text/css`", ou
* "`script`" e o tipo MIME não é um tipo JavaScript.

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

| Specification |
| --- |
| Fetch Standard # x-content-type-options-header |

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

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

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

* `Content-Type`
* A definição original do X-Content-Type-Options pela Microsoft.
* A ferramenta Mozilla Observatory testando a configuração (incluindo este header) de páginas por segurança e precaução.
* Mitigando ataques de confusão de MIME no Firefox


Referrer-Policy - HTTP

Referrer-Policy
===============

O cabeçalho HTTP **`Referrer-Policy`** controla quanta informação de referência (en-US) (enviado pelo cabeçalho `Referer`) deve ser incluída nas requisições.

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

Sintaxe
-------

**Nota:** O nome original do cabeçalho `Referer` é um erro ortográfico da palavra "referrer". O cabeçalho `Referrer-Policy` não compartilha do mesmo erro ortográfico.
```

Referrer-Policy: no-referrer
Referrer-Policy: no-referrer-when-downgrade
Referrer-Policy: origin
Referrer-Policy: origin-when-cross-origin
Referrer-Policy: same-origin
Referrer-Policy: strict-origin
Referrer-Policy: strict-origin-when-cross-origin
Referrer-Policy: unsafe-url
```

Diretivas
---------

`no-referrer`

O cabeçalho `Referer` será omitido completamente. Nenhuma informação de referência será enviada junto com as requisições.

`no-referrer-when-downgrade` (padrão)

Este é o comportamento padrão quando nenhuma política é especificada, ou se o valor provido é inválido. A origem, caminho e cadeia de consulta (origin, path, and querystring) da URL são enviadas como referência quando os níveis de protocolo de segurança continuam os mesmos (HTTP→HTTP, HTTPS→HTTPS) ou melhora (HTTP→HTTPS), mas não é enviado para destinos menos seguros (HTTPS→HTTP).

**Nota:** Existe um esforço dos navegadores em mover para um valor padrão mais estrito, chamado de `strict-origin-when-cross-origin` (veja https://github.com/whatwg/fetch/pull/952), considere usar este valor (ou um mais estrito), se possível, quando trocando a Referrer-Policy.

`origin`

 Somente envia a origem (origin) do documento como referência.
 Por exemplo, um documento em `https://example.com/page.html` irá mandar a referência `https://example.com/`.

`origin-when-cross-origin`

Envia a origem, caminho e cadeia de consulta quando performando uma requisição same-origin (en-US), mas somente envia a origem do documento em outros casos.

`same-origin`

A referência será enviada para origens do mesmo site (en-US), mas requisições entre origens não enviarão informação de referência.

`strict-origin`

Envia somente a origem do documento como referência quando o nível de protocolo de segurança se mantém o mesmo (HTTPS→HTTPS), mas não o envia para um destinatário menos seguro (HTTPS→HTTP).

`strict-origin-when-cross-origin`

Envia a origem, caminho e cadeia de consulta quando performando uma requisição de mesma origem, somente envia a origem quando o nível do protocolo de segurança se mantém o mesmo durante uma requisição entre origens (HTTPS→HTTPS), e envia nenhum cabeçalho para destinatários menos seguros (HTTPS→HTTP).

`unsafe-url`

Envia a origem, o caminho e a cadeia de consulta quando performando qualquer requisição, independente da segurança.

**Aviso:** Esta política irá vazar informações potencialmente privadas da URL HTTPS do recurso para origens inseguras. Considere o impacto desta configuração com cuidado.

Integração com HTML
-------------------

Você também pode colocar política de referência dentro do HTML. Por exemplo, você pode colocar uma política de referência para o documento inteiro com um elemento `<meta>` com um nome de `referrer`:

```html
<meta name="referrer" content="origin" />
```

Ou colocar ele para requisições individuais com o atributo `referrerpolicy` nos elementos `<a>`, `<area>`, `<img>`, `<iframe>`, `<script>`, or `<link>`:

```html
<a href="http://example.com" referrerpolicy="origin"></a>
```

Alternativamente, uma relação de link (en-US) `noreferrer` em um elemento `a`, `area`, ou `link` pode ser colocada:

```html
<a href="http://example.com" rel="noreferrer"></a>
```

Integração com CSS
------------------

CSS pode buscar recursos referênciados de suas folhas de estilo. Estes recursos seguem a política de referência também como:

* Folhas de estilo CSS externas usam a política padrão (`no-referrer-when-downgrade`), a não ser que seja sobrescrita por um cabeçalho HTTP `Referrer-Policy` na resposta da folha de estilo CSS.
* Para elementos `<style>` ou atributos `style` (en-US), a política de referência do dono do documento é utilizada.
Exemplos
--------

| Política | Documento | Navegar para | Referência |
| --- | --- | --- | --- |
| `no-referrer` | https://example.com/page | *qualquer lugar* | *(sem referência)* |
| `no-referrer-when-downgrade` | https://example.com/page | https://example.com/otherpage | https://example.com/page |
| https://mozilla.org | https://example.com/page |
| **http**://example.org | *(sem referência)* |
| `origin` | https://example.com/page | *qualquer lugar* | https://example.com/ |
| `origin-when-cross-origin` | https://example.com/page | https://example.com/otherpage | https://example.com/page |
| https://mozilla.org | https://example.com/ |
| **http**://example.com/page | https://example.com/ |
| `same-origin` | https://example.com/page | https://example.com/otherpage | https://example.com/page |
| https://mozilla.org | *(sem referência)* |
| `strict-origin` | https://example.com/page | https://mozilla.org | https://example.com/ |
| **http**://example.org | *(sem referência)* |
| **http**://example.com/page | *qualquer lugar* | http://example.com/ |
| `strict-origin-when-cross-origin` | https://example.com/page | https://example.com/otherpage | https://example.com/page |
| https://mozilla.org | https://example.com/ |
| **http**://example.org | *(sem referência)* |
| `unsafe-url` | https://example.com/page?q=123 | *qualquer lugar* | https://example.com/page?q=123 |

### Especificando uma política de recuo (*fallback)*

Se você quer especificar uma política de recuo em qualquer caso que a política desejada não tenha um grande suporte do navegador, use uma lista separada por vírgulas com a política desejada especificada por último:
```

Referrer-Policy: no-referrer, strict-origin-when-cross-origin
```

No cenário acima, `no-referrer` só será usada se `strict-origin-when-cross-origin` não for suportada pelo navegador.

**Nota:** Especificar múltiplos valores só é suportado no cabeçalho HTTP `Referrer-Policy`, e não no atributo `referrerpolicy`.

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

| Especificação | Status |
| --- | --- |
| Referrer Policy | Rascunho do editor |

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

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

**Nota:** - Da versão 53 em diante, Gecko possui uma preferência disponível em `about:config` para permitir usuários colocarem a `Referrer-Policy` padrão — `network.http.referer.userControlPolicy`.

* Da versão 59 em diante (veja #587523), isso foi substituído por `network.http.referer.defaultPolicy` e `network.http.referer.defaultPolicy.pbmode`.Valores possíveis são:- 0 — `no-referrer`
* 1 — `same-origin`
* 2 — `strict-origin-when-cross-origin`
* 3 — `no-referrer-when-downgrade` (o padrão)

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

* HTTP referer on Wikipedia
* Quando usando Fetch: `Request.referrerPolicy` (en-US)
* A obsoleta diretiva `Content-Security-Policy` `referrer` (en-US).
* Política de mesma origem (*Same-origin policy*) (en-US)
* Tighter Control Over Your Referrers – Mozilla Security Blog


Accept - HTTP

Accept
======

O cabeçalho de requisição HTTP **`Accept`** anuncia quais tipos de conteúdo, expressos como MIME types, o cliente é capaz de entender. Usando negociação de conteúdo, o servidor então seleciona uma das propostas, a usa e então informa o cliente da sua escolha com o cabeçalho de resposta `Content-Type`. Navegadores colocam valores adequados para este cabeçalho dependendo do contexto onde a requisição é feita: quando buscando um CSS *stylesheet*, um valor diferente é colocado para a requisição, o mesmo acontece com imagens, vídeos ou scripts.

|  |  |
| --- | --- |
| Tipo de cabeçalho | Request header |
| Forbidden header name | não |
| CORS-safelisted request header (en-US) |
 sim, com a restrição adicional de que valores não podem conter um
 *byte de requisição de cabeçalho CORS inseguro:*`"():<>?@[\]{}`, Delete, Tab e outros
 caracteres de controle: 0x00 à 0x19.
  |

Sintaxe
-------
```

Accept: <MIME_type>/<MIME_subtype>
Accept: <MIME_type>/*
Accept: */*

// Múltiplos tipos, com pesos devido à sintaxe quality value (en-US):
Accept: text/html, application/xhtml+xml, application/xml;q=0.9, image/webp, */*;q=0.8
```

Diretivas
---------

`<MIME_type>/<MIME_subtype>`

Um único e preciso MIME type, como por exemplo: `text/html`.

`<MIME_type>/*`

Um MIME type, mas com qualquer subtipo. `image/*` vai coincidir com `image/png`, `image/svg`, `image/gif` e outros tipos de imagens.

`*/*`

Qualquer MIME type.

`;q=` (fator de q de peso [q-factor])

Qualquer valor usado é colocado em uma ordem de preferência expressada usando o quality value (en-US) relativo chamado *peso.*

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

Accept: text/html

Accept: image/*

// Padrão geral
Accept: */*

// Padrão para requisições de navegação
Accept: text/html, application/xhtml+xml, application/xml;q=0.9, */*;q=0.8
```

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

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

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

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

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

* Negociação de conteúdo HTTP
* Cabeçalho com o resultado da negociação de conteúdo: `Content-Type`
* Outros cabeçalhos similares: `TE`, `Accept-Encoding`, `Accept-Charset`, `Accept-Language`


Range - HTTP

Range
=====

O cabeçalho de requisição HTTP **`Range`** indica a parte do documento que o servidor deve retornar. Várias partes podem ser requisitadas com um cabeçalho `Range` de uma vez, e o servidor pode mandar de volta estes intervalos em um documento de múltiplas partes. Se o servidor manda de volta os intervalos, ele usa o `206` `Partial Content` para resposta. Se os intervalos são inválidos, o servidor retorna o erro `416` `Range Not Satisfiable`. O servidor também pode ignorar o cabeçalho `Range` e enviar o documento inteiro com um código de status `200`.

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

Sintaxe
-------
```

Range: <unit>=<range-start>-
Range: <unit>=<range-start>-<range-end>
Range: <unit>=<range-start>-<range-end>, <range-start>-<range-end>
Range: <unit>=<range-start>-<range-end>, <range-start>-<range-end>, <range-start>-<range-end>
Range: <unit>=-<suffix-length>
```

Diretivas
---------

<unit>

A unidade no qual os intervalos são especificados. É geralmente em `bytes`.

<range-start>

Um inteiro na dada unidade indicando o começo da requisição de intervalo.

<range-end>

Um inteiro na dada unidade indicando o fim da requisição de intervalo. Este valor é opcional e, se omitido, o fim do documento é utilizado como fim do intervalo.

<suffix-length>

Um inteiro na dada unidade indicando o número de unidades ao fim do arquivo para retornar.

Exemplos
--------

Requisitando três intervalos deste arquivo.
```

Range: bytes=200-1000, 2000-6576, 19000-
```

Requisitando os primeiros 500 e últimos 500 *bytes* do arquivo. A requisição pode ser rejeitada pelo servidor se os intervalos se sobrepõem.
```

Range: bytes=0-499, -500
```

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

| Especificação | Título |
| --- | --- |
| RFC 7233, sessão 3.1: 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`
* `Content-Range`
* `Content-Type`
* `206` `Partial Content`
* `416` `Range Not Satisfiable`


Expect-CT - HTTP

Expect-CT
=========

O cabeçalho `Expect-CT` deixa sites optarem em reportar e/ou forçar requirimentos do Certificado de Transparência (en-US), para previnir o uso incorreto de certificados do site passar despercebido.

Os requerimentos do CT podem ser satisfeitos utilizando qualquer um dos seguintes mecanismos:

* A extensão do certificado X.509v3 permite embebedar uma marcação de data e hora de certificados assinados reportados por *logs* individuais.
* A extensão TLS do tipo `signed_certificate_timestamp` enviada durante um *handshake*.
* Dando suporte a OCSP (que é, a extensão TLS `status_request`) e provendo uma `SignedCertificateTimestampList`

**Nota:** Quando um site habilita o cabeçalho `Expect-CT`, ele está requisitando que o navegador verifique se qualquer certificado para aquele site aparece em ***logs* CT públicos**.

**Nota:** **Navegadores ignoram** o cabeçalho `Expect-CT` através do HTTP; o cabeçalho só tem efeito em conexões HTTPS.

**Nota:** O `Expect-CT` provavelmente se tornará obsoleto em Junho de 2021. Desde Maio de 2018, esperasse que novos certificados suportem SCTs por padrão. Certificados de antes de Maio de 2018 eram permitidos ter uma vida útil de 39 meses, todos eles serão expirados em Junho de 2021.

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

Sintaxe
-------
```

Expect-CT: report-uri="<uri>",
           enforce,
           max-age=<age>
```

Diretivas
---------

`max-age`

O número de segundos depois da recepção do cabeçalho `Expect-CT` durante o qual o agente de usuário deve identificar o hospedeiro da mensagem recebida como um hospedeiro `Expect-CT` conhecido.

Se o cache receber um valor maior do que ele pode representar, or se qualquer um dos seus cálculos subsequentes estourar o limite, o cache vai considerar este valor a ser 2,147,483,648 (231) ou o maior inteiro positivo que ele pode representar.

`report-uri="<uri>"` Optional

A URI onde o agente de usuário deve reportar falhas `Expect-CT`.

Quando presente com a diretiva `enforce`, a configuração é referida como uma configuração "executar-e-reportar", sinalizando ao agente de usuário que ambos o *compliance* da política do Certificado de Transparência deve ser executado *e* que as violações devem ser reportadas.

`enforce` Optional

Sinais ao agente do usuário que conforme a política do Certificado de Transparência deve ser executada (ao invés de somente ser reportada) e o agente de usuário deve recusar futuras conexões que violem a política do Certificado de Transparência.

Quando ambas as diretivas `enforce` e `report-uri` estiverem presentes, configuração é referida como uma configuração "executar-e-reportar", sinalizando ao agente de usuário que ambos o *compliance* da política do Certificado de Transparência deve ser executado *e* que as violações devem ser reportadas.

Exemplo
-------

O seguinte exemplo especifica uma execução do Certificado de Transparência por 24 horas e reporta violações para `foo.example`.
```

Expect-CT: max-age=86400, enforce, report-uri="https://foo.example/report"
```

Notas
-----

Certificados de Autoridade Raiz (*Root CAs*) manualmente adicionados para a loja de confiança, sobrescrevendo e suprimindo relatórios e execuções do `Expect-CT`.

Navegadores não vão lembrar de uma política `Expect-CT`, a menos que o site tenha "provado" que ele pode servir um certificado satisfazendo os requerimentos do certificado de transparência. Navegadores implementam seus próprios modelos em relação a quais *logs* CT são considerados confiáveis para o certificado logar.

Versões do Chrome são desenvolvidas para parar execução de políticas de `Expect-CT` 10 semanas depois da data de instalação da versão.

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

| Especificação | Título |
| --- | --- |
| Internet Draft | Expect-CT Extension for HTTP |

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

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