Registering a ServiceWorker with type set to 'module' serves text/html MIME

[guest271314]

Describe the bug Registering a ServiceWorker with type set to 'module' serves text/html MIME.

To Reproduce Steps to reproduce the behavior:

1. Register a ServiceWorker with type set to 'module'.

Errors / logs in developer tools

Failed to register a ServiceWorker for scope
 ('https://run.plnkr.co/preview/clfe90h0l00052v759v2crhd0/') 
 with script ('https://run.plnkr.co/preview/clfe90h0l00052v759v2crhd0/sw.js?=1679160846816'): 
 The script has an unsupported MIME type ('text/html').

Expected behavior Served Type in Chromium DevTools Network panel should be script.

Screenshots

With type set to 'module'

Without type set to 'module'

Desktop (please complete the following information):

• OS: Linux
• Browser: Chromium
• Version: 113

Additional context https://plnkr.co/edit/qX5tepJ38BuDOSZj?preview

[ggoodman]

I'm not seeing that behaviour in Chrome 113. Is that issue persisting?

[guest271314]

Yes. Chromium Version 115.0.5774.0 (Developer Build) (64-bit)

      const sw = await navigator.serviceWorker.register(
        `./sw.js?=${new Date().getTime()}`,
      {
        scope: './',
        type: 'module', // Uncomment this line in linked plnkr
        updateViaCache: 'none',
      });

[ggoodman]

I think I might see what's going on. One of the mitigations I had to add to Plnkr to deal with spammers and abusers was the 'phishing warning'. This is a sort of interstitial html page that gets rendered for all previews and saved plunks unless they're shown in the context of an editor preview or other controlled ways.

The way that they work is by setting a cookie to indicate that the user has accepted the risk of visiting the page.

I suspect that what is happening is that when the sw.js file is requested as a type=module, the browser is changing the set of credentials it attaches to the request. One of the things that is probably getting not getting added in this opaque request is the cookie header. As a result, the preview server thinks that the request requires this phishing warning (which is a text/html page).

I'm not familiar with the mechanics of module service workers; is there any option you can pass when registering to indicate that the request should be authenticated?

[guest271314]

I'm not familiar with the mechanics of module service workers; is there any option you can pass when registering to indicate that the request should be authenticated?

Not that I am aware of https://w3c.github.io/ServiceWorker/#serviceworkerregistration.

At the front-end all I can verify is the resource is served with this header

Content-Type:
text/html; charset=utf-8

JavaScript modules require text/javascript content-type header to be served, with the exception being import Ecmascript assertions, which supports JSON.