A large download can occupy an application worker for much longer than the authorization decision takes. A supported web-server or storage-service handoff can deliver the file more efficiently.
IN THIS ARTICLE
What you need before you begin
Classify the file as public or private and confirm the hosting stack supports the chosen delivery mechanism. Identify range-request and download-expiry requirements.
01 Serve large file downloads without tying up workers
Authorize access in the application before generating a private download response. Check the requested resource belongs to the user or permitted role.
For supported local delivery, use an internal web-server handoff configured by the administrator. Keep the protected file location inaccessible through ordinary public URLs.
For object storage, use an appropriately scoped, short-lived signed delivery mechanism where the provider supports it.
Set a safe download filename and content type. Support the required size, timeout and resume behavior without exposing arbitrary filesystem paths.
Test concurrent downloads and observe application worker availability. Keep audit information limited to safe identifiers.
02 Example: hand an authorized file to an internal Nginx location
An administrator can adapt this Nginx server-block fragment in staging when the stack supports X-Accel-Redirect. The directory is illustrative and must contain only the intended private downloads.
location /private-downloads/ {
internal;
alias /srv/example-app/private-downloads/;
}
After authenticating the user and checking ownership of the requested report, the application can return a mapped internal path such as:
X-Accel-Redirect: /private-downloads/report-1042.pdf
Choose that path from a trusted application record, not by concatenating an arbitrary requested filename. Supply the intended content type and safe download disposition. Validate the configuration before applying it through the server's normal process.
Expected result: the authorized application request delivers the file through Nginx, while a direct external request to /private-downloads/report-1042.pdf is rejected. Confirm this negative test and worker availability before serving real customer files.
Confirm the expected result
Confirm the intended user can download the file and an unauthorised user cannot bypass the application by copying an internal path. Test an expired signed link where applicable.
Troubleshoot unexpected results
If downloads still consume all application workers, verify that the handoff is actually active. A header unsupported by the server may not produce the intended behavior.
A common question
Is every signed URL private forever?
A signed URL normally grants access according to its scope and lifetime. Anyone who obtains it may be able to use it until it expires, so choose those limits carefully.