Chrome S3 Cloudfront: в начальном запросе XHR отсутствует заголовок "Access-Control-Allow-Origin"

Вы делаете два запроса на один и тот же объект, один из HTML, другой из XHR. Второй сбой, потому что Chrome использует кэшированный ответ от первого запроса, который не имеет Access-Control-Allow-Origin заголовок ответа.

Зачем?

Ошибка Chromium 409090 Не удается выполнить перекрестный запрос из кэша после кэширования обычного запроса, и эта проблема "не будет устранена" - они считают, что их поведение правильное. Chrome считает, что кэшированный ответ пригоден для использования, по- видимому, потому что ответ не включает Vary: Origin заголовок.

Но S3 не возвращает Vary: Origin когда объект запрашивается без Origin: заголовок запроса, даже если CORS настроен на ведро. Vary: Origin отправляется только когда Origin заголовок присутствует в запросе.

И CloudFront не добавляет Vary: Origin даже когда Origin находится в белом списке для пересылки, что по определению должно означать, что изменение заголовка может изменить ответ - вот почему вы пересылаете и кэшируете заголовки запроса.

CloudFront получает пропуск, потому что его ответ был бы правильным, если бы S3 был более правильным, поскольку CloudFront действительно возвращает его, когда он предоставляется S3.

S3, немного пушистый. Это не так, чтобы вернуться Vary: Some-Header когда не было Some-Header в запросе.

Например, ответ, который содержит

Vary: accept-encoding, accept-language

указывает, что исходный сервер мог использовать запрос Accept-Encoding а также Accept-Language поля (или их отсутствие) как определяющие факторы при выборе контента для этого ответа. (выделение добавлено)

https://tools.ietf.org/html/rfc7231

Очевидно, что Vary: Some-Absent-Header допустимо, поэтому S3 будет правильным, если он добавлен Vary: Origin на его ответ, если CORS настроен, так как это действительно может изменить ответ.

И, видимо, это заставило бы Chrome делать правильные вещи. Или, если это не будет делать правильно в этом случае, это будет нарушать MUST NOT, Из того же раздела:

Исходный сервер может отправить Vary со списком полей для двух целей:

1. Сообщать получателям кэша, что они MUST NOT используйте этот ответ для удовлетворения более позднего запроса, если только у более позднего запроса нет тех же значений для перечисленных полей, что и у исходного запроса (Раздел 4.1 [RFC7234]). Другими словами, Vary расширяет ключ кеша, необходимый для сопоставления нового запроса с сохраненной записью кеша.

...

Итак, S3 действительно SHOULD возвращаться Vary: Origin когда CORS настроен на ведро, если Origin отсутствует в запросе, но это не так.

Тем не менее, S3 не является строго неправильным для того, чтобы не возвращать заголовок, потому что это только SHOULD не MUST, Опять же из того же раздела RFC-7231:

Исходный сервер SHOULD отправляет поле заголовка Vary, когда его алгоритм выбора представления изменяется в зависимости от аспектов сообщения запроса, отличных от метода и цели запроса,...

С другой стороны, можно утверждать, что Chrome должен неявно знать, что изменение Origin заголовок должен быть ключом кеша, потому что он может изменить ответ таким же образом Authorization может изменить ответ.

... если дисперсия не может быть пересечена или исходный сервер не был специально настроен для предотвращения прозрачности кэша. Например, нет необходимости отправлять Authorization имя поля в Vary потому что повторное использование между пользователями ограничено определением поля [...]

Точно так же повторное использование в разных источниках возможно ограничено природой Origin но этот аргумент не является сильным.

tl; dr: Вы, очевидно, не можете успешно извлечь объект из HTML, а затем успешно извлечь его снова с запросом CORS с Chrome и S3 (с или без CloudFront) из-за особенностей реализации.

Временное решение:

Это поведение можно обойти с помощью CloudFront и Lambda@Edge, используя следующий код в качестве триггера Origin Response.

Это добавляет Vary: Access-Control-Request-Headers, Access-Control-Request-Method, Origin на любой ответ от S3, который не имеет Vary заголовок. В противном случае Vary Заголовок в ответе не изменяется.

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

Атрибуция. Я также являюсь автором исходного поста на форумах поддержки AWS, где этот код был опубликован изначально.

Решение Lambda@Edge, приведенное выше, приводит к полностью корректному поведению, но вот две альтернативы, которые вы можете найти полезными, в зависимости от ваших конкретных потребностей:

Альтернатива /Hackaround #1: Подделать заголовки CORS в CloudFront.

CloudFront поддерживает пользовательские заголовки, которые добавляются к каждому запросу. Если вы установите Origin: при каждом запросе, даже если он не является кросс-источником, это обеспечит правильное поведение в S3. Параметр конфигурации называется Custom Origin Headers, а слово "Origin" означает нечто совершенно иное, чем в CORS. Конфигурирование пользовательского заголовка, подобного этому, в CloudFront перезаписывает то, что отправлено в запросе, с указанным значением, или добавляет его, если оно отсутствует. Если у вас есть только один источник доступа к вашему контенту через XHR, например https://example.com Вы можете добавить это. С помощью * сомнительно, но может работать для других сценариев. Тщательно обдумайте последствия.

Альтернатива /Hackaround #2: Используйте "пустой" параметр строки запроса, который отличается для HTML и XHR или отсутствует у того или другого. Эти параметры обычно называются x-* но не должно быть x-amz-*,

Допустим, вы составляете имя x-request, Так <img src="https://dzczcexample.cloudfront.net/image.png?x-request=html">, При доступе к объекту из JS не добавляйте параметр запроса. CloudFront уже делает правильные вещи, кэшируя различные версии объектов, используя Origin заголовок или его отсутствие как часть ключа кеша, потому что вы перенаправили этот заголовок в поведение кеша. Проблема в том, что ваш браузер этого не знает. Это убеждает браузер в том, что на самом деле это отдельный объект, который необходимо запросить снова, в контексте CORS.

Если вы используете эти альтернативные предложения, используйте одно или другое, а не оба.