Fallback .html extension matters to fallback setup?

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]

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!