LFS downloads redirected to GCS does not set Content-Disposition
Downloads of LFS objects saved in Google Cloud Storage are saved by the browser with the hash as filename.
Steps to reproduce
- Setup a instance with GCS as LFS store.
- Upload files.
- Download files via web interface, the browser will ask file to be saved as "442e0c76ffb0b850e70f6889a7f4df77272daa6269691671912a1c4fb96c".
What is the current bug behavior?
Redirects to GCS don't include a
There is code to generate some, but it seems to be not always done.
What is the expected correct behavior?
Redirects to GCS should always include a
response-content-disposition parameter and provide the browser with a name to save the file under.
Output of checks
(If you are reporting a bug on GitLab.com, write: This bug happens on GitLab.com)
Results of GitLab environment info
Expand for output related to GitLab environment info
System information System: Debian 9.5 Current User: git Using RVM: no Ruby Version: 2.3.3p222 Gem Version: 22.214.171.124 Bundler Version:1.13.6 Rake Version: 12.3.1 Redis Version: 3.2.6 Git Version: 2.11.0 Sidekiq Version:5.1.3 Go Version: go1.10.3 linux/amd64
GitLab information Version: 11.1.2 Revision: 50bae62c38 Directory: /srv/salsa-test.debian.net/gitlab DB Adapter: postgresql URL: https://salsa-test.debian.net HTTP Clone URL: https://salsa-test.debian.net/some-group/some-project.git SSH Clone URL: firstname.lastname@example.org:some-group/some-project.git Using LDAP: no Using Omniauth: no
GitLab Shell Version: 7.1.4 Repository storage paths:
- default: /srv/salsa-test.debian.net/repositories Hooks: /srv/salsa-test.debian.net/gitlab-shell/hooks Git: /usr/bin/git
(If you can, link to the line of code that might be responsible for the problem)