Re: Force render issues (raw=1) and shared links won't work for hosting.

All my photo links on the geocaching.com site have stopped working when using the /scl/ link.
the old /s/ links still work.
Tried dl=1 and raw=1
Tried on Chrome & Firefox.

Hi Stratoman, thanks for bringing this to our attention.

Could you try these steps to see if they help with your shared links?

Keep me posted!

Hi Msloane2, thanks for bringing this to our attention.

Just for clarification, when you say 'images from the web', do you mean when you open the shared link from outside of the Wordpress site?

This will help me to assist further!

It sounds like the link itself is working normally in that case. This would be an issue with how Wordpress is processing the image link. Have you tried contacting them directly regarding this matter?

Thanks Jay, I've had the same issue, the thing that worked for me is this: 

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

the other options are not functionning anymore, please what's the reason behind this strange behavior ?

Hi,

I'm seeing a related problem. On an animation forum where I've shared hundreds of images for training and demonstration, I'm now seeing broken image links.

These images were shared from my Dropbox account using raw=1 in the link path, and this had worked perfectly for many years. The images broke sometime this morning.

I checked various browsers (Chrome, Safari, Firefox, and Edge,) and the images shared with Dropbox appear broken in all of them.

I had wondered if this was temporary server issue on Dropbox's end, but it's been like this all day.

Thanks in advance for any assistance! 

Did you get a fix? All of my iframe embedded videos using the raw=1 change in the link have stopped working on Wordpress too. 

It appears that what is being returned for a URL like removed has a Content-type of "text/html" instead of being the raw image data. It appears that the image is eventually delivered, but only after a ton of JS scripts and a 302 redirect.

This is also breaking Google Docs' PDF renderer, which is now displaying the source-text of an HTML page instead of the PDF file itself.

...or at least it was. It's now "refusing to connect."

Hi Jay,

I had already found that document and tried dl=1 and raw=1 with no luck.
I didn't try replacing www with dl as it says :-

<<<<<<

While we don't "officially" list these anymore in our Help Center, we are continuing to support them for now.  

>>>>>>

However , I have just tried it and it works fine BUT this means going all the way back to June 2023 and changing all my links , not knowing how long it will be supported.
I really need the www /scl/ to work as it did a few days ago.

Thanks
John

Same problem here. Directly passing the link into the browser works. Rendering the files as part of another website does not.
Everything uploaded before the new link change renders fine. Every file that has the new link (with the "rlkey=" in the URL) breaks and cannot be rendered.  Filetypes (jpg/png/mp3) is exactly the same. The only difference is the URL structure. Happens on any platform I use (gallery platforms with html displays/boxes, google docs and sheets, etc) as well as in any browser I tried with the latest versions and cache cleared (Firefox, Chrome, Opera).

It seems like something has actively changed on Dropbox as videos are not rendering either now (see here). However as Dropbox is NOT a hosting tool this is not unexpected - they have previously done similar to stop people using Dropbox as a web host, so, my guess is that this may be the same again.

Same issue.

same issue here. when using the "raw=1" link, picture don't show in my obsidian notes, before is working fine.

No fix yet. All my shared images are still broken today.

---

Greenlaw wrote:

No fix yet. All my shared images are still broken today.

---

It seems to be an intentional change on shared links - based upon the fact that the links themselves work when not on a web page. I would not expect Dropbox to change this - they didnt last time. 

You would be better off looking at moving to, and using, a proper webhost.

Hmm...this is unfortunate, if true.

I've been a long-time subscriber to Dropbox for many reasons, and this was one important one. I don't really want to shop around for another cloud storage service yet but I may have to consider doing so if this is the case.

Can anyone from Dropbox please verify or explain the reason the shared image links suddenly broke without warning yesterday? Thanks!

Hi

I use images from Dropbox to display images on websites. For this I use the public link such as:

https://www.dropbox.com/scl/fi/5x1t2ddk9wlhxz5naoscg/2204-01.jpeg?rlkey=m8zkxxnzge6s05rqo696m0jq8&raw=1

(ending dl=0 replaced by raw=1).

 
This no longer works. No image is displayed on the website. 

If I add the address:

https://www.dropbox.com/scl/fi/5x1t2ddk9wlhxz5naoscg/2204-01.jpeg?rlkey=m8zkxxnzge6s05rqo696m0jq8&raw=1

directly into the browser, the adress is redirected to 

https://ucd8a1098089b4c4a8845e8a7d2b.dl.dropboxusercontent.com/cd/0/inline/CSR-j0SA5XN8_K8Lvb8wcnZjUS-ET9TqBGZlXDQJjXPcaeqGAHINekXc1mb-tgzx-Sq7g1twcAf32L6TbV-94Jx4q85sxuObdvn4sl6iNuRBjfUrUg6rJLDDOJS4PmZ_ndV2egfdRLNMuQpQgypmrdJ0/file

Why that? I think that the redirect is the reason why the image can no longer be displayed on the website where the image is integrated.

Any idea to solve this issue?

Just an FYI this only is affecting files later than June of 2023. All of my prior files will still load with raw=1

I do think that Dropbox is a very greedy company. If they don't want to allow users to render content from the browser (by the way, they mentioned only HTML content), then why did they put it on their support pages?

The most important about cloud services is the reliability, how would trust a company is lead by kids to save a backup of your important files, where is their policy.

---

mondstaub wrote:

...

If I add the address:

https://www.dropbox.com/scl/fi/5x1t2ddk9wlhxz5naoscg/2204-01.jpeg?rlkey=m8zkxxnzge6s05rqo696m0jq8&raw=1

directly into the browser, the adress is redirected to 
https://ucd8a1098089b4c4a8845e8a7d2b.dl.dropboxusercontent.com/cd/0/inline/CSR-j0SA5XN8_K8Lvb8wcnZjUS-ET9TqBGZlXDQJjXPcaeqGAHINekXc1mb-tgzx-Sq7g1twcAf32L6TbV-94Jx4q85sxuObdvn4sl6iNuRBjfUrUg6rJLDDOJS4PmZ_ndV2egfdRLNMuQpQgypmrdJ0/file

Why that? I think that the redirect is the reason why the image can no longer be displayed on the website where the image is integrated.
...

---

Hi mondstaub,

Actually No. Dropbox links have been always redirecting. You probably haven't noticed but any other than preview link has redirected all the time. So described by you is not something new and byself cannot be the reason for observed issue. Despite there is something new and it's about how this redirection happens! While till some time ago it was protocol redirect (HTTP location redirect), recently Dropbox started using page redirect (HTML page redirect itself to another place). This is something problematic in most use cases since while an image is expected text file is received, for instance. Since this is NOT something normal, that confuses most applications (including media players, browsers, etc.). Only few are able to handle HTML redirect. Of course when loaded in the main frame of a browser (not as an image inside page or something else) all web browsers handle such redirection correctly (on such a place would be strange to be something other than HTML, so HTML redirect is possible too). That's why those links work in browsers as a page, but do not it while embedded in any way. That's what the nature of this issue is. Combined with forbidding, forced by Dropbox, of such "pages" to load as inline frame, for instance, makes this issue even more hard. There are still some workarounds (not all link types are changed yet). 😉

Hope this clarifies matter.

---

iggy097  wrote:

Just an FYI this only is affecting files later than June of 2023. All of my prior files will still load with raw=1

---

Hi iggy097,

Yes and No. There is nothing related to "ages" of your files, but to their links creation time. Old links (created before last "move") would continue work, but all new links (it doesn't matter to old or new files) will follow discussed new behavior (I hope still, it's some mistake that will be fixed). 🤷 That's it. In other words, this change is not retroactive for links.

Good luck to all of us.

FWIW, I'm seeing the broken links with images shared in April. Some older images are still working, but I'm not sure when the cut-off date is yet, if there even is one.

I read elsewhere that the cutoff could be March, but there is no official confirmation from Dropbox about this issue. For now, I'm assuming no images are guaranteed to remain active.

Hopefully, Dropbox can clarify what's going on.