Repository navigation
[ServiceWorker] localhost took too long to respond. HTTP ERROR 504 #21636
Description
I'm submitting a...
[x] Bug report
Minimal reproduction of the problem with instructions
ng new sw --service-worker --routingcd swng g c homeng g c about- Edit
app-routing.module.tsto 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 }
];
// ...
ng build --prodnpm install -g http-server(you can use any server to test this, if you already prefer another one)http-server dist- Access
localhost:8080(8080 is the default port that http-server uses at the time of reporting this issue) - Access
localhost:8080/about - Stop the server
- Now try reloading the app while on the
/aboutroute (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)
Activity
NgxDev commentedon Jan 24, 2018
I've just realised that the same things also happen with API requests (urls which are set up in "dataGroups"), not just with static assets. If I stop the API server, I get
504 Gateway Timeout (from ServiceWorker)if I open to check the network tab.I'm sure that this was working fine at some point in the past, but the more I think about it, the more I'm wondering if this might rather be an issue for the CLI instead?...
odahcam commentedon Jan 30, 2018
I'm with the same error here, when I'm online I can see a lot of things being loaded by the service worker, but when I turn into online, nothing is loaded.
odahcam commentedon Jan 30, 2018
Seems like when I disable the SW registration already having it registered, the offline functionality works fine. 🤔
KGALLET commentedon Feb 1, 2018
Seems like I've got the same issue
jackkoppa commentedon Feb 4, 2018
I believe the root cause would be the same as the issue for this SO question I posted: How to handle routing in Angular 5+ Service Workers? It doesn't seem that Angular 5+ gives us a way to route service worker handling for non-index routes, at least that I can find.
DominicBoettger commentedon Feb 8, 2018
same error here? So is the service worker in ng5 not usable?
odahcam commentedon Feb 8, 2018
In CLI projects it works fine, I really don't know what's the problem. 😕
jackkoppa commentedon Feb 8, 2018
@odahcam - does that mean, in a CLI project on Angular 5, you're able to handle routing with the generated service worker? And if so, how? Sorry, not sure if you mean "you don't know where the problem comes from" or "you're not sure what problem other people are having, because it works for you"
jackkoppa commentedon Feb 8, 2018
Hi @alxhub - would you be able to give input on whether the
ServiceWorkerModulehas the "routing" functionality, that was in older versions of the@angular/service-workerpackage? I know at the time you gave this talk (linked w/ timestamp), thengsw-manifest.jsoncould be auto-generated with routing based on the AppModule. But now route handling doesn't seem to be anywhere in the docs, which leads to the 504 errors as in this issue, for non-index, non-dataGroup routes. Would be happy to attempt to work on this, but I'm guessing I've missed some discussion about future direction for the service-worker packageodahcam commentedon Feb 8, 2018
I don't know where the problem came from, I only saw it after
ng ejectand working without the CLI. With the CLI everything always worked fine for me. 😕 ²59 remaining items
DanielRuf commentedon May 27, 2019
We have no thirdparty which changes the files in our case ;-) Our CI builds rsync the files to the server and server content does not change.
RamBoFe commentedon Jun 12, 2019
Hello,
I had the same problem and after reading the conversation, it turns out that my problem was with the FTP client I was using to send my Angular project to the host.
I was using FileZilla and noticed that the size of the files sent including the ngsw.json file was different from my local file once on the FTP server. And that was what caused my problem. Since I use WinSCP I have no problems anymore and my project works offline :)
DanielRuf commentedon Jun 12, 2019
Hi @RamBoFe,
you might like to try CyberDuck too. The problem may be normal vs binary transfer (use the binary one).
RamBoFe commentedon Jun 12, 2019
Thank you @DanielRuf,
I'll try CyberDuck ;)
danieldanielecki commentedon Jun 18, 2019
Same issue here, working on Firefox "Work Offline", but on Chrome have 504. Using Angular 7 with Firebase hosting.
david-genger commentedon Jun 19, 2019
Same here using chrome 74 and Angular 8. Not working.
zain-b commentedon Jul 18, 2019
Same issue, Angular 8
jrcasso commentedon Aug 6, 2019
Same issue, Angular 8 also. Lazy-loaded feature modules, the works.
Service Workers are a constant pain in my ass with Angular.
For example, as a test, I have one of my dataGroups caching all PHP requests:
{ "name": "test", "urls": [ "/**/*.php" ], "version": 0, "cacheConfig": { "maxSize": 200, "maxAge": "7d", "timeout?": "3s", "strategy": "freshness" } }...and not a single call to my PHP API is cached. It feels like every time I rebuild a branch for an enterprise production master, the service worker may or may not cache GET requests for offline PWA usage, for reasons that are seemingly arbitrary. It's debilitating, frustrating, and dysfunctional.
pzuschlag commentedon Aug 6, 2019
Thanks for this comment! For a long time, I thought, I'm the only one who feels like that!
H--o-l commentedon Aug 6, 2019
@jrcasso @zuschy guys (or girl) it's an open-source project.
First, thank people that have given time building it so you do not have to do it yourself.
Second, if you think it should be improved, and have idea how to do it, open issues/PRs.
You have the right to look at the service code, it's not that hard.
Finally, if this code does not match your needs, there is other pre-written service workers out there which work fine with Angular.
I personnally think the Angular service worker have some unique concepts that makes it powerfull (no need to
skipWait()between app versions, multiple app versions in parrallel, nice self-hosted debug page/ngsw/state, in-app service to control it, etc), but you have to be meticulous at configuring it.If there are bugs, your comments certainly does not help fixing them.
pzuschlag commentedon Aug 6, 2019
@H--o-l don't get me wrong, I agree with you.
But sometimes it appears, that the service worker arbitrary does or does't cache requests.
I built the same code, serveral times, on different servers, but the behavior is never the same. I try continuously to find the right configuration, but the behavior of the service worker isn't clearly reproducible, this is frustrating.
Sometimes it's good to know, that you're not alone with a problem like that.
That doesn't mean, that we doesn't try to find a way to fix the bug! ;)
NgxDev commentedon Aug 6, 2019
@H--o-l
To be honest, I haven't checked lately if the same reproduction steps still apply, or if people are running into this in some more specific scenarios. I guess it doesn't bother me that much because I don't have any apps that truly need to work offline, I only use the ServiceWorker to benefit from faster load times (after that first load, when it builds the cache, of course).
As simple as it may look for some, other people surely either don't have the time or the understanding of what's going on there. I tend to understand people's frustration, if an issue has been marked as resolved but it's still happening for them. As long as they're not hateful, I usually "thumbs up" comments that report the issue still happening. I always thought that reopening an issue is better than opening a new one, identical to an existing one. But that's just my opinion.
I don't think this is about "needs matching". As long as the app loads in offline mode when accessing
/and doesn't load when accessing/some/route/(and we're not talking about a misconfigured server - especially if we're "offline", that wouldn't even matter, since we don't even reach the server), that seems like a bug. If I really needed my apps to "fully" work offline, I guess this would be frustrating for me as well, to have the issue resolved/closed, but the reported behavior still happening.Agree! I guess that's why people prefer the built-in option, rather than 3rd party solutions.
But, like I said, not everybody has the time or understanding to be able to come with bug fixes, improvements etc. I don't think that they don't appreciate the team, the contributors, the community. Maybe just lacking expressing gratitude sometimes or (like me) thinking it's iimplied automatically.
That being said, I always thought that big "thank you" 's are implied 😃. Surely, every developer using it is grateful for everything that the Angular framework (or, rather, the entire ecosystem) does for us, grateful for everything that the core team and every contributor is doing, and for the whole community. But I guess you're right, not saying it makes it seem like it's not appreciated enough.
jrcasso commentedon Aug 15, 2019
@H--o-l
You're confusing my frustration with ingratitude.
This is essentially the same as saying "You fix it." which I did, outside of the framework. I don't know what kind of life you have where you have the time to PR Angular issues, but I don't have it. Frankly, that's the reason I picked Angular as a framework in the first place; I figured it was reliable and highly functional requiring minimal non-native additions. This is clearly not the case with Service Workers, and I disagree with your assertion that my comment isn't helpful. It's a closed issue that I believe to be very open, and voicing my frustration about that can bring attention to the issue. Moreover, I provided a small snippet that fails in my use-case.
Bingo. If life affords me some time, I'll see if my fix applies to Angular and submit a PR.
Obviously I agree Angular is great. That's why we're here in the first place. But I also don't think your comment helped the issue. In fact, it seems like you focused entirely on the tone of my comment than the content: the issue is still open.
You might notice more frustration in the tone here; that's because I find your fixation on my tone in the first comment to be unnecessary in the context of fixing the issue.
angular-automatic-lock-bot commentedon Sep 15, 2019
This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.
Read more about our automatic conversation locking policy.
This action has been performed automatically by a bot.