Service worker returning index page for nonexistent route

[BrandonClapp]

Is this a bug report?

Not sure. Trying to determine that.

Which terms did you search for in User Guide?

service worker

Environment

Node v6.9.2
NPM v3.10.9
react-scripts 1.0.14

Mac OSX El Capitan 10.11.6
Google Chrome Version 61.0.3163.100 (Official Build) (64-bit)

Steps to Reproduce

1. Scaffold a new react application following the instructions found on the user guide.
2. Serve index.html and all related artifacts in the ./build directory from my server.
3. Navigate to localhost:8080. Observe that the "Welcome to React" page is displayed.
4. Navigate to localhost:8080/idonotexist. Observe that the "Welcome to React" page is still displayed.

Expected Behavior

I expected the localhost:8080/idonotexist request to be handled by the server, rather than the service worker.

Actual Behavior

The service worker returns localhost:8080/idonotexist from the service worker. The page that is displayed is the default "Welcome to React" page.

Is this the desired behavior of the service worker? My understanding of service workers is limited, so I'm trying to determine if this is a bug or simply a gap in my knowledge.

Thanks for the great tool. Keep up the good work.

Brandon

[BrandonClapp]

I noticed that this also happens for routes that do exist on the server.

After a few hours of reading and experimenting, I've come to the conclusion that this is the intended behavior of create-react-app and this appears to be a catch all route "feature" in sw-precache-webpack-plugin.

After removing the service worker registration, doing an npm run build, disabling the service worker from my browser cache, then serving the production build from the server it seems to be working as expected.

However, when using development mode, the catch-all route is still enforced (even after removing the registration of the service worker) and I'm not sure if this is configurable. I've followed the user guide to use the proxy setting in package.json for routing my api calls to the server instance that I'm using locally and all seems to work fine now.

[goldhand]

Yeah the current behavior is kind of undesirable. There should be a way to handle navigateFallback without having to eject the app. See the bottom of this section in the doc about fallback routing or the SWPrecacheWebpackPlugin#navigateFallback config for source of whats going on.

Maybe create a feature request to support customizing the fallback url?

[gaearon]

cc @jeffposnick

[jeffposnick]

You're correct in all of your conclusions at #3299 (comment) The behavior you're observing can be modified while keeping service workers enabled, but only post-eject, since it's defined in the Webpack plugin config.

Balancing the benefits of offline-first navigations with the desire to avoid common pain points is being discussed at #3248

I'd imagine this issue could be closed in favor of that one.

[seejamescode]

If anyone is looking for a non-eject solution to this until #3419 is merged, you can use react-app-rewired with this config-overrides.js.

[stale]

This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in 7 days if no further activity occurs.