Users downloading non-ASCII attachments would see garbled characters.
When used with object storage, AWS S3 would return an InvalidArgument
error: Header value cannot be represented using ISO-8859-1.
Per RFC 5987 and RFC 6266, Content-Disposition should be encoded
properly. This commit takes the Rails 6 implementation of
ActiveSuppport::Http::ContentDisposition
(https://github.com/rails/rails/pull/33829) and ports it here.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/47673
There were several issues:
1. With Google Cloud Storage, we can't override the Content-Type with
Response-Content-Type once it is set. Setting the value to
`application/octet-stream` doesn't buy us anything. GCS defaults to
`application/octet-stream`, and AWS uses `binary/octet-stream`. Just remove
this `Content-Type` when we upload new files.
2. CarrierWave and fog-google need to support query parameters:
https://github.com/fog/fog-google/pull/409/files, https://github.com/carrierwaveuploader/carrierwave/pull/2332/files.
CarrierWave has been monkey-patched until an official release.
3. Workhorse also needs to remove the Content-Type header in the request
(ef80978ff8/internal/objectstore/object.go (L66)),
or we'll get a 403 error when uploading due to signed URLs not matching the headers.
Upgrading to Workhorse 6.1.0 for https://gitlab.com/gitlab-org/gitlab-workhorse/merge_requests/297
will make Workhorse use the headers that are used by Rails.
Closes#49957
If you upload a file with a .js extension, Rails' cross-origin JavaScript
protection will prevent a user from downloading the file with a 422 error.
Setting the content-type to `text/plain` will allow the user to download
the file as a plaintext file.
Closes#45826
Stan Hu