Sem cabeçalho de controle de cache para arquivos do AWS CloudFront com S3 Origin

21

Acabamos de migrar para o Amazon AWS. Atualmente, temos uma instância do EC2 que está funcionando bem. Ele está executando o Nginx na frente e o Apache no back-end. Isso está funcionando bem também. Todos os sites são lançados corretamente e incluem o cabeçalho Cache-Control para arquivos que são fornecidos pelo EC2.

O problema é que TODOS os arquivos estáticos que colocamos no Amazon S3 estão sendo acessados através do CloudFront CDN . Podemos acessar os arquivos bem ( e nenhum problema com o CORS), mas aparentemente o CloudFront não serve arquivos com o cabeçalho Cache-Control. Queremos aproveitar o cache do navegador.

Do jeito que eu vejo, a instância do EC2 não tem um papel aqui, pois os arquivos estáticos estão sendo servidos diretamente pelo S3 + CloudFront, a requisição não vai para o servidor da Web no EC2.

Estou completamente perdido.

Pergunta: 1) Como eu defino o controle de cache neste caso? 2) É possível definir o controle de cache? Do S3 ou do CloudFront?

Nota: acertei algumas páginas no Google onde você pode definir o cabeçalho no S3 para objetos individuais. Isso realmente não é uma maneira produtiva de fazê-lo, especialmente porque no meu caso estamos falando de vários objetos.

Obrigado!

    
por jarvis 14.04.2016 / 14:32

1 resposta

23

I've hit a few pages in Google where you can set the Header in S3 for individual objects. That's really not a productive way to do it specially since in my case we are talking of several objects.

Bem, "produtivo" ou não, é assim que ele é projetado para funcionar.

O CloudFront não adiciona Cache-Control: cabeçalhos.

CloudFront passa adiante (e também respeita, a menos que seja configurado de outra forma) os cabeçalhos Cache-Control: fornecidos pelo servidor de origem, que neste caso é S3.

Para obter Cache-Control: de cabeçalhos fornecidos pelo S3 quando um objeto é buscado, eles devem ser fornecidos quando o objeto é carregado no S3 ou adicionados aos metadados do objeto por uma operação put + copy subsequente, que pode ser usada internamente copie um objeto para si mesmo no S3, modificando os metadados no processo. Isso é o que o console faz, nos bastidores, se você editar os metadados do objeto.

Há também (caso você esteja se perguntando) nenhuma configuração global no S3 para forçar todos os objetos em um bucket a retornar esses cabeçalhos - é um atributo por objeto.

Atualização: Lambda @ Edge é um novo recurso no CloudFront que permite disparar gatilhos contra solicitações e / ou respostas, entre visualizador e cache e / ou cache e origem, executando código escrito em Node.js em relação a uma estrutura simples de objeto de solicitação / resposta exposta por CloudFront.

Uma das principais aplicações para este recurso é manipular cabeçalhos ... então, enquanto o acima ainda é preciso - o próprio CloudFront não adiciona Cache-Control - agora é possível para uma função do Lambda adicioná-los à resposta que é retornado do CloudFront.

Este exemplo adiciona Cache-Control: public, max-age=86400 somente se não houver nenhum cabeçalho Cache-Control presente na resposta.

O uso desse código em um gatilho de Resposta de Origem faria com que ele fosse disparado toda vez que o CloudFront buscasse um objeto a partir da origem e modificasse a resposta antes do armazenamento em cache do CloudFront.

'use strict';

exports.handler = (event, context, callback) => {
    const response = event.Records[0].cf.response;

    if(!response.headers['cache-control'])
    {
        response.headers['cache-control'] = [{ 
            key:   'Cache-Control', 
            value: 'public, max-age=86400' 
        }];
    }

    callback(null, response);
};

Atualização (2018-06-20): Recentemente, enviei uma solicitação de recurso para a equipe do CloudFront para permitir a configuração de cabeçalhos resposta de origem estática como atributos de origem, semelhantes ao modo como os cabeçalhos static request podem ser adicionados, agora ... mas com uma torção, permitindo que cada cabeçalho seja configurado para ser adicionado condicionalmente (somente se a origem não fornecer esse cabeçalho na resposta ) ou incondicionalmente (adicionar o cabeçalho e sobrescrever o cabeçalho da origem, se presente).

Com solicitações de recursos, você normalmente não recebe nenhuma confirmação se está realmente considerando a implementação do novo recurso ... ou até mesmo se eles já estiveram trabalhando nele ... é apenas anunciado quando eles terminam. Então, não tenho idéia se isso será implementado. Há um argumento a ser feito de que uma vez que este recurso já está disponível via Lambda @ Edge, não há necessidade disso na funcionalidade básica ... mas meu contra-argumento é que a base funcionalmente não é completa de recursos sem a capacidade de faça manipulação de cabeçalho de resposta simples e estática e, se essa for a única razão pela qual um acionador é necessário, exigir acionadores do Lambda é um custo desnecessário, financeiramente e com latência adicional (embora nenhum seja necessariamente um custo exorbitante).

    
por 15.04.2016 / 02:49