Примушуючи CloudFront передати останній HTML-файл із S3

Фон

Я розміщую статичний сайт на S3, з CloudFront вгорі. У мене є проблема з моїми HTML-файлами.

Відповідно до поширених запитань CloudFront :

Amazon CloudFront використовує ці заголовки кеш-керування, щоб визначити, наскільки часто потрібно перевіряти походження для оновленої версії цього файлу

Що я робив до цих пір

Зважаючи на це, я встановив HTML-файли у своєму відрі S3, щоб додати до таких заголовків:

Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Expires: Fri, 01 Jan 1990 00:00:00 GMT

Під час мого першого дзвінка до мого samplefile.htmя бачу наступні заголовки відповідей (я виключив очевидні заголовки (наприклад Content-Type) для того, щоб продовжувати:

Cache-Control:no-cache, no-store, max-age=0, must-revalidate
Date:Sat, 10 Dec 2011 14:16:51 GMT
ETag:"a5890ace30a3e84d9118196c161aeec2"
Expires:Fri, 01 Jan 1990 00:00:00 GMT
Last-Modified:Sat, 10 Dec 2011 14:16:43 GMT
Server:AmazonS3
X-Cache:Miss from cloudfront

Як бачите, мій Cache-Controlзаголовок знаходиться там. Проблема полягає в тому, що якщо я оновлюю цей файл і оновлююсь, я отримую кешований вміст (а не останній файл), і я бачу, що CloudFront обслуговує кешовану версію, переглядаючи заголовки відповідей:

X-Cache:Hit from cloudfront

Резюме / питання

Зважаючи на вищезазначене, як я можу досягти автоматичного пошуку останнього HTML при використанні CloudFront?

Відповідно до його поширених запитань, я повинен бути в змозі зробити це з заголовками кеш-керування, але я не можу зробити так, що це працює.

Дотримуючись відповідей нижче

Врешті-решт я вирішив змінити свій www CNAME, щоб безпосередньо вказати на моє відро S3. Потім додали новий CNAME під назвою "статичний", який вказує на CloudFront.

Це означає, що HTML є прямим від S3, який потім має всі свої посилання CSS / JS / IMG, які вказують на static.mydomain.com

По-перше, сенс Cloudfront полягає в поданні кешованого контенту - якщо ви намагаєтеся розміщувати кешований вміст із Cloudfront, це повільніше, ніж подавати його безпосередньо з S3, майже у всіх випадках (виняток становитиме щось на зразок потокового вмісту). Подумайте на мить, що має статися для подачі контенту з Cloudfront - його потрібно перенести з початкового сервера до місця, яке географічно наближене до користувача, - це означає, що для запиту, де Cloudfront повинен отримати вміст із початкового сервера , ви додаєте додаткову затримку в запит, і користувач отримує вміст повільніше. Лише коли вміст буде доступний у крайовому місці, наступні запити будуть швидшими.

Найкращим підходом до цієї проблеми є зміна ваших імен файлів під час оновлення сторінки - це змусить Cloudfront отримати новий вміст. Знову ж таки, майте на увазі, що Cloudfront зазвичай використовується для медіафайлів (включаючи зображення) та стилю / javascript - і не стільки для html. По суті, у вас буде HTML на S3, а ваші зображення на Cloudfront - при будь-яких внесених змінах ви можете змінити ім'я файлу на Cloudfront (наприклад, файл-v1.jpg, файл-v2.jpg тощо). Ще один поширений спосіб - це включення рядка запиту з інформацією про версію.

Також майте на увазі, що Cloudfront не подає gzipped вміст - це може спричинити повільнішу реакцію, ніж звичайний сервер (хоча у вашому випадку S3 також не ідентифікує браузери, здатні на gzip).

Нарешті, якщо ви хочете, ви можете використовувати недійсність, щоб змусити Cloudfront відмовитися від існуючої копії та отримати нову з початкового сервера. Однак зауважте, що Cloudfront дає вам лише 1000 безкоштовних інвалідів на місяць, після чого вартість становить 0,005 дол. США / інвалідація.

Найменший час, коли Cloudfront зберігатиме вміст, становить 1 год , хоча за замовчуванням - 24 години . Тому я б спробував встановити максимальний вік принаймні 3600. Розглянемо також заголовок s-maxage (для спільного - тобто проксі-вмісту). Amazon рекомендує цей підручник з кешування.

З цим виникла нещодавня проблема , виправлена ​​кілька днів тому

Я вважаю, що відповіді поки що є правильними, але застарілі, оскільки Cloudfront зараз підтримує мінімальний TTL 0, і початкова спроба ОП використовувати кеш-вік = 0 повинна працювати.

Ви хочете вивчити, чи використовувати ці інші заголовки кеш-керування з точки зору того, чи вони дадуть результат, який ви шукаєте - вам може знадобитися лише максимальний вік. Напевно, ви хочете, щоб Cloudfront перевірив S3, щоб побачити, чи змінився HTML-файл. Якщо він є, Cloudfront може отримати та повернути новий файл. Якщо ні, він може обслуговувати клієнта з наявного кешу (збереження смуги пропускання S3 та обслуговування клієнта швидше та локальніше).

Суть Cloudfront полягає в поданні кешованого вмісту, так, але тепер це включає вміст, який іноді змінюється, але може бути кешований, якщо він не змінився.

Рядки запитів Ps також зараз працюють з Cloudfront (якщо ви налаштуєте "поведінку" для відповідного походження - ще одна нова функція), проте деякі проксі-сервери все ще можуть не кешувати файли з рядками запитів.

Посібник для розробників Amazon: термін дії 1

Не знаєте, як CloudFront ставиться до заголовка, як до вас, але якщо ви не вказали жодних заголовків, час оновлення об'єктів за замовчуванням - 24 години.

Однією з речей, які ви можете зробити для оновлення об'єктів, є недійсна зміст. Перегляньте посилання нижче, щоб отримати додаткову інформацію. http://blog.cloudberrylab.com/2010/08/how-to-manage-cloudfront-object.html