Failed to load resource - problem loading SW in Nginx

Same here.

A bad HTTP response code (404) was received when fetching the script. /pwa/1/serviceworker.js:1
Failed to load resource: net::ERR_INVALID_RESPONSE  https://example.org/pwa/1/serviceworker.js

Did you go to the settings page and save the form once? Might be the install step doesn't do everything it's supposed to do.

@nod_, yes, I have saved them one. The module seems to be working on my smartphone, but I still see the errors from time to time in my chromium browser. I will have a look in my nginx log files.

@molnitza, did you happen to resolve this issue?
I'm also facing this problem so if you've managed to solve this I'm curious to know how you fixed it.

The two error reports are different. The OP was trying to load a file called [object%20Object] and comment #2 has a 404 for the actual SW as defined in the module code.

I will be alert for this but i haven't run across it while developing.

I can also confirm this issue:

Failed to register/update a ServiceWorker for scope ‘https://example.com/’: Load failed with status 404 for script ‘https://example.com/pwa/2/serviceworker.js’.

Additional debugging shows the following:

Notice: Undefined property: stdClass::$headers in _pwa_fetch_offline_page_resources() (line 226 of /var/www/html/example.com/sites/all/modules/contrib/pwa/pwa.module).

I am using 7.56, with PWA version 7.x-1.x-dev with PHP 7, and NGINX server.

I am also getting this with the 8.x-1.x version on a fresh install.

Loading failed for the

If you are using Nginx (probably the same for Apache - I haven't tested), chances are that the server will not find the serviceworker.js file as it is now. This is because the module generates the .js file dynamically through Drupal's index.php.

There are two possible solutions (the first is better):

1 - If you have access to change the Nginx config file for your website, add the following block to the file:

    ## PWA serviceworker support.
    location ~ ^/pwa/[0-9a-z]+/serviceworker.js {
       try_files $uri /index.php?$query_string;
    }

Note: If you are using Apache, you may have to work with the .htaccess file to get a similar result (using different code, obviously).

That block should be placed right before any block where you define how JavaScript files are to be handled. In my case, I had to put it immediately above the following block:

    location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff)$ {
        expires max;
        log_not_found off;
        access_log off;
    }

After adding the first block above, you need to reload Nginx (or Apache) for the changes to be picked up.

2 - The second option, which I haven't tried and would be the last resource, is to hack the module. Yes, I said hack the module, but only if you don't have access to Nginx configs.

To shamelessly hack the module, as the last resource, do a search inside the file pwa.module and replace all instances of "serviceworker.js" with "serviceworker". That should do the trick.

Obviously, if you are going to hack the module, do it responsibly, create a patch and put it somewhere so that you can reapply the patch to the module in the future when this module gets updated.

Related issue here with Drupal 8.5 and Apache, with latest dev version of pwa:
WSOD on all pages and these messages in logs:
"GET /serviceworker-pwa.js HTTP/1.1" 404 904
"GET /modules/pwa/js/serviceworker.js?oy2r7q HTTP/1.1" 404 922

used drush cr and tried to disable/uninstall pwa with drush, but I still get these errors and wsod everywhere.

I don't see how to adapt @jcmartinez's solution to apache, any hints to fix the issue or disable the module for good will be appreciated!

If you have Fast404 installed, it may give you same result. You need to add "/serviceworker.js" into

$conf['fast_404_string_whitelisting'][] = "/serviceworker.js";

array.

Switching major versions since most of the feedback transitioned to 8.x installations and I still have yet to repro while developing 7.x branch.

You should be able to fix this by not making the callback path end in .js. That way server config won't choke on it. /pwa/serviceworker/js should do the trick. The callback injects the correct Content-Type header, so nothing should break. 🤞🏻

Ok thanks for the tip, I'll do some testing to see if it breaks an existing installation to swap out the registration URL. Worst case I guess we'll break <300 sites and fix it for the future.

Per @cafuego in chat, we can also add an additional HTTP header to ensure the file is downloaded with an extension:

Content-Disposition: inline; filename="serviceworker.js"

Patch providing a method to switch the menu endpoint to use, using a variable pwa_serviceworker_path, so it doesn't break existing sites.

Note that #16 is a *maybe*

@attiks I think you forgot to attach the patch ;)

Grrrr

I looked into this and apparently if the scope is identical, the newest SW gets priority. We can safely patch the module with a new hardcoded location.

• https://w3c.github.io/ServiceWorker/#service-worker-registration-concept
• https://w3c.github.io/ServiceWorker/#get-newest-worker

A service worker registration of an identical scope url when one already exists in the user agent causes the existing service worker registration to be replaced.

My gut feeling is that allowing a configurable path will invite problems but I'll give it a try. I'll test the following scenarios on nginx:

• Existing 1.0 code
• New SW URL
• Upgrade path to new SW URL
• Effect of changing SW URL via admin config

It might be time to break out Puppeteer and have a testing suite built into the module so I can rapidly test several scenarios like this one.

Ok let's give this one a try. The route is hardcoded, it no longer has the extension, and the header is set to be extra careful about the download of the file itself.

Nice job, works like a charm

Alright, committed to dev! Hopefully this cuts down on nginx issues.

Tossing issue to 8.x branch since it seemed to be an issue in both versions of the module.

This solves the problem for D8 + nginx in a similar fashion, pending a fix for multilingual sites since they try to redirect the serviceworker which is not permitted.

Update issue status

This patch seems to be coding style, apart from the single line of code where ".js" was dropped from the pwa.routing.yml

Is there a coding standard we weren't following or was this just your preference?

It's the standard enforced by Prettier, I was told that's coding standard of choice for Drupal :)

Disabled route normalisation for the service worker path because multi-lingual sites break the service worker

ok this one is committed and hopefully it works on nginx now. thanks for the patch!