Add `send-scaled-img:` handler for Workhorse
What does this MR do?
We are currently exploring solutions to auto-scaling images on GitLab. While we haven't made a final decision yet which exact approach we will take, one promising avenue is to do this on-the-fly, whenever the frontend/client requests a particular width for an image to be returned.
Most of the heavy lifting is done in workhorse, but we need a Rails handler to authenticate the request, do a couple sanity checks (such as is a correct width provided) and render out the respective instructions for workhorse to then act on this request.
The workhorse changes are still in progress, but it is safe to ship the Rails changes already, as they are feature-flagged and gated to specific users for whom we will enable this functionality. This would make it a lot easier as well for us to experiment with this feature on an ongoing basis. If we decide to use a different approach, it is easy enough to drop it again.
For this to work, workhorse must implement an injecter for send-scaled-img
. There is a proposal for how to do that here: gitlab-workhorse!546 (merged)
This MR should not be blocked on the particular WH implementation, however, as long as it is behind a user-gated feature flag.
Implementation
We use a similar approach to the send_url
feature. Upon receiving a request for an upload
entity, we first check whether it is an image file, and whether a width was requested. If so, we:
- construct
Gitlab-Workhorse-Send-Data
header with the newsend-scaled-img
command, including- the location of the image file (can be local or remote)
- the requested width
- render
200 OK
to workhorse - workhorse recognizes the header, unrolls the parameters embedded in it, reads the image file, resizes it and renders it out to the client
Feature flag
dynamic_image_resizing
- Issue: #233704 (closed)
Screenshots
Before
After
Does this MR meet the acceptance criteria?
Conformity
- [-] Changelog entry Highly experimental and behind feature flag, so we will not announce this yet.
- [-] Documentation (if required)
-
Code review guidelines -
Merge request performance guidelines -
Style guides - [-] Database guides
- [-] Separation of EE specific content
Availability and Testing
-
Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process. - [-] Tested in all supported browsers
- [-] Informed Infrastructure department of a default or new setting change, if applicable per definition of done
Security
Security team is already involved in this epic via https://gitlab.com/gitlab-com/gl-security/engineering/-/issues/1043
-
Label as security and @ mention @gitlab-com/gl-security/appsec
-
The MR includes necessary changes to maintain consistency between UI, API, email, or other methods -
Security reports checked/validated by a reviewer from the AppSec team