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

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

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

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

Syntax
------
```

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

Directives
----------

<day-name>

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

<day>

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

<month>

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

<year>

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

<hour>

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

<minute>

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

<second>

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

`GMT`

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

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

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

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

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

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

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

See also
--------

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

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

Sintaxe
-------
```

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


`<uri-reference>`

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

### Parâmetros

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

Exemplos
--------

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


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



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

### Especificando múltiplos *links*

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

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

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

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

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

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

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

* `103 Early Hints`
Origin
======

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

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


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

Sintaxe
-------
```

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

Diretivas
---------

<scheme>

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

<hostname>

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

<port> Optional

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

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

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

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

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

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

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

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

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

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

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

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

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

Syntax
------
```

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

Directives
----------

<host>

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

<port> Optional

TCP port number on which the server is listening.

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

Host: developer.mozilla.org
```

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

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

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

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

See also
--------

* `400`
Cookie
======

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

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

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

Sintaxe
-------
```

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


<cookie-list>

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

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

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

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

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

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

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

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

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

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

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

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

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

Sintaxe
-------
```

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

Diretivas
---------

<identifier>

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

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

by=<identifier>

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

for=<identifier>

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

host=<host>

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

proto=<http|https>

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

Exemplos
--------

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

Forwarded: for="_mdn"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Sintaxe
-------
```

Content-Length: <tamanho>
```

Diretivas
---------

<tamanho>

O tamanho em número decimal de octetos.

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

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

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

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

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

* `Transfer-Encoding`
Access-Control-Allow-Origin
===========================

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

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

Sintaxe
-------
```

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

Diretivas
---------

`*`

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

`<origin>`

Especifica a URI que pode acessar o recurso.

Exemplos
--------

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

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


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

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

### CORS e caching

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

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

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

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

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

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

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

* `Origin`
* `Vary`
Pragma
======

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

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


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

Sintaxe
-------
```

Pragma: no-cache
```

Diretivas
---------

no-cache

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

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

Pragma: no-cache
```

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

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

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

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

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

* `Cache-Control`
* `Expires`
Content-Type
============

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

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

Sintaxe
-------
```

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

Diretivas
---------

`media-type`

O MIME type do recurso ou dado.

charset

O encoding da string

boundary

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

Exemplos
--------

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

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


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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Sintaxe
-------

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

Expect: 100-continue
```

Diretivas
---------

100-continue

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

Exemplos
--------

### Mensagem de corpo grande

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

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


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

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

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

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

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

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

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