Использование AWS CloudFront для обслуживания HTTPS в корзинах AWS S3, но НЕКОТОРЫЕ изображения застревают в цикле перенаправления
Вчера я настроил Certs и CloudFront, чтобы перевести свои сайты с http на https. http автоматически перенаправляет на https. Дистрибутивы CloudFront указывают на сегменты S3. Все работает; за исключением того, что некоторые файлы застревают в цикле перенаправления. Я предположил, что это CF немного медленный, поэтому оставил его на ночь. 12 часов спустя... та же проблема.
Примеры:
https://www.humantruth.info/1.jpg -> Цикл перенаправления. (20 редиректов, затем браузер сдается)
https://www.humantruth.info/bus_seats.jpg -> Грузится нормально.
В корзине S3 у них обоих есть «Стандартный» класс хранения (что бы это ни значило), и нет никаких признаков каких-либо специальных настроек, которые есть только у одного из них, но не у другого.
Я пробовал разные браузеры на разных устройствах на работе и дома и получил одинаковые результаты. Я меняю настройки AWS только раз в несколько лет, у меня очень простая настройка, и я никогда не пытался применить конкретную переадресацию или настройки к отдельным изображениям; Я уверен, что настройки для обоих одинаковы.
(Q1) Какие /виды/ вещей мне следует делать, чтобы найти недостатки? Я следовал руководствам AWS о том, «как включить https», и оставил все настройки по умолчанию (как указано в руководстве), за исключением нескольких основных (например, установка источников в дистрибутивах).
(Q2) Это проблема с кэшированием? Когда я обновляю элементы корзины S3, содержимое действующего сайта не обновляется даже через 3 часа. Обычно оно обновляется в течение минуты. Поэтому мне нужно сказать CF, чтобы он обновлялся чаще. Возможно, это тоже неясная причина проблемы с перенаправлением.
Глядя на https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/understanding-how-origin-request-policies-and-cache-policies-work-together.html, у меня возникает соблазн обновите этот параметр:
CloudFront distribution > Edit Behaviour > Cache key and origin requests
По умолчанию:
Cache policy and origin request policy (recommended)
К:
Legacy cache settings > None (for Headers, Query Strings and Cookies).
Я вообще не использую файлы cookie и не делаю никаких особых запросов; весь сайт представляет собой статические страницы .html, статические .js, статические .css и статические изображения.
(Q3) Что происходит? У меня очень-очень простая настройка, и подобные сложности заставляют меня думать, что мне следует отказаться от всей концепции https и оставить ее http. Что-то принципиально не так с CF и/или отсутствует в руководствах по установке?
Я внес изменение во втором квартале, установив для всех настроек «Редактировать поведение» значение «Нет». Оставляю этот комментарий, чтобы помнить, в какое время я это сделал! Я дам ему час, чтобы переодеться. Если это исправит, как нам заставить AWS обновить свои руководства, включив это в качестве шага?
Я пробовал (100 раз) принудительное обновление браузера и полное удаление кеша браузера (я специально использую Chrome для тестирования, это мой «пустой» браузер); Принудительные обновления и запросы после очистки кэша приводят к ответам http-200 от сервера с содержимым .html, а обновление F5 после этого приводит к ответам http-304 (не изменено). Несмотря ни на что, CloudFront возвращает старые, устаревшие (на несколько часов) файлы; У меня еще нет ни одного обновления. Я хочу полностью отключить службы кэширования CloudFront, но как? (Надеюсь, что это также исправит 301-е наводнение).
Некоторые пользователи говорят, что оба изображения загружаются нормально. Это может указывать на региональную проблему CloudFront; это еще больше затрудняет расследование.
Я установил новый браузер (Firefox), протестировал его и столкнулся с той же проблемой. Это определенно не проблема с локальным кешем браузера.
Я знаю ответ, я дам ему день, чтобы кто-нибудь еще придумал его, прежде чем объявить его и отметить «Правильный ответ».
Ответы 1
Починил это. Решение:
After setting up CloudFront, do an Invalidate on /* files.
Корзины Amazon S3 УЖЕ должны незаметно использовать CloudFront по умолчанию. Когда я создавал свои собственные дистрибутивы CloudFront, НЕКОТОРЫЕ файлы уже были предварительно кэшированы, когда они существовали только по http. Итак, когда я реализовал пересылку http > https, несмотря ни на что, НЕКОТОРЫЕ файлы все еще перенаправлялись теперь неверными предварительными кэшами CloudFronts старых версий http.
Поэтому, что бы я ни делал, они никогда не работали (в частности, для нескольких файлов), и не имело значения, какие у меня были настройки. Решением в CloudFront было принудительное признание всех файлов недействительными с использованием шаблона «все», /*.
Очень раздражало то, что с самого начала, еще до того, как что-либо сделать, поведение по умолчанию заключалось в том, что любые уже кэшированные файлы создавали циклы перенаправления.
AWS действительно следует включить в свои руководства по настройке для перевода сайтов S3 с http на https, что этот дополнительный шаг необходим для предотвращения этой ошибки.
Настройки «Кэширования» в моих дистрибутивах CloudFront установлены по умолчанию (и они работают с большей частью контента). Но я заметил, что когда я обновляю элементы корзины S3, они не обновляются «в реальном времени» на веб-сайтах. Он по-прежнему возвращает 304 (не изменено), даже через два часа после обновлений. Это указывает на проблему с кэшированием. Но что мне делать? в частности: (1) Сделать ВСЕ файлы загружаемыми без циклов перенаправления. (2) Сделать так, чтобы обновления файлов S3 отражались через CloudFront практически мгновенно (в течение минуты)?