Service Worker Http Error 504 When Build Using --base-href=./ (Dynamic Base Href)

[willy-juisan]

I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[x] Bug report  
[ ] Performance issue
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question
[ ] Other... Please describe:

Current behavior

Whenever the application load for first time, and then the network goes offline, the service worker couldn't provide the application cache and failed with http error 504 as shown below:

Expected behavior

The service worker could provide the application cache and the application could still be loaded even when the network goes offline.

Minimal reproduction of the problem with instructions

1. ng new sw2 --routing
2. cd sw2
3. ng add @angular/pwa --project sw2
4. ng build --prod --base-href=./
5. cd dist
6. cd sw2
7. npm install -g http-server (you can use any server to test this, if you prefer another one)
8. http-server
9. Access localhost:8080 (8080 is the default port that http-server use at the time of reporting this issue)
10. Stop the server
11. Now try reloading the app again, and the browser will display the message:

This page isn’t working
localhost took too long to respond.
HTTP ERROR 504

What is the motivation / use case for changing the behavior?

I need to build my angular application with dynamic base href, because my application will be deployed as any name context e. g. client1app, client2app, /external/client3app, etc.
The application should be working good even when the network is offline (still loaded correctly with cached resources and data).

Environment

Angular version: 6.0.9
Angular CLI version: 6.0.8

Browser:
- [x] Chrome (desktop) version 67.0.3396.99 (Official Build) (64-bit)
 
For Tooling issues:
- Node version: v8.9.4 
- Platform: Windows 7 

[gkalpak]

Currently, the SW needs to know the absolute URL to the files. Why do you need a "generic" version?
Won't you have a different build for each deploy context? If anything, the base[href] needs to be changed. How do you handle that?

[willy-juisan]

@gkalpak : I need SW to handle the URL files as an relative path, not absolute path. There are case where in my client environment, the app deployed as any name they want, let say clientApp1. Then from their internal network, the client only could access the application using this url : https://some.domain.name/clientApp1, but from external network (or internet), the client only could access the application using this url : https://some.domain.name/esb/frontend/clientApp1 due to their environment infrastructure have ESB or any other web server routing for their own reason (mostly because security).
So for above case, we can't have different build for each deployment context, since we only have one deployment, but the URL for accessing the application is different, base on user network connection. I really hope this feature could be added to angular service worker, since I believe large scale / enterprise user will probably have this kind of setup and environment.

[gkalpak]

I see. I think it makes sense. Basically, this is a feature request to support relative paths in ngsw.json, which would be resolved at runtime relative to the SW scope.

AFAICT, that would affect index, assetGroup > urls, and hashTable (in the generated ngsw.json).

[willy-juisan]

@gkalpak : Thank you for your understanding. It's there anything I could do to fasten the development of this feature? Since this feature is critical for my application.

[gkalpak]

Pull requests usually help 😉
TBH, this is not a high priority atm, so do not expect a quick turn-around. But if you want to dive in, I would be more than happy to provide help and guidance (and reviews) 😃

[willy-juisan]

@gkalpak : sounds challenging, so how do I dive in to add this feature? TBH, this is a useful feature, because it will make our angular application more flexible in deployment, rather than do every build for every deployment.

[gkalpak]

Yes, it is challenging (especially if you are not familiar with the @angular/service-worker implementation).
So, I started writing up some info to give you pointers to where to start looking at it, but I ended up implementing it 😁

You can find the built code that (I think) adds support for relative baseHref here.
Note: The ngsw-worker.js file is copied into your dist directory when building the app. You need to replace the original ngsw-worker.js file with the one in the gist above.

I fixed a couple of other minor issues I stumbled upon, but the main fix is about getting relative URLs to work in ngsw.json (the generated manifest) - relative to the SW scope. You can see the diff here.

This is not in a PR-ready state, of course. This is the built artifact produced by the source code. To make a PR, one would have to port the changes from the diff to the actual source files and write some tests 😁

I don't have time to clean this up and submit a proper PR, but if you or anyone else feels like helping out, you have a good starting point. (I understand you might be less incentivised now 😁)
Of course, I am still happy to assist along the way.

[gkalpak]

@willy-juisan, could you at least try it out and let me know if it actually works (so someone else (or me) can turn it into a PR)?

[sheikalthaf]

@gkalpak Hi,

I'm facing an issue in service worker. I'm using angular i18n in my project and it has two build with en and de. Both language is hosted with different base URL in same domain. If i try to switch language then i'm getting error Cannot match any routes. URL Segment: 'en/rider/description'. Then i got a update promt with service worker update check but there is no build published. after the update i can able to switch. again repeat from above the issue continues

Maybe it happens due to both the service workers runs simultaneously due to same domain. Please help me to resolve the issue

Thanks in Advance

[gkalpak]

@sheikalthaf, you didn't provide enough info for me to fully understand the problem, but it sounds like it doesn't fall into the bug report or feature request category. GitHub issues are not suitable for support requests, please repost your issue on StackOverflow using tag angular.

(If you think there is a bug in Angular or want to request a feature, please open a new issue and provide all the necessary details, including a minimal reproduction.)

_{If you are wondering why we don't resolve support issues via the issue tracker, please check out this explanation.}

[vallgrenerik]

@gkalpak I've created a thread on StackOverflow with a similar problem. Could you please take a look at it?

[angular-automatic-lock-bot]

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.}