nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

The Dropbox XML link no longer works on Samsung TV

deco10

Hi,

I’m opening a new thread because I believe the problem is now easier to describe after having gone through the troubleshooting on my side.

I have an older Samsung TV, a Samsung UE46F8005, running a streaming app that loads an XML file from a public Dropbox folder.

This setup has worked perfectly before. I have not changed the TV, the streaming app, the XML structure, or the way the link is configured, and the TV is not set to automatically update its firmware. The problem simply appeared even though I have not made any changes on my side.

I have also already tested the XML itself by putting the exact same XML content directly into the app. In that case it works correctly. The problem therefore appears to occur specifically when the app/TV tries to retrieve the XML from Dropbox.

This makes me suspect that something has changed on the Dropbox side, most likely concerning the way the shared link is handled.

Possible redirect / new link architecture issue

I found this previous Dropbox Community discussion about the change from the old /s/ links to the newer /scl/fi/ link architecture.

In that discussion, Dropbox explains that the new link architecture can involve an HTTP 302 redirect, and specifically mentions that applications need to be able to follow the redirect. Dropbox also describes a dl.dropboxusercontent.com variant which does not require the application to follow the HTTP 302 redirect.

This seems particularly relevant in my case because the Samsung TV is using an old platform/browser/network stack, and it is quite possible that it cannot handle the current redirect/link behaviour correctly.

The previous discussion also shows that similar third-party integration problems have occurred with the newer Dropbox links.

So my question is:

Could you please check what happens when the XML file is requested from my Dropbox link, including the HTTP response and any redirects involved?

In particular, could you check whether the current shared link is now redirecting the request somewhere that this older Samsung TV cannot handle?

The important point is that the XML itself is valid and works when included directly in the app. The problem only occurs when the app has to retrieve the XML from Dropbox.

I have done the troubleshooting on my side and have not made any changes to the setup. This setup previously worked, so I would really appreciate it if someone could investigate whether something has changed in Dropbox's handling of the shared file/link.

I will link to my previous cases/posts in this thread so you can see the history and that this setup has worked before.

Thanks in advance for looking into this.

https://community.dropbox.com/en/discussion/689070/why-does-my-shared-link-preview-like-scl-instead-of-s-can-i-change-that

https://community.dropbox.com/en/discussion/855269/i-have-an-xml-file-which-i-share-with-my-own-smart-tv-app-but-it-doesnt-work

Find more posts tagged with

Shared Links

Preview

Accepted answers

All comments

Jay

Hi @deco10, thanks for messaging the Community.

There aren't any changes to how files are rendered via a shared link, aside from the URL changing.

If you open the shared link in a private browsing/incognito window, does the XML file render normally?

Feel free to drop any relevant details below. The more I know upfront, the sooner I can zero in and find a solution for you.

deco10

Thanks for the reply.

Yes, the XML file renders normally when I open the shared link in a modern browser/private browsing window. That is not really the part that is failing.

The important point is that **this exact setup has worked previously on the Samsung TV without any problems**. I have not changed the TV, the streaming app, the XML file, or the way the XML is hosted. The TV is also not set to automatically update its firmware.

The same XML works perfectly when I include the XML directly in the app. The problem only occurs when the app has to retrieve the XML from the Dropbox shared link.

So I don't think this is an issue with the XML itself or whether the shared link can render in a normal browser.

What I'm trying to determine is whether something has changed in the way Dropbox delivers the file to older clients.

As mentioned in the previous thread, Dropbox introduced the newer `/scl/fi/` shared-link architecture. Your own Dropboxer explanation in that thread mentions that the new links can involve an **HTTP 302 redirect**, and also specifically mentions `dl.dropboxusercontent.com` as a way to access the content without requiring the application/browser to follow that redirect.

That is exactly the kind of change that could explain why something that previously worked on an older Samsung TV suddenly stopped working, even though nothing was changed on the TV or in my app.

The Samsung UE46F8005 is an older TV platform, so it is quite possible that its built-in web/network component handles the current Dropbox response differently from a modern browser.

Could you therefore please check the actual HTTP response/redirect chain for the shared XML file and compare it with how the old links were served?

In particular, I would like to know:

* Does the current shared link return a 302 redirect?

* Where does it redirect the TV/client?

* Has the redirect or response behaviour changed compared with the previous Dropbox link architecture?

* Is there still a way to provide the file through a URL that does **not require the old Samsung client to follow the redirect**?

I'm not claiming that the XML cannot be opened in a browser — I have already established that it can.

The problem is specifically that an **older client which previously worked can no longer retrieve the same type of file from Dropbox**.

I have linked the previous cases in this thread because they show that this setup has worked before and that Dropbox has previously had similar compatibility issues with older/third-party clients.

Could you please investigate the delivery/redirect side rather than only testing whether the link opens in a modern browser?

Thanks.

Jay

The last changes to shared links was back in August 2024, in which you can read about the changes here.

We've not received any information on new changes to how shared links are being delivered. The 302 redirect was present in the above changes, and occur when using either:

https://www.dropbox.com/scl/fi/<token>/path.jpg?raw=1&rlkey=<token>

Or…

https://dl.dropbox.com/scl/fi/<token>/path.jpg?dl=0&rlkey=<token>

…for shared links.

These links will directly render the content in the browser if the link is public without any other permissions, and will require a browser or app that can follow a 302 direct. Currently, there isn't a method to return to the old version of shared links without a redirect.

If you have any further queries, feel free to message back.

deco10

Yes, the XML file opens normally in a private/incognito browser window. I have already established that the Dropbox link itself works in a modern browser.

However, that does not explain the problem.

The issue is specifically that the same XML file and the same setup previously worked on my Samsung UE46F8005, and I have not changed anything on the TV, the streaming app, the XML file, or the TV firmware.

The XML also works perfectly when it is embedded directly in the app. It only fails when the app has to retrieve the XML from Dropbox.

So the question is not whether Dropbox can render the XML in a browser. The question is:

What does Dropbox currently return to an older client when it requests this file?

Could you please check the HTTP response/redirect chain for the shared link?

For example, does the current `/scl/fi/` link return a 302 redirect before serving the file?

I ask because the previous Dropbox discussion about the new `/scl/fi/` link architecture specifically states that these links can use HTTP 302 redirects, and that `dl.dropboxusercontent.com` can be used to access the content without requiring the application to follow the redirect.

That seems highly relevant to an older Samsung TV platform.

If Dropbox has not changed anything about the way the file is delivered, could you please explain why an unchanged Samsung TV/app combination that previously retrieved the XML successfully can no longer retrieve it?

I am happy to provide the actual shared link privately if needed so you can inspect the response and redirect chain.

Thanks.

deco10

I noticed something..you are putting this at last..&rlkey=<token>..this is new..or doesn't this matter?..

either:

https://www.dropbox.com/scl/fi/<token>/path.jpg?raw=1&rlkey=<token>

Or…

https://dl.dropbox.com/scl/fi/<token>/path.jpg?dl=0&rlkey=<token>

Jay

For shared links, you would need to have the &rlkey=<token> included in order to allow the files to preview normally.

In relation to your other questions about what Dropbox returns to an older client when a link is requested, we don't have any information available regarding this, or the redirect chain itself.

deco10

Regarding the `rlkey` parameter: my question is not whether `rlkey` needs to be included. I understand that it does.

My question is whether the **order of the query parameters matters for an older client**.

The URL Dropbox generates when I share the file is in the form:

`...?rlkey=XXXXX&raw=1`

while your reply says:

`&rlkey=<token>`

So I just want to clarify whether the position of `rlkey` relative to `raw=1` makes any difference, or whether these are completely equivalent:

`?rlkey=XXXXX&raw=1`

and

`?raw=1&rlkey=XXXXX`

I understand from your latest reply that Dropbox does not have information available about the redirect chain or what an older client receives when requesting the file.

That unfortunately leaves us with the exact part of the problem that needs to be investigated.

The TV has not changed, the app has not changed, and the XML itself works correctly when it is included directly in the app. The only relevant difference I can identify is how Dropbox now serves the externally hosted XML file.

So if Dropbox cannot provide information about the redirect chain, could you at least confirm whether there is a way to create a shared/direct file URL using the current Dropbox system that does **not rely on a redirect**, specifically for older clients?

I am trying to establish whether there is still a Dropbox-compatible URL format that an older Samsung TV can retrieve directly, as this worked previously.

Thanks.