Feature Request: Ability to configure cache_control and other headers on ActiveStorage uploaded objects

147 views
Skip to first unread message

Dimitri Roche

unread,
Oct 3, 2017, 4:52:01 AM10/3/17
to Ruby on Rails: Core
Right now files uploaded via ActiveStorage with the GCS Service default to

cache-control:
private,max-age=0

This is particularly problematic for Google Cloud CDN, since it only caches assets that are public: 
https://cloud.google.com/cdn/docs/troubleshooting

Cloud CDN caches only responses that are marked public and specify an expiration time or maximum age. This information is conveyed in HTTP response headers. If responses for a URL aren't being cached, check which HTTP headers are being returned for that URL.


ActiveStorage's architecture involves a 302 redirect to the underlying asset. Without a CDN for the GCS scenario, the performance implications of a highly trafficked site to also have to redirect wouldn't be stellar. But perhaps this is only a GCS problem, since I know AWS will cache content regardless of the cache-control header.

My proposed solution for this is to allow a developer to configure headers in the config/storage.yml on a per service basis:

google:
  service: GCS
  project: someproject
  keyfile: credentials.json
  bucket: bucket-of-assets
  object_options:
    cache_control: public, max-age=31556926


Ultimately, I believe developers will occasionally need a way to set headers on the files uploaded via ActiveStorage by the non Disk services. I would love to hear better alternatives if there are any.

Dimitri Roche

unread,
Oct 3, 2017, 11:09:42 PM10/3/17
to Ruby on Rails: Core
After further thought on the architectural decision to have image requests hit rails and then be redirected to cloud storage, I'm having second thoughts.

The scenario as is involves a page returning <img src=http://url.com/rails/active_storage/someasset.jpg /> tag that hits Rails and then redirects to cloud storage. It enables touted features like mirroring and lazy image processing (variants). It also means that image assets must now be served by Rails controllers, albeit as a redirect. My concern is the performance implications of having to hit Rails controllers to serve image assets, even as a redirect. It's not as ideal as having S3 or GCS serve up these image assets directly, offloading traffic from your rails server. The CDN will be critical in this scenario.

I feel like most people would prefer having image assets served directly by cloud storage over mirroring, which is a niche feature.
Reply all
Reply to author
Forward
0 new messages