# Comportamento de solicitação e resposta
Os tópicos a seguir descrevem como o CloudFront lida com solicitações e respostas.
Você pode saber mais sobre como o CloudFront interage com o Amazon S3 ou com origens personalizadas, lida com vários métodos e cabeçalhos HTTP, processa códigos de status e gerencia o armazenamento em cache e as respostas de erro.
**Topics**
+ [Como o CloudFront processa solicitações HTTP e HTTPS](HTTPandHTTPSRequests.md)
+ [Comportamento de solicitações e respostas para origens do Amazon S3](RequestAndResponseBehaviorS3Origin.md)
+ [Comportamento de solicitações e respostas para origens personalizadas](RequestAndResponseBehaviorCustomOrigin.md)
+ [Comportamento de solicitações e respostas para grupos de origens](RequestAndResponseBehaviorOriginGroups.md)
+ [Adicionar cabeçalhos personalizados às solicitações de origem](add-origin-custom-headers.md)
+ [Como o CloudFront processa solicitações parciais de um objeto (Range GETs)](RangeGETs.md)
+ [Como o CloudFront processa códigos de status HTTP 3xx da origem](http-3xx-status-codes.md)
+ [Como o CloudFront processa códigos de status HTTP 4xx e 5xx da origem](HTTPStatusCodes.md)
+ [Gerar respostas a erros personalizadas](GeneratingCustomErrorResponses.md)
# Como o CloudFront processa solicitações HTTP e HTTPS
Para origens do Amazon S3, o CloudFront aceita solicitações nos protocolos HTTP e HTTPS para objetos em uma distribuição do CloudFront por padrão. O CloudFront encaminha as solicitações ao bucket do Amazon S3 usando o mesmo protocolo usado para fazer as solicitações.
Para origens personalizadas, ao criar a distribuição, é possível especificar como o CloudFront acessa a origem: apenas HTTP ou correspondência com o protocolo usado pelo visualizador. Para mais informações sobre como o CloudFront lida com solicitações HTTP e HTTPS para origens personalizadas, consulte [Protocolos](RequestAndResponseBehaviorCustomOrigin.md#RequestCustomProtocols).
Para informações sobre como restringir sua distribuição, de modo que os usuários finais só possam acessar objetos usando HTTPS, consulte [Usar HTTPS com o CloudFront](using-https.md).
**nota**
A cobrança de solicitações HTTPS é superior a de solicitações HTTP. Para ter mais informações sobre as taxas de faturamento, acesse [Preço do CloudFront](https://aws.amazon.com/cloudfront/#pricing).
# Comportamento de solicitações e respostas para origens do Amazon S3
Para entender como o CloudFront processa solicitações e respostas ao usar o Amazon S3 como origem, consulte as seguintes seções:
**Topics**
+ [Como o CloudFront processa e encaminha solicitações à sua origem do Amazon S3](#RequestBehaviorS3Origin)
+ [Como o CloudFront processa as respostas da origem do Amazon S3](#ResponseBehaviorS3Origin)
## Como o CloudFront processa e encaminha solicitações à sua origem do Amazon S3
Saiba como o CloudFront processa solicitações do visualizador e as encaminha para a origem do Amazon S3.
**Contents**
+ [Duração do armazenamento em cache e TTL mínimo](#RequestS3Caching)
+ [Endereços IP do cliente](#RequestS3IPAddresses)
+ [Solicitações GET condicionais](#RequestS3ConditionalGETs)
+ [Cookies](#RequestS3Cookies)
+ [Compartilhamento de recursos de origem cruzada (CORS)](#RequestS3-cors)
+ [Solicitações GET que incluem um corpo](#RequestS3-get-body)
+ [Métodos HTTP](#RequestS3HTTPMethods)
+ [Cabeçalhos de solicitação HTTP removidos ou atualizados pelo CloudFront](#request-s3-removed-headers)
+ [Tamanho máximo de uma solicitação e de um URL](#RequestS3MaxRequestStringLength)
+ [OCSP Stapling](#request-s3-ocsp-stapling)
+ [Protocolos](#RequestS3Protocol)
+ [Strings de consulta](#RequestS3QueryStrings)
+ [Tentativas e tempo limite de conexão da origem](#s3-origin-timeout-attempts)
+ [Tempo limite de resposta da origem](#RequestS3RequestTimeout)
+ [Solicitações simultâneas para o mesmo objeto (recolhimento de solicitações)](#request-s3-traffic-spikes)
### Duração do armazenamento em cache e TTL mínimo
Para controlar por quanto tempo os objetos permanecem em um cache do CloudFront antes que o CloudFront encaminhe outra solicitação para a sua origem, você pode:
+ Configurar sua origem para adicionar um campo de cabeçalho `Cache-Control` ou `Expires` a cada objeto.
+ Especificar um valor de TTL mínimo nos comportamentos de cache do CloudFront.
+ Usar o valor padrão de 24 horas.
Para obter mais informações, consulte [Gerenciar o tempo de permanência do conteúdo no cache (expiração)](Expiration.md).
### Endereços IP do cliente
Se um visualizador enviar uma solicitação ao CloudFront e não incluir um cabeçalho de solicitação `X-Forwarded-For`, o CloudFront receberá o endereço IP do visualizador na conexão TCP, adicionará um cabeçalho `X-Forwarded-For` que inclui o endereço IP e encaminhará a solicitação à origem. Por exemplo, se o CloudFront obter o endereço IP `192.0.2.2` da conexão TCP, ele encaminhará o seguinte cabeçalho à origem:
`X-Forwarded-For: 192.0.2.2`
Se um visualizador enviar uma solicitação ao CloudFront e incluir um cabeçalho de solicitação `X-Forwarded-For`, o CloudFront obterá o endereço IP do visualizador na conexão TCP, incluirá ele no fim do cabeçalho `X-Forwarded-For` e encaminhará a solicitação à origem. Por exemplo, se a solicitação do visualizador incluir `X-Forwarded-For: 192.0.2.4,192.0.2.3` e o CloudFront obtiver o endereço IP `192.0.2.2` da conexão TCP, ele encaminhará o seguinte cabeçalho à origem:
`X-Forwarded-For: 192.0.2.4,192.0.2.3,192.0.2.2`
**nota**
O cabeçalho `X-Forwarded-For` contém endereços IPv4 (como 192.0.2.44) e IPv6 (como 2001:0db8:85a3::8a2e:0370:7334).
### Solicitações GET condicionais
Ao receber uma solicitação de um objeto que expirou de um cache de borda, o CloudFront encaminha a solicitação à origem do Amazon S3 a fim de receber a versão mais recente do objeto ou a confirmação do Amazon S3 de que o cache de borda do CloudFront já tem a versão mais recente. Ao enviar originalmente o objeto ao CloudFront, o Amazon S3 incluiu os valores `ETag` e `LastModified` na resposta. Na nova solicitação encaminhada pelo CloudFront ao Amazon S3, o CloudFront adiciona um destes cabeçalhos:
+ Um cabeçalho `If-Match` ou `If-None-Match` com o valor `ETag` da versão expirada do objeto.
+ Um cabeçalho `If-Modified-Since` com o valor `LastModified` da versão expirada do objeto.
O Amazon S3 usa essas informações para determinar se o objeto foi atualizado e, portanto, se deve retornar todo o objeto ao CloudFront ou apenas a um código de status HTTP 304 (não modificado).
### Cookies
O Amazon S3 não processa cookies. Se você configurar um comportamento de cache para encaminhar cookies a uma origem do Amazon S3, o CloudFront encaminhará os cookies, mas o Amazon S3 os ignorará. Todas as solicitações futuras do mesmo objeto, independentemente se você variar o cookie ou não, serão fornecidas do objeto existente no cache.
### Compartilhamento de recursos de origem cruzada (CORS)
Se quiser que o CloudFront respeite as configurações de compartilhamento de recursos entre origens do Amazon S3, configure o CloudFront para encaminhar os cabeçalhos selecionados ao Amazon S3. Para obter mais informações, consulte [Conteúdo em cache com base nos cabeçalhos de solicitação](header-caching.md).
### Solicitações GET que incluem um corpo
Se a solicitação `GET` do visualizador incluir um corpo, o CloudFront retornará o código de status HTTP 403 (Proibido).
### Métodos HTTP
Se você configurar o CloudFront para processar todos os métodos HTTP compatíveis, ele aceitará as seguintes solicitações de visualizadores e as encaminhará à origem do Amazon S3:
+ `DELETE`
+ `GET`
+ `HEAD`
+ `OPTIONS`
+ `PATCH`
+ `POST`
+ `PUT`
O CloudFront sempre armazena respostas às solicitações `GET` e `HEAD` em cache. Também é possível configurar o CloudFront para armazenar respostas a solicitações `OPTIONS` em cache. O CloudFront não armazena em cache respostas a solicitações que usem outros métodos.
Se você quiser usar carregamentos fragmentados para adicionar objetos a um bucket do Amazon S3, será necessário adicionar um controle de acesso à origem (OAC) do CloudFront à distribuição e conceder ao OAC as permissões necessárias. Para obter mais informações, consulte [Restringir o acesso a uma origem do Amazon S3](private-content-restricting-access-to-s3.md).
**Importante**
Se você configurar o CloudFront para aceitar e encaminhar ao Amazon S3 todos os métodos HTTP compatíveis com o CloudFront, será necessário criar um AOC do CloudFront para restringir o acesso ao conteúdo do Amazon S3 e conceder ao OAC as permissões necessárias. Por exemplo, se você configurar o CloudFront para aceitar e encaminhar esses métodos porque deseja usar o método `PUT`, será necessário configurar as políticas do bucket do Amazon S3 para lidar com solicitações `DELETE` de forma apropriada para que os visualizadores não possam excluir recursos que você não deseja que eles excluam. Para obter mais informações, consulte [Restringir o acesso a uma origem do Amazon S3](private-content-restricting-access-to-s3.md).
Para obter informações sobre as operações compatíveis com o Amazon S3, consulte a [Documentação do Amazon S3](https://docs.aws.amazon.com/s3/index.html).
### Cabeçalhos de solicitação HTTP removidos ou atualizados pelo CloudFront
O CloudFront remove ou atualiza alguns cabeçalhos antes de encaminhar solicitações à origem do Amazon S3. Para a maioria dos cabeçalhos, esse comportamento é o mesmo que para origens personalizadas. Para obter uma lista completa dos cabeçalhos de solicitação HTTP e a maneira como o CloudFront os processa, consulte [Cabeçalhos de solicitação HTTP e comportamento do CloudFront (origens do Amazon S3 e personalizadas)](RequestAndResponseBehaviorCustomOrigin.md#request-custom-headers-behavior).
### Tamanho máximo de uma solicitação e de um URL
O tamanho máximo de uma solicitação, com o caminho, a query string (se houver) e os cabeçalhos, é de 20.480 bytes.
O CloudFront cria um URL com base na solicitação. O tamanho máximo do URL é de 8.192 bytes.
Se uma solicitação ou um URL ultrapassar o tamanho máximo, o CloudFront exibirá o código de status HTTP 413 (Entidade de solicitação muito grande) ao visualizador e, depois, encerrará a conexão TCP com ele.
### OCSP Stapling
Quando um visualizador envia uma solicitação HTTPS para um objeto, tanto ele quanto o CloudFront devem confirmar com a autoridade de certificação (CA) se o certificado SSL do domínio não foi revogado. O OCSP Stapling acelera a validação do certificado permitindo que o CloudFront valide o certificado e armazene as respostas da CA em cache, a fim de que o cliente não precise validar o certificado diretamente com a CA.
A melhoria da performance do OCSP Stapling é mais acentuada quando o CloudFront recebe um grande número de solicitações HTTPS para objetos no mesmo domínio. Cada servidor em um ponto de presença do CloudFront deve enviar uma solicitação de validação separada. Quando o CloudFront recebe um grande número de solicitações HTTPS para o mesmo domínio, cada servidor no local da borda logo recebe uma resposta da CA que pode "grampear" em um pacote no handshake SSL. Quando o visualizador está convencido de que o certificado é válido, o CloudFront pode servir o objeto solicitado. Caso sua distribuição não tenha muito tráfego em um ponto de presença do CloudFront, é provável que novas solicitações sejam direcionadas para um servidor que ainda não validou o certificado com a CA. Nesse caso, o visualizador executa separadamente a etapa de validação, e o servidor do CloudFront fornece o objeto. Esse servidor do CloudFront também envia uma solicitação de validação para a CA para que, na próxima vez que receber uma solicitação com o mesmo nome de domínio, tenha uma resposta de validação da CA.
### Protocolos
O CloudFront encaminha solicitações HTTP ou HTTPS ao servidor de origem com base no protocolo da solicitação do visualizador: HTTP ou HTTPS.
**Importante**
Se o bucket do Amazon S3 estiver configurado como um endpoint de site, não será possível configurar o CloudFront para usar HTTPS para comunicação com a origem, pois o Amazon S3 não é compatível com conexões HTTPS nessa configuração.
### Strings de consulta
É possível configurar se o CloudFront encaminha parâmetros de string de consulta para a sua origem no Amazon S3. Para obter mais informações, consulte [Conteúdo em cache com base em parâmetros de string de consulta](QueryStringParameters.md).
### Tentativas e tempo limite de conexão da origem
*Tempo limite de conexão da origem* é o número de segundos que o CloudFront aguarda ao tentar estabelecer uma conexão com a origem.
*Tentativas de conexão da origem* é o número de vezes que o CloudFront tenta se conectar à origem.
Juntas, essas configurações determinam por quanto tempo o CloudFront tenta se conectar à origem antes de fazer o failover para a origem secundária, no caso de um grupo de origens, ou retornar uma resposta de erro ao visualizador. Por padrão, o CloudFront aguarda até 30 segundos (3 tentativas de 10 segundos cada) antes de tentar se conectar à origem secundária ou retornar uma resposta de erro. Esse tempo pode ser reduzido especificando um tempo limite de conexão mais curto, menos tentativas ou ambos.
Para obter mais informações, consulte [Controlar tempos limite e tentativas da origem](high_availability_origin_failover.md#controlling-attempts-and-timeouts).
### Tempo limite de resposta da origem
O *tempo limite de resposta da origem*, também conhecido como *tempo limite de leitura da origem* ou *tempo limite de solicitação da origem*, aplica-se a estes dois valores:
+ A quantidade de tempo, em segundos, que o CloudFront aguarda uma resposta após o encaminhamento de uma solicitação à origem.
+ A quantidade de tempo, em segundos, que o CloudFront aguarda após o recebimento de um pacote de resposta da origem e antes do recebimento do próximo pacote.
O comportamento do CloudFront depende do método HTTP da solicitação do visualizador:
+ Solicitações `GET` e `HEAD`: se a origem não responder dentro de 30 segundos ou parar de responder por 30 segundos, o CloudFront descartará a conexão. Se o número especificado de [tentativas de conexão da origem](DownloadDistValuesOrigin.md#origin-connection-attempts) for maior que 1, o CloudFront tentará obter uma resposta completa novamente. O CloudFront tenta até 3 vezes, conforme determinado pelo valor da configuração de *tentativas de conexão da origem*. Se a origem não responder durante a terceira tentativa, o CloudFront não tentará novamente enquanto não receber outra solicitação de conteúdo na mesma origem.
+ Solicitações `DELETE`, `OPTIONS`, `PATCH`, `PUT` e `POST`: se a origem não responder em 30 segundos, o CloudFront interromperá a conexão e não tentará entrar em contato com a origem novamente. O cliente pode reenviar a solicitação, se necessário.
Não é possível alterar o tempo limite de resposta para uma origem do Amazon S3 (um bucket do S3 que *não* esteja configurado com hospedagem de site estático).
### Solicitações simultâneas para o mesmo objeto (recolhimento de solicitações)
Quando um local da borda do CloudFront recebe uma solicitação de um objeto, e o objeto não está no cache ou o objeto em cache expirou, o CloudFront envia imediatamente a solicitação para a origem. No entanto, se houver solicitações simultâneas para o mesmo objeto, ou seja, se solicitações adicionais para o mesmo objeto (com a mesma chave de cache) chegarem ao local da borda antes de o CloudFront receber a resposta à primeira solicitação, o CloudFront fará uma pausa antes de encaminhar solicitações adicionais à origem. Essa breve pausa ajuda a reduzir a carga na origem. O CloudFront envia a resposta da solicitação original a todas as solicitações recebidas enquanto estava em pausa. Isso é chamado de *recolhimento de solicitações*. Nos logs do CloudFront, a primeira solicitação é identificada como `Miss` no campo `x-edge-result-type` e as solicitações recolhidas são identificadas como `Hit`. Para mais informações sobre os logs do CloudFront, consulte [Registro em log do CloudFront e de funções de borda](logging.md).
O CloudFront apenas recolhe solicitações que compartilham uma [*chave de cache*](understanding-the-cache-key.md). Se as solicitações adicionais não compartilharem a mesma chave de cache porque, por exemplo, você configurou o CloudFront para armazenar em cache com base nas strings de consulta, nos cookies ou nos cabeçalhos da solicitação, o CloudFront encaminhará todas as solicitações com uma chave de cache exclusiva à origem.
Se quiser evitar o recolhimento de todas as solicitações, será possível usar a política de cache gerenciada `CachingDisabled`, que também impede o armazenamento em cache. Para obter mais informações, consulte [Usar políticas de cache gerenciadas](using-managed-cache-policies.md).
Se você quiser evitar o recolhimento das solicitações para objetos específicos, defina a TTL mínima para o comportamento de cache como 0 *e* configure a origem para enviar `Cache-Control: private`, `Cache-Control: no-store`, `Cache-Control: no-cache`, `Cache-Control: max-age=0` ou `Cache-Control: s-maxage=0`. Essas configurações vão aumentar a carga na origem e introduzir latência adicional para as solicitações simultâneas que são pausadas enquanto o CloudFront aguarda a resposta à primeira solicitação.
**Importante**
Atualmente, o CloudFront não comporta recolher solicitações caso você habilite o encaminhamento de cookies na [política de cache](controlling-the-cache-key.md), na [política de solicitação de origem](controlling-origin-requests.md) ou nas configurações de cache herdadas.
## Como o CloudFront processa as respostas da origem do Amazon S3
Saiba como o CloudFront processa as respostas da origem do Amazon S3.
**Contents**
+ [Solicitações canceladas](#response-s3-canceled-requests)
+ [Cabeçalhos de resposta HTTP removidos ou atualizados pelo CloudFront](#response-s3-removed-headers)
+ [Tamanho máximo do arquivo armazenável em cache](#ResponseS3MaxFileSize)
+ [Redirecionamentos](#ResponseS3Redirects)
### Solicitações canceladas
Se o objeto não estiver no cache de ponto de presença e o visualizador encerrar a sessão (por exemplo, fechar o navegador) depois de o CloudFront obter o objeto da origem, mas antes de conseguir fornecer o objeto solicitado, ele não armazenará o objeto em cache no ponto de presença.
### Cabeçalhos de resposta HTTP removidos ou atualizados pelo CloudFront
O CloudFront remove ou atualiza os seguintes campos de cabeçalho antes de encaminhar a resposta da origem do Amazon S3 ao visualizador:
+ `X-Amz-Id-2`
+ `X-Amz-Request-Id`
+ `Set-Cookie`: se você configurar o CloudFront para encaminhar cookies, ele encaminhará o campo de cabeçalho `Set-Cookie` aos clientes. Para obter mais informações, consulte [Conteúdo em cache com base em cookies](Cookies.md).
+ `Trailer`
+ `Transfer-Encoding`: se a origem do Amazon S3 retornar esse campo de cabeçalho, o CloudFront definirá o valor de `chunked` antes de retornar a resposta ao visualizador.
+ `Upgrade`
+ `Via`: o CloudFront define o seguinte valor na resposta para o visualizador:
`Via: `*versão HTTP* *string alfanumérica*`.cloudfront.net (CloudFront)`
Por exemplo, o valor é semelhante ao seguinte:
`Via: 1.1 1026589cc7887e7a0dc7827b4example.cloudfront.net (CloudFront)`
### Tamanho máximo do arquivo armazenável em cache
O tamanho máximo do corpo de uma resposta salva pelo CloudFront no cache é de 50 GB. Isso inclui respostas de transferência em partes que não especificam o valor de cabeçalho `Content-Length`.
É possível usar o CloudFront para armazenar em cache um objeto maior que isso usando solicitações de intervalo para solicitar os objetos em partes que sejam cada uma de 50 GB ou menores. O CloudFront armazena essas partes em cache porque cada uma delas é de 50 GB ou menor. Depois que o visualizador recuperar todas as partes do objeto, ele poderá reconstruir o objeto original, maior. Para obter mais informações, consulte [Usar solicitações de intervalo para armazenar objetos grandes em cache](RangeGETs.md#cache-large-objects-with-range-requests).
### Redirecionamentos
É possível configurar um bucket do Amazon S3 para redirecionar todas as solicitações para outro nome de host, que pode ser outro bucket do Amazon S3 ou um servidor HTTP. Se você configurar um bucket para redirecionar todas as solicitações e se ele for a origem de uma distribuição do CloudFront, recomendamos configurá-lo para redirecionar todas as solicitações para uma distribuição do CloudFront usando o nome de domínio da distribuição (por exemplo, d111111abcdef8.cloudfront.net) ou um nome de domínio alternativo (CNAME) associado a uma distribuição (por exemplo, example.com). Caso contrário, as solicitações do visualizador ignorarão o CloudFront, e os objetos serão fornecidos diretamente da nova origem.
**nota**
Se você redirecionar as solicitações para um nome de domínio alternativo, deverá também atualizar o serviço de DNS do seu domínio adicionando um registro CNAME. Para obter mais informações, consulte [Usar URLs personalizados adicionando nomes de domínio alternativos (CNAMEs)](CNAMEs.md).
Veja o que acontece quando você configura um bucket para redirecionar todas as solicitações:
1. Um visualizador (por exemplo, um navegador) solicita um objeto do CloudFront.
1. O CloudFront encaminha a solicitação para o bucket do Amazon S3 que é a origem da distribuição.
1. O Amazon S3 retorna um código de status HTTP 301 (Movido permanentemente) e o novo local.
1. O CloudFront armazena o código de status de redirecionamento e o novo local e retorna os valores ao visualizador. O CloudFront não segue o redirecionamento para obter o objeto do novo local.
1. O visualizador envia outra solicitação do objeto, mas desta vez especifica o novo local obtido do CloudFront:
+ Se o bucket do Amazon S3 estiver redirecionando todas as solicitações para uma distribuição do CloudFront, usando o nome de domínio da distribuição ou um nome de domínio alternativo, o CloudFront solicitará o objeto do bucket do Amazon S3 ou do servidor HTTP no novo local. Quando o novo local retornar o objeto, o CloudFront o retorna ao visualizador e o armazenará em cache em um ponto de presença.
+ Se o bucket do Amazon S3 estiver redirecionando solicitações para outro local, a segunda solicitação ignorará o CloudFront. O bucket do Amazon S3 ou servidor HTTP no novo local retorna o objeto diretamente para o visualizador, para que ele nunca seja armazenado em cache em um cache de ponto de presença do CloudFront.
# Comportamento de solicitações e respostas para origens personalizadas
Para entender como o CloudFront processa solicitações e respostas ao usar origens personalizadas, consulte as seguintes seções:
**Topics**
+ [Como o CloudFront processa e encaminha solicitações para sua origem personalizada](#RequestBehaviorCustomOrigin)
+ [Como o CloudFront processa respostas da sua origem personalizada](#ResponseBehaviorCustomOrigin)
## Como o CloudFront processa e encaminha solicitações para sua origem personalizada
Saiba como o CloudFront processa solicitações do visualizador e as encaminha para a origem personalizada.
**Contents**
+ [Autenticação](#RequestCustomClientAuth)
+ [Duração do armazenamento em cache e TTL mínimo](#RequestCustomCaching)
+ [Endereços IP do cliente](#RequestCustomIPAddresses)
+ [Autenticação SSL do lado do cliente](#RequestCustomClientSideSslAuth)
+ [Compactação](#RequestCustomCompression)
+ [Solicitações condicionais](#RequestCustomConditionalGETs)
+ [Cookies](#RequestCustomCookies)
+ [Compartilhamento de recursos de origem cruzada (CORS)](#request-custom-cors)
+ [Criptografia](#RequestCustomEncryption)
+ [Solicitações GET que incluem um corpo](#RequestCustom-get-body)
+ [Métodos HTTP](#RequestCustomHTTPMethods)
+ [Cabeçalhos de solicitação HTTP e comportamento do CloudFront (origens do Amazon S3 e personalizadas)](#request-custom-headers-behavior)
+ [Versão HTTP](#RequestCustomHTTPVersion)
+ [Tamanho máximo de uma solicitação e de um URL](#RequestCustomMaxRequestStringLength)
+ [Associação OCSP](#request-custom-ocsp-stapling)
+ [Conexões persistentes](#request-custom-persistent-connections)
+ [Protocolos](#RequestCustomProtocols)
+ [Strings de consulta](#RequestCustomQueryStrings)
+ [Tentativas e tempo limite de conexão da origem](#custom-origin-timeout-attempts)
+ [Tempo limite de resposta da origem](#request-custom-request-timeout)
+ [Solicitações simultâneas para o mesmo objeto (recolhimento de solicitações)](#request-custom-traffic-spikes)
+ [`User-Agent`Cabeçalho](#request-custom-user-agent-header)
### Autenticação
Se você encaminhar o cabeçalho `Authorization` para sua origem, será possível configurar o servidor de origem para solicitar a autenticação do cliente para os seguintes tipos de solicitações:
+ `DELETE`
+ `GET`
+ `HEAD`
+ `PATCH`
+ `PUT`
+ `POST`
Para solicitações `OPTIONS`, é possível configurar a autenticação do cliente *somente* se usar as seguintes configurações do CloudFront:
+ O CloudFront foi configurado para encaminhar o cabeçalho `Authorization` à origem
+ O CloudFront foi configurado para *não* armazenar a resposta a solicitações `OPTIONS` em cache
Para obter mais informações, consulte [Configurar o CloudFront para encaminhar o cabeçalho `Authorization`](add-origin-custom-headers.md#add-origin-custom-headers-forward-authorization).
É possível usar HTTP ou HTTPS para encaminhar solicitações para o servidor de origem. Para obter mais informações, consulte [Usar HTTPS com o CloudFront](using-https.md).
### Duração do armazenamento em cache e TTL mínimo
Para controlar por quanto tempo os objetos permanecem em um cache do CloudFront antes que o CloudFront encaminhe outra solicitação para a sua origem, você pode:
+ Configurar sua origem para adicionar um campo de cabeçalho `Cache-Control` ou `Expires` a cada objeto.
+ Especificar um valor de TTL mínimo nos comportamentos de cache do CloudFront.
+ Usar o valor padrão de 24 horas.
Para obter mais informações, consulte [Gerenciar o tempo de permanência do conteúdo no cache (expiração)](Expiration.md).
### Endereços IP do cliente
Se um visualizador enviar uma solicitação ao CloudFront e não incluir um cabeçalho de solicitação `X-Forwarded-For`, o CloudFront obterá o endereço IP do visualizador na conexão TCP, adicionará um cabeçalho `X-Forwarded-For` que inclui o endereço IP e encaminhará a solicitação à origem. Por exemplo, se o CloudFront obter o endereço IP `192.0.2.2` da conexão TCP, ele encaminhará o seguinte cabeçalho à origem:
`X-Forwarded-For: 192.0.2.2`
Se um visualizador enviar uma solicitação ao CloudFront e incluir um cabeçalho de solicitação `X-Forwarded-For`, o CloudFront obterá o endereço IP do visualizador na conexão TCP, incluirá ele no fim do cabeçalho `X-Forwarded-For` e encaminhará a solicitação à origem. Por exemplo, se a solicitação do visualizador incluir `X-Forwarded-For: 192.0.2.4,192.0.2.3` e o CloudFront obtiver o endereço IP `192.0.2.2` da conexão TCP, ele encaminhará o seguinte cabeçalho à origem:
`X-Forwarded-For: 192.0.2.4,192.0.2.3,192.0.2.2`
Algumas aplicações, como balanceadores de carga (inclusive o Elastic Load Balancing), firewalls de aplicações Web, proxies reversos, sistemas de prevenção de invasão e API Gateway, adicionam o endereço IP do servidor de borda do CloudFront que encaminhou a solicitação no fim do cabeçalho `X-Forwarded-For`. Por exemplo, se o CloudFront incluir `X-Forwarded-For: 192.0.2.2` em uma solicitação encaminhada ao ELB e o endereço IP do servidor de borda do CloudFront for 192.0.2.199, a solicitação recebida pela instância do EC2 conterá o seguinte cabeçalho:
`X-Forwarded-For: 192.0.2.2,192.0.2.199`
**nota**
O cabeçalho `X-Forwarded-For` contém endereços IPv4 (como 192.0.2.44) e IPv6 (como 2001:0db8:85a3::8a2e:0370:7334).
Observe também que o cabeçalho `X-Forwarded-For` pode ser modificado por cada nó no caminho para o servidor atual (CloudFront). Para obter mais informações, consulte a seção 8.1 do [RFC 7239](https://datatracker.ietf.org/doc/html/rfc7239). Também é possível modificar o cabeçalho usando as funções de computação de borda do CloudFront.
### Autenticação SSL do lado do cliente
O CloudFront permite a autenticação TLS mútua (mTLS), na qual o cliente e o servidor se autenticam usando certificados. Com a mTLS configurada, o CloudFront pode validar certificados de clientes durante o handshake do TLS e, opcionalmente, executar o CloudFront Functions para implementar uma lógica de validação personalizada.
Se uma origem solicitar um certificado do lado do cliente quando a mTLS não está configurada, o CloudFront interromperá a solicitação.
Para ter mais informações sobre a configuração da mTLS, consulte [Associar uma função de conexão do CloudFront](connection-functions.md).
O CloudFront não é compatível com a autenticação do cliente com certificados SSL no lado do cliente. Se uma origem solicitar um certificado no lado do cliente, o CloudFront interromperá a solicitação.
### Compactação
Para obter mais informações, consulte [Fornecer arquivos compactados](ServingCompressedFiles.md).
### Solicitações condicionais
Ao receber uma solicitação de um objeto que expirou de um cache de ponto de presença, o CloudFront encaminha a solicitação à origem a fim de obter a versão mais recente do objeto ou a confirmação da origem de que o cache do ponto de presença do CloudFront já tem a versão mais recente. Normalmente, ao enviar o objeto pela última vez ao CloudFront, a origem inclui um valor `ETag` ou `LastModified`, ou os dois, na resposta. Na nova solicitação encaminhada pelo CloudFront à origem, o CloudFront adiciona um destes (ou os dois):
+ Um cabeçalho `If-Match` ou `If-None-Match` com o valor `ETag` da versão expirada do objeto.
+ Um cabeçalho `If-Modified-Since` com o valor `LastModified` da versão expirada do objeto.
A origem usa essas informações para determinar se o objeto foi atualizado e, portanto, se deve retornar todo o objeto ao CloudFront ou apenas a um código de status HTTP 304 (não modificado).
**nota**
As solicitações condicionais `If-Modified-Since` e `If-None-Match` não são compatíveis com o CloudFront quando ele estiver configurado para encaminhar cookies (todos ou um subconjunto).
Para obter mais informações, consulte [Conteúdo em cache com base em cookies](Cookies.md).
### Cookies
É possível configurar o CloudFront para encaminhar cookies à origem. Para obter mais informações, consulte [Conteúdo em cache com base em cookies](Cookies.md).
### Compartilhamento de recursos de origem cruzada (CORS)
Se quiser que o CloudFront respeite as configurações de compartilhamento de recursos entre origens, configure o CloudFront para encaminhar o cabeçalho `Origin` à origem. Para obter mais informações, consulte [Conteúdo em cache com base nos cabeçalhos de solicitação](header-caching.md).
### Criptografia
É possível solicitar que os usuários usem HTTPS para enviar solicitações ao CloudFront e que o CloudFront as encaminhe à origem personalizada usando o protocolo usado pelo visualizador. Para mais informações, consulte as configurações da distribuição:
+ [Política de protocolo do visualizador](DownloadDistValuesCacheBehavior.md#DownloadDistValuesViewerProtocolPolicy)
+ [Protocolo (somente origens personalizadas)](DownloadDistValuesOrigin.md#DownloadDistValuesOriginProtocolPolicy)
O CloudFront encaminha solicitações HTTPS ao servidor de origem usando os protocolos SSLv3, TLSv1.0, TLSv1.1, TLSv1.2 e TLSv1.3. Para origens personalizadas, é possível escolher os protocolos SSL a serem usados pelo CloudFront na comunicação com a origem:
+ Se você estiver usando o console do CloudFront, escolha os protocolos usando as caixas de seleção **Origin SSL Protocols (Protocolos SSL da origem)**. Para obter mais informações, consulte [Criar uma distribuição](distribution-web-creating-console.md).
+ Se você estiver usando a API do CloudFront, especifique os protocolos usando o elemento `OriginSslProtocols`. Para mais informações, consulte [OriginSslProtocols](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_OriginSslProtocols.html) e [DistributionConfig](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_DistributionConfig.html) na *Referência da API do Amazon CloudFront*.
Se a origem for um bucket do Amazon S3, o CloudFront sempre usará o TLSv1.3.
**Importante**
Outras versões de SSL e TLS não são compatíveis.
Para mais informações sobre como usar HTTPS com o CloudFront, consulte [Usar HTTPS com o CloudFront](using-https.md). Para ver as listas de criptografias compatíveis com o CloudFront para comunicação HTTPS entre os visualizadores e o CloudFront e entre o CloudFront e a origem, consulte [Protocolos e cifras compatíveis entre visualizadores e o CloudFront](secure-connections-supported-viewer-protocols-ciphers.md).
### Solicitações GET que incluem um corpo
Se a solicitação `GET` do visualizador incluir um corpo, o CloudFront retornará o código de status HTTP 403 (Proibido).
### Métodos HTTP
Se você configurar o CloudFront para processar todos os métodos HTTP compatíveis, ele aceitará as seguintes solicitações de visualizadores e as encaminhará à origem personalizada:
+ `DELETE`
+ `GET`
+ `HEAD`
+ `OPTIONS`
+ `PATCH`
+ `POST`
+ `PUT`
O CloudFront sempre armazena respostas às solicitações `GET` e `HEAD` em cache. Também é possível configurar o CloudFront para armazenar respostas a solicitações `OPTIONS` em cache. O CloudFront não armazena em cache respostas a solicitações que usam outros métodos.
Para obter informações sobre como configurar se sua origem personalizada processa esses métodos ou não, consulte a documentação referente a ela.
**Importante**
Se você configurar o CloudFront para aceitar e encaminhar todos os métodos HTTP compatíveis com o CloudFront à origem, configure o servidor de origem para lidar com todos eles. Por exemplo, se você configurar do CloudFront para aceitar e encaminhar esses métodos porque deseja usar `POST`, será necessário configurar o servidor de origem para lidar com solicitações `DELETE` de forma apropriada para que os visualizadores não possam excluir recursos selecionados. Para obter mais informações, consulte a documentação do seu servidor HTTP.
### Cabeçalhos de solicitação HTTP e comportamento do CloudFront (origens do Amazon S3 e personalizadas)
A tabela a seguir lista os cabeçalhos de solicitação HTTP que você pode encaminhar às origens personalizadas e do Amazon S3 (com as exceções observadas). Para cada cabeçalho, a tabela inclui informações sobre o seguinte:
+ O comportamento do CloudFront se você não configurar o CloudFront para encaminhar o cabeçalho à origem, o que faz com que ele armazene os objetos em cache com base nos valores de cabeçalho.
+ Se é possível configurar o CloudFront para armazenar os objetos em cache com base nos valores do cabeçalho em questão.
É possível configurar o CloudFront para armazenar os objetos em cache com base nos valores dos cabeçalhos `Date` e `User-Agent`, mas não recomendamos fazer isso. Há vários valores possíveis para esses cabeçalhos, e o armazenamento em cache com base nesses valores faz com que o CloudFront encaminhe significativamente mais solicitações à origem.
Para obter mais informações sobre o armazenamento em cache com base nos valores de cabeçalho, consulte [Conteúdo em cache com base nos cabeçalhos de solicitação](header-caching.md).
| Cabeçalho | Comportamento se você não configurar o CloudFront para armazenar em cache com base nos valores de cabeçalho | O armazenamento em cache com base nos valores de cabeçalho é compatível |
| --- | --- | --- |
| Outros cabeçalhos definidos | **Configurações de cache herdadas**: o CloudFront encaminha os cabeçalhos para a origem. | Sim |
| `Accept` | O CloudFront remove o cabeçalho. | Sim |
| `Accept-Charset` | O CloudFront remove o cabeçalho. | Sim |
| `Accept-Encoding` | Se o valor contiver `gzip` ou `br`, o CloudFront encaminhará um cabeçalho normalizado `Accept-Encoding` à origem. Para obter mais informações, consulte [Suporte à compactação](cache-key-understand-cache-policy.md#cache-policy-compressed-objects) e [Fornecer arquivos compactados](ServingCompressedFiles.md). | Sim |
| `Accept-Language` | O CloudFront remove o cabeçalho. | Sim |
| `Authorization` | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html) | Sim |
| `Cache-Control` | O CloudFront encaminha o cabeçalho à origem. | Não |
| `CloudFront-Forwarded-Proto` | O CloudFront não adiciona o cabeçalho antes de encaminhar a solicitação à origem. Para obter mais informações, consulte [Configurar o armazenamento em cache com base no protocolo da solicitação](header-caching.md#header-caching-web-protocol). | Sim |
| `CloudFront-Is-Desktop-Viewer` | O CloudFront não adiciona o cabeçalho antes de encaminhar a solicitação à origem. Para obter mais informações, consulte [Configurar o armazenamento em cache com base no tipo de dispositivo](header-caching.md#header-caching-web-device). | Sim |
| `CloudFront-Is-Mobile-Viewer` | O CloudFront não adiciona o cabeçalho antes de encaminhar a solicitação à origem. Para obter mais informações, consulte [Configurar o armazenamento em cache com base no tipo de dispositivo](header-caching.md#header-caching-web-device). | Sim |
| `CloudFront-Is-Tablet-Viewer` | O CloudFront não adiciona o cabeçalho antes de encaminhar a solicitação à origem. Para obter mais informações, consulte [Configurar o armazenamento em cache com base no tipo de dispositivo](header-caching.md#header-caching-web-device). | Sim |
| `CloudFront-Viewer-Country` | O CloudFront não adiciona o cabeçalho antes de encaminhar a solicitação à origem. | Sim |
| `Connection` | O CloudFront substitui esse cabeçalho por `Connection: Keep-Alive` antes de encaminhar a solicitação à origem. | Não |
| `Content-Length` | O CloudFront encaminha o cabeçalho à origem. | Não |
| `Content-MD5` | O CloudFront encaminha o cabeçalho à origem. | Sim |
| `Content-Type` | O CloudFront encaminha o cabeçalho à origem. | Sim |
| `Cookie` | Se você configurar o CloudFront para encaminhar cookies, ele encaminhará o campo de cabeçalho `Cookie` à origem. Em caso negativo, o CloudFront removerá o campo de cabeçalho `Cookie`. Para obter mais informações, consulte [Conteúdo em cache com base em cookies](Cookies.md). | Não |
| `Date` | O CloudFront encaminha o cabeçalho à origem. | Sim, mas não recomendado |
| `Expect` | O CloudFront remove o cabeçalho. | Sim |
| `From` | O CloudFront encaminha o cabeçalho à origem. | Sim |
| `Host` | O CloudFront define o valor do nome de domínio da origem associada ao objeto solicitado. Não é possível fazer o armazenamento em cache com base no cabeçalho Host para origens do Amazon S3 ou MediaStore. | Sim (personalizada) Não (S3 e MediaStore) |
| `If-Match` | O CloudFront encaminha o cabeçalho à origem. | Sim |
| `If-Modified-Since` | O CloudFront encaminha o cabeçalho à origem. | Sim |
| `If-None-Match` | O CloudFront encaminha o cabeçalho à origem. | Sim |
| `If-Range` | O CloudFront encaminha o cabeçalho à origem. | Sim |
| `If-Unmodified-Since` | O CloudFront encaminha o cabeçalho à origem. | Sim |
| `Max-Forwards` | O CloudFront encaminha o cabeçalho à origem. | Não |
| `Origin` | O CloudFront encaminha o cabeçalho à origem. | Sim |
| `Pragma` | O CloudFront encaminha o cabeçalho à origem. | Não |
| `Proxy-Authenticate` | O CloudFront remove o cabeçalho. | Não |
| `Proxy-Authorization` | O CloudFront remove o cabeçalho. | Não |
| `Proxy-Connection` | O CloudFront remove o cabeçalho. | Não |
| `Range` | O CloudFront encaminha o cabeçalho à origem. Para obter mais informações, consulte [Como o CloudFront processa solicitações parciais de um objeto (Range GETs)](RangeGETs.md). | Sim, por padrão |
| `Referer` | O CloudFront remove o cabeçalho. | Sim |
| `Request-Range` | O CloudFront encaminha o cabeçalho à origem. | Não |
| `TE` | O CloudFront remove o cabeçalho. | Não |
| `Trailer` | O CloudFront remove o cabeçalho. | Não |
| `Transfer-Encoding` | O CloudFront encaminha o cabeçalho à origem. | Não |
| `Upgrade` | O CloudFront remove o cabeçalho, a menos que você tenha estabelecido uma conexão WebSocket. | Não (exceto para conexões WebSocket) |
| `User-Agent` | O CloudFront substitui o valor desse campo de cabeçalho por `Amazon CloudFront`. Se você quiser que o CloudFront armazene o conteúdo em cache com base no dispositivo do usuário, consulte [Configurar o armazenamento em cache com base no tipo de dispositivo](header-caching.md#header-caching-web-device). | Sim, mas não recomendado |
| `Via` | O CloudFront encaminha o cabeçalho à origem. | Sim |
| `Warning` | O CloudFront encaminha o cabeçalho à origem. | Sim |
| `X-Amz-Cf-Id` | O CloudFront adiciona o cabeçalho à solicitação do visualizador antes de encaminhá-la à origem. O valor do cabeçalho contém uma string criptografada que identifica exclusivamente a solicitação. | Não |
| `X-Edge-*` | O CloudFront remove todos os cabeçalhos `X-Edge-*`. | Não |
| `X-Forwarded-For` | O CloudFront encaminha o cabeçalho à origem. Para obter mais informações, consulte [Endereços IP do cliente](#RequestCustomIPAddresses). | Sim |
| `X-Forwarded-Proto` | O CloudFront remove o cabeçalho. | Não |
| `X-HTTP-Method-Override` | O CloudFront remove o cabeçalho. | Sim |
| `X-Real-IP` | O CloudFront remove o cabeçalho. | Não |
### Versão HTTP
O CloudFront encaminha as solicitações à origem personalizada usando HTTP/1.1.
### Tamanho máximo de uma solicitação e de um URL
O tamanho máximo de uma solicitação, com o caminho, a query string (se houver) e os cabeçalhos, é de 20.480 bytes.
O CloudFront cria um URL com base na solicitação. O tamanho máximo do URL é de 8.192 bytes.
Se uma solicitação ou um URL ultrapassar esses limites máximos, o CloudFront retornará o código de status HTTP 413, Request Entity Too Large (Entidade de solicitação muito grande), ao visualizador e encerrará a conexão TCP com ele.
### Associação OCSP
Quando um visualizador envia uma solicitação HTTPS para um objeto, tanto ele quanto o CloudFront devem confirmar com a autoridade de certificação (CA) se o certificado SSL do domínio não foi revogado. O OCSP Stapling acelera a validação do certificado permitindo que o CloudFront valide o certificado e armazene as respostas da CA em cache, a fim de que o cliente não precise validar o certificado diretamente com a CA.
A melhoria da performance do OCSP Stapling é mais acentuada quando o CloudFront recebe inúmeras solicitações HTTPS para objetos no mesmo domínio. Cada servidor em um ponto de presença do CloudFront deve enviar uma solicitação de validação separada. Quando o CloudFront recebe um grande número de solicitações HTTPS para o mesmo domínio, cada servidor no ponto de presença logo recebe uma resposta da CA que pode "grampear" em um pacote no handshake SSL. Quando o visualizador acreditar que o certificado é válido, o CloudFront poderá fornecer o objeto solicitado. Caso sua distribuição não tenha muito tráfego em um ponto de presença do CloudFront, é provável que novas solicitações sejam direcionadas para um servidor que ainda não validou o certificado com a CA. Nesse caso, o visualizador executa separadamente a etapa de validação, e o servidor do CloudFront fornece o objeto. Esse servidor do CloudFront também envia uma solicitação de validação para a CA para que, na próxima vez que receber uma solicitação com o mesmo nome de domínio, tenha uma resposta de validação da CA.
### Conexões persistentes
Ao obter uma resposta da origem, o CloudFront tenta manter a conexão por alguns segundos caso chegue outra solicitação nesse período. A manutenção de uma conexão persistente economiza o tempo necessário para restabelecer a conexão TCP e executar outro handshake TLS para solicitações subsequentes.
Para obter mais informações, inclusive como configurar a duração de conexões persistentes, consulte [Tempo limite de keep alive (somente origens de VPC e personalizadas)](DownloadDistValuesOrigin.md#DownloadDistValuesOriginKeepaliveTimeout) na seção [Referência de configurações de todas as distribuições](distribution-web-values-specify.md).
### Protocolos
O CloudFront encaminha solicitações HTTP ou HTTPS ao servidor de origem levando em consideração:
+ O protocolo da solicitação enviada pelo visualizador ao CloudFront: HTTP ou HTTPS.
+ O valor do campo **Origin Protocol Policy (Política de protocolo da origem)** no console do CloudFront ou, se você estiver usando a API do CloudFront, o elemento `OriginProtocolPolicy` no tipo complexo `DistributionConfig`. No console do CloudFront, as opções são **HTTP Only (Somente HTTP)**, **HTTPS Only (Somente HTTPS)** e **Match Viewer (Corresponder visualizador)**.
Se você especificar **HTTP Only (Somente HTTP)** ou **HTTPS Only (Somente HTTPS)**, o CloudFront encaminhará as solicitações ao servidor de origem usando o protocolo especificado, independentemente do protocolo da solicitação do visualizador.
Se você especificar **Match Viewer (Corresponder visualizador)**, o CloudFront encaminhará as solicitações ao servidor de origem usando o protocolo da solicitação do visualizador. O CloudFront armazenará o objeto em cache somente uma vez se os visualizadores fizerem solicitações usando protocolos HTTP e HTTPS.
**Importante**
Se o CloudFront encaminhar uma solicitação à origem usando o protocolo HTTPS, e o servidor de origem retornar um certificado inválido ou autoassinado, o CloudFront interromperá a conexão TCP.
Para obter informações sobre como atualizar uma distribuição usando o console do CloudFront, consulte [Atualizar uma distribuição](HowToUpdateDistribution.md). Para obter informações sobre como atualizar uma distribuição usando a API do CloudFront, acesse [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html) na *Referência da API do Amazon CloudFront*.
### Strings de consulta
É possível configurar se o CloudFront encaminha parâmetros de query strings à origem. Para obter mais informações, consulte [Conteúdo em cache com base em parâmetros de string de consulta](QueryStringParameters.md).
### Tentativas e tempo limite de conexão da origem
*Tempo limite de conexão da origem* é o número de segundos que o CloudFront aguarda ao tentar estabelecer uma conexão com a origem.
*Tentativas de conexão da origem* é o número de vezes que o CloudFront tenta se conectar à origem.
Juntas, essas configurações determinam por quanto tempo o CloudFront tenta se conectar à origem antes de fazer o failover para a origem secundária, no caso de um grupo de origens, ou retornar uma resposta de erro ao visualizador. Por padrão, o CloudFront aguarda até 30 segundos (3 tentativas de 10 segundos cada) antes de tentar se conectar à origem secundária ou retornar uma resposta de erro. Esse tempo pode ser reduzido especificando um tempo limite de conexão mais curto, menos tentativas ou ambos.
Para obter mais informações, consulte [Controlar tempos limite e tentativas da origem](high_availability_origin_failover.md#controlling-attempts-and-timeouts).
### Tempo limite de resposta da origem
O *tempo limite de resposta da origem*, também conhecido como *tempo limite de leitura da origem* ou *tempo limite de solicitação da origem*, aplica-se a estes dois valores:
+ A quantidade de tempo, em segundos, que o CloudFront aguarda uma resposta após o encaminhamento de uma solicitação à origem.
+ A quantidade de tempo, em segundos, que o CloudFront aguarda após o recebimento de um pacote de resposta da origem e antes do recebimento do próximo pacote.
O comportamento do CloudFront depende do método HTTP da solicitação do visualizador:
+ Solicitações `GET` e `HEAD`: se a origem não responder ou parar de responder dentro da duração do tempo limite da resposta, o CloudFront interromperá a conexão. Se o número especificado de [tentativas de conexão da origem](DownloadDistValuesOrigin.md#origin-connection-attempts) for maior que 1, o CloudFront tentará obter uma resposta completa novamente. O CloudFront tenta até 3 vezes, conforme determinado pelo valor da configuração de *tentativas de conexão da origem*. Se a origem não responder durante a terceira tentativa, o CloudFront não tentará novamente enquanto não receber outra solicitação de conteúdo na mesma origem.
+ Solicitações `DELETE`, `OPTIONS`, `PATCH`, `PUT` e `POST`: se a origem não responder dentro da duração do tempo limite da leitura, o CloudFront interromperá a conexão e não tentará entrar em contato com a origem novamente. O cliente pode reenviar a solicitação, se necessário.
Para mais informações, inclusive como configurar o tempo limite de resposta da origem, consulte [Tempo limite de resposta](DownloadDistValuesOrigin.md#DownloadDistValuesOriginResponseTimeout).
### Solicitações simultâneas para o mesmo objeto (recolhimento de solicitações)
Quando um local da borda do CloudFront recebe uma solicitação de um objeto, e o objeto não está no cache ou o objeto em cache expirou, o CloudFront envia imediatamente a solicitação para a origem. No entanto, se houver solicitações simultâneas para o mesmo objeto, ou seja, se solicitações adicionais para o mesmo objeto (com a mesma chave de cache) chegarem ao local da borda antes de o CloudFront receber a resposta à primeira solicitação, o CloudFront fará uma pausa antes de encaminhar solicitações adicionais à origem. Essa breve pausa ajuda a reduzir a carga na origem. O CloudFront envia a resposta da solicitação original a todas as solicitações recebidas enquanto estava em pausa. Isso é chamado de *recolhimento de solicitações*. Nos logs do CloudFront, a primeira solicitação é identificada como `Miss` no campo `x-edge-result-type` e as solicitações recolhidas são identificadas como `Hit`. Para mais informações sobre os logs do CloudFront, consulte [Registro em log do CloudFront e de funções de borda](logging.md).
O CloudFront apenas recolhe solicitações que compartilham uma [*chave de cache*](understanding-the-cache-key.md). Se as solicitações adicionais não compartilharem a mesma chave de cache porque, por exemplo, você configurou o CloudFront para armazenar em cache com base nas strings de consulta, nos cookies ou nos cabeçalhos da solicitação, o CloudFront encaminhará todas as solicitações com uma chave de cache exclusiva à origem.
Se quiser evitar o recolhimento de todas as solicitações, será possível usar a política de cache gerenciada `CachingDisabled`, que também impede o armazenamento em cache. Para obter mais informações, consulte [Usar políticas de cache gerenciadas](using-managed-cache-policies.md).
Se você quiser evitar o recolhimento das solicitações para objetos específicos, defina a TTL mínima para o comportamento de cache como 0 *e* configure a origem para enviar `Cache-Control: private`, `Cache-Control: no-store`, `Cache-Control: no-cache`, `Cache-Control: max-age=0` ou `Cache-Control: s-maxage=0`. Essas configurações vão aumentar a carga na origem e introduzir latência adicional para as solicitações simultâneas que são pausadas enquanto o CloudFront aguarda a resposta à primeira solicitação.
**Importante**
Atualmente, o CloudFront não comporta recolher solicitações caso você habilite o encaminhamento de cookies na [política de cache](controlling-the-cache-key.md), na [política de solicitação de origem](controlling-origin-requests.md) ou nas configurações de cache herdadas.
### `User-Agent`Cabeçalho
Se você quiser que o CloudFront armazene diferentes versões dos objetos em cache com base no dispositivo usado pelo usuário para visualizar o conteúdo, recomendamos configurar o CloudFront para encaminhar um ou mais dos cabeçalhos à origem personalizada:
+ `CloudFront-Is-Desktop-Viewer`
+ `CloudFront-Is-Mobile-Viewer`
+ `CloudFront-Is-SmartTV-Viewer`
+ `CloudFront-Is-Tablet-Viewer`
Com base no valor do cabeçalho `User-Agent`, o CloudFront define o valor desses cabeçalhos como `true` ou `false` antes de encaminhar a solicitação para a origem. Se o dispositivo se encaixar em mais de uma categoria, mais de um valor poderá ser `true`. Por exemplo, para alguns tablets, o CloudFront pode definir tanto `CloudFront-Is-Mobile-Viewer` quanto `CloudFront-Is-Tablet-Viewer` como `true`. Para mais informações sobre como configurar o CloudFront para armazenar em cache com base nos cabeçalhos de solicitação, consulte [Conteúdo em cache com base nos cabeçalhos de solicitação](header-caching.md).
É possível configurar o CloudFront para armazenar os objetos em cache com base nos valores do cabeçalho `User-Agent`, mas não recomendamos fazer isso. Há vários valores possíveis para o cabeçalho `User-Agent`, e o armazenamento em cache com base nesses valores faz com que o CloudFront encaminhe significativamente mais solicitações à origem.
Se você não configurar o CloudFront para armazenar os objetos em cache com base nos valores do cabeçalho `User-Agent`, o CloudFront adicionará um cabeçalho `User-Agent` com o seguinte valor antes de encaminhar uma solicitação à origem:
`User-Agent = Amazon CloudFront`
O CloudFront adiciona esse cabeçalho, independentemente se a solicitação do visualizador inclui um cabeçalho `User-Agent` ou não. Se a solicitação do visualizador incluir um cabeçalho `User-Agent`, o CloudFront o removerá.
## Como o CloudFront processa respostas da sua origem personalizada
Saiba como o CloudFront processa respostas da origem personalizada.
**Contents**
+ [`100 Continue`Respostas](#Response100Continue)
+ [Armazenamento em cache](#ResponseCustomCaching)
+ [Solicitações canceladas](#response-custom-canceled-requests)
+ [Negociação de conteúdo](#ResponseCustomContentNegotiation)
+ [Cookies](#ResponseCustomCookies)
+ [Conexões TCP interrompidas](#ResponseCustomDroppedTCPConnections)
+ [Cabeçalhos de resposta HTTP que o CloudFront remove ou substitui](#ResponseCustomRemovedHeaders)
+ [Tamanho máximo do arquivo armazenável em cache](#ResponseCustomMaxFileSize)
+ [Origem indisponível](#ResponseCustomOriginUnavailable)
+ [Redirecionamentos](#ResponseCustomRedirects)
+ [`Transfer-Encoding`Cabeçalho](#ResponseCustomTransferEncoding)
### `100 Continue`Respostas
Não é possível que a origem envie mais de uma resposta 100-Continue ao CloudFront. Após a primeira resposta 100-Continue, o CloudFront espera uma resposta HTTP 200 OK. Se a origem enviar outra resposta 100-Continue após a primeira, o CloudFront retornará um erro.
### Armazenamento em cache
+ Certifique-se de que o servidor de origem defina valores válidos e precisos para os campos de cabeçalho `Date` e `Last-Modified`.
+ Normalmente, o CloudFront respeita um cabeçalho `Cache-Control: no-cache` na resposta da origem. Para ver uma exceção, consulte [Solicitações simultâneas para o mesmo objeto (recolhimento de solicitações)](#request-custom-traffic-spikes).
### Solicitações canceladas
Se o objeto não estiver no cache de ponto de presença e o visualizador encerrar a sessão (por exemplo, fechar o navegador) depois de o CloudFront obter o objeto da origem, mas antes de conseguir fornecer o objeto solicitado, ele não armazenará o objeto em cache no ponto de presença.
### Negociação de conteúdo
Se a origem retornar `Vary:*` na resposta e o valor de **Minimum TTL** do comportamento de cache correspondente for **0**, o CloudFront armazenará o objeto em cache, mas, mesmo assim, encaminhará todas as solicitações subsequentes do objeto à origem a fim de confirmar se o cache contém a versão mais recente do objeto. O CloudFront não inclui cabeçalhos condicionais, como `If-None-Match` ou `If-Modified-Since`. Consequentemente, a origem retorna o objeto ao CloudFront em resposta a cada solicitação.
Se a origem retornar `Vary:*` na resposta e o valor de **Minimum TTL** do comportamento de cache correspondente for qualquer outro valor, o CloudFront processará o cabeçalho `Vary` conforme descrito em [Cabeçalhos de resposta HTTP que o CloudFront remove ou substitui](#ResponseCustomRemovedHeaders).
### Cookies
Se você permitir cookies para um comportamento de cache e a origem retornar cookies com um objeto, o CloudFront armazenará tanto o objeto quanto os cookies em cache. Observe que isso reduz a capacidade de armazenamento em cache de um objeto. Para obter mais informações, consulte [Conteúdo em cache com base em cookies](Cookies.md).
### Conexões TCP interrompidas
Se a conexão TCP entre o CloudFront e a origem cair enquanto a origem estiver retornando um objeto ao CloudFront, o comportamento do CloudFront dependerá da inclusão ou não de um cabeçalho `Content-Length` na resposta pela origem:
+ **Cabeçalho Content-Length**: o CloudFront retorna o objeto ao visualizador assim que o obtém da origem. No entanto, se o valor do cabeçalho `Content-Length` não corresponder ao tamanho do objeto, o CloudFront não o armazenará em cache.
+ **Transfer-Encoding: Chunked**: o CloudFront retorna o objeto ao visualizador assim que o obtém da origem. No entanto, se a resposta em partes não for concluída, o CloudFront não armazenará o objeto em cache.
+ **Sem cabeçalho Content-Length**: o CloudFront retorna o objeto ao visualizador e o armazena em cache, mas o objeto não pode ser concluído. Sem um cabeçalho `Content-Length`, o CloudFront não consegue determinar se a conexão TCP foi interrompida de forma acidental ou proposicional.
Recomendamos que você configure o servidor HTTP para adicionar um cabeçalho `Content-Length` a fim de impedir que o CloudFront armazene objetos parciais em cache.
### Cabeçalhos de resposta HTTP que o CloudFront remove ou substitui
O CloudFront remove ou atualiza os seguintes campos de cabeçalho antes de encaminhar a resposta da origem ao visualizador:
+ `Set-Cookie`: se você configurar o CloudFront para encaminhar cookies, ele encaminhará o campo de cabeçalho `Set-Cookie` aos clientes. Para obter mais informações, consulte [Conteúdo em cache com base em cookies](Cookies.md).
+ `Trailer`
+ `Transfer-Encoding`: se a origem retornar esse campo de cabeçalho, o CloudFront definirá o valor de `chunked` antes de retornar a resposta ao visualizador.
+ `Upgrade`
+ `Vary` – Observe o seguinte:
+ Se você configurar o CloudFront para encaminhar os cabeçalhos específicos do dispositivo à origem (`CloudFront-Is-Desktop-Viewer`, `CloudFront-Is-Mobile-Viewer`, `CloudFront-Is-SmartTV-Viewer`, `CloudFront-Is-Tablet-Viewer`) e a origem para retornar `Vary:User-Agent` ao CloudFront, o CloudFront retornará `Vary:User-Agent` ao visualizador. Para obter mais informações, consulte [Configurar o armazenamento em cache com base no tipo de dispositivo](header-caching.md#header-caching-web-device).
+ Se você configurar a origem para incluir `Accept-Encoding` ou `Cookie` no cabeçalho `Vary`, o CloudFront incluirá os valores na resposta ao visualizador.
+ Se você configurar o CloudFront para encaminhar cabeçalhos à origem e configurar a origem para retornar os nomes de cabeçalho ao CloudFront no cabeçalho `Vary` (por exemplo, `Vary:Accept-Charset,Accept-Language`), o CloudFront retornará o cabeçalho `Vary` com esses valores ao visualizador.
+ Para obter informações sobre como o CloudFront processa um valor de `*` no cabeçalho `Vary`, consulte [Negociação de conteúdo](#ResponseCustomContentNegotiation).
+ Se você configurar a origem para incluir qualquer outro valor no cabeçalho `Vary`, o CloudFront removerá os valores antes de retornar a resposta ao visualizador.
+ `Via`: o CloudFront define o seguinte valor na resposta para o visualizador:
`Via: `*versão HTTP* *string alfanumérica*`.cloudfront.net (CloudFront)`
Por exemplo, o valor é semelhante ao seguinte:
`Via: 1.1 1026589cc7887e7a0dc7827b4example.cloudfront.net (CloudFront)`
### Tamanho máximo do arquivo armazenável em cache
O tamanho máximo do corpo de uma resposta salva pelo CloudFront no cache é de 50 GB. Isso inclui respostas de transferência em partes que não especificam o valor de cabeçalho `Content-Length`.
É possível usar o CloudFront para armazenar em cache um objeto maior que isso usando solicitações de intervalo para solicitar os objetos em partes que sejam cada uma de 50 GB ou menores. O CloudFront armazena essas partes em cache porque cada uma delas é de 50 GB ou menor. Depois que o visualizador recuperar todas as partes do objeto, ele poderá reconstruir o objeto original, maior. Para obter mais informações, consulte [Usar solicitações de intervalo para armazenar objetos grandes em cache](RangeGETs.md#cache-large-objects-with-range-requests).
### Origem indisponível
Se o servidor de origem estiver indisponível e o CloudFront receber uma solicitação de um objeto que está no cache do ponto de presença, mas expirou (por exemplo, porque o período especificado na diretiva `Cache-Control max-age` passou), o CloudFront fornecerá a versão expirada do objeto ou uma página de erro personalizada. Para mais informações sobre o comportamento do CloudFront ao configurar páginas de erro personalizadas, consulte [Como o CloudFront processará erros quando páginas de erro personalizadas estiverem configuradas](HTTPStatusCodes.md#HTTPStatusCodes-custom-error-pages).
Em alguns casos, um objeto que é raramente solicitado é removido e se torna indisponível no ponto de presença de caches. O CloudFront não pode fornecer um objeto que foi removido.
### Redirecionamentos
Se você alterar a localização de um objeto no servidor de origem, poderá configurar o servidor da Web para redirecionar as solicitações para o novo local. Depois de configurar o redirecionamento, a primeira vez que um visualizador enviar uma solicitação para o objeto, o CloudFront a enviará à origem, e a origem responderá com um redirecionamento (por exemplo, `302 Moved Temporarily`). O CloudFront armazena o redirecionamento em cache e o retorna ao visualizador. O CloudFront não acompanha o redirecionamento.
Você pode configurar o servidor da web para redirecionar as solicitações para um destes locais:
+ O novo URL do objeto no servidor de origem. Ao seguir o redirecionamento para o novo URL, o visualizador ignora o CloudFront e vai diretamente à origem. Por isso, recomendamos que você não redirecione as solicitações para o novo URL do objeto na origem.
+ O novo URL do CloudFront do objeto. Quando o visualizador envia a solicitação que contém o novo URL do CloudFront, o CloudFront obtém o objeto do novo local na origem, armazena-o em cache no ponto de presença e retorna-o ao visualizador. As solicitações subsequentes do objeto são fornecidas pelo ponto de presença. Isso evita a latência e a carga associadas à solicitação do objeto pelo visualizador da origem. No entanto, cada nova solicitação do objeto será cobrada por duas solicitações ao CloudFront.
### `Transfer-Encoding`Cabeçalho
O CloudFront é compatível apenas com o valor `chunked` do cabeçalho `Transfer-Encoding`. Se a origem retornar `Transfer-Encoding: chunked`, o CloudFront retornará o objeto ao cliente assim que for recebido no ponto de presença e o armazenará em partes para solicitações subsequentes.
Se o visualizador fizer uma solicitação `Range GET` e a origem retornar `Transfer-Encoding: chunked`, o CloudFront retornará o objeto inteiro ao visualizador, em vez do intervalo solicitado.
Recomendamos que você use codificação em partes se o tamanho do conteúdo da sua resposta não puder ser predeterminado. Para obter mais informações, consulte [Conexões TCP interrompidas](#ResponseCustomDroppedTCPConnections).
# Comportamento de solicitações e respostas para grupos de origens
As solicitações a um grupo de origens funcionarão da mesma forma que as solicitações a uma origem que não esteja configurada como um grupo de origens, exceto quando houver um failover da origem. Assim como ocorre com qualquer outra origem, quando o CloudFront recebe uma solicitação, e o conteúdo já está armazenado em cache em um ponto de presença, o conteúdo é fornecido aos visualizadores do cache. Quando há uma falha de cache e a origem é um grupo de origens, as solicitações do visualizador são encaminhadas para a origem primária no grupo de origens.
O comportamento da solicitação e da resposta para a origem primária é o mesmo de uma origem que não esteja incluída em um grupo de origens. Para obter mais informações, consulte [Comportamento de solicitações e respostas para origens do Amazon S3](RequestAndResponseBehaviorS3Origin.md) e [Comportamento de solicitações e respostas para origens personalizadas](RequestAndResponseBehaviorCustomOrigin.md).
A tabela a seguir descreve o comportamento para origem de failover quando a origem primária retorna códigos de status HTTP específicos:
+ Código de status HTTP 2xx (êxito): o CloudFront armazena o arquivo e o retorna ao visualizador.
+ Código de status HTTP 3xx (redirecionamento): o CloudFront retorna o código de status ao visualizador.
+ Código de status HTTP 4xx ou 5xx (erro de cliente/servidor): se o código de status retornado foi configurado para failover, o CloudFront envia a mesma solicitação à origem secundária no grupo de origens.
+ Código de status HTTP 4xx ou 5xx (erro de cliente/servidor): se o código de status retornado não foi configurado para failover, o CloudFront retornará o erro ao visualizador.
O CloudFront faz failover para a origem secundária somente quando o método HTTP da solicitação do visualizador for `GET`, `HEAD` ou `OPTIONS`. O CloudFront não faz failover quando o visualizador envia um método HTTP diferente (por exemplo `POST`, `PUT` etc.).
Quando o CloudFront envia uma solicitação a uma origem secundária, o comportamento de resposta é o mesmo que para uma origem do CloudFront que não esteja em um grupo de origens.
Para mais informações sobre grupos de origens, consulte [Otimizar a alta disponibilidade com o failover de origem do CloudFront](high_availability_origin_failover.md).
# Adicionar cabeçalhos personalizados às solicitações de origem
Você pode configurar o CloudFront para adicionar cabeçalhos personalizados às solicitações que ele envia à sua origem. É possível usar cabeçalhos personalizados para enviar e reunir informações da origem que você não recebe com solicitações regulares do visualizador. É possível até mesmo personalizar os cabeçalhos para cada origem. O CloudFront comporta cabeçalhos personalizados para origens personalizadas e origens do Amazon S3.
**Contents**
+ [Casos de uso](#add-origin-custom-headers-use-cases)
+ [Configurar o CloudFront para adicionar cabeçalhos personalizados às solicitações de origem](#add-origin-custom-headers-configure)
+ [Cabeçalhos personalizados que o CloudFront não pode adicionar às solicitações da origem](#add-origin-custom-headers-denylist)
+ [Configurar o CloudFront para encaminhar o cabeçalho `Authorization`](#add-origin-custom-headers-forward-authorization)
## Casos de uso
É possível usar cabeçalhos personalizados, como nos seguintes exemplos:
**Identificar solicitações do CloudFront**
Você pode identificar as solicitações que a origem recebe do CloudFront. Isso poderá ser útil se você quiser saber se os usuários estão ignorando o CloudFront ou se você estiver usando mais de uma CDN e quiser obter informações sobre quais solicitações são provenientes de cada CDN.
Se estiver usando uma origem do Amazon S3 e habilitar o [Registro em log de acesso do servidor do Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/dev/ServerLogs.html), os logs não incluirão as informações de cabeçalho.
**Determinar quais solicitações vêm de uma distribuição específica**
Se você configurar mais de uma distribuição do CloudFront para usar a mesma origem, poderá adicionar cabeçalhos personalizados diferentes em cada distribuição. Depois, você poderá usar os logs da origem para determinar quais solicitações vieram de qual distribuição do CloudFront.
**Habilitar o compartilhamento de recursos de origem cruzada (CORS)**
Se alguns dos visualizadores não forem compatíveis com o compartilhamento de recursos de origem cruzada (CORS), você poderá configurar o CloudFront para sempre adicionar o cabeçalho da `Origin` às solicitações que ele enviar à sua origem. Depois, você poderá configurar sua origem para retornar o cabeçalho `Access-Control-Allow-Origin` para cada solicitação. Você também deve [configurar o CloudFront para respeitar as configurações do CORS](header-caching.md#header-caching-web-cors).
**Controlar o acesso ao conteúdo**
Você pode usar cabeçalhos personalizados para controlar o acesso ao conteúdo. Ao configurar a origem para responder às solicitações somente quando elas incluírem um cabeçalho personalizado que é adicionado pelo CloudFront, você evita que os usuários ignorem o CloudFront e acessem o conteúdo diretamente na origem. Para obter mais informações, consulte [Restringir o acesso a arquivos em origens personalizadas](private-content-overview.md#forward-custom-headers-restrict-access).
## Configurar o CloudFront para adicionar cabeçalhos personalizados às solicitações de origem
A fim de configurar uma distribuição para adicionar cabeçalhos personalizados às solicitações que ela enviar à sua origem, atualize a configuração da origem usando um dos seguintes métodos:
+ **Console do CloudFront**: ao criar ou atualizar uma distribuição, especifique nomes e valores de cabeçalho nas configurações **Adicionar cabeçalhos personalizados**. Para obter mais informações, consulte [Adicionar cabeçalho personalizado](DownloadDistValuesOrigin.md#DownloadDistValuesOriginCustomHeaders).
+ **API do CloudFront **: para cada origem à qual você deseja adicionar cabeçalhos personalizados, especifique os nomes e os valores dos cabeçalhos no campo `CustomHeaders` em `Origin`. Para ter mais informações, consulte [CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html) ou [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html) na *Referência da API do Amazon CloudFront*.
Se os nomes e os valores dos cabeçalhos especificados ainda não estiverem na solicitação do visualizador, o CloudFront os adicionará à solicitação da origem. Se houver um cabeçalho presente, o CloudFront substituirá o valor antes de encaminhar a solicitação para a origem.
Para ver as cotas que se aplicam aos cabeçalhos personalizados de origem, consulte [Cotas para cabeçalhos](cloudfront-limits.md#limits-custom-headers).
## Cabeçalhos personalizados que o CloudFront não pode adicionar às solicitações da origem
Não é possível configurar o CloudFront para adicionar um dos seguintes cabeçalhos às solicitações que ele envia à origem:
+ `Cache-Control`
+ `Connection`
+ `Content-Length`
+ `Cookie`
+ `Host`
+ `If-Match`
+ `If-Modified-Since`
+ `If-None-Match`
+ `If-Range`
+ `If-Unmodified-Since`
+ `Max-Forwards`
+ `Pragma`
+ `Proxy-Authenticate`
+ `Proxy-Authorization`
+ `Proxy-Connection`
+ `Range`
+ `Request-Range`
+ `TE`
+ `Trailer`
+ `Transfer-Encoding`
+ `Upgrade`
+ `Via`
+ Cabeçalhos que começam com `X-Amz-`
+ Cabeçalhos que começam com `X-Edge-`
+ `X-Real-Ip`
## Configurar o CloudFront para encaminhar o cabeçalho `Authorization`
Quando o CloudFront encaminha uma solicitação de visualizador para sua origem, o CloudFront remove alguns cabeçalhos de visualizador por padrão, incluindo o `Authorization` cabeçalho. Para garantir que sua origem sempre receba o `Authorization` cabeçalho em solicitações de origem, você tem as seguintes opções:
+ Adicione o `Authorization` cabeçalho à chave de cache usando uma política de cache. Todos os cabeçalhos na chave de cache são automaticamente incluídos nas solicitações de origem. Para obter mais informações, consulte [Controlar a chave de cache com uma política](controlling-the-cache-key.md).
+ Use uma política de solicitação de origem que encaminha todos os cabeçalhos do visualizador para a origem. Você não pode encaminhar o `Authorization` cabeçalho individualmente em uma política de solicitação de origem, mas ao encaminhar todos os cabeçalhos do visualizador, o CloudFront inclui o `Authorization` cabeçalho nas solicitações do visualizador. O CloudFront fornece uma política de solicitação de origem gerenciada para esse caso de uso, chamada **Managed-AllViewer**. Para obter mais informações, consulte [Usar políticas de solicitação de origem gerenciadas](using-managed-origin-request-policies.md).
# Como o CloudFront processa solicitações parciais de um objeto (Range GETs)
Para um objeto grande, o visualizador (navegador ou outro cliente) pode fazer várias solicitações `GET` e usar o cabeçalho de solicitação `Range` para baixar o objeto em partes menores. Essas solicitações de intervalos de bytes, também conhecidas como solicitações `Range GET`, melhoram a eficiência de downloads parciais e a recuperação de transferências parciais com falha.
Ao receber uma solicitação `Range GET`, o CloudFront verifica o cache no local de borda que recebeu a solicitação. Se o cache desse ponto de presença já contiver todo o objeto ou a parte solicitada dele, o CloudFront fornecerá imediatamente o intervalo solicitado do cache.
Se o cache não contiver o intervalo solicitado, o CloudFront encaminhará a solicitação à origem. (Para otimizar a performance, o CloudFront pode solicitar um intervalo maior que o solicitado pelo cliente em `Range GET`.) O que acontece em seguida depende se a origem é compatível ou não com solicitações `Range GET`:
+ **Se a origem for compatível com solicitações `Range GET`**: ele exibirá o intervalo solicitado. O CloudFront fornece o intervalo solicitado e o armazena em cache para futuras solicitações. (O Amazon S3 oferece suporte a solicitações `Range GET`, assim como muitos servidores HTTP.)
+ **Se a origem não for compatível com solicitações `Range GET`**: ele exibirá todo o objeto. O CloudFront atende à solicitação atual enviando o objeto inteiro enquanto também o armazena em cache para solicitações futuras. Depois de armazenar o objeto inteiro em cache em um cache de ponto de presença, o CloudFront responde a novas solicitações `Range GET` fornecendo o intervalo solicitado.
Nos dois casos, o CloudFront começa a fornecer o intervalo ou o objeto solicitado ao usuário final assim que o primeiro byte chega da origem.
**nota**
Se o visualizador fizer uma solicitação `Range GET` e a origem retornar `Transfer-Encoding: chunked`, o CloudFront retornará o objeto inteiro ao visualizador, em vez do intervalo solicitado.
Normalmente, o CloudFront segue a especificação RFC do cabeçalho `Range`. No entanto, se os cabeçalhos `Range` não seguirem os seguintes requisitos, o CloudFront retornará o código de status `200` com todo o objeto, em vez do código de status `206` com os intervalos especificados:
+ Os intervalos devem estar indicados em ordem crescente. Por exemplo, `100-200,300-400` é válido; `300-400,100-200` não é válido.
+ Os intervalos não devem se sobrepor. Por exemplo, `100-200,150-250` não é válido.
+ Todas as especificações dos intervalos devem ser válidas. Por exemplo, você não pode especificar um valor negativo como parte de um intervalo.
Para obter mais informações sobre o cabeçalho de solicitação `Range`, consulte [Solicitações de intervalo](https://httpwg.org/specs/rfc7233.html#range.requests) na RFC 7233, ou [Intervalo](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Range) no MDN Web Docs.
## Usar solicitações de intervalo para armazenar objetos grandes em cache
Quando o armazenamento em cache está ativado, o CloudFront não recupera nem armazena em cache um objeto maior que 50 GB. Quando uma origem indica que o objeto é maior que isso (no cabeçalho de resposta `Content-Length`), o CloudFront fecha a conexão com a origem e exibe um erro ao visualizador. (Com o armazenamento em cache desativado, o CloudFront pode recuperar um objeto maior que isso da origem e passá-lo para o visualizador. No entanto, o CloudFront não armazena o objeto em cache.)
No entanto, com solicitações de intervalo, é possível usar o CloudFront para armazenar em cache um objeto maior que o [tamanho máximo de arquivo armazenável em cache](cloudfront-limits.md#limits-web-distributions).
**Example Exemplo**
1. Pense em uma origem com um objeto de 100 GB. Com o armazenamento em cache habilitado, o CloudFront não recupera nem armazena em cache um objeto desse tamanho. No entanto, o visualizador pode enviar várias solicitações de intervalo para recuperar esse objeto em partes, sendo cada uma menor que 50 GB.
1. O visualizador pode solicitar o objeto em partes de 20 GB enviando uma solicitação com o cabeçalho `Range: bytes=0-21474836480` para recuperar a primeira parte, outra solicitação com o cabeçalho `Range: bytes=21474836481-42949672960` para recuperar a próxima parte, e assim por diante.
1. Quando o visualizador tiver recebido todas as partes, ele pode combiná-las para construir o objeto original de 100 GB.
1. Nesse caso, o CloudFront armazena em cache cada uma das partes de 20 GB do objeto e pode responder a solicitações subsequentes para a mesma parte do cache.
Para uma solicitação de intervalo para um objeto compactado, a solicitação de intervalo de bytes é baseada no tamanho compactado e não no tamanho original do objeto. Consulte mais informações sobre compactação de arquivos em [Fornecer arquivos compactados](ServingCompressedFiles.md).
# Como o CloudFront processa códigos de status HTTP 3xx da origem
Quando o CloudFront solicita um objeto do bucket do Amazon S3 ou de um servidor de origem personalizado, a origem às vezes retorna um código de status HTTP 3xx. Isso normalmente indica uma das seguintes situações:
+ O URL do objeto foi alterado (por exemplo, códigos de status 301, 302, 307 ou 308)
+ O objeto não foi alterado desde a última vez que o CloudFront o solicitou (código de status 304)
O CloudFront armazena em cache as respostas 3xx de acordo com as configurações na distribuição do CloudFront e os cabeçalhos na resposta. O CloudFront armazena 307 e 308 respostas em cache somente quando você inclui o cabeçalho `Cache-Control` nas respostas da origem. Para obter mais informações, consulte [Gerenciar o tempo de permanência do conteúdo no cache (expiração)](Expiration.md).
Se a origem retornar um código de status de redirecionamento (por exemplo, 301 ou 307), o CloudFront não acompanhará o redirecionamento. O CloudFront transmite a resposta 301 ou 307 ao visualizador, que pode acompanhar o redirecionamento enviando uma nova solicitação.
# Como o CloudFront processa códigos de status HTTP 4xx e 5xx da origem
Quando o CloudFront solicita um objeto do bucket do Amazon S3 ou servidor de origem personalizada, a origem pode retornar um código de status HTTP 4xx ou 5xx, que indica um erro. O comportamento do CloudFront depende do seguinte:
+ Se você configurou páginas de erro personalizadas
+ Se você configurou o tempo que o CloudFront armazenará em cache as respostas a erros da origem (TTL mínima de armazenamento de erros em cache).
+ O código do status
+ Em relação a códigos de status 5xx, se o objeto solicitado estiver no cache de borda do CloudFront.
+ Para alguns códigos de status 4xx, se a origem exibir um cabeçalho `Cache-Control max-age` ou `Cache-Control s-maxage`
O CloudFront sempre armazena respostas às solicitações `GET` e `HEAD` em cache. Também é possível configurar o CloudFront para armazenar respostas a solicitações `OPTIONS` em cache. O CloudFront não armazena em cache respostas a solicitações que usam outros métodos.
Se a origem não responder, a solicitação do CloudFront à origem expirará, o que é considerado um erro HTTP 5xx da origem, mesmo que a origem não tenha respondido com esse erro. Nessa situação, o CloudFront continua fornecendo conteúdo armazenado em cache. Para obter mais informações, consulte [Origem indisponível](RequestAndResponseBehaviorCustomOrigin.md#ResponseCustomOriginUnavailable).
Se você ativou o registro em log, o CloudFront gravará os resultados nos logs, independentemente do código de status HTTP.
Para mais informações sobre os recursos e as opções relacionadas à mensagem de erro retornada pelo CloudFront, consulte o seguinte:
+ Para obter informações sobre as configurações de páginas de erro personalizadas no console do CloudFront, consulte [Páginas de erro personalizadas e erro de armazenamento em cache](DownloadDistValuesErrorPages.md).
+ Para mais informações sobre o TTL mínimo de armazenamento de erros em cache no console do CloudFront, consulte [Erro ao armazenar TTL mínimo em cache (segundos)](DownloadDistValuesErrorPages.md#DownloadDistValuesErrorCachingMinTTL).
+ Para consultar uma lista de códigos de status HTTP armazenados em cache pelo CloudFront, consulte [Códigos de status HTTP 4xx e 5xx armazenados em cache pelo CloudFront](#HTTPStatusCodes-cached-errors).
**Topics**
+ [Como o CloudFront processará erros quando páginas de erro personalizadas estiverem configuradas](#HTTPStatusCodes-custom-error-pages)
+ [Como o CloudFront processará erros se você não tiver configurado páginas de erro personalizadas](#HTTPStatusCodes-no-custom-error-pages)
+ [Códigos de status HTTP 4xx e 5xx armazenados em cache pelo CloudFront](#HTTPStatusCodes-cached-errors)
## Como o CloudFront processará erros quando páginas de erro personalizadas estiverem configuradas
Se você configurou páginas de erro personalizadas, o comportamento do CloudFront será determinado de acordo com o objeto solicitado estar ou não no cache de ponto de presença.
### O objeto solicitado não está no cache de borda
O CloudFront continuará tentando obter o objeto solicitado da origem quando todas estas opções forem verdadeiras:
+ Um visualizador solicita um objeto.
+ O objeto não está no ponto de presença de caches
+ Sua origem retorna um código de status HTTP 4xx ou 5xx e uma das seguintes situações é verdadeira:
+ A origem retorna um código de status HTTP 5xx, em vez de retornar um código de status 304 (Não modificado) ou uma versão atualizada do objeto
+ A origem retorna um código de status HTTP 4xx que não é restrito por um cabeçalho de controle de cache e é incluído na seguinte lista de códigos de status: [Códigos de status HTTP 4xx e 5xx armazenados em cache pelo CloudFront](#HTTPStatusCodes-cached-errors).
+ A origem exibe um código de status HTTP 4xx com um cabeçalho `Cache-Control max-age` ou `Cache-Control s-maxage` e o código de status é incluído na seguinte lista de códigos de status: Control [Códigos de status HTTP 4xx que o CloudFront armazena em cache com base em cabeçalhos de `Cache-Control`](#HTTPStatusCodes-cached-errors-with-cache-control).
**O CloudFront faz o seguinte:**
1. No cache de ponto de presença do CloudFront que recebeu a solicitação do visualizador, o CloudFront verifica a configuração da distribuição e obtém o caminho da página de erro personalizada correspondente ao código de status retornado pela origem.
1. O CloudFront encontra o primeiro comportamento de cache na distribuição que tem um padrão de caminho correspondente ao caminho da página de erro personalizada.
1. O ponto de presença do CloudFront envia uma solicitação da página de erro personalizada à origem especificada no comportamento de cache.
1. A origem retorna a página de erro personalizada para o ponto de presença.
1. O CloudFront retorna a página de erro personalizada ao visualizador que fez a solicitação e a armazena em cache por no máximo:
+ A quantidade de tempo especificada pelo TTL mínimo de armazenamento de erros em cache (10 segundos, por padrão)
+ A quantidade de tempo especificada por um cabeçalho `Cache-Control max-age` ou `Cache-Control s-maxage` retornado pela origem quando a primeira solicitação gerou o erro.
1. Após o término do tempo de armazenamento em cache (determinado na Etapa 5), o CloudFront tentará obter o objeto solicitado novamente encaminhando outra solicitação à origem. O CloudFront continua tentando em intervalos especificados pelo TTL mínimo de armazenamento de erros em cache.
**nota**
Se você também configurou um comportamento de cache para a mesma página de erro personalizada, o CloudFront usará o TTL do comportamento de cache em vez disso. Nesse caso, o CloudFront realizará o seguinte nas etapas 5 e 6:
Depois de exibir a página de erro personalizada ao visualizador que fez a solicitação, o CloudFront verifica o TTL do comportamento de cache (por exemplo, você definiu o TTL padrão como 5 segundos). Em seguida, o CloudFront armazena em cache a página de erro personalizada até esse limite máximo.
Após 5 segundos, o CloudFront busca novamente a página de erro personalizada da origem. O CloudFront continuará tentando em intervalos especificados pelo TTL do comportamento de cache.
Para ter mais informações, consulte as [configurações de TTL](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMinTTL) de comportamento de cache.
### O objeto solicitado está no cache de borda
O CloudFront continuará fornecendo o objeto que está no cache de ponto de presença quando todas estas opções forem verdadeiras:
+ Um visualizador solicita um objeto.
+ O objeto está no cache do ponto de presença, mas expirou
+ A origem retorna um código de status HTTP 5xx, em vez de retornar um código de status 304 (Não modificado) ou uma versão atualizada do objeto
**O CloudFront faz o seguinte:**
1. Se a origem retornar um código de status 5xx, o CloudFront fornecerá o objeto mesmo se ele tiver expirado. Pela duração do TTL mínimo de armazenamento de erros em cache, o CloudFront continuará respondendo a solicitações do visualizador fornecendo o objeto do cache do ponto de presença.
Se a origem retornar um código de status 4xx, o CloudFront retornará o código de status ao visualizador, não o objeto solicitado.
1. Após o término desse TTL mínimo, o CloudFront tentará obter o objeto solicitado novamente encaminhando outra solicitação para a origem. Observe que, se o objeto não for solicitado com frequência, o CloudFront poderá removê-lo do cache do ponto de presença enquanto o servidor de origem ainda estiver retornando respostas 5xx. Para obter informações sobre o tempo de permanência de objetos de caches de ponto de presença do CloudFront, consulte [Gerenciar o tempo de permanência do conteúdo no cache (expiração)](Expiration.md).
## Como o CloudFront processará erros se você não tiver configurado páginas de erro personalizadas
Se você não tiver configurado páginas de erro personalizadas, o comportamento do CloudFront será determinado de acordo com o objeto solicitado estar ou não no cache da borda.
**Topics**
+ [O objeto solicitado não está no cache de borda](#HTTPStatusCodes-no-custom-error-pages-not-in-cache)
+ [O objeto solicitado está no cache de borda](#HTTPStatusCodes-no-custom-error-pages-in-cache)
### O objeto solicitado não está no cache de borda
O CloudFront continuará tentando obter o objeto solicitado da origem quando todas estas opções forem verdadeiras:
+ Um visualizador solicita um objeto.
+ O objeto não está no ponto de presença de caches
+ Sua origem retorna um código de status HTTP 4xx ou 5xx e uma das seguintes situações é verdadeira:
+ A origem retorna um código de status HTTP 5xx, em vez de retornar um código de status 304 (Não modificado) ou uma versão atualizada do objeto
+ A origem retorna um código de status HTTP 4xx que não é restrito por um cabeçalho de controle de cache e é incluído na seguinte lista de códigos de status: [Códigos de status HTTP 4xx e 5xx armazenados em cache pelo CloudFront](#HTTPStatusCodes-cached-errors)
+ A origem exibe um código de status HTTP 4xx com um cabeçalho `Cache-Control max-age` ou `Cache-Control s-maxage` e o código de status é incluído na seguinte lista de códigos de status: Control [Códigos de status HTTP 4xx que o CloudFront armazena em cache com base em cabeçalhos de `Cache-Control`](#HTTPStatusCodes-cached-errors-with-cache-control).
O CloudFront faz o seguinte:
1. O CloudFront retorna o código de status 4xx ou 5xx ao visualizador e também armazena o código de status no cache do ponto de presença que recebeu a solicitação por no máximo:
+ A quantidade de tempo especificada pelo TTL mínimo de armazenamento de erros em cache (10 segundos, por padrão)
+ A quantidade de tempo especificada por um cabeçalho `Cache-Control max-age` ou `Cache-Control s-maxage` retornado pela origem quando a primeira solicitação gerou o erro.
1. Durante o tempo de armazenamento em cache (determinado na etapa 1), o CloudFront responderá a solicitações subsequentes do visualizador do mesmo objeto com o código de status 4xx ou 5xx armazenado em cache.
1. Após o término do tempo de armazenamento em cache (determinado na Etapa 1), o CloudFront tentará obter o objeto solicitado novamente encaminhando outra solicitação à origem. O CloudFront continua tentando em intervalos especificados pelo TTL mínimo de armazenamento de erros em cache.
### O objeto solicitado está no cache de borda
O CloudFront continuará fornecendo o objeto que está no cache de ponto de presença quando todas estas opções forem verdadeiras:
+ Um visualizador solicita um objeto.
+ O objeto está no cache do ponto de presença, mas expirou Isso significa que o objeto está *obsoleto*.
+ A origem retorna um código de status HTTP 5xx, em vez de retornar um código de status 304 (Não modificado) ou uma versão atualizada do objeto
O CloudFront faz o seguinte:
1. Se a origem retornar um código de erro 5xx, o CloudFront fornecerá o objeto mesmo se ele tiver expirado. Pela duração do TTL mínimo de armazenamento de erros em cache (10 segundos, por padrão), o CloudFront continua respondendo a solicitações do visualizador fornecendo o objeto do cache de ponto de presença.
Se a origem retornar um código de status 4xx, o CloudFront retornará o código de status ao visualizador, não o objeto solicitado.
1. Após o término desse TTL mínimo, o CloudFront tentará obter o objeto solicitado novamente encaminhando outra solicitação para a origem. Se o objeto não for solicitado com frequência, o CloudFront poderá removê-lo do cache da borda enquanto o servidor de origem ainda estiver retornando respostas 5xx. Para obter mais informações, consulte [Gerenciar o tempo de permanência do conteúdo no cache (expiração)](Expiration.md).
**dica**
Se você configurar a diretiva `stale-if-error` ou `Stale-While-Revalidate`, poderá especificar por quanto tempo os objetos obsoletos estarão disponíveis no cache da borda. Isso permite que você continue fornecendo conteúdo para os visualizadores mesmo quando a origem não estiver disponível. Para mais informações, consulte [Fornecer conteúdo obsoleto (expirado)](Expiration.md#stale-content).
O CloudFront fornecerá somente um objeto que esteja obsoleto até o valor [máximo de TTL](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMaxTTL) especificado. Após essa duração, o objeto não estará disponível no cache da borda.
## Códigos de status HTTP 4xx e 5xx armazenados em cache pelo CloudFront
O CloudFront armazena em cache os códigos de status HTTP 4xx e 5xx retornados pela origem, dependendo do código de status específico que é retornado e se a origem retorna cabeçalhos específicos na resposta.
O CloudFront armazena em cache os códigos de status HTTP 4xx e 5xx a seguir que são exibidos pela origem. Se você configurou uma página de erro personalizada para um código de status HTTP, o CloudFront a armazenará em cache.
**nota**
Se você estiver usando a política de cache gerenciada [CachingDisabled](using-managed-cache-policies.md#managed-cache-policy-caching-disabled), o CloudFront não armazenará esses códigos de status nem páginas de erro personalizadas.
| | |
| --- |--- |
| 404 | Não encontrado |
| 414 | URI da solicitação muito grande |
| 500 | Internal Server Error |
| 501 | Não implementado |
| 502 | Gateway inválido |
| 503 | Serviço indisponível |
| 504 | Tempo limite do gateway |
### Códigos de status HTTP 4xx que o CloudFront armazena em cache com base em cabeçalhos de `Cache-Control`
O CloudFront apenas armazena os seguintes códigos de status HTTP 4xx retornados pela origem se a origem retornar um cabeçalho `Cache-Control max-age` ou `Cache-Control s-maxage`. Se você configurou uma página de erro personalizada para um dos códigos de status HTTP a seguir, e a origem exibir um dos cabeçalhos de controle de cache, o CloudFront a armazenará em cache.
| | |
| --- |--- |
| 400 | Solicitação inválida |
| 403 | Proibido |
| 405 | Método não permitido |
| 412¹ | Falha na pré-condição |
| 415¹ | Tipo de mídia incompatível |
¹ O CloudFront não é compatível com a criação de páginas de erro personalizadas para esses códigos de status HTTP.
# Gerar respostas a erros personalizadas
Se um objeto fornecido pelo CloudFront estiver indisponível por algum motivo, seu servidor web normalmente retornará um código de status HTTP relevante para o CloudFront para indicar isso. Por exemplo, se um visualizador solicitar um URL inválido, o servidor Web exibirá um código de status HTTP 404 (Não encontrado) para o CloudFront e o CloudFront exibirá esse código de status para o visualizador. Em vez de usar essa resposta a erros padrão, é possível criar uma resposta personalizada que o CloudFront exiba ao visualizador.
Se você configurar o CloudFront para retornar uma página de erro personalizada para um código de status HTTP, mas a página de erro personalizada não estiver disponível, o CloudFront retornará ao visualizador o código de status recebido do CloudFront da origem que contém as páginas de erro personalizadas. Por exemplo, suponha que sua origem personalizada retorne um código de status 500 e você configurou o CloudFront para obter uma página de erro personalizada para esse código em um bucket do Amazon S3. Porém, alguém excluiu a página de erro personalizada do bucket do Amazon S3 por acidente. O CloudFront retorna um código de status HTTP 404 (Não encontrado) para o visualizador que solicitou o objeto.
Quando o CloudFront retorna uma página de erro personalizada ao visualizador, você paga as cobranças padrão equivalentes do CloudFront para a página de erro personalizada, e não as cobranças do objeto solicitado. Para obter mais informações sobre as cobranças do CloudFront, consulte [Definição de preço do Amazon CloudFront](https://aws.amazon.com/cloudfront/pricing/).
**Topics**
+ [Configurar o comportamento de resposta a erros](custom-error-pages-procedure.md)
+ [Criar uma página de erro personalizada para códigos de status HTTP específicos](creating-custom-error-pages.md)
+ [Armazenar objetos e páginas de erro personalizadas em diferentes locais](custom-error-pages-different-locations.md)
+ [Alterar códigos de resposta exibidos pelo CloudFront](custom-error-pages-response-code.md)
+ [Controlar por quanto tempo o CloudFront armazena erros em cache](custom-error-pages-expiration.md)
# Configurar o comportamento de resposta a erros
Você tem várias opções para gerenciar como o CloudFront reage quando há um erro. Para configurar respostas de erro personalizadas, você pode usar o console e a API do CloudFront ou o CloudFormation. Independentemente de como você optar por atualizar a configuração, considere as seguintes dicas e recomendações:
+ Salve suas páginas de erro personalizadas em um local acessível ao CloudFront. Recomendamos que você os armazene em um bucket do Amazon S3 e que você [não os armazene no mesmo local que o restante do conteúdo do seu site ou aplicativo](custom-error-pages-different-locations.md). Se você armazenar as páginas de erro personalizadas na mesma origem do seu site ou aplicativo e a origem começar a retornar erros 5xx, o CloudFront não poderá obter as páginas de erro personalizadas porque o servidor de origem não está disponível. Para obter mais informações, consulte [Armazenar objetos e páginas de erro personalizadas em diferentes locais](custom-error-pages-different-locations.md).
+ Certifique-se de que o CloudFront tenha permissão para obter suas páginas de erro personalizadas. Se as páginas de erro personalizadas forem armazenadas no Amazon S3, elas deverão estar acessíveis ao público ou você deve configurar um [controle de acesso à origem (OAC)](private-content-restricting-access-to-s3.md) do CloudFront. Se as páginas de erro personalizadas forem armazenadas em uma origem personalizada, as páginas deverão estar acessíveis publicamente.
+ (Opcional) Configure sua origem para adicionar um `Cache-Control` ou `Expires` cabeçalho junto com as páginas de erro personalizadas, se desejar. Você também pode usar a configuração de **TTL mínimo de cache de erro** para controlar por quanto tempo o CloudFront armazena em cache as páginas de erro personalizadas. Para obter mais informações, consulte [Controlar por quanto tempo o CloudFront armazena erros em cache](custom-error-pages-expiration.md).
## Configurar respostas a erros personalizadas
Para configurar respostas de erro personalizadas no console do CloudFront, você deve ter uma distribuição do CloudFront. No console, as configurações para respostas de erro personalizadas só estão disponíveis para distribuições existentes. Para saber como criar uma distribuição, consulte [Conceitos básicos de uma distribuição padrão do CloudFront](GettingStarted.SimpleDistribution.md).
------
#### [ Console ]
**Para configurar respostas de erro personalizadas (console)**
1. Faça login no Console de gerenciamento da AWS e abra a página **Distributions** (Distribuições) no console do CloudFront em [https://console.aws.amazon.com/cloudfront/v4/home#distributions](https://console.aws.amazon.com/cloudfront/v4/home#distributions).
1. Na lista de distribuições, escolha a distribuição a ser atualizada.
1. Escolha a guia **Error Pages (Páginas de erro)** e escolha **Create Custom Error Response (Criar resposta de erro personalizada)**.
1. Insira os valores aplicáveis. Para obter mais informações, consulte [Páginas de erro personalizadas e erro de armazenamento em cache](DownloadDistValuesErrorPages.md).
1. Depois de inserir os valores desejados, escolha **Create (Criar)**.
------
#### [ CloudFront API or CloudFormation ]
Para configurar respostas de erro personalizadas com a API do CloudFront ou do CloudFormation, use o tipo `CustomErrorResponse` em uma distribuição. Para obter mais informações, consulte:
+ [AWS::CloudFront::Distribution CustomErrorResponse](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-cloudfront-distribution-customerrorresponse.html) no *Manual do usuário do AWS CloudFormation*
+ [CustomErrorResponse](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CustomErrorResponse.html) na *Referência da API do Amazon CloudFront*
------
# Criar uma página de erro personalizada para códigos de status HTTP específicos
Se você preferir exibir uma mensagem de erro personalizada em vez da mensagem padrão, como por exemplo, uma página que usa a mesma formatação do resto do seu site, você pode fazer com que o CloudFront retorne ao visualizador um objeto (como um arquivo HTML) que contenha sua mensagem de erro personalizada.
Para especificar o arquivo que deseja retornar e os erros para os quais o arquivo deve ser retornado, atualize sua distribuição do CloudFront para especificar esses valores. Para obter mais informações, consulte [Configurar o comportamento de resposta a erros](custom-error-pages-procedure.md).
Por exemplo, o seguinte item é uma página de erro personalizada:
![\[Captura de tela de um exemplo de página 404 personalizada da AWS.\]](http://docs.aws.amazon.com/pt_br/AmazonCloudFront/latest/DeveloperGuide/images/custom-error-page-aws-404-example.png)
Você pode especificar um objeto diferente para cada código de status HTTP compatível ou usar o mesmo objeto para todos os códigos de status compatíveis. Você pode optar por especificar páginas de erro personalizadas para alguns códigos de status e não para outros.
Os objetos fornecidos pelo CloudFront podem estar indisponíveis por vários motivos. Eles se encaixam em duas categorias gerais:
+ *Erros de cliente* indicam um problema com a solicitação. Por exemplo, um objeto com o nome especificado não está disponível ou o usuário não tem as permissões necessárias para obter um objeto no bucket do Amazon S3. Quando ocorre um erro de cliente, a origem retorna um código de status HTTP no intervalo 4xx para o CloudFront.
+ *Erros do servidor* indicam um problema com o servidor de origem. Por exemplo, o servidor HTTP está ocupado ou indisponível. Quando ocorre um erro de servidor, seu servidor de origem retorna um código de status HTTP no intervalo 5xx para o CloudFront ou o CloudFront não recebe uma resposta do seu servidor de origem por um determinado período de tempo e assume um código de status 504 (Tempo limite do Gateway).
Os códigos de status HTTP para os quais o CloudFront pode retornar uma página de erro personalizada incluem:
+ 400, 403, 404, 405, 414, 416
+ 500, 501, 502, 503, 504
**Observações**
Se o CloudFront detectar que a solicitação pode não ser segura, retornará um erro 400 (solicitação inválida) em vez de uma página de erro personalizada.
É possível criar uma página de erro personalizada para o código de status HTTP 416 (intervalo solicitado insatisfatório) e alterar o código de status HTTP retornado pelo CloudFront aos visualizadores quando a origem retornar um código de status 416 ao CloudFront. Para obter mais informações, consulte [Alterar códigos de resposta exibidos pelo CloudFront](custom-error-pages-response-code.md). No entanto, o CloudFront não armazena em cache as respostas do código de status 416, portanto, mesmo se você especificar um valor para o **TTL mínimo de cache de erro** para o código de status 416, o CloudFront não o usará.
Em alguns casos, o CloudFront não retorna uma página de erro personalizada para o código de status HTTP 503, mesmo se você configurar o CloudFront para isso. Se o código de erro do CloudFront for `Capacity Exceeded` ou `Limit Exceeded`, o CloudFront retornará um código de status 503 ao visualizador sem usar sua página de erro personalizada.
Se você criou uma página de erro personalizada, o CloudFront exibirá `Connection: close` ou `Connection: keep-alive` para os seguintes códigos de resposta:
O CloudFront exibe `Connection: close` para os códigos de status 400, 405, 414, 416, 500 e 501
O CloudFront exibe `Connection: keep-alive` para os códigos de status 403, 404, 502, 503 e 504.
Para obter uma explicação detalhada de como o CloudFront lida com respostas de erro de sua origem, consulte [Como o CloudFront processa códigos de status HTTP 4xx e 5xx da origem](HTTPStatusCodes.md).
# Armazenar objetos e páginas de erro personalizadas em diferentes locais
Se você quiser armazenar seus objetos e páginas de erro personalizadas em locais diferentes, sua distribuição deverá incluir um comportamento de cache para o qual o seguinte é verdadeiro:
+ O valor de **Path Pattern** é correspondente às suas mensagens de erro personalizadas. Por exemplo, imagine que você salvou páginas de erro personalizadas para erros 4xx em um bucket do Amazon S3 em um diretório denominado `/4xx-errors`. Sua distribuição deverá incluir um comportamento de cache para o qual o padrão de caminho roteia solicitações de suas páginas de erro personalizadas para esse local, por exemplo, `/4xx-errors/*`.
+ O valor de **Origin** especifica o valor de **Origin ID** da origem que contém suas páginas de erro personalizadas.
Para obter mais informações, consulte [Configurações de comportamento de cache](DownloadDistValuesCacheBehavior.md).
# Alterar códigos de resposta exibidos pelo CloudFront
Você pode configurar o CloudFront para retornar um código de status HTTP diferente para o visualizador do que o CloudFront recebeu da origem Por exemplo, se a origem retornar um código de status 500 para o CloudFront, você poderá solicitar que o CloudFront retorne uma página de erro personalizada e um código de status 200 (OK) ao visualizador. Há vários motivos pelos quais você pode querer que o CloudFront retorne um código de status ao visualizador diferente daquele retornado por sua origem ao CloudFront:
+ Alguns dispositivos de internet (alguns firewalls e proxies corporativos, por exemplo) interceptam códigos de status HTTP 4xx e 5xx e impedem que a resposta seja retornada ao visualizador. Neste caso, se você substituir `200`, a resposta não será interceptada.
+ Se não for necessário distinguir diferentes erros de cliente ou erros de servidor, você pode especificar `400` ou `500` como o valor que o CloudFront retorna para todos os códigos de status 4xx ou 5xx.
+ Você pode retornar um código de status `200` (OK) e um site estático para que seus clientes não saibam que seu site está inativo.
Se você habilitar [os logs padrão do CloudFront](AccessLogs.md) e configurar o CloudFront para alterar o código de status HTTP na resposta, o valor da coluna `sc-status` nos logs conterá o código de status especificado. No entanto, o valor da coluna `x-edge-result-type` não é afetado. Ele contém o tipo de resultado da resposta da origem. Por exemplo, digamos que você configure o CloudFront para retornar um código de status `200` ao visualizador quando a origem retornar `404` (Not Found) ao CloudFront. Quando a origem responde a uma solicitação com um código de status `404`, o valor na coluna `sc-status` no log será `200`, mas o valor na coluna `x-edge-result-type` será `Error`.
Você pode configurar o CloudFront para retornar qualquer um dos seguintes códigos de status HTTP junto com uma página de erro personalizada:
+ 200
+ 400, 403, 404, 405, 414, 416
+ 500, 501, 502, 503, 504
# Controlar por quanto tempo o CloudFront armazena erros em cache
Por padrão, o CloudFront armazena em cache as respostas durante 10 segundos. Por sua vez, o CloudFront envia a próxima solicitação do objeto à origem para ver se o problema que causou o erro foi resolvido e se o objeto solicitado está disponível.
É possível especificar a duração, o **Error Caching Minimum TTL (TTL mínimo de armazenamento em cache do erro)**, de cada código de status 4xx e 5xx armazenado em cache pelo CloudFront. (Para ter mais informações, consulte [Códigos de status HTTP 4xx e 5xx armazenados em cache pelo CloudFront](HTTPStatusCodes.md#HTTPStatusCodes-cached-errors).) Quando você especificar uma duração, observe o seguinte:
+ Se você especificar uma duração curta de armazenamento de erros em cache, o CloudFront encaminhará mais solicitações para a origem do que se você especificar um período maior. Para erros 5xx, isso pode agravar o problema que originalmente fez com que a origem retornasse um erro.
+ Quando a origem retorna um erro para um objeto, o CloudFront responde às solicitações do objeto com a resposta de erro ou com a página de erro personalizada até que a duração do armazenamento em cache expire. Se você especificar uma duração longa para o armazenamento de erros em cache, o CloudFront poderá continuar a responder às solicitações com uma resposta de erro ou com a página de erro personalizada por um longo período após o objeto se tornar disponível novamente.
**nota**
É possível criar uma página de erro personalizada para o código de status HTTP 416 (intervalo solicitado insatisfatório) e alterar o código de status HTTP retornado pelo CloudFront aos visualizadores quando a origem retornar um código de status 416 ao CloudFront. (Para obter mais informações, consulte [Alterar códigos de resposta exibidos pelo CloudFront](custom-error-pages-response-code.md).) No entanto, o CloudFront não armazena em cache as respostas do código de status 416, portanto, mesmo se você especificar um valor para o **TTL mínimo de cache de erro** para o código de status 416, o CloudFront não o usará.
Para controlar o tempo que o CloudFront armazena erros em cache para objetos individuais, configure seu servidor de origem para adicionar o cabeçalho aplicável à resposta de erro desse objeto.
Se a origem adicionar uma diretiva `Cache-Control: max-age` ou `Cache-Control: s-maxage`, ou um cabeçalho `Expires`, o CloudFront armazenará as respostas de erro em cache pelo valor no cabeçalho ou pelo valor do **Error Caching Minimum TTL** (TTL mínimo de armazenamento em cache de erros), o que for maior.
**nota**
Os valores `Cache-Control: max-age` e `Cache-Control: s-maxage` não podem ser maiores que o valor de **Maximum TTL** (TTL máximo) definido para o comportamento de cache para o qual a página de erro está sendo buscada.
Se a origem adicionar uma diretiva `Cache-Control: no-store`, `Cache-Control: no-cache` ou `Cache-Control: private` para os códigos de erro 404, 410, 414 ou 501, o CloudFront não armazenará em cache a resposta de erro. Com relação a todos os outros códigos de erro, o CloudFront ignorará as diretivas `no-store`, `no-cache` e `private` e armazenará em cache a resposta de erro referente ao valor de **Error Caching Minimum TTL**.
Se a origem adicionar outras diretivas `Cache-Control` ou nenhum cabeçalho, o CloudFront armazenará as respostas de erro em cache pelo valor de **Error Caching Minimum TTL** (TTL mínimo de armazenamento em cache de erros).
Se o tempo de expiração de um código de status 4xx ou 5xx para um objeto for maior do que você deseja e o objeto estiver disponível novamente, você poderá invalidar o código de erro armazenado em cache usando a URL do objeto solicitado. Se a origem estiver retornando uma resposta de erro para vários objetos, você precisará invalidar cada objeto separadamente. Para obter mais informações sobre como invalidar objetos, consulte [Invalidar arquivos para remover conteúdo](Invalidation.md).
Se você tiver o armazenamento em cache habilitado para uma origem de bucket do S3 e configurar um TTL mínimo de armazenamento de erros em cache de 0 segundo em sua distribuição do CloudFront, ainda verá um TTL mínimo de armazenamento de erros em cache de 1 segundo para erros de origem do S3. O CloudFront faz isso para proteger sua origem contra ataques de DDoS. Isso não se aplica a outros tipos de origem.