Fallback .html extension matters to fallback setup?

[DotIN13]

I'm following the google developer guide to build a PWA with a fallback page.

my SW:

import { registerRoute, NavigationRoute } from 'workbox-routing';
import * as navigationPreload from 'workbox-navigation-preload';
import { NetworkFirst, StaleWhileRevalidate, CacheFirst } from 'workbox-strategies';
// Used for filtering matches based on status code, header, or both
import { CacheableResponsePlugin } from 'workbox-cacheable-response';
// Used to limit entries in cache, remove entries after a certain period of time
import { ExpirationPlugin } from 'workbox-expiration';
import { precacheAndRoute } from 'workbox-precaching';

// Add offline fallback cache when installing
const FALLBACK_CACHE_NAME = 'offline-fallbacks';
// This assumes /404.html is a URL for your self-contained
// (no external images or styles) offline page.
const FALLBACK_HTML_URL = '/404';
// Build fallback asset array
// let offlineCaches = placeholderImage.images.map((img) => `${img.path}`)
// offlineCaches.push(FALLBACK_HTML_URL)
// Populate the cache with the offline HTML page when the
// service worker is installed.
self.addEventListener('install', async (event) => {
    event.waitUntil(
        caches.open(FALLBACK_CACHE_NAME)
        .then((cache) => cache.addAll([FALLBACK_HTML_URL, placeholderImage.src]))
    );
});

const navNetworkfirstHandler = new NetworkFirst({
    cacheName: 'cached-navigations',
})

const navigationHandler = async (params) => {
    try {
        // Attempt a network request.
        return await navNetworkfirstHandler.handle(params);
    }
    catch (error) {
        // If it fails, return the cached HTML.
        return caches.match(FALLBACK_HTML_URL, {
            cacheName: FALLBACK_CACHE_NAME,
        });
    }
};

// Cache page navigations (html) with a Network First strategy
registerRoute(
    new NavigationRoute(navigationHandler)
);

But the fallback page always respond with ERR_INTERNET_CONNECTION.

After changing /404 to /404.html and serving the page with the extension, the issue was gone.

Out of curiosity, I would like to know why URL without extension would not work as a fallback path. Any insights?

PS. Sorry if it's a bad place to ask questions...

[jeffposnick]

This all depends on the setup of your web server. Based on what you describe, it sounds like your web server returns a valid HTML document when /404.html is requested, but doesn't know how to handle a request for /404. If your web server is configured to respond with the contents of local files in a static directory, it's probably because you have a local file named 404.html.

This is mostly beyond the scope of what we have control over in the Workbox project, though.

[DotIN13]

Thank you so much for answering, looks like I'll have to explore more to understand the mechanism of file hosting.

[DotIN13]

I've done multiple experiments with my Jekyll+Webpack+WEBrick setup, looks like the service worker was able to cache all of /404, /404/ and /404/index.html. All three had the same correct content length:

but only /404/ and /404/index.html settings gets correct redirect response when offline. If using /404, there will be an error as follows and the fallback page won't load.

So the web server seems to be doing the job sending the server copies of offline page, but the service worker was not able to serve the offline page when /404 was used as fallback URL.

When I try to access localhost:4000/404 in Chrome, Chrome automatically redirects me to /404/, so it seems the service worker does not have the capability to resolve URL without backslash to index html files which the WEBrick has.

[DotIN13]

I see from #903 (comment) that workbox handle /404 defaultly as /404.html, so that is why I am experiencing this.

[jeffposnick]

Oh, so looking more closely, the issue is that your response was the result of a redirect, and there's a service worker security restriction that prevents redirected responses from being used to fulfill navigation requests.

I'm assuming /404 redirects to /404/. What I'd suggest doing is to change things so that /404/ is used as the fallback instead:

const FALLBACK_HTML_URL = '/404/';

[DotIN13]

That fully dspell my doubts, thanks a lot for your kind explanation!