Summary
When using the ?url= parameter to load a TAP file from archive.org, the emulator fails to load the file - either getting stuck with blank screen or falling back to the BASIC prompt with no program loading. The root cause is that archive.org redirects some files to CDN nodes that don't send CORS headers, and the proxy in html/webapp/functions/programs.js passes the redirect through to the browser rather than following it server-side.
Failing example
https://oric.games/?url=https://archive.org/download/castle-of-doom/CASTLE%20OF%20DOOM.tap
Browser console error:
https://ia600107.us.archive.org/34/items/castle-of-doom/CASTLE%20OF%20DOOM.tap' (redirected from 'https://oric.games/programs?url=https://archive.org/download/castle-of-doom/CASTLE%20OF%20DOOM.tap') from origin 'https://oric.games/' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
Working example (for comparison)
https://oric.games/?url=https://archive.org/download/Gamebase_Oric_V1.0/Games.rar/Games%2FB%2FBattle%20Flight%204%2FBattle%20Flight.TAP
This works because the CDN node it redirects to (ia800104.us.archive.org/view_archive.php) happens to send Access-Control-Allow-Origin: *. The failing case redirects to a different CDN node (ia600107.us.archive.org) that does not.
Suspected root cause
The proxy in html/webapp/functions/programs.js does:
let response = await fetch(request);
When fetch() receives a redirect, it passes it through to the browser rather than following it server-side. The browser then requests the CDN URL directly, which fails CORS. Since the whitelist check happens before the fetch() call, redirect destinations are never checked against the whitelist — so following redirects server-side doesn't require whitelisting of individual CDNs.
Suggested fix
Change this:
let response = await fetch(request);
To this:
let response = await fetch(request, { redirect: 'follow' });This tells the Cloudflare Worker to follow redirects internally, returning the file content directly to the browser with the proxy's own CORS headers applied — regardless of what the CDN node sends. I've tested this locally using Wrangle to confirm it does behave as expected. (I haven't tested a full web server hosting of Joric though.)
This suggested fix does result in more data traffic for the web server for each file load though. (The whole of the program proxying through the web server in all cases, rather than just the 302 redirect URL in the case of redirects.) I'm hoping that given the relatively small file sizes of Oric programs that this does not represent an issue for hosting of the service during normal non-malicious usage. But wanted to flag it as something to consider.
Summary
When using the ?url= parameter to load a TAP file from archive.org, the emulator fails to load the file - either getting stuck with blank screen or falling back to the BASIC prompt with no program loading. The root cause is that archive.org redirects some files to CDN nodes that don't send CORS headers, and the proxy in
html/webapp/functions/programs.jspasses the redirect through to the browser rather than following it server-side.Failing example
https://oric.games/?url=https://archive.org/download/castle-of-doom/CASTLE%20OF%20DOOM.tapBrowser console error:
https://ia600107.us.archive.org/34/items/castle-of-doom/CASTLE%20OF%20DOOM.tap' (redirected from 'https://oric.games/programs?url=https://archive.org/download/castle-of-doom/CASTLE%20OF%20DOOM.tap') from origin 'https://oric.games/' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.Working example (for comparison)
https://oric.games/?url=https://archive.org/download/Gamebase_Oric_V1.0/Games.rar/Games%2FB%2FBattle%20Flight%204%2FBattle%20Flight.TAPThis works because the CDN node it redirects to (ia800104.us.archive.org/view_archive.php) happens to send Access-Control-Allow-Origin: *. The failing case redirects to a different CDN node (ia600107.us.archive.org) that does not.
Suspected root cause
The proxy in html/webapp/functions/programs.js does:
let response = await fetch(request);When fetch() receives a redirect, it passes it through to the browser rather than following it server-side. The browser then requests the CDN URL directly, which fails CORS. Since the whitelist check happens before the fetch() call, redirect destinations are never checked against the whitelist — so following redirects server-side doesn't require whitelisting of individual CDNs.
Suggested fix
Change this:
To this:
This tells the Cloudflare Worker to follow redirects internally, returning the file content directly to the browser with the proxy's own CORS headers applied — regardless of what the CDN node sends. I've tested this locally using Wrangle to confirm it does behave as expected. (I haven't tested a full web server hosting of Joric though.)
This suggested fix does result in more data traffic for the web server for each file load though. (The whole of the program proxying through the web server in all cases, rather than just the 302 redirect URL in the case of redirects.) I'm hoping that given the relatively small file sizes of Oric programs that this does not represent an issue for hosting of the service during normal non-malicious usage. But wanted to flag it as something to consider.