Prefix strategy 404 error on initial load (static)

[divine]

Version

nuxt-i18n: 6.13.1
nuxt: 2.13.3

Nuxt configuration

mode:

• universal with static render

Nuxt-i18n configuration

i18n: {
    strategy: 'prefix'
}

With target: "static" in nuxt.config.js

Reproduction Link

CodeSandbox: https://codesandbox.io/s/nuxt-nuxt-i18n-base-template-8boev?file=/nuxt.config.js:123-143

Another Demo: https://present-feet.surge.sh
Github: https://github.com/divine/i18nuxt-redirect-bug-master

Steps to reproduce

Change strategy to prefix and target to static.

What is Expected?

Index page after that it should redirect to detected language prefix.

What is actually happening?

Initial load shows 404 error after that redirection happens.

Similar issues are #700 , #677 #491.

---

@rchl

Note that next version of Nuxt will do some command renaming again (deprecate the export command) so might be better to wait for that before taking a look

In my opinion it has nothing to do with the export command (see codesanbox or github repo) and I don't think that waiting might help, if there is an issue that might need a fix upstream (nuxtjs) it's better to report it now.

Thanks!

[rchl]

Created fix at #808

While making it, I was wondering if it's even correct/necessary for me to do that since Nuxt generates the fallback route (200.html) itself and it should be possible to set that route as 404-handler on any hosting.

[rchl]

Released in v6.13.2

[violoncelloCH]

hi @rchl
I made use of #808 and noticed that routes are generated for every static route (corresponding .vue file in pages/) but not for dynamic routes. For dynamic routes only the prefixed variants are generated. Do you want me to provide a reproduction repo and/or to open a new issue for this?

[rchl]

Yes, a new issue would be preferred.

But I'm still not sure whether that whole "generate fallback routes" business makes sense even. Did anyone of you try using the generated 200.html as a fallback instead? I suppose hosting services support hooking up a custom path to a 404 handler. Another benefit of that would be that actual 404 handling would be better.

[rchl]

For example, for Netlify see https://nuxtjs.org/faq/netlify-deployment/
Setting:

  generate: {
    fallback: true
  },

will generate 404.html file which Netlify will automatically use on visiting a route that doesn't exist. And I would assume that then i18n would redirect to an existing route if one exists.

[violoncelloCH]

okay, will do so...

well, I set the 200.html (or 404.html in my case) as ErrorDocument, so on any not found route the webserver returns the general fallback with status code 404. Therefore I think it makes sense to have those routes generated so they are served with status code 200. (And in case of mode: universal, target: static it also means that those routes are even displayed on a browser without / with disabled javascript as they are rendered directly as html/css whereas the generic fallback always needs js to be executed)

[divine]

@violoncelloCH yeah, that was the main issue I was having.

Hosting services returns 404 error code after that redirection happens not something that makes sense for main path route.

[violoncelloCH]

Yes, a new issue would be preferred.

#822

@violoncelloCH yeah, that was the main issue I was having.

Hosting services returns 404 error code after that redirection happens not something that makes sense for main path route.

exactly... on Apache/Nginx one could generate some fancy redirection rules which would try to redirect every non-prefixed route to it's (default) prefixed variant and try if this one is found before returning a 404, but this gets quickly quite complicated. Also, I've no idea if redirects like this are even possible on Netlify and the likes...

[notflip]

@violoncelloCH Did you find a way to make this work using Nginx?