#reactjs #amazon-web-services #amazon-s3 #amazon-cloudfront #amazon-route53
#reactjs #amazon-веб-сервисы #amazon-s3 #amazon-cloudfront #amazon-route53
Вопрос:
DNS обрабатывается через Route53. Ранее React SPA был развернут на AWS S3 (с Cloudfront dist SSL). Перенесен из этого в приложение SSR NextJS на ElasticBeanstalk, но даже после изменения записей A и аннулирования CF некоторые пользователи по-прежнему сообщают, что их браузер использует старый S3 SPA. Единственное исправление для них — вручную очистить свой кэш для сайта.
Просить каждого случайного пользователя, который кэшировал мой сайт, вручную обновить свой кэш для страницы, не кажется хорошим решением 😉
Вот что я сделал на данный момент:
- Обновлен Route53 (запись), чтобы указывать на сервер EB (это работает как задумано),
- Пытался отключить связанный дистрибутив CF,
- Когда это не сработало, я удалил файлы в S3 и аннулировал CF dist,
- РЕДАКТИРОВАТЬ: После полного удаления CF dist пользователи могут перейти на новый сайт — но только после тщательного обновления полдюжины раз. Я все еще чувствую, что для этого должно быть более элегантное решение, требующее небольшого ноу-хау пользователя.
Ко всем моим CSS amp; JS файлам были добавлены номера версий, чтобы помочь с уничтожением кэша. Пользователи сообщают, что они видят HTML-структуру страницы, но для них используется версия JS amp; CSS 404 (как и должно быть, поскольку файлы больше не существуют).
Я бы подумал, что этого будет достаточно, чтобы браузер swap обновил свой кэш — но, видимо, нет. Единственным решением на данный момент для затронутых пользователей было вручную очистить свой кэш.
Более чем рад предложить более подробную информацию, если необходимо, любые мысли / вклад очень ценятся!
Комментарии:
1. Если очистка кэша решает проблему, то на самом деле это может быть только кэширование браузера. Были ли у вас агрессивные
Cache-Controlнастройки на главной странице старого сайта (на которой не было бы такого же кеширования, поскольку это главная страница сайта)?2. Вы сделали недействительным кэш в Cloudfront? Они взимают с вас плату за это, но именно так вы бы очистили кэш.
3. @Michael-sqlbot Нет, в прошлом у меня были проблемы с перебором кэша в CF, поэтому для всех моих соответствующих заголовков / meta были установлены сверхнизкие значения.
4. @JackMarchetti Да, делал это несколько раз; даже удалил все из S3, а затем аннулировал — тот же результат. До сих пор единственное, что вообще работало, это отключение, а затем полное удаление дистрибутива — но для этого все еще требуется, чтобы пользователь вручную обновлял несколько раз. Думаю, я мог бы довольствоваться одним обновлением, большинство нашей целевой аудитории достаточно подкованы, чтобы попробовать, но несколько обновлений, я думаю, немного вредят.
5. Если запросы каким-то образом все еще поступали в CloudFront, они бы не были обслужены, если бы дистрибутив был отключен… но все, что было обработано, должно было быть зарегистрировано. Удаление его не должно было быть необходимым, и даже это не объясняет «многократных обновлений». Происходит что-то еще, потому что ничего из этого не является нормальным / ожидаемым. HTTP-заголовки из инструментов разработчика браузера были бы полезны, но если бы с этим сталкивались только некоторые конечные пользователи, было бы неразумно пытаться заставить конечного пользователя проверять их.