Dropbox URL formats as shorthands/favorites passed as --link-* argument

[porg]

Goal

• Define certain Dropbox base URL formats (shorthands/favorites which include a certain form of: subdomain, domain, path, arguments) reflecting the officially supported Dropbox URL patterns which one can pass as script arguments.
• That way one could create different keyboard shortcuts which point to different Automator scripts which call get_dropbox_link with different arguments.
• Argument syntax would be --link-<shorthand> or --link=<shorthand>.
• Then on top of that you can still modify the --query with optional #3.

Dropbox /s/ link formats

--link-preview

https://www.dropbox.com/s/<identifier>/filename.png

--link-download-argument

https://www.dropbox.com/s/<identifier>/filename.png?&dl=1

--link-download-subdomain

https://dl.dropbox.com/s/<identifier>/filename.png

--link-raw-redirect

https://www.dropbox.com/s/<identifier>/filename.png?&raw=1

• HTTP 302

--link-raw-direct

https://dl.dropboxusercontent.com/s/<identifier>/filename.png>

• HTTP 200

Dropbox /scl/ link formats

--link-scl-preview

https://www.dropbox.com/scl/fi/<identifier>/filename.png?rlkey=<content-key>&dl=0

--link-scl-download

https://www.dropbox.com/scl/fi/<identifier>/filename.png?rlkey=<content-key>&dl=1

• Safari: Fails sometimes, cause yet unknown: Either too many redirects or browser caching issue.
• wget <url> → Creates ugly filename (the last URL part as is).
• wget -content-dispositon <url> → Creates intended filename (passed via HTTP Content-Disposition header)

--link-scl-raw-redirect

https://www.dropbox.com/scl/fi/<identifier>/filename.png?rlkey=<content-key>&raw=1

• HTTP 302

--link-scl-raw-direct

https://dl.dropboxusercontent.com/scl/fi/<identifier>/filename.png?rlkey=<content-key>

• HTTP 200

[nk9]

Thank you for the suggestion. However, the named link styles would involve parsing the returned link to pull out the item code and then constructing a link. That would add a lot of complexity to the code, and is frankly just more work than I am prepared to put into this project, for very limited benefit. If I understand correctly, all of the various behaviors (not link styles, but behaviors) can be achieved using different combinations of link arguments. So this is purely about link aesthetics.

If you need the links fetched by this tool to be formatted differently, you can use sed or your own script to modify them to suit your purposes.

As for the new scl link style, it seems premature to put work into supporting it when it may be modified, or even abandoned.

[porg]

1. Totally agree it is premature to care about /scl/ links - Let's consider that only should they "re-surface again".
2. The proposal is not only about link aesthetics, but in one case also a real functional difference:
   • The HTTP 200 type links are not achievable via www.dropbox.com + arguments.
   • But only via dl.dropboxusercontent.com
   • And some forums restrict links and or embedding if that link redirects.
   • So maybe do you re-consider those formats?