We're making changes to the Community, so you may have received some notifications - thanks for your patience and welcome back. Learn more here.
Forum Discussion
Shared Link / "scl" to "s"
Hello. My question concerns my recent issue with file sharing. Usually, my links were generated in this way: 'https://www.dropbox.com/s/'. However, lately, every file is being generated in this way: ...
Direct Download on new link architecture is Solved
What is the DL parameter?
- Default link. This will render the content in the Dropbox file viewer.
- Downloads the content of the link (if the user has access to the content based on link settings). This query parameter takes precedence even if raw=1 is also added.
- Directly renders the content in the browser (if the link has a public audience and no other restrictions). Note that this link has an HTTP 302 redirect, so the application or browser must be able to follow the redirect.
What are the dl.dropbox... modifications?
These are link transformations from the early days of Dropbox. While we don't "officially" list these anymore in our Help Center, we are continuing to support them for now.- Replacing www with dl works exactly like a ?raw=1 link: this will directly render content for public links in the browser. It requires following an HTTP 302 redirect.
- Works like a ?raw=1 link, but the application or browser will not need to follow an HTTP 302 redirect to access the content.
First some sad honest truth: Your New Link API partial rollout was nothing less than a disaster. So many complaints and hundreds of integrations which stopped working. For a company your size I don't understand how such an unthoughtful rollout could happen.
Now to some concrete feature request WITHIN that new landscape:
As a Dropbox user I want my URL to be
- as short as possible
- as beautiful and transparent as possible (as few arguments as possible, if then with short variable names and short values)
- if you insist on the rlkey then put it after the identifier token, but not as an argument, which are always at the end of a URL!
- To be a psychologically trustworthy link the "…-file-name-end.suffix" should still be visible for abbreviated URLs (in some device/usage contexts users only see an abbreviated URL! If that's "cryptic stuff" only, and no "…fileend.suffix" in sight anymore, it becomes distrustful.)
- provide a possibility for URLs without a rlkey, like in elder versions everything in ~/Dropbox/Public/ defaults to read:everybody, then no need for a key
- no redirects (or as few as possible) for reliable embedding
- browser caching working reliable
URL pattern general
https://dropbox.com/scl/<options>/<identifier>/<content-key>/file-anywhere.png
For a file within ~/Dropbox/Public/ which gets a "totally easygoing treatment":
https://dropbox.com/scl/<options>/<identifier>/file-within-dropbox-public.png
options: n | dl | raw
- n as in normal (or a similar short/intuitive flag, e.g. "p" as in preview)
- dl as in dl=1
- raw as in raw=1
As these are binary toggles and anyhow mutually exclusive only one of them will be at its token position. Totally intuitive.
Options could also be the last part before the filename.
You have to do usability and best practise research yourself, how URLs are abbreviated in most software/device contexts. To my knowledge:
- Start… — Not too common I think.
- Start…End — Common — Options at the beginning plus filename at the end are readable. That's the abbreviation which is least prone to URL hacks, but ofc there are still tricks like legit-sounding-subdomain.com.malicious.domain/badvirus.exe?f=bogus-but-innocent-sounding-filename-towards-the-end.jpg . But overally this is the most balanced/common one AFAIK.
- …End — Also Common — Then options and filepath as the last tokens would be ideal.
