Назад | Перейти на главную страницу

CloudFront с Custom Origin и ELB

Мы используем CloudFront для наших статических ресурсов, но также хотели разрешить Gzip. Мы настроили новый дистрибутив с настраиваемым источником, указывающим на наши серверы приложений, которые находятся за эластичным балансировщиком нагрузки. Мы вручную синхронизируем файлы в кластере и обновляем их при публикации.

Однако с этой настройкой мы не получаем ничего, кроме Miss и RefreshHits от CloudFront, что пока что не удалось. Есть ли какие-либо дополнительные настройки для использования ELB в качестве настраиваемого источника? В документации это упоминается как жизнеспособное решение.

Похоже, что когда мы направляем распределение на один сервер в нашем производственном кластере, облачный интерфейс правильно кэширует наши активы.

Возможно ли, что прикрепленный файл cookie сеансов и последующий добавляемый им заголовок могут быть проблемой?

Cache-Control: no-cache="set-cookie" // Добавлен балансировщиком нагрузки

Любые идеи?

К вашему сведению - в настоящее время у нас есть пользовательское происхождение, указывающее на один экземпляр EC2, поэтому кеширование работает правильно - на случай, если вы попытаетесь скрутить файл ниже.

Пример заголовков: curl -I http://static.quick-cdn.com/css/9850999.css

HTTP/1.0 200 OK
Accept-Ranges: bytes
Cache-Control: max-age=3700
Cache-Control: no-cache="set-cookie"
Content-Length: 23038
Content-Type: text/css
Date: Thu, 12 Apr 2012 23:03:52 GMT
Last-Modified: Thu, 12 Apr 2012 23:00:14 GMT
Server: Apache/2.2.17 (Ubuntu)
Vary: Accept-Encoding
X-Cache: RefreshHit from cloudfront
X-Amz-Cf-Id: K_q7Zy3_jdzlEJ85ukELVtdx1GmuXqApAbZZ7G0fPt0mxRMqPKX5pQ==,RzJmPku-rEIO9WlvuSoKa8hiAaR3dLk5KC4cQMWWrf_MDhmjWe8n6A==
Via: 1.0 28c34f9fbf559a21ee16594849e4fc9c.cloudfront.net (CloudFront)
Connection: close

При использовании закрепленных сеансов на ELB балансировщик нагрузки добавит в ответ следующие два заголовка: Set-Cookie (с файлом cookie AWSELB) и Cache-Control: no-cache="set-cookie".

Если min-ttl на вашем CF Distro равен 0 (который теперь является значением по умолчанию), CloudFront будет использовать директиву no-cache. Представитель Amazon связал меня с этим: w3.org - RFC2616.

Применяется следующее из раздела без кеширования:

Если директива no-cache указывает одно или несколько имен полей, то кеш МОЖЕТ использовать ответ для удовлетворения последующего запроса с учетом любых других ограничений на кэширование. Однако указанные имена полей НЕ ДОЛЖНЫ быть отправлены в ответе на последующий запрос без успешной повторной проверки исходным сервером.

Однако по моему опыту CloudFront всегда повторно проверяет объект, если no-cache установлена ​​директива. Я считаю, что им на самом деле следует просто опустить заголовок Set-Cookie, как указано в no-cache начать с.

Быстрое исправление заключалось в создании нового CF Distro и ручном указании min-ttl больше 0, что, кажется, отменяет no-cache директива. Для этого вам нужно использовать API или стороннюю программу, так как Консоль AWS не позволяет вам изменять min-ttl.

Возможно, CloudFront неправильно обрабатывает несколько заголовков с одним и тем же именем и не видит ваш max-age директива. В соответствии с этот CloudFront использует Expires заголовок, если он присутствует, поэтому попробуйте заставить исходный сервер установить это вместо этого (желательно относительно времени запроса). Для Apache, я думаю, вам нужно что-то подобное с mod_expires:

ExpiresDefault "access plus 1 hour"