We are aware of the issue with the badge emails resending to everyone, we apologise for the inconvenience - learn more here.
Forum Discussion
raw=1 stop working in safari. Why?
I am using raw=1 to render images in the website I built, the images were working fine on every browser util yesterday (08/09/2023), and now stop working on safari. Does anyone experience the same thing?
We just released the fix for the issue on Safari with "raw=1" links. Please let us know if you still have any issues.
lisadbxDropbox Engineer
Solution in Progress
We have confirmed the issue is limited to Safari and we will have a fix out shortly.
I agree, though no idea where to start in approaching Apple about it, or what to say. Are you able to give me any technical description of what happens when we change that suffix? I read something about it forcing a redirect (though I don't understand how that would work in this type of situation).
- Jay
Dropbox Staff
Depending on the shared links used, there may be a redirect used. This thread shows more information on recent changes made to shared links.
Hi All, Same issue here. Safari just showing blank screen for a raw=1 image
Chrome and Firefox loading properly.
Seems like a Safari issue but I can't see what changed around Aug 9th. Was there an update to Safari around then? I don't see evidence of a software update.
It appears Dropbox has changed their share link structure by embedding a key into the share link. For some reason, since this change has occurred, we have noticed that shared pdf files set to open directly (by changing dl=0 to raw=1), open as blank pages on iOS safari. If the Dropbox app is installed, the files open in Dropbox directly just fine. Links also work in Chrome and Edge desktop just fine.
We do not want to have to have user install Dropbox to share pdf's however. Anyone else experiencing these issues, and is their a structural change to the link we can make to correct?Thank you for the solution. My only hang up with using the "dl.dropboxusercontent" is that it sounds as if it's a deprecated endpoint. Furthermore, this path causes pdfs to download vs display directly in some browsers. Is there a plan to fix the redirect issue with Safari that is being caused by the new links? I would prefer to not use any deprecated endpoints that are not supported with current documentation long term, lest the next guy has to navigate old threads to determine why we are using an undocumented endpoint.
I appreciate the work around.
I have also struck this problem. It still works in Firefox and Chrome, but on Safari I just get a blank screen. When working on a newsletter and adding code to embed an image, again with the raw=1 suffix, the preview works on those alternative browsers but I get just the little broken image icon on Safari.
I have temporarily turned off the content blocker for Safari and a separate pop-up blocker, but that has made no difference.
Hello all, I tried the thread that links to links to this thread, and safari started working again by modifying using dl.dropbox.com or dl.dropboxusercontent.com.
Hope this helps!
My previous message was falsely reported as spam.
Again with fewer links to hopefully not get flagged false positive again.
I experienced this bug in the wild in this WordPress forum thread that I started:
1) In my initial post on top
dropbox.com /scl/fi/<identifier>/<filepath1>?rlkey=XXX2) a+b) In my second post I used 2 links with this pattern
dl.dropboxusercontent.com /scl/fi/<identifier>/<filepath2>?rlkey=YYYChrome + Firefox: Load all 3 links fine.
Safari: All links work fine when clicked. But in addition I also had the videos embedded inline as IMG elements, which Safari allows. It treats them like animated GIFs (autoplays, looped, muted). This worked fine yesterday. But not when I revisited the page.
Interestingly a hard reload helped. Maybe your browser caching busting/policies are not set up correctly? (Especially in conjunction with redirects, something probably messes up Safari). Although theoretically link pattern 2ab should not use any HTTP redirects, so should serve with HTTP 200 according to your documentation.
That did work, I just changed the link and added the dl.dropbox.com up front and Safari now loads fine, dl.dropboxusercontent.com work fine too. Fortunately I only had to modified a hand full of new links and all the legacy links still work. Thanks!
Another example
The first posting contains 2 inline images which were embedded with this link type:
dl.dropboxusercontent.com /scl/fi/<identifier>/filename.png?rlkey=XXXAnd on each revisting of the page it is NOT shown in Safari
Only when I issue a hard-reload it is shown.
Though I experience this again and again I can not artificially reproduce it.
- New browser tab
- Open forum URL
- Open DevTools → Network
- Filter for "dropbox", shows two PNGs, both HTTP 200, so no redirects, no caching issues
- Hard reload
- Network inspection still open: PNGs are shown as HTTP 200 but with the note "served from memory", this is normal, Safari considers its TTL, and does not re-evaluate before that, if the policy does not ask to re-evaluate on each request.
- Closing all browser windows.
- Open new browser window
- While that browser windows is still blank: Open DevTools → Network — So that I can observe it while in that state
- Reload
- Again, both PNGs HTTP 200.
It seems to have to do with Safari's TTL assumption regarding the cached files, which seems to be not in the minutes or so, but happens definitely if you revisit some more minutes hours later. Very very odd all this.
