raw=1 stop working in safari. Why?

[yl4882]

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?

[porg]

Another example

https://wordpress.org/support/topic/wp-image-block-wrapped-in-greenshift-container-should-not-have-b...

The first posting contains 2 inline images which were embedded with this link type:

dl.dropboxusercontent.com /scl/fi/<identifier>/filename.png?rlkey=XXX

And 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.

[mdlahey]

Did it work only for DL=0 and DL=1? When I try to modify links to (dl.dropboxusercontent.com) it only will download and does not pay attention to the raw=1 modifier. 

[Freqs]

This format worked for me with Safari, either:

https://dl.dropbox.com/scl/fi/...&raw=1

https://dl.dropboxusercontent.com/scl/fi/...&raw=1

[justing1]

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?

[Jay]

Hi @justing1, I've merged you to this thread for users with similar questions. Could you try the solutions above to see if they help?

[justing1]

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.

[lisadbx]

Solution in Progress

We have confirmed the issue is limited to Safari and we will have a fix out shortly. 

[lisadbx · Accepted solution]

We just released the fix for the issue on Safari with "raw=1" links. Please let us know if you still have any issues.

[justing1]

Appears to be working again. Thanks for the prompt fix.

[Freqs]

Yes it's working as before now, thanks!