我注意到，当serve_static_assets设置为false时，heroku会在Cedar上注入rails3_serve_static_assets中间件。我在上面找到的只是这个init脚本，它与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提供的，但在线文档。关于此事，Cedar上没有Varnish。
Cedar关于gzipped响应的文档（底部）指出：
由于对Cedar应用程序的请求是直接向应用程序服务器发出的，而不是通过像nginx这样的HTTP服务器代理的，因此必须在应用程序中压缩响应。
然而，我们可以清楚地看到，根据Content-Encoding，资产是gzip的。现在我很确定Rails 3.0.x没有启用Rack::Deflater（它无论如何都不会出现在rake middleware中），所以我有点困惑这个资产是如何gzip的。
这是我下一个关于通过Cloudfront服务这些资产的问题的指针，但我的问题是：
有人能解释一下Cedar re静态资产到底发生了什么吗。也就是说，什么服务于我的资产（Rails、Ngnix、Varnish？），什么是gzip？
如果你在你的头中看到Varnish，这意味着你的域CNAME指向了proxy.heroku.com，而不是proxy.horokuapp.com-Cedar上没有Varnish但如果你使用proxy.heroku.com，你会看到返回的头，它会起作用，但这只是一个传递。他们将由nginx提供服务。
用于Bamboo和Cedar堆栈的堆栈是相同的，只是有一个区别，那就是Cedar上的清漆缓存不是"活动的"。这是因为Cedar支持流媒体，而Varnish不支持流媒体。
因此，您的资产来自Rails流程。对于Rails 3.0，这些文件显然只是普通的旧文件。如果您在Rails3.1上使用Asset管道，rake assets:precompile过程将为您生成文件的gzip版本并为这些文件提供服务。