Fallback URLs allow you to define alternative URLs for failed network requests. If the request to a URL fails for whatever reason (e.g. if your server is down), Progressier can then attempt to make the exact same request to the fallback URL of your choice. All of this happens at the service worker level.
What is it for?
A good way to make your website or app more reliable is creating redundancy. If your server is down, all requests to any resources located on that server will also fail. With our Fallback URL feature, you provide the browser with an alternative path to get these resources.
Placeholders are another good use case for Fallback URLs. When a request for an image fails, you could display a pretty image placeholder instead of the ugly standard broken image UI.
For now, you'll have to take care of hosting these resources yourself somewhere else. But if the feature is popular, we could possibly automatically make back-ups of your important resources for you. Let us know if you're interested.
What sort of response triggers a retry?
Progressier will try making a request to the Fallback URL if the receiving server isn't accessible at all or if it returns a HTTP response code that starts with 5xx, signaling a server error.
What about headers/payload?
The body and headers of the initial request will be copied and passed to the alternative URL. The fallback request will be exactly the same, except for the URL.
The special case of query string parameters
Let's say your resource is located at the following URL:
https://example.com/create-user?firstname=John&lastname=Doe
As you can see, it has two query string parameters, firstname
which is set to John
and lastname
which is set to Doe
. Now we'll see what happens when you specify a Fallback URL.
Example 1: https://fallback.com/new-user
The request above does not have any parameters β and for good reason. By design, the parameters from the original URL will automatically be appended to the Fallback URL. So if you specify this Fallback URL, the actual fallback request will be made to this URL:
https://fallback.com/new-user?firstname=John&lastname=Doe
Example 2: https://fallback.com/new-user?country=US
As with Example 1, the parameters from the original URL will be appended to the Fallback URL. But since the Fallback URL also has its own parameters, we'll append those as well β resulting in the request being made to this final URL:
https://fallback.com/new-user?firstname=John&lastname=Doe&country=US
Example 3: https://fallback-example.com/new-user?firstname=Mark
If you specify query strings parameters in your Fallback URL that are also present in the original URL, we'll use those you specify in the Fallback URL. So in this case, the final URL will be the following:
https://fallback.com/new-user?firstname=Mark&lastname=Doe
Fun fact...
With The Coronavirus App, we had an issue early on that prevented users of certain anti-virus software or firewalls to access the app at all (more on that here). It would simply fail to load, as if our server was down completely. One of the drawbacks of having a domain that contains the term virus π.
To partially solve that problem, we set up an alternative domain (https://crnvr.us) that serves exactly the same app. This solved the problem for all our users who bothered reaching out. But many of them never reached out β thinking we had probably simply stopped working on this app.
If we had Progressier's Fallback URL feature back then, we could have automatically redirected all failed coronavirus.app/* requests to crnvr.us/* β ensuring uninterrupted access to the app for all users.