recursal/MDN huggingface dataset:
NEL
===

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

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

Sintaxe
-------
```

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

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

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

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

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

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

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

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

Sintaxe
-------
```

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

Diretivas
---------

<type>

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

realm=<realm>

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

charset=<charset>

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

Exemplos
--------

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

WWW-Authenticate: Basic

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


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

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

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

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

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

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

* Autenticação HTTP
* `Authorization`
* `Proxy-Authorization`
* `Proxy-Authenticate`
* `401`, `403`, `407`
Access-Control-Request-Method
=============================

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

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

Sintaxe
-------
```

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

Diretivas
---------

<método>

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

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

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

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

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

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

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

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

* `Access-Control-Request-Headers`
X-Forwarded-Host
================

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

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

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

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

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

Sintaxe
-------
```

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

Diretivas
---------

<host>

O nome do domínio do servidor encaminhado.

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

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

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

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

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

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

* `Host`
* `Forwarded`
* `X-Forwarded-For`
* `X-Forwarded-Proto`
Keep-Alive
==========

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

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


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

Sintaxe
-------
```

Keep-Alive: parametros
```

Diretivas
---------

*parâmetros*

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

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

Exemplos
--------

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

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

(body)
```

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

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

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

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

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

* `Connection`
* Connection management in HTTP/1.x
Proxy-Authenticate
==================

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

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

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

Sintaxe
-------
```

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

Diretivas
---------

<type>

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

realm=<realm>

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

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

Proxy-Authenticate: Basic

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

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

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

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

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

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

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

O cabeçalho de resposta HTTP **`X-XSS-Protection`** é uma funcionalidade do Internet Explorer, Chrome e Safari que impede páginas de carregarem quando eles detectam ataques de scripting entre sites (XSS (en-US)) refletidos. Apesar destas proteções serem majoritariamente desnecessárias em navegadores modernos em sites utilizando uma forte `Content-Security-Policy` que desabilita o uso de JavaScript *inline* (`'unsafe-inline'`), eles ainda podem oferecer proteções para usuários de navegadores mais antigos que ainda não suportam CSP (en-US).

**Nota:** - Chrome removeu o XSS Auditor deles

* Firefox não tem, e não irá implementar `X-XSS-Protection`
* Edge aposentou o filtro XSS delesIsso significa que se você não precisa dar suporte para navegadores legado, é recomendado que você use `Content-Security-Policy` sem permitir scripts `unsafe-inline` ao invés disso.


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

Sintaxe
-------
```

X-XSS-Protection: 0
X-XSS-Protection: 1
X-XSS-Protection: 1; mode=block
X-XSS-Protection: 1; report=<reporting-uri>
```


0

Desabilita filtragem XSS.

1

Habilita filtragem XSS (geralmente padrão em navegadores). Se um ataque de scripting entre sites é detectado, o navegador irá higienizar a página (remover as partes inseguras).

1; mode=block

Habilita filtragem XSS. Ao invés de higienizar a página, o navegador irá impedir a renderização da página em que o ataque foi detectado.

1; report=<reporting-URI> (Chromium somente)

Habilita filtragem XSS. Se o ataque de scripting entre sites é detectado, o navegador irá higienizar a página e reportar a violação. Isso utiliza a funcionalidade da diretiva CSP `report-uri` (en-US) para enviar o relatório.

Exemplos
--------

Bloqueia páginas de carregarem quando elas detectam ataques XSS refletidos:


```bash
X-XSS-Protection: 1; mode=block
```


PHP


```php
header("X-XSS-Protection: 1; mode=block");
```


Apache (.htaccess)


```bash
<IfModule mod_headers.c>
  Header set X-XSS-Protection "1; mode=block"
</IfModule>
```


Nginx


```bash
add_header "X-XSS-Protection" "1; mode=block";
```

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

Não faz parte de nenhuma especificação ou rascunho.

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

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

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

* `Content-Security-Policy`
* Controlando o XSS Filter (Controlling the XSS Filter) – Microsoft
* Entendendo o XSS Auditor (Understanding XSS Auditor) – Virtue Security
* O mal-entendido X-XSS-Protection (The misunderstood X-XSS-Protection) – blog.innerht.ml
Via
===

O cabeçalho geral **`Via`** é adicionado por proxies, ambos diretos e reversos, e pode aparecer em cabeçalhos de requisição e de cabeçalhos de resposta. Ele é usado para rastrear mensagens direcionadas, evitando laços de requisição, e identificando as capacidades dos protocolos dos remetentes ao longo da cadeia de requisição/resposta.

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

Sintaxe
-------
```

Via: [ <protocol-name> "/" ] <protocol-version> <host> [ ":" <port> ]
or
Via: [ <protocol-name> "/" ] <protocol-version> <pseudonym>
```

Diretivas
---------

<protocol-name>

Opcional. O nome do protocolo usado, como "HTTP".

<protocol-version>

A versão do protocolo usado, como "1.1".

<host> e <port>

URL pública do proxy e sua porta.

<pseudonym>

Nome/pseudônimo de um proxy interno.

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

Via: 1.1 vegur
Via: HTTP/1.1 GWA
Via: 1.0 fred, 1.1 p.example.net
```

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

| Especificação | Título |
| --- | --- |
| RFC 7230, sessão 5.7.1: Via | 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
-----------

* `X-Forwarded-For`
* Biblioteca proxy Vegur do Heroku
Tk
==

O cabeçalho de resposta **`Tk`** indica o status de rastreamento que foi aplicado à requisição correspondente.

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

Sintaxe
-------
```

Tk: !  (em construção)
Tk: ?  (dinâmico)
Tk: G  (portão ou múltiplas partes)
Tk: N  (não está rastreando)
Tk: T  (rastreando)
Tk: C  (rastreando com consentimento)
Tk: P  (potencial consentimento)
Tk: D  (desconsiderando DNT)
Tk: U  (atualizado)
```

### Diretivas

!

Em construção. O servidor de origem está atualmente testando sua comunicação de status de rastreamento.

?

Dinâmico. O servidor de origem precisa de mais informação para determinar o status de rastreamento.

G

Portão ou múltiplas partes. O servidor está agindo como um portão para uma troca envolvendo várias múltiplas partes.

N

Não está rastreando.

T

Rastreando.

C

Rastreamento com consentimento. O servidor de origem acredita que ele recebeu consentimento a priori para rastrear o usuário, agente de usuário ou dispositivo.

P

Potencial consentimento. O servidor origem não conhece, em tempo real, se ele recebeu consentimento a priori para rastrear o usuário, o agente de usuário ou dispositivo, mas promete não usar ou compartilhar qualquer dado `DNT:1` até que o consentimento seja determinado, e promete futuramente deletar ou permanentemente sumir com a identidade em até 48 horas para qualquer dado `DNT:1` recebido para qual o consentimento não tenha sido recebido.

D

Desconsiderando DNT. O servidor de origem está incapacitado ou relutante em respeitar uma preferência de rastreamento recebida do agente de usuário requisitante.

U

Atualizado. A requisição resultou em uma potencial mudança no status de rastreamento aplicado ao usuário, agente de usuário ou dispositivo.

Exemplos
--------

O cabeçalho `Tk` para um recurso que diz não querer ser rastreado se parece com isso:
```

Tk: N
```

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

#### No specification found

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

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

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

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

* Cabeçalho `DNT`
* `Navigator.doNotTrack` (en-US)
Access-Control-Max-Age
======================

O cabeçalho de resposta **`Access-Control-Max-Age`** indica por quanto tempo os resultados de uma preflight request (que é a informação contida nos cabeçalhos `Access-Control-Allow-Methods` e `Access-Control-Allow-Headers`) pode ser cacheada (mantida).

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

Sintaxe
-------
```

Access-Control-Max-Age: <delta-segundos>
```

Diretivas
---------

<delta-segundos>

 Número máximo de segundos que os resultados podem ser cacheados.
 Firefox limita isso em 24 horas (86400 segundos).
 Chromium (anterior à v76) limita isso à 10 minutos (600 segundos).
 Chromium (começando na v76) limita isso à 2 horas (7200 segundos).
 Chromium também especifica o valor padrão de 5 segundos.
 O valor de **-1** irá desabilitar o cacheamento, requerendo uma requisição de checagem pré-vôo OPTIONS para todas as chamadas.


Exemplos
--------

Resultados cacheados para uma requisição pré-vôo por 10 minutos:
```

Access-Control-Max-Age: 600
```

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

| Specification |
| --- |
| Fetch Standard # http-access-control-max-age |

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

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

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

* `Access-Control-Allow-Headers`
* `Access-Control-Allow-Methods`
Upgrade-Insecure-Requests
=========================

O cabeçalho HTTP **`Upgrade-Insecure-Requests`** envia um sinal ao servidor expressando a preferência do cliente por uma resposta criptografada e autenticada, e podendo manipular com êxito a diretiva `upgrade-insecure-requests` (en-US) CSP (en-US).

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

Syntaxe
-------
```

Upgrade-Insecure-Requests: 1
```

Exemplos
--------

Um cliente solicita ao servidor que ele faça o suporte aos mecanismos de upgrade de `upgrade-insecure-requests` (en-US):
```

GET / HTTP/1.1
Host: example.com
Upgrade-Insecure-Requests: 1
```


O servidor agora pode redirecionar para uma versão segura do site. Um cabeçalho `Vary` pode ser usado para que o site não seja veiculado por caches à clientes que não oferecem suporte ao mecanismo de upgrade.
```

Local: https://example.com/
Vary: Upgrade-Insecure-Requests
```

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

| Specification |
| --- |
| Upgrade Insecure Requests # preference |

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

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

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

* `Content-Security-Policy`
* CSP `upgrade-insecure-requests` (en-US) directive
Save-Data
=========

O cabeçalho **`Save-Data`** é um booleano no qual, em requisições, indica a preferência do cliente para reduzir uso de dados. Isso pode ser por algumas razões como custo de transferência alto, baixa velocidade de conexão, etc.

Um valor de `On` indica uma opção explícita do usuário em querer reduzir a quantidade de dados usados no cliente, e quando comunicade para origens permite elas entregarem conteúdo alternativo para reduzir a quantidade de dados baixados como recursos de imagem e vídeo menores, marcação e estilo diferente, desabilitar *polling* e atualizações automáticas, e assim por diante.

**Nota:** Desabilitar HTTP/2 Server Push (RFC 7540, sessão 8.2: Server Push) pode ser desejável para reduzir o *download* de dados.

Sintaxe
-------
```

Save-Data: <sd-token>
```

Diretivas
---------

`<sd-token>`

Um valor numérico indicando se o cliente quer optar ou não em entrar em modo de utilização de dados reduzido. `on` significa sim, enquanto `off` (o padrão) indica não.

Exemplos
--------

O cabeçalho `Vary` assegura que o conteúdo é cacheado apropriadamante (por exemplos assegurando que o usuário não é servido com uma imagem de baixa qualidade do cache quando o cabeçalho `Save-Data` não está mais presente [*e.g.* depois de ter trocado de rede celular para Wi-Fi]).

### Com `Save-Data: on`

Requisição:
```

GET /image.jpg HTTP/1.0
Host: example.com
Save-Data: on
```


Resposta:
```

HTTP/1.0 200 OK
Content-Length: 102832
Vary: Accept-Encoding, Save-Data
Cache-Control: public, max-age=31536000
Content-Type: image/jpeg

[...]
```

### Sem `Save-Data`

Requisição:
```

GET /image.jpg HTTP/1.0
Host: example.com
```


Resposta:
```

HTTP/1.0 200 OK
Content-Length: 481770
Vary: Accept-Encoding, Save-Data
Cache-Control: public, max-age=31536000
Content-Type: image/jpeg

[...]
```

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

| Especificação | Título |
| --- | --- |
| draft-grigorik-http-client-hints-03, section 7: Save-Data | HTTP Client Hints |

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

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

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

* Ajude seus usuários a "salvar-dados" (Help Your Users `Save-Data`) - CSS Tricks
* Entregando aplicações leves e rápidas com Save-Data (Delivering Fast and Light Applications with Save-Data) - Google Developers
* Cabeçalho para indicar que o conteúdo servidor varia por `Save-Data`: `Vary`
* Funcionalidade CSS @media `prefers-reduced-data` (en-US) 
Experimental
Access-Control-Expose-Headers
=============================

O cabeçalho de resposta **`Access-Control-Expose-Headers`** indica quais cabeçalhos podem ser expostos como parte da resposta listando os seus nomes.

Por padrão, somente os 6 CORS-safelisted response headers (en-US) são expostos:

* `Cache-Control`
* `Content-Language`
* `Content-Type`
* `Expires`
* `Last-Modified`
* `Pragma`

Se você quiser que clientes tenham acesso a outros cabeçalhos, você deve listá-los usando o cabeçalho `Access-Control-Expose-Headers`.

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

Sintaxe
-------
```

Access-Control-Expose-Headers: <nome-do-cabeçalho>, <nome-do-cabeçalho>, ...
Access-Control-Expose-Headers: *
```

Diretivas
---------

<nome-do-cabeçalho>

Uma lista dos cabeçalhos expostos contendo zero ou mais nomes de cabeçalhos além dos CORS-safelisted request headers (en-US) que o recurso pode usar e expor.

`*` (coringa)

 O valor "`*`" conta somente 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, ele é tratado como o nome de cabeçalho literal "`*`" sem qualquer semântica.
 Note que o cabeçalho `Authorization` não pode ter valor coringa e sempre precisa ser listado explicitamente.


Exemplos
--------

Para expor um cabeçalho de requisição não-CORS-seguro, você pode especificar:
```

Access-Control-Expose-Headers: Content-Length
```


Para expor um cabeçalho customizado adicionalmente, como `X-Kuma-Revision`, você pode adicionar múltiplos cabeçalhos separados por vírgula:
```

Access-Control-Expose-Headers: Content-Length, X-Kuma-Revision
```


Em requisições sem credênciais, você também pode usar um valor coringa:
```

Access-Control-Expose-Headers: *
```


Entretanto, isso não irá colocar um valor coringa para o cabeçalho `Authorization`, então caso você precise que ele seja exposto, você precisa listá-lo explicitamente:
```

Access-Control-Expose-Headers: *, Authorization
```

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

| Specification |
| --- |
| Fetch Standard # http-access-control-expose-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-Headers`
* `Access-Control-Allow-Origin`
GET
===

O **método HTTP GET** solicita uma representação do recurso especificado. Solicitações usando GET só devem recuperar dados.

|  |  |
| --- | --- |
| Requisição tem corpo | Não |
| Resposta bem-sucedida tem corpo | Sim |
| Seguro | Sim |
| Idempotente | Sim |
| Cacheável | Sim |
| Permitido em formulários HTML | SIm |

Sintaxe
-------
```

GET /index.html
```

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

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

* `Range`