Chrome S3 Cloudfront: nenhum cabeçalho 'Access-Control-Allow-Origin' na solicitação XHR inicial

Você está fazendo duas solicitações para o mesmo objeto, uma de HTML e outra de XHR. A segunda falha porque o Chrome usa a resposta em cache da primeira solicitação, que não tem Access-Control-Allow-Origincabeçalho de resposta.

Por quê?

Bug do Chromium 409090 Falha na solicitação de origem cruzada do cache após a solicitação regular ser armazenada em cache descreve esse problema e é um "não corrigirá" - eles acreditam que seu comportamento está correto. O Chrome considera a resposta em cache utilizável, aparentemente porque a resposta não incluiu um Vary: Origincabeçalho.

Mas o S3 não retorna Vary: Originquando um objeto é solicitado sem um Origin:cabeçalho de solicitação, mesmo quando o CORS está configurado no bucket. Vary: Originé enviado apenas quando um Origincabeçalho está presente na solicitação.

E o CloudFront não adiciona Vary: Originmesmo quando Originestá na lista de permissões para encaminhamento, o que deve, por definição, significar que variar o cabeçalho pode modificar a resposta. Essa é a razão pela qual você encaminha e armazena em cache nos cabeçalhos de solicitação.

O CloudFront recebe um passe, porque sua resposta estaria correta se os S3 fossem mais corretos, pois o CloudFront retorna isso quando é fornecido pelo S3.

S3, um pouco mais confuso. Não é errado retornar Vary: Some-Headerquando não havia Some-Headerno pedido.

Por exemplo, uma resposta que contém

Vary: accept-encoding, accept-language

indica que o servidor de origem pode ter utilizado as requisições Accept-Encodinge Accept-Languagecampos (ou a falta deles) como fatores determinantes na escolha do conteúdo para esta resposta. (enfase adicionada)

https://www.rfc-editor.org/rfc/rfc7231#section-7.1.4

Claramente, Vary: Some-Absent-Headeré válido, então S3 estaria correto se adicionasse Vary: Originà sua resposta se o CORS estivesse configurado, pois isso de fato poderia variar a resposta.

E, aparentemente, isso faria o Chrome fazer a coisa certa. Ou, se não fizer a coisa certa neste caso, estaria violando um MUST NOT. Da mesma seção:

Um servidor de origem pode enviar Varyuma lista de campos para duas finalidades:

1. Para informar os destinatários de cache que eles MUST NOTusam essa resposta para satisfazer uma solicitação posterior, a menos que a solicitação posterior tenha os mesmos valores para os campos listados que a solicitação original (Seção 4.1 de [RFC7234]). Em outras palavras, Vary expande a chave de cache necessária para corresponder uma nova solicitação à entrada de cache armazenada.

...

Então, o S3 realmente SHOULDestará retornando Vary: Originquando o CORS estiver configurado no bucket, se Originestiver ausente da requisição, mas não.

Ainda assim, o S3 não está estritamente errado por não retornar o cabeçalho, porque é apenas um SHOULD, não um MUST. Novamente, da mesma seção do RFC-7231:

Um servidor de origem SHOULDenvia um campo de cabeçalho Vary quando seu algoritmo para selecionar uma representação varia com base em aspectos da mensagem de solicitação que não sejam o método e o destino da solicitação, ...

Por outro lado, pode-se argumentar que o Chrome deve saber implicitamente que a variação do Origincabeçalho deve ser uma chave de cache, pois pode alterar a resposta da mesma maneira Authorizationque pode alterar a resposta.

...a menos que a variação não possa ser cruzada ou o servidor de origem tenha sido configurado deliberadamente para evitar a transparência do cache. Por exemplo, não há necessidade de enviar o Authorizationnome do campo Varyporque a reutilização entre usuários é restringida pela definição do campo [...]

Da mesma forma, a reutilização entre origens é indiscutivelmente limitada pela natureza, Originmas esse argumento não é forte.

tl;dr: Você aparentemente não pode buscar com sucesso um objeto do HTML e depois buscá-lo novamente com sucesso como uma solicitação CORS com Chrome e S3 (com ou sem CloudFront), devido a peculiaridades nas implementações.

Gambiarra:

Esse comportamento pode ser contornado com CloudFront e Lambda@Edge, usando o código a seguir como um gatilho de resposta de origem.

Isso adiciona Vary: Access-Control-Request-Headers, Access-Control-Request-Method, Origina qualquer resposta do S3 que não tenha Varycabeçalho. Caso contrário, o Varycabeçalho na resposta não será modificado.

'use strict';
 
// If the response lacks a Vary: header, fix it in a CloudFront Origin Response trigger.
 
exports.handler = (event, context, callback) => {
    const response = event.Records[0].cf.response;
    const headers = response.headers;
 
    if (!headers['vary'])
    {
        headers['vary'] = [
            { key: 'Vary', value: 'Access-Control-Request-Headers' },
            { key: 'Vary', value: 'Access-Control-Request-Method' },
            { key: 'Vary', value: 'Origin' },
        ];
    }
    callback(null, response);
};

Atribuição: também sou o autor da postagem original nos fóruns do AWS Support em que esse código foi compartilhado inicialmente.

A solução Lambda@Edge acima resulta em um comportamento totalmente correto, mas aqui estão duas alternativas que podem ser úteis, dependendo de suas necessidades específicas:

Alternativa/solução nº 1: forje os cabeçalhos CORS no CloudFront.

O CloudFront oferece suporte a cabeçalhos personalizados que são adicionados a cada solicitação. Se você definir Origin:em todas as solicitações, mesmo aquelas que não são de origem cruzada, isso permitirá o comportamento correto no S3. A opção de configuração é chamada de Custom Origin Headers, com a palavra "Origin" significando algo totalmente diferente do que significa no CORS. A configuração de um cabeçalho personalizado como este no CloudFront substitui o que é enviado na solicitação pelo valor especificado ou o adiciona se estiver ausente. Se você tiver exatamente uma origem acessando seu conteúdo por XHR, por exemplo https://example.com, você pode adicionar isso. O uso *é duvidoso, mas pode funcionar para outros cenários. Considere as implicações com cuidado.

Alternativa/Solução nº 2: Use um parâmetro de string de consulta "fictício" que difere para HTML e XHR ou está ausente de um ou de outro. Esses parâmetros geralmente são nomeados x-*, mas não devem ser x-amz-*.

Digamos que você invente o nome x-request. Então <img src="https://dzczcexample.cloudfront.net/image.png?x-request=html">. Ao acessar o objeto do JS, não adicione o parâmetro de consulta. O CloudFront já está fazendo a coisa certa, armazenando em cache diferentes versões dos objetos usando o Origincabeçalho ou a ausência dele como parte da chave de cache, porque você encaminhou esse cabeçalho em seu comportamento de cache. O problema é que seu navegador não sabe disso. Isso convence o navegador de que este é realmente um objeto separado que precisa ser solicitado novamente, em um contexto CORS.

Se você usar essas sugestões alternativas, use uma ou outra – não ambas.

A partir de novembro de 2021, o CloudFront oferece suporte direto às políticas de cabeçalhos de resposta . Isso inclui CORS, segurança e cabeçalhos personalizados. Não há mais necessidade de injetar cabeçalhos personalizados via Lambda@Edge ou CloudFront Functions.

Talvez mais agradável, não há mais necessidade de adicionar Vary como um cabeçalho personalizado. A nova implementação do CORS nas Políticas de Cabeçalhos inclui lógica adicional para definir os cabeçalhos apropriados, como Vary, de acordo com o padrão de busca.

Não sei por que você estaria obtendo resultados tão diferentes em vários navegadores, mas:

X-Amz-Cf-Id: wxn_m9meR6yPoyyvj1R7x83pBDPJy1nT7kdMv1aMwXVtHCunT9OC9g==

Essa linha é o que (se você conseguir chamar a atenção deles) um engenheiro do CloudFront ou de suporte usará para seguir uma de suas solicitações com falha. Se a solicitação estiver chegando a um servidor CloudFront, ela deverá ter esse cabeçalho na resposta. Se esse cabeçalho não estiver lá, a solicitação provavelmente está falhando em algum lugar antes de chegar ao CloudFront.

A solução aceita resolve o problema, mas não é a de melhor desempenho, principalmente para distribuições do CloudFront que atendem a conteúdo dinâmico. A configuração do cache de cabeçalho com uma lista de permissões resulta no armazenamento em cache do CloudFront de várias versões do objeto solicitado, dependendo do cabeçalho. Isso significa que internamente o CloudFront pode precisar buscar novamente o objeto da origem do S3 várias vezes. A transferência de dados do S3 para o CloudFront é gratuita, mas isso não leva em conta a latência adicional.

Uma solução alternativa aqui seria desabilitar a configuração CORS no bucket do S3 e, em vez disso, definir manualmente os cabeçalhos CORS usando uma função Lambda@Edge configurada na resposta do visualizador. A função pode ter a seguinte aparência:

'use strict';

const AllowedOriginRegex = /^(.*\.)?example\.com$/;

exports.handler = async (event = {}) => {
  const request = event.Records[0].cf.request;
  const response = event.Records[0].cf.response;

  if (!response.headers.vary) {
    response.headers.vary = [
      {key: 'Vary', value: 'Origin'},
      {key: 'Vary', value: 'Access-Control-Request-Headers'},
      {key: 'Vary', value: 'Access-Control-Request-Method'},
    ];
  }

  const origin = request.headers.origin && request.headers.origin[0].value;
  if (origin && AllowedOriginRegex.test(origin)) {
    response.headers['access-control-allow-origin'] = [
      {key: 'Access-Control-Allow-Origin', value: origin},
    ];
    response.headers['access-control-allow-methods'] = [
      {key: 'Access-Control-Allow-Methods', value: 'GET, HEAD'},
    ];
    response.headers['access-control-max-age'] = [
      {key: 'Access-Control-Max-Age', value: '3600'},
    ];
  }

  return response;
}

Existe outra solução mais simples que funciona para mim com o uso de um atributo HTML chamado crossorigin='anonymous'conforme detalhado aqui . Basicamente, você pode adicionar este atributo como tal:

<img src="your_image_url_here" crossorigin='anonymous'>

e isso faria essencialmente sua "primeira" solicitação para a imagem uma solicitação CORS, agora se você tentar recuperar a mesma imagem novamente por meio do XHR, mesmo que o Chrome decida usar o cache (resposta em cache para a primeira solicitação), tudo bem como agora vem com Access-Control-Allow-Originheader.

Eu não tinha a reputação de comentar a resposta aceita, mas queria ajudar alguém com problemas semelhantes.

Em suma, acredito que a AWS mudou algo para que o código lambda da solução aceita não funcione mais (talvez se/quando você mudar para a nova implementação da política de cache do CloudFront?)

headers['vary']não é falsey, portanto, a solução alternativa nunca é acionada.

Este é o lambda corrigido conforme a solução do dobesv na postagem original do fórum ( https://forums.aws.amazon.com/thread.jspa?messageID=796312 ):

'use strict';
 
// If the response lacks a Vary: header, fix it in a CloudFront Origin Response trigger.
 
exports.handler = (event, context, callback) => {
    const response = event.Records[0].cf.response;
    const headers = response.headers;
 
    if(!headers.vary) headers.vary = [];
    for(const hdr of ['Origin', 'Access-Control-Request-Headers', 'Access-Control-Request-Method']) {
        if(!headers['vary'].some(h => h.value === hdr)) {
            headers.vary.push({key: 'Vary', value: hdr});
        }
    }
    callback(null, response);
};

Para evitar completamente o comportamento de cache, você pode anexar um parâmetro de consulta aleatório ao fazer a solicitação via XHR.