What is a Media URL?
A media URL identifies an image, video, audio file, manifest, or generated rendition at a network endpoint. Its path and query parameters may select a source asset, transformation, or delivery policy.
How Media URLs work
A media URL is the address through which a client retrieves an original file, a rendition, a segment, or a streaming manifest. The server decides what each part means: commonly the path identifies the asset and query parameters carry transformation settings or a signature. The URL does not settle the format of the response. HTTP’s Content-Type header states the media type, so the file extension in a path does not decide what a client receives. Other response headers govern caching, byte-range delivery, and cross-origin use. A streaming manifest adds one more layer, because it is a file of further URLs: in HLS, a relative URI inside a playlist is resolved against the URL of the playlist that contains it, so the manifest URL determines where a player looks for segments.
Key facts
- 1Is the query string part of the cache key? It depends on the CDN and its configuration, so check before putting transformation parameters there. HTTP defines a cache key as, at minimum, the request method and target URI. Cloudflare’s default key includes the full URL with its query string. Amazon CloudFront’s default key contains only the distribution’s domain name and the URL path, so two URLs that differ only in a parameter such as
?w=return the same cached object until a cache policy adds that parameter to the key. Adding a parameter that does not change the response has the opposite cost: CloudFront warns that it can cache duplicate objects and lower the cache hit ratio. - 2Does a video or audio file URL need a server that supports byte ranges? For seeking on iOS, yes: Apple’s archived Safari guidance states that servers hosting media files for iOS must support byte-range requests, which iOS uses for random access during playback. MDN describes range requests more generally as useful to media players that support random access. HTTP itself makes range requests optional, and a server may ignore the
Rangeheader and answer 200 with the whole file. A CDN can add conditions of its own: CloudFront returns the entire object instead of the requested range when the origin answers withTransfer-Encoding: chunked. Send a ranged request to the public URL, not only to the origin, and expect a 206 response with aContent-Rangeheader. - 3What happens to segment URLs when an HLS manifest URL is signed? A signature in the manifest’s query string is not carried over to them. Relative segment URIs are resolved against the playlist URL, and standard URI reference resolution keeps the query of the relative reference, not that of the base URL, so segment requests arrive without the signature unless the playlist is rewritten per viewer or access is granted another way. Amazon CloudFront’s documentation recommends signed cookies instead of signed URLs for giving access to multiple restricted files, and names all the files of an HLS video as its example.
- 4Can the bytes behind a URL change? If they can, a cache that holds the earlier response may keep serving it for as long as it is fresh, so give the response a short freshness lifetime or require revalidation when updates must become visible promptly. Publishing each version under a new URL avoids the problem: RFC 8246 describes versioned URLs as the pattern that allows a very large freshness lifetime without guessing when a resource will be updated, and MDN recommends a long
max-agefor URLs that include a version number or hash.
When Media URLs matter
Return stable media URLs when clients embed assets in pages, players, or API responses. A signed URL limits access. When it carries an expiry, requests made after that time are refused, so it does not suit long-lived references, and each new signature is a new URL to any cache whose key includes the full query string.
How Transloadit helps with Media URLs
Transloadit hands out media URLs in two ways. Each result file in an Assembly Status carries a url and an ssl_url. When a result is exported with a storage Robot such as /s3/store, the Assembly Status returns the URL of the file in your bucket. That URL locates the stored object, but it does not make a private object public or grant read access, so publish it only where viewers are allowed to read the object, and otherwise publish an authorized storage or CDN URL for it. URLs on Transloadit’s temporary storage are removed automatically and are documented as not for serving end users. A Smart CDN URL has the form https://[your-workspace].tlcdn.com/[template-name]/[file-path]?[parameters]: the Template name and file path select the workflow and the original, and the query parameters reach the Template as transformation settings. It can be signed with an exp expiry and a sig signature, and the effective cache lifetime of a signed response is bounded by the remaining signature lifetime.
For Smart CDN responses, the /file/serve Robot’s documented default headers include Accept-Ranges: bytes and a Content-Type taken from the file’s detected MIME type.
Sources
- RFC 9110: HTTP Semantics (Content-Type, section 8.3; range requests, section 14)
- RFC 9111: HTTP Caching (cache keys, section 2)
- Cloudflare: cache keys and the default cache key
- Amazon CloudFront: understand the cache key
- Amazon CloudFront: how partial requests (range GETs) are processed
- Apple Safari Web Content Guide (archived): configuring your server for byte-range requests
- MDN: HTTP range requests
- RFC 8216: HTTP Live Streaming (relative URIs in playlists, section 4.1)
- RFC 3986: URI Generic Syntax (reference resolution, section 5.2.2)
- Amazon CloudFront: decide to use signed URLs or signed cookies
- RFC 8246: HTTP Immutable Responses (versioned URLs)
- MDN: HTTP caching (cache busting with versioned URLs)