CloudFront com origem personalizada e ELB

Question

Estamos usando o CloudFront para nossos recursos estáticos, mas também desejamos permitir o Gzip. Nós configuramos uma nova distribuição com uma origem personalizada apontando para nossos servidores de aplicativos que estão por trás de um balanceador de carga elástico. Mantemos manualmente os arquivos em sincronia através do cluster e os atualizamos quando publicamos.

No entanto, com essa configuração, não obtemos nada além de Miss e RefreshHits do CloudFront, que até agora derrotou o objetivo. Existe alguma configuração adicional para usar um ELB como sua origem personalizada? Nos documentos, ele faz referência a isso como uma solução viável.

Aparece quando apontamos a distribuição para um único servidor em nosso cluster de produção, o cloudfront armazena corretamente nossos ativos.

É possível que o cookie de sessões fixas e o cabeçalho subsequente adicionado por ele possam ser um problema?

Cache-Control: no-cache="set-cookie" // Adicionado pelo balanceador de carga

Alguma idéia?

FYI - atualmente, temos nossa origem personalizada apontando para uma única instância do EC2, portanto, o armazenamento em cache está funcionando corretamente - caso você tente encurtar o arquivo abaixo.

Cabeçalhos de exemplo: curl -I link

HTTP/1.0 200 OK
Accept-Ranges: bytes
Cache-Control: max-age=3700
Cache-Control: no-cache="set-cookie"
Content-Length: 23038
Content-Type: text/css
Date: Thu, 12 Apr 2012 23:03:52 GMT
Last-Modified: Thu, 12 Apr 2012 23:00:14 GMT
Server: Apache/2.2.17 (Ubuntu)
Vary: Accept-Encoding
X-Cache: RefreshHit from cloudfront
X-Amz-Cf-Id: K_q7Zy3_jdzlEJ85ukELVtdx1GmuXqApAbZZ7G0fPt0mxRMqPKX5pQ==,RzJmPku-rEIO9WlvuSoKa8hiAaR3dLk5KC4cQMWWrf_MDhmjWe8n6A==
Via: 1.0 28c34f9fbf559a21ee16594849e4fc9c.cloudfront.net (CloudFront)
Connection: close

    

Answer 1

Ao usar sessões fixas no ELB, o balanceador de carga adicionará os dois cabeçalhos a seguir à resposta: Set-Cookie (com o cookie AWSELB) e Cache-Control: no-cache="set-cookie" .

Se o min-ttl em seu CF Distro for 0 (que agora é o valor padrão), o CloudFront usará a diretiva no-cache. Um representante da Amazon me ligou: w3.org - RFC2616 .

O seguinte da seção no-cache se aplica:

If the no-cache directive does specify one or more field-names, then a cache MAY use the response to satisfy a subsequent request, subject to any other restrictions on caching. However, the specified field-name(s) MUST NOT be sent in the response to a subsequent request without successful revalidation with the origin server

No entanto, pela minha experiência, o CloudFront sempre revalida o objeto se a diretiva no-cache estiver definida. Eu acredito, eles deveriam na verdade apenas omitir o cabeçalho Set-Cookie conforme especificado no no-cache para começar.

O conserto rápido foi criar uma nova distribuição do CF e especificar manualmente um min-ttl maior que 0, o que parece substituir a diretiva no-cache . Você precisa usar a API ou um programa de terceiros para fazer, pois o AWS Console não permite modificar o min-ttl.

    

Answer 2

É possível que o CloudFront não manipule vários cabeçalhos com o mesmo nome corretamente e não esteja vendo sua diretiva max-age . De acordo com este CloudFront usa o Expires header, se presente, tente acessar seu servidor de origem para definir isso em vez disso (de preferência em relação ao tempo de solicitação). Para o Apache, eu acho que você quer algo assim com mod_expires :

ExpiresDefault "access plus 1 hour"