curl saves the redirect response: follow Location and verify the final payload
By ON Lab · Sources checked November 8, 2026
For an HTTP download that responds with a redirect, curl --location follows the Location destination. Without that option, a successful transfer can save the redirect response body instead of the intended final file. Inspect the effective URL, final HTTP status and actual saved content before treating an output filename as proof of a correct download.
The historical reader wanted a download URL followed to its file destination in a batch workflow. We checked curl's current manual and built a harmless local GET endpoint returning a 302 followed by a plain-text payload. We did not test the reader's remote service, Windows batch syntax, authentication or JavaScript navigation.
Confirm whether this is an HTTP redirect
A web browser can reach another page through an HTTP Location response, an HTML instruction, JavaScript, an authentication flow or a user click. Those mechanisms are not interchangeable. The location option addresses supported HTTP redirects; it does not turn curl into a browser that runs arbitrary page scripts.
For a public URL you are permitted to inspect, record the status and response headers from the actual request. Avoid assuming a HEAD request behaves exactly like a GET download. Our fixture used GET for both comparisons, so the only change was whether curl followed the redirect.
What the local comparison showed
The first fixture endpoint returned status 302, a Location pointing to a second endpoint and a short body identifying the redirect response. The second endpoint returned status 200 and a different known payload.
| GET request | Response body received | Final status | Redirect count |
|---|---|---|---|
| Without --location | Redirect response marker | 302 | 0 |
| With --location | Expected payload marker | 200 | 1 |
Both curl processes exited successfully in this controlled example. The distinction was which response body they transferred, not whether the local network connection worked. We read the returned bytes and write-out metadata. A process success alone did not identify the intended file.
Save to a deliberate new output file
curl --location --output download-check.bin --write-out '
status=%{http_code} url=%{url_effective} redirects=%{num_redirects}
' 'https://example.com/reviewed-download'The URL is a placeholder, and the line continuation is POSIX-shell syntax. Choose a new output filename after checking it does not contain work you need. The command's output option selects where bytes are saved; it does not validate their file format or contents.
The write-out fields report the final status, effective URL and number of redirects followed. Compare them with the service's documented download flow. If a link unexpectedly reaches a login page with status 200, another redirect flag does not prove that you received the requested document.
For a known public file, verify a documented checksum or inspect the expected format and a small meaningful content check. A filename ending in .zip does not make an HTML page a ZIP archive. Do not execute a downloaded artifact merely because its transfer succeeded.
Separate redirect selection from HTTP error policy
Following a redirect and deciding whether HTTP errors should fail the command are separate choices. A final response can still be 404 or another error after a valid redirect. The HTTP status versus curl exit code guide covers the failure-policy options and version check.
Read the actual installed curl help before adopting a newer option. Preserve the first failing output. Adding unrelated switches until a command exits zero can hide the distinction among connection failure, redirect selection, HTTP status and payload validation.
If the download is still wrong
- Compare the initial request URL with the final effective URL.
- Check whether the redirect chain is finite and reaches the expected destination.
- Read the final status and content type as clues, then validate the bytes.
- Check the service's documented public download route rather than substituting a browser page URL.
- Keep login-dependent or permission-dependent responses separate from public redirects.
curl provides controls for redirect limits and which protocols are permitted during redirection. Choose them according to your environment's policy; do not assume every destination is an intended download just because a server supplied a Location header.
Credential forwarding across hosts and redirect behavior for non-GET requests require separate review. This guide does not recommend adding credential-forwarding options, changing request methods or disabling certificate verification to repair a wrong downloaded file. Our local evidence only establishes the GET redirect and payload distinction.
Checked November 8, 2026. The 302/200 comparison used a local temporary server, which was shut down after verification. Windows batch percent expansion, authenticated services, HTML/JavaScript redirects and the original reader's download were not reproduced.