How to handle 404 error request in vuejs SPA with nginx server

Question

I have set up my vue-cli version 3 SPA so that any requests not found in my routes.js file will default to my 404 view as shown in the official documentation:

Inserted near bottom of routes.js file:

{ // catches 404 errors
  path: '*',
  name: '404',
  component: () => import(/* webpackChunkName: "NotFoundComponent" */ './views/NotFoundComponent.vue'),
},

Inserted into nginx configuration file:

location / {
  try_files $uri $uri/ /index.html;
}

This successfully alerts the user that the page they requested doesn't exist.

My Question:

I would like for the error 404 component to return a 404 response header (it current returns the 200 status code) and also log this error to the nginx error.log file. I imagine this is only possible through using nginx configuration. Has anyone achieved this goal?

I noticed that this issue is addressed in the following page in the vue-cli official docs, but it only is concerned with node express servers and not nginx: https://router.vuejs.org/guide/essentials/history-mode.html#caveat

Solution 1

I think it is similar to Node solution - you should repeat all your routes in nginx config to return 404 status code correctly, the main idea is that you should use "equals" modifier in locations and define error_page to return same index.html file but with 404 status code, example:

server {
    listen       80;
    server_name  localhost;
    root /my/dir/with/app
    error_page  404 /index.html;

    location = / {
        try_files $uri $uri/ /index.html;
    }

    location = /books {
        try_files $uri $uri/ /index.html;
    }

    # example nested page
    location = /books/authors {
        try_files $uri $uri/ /index.html;
    }

    # example dynamic route to access book by id
    location ~ /books/\d+$ {
        try_files $uri $uri/ /index.html;
    }
}

Probably this config can be simplified or improved because I am not very good at nginx configuration but it works.

Solution 2

I solved this the easy way by breaking out of the Vue ecosystem else it wont work or would take a lot of effort.

Make the following route in your Vue router:

{
  path: '*',
  name: 'PageNotFound',
  component: PageNotFound
}

The PageNotFound component should have the following code:

<script>
export default {
  name: 'PageNotFound',
  created() {
    window.location.href = "/404/"
  }
}
</script>

The nginx config should return a 404 on getting /404/ route:

server {
    ...
    location ~ ^/404/$ {
        return 404;
    }
    ...
}

I don't think it would work in a server side rendering environment. In such a case you might need to put the statement containing window.location.href in the mounted method.

Solution 3

For whoever lands into this issue and to save you hours of headaches.

Caveats with above answers

1. Simply reloading the page with a new URL (e.g. /notfound) does not solve it since that means that a potential spider already received 200.
2. Simply copying the routes, is a half-solution. That works with URLs that are never going to change and by checking the validity of the URL structure. So for example it can check if the book id in books/123 has the right format, but it can't check if books/123 actually exists in the backend.

---

Here's two approaches that can tackle the above issues

1. Have Nginx to make a mirrored subrequest to the backend to check if the resource actually exists. Then always return index.html but with the status from the subrequest's response. This is very tricky with Nginx, since by design it makes it very hard to combine answers.
2. Have the backend API to return index.html for Accept: text/html. Then Nginx simply needs to forward responses.

The first solution is a pain in the ass for someone not familiar with Nginx. It requires to get Lua with OpenResty and then again you will run into all kinds of quirks with how Nginx works. You end up with a lot of hard-to-read code and that makes it extra hard if you further-more want to introduce caching.

The second solution is easier. The only possible negative is that it means that you can't view the API from the browser if that's something currently you have in place.

nginx.config (when API responds with index.html on Accept: text/html)

    location / {
      try_files $uri $uri/ @fallback;
    }

    location @fallback {
      rewrite ^(.*) /api$1 break;
      proxy_set_header "Accept" "text/html";
      proxy_pass http://localhost:8000;
    }

In this case, Nginx will try first to serve the file and in case it doesn't find it locally, it will go through the fallback.

In the fallback we rewrite the URI to match what the backend server expects. In this example I prepend api/ to each request. Then I add the header Accept: text/html so that the backend API will respond with the index.html instead of JSON. And lastly we directly give back the response to the client.

This has the below benefits:

1. It does not rely on Nginx so it can work with any reverse proxy. Most importantly it does not rely on the proxy server to have certain features.
2. Works even during development without having Nginx running.
3. Easy to write tests for. You simply have to test your backend API for spitting out index.html when given Accept: text/html for any endpoint.
4. Does not require you to manually update Nginx configuration with each new endpoint.

Furthermore you can change the config to make Nginx follow redirects internally, and possibly not even having to look at the backend API for URLs that never change.

Comments

[GustavMahler]

This makes sense. I'll try it out and mark as answered if it works. Thank you Max!

[Pithikos]

This is good in some cases. I see only 2 problems: (1) The URL that resolved to 404, will not be visible in the address bar, (2) the redirection occurs quite late, after the browser already has received the initial 200. This probably will confuse crawlers.

[Pithikos]

Note /books/666 will give 200 regardless if it exists or not. There must be a way to check the response from the application server before forwarding a response.

[Soubriquet]

I tried this, but keep getting 404 on /about