Video & subtitles · Direct Media Downloader
Where a downloaded file's name comes from: URL path vs Content-Disposition
· How it works
http downloads media
Explains how a browser decides what to call a saved file: the last segment of the URL, the server's Content-Disposition header, and the download attribute a tool can set. Shows why a clean URL sometimes still yields a bad filename.
The file saved as 'file.php' and will not open — the naming problem that a direct link can hide
A URL ending in `file.php?id=42` can deliver video bytes while leaving the browser with an unhelpful path name. Conversely, an address ending in `.mp4` can return HTML. A filename is a label chosen from request and response metadata, not proof about the payload inside.
Direct Media Downloader calculates a suggested name only after a successful GET response arrives. It checks Content-Disposition first, then the last non-empty path segment, then a small MIME-based fallback. This order is narrower and more predictable than claiming the browser performs a universal negotiation. This separation prevents temporary authorization material from leaking into a disk name and avoids illegal filename characters contributed by an entire query string.
The last path segment: the default guess — how the browser reads the filename from the URL and where query strings confuse it
The path candidate is the final segment after slash separation, decoded from percent encoding. Query parameters are not included because the URL API stores them separately. Thus `/episodes/launch.mp3?token=...` yields `launch.mp3`, while a trailing slash has no final segment and needs another source.
This path rule does not decide whether an extension is honest. A signed delivery route can hide the human title in a parameter, and this implementation will not mine arbitrary query keys for names. That restraint avoids mistaking a signature component, campaign value, or record identifier for a filename. When both forms exist, the internationalized form can preserve non-ASCII names more clearly, while the fallback handles simpler server implementations.
Content-Disposition: the server's suggestion — how a header can override the URL's name and why some CDNs set it and others do not
Content-Disposition can carry a plain `filename=` suggestion or an encoded UTF-8 `filename*=` form. ToolAcre gives the encoded star form precedence and attempts percent decoding; if decoding fails, it falls through to the plain form and then to path logic rather than crashing the completed transfer.
The header is merely the serving host’s suggestion. Application code does not inspect media metadata to verify it, and a misleading server can provide a misleading name. Review unusual characters and extensions before opening a file, especially when the source host is unfamiliar. Object URLs are temporary browser references, not remote addresses, and their use does not create another upload or HTTP request for the media body.
The download attribute: what a tool can set itself — how a browser-side downloader can choose a name for the Blob it saves
After the Blob is ready, the UI passes both Blob and selected filename to the shared download utility. That utility triggers the browser save behavior with an object URL and download name. The server’s header is no longer consulted at that final click because its suggestion was already resolved.
This mechanism does not rename an existing disk file or choose a folder. Browser settings still determine whether a dialog appears and how duplicate names are handled. ToolAcre supplies one candidate; the browser and visitor remain responsible for the final filesystem result. Users should resist “fixing” a mismatch by renaming alone; inspect the actual container and codecs before deciding whether metadata or content needs correction.
Extensions and MIME types: keeping them consistent — why a file called .mp4 that is really WebM confuses players
An `.mp4` name paired with `video/webm` can confuse software that routes by extension, even though a capable player may inspect the bytes. ToolAcre preserves a path or header name rather than rewriting its extension to match Content-Type. It also preserves the server MIME value on the Blob.
If no header and no path segment exist, the fallback recognizes a Content-Type containing WebM or MP4 and returns `download.webm` or `download.mp4`; every other type becomes `download.bin`. Audio MIME values do not currently receive a special extension through this last-resort branch. If a signature expires between HEAD and GET, no filename wins because the body request fails; naming begins only after a successful readable response.
Worked example: one signed CDN link and three possible filenames — walking through which name wins and why
Take a signed CDN address whose path ends in `asset`, whose response says `filename*=UTF-8''approved%20cut.mp4`, and whose type is `video/mp4`. The encoded header wins, producing `approved cut.mp4`. Remove the header and the path yields `asset`; remove that segment too and MIME fallback yields `download.mp4`.
A plain `filename="review.webm"` would win when no usable star value exists, even if the path says `clip.mp4`. The example shows precedence, not validation. Inspecting Content-Type and opening the saved result in trusted software remain separate checks after the name is chosen. A catalogue can additionally record a checksum after saving, but hashing is outside this downloader and should not be implied by its displayed byte count.
What this does not cover — renaming after download, batch naming, or reading metadata inside the file to name it
The downloader does not batch-number files, read title tags from a media container, clean an archive catalogue, or repair a misleading extension after saving. It also cannot promise that every Content-Disposition grammar variation will match its focused regular expressions.
Renaming later is an operating-system task. If archival naming matters, record the source URL, response type, byte count, and approved descriptive name in your own catalogue. Do not treat a convenient header as provenance or a filename extension as a cryptographic identity. Malformed percent encoding in a path is another host-quality problem; the current fallback does not claim to sanitize every server-provided name into every operating system’s rules.
Takeaway: the name is a negotiation between URL, header and tool — what to check in the saved file's name and extension after using the Direct Media Downloader
The implemented precedence is concrete: valid UTF-8 star filename, plain filename, decoded final path segment, then `download.webm`, `download.mp4`, or `download.bin`. Query strings can authorize delivery without becoming part of the saved name. This explains many “download” and “index” surprises.
After using Direct Media Downloader, compare name, extension, Content-Type, expected source, and actual playability. These observations answer different questions. A clean filename improves handling, but only the host’s bytes and the receiving application determine what the file truly contains. Filename selection improves usability, while provenance still comes from the authorized source, recorded request, and independent inspection of the completed bytes.