HTTP Status 500 on every CD Image

[fullpwn]

[parkerlreed]

500 is remote server error. Appears to be working here. Check to see if you can reach the sources outside of the emulator.

[mihaip]

@parkerlreed is correct that this is an error relating to the (archive.org) server that the CD-ROM image is being streamed from. I'll look into making the message friendlier so that it's easier to understand what is happening.

[kiljorn1109]

@mihaip isn't this because of the image file chunks not being generated? nearly all the links work for download

[that-ben]

I've been getting this 90% of the time since last year whenever I try to stream disk images on IM from ARCHIVE.ORG. Accessing them as a download in my browser always works, except for a few times where I also get the page where ARCHIVE.ORG claims it's overloaded and that I need to try again in a couple seconds, so I'm pretty sure they do this to prevent the server from crashing due to high load or too many requests in a short period of time.

[spudpiggy]

I've been getting this 90% of the time since last year whenever I try to stream disk images on IM from ARCHIVE.ORG. Accessing them as a download in my browser always works, except for a few times where I also get the page where ARCHIVE.ORG claims it's overloaded and that I need to try again in a couple seconds, so I'm pretty sure they do this to prevent the server from crashing due to high load or too many requests in a short period of time.

I recommend downloading the ISO manually and then mounting the downloaded copy instead of streaming from archive.org. Their download servers are almost always terrible (several hundred kb/s) so larger isos will error if they don't download fast enough. Try finding the iso on macintoshgarden or another service with actually good file servers.

[that-ben]

The thing is that I also tried to directly stream an ISO from MR and it does the same thing, even on days where MR is obviously not overcrowded. I suspect there's some kind of bug in the file streamer or that it asks too many chunks at the exact same time which makes website firewalls suspicious or something alike. I can guarantee you that when I test with MR, it's NOT overcrowded. I can see the Apache status, open socket slots, bandwidth, etc... Plus, if I immediately copy/paste the same URL in my browser, it fires the download at 4MB/s (this is my ISP cap, but it would download at much higher speed otherwise) so it's pretty weird.

At first, I thought since some other people claim that it works, that it was a Firefox bug, but it also does the same on Safari under macOS 14.4.

@mihaip if you want to test with MR, you can use this direct URL: https://macintoshrepository.org/files/direct/Mac-OS-9-Boot-Kit.iso

[mihaip]

What I think is happening is that the Cloudflare Worker is (at least sometimes) fetching the entire disk image, even though I'm only requesting a small piece of it. Using the image that @that-ben provided, the first 4 chunks are from relatively early in the file, but the one that fails is ~200MB into it.

I think the reason why it eventually succeeds (if you reload enough times) is that the whole file ends up being cached by Cloudflare, and then it can respond to these range requests from its cache.

I'll look into workarounds.

[mihaip]

Based on https://community.cloudflare.com/t/cloudflare-worker-fetch-ignores-byte-request-range-on-initial-request/395047 and https://community.cloudflare.com/t/how-do-you-do-the-equivalent-of-the-page-rule-cache-level-bypass-in-a-worker-fetch/388255/5 I enabled bypassing the Cloudflare cache to archive.org and a few other sites and it seems to be working better now.

[that-ben]

EDIT: Whoops just saw the second post in a row. @mihaip Would you like me and you to test things out in real time on the MR server sometime? Perhaps together we can find why Cloudflare sometimes requests the whole file and then you implement a fix for that issue or find a workaround that would also work on other web servers?

---

But the question remains: How is CloudFlare even relevant for the task of streaming chunks from various places on the internet? What does it bring to the table? Also: one of your links suggests "Rename your resources to a non-cacheable extension". Could this be done by adding a query string (e.g. 0-131072.chunk?somerandomnumber=123456) on each chunk?

[mihaip]

How is CloudFlare even relevant for the task of streaming chunks from various places on the internet?

Cloudflare is where the site is hosted (using their Workers product), there is no other server component for Infinite Mac. CD-ROM chunks have to be proxied through the Cloudflare worker because they can't be fetched from the browser directly (archive.org and others don't send CORS headers to allow cross-origin fetching).

[that-ben]

Oh I see. Wait, so does that mean that my local implementation (or others') of IM will stop working the day you unplug Cloudflare?

[mihaip]

If you're not requesting anything from infinitemac.org (which you don't appear to be) then you're not dependent on what's running on Cloudflare.

I don't think you have the CD-ROM functionality hooked up, but if you did, you'd need to replicate the chunk fetching on your server set up (something to handle the /CD-ROM/... URLs that createEmulatorWorkerCDROMDisk generates)

[that-ben]

Ah, I see what you mean, thanks for the clarification.

[kiljorn1109]

Sorry for the offtopic, by any chance can you tell me, how does the LAN exactly work? Couldn't get it to work neither on a cloudflare worker or on your site, the zones can have any name? Or are they set to something?

[fullpwn]

That is definitely off topic and not really suited for this issue.

I recommend you probably either contact mihaip directly or create a separate issue. Thanks

[mihaip]

Closing this out, CD-ROM images seem to be more reliable now.