External Downloads - cannot be processed by the server message

[INsane_dod]

I have two sites running JDownloads, both nearly identical. I love JDownloads the best there is in Joomala!

One of them started to display this message...

"The external download could not be started because the stored external address cannot be processed by the server. Please inform the website operator."

I have never seen that before.

Now both sites are on the same host, Joomla! "‎5.4.5" PHP 8.3
Both run jDownloads Version 4.1.4 Stable
Both have the downloads from the same Webspace address (main folder and subfolders) as the websites are installed on.

Nothing major changed recently in configurations on either of the sites, not sure what changed but on this website...
https://www.dodbits.com/dods/index.php/downloads
...Any attempt to download the files I get the above message.

The other website...
https://sturmbot.org/index.php/downloads
...the downloads work fine.

Now as I said both sites use the same downloads folder, and they have been using that since 2013.

I know of this topic...
https://www.jdownloads.net/?view=article&id=109:downloads-with-an-external-file&catid=28&highlight=WyJleHRlcm5hbCIsIidleHRlcm5hbCIsImV4dGVybmFsbHkiLCJmaWxlc2l6ZSIsImZpbGVzIiwiZmlsZXNpemUnIiwiZmlsZXMnIiwiJ2ZpbGVzJyIsIidmaWxlcyIsInByb2ZpbGVzIl0=

In 98% of my downloads I always fill out the files page...

1. I put my link in the "External File Link"
2. I leave the "Is file on a external Web site" to "No"
3. I place in the size of the file manually

I have been doing that way, for a long time (don't like my joomla install to get bloated) Its always worked great.

The only "bug" is if I put in lets say 16.56MB it will not keep that on the first save, I always have to reopen it and apply that again...then save.

But this message on the one site that is doing this...has me stumped, it just started to happen and only on one site.

Anyone got a clue what this could be?

Another bit of info' - I did select YES in the "Is file on a external Web site" option on one test download...
https://www.dodbits.com/dods/index.php/downloads/download/38-rcbot2-waypoints/259-latest-rcbot2-dod-s-waypoints-update-4th-august-2025
...and yes it downloads OK

1. I have a LOT of downloads and I now need to edit all of them now?
2. If I do... the page that comes up is a new link... all white page what gives there?

I would prefer...the way it was and is on the other site.

Any clue on why one site is behaving like that all of a sudden?

[Arno]

Hi,
thank you for reporting this case and for describing your setup so clearly.

We added this protection recently for a specific reason: jDownloads now blocks server-side external download requests when the stored external URL points back to the same website, to localhost, or to internal network targets. The goal was to harden the download process against problematic loopback and SSRF-style requests and to avoid recursive calls such as internal jDownloads URLs pointing back into the same site.

In your case, however, you appear to be using a long-standing and valid setup where the files are stored under normal direct file URLs on the same host/domain, not as internal jDownloads routes. That is a practical real-world use case, and the current protection seems to be too strict for it.

For testing, I have now prepared a narrower compatibility adjustment:

• same-site external URLs are no longer blocked automatically
• but only if they point to a direct file-like target
• internal/script-style targets and suspicious URLs remain blocked
• URLs with query strings or typical internal application routes are still not allowed

So the intention is:

• direct same-site file URLs should work again
• internal Joomla/jDownloads URLs should still stay blocked

Could you please test this adjusted version on your affected site and let me know the result?

What I would specifically like to know:

• Does the download work again for your existing external file entries?
• Does it work for all affected downloads or only some of them?
• If some still fail, could you send me one example URL pattern from the affected download record?

That would help us confirm whether this narrower exception covers your real-world setup correctly.

I will send you the modified test version as an attachment to a private message.

Best regards
Arno

[INsane_dod]

Wow, Thanks Arno, I didn't expect such a quick answer.
I'll certainly watch for the test version and report back.

Reminds me, I have not donated in a while. I had better get on to that to.

EDIT: Thank You Arno!

Check your PM's the test version 100% worked. All back to normal now.
I will continue to monitor but so far all downloads I tried on the affected site, all work fine.