Heroku Cedar上のRails 3.0.xのCloudwardサービスアセットのAccept-Encodingヘッダー

Question

私のRailsアプリをHerokuのCedarスタック（つまりCDNではなく）を介して直接配信すると、自動的にgzipされます。 （私がこれについて混乱している理由については、previous questionを参照してください）

ここで、これらの資産を提供するためにCloudfrontを設定しようとしています。理想的には、gzipにすることもできます。私が読んだところでは、Cloudfrontは私のアプリにAcceptヘッダーを渡すと考えていたので、サポートされていればgzipされているはずです（ヒーローの資産に直接リクエストをしたときと同じです）。しかし、そうではありません。エンコーディングの言及はここにありません

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で圧縮いない：アセット・ヘッダは次のように見て終わります。だから、クラウドフロントに私のアプリからアセットのgzipされたバージョンをリクエストして、これをクライアントに提供できるようにするためには、ここで何をする必要があるのだろうかと思います。

This postは、ファイルを手動でgzipしてアップロードする必要があると言われていますが、なぜそれが必要なのかわかりません。 1つは迷惑で、2つはブラウザに直接ファイルを要求しないでしょうか？だからなぜそれは私のアプリでデフォルトでgzipされたファイルを提供しないだろうか？

gzip'ngが正常に動作するようにするためのヒントは素晴らしいでしょう。私は手動でファイルをgzipし、可能であればアップロードする必要はありません。

Answer 1

Cedarで処理されたファイルはスタックでGZipされません。Cedarはアプリケーションコード内にあるものだけを提供します。 documentationを参照してください：

シーダーアプリケーションへの要求がアプリケーション サーバーに直接作られているので - nginxのようなHTTPサーバを介してプロキシではない - 応答のいずれか 圧縮はアプリケーション内で行わなければなりません。 ラックアプリの場合、これはRack :: Deflater ミドルウェアで行うことができます。 gzipされた静的資産の場合、ミドルウェアスタック内のRack :: Deflater がActionDispatch :: Staticの前にロードされていることを確認してください。

したがって、あなたの見ているGZippingは、間違ったヘッダーか、他の場所から来ています。したがって、Cloudfrontにファイルをプッシュしただけの場合、同じことが表示されています。

CDNでジップアセットを提供することを検討している場合は、Rails 3.1に突き当たり、アセットパイプラインを使用することを検討することをおすすめします。これにより、資産をより詳細に管理できるだけでなく、serving them over a CDNへのパスも簡単になります。