I ran into the following problem:
The file is a plain .html file and I am using a simple GET request.
Shouldn't the Access-Control-Allow-Origin header automatically be included when I share a file so that it can be downloaded? As it is now, I can't use Dropbox to share my files with others.
Links take you to a generated preview page, and not the file so I wouldnt have expected a link to work right off.
You can try adjusting the links end from ?dl=0 to ?dl=1 as this changes the link to an immediate download of the file, which I would suspect is what you were expecting.
Thanks for the answer. I actually tried it with ?dl=0 and ?dl=1 and either produces the same error. It's not that the content is wrong, but the CORS header is not set correctly even when sharing a link.
We don't currently set the Access-Control-Allow-Origin header on shared links like this, but I'll be sure to pass this along as a request.
For now I found a 'hacky' workaround by replacing the domain in the passed in link, 'www.dropbox.com', with 'dl.dropboxusercontent.com'. Using that domain the Access-Control-Allow-Origin header is set correctly. But I don't know if Dropbox continues to allow that in the future.
And speaking of links: When using the Dropbox App on IOS to copy a link to clipboard, the link is apparently placed on the clipboard with Mime Type 'text/html' as a html element. However, this creates a problem when trying to paste that link into a text input or textaera element in IOS Safari. IOS Safari only accepts text/plain clipboard content on those elements and therefore a Dropbox generated link can't be pasted. I know, not the fault of Dropbox, but annoying nevertheless. My workaround (if others run into the same problem) is instead of using a text-input or textarea element to paste the link in, use a DIV element with contenteditable set to true. Not a preferred solution because IOS Safari's clipboard functionality behaves very flaky with contenteditable elements.
We do recommend using the URL parameters whenever possible, but since that doesn't work in your case your workaround is likely the only solution right now.
And thanks for your feedback regarding the iOS interaction. I'll send that along to the right people.
I ran into the same problem. Using the dl.dropboxusercontent.com domain allows access with pdfjs, but the officially documented URL (www.dropbox.com) does not work. The reason might be that the 302 call from dropbox does not include the CORS headers, despite the presence of the Origin header in the original request.
I've been using the "dl.dropboxusercontent.com" method as described by Klaus above to access a shared file in my Dropbox with a GET request from a different domain.
However, just now it stopped working and it throws a timeout error.
I'm guessing Dropbox have finally stopped supporting dl.dropboxusercontent.com?
Is there any chance that you'll set the Access-Control-Allow-Origin header on shared links, as Greg mentioned above (more than a year ago)?
Never mind, it seems to be working again, for now.
Would be nice to get this sorted officially though. We'd only need CORS headers for the shared links.