I’ve noticed that heroku injects a rails3_serve_static_assets middleware on Cedar when serve_static_assets is set to false. All I’ve found on this is this init script that matches the name mentioned on Heroku deploy, and all it does it re-enable the serving of static assets.
I’m trying to find more information on how Heroku serves up these assets, because they don’t appear to just come straight from the Rails app.
When I look at the headers of a js file, for instance, they look something like this:
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
I’m assuming the Via:1.1 varnish means these assets are being served through Varnish, but the online documentation. on the matter says that Varnish is not available on Cedar.
The Cedar docs on gzipped responses (bottom) states that:
Since requests to Cedar apps are made directly to the application server – not proxied through an HTTP server like nginx – any compression of responses must be done within your application.
However we can clearly see that the asset is gzip’d according to the Content-Encoding. Now I’m fairly certain Rails 3.0.x doesn’t have Rack::Deflater enabled (it doesn’t show up in rake middleware anyway) so I’m a bit confused as to how this asset is being gzip’d.
This is sort of a pre-cursor to my next question regarding serving these assets through Cloudfront, but my question here is:
Can someone explain exactly what is happening on Cedar re: static assets. Namely, what is serving my assets (Rails, Ngnix, Varnish ??) and what is gzip’ng them?
If you’re seeing Varnish in your headers it means that you have your domains CNAME pointed at proxy.heroku.com and not proxy.herokuapp.com – there is no Varnish on Cedar but you will see headers returned if you use proxy.heroku.com and it will work but it’s merely a pass through. They will be being served by nginx.