Skip to content

G
gitlab-workhorse
Switch branch/tag
  1. 27 Nov, 2019 2 commits
  3. 21 Nov, 2019 1 commit
  5. 20 Nov, 2019 1 commit
  7. 19 Nov, 2019 2 commits
  9. 11 Nov, 2019 2 commits
  11. 05 Nov, 2019 2 commits
  13. 25 Oct, 2019 2 commits
  15. 15 Oct, 2019 3 commits
  17. 14 Oct, 2019 1 commit
  19. 11 Oct, 2019 4 commits
  21. 10 Oct, 2019 4 commits
  23. 09 Oct, 2019 2 commits
  25. 07 Oct, 2019 2 commits
    • Nick Thomas's avatar
      Merge branch 'preserve-cache-headers-in-sendurl' into 'master' · 560ad42f
      Nick Thomas authored 
      Preserve original HTTP cache headers in sendurl

See merge request gitlab-org/gitlab-workhorse!428
      560ad42f
    • Sean McGivern's avatar
      Preserve original HTTP cache headers in sendurl · cfd8e4e8
      Sean McGivern authored 
      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.
2. 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.
      cfd8e4e8
  27. 30 Sep, 2019 4 commits
  29. 26 Sep, 2019 2 commits
  31. 12 Sep, 2019 6 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7