Skip to content

Knowledgebase

Serving large file downloads without tying up workers

development

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.

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

  1. Authorize access in the application before generating a private download response. Check the requested resource belongs to the user or permitted role.

  2. For supported local delivery, use an internal web-server handoff configured by the administrator. Keep the protected file location inaccessible through ordinary public URLs.

  3. For object storage, use an appropriately scoped, short-lived signed delivery mechanism where the provider supports it.

  4. Set a safe download filename and content type. Support the required size, timeout and resume behavior without exposing arbitrary filesystem paths.

  5. 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.

Code or configuration example
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:

Code or configuration example
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.

Was this answer helpful?

Need a little more help?

Our support team can help you find the next step.

Contact support