angular: Angular Service worker incorrectly intercepting http redirects (302)

So, it sounds you like all three options 😁

What I like about the 3rd oprion is that it is more generic. I would like to try that first (unless we find out it has shortcomings while working on it). (This is also likely the most straight forward to implement, because the association between the requested resources and their cache is clearly defined.)

if it’s good “first contribution” issue

SW issues are generally not good first issues, because SW is quite different than other front-end code people are used working on. (It’s a little like a server and is very powerful (i.e. even a small change in behavior can significantly impact apps).

But you already seems to have a good grasp of SWs (and @angular/service-worker in particular), so you might want to give it a go 😃

_{(Truth be told, this is probably going to be somewhat more complicated than expected.)}

This is the exact problem I was facing as well before and opened two issues:

• https://github.com/angular/angular/issues/36068 (closed it myself the same day - no clue why 😇)
• https://github.com/angular/angular/issues/36099

Hope this can help us moving this issue forward.

I think the reproduction should be possible with the minimal setup just creating a dummy redirect with any server while having Angular Service Worker enabled.

@gkalpak your initial thoughts on the matter were the following:

I feel like this is too specific a usecase (and one that doesn’t fit very well with SW caching) to be worth supporting in @angular/service-worker.

Personally, I would consider redirecting to login from the client (subject to whether the browser is online or not).

If your stance on this issue has changed that would be really great. If not we do have a client redirect as a workaround. I am slightly surprised that only a handful of people hit this problem, considering http redirect is an valid solution for a wide range of problems.

Awesome! LMK if you need any help.

I am just trying to fully understand the usecase/requirements in order to determine if/how it should be addressed 😃 (Basically, I am trying to avoid implementing a fix only to find out one month later that it doesn’t cover other similar scenarios and a different fix is needed 😁)

Thinking about it again, I guess that an app would break anyway (i.e. even without the SW) if the server returned a redirect to a non-navigate request, right? So, the SW shouldn’t need to handle the non-navigate requests specially anyway.

FYI, I am still trying to wrap my head around this issue and how to best address it.

@klemenoslaj, have you verified that the fix you proposed in https://github.com/angular/angular/issues/36099 (which is similar to what is shown in the blog post you mentioned above) works for this usecase? AFAICT, it would only work if the redirection target allows cross-origin requests, which is not necessarily the case. What did I miss?

@gkalpak I created one repository with a very stupid express server: https://github.com/klemenoslaj/ng-pwa-redirect

To describe the problem from the beginning, keycloak and other similar solutions are using a http redirect to bring user back to their login page when the session is lost.

So the expected flow is something like:

• browser refresh
• request for index.html
• not authenticated - redirect using navigate 302
• user lands on keycloak login page

What happens with SW enabled:

• browser refresh
• no request for index.html
• not authenticated - first arbitrary http request is redirected (e.g. rest call or anything else)
• user is not redirected page is loaded with broken session

The error looks something along these lines:

Access to fetch at 'https://www.google.com/' (redirected from 'http://localhost:3000/ngsw.json?ngsw-cache-bust=0.3744734012346962') from origin 'http://localhost:3000' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

To reproduce, please clone the repo mentioned above and follow the steps:

• execute yarn
• execute yarn server:build
• execute yarn app:build
• execute yarn server:start
• open browser with http://localhost:3000
  • application will load, all files will be requested and cached by the SW
• terminate server (cmd+c or ctrl+c)
• execute yarn server:start-redirect
  • server will redirect the first request (without SW you’d land on Google, with SW error is thrown)

Please let me know if you have any questions.

No worries, @Aubry-a. Your English is fine (I am not a native speaker myself either). This kind of things are better expressed in code anyway 😛