This really isn’t possible the way you’re describing. Think about this: If
google.com is down, where would you expect to be getting a redirect to
googlebackup.com from? By definition, if the gateway is down and the backup has taken over, there’s no longer any webserver at
<primary>/data/perspective/client/project to serve up even a redirect notice to
<backup>/data/perspective/client/project. It’s just fundamentally not possible to have a single webserver, in isolation, do what you’re describing. A URL always points to a specific ‘resource’ (hence the name) - so in the ‘naive’ architecture,
<primary>/data/perspective/client/project is always the exact location of the primary gateway.
What you’re actually looking for is to have
<something>/data/perspective/client/project resolve to some other application, which is acting as a middleman - you would go to
<somethingElse>/data/perspective/client/project/, and that other service would conditionally route you to
<backup>/data/perspective/client/project. There are infinite possibilities for this - look into load balancers, reverse proxies, etc -
nginx is a solid choice for a Linux server. Crucially, this middleman must be at a separate network location - it doesn’t matter to consumers of
<yourServer>/data/perspective/client/project, but internally, the middleman itself must have unique addresses for both the primary and backup nodes (or however many nodes you have; true load balancers can scale “horizontally” to multiple nodes). This also isn’t an area Inductive Automation is interested in providing a solution first party - HTTP load balancers are a “solved” problem, and nothing we can come up with would improve on existing open source, free solutions.
There is one caveat/wrinkle/exception to all this - if you are already in a Perspective session when the master -> backup transition happens, things (should) continue to work, “seamlessly”. How? Because the actual Perspective client is a so-called “Single-Page Application” - once you’ve downloaded all the required resources (which happens as soon as you open a Perspective session), everything else is happening, from your web browser’s perspective, on a single page - the frontend is continually talking to some backend via an open websocket, but in the event of a failure on that connection, it will also have downloaded the address of the backup server, and thus the frontend can independently attempt to connect to the backup system. Vision clients work in much the same way. Crucially, though, the difference is in the scope of responsibility - the actual Ignition application (Vision or Perspective) “knows” how to find the backup - but a standalone web browser, pointed at
<primary>/data/perspective/client/project, simply cannot know where the backup server is without something there to redirect it.