Lost emulator configuration and disk subsystem

[Paul Kimpel]

A user posted an issue on the retro-b5500 GitHub repo last month, saying that he hadn't used the emulator in a while, but when he tried, it reported that the configuration data base didn't exist. He was running the emulator from the hosting site, www.phkimpel.us/B5500/.

Well, there are lots of things that can cause that -- starting with purging your browser cache and including off-line website data (which includes the IndexedDB data bases the emulator uses for configuration and disk units) in the things to be purged. Recently, Apple Safari has started throwing away off-line data that hasn't been used in more than a few weeks, apparently as part of an aggressive anti-tracking initiative.

The problem turned out to be none of that, however. The user's configuration and disk units were still there, sleeping peacefully, but otherwise in fine shape. The problem was that they had become hidden, and it was all my fault.

A lot of browser resources that are related to a specific web site, including cookies and IndexedDB data bases, are subject to what is termed the "same site rule." This rule says that a resource is only available to a JavaScript module if that module was loaded from the same site that created the resource. "Same site" is defined the mean that the URL used to fetch the module has the same scheme, host name, and port as the one that created the resource. So while http://phkimpel.us/B5500/ and http://www.phkimpel.us/B5500/ point to exactly the same physical directory on the web server, browsers consider those to be separate sites.

Alas, it also means that http://www.phkimpel.us/ and https://www.phkimpel.us are also considered to be separate sites.

I had not been running SSL/TLS on the hosting site, but last year bought an SSL certificate for it. I also configured the site to force all http: requests to be redirected to https: requests. Thus, anyone who had been accessing the emulator using http://www.phkimpel.us/B5500/ (whether they realized the http: bit or not) suddenly found themselves accessing the site using https://www.phkimpel.us/B5500/ (whether they realized it or not), and poof! no more access to their old IndexedDB data bases. There wasn't any way the user could get back to the http: site, either, since the web server was automatically forcing a redirect to https:.

To enable that user to get back to his old configuration and disk data, I simply turned off the forced redirect for the hosting site. Now if you use an http: scheme (which is the default), it will use that; if you use https:, it will use that.

I would like to reinstate the automatic redirect to https:, but I don't want to lock anyone out of their existing B5500 configuration and disk data. There isn't a way to simply transfer the IndexedDB data bases to another browser site (it could probably be hacked, but the approach would be different for every browser and would probably change over some browser updates). The configuration data isn't that hard to recreate, and you can of course dump your disk data to an emulated tape, save the tape image, and rebuild the emulator under a different URL.

I am interested in hearing from other users how to move forward on this issue, and whether you would be willing to dump your B5500 data from an older http: site and reload it under an https: site.

To dump all files to a tape, use this command on the SPO:

CC DUMP TO FULLBK =/=; END

"FULLBK" will be the name of the tape, and can be any 1-7 character name. This will not dump the system log, so if you want to keep that, release it first with an LN SPO command. See the wiki for instructions to load a scratch tape or tape image and unload and save a tape image once the dump completes. To load the tape again later, use this SPO command:

CC ADD FROM FULLBK =/=; END