Я размещаю статический сайт на S3 с CloudFront поверх. У меня проблема с моими HTML-файлами.
В соответствии с FAQ по CloudFront:
Amazon CloudFront использует эти заголовки элементов управления кешем, чтобы определить, как часто нужно проверять источник для обновленной версии этого файла.
Имея это в виду, я установил HTML-файлы в моем S3 Bucket, чтобы добавить следующие заголовки:
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?
Согласно его часто задаваемым вопросам, я могу сделать это с помощью заголовков Cache-Control, но я не могу заставить это работать.
В конце концов, я решил изменить свой www CNAME, чтобы он указывал напрямую на мою корзину S3. Затем добавлен новый CNAME под названием «static», указывающий на CloudFront.
Это означает, что HTML напрямую из S3, в котором все ссылки CSS / JS / IMG указывают на static.mydomain.com
Я считаю, что ответы на данный момент, хотя и правильные на тот момент, теперь устарели, поскольку Cloudfront теперь поддерживает минимальный TTL, равный 0, и исходная попытка OP использовать cache-age = 0 теперь должна работать.
Вы могли бы изучить, использовать ли эти другие заголовки для управления кешем, с точки зрения того, дадут ли они результат, который вы ищете - вам может потребоваться только max-age. Вероятно, вы хотите, чтобы Cloudfront проверил S3, чтобы увидеть, изменился ли файл HTML. Если да, Cloudfront может получить и вернуть новый файл. В противном случае он может обслуживать клиента из существующего кеша (сохраняя полосу пропускания S3 и обслуживая клиента быстрее и более локально).
Задача Cloudfront - обслуживать кэшированный контент, да, но теперь он включает контент, который иногда изменяется, но может быть кэширован, если он не изменился.
P.s. Строки запросов теперь также работают с Cloudfront (если вы настроите «поведение» для соответствующего источника - еще одна новая функция), однако некоторые прокси-серверы могут по-прежнему не кэшировать какие-либо файлы со строками запроса.
Руководство разработчика Amazon: срок действия1
Во-первых, цель Cloudfront - обслуживать кэшированный контент - если вы попытаетесь обслуживать некэшированный контент из Cloudfront, это будет медленнее, чем обслуживание его напрямую из S3, почти во всех случаях (что-то вроде потокового контента будет исключением). Подумайте на мгновение, что должно произойти для обслуживания контента из Cloudfront - он должен быть получен с исходного сервера в местоположение, которое географически близко к пользователю, что означает, что для запроса, где Cloudfront должен получить контент с исходного сервера , вы добавляете дополнительную задержку в запрос, и пользователь получает контент медленнее. Только когда контент становится доступным на периферии, последующие запросы выполняются быстрее.
Лучший подход к этой проблеме - изменить имена файлов при обновлении страницы - это заставит Cloudfront извлекать новый контент. Опять же, имейте в виду, что Cloudfront обычно используется для мультимедийных файлов (включая изображения) и style / javascript - и не столько для html. По сути, ваш HTML-код будет на S3, а ваши изображения - на Cloudfront - с любыми внесенными вами изменениями вы можете изменить имя файла в Cloudfront (например, file-v1.jpg, file-v2.jpg и т. Д.). Другой распространенный способ - включить строку запроса с информацией о версии.
Также имейте в виду, что Cloudfront не обслуживает сжатый с помощью gzip контент, что может привести к более медленному отклику, чем от обычного сервера (хотя в вашем случае S3 также не идентифицирует браузеры, поддерживающие gzip).
Наконец, если вы хотите, вы можете использовать аннулирование, чтобы заставить Cloudfront отказаться от своей существующей копии и получить новую с исходного сервера. Однако обратите внимание, что Cloudfront дает вам только 1000 бесплатных аннулирований в месяц, после чего стоимость составляет 0,005 доллара за аннулирование.
Минимальное время, в течение которого Cloudfront будет хранить контент, - 1 час, хотя по умолчанию установлено 24 часа. Поэтому я бы попытался установить max-age как минимум на 3600. Рассмотрим также заголовок s-maxage (для общего, то есть проксированного контента). Amazon рекомендует этот кеширование учебник.
Был недавняя проблема с этим, исправлено несколько дней назад
Не знаю, как CloudFront обрабатывает заголовок так же, как и ваш, но если вы не укажете заголовки, время обновления объектов по умолчанию составляет 24 часа.
Одна из вещей, которые вы можете сделать для обновления объектов, - это сделать контент недействительным. Перейдите по ссылке ниже для получения дополнительной информации. http://blog.cloudberrylab.com/2010/08/how-to-manage-cloudfront-object.html