When Blazor WASM PWA app is hosted in subdirectory and published to Azure service-worker makes requests to wrong path.

[Hristo-Nikodimov-Nenkov]

Describe the bug

When Blazor WASM PWA application is hosted in subdirectory and published in Azure service-worker.js makes requests to
https://multiclientapp.azurewebsites.net/Store/Store/{asset} instead to https://multiclientapp.azurewebsites.net/Store/{asset}
and even to https://multiclientapp.azurewebsites.net/Store/Store/Store/MultiClientApp.ClientApps.Store.styles.css instead of https://multiclientapp.azurewebsites.net/Store/MultiClientApp.ClientApps.Store.styles.css

To Reproduce

https://github.com/Hristo-Nikodimov-Nenkov/MultiClientApp

Published at https://multiclientapp.azurewebsites.net

Created MultiClientApp project with Blazor WebAssembly template with checked hosted and PWA.
Remove the client application.
Add new Blazor WebAssembly project named ClientApps.Store with PWA checked.
Change project name to MultiClientApp.ClientApps.Store
Add Store to project.
Change base href to "/Store/"
Add referance to client project in MultiClientApp.Server
Add app.MapWhen to Server's Startup.cs Configure method.

Exceptions (if any)

In Chrome DevTools console
Failed to find a valid digest in the 'integrity' attribute for resource 'https://multiclientapp.azurewebsites.net/Store/Store/css/app.css' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked.
Unknown error occurred while trying to verify integrity.
service-worker.js:1 Uncaught (in promise) TypeError: Failed to fetch

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. Because it's not immediately obvious that this is a bug in our framework, we would like to keep this around to collect more feedback, which can later help us determine the impact of it. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[Hristo-Nikodimov-Nenkov]

If the path to the asset in service-worker-assets.js is set relative to wwwroot of the client app that would fix the problem.

I've made it work by changeing service-worker.published.js onInstall function to:

1. async function onInstall(event) {
2.     console.info('Service worker: Install');
3.     const replacePattern = /^(Store\/)+/;
4. 
5.     // Fetch and cache all matching items from the assets manifest
6.     const assetsRequests = self.assetsManifest.assets
7.         .filter(asset => offlineAssetsInclude.some(pattern => pattern.test(asset.url)))
8.         .filter(asset => !offlineAssetsExclude.some(pattern => pattern.test(asset.url)))
9.         .map(asset => asset.url = asset.url.replace(replacePattern, ""))
10.        .map(asset => {
11.             const url = asset.url.replace(replacePattern, "");
12.             return new Request(url, { integrity: asset.hash });
13.         });
14.         
15.         await caches.open(cacheName).then(cache => cache.addAll(assetsRequests));
16. }

by adding line 3 and changing last .map to lines 10-13.

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.