Skip to content

Preserve original HTTP cache headers in sendurl

Sean McGivern requested to merge preserve-cache-headers-in-sendurl into master

There are a few cases for serving uploads:

  1. File storage. Rails asks Workhorse to serve the file.
  2. Object storage. Rails redirects (via SendFileUpload) to the object storage host.
  3. Object storage with proxy_download enabled. Rails asks Workhorse to proxy the download from the object storage host.

Rails also sets caching headers for uploads. In case 1, the reverse proxy will keep those headers. In case 2, the headers are whatever the object storage provider sets.

Case 3 is changed here. Previously, it would use the cache headers from the object storage provider. Now, it keeps the cache headers from Rails instead. This is better because:

  1. Cache headers on the object storage provider can be hard to configure.
  2. Even if we ask users to manually configure them, they may get it wrong and inadvertently allow private resources to be cached by proxies.
  3. Even if we ask users to manually configure them and they get it right, they will also need to track any updates the Rails application makes to the cache headers it sends.

We could solve these by trying to automatically set the metadata policy on the object storage bucket, which would also help with case 2 above. However, that has its own pitfalls. We could, for instance, say that uploads/-/system/user is public with an expiry of five minutes, and that's fairly straightforward. But then if we need to update that policy in future to make it public with an expiry of one minute, we are introducing coordination issues.

This would get even more complicated if we allowed caching uploads from public projects. If the project's visibility changed, we'd need to update the object storage metadata too. So it's a tricky problem, and this is a relatively small code change to at least solve one case.

For gitlab#32761 (closed).

Merge request reports