question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

[ServiceWorker] localhost took too long to respond. HTTP ERROR 504

See original GitHub issue

I’m submitting a…

[x] Bug report

Minimal reproduction of the problem with instructions

  1. ng new sw --service-worker --routing
  2. cd sw
  3. ng g c home
  4. ng g c about
  5. Edit app-routing.module.ts to add the routes for the 2 components we’ve just created:
// ...
import { HomeComponent } from './home/home.component';
import { AboutComponent } from './about/about.component';

const routes: Routes = [
  { path: '', component: HomeComponent },
  { path: 'about', component: AboutComponent }
];

// ...
  1. ng build --prod
  2. npm install -g http-server (you can use any server to test this, if you already prefer another one)
  3. http-server dist
  4. Access localhost:8080 (8080 is the default port that http-server uses at the time of reporting this issue)
  5. Access localhost:8080/about
  6. Stop the server
  7. Now try reloading the app while on the /about route (if it works the first time, try refreshing a few more times or wait a little before trying again). The browser will display the message:
This page isn’t working
localhost took too long to respond.
HTTP ERROR 504

(With Universal/SSR, it stops working right away, most of the time with the first refresh after stopping the server, no matter the route - and the issue is not the hash in the generated ngsw.json, because I regenerate that at the end of the build process).

Now, if you start the server again, loading the app on the /about route works (even though http-server is not SPA friendly, it doesn’t redirect all requests to index.html), but the service worker kicks in. Initially I noticed this behavior on a Universal app, doing server side rendering (following the universal-starter repo). So this is not a http-server “not being SPA friendly” issue. I only used http-server to reproduce it because I wanted to keep the reproduction process as fast as possible, without introducing server side rendering. The CLI version used (1.6.4) initializes the app with Angular 5.1.0, but I’ve also tested on 5.2.1. I’ve skipped mentioning this step above because it happens regardless of the Angular version (at least on >= 5.1.0, haven’t tested with older versions).

Environment

Angular CLI: 1.6.4
Node: 8.9.4
OS: win32 x64
Angular: 5.2.1

Browser:
I've only tested on:
- [x] Chrome (desktop) version 63.0.3239.132
- [x] Chrome (desktop) version 65.0.3323.2 (canary)

Issue Analytics

  • State:closed
  • Created 6 years ago
  • Reactions:23
  • Comments:72 (15 by maintainers)

github_iconTop GitHub Comments

22reactions
jackkoppacommented, Feb 16, 2018

I’ve been able to figure out two issue spots, that when worked around in my app, allow it to work offline. I won’t go into full detail here; I’ve given a long explanation on this SO answer.

  1. Hosted versions of an Angular app, where the --base-href flag is set from the CLI, list absolute URLs for their service worker resources. When comparing requests to these resources, ngsw-worker.js is expecting relative URLs
  2. Of the 3 available “states” that the ngsw-worker.js can be in, in my experience, EXISTING_CLIENTS_ONLY seems to bet set incorrectly.

(source code links are in the SO answer; I can duplicate them here as well)

My current workaround is running this build script, after ng build -prod and before http-server. If you can, give it a shot and see if it works for you? I’m trying to work on a pull request (# 1 above can definitely be fixed in the source, # 2 needs more investigation to avoid breaking anything); currently stymied by setting up a dev environment for the @angular/service-worker package

Final note: you can see my app working offline in this repo (using the build script at this line), and you can see a clone of that repo from the time where I was having the issue (so it still fails offline) here

15reactions
david-gengercommented, Feb 5, 2019

I’m voting this issue to be reopened.

Read more comments on GitHub >

github_iconTop Results From Across the Web

How to Fix the 504 Gateway Timeout Error on Your Site - Kinsta
A 504 Gateway Timeout error indicates that the web server is waiting too long to respond from another server and “timing out.
Read more >
504 Gateway Timeout Error: What It Is and How to Fix It
As mentioned before, a 504 Error means that a server upstream did not receive a "timely" response from another server further along upstream....
Read more >
How to Fix 504 Gateway Timeout Error: 10 Reliable Solutions
504 Gateway Time-out. The server didn't respond in time. This page isn't working. Domain took too long to respond. HTTP Error 504 –...
Read more >
504 Gateway Timeout - HTTP - MDN Web Docs
The HyperText Transfer Protocol (HTTP) 504 Gateway Timeout server error response code indicates that the server, while acting as a gateway ...
Read more >
Angular service worker with @angular/pwa package showing ...
Based on http error (504), maybe your problem is related to where you are hosting your pwa. So, basically, your connection with the...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found