Códigos de status de respostas HTTP - HTTP

Códigos de status de respostas HTTP
===================================

 Os códigos de status de resposta HTTP indicam se uma solicitação HTTP específica foi concluída com êxito.
 As respostas são agrupadas em cinco classes:

1. Respostas Informativas (`100` – `199`)
2. Respostas bem-sucedidas (`200` – `299`)
3. Mensagens de redirecionamento (`300` – `399`)
4. Respostas de erro do cliente (`400` – `499`)
5. Respostas de erro do servidor (`500` – `599`)

Os códigos de status listados abaixo são definidos por RFC 9110.

**Nota:** Se você receber uma resposta que não esteja nesta lista, é uma resposta não padrão, possivelmente personalizada para o software do servidor.

Respostas informativas
----------------------

`100 Continue`

Essa resposta provisória indica que o cliente deve continuar a solicitação ou ignorar a resposta se a solicitação já estiver concluída.

`101 Switching Protocols`

Esse código é enviado em resposta a um cabeçalho de solicitação `Upgrade` (en-US) do cliente e indica o protocolo para o qual o servidor está mudando.

`102 Processing` (en-US) (WebDAV (en-US))

Este código indica que o servidor recebeu e está processando a requisição, mas nenhuma resposta está disponível ainda.

`103 Early Hints`
Experimental

Este código de status destina-se principalmente a ser usado com o cabeçalho `Link`, permitindo que o agente do usuário inicie o pré-carregamento (en-US) recursos enquanto o servidor prepara uma resposta.

Respostas bem-sucedidas
-----------------------

`200 OK`

A solicitação foi bem-sucedida. O significado do resultado de "sucesso" depende do método HTTP:

* `GET`: O recurso foi obtido e transmitido no corpo da mensagem.
* `HEAD`: Os cabeçalhos de representação são incluídos na resposta sem nenhum corpo de mensagem.
* `PUT` ou `POST`: O recurso que descreve o resultado da ação é transmitido no corpo da mensagem.
* `TRACE`: O corpo da mensagem contém a mensagem de requisição recebida pelo servidor.

`201 Created`

A requisição foi bem sucedida e um novo recurso foi criado como resultado. Esta é normalmente a resposta enviada após as solicitações `POST` ou algumas solicitações `PUT`.

`202 Accepted`

 A solicitação foi recebida, mas ainda não foi atendida.
 É sem compromisso, pois não há como no HTTP enviar posteriormente uma resposta assíncrona indicando o resultado da solicitação.
 Destina-se a casos em que outro processo ou servidor manipula a solicitação ou processamento em lote.

`203 Non-Authoritative Information`

 Esse código de resposta significa que os metadados retornados não são exatamente os mesmos que estão disponíveis no servidor de origem, mas são coletados de uma cópia local ou de terceiros.
 Isso é usado principalmente para espelhos ou backups de outro recurso.
 Exceto para esse caso específico, a resposta `200 OK` é preferida a este status.

`204 No Content`

 Não há conteúdo para enviar para esta solicitação, mas os cabeçalhos podem ser úteis.
 O agente do usuário pode atualizar seus cabeçalhos em cache para este recurso com os novos.

`205 Reset Content`

Diz ao agente do usuário para redefinir o documento que enviou esta solicitação.

`206 Partial Content`

Este código de resposta é usado quando o cabeçalho `Range` é enviado do cliente para solicitar apenas parte de um recurso.

`207 Multi-Status` (en-US) (WebDAV (en-US))

Transmite informações sobre vários recursos, para situações em que vários códigos de status podem ser apropriados.

`208 Already Reported` (en-US) (WebDAV (en-US))

Usado dentro de um elemento de resposta `<dav:propstat>` para evitar enumerar repetidamente os membros internos de várias ligações para a mesma coleção.

`226 IM Used` (en-US) (HTTP Delta encoding)

O servidor atendeu a uma solicitação `GET` para o recurso e a resposta é uma representação do resultado de uma ou mais manipulações de instância aplicadas à instância atual.

Mensagens de redirecionamento
-----------------------------

`300 Multiple Choices`

A solicitação tem mais de uma resposta possível. O agente do usuário ou usuário deve escolher um deles. (Não há uma maneira padronizada de escolher uma das respostas, mas links HTML para as possibilidades são recomendados para que o usuário possa escolher).

`301 Moved Permanently`

A URL do recurso solicitado foi alterada permanentemente. A nova URL é fornecida na resposta.

`302 Found`

 Este código de resposta significa que o URI do recurso solicitado foi alterado *temporariamente*.
 Outras alterações no URI podem ser feitas no futuro. Portanto, esta mesma URI deve ser utilizada pelo cliente em requisições futuras.

`303 See Other`

O servidor enviou esta resposta para direcionar o cliente a obter o recurso solicitado em outro URI com uma solicitação GET.

`304 Not Modified`

 É usado para fins de cache.
 Ele informa ao cliente que a resposta não foi modificada, portanto, o cliente pode continuar a usar a mesma versão em cache da resposta.

`305 Use Proxy`
Deprecated

 Definido em uma versão anterior da especificação HTTP para indicar que uma resposta solicitada deve ser acessada por um proxy.
 Foi descontinuado devido a questões de segurança em relação à configuração em banda de um proxy.

`306 unused`
Deprecated

Esse código de resposta não é mais usado, é apenas reservado. Foi usado em uma versão anterior da especificação HTTP/1.1.

`307 Temporary Redirect`

 O servidor envia esta resposta para direcionar o cliente a obter o recurso solicitado em outra URI com o mesmo método usado na solicitação anterior.
 Tem a mesma semântica do código de resposta HTTP `302 Found`, com a exceção de que o agente do usuário *não deve* alterar o método HTTP usado: se um `POST` foi usado na primeira solicitação, um `POST` deve ser usado no segundo pedido.

`308 Permanent Redirect`

 Isso significa que o recurso agora está permanentemente localizado em outro URI, especificado pelo cabeçalho de resposta HTTP `Location:`.
 Isso tem a mesma semântica que o código de resposta HTTP `301 Moved Permanently`, com a exceção de que o agente do usuário *não deve* alterar o método HTTP usado: se um `POST` foi usado na primeira solicitação, um `POST` deve ser usado no segundo pedido.

Respostas de erro do cliente
----------------------------

`400 Bad Request`

O servidor não pode ou não irá processar a solicitação devido a algo que é percebido como um erro do cliente (por exemplo, sintaxe de solicitação malformada, enquadramento de mensagem de solicitação inválida ou roteamento de solicitação enganosa).

`401 Unauthorized`

 Embora o padrão HTTP especifique "unauthorized", semanticamente, essa resposta significa "unauthenticated".
 Ou seja, o cliente deve se autenticar para obter a resposta solicitada.

`402 Payment Required`
Experimental

 Este código de resposta está reservado para uso futuro.
 O objetivo inicial da criação deste código era usá-lo para sistemas digitais de pagamento, no entanto, este código de status é usado raramente e não existe nenhuma convenção padrão.

`403 Forbidden`

 O cliente não tem direitos de acesso ao conteúdo; ou seja, não é autorizado, portanto o servidor está se recusando a fornecer o recurso solicitado.
 Ao contrário do `401 Unauthorized`, a identidade do cliente é conhecida pelo servidor.

`404 Not Found`

 O servidor não pode encontrar o recurso solicitado.
 No navegador, isso significa que o URL não é reconhecido.
 Em uma API, isso também pode significar que o endpoint é válido, mas o próprio recurso não existe.
 Os servidores também podem enviar esta resposta em vez de `403 Forbidden` para ocultar a existência de um recurso de um cliente não autorizado.
 Este código de resposta é provavelmente o mais conhecido devido à sua ocorrência frequente na web.

`405 Method Not Allowed`

 O método de solicitação é conhecido pelo servidor, mas não é suportado pelo recurso de destino.
 Por exemplo, uma API pode não permitir chamar `DELETE` para remover um recurso.

`406 Not Acceptable`

Esta resposta é enviada quando o servidor web, após realizar negociação de conteúdo orientada pelo servidor, não encontra nenhum conteúdo que esteja em conformidade com os critérios fornecidos por o agente do usuário.

`407 Proxy Authentication Required`

É semelhante a `401 Unauthorized`, mas a autenticação precisa ser feita por um proxy.

`408 Request Timeout`

 Esta resposta é enviada por alguns servidores em uma conexão ociosa, mesmo sem qualquer requisição prévia pelo cliente.
 Isso significa que o servidor gostaria de desligar esta conexão não utilizada.
 Essa resposta é muito mais usada, pois alguns navegadores, como Chrome, Firefox 27+ ou IE9, usam mecanismos de pré-conexão HTTP para acelerar a navegação.
 Observe também que alguns servidores simplesmente encerram a conexão sem enviar esta mensagem.

`409 Conflict`

Esta resposta será enviada quando uma requisição conflitar com o estado atual do servidor.

`410 Gone`

 Esta resposta é enviada quando o conteúdo solicitado foi excluído permanentemente do servidor, sem endereço de encaminhamento.
 Espera-se que os clientes removam seus caches e links para o recurso.
 A especificação HTTP pretende que esse código de status seja usado para "serviços promocionais por tempo limitado".
 As APIs não devem se sentir compelidas a indicar recursos que foram excluídos com esse código de status.

`411 Length Required`

O servidor rejeitou a solicitação porque o campo de cabeçalho `Content-Length` não está definido e o servidor o exige.

`412 Precondition Failed`

O cliente indicou nos seus cabeçalhos pré-condições que o servidor não atende.

`413 Payload Too Large`

 A entidade requisição é maior do que os limites definidos pelo servidor.
 O servidor pode fechar a conexão ou retornar um campo de cabeçalho `Retry-After`.

`414 URI Too Long`

O URI solicitado pelo cliente é mais longo do que o servidor está disposto a interpretar.

`415 Unsupported Media Type`

O formato de mídia dos dados requisitados não é suportado pelo servidor, portanto, o servidor está rejeitando a requisição.

`416 Range Not Satisfiable`

 O intervalo especificado pelo campo de cabeçalho `Range` na solicitação não pode ser atendido.
 É possível que o intervalo esteja fora do tamanho dos dados do URI de destino.

`417 Expectation Failed`

Este código de resposta significa que a expectativa indicada pelo campo de cabeçalho de solicitação `Expect` não pode ser atendida pelo servidor.

`418 I'm a teapot`

O servidor recusa a tentativa de coar café num bule de chá.

`421 Misdirected Request` (en-US)

 A requisição foi direcionada a um servidor inapto a produzir a resposta.
 Pode ser enviado por um servidor que não está configurado para produzir respostas para a combinação de esquema e autoridade inclusas na URI da requisição.

`422 Unprocessable Content` (WebDAV (en-US))

A solicitação foi bem formada, mas não pôde ser atendida devido a erros semânticos.

`423 Locked` (en-US) (WebDAV (en-US))

O recurso que está sendo acessado está bloqueado.

`424 Failed Dependency` (en-US) (WebDAV (en-US))

A solicitação falhou devido à falha de uma solicitação anterior.

`425 Too Early`
Experimental

Indica que o servidor não está disposto a correr o risco de processar uma solicitação que pode ser repetida.

`426 Upgrade Required`

 O servidor se recusa a executar a solicitação usando o protocolo atual, mas pode estar disposto a fazê-lo depois que o cliente atualizar para um protocolo diferente.
 O servidor envia um cabeçalho `Upgrade` (en-US) em uma resposta 426 para indicar os protocolos necessários.

`428 Precondition Required`

 O servidor de origem exige que a solicitação seja condicional.
 Esta resposta destina-se a prevenir o problema de 'atualização perdida', onde um cliente pega (`GET`) o estado de um recurso, o modifica e o coloca (`PUT`) de volta no servidor, quando entretanto um terceiro modificou o estado no servidor, levando a um conflito.

`429 Too Many Requests`

O usuário enviou muitas requisições num dado tempo ("limitação de frequência").

`431 Request Header Fields Too Large`

 O servidor não está disposto a processar a solicitação porque seus campos de cabeçalho são muito grandes.
 A solicitação pode ser reenviada após reduzir o tamanho dos campos do cabeçalho da solicitação.

`451 Unavailable For Legal Reasons`

O agente do usuário solicitou um recurso que não pode ser fornecido legalmente, como uma página da Web censurada por um governo.

Respostas de erro do servidor
-----------------------------

`500 Internal Server Error`

O servidor encontrou uma situação com a qual não sabe lidar.

`501 Not Implemented`

O método da requisição não é suportado pelo servidor e não pode ser manipulado. Os únicos métodos que servidores devem suportar (e portanto não devem retornar este código) são `GET` e `HEAD`.

`502 Bad Gateway`

Essa resposta de erro significa que o servidor, enquanto trabalhava como um gateway para obter uma resposta necessária para lidar com a solicitação, obteve uma resposta inválida.

`503 Service Unavailable`

 O servidor não está pronto para manipular a requisição
 Causas comuns são um servidor em manutenção ou sobrecarregado.
 Note que junto a esta resposta, uma página amigável explicando o problema deveria ser enviada.
 Esta resposta deve ser usada para condições temporárias e o cabeçalho HTTP `Retry-After` deverá, se possível, conter o tempo estimado para recuperação do serviço.
 O webmaster deve também tomar cuidado com os cabeçalhos relacionados com o cache que são enviados com esta resposta, já que estas respostas de condições temporárias normalmente não deveriam ser postas em cache.

`504 Gateway Timeout`

Essa resposta de erro é fornecida quando o servidor está atuando como um gateway e não consegue obter uma resposta a tempo.

`505 HTTP Version Not Supported`

A versão HTTP usada na requisição não é suportada pelo servidor.

`506 Variant Also Negotiates`

O servidor tem um erro de configuração interna: o recurso variante escolhido está configurado para se envolver em negociação de conteúdo transparente e, portanto, não é um ponto final adequado no processo de negociação.

`507 Insufficient Storage` (WebDAV (en-US))

O método não pôde ser executado no recurso porque o servidor não pode armazenar a representação necessária para concluir a solicitação com êxito.

`508 Loop Detected` (WebDAV (en-US))

O servidor detectou um loop infinito ao processar a solicitação.

`510 Not Extended`

Extensões adicionais à solicitação são necessárias para que o servidor a atenda.

`511 Network Authentication Required`

Indica que o cliente precisa se autenticar para obter acesso à rede.

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

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

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

* Lista de códigos de status na Wikipedia
* Registro oficial IANA de códigos de status HTTP


Autenticação HTTP - HTTP

Autenticação HTTP
=================

O HTTP fornece uma estrutura geral para controle de acesso e autenticação. A autenticação HTTP mais comum é fundamentada no esquema "Basic". Esta página introduz a estrutura HTTP para autenticação e mostra como restringir acesso ao seu servidor usando o esquema "Basic".

A estrutura geral de autenticação HTTP
--------------------------------------

RFC 7235 define a estrutura de autenticação HTTP que pode ser usada por um servidor para definir uma solicitação ("challenge (en-US)") do cliente e para um cliente fornecer informações de autenticação. A pergunta e resposta segue um caminho como esse: O servidor responde ao cliente com uma mensagem do tipo `401` (Não autorizado) e fornece informações de como autorizar com um cabeçalho de resposta `WWW-Authenticate` contendo ao menos uma solicitação. Um cliente que deseja autenticar-se com um servidor pode fazer isso incluindo um campo de cabeçalho de solicitação `WWW-Authenticate` com as credenciais. Usualmente um cliente apresentará uma solicitação de senha ao usuário e, em seguida, emitirá uma solicitação incluindo o cabeçalho `Authorization` correto.

![A sequence diagram illustrating HTTP messages between a client and a server lifeline.](/pt-BR/docs/Web/HTTP/Authentication/httpauth.png)

No caso de uma autorização "Basic" (como a mostrada na figura), a troca **deve** acontecer por meio de uma conexão HTTP (TLS) para ser segura.

### Autenticação de Proxy

O mesmo mecanismo de solicitação e resposta pode ser usado para uma *autenticação de proxy*. Neste caso, é um proxy intermediário que requer autenticação. Como ambas autenticação de recurso e autenticação de proxy podem coexistir, um conjunto diferente de códigos de cabeçalhos e status torna-se necessário. No caso de proxys, o código de status de solicitação é `407` (Autenticação de Proxy necessária), o cabeçalho de resposta `Proxy-Authenticate` contém ao menos uma solicitação aplicável para o proxy, e o cabeçalho de pedido `Proxy-Authorization` é usado para fornecer as credenciais ao servidor proxy.

### Acesso proibido

Se um servidor proxy recebe credenciais válidas, mas que não são adequadas para ter acesso a um determinado recurso, o servidor responderá com o código de status `Forbidden` `403`. Ao contrário de `401` `Unauthorized` ou `407` `Proxy Authentication Required`, a autenticação é impossível para este usuário.

### Autenticação de imagens de origem cruzada

Um potencial buraco de segurança que foi corrigido recentemente pelos navegadores é a autenticação de imagens cross-site (origem cruzada). Do Firefox 59 (en-US) em diante, recursos de imagem carregados de diferentes origens não são mais capazes de adicionar diálogos de autenticação HTTP (Erro do Firefox 1423146), impedindo que as credencias do usuário sejam roubadas se invasores conseguissem incorporar uma imagem arbitrária em uma página de terceiros.

### A codificação de caracteres da autenticação HTTP

Os navegadores usam a codificação `utf-8` para nomes de usuários e senhas. Firefox usava `ISO-8859-1`, mas alterou para `utf-8` por questões de compatiblidade com outros navegadores, assim como para evitar os potenciais problemas descritos em Erro do Firefox 1419658.

### Cabeçalhos `WWW-Authenticate` e `Proxy-Authenticate`

Os cabeçalhos de resposta `WWW-Authenticate` e `Proxy-Authenticate` definem o método de autenticação que deve ser usado para ganhar acesso a um recurso. Eles precisam especificar que esquema de autenticação é usado para que o cliente que deseja autorizar saiba como fornecer as credenciais. A sintaxe para esses cabeçalhos é a seguinte:
```

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

`<type>` é o esquema de autenticação ("Basic" é o esquema mais comum e será introduzido abaixo). O *realm* é usado para indicar a área protegida ou o escopo de proteção. Poderia ser uma mensagem parecida com "Access to the staging site" (Acesso ao site de teste), portanto o usuário saberá qual área ele está tentando acessar.

### Cabeçalhos `Authorization` e `Proxy-Authorization`

Os cabeçalhos de solicitação `Authorization` e `Proxy-Authorization` contém as credenciais para autenticar um agente de usuário com um servidor proxy. Aqui o tipo é novamente necessário, seguido pelas credenciais, que podem ser codificadas ou criptografadas dependendo do esquema de autenticação usado.
```

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

### Esquemas de autenticação

A estrutura geral de autenticação HTTP é usado por vários esquemas de autenticação. Os esquemas podem divergir na força da segurança e na disponibilidade do software cliente ou servidor.

O esquema mais comum de autenticação é o "Basic", que é introduzido com mais detalhes abaixo. IANA mantém uma lista de esquemas de autenticação, mas existem outros esquemas oferecidos por serviços de hospedagem, como Amazon AWS. Os esquemas de autenticação comuns incluem:

* **Basic** (veja RFC 7617, credenciais codificadas em base64. Veja abaixo mais informações.),
* **Bearer** (veja RFC 6750, tokens bearer (de portador) para acessar recursos protegidos por OAuth 2.0),
* **Digest** (veja RFC 7616, apenas hash md5 é suportado no Firefox, veja Erro do Firefox 472823 para o suporte de encriptação SHA),
* **HOBA** (veja RFC 7486 (esboço), **H**TTP **O**rigin-**B**ound **A**uthentication (Autenticação Vinculada à Origem HTTP), baseado em assinatura digital),
* **Mutual** (veja draft-ietf-httpauth-mutual),
* **AWS4-HMAC-SHA256** (veja Documentação AWS).
Esquema Basic de autenticação
-----------------------------

O esquema "Basic" de autenticação HTTP é definido em RFC 7617, transmitindo credenciais como pares de ID/senhas de usuários, codificadas usando base64.

### Segurança da autenticação básica

Como o ID e senha do usuário são transmitidos através da rede como texto claro (é codificado em base64, mas base64 é uma codificação reversível), o esquema básico de autenticação não é seguro. HTTPS / TLS devem ser usados em conjunto com autenticação básica. Sem esses aprimoramentos de segurança adicionais, a autenticação básica não deve ser usada para proteger informação sensível ou valiosa.

### Restringindo acesso no Apache e autorização básica

Para proteger com senha um diretório em um servidor Apache, você precisará de um arquivo `.htaccess` e um `.htpasswd`.

O arquivo `.htaccess` normalmente parece com isso:
```

AuthType Basic
AuthName "Access to the staging site"
AuthUserFile /path/to/.htpasswd
Require valid-user
```

O arquivo `.htaccess` referencia um arquivo `.htpasswd` em que cada linha contém um nome de usuário e senha separados por dois pontos (":"). Você não pode ver as senhas reais porque foram criptografadas (em md5, neste caso). Note que você pode renomear seu arquivo `.htpasswd` caso queira, mas tenha em mente que este arquivo não deve ser acessado por ninguém. (Apache normalmente é configurado para previnir acesso aos arquivos `.ht*`).
```

aladdin:$apr1$ZjTqBB3f$IF9gdYAGlMrs2fuINjHsz.
user2:$apr1$O04r.y2H$/vEkesPhVInBByJUkXitA/
```

### Restringindo acesso no nginx e autenticação básica

No nginx, você precisará especificar uma área que que você protegerá e a diretiva `auth_basic` que fornece o nome para a área protegida por senha. A diretiva `auth_basic_user_file` aponta para um arquivo .htpasswd contentdo as credenciais do usuário criptografadas, assim como no exemplo Apache acima.
```

location /status {
    auth_basic           "Access to the staging site";
    auth_basic_user_file /etc/apache2/.htpasswd;
}
```

### Acesso usando as credenciais na URL

Vários clientes também permitem que você evite o prompt de login usando uma URL codificada contendo o nome de usuário e senha como esta:
```

https://username:password@www.example.com/
```

**O uso destas URLs está obsoleto**. No Chrome, a parte `username:password@` nas URLs é retirada por razões de segurança. No Firefox, é verificado se o site realmente Airequer autenticação e, se não, Firefox alertará o usuário com uma mensagem "Você está prestes a logar no site "www.example.com" com seu nome de usuário "username", mas o website não requer autenticação. Isso pode ser uma tentativa de enganá-lo".

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

* `WWW-Authenticate`
* `Authorization`
* `Proxy-Authorization`
* `Proxy-Authenticate`
* `401`, `403`, `407`


HTTP caching - HTTP

HTTP caching
============

Visão geral
-----------

O cache HTTP armazena uma resposta associada a uma solicitação e reutiliza a resposta armazenada para solicitações subsequentes.

Existem várias vantagens na reutilização. Primeiro, como não há necessidade de entregar a solicitação ao servidor de origem, quanto mais próximos o cliente e o cache estiverem, mais rápida será a resposta. O exemplo mais típico é quando o próprio navegador armazena um cache para solicitações do navegador.

Além disso, quando uma resposta é reutilizável, o servidor de origem não precisa processar a solicitação — portanto, não precisa analisar e rotear a solicitação, restaurar a sessão com base no cookie, consultar o banco de dados para obter resultados ou renderizar o mecanismo de modelo . Isso reduz a carga no servidor.

A operação adequada do cache é fundamental para a integridade do sistema.

Tipos de caches
---------------

Na especificação HTTP Caching, existem dois tipos principais de caches: **caches privados** e **caches compartilhados**.

### Caches privados

Um cache privado é um cache vinculado a um cliente específico — normalmente um cache de navegador. Como a resposta armazenada não é compartilhada com outros clientes, um cache privado pode armazenar uma resposta personalizada para esse usuário.

Por outro lado, se o conteúdo personalizado for armazenado em um cache que não seja um cache privado, outros usuários poderão recuperar esse conteúdo - o que pode causar vazamento não intencional de informações.

Se uma resposta contém conteúdo personalizado e você deseja armazenar a resposta apenas no cache privado, você deve especificar uma diretiva `private`.

```http
Cache-Control: private
```

Os conteúdos personalizados são geralmente controlados por cookies, mas a presença de um cookie nem sempre indica que é privado e, portanto, um cookie por si só não torna a resposta privada.

Observe que se a resposta tiver um cabeçalho `Authorization`, ela não poderá ser armazenada no cache privado (ou em um cache compartilhado, a menos que `public` seja especificado).

### Cache compartilhado

O cache compartilhado está localizado entre o cliente e o servidor e pode armazenar respostas que podem ser compartilhadas entre os usuários. E os caches compartilhados podem ser subdivididos em **caches de proxy** e **caches gerenciados**.

#### Caches de proxy

Além da função de controle de acesso, alguns proxies implementam cache para reduzir o tráfego fora da rede. Isso geralmente não é gerenciado pelo desenvolvedor do serviço, portanto, deve ser controlado por cabeçalhos HTTP apropriados e assim por diante. No entanto, no passado, implementações de cache de proxy desatualizadas — como implementações que não entendem adequadamente o padrão HTTP Caching — geralmente causavam problemas para os desenvolvedores.

**Kitchen-sink headers** como os seguintes são usados para tentar contornar implementações de "cache de proxy antigo e não atualizado" que não entendem as diretivas atuais de especificação de cache HTTP, como `no-store`.

```http
Cache-Control: no-store, no-cache, max-age=0, must-revalidate, proxy-revalidate
```

No entanto, nos últimos anos, à medida que o HTTPS se tornou mais comum e a comunicação cliente/servidor tornou-se criptografada, os caches de proxy no caminho só podem encapsular uma resposta e não podem se comportar como um cache, em muitos casos. Portanto, nesse cenário, não há necessidade de se preocupar com implementações de cache de proxy desatualizadas que nem conseguem ver a resposta.

Por outro lado, se um proxy de ponte TLS descriptografa todas as comunicações de maneira intermediária instalando um certificado de uma CA (entidade certificadora) (en-US) gerenciada pela organização no PC e executa o controle de acesso, etc. — é possível ver o conteúdo da resposta e armazená-la em cache. No entanto, como CT (transparência do certificado) (en-US) se tornou comum nos últimos anos e alguns navegadores permitem apenas certificados emitidos com um SCT (carimbo de data e hora do certificado assinado), esse método exige a aplicação de uma política empresarial. Em um ambiente tão controlado, não há necessidade de se preocupar com o cache do proxy estar "desatualizado e não atualizado".

#### Caches gerenciados

Os caches gerenciados são implantados explicitamente por desenvolvedores de serviços para descarregar o servidor de origem e fornecer conteúdo com eficiência. Os exemplos incluem proxies reversos, CDNs e service workers em combinação com a API de cache.

As características dos caches gerenciados variam dependendo do produto implementado. Na maioria dos casos, você pode controlar o comportamento do cache através do cabeçalho `Cache-Control` e seus próprios arquivos de configuração ou painéis.

Por exemplo, a especificação HTTP Caching essencialmente não define uma maneira de excluir explicitamente um cache — mas com um cache gerenciado, a resposta armazenada pode ser excluída a qualquer momento por meio de operações de painel, chamadas de API, reinicializações e assim por diante. Isso permite uma estratégia de cache mais proativa.

Também é possível ignorar os protocolos de especificação de cache HTTP padrão em favor da manipulação explícita. Por exemplo, o seguinte pode ser especificado para desativar um cache privado ou cache proxy, ao usar sua própria estratégia para armazenar em cache apenas em um cache gerenciado.

```http
Cache-Control: no-store
```

Por exemplo, o Varnish Cache usa VCL (Varnish Configuration Language, um tipo de lógica DSL (en-US)) para lidar com o armazenamento em cache, enquanto os service workers em combinação com a Cache API permitem que você crie essa lógica em JavaScript.

Isso significa que se um cache gerenciado ignorar intencionalmente uma diretiva `no-store`, não há necessidade de percebê-lo como "não compatível" com o padrão. O que você deve fazer é evitar o uso de cabeçalhos de pia de cozinha, mas leia atentamente a documentação de qualquer mecanismo de cache gerenciado que estiver usando e verifique se está controlando o cache adequadamente da maneira fornecida pelo mecanismo escolhido para usar.

Observe que alguns CDNs fornecem seus próprios cabeçalhos que são eficazes apenas para esse CDN (por exemplo, `Surrogate-Control`). Atualmente, o trabalho está em andamento para definir um cabeçalho `CDN-Cache-Control` para padronizá-los.

![Tipo de Cache](/pt-BR/docs/Web/HTTP/Caching/type-of-cache.png)

Cache heurístico
----------------

O HTTP foi projetado para armazenar em cache o máximo possível, portanto, mesmo que nenhum `Cache-Control` seja fornecido, as respostas serão armazenadas e reutilizadas se determinadas condições forem atendidas. Isso é chamado de **caching heurístico**.

Por exemplo, tome a seguinte resposta. Esta resposta foi atualizada pela última vez há 1 ano.

```http
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1024
Date: Tue, 22 Feb 2022 22:22:22 GMT
Last-Modified: Tue, 22 Feb 2021 22:22:22 GMT

<!doctype html>
…
```

Sabe-se heuristicamente que o conteúdo que não foi atualizado por um ano inteiro não será atualizado por algum tempo depois disso. Portanto, o cliente armazena essa resposta (apesar da falta de `max-age`) e a reutiliza por um tempo. Quanto tempo para reutilizar depende da implementação, mas a especificação recomenda cerca de 10% (neste caso 0,1 ano) do tempo após o armazenamento.

O cache heurístico é uma solução alternativa que veio antes que o suporte `Cache-Control` fosse amplamente adotado, e basicamente todas as respostas deveriam especificar explicitamente um cabeçalho `Cache-Control`.

Fresh e stale com base na idade
-------------------------------

As respostas HTTP armazenadas têm dois estados: **fresh** e **stale**. O estado *fresh* geralmente indica que a resposta ainda é válida e pode ser reutilizada, enquanto o estado *stale* significa que a resposta em cache já expirou.

O critério para determinar quando uma resposta é recente e quando está desatualizada é **age**. Em HTTP, a idade é o tempo decorrido desde que a resposta foi gerada. Isso é semelhante ao TTL (en-US) em outros mecanismos de cache.

Veja a seguinte resposta de exemplo (604800 segundos é uma semana):

```http
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1024
Date: Tue, 22 Feb 2022 22:22:22 GMT
Cache-Control: max-age=604800

<!doctype html>
…
```

O cache que armazenou a resposta de exemplo calcula o tempo decorrido desde que a resposta foi gerada e usa o resultado como *age* da resposta.

Para a resposta de exemplo, o significado de `max-age` é o seguinte:

* Se a idade da resposta for *menos* de uma semana, a resposta será *fresh*.
* Se a idade da resposta for *mais* de uma semana, a resposta será *stale*.

Enquanto a resposta armazenada permanecer atualizada, ela será usada para atender às solicitações do cliente.

Quando uma resposta é armazenada em um cache compartilhado, é necessário informar ao cliente a idade da resposta. Continuando com o exemplo, se o cache compartilhado armazenasse a resposta por um dia, o cache compartilhado enviaria a seguinte resposta para solicitações de clientes subsequentes.

```http
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1024
Date: Tue, 22 Feb 2022 22:22:22 GMT
Cache-Control: max-age=604800
Age: 86400

<!doctype html>
…
```

O cliente que receber essa resposta a achará atualizada pelos 518.400 segundos restantes, a diferença entre a `max-age` e a `Age` da resposta.

Expires ou max-age
------------------

No HTTP/1.0, o frescor costumava ser especificado pelo cabeçalho `Expires`.

O cabeçalho `Expires` especifica o tempo de vida do cache usando um tempo explícito em vez de especificar um tempo decorrido.

```http
Expires: Tue, 28 Feb 2022 22:22:22 GMT
```

No entanto, o formato de hora é difícil de analisar, muitos bugs de implementação foram encontrados e é possível induzir problemas alterando intencionalmente o relógio do sistema; portanto, `max-age` — para especificar um tempo decorrido — foi adotado para `Cache-Control` em HTTP/1.1.

Se `Expires` e `Cache-Control: max-age` estiverem disponíveis, `max-age` será definido como preferencial. Portanto, não é necessário fornecer `Expires` agora que o HTTP/1.1 é amplamente utilizado.

Vary
----

A maneira como as respostas são diferenciadas umas das outras é essencialmente baseada em seus URLs:

![chave com url](/pt-BR/docs/Web/HTTP/Caching/keyed-with-url.png)

Mas o conteúdo das respostas nem sempre é o mesmo, mesmo que tenham a mesma URL. Especialmente quando a negociação de conteúdo é realizada, a resposta do servidor pode depender dos valores dos cabeçalhos de solicitação `Accept`, `Accept-Language` e `Accept-Encoding`.

Por exemplo, para conteúdo em inglês retornado com um cabeçalho `Accept-Language: en` e armazenado em cache, é indesejável reutilizar essa resposta em cache para solicitações que tenham um cabeçalho de solicitação `Accept-Language: ja`. Nesse caso, você pode fazer com que as respostas sejam armazenadas em cache separadamente — com base no idioma — adicionando "`Accept-Language`" ao valor do cabeçalho `Vary`.

```http
Vary: Accept-Language
```

Isso faz com que o cache seja codificado com base em uma composição do URL de resposta e no cabeçalho de solicitação `Accept-Language` — em vez de ser baseado apenas no URL de resposta.

![chaveado com url e idioma](/pt-BR/docs/Web/HTTP/Caching/keyed-with-url-and-language.png)

Além disso, se você estiver fornecendo otimização de conteúdo (por exemplo, para design responsivo) com base no agente do usuário, pode ser tentado a incluir "`User-Agent`" no valor do cabeçalho `Vary`. No entanto, o cabeçalho de solicitação `User-Agent` geralmente tem um número muito grande de variações, o que reduz drasticamente a chance de o cache ser reutilizado. Portanto, se possível, considere uma maneira de variar o comportamento com base na detecção de recursos, em vez de com base no cabeçalho da solicitação `User-Agent`.

Para aplicativos que empregam cookies para impedir que outros reutilizem conteúdo personalizado em cache, você deve especificar `Cache-Control: private` em vez de especificar um cookie para `Vary`.

Validação
---------

As respostas obsoletas não são descartadas imediatamente. O HTTP tem um mecanismo para transformar uma resposta obsoleta em uma nova, perguntando ao servidor de origem. Isso é chamado de **validação** ou, às vezes, **revalidação**.

A validação é feita usando uma **solicitação condicional** que inclui um cabeçalho de solicitação `If-Modified-Since` ou `If-None-Match`.

### If-Modified-Since

A resposta a seguir foi gerada às 22:22:22 e tem um `max-age` de 1 hora, então você sabe que ela é atualizada até 23:22:22.

```http
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1024
Date: Tue, 22 Feb 2022 22:22:22 GMT
Last-Modified: Tue, 22 Feb 2022 22:00:00 GMT
Cache-Control: max-age=3600

<!doctype html>
…
```

Às 23:22:22, a resposta se torna obsoleta e o cache não pode ser reutilizado. Portanto, a solicitação abaixo mostra um cliente enviando uma solicitação com um cabeçalho de solicitação `If-Modified-Since`, para perguntar ao servidor se houve alguma alteração feita desde o horário especificado.

```http
GET /index.html HTTP/1.1
Host: example.com
Accept: text/html
If-Modified-Since: Tue, 22 Feb 2022 22:00:00 GMT
```

O servidor responderá com `304 Not Modified` se o conteúdo não mudou desde o horário especificado.

Como essa resposta indica apenas "sem alteração", não há corpo de resposta - há apenas um código de status - portanto, o tamanho da transferência é extremamente pequeno.

```http
HTTP/1.1 304 Not Modified
Content-Type: text/html
Date: Tue, 22 Feb 2022 23:22:22 GMT
Last-Modified: Tue, 22 Feb 2022 22:00:00 GMT
Cache-Control: max-age=3600
```

Ao receber essa resposta, o cliente reverte a resposta antiga armazenada e pode reutilizá-la durante a 1 hora restante.

O servidor pode obter o tempo de modificação do sistema de arquivos do sistema operacional, o que é relativamente fácil de fazer no caso de servir arquivos estáticos. No entanto, existem alguns problemas; por exemplo, o formato de hora é complexo e difícil de analisar, e os servidores distribuídos têm dificuldade em sincronizar os horários de atualização de arquivo.

Para resolver tais problemas, o cabeçalho de resposta `ETag` foi padronizado como alternativa.

### ETag/If-None-Match

O valor do cabeçalho de resposta `ETag` é um valor arbitrário gerado pelo servidor. Não há restrições sobre como o servidor deve gerar o valor, portanto, os servidores são livres para definir o valor com base em qualquer meio que escolherem - como um hash do conteúdo do corpo ou um número de versão.

Como exemplo, se um valor de hash for usado para o cabeçalho `ETag` e o valor de hash do recurso `index.html` for `33a64df5`, a resposta será a seguinte:

```http
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1024
Date: Tue, 22 Feb 2022 22:22:22 GMT
ETag: "33a64df5"
Cache-Control: max-age=3600

<!doctype html>
…
```

Se essa resposta estiver obsoleta, o cliente pega o valor do cabeçalho de resposta `ETag` para a resposta em cache e o coloca no cabeçalho de solicitação `If-None-Match`, para perguntar ao servidor se o recurso foi modificado:

```http
GET /index.html HTTP/1.1
Host: example.com
Accept: text/html
If-None-Match: "33a64df5"
```

O servidor retornará `304 Not Modified` se o valor do cabeçalho `ETag` que ele determinar para o recurso solicitado for o mesmo que o valor `If-None-Match` na solicitação.

Mas se o servidor determinar que o recurso solicitado deve ter agora um valor 'ETag' diferente, o servidor responderá com um '200 OK' e a versão mais recente do recurso.

**Nota:** ao avaliar como usar `ETag` e `Last-Modified`, considere o seguinte:
 Durante a revalidação de cache, se ambos `ETag` e `Last-Modified` estiverem presentes, `ETag` terá precedência.
 Portanto, se você está considerando apenas o armazenamento em cache, você pode pensar que 'Last-Modified' é desnecessário.
 No entanto, `Last-Modified` não é apenas útil para cache; em vez disso, é um cabeçalho HTTP padrão que também é usado por sistemas de gerenciamento de conteúdo (CMS) para exibir a hora da última modificação, por rastreadores para ajustar a frequência de rastreamento e para outras finalidades.
 Portanto, considerando o ecossistema HTTP geral, é preferível fornecer `ETag` e `Last-Modified`.

### Forçar revalidação

Se você não quer que uma resposta seja reutilizada, mas quer sempre buscar o conteúdo mais recente do servidor, você pode usar a diretiva `no-cache` para forçar a validação.

Ao adicionar `Cache-Control: no-cache` à resposta junto com `Last-Modified` e `ETag` — como mostrado abaixo — o cliente receberá uma resposta `200 OK` se o recurso solicitado foi atualizado ou caso contrário, receba uma resposta `304 Not Modified` se o recurso solicitado não tiver sido atualizado.

```http
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1024
Date: Tue, 22 Feb 2022 22:22:22 GMT
Last-Modified: Tue, 22 Feb 2022 22:00:00 GMT
ETag: deadbeef
Cache-Control: no-cache

<!doctype html>
…
```

Costuma-se dizer que a combinação de `max-age=0` e `must-revalidate` tem o mesmo significado de `no-cache`.

```http
Cache-Control: max-age=0, must-revalidate
```

`max-age=0` significa que a resposta é imediatamente obsoleta, e `must-revalidate` significa que ela não deve ser reutilizada sem revalidação uma vez que está obsoleta - então, em combinação, a semântica parece ser a mesma que `no -cache`.

No entanto, esse uso de `max-age=0` é um resquício do fato de que muitas implementações anteriores ao HTTP/1.1 eram incapazes de lidar com a diretiva `no-cache` — e, portanto, para lidar com essa limitação, `max-age =0` foi usado como solução alternativa.

Mas agora que os servidores compatíveis com HTTP/1.1 são amplamente implantados, não há razão para usar essa combinação `max-age=0` e `must-revalidate` - você deve usar apenas `no-cache`.

Não armazenar em cache
----------------------

A diretiva `no-cache` não impede o armazenamento de respostas, mas impede a reutilização de respostas sem revalidação.

Se você não quiser uma resposta armazenada em nenhum cache, use `no-store`.

```http
Cache-Control: no-store
```

No entanto, em geral, um requisito de "não armazenar em cache" na prática equivale ao seguinte conjunto de circunstâncias:

* Não deseja que a resposta seja armazenada por outra pessoa que não seja o cliente específico, por questões de privacidade.
* Quer fornecer informações atualizadas sempre.
* Não sei o que pode acontecer em implementações desatualizadas.

Sob esse conjunto de circunstâncias, `no-store` nem sempre é a diretiva mais apropriada.

As seções a seguir examinam as circunstâncias com mais detalhes.

### Não compartilhe com outras pessoas

Seria problemático se uma resposta com conteúdo personalizado fosse inesperadamente visível para outros usuários de um cache.

Nesse caso, usar a diretiva `private` fará com que a resposta personalizada seja armazenada apenas com o cliente específico e não seja vazada para nenhum outro usuário do cache.

```http
Cache-Control: private
```

Nesse caso, mesmo que `no-store` seja fornecido, `private` também deve ser fornecido.

### Forneça conteúdo atualizado sempre

A diretiva `no-store` impede que uma resposta seja armazenada, mas não exclui nenhuma resposta já armazenada para o mesmo URL.

Em outras palavras, se já houver uma resposta antiga armazenada para uma URL específica, retornar `no-store` não impedirá que a resposta antiga seja reutilizada.

No entanto, uma diretiva `no-cache` forçará o cliente a enviar uma solicitação de validação antes de reutilizar qualquer resposta armazenada.

```http
Cache-Control: no-cache
```

Se o servidor não suportar solicitações condicionais, você pode forçar o cliente a acessar o servidor todas as vezes e sempre obter a resposta mais recente com `200 OK`.

### Lidando com implementações desatualizadas

Como solução para implementações desatualizadas que ignoram `no-store`, você pode ver cabeçalhos de pia de cozinha, como o seguinte, sendo usados.

```http
Cache-Control: no-store, no-cache, max-age=0, must-revalidate, proxy-revalidate
```

É recomendado usar `no-cache` como uma alternativa para lidar com essas implementações desatualizadas , e não há problema se `no-cache` for fornecido desde o início, pois o servidor sempre receberá a solicitação.

Se você está preocupado com o cache compartilhado, certifique-se de evitar o cache não intencional adicionando também `private`:

```http
Cache-Control: no-cache, private
```

### O que é perdido por `no-store`

Você pode pensar que adicionar `no-store` seria a maneira correta de desativar o armazenamento em cache.

No entanto, não é recomendado conceder `no-store` liberalmente, porque você perde muitas vantagens que o HTTP e os navegadores têm, incluindo o cache de retorno/avanço do navegador.

Portanto, para obter as vantagens do conjunto completo de recursos da plataforma web, prefira o uso de `no-cache` em combinação com `private`.

Recarregue e force o recarregamento
-----------------------------------

A validação pode ser realizada tanto para solicitações quanto para respostas.

As ações **reload** e **force reload** são exemplos comuns de validação realizada do lado do navegador.

### Recarregar

Para recuperar a corrupção da janela ou atualizar para a versão mais recente do recurso, os navegadores fornecem uma função de recarregamento para os usuários.

Uma visualização simplificada da solicitação HTTP enviada durante um recarregamento do navegador é a seguinte:

```http
GET / HTTP/1.1
Host: example.com
Cache-Control: max-age=0
If-None-Match: "deadbeef"
If-Modified-Since: Tue, 22 Feb 2022 20:20:20 GMT
```

(As solicitações do Chrome, Edge e Firefox são muito parecidas com as acima; as solicitações do Safari serão um pouco diferentes.)

A diretiva `max-age=0` na solicitação especifica "reutilização de respostas com idade igual ou inferior a 0" — portanto, na verdade, as respostas armazenadas intermediárias não são reutilizadas.

Como resultado, uma solicitação é validada por `If-None-Match` e `If-Modified-Since`.

Esse comportamento também é definido no padrão Fetch e pode ser reproduzido em JavaScript chamando `fetch()` com o modo de cache definido como `no-cache` (observe que `reload` não é o modo correto para este caso):

```js
// Nota: "reload" não é o modo correto para um recarregamento normal; "no-cache" é
fetch("/", { cache: "no-cache" });
```

### Forçar recarga

Os navegadores usam `max-age=0` durante os recarregamentos por motivos de compatibilidade com versões anteriores — porque muitas implementações desatualizadas anteriores ao HTTP/1.1 não entendiam `no-cache`. Mas `no-cache` está bem agora neste caso de uso, e **forçar recarregamento** é uma forma adicional de contornar as respostas em cache.

A solicitação HTTP durante um **recarregamento forçado** do navegador tem a seguinte aparência:

```http
GET / HTTP/1.1
Host: example.com
Pragma: no-cache
Cache-Control: no-cache
```

(As solicitações do Chrome, Edge e Firefox são muito parecidas com as acima; as solicitações do Safari serão um pouco diferentes.)

Como essa não é uma solicitação condicional com `no-cache`, você pode ter certeza de que receberá um `200 OK` do servidor de origem.

Esse comportamento também é definido no padrão Fetch e pode ser reproduzido em JavaScript chamando `fetch()` com o modo de cache definido como `reload` (observe que não é `force-reload`):

```js
// Nota: "reload" — em vez de "no-cache" — é o modo correto para um "force reload"fetch("/", { cache: "reload" });
```

### Evitando a revalidação

O conteúdo que nunca muda deve receber uma longa `max-age` usando cache busting — ou seja, incluindo um número de versão, valor de hash, etc., no URL da solicitação.

No entanto, quando o usuário recarrega, uma solicitação de revalidação é enviada mesmo que o servidor saiba que o conteúdo é imutável.

Para evitar isso, a diretiva `immutable` pode ser usada para indicar explicitamente que a revalidação não é necessária porque o conteúdo nunca muda.

```http
Cache-Control: max-age=31536000, immutable
```

Isso evita revalidações desnecessárias durante as recargas.

Observe que, em vez de implementar essa diretiva, o Chrome mudou sua implementação para que a revalidação não seja executado durante recargas para sub-recursos.

Excluindo respostas armazenadas
-------------------------------

Basicamente, não há como excluir respostas que já foram armazenadas com um `max-age` longo.

Imagine que a seguinte resposta de `https://example.com/` foi armazenada.

```http
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1024
Cache-Control: max-age=31536000

<!doctype html>
…
```

Você pode querer sobrescrever essa resposta depois que ela expirar no servidor, mas não há nada que o servidor possa fazer depois que a resposta for armazenada - já que nenhuma solicitação chega ao servidor devido ao armazenamento em cache.

Um dos métodos mencionados na especificação é enviar uma solicitação para a mesma URL com um método não seguro como `POST`, mas isso geralmente é difícil de fazer intencionalmente para muitos clientes.

Há também uma especificação para um cabeçalho e valor `Clear-Site-Data: cache`, mas nem todos os navegadores o suportam — e mesmo quando usado, afeta apenas os caches do navegador e não afeta os caches intermediários.

Portanto, deve-se presumir que qualquer resposta armazenada permanecerá por seu período de `max-age`, a menos que o usuário execute manualmente uma ação de recarregar, forçar o recarregamento ou limpar o histórico.

O armazenamento em cache reduz o acesso ao servidor, o que significa que o servidor perde o controle dessa URL. Se o servidor não quiser perder o controle de uma URL — por exemplo, no caso de um recurso ser atualizado com frequência — você deve adicionar `no-cache` para que o servidor sempre receba solicitações e envie as respostas pretendidas.

Recolhimento da solicitação
---------------------------

O cache compartilhado está localizado principalmente antes do servidor de origem e destina-se a reduzir o tráfego para o servidor de origem.

Assim, se várias solicitações idênticas chegarem a um cache compartilhado ao mesmo tempo, o cache intermediário encaminhará uma única solicitação em seu nome para a origem, que poderá reutilizar o resultado para todos os clientes. Isso é chamado de ***recolhimento da solicitação***.

O colapso da solicitação ocorre quando as solicitações chegam ao mesmo tempo, portanto, mesmo que `max-age=0` ou `no-cache` seja fornecido na resposta, ele será reutilizado.

Se a resposta for personalizada para um usuário específico e você não quiser que ela seja compartilhada em recolhimento, você deve adicionar a diretiva `private`:

![Recolher solicitação](/pt-BR/docs/Web/HTTP/Caching/request-collapse.png)

Padrões de cache comuns
-----------------------

Existem muitas diretivas na especificação `Cache-Control`, e pode ser difícil entender todas elas. Mas a maioria dos sites pode ser coberta por uma combinação de alguns padrões.

Esta seção descreve os padrões comuns no projeto de caches.

### Configurações padrão

Como mencionado acima, o comportamento padrão para armazenamento em cache (ou seja, para uma resposta sem `Cache-Control`) não é simplesmente "não armazenar em cache", mas cache implícito de acordo com o chamado "caching heurístico".

Para evitar esse cache heurístico, é preferível fornecer explicitamente a todas as respostas um cabeçalho padrão `Cache-Control`.

Para garantir que, por padrão, as versões mais recentes dos recursos sempre serão transferidas, é uma prática comum fazer com que o valor padrão de `Cache-Control` inclua `no-cache`:

```http
Cache-Control: no-cache
```

Além disso, se o serviço implementa cookies ou outros métodos de login, e o conteúdo é personalizado para cada usuário, também deve ser fornecido `privado`, para evitar o compartilhamento com outros usuários:

```http
Cache-Control: no-cache, private
```

### Bloqueio de cache

Os recursos que funcionam melhor com cache são arquivos estáticos imutáveis cujo conteúdo nunca muda. E para recursos que *fazem* alterações, é uma prática recomendada comum alterar a URL sempre que o conteúdo for alterado, para que a unidade de URL possa ser armazenada em cache por um período mais longo.

Como exemplo, considere o seguinte HTML:

```html
<script src="bundle.js"></script>
<link rel="stylesheet" href="build.css" />
<body>
  hello
</body>
```

No desenvolvimento web moderno, os recursos JavaScript e CSS são atualizados com frequência à medida que o desenvolvimento avança. Além disso, se as versões dos recursos JavaScript e CSS que um cliente usa estiverem fora de sincronia, a exibição será interrompida.

Portanto, o HTML acima dificulta o cache de `bundle.js` e `build.css` com `max-age`.

Portanto, você pode fornecer JavaScript e CSS com URLs que incluem uma parte de alteração com base em um número de versão ou valor de hash. Algumas das maneiras de fazer isso são mostradas abaixo.
```

# versão no nome do arquivo
bundle.v123.js

# versão na consulta
bundle.js?v=123

# hash no nome do arquivo
bundle.YsAIAAAA-QG4G6kCMAMBAAAAAAAoK.js

# hash na consulta
bundle.js?v=YsAIAAAA-QG4G6kCMAMBAAAAAAAoK
```

Como o cache distingue recursos uns dos outros com base em seus URLs, o cache não será reutilizado novamente se o URL for alterado quando um recurso for atualizado.

```html
<script src="bundle.v123.js"></script>
<link rel="stylesheet" href="build.v123.css" />
<body>
  hello
</body>
```

Com esse design, os recursos JavaScript e CSS podem ser armazenados em cache por um longo tempo. Então, quanto tempo deve ser definido como `max-age`? A especificação QPACK fornece uma resposta a essa pergunta.

QPACK é um padrão para compactar campos de cabeçalho HTTP, com tabelas de valores de campo comumente usados definidas.

Alguns valores de cabeçalho de cache comumente usados são mostrados abaixo.
```

36 cache-control max-age=0
37 cache-control max-age=604800
38 cache-control max-age=2592000
39 cache-control no-cache
40 cache-control no-store
41 cache-control public, max-age=31536000
```

Se você selecionar uma dessas opções numeradas, poderá compactar valores em 1 byte quando transferidos via HTTP3.

Os números `37`, `38` e `41` são para períodos de uma semana, um mês e um ano.

Como o cache remove entradas antigas quando novas entradas são salvas, a probabilidade de que uma resposta armazenada ainda exista após uma semana não é tão alta — mesmo se `max-age` for definido como 1 semana. Portanto, na prática, não faz muita diferença qual você escolhe.

Observe que o número `41` tem a `max-age` mais longa (1 ano), mas com `public`.

O valor `public` tem o efeito de tornar a resposta armazenável mesmo se o cabeçalho `Authorization` estiver presente.

**Nota:** A diretiva `public` só deve ser usada se houver necessidade de armazenar a resposta quando o cabeçalho `Authorization` for definido.
 Não é necessário de outra forma, porque uma resposta será armazenada no cache compartilhado enquanto `max-age` for fornecido.

Portanto, se a resposta for personalizada com autenticação básica, a presença de `público` pode causar problemas. Se estiver preocupado com isso, você pode escolher o segundo valor mais longo, `38` (1 mês).

```http
# resposta para bundle.v123.js

# Se você nunca personalizar as respostas por meio de autorização
Cache-Control: public, max-age=31536000

# Se você não pode ter certeza
Cache-Control: max-age=2592000
```

### Validação

Não se esqueça de definir os cabeçalhos `Last-Modified` e `ETag`, para que você não precise retransmitir um recurso ao recarregar. É fácil gerar esses cabeçalhos para arquivos estáticos pré-criados.

O valor `ETag` aqui pode ser um hash do arquivo.

```http
# resposta para bundle.v123.js
Last-Modified: Tue, 22 Feb 2022 20:20:20 GMT
ETag: YsAIAAAA-QG4G6kCMAMBAAAAAAAoK
```

Além disso, `imutable` pode ser adicionado para evitar a validação no recarregamento.

O resultado combinado é mostrado abaixo.

```http
# bundle.v123.js
HTTP/1.1 200 OK
Content-Type: application/javascript
Content-Length: 1024
Cache-Control: public, max-age=31536000, immutable
Last-Modified: Tue, 22 Feb 2022 20:20:20 GMT
ETag: YsAIAAAA-QG4G6kCMAMBAAAAAAAoK
```

O **bloqueio de cache** é uma técnica para tornar uma resposta armazenável em cache por um longo período, alterando o URL quando o conteúdo é alterado. A técnica pode ser aplicada a todos os sub-recursos, como imagens.

**Nota:** Ao avaliar o uso de `immutable` e QPACK:
 Se você está preocupado que `imutable` altera o valor predefinido fornecido pelo QPACK, considere que
 neste caso, a parte `imutable` pode ser codificada separadamente dividindo o valor `Cache-Control` em duas linhas — embora isso dependa do algoritmo de codificação que uma implementação QPACK específica usa.

```http
Cache-Control: public, max-age=31536000
Cache-Control: immutable
```

### Principais recursos

Ao contrário dos sub-recursos, os recursos principais não podem ser bloqueados no cache porque suas URLs não podem ser decoradas da mesma forma que as URLs de sub-recursos.

Se o próprio HTML a seguir for armazenado, a versão mais recente não poderá ser exibida, mesmo que o conteúdo seja atualizado no lado do servidor.

```html
<script src="bundle.v123.js"></script>
<link rel="stylesheet" href="build.v123.css" />
<body>
  hello
</body>
```

Para esse caso, `no-cache` seria apropriado — em vez de `no-store` — já que não queremos armazenar HTML, mas apenas queremos que ele esteja sempre atualizado.

Além disso, adicionar `Last-Modified` e `ETag` permitirá que os clientes enviem solicitações condicionais, e um `304 Not Modified` pode ser retornado se não houver atualizações no HTML:

```http
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1024
Cache-Control: no-cache
Last-Modified: Tue, 22 Feb 2022 20:20:20 GMT
ETag: AAPuIbAOdvAGEETbgAAAAAAABAAE
```

Essa configuração é apropriada para HTML não personalizado, mas para uma resposta personalizada usando cookies — por exemplo, após um login — não se esqueça de especificar também `private`:

```http
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1024
Cache-Control: no-cache, private
Last-Modified: Tue, 22 Feb 2022 20:20:20 GMT
ETag: AAPuIbAOdvAGEETbgAAAAAAABAAE
Set-Cookie: \_\_Host-SID=AHNtAyt3fvJrUL5g5tnGwER; Secure; Path=/; HttpOnly
```

O mesmo pode ser usado para `favicon.ico`, `manifest.json`, `.well-known` e endpoints de API cujos URLs não podem ser alterados usando cache busting.

A maior parte do conteúdo da web pode ser coberta por uma combinação dos dois padrões descritos acima.

### Mais sobre caches gerenciados

Com o método descrito nas seções anteriores, os sub-recursos podem ser armazenados em cache por um longo tempo usando o cache busting, mas os recursos principais (que geralmente são documentos HTML) não podem.

O armazenamento em cache dos recursos principais é difícil porque, usando apenas diretivas padrão da especificação HTTP Caching, não há como excluir ativamente o conteúdo do cache quando o conteúdo é atualizado no servidor.

No entanto, é possível implementar um cache gerenciado, como um CDN ou um service worker.

Por exemplo, uma CDN que permite a limpeza de cache por meio de uma API ou operação de painel permitiria uma estratégia de armazenamento em cache mais agressiva armazenando o recurso principal e limpando explicitamente o cache relevante somente quando ocorrer uma atualização no servidor.

Um service worker poderia fazer o mesmo se pudesse excluir o conteúdo da API de Cache quando ocorrer uma atualização no servidor.

Para obter mais informações, consulte a documentação do seu CDN e consulte a documentação do service worker.

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

* RFC 9111: Protocolo de transferência de hipertexto (HTTP/1.1): armazenamento em cache
* Tutorial de armazenamento em cache - Mark Nottingham


Métodos de requisição HTTP - HTTP

Métodos de requisição HTTP
==========================

>
> *Nota: O conteúdo original publicado em inglês no Mozilla Developer Network utiliza o termo "resource", mantido na tradução, que refere-se a qualquer destino válido ao executar uma conexão usando o protocolo HTTP. Na língua portuguesa, ao falar sobre requisições, o termo é pouco usado com essa finalidade ou contexto.*
>
>
>

O protocolo HTTP define um conjunto de **métodos de requisição** responsáveis por indicar a ação a ser executada para um dado recurso. Embora esses métodos possam ser descritos como substantivos, eles também são comumente referenciados como ***HTTP Verbs (Verbos HTTP)***. Cada um deles implementa uma semântica diferente, mas alguns recursos são compartilhados por um grupo deles, como por exemplo, qualquer método de requisição pode ser do tipo safe, idempotent ou cacheable (en-US).

`GET`

O método `GET` solicita a representação de um recurso específico. Requisições utilizando o método `GET` devem retornar apenas dados.

`HEAD`

O método `HEAD` solicita uma resposta de forma idêntica ao método `GET`, porém sem conter o corpo da resposta.

`POST`

O método `POST` é utilizado para submeter uma entidade a um recurso específico, frequentemente causando uma mudança no estado do recurso ou efeitos colaterais no servidor.

`PUT`

O método `PUT` substitui todas as atuais representações do recurso de destino pela carga de dados da requisição.

`DELETE`

O método `DELETE` remove um recurso específico.

`CONNECT`

O método `CONNECT` estabelece um túnel para o servidor identificado pelo recurso de destino.

`OPTIONS`

O método `OPTIONS` é usado para descrever as opções de comunicação com o recurso de destino.

`TRACE`

O método `TRACE` executa um teste de chamada *loop-back* junto com o caminho para o recurso de destino.

`PATCH`

O método `PATCH` é utilizado para aplicar modificações parciais em um recurso.

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

| Especificação | Título | Comentário |
| --- | --- | --- |
| RFC 7231, sessão 4: Request methods | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content | Especifica os métodos GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE. |
| RFC 5789, sessão 2: Patch method | PATCH Method for HTTP | Especifica o método PATCH. |

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

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

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

* Cabeçalhos HTTP


Utilizando Políticas de Segurança de Conteúdo - HTTP

Utilizando Políticas de Segurança de Conteúdo
=============================================

**Content Security Policy** (Política de Segurança de Conteúdo, também conhecida como CSP (en-US)) é uma camada adicional de segurança que facilita a detecção e mitigação de certos tipos de ataques, incluindo Cross Site Scripting (XSS (en-US)) e ataques de injeção de dados. Esses ataques são utilizados para diversos fins, e eles vão desde roubo de dados até desfiguração do site para distribuição de malware.

O CSP foi projetado para ser totalmente compatível retroatívelmente (come exceção da versão 2 do CSP onde existem algumas inconsistências explicitamente mencionadas com compatibilidade retroativa; mais detalhes podem ser encontrados aqui na seção 1.1). Os navegadores que não possuem suporte para o CSP ainda irão funcionar com servidores que o implementarem, e vice-versa: navegadores que não fornecem suporte podem simplesmente ignora-lo, funcionando normalmente, utilizando a norma padrão de same-origin policy (en-US) (política de mesma origem) para conteúdo web. Se o site não oferecer o cabeçaho CSP, os navegadores também utilizam a política de same-origin.

Para habilitar o CSP, você precisa configurar seu web server para retornar o cabeçalho `Content-Security-Policy` (algumas vezes você verá menções para o cabeçalho `X-Content-Security-Policy`, mas essa é uma versão antiga que você não precisa especificar mais.

Alternativamente, o elemento `<meta>` pode ser usado para configurar a política, por exemplo: `<meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*; child-src 'none';">`

Ameaças
-------

### Mitigando cross site scripting

Um objetivo primário do CSP é de mitigar e reportar ataques XSS. Os ataques de XSS exploram a confiaça do navegador sobre o conteúdo recebido pelo servidor. Scripts maliciosos são executados pelo navegador da vítima porque o navegador confia na origem do conteúdo, mesmo quando sua origem não está vindo de onde parece que está vindo.

O CSP faz com que seja possível para administradores de servidores reduzirem ou eliminarem os vetores em que os ataques de XSS podem ocorrer, especificando os domínios que o navegador deve considerar como origens válidas de scripts para serem executados. Um navegador compatível com o CSP só irá executar então scripts que vierem de arquivos que estejam presentes nos domínios que foram previamente especificados como confiáveis, ignorando todos os outros scripts (incluindo scripts inline e atributos HTML de manipulação de eventos).

Como uma forma de proteção final, os sites que querem nunca permitir a execução de scripts podem optar para desabilitar a execução globalmente.

### Mitigando ataques de captura de pacotes

Além da restrição de domínios deonde o conteúdo pode ser carregado, o servidor consegue especificar quais protocolos estão habilitados para utilização; por exemplo (e literalmente, de um ponto de vista de segurança), um servidor pode especificar que todo conteúdo deve ser carregando utilizando HTTPS. Uma estratégia completa de transmissão de dados segura inclui não só impor o protocolo HTTPS para transferência de dados, mas também marcar todos os *cookies* com a *secure flag* e prover redirecionamentos automáticos de páginas HTTP para suas versões HTTPS. Os sites também podem utilizar o cabeçalho `Strict-Transport-Security` para garantir que os navegadores se conectem neles apenas usando um canal criptografado.

Utilizando o CSP
----------------

Configurar uma Política de Segurança de Conteúdo envolve adicionar o header HTTP `Content-Security-Policy` a uma página web e adicionar valores para controlar recursos que o user-agent é habilitado para carregar para aquela página. Por exemplo, uma página que faz o upload e exibe imagens poderia permitir imagens de qualquer lugar, mas restringir um form action de um end point específico. Uma política de segurança de conteúdo devidamente concebida ajuda a proteger a página contra ataques do tipo cross site scripting. Este artigo explica como construir tais headers devidamente, e provê exemplos.

Anteriormente ao Firefox 23, o header HTTP `X-Content-Security-Policy` era utilizado. Do Firefox 23 em diante começou-se a usar o novo padrão, o header `Content-Security-Policy`. Durante a transição do header anterior para o novo header, sites podiam enviar ambos os header `X-Content-Security-Policy` e `Content-Security-Policy`. Neste caso, o header `X-Content-Security-Policy` seria ignorado e a política contida no header `Content-Security-Policy` seria utilizada.

Especificando sua política
--------------------------

Você pode usar o `Content-Security-Policy` HTTP header para especificar sua política, dessa forma:
```

Content-Security-Policy: policy
```

A política é uma string contendo as diretivas de políticas descrevendo seu Content Security Policy.

Escrevendo uma política
-----------------------

Uma politica é descrita usando uma série de diretivas de políticas (en-US), cada uma descrevendo uma política para certos tipos de recursos ou áreas de política. Sua política deve incluir uma diretiva de política padrão `default-src`, que cobre os outros tipos de recursos quando eles não possuem política própria. (Para uma lista completa, veja a descrição da diretiva default-src.) Uma política precisa incluir uma diretiva `default-src` ou script-src para evitar que scripts inline sejam executados, assim como bloquear o uso de `eval()`. Uma política precisa incluir uma diretiva `default-src` ou `style-src`para restringir estilos inline de serem aplicados a partir de um elemento `<style>` ou um `.style` atributo.

A sintaxe para uma política é uma string de diretivas separadas por ponto e vírgula `;`, cada seguindo a sintaxe descrita em Diretivas de políticas suportadas.

Exemplos: Casos de uso comuns
-----------------------------

A sessão provê alguns exemplos de alguns cenários comuns de política de segurança.

### Exemplo 1

Um administrador de *web site* quer que todo o conteúdo venha do mesmo *site* de origem (excluindo seus subdomínios).
```

Content-Security-Policy: default-src 'self'
```

### Exemplo 2

Um administrador de *web site* quer que todo o conteúdo venha do mesmo *site* de origem, e também de um domínio confiável e seus todos seus subdomínios (não necessariamente precisa ser o mesmo domínio onda a CSP está inserida).
```

Content-Security-Policy: default-src 'self' *.trusted.com
```

### Exemplo 3

A web site administrator wants to allow users of a web application to include images from any origin in their own content, but to restrict audio or video media to trusted providers, and all scripts only to a specific server that hosts trusted code.
```

Content-Security-Policy: default-src 'self'; img-src *; media-src media1.com media2.com; script-src userscripts.example.com
```

Here, by default, content is only permitted from the document's origin, with the following exceptions:

* Images may loaded from anywhere (note the "\*" wildcard).
* Media is only allowed from media1.com and media2.com (and not from subdomains of those sites).
* Executable script is only allowed from userscripts.example.com.
### Exemplo 4

A web site administrator for an online banking site wants to ensure that all its content is loaded using SSL, in order to prevent attackers from eavesdropping on requests.
```

Content-Security-Policy: default-src https://onlinebanking.jumbobank.com
```

The server only permits access to documents being loaded specifically over HTTPS through the single origin onlinebanking.jumbobank.com.

### Exemplo 5

A web site administrator of a web mail site wants to allow HTML in email, as well as images loaded from anywhere, but not JavaScript or other potentially dangerous content.
```

Content-Security-Policy: default-src 'self' *.mailsite.com; img-src *
```

Note that this example doesn't specify a `script-src`; with the example CSP, this site uses the setting specified by the `default-src` directive, which means that scripts can be loaded only from the originating server.

Testando sua política
---------------------

To ease deployment, CSP can be deployed in "report-only" mode. The policy is not enforced, but any violations are reported to a provided URI. Additionally, a report-only header can be used to test a future revision to a policy without actually deploying it.

You can use the `Content-Security-Policy-Report-Only` HTTP header to specify your policy, like this:
```

Content-Security-Policy-Report-Only: policy
```

If both a `Content-Security-Policy-Report-Only` header and a `Content-Security-Policy` header are present in the same response, both policies are honored. The policy specified in `Content-Security-Policy` headers is enforced while the `Content-Security-Policy-Report-Only` policy generates reports but is not enforced.

Note that the `X-Content-Security-Policy-Report-Only` header was used before Firefox 23. If both the `X-Content-Security-Policy-Report-Only` and `Content-Security-Policy-Report-Only` are sent, the `Content-Security-Policy-Report-Only` will be used and the `X-Content-Security-Policy-Report-Only` will be ignored.

The UserCSP Addon also helps test and develop Content Security Policies for a site.

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

* Introducing Content Security Policy
* CSP policy directives
* Using CSP violation reports
* Content Security Policy recommendation bookmarklet


Gerenciamento de Conexão em HTTP/1.x - HTTP

Gerenciamento de Conexão em HTTP/1.x
====================================

Gerenciamento de Conexão é um tema central em HTTP: abertura e manutenção de conexões e em grande parte tem impacto sobre o desempenho de Web sites e aplicações Web. Existem vários modelos, em HTTP/1.x: *ligações de curta duração, conexões persistentes, canalização e HTTP (HTTP pipelining)*.

HTTP é um protocolo de transporte que fornece conexão entre o cliente e o servidor geralmente depende de TCP. Em sua infância, HTTP usava um único modelo para lidar com tais conexões. Sua conexão é de curta duração. Essas conexões foram de curta duração: criado um novo cada vez que enviar um pedido necessário, e fechado uma vez a resposta tinha sido recebida.

Este simples modelo realiza uma limitação inata em desempenho: a abertura de cada uma das conexões TCP é uma operação de consumo de recursos.Várias mensagens devem ser trocadas entre o cliente e o servidor. Latência de rede e largura de banda afetam o desempenho quando precisa de uma solicitação de envio. Páginas de Web modernas exigem muitos pedidos (uma dúzia ou mais) para servir a quantidade de informação necessária, provando este modelo anterior ineficiente.

Dois novos modelos foram criados no HTTP/1.1.

1. **O modelo de conexão persistente**, mantém conexões abertas entre solicitações sucessivas, reduzindo o tempo necessário para abrir novas conexões.
2. **O modelo de pipelining HTTP**, vai um passo além, enviando várias solicitações sucessivas sem nem esperar por uma resposta, reduzindo em grande parte a latência da rede.

![Compares the performance of the three HTTP/1.x connection models: short-lived connections, persistent connections, and HTTP pipelining.](/pt-BR/docs/Web/HTTP/Connection_management_in_HTTP_1.x/http1_x_connections.png)

**Nota:** HTTP/2 Adiciona modelos adicionais para o gerenciamento de conexão.

Um ponto importante para observar, que gerenciamento de conexão HTTP, aplica-se para a conexão entre dois nós consecutivos, que é o hop-by-hop e não end-to-end . O modelo usado em conexões entre um cliente e seu primeiro proxy pode diferir do modelo entre um proxy e o servidor de destino (ou qualquer proxies intermédios). Os cabeçalhos HTTP envolvidos na definição do modelo de conexão, como `Connection` e `Keep-Alive`, são hop-by-hop, cabeçalhos com seus valores poderão ser alterados por nós intermediários.

Short-lived connections (Conexões de curta duração)
---------------------------------------------------

O modelo original de HTTP e o padrão HTTP/1.0, é short-lived connections (conexões de curta duração). Cada solicitação HTTP é concluída na sua própria conexão; Isto significa que um handshake TCP acontece antes de cada solicitação HTTP, e estas são serializadas.

O handshake TCP em si é demorado, mas uma conexão TCP adapta-se a sua carga, tornando-se mais eficiente com mais conexões sustentadas (ou aquecidas). Conexões de curta duração não fazem uso desse recurso de eficiência do TCP, e degrada o desempenho do ideal persistindo para transmitir mais de uma conexão nova, frio.

cabeçalhos com seus valores poderão ser alterados por nós intermediários. (if there is no `Connection` header, or if its value is set to `close`). Em HTTP/1.1 este modelo é apenas usado quando o `Connection`cabeçalho é enviado com um valor de fechamento.

**Nota:** A menos que lidemos com um sistema muito antigo, que não suporta uma conexão persistente, não há nenhuma razão convincente para usar este modelo.

Conexões Persistentes
---------------------

Short-lived connections (conexões de curta duração) tem dois grandes problemas: o tempo necessário para estabelecer uma nova conexão é significativo, e desempenho da conexão TCP subjacente melhora somente quando esta conexão tem sido usado há algum tempo (conexão quente). Para aliviar estes problemas, foi concebido o conceito de uma conexão persistente, mesmo antes de HTTP/1.1. Alternativamente, este pode ser chamado uma conexão keep-alive.

É uma conexão persistente que permanece aberto por um período e pode ser reutilizado por vários pedidos, salvando a necessidade de um novo handshake TCP, e utilizando recursos para melhorar o desempenho do TCP. Esta conexão não vai ficar aberta para sempre: conexões ociosas são fechadas depois de algum tempo (um servidor pode usar o cabeçalho `Keep-Alive` para especificar um tempo mínimo de conexão que deve ser mantido aberto).

Conexões persistentes também têm desvantagens, mesmo quando em marcha lenta eles consomem recursos do servidor e sob pesada carga, pode efetuar-se DoS attacks (en-US). Em tais casos, usar conexões não-persistentes, que estão fechadas, assim como elas estão ociosas, pode fornecer um melhor desempenho.HTTP/1.0 as conexões sem persistencia por default.Setting `Connection` para algo diferente de fechar, costuma após repetir, irá torná-los persistente.

Em HTTP/1.1, persistencia é o padrão e o cabeçalho não é mais necessário (mas ele é adicionado frequentemente como uma medida defensiva contra casos que exigem um fallback para HTTP/1.0).

HTTP pipelining
---------------

**Nota:** HTTP o pipelining não é ativado por padrão em navegadores modernos:

* Buggy proxies são ainda comuns e eles levam a comportamentos estranhos e erráticos que desenvolvedores Web não podem prever e diagnosticar facilmente.
* Pipelining é complexo para implementar corretamente: o tamanho do recurso a ser transferido, a efetiva RTT que será usado, bem como a largura de banda efetiva, têm uma incidência direta na melhoria fornecida pelo pipeline. Sem conhecer eles, mensagens importantes podem ser atrasadas por detrás aqueles sem importância. A noção de importante mesmo evolui durante o layout de página! Pipeline HTTP, portanto, traz uma melhoria marginal na maioria dos casos apenas.
* Pipelining está sujeito à problema HOL.

Por estas razões, o pipelining tem sido substituído por um algoritmo melhor, multiplexação, que é usado pelo HTTP/2.

Por padrão, HTTP as solicitações são emitidas sequencialmente. A próxima solicitação só é emitida depois que recebeu a resposta para a solicitação atual. Como eles são afetados pelas latências de rede e as limitações de largura de banda, isso pode resultar em atrasos significativos antes que a próxima solicitação é vista pelo servidor.

Pipelining é o processo para enviar solicitações sucessivas, sobre a mesma conexão persistente, sem esperar pela resposta. Isso evita a latência da conexão. Teoricamente, desempenho também poderia ser melhorado se duas solicitações HTTP para ser embalado na mesma mensagem TCP. O MSS típico (tamanho máximo de segmento), é grande o suficiente para conter várias solicitações simples, embora a demanda em tamanho de solicitações HTTP continua a crescer.

Nem todos os tipos de solicitações HTTP podem ser intermitente: only idempotent método, isso é `GET`, `HEAD`, `PUT` e `DELETE` pode ser repetido com segurança: uma falha pode acontecer, o conteúdo do pipeline simplesmente pode ser repetido.

Hoje, cada proxy HTTP/1.1-compatível e servidor devem apoiar o pipelining, embora muitos têm limitações na prática: uma razão significativa, nenhum navegador moderno ativa esse recurso por padrão.

Domain sharding
---------------

**Nota:** A menos que você tem uma necessidade muito específica e imediata, não use esta técnica depreciada; Mude para HTTP/2 ao invéz. Em HTTP/2, sharding domínio não é mais útil: a conexão HTTP/2 é capaz de manipular as solicitações sem prioridades paralelas muito bem. Sharding domínio é mesmo prejudicial ao desempenho. A maioria dos implementação de HTTP/2 usam uma técnica chamada connection coalescing para reverter o sharding de domínio eventual.

Como uma conexão de HTTP/1.x está serializando solicitações, mesmo sem qualquer ordenação, não pode ser ideal sem largura de banda grande o suficiente disponível. Como uma solução, os navegadores abrir várias conexões para cada domínio, enviando solicitações paralelas. Era padrão conexões de 2 a 3, mas isto agora aumentou para um uso mais comum de 6 conexões paralelas. Há um risco de provocar proteção DoS (en-US) no lado do servidor, se tentar mais do que este número.

Se o servidor deseja um site de Web mais rápido ou resposta do aplicativo, é possível para o servidor forçar a abertura de mais conexões. Por exemplo, em vez de ter todos os recursos no mesmo domínio, diz www.example.com, poderia dividir em vários domínios, www1.example.com, www2.example.com, www3.example.com. Cada um destes domínios resolver acessar o mesmo servidor e o navegador da Web abrirá 6 conexões para cada (no nosso exemplo, impulsionando as conexões para 18). Esta técnica é chamada sharding do domínio.

![](/pt-BR/docs/Web/HTTP/Connection_management_in_HTTP_1.x/httpsharding.png)

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

Gerenciamento de conexão melhorada permite considerável aumento de desempenho em HTTP. Com HTTP/1.1 ou HTTP/1.0, usando uma conexão persistente – pelo menos até que se torne ocioso – levando para o melhor desempenho. No entanto, o falha do pipelining tem levado para a concepção de modelos de gestão de conexão superior, que foram incorporados ao HTTP/2.


Básico sobre HTTP - HTTP

Básico sobre HTTP
=================

HTTP é um protocolo bem extensivo. Isso depende um pouco do conceito básico com noção de recursos e URIs, uma simples estrutura de mensagens, e uma estrutura de cliente-servidor para a comunicação ocorrer. Em cima destes conceitos básicos, várias versões surgiram ao longo do tempo, adicionando novas funcionalidades e novas semanticas para criar novos métodos HTTP ou cabeçalhos.

Artigos
-------

Visão geral sobre HTTP

Descreve o que é HTTP e quais as regras para arquitetura Web, sua posição na lista de protocolos.

Evolução do HTTP (en-US)

HTTP foi criada no inicio dos anos 1990 e vem evoluindo ao longo do tempo. Esse artigo passa por sua história e descreve HTTP/0.9, HTTP/1.0, HTTP/1.1, e o moderno HTTP/2 bem como pequenas novidades adicionadas ao longo de seus anos.

**Negociação entre versões HTTP**

Explicações de como um cliente e um servidor conseguem negociar em uma versão expecífica do HTTP e enventuais atualizaçõs nos protocolos usados;

Recursos e URIs (en-US)

Uma breve introdução sobre noção de recursos, identicadores e localizações na Web.

Identificando recursos na Web

Descreve como os recursos Web são referênciados e como encontrar eles.

Data URIs (en-US)

Um tipo especifico de URIs que incorpora diretamente os recursos apresentados, Data URIs são muito convenientes, mas tem algumas ressalvas

**Separando identidades e localização de recursos: O cabeçalho Alt-Svc HTTP**

Na maioria das vezes, a indentidade ea localização de um recurso da Web são compartilhados, isso pode ser mudado com no cabeçalho `Alt-Svc`.

MIME types

Desde HTTP/1.0, diferentes tipos de conteúdos poderam ser transmitidos. Esse artigo explica como funciona usando o {cabeçalho {HTTPHeader("Content-Type")}} e o MIME standard.

Escolhendo entre URLs www e sem-www (en-US)

Ajuda de como usar o prefixo www no domínio ou não, esse artigo fala as consequencias da escolhe e também como fazer isso.

Fluxo de sessões HTTP

Esse artigo fundamente descreve uma típica sessão HTTP: o que acontece por trás do do navegador quando você clica em um link.

Mensagens HTTP

Mensagens HTTP transmitidas durante o pedido ou resposta tem uma clara estrutura; isso introduz descrição sobre essas estrutura no artigo, seus proprósitos e suas possibilidades.

Quadro e estrutura de mensagens no HTTP/2

HTTP/2 junta e representa mensagens do HTTP/1.x em um quadro binário. Esse artigo explica a estrutura do quadro, sua finalidade ea maneira como ele é codificado.

Gerenciamento de conexão no HTTP/1.x

HTTP/1.1 foi a primeira versão do HTTP a suportar conexão constante e canalizar elas. Esse artigo explica sobre estes dois conceitos.

Gerenciamento de conexão no HTTP/2

HTTP/2 Revisitou completamente como as conexões são criadas e mantidas: esse artigo explica como os quadros HTTP permitem multiplexação e resolver o bloco 'head-of-line' bloqueio das versões anteirores do HTTP.

Conteúdo da negociação

HTTP introduz um conjunto de cabeçalhos, começando com `Accept-` como o meio que o navegador anuncia o formato, linguagem, ou a codificação é preferida. Esse artigo explica como esse anuncio acontece, como o servidor é esperado para reagir e como será escolhido a melhor resposta.