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

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

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

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

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

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

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

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

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

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