Chrome S3 Cloudfront: Pas d'en-tête 'Access-Control-Allow-Origin' sur la demande XHR initiale

Vous faites deux demandes pour le même objet, une depuis HTML, une depuis XHR. La deuxième échoue, car Chrome utilise la réponse mise en cache de la première demande, qui n'a pas d'en-tête de réponse Access-Control-Allow-Origin.

Pourquoi?

Bug Chromium 409090 Demande cross-domain à partir du cache échouant après qu'une demande régulière soit mise en cache décrit ce problème, et c'est un "ne sera pas corrigé" -- ils pensent que leur comportement est correct. Chrome considère que la réponse mise en cache est utilisable, apparemment parce que la réponse n'incluait pas d'en-tête Vary: Origin.

Mais S3 ne retourne pas de Vary: Origin quand un objet est demandé sans en-tête de demande Origin:, même lorsque CORS est configuré sur le compartiment. Vary: Origin est uniquement envoyé lorsque un en-tête Origin est présent dans la demande.

Et CloudFront n'ajoute pas de Vary: Origin même lorsque Origin est autorisé pour être transmis, ce qui devrait par définition signifier que la variation de l'en-tête pourrait modifier la réponse -- c'est la raison pour laquelle vous transmettez et mettez en cache en fonction des en-têtes de demande.

CloudFront passe, car sa réponse serait correcte si celle de S3 l'était davantage, puisque CloudFront retourne ceci lorsqu'il est fourni par S3.

S3, un peu moins clair. Ce n'est pas incorrect de retourner Vary: Some-Header quand il n'y avait pas de Some-Header dans la demande.

Par exemple, une réponse qui contient

Vary: accept-encoding, accept-language

indique que le serveur d'origine pourrait avoir utilisé les champs Accept-Encoding et Accept-Language de la demande comme facteurs déterminants lors du choix du contenu pour cette réponse. (mise en évidence ajoutée)

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

Clairement, Vary: Some-Absent-Header est valable, donc S3 serait correct s'il ajoutait Vary: Origin à sa réponse si CORS est configuré, car cela pourrait en effet faire varier la réponse.

Et, apparemment, cela ferait que Chrome fasse la bonne chose. Ou, s'il ne fait pas la bonne chose dans ce cas, il violerait un MUST NOT. De la même section:

Un serveur d'origine peut envoyer Vary avec une liste de champs pour deux raisons :

1. Pour informer les destinataires du cache qu'ils DOIVENT PAS utiliser cette réponse pour satisfaire une demande ultérieure à moins que la demande ultérieure ait les mêmes valeurs pour les champs listés que la demande originale (Section 4.1 de [RFC7234]). En d'autres termes, Vary élargit la clé de cache nécessaire pour correspondre à une nouvelle demande à l'entrée du cache enregistrée.

...

Donc, S3 devrait vraiment retourner Vary: Origin lorsque CORS est configuré sur le compartiment, si Origin est absent de la demande, mais ce n'est pas le cas.

Cependant, S3 n'a pas strictement tort de ne pas retourner l'en-tête, car ce n'est qu'un DEVRAIT, pas un DOIT. Encore une fois, de la même section de RFC-7231 :

Un serveur d'origine DEVRAIT envoyer un champ d'en-tête Vary lorsque son algorithme pour choisir une représentation varie en fonction d'aspects de la demande autre que la méthode et la cible de la demande, ...

D'un autre côté, on pourrait soutenir que Chrome devrait implicitement savoir que faire varier l'en-tête Origin devrait être une clé de cache car cela pourrait changer la réponse de la même manière que Authorization pourrait changer la réponse.

...à moins que la variance ne puisse être franchie ou que le serveur d'origine ait été délibérément configuré pour empêcher la transparence du cache. Par exemple, il n'est pas nécessaire d'envoyer le nom du champ Authorization dans Vary car la réutilisation à travers les utilisateurs est contrainte par la définition du champ [...]

De même, la réutilisation à travers les origines est indiscutablement limitée par la nature de Origin, mais cet argument n'est pas un argument solide.

tl;dr: Vous ne pouvez apparemment pas récupérer avec succès un objet depuis HTML, puis le récupérer à nouveau en tant que demande CORS avec Chrome et S3 (avec ou sans CloudFront), en raison des particularités dans les implémentations.

Contournement:

Ce comportement peut être contourné avec CloudFront et Lambda@Edge, en utilisant le code suivant en tant que déclencheur de réponse d'origine.

Ceci ajoute Vary: Access-Control-Request-Headers, Access-Control-Request-Method, Origin à toute réponse de S3 qui n'a pas d'en-tête Vary. Sinon, l'en-tête Vary dans la réponse n'est pas modifié.

'use strict';

// Si la réponse manque d'un en-tête Vary, corrigez-le dans un déclencheur de réponse d'origine CloudFront.

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);
};

Attribution: Je suis également l'auteur du