Service worker fails in IIS, but works perfectly in IIS Express

[smalleythedave]

Hi,

I'm sure there must be a trivial explanation for this, but I can't find it.

I create a Blazor Web Assembly project from the template. Everything works as expected. I add the nuget, and again it all works fine and when I launch the application in IIS Express, I get the install banner in desktop Chrome, and I can install the application and run it from the desktop icon, etc. No problems at all.

Then I deploy the application to full IIS. The Blazor app downloads and runs as expected. However, the install banner doesn't appear. Looking in the Chrome dev-tools, in the console I get a message that the Service Worker was registered successfully and is controlling http://localhost. However, when I check the application tab, it lists the SW status as redundant. Reloading the page or deleting the SW always results in the same message, saying "uncaught exception in Promise, request failed".

I have searched the web and tried numerous things like custom HTTP headers, opening up permissions on inetpub to Full Control for Everyone, changing the user IIS is running under, using a valid SSL certificate (which shouldn't be necessary for localhost), etc. Always the same thing: the Blazor app downloads and runs correctly, the registration of the SW succeeds, but the status is redundant and stopped.

I have also fiddled with Chrome flags, but that would seem to be useless, since the only difference is running against IIS or Express.

Any idea what I am doing wrong?

Dave

[SQL-MisterMagoo]

I believe you have to serve the application over Https for full functionality of PWA.

[smalleythedave]

Well, actually there is an exception for service workers and PWA which allows them to be served over HTTP from localhost. More to the point, this is my problem: 1) Serve from http://localhost:12345 with IIS Express - works. 2) Serve from https://localhost:12345 with IIS Express - works. 3) Serve from http://mydomain:12345 with IIS Express - doesn't work. 4) Serve from https://mydomain:12345 with IIS Express - works. 5) Serve from http://localhost with IIS - doesn't work. 6) Serve from https://localhost with IIS - doesn't work. 7) Serve from http://mydomain with IIS - doesn't work. 8) Serve from https://mydomain with IIS - doesn't work. As you can see, using IIS Express behavior is as expected, works with either protocol except when not using localhost, in which case HTTPS is required. Using IIS, nothing works, through either localhost or the domain name, with either HTTP or HTTPS. Also, to re-iterate, "works" and "doesn't work" refers to the service worker. In all cases, the blazor app itself downloads and runs correctly. I know this doesn't make sense, but it's the behavior I'm getting. Dave

…

On Sun, Dec 15, 2019 at 10:39 AM SQL-MisterMagoo ***@***.***> wrote: I believe you have to serve the application over Https for full functionality of PWA. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#10?email_source=notifications&email_token=AHQPCGIHWRH6WTFTKLS3L5DQYZ2XNA5CNFSM4J3A4K7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEG47LYA#issuecomment-565835232>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHQPCGOPO3UG6MK3Z3UR72DQYZ2XNANCNFSM4J3A4K7A> .

[SQL-MisterMagoo]

I don't know what could be causing this - do you see any differences in the network traffic between IIS and Express?

[smalleythedave]

I've been looking at logs, and so far can't see anything different in requests and responses. However, I did stumble upon something bizarre: If I comment out the requiredFiles in serviceworker.js (requiredFiles = [];), the first time I run desktop chrome against http://localhost, the Blazor app loads and the Install Banner appears, however, thereafter, in chrome, the website won't load at all (There is a problem with the website), and the only fix is to go to chrome advanced settings and reset all settings. Also, obviously, the cache is empty on the client. The website is actually running fine, because I can load it in Edge, but Edge doesn't currently support PWA's anyway. I just keep feeling there is something a little weird I'm not understanding. Are you able to create the default template Blazor app and deploy it to IIS without problems? Just curious.

…

On Wed, Dec 18, 2019 at 5:49 AM SQL-MisterMagoo ***@***.***> wrote: I don't know what could be causing this - do you see any differences in the network traffic between IIS and Express? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#10?email_source=notifications&email_token=AHQPCGLRCH2A6BVL57MFBBDQZIS4XA5CNFSM4J3A4K7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHGFGJY#issuecomment-567038759>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHQPCGKFSQAF57JBJIHX5WLQZIS4XANCNFSM4J3A4K7A> .

[SQL-MisterMagoo]

I have reproduced the problem.

For me, something was going wrong with the list of required files and some of them were erroring on fetch, which breaks the service worker - just removing the failed files manually from the list allowed the service worker to complete and WPA functionality was restored.

I just need to figure out why they are going wrong and how to prevent the service worker from giving up or at least to provide some mechanism where you know why it has given up.

[smalleythedave]

Maybe missing or incorrect MIME types?

…

On Sat, Dec 21, 2019, 3:22 AM SQL-MisterMagoo ***@***.***> wrote: I have reproduced the problem. For me, something was going wrong with the list of required files and some of them were erroring on fetch, which breaks the service worker - just removing the failed files manually from the list allowed the service worker to complete and WPA functionality was restored. I just need to figure out why they are going wrong and how to prevent the service worker from giving up or at least to provide some mechanism where you know why it has given up. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#10?email_source=notifications&email_token=AHQPCGPUOU4O675FP2IDW3LQZX4AHA5CNFSM4J3A4K7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHO2IPQ#issuecomment-568173630>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHQPCGI2OTLAXZUMBMNAWQDQZX4AHANCNFSM4J3A4K7A> .

[smalleythedave]

Got it to work by adding mime types for ".pdb", ".md", and ".". The last is for files without extensions, in other words, the FONT-LICENSE and ICON-LICENSE. I don't think any of those files are actually required on the client anyway, so they could just be removed from "requiredFiles" I suppose. On Sat, Dec 21, 2019 at 11:36 AM David Smalley <smalley.thedave@gmail.com> wrote:

…

Maybe missing or incorrect MIME types? On Sat, Dec 21, 2019, 3:22 AM SQL-MisterMagoo ***@***.***> wrote: > I have reproduced the problem. > > For me, something was going wrong with the list of required files and > some of them were erroring on fetch, which breaks the service worker - just > removing the failed files manually from the list allowed the service worker > to complete and WPA functionality was restored. > > I just need to figure out why they are going wrong and how to prevent the > service worker from giving up or at least to provide some mechanism where > you know why it has given up. > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <#10?email_source=notifications&email_token=AHQPCGPUOU4O675FP2IDW3LQZX4AHA5CNFSM4J3A4K7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHO2IPQ#issuecomment-568173630>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AHQPCGI2OTLAXZUMBMNAWQDQZX4AHANCNFSM4J3A4K7A> > . >

[GregTrevellick]

In my case the manifest.json served up successfully locally using IIS Express (via F5 in VS) with response header content type application/json.

But after deploying to server full IIS served up manifest.json with response header content type text/html (the default I believe). This caused (or was the effect of) a 401 not authorized error when serving up the manifest.json file.

I tried adding a MIME type to IIS for json files to no avail, and tried adding this to startup.cs

            var provider = new FileExtensionContentTypeProvider();
            provider.Mappings[".json"] = "application/json";
            app.UseStaticFiles(new StaticFileOptions
            {
                ContentTypeProvider = provider
            });

but neither worked.

The thing that did work, after much bingling, was to add crossorigin="use-credentials" to the html file (_Host.cshtml) like this:
<link href="/manifest.json" rel="manifest" crossorigin="use-credentials" />

[fnils]

I had the same problem in my case it was the start_url in the manifest.json file. It need the full path to the website.

I found the issue generating a report using lighthouse for progressive apps in the audit window in Chrome.
F12 --> Audits.

Maybe everyone knows this already but just in case someone doesn't.

[chucker]

@fnils if your base URL isn't /, check this comment: #5 (comment)