Set Cache-Control headers for assets #401
Comments
|
It may be possible/preferable to reuse the |
|
@wireframe that sounds like a great alternative! Are you familiar enough with ActionDispatch::Static to create a PR? |
|
@wireframe I've thought about this further. While we'd gladly accept a PR that implemented this functionality, it might not be necessary. We encourage users to serve their assets over a CDN configured to pull from the Rails app. This means that after the initial pull from origin, the Rails application would no longer serve the fingerprinted assets. This limits the impact of Content headers (which are ultimately overwritten by the CDN) to a single request per asset. |
|
Closing this issue for now. If you feel strongly about introducing |
|
@seanpdoyle every CDN that i've worked with (cloudfront/fastly) acts as a reverse proxy to load resources from rails and then caches them on their edge servers. The duration of the cache relies 100% on the cache headers sent from the origin server (ie: rails) so the cache headers are extremely important in order to take full advantage of your CDN. The thoughtbot blog you linked to actually explains this in detail. If rails isn't setting the "Cache-Control" header, your CDN will only cache that asset for a fairly short time and the benefit is very limited. If you're CDN experience is different, I'd love to hear it, but this seems like a pretty standard flow for vanilla rails apps assets + CDN's. |
|
@wireframe thanks for clarifying, those are some good points. I'll reopen this issue. |
Closes [#401]. Previously, requests for Ember assets were being proxied through `EmberCli::Deploy::File` Rack middleware without the HTTP `Cache-Control` header. Ember `production` builds digest the filenames of images/css/js/etc. This makes these files highly cachable. This commit configures the underlying `Rack::File` middleware to serve assets with the `Cache-Control` header set by Rails. [#401]: #401
|
@wireframe I've pushed #403. Please weigh in there. |
Closes [#401]. Previously, requests for Ember assets were being proxied through `EmberCli::Deploy::File` Rack middleware without the HTTP `Cache-Control` header. Ember `production` builds digest the filenames of images/css/js/etc. This makes these files highly cachable. This commit configures the underlying `Rack::File` middleware to serve assets with the `Cache-Control` header set by Rails. [#401]: #401
Closes [#401]. Previously, requests for Ember assets were being proxied through `EmberCli::Deploy::File` Rack middleware without the HTTP `Cache-Control` header. Ember `production` builds digest the filenames of images/css/js/etc. This makes these files highly cachable. This commit configures the underlying `Rack::File` middleware to serve assets with the `Cache-Control` header set by Rails. [#401]: #401
Closes [#401]. Previously, requests for Ember assets were being proxied through `EmberCli::Deploy::File` Rack middleware without the HTTP `Cache-Control` header. Ember `production` builds digest the filenames of images/css/js/etc. This makes these files highly cachable. This commit configures the underlying `Rack::File` middleware to serve assets with the `Cache-Control` header set by Rails. [#401]: #401
Requests for ember assets are being proxied through the
EmberCli::Deploy::Filerack middleware, but does not set any of the HTTP cache control headers from rails.Since ember production builds automatically digest the filenames of images/css/js/etc, these files are highly cachable, and should support the standard HTTP caching headers in some way (ex: rails
static_cache_controlconfig).The text was updated successfully, but these errors were encountered: