我注意到当rails3_serve_static_assets设置为false时，heroku会在Cedar上注入serve_static_assets中间件。我在此发现的所有this init script都与Heroku部署中提到的名称相匹配，所有这一切都重新启用了静态资产的提供。
我试图找到有关Heroku如何提供这些资产的更多信息，因为他们似乎并不是直接来自Rails应用程序。
例如，当我查看js文件的标题时，它们看起来像这样：
Age:0
Connection:close
Content-Encoding:gzip
Content-Type:text/css
Date:Sun, 08 Jan 2012 19:04:05 GMT
Last-Modified:Sat, 07 Jan 2012 23:43:30 GMT
Server:nginx/0.7.67
Transfer-Encoding:Identity
Via:1.1 varnish
X-Varnish:677359987
我假设Via:1.1 varnish表示这些资产是通过Varnish提供的，但是the online documentation。在这个问题上说，Cedar上没有Varnish。
gzip响应的Cedar docs（底部）指出：
由于对Cedar应用程序的请求直接发送到应用程序服务器 - 不通过像nginx这样的HTTP服务器代理 - 任何响应压缩都必须在您的应用程序中完成。
但是，根据Content-Encoding，我们可以清楚地看到资产是gzip＆＃d; dd。现在我已经相当肯定 Rails 3.0.x没有启用Rack::Deflater（它无论如何都不会出现在rake middleware中）所以I＆I ＃39;有点混淆这个资产是如何被gzip＆＃39; d。
这是my next question关于通过Cloudfront提供这些资产的前提，但我的问题是：
有人可以准确解释Cedar re：静态资产的情况。也就是说，什么是我的资产（Rails，Ngnix，Varnish ??）以及什么是gzip＆＃39;它们？
答案 0 :(得分：3)
如果您在标题中看到Varnish，则意味着您的域名CNAME指向proxy.heroku.com而不是proxy.herokuapp.com - Cedar上没有Varnish但是如果您使用，则会看到标题返回proxy.heroku.com它会工作，但它只是一个传递。他们将由nginx提供服务。
答案 1 :(得分：0)
用于Bamboo和Cedar堆栈的堆栈是相同的，除了一个区别，即清漆缓存在Cedar上不是“活动”。这是因为Cedar支持流媒体，这是Varnish所不具备的。
因此，您的资产将来自您的Rails流程。使用Rails 3.0，这些显然只是普通的旧文件。如果您在Rails 3.1上使用资产管道，rake assets:precompile进程将为您生成文件的gzip压缩版本并提供服务。