2012-01-08 1 views
4

Когда я использую приложение Rails, чтобы напрямую обслуживать свои активы через стек кедра Heroku (т.е. через CDN), они автоматически получают gzip'd. (См. Мой previous question о том, почему я в замешательстве об этом)Заголовки Accept-Encoding на Cloudfront, обслуживающие активы от Rails 3.0.x на керосине Heroku

Теперь я пытаюсь настроить Cloudfront для обслуживания этих активов, и в идеале я бы хотел, чтобы они также были gzip'd. Из того, что я прочитал, я подумал, что Cloudfront будет передавать заголовки Accept в мое приложение, поэтому их следует обслуживать gzip'd, если они поддерживаются (так же, как и при прямом запросе актива на heroku). Но это не так. Заголовки активов в конечном итоге выглядит так:

Age:510 
Connection:keep-alive 
Content-Length:178045 
Content-Type:text/css 
Date:Sun, 08 Jan 2012 18:55:13 GMT 
Last-Modified:Sun, 08 Jan 2012 18:42:34 GMT 
Server:nginx/0.7.67 
Via:1.1 varnish, 1.0 7a0b4b3db0cc0d369fe1d6981bfb646a.cloudfront.net:11180 (CloudFront), 1.0 6af08f4042ec142b4b760ca4cd62041d.cloudfront.net:11180 (CloudFront) 
X-Amz-Cf-Id:2b205edf4e9ef000a31a0208ca68f4e15b746eb430cde2ba5cc4b7dff4ba41a76c24f43cf498be02,8d5863a42eea452f86831a02f3eb648b26fe07013b08b95950f15ef8ba275822e1eb3b7ed2550d01 
X-Cache:Hit from cloudfront 
X-Varnish:2130919357 

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

This post говорит, что вам нужно вручную gzip и загрузить файл, но я не понимаю, почему это необходимо. Во-первых, это раздражает, и два, не будет ли он запрашивать файл так же, как мой браузер напрямую? Так почему бы ему просто не обслуживать файл gzip'd, как по умолчанию в моем приложении?

Любые советы по правильной работе gzip'ng были бы замечательными. Мне бы не пришлось вручную gzip мои файлы и загружать их, если это возможно.

ответ

3

Cedar поданные файлы НЕ получают GZipped от стека, Cedar только обслуживает все, что у вас есть в коде приложения. Смотрите documentation:

Поскольку запросы в Сидар приложения выполняются непосредственно на сервере приложений - не проксированном через сервер HTTP, как Nginx - любое сжатие ответов должно быть сделано в рамках вашего приложения. Для приложений Rack это можно выполнить с помощью промежуточного программного обеспечения Rack :: Deflater . Для статических активов gzipped убедитесь, что Rack :: Deflater загружен до ActionDispatch :: Static в стек промежуточного программного обеспечения.

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

Если вы смотрите на обслуживание заархивированных активов через CDN, я бы порекомендовал посмотреть на столкновение с Rails 3.1 и использовать конвейер Asset. Это не только даст вам больше контроля над вашими активами, но и даст вам гораздо более легкий путь к serving them over a CDN.

+0

Так получилось, что у меня были записи A, указывающие на heroku.com, а не на CNAME-ing herokuapp.com, как предлагают документы. В этом случае он фактически фильтровал мои запросы через Varnish. И это было все. Я изменил его сейчас, и я собираюсь использовать «Rack :: Deflater», пока я не смогу перейти на Rails 3.1 (это, очевидно, мой первый выбор, но, возможно, не для меня ATM) – brad

+0

Супер, рад помочь - не стесняйтесь галопировать мой ответ;) –

+0

FYI Я не думаю, что в этой статье, на которую вы ссылались, действительно необходимо. Cloudfront захватывает мои файлы, передавая заголовок Accept-Encoding, а затем кэширует их в своем CDN. Я не вижу причин, по которым я буду вручную синхронизировать свои активы. Первый запрос будет медленным, но последующие запросы будут быстрыми и будут отправлены из CDN. Thx снова, хотя для подсказок. – brad

Смежные вопросы